Une API de facturation électronique permet à un logiciel d’émettre et de recevoir des factures au format structuré, sans intervention manuelle. Elle ne dispense pas de passer par une plateforme habilitée à transmettre.
Ce que recouvre le terme
L’expression désigne trois objets différents, et la confusion entre eux explique la plupart des malentendus lors du choix d’une solution.
L’API d’une plateforme de transmission
C’est l’interface exposée par un opérateur habilité à faire transiter les factures. Elle permet de lui déposer une facture, de suivre son acheminement et de récupérer celles qui vous sont adressées. C’est l’API dont on parle le plus souvent.
L’API d’un logiciel de gestion
C’est l’interface d’un outil de facturation, qui permet à d’autres applications de créer des factures, de lire des données ou de déclencher des traitements. Elle sert l’intégration au système d’information, pas la transmission réglementaire.
Les bibliothèques de format
Ce sont des composants techniques qui produisent ou lisent un fichier structuré, sans rien transmettre. Elles répondent à la question du format, pas à celle de l’acheminement.
| Type | Ce qu’elle fait | Ce qu’elle ne fait pas |
|---|---|---|
| API de plateforme | Dépose, achemine, remonte les statuts | Ne crée pas la facture |
| API de logiciel de gestion | Crée et lit les documents de gestion | Ne transmet pas au destinataire |
| Bibliothèque de format | Produit ou lit le fichier structuré | Ni transmission ni suivi |
Une solution complète combine les trois fonctions, qu’elles soient assurées par un acteur unique ou par plusieurs briques assemblées.
Le cadre : qui transmet quoi
La réforme française repose sur un principe simple : une facture entre entreprises ne circule plus directement de l’émetteur au destinataire, elle transite par des plateformes.
La conséquence pour un développeur est déterminante. Générer un fichier au bon format ne suffit pas à respecter l’obligation : encore faut-il qu’il soit déposé auprès d’un opérateur habilité, qui l’acheminera vers la plateforme du destinataire.
Cette architecture explique pourquoi la plupart des éditeurs de logiciels de gestion ne cherchent pas à devenir eux-mêmes opérateurs. L’habilitation suppose des exigences de sécurité, d’archivage et de disponibilité sans rapport avec le métier d’un logiciel de facturation. La voie majoritaire consiste donc à s’interfacer avec un opérateur, par son API.
Ce que l’API ne dispense pas de faire
Trois obligations restent à la charge de l’entreprise, quelle que soit la qualité de l’intégration technique.
La complétude des données. Une facture au format structuré doit porter des mentions que les factures papier toléraient absentes ou implicites, en particulier l’identifiant du destinataire et la nature de l’opération.
L’archivage. La conservation du document et de sa piste d’audit reste une obligation propre, que la transmission n’assure pas nécessairement.
Le traitement des rejets. Une facture refusée par la plateforme ou par le destinataire doit être corrigée et renvoyée. Une intégration qui ne prévoit pas ce circuit produit des factures perdues sans que personne ne s’en aperçoive.
Les formats
Le socle sémantique
La norme européenne EN 16931 définit le contenu d’une facture électronique : quelles données, sous quels noms, avec quelles règles de cohérence. Elle décrit le sens, indépendamment de la façon dont les données sont écrites dans un fichier.
C’est le point de départ de toute intégration sérieuse. Un logiciel qui sait produire une représentation conforme à cette norme peut ensuite alimenter n’importe quelle syntaxe.
Les trois syntaxes
Trois formats matérialisent cette norme, et le choix entre eux dépend surtout du destinataire.
| Format | Nature | Particularité |
|---|---|---|
| UBL | XML | Très répandu à l’international |
| CII | XML | Issu des travaux des Nations unies sur l’échange commercial |
| Factur-X | PDF avec XML intégré | Lisible par un humain et par une machine |
Le format Factur-X occupe une place particulière parce qu’il est hybride : le fichier reste un PDF ouvrable par n’importe qui, et il embarque les données structurées dans ses métadonnées. Cette double nature en fait le format le plus confortable pour les échanges avec de petites structures, qui continuent de vouloir lire une facture à l’écran.
Les opérations d’une API de facturation électronique
Une intégration complète mobilise cinq familles d’opérations. Les négliger conduit à une mise en production qui fonctionne en démonstration et échoue en usage réel.
| Opération | Rôle | Fréquence d’appel |
|---|---|---|
| Validation | Vérifier la conformité avant envoi | À chaque facture |
| Émission | Déposer la facture chez l’opérateur | À chaque facture |
| Suivi des statuts | Connaître l’état d’acheminement | Périodique ou par notification |
| Réception | Récupérer les factures entrantes | Périodique |
| Retour de statut | Signaler l’acceptation ou le refus reçu | À chaque décision |
La validation avant envoi
C’est l’opération la plus rentable de toute l’intégration. Une facture validée en amont évite un rejet, sa détection tardive et sa correction manuelle.
Le rapport de validation doit être exploité et affiché à l’utilisateur en termes compréhensibles. Un message technique brut renvoyé tel quel à un comptable ne produit aucune correction.
Le suivi des statuts du cycle de vie
Une facture électronique n’est pas seulement envoyée : elle traverse une série d’états, du dépôt à l’encaissement. Ces statuts constituent une information de gestion précieuse, bien au-delà de la conformité.
Savoir qu’une facture a été reçue et acceptée par le client supprime une catégorie entière de litiges, celle du « nous ne l’avons jamais reçue ». Et la remontée du statut d’encaissement rapproche la comptabilité du réel sans attendre le relevé bancaire.
La réception, souvent traitée en second
Nombre d’intégrations se concentrent sur l’émission et traitent la réception plus tard. C’est un mauvais ordre de priorité, puisque l’obligation de recevoir concerne toutes les entreprises et arrive en premier dans le calendrier.
La réception suppose un mécanisme de récupération périodique, une conversion vers le modèle de données interne, et un circuit pour signaler l’acceptation ou le refus. Ce dernier point est une obligation, pas une option.
Le calendrier
Deux échéances structurent le projet, et elles ne portent pas sur la même chose.
Au 1er septembre 2026, toutes les entreprises assujetties doivent être en capacité de recevoir des factures électroniques. Cette obligation ne dépend pas de la taille.
L’obligation d’émettre suit un calendrier échelonné : au 1er septembre 2026 pour les grandes entreprises et les entreprises de taille intermédiaire, et au 1er septembre 2027 pour les petites et moyennes entreprises, les très petites entreprises et les micro-entreprises.
La conséquence pratique pour une PME est nette : la réception doit être opérationnelle un an avant l’émission. Un projet qui traite les deux ensemble prend le risque de manquer la première échéance en travaillant sur la seconde.
Les critères de choix d’une API
| Critère | Question à poser | Conséquence si négligé |
|---|---|---|
| Habilitation de l’opérateur | Est-il autorisé à transmettre ? | Factures non conformes |
| Formats supportés | UBL, CII et Factur-X en émission et réception ? | Échanges impossibles avec certains partenaires |
| Validation en amont | Un rapport d’erreurs exploitable ? | Rejets découverts trop tard |
| Gestion des statuts | Notifications ou interrogation périodique ? | Aucun suivi du cycle de vie |
| Environnement de test | Un bac à sable réaliste ? | Découverte des cas limites en production |
| Réversibilité | Peut-on récupérer l’historique ? | Dépendance à l’opérateur |
Le critère de réversibilité mérite d’être posé avant la signature, alors qu’il ne se pose concrètement qu’au moment de partir. Les factures transmises et leurs statuts constituent une piste d’audit dont l’entreprise reste responsable.
Authentification et sécurité
Une API de facturation électronique manipule des données commerciales sensibles et engage l’entreprise sur le plan réglementaire. Son accès est donc encadré plus strictement que celui d’une API de gestion ordinaire.
Le mécanisme de jetons
L’authentification repose généralement sur un échange de jetons plutôt que sur des identifiants transmis à chaque appel. Le principe est simple : des informations d’accès permettent d’obtenir un jeton temporaire, seul utilisé ensuite, et renouvelé à son expiration.
Deux conséquences pratiques en découlent pour l’intégration. Le renouvellement doit être automatique, faute de quoi les envois cessent silencieusement à l’expiration. Et le jeton ne doit jamais être stocké en clair ni journalisé, puisqu’il vaut identité pendant sa durée de vie.
Les environnements séparés
Un environnement de test distinct est indispensable, et ses identifiants doivent être différents de ceux de production. L’erreur qui consiste à tester avec les accès de production produit des factures réellement transmises à de vrais destinataires, sans possibilité de rappel.
Trois architectures d’intégration
Le raccordement d’un logiciel de gestion à une plateforme suit l’un de trois patrons, dont le choix engage la maintenance sur plusieurs années.
L’intégration directe
Le logiciel appelle l’API de la plateforme, sans intermédiaire. C’est la solution la plus simple et la plus rapide, et elle convient lorsqu’un seul opérateur est visé.
Son inconvénient est le couplage : changer d’opérateur suppose de réécrire la couche d’appel, et chaque évolution de son API impose une mise à jour.
L’intégration par abstraction
Le logiciel produit une représentation normalisée de la facture, puis un composant dédié se charge de la traduire pour l’opérateur retenu. C’est l’architecture qui isole le métier de la plomberie.
Son intérêt apparaît au premier changement : seule la couche de traduction est reprise, le reste du logiciel ignorant totalement quel opérateur est utilisé. C’est le patron que retiennent les éditeurs qui envisagent plusieurs opérateurs ou plusieurs pays.
La délégation complète
Le logiciel transmet ses données dans un format sémantique et laisse l’opérateur produire le fichier final. Il ne maintient alors aucun sérialiseur de format.
C’est le choix le plus économe en maintenance, puisque les évolutions de syntaxe sont absorbées par la plateforme. Il suppose en contrepartie une confiance dans la pérennité de l’opérateur.
| Architecture | Effort initial | Coût de changement | Maintenance des formats |
|---|---|---|---|
| Intégration directe | Faible | Élevé | À votre charge partiellement |
| Couche d’abstraction | Moyen | Faible | Centralisée dans un composant |
| Délégation complète | Faible | Moyen | Assurée par l’opérateur |
Tester son intégration
Un jeu de tests limité aux factures nominales donne une fausse assurance. Six cas doivent être couverts avant la mise en production.
| Cas de test | Ce qu’il vérifie |
|---|---|
| Facture simple à un taux de taxe | Le chemin nominal |
| Facture à plusieurs taux | La ventilation des taxes |
| Facture avec remise globale | La cohérence des totaux |
| Avoir | Le traitement des montants négatifs |
| Facture rejetée | Le circuit de correction et de renvoi |
| Destinataire inconnu | La gestion de l’erreur d’identification |
Les deux dernières lignes sont celles que l’on saute et celles qui provoquent les incidents de production. Un rejet non traité n’est pas visible : la facture disparaît simplement du circuit, et l’entreprise découvre le problème lorsque le client s’étonne de ne rien avoir reçu.
Le contrôle du référentiel avant bascule
Avant toute mise en production, un contrôle du fichier clients évite l’essentiel des rejets initiaux. Les points à vérifier sont l’identifiant de chaque entreprise cliente, l’exactitude des adresses de facturation, et la présence des mentions propres à certaines opérations.
Ce contrôle prend quelques heures et supprime des semaines de correction au fil de l’eau. C’est le meilleur investissement du projet.
Questions fréquentes
Faut-il développer soi-même ou utiliser son logiciel de gestion ?
Si votre logiciel propose déjà un raccordement, l’utiliser évite un développement et sa maintenance. Le développement sur mesure ne se justifie que pour un système propriétaire sans solution existante, ou pour des volumes et des règles très spécifiques.
Une API suffit-elle pour être conforme ?
Non. La conformité suppose aussi la complétude des données facturées, l’archivage du document et de sa piste d’audit, et le traitement des rejets. L’API est le canal, pas la conformité.
Que se passe-t-il si la plateforme est indisponible ?
Les envois échouent et doivent être rejoués. Une file d’attente avec reprise automatique est donc nécessaire côté logiciel, sans quoi une indisponibilité de quelques heures se traduit par des factures jamais transmises.
Peut-on continuer à envoyer un PDF par courriel ?
Entre entreprises assujetties, non, une fois l’obligation applicable. Le format Factur-X permet cependant de conserver un document lisible à l’écran, puisqu’il reste un PDF, tout en portant les données structurées attendues.
Comment savoir qui est le destinataire technique ?
L’identification passe par un annuaire qui associe l’identifiant d’une entreprise à la plateforme qui la dessert. C’est cette information qui permet à votre opérateur d’acheminer la facture au bon endroit, et son absence est une cause fréquente de rejet.
Les factures aux particuliers sont-elles concernées ?
L’obligation de facturation électronique porte sur les opérations entre entreprises assujetties. Les opérations avec des particuliers relèvent d’une obligation distincte de transmission de données, l’e-reporting, avec ses propres modalités.
Les erreurs d’intégration qui reviennent
| Erreur | Conséquence | Correction |
|---|---|---|
| Traiter l’émission avant la réception | Première échéance manquée | Commencer par recevoir |
| Ne pas valider avant d’envoyer | Rejets en série | Appeler la validation systématiquement |
| Afficher les erreurs techniques brutes | Aucune correction possible par l’utilisateur | Traduire en messages métier |
| Ignorer les statuts du cycle de vie | Litiges de réception et suivi aveugle | Récupérer et stocker chaque changement d’état |
| Ne pas prévoir le circuit de rejet | Factures perdues sans alerte | File de traitement des rejets |
| Coder un sérialiseur XML maison | Maintenance permanente à chaque évolution | Déléguer la conversion à l’opérateur |
Une septième erreur mérite d’être isolée : considérer le projet comme purement technique. La qualité du référentiel client conditionne davantage la réussite que l’intégration elle-même. Des adresses incomplètes ou des identifiants d’entreprise absents produisent des rejets que le meilleur code ne corrigera pas.
API de facturation électronique et Djaboo : ce que l’outil couvre
Djaboo est un logiciel de gestion tout-en-un pour TPE et PME. Sur ce sujet, il faut distinguer deux choses : son API de gestion, et son raccordement à la facturation électronique.
Son interface de programmation couvre les objets de gestion : clients, contacts, devis, factures, avoirs, dépenses, articles, prospects, projets, contrats, ainsi que l’authentification et des compteurs. Elle propose également des webhooks, avec leur création, leur activation et la consultation de leurs journaux, ce qui permet d’être notifié d’un événement plutôt que d’interroger en boucle. Un mécanisme de traitement par lot et des connecteurs de test complètent l’ensemble.
Sur la facturation électronique, l’architecture retenue est celle décrite plus haut. Djaboo n’est pas une plateforme agréée et ne transmet pas lui-même : il est compatible et intégré avec Super PDP, qui assure la transmission. Concrètement, la facture est d’abord traduite dans le modèle sémantique de la norme européenne EN 16931, puis la conversion vers le XML et l’acheminement sont délégués à Super PDP, ce qui évite de maintenir un sérialiseur de format côté Djaboo.
Le raccordement couvre les cinq opérations d’une intégration complète. Une validation préalable renvoie un rapport d’erreurs avant l’envoi. L’émission dépose la facture chez l’opérateur. Le suivi récupère l’état d’avancement d’une facture émise. La réception synchronise les factures entrantes et permet de télécharger le document reçu au format Factur-X. Enfin, les statuts du cycle de vie peuvent être renvoyés à l’opérateur, avec un motif en cas de refus. L’authentification auprès de la plateforme repose sur un échange de jetons.
Deux limites doivent être dites clairement. Djaboo dépend de la plateforme partenaire pour tout ce qui relève de la transmission et de la conversion de format : les capacités réelles en la matière sont celles de Super PDP, pas celles de Djaboo. Et le raccordement suppose une configuration préalable côté opérateur, avec les identifiants correspondants.
Un simulateur permet par ailleurs de situer votre situation au regard du calendrier de la réforme.
Ce qu’il faut retenir en 2026
Une API de facturation électronique sert à déposer, suivre et récupérer des factures auprès d’un opérateur habilité. Produire un fichier au bon format ne suffit pas à satisfaire l’obligation : la transmission passe nécessairement par une plateforme.
Cinq opérations composent une intégration complète, et la validation en amont est celle qui évite le plus de travail manuel. La réception, souvent traitée en second, correspond pourtant à la première échéance du calendrier.
Et le facteur décisif de réussite n’est pas technique. Un référentiel client incomplet produit des rejets que l’intégration la mieux conçue ne rattrapera pas.
