Notre précédent article du 27 avril annonçait l'agrément définitif d'Odoo comme Plateforme Agréée par la DGFiP. Le débat stratégique « Odoo ou PDP externe » est tranché. Place désormais aux questions concrètes que se posent les équipes finance, comptabilité, ADV et systèmes d'information : comment ça va se passer chez nous ? Quels workflows ? Quels paramétrages ? Quels écarts par rapport à nos processus actuels ? Le courriel d'Odoo France du 18 mai à ses partenaires intégrateurs apporte enfin la matière opérationnelle. Cet article décortique l'architecture, les flux, les statuts, les référentiels et les 42 cas d'usage sous un angle terrain — celui d'un chef de projet ERP qui doit livrer la conformité en septembre.
1. Du « c'est validé » au « voici comment on le met en œuvre »
Le 27 avril, nous avons partagé sur ce blog la bonne nouvelle attendue depuis des mois : Odoo n'est plus en immatriculation « sous réserve », l'agrément définitif est obtenu, les tests d'interopérabilité avec le Portail Public de Facturation sont validés. Pour les directions financières, c'était la levée de la dernière incertitude majeure.
Depuis, une autre question monte chez nos clients : comment cela va-t-il s'opérer concrètement dans notre base Odoo ? Quels changements dans le quotidien de la comptabilité ? Quels écarts d'effort selon notre version actuelle ? Quels référentiels à nettoyer en priorité ?
Le courriel transmis par Odoo France à ses partenaires intégrateurs le 18 mai apporte enfin cette matière opérationnelle. C'est le sujet de cet article : pas la stratégie de conformité (déjà traitée en avril), mais la mécanique de déploiement.
2. Architecture fonctionnelle de la solution Odoo PA
2.1. Le rôle de la Plateforme Agréée
Dans la réforme française, une Plateforme Agréée joue trois rôles simultanément :
- Routeur de factures B2B : elle transmet les factures structurées émises par votre entreprise aux PA de vos clients, via le réseau Peppol entre PA.
- Émetteur d'E-reporting : elle transmet à l'administration les données de transactions non couvertes par la facturation électronique (B2C, B2B international, opérations en numéraire, paiements).
- Gestionnaire de statuts : elle reçoit, met à jour et redistribue les statuts de cycle de vie des factures (déposée, rejetée, refusée, encaissée, etc.).
Odoo a fait le choix d'intégrer ces trois fonctions nativement dans l'ERP. Pas de connecteur externe, pas de PDP tierce à brancher, pas de coût par facture, pas de contrat séparé à négocier. Tout se passe dans Odoo.
2.2. Le schéma de flux pour le B2B France
Pour une facture émise depuis votre Odoo vers un client professionnel français :
- La facture est générée nativement dans Odoo (devis → bon de commande → facture, ou facturation directe).
- Odoo PA convertit automatiquement la facture au format normé (Factur-X ou UBL).
- La facture est routée via Peppol entre PA jusqu'à la PA du client destinataire.
- En parallèle, la facture est transmise au Portail Public de Facturation (PPF) qui en conserve l'archivage légal.
- Les statuts de cycle de vie remontent automatiquement dans Odoo au fil de l'eau.
Conséquence opérationnelle : la facture n'est plus envoyée par courriel. Le PDF reste générable pour archivage interne ou usage commercial, mais la transmission légale passe par le réseau de plateformes.
2.3. Le schéma de flux pour le E-reporting
Pour les flux qui ne sont pas du B2B France (B2C, B2B international, paiements) :
- Odoo collecte les données pertinentes au fil de la facturation et des encaissements.
- Avant chaque échéance imposée par la DGFiP, Odoo PA agrège ces données dans un fichier structuré.
- Le fichier est transmis automatiquement au PPF.
- Aucune intervention manuelle requise sur le périmètre standard.
3. ⚠️ Le module « Facturation électronique » actuel : à ne pas confondre
Point d'attention que nous remontons systématiquement à nos clients lors des audits.
Dans votre base Odoo, vous trouvez aujourd'hui un module nommé « Facturation électronique ». Plusieurs équipes ont, en toute bonne foi, activé ce module et inscrit leur société dans les annuaires Peppol pensant être en avance sur la conformité.
Ce module n'est PAS le futur module PA d'Odoo. C'est un connecteur Peppol générique, pertinent dans des contextes européens (notamment B2G en Belgique ou aux Pays-Bas), mais qui n'a pas vocation à remplir les exigences françaises de la PA.
Conduite à tenir :
- Ne pas activer le module actuel s'il ne l'est pas.
- Si vous l'avez activé et inscrit votre société dans un annuaire, prévenez votre intégrateur avant la publication du module officiel pour éviter les conflits techniques au moment du déploiement.
- Attendre la communication officielle d'Odoo sur la disponibilité du nouveau module PA, qui interviendra dans les prochaines semaines.
4. Les versions Odoo prises en charge
Précision importante apportée par Odoo le 18 mai par rapport à notre article d'avril : le rétroportage en V17 est désormais confirmé, alors qu'il était encore en discussion il y a un mois.
| Version | Statut PA | Délai de mise à disposition | Délai correctifs |
|---|---|---|---|
| V19 | Supportée par construction | À la sortie du module officiel | En temps réel |
| V18 | Version cible prioritaire d'Odoo | À la sortie du module officiel | En premier |
| V17 | Rétroportage confirmé | Quelques semaines de décalage | Quelques semaines de décalage |
| V16 et antérieures | Non supporté | — | — |
Lecture opérationnelle pour vos équipes :
- Si vous êtes en V16 ou antérieur : la migration est non négociable. Aucun contournement possible.
- Si vous êtes en V17 : vous serez couvert, mais avec un décalage sur la livraison des correctifs et des évolutions. Position acceptable à court terme, à interroger sur le moyen terme.
- Si vous êtes en V18 ou V19 : vous êtes au bon endroit.
Notre recommandation Auguria à toutes les équipes en V17 ou inférieur : planifier la migration directement en V19, plutôt que de viser V18 et devoir refaire le chantier dans douze mois. Une seule opération de migration, sur la version courante, c'est la trajectoire la plus économique et la plus sereine.
5. Les référentiels tiers : la fondation à fiabiliser sans attendre
C'est le chantier le plus sous-estimé par les équipes projet, et pourtant le plus structurant.
La facturation électronique repose intégralement sur l'identification fiable des partenaires. Une donnée tiers incorrecte ou manquante = une facture rejetée par le PPF ou par la PA destinataire. Sans recours immédiat.
5.1. Données obligatoires à fiabiliser sur la fiche partenaire
Sur chaque client professionnel français :
- SIREN à neuf chiffres valide et actif (vérifiable via l'API INSEE intégrée à Odoo).
- SIRET à quatorze chiffres de l'établissement destinataire si vous facturez un établissement précis.
- Adresse de facturation normalisée (norme AFNOR), distincte de l'adresse de livraison si nécessaire.
- Numéro de TVA intracommunautaire pour les clients européens hors France.
- Identifiant Peppol du client lorsque son éditeur en publie un.
5.2. Méthode Auguria pour l'audit des référentiels
Nous procédons en quatre étapes lors de nos missions :
- Extraction de la totalité des fiches partenaires actives sur les 24 derniers mois.
- Confrontation avec les bases INSEE / VIES pour identifier les écarts.
- Détection des doublons, des fiches obsolètes, des champs manquants.
- Plan de nettoyage : actions automatisables (scripts ORM Odoo) versus actions manuelles (à confier au service ADV).
Ce travail est dimensionnant. Pour un parc de 1 500 clients actifs, comptez en moyenne 8 à 15 jours de mission selon l'état initial.
6. Les statuts du cycle de vie de la facture
La DGFiP impose la gestion d'un cycle de vie standardisé. Voici les statuts que vous verrez apparaître dans Odoo après déploiement du module PA.
6.1. Statuts obligatoires (à minima)
- Déposée : la facture est correctement reçue par la PA destinataire.
- Rejetée : refus technique (format invalide, identifiant inconnu, etc.).
- Refusée : refus métier par le client destinataire (litige sur la prestation, désaccord commercial).
- Encaissée : paiement intervenu, déclaré pour conformité TVA.
6.2. Statuts facultatifs gérés par Odoo
Selon la communication d'Odoo, l'éditeur prendra en charge l'essentiel des statuts facultatifs en standard (mise à disposition, prise en charge, approbation, suspension de paiement, paiement partiel, etc.). C'est confortable, car cela rapproche le modèle Odoo de ce que les directions financières utilisent déjà comme suivi interne.
6.3. Impact sur les workflows internes
Conséquence très concrète : votre workflow de validation de facture doit absorber les statuts émis par les contreparties.
- Un statut « Refusée » côté client doit déclencher une procédure de traitement litige.
- Un statut « Suspension de paiement » doit alerter votre équipe recouvrement.
- Un statut « Encaissée » côté fournisseur peut accélérer votre lettrage automatique.
Sur cette dimension, nous recommandons un atelier dédié de 2 à 3 jours pour cartographier vos circuits actuels et les adapter aux nouveaux statuts entrants. C'est typiquement le genre de mission où une expérience d'intégrateur fait gagner des semaines de tâtonnement.
7. Lecture opérationnelle des 42 cas d'usage publiés par l'État
L'État a publié une liste de 42 cas d'usage que les PA et PDP peuvent traiter. Odoo a fait le choix de couvrir tout ce que sa solution standard gère nativement et de concentrer son effort certifié sur ce socle. La capacité de l'écosystème intégrateurs à étendre ce socle pour adresser les spécificités sectorielles est une question architecturale en cours de clarification avec l'éditeur (voir section 7.4).
7.1. Synthèse de la couverture Odoo
| Statut | Nombre | Part |
|---|---|---|
| Couverts en standard | 21 | 50 % |
| Couverts si la demande du marché est suffisante | 7 | 17 % |
| Non couverts par le périmètre standard | 14 | 33 % |
| Total | 42 | 100 % |
7.2. Les 21 cas couverts en standard
Multi-commande / multi-livraison, facture déjà payée à l'émission, frais payés par collaborateurs (avec ou sans facture entreprise), carte logée, paiements via intermédiaire de marché, notes de débit, auto-facturation, factures d'acompte et définitives, escompte avec TVA à l'encaissement ou sur les débits, auto-facturation particulier/professionnel, tickets de péage, notes de restaurant, assujetti unique, TVA déjà collectée, factures mixtes, paiements mensuels, encaissements partiels, sous-lignes et regroupements.
Si votre activité s'inscrit dans le négoce généraliste, le retail, les services standards ou l'industrie classique sans sous-traitance complexe, vous êtes couvert nativement.
7.3. Les 7 cas conditionnels (« Si demande »)
Ces cas seront pris en charge par Odoo si un volume suffisant de clients les remonte à l'éditeur. À défaut, leur trajectoire rejoint celle des cas non couverts (voir section 7.4).
- Tiers payeur connu à la facturation (sociétés de groupe, organismes centralisateurs)
- Prise en charge partielle par un tiers (subventions, assurances)
- Tiers gérant paiement + chaîne logistique (variante affacturage)
- Co-traitance B2B (groupements d'entreprises)
- Commande passée par un tiers pour l'acheteur (agences média, courtiers)
- Facture de débours (remboursements hors TVA)
- Bons et cartes cadeaux
Si vous tombez sur l'un de ces cas, la trajectoire dépendra de l'arbitrage d'Odoo : couverture native si le marché le pousse, sinon le sujet bascule sur la question d'extensibilité partenaire actuellement en discussion avec l'éditeur (voir section 7.4).
7.4. Les 14 cas hors périmètre standard
Affacturage avec tiers payeur déterminé, subrogation d'affactureur en cours de vie, tiers réceptionnaire (syndic, gestionnaire d'immeuble), intermédiaire transparent, sous-traitance avec paiement direct (typique du BTP), intermédiaire de paiement avec mandat de facturation, tiers facturant avec mandat, arrhes, clauses de réserve contractuelle, régime de la marge bénéficiaire, notes d'auteur, secret professionnel, sociétés en participation, factures multi-vendeurs, compensation / netting, sociétés de barter, détaxe.
Sur ces cas, une question technique précise conditionne la suite. Elle ne porte pas sur l'accès à la PA elle-même — il est clair que la PA Odoo sera réservée aux applications Odoo, ce qui est cohérent avec un éditeur ERP intégré — mais sur le contenu fonctionnel du module Odoo qui se connecte à la PA :
La PA Odoo va-t-elle implémenter, dans son module officiel, l'ensemble des champs structurés nécessaires aux extensions françaises EXT-FR-FE- (PAYEUR pour sous-traitance BTP, ADRESSÉ À pour syndic, BÉNÉFICIAIRE factor pour affacturage, etc.), ou uniquement ceux strictement nécessaires aux 21 cas couverts en standard ?*
Deux scénarios possibles à partir de cette réponse :
- Scénario 1 — La PA implémente tous les champs Factur-X / EXT-FR-FE-*. Les intégrateurs partenaires comme Auguria peuvent alors étendre les modules Odoo en amont (par héritage Odoo classique) pour utiliser ces champs déjà disponibles dans la PA et adresser les cas non couverts en standard. La conformité est alors atteignable par développement partenaire, sans dépendance à la roadmap Odoo.
- Scénario 2 — La PA n'implémente que les champs des 21 cas standards. Dans cette configuration, il n'est pas possible pour un module d'extension de générer dans le XML les champs manquants pour les 14 autres cas — la PA ne saurait pas les traiter. La trajectoire de conformité de ces clients dépend alors entièrement de la décision d'Odoo de faire évoluer sa PA pour intégrer ces champs supplémentaires.
Sur le plan technique, le standard Factur-X profil EXTENDED-CTC-FR défini par FNFE-MPE existe précisément pour porter l'ensemble des champs nécessaires. La norme AFNOR XP Z12-013 publiée en mai 2025 standardise par ailleurs les API d'échange entre systèmes d'entreprise et plateformes agréées.
Nous avons posé formellement cette question à Odoo. La réponse attendue lors de l'Odoo Insider du 4 juin conditionne directement la trajectoire de conformité que nous pourrons proposer aux clients de ces secteurs (BTP avec sous-traitance, agences de voyage, négoce d'occasion, ETI utilisant l'affacturage). Auguria publiera la position d'Odoo dans la foulée, avec les implications opérationnelles concrètes pour chaque profil concerné.
7.5. Recommandation par profil sectoriel
| Profil sectoriel | Niveau d'attention |
|---|---|
| Négoce généraliste, retail, services standards, industrie classique | Couverture standard Odoo PA suffisante. Aucune action complémentaire. |
| Industrie avec sous-traitance, distribution avec affacturage, immobilier | Audit ciblé recommandé. La trajectoire de conformité dépendra de la position d'Odoo sur l'extensibilité partenaire (clarification en cours). |
| BTP, agences de voyage, négoce de biens d'occasion, professions réglementées | Audit cas d'usage indispensable dès maintenant. La cartographie de vos cas vous permettra d'arbitrer rapidement dès qu'Odoo aura précisé sa doctrine sur l'extensibilité. |
Pour les profils des deux derniers groupes, la cartographie de vos cas d'usage est un travail à engager immédiatement, indépendamment de l'arbitrage technique en cours. Plus tôt vous avez la liste précise et chiffrée de vos cas à risque, plus rapidement vous serez en mesure d'arbitrer entre les options qui se présenteront.
8. La méthode Auguria pour déployer la PA chez nos clients
Voici, sous forme méthodologique, comment nous séquençons un projet de mise en conformité PA chez un client PME ou ETI.
Phase 1 — Cadrage stratégique
- Cartographie de vos flux face aux 42 cas d'usage.
- Évaluation de votre version Odoo actuelle et trajectoire de migration recommandée.
- Identification des développements spécifiques nécessaires, chiffrés.
- Plan global avec macro-planning et budget.
Phase 2 — Audit et fiabilisation des référentiels
- Extraction et analyse des fiches partenaires.
- Confrontation INSEE / VIES.
- Plan de nettoyage et déduplication.
- Mise en place des contrôles de qualité dans Odoo.
Phase 3 — Migration Odoo si nécessaire (variable selon version source)
- Migration en V19 directement, plutôt que via V18.
- Reprise des données, recette fonctionnelle, formation des équipes.
- Bascule en production.
Phase 4 — Déploiement du module PA
- Activation du module officiel Odoo PA dès sa publication.
- Inscription dans les annuaires DGFiP.
- Paramétrage des workflows de validation pour intégrer les statuts entrants.
- Tests d'émission et de réception en environnement pilote.
Phase 5 — Conduite du changement et formation
- Formation des équipes comptabilité, ADV, achats.
- Mise à jour des procédures internes.
- Suivi post-démarrage sur 30 jours.
Total moyen pour un projet PME standard : 20 à 40 jours d'intervention, étalés sur 3 à 6 mois selon votre version de départ et la complexité de votre activité.
9. Le piège du dernier moment
Septembre 2026 est l'échéance d'obligation de réception pour toutes les entreprises assujetties à la TVA, et d'obligation d'émission pour les grandes entreprises et ETI. Nous sommes en mai 2026. Il vous reste quatre mois.
Sur un projet de 20 à 40 jours, étalé sur 3 à 6 mois, la fenêtre de démarrage utile se referme à la fin du mois de juin. Au-delà, l'opération sera tendue, voire impossible à réaliser dans des conditions normales.
Notre conseil : ne procrastinez pas. Un cadrage de 2 jours engagé dès maintenant vous coûte peu, mais vous donne une visibilité claire sur votre situation, votre charge de travail et votre budget. À partir de là, vous décidez en connaissance de cause.
10. Comment Auguria vous accompagne
Auguria, membre du groupe ANOR, accompagne les PME et ETI françaises sur l'ensemble de leur cycle de vie Odoo : cadrage stratégique, intégration, migration, formation, support. Pour le sujet précis de la facturation électronique, nous proposons trois offres dédiées.
Audit Conformité PA (forfait)
Un cadrage rapide de 2 à 5 jours pour vous donner une visibilité complète sur :
- Votre situation actuelle face aux 42 cas d'usage
- L'état de vos référentiels tiers
- La trajectoire de migration recommandée
- Le budget global et le planning de mise en conformité
Projet de mise en conformité PA (sur devis)
Le pack complet pour passer de votre situation actuelle à la conformité PA opérationnelle : migration si nécessaire, fiabilisation des référentiels, déploiement du module officiel, paramétrage des workflows, formation des équipes.
Accompagnement post-bascule
Une fois le module PA déployé, nous restons à vos côtés pour les ajustements, les évolutions réglementaires, l'optimisation des workflows et la formation des nouveaux arrivants dans vos équipes.
11. En conclusion
L'agrément définitif d'Odoo en avril a levé la question stratégique. Le courriel d'Odoo France du 18 mai apporte aujourd'hui la matière opérationnelle qui manquait pour passer à l'exécution sur la grande majorité des activités.
Saluons à nouveau la qualité du travail accompli par les équipes d'Odoo France : obtenir une certification PA, dans les délais, avec un périmètre fonctionnel large couvrant Odoo Online, Odoo.sh, hébergement privé et Community, c'est une performance industrielle remarquable. C'est aussi une excellente nouvelle pour la souveraineté technologique des PME et ETI françaises : le logiciel libre devient un acteur de la conformité réglementaire, et c'est une démonstration que l'écosystème open source est mature pour porter les enjeux critiques de notre tissu économique.
Pour les activités hors socle standard (BTP, voyage, occasion, affacturage, professions réglementées), la question de l'extensibilité du module Odoo PA par les partenaires intégrateurs reste à clarifier avec l'éditeur. Nous avons posé formellement cette question à Odoo France, et nous publierons sa réponse au lendemain de l'Odoo Insider du 4 juin. D'ici là, la cartographie de vos cas d'usage est un travail que vous pouvez engager dès maintenant : il vous donnera la matière pour décider rapidement, quelle que soit la trajectoire technique qui se dessinera.
Pour vous, dirigeant, DAF, responsable ERP ou chef de projet, la fenêtre d'action est claire : entre maintenant et septembre. Et plus précisément, entre maintenant et fin juin pour démarrer un projet dans des conditions sereines.
Si vous voulez engager le dialogue sur votre situation précise, prenons rendez-vous. Le premier échange est gratuit, sans engagement, et orienté décision.