Facturation électronique 2026 : connecter votre logiciel
Pour la facturation électronique en France en 2026, quatre acteurs peuvent connecter votre logiciel à une plateforme agréée par API : l'éditeur de ce logiciel s'il existe, la plateforme elle-même, un intégrateur, ou le développeur de votre application sur mesure. Le bon choix dépend de la personne qui possède le code. Dans tous les cas, c'est la plateforme agréée qui transmet les factures : le connecteur ne fait que lui parler.
Je précise mon intérêt : l'intégration de la facture électronique dans des applications existantes fait partie de mes offres. Ce guide ne redit pas toute la réforme, il répond à une question plus étroite que se pose un dirigeant dont le logiciel a été développé pour lui, ou dont l'éditeur reste flou : à qui confier ce branchement ?
Obligations et calendrier en novembre 2026
Depuis le 1er septembre 2026, toutes les entreprises doivent pouvoir recevoir des factures électroniques, et les grandes entreprises comme les ETI doivent aussi émettre les leurs sous cette forme. Les PME et micro-entreprises ont jusqu'au 1er septembre 2027 pour l'émission. L'administration indique que l'e-reporting, c'est-à-dire la transmission de certaines données de vente et de paiement, suit le même calendrier.
La situation d'une PME qui a un logiciel maison est donc particulière. Elle a déjà dû organiser sa réception, souvent avec un portail fourni par une plateforme. Sa facturation sortante peut encore partir de son application, mais elle a moins d'un an pour que les factures passent par le bon circuit, avec le bon format et les bons champs. Pour le détail des échéances, lisez mon article sur le calendrier 2026 et 2027.
Plateforme agréée, solution compatible : qui a le droit de faire quoi
La distinction officielle est simple. Une plateforme agréée est un opérateur de dématérialisation immatriculé par l'administration fiscale pour trois ans renouvelables. Sans cette immatriculation, un outil reste une solution compatible : il peut préparer ou présenter les factures, mais il ne peut ni les transmettre à la plateforme du client, ni en recevoir pour le compte de l'entreprise, ni transmettre les données à l'administration.
Votre application sur mesure est donc, au mieux, une solution compatible. Ce n'est pas un défaut. Elle garde les devis, les commandes, les règles propres à votre métier et l'affichage pour vos équipes, et elle délègue l'acheminement à une plateforme. Avant de choisir celle-ci, vérifiez son nom sur la liste officielle publiée par impots.gouv.fr : le nombre d'inscrits évolue et les comparatifs vieillissent vite.
Connecter un logiciel par API : quatre interlocuteurs possibles
| Qui | Bon choix si | Limite à vérifier |
|---|---|---|
| Éditeur du logiciel | Vous utilisez un produit du marché maintenu | Plateformes réellement prises en charge, statuts remontés |
| Plateforme agréée | Votre volume est simple, un portail ou un import suffit | Ressaisie, écart avec vos données métier |
| Intégrateur | ERP et plusieurs systèmes à faire dialoguer | Coût, dépendance à un connecteur tiers |
| Développeur de l'application | Logiciel sur mesure dont vous avez le code | Accès au code, tests, maintenance après le passage en production |
Si votre éditeur annonce une compatibilité, demandez-lui une réponse écrite : quelle plateforme, quels flux, quels statuts, à partir de quelle version. La page officielle conseille d'ailleurs de contacter son logiciel de facturation pour savoir s'il est déjà connecté à une plateforme agréée. Si aucune réponse précise ne vient, ou si l'éditeur a disparu, le problème rejoint celui de la reprise d'une application : retrouver le code, comprendre la génération des factures, puis ajouter le connecteur.
Ce que le raccordement API contient vraiment
L'API n'est que la partie visible. La norme AFNOR XP Z12-013 décrit des interfaces entre le système d'information d'une entreprise et les plateformes agréées, notamment pour échanger factures et statuts. Selon l'analyse de Ma Facture Électronique, site qui signale lui-même des liens rémunérés, une plateforme peut être immatriculée sans proposer cette API normalisée, et plusieurs fonctions comme les notifications automatiques restent de simples recommandations. Le même site rapporte, sur sa page consacrée à la norme, une enquête de la DGFiP présentée en mai 2026 où 84 % des plateformes répondantes confirmaient la mettre en œuvre. Deux plateformes conformes peuvent donc offrir un service très différent à votre développeur.
Le travail se découpe en quatre chantiers. D'abord les données : une facture doit respecter un format UBL, CII ou mixte et porter ses mentions obligatoires dans des champs dédiés, dont les numéros SIREN du fournisseur et du client. Ensuite l'envoi et le suivi : l'application doit authentifier ses appels, transmettre le fichier, puis enregistrer les statuts de la facture, y compris les rejets et les refus. Vient la réception des factures d'achat si vous voulez les traiter dans l'application. Enfin l'exploitation : journal des échanges, alerte en cas d'échec, reprise sans doublon.
Le risque le plus coûteux n'est pas une panne franche, c'est une facture rejetée que personne ne voit. Une application qui affiche « envoyée » parce que l'appel a réussi, alors que la plateforme a ensuite refusé le fichier, trompe la comptabilité. Faites donc tester le rejet technique, le refus du client et l'encaissement, pas seulement le cas qui marche.
Ce qu'il faut demander avant de signer
À la plateforme, demandez sa documentation d'API complète, un environnement de test, le mode d'authentification et, par écrit, les canaux réellement ouverts : API normalisée, API propre ou dépôt de fichiers. À la personne qui développe, demandez une preuve correspondant à votre cas (une intégration de plateforme, ou à défaut un projet de génération de factures structurées), la liste des tests prévus et qui gérera les changements de spécification. Cette question vaut pour tout prestataire, moi compris.
Demandez aussi qui possède le connecteur. S'il est écrit dans votre application, sa propriété, son code et sa documentation doivent vous revenir, et changer de plateforme doit rester envisageable sans tout refaire. Une couche séparée, qui isole les appels à la plateforme du reste du code, coûte peu au départ et protège de ce risque.
Quand il ne faut pas développer de connecteur
Si vous émettez quelques factures par mois, et que votre application ne produit pas de données complexes, le portail d'une plateforme ou un logiciel de facturation du marché suffira. Développer un connecteur serait une dépense sans retour. Si votre logiciel métier est un produit d'éditeur encore maintenu, attendez d'abord sa réponse écrite : un développement parallèle risque d'être cassé par sa prochaine version. Enfin, un grand groupe avec plusieurs ERP et filiales relèvera plutôt d'un intégrateur spécialisé, avec une équipe dédiée à la conduite du projet.
Le sujet vous concerne plutôt si votre application génère elle-même ses factures et que personne ne peut vous dire ce qu'elle fera en septembre 2027. Dans ce cas, la prochaine étape tient en trois éléments à rassembler : un exemple de facture, le nom de votre plateforme si vous l'avez choisie, et l'accès au code. Avec cela, je peux vous dire ce qui manque, à travers mon offre d'intégration de la facture électronique, ou vous orienter ailleurs si un autre circuit vous convient mieux.