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

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 :

• L’e-invoicing (facturation électronique B2B) : toutes les factures émises entre entreprises assujetties à la TVA en France devront transiter par une plateforme agréée (PA) ou par le Portail Public de Facturation (PPF). La facture doit être dans un format structuré ou mixte (Factur-X, UBL, CII).
• L’e-reporting : pour les transactions B2C (ventes aux particuliers) et les transactions avec des entreprises non établies en France, tu n’émetras pas de facture électronique au sens strict, mais tu devras transmettre périodiquement à l’administration fiscale les données de transaction (montants, TVA, etc.) via une plateforme agréée.

1.2 Le calendrier de déploiement

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

• 1er septembre 2026 : obligation de réception des factures électroniques pour toutes les entreprises. Toutes les grandes entreprises et ETI devront émettre des factures électroniques.
• 1er septembre 2027 : obligation d’émission étendue aux PME et micro-entreprises.

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

• Le PPF (Portail Public de Facturation) : la plateforme publique gérée par la DGFiP, accessible gratuitement. Elle fait office d’annuaire des entreprises et de solution de transit pour les factures.
• Les Plateformes de Dématérialisation Partenaires (PDP) : des opérateurs privés immatriculés par l’administration, qui offrent des services à valeur ajoutée (archivage, réconciliation, intégration ERP). C’est vers eux que s’orientent la plupart des solutions SaaS.
• Les Solutions de Dématérialisation (SD) ou Solutions Compatibles (SC) : des logiciels intermédiaires (comptabilité, ERP, plugin) qui génèrent les factures au bon format et communiquent avec une PDP ou le PPF.

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 :

• Un module de synchronisation PrestaShop ↔ logiciel comptable (la plupart des éditeurs proposent leur propre module sur l’Addons Marketplace).
• Un logiciel comptable qui s’est déclaré compatible avec la réforme et qui dispose d’une connexion PDP ou PPF. À date, Pennylane, Sage 100, Cegid, Sellsy et quelques autres ont annoncé leur conformité.
• Une configuration correcte du mapping des données : SIREN de ton entreprise, numéro de TVA intracommunautaire, codes NAF, mode de paiement — autant de champs qui devront être correctement renseignés dans PrestaShop pour que la synchronisation soit propre.

Avantages :

• Pas de refonte de PrestaShop.
• Centralisation comptable et conformité RFE dans un seul outil.
• Solution éprouvée, support éditeur.

Limites :

• Dépendance à l’éditeur du logiciel comptable pour la mise à jour vers la conformité PDP.
• Coût mensuel SaaS à prévoir.
• Latence possible entre la commande et la facture électronique si la synchro n’est pas temps réel.

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.

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 :

• Le module se greffe sur le hook actionOrderStatusPostUpdate ou actionOrderInvoiceNumberFormatted de PrestaShop pour intercepter la création de facture.
• Il récupère les données de commande (produits, TVA, coordonnées client, numéro de TVA si B2B) et les formate selon le standard Factur-X (profil MINIMUM, BASIC WL, BASIC ou EN 16931 selon le niveau de détail requis).
• Il transmet ensuite le fichier à une PDP partenaire via une API REST.
• Il peut aussi gérer l’e-reporting B2C en agrégeant les transactions sur une période donnée et en les transmettant périodiquement.

Avantages :

• Facturation quasi automatisée dès la commande, sans intervention manuelle.
• Pas besoin de logiciel comptable tiers pour la partie e-invoicing.
• Solution centralisée dans PrestaShop, plus simple à maintenir si tu gères toi-même ta boutique.

Limites :

• Le module doit être activement maintenu par son éditeur à mesure que les spécifications de la réforme évoluent.
• Tu restes dépendant d’une PDP tierce pour la transmission réglementaire.
• Les modules disponibles sur le marché en 2025-2026 sont encore peu nombreux et peu matures — à évaluer avec soin.

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 :

