La facturation électronique expliquée aux développeurs : ce qui change vraiment le 1er septembre 2026

Table des matières

Pourquoi cet article (et pourquoi maintenant)

Le 1er septembre 2026 — dans trois semaines au moment où j’écris — la France bascule dans la facturation électronique obligatoire entre entreprises. Vous avez peut-être vu passer le sujet de loin, en vous disant que c’était une affaire de comptables. Mauvaise nouvelle : si vous développez ou maintenez un logiciel qui émet, reçoit ou touche des factures — ERP, SaaS de gestion, boutique en ligne, outil de facturation maison — c’est d’abord un chantier d’intégration logicielle. Et donc le vôtre.

La bonne nouvelle, c’est que sous le vocabulaire fiscal se cache un système d’échange de messages plutôt bien spécifié : des formats structurés, des API normalisées, un annuaire, des accusés de réception. Bref, notre monde. Cet article est le premier d’une série où je traduis la réforme en langage développeur — je travaille au quotidien sur la construction d’une plateforme agréée, autant que ça serve.

Ici, on pose les fondations : qui est obligé de faire quoi, quand, avec quels acteurs et quels formats. Les épisodes suivants creuseront chaque brique.

La réforme en une phrase (puis en plusieurs)

La version courte : les factures entre entreprises françaises assujetties à la TVA ne transiteront plus librement par mail ou par papier, mais par des plateformes agréées par l’administration, dans des formats structurés — et l’administration fiscale recevra au passage les données qui l’intéressent.

Décortiquons, parce que chaque mot compte.

Les factures entre entreprises : la réforme vise le B2B domestique. Vos ventes aux particuliers (B2C) et vos opérations internationales ne passent pas par ce circuit — mais elles ne sont pas oubliées pour autant : elles relèvent du e-reporting, on y revient plus bas.

Des plateformes agréées : c’est le pivot du système. L’article 289 bis du Code général des impôts prévoit que l’émission, la transmission et la réception des factures électroniques s’effectuent en recourant à une plateforme agréée. Une plateforme agréée (vous verrez aussi l’ancien sigle « PDP », plateforme de dématérialisation partenaire) est un opérateur immatriculé par l’administration fiscale, pour trois ans renouvelables, après un dossier exigeant. La liste officielle est publiée sur impots.gouv.fr. Attention à la nuance qui pique : un éditeur peut proposer une « solution compatible » — un logiciel qui se branche sur une plateforme agréée — sans être lui-même agréé. Seule la plateforme agréée a le droit de transmettre les factures aux autres plateformes et les données à l’administration.

Des formats structurés : fini le PDF « image » envoyé par mail comme facture officielle. Le socle de la réforme repose sur trois formats : UBL et CII (deux dialectes XML structurés) et Factur-X (un format hybride : un PDF lisible par un humain, avec un XML structuré embarqué dedans). Les trois portent la même sémantique, héritée de la norme européenne EN 16931. L’épisode 2 de cette série leur est entièrement consacré.

L’administration reçoit les données : c’est l’article 289 E du CGI — les données des factures électroniques sont transmises à l’administration par la plateforme agréée choisie par l’assujetti. Vous ne parlez jamais directement au fisc : votre plateforme s’en charge. C’est tout l’intérêt du dispositif pour l’État (lutte contre la fraude à la TVA, pré-remplissage à terme), et toute la responsabilité des plateformes.

Le schéma en Y (votre nouvelle carte mentale)

L’architecture cible tient dans un schéma que tout le monde appelle « le schéma en Y ». En voici la version développeur :

• Le fournisseur émet sa facture via sa plateforme agréée.
• La plateforme du fournisseur consulte l’annuaire — un service central géré par l’État — pour savoir quelle plateforme dessert le client, puis lui transmet la facture. Pensez-y comme à un DNS des entreprises : on résout un identifiant (le SIREN, éventuellement affiné) vers une plateforme de réception.
• La plateforme du client reçoit, contrôle, met la facture à disposition du client, et renvoie des statuts de cycle de vie (reçue, refusée, encaissée…) qui remontent le circuit en sens inverse.
• La branche du Y : les plateformes extraient les données fiscales des factures et les poussent vers le concentrateur de l’administration.

Retenez le renversement : l’État ne fournit pas la tuyauterie d’échange entre entreprises — il fournit l’annuaire et le concentrateur, et il agrée des opérateurs privés qui font le reste. Le guide officiel de démarrage liste d’ailleurs les « outils mis à disposition par l’État » : l’annuaire, le concentrateur, le système d’échange. Tout le reste — API, réception, contrôles, restitution — c’est le travail des plateformes et de vos intégrations.

Le calendrier : deux dates, deux obligations

Le calendrier légal tient en deux dates, et il est explicitement maintenu (le guide officiel de démarrage publié par la DGFiP commence par le rappeler) :

• 1er septembre 2026 : toutes les entreprises concernées par la réforme doivent être capables de recevoir des factures électroniques via une plateforme agréée. Et les grandes entreprises ainsi que les ETI entrent dans l’obligation d’émission.
• 1er septembre 2027 : l’obligation d’émission s’étend aux PME, TPE et micro-entreprises.

Traduction pratique pour vous, développeur : la réception, c’est pour tout le monde, maintenant. Même la petite SARL cliente de votre SaaS devra avoir désigné une plateforme de réception. L’émission arrive en deux vagues — mais ne vous y trompez pas : une entreprise non encore soumise à l’émission peut déjà recevoir des factures électroniques de ses gros fournisseurs dès septembre 2026. Le flux entrant précède le flux sortant.

