Site icon Freelance Expert PrestaShop – WordPress – WooCommerce : Arnaud Merigeau

Facturation électronique 2026 : le guide technique complet pour mettre PrestaShop et WooCommerce en conformité avant l’échéance

Arnaud Merigeau

Tu gères une boutique PrestaShop ou WooCommerce, tu factures des clients en France, et tu te dis que la réforme de la facturation électronique, c’est un problème de comptable — jusqu’au jour où tu réalises que c’est ton code, tes modules et ton architecture serveur qui devront changer avant septembre 2026.

 

Tu gères une boutique PrestaShop ou un site WooCommerce, tu factures des clients français, et tu as vaguement entendu parler de la réforme de la facturation électronique qui entre en vigueur à partir de septembre 2026. Tu te dis peut-être que ça ne concerne que les grands groupes ou que ton expert-comptable s’en occupera au dernier moment. Mauvaise piste. La réforme touche toutes les entreprises assujetties à la TVA en France, y compris les e-commerçants TPE et indépendants, et les implications techniques sur tes outils actuels — PrestaShop, WooCommerce, plugins de facturation — sont loin d’être négligeables. Si tu attends septembre 2026 pour ouvrir le dossier, tu seras dans la situation du marchand qui découvre que son module de paiement est obsolète la veille du Black Friday. Ce guide te donne une feuille de route complète, technique et actionnelle, pour être conforme sans tout réarchitecturer.
Sommaire
1. 1. Comprendre la réforme en 5 minutes : ce qui change vraiment pour ton e-commerce
2. 2. Les trois architectures possibles pour PrestaShop
3. 3. Les trois architectures possibles pour WooCommerce / WordPress
4. 4. Implémenter le Factur-X : guide technique pas-à-pas
5. 5. Impacts SEO et performance à anticiper
6. 6. Checklist de mise en conformité : ce que tu dois faire maintenant
7. 7. Cas pratiques et configurations serveur
8. Questions Fréquentes (FAQ)
9. Conclusion

1. Comprendre la réforme en 5 minutes : ce qui change vraiment pour ton e-commerce

1.1 Le cadre légal résumé sans jargon fiscal

La réforme française de la facturation électronique repose sur l’ordonnance n°2021-1190 du 15 septembre 2021 et ses décrets d’application. Elle impose deux obligations distinctes selon le type de transaction :

La distinction e-invoicing / e-reporting est fondamentale pour un e-commerçant. Si ton chiffre d’affaires est majoritairement B2C, tu n’es pas soumis à l’obligation d’émettre des factures électroniques structurées pour chaque vente, mais tu dois quand même mettre en place l’e-reporting. Les deux obligations nécessitent un raccordement à une plateforme agréée (PA).

1.2 Le calendrier de déploiement

Le calendrier a été repoussé plusieurs fois. Voici l’état actuel :

Concrètement, si tu es une PME, tu as jusqu’en septembre 2027 pour émettre des factures électroniques conformes. Mais l’obligation de réception, elle, s’applique dès septembre 2026 — ce qui signifie que tu dois être capable de recevoir et traiter des Factur-X dès cette date. Et l’e-reporting, lui, suit le même calendrier que l’émission.

1.3 Les acteurs du nouveau système

1.4 Ce que PrestaShop et WooCommerce ne font pas nativement

Ni PrestaShop (toutes versions, de la 1.7 à la 9.x), ni WooCommerce ne génèrent nativement des factures au format Factur-X ou UBL. Leurs modules de facturation intégrés produisent des PDF simples, sans données structurées embarquées. Il n’existe pas non plus de connecteur natif vers une PDP ou le PPF dans le core de ces deux solutions. Tu dois donc passer par une couche intermédiaire — module tiers, connecteur logiciel comptable, ou intégration ERP — pour être conforme.

2. Les trois architectures possibles pour PrestaShop

2.1 Architecture 1 : connecteur PrestaShop vers logiciel comptable