• La commande est créée dans PrestaShop.
• Via une API ou un connecteur middleware (souvent basé sur un bus d’événements ou un ETL comme Talend, Boomi ou un connecteur custom), la commande est transmise à l’ERP.
• L’ERP génère la facture au format Factur-X et la transmet à la PDP.
• L’ERP gère également l’e-reporting agrégé.

Avantages :

• Cohérence totale entre ventes, stock, comptabilité et obligations fiscales.
• Mutualisation du connecteur PDP pour tous les canaux de vente (PrestaShop, marketplace, vente directe).

Limites :

• Complexité et coût d’intégration élevés.
• Nécessite un ERP déjà en place ou un projet de déploiement ERP.
• Pas adapté à une TPE ou à un indépendant.

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é :

• L’écosystème de plugins WordPress/WooCommerce est beaucoup plus fragmenté. Il existe des dizaines de plugins de facturation (WooCommerce PDF Invoices, Germanized, WCPDF, etc.) dont aucun ne génère nativement du Factur-X.
• WordPress repose sur PHP et une architecture de hooks (actions/filtres) similaire à PrestaShop, mais la gestion des données de commande est différente — particulièrement depuis WooCommerce 8.x et l’introduction du bloc de caisse (Cart and Checkout Blocks) qui modifie le cycle de vie des commandes.
• Les performances du stack PHP de WordPress sous forte charge sont un facteur à surveiller si tu ajoutes une couche de génération de Factur-X synchrone à chaque commande.

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 :

• Vérifie que le plugin de synchronisation est compatible avec les dernières versions de WooCommerce (8.x+) et avec les Blocks si tu les utilises.
• Le champ « numéro de TVA » client n’est pas natif dans WooCommerce — il faut soit un plugin dédié (WooCommerce B2B, WooCommerce EU VAT Number) soit un champ personnalisé bien mappé.
• La gestion des taxes dans WooCommerce peut être complexe si tu vends en multidevise ou vers plusieurs pays. S’assurer que les codes TVA sont correctement remontés dans le logiciel comptable est indispensable.

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.

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 :

• Génère-t-il du Factur-X (PDF/A-3 + XML EN 16931) ou seulement du XML standalone ?
• Quel profil Factur-X supporte-t-il (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) ?
• Dispose-t-il d’un connecteur vers une PDP immatriculée, ou se contente-t-il de générer le fichier localement ?
• Gère-t-il l’e-reporting B2C et la transmission périodique à l’administration ?
• Est-il maintenu activement par un éditeur français qui suit les évolutions réglementaires ?

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 :

• MINIMUM : données minimales obligatoires (identifiant facture, date, vendeur, acheteur, montant TTC). Pas suffisant pour la déductibilité TVA.
• BASIC WL : données au niveau en-tête, sans détail des lignes. Suffisant pour de nombreux cas B2C.
• BASIC : avec détail des lignes. Requis dans la plupart des cas B2B.
• EN 16931 (anciennement COMFORT) : profil complet conforme EN 16931. Recommandé pour la conformité totale.
• EXTENDED : superset de EN 16931, avec champs additionnels. Utile pour les intégrations ERP complexes.

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 :

• horstoeko/zugferd : bibliothèque PHP la plus complète pour ZUGFeRD / Factur-X, disponible sur Packagist. Supporte tous les profils. Utilisable via Composer : composer require horstoeko/zugferd.
• atgp/factur-x : port PHP de la bibliothèque Python de référence (rappdur/factur-x). Plus légère mais moins maintenue.
• Konek\Facturx : alternative française, moins documentée.

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');

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.

• Bibliothèque PDF/A-3 recommandée : horstoeko/zugferd gère aussi la création du PDF/A-3 final.
• Prérequis serveur : l’extension PHP ext-xsl (pour la validation XSD), ext-zip (manipulation du PDF/A-3), et idéalement ghostscript si tu fais de la conversion PDF vers PDF/A-3 sur le serveur.
• PHP minimum : 8.1. La génération de Factur-X en PHP 7.4 est techniquement possible avec certaines bibliothèques mais non recommandée.

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 :