Un mot sur la phase de démarrage, parce que le guide officiel est d’une honnêteté rafraîchissante : il n’y aura pas d’application des sanctions aux entreprises qui rencontrent des difficultés mais sont engagées dans une trajectoire sérieuse de mise en conformité — tout en précisant que cette souplesse ne constitue ni un report ni une suspension de l’obligation. L’administration distinguera l’inertie de la difficulté réelle, documentée et suivie d’actions. Autrement dit : gardez des traces de vos démarches d’intégration — c’est littéralement une recommandation officielle.

Et la continuité économique est préservée : une facture reçue par mail ou papier après le 1er septembre 2026 ne doit pas être écartée pour cette seule raison — elle reste payable, comptabilisable, et la TVA reste déductible. La cible reste le circuit électronique, mais la réforme n’a pas vocation à bloquer l’économie pendant la transition.

E-invoicing vs e-reporting : les deux moitiés du dispositif

Deux mots-valises reviennent partout, et ils structurent tout le dispositif :

• E-invoicing : l’échange de la facture électronique elle-même entre entreprises françaises, via les plateformes. La facture est le message.
• E-reporting : pour les opérations qui ne passent pas par ce circuit — ventes aux particuliers (B2C), transactions internationales — l’entreprise doit quand même transmettre à l’administration des données de transactions, ainsi que des données de paiement. Pas la facture complète : des données agrégées ou par opération, selon les cas, envoyées par votre plateforme agréée.

Pour un développeur, la conséquence est structurante : même si votre logiciel ne gère « que » de la vente B2C, la réforme vous concerne — il faudra produire et transmettre ces données. J’y consacre l’épisode 5.

Où sont les specs (et lesquelles lire)

Parlons documentation, puisque c’est par là que tout chantier commence. Trois sources à connaître :

1. Les spécifications externes publiées sur impots.gouv.fr — le document de référence technique du dispositif : dossier principal, annexes, exemples, schémas XSD et swaggers. La version courante est la 3.2 (avril 2026). C’est volumineux, mais c’est la source de vérité, et les swaggers vous donnent une longueur d’avance sur la forme des API.
2. Les normes AFNOR qui normalisent la couche technique entre entreprises et plateformes : la XP Z12-012 (« Formats et Profils des messages Factures et Statuts de cycle de vie »), la XP Z12-013 (« API pour interfacer les systèmes d’information des entreprises avec les plateformes agréées ») et la XP Z12-014 (cas d’usage B2B). Elles sont payantes chez AFNOR — je n’en reproduirai donc pas le contenu ici — mais sachez qu’elles existent : si votre plateforme vous parle de « profils » ou d’« API normalisée », c’est de là que ça vient.
3. Le guide pratique de démarrage (PDF gratuit sur impots.gouv.fr) — 29 questions-réponses très concrètes sur la phase de transition. Lisez-le : c’est court, officiel, et ça répond aux questions que votre product owner va vous poser.

Un conseil de praticien : quand vous lisez ces documents, notez précisément d’où vient chaque règle que vous implémentez. La demi-vie d’une spec en évolution est courte, et une règle qu’on ne peut pas citer est une règle qu’on ne peut pas vérifier.

Ce que ça change concrètement dans votre code

Faisons atterrir tout ça sur votre backlog. Selon votre situation :

Vous éditez un logiciel qui émet des factures (SaaS de gestion, ERP, outil métier) : votre logiciel devra se raccorder à une ou plusieurs plateformes agréées — via leurs API (couvertes par la norme XP Z12-013 et les swaggers des spécifications externes) — pour émettre au format structuré, suivre les statuts de cycle de vie, et gérer les rejets. Le PDF généré par votre lib préférée ne suffira plus pour le B2B domestique.

Vous consommez des factures fournisseurs (compta, gestion des achats, pre-accounting) : vos factures entrantes arriveront par la plateforme de réception de vos clients, en UBL, CII ou Factur-X. Bonne nouvelle : vous allez recevoir de la donnée structurée et fiable, là où vous faisiez peut-être de l’OCR sur des PDF. C’est une opportunité produit autant qu’une contrainte.

Vous faites du B2C ou de l’international : cap sur le e-reporting — production des données de transactions et de paiement, transmission via une plateforme.

Dans tous les cas : il y a un choix structurant à faire — quelle(s) plateforme(s), quel mode d’intégration (API, dépôt de fichiers…), quelle stratégie multi-clients si vous êtes éditeur. C’est exactement l’objet de l’épisode 3, « Intégrer une plateforme agréée : par où commencer ».

Épilogue : une réforme de plomberie, et c’est un compliment

On présente souvent cette réforme comme une contrainte fiscale. Vue de ma chaise de développeur, c’est d’abord la normalisation d’une tuyauterie que chaque éditeur bricolait dans son coin depuis vingt ans : des formats communs, un annuaire commun, des statuts communs. Douloureux à court terme, comme toute normalisation — mais structurellement sain. Et pour ceux qui investissent le sujet tôt, c’est un avantage concurrentiel réel : vos concurrents découvriront en 2027 ce que vous maîtriserez en 2026.

La suite de la série : Factur-X, UBL, CII : le guide du développeur, puis Intégrer une plateforme agréée : par où commencer. Et si votre entreprise cherche un renfort qui a déjà les mains dans une plateforme agréée, mon profil et mes disponibilités sont sur gaetancottrez.dev/facturation-electronique 🔗.

Des questions sur la réforme vue du code ? Les commentaires sont là pour ça — je me ferai une joie de vous répondre.

Sources officielles (consultées en août 2026) : Facturation électronique et plateformes agréées 🔗 (impots.gouv.fr) · Guide pratique de démarrage au 1er septembre 2026 🔗 (PDF, DGFiP) · Spécifications externes et normes 🔗 (impots.gouv.fr) · Je passe à la facturation électronique 🔗 (impots.gouv.fr).