C’est la solution la plus répandue pour les marchands qui ont déjà un logiciel de comptabilité (Pennylane, Sage, Cegid, QuickBooks, Sellsy, etc.). Le principe est simple : PrestaShop reste ton outil de gestion des commandes, mais toutes les données de facturation sont exportées vers le logiciel comptable via un connecteur (module PrestaShop ou API). C’est le logiciel comptable qui prend en charge la génération du Factur-X et la transmission à la PDP.

Ce dont tu as besoin dans ce cas :

Point technique critique : le format Factur-X est un PDF/A-3 avec un fichier XML embarqué (profil EN 16931). Le logiciel comptable génère ce fichier. Mais si les données de commande transmises depuis PrestaShop sont incomplètes ou mal mappées (absence de SIREN acheteur, TVA mal ventilée), la facture sera techniquement invalide. Audite ton flux de données avant la mise en production.

Avantages :

Limites :

Pour mettre en oeuvre l’Architecture 1 directement depuis ton back-office PrestaShop, le Connecteur Pennylane – Facture Electronique disponible sur l’Addons Marketplace est aujourd’hui l’une des options les plus solides. Pennylane est officiellement immatriculée comme Plateforme Agréée (PDP) par l’État et connectée au réseau PEPPOL — ce qui garantit la compatibilité avec l’ensemble des autres plateformes. Le module prend en charge la conversion automatique des commandes PrestaShop en factures, la génération des écritures comptables en temps réel, ainsi que la synchronisation des
clients et des avoirs. La conformité RFE complète (émission et réception de factures électroniques structurées) est en cours de déploiement pour les marchands déjà connectés — raison de plus pour anticiper plutôt que de s’y prendre à la dernière minute.

 

Voir le Connecteur Pennylane - PrestaShop

2.2 Architecture 2 : module de facturation électronique directement dans PrestaShop

La deuxième approche consiste à installer un module spécialisé directement dans PrestaShop, qui intercède dans le processus de génération de factures et produit du Factur-X nativement à chaque commande validée. Des acteurs comme Azopio se positionnent sur ce créneau.

Comment ça fonctionne techniquement :

Les hooks PrestaShop à connaître pour ce type d’intégration : actionOrderStatusPostUpdate (déclenché au changement de statut de commande), actionPDFInvoiceRender (rendu PDF de la facture), et displayAdminOrderTabContent (si tu veux ajouter une interface de suivi dans le back-office). Si tu développes ton propre module, ces hooks sont ton point d’entrée.

Avantages :

Limites :

2.3 Architecture 3 : PrestaShop en front-end, ERP ou back-office centralisé pour la facturation

Pour les structures plus importantes — marchands multicanaux, B2B avec catalogue complexe, boutiques avec stocks gérés via un ERP comme Sage X3, Odoo, SAP Business One ou Microsoft Dynamics — PrestaShop reste le moteur de vente en ligne mais délègue entièrement le cycle de facturation à l’ERP.

Flux typique :

Si tu passes par Odoo, note que les versions 16 et 17 ont intégré nativement la génération de Factur-X via le module l10n_fr_facturx. La connexion PDP reste à configurer via un connecteur tiers ou une API custom. Sous Sage X3, la conformité FE est assurée via le module « Dématérialisation Factures » à partir de la version 12.

Avantages :

Limites :

3. Les trois architectures possibles pour WooCommerce / WordPress

3.1 Spécificités de l’écosystème WooCommerce

WooCommerce fonctionne différemment de PrestaShop sur plusieurs points qui impactent la mise en conformité :

3.2 Architecture 1 (WooCommerce) : connecteur WooCommerce vers logiciel comptable

Le principe est identique à l’Architecture 1 pour PrestaShop. La plupart des logiciels comptables SaaS compatibles FE proposent aussi un plugin WooCommerce (ou une API générique). La configuration est souvent plus simple car WooCommerce expose une API REST bien documentée (API v3) que les éditeurs comptables utilisent pour récupérer les données de commande.

Points de vigilance spécifiques à WooCommerce :

