API de facturation électronique en France : exigences d’intégration pour les développeurs
La facturation électronique en France est autant un projet d’intégration qu’un projet financier. Les ERP, applications de facturation, plateformes comptables et autres logiciels métiers doivent disposer d’un moyen fiable pour échanger les données de facturation et de déclaration avec l’écosystème français de la facturation électronique.
Table of Contents
Introduction
La facturation électronique en France est autant un projet d’intégration qu’un projet financier. Les ERP, applications de facturation, plateformes comptables et autres logiciels métiers doivent disposer d’un moyen fiable pour échanger les données de facturation et de déclaration avec l’écosystème français de la facturation électronique.
Pour les développeurs, la question essentielle n’est pas seulement de savoir quelle API appeler. Il faut comprendre comment le système source, les données de facture, les règles de validation, l’adressage du destinataire, la Plateforme Agréée (PA), la gestion des statuts et les flux déclaratifs fonctionnent ensemble.
Le cadre technique français fournit des standards communs, mais une implémentation réussie nécessite également des tests spécifiques au fournisseur et une conception rigoureuse des données.
Qu’est-ce que la couche API de la facturation électronique en France ?
Le cadre technique français définit un modèle commun d’interfaçage API à travers AFNOR XP Z12-013. D’autres normes associées couvrent les formats de factures et de messages de statut ainsi que les aspects liés à la sécurité et à l’identification. La norme XP Z12-012 concerne les formats de factures et de messages de statut, tandis que XP Z12-014 couvre les aspects de sécurité et d’identification.
Ces normes fournissent une base technique commune pour connecter les systèmes d’information des entreprises à l’écosystème français de la facturation électronique. Elles ne signifient pas que toutes les PA exposent exactement la même API publique.
Chaque PA peut avoir ses propres endpoints, méthodes d’authentification, environnements sandbox, identifiants, mécanismes de gestion des messages, catalogue d’erreurs, limites de débit, processus d’intégration et politique de versionnement.
Avant de commencer le développement, obtenez la documentation technique à jour de la PA sélectionnée. Considérez les standards français communs comme la base architecturale et la documentation de la PA comme le contrat d’implémentation.
API et PA : deux notions différentes
Une API est un mécanisme d’intégration. Une PA est l’opérateur réglementé utilisé pour les flux français concernés de facturation électronique et de déclaration.
Une entreprise peut utiliser plusieurs modèles d’architecture. Un ERP peut se connecter directement à une PA. Une couche d’intégration ou de middleware peut être placée entre l’ERP et la PA. Une solution métier compatible peut également se connecter à une PA pour le compte de l’entreprise.
L’important est de comprendre que la connexion API ne remplace pas l’architecture PA.
Pour la France, les développeurs doivent déterminer quel composant prend en charge la validation, le routage, l’échange des factures, l’e-reporting des transactions et l’e-reporting des paiements. Ces responsabilités doivent être documentées avant le début du développement.
Commencez par le modèle de données
Ne commencez pas un projet de facturation électronique par les endpoints API. Commencez par les données métier.
Mappez les champs disponibles dans l’ERP, le système de facturation, l’application comptable ou tout autre système source avec les exigences françaises en matière de factures et de déclarations.
Les données de facture comprennent généralement :
- Identité du vendeur et informations TVA
- Identité de l’acheteur et informations SIREN applicables
- Numéro et date d’émission de la facture
- Lignes de facture, quantités et montants
- Taux de TVA et traitement fiscal
- Totaux hors taxes et toutes taxes comprises
- Conditions de paiement et informations de paiement pertinentes
- Références et informations de livraison lorsque nécessaires
- Catégorie de transaction, par exemple biens, services ou opération mixte
Le même exercice doit être réalisé pour les données de transaction et de paiement lorsque l’entreprise est soumise à l’e-reporting.
Le routage fait partie de l’intégration
Une facture techniquement valide doit également parvenir au bon destinataire.
La facturation électronique française utilise des informations d’annuaire et d’adressage faisant intervenir des identifiants tels que le SIREN, le SIRET et la ligne d’adressage ou les informations de routage applicables.
Les données de référence des destinataires deviennent donc une partie intégrante de l’intégration technique. Le système doit pouvoir identifier l’entité destinataire et utiliser les informations de routage à jour nécessaires à la livraison.
Une erreur de routage doit être traitée comme une exception d’intégration, et pas simplement comme un champ financier manquant.
La validation comporte plusieurs niveaux
La validation doit intervenir avant et pendant l’échange.
Une intégration pratique peut vérifier :
- Les champs obligatoires
- Les types et formats de données
- Les dates de facture
- Les calculs des lignes et les totaux
- Les taux et traitements de TVA
- Les identifiants du vendeur et de l’acheteur
- La syntaxe de la facture
- Les règles métier françaises
- L’adressage du destinataire
Le cadre français contient des concepts techniques et de cycle de vie communs. La PA sélectionnée peut également appliquer des contrôles opérationnels supplémentaires.
Une validation en amont permet à l’entreprise de corriger les données sources avant qu’une facture n’atteigne l’étape d’échange.
Échanges entrants et sortants
Les développeurs doivent concevoir la réception en même temps que l’émission.
Le traitement sortant commence généralement par une facture dans le système source, transforme les données, les valide puis les transmet via l’architecture PA applicable.
Le traitement entrant peut impliquer un échange PA à PA et une livraison vers la solution destinataire. L’application de réception doit alors conserver la facture structurée, les informations de validation et les identifiants pertinents avant de transmettre le document à l’ERP ou au workflow des comptes fournisseurs.
Cela signifie qu’un endpoint API entrant n’est qu’un composant technique possible. Le modèle d’interface actuel de la PA sélectionnée détermine si la solution de réception utilise un mécanisme push, une récupération, des notifications ou une autre méthode.
Statuts et suivi du cycle de vie
Le cadre français définit des concepts communs de cycle de vie et des statuts minimaux, tandis que la PA détermine la manière dont ces statuts sont exposés via son API et son portail.
L’intégration doit suivre les statuts applicables de dépôt, rejet, livraison, réception, acceptation, paiement et les autres états du cycle de vie pris en charge par la PA et le cadre français.
Ne considérez pas tous les statuts applicatifs comme des statuts réglementaires. Un fournisseur peut également exposer des états de workflow utiles à l’entreprise mais qui ne font pas partie du modèle commun du cycle de vie français.
Chaque statut doit rester associé au document ERP d’origine afin que les équipes financières puissent réconcilier la facture sans devoir rechercher dans les journaux techniques.
E-reporting et données de paiement
L’intégration peut également devoir préparer les données d’e-reporting.
Les transactions B2C, certaines transactions internationales et les informations de paiement peuvent provenir de systèmes autres que l’ERP. Un distributeur, par exemple, peut gérer les transactions consommateurs dans un système de caisse ou une plateforme e-commerce, tandis que ses factures B2B restent dans l’ERP.
Les données de paiement peuvent également suivre un flux technique différent de celui de la transmission des factures. Selon la PA, les informations de paiement peuvent utiliser une opération de déclaration ou un flux de fichier distinct.
Les développeurs doivent donc confirmer l’interface et le modèle de réconciliation propres à la PA sélectionnée plutôt que de supposer que l’e-reporting des paiements utilise le même endpoint que la transmission des factures.
Recommandations d’ingénierie pour la fiabilité
Les contrôles d’ingénierie ne constituent pas une terminologie juridique française, mais ils sont importants pour une intégration en production.
Utilisez un statut de message persistant et un identifiant de corrélation reliant le document ERP à la requête d’intégration et à la réponse de la PA.
Lorsque cela est pris en charge, utilisez des clés d’idempotence ou une clé métier de déduplication. Conservez la relation entre la facture ERP, le message d’intégration, l’identifiant de soumission à la PA et les statuts du cycle de vie obtenus.
Ne relancez pas aveuglément chaque requête ayant échoué. Un timeout peut correspondre à un problème technique temporaire, tandis qu’un identifiant acheteur manquant constitue un problème de données permanent nécessitant une correction.
La supervision doit couvrir les soumissions échouées, les factures rejetées, les statuts retardés, les échecs d’authentification, les erreurs de routage et les échecs de transmission d’e-reporting.
Sécurité et traçabilité
Les données de facture sont sensibles sur le plan commercial. L’architecture API doit inclure une authentification sécurisée, une gestion des identifiants, le chiffrement, des contrôles d’accès, des journaux d’audit et une gestion maîtrisée des secrets.
L’immatriculation PA comprend des exigences en matière de sécurité et d’infrastructure. L’intégrateur doit évaluer séparément le modèle d’authentification, d’hébergement, de contrôle d’accès, de journalisation et de gestion des incidents de la PA sélectionnée.
Les journaux applicatifs doivent contenir suffisamment d’informations pour tracer une transaction sans exposer inutilement l’intégralité des payloads de facture ou des données financières sensibles.
Standard commun, implémentation spécifique à chaque fournisseur
AFNOR XP Z12-013 réduit la fragmentation architecturale, mais ne crée pas une API identique pour toutes les PA.
Avant le développement, confirmez les éléments suivants auprès de la PA sélectionnée :
- Endpoints API et environnements
- Méthode d’authentification
- Exemples de messages et schémas
- Identifiants sandbox
- Modèle de statuts
- Codes d’erreur
- Limites de débit
- Recommandations de retry
- Modèle webhook ou polling
- Politique de versionnement et de notification des changements
Cette étape évite une erreur fréquente : développer à partir d’un ancien exemple de payload et supposer qu’il représente toutes les PA.
Tester l’intégration
Les tests de bout en bout doivent couvrir davantage qu’une transmission de facture réussie.
Testez le mapping des données sources, les formats structurés, les échecs de validation, le routage du destinataire, la réception des factures, les mises à jour de statut, les factures corrigées, les avoirs, la prévention des doublons, l’e-reporting et les scénarios d’e-reporting des paiements lorsque cela est applicable.
Pour chaque document sortant, conservez au minimum l’identifiant de facture ERP, la version du système source, l’identifiant du message d’intégration, le hash du payload lorsque pertinent, l’identifiant de soumission à la PA, le résultat du routage, le résultat de la validation et les statuts du cycle de vie.
Pour les factures entrantes, conservez le numéro de facture fournisseur, l’identifiant du message PA, le payload structuré reçu, les résultats de validation et l’enregistrement correspondant dans le système de comptes fournisseurs de l’ERP.
Cela permet aux équipes techniques et financières de disposer d’une piste d’audit commune sur l’ensemble du cycle de vie.
Comment Complyance peut s’intégrer
Complyance peut fournir une couche d’intégration et de technologie entre les ERP, systèmes comptables ou systèmes de facturation existants et l’infrastructure française de facturation électronique.
La configuration PA exacte, les formats pris en charge, les fonctions API et les responsabilités déclaratives doivent être confirmés pour le déploiement prévu.
L’objectif est de permettre aux systèmes métiers centraux de rester concentrés sur les données métier, tandis que la couche d’intégration prend en charge les transformations, validations et logiques d’échange spécifiques au pays nécessaires au déploiement.
Checklist développeur
Avant la mise en production, confirmez :
- Les champs sources sont mappés et leur responsabilité est définie
- Les identifiants acheteur et vendeur sont maintenus
- L’adressage des destinataires est testé
- Les formats de facture sont correctement validés
- L’authentification PA est sécurisée
- Les échanges entrants et sortants sont testés
- Les statuts du cycle de vie sont retournés vers le bon enregistrement ERP
- Les rejets et corrections peuvent être traités
- Les données d’e-reporting sont mappées lorsque nécessaire
- L’e-reporting des paiements est pris en charge lorsque applicable
- Les contrôles de corrélation et de déduplication sont implémentés
- La supervision et les pistes d’audit sont disponibles
Conclusion
L’intégration d’une API de facturation électronique en France ne consiste pas simplement à envoyer du JSON ou du XML de facture vers un endpoint.
L’API s’inscrit dans une architecture plus large couvrant les données métier, les règles de validation françaises, l’adressage des destinataires, les échanges via la PA, la gestion du cycle de vie et les flux déclaratifs applicables.
Les développeurs qui conçoivent l’intégration autour de l’ensemble de ce cycle de vie peuvent construire une architecture plus facile à superviser, à diagnostiquer et à adapter lorsque le cadre technique français évolue.
Source officielle
Spécifications externes et normes techniques de la DGFiP
About the Author
Swathy
Content Marketer
I’m a Content Marketer at Complyance, focused on e-invoicing. Over the years, I’ve created a wide range of content, including blog posts, whitepapers, and product guides, which have supported Complyance’s growth across markets such as the UAE and EU regions. My goal is to deliver content that is comprehensive, clear, accurate, and easy to understand, no matter how complex the topic.
