Facturation électronique : mon retour d'expérience
Avant de proposer à des boutiques en ligne de se raccorder à une plateforme agréée, j'ai fait le chantier pour ma propre activité. Ma facturation tourne sur une application Symfony que j'ai écrite, et cette application émet, transmet, suit et reçoit les factures par le circuit officiel. Voici ce que ce chantier m'a appris, avec le code en tête et sans jargon inutile.
Je vends ce type d'intégration, gardez cet intérêt en tête en me lisant. Les dates et les montants ci-dessous renvoient à leur source officielle, vérifiée le 14 novembre 2026.
Le calendrier, tel qu'il s'applique aujourd'hui
Selon impots.gouv.fr, toutes les entreprises assujetties à la TVA doivent pouvoir recevoir des factures électroniques depuis le 1er septembre 2026. Les grandes entreprises et les ETI émettent depuis la même date. Les PME et les micro-entreprises émettront au 1er septembre 2027, et l'e-reporting, c'est-à-dire la déclaration des ventes aux particuliers et à l'étranger, suit le même calendrier.
Un point d'actualité : le 3 novembre 2026, les députés ont adopté un amendement qui suspendait ces obligations pour les petites entreprises. Il est tombé le lendemain, avec le rejet de la première partie du projet de loi de finances pour 2027. Le calendrier reste donc celui de la réforme, mais le Sénat examine le budget à partir du 20 novembre et une disposition semblable peut revenir. Je mettrai cet article à jour si les dates changent.
Première leçon : il y a deux flux, pas un
Une vente à une entreprise française donne lieu à une facture électronique, transmise par la plateforme agréée. Une vente à un particulier, ou à un client établi à l'étranger, ne donne pas lieu à une facture électronique : elle est déclarée en e-reporting, sous forme de données de transaction. Mon application fait ce tri au moment où la facture est émise, à partir de deux informations : le pays du client et le fait qu'il soit un professionnel.
Pour une boutique en ligne, la difficulté n'est pas le code. C'est la donnée. Savez-vous, pour chaque commande, si le client est une entreprise, avec quel SIREN, et dans quel pays elle est établie ? Beaucoup de boutiques ne le stockent pas de façon fiable, et c'est le premier chantier à lancer, bien avant de choisir un module.
Deuxième leçon : un fichier pour la plateforme, un PDF pour le client
La plateforme reçoit un fichier structuré. J'envoie de l'UBL. Mon client, lui, reçoit un PDF Factur-X : un PDF lisible par un humain, qui embarque les données structurées au profil EN 16931. Je le génère avec la bibliothèque open source horstoeko/zugferd. Les deux documents viennent de la même facture dans la base, ce qui évite qu'un montant affiché au client diffère de celui qui part vers l'administration.
Troisième leçon : une facture a une vie après l'envoi
Une facture transmise passe par des statuts : déposée, reçue, mise à disposition, refusée, encaissée. La plateforme les renvoie par webhook, et je les synchronise aussi à intervalles réguliers au cas où un appel se perdrait. Je ramène les codes officiels à trois états lisibles dans l'administration : en attente, reçue, refusée. Une facture refusée que personne ne voit est une facture qui ne sera pas payée, d'où l'intérêt de l'afficher clairement.
Quatrième leçon : prévoir un interrupteur
Tout ce qui parle à la plateforme passe par un coupe-circuit. Tant qu'il est coupé, les factures sont générées et stockées, mais rien ne sort de l'application. J'ai pu tester sur des données réelles sans risque d'envoyer une facture erronée sur le réseau officiel. Je transmets aussi l'identifiant interne de chaque facture, pour pouvoir rattacher chaque transmission à son origine en cas de question.
Cinquième leçon : commencer par la réception
On parle surtout de l'émission, mais la réception est obligatoire depuis septembre 2026. Mes factures fournisseurs arrivent par la même plateforme, et mon application les liste et les télécharge par l'API. Si votre boutique n'a encore rien fait, commencez par là : choisir une plateforme dans la liste officielle des plateformes agréées et vérifier que vous recevez bien vos factures.
Ce que coûte le retard
Les sanctions ont été relevées par la loi de finances pour 2026. Une facture non émise sous forme électronique coûte 50 euros, dans la limite de 15 000 euros par an, selon l'article 1737 du Code général des impôts. Une transmission d'e-reporting manquante coûte 500 euros, avec le même plafond annuel, selon l'article 1788 D. Une première infraction réparée dans les trente jours n'est pas sanctionnée.
Ce que cela change pour une boutique Sylius ou sur mesure
Les solutions du marché passent par un module ou une application, dont la couverture varie : vérifiez qu'il gère l'e-reporting, les statuts et la réception, pas seulement la génération d'un PDF. Une boutique Sylius ou sur mesure peut aller plus loin, parce que les données de commande lui appartiennent : trier chaque commande entre facture électronique et e-reporting, générer le Factur-X à partir de la commande, l'envoyer par l'API d'une plateforme agréée et conserver les statuts. J'ai détaillé l'aspect technique côté Sylius dans ce guide sur Sylius et la facture électronique, et une version anglaise de ce retour d'expérience est publiée sur dev.to.
Si vous voulez un avis sur votre cas, je regarde avec vous votre plateforme, vos données clients et votre logiciel comptable : voyez mon accompagnement à la facturation électronique. Le premier diagnostic est offert, et vous parlez directement à la personne qui écrit le code.