Hook WooCommerce clé pour ce type d’intégration : woocommerce_order_status_changed pour déclencher la transmission dès le changement de statut. Pour la récupération des données de commande, utilise la classe WC_Order et ses méthodes (get_items(), get_taxes(), get_billing_company(), etc.). Évite d’accéder directement aux tables wp_posts et wp_postmeta — WooCommerce 8+ utilise des tables HPOS (High-Performance Order Storage) dédiées.

Pour l’équivalent WooCommerce, le plugin open source WooCommerce Pennylane développé par Tibo Alberny constitue un point de départ sérieux. Disponible gratuitement sur GitHub et sur le répertoire officiel WordPress.org, il relie ta boutique WooCommerce à Pennylane via l’API, en gérant la création des factures clients, l’ajout des champs SIRET et numéro de TVA intracommunautaire dans le formulaire de commande — deux données obligatoires dans un Factur-X B2B — ainsi que la synchronisation des avoirs en cas de remboursement. Pennylane étant officiellement immatriculée comme Plateforme Agréée (PDP) et connectée au réseau PEPPOL, c’est bien elle qui prend en charge la transmission réglementaire des factures électroniques côté conformité RFE. Pour les boutiques à volume important ou ayant besoin d’automatisation poussée (lettrage automatique des paiements, factures multilingues, opérations en masse), une version PRO maintenue par Devikit étend les fonctionnalités du plugin de base. Dans tous les cas, tu auras besoin d’un compte Pennylane actif avec un accès API configuré pour que l’intégration fonctionne.

 

Voir le plugin WooCommerce Pennylane sur GitHub

3.3 Architecture 2 (WooCommerce) : plugin de facturation électronique natif

L’offre de plugins WooCommerce spécifiquement dédiés à la conformité FE française est encore très limitée fin 2025. Les plugins généralistes comme WooCommerce PDF Invoices & Packing Slips (par WP Overnight) ou YITH WooCommerce PDF Invoices ne supportent pas le Factur-X nativement. Il faudra soit attendre des mises à jour majeures de ces plugins, soit passer par un plugin français spécialisé.

Comment évaluer un plugin de FE pour WooCommerce :

3.4 Architecture 3 (WooCommerce) : WooCommerce + ERP centralisé

Même logique qu’en Architecture 3 PrestaShop. WooCommerce, via son API REST, s’intègre bien avec la plupart des ERP du marché. Odoo, en particulier, dispose d’un connecteur WooCommerce natif dans les versions récentes, et de la génération Factur-X via l10n_fr_facturx.

4. Implémenter le Factur-X : guide technique pas-à-pas

4.1 Le format Factur-X : ce que tu dois savoir pour coder

Factur-X est une norme franco-allemande (aussi appelée ZUGFeRD 2.x en Allemagne). Un fichier Factur-X est un PDF/A-3 qui contient en pièce jointe un fichier XML nommé factur-x.xml (ou xrechnung.xml pour la variante allemande). L’XML est conforme au standard EN 16931 (modèle de données sémantique européen pour la facturation électronique).

Les profils Factur-X à connaître :

Pour la majorité des e-commerçants, le profil BASIC ou EN 16931 est le bon choix. Le profil MINIMUM ne suffit pas pour émettre des factures B2B déductibles. Pour l’e-reporting B2C, le profil BASIC WL peut être acceptable selon les spécifications DGFiP.

4.2 Bibliothèques PHP disponibles pour générer du Factur-X

Si tu développes ta propre solution (module PrestaShop custom, plugin WooCommerce, script CLI), plusieurs bibliothèques PHP existent :

Exemple d’intégration basique avec horstoeko/zugferd dans un contexte PrestaShop :


use horstoeko\zugferd\ZugferdDocumentBuilder;
use horstoeko\zugferd\ZugferdProfiles;
 
$document = ZugferdDocumentBuilder::CreateNew(ZugferdProfiles::PROFILE_EN16931);
 
