Facturation électronique : prenez le module de l'éditeur, pas la dépendance

La réforme laisse le libre choix de la plateforme. Le module intégré de l'ERP, lui, vous en laisse un seul.

L'échéance est dans le calendrier. L'intégrateur de l'ERP propose le module de facturation électronique « déjà branché ». Le comité remercie. On signe. L'équipe qui raccorde déjà l'ERP aux autres applications n'est pas dans la pièce. Aucune autre plateforme n'est comparée. La sortie vers un autre opérateur, dans deux ans, n'est pas dans le contrat.

En résumé

En France, les factures B2B doivent transiter par une plateforme de dématérialisation partenaire (PDP) agréée. Le texte dit libre choix. Le connecteur natif de l'éditeur dit chemin unique. Prendre le module dans l'urgence est tenable. En faire l'architecture définitive, non. La réforme est aussi l'occasion de reprendre la propriété de vos processus de facturation, pas de la déléguer. Il faut une porte de sortie dès le premier contrat.

Ce que dit la réforme, ce que fait le connecteur

Le calendrier, les formats et le circuit officiel sont détaillés dans facturation électronique : définition et fonctionnement. La DGFiP impose un fichier structuré et le passage par une PDP. Elle n'impose pas celle de votre éditeur ERP. Le principe de la réforme, c'est de publier une norme et de laisser le choix du partenaire.

En pratique, l'éditeur vend un module « clé en main » avec le connecteur déjà dans la version. C'est plus simple qu'un appel d'offres. C'est aussi le moyen le plus court de transformer un marché ouvert en monopole de facto sur son propre parc. Une fois ce connecteur en production, demander une mise en concurrence pour la suite revient souvent à menacer l'accès. L'intégrateur n'est plus un fournisseur que vous mettez en face d'un autre. Il tient le tuyau.

Deux effets que le devis du module ne montre pas

Les cas tordus restent dehors. Avoir, facture d'acompte, multi-société, tiers avec plusieurs adresses d'envoi : le module couvre le flux standard. Le reste continue à vivre dans un fichier, une ressaisie, ou un développement que l'éditeur n'avait pas prévu. Cette ressaisie a le même coût que celui chiffré dans le coût caché de la saisie manuelle.

Vous sortez du marché. Une fois le connecteur natif en production, comparer une autre PDP coûte une reconnexion, une recette, parfois une montée de version. La concurrence que la réforme voulait protéger n'existe plus pour vous.

Ce n'est pas un module, c'est un raccord entre deux systèmes

Acheter le connecteur natif, c'est acheter le tuyau. Ce n'est pas acheter le flux. La facturation électronique se joue entre l'ERP qui émet et le référentiel qui dit qui est le tiers, avec quelle adresse, quel rôle. Deux équipes, deux chefs de projet, souvent une spec d'un seul côté. Le module arrive. La discussion entre les deux systèmes, elle, n'a pas lieu.

C'est là que les cas tordus apparaissent trop tard : des objets qui doivent partir ensemble, un code d'adressage qui change sans que le tiers bouge, une règle que personne n'avait écrite parce que chaque équipe connaissait la sienne. Le module ne documente pas ça. Il suppose le flux standard.

Les coûts qui n'étaient pas sur la ligne « module PDP »

• Une montée de version de l'ERP, posée comme prérequis, pas comme option.
• Un prestataire pour les flux associés : tiers, codes d'adressage, statuts, retours d'erreur.
• Des données supplémentaires à produire et à maintenir, que votre référentiel actuel ne porte pas.
• Des correctifs déployés en production pour suivre la plateforme, parfois sans recette métier.

Aucun de ces postes n'est malhonnête. Ils sont juste absents du premier devis.

Trois temps, pas un seul achat

• Court terme. Si l'échéance est trop proche pour un vrai choix, prenez le module de l'éditeur. Rester hors délai coûte plus cher qu'un connecteur imparfait.
• En parallèle. Faites lire la norme à quelqu'un de chez vous. Cartographiez ce que le module couvre et ce qu'il ignore. Posez un contrat de données : qui produit quoi, qui corrige, qui a le droit de changer le code d'adressage.
• À un ou deux ans. Remettez en concurrence. Vous avez alors la spécification, les volumes, et les cas tordus. Une PDP externe devient comparable, pas un saut dans le vide.

Confier la dématérialisation et la facturation au même prestataire doit rester transitoire. Si le contrat ne prévoit pas la sortie, la sortie n'existera pas.

Ne pas confier toutes les clés à une seule personne

L'éditeur n'est pas le seul point de concentration. En interne, un unique « pilote facturation électronique » qui a lu la norme et bâti une spec fonctionnelle fait le bon premier geste. Dès que la discussion devient la séquence entre deux applications, un profil uniquement haut niveau lâche. Il faut quelqu'un chez vous qui tient le schéma, pas seulement le planning.

L'éditeur peut vous vulgariser la norme. C'est confortable. C'est aussi le moyen de rester le seul à la connaître. Ce dernier kilomètre, la cinématique réelle, ne se sous-traite pas. C'est précisément ce qu'il a intérêt à garder flou.

Par où commencer

Listez vos cas de facturation réels, pas le flux de démo. Cochez ceux que le module de l'éditeur couvre sans développement. Le reste, c'est votre porte de sortie, ou votre dette. Une Mission Data & Intégration sert à poser ce contrat de données et à raccorder l'existant à la PDP que vous aurez choisie. Le premier échange, c'est un Appel découverte, pas un audit d'entrée.

BastionLab n'est pas une PDP. On ne vend pas le remplacement du module demain matin. On aide à ne pas transformer l'urgence de 2026 en dépendance de 2028.

Questions fréquentes

On est trop proche de l'échéance : on prend le module de l'éditeur ?

Oui, si le délai ne permet plus un vrai choix. Rester hors circuit coûte plus cher qu'un connecteur imparfait. Posez toutefois la sortie dans le contrat : formats d'export, délai de révocation, qui porte les flux annexes. Sans ça, l'urgence de 2026 devient la dépendance de 2028.

Quels coûts le devis du module ne montre pas ?

Quatre postes reviennent : une montée de version de l'ERP posée en prérequis, un prestataire pour raccorder les flux (tiers, codes d'adressage, statuts, retours d'erreur), des données que votre référentiel ne porte pas encore, et des correctifs déployés en production pour suivre la plateforme, parfois sans recette métier. Aucun n'est malhonnête. Ils sont absents du premier devis.

Un pilote interne qui a lu la norme, ça suffit ?

C'est le bon départ, pas le dossier. La spec fonctionnelle aligne le comité. Elle ne tranche pas l'ordre des flux, les objets à publier ensemble, ni l'absence de spec de l'autre application. Il faut aussi quelqu'un qui lit la séquence entre les systèmes, ou un binôme métier et technique. Sinon le module de l'éditeur devient l'architecture par défaut, faute d'alternative écrite.

On a déjà signé. Comment garder une porte de sortie ?

Cartographiez ce que le module couvre et ce qu'il ignore, cas par cas, pas sur le flux de démo. Faites lire la norme à quelqu'un de chez vous. Posez un contrat de données : qui produit, qui corrige, qui a le droit de changer un code d'adressage. À un ou deux ans, vous avez de quoi remettre une autre plateforme en face, au lieu d'un saut dans le vide.