2024 : report de l’obligation initiale. 2026 : entrée en vigueur progressive pour les transactions B2B en France. Entre ces deux dates, la réforme de facturation électronique a changé plusieurs fois de calendrier, ce qui a conduit nombre de boutiques à repousser leur préparation technique jusqu’au dernier moment. Ce moment approche désormais concrètement pour toute boutique WooCommerce qui vend à des professionnels.
Le principe de la réforme reste stable malgré les reports successifs : chaque facture entre assujettis à la TVA française devra transiter par une plateforme de dématérialisation, sous un format structuré exploitable par une machine, et non plus seulement sous forme de PDF lisible par un humain. Pour un développeur, cela signifie repenser la chaîne d’émission de facture d’une boutique B2B bien avant l’échéance réglementaire.
Ce que la réforme change concrètement pour une boutique
Une facture WooCommerce classique, qu’elle soit générée par le cœur du plugin ou par une extension de facturation, produit aujourd’hui un document PDF, éventuellement accompagné d’une ligne comptable exportée vers un logiciel tiers. La réforme impose un format structuré supplémentaire, distinct du PDF affiché au client, qui porte les mêmes informations sous une forme interprétable automatiquement : numéro de TVA intracommunautaire, détail des lignes, montants hors taxes et taxes associées, dans un schéma standardisé.
Trois formats structurés circulent aujourd’hui dans les échanges envisagés : Factur-X (PDF enrichi d’un fichier XML embarqué), UBL et CII, ces deux derniers étant des formats XML purs sans représentation visuelle intégrée. Une boutique n’a pas à choisir un format unique dès aujourd’hui : elle doit surtout s’assurer que son architecture peut produire les données nécessaires à n’importe lequel de ces formats sans réécriture complète.
Architecture d’export recommandée

Le principe directeur consiste à découpler la génération des données de facturation du choix de la plateforme de dématérialisation partenaire (PDP), puisque ce choix appartient souvent au client final ou évolue avec le temps.
Commande WooCommerce (wc_order)
│
▼
Service interne de normalisation de facture
│ (mapping vers un schéma pivot interne)
▼
┌────────────┬─────────────┬─────────────┐
▼ ▼ ▼
Export Factur-X Export UBL Export CII
│ │ │
└─────┬──────┴──────┬──────┘
▼ ▼
Plateforme de dématérialisation partenaire (PDP)
│
▼
Administration fiscale (transmission indirecte)
Le point clé de ce schéma est le service de normalisation interne : il transforme chaque commande WooCommerce en un modèle de données pivot, indépendant du format final, avant de le convertir vers le format attendu par la plateforme choisie. Sans cette étape intermédiaire, un changement de plateforme partenaire imposerait de réécrire toute la logique d’export.
Ce que la boutique doit fournir dès aujourd’hui, sans attendre la plateforme finale
- Le numéro de TVA intracommunautaire du client B2B, déjà collecté et validé pour l’autoliquidation, réutilisable directement dans le schéma pivot.
- Le détail ligne par ligne de chaque commande, avec taux de TVA appliqué par ligne et non un total global agrégé.
- Une adresse de facturation strictement conforme, y compris pour les clients dont l’adresse de livraison diffère.
- Un identifiant de commande stable et unique, conservé même après un éventuel avoir ou une facture rectificative.
Le cas des avoirs et factures rectificatives
La réforme s’applique également aux avoirs, qui devront eux aussi transiter sous format structuré. Une boutique qui gère aujourd’hui ses avoirs par une simple note manuelle dans WooCommerce devra faire correspondre chaque avoir à la facture d’origine dans le schéma pivot, avec une référence croisée explicite, faute de quoi la plateforme de dématérialisation risque de rejeter le document pour incohérence de rattachement.
Le format d’échange finira par se stabiliser avec le temps ; la vraie urgence pour une boutique B2B est de disposer de données de facturation complètes et cohérentes à la source, bien avant de savoir quel format exact sera exigé.
Ne pas confondre transmission et choix de la plateforme
Le choix de l’opérateur de dématérialisation partenaire relève d’une décision commerciale et comptable qui appartient à l’entreprise cliente, pas au développeur de la boutique. La responsabilité technique se limite à produire une donnée de facturation complète, structurée et exportable dans un format standard, prête à être transmise à la plateforme retenue le moment venu, quelle qu’elle soit.
En résumé
Se préparer à la facturation électronique 2026 ne consiste pas à parier sur un format ou une plateforme précise, mais à construire dès maintenant un modèle de données pivot fiable à partir des commandes WooCommerce, capable d’alimenter n’importe quel export structuré demandé le jour où l’obligation s’appliquera concrètement à la boutique.