$document
    ->setDocumentInformation(
        $order->reference,       // Numéro de facture
        "380",                   // Type "380" = facture commerciale
        new \DateTime($order->date_add),
        "EUR"
    )
    ->setDocumentSeller(
        Configuration::get('PS_SHOP_NAME'),
        Configuration::get('PS_COMPANY_VAT_NUMBER')
    )
    ->setDocumentSellerAddress(
        Configuration::get('PS_SHOP_ADDR1'),
        "",
        "",
        Configuration::get('PS_SHOP_CODE'),
        Configuration::get('PS_SHOP_CITY'),
        "FR"
    )
    ->setDocumentBuyer(
        $customer->company ?: $customer->firstname . ' ' . $customer->lastname,
        $customer->siret ?? null
    );
 
// Ajouter les lignes de produit
foreach ($order->getProducts() as $product) {
    $document->addNewPosition((string) $product['id_order_detail'])
        ->setDocumentPositionProductDetails($product['product_name'])
        ->setDocumentPositionQuantity($product['product_quantity'], "H87")
        ->setDocumentPositionNetPrice($product['unit_price_tax_excl'])
        ->setDocumentPositionLineSummation($product['total_price_tax_excl']);
}
 
$document->setDocumentSummation(
    $order->total_paid_tax_incl,
    $order->total_paid_tax_incl,
    $order->total_products,
    0.0,
    0.0,
    $order->total_products,
    $order->total_paid_tax_incl - $order->total_products
);
 
// Générer et sauvegarder
$document->writeFile('/path/to/facture-' . $order->reference . '.xml');
Ce code est une illustration simplifiée. En production, tu dois gérer les cas multiples de TVA (TVA 20%, TVA réduite 10%, 5.5%, exonérations), les remises, les frais de port, et les validations de données obligatoires avant génération. La bibliothèque horstoeko intègre un validateur XML — utilise-le systématiquement.

4.3 Intégration du Factur-X dans un PDF existant (cas WooCommerce)

Si tu utilises un plugin PDF existant dans WooCommerce, tu peux lui greffer la génération Factur-X en post-traitement : générer d’abord le PDF standard via le plugin, puis utiliser une bibliothèque comme setasign/fpdi combinée avec la génération XML pour embedder le XML dans le PDF et le convertir en PDF/A-3.

4.4 Connexion à une PDP : les APIs à connaître

La transmission à une PDP se fait généralement via une API REST. Chaque PDP a sa propre API, mais toutes exposent au minimum :

Les PDP immatriculées publient leur documentation API. Avant de choisir une PDP, vérifie :

5. Impacts SEO et performance à anticiper

5.1 La génération de Factur-X ne doit pas peser sur tes Core Web Vitals

La génération d’un fichier Factur-X côté serveur au moment de la validation d’une commande peut consommer significativement du CPU (notamment la conversion PDF/A-3 et la validation XML). Si cette opération est synchrone dans le processus de checkout, elle peut allonger le TTFB (Time to First Byte) de ta page de confirmation de commande, ce qui impacte ton LCP (Largest Contentful Paint) et ton INP (Interaction to Next Paint) — deux métriques Core Web Vitals cruciales pour le ranking Google.

La bonne pratique : asynchronisme systématique.

Action Scheduler est une bibliothèque de queue de tâches robuste, déjà présente dans WooCommerce. Elle persiste les tâches en base de données et les exécute via wp-cron ou un vrai cron système. Pour la génération de Factur-X, c’est exactement le bon outil : la tâche est déclenchée dès la commande, exécutée en arrière-plan sans impacter l’expérience utilisateur.

5.2 Sécurité et confidentialité : les factures ne doivent pas être indexées

Si tu stockes les fichiers Factur-X sur le serveur web (dans le répertoire de PrestaShop ou WordPress), assure-toi qu’ils ne sont pas accessibles publiquement. Une facture client exposée sans authentification est une fuite de données personnelles (RGPD) et potentiellement une faille de sécurité.

5.3 Structured data et facturation : aucun impact SEO direct, mais des bonnes pratiques

La facturation électronique n’a pas d’impact direct sur le SEO de tes pages publiques. Cependant, si tu utilises des données de commande pour alimenter des pages de confirmation ou des emails transactionnels, s’assurer de la cohérence des données (prix TTC, HT, TVA) est important pour la qualité globale du contenu que tu envoies à tes clients — et indirectement pour ta réputation de marque.