• Un endpoint de dépôt de facture (POST avec le fichier Factur-X en multipart ou base64).
• Un endpoint de statut (GET pour récupérer le statut de traitement de la facture).
• Un endpoint d’e-reporting (POST pour transmettre les données agrégées B2C).

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

• Leur statut d’immatriculation DGFiP (liste publiée sur impots.gouv.fr).
• La disponibilité d’un sandbox de test.
• Les tarifs (à l’émission ou en abonnement).
• La présence d’un SDK PHP ou d’exemples d’intégration.

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.

• PrestaShop : utilise un job différé via une tâche Cron ou une queue de messages. Le hook actionOrderStatusPostUpdate peut déclencher l’insertion d’un enregistrement dans une table de queue personnalisée, traitée ensuite par un script CLI hors cycle HTTP.
• WooCommerce : utilise Action Scheduler (inclus dans WooCommerce) pour différer la génération. as_schedule_single_action( time(), 'generate_facturx_for_order', [ 'order_id' => $order_id ] ) est ton meilleur ami.

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é.

• PrestaShop : stocke les factures hors du répertoire /img/ et du répertoire racine web, dans un répertoire protégé par .htaccess ou hors du DocumentRoot.
• WooCommerce : utilise le répertoire wp-content/uploads/woocommerce_uploads/ qui est protégé par défaut via .htaccess sur Apache, ou via des règles Nginx équivalentes.
• Dans tous les cas : génère des URLs signées temporaires si tu dois permettre le téléchargement par le client.

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

• Identifie ta structure juridique : es-tu une entreprise assujettie à la TVA en France ? Si oui, la réforme te concerne.
• Détermine ton mix B2B / B2C : quelle proportion de tes ventes sont des ventes B2B (avec numéro de SIRET ou TVA acheteur) ? Cela détermine l’urgence de l’e-invoicing vs e-reporting.
• Recense ton stack technique : quelle version de PrestaShop ou WooCommerce ? Quel hébergeur ? Quelle version de PHP ? Quel logiciel comptable ?
• Identifie les champs manquants : est-ce que ton formulaire de commande B2B collecte le SIRET de l’acheteur ? Le numéro de TVA intracommunautaire ? Ces données sont obligatoires dans le Factur-X B2B.

6.2 Choisir ton architecture

• TPE / indépendant, volume faible : connecteur vers logiciel comptable SaaS compatible FE (Pennylane, Qonto comptabilité, etc.).
• PME, volume moyen, ressources techniques : module FE directement dans PrestaShop ou WooCommerce.
• Structure complexe, multicanal, ERP existant : architecture ERP centralisée.

6.3 Plan d’action technique

• Choisir et installer la solution technique avant fin 2025 pour avoir le temps de tester.
• Tester sur un environnement de staging avec des commandes réelles (B2B et B2C).
• Vérifier la conformité des fichiers Factur-X générés via l’outil de validation officiel de la DGFiP ou un validateur tiers (Kosit Validator, etc.).
• Tester la transmission à la PDP en environnement sandbox.
• Former les équipes opérationnelles (service client, comptabilité) aux nouveaux flux.
• Prévoir un plan de continuité en cas de défaillance de la PDP (la réglementation impose aux PDP des obligations de disponibilité, mais un plan B reste nécessaire).

6.4 Points de vigilance réglementaires

• L’archivage des factures électroniques doit être assuré pendant 10 ans (délai légal en France), dans un format qui garantit l’intégrité et la lisibilité.
• La mention « Facture électronique » ou l’indication du canal de transmission peut être requise sur les factures.
• Les avoirs et factures rectificatives doivent aussi être conformes au format Factur-X.
• Pour l’e-reporting B2C, la périodicité de transmission dépend de ta fréquence de déclaration TVA (mensuelle ou trimestrielle).

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 :

• ext-xsl : transformation XSLT pour la validation XSD.
• ext-zip : manipulation des archives ZIP (utilisées dans le format PDF/A-3).
• ext-dom : manipulation DOM pour le XML.
• ext-libxml : parsing XML.
• ext-mbstring : gestion des chaînes multibytes (noms avec caractères spéciaux).

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.