Brancher un ERP à une Plateforme Agréée ressemble moins à une intégration classique qu'à un protocole diplomatique : chaque PA parle son propre dialecte, les règles de routage sont imposées par un annuaire central d'État, et une erreur de statut non corrigée coûte de l'argent réel. Ce n'est pas un projet de quelques jours pour une équipe technique habituée aux webhooks Stripe. Cet article détaille les cinq décisions d'architecture que vous devez prendre avant d'écrire la première ligne de code, avec les contraintes réglementaires et les pièges concrets à chaque étape.
Ce que le cahier des charges DGFiP impose côté API#
Le cahier des charges technique des Plateformes Agréées publié par la DGFiP (version 2.3) établit les fondations non négociables de toute intégration. OAuth 2.0 est le seul schéma d'authentification accepté pour les flux entrants et sortants - aucune PA ne peut vous proposer une clé API statique en guise d'alternative conforme.
Le payload de chaque appel doit respecter le modèle sémantique EN 16931, formalisé par la norme AFNOR NF EN 16931-1:2017. Ce modèle est commun aux trois formats acceptés - Factur-X, UBL et CII - ce qui signifie que la structure de données sous-jacente est identique quel que soit le format de sérialisation choisi. Pour en savoir plus sur les différences entre ces formats, consultez notre comparatif Factur-X, UBL et CII.
Les quelque 113 PA immatriculées ou en cours d'immatriculation au printemps 2026 n'ont aucune interface commune entre elles. Le cahier des charges définit ce que les PA doivent faire, pas comment elles doivent le faire côté intégrateur. Chaque connecteur devra donc s'adapter à la documentation propriétaire de la PA retenue.
Changer de PA après mise en production implique de réécrire le connecteur dans sa quasi-totalité. Anticipez ce risque dès la phase de choix : exigez un contrat précisant les conditions de portabilité des données et la durée minimale d'engagement. Consultez notre comparatif des Plateformes Agréées 2026 pour évaluer la maturité technique de chaque PA.
Décision 1 et 2 - Authentification OAuth 2.0 et routage SIRET#
OAuth 2.0 avec le flux client_credentials est le pattern de référence pour des échanges machine-to-machine sans intervention humaine. L'ERP obtient un access token auprès du serveur d'autorisation de la PA, le rafraîchit avant expiration, et ne stocke jamais de credentials en clair dans la base de données ou les logs applicatifs.
Bonnes pratiques OAuth 2.0 pour un connecteur ERP#
Stocker les tokens dans un coffre secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) est la pratique minimale. Implémenter un retry avec backoff exponentiel sur les réponses 401 évite les tempêtes de requêtes en cas d'expiration de token pendant une fenêtre de charge. Prévoir la rotation des client_secret sans downtime est un point souvent négligé au moment de l'intégration initiale : exigez de la PA une période de chevauchement entre l'ancien et le nouveau secret, sinon chaque rotation nécessite une fenêtre de maintenance.
Avant tout appel d'émission, le connecteur doit interroger l'annuaire central maintenu par la DGFiP pour résoudre le SIRET de l'acheteur vers sa PA destinataire. Un routage incorrect - envoyer une facture à la mauvaise PA ou directement sans passer par l'annuaire - entraîne un rejet immédiat. Cette étape de résolution n'est pas optionnelle et doit être implémentée comme une dépendance bloquante avant chaque soumission. La liste officielle des PA immatriculées vous permet de vérifier que la PA destinataire résout bien depuis l'annuaire central.
Décision 3 - Gérer les acquittements et le cycle de vie facture#
La FNFE-MPE définit les statuts obligatoires du cycle de vie d'une facture électronique : déposée, rejetée, approuvée, contestée, payée. Chaque changement de statut transite par la PA émettrice, remonte à l'émetteur via l'API, et doit être consommé par le connecteur. Le cycle de vie complet est documenté sur le site de la FNFE-MPE.
Un statut "rejeté" non consommé ne déclenche pas de correction automatique côté PA. L'émetteur doit réémettre une facture corrigée dans un délai raisonnable - sans quoi la facture initiale reste non conforme au sens réglementaire. Ce point a des conséquences financières directes, détaillées dans notre guide sur les sanctions liées à la facturation électronique 2026.
Modéliser une machine à états dans le connecteur est indispensable : chaque transition doit être persistée en base de données avant d'acquitter la notification côté PA. Cette traçabilité doit couvrir dix ans, conformément à l'article L123-22 du Code de commerce. Ne jamais acquitter un statut sans l'avoir écrit en base : un acquittement prématuré suivi d'un crash applicatif fait perdre définitivement l'information de statut.
Article 1737 du CGI : 15 EUR par facture dont le statut "rejeté" n'est pas corrigé, plafond 15 000 EUR/an. Pour une entreprise émettant plusieurs centaines de factures par mois, le plafond annuel peut être atteint rapidement si le connecteur ne traite pas les acquittements en temps réel. Source : Legifrance.
Décision 4 et 5 - Idempotence et webhooks versus polling#
Chaque appel d'émission doit porter un identifiant unique - UUID v4 ou équivalent - transmis dans un header dédié que la PA utilise pour détecter les doublons. En cas de retry après timeout réseau, la PA renvoie le résultat du premier appel sans créer de nouvelle facture. Sans idempotence, un simple timeout côté ERP peut générer deux factures identiques avec des numéros différents, ce qui crée un problème comptable et réglementaire difficile à corriger a posteriori.
Les webhooks (mode push) réduisent la latence de réception des statuts et la charge sur l'infrastructure de la PA. Le polling (mode pull) reste le fallback lorsque la PA ne supporte pas les callbacks, ou que votre infrastructure n'expose pas d'endpoint HTTPS public avec un certificat valide. Ces deux contraintes sont fréquentes dans les environnements ERP on-premise ou derrière un pare-feu d'entreprise strict.
La meilleure architecture combine les deux approches : webhook pour les statuts temps réel, polling de réconciliation toutes les heures pour détecter les notifications manquées dues à un timeout ou un redémarrage serveur. Cette stratégie défensive est recommandée dès lors que la PA ne garantit pas de re-livraison automatique des webhooks en cas d'échec de réception.
Choisir sa PA et son logiciel : ce que l'API change dans l'évaluation#
La qualité de la documentation API et la disponibilité d'un environnement sandbox sont désormais des critères de sélection d'une PA au même titre que le prix ou la couverture réglementaire. Une PA qui ne propose pas de sandbox force les tests en production, ce qui est inacceptable pour un projet d'intégration ERP. Consultez la liste officielle des PA sur impots.gouv.fr pour vérifier le statut d'immatriculation avant tout engagement contractuel - la différence entre "immatriculée" et "en cours d'immatriculation" n'est pas anodine.
Un logiciel de facturation SaaS intégrant nativement un connecteur PA certifié élimine la charge de développement interne et transfère la responsabilité des évolutions API au fournisseur logiciel. C'est particulièrement pertinent pour les PME sans équipe technique dédiée. Vérifiez cependant que le contrat précise explicitement la prise en charge des évolutions API PA futures sans surcoût - les mises à jour de cahier des charges DGFiP peuvent impacter les connecteurs existants. Notre comparatif des logiciels de facturation conformes 2026 évalue ce critère pour les principales solutions du marché.
Les PME et TPE dont l'obligation d'émission n'entre en vigueur qu'au 1er septembre 2027 disposent de temps pour choisir. En revanche, l'obligation de réception s'applique à toutes les entreprises dès le 1er septembre 2026 : même sans émettre, votre système doit être capable de recevoir et traiter des factures entrantes via PA. Vérifiez l'état de préparation de votre stack avec notre checklist de préparation à septembre 2026.
Sources officielles
- [1]DGFiP - Cahier des charges technique Plateformes Agréées v2.3(consulte le )
- [2]AFNOR - NF EN 16931-1:2017 - Modèle sémantique commun Factur-X, UBL, CII(consulte le )
- [3]Legifrance - Article 1737 CGI - Sanctions factures non conformes(consulte le )
- [4]FNFE-MPE - Spécifications fonctionnelles statuts cycle de vie facture électronique(consulte le )
Notre methodologie editoriale consiste a citer systematiquement nos sources et a dater chaque verification. Consultez notre methodologie de citation complete pour comprendre comment nous evaluons la fiabilite des informations.