6. Checklist de mise en conformité : ce que tu dois faire maintenant

6.1 Audit préalable de ta boutique

6.2 Choisir ton architecture

6.3 Plan d’action technique

6.4 Points de vigilance réglementaires

7. Cas pratiques et configurations serveur

7.1 Configuration PHP recommandée pour la génération Factur-X

La génération de Factur-X en PHP nécessite les extensions suivantes :

Version PHP minimale recommandée : PHP 8.1. PHP 8.2 et 8.3 sont supportés par les bibliothèques actuelles. Évite PHP 7.x pour tout nouveau développement lié à la FE.

Mémoire PHP : la génération d’un PDF/A-3 peut consommer entre 32 et 128 Mo de mémoire selon la taille du document. Assure-toi que ton memory_limit PHP est au minimum à 256M sur les processus de génération de factures.

7.2 Hébergement mutualisé vs VPS : ce qui change

Sur un hébergement mutualisé, tu risques de ne pas avoir accès à toutes les extensions PHP nécessaires ni aux binaires système (ghostscript, par exemple). Tu risques aussi d’avoir des contraintes sur les tâches Cron et la mémoire PHP. Si tu es sur un hébergement mutualisé et que tu veux générer du Factur-X nativement, audite ton hébergeur avant de choisir ta solution technique. Sur un VPS ou un hébergement managé avec accès SSH (OVHcloud, PlanetHoster, Kinsta, etc.), tu as généralement toute la latitude nécessaire.

7.3 Mise à jour de PrestaShop : la question des versions

PrestaShop 1.7 est en fin de vie depuis juillet 2023. PrestaShop 8.x est la version stable actuelle (8.1 et 8.2 en 2025). PrestaShop 9.x est en développement. Si tu es encore sur une version 1.7.x, la mise en conformité FE est une raison supplémentaire de migrer vers PrestaShop 8.x — non pas parce que PrestaShop 8 gère nativement la FE, mais parce que les modules tiers compatibles FE seront développés en priorité pour les versions récentes, et parce que PrestaShop 1.7 ne recevra plus de correctifs de sécurité.

Questions Fréquentes (FAQ)

La réforme de facturation électronique s’applique-t-elle à un micro-entrepreneur e-commerçant ?

Oui, si tu es assujetti à la TVA. Les micro-entrepreneurs en franchise de TVA (chiffre d’affaires sous les seuils) ne sont pas concernés par l’obligation d’émission, mais ils devront potentiellement être capables de recevoir des factures électroniques si leurs fournisseurs leur en envoient à partir de septembre 2026. Il est conseillé de vérifier ton statut TVA avec ton expert-comptable.

PrestaShop sera-t-il un jour conforme nativement ?

À date, Prestashop SA n’a pas communiqué de roadmap officielle sur l’intégration native de la FE dans le core. Il est probable que la conformité passe par des modules partenaires plutôt que par le core, sur le même modèle que d’autres fonctionnalités réglementaires (RGPD, caisse enregistreuse, etc.). Surveille les annonces sur le blog officiel PrestaShop et les PrestaShop Day.

Quelle est la différence entre une PDP et le PPF ?

Le PPF (Portail Public de Facturation) est la plateforme publique gratuite gérée par la DGFiP. Il offre des fonctionnalités de base. Les PDP (Plateformes de Dématérialisation Partenaires) sont des opérateurs privés immatriculés qui offrent des services à valeur ajoutée : intégration API, archivage, workflows de validation, support dédié. Pour un e-commerçant, passer par une PDP via son logiciel comptable ou son module FE est généralement plus pratique que d’accéder directement au PPF.

Mon expert-comptable peut-il gérer la FE à ma place ?

Ton expert-comptable peut gérer la partie comptable et réglementaire (transmission à la PDP, archivage, e-reporting agrégé) via son propre logiciel. Mais la génération des données structurées à partir de ta boutique PrestaShop ou WooCommerce reste une problématique technique qui te revient. Il faut que ton système e-commerce transmette les bonnes données à ton expert-comptable, dans le bon format.

