Bonjour Martin, pouvez-vous vous présenter brièvement et expliquer en quoi la réforme de la facturation électronique, telle que vous la vivez chez Iopole en tant que Plateforme Agréée, transforme concrètement les logiciels de gestion et les attentes des entreprises ?
IOPOLE est une Plateforme Agréée (PA) pure player de la facturation électronique, fondée en 2022. Notre particularité : nous n'adressons pas directement les entreprises finales, mais les éditeurs de logiciels de gestion, d'ERP, de caisse, de CRM, qui veulent proposer à leurs clients des services de facturation électronique en France et à l'international. Nous leur fournissons un socle technique et réglementaire, accessible par API, qu'ils intègrent soit en marque grise (leur logiciel devient Solution Compatible), soit en marque blanche (leur logiciel obtient lui-même le statut de PA immatriculée à la DGFiP).
Ce qu'on observe concrètement sur le marché, c'est un changement de paradigme pour les éditeurs. Jusqu'ici, émettre une facture était souvent synonyme de générer un PDF et l'envoyer par email. Demain, c'est envoyer un flux de données structuré, certifié, tracé, via une infrastructure réglementée. Avec la réforme, les clients attendent de leurs logiciels de facturation qu'ils assurent la conformité des factures pour eux. Cela change l'architecture des logiciels, les workflows internes, et le niveau de qualité des données exigé. Notre rôle est de faire en sorte que cette transformation reste la plus transparente et simple possible pour les éditeurs, afin qu'ils continuent à se concentrer sur ce qui les différencie : leur connaissance métier et l'expérience utilisateur qu'ils offrent à leurs clients.
Vous travaillez au quotidien sur Peppol et l’interopérabilité internationale : comment la généralisation de Peppol dans l’écosystème français de facturation électronique va, selon vous, obliger les éditeurs d’ERP et de logiciels de gestion à repenser leur architecture (modèle de données, workflows, gestion des statuts) ?
PEPPOL change fondamentalement la logique d'interopérabilité. Avant, les échanges EDI étaient des connexions bilatérales, négociées une par une entre partenaires. Avec le réseau PEPPOL, toute PA doit être atteignable depuis n'importe quelle autre PA du réseau. C'est une interopérabilité par défaut, qui oblige les éditeurs à travailler différemment à trois niveaux.
Sur le modèle de données d'abord : les formats structurés imposent une précision champ par champ. Un SIREN erroné, une raison sociale mal renseignée, une adresse de réception non initialisée dans l'annuaire du PPF, et la facture ne part pas. Cela force les éditeurs à renforcer la qualité des référentiels clients et fournisseurs dans leurs bases, ce qui est un bénéfice net pour tout le monde.
Sur la gestion des statuts ensuite : la réforme introduit des statuts de cycle de vie obligatoires, au minimum "déposée", "rejetée", "refusée", "encaissée", qui doivent être intégrés dans les processus comptables et financiers. Pour les éditeurs ayant l'habitude de gérer des workflows de validation de factures, c'est une adaptation à la marge. Pour ceux qui ne traitaient pas ces sujets en natif, c'est un chantier plus profond.
Sur l'adressage enfin : les éditeurs doivent permettre à leurs utilisateurs d'initialiser leurs adresses de réception dans l'annuaire du PPF et de renseigner les adresses électroniques de leurs clients pour le routage. C'est invisible pour l'utilisateur final, mais structurant pour l'architecture du logiciel.
Dans vos analyses sur LinkedIn, vous évoquez souvent des sujets très opérationnels comme l’adressage via le Peppol Directory ou la gestion des écarts d’arrondi côté ERP : pouvez-vous nous décrire un cas concret où la mise en conformité e-invoicing a obligé un client ou un éditeur à revoir en profondeur son logiciel de gestion ?
L'arrondi est un excellent exemple parce qu'il illustre un problème invisible jusqu'au jour où il bloque tout. Dans des secteurs comme l'industrie ou l'agroalimentaire, certaines transactions portent sur des volumes très importants avec des prix unitaires qui nécessitent plusieurs décimales de précision. Une variation minime par unité, multipliée par des millions d'unités, peut représenter des montants significatifs. Or les normes de facturation électronique encadrent strictement les règles d'arrondi : la cohérence entre le HT, la TVA et le TTC doit être mathématiquement vérifiable. Deux approches permettent de gérer ce sujet. La première consiste à reconstruire la facture à partir d'un prix unitaire très précis en HT, jusqu'à six décimales, pour garantir que les totaux restent cohérents après application de la TVA. La seconde consiste à jouer sur l'unité de vente : en ajustant le conditionnement, le lot ou l'unité de mesure, on absorbe mathématiquement les écarts de façon plus naturelle.
Autre sujet structurant pour les éditeurs : la vérification d'identité. Pour prévenir la fraude, la réforme impose de certifier que l'entité qui émet une facture est bien celle qu'elle prétend être. Il n'est pas question qu'un utilisateur puisse émettre ou recevoir des factures au nom d'une autre entreprise avec un RIB différent. Cela oblige les éditeurs et les PA à mettre en place des mécanismes de KYC/KYB, ce qui peut représenter un chantier non trivial selon leur architecture. Chez IOPOLE, nous fournissons un module d'onboarding complet qui intègre cette certification d'identité et la signature du mandat de réception pour l'annuaire.
Enfin, un cas très répandu : les logiciels de caisse. Ces outils ne géraient pas historiquement les obligations de e-reporting. Notre approche consiste à ne pas abîmer la conception produit de l'éditeur : la caisse nous envoie ses données au fil de l'eau, facturettes ou tickets Z, et c'est côté PA que nous gérons l'agrégation et la transmission à l'administration fiscale sur les bonnes périodes, selon le régime fiscal de chaque déclarant. L'éditeur garde la main sur son produit, nous absorbons la complexité réglementaire.
Iopole propose une brique "Peppol as a Service" en marque blanche destinée à d’autres Plateformes Agréées : qu’est-ce que cette approche change, en coulisses, dans la façon dont les éditeurs de solutions compatibles ou les intégrateurs conçoivent aujourd’hui leurs connecteurs de facturation électronique ?
Il faut bien distinguer les deux briques pour éviter toute confusion. Notre offre PA en marque blanche, c'est l'ensemble du socle technique et réglementaire : transmission des factures, e-reporting, cycle de vie, archivage légal, connexion au PPF, immatriculation DGFiP. C'est ce qui permet à un éditeur de devenir lui-même PA.
Notre offre "PEPPOL as a Service" est différente : c'est une solution 100% technique qui permet à un acteur de devenir Point d'Accès PEPPOL, sans la couche réglementaire que nous portons dans notre offre PA. Elle s'adresse à des acteurs de la facturation électronique qui gèrent déjà eux-mêmes la partie réglementaire, et qui ont besoin d'intégrer techniquement le réseau PEPPOL pour faciliter leurs échanges internationaux. C'est typiquement utile pour des acteurs qui ont une dimension européenne ou mondiale et qui veulent s'appuyer sur PEPPOL comme backbone d'interopérabilité, sans tout reconstruire. Cette séparation claire entre infrastructure réseau et conformité réglementaire permet à chaque éditeur de déléguer exactement le niveau de complexité qu'il ne souhaite pas gérer en interne.
Votre partenariat avec Koesio illustre l’articulation entre Plateforme Agréée (PA) et Solution Compatible (SC) : quels sont, d’après vous, les principaux malentendus ou angles morts que vous observez encore chez les DAF et les DSI lorsqu’ils projettent l’impact de la réforme sur leur parc de logiciels de gestion ?
Le cas Koesio est justement éclairant parce qu'il illustre la bonne approche. Koesio a développé Summeo, une solution de gestion destinée aux TPE et PME. Ils ont fait le choix de rester en position de Solution Compatible, en s'appuyant sur IOPOLE comme PA. Résultat : leurs clients disposent d'une PA dès aujourd'hui, sans avoir à faire eux-mêmes ce choix. La séparation est nette : Koesio se concentre sur l'expérience utilisateur et la valeur métier, nous gérons la conformité réglementaire dans la durée.
Le premier angle mort que j'observe chez les DAF et DSI, c'est de partir de la mauvaise question. On entend souvent "il faut choisir sa PA", comme si c'était la première étape. Ce n'est pas la bonne approche. La bonne première étape, c'est de cartographier ses flux de facturation existants, identifier quels logiciels sont impliqués, et vérifier si ces logiciels sont déjà PA ou Solution Compatible. Très souvent, l'ERP sectoriel le plus proche des problématiques spécifiques de l'entreprise est mieux placé pour porter la relation PA que le logiciel comptable ou la banque.
Le second angle mort, c'est de ne pas penser futur-proof. Les normes vont évoluer, en France avec les mises à jour réglementaires, en Europe avec ViDA à horizon 2030. Un éditeur qui souhaite devenir PA par lui-même doit anticiper que cela implique de structurer pour du long terme une veille réglementaire et technique, et de permettre à ses clients d'opérer au-delà des frontières françaises. Ce n'est pas juste une case à cocher, c'est un engagement dans la durée.
Le troisième angle mort, c'est la procrastination. L'intégration technique d'une API comme la nôtre par un éditeur, c'est une affaire de jours. Ce qui prend du temps, c'est l'analyse en amont : la cartographie des cas d'usage, la gestion des spécificités sectorielles, la mise à jour des référentiels. Et il y aura très certainement un goulot d'étranglement chez les éditeurs et les consultants pour les projets lancés en last minute. Les entreprises qui démarrent aujourd'hui arrivent sereinement. Celles qui attendent septembre 2026 pour se décider prendront des risques inutiles.
À l’horizon du 1er septembre 2026 et au-delà, comment imaginez-vous l’écosystème logiciel une fois la facturation électronique généralisée : va-t-on vers une standardisation forte autour de quelques référentiels (Peppol, formats de données, statuts de cycle de vie), ou au contraire vers une spécialisation accrue des ERP, PA et SC avec de nouveaux rôles à inventer ?
Sur le plan technique et réglementaire, l'horizon est balisé. La directive ViDA, adoptée par le Conseil de l'Union européenne en mars 2025, impose l'e-invoicing structuré pour les transactions B2B intracommunautaires à partir du 1er juillet 2030, avec PEPPOL comme réseau de transmission de référence et EN16931 comme standard de format. Vue de France, c'est pratiquement une extension de la réforme domestique au périmètre européen : nous avons intégré dès le lancement l'e-reporting et les standards PEPPOL, ce qui nous place en avance sur la plupart des autres États membres. L'investissement réalisé pour 2026 n'est pas à refaire pour 2030, il est à étendre. Mais cela suppose d'avoir choisi des partenaires PA capables de se pérenniser et d'évoluer avec ces obligations dans la durée.
Sur le plan du marché en revanche, la question est ouverte. On compte aujourd'hui plus de 110 PA immatriculées, avec des modèles économiques très différents. Certains acteurs historiques de l'ERP, de la comptabilité ou du banking voient dans la facturation électronique un produit d'appel pour capter des clients sur leurs offres principales. Plusieurs observateurs anticipent une contraction du marché à moyen terme, avec des rachats et des disparitions probables, parfois intégrés by design dans la stratégie de certains entrants.
Notre pari chez IOPOLE est différent : nous cherchons à permettre à un maximum d'éditeurs de porter eux-mêmes le service de facturation électronique. Parce que c'est la seule façon de couvrir l'ensemble des cas d'usage sectoriels, d'encourager la décentralisation de l'écosystème, et de préparer l'internationalisation de façon cohérente. La standardisation technique est inévitable et souhaitable. La diversité fonctionnelle et sectorielle l'est tout autant.
Pour conclure, quel message aimeriez-vous adresser aux DAF, DSI et responsables métiers qui hésitent encore à lancer leurs chantiers de mise en conformité : par où commencer et quelle erreur liée aux logiciels de gestion devraient-ils absolument éviter dans les prochains mois ?
Le message est simple : ne confondez pas la complexité technique et la complexité métier. La partie technique, s'interfacer avec une PA, intégrer les statuts de cycle de vie, gérer les formats, se résout rapidement avec les bons partenaires. Ce qui prend du temps, c'est ce qui se passe en amont : comprendre ses flux de facturation, identifier les cas d'usage spécifiques à son secteur, mettre à jour ses référentiels clients et fournisseurs, aligner ses équipes comptables, achats et informatiques sur les nouveaux processus, et pour les éditeurs Solutions Compatibles, accompagner et éduquer le client final.
L'erreur à éviter absolument, c'est de traiter ce chantier comme un projet informatique avec une date limite. C'est une transformation des processus Order-to-Cash et Purchase-to-Pay, avec une date limite. La différence n'est pas anodine : un projet IT se pilote en DSI, une transformation de processus se pilote au niveau de la direction financière.
Commencez dès maintenant par cartographier vos flux. Identifiez quels logiciels sont dans la boucle, vérifiez leur statut PA ou SC, et posez les bonnes questions à vos éditeurs. Pour les DAF et DSI d'éditeurs logiciels, la question stratégique est claire : avez-vous intérêt à porter et maintenir l'immatriculation en interne sur le long terme, ou à l'externaliser à un pure player spécialisé ?
La réforme est une opportunité réelle de fiabiliser les données et d'améliorer les processus. Les entreprises qui l'abordent de façon proactive en sortiront renforcées, avec une visibilité en quasi temps réel sur leurs créances et leurs dettes qu'elles n'ont pas aujourd'hui. Celles qui subiront la réforme à marche forcée auront investi autant d'énergie pour un résultat bien moindre.
Pour en savoir plus : https://www.iopole.com/