Pourquoi nous avons dû créer e.Invoicing Hub : le point de vue d'un éditeur de logiciel

Les Entrecodeurs sont une agence de développement qui édite aussi ses propres produits. Cette double nature explique e.Invoicing Hub mieux que n'importe quelle analyse de la réforme : plusieurs de nos produits émettent des factures, et nous maintenons par ailleurs des dizaines de logiciels métier que nous avons développés sur mesure ou repris en maintenance, dont beaucoup produisent les factures de nos clients. Quand la facturation électronique est devenue obligatoire, ce n'est pas un chantier qui est arrivé sur notre backlog. C'en est arrivé des dizaines, tous différents.

Nous n'avons jamais envisagé de devenir Plateforme Agréée : ce n'est pas notre métier et ça n'a jamais été un projet d'entreprise. Notre problème était beaucoup plus prosaïque — faire sortir des factures conformes depuis des logiciels que nous avions écrits, vers des plateformes que nous n'avions pas choisies.

Premier cas : nos produits, où la facturation électronique est une fonctionnalité

Quand un produit que nous éditons émet les factures de ses utilisateurs, la facturation électronique n'est pas une option d'intégration : c'est une fonctionnalité attendue du produit. Nos clients ne veulent pas sortir de leur outil pour aller déposer un fichier ailleurs, et ils ne veulent pas non plus que nous leur imposions une plateforme. Ils veulent cliquer sur « Envoyer » et que la facture parte au bon endroit.

Le problème côté éditeur, c'est que « le bon endroit » change d'un utilisateur à l'autre. Sur un même produit, un client est chez Pennylane, un autre chez une plateforme concurrente, un troisième a une filiale raccordée à un Access Point Peppol en Belgique. Développer un connecteur par destination, c'est multiplier dans le produit un code que personne ne nous paie pour maintenir, et dont chaque évolution de spécification déclenche une release pour tout le parc.

Second cas : les logiciels métier que nous avons développés ou repris

C'est la partie prestation d'agence, et c'est celle qui a fait pencher la décision. Nous maintenons des logiciels de gestion sur mesure — certains écrits par nous, d'autres hérités d'un prestataire précédent et repris en maintenance. Beaucoup facturent : c'est l'outil qui connaît les commandes, les contrats, les abonnements, donc c'est lui qui édite la facture. La réforme nous a mis devant une liste de dizaines de clients à raccorder, chacun depuis une base de code différente, vers autant de Plateformes Agréées.

Dans ce contexte, chaque raccordement traité « à la main » dans le logiciel du client, c'est un devis, un développement, une recette, et surtout un engagement de maintenance de plusieurs années sur un périmètre réglementaire qui bouge. Nous savions dès le premier chiffrage que le dixième client serait rentable et que le trentième serait un problème. Nous avions besoin d'une brique unique à brancher partout, quelle que soit la techno du logiciel en face — un développement sur mesure se raccorde alors en une intégration, pas en un projet de conformité.

Ce n'est pas l'éditeur qui choisit la plateforme, c'est le cabinet comptable

C'est le point que nous avons compris le plus tard, et le plus important. Dans les PME que nous équipons, la Plateforme Agréée n'est pas choisie par le dirigeant ni par son éditeur de logiciel : elle est choisie par le cabinet d'expertise comptable, qui a standardisé ses dossiers sur un outil. Dans notre parc, c'est très souvent Pennylane — immatriculée Plateforme Agréée à titre définitif depuis fin 2025 — parce que les cabinets y ont basculé leur production comptable bien avant l'échéance.

Concrètement : un client nous demande que ses factures arrivent dans Pennylane, parce que c'est là que son comptable travaille. Le client suivant a un autre cabinet, donc une autre plateforme. Et si le client change de cabinet, il change de plateforme, sans que cela ait le moindre rapport avec le logiciel que nous maintenons pour lui. Un éditeur qui code une intégration en dur vers Pennylane se retrouve donc avec un produit qui fonctionne pour une partie de son parc seulement, et qui redevient un chantier à chaque changement de cabinet comptable.

Une couche d'orchestration, pas une intégration de plus

Nous avons donc construit e.Invoicing Hub avec PPI Group, au sein d'Alliances Groupe : le logiciel se connecte une fois au Hub, et le Hub porte la connexion aux plateformes agréées — Pennylane comme les autres — ainsi qu'aux Access Points Peppol pour la Belgique et le Luxembourg. Pour nous, éditeur, cela déplace la dette au bon endroit : nous maintenons une intégration, pas un catalogue de destinations.

Les trois mécanismes qui font que le modèle tient, détaillés sur la page dédiée aux éditeurs de logiciel :

• Une API unifiée : la même intégration sert tous les clients du produit, quelle que soit la plateforme de leur cabinet comptable
• Un contrôle de conformité avant transmission : mentions obligatoires, format attendu par la plateforme destinataire, cohérence des montants et de la TVA — une facture rejetée n'est pas payée, et c'est l'éditeur qu'on appelle
• La correction par paramétrage : un écart de format récurrent se corrige par une règle de mapping posée une fois, sans release du logiciel

Ce troisième point est celui qui change la vie d'une agence. Un pays saisi « France » qui doit devenir un code FR, une date française qui doit devenir une date ISO, une TVA à 20 qui doit devenir un taux avec sa catégorie : traité dans le code, c'est un ticket, une release et un déploiement sur un logiciel client. Traité en paramétrage, c'est une règle posée le jour où le besoin apparaît, sans passer par notre planning.

Corollaire pour nos clients : comme les factures sont conservées dans le format du Hub, changer de plateforme agréée — parce qu'on change de cabinet comptable, par exemple — n'impose pas de reprendre l'intégration. C'était une condition de conception, pas un argument commercial : sans elle, nous aurions enfermé notre propre parc client.

Notre position frontalière a imposé le multi-pays dès le départ

Nous développons depuis Metz, à 45 minutes du Luxembourg comme de l'Allemagne, et très proches de la Belgique et de la Suisse — et nous intervenons au Grand-Duché avec PPI-Group. Nos clients ne vivent pas dans un seul régime : une maison mère en Moselle, une filiale au Luxembourg, un fournisseur belge. Un logiciel de facturation que nous maintenons pour un groupe comme celui-là doit émettre vers une Plateforme Agréée française, recevoir côté belge via Peppol depuis janvier 2026, et se préparer à l'échéance luxembourgeoise de janvier 2028 — alors que l'émission française pour les PME tombe en septembre 2027.

Un éditeur installé au centre de la France pouvait traiter la facturation électronique comme un sujet franco-français. Pour nous, c'était d'emblée un sujet multi-plateformes et multi-pays, avec des dates qui ne s'alignent pas. Cette contrainte nous a interdit de livrer une solution franco-centrée qu'il aurait fallu refaire deux ans plus tard, et elle explique pourquoi le routage par pays est dans le Hub plutôt que dans chaque logiciel client.

Ce que nous regardons quand une autre agence nous pose la question

L'arbitrage ne se joue pas sur le premier raccordement, qui est un chantier de quelques semaines. Il se joue sur la maintenance d'un parc. Les questions que nous nous sommes posées, et que nous reposons aux éditeurs et aux agences qui nous consultent :

• Combien de logiciels différents maintenez-vous qui émettent des factures, et sur combien de bases de code distinctes ?
• Combien de Plateformes Agréées différentes sont déjà présentes dans votre parc client, Pennylane comprise, et qui les a choisies ?
• Que devient votre backlog le jour où une plateforme durcit ses contrôles de conformité ?
• Un client qui change de cabinet comptable, donc de plateforme, vous impose-t-il un nouveau développement ?
• Avez-vous des clients avec une entité en Belgique ou au Luxembourg, donc trois calendriers à faire cohabiter dans le même outil ?

Si vous répondez à ces questions comme nous y répondions, la page éditeurs de logiciel décrit exactement la brique que nous avons construite pour notre propre parc — proposable en marque blanche sous votre identité, à 0,22 € HT la transaction, sans frais de mise en service. Le détail du projet explique l'architecture. Et si vous préférez partir de votre parc client plutôt que du produit, parlons-en : c'est par là que nous avons commencé.