Puis-je continuer à envoyer des factures PDF classiques après la réforme ?

Pour les transactions B2B entre entreprises françaises assujetties à la TVA, non — les factures PDF non structurées ne seront plus acceptées. Pour le B2C, tu n’émets pas de facture électronique structurée mais tu dois transmettre les données d’e-reporting à l’administration. Les PDF classiques pourront subsister comme documents de synthèse pour le client, mais le processus fiscal sous-jacent devra passer par les circuits réglementaires.

WooCommerce est-il plus ou moins bien loti que PrestaShop pour la FE ?

Les deux sont à peu près au même niveau : ni l’un ni l’autre ne gère nativement la FE. L’écosystème WooCommerce est plus large, ce qui peut signifier plus de plugins disponibles, mais aussi plus de fragmentation et de risques de plugins non maintenus. PrestaShop bénéficie d’une communauté française plus structurée autour des questions réglementaires françaises.

Combien coûte la mise en conformité FE pour une boutique PrestaShop standard ?

Difficile de donner un chiffre unique, mais voici des ordres de grandeur : un module FE pour PrestaShop se situe généralement entre 200 et 800 euros en licence unique ou entre 30 et 100 euros par mois en SaaS. Un connecteur vers logiciel comptable peut être gratuit ou coûter entre 20 et 80 euros par mois selon l’éditeur. Une solution sur mesure (développement module custom + intégration PDP) peut représenter entre 2 000 et 8 000 euros de développement initial. À cela s’ajoutent les coûts de la PDP ou du logiciel comptable.

Qu’est-ce que le profil Factur-X « MINIMUM » et est-il suffisant pour mes factures B2B ?

Le profil MINIMUM contient les données obligatoires les plus basiques (identifiant, date, vendeur, acheteur, montant TTC global). Il ne contient pas le détail des lignes de produits ni la ventilation TVA. Il n’est pas suffisant pour une facture B2B déductible. Pour tes factures B2B, utilise au minimum le profil BASIC (avec lignes de détail) ou idéalement EN 16931 pour une conformité optimale.

Mon hébergement OVHcloud mutualisé est-il compatible avec la génération de Factur-X ?

OVHcloud mutualisé (offres Perso, Pro, Performance) intègre PHP 8.1+ et la plupart des extensions nécessaires (ext-xsl, ext-zip, ext-dom). Les tâches Cron y sont disponibles. La principale limitation sera la mémoire PHP (souvent limitée à 128 Mo sur les offres d’entrée de gamme) et l’absence de ghostscript. Si tu passes par une solution SaaS (module FE qui envoie les données à une API externe), ces contraintes ne s’appliquent pas — la génération du Factur-X est déportée chez le prestataire.

Comment tester que mon Factur-X est valide avant de le transmettre à la PDP ?

Plusieurs outils de validation sont disponibles : le validateur Kosit (validator.kosit.de), l’outil FeRD (disponible sur fnfe-mpe.org), et les sandbox des PDP elles-mêmes. La bibliothèque horstoeko/zugferd intègre aussi une validation XSD. Teste systématiquement sur des commandes réelles (pas seulement des données fictives) pour couvrir les cas limites : commandes avec remises, TVA multiple, livraison gratuite, avoir, etc.

Conclusion

La réforme de la facturation électronique n’est pas un problème purement comptable. C’est un projet technique à part entière, avec des implications sur ton architecture applicative, tes performances, ta sécurité et tes flux de données. PrestaShop et WooCommerce ne t’offrent pas de solution clé en main — mais les trois architectures décrites dans ce guide te donnent un cadre clair pour choisir la bonne approche selon ta situation. Le plus mauvais choix serait d’attendre. Commence par l’audit de ta boutique, choisis ton architecture, et commence à tester bien avant septembre 2026. Les entreprises qui s’y prendront à la dernière minute découvriront que les prestataires, les éditeurs de modules et les experts-comptables seront débordés — exactement comme lors des autres grandes réformes réglementaires françaises (RGPD, caisse certifiée, facture NF525). Prends de l’avance.


Quitter la version mobile