Depuis la rentrée, la question n'est plus « faut-il passer à la facture électronique ? » mais « comment mon logiciel s'y branche ? ». La réforme est entrée en vigueur le 1er septembre 2026 : toutes les entreprises assujetties à la TVA doivent désormais être capables de recevoir des factures électroniques, tandis que l'obligation d'émettre concerne d'abord les grandes entreprises et les ETI, avec le e-reporting associé (economie.gouv.fr). Plus de 10 millions d'acteurs économiques sont concernés selon la DGFiP. Pour les TPE et PME, l'échéance d'émission est fixée au 1er septembre 2027 (Cegid) : c'est exactement le temps qu'il faut pour préparer proprement son système d'information, sans bricolage de dernière minute.

Reste la question côté développement : que faut-il réellement construire dans votre ERP, votre boutique ou votre logiciel maison pour dialoguer avec une plateforme agréée (PA, anciennement PDP) ?

Ce qui change vraiment dans votre code

Un PDF envoyé par e-mail n'est plus une facture électronique au sens de la réforme. Il faut produire un fichier structuré, lisible par une machine, dans l'un des formats socles conformes à la norme européenne EN 16931 : Factur-X (PDF + XML embarqué), UBL ou CII (Tenor Solutions). Le standard franco-allemand Factur-X continue d'évoluer, sa dernière version publiée par la FNFE-MPE étant Factur-X 1.09.2 / ZUGFeRD 2.5.2 : votre générateur de factures doit donc être versionné, pas figé.

Deuxième changement : la facture ne va plus directement au client. Elle transite par une plateforme agréée par l'administration, choisie par l'émetteur et par le destinataire. Plus de 140 plateformes ont obtenu l'agrément (dolibarr.org), et la liste officielle publiée par l'administration en recensait 145 fin juillet (independant.io). Concrètement, votre application ne « poste » plus un PDF : elle appelle une API, reçoit un identifiant de dépôt, puis suit des statuts de cycle de vie (déposée, reçue, rejetée, encaissée…) qu'il faut stocker et afficher.

Les trois briques à construire

1. La génération du format structuré

C'est la partie la plus sous-estimée. Une facture structurée impose des données propres : SIREN/SIRET de l'acheteur, adresse de livraison, catégorie de TVA par ligne, mentions d'exonération, référence de commande. Si votre base contient des clients sans SIRET ou des libellés de TVA saisis à la main, le générateur produira des fichiers rejetés. Avant d'écrire la moindre ligne de mapping, faites un audit de qualité des données : requêtes de contrôle, taux de complétude, correction en masse.

2. Le connecteur vers la plateforme

Chaque plateforme expose sa propre API REST, avec ses règles d'authentification et ses quotas. Trois réflexes d'ingénierie évitent les mauvaises surprises : une couche d'abstraction (votre code appelle votre interface, pas directement le fournisseur, pour pouvoir changer de plateforme sans tout réécrire), l'idempotence des envois (une facture ne doit jamais partir deux fois après un timeout), et une file d'attente avec relances plutôt qu'un appel synchrone au moment de la validation. Ce type de tuyauterie relève typiquement de l'automatisation des tâches et des flux : planification, rejeu, journalisation.

3. La réception et le rapprochement

Obligation immédiate pour tout le monde, la réception est souvent oubliée. Il faut récupérer les factures fournisseurs déposées sur votre plateforme, les rapprocher de vos commandes, et surtout renvoyer les statuts attendus (acceptée, refusée, en litige, payée). Sans automatisation, ce travail retombe sur la comptabilité, ce qui annule le bénéfice de la réforme.

Les pièges techniques les plus fréquents

  • Le routage : identifier la plateforme du destinataire via l'annuaire, et gérer le cas « client introuvable » sans bloquer la facturation.
  • Les avoirs et factures d'acompte : ils ont leur propre typologie dans le format structuré et cassent souvent les modèles internes trop simples.
  • L'archivage : le PDF lisible et le XML doivent rester accessibles et cohérents pendant toute la durée légale, y compris après une migration.
  • Les rejets : prévoir un écran de reprise d'erreur compréhensible par un non-technicien, avec le motif renvoyé par la plateforme.
  • Les tests : exigez un environnement de recette chez la plateforme et rejouez un vrai mois de facturation avant la bascule.

Selon votre socle logiciel

Vous êtes sur Dolibarr. L'écosystème bouge vite : des passerelles vers des plateformes agréées existent déjà et l'association PDP Libre a annoncé un partenariat avec la plateforme EsaLink (dolibarr.org). Reste que la logique métier est rarement standard : numérotation, remises, TVA spécifiques, entités multiples. Un module Dolibarr sur mesure permet de fiabiliser le mapping et les statuts sans dénaturer votre ERP.

Vous vendez sur WooCommerce. Le B2C n'est pas concerné par l'e-invoicing, mais vos ventes à des professionnels le sont, et les données de transaction relèvent du e-reporting. Le sujet devient donc un enjeu de collecte : numéro de TVA intracommunautaire, SIRET, type de client. Un plugin WooCommerce adapté peut capter ces informations au bon moment, sans alourdir le tunnel de commande.

Vous éditez un logiciel métier ou un SaaS. Vos propres clients vont vous réclamer la conformité. Intégrer la facturation électronique dans un logiciel SaaS multi-clients suppose de gérer plusieurs plateformes, plusieurs profils fiscaux et un paramétrage par locataire : mieux vaut concevoir cette abstraction dès maintenant que la greffer dans l'urgence.

Une feuille de route réaliste sur quelques mois

Un séquencement qui fonctionne bien pour une PME : audit des données clients et TVA, puis choix de la plateforme agréée (critères : API documentée, environnement de test, formats supportés, réversibilité), puis développement du connecteur d'émission et de réception, puis recette sur données réelles, enfin bascule progressive par typologie de clients. Traiter d'abord la qualité des données est ce qui fait gagner le plus de temps sur la partie développement.

La facturation électronique n'est pas qu'une contrainte : c'est l'occasion de fiabiliser un flux qui touche la trésorerie, et de supprimer des ressaisies. Si vous ne savez pas par où commencer, faites d'abord établir un état des lieux technique de votre facturation actuelle. Nos équipes peuvent auditer votre existant et chiffrer un connecteur. Parlons de votre projet pour cadrer les priorités.

Questions fréquentes

Non. Un PDF classique, même envoyé par e-mail, n'a pas la valeur d'une facture électronique au sens de la réforme. Il faut un format structuré conforme à la norme EN 16931 (Factur-X, UBL ou CII) et un passage par une plateforme agréée. En revanche, si votre logiciel produit déjà des PDF fiables, l'essentiel du travail consiste à y ajouter la couche XML et le connecteur vers la plateforme, pas à tout recommencer.

Cela dépend de votre niveau de personnalisation. Si votre facturation est standard, un module ou une passerelle du marché peut suffire et coûtera moins cher. Dès que vous avez des règles spécifiques (numérotation, acomptes, refacturation inter-entités, TVA particulière, multi-sociétés), le module standard atteint vite ses limites : le développement sur mesure porte alors sur le mapping des données et la gestion des statuts, pas sur la plateforme elle-même.

La réception est déjà obligatoire, donc le volet « recevoir et rapprocher » est prioritaire. Pour l'émission, l'échéance des petites structures est fixée à septembre 2027 : commencer par l'audit des données clients (SIRET, TVA, adresses) dans les mois qui viennent laisse une marge confortable pour développer, tester et corriger, plutôt que de tout condenser sur les dernières semaines.