Suivi de la réforme de la facturation électronique
Sommaire
Walid : bonjour et bienvenue sur Projets Libres, le podcast de LinuxFr.org, qui parle de logiciels libres, de données ouvertes et de communs numériques. Je suis Walid Nouh et aujourd’hui, je suis très heureux, j’ai avec moi trois invités avec qui on va faire un épisode de suivi sur la facturation électronique. Si vous voulez en savoir plus sur le sujet, je vous invite à aller écouter l’épisode numéro 1 de la saison 4. Dans lequel on avait abordé le sujet de la facturation électronique et ses implications sur la communauté de Dolibarr et sur la communauté de l’OCA, l’Odoo Community Association.
Et donc aujourd’hui, je suis ravi, avec moi, j’ai trois invités : Philippe Scoffoni, qui est président de l’association PDP Libre, on va vous en dire plus tout à l’heure, et membre de la communauté de Dolibarr, Maxime Kohlass, qui est fondateur de ATM Consulting et président de l’Association de Dolibarr. Et Alexis Delattre, qui est développeur Odoo chez Akretion et membre de l’OCA, l’Odoo Community Association.
Présentation des invités
Bienvenue à tous les trois. Je suis ravi de pouvoir faire un épisode de suivi avec vous, sur où on en est de ce magnifique sujet. Pour la présentation habituelle des invités, on va faire très simple pour Alexis et pour Philippe, si vous voulez en savoir beaucoup plus, je vous invite à aller écouter le premier épisode. Je vais leur laisser juste la parole pendant deux minutes pour qu’ils se présentent de manière un peu plus succincte. Et Maxime, écoute, toi, c’est la première fois que tu passes sur le podcast, alors bienvenue et je te laisse commencer par te présenter. Qui es-tu et comment est-ce que tu as découvert, à quel moment tu as découvert Dolibarr?
Maxime : merci beaucoup pour l’invitation. Moi, c’est Maxime Kohlass. Je suis le créateur de ATM Consulting depuis 2012, basé à Valence. On est intégrateur de la solution Dolibarr. On fait exclusivement du Dolibarr depuis tout ce temps. On est une équipe de 25 personnes et on intervient sur toute la France. Moi, j’ai découvert Dolibarr, je dirais, autour de 2010, dans ma première expérience professionnelle, où j’étais déjà associé avec un ex-collègue à l’époque, on était prestataire du service informatique de Veolia.
Il fallait qu’on facture nos prestations. J’ai découvert Dolibarr à ce moment-là, j’ai vu que c’était sympa. Et donc, deux années plus tard, quand j’ai voulu créer mon entreprise, le choix de Dolibarr a été vite fait pour intégrer cette solution open source.
Walid : ok, et tu connaissais le logiciel libre avant Dolibarr?
Maxime : oui, parce que dans ce premier métier de prestataire chez Veolia, on avait un gros projet tourné autour du CRM. Moi, je sortais tout juste d’études à l’époque. Et donc, pour pouvoir faire un peu de proof of concept [preuve de concept, POC] dans ce projet CRM, on s’était basé à l’époque sur SugarCRM, qui est un logiciel open source qu’on a testé un peu dans tous les sens. Pour voir quelles étaient les capacités du logiciel et voir si ça répondait aux besoins de Veolia à l’époque. Bon, la direction a choisi de partir sur un autre outil propriétaire, mais au moins tout le POC a été fait sur de l’open source.
Walid : ok, merci. Philippe, est-ce que tu veux te présenter rapidement ?
Philippe : oui, bonjour, merci pour cette nouvelle invitation. Philippe, aujourd’hui, je suis là avec ma casquette de président d’une association, PDP Libre. On prendra peut-être un peu plus de temps, tout à l’heure pour en parler. Je suis aussi intégrateur de Dolibarr via ma société OpenDSI, depuis 2012, aujourd’hui.
Walid : très bien. Et Maxime, de ton côté ?
Alexis : j’ai commencé l’open source avec le projet VideoLAN, dont le composant le plus connu est VLC Media Player. Quand j’étais étudiant. Et puis je travaille sur Odoo depuis 2008, d’abord pour ma société, et puis ensuite, en 2010, je suis devenu intégrateur Odoo, avec, quelques années plus tard, la création d’Akretion. Et dans l’Odoo Community Association, j’ai toujours été actif sur les modules qui touchent à la compta au sens large, c’est-à-dire la compta, la partie bancaire, facturation électronique, douane, et, du coup, naturellement, sur la réforme de la facturation électronique.
Dans mes faits d’armes, un peu sur le sujet de la réforme de la facturation électronique, j’étais même le premier à implémenter la norme Factur-X dans un logiciel de gestion. C’était à l’époque où la norme Factur-X était encore en version bêta. Et puis, un autre de nos faits d’armes, c’était qu’avec un de mes clients, on était les premiers à déposer une facture Factur-X sur Chorus Pro. C’était en 2018. Et voilà, à l’époque, on était vraiment au début de la norme Factur-X. Et puis, voilà, après, il y a eu la réforme. Et donc, je suis actif sur les développements des modules Odoo pour la réforme de la facturation électronique.
Les évolutions réglementaires
Walid : ok. On ne va pas refaire tout l’historique de la facturation électronique, par où ça passe, etc. Tout ça, je vous invite vraiment à aller écouter le premier épisode. On va se concentrer aujourd’hui sur qu’est-ce qui a changé depuis ce premier épisode, puisque maintenant, vous êtes tous en phase d’implémentation. Donc, la première chose que je voudrais, c’est qu’on explique, est-ce qu’il y a eu des évolutions réglementaires dans les derniers mois sur ce sujet-là et est-ce que ça vous a impacté d’une manière ou d’une autre?
Walid : Alexis, est-ce que tu veux commencer, peut-être?
Alexis : du coup, les principaux changements, c’est dans le PLF Projet Loi de Finance 2026, où, pour moi, il y a eu deux choses importantes dans ce projet de loi de finances. La première chose importante, c’est d’abord que c’était la dernière fenêtre de tir pour éventuellement changer le calendrier. Parce que, comme il est inscrit dans la loi, s’ils veulent changer le calendrier, il faut passer par la loi. Et donc potentiellement par le projet de loi de finances, c’était ça.
Finalement, le fait qu’ils n’aient pas touché au calendrier dans ce projet de loi de finances, c’était la confirmation que la réforme allait bien démarrer au 1er septembre 2026. Ils ont quand même la possibilité par décret de décaler la date de 3 mois par simple décret. Donc ça, c’était finalement une confirmation qui ne touchait pas au calendrier.
Deuxième chose importante dans le PLF 2026 : ils avaient décidé l’abandon du portail public de facturation, le portail public géré par Bercy [Ministère des finances français], qui devait permettre aux entreprises qui ne voulaient pas payer un prestataire privé de pouvoir déposer, recevoir, envoyer, recevoir leurs factures gratuitement. Le fisc avait décidé d’arrêter ce projet, probablement parce que c’était un naufrage logiciel en termes de développement. C’est ça qui s’est passé. Même s’ils ont eu un peu de mal à l’admettre.
Dans la loi, il était encore mentionné ce portail public gratuit. Donc, il fallait quand même enlever les textes de loi qui faisaient référence à ce portail gratuit parce qu’ils ne l’avaient pas fait dans le PLF 2025. Ils ont effectivement enlevé tout ce qui touchait à la solution gratuite fournie par l’État. Ensuite, il y a une autre chose importante du PLF 2026, c’est qu’à l’époque où il y avait le portail public de facturation, une entreprise qui ne faisait rien était attribuée automatiquement, par défaut au portail public de facturation pour recevoir ses factures.
Maintenant qu’il n’y a plus de portail public, une entreprise qui ne fait aucun choix et qui laisse passer la date limite, on ne peut pas lui envoyer une facture parce qu’elle n’est pas présente dans l’annuaire avec une plateforme agréée associée. Et donc ils ont introduit des amendes pour les entreprises qui ne feraient pas le choix d’une plateforme agréée avant le 1er septembre 2026. Il y a d’abord une mise en demeure de trois mois.
Et puis, passé ces trois mois de mise, en demeure, une première amende de 500 euros. Et puis, si, trois mois plus tard, vous n’avez toujours pas choisi de plateforme agréée, une amende qui est montée à 1000 euros. Donc des amendes pour forcer les entreprises à bien faire un choix de plateforme agréée. Normalement, on est censé le choisir avant le 1er septembre 2026. Et ça, c’est toutes les entreprises, quelle que soit leur taille, pour pouvoir recevoir des factures.
Walid : ok. Donc, finalement rien qui vous impacte directement dans les choix ou dans la direction que vous avez pris?
Alexis : non, sinon rien d’autre. Pour moi, je ne pense pas à d’autres choses, mais c’était quand même quelque chose d’important, parce qu’en cette période d’instabilité politique, on n’était pas à l’abri d’un retournement de situation. Finalement, il n’y a pas eu de retournement de situation sur la réforme de la facturation électronique. Il y a eu un retournement sur l’histoire de la certification des logiciels de caisse, qu’un sujet bien différent, où il y a eu un un virage à 180 degrés du législateur, mais pas sur la réforme de la facturation électronique, juste finalement la confirmation du calendrier. Et puis des trucs sur les amendes, etc. Pour s’adapter à l’abandon du portail public.
Walid : Maxime, Philippe, est-ce que vous avez des choses à rajouter là-dessus?
Maxime : non, non, c’est très complet. Non, ouais, merci, Alexis.
Walid : ok. Vous aviez rajouté, je pense que c’était Alexis, des questions liées aux achats en magasin ou en restaurant et qui ont besoin d’une facture.
Alexis : un professionnel qui fait un achat dans un magasin pour son entreprise : si c’est un tout petit montant, un ticket de caisse, ça peut suffire. Mais quand c’est un montant un petit peu significatif, normalement, on doit avoir une facture en bonne et due forme pour justifier la charge et aussi justifier la TVA déductible.
Dans ce qu’on appelle les cas d’usage de la réforme, par exemple, dans le cas d’un repas au restaurant pris dans le cadre professionnel, donc, par exemple, j’invite un client au restaurant ou quelque chose comme ça, ils précisent qu’en dessous de 150 euros, hors taxe, il y a une tolérance pour juste avoir un simple ticket de caisse, mais ils précisent qu’au-delà de 150 euros hors taxe, on est censé avoir une facture en bonne et due forme, et donc, du coup, que le restaurateur émette une facture électronique à destination de l’entreprise.
Et pour ça, il faut qu’ils connaissent l’adresse de facturation. C’est-à-dire qu’il faut qu’ils connaissent, la ligne d’annuaire qu’ils doivent nous facturer. On doit avoir au minimum, une ligne d’annuaire qui est basée sur le SIREN.
Mais les entreprises peuvent choisir d’avoir plusieurs lignes d’annuaire histoire de faire, par exemple, un routage des factures entre différents services ou c’est leur organisation interne après. Et donc, du coup, pendant une des conférences qui abordait justement ces sujets-là, des frais professionnels, il y a une personne de la DGFIP a dit dans cette conférence qu’il y aura la possibilité de montrer un QR code, que le professionnel puisse montrer aux commerçants ou aux restaurateurs.
Un QR code pour que le restaurateur puisse facilement scanner leur QR code pour obtenir l’adresse de facturation sur laquelle il doit adresser la facture. Donc moi, je trouvais ça intéressant. C’est la première fois que j’entendais parler de concrètement. Comment on pourrait facilement transmettre l’adresse de facturation rapidement et facilement quand on est physiquement en magasin.
Pourtant, j’ai bien potassé tous les différents documents des normes AFNOR, les documents sur le site des impôts, etc. Je n’avais pas entendu parler de ce QR code. Donc, du coup, j’ai été à la pêche, aux renseignements. Et puis là, j’apprends qu’en fait, oui, ils ont mentionné ça pendant la conférence, mais en réalité, ça n’a pas été normalisé jusqu’à présent. J’en ai parlé avec le président du Forum National de la Facturation électronique, Cyrille Sautereau, que j’ai la chance de connaître. J’en ai parlé avec une personne de GS1, c’est l’organisme qui a normalisé les codes barres dans la grande distribution que j’ai la chance de connaître aussi.
Donc, j’en ai parlé pour être sûr qu’il n’y avait vraiment rien qui était aujourd’hui sur la table. Et donc, ils m’ont tous confirmé qu’effectivement, c’était abordé à la conférence, mais qu’en fait, non, ce n’était pas encore spécifié, précisément.
Je me suis dit quand même, c’est vraiment fou. Il faut avancer sur ce sujet concrètement. J’ai fait l’exercice de proposer un standard en disant voilà, je propose quelque chose, venez donner votre avis, qu’est-ce que vous pensez de la norme. Je connais un peu les codes barres, d’une manière générale, les codes barres 2D, les codes barres, 1D, j’ai plusieurs clients dans le monde médical et dans le monde médical c’est assez courant. Les codes barres en deux dimensions qui, dans un même code barre, codent plusieurs informations : le code article, le numéro de lot, la date de péremption, tout ça dans un seul code barre.
Donc, là, c’est pareil, on veut que dans un seul code barre, il y ait à la fois, l’adresse de facturation de l’entreprise et peut-être potentiellement d’autres infos optionnelles, par exemple le matricule du salarié pour savoir qui a acheté ou des choses comme ça. Des infos qui pourraient, après se retrouver dans la facture que reçoit l’entreprise, par exemple.
Donc j’ai écrit une norme que j’ai inventée moi-même. Enfin, c’est tout simple, parce qu’un code barre 2D, ce n’est jamais qu’une chaîne de caractère qui est représentée sous un graphique. Donc, la question, c’est qu’est-ce qu’on met dans la chaîne de caractère pour codifier les différentes informations et transporter les différentes informations ? La seule qui est obligatoire étant la ligne d’annuaire de l’entreprise sur laquelle elle veut recevoir sa facture.
Et donc, voilà, j’ai essayé de lancer quelque chose en espérant que ça soit repris par le Forum national de la facturation électronique ou un des groupes AFNOR. Je ne sais pas si ça réussira à faire bouger les lignes, mais j’ai amené ma petite pierre à l’édifice, histoire de rentrer un peu dans le concret et de dire, voilà, allez, je propose quelque chose, dites ce que vous en pensez, proposez mieux, etc.
Mais j’étais finalement un peu déçu de voir que finalement, ce sujet concret de comment, en magasin, je peux transmettre mon adresse de facturation n’avait pas vraiment été correctement traité. Et en fait, quand on discute avec notamment les gens du Forum national de la facturation électronique, le scénario qui semble en tout cas plutôt évoqué aujourd’hui, ce n’est pas tant le fait de transmettre son adresse de facturation, c’est plutôt de dire que sur le ticket de caisse, voire à l’affichage en caisse, il y aurait un QR code.
Qu’après le passage en caisse, avec son téléphone, on viendrait scanner ce QR code. Ça nous amènerait sur un portail web du commerce. Et ce QR code, il ferait le lien avec le ticket de caisse. Donc, en gros, on retrouverait son ticket de caisse sur ce portail web. Et là, on pourrait indiquer l’adresse, le SIREN de son entreprise, sélectionner sa ligne d’annuaire sur laquelle on souhaite recevoir la facture.
Et finalement, sur cette plateforme web, on transformerait son ticket de caisse en facture électronique, qui sera ensuite mise. Mais ça sera un process qui aurait lieu après le passage en caisse, avec un QR code qui aurait été scanné sur le ticket de caisse, etc. Enfin, c’est un truc qui aurait lieu a posteriori. Bon, pourquoi pas ? Je veux dire, il y a différentes solutions, mais je trouvais qu’elle a aussi ses inconvénients, cette solution-là. Ce n’est pas la solution parfaite, non plus. J’ai essayé de faire un peu bouger les lignes. On verra si je réussis à faire bouger les lignes ou pas. On verra.
Avancement de l’implémentation sur Dolibarr
Walid : alors maintenant, rentrons un peu dans le dur du sujet, dans l’épisode 1. On avait expliqué qu’au niveau de Dolibarr et au niveau OCA, il y avait du travail à mettre en place pour implémenter ce processus de la facturation électronique. On avait parlé du financement, comment ça allait se faire, etc. Maintenant, j’aimerais savoir, puisque c’est en septembre, donc c’est bientôt, où est-ce que vous en êtes sur ce process d’implémentation? Au niveau de Dolibarr, Maxime et Philippe, où est-ce qu’on en est là-dessus? Peut-être Maxime, est-ce que tu veux commencer?
Maxime : avec plaisir. Aujourd’hui, on est en pleine phase de test du connecteur qu’on est en train de développer avec EsaLink. On a tout un groupe de travail qui se réunit toutes les deux semaines pour faire justement ces tests, s’envoyer des factures entre nous, recevoir des factures et mettre dans les deux sens. On a plein de choses encore à peaufiner, mais qui sont pour moi plus de l’ordre du processus métier fonctionnel. Une petite question qu’on se pose, de se dire, est-ce qu’une facture que j’ai reçue de la part d’un fournisseur, dans mon Dolibarr, j’ai le droit de la modifier ?
Est-ce que je dois changer des choses dessus ? Alors que les données ont été bien codifiées en entrée quand on l’a reçue depuis la plateforme. On n’est plus dans ce genre de questionnement-là et d’ajustement-là.
Walid : est-ce que tu peux expliquer qui est EsaLink, s’il te plaît ?
Maxime : oui, bien sûr. EsaLink est une plateforme agréée avec laquelle on est en train de travailler pour connecter Dolibarr à EsaLink. Ce ne sera pas la seule qui sera connectable. Il y en a d’autres qui vont suivre. Mais on a fait le choix de EsaLink avec plusieurs intégrateurs parce qu’ils nous ont accompagnés depuis le début. Ils nous ont montré leur sérieux et leur envie de travailler avec nous. Ils nous ont mis à disposition tout un tas de ressources techniques qui nous permettent aujourd’hui d’avoir un connecteur qui est en phase de test, mais qui est quasi terminé.
On a encore quelques choix à faire techniques, mais aujourd’hui, on arrive à émettre et à recevoir des factures dans les deux sens dans un Dolibarr en quelques clics. C’est aussi simple que d’envoyer une facture par mail aujourd’hui.
Walid : donc là, concrètement, ça se passe comment ? Je facture un client, automatiquement, cette facture est envoyée merci. À la plateforme EsaLink, pour être ensuite routé vers le système de facturation de son client.
Maxime : exactement, c’est ça. Après, tout réside dans le automatiquement, justement. C’est une des questions qu’on se pose. Est-ce qu’on automatise vraiment l’envoi ? Comme aujourd’hui, un utilisateur a l’habitude de cliquer sur « Envoyer par mail », demain, il clique sur « Envoyer sur la plateforme ». Est-ce qu’on force l’envoi à la validation ? Est-ce qu’on développe aussi une fonctionnalité qui permet d’envoyer en masse des factures sur la plateforme ? J’ai aussi pas mal d’utilisateurs qui ont des générations automatiques de factures la nuit : des factures récurrentes qui sont complètement automatisées.
Donc, celles-là, il faudra les déposer en automatique. On ne va pas demander aux utilisateurs de reprendre manuellement ces factures autogénérées pour les déposer à la main. C’est ces choix métiers dont je parlais, un peu fonctionnels, qu’il nous reste à faire et les petits automatismes. Et toute la partie du travail sur le connecteur, les échanges de flux et le traitement des flux, la mise à jour des flux, celui-là, il est en train d’être peaufiné, il est sur la fin.
Walid : et comment ça se passe ? Quand Dolibarr est le réceptacle de la facture de quelqu’un d’autre, qu’est-ce qui se passe à ce moment-là, à partir du moment où la facture est émise ? Elle arrive via la plateforme sur Dolibarr. Qu’est-ce qui se passe dans ce cas-là ?
Maxime : dans ce cas-là, la facture arrive aujourd’hui en l’état, elle arrive dans le système en tant que ce qu’on appelle nous, dans Dolibarr, une facture fournisseur brouillon. Il y a une action manuelle de la part d’un utilisateur qui permet de dire est-ce que j’accepte ou est-ce que je refuse la facture, pour pouvoir envoyer justement la mise à jour du statut sur la plateforme. Et au moment du refus, si c’est le cas, il y a un motif de refus qui doit être sélectionné, qui fait partie des 12 motifs disponibles définis dans la norme aujourd’hui.
Walid : est-ce que c’est un travail qui a été compliqué à faire, qui a été long ? Combien de temps vous avez passé à travailler sur ce module ?
Maxime : tu complètes ce que je dis, Philippe. Ça n’a pas été simple, effectivement, parce qu’on est une communauté avec plein d’acteurs, plein d’intégrateurs, plein de développeurs à droite, à gauche. On a chacun nos activités respectives. Et le travail communautaire aujourd’hui, autour de Dolibarr, il est très empirique, j’ai envie de dire. Chacun propose des améliorations. Il n’y a pas aujourd’hui une direction de projet avec des cahiers, des charges, des recettes, tout bien formalisé, etc., comme on pourrait le faire en entreprise, on va dire.
Pour organiser la communauté et même ce groupe de travail, c’était un bon boulot qui a été initié par Philippe, justement, au début, avec ses équipes. Mais le chef de projet principal de la communauté Dolibarr aujourd’hui, a pris à sa charge, justement, le développement du cœur du connecteur. Il a fait le gros du travail et maintenant, il s’est arrêté là-dessus. Il a laissé le groupe de travail prendre la suite, faire commencer les tests et ensuite compléter, corriger ce qu’il y avait à corriger.
Walid : déjà, la première question, c’est est-ce que vous pensez que vous serez prêt pour septembre 2026 ? Et si oui, est-ce que, dans cette version 1 du connecteur, vous implémentez tout ce qui est nécessaire, toutes les fonctionnalités de ce qu’on entend par réforme de la facturation électronique, telles que ces prévues pour être mises en place en septembre 2026 ?
Maxime : moi, je dirais oui, on sera prêts, bien sûr, pour septembre 2026. On est déjà en ordre de marche. Et après, sur le côté couverture fonctionnelle de la réforme, il manquera des cas, c’est sûr. Aujourd’hui on a traité les cas les plus courants parmi nos utilisateurs. Mais très clairement, je pense, je dis ça, je ne sais même pas s’il n’y a pas déjà quelqu’un qui a travaillé dessus, mais je pense au cas de la facture de situation, par exemple, pour le domaine du secteur du BTP, pour l’instant, elle n’est pas finalisée.
On a quelques cas comme ça, qui ne sont pas encore complètement traités, mais je n’ai aucun doute que ça va se faire dans la foulée.
Philippe : aujourd’hui, le module ne couvre clairement pas les 42 usages gentiment décrits dans la réforme. Ça va se faire un peu au fur et à mesure. L’objectif, c’est d’avoir quelque chose qui réponde au socle de la réforme. C’est déjà le cas. Maintenant, on sait qu’il va rester plein de trucs particuliers, de tous les cas d’usage à implémenter. Il y a plusieurs affacturages, le factor, etc. Ça fait partie du travail qui reste encore à faire. En tout cas, d’ici septembre, il n’y aura certainement pas tout. Il y aura les principaux cas d’usage qu’on aura peut-être déblayés. C’est encore un long chemin.
Walid : est-ce qu’il y a une… je ne sais plus comment on appelle, ça, pas une période de carence, mais est-ce qu’il y a une période de…?
Maxime : tolérance ?
Walid : oui, de tolérance. Je ne sais pas, est-ce qu’il y a quelques mois, les premiers mois, pour que tout le monde se mette bien en ordre de marche, etc.? Comment ça se passe?
Philippe : le projet est tellement ambitieux, je pense que l’État va être, entre guillemets, raisonnable. Je pense qu’à partir du moment où on démontrera qu’on s’est inscrit sur l’annuaire, qu’on envoie des choses bien faites, mal faites. Je pense qu’au démarrage, l’État se contentera déjà si les gens font, s’ils sont inscrits sur l’annuaire, si les ETI, les grandes entreprises envoient vraiment leurs factures. Elles ne sont pas très présentes de ce que j’ai cru comprendre actuellement sur les tests de la facturation électronique.
Voilà, je pense que l’État sera content. Je pense que 2026-2027, ça va rester encore une grosse période de transition avec, c’est à souhaiter une tolérance de l’État sur les erreurs, les problèmes et autres qui n’auront pas manqué de surgir.
Alexis : ce qu’il faut rappeler aussi, c’est que pour les PME, on parle bien des PME, c’est quand même une réforme en deux étapes. L’étape du 1er septembre 2026, c’est qu’il faut choisir sa plateforme agréée pour recevoir les factures. Mais l’obligation d’émettre les factures pour les PME, elle est à partir du 1er septembre 2027. Là, on a deux nouvelles obligations, le 1er septembre 2027, l’obligation d’émettre les factures en B2B et l’obligation du e-reporting.
Le e-reporting, c’est tout ce qui concerne la remontée des informations sur la facturation, ce qu’on appelle en B2C, vers les particuliers, donc tout ce qui est tickets de caisse ou des factures pour des particuliers qui ne sont pas un assujetti à la TVA.
Et puis, dans le e-reporting, il y a beaucoup plus que ça. Il y a aussi :
- la remontée des factures de facturation à l’export, que ce soit en intracommunautaire ou extracommunautaire.
- les factures des acquisitions intracommunautaires, quand j’achète hors-taxe dans l’Union européenne et qu’il y a un mécanisme qui s’appelle l’auto-liquidation de la TVA
- il faut remonter les informations de ces acquisitions intracommunautaires
- il faut remonter les informations des acquisitions extracommunautaires de prestations de services
- il faut remonter les informations des encaissements de ces factures clients si elles sont sous le régime de la TVA sur encaissement.
Donc, en fait, le e-reporting, c’est un gros morceau. C’est un peu ce que j’appelle la face cachée de l’iceberg. Et c’est le truc pas drôle, le e-reporting. Et ça, pour les PME, ça ne commence qu’à partir du 1er septembre 2027.
Pour les grandes entreprises et les ETI, par contre, tout démarre au 1er septembre 2026, à la fois, la réception des factures et l’émission des factures et le e-reporting. Pour eux, normalement, tout démarre en septembre de cette année. Petite chose quand même à garder en mémoire, c’est qu’entre les deux échéances, il y a l’élection présidentielle. Normalement, ce n’est pas censé influer sur ce genre de choses, mais il faut quand même garder ça en mémoire. Après, on peut spéculer sur ce qui peut se passer.
Moi, je peux vous donner mon avis personnel : je pense que si ça démarre bien en septembre 2026 et que ça ne fait pas trop de vagues et qu’il n’y a pas de gros problèmes qui viendraient survenir, je pense que ça ne sera pas un sujet de campagne présidentielle. Et que ça reste un sujet technique entre le fisc et les entreprises, et que ça ne viendra pas interférer dans le débat public.
Mais s’il y avait des vagues, des problèmes, des trucs qui viendraient un peu faire les titres de certains journaux, peut-être qu’à un moment, il y aurait des candidats qui se saisiraient du sujet en disant « c’est quoi cette folie administrative du e-reporting? » Parce qu’il y a encore un certain nombre de gens qui s’opposent au e-reporting. En disant que le e-reporting, c’est très lourd, etc. Ils ont tout à fait raison, d’ailleurs, de le faire.
Et du coup, après avoir, on ne sait pas ce qui peut se passer dans une campagne présidentielle et ce qui peut déboucher après. Donc voilà. Moi, j’espère que la réforme va démarrer, qu’il n’y aura pas des gros soucis qui viendront faire la une des journaux, mais on verra.
Maxime : moi, j’ajouterais juste, pour revenir au sujet, effectivement, de la tolérance, du démarrage. C’est que l’obligation, elle, est d’être, pour les entreprises, en capacité de recevoir dès septembre. Le fait qu’il y ait un connecteur qui permet de faciliter l’intégration de la facture dans le logiciel, l’ERP de l’entreprise, ça, c’est à l’état, ça en fiche un peu. À partir du moment où l’entreprise s’est déclarée dans l’annuaire et qu’elle est en capacité d’aller récupérer ses factures sur une plateforme quelle qu’elle soit, que la plateforme soit connectée par un flux automatisé avec l’ERP, ça, ça ne la regarde pas, c’est quelque chose qui va faciliter la gestion de l’entreprise en elle-même.
Alexis : oui, c’est-à-dire que là, quand on parle du cas des PME, finalement, le fait d’avoir un connecteur entre son logiciel comptable et sa plateforme agréée qu’on a choisie, en réception, c’est presque un luxe. C’est-à-dire que c’est évidemment le confort d’avoir la facture qui s’importe automatiquement, etc, ça fait gagner du temps, c’est précieux. On est tous là pour faire gagner du temps à nos utilisateurs. Mais finalement, quelqu’un qui aurait une vieille version, qui n’a pas été mise à jour et qui ne peut pas installer ce module, finalement, il ira sur le portail web de sa plateforme agréée et récupérera ses factures qu’il aura reçues.
Ce qui, finalement, fait déjà gagner du temps parce qu’aujourd’hui, quand on fait sa comptabilité, on se connecte sur le portail d’EDF pour récupérer sa facture d’électricité, on se connecte sur le portail d’Orange, SFR ou Bouygues ou Free, ou je ne sais pas quoi pour récupérer sa facture d’accès Internet, on se connecte sur le portail de son télépéage pour ses déplacements professionnels. Donc, finalement, on passe sa vie à se connecter sur plein de portails différents.
Et là, si tout marche, comme prévu, on aura sur sa plateforme agréée, finalement, un portail unifié, on reçoit toutes ces factures. Donc, déjà, ça, c’est un gain de temps en termes de réception. Et donc, si elle ne remonte pas en automatique, c’est déjà un gain de temps en soi. Après, là où ça change, la donne, c’est pour les PME à partir de septembre 2027, en émission.
Si on n’a pas un connecteur ou un module qui permet de relier son logiciel de gestion, son logiciel de facturation à sa plateforme agréée, là, ça veut dire pour chacune des factures qu’on émet, il faut la déposer à la main sur sa plateforme agréée et potentiellement qu’elle passe dans un système de reconnaissance de caractère, on sait que la reconnaissance de caractère, ce n’est jamais fiable à 100%, même si avec l’IA, ça fait énormément de progrès.
Et là, après, il faut vérifier qu’elle a bien tout reconnu, etc. Donc, là, pour le coup, il y a une vraie perte de temps par rapport à aujourd’hui. Aujourd’hui, on fait un envoi par mail ou quelque chose comme ça.
En fait, je pense que pour les PME, pour ne pas perdre en efficacité, c’est vraiment se dire d’ici à septembre 2027, d’avoir une mise à jour de son logiciel de gestion, son logiciel de facturation, pour que quand j’envoie les factures clients à mes clients, je puisse automatiser autant que possible la transmission à ma plateforme agréée pour que ça soit fluide l’envoi des factures.
Les deux implémentations sur Odoo
Walid : justement, toi qui avais la parole, maintenant, côté Odoo, côté OCA, où est-ce que tu en es déjà, toi?
Alexis : la première chose à comprendre, c’est qu’il y a deux initiatives, le choix entre deux implémentations. D’un côté, l’éditeur, la société belge Odoo SA, l’éditeur d’Odoo, s’est lancé dans un projet assez ambitieux de devenir lui-même plateforme agréée. Ils étaient déjà Access Point Peppol, ça depuis plusieurs années. Ils avaient dit l’année dernière : on va se lancer pour être nous-mêmes plateforme agréée. Ils ont eu le statut d’agréé sous réserve en janvier 2026. Et puis, il y a quelques semaines, ils ont obtenu leur agrément final.
Et donc, ils promettent, y compris à la fois sur l’édition Odoo Entreprise, et aussi sur la version Odoo Community, d’avoir les modules de facturation électronique. Et ils les promettent gratuits, y compris sur la version communautaire, enfin, open source et gratuite, en passant du coup par leur propre serveur et leur agrément de plateforme agréée. Voilà, donc ça, c’est, on va dire, l’implémentation de l’éditeur. Pour l’instant, ils ont leur statut de plateforme agréée. Ils n’ont pas encore fait de démonstration de l’implémentation concrète dans Odoo. Je crois qu’ils l’ont promis pour le mois de mai, donc je pense que ça va arriver. Mais pour l’instant, on n’a pas vu trop la couleur de façon très précise à ce jour.
Et puis, en parallèle de cette implémentation de l’éditeur, moi, j’ai promis depuis longtemps, j’avais dit que j’allais implémenter sous forme d’un module communautaire open source, la réforme de la facturation électronique en implémentant les API AFNOR, donc les fameuses API normalisées qui permettent de se connecter à toutes les plateformes agrées qui implémentent les API AFNOR. Ce n’est pas une obligation pour les plateformes agrées d’avoir des API AFNOR, mais en tout cas pour les plateformes agrées qui ont vocation à s’interfacer avec des logiciels de gestion des entreprises, c’est quand même la plupart qui ont promis des API compatibles AFNOR.
Et donc, moi, j’implémente ça. Donc, ça sera une implémentation alternative à celle de l’éditeur. Ça laissera le choix aux entreprises dotées d’Odoo de choisir l’implémentation des éditeurs ou celle sur laquelle moi, je travaille. Et où est-ce que j’en suis sur mon implémentation ? Sur la partie e-invoicing, sur le volet e-invoicing de la réforme, j’ai implémenté toute la gestion de l’annuaire, ça, c’est vraiment très finalisé. J’ai implémenté l’envoi et la réception de factures avec les cycles de vie.
Parce que les cycles de vie, c’est justement dire la facture est approuvée, la facture est en litige, la facture est refusée, la facture est mise en paiement. Il y a pas mal de choses qui permettent de partager le statut des factures entre clients et fournisseurs. Donc, là, j’ai aussi les cycles de vie qui fonctionnent. C’est encore un peu en version bêta. J’ai encore du travail, de finalisation et de peaufinage à faire. On sait que le travail de finalisation et de peaufinage, c’est souvent ce qui prend le plus de temps.
Mais en tout cas, ça fonctionne. Je sais envoyer, recevoir des cycles de vie, envoyer, recevoir des factures. Par contre, je n’ai pas commencé le volet e-reporting de la réforme, en sachant que notre clientèle, c’est des PME. L’obligation de e-reporting, c’est 1er septembre 2027 et pour les PME, ce n’est pas 1er septembre 2026. Donc, ce volet e-reporting, pour l’instant, je n’ai pas encore attaqué ce chantier-là. Je ne sais pas d’ailleurs, sur le e-reporting, sur Dolibarr, si vous avez fait comme moi, vous avez commencé par le e-invoicing et vous avez dit le e-reporting, on verra plus tard, ou si vous êtes déjà dans le chantier du e-reporting ?
Philippe : même choix, même choix, même stratégie, même état d’avancement.
Alexis : d’accord, très bien. Parce que le e-reporting c’est la partie pas drôle et pas simple de la réforme. Parce qu’en fait, sur le volet e-invoicing de la réforme, nous, et je pense que c’est pareil pour Dolibarr, on avait déjà la génération Factur-X, on avait déjà l’import Factur-X et l’import UBL.
Donc, finalement, le travail d’implémentation, ça a été surtout la gestion de l’annuaire, d’être capable de récupérer les lignes d’annuaire des entreprises, notamment pour celles qui ont plusieurs lignes d’annuaire, parce que là, il y a un enjeu de sélectionner la ligne d’annuaire sur laquelle on va facturer l’entreprise. Il y a eu le travail, évidemment, d’implémenter les API AFNOR pour s’interfacer avec ces API normalisées et pouvoir automatiser directement depuis le logiciel l’envoi et la réception à la fois.
Des factures, des cycles de vie et aussi le téléchargement des lignes d’annuaire pour une entité donnée. Et puis, il y a toute cette partie cycle de vie qui, pour moi, je pense pour vous aussi, Dolibarr, c’était aussi une découverte. Ça, pour le coup, il n’y avait pas ça jusqu’à présent. Sur Chorus Pro, les cycles de vie, ce n’était pas des fichiers XML normalisés, comme on le connaît dans le cadre de la réforme de la facturation électronique. Donc, il a fallu apprendre un petit peu à découvrir ces fichiers XML de cycle de vie, connaître un peu les subtilités de ça.
Moi, c’est assez récent, les cycles de vie, je l’ai implémenté il y a quelques semaines. J’ai commencé à avoir une première implémentation qui fonctionne seulement il y a quelques semaines et je suis en train un peu de finaliser l’implémentation des cycles de vie.
Walid : et là, donc, ce travail, il est fait, c’est un module OCA à part ?
Alexis : c’est un module communautaire, effectivement, que moi, je développe. Mais ce n’est pas un module officiel de l’éditeur. Il y aura vraiment le choix entre, d’un côté, l’implémentation de l’éditeur. Pour l’instant, on n’a pas trop vu la couleur. On sait qu’ils ont l’agrément, ils sont devenus plateforme agréée, mais ils n’ont pas montré la partie utilisateur, les modules cotés dans le côté serveur.
Walid : tu ne sais pas comparer pour l’instant ce qu’ils ont fait
Alexis : moi, j’ai pu faire des démonstrations. Pour l’instant, j’ai fait des démonstrations. C’est vrai que je ne les ai pas faites en public, je les ai plutôt faites en privé, les démonstrations de mon implémentation. D’ailleurs, je compte bien, dans les jours qui viennent, publier vraiment un screencast de l’état d’avancement, de mon implémentation.
On verra la récupération des lignes d’annuaire, la génération d’une facture, l’envoi, la réception, les cycles de vie pour dire la facture est en litige, le litige est résolu, la facture est approuvée, la facture est mise en paiement et de voir les cycles de vie qui s’échangent. Voilà, moi, mon implémentation, elle est basée sur les API AFNOR. Je la teste avec l’environnement de test de SuperPDP, un concurrent d’Esalink. Tous les deux sont des plateformes agréées qui implémentent les API AFNOR. Pour nos clients, on a choisi SuperPDP, mais normalement, comme c’est les API AFNOR, c’est censé être compatible avec toutes les plateformes agréées qui implémentent les API AFNOR.
Walid : pour que je comprenne bien sur le sujet, ce module-là, il fonctionne que tu sois sur la version entreprise ou que tu sois sur la version Community ?
Alexis : oui, normalement, le module va marcher sur les deux éditions.
Walid : ça marche. Tu seras prêt aussi pour septembre 2026 ?
Alexis : oui, de toute façon, là, on n’a pas le choix. Là, le but, c’est même d’être prêt avant, évidemment, parce qu’on ne peut pas livrer les trucs juste le jour de la deadline. Moi, l’objectif, c’est dans les prochaines semaines de finaliser l’implémentation des cycles de vie sur lesquels j’ai encore du peaufinage.
Je pense que déjà, on va l’installer en prod chez nous au mois de juin, pour que nous, on commence à l’utiliser en prod. On a la chance d’avoir le Forum national de la facturation électronique parmi nos clients, donc parmi les clients d’Akretion. Du coup, comme ils ont déjà activé leur adresse dans l’annuaire, on va pouvoir leur envoyer une vraie facture pour de vrai. Le but, c’est que nous, on puisse commencer à tester sur notre serveur Odoo à nous.
Et puis, nous, on a prévu de commencer la formation de nos utilisateurs fin juin, début juillet et après de commencer aussi à backporter le module sur les différentes versions de nous. Parce que là, je travaille sur la version 18, mais il n’y a pas que la version 18. J’ai promis de le mettre à disposition aussi sur la version 16. Et après, les versions impaires, ça sera si des gens m’en font la demande et me sponsorisent le portage sur des versions impaires. Mais je ne le ferai pas spontanément sauf demande express.
Walid : côté Dolibarr, qu’est-ce que vous avez prévu pour le testing ? Est-ce que vous avez prévu une phase de bêta publique ? Comment est-ce que vous comptez vous organiser de votre côté dans les semaines, mois à venir ?
Philippe : déjà, on joue entre intégrateurs sur du bac à sable pour l’instant, mais j’ai envie de dire, il n’y a pas grand-chose qui diffère, si ce n’est qu’on n’est pas sur l’environnement de prod en test, avec des vraies factures. Ça nous permet de rejouer des jeux beaucoup plus facilement. Donc, aujourd’hui, on est déjà, je dirais, dans cette phase-là active.
Moi, je compte bien de mon côté, je pense que chez mes confrères aussi, à très court terme, essayer de basculer tout ça en prod aussi, de s’embarquer sur l’annuaire et de dire peut-être en juin, quelque part, on va pouvoir aussi peut-être commencer à s’échanger des vraies factures entre intégrateurs de Dolibarr. On facture de temps en temps des choses. Et puis peut-être d’embarquer des clients. Moi, je sais que j’ai des clients qui sont demandeurs aujourd’hui de faire du test là-dessus.
Maxime : oui, parce que la difficulté, c’est que les ETI et les grandes entreprises qui sont dans l’obligation d’émettre à partir de septembre, on ne va pas les appeler pendant notre phase de test en disant « coucou Orange, coucou EDF, est-ce que vous pouvez nous envoyer des factures de test, s’il vous plaît, qu’on vérifie notre connecteur d’Odoo ? » Donc ceux-là, on les recevra pour de vrai en production à partir de septembre. Et ça va être rigolo. Donc, en attendant, on s’est organisé effectivement entre nous, dans la communauté, principalement avec les intégrateurs, pour pouvoir faire ces tests et s’envoyer des factures mutuellement les uns aux autres.
L’avancement de PDPLibre
Walid : ok. J’aimerais qu’on parle, dans l’épisode 1, on avait parlé de l’initiative lancée par Philippe et d’autres, qui s’appelle PDP Libre. J’aimerais, Philippe, que tu rappelles un peu quels étaient les objectifs, et où est-ce que vous en êtes de votre réflexion, implémentation ?
Philippe : les objectifs, à l’époque, quand on était très énervés, fin 2024, on s’est dit, puisque l’État ne le fait pas, on va le faire. C’était tellement ambitieux quand même. Alors, le projet n’est pas abandonné. Ça voulait dire quoi ? Ça voulait dire créer une PDP, mais basée sur une structure avec une gouvernance ouverte, etc.
Walid : donc, une plateforme agréée.
Philippe : une plateforme agréée, tout à fait. D’où l’acronyme de PDP Libre, qui veut dire projet de dématérialisation participative, puisqu’on ne va pas changer de nom. Construire une plateforme agréée, mais basée sur du code open source. C’est un projet qui n’est pas abandonné, c’est un projet long terme. De toute façon, si on ne le fait pas cette année, on pourra tout le faire en 2027, en 2028 ou en 2029.
Aujourd’hui, on bosse essentiellement sur du temps de bénévole. Sachant qu’à terme, s’il faut vraiment le faire, il y a des ISO 27001 à passer, devenir Access Point. C’est quand même des budgets derrière qui ne sont pas forcément très neutres. Est-ce que ça ira jusqu’au bout ? Je dirais à date, je ne sais pas le dire. En tout cas, il y a, au sein de PDP Libre, un groupe de travail là-dessus, sur la PDP communautaire, comme on l’appelle chez nous, qui a bossé sur les specs, qui a commencé à jeter des choses sur un dépôt.
En attendant, ce qu’on voulait, nous, c’était aussi un peu se sécuriser par rapport à la réforme. Il y a eu quelqu’un, en l’occurrence, c’était à l’époque Aurélien Bisotti, qui a pris son baton de pélerin et qui est allé toquer à la porte à l’époque des 80-90 PDP. On a fait un peu le filtre en amont en se disant, avec qui on va travailler, pour essayer de voir comment on pouvait mettre en place un achat groupé, quelque part. L’idée, c’est de se dire, on est tous des petits, si on y va séparément, potentiellement… alors, à l’époque, il n’y avait pas encore l’offre de Super PDP, je vais revenir là-dessus après.
L’idée, c’était effectivement de trouver une plateforme agréée, d’en sélectionner une qui corresponde à un certain nombre de nos critères, une société basée en France, de taille humaine avec qui on puisse discuter, etc. Et c’est dans ce contexte-là que j’ai rencontré Esalink, qui à l’époque, c’est l’une des rares, nous a dit tout de suite « banco, on vous ouvre nos API » et qui ne nous demandait pas 20 ou 30k pour accéder à leur bac à sable.
Alexis : il y a vraiment des gens qui ont demandé 20 ou 30 k pour accéder au bac à sable.
Philippe : ah oui,
Alexis : c’est fou.
Philippe : oui, voilà. Donc, entre ceux qui ne répondaient pas, ceux qui disaient oui, mais non, mais on n’est pas tout de suite, bientôt, etc. On s’est retrouvés, puis ils ont été assez volontaires et très « proactifs ». Il fallait qu’on commence à développer. Ça nous a permis en tout cas de commencer à travailler avec eux sans qu’ils nous demandent rien en contrepartie. Effectivement, entre-temps, il y a Super PDP qui est apparu avec son offre, je l’ai dit, un peu à la Free, avec le prix cassé. Malgré tout, nous, donc on a continué dans la démarche qu’on avait initiée.
Ce qu’on voulait, c’était sécuriser aussi la relation contractuelle entre PDP Libre, aujourd’hui, OCA, c’est essentiellement des intégrateurs, des plateformes SaaS. Il n’y a pas que des gens de Dolibarr. Il y a des gens de Dokos, des plateformes SaaS, des intégrateurs Odoo communautaires, Community, aussi. Il y a un panel assez large, entre guillemets. Des plateformes SaaS, propriétaires aussi, qui, elles aussi, étaient à la fois intéressées par l’approche communautaire, mais aussi par la fois mutualisation. Mutualisation un peu du risque aussi vis-à-vis de la réforme et d’un acteur à qui on va confier nos factures et à qui on va confier les factures de nos clients directement. Il y avait un besoin, un peu de sécuriser.
Donc, la démarche de PDP Libre aujourd’hui, c’est un peu un mix de tout ça qui nous a amené aujourd’hui, donc côté PDP Libre à contractualiser avec Esalink sur un ensemble de garanties contractuelles. On a passé beaucoup de temps à négocier, revoir toutes les clauses contractuelles, tous les engagements en termes de niveau de service, de support, de temps de réponse, voilà pour que, effectivement, on puisse déjà avoir une première offre, alors, certes, qui a un coût, par contre, derrière, on a des SLA, des niveaux de garantie, des engagements sur le support qui sont forts et qui, pour pas mal d’intégrateurs et de plateformes, était importante.
Donc là, on est parti là-dessus. Ça ne veut pas dire que tous les membres de PDP Libre vont utiliser les Esalink. En fait, on va être assez ouverts, puisque finalement, à l’arrivée, on avait les Esalink et Super PDP. Super PDP, c’était plus compliqué de contractualiser parce qu’il y avait une question de modèle économique, quelque part, avec le prix plancher qu’ils font aujourd’hui, c’est compliqué derrière de pouvoir, nous côté PDP Libre, arriver à financer une mutualisation, mais qui, finalement, avec ces tarifs-là, n’a pas tellement de sens.
Donc, en fin de compte, aujourd’hui, on est plus dans une situation où, quelque part, on va router à la fois les gens vers Esalink ou Super PDP en fonction de leurs besoins, si on prend le cas que je connais bien de Dolibarr aujourd’hui, le connecteur de Dolibarr est compatible à la fois Esalink et Super PDP, les deux sont implémentés.
Je pense que ça ne répondra pas aux mêmes besoins. Je pense qu’un utilisateur de Dolibarr, qui veut être totalement autonome, comme on en a beaucoup et énormément aujourd’hui, prendra le module communautaire, il l’installera, il ira ouvrir son compte chez Super PDP, récupérer ses identifiants et il vivra sa vie. Pour des structures qui veulent être accompagnées ou des intégrateurs qui veulent tenir la main à leurs clients, Esalink correspondra peut-être probablement mieux, parce que je sais que, derrière, j’aurai accès au support en ligne directe, qu’ils auront X heures pour me résoudre des problèmes quand mon client ne pourra plus envoyer ses factures et me gueulera derrière au téléphone.
C’est une forme d’assurance, de mutualisation du risque entre intégrateur, plateforme. Voilà un petit peu le choix. L’histoire dira si c’était un bon ou un mauvais choix. En tout cas, pour l’instant, pour ceux qui ont choisi cette option-là, on est plutôt serain.
Walid : donc, PDP Libre, c’est une association. Vous êtes combien d’adhérents ?
Philippe : loi 1901, oui.
Walid : vous êtes combien d’adhérents pour l’instant ?
Philippe : alors, elle est structurée avec deux collèges. On a créé, effectivement, dans le cadre de cette mutualisation, via une contractualisation. Il y a un collège distributeur dans lequel on pourra adhérer si on veut, entre guillemets, profiter du contrat qui a été négocié entre les Esalink et PDP Libre. Il y aura un contrat entre PDP Libre et ses membres distributeurs qui seront autonomes pour gérer leurs clients, les connecter à leur logiciel de gestion, etc.
Et puis, il y a un collège utilisateur, si on veut participer à la gouvernance, un peu de l’association, si on veut participer aux travaux autour de la PA communautaire, etc., apporter sa pierre, on pourra aussi adhérer à l’association. Mais dans un premier temps, l’association n’a pas vraiment les moyens de proposer, de faire du service ou autre. Ça viendra peut-être, mais à court terme, c’est un peu compliqué.
Walid : Maxime, est-ce que tu as des choses à rajouter de plus ?
Maxime : non, je confirme un peu tout ce qui a été dit avec Philippe. L’objectif de PDP Libre, le fait d’avoir une alternative. Pour le coup, moi, en tant qu’intégrateur, mes clients me confient leur ERP parce que je les accompagne. Ils vont me confier de la même manière l’intégration de ce connecteur de facturation électronique. On a vraiment deux populations distinctes d’utilisation, notamment chez Dolibarr. Ceux qui se débrouillent un peu tout seuls avec le Dolibarr communautaire et donc les modules qui vont avec.
Alexis : moi, j’avais une question parce que du coup, vous avez l’expérience de vous interfacer à la fois avec Super PDP et Esalink en utilisant les API AFNOR. Alors, l’API AFNOR, normalement, la promesse, c’est que ça soit le même code qui puisse échanger avec l’un comme avec l’autre. Est-ce que dans les faits, du coup, vous avez quand même des petits trucs à changer quand vous basculez, quand vous disiez Super PDP ou Esalink, et quel genre de choses, à quoi ça touche, les changements à opérer quand on passe de l’un à l’autre ?
Finalement, est-ce que la promesse des API AFNOR est tenue finalement ou est-ce que quand même dans les faits, il y a des petits if dans le code, if Super PDP, alors cette balise est obligatoire ? C’est un peu ce genre de truc que je pourrais vous dire après mon expérience, mais par rapport à l’API AFNOR, vous avez de l’expérience, moi, je ne l’ai pas.
Maxime : je pense qu’on ne pourra pas répondre, je ne sais pas toi, Philippe, tout de suite, parce que, justement, avec Philippe, on s’est beaucoup concentré sur le testing et la partie Esalink, basée sur ce connecteur commun, qui est d’ailleurs open source [voir sur github], lui aussi. Et ce n’est pas nous qui, directement, avons codé la partie connecteur Super PDP. Alors, non, seulement Philippe et moi, je pense qu’on ne met pas beaucoup les mains dans le code, mais en plus, on n’a pas eu à le faire sur les deux en parallèle. Maintenant, moi, vu de ma fenêtre, le connecteur qui a été développé pour Dolibarr, il est très générique.
Oui, j’ai une classe de connexion différente, une pour Ezalink, une pour Super PDP, mais derrière, tout le flow métier est le même. Après, je ne sais pas dans quelle mesure les API d’Esalink et les API de Super PDP sont différentes, mais pour moi, la partie normalisation AFNOR, elle est entre la PA et les autres PA. C’est eux qui nous mettent à disposition le format Factur-X qu’on décode, et nous, on se base là-dessus pour récupérer les données. Je pensais à l’interopérabilité quand je parlais des échanges entre les plateformes, mais on n’a pas eu de différence de fonctionnement entre les deux systèmes.
Philippe : quand on a lancé le développement, c’était un prérequis. On s’est appuyé notamment sur l’expérience qu’avait un des intégrateurs CAP-REL, qui avait développé le module Peppol pour la Belgique, où là, il y a autant d’access points, avec presque autant d’API, etc. Donc, on s’est appuyé sur son expérience.
Sur le module de connexion pour Dolibarr, il y a une classe d’abstraction qui est complètement générique par rapport à l’API AFNOR. Et après, effectivement, il y a une surcouche de code. J’avoue qu’effectivement, je n’ai pas regardé s’il y avait eu énormément de codes rajoutés, d’écarts entre les deux. Il faudrait regarder les deux classes. Il faudrait voir la classe de Super PDP, si elle est conséquente ou pas. C’est facile, j’avoue que je n’ai pas fait l’effort intellectuel, mais je pense que ça ne doit pas être très compliqué.
Maxime : les deux connecteurs semblent à peu près identiques, en tout cas en termes de lignes de code. Mais les connecteurs Esalink et Super PDP, comme je disais, traitent les API mises à disposition par ces deux plateformes-là. Après, dans les deux cas, comme tu dis, il y a le format Factur-X, notamment, et puis mc2i, qui est décodé par d’autres classes abstraites.
Walid : et toi, Alexis, avant qu’on finisse, quelle est ton expérience là-dessus ? Tu voulais dire un mot là-dessus ?
Alexis : moi, je ne l’expérimente qu’avec l’API AFNOR de Super PDP. Les seules petites difficultés que j’ai rencontrées, par exemple, c’est que, notamment sur les cycles de vie.
Je n’ai eu globalement aucune difficulté sur la partie annuaire. Et puis la partie envoi, réception des factures. Sur les cycles de vie, j’ai été confronté à des petits soucis où, par exemple, certains champs que moi, je n’avais pas renseignés dans mon XML parce que dans les specs, le champ XML était marqué comme étant facultatif, en tout cas, pour l’échange entre l’entreprise et sa PA. Parce que le champ, potentiellement, il peut être, dans certains cas, obligatoire, dans certains cas, entre la PA et le fisc. Et eux, ils avaient dit que le champ était obligatoire. Moi, je ne l’avais pas renseigné, ça faisait une erreur.
Et puis, comme le message d’erreur n’était pas toujours hyper explicite sur exactement quelle balise bloquait, ils m’ont donné un petit coup de main pour me dire que cette balise-là, effectivement, chez nous, elle est obligatoire. En fait, ce n’était pas dans l’API AFNOR elle-même, c’est dans les fichiers XML, quelles sont les balises obligatoires ? Quelles sont les balises facultatives ? Il y en a qui mettent la barre un peu plus haut, des balises facultatives qui, en fait, dans les faits, sont obligatoires. Sinon, on se prend une erreur quand on essaye d’envoyer le fichier XML.
J’ai eu deux petits trucs comme ça. Ce n’était pas très difficile à corriger. Sinon, j’ai trouvé que cette API AFNOR était plutôt bien conçue. En tout cas, j’étais agréablement surpris par l’API AFNOR. Et c’est vrai que dans le monde, Peppol, il n’y a pas de normes d’API entre l’entreprise et son point d’accès Peppol. Et finalement, nous en France, il y a eu cette initiative de l’API AFNOR. Je crois que c’est vraiment à souligner parce que quand il y a eu l’abandon du portail public, on s’est dit : « il va falloir implémenter les API de différentes plateformes agréées ». Il y a eu cette initiative d’API AFNOR, c’était vraiment une bonne nouvelle.
Walid : on arrive à la fin. Avant de se quitter, j’aimerais vous laisser à chacun, si vous voulez, un mot de la fin, les faire passer. Un message avant qu’on se quitte aux auditrices et aux auditeurs du podcast, et qui utilisent un ERP Dolibarr ou un ERP Odoo avec le module OCA. Maxime, est-ce que tu veux commencer ?
Maxime : petit mot de la fin, je dirais qu’il va falloir prévoir un épisode 3 de podcast au cœur de l’été pour pouvoir justement dire dans quelle mesure on est dans les starting-blocks. Et prendre la température qui crèvera les plafonds. Je suis plutôt confiant effectivement sur la suite, par rapport à notre capacité, de toute façon, à répondre aux besoins clients et à pouvoir, comme je disais tout à l’heure, peaufiner et améliorer le tout pour que, je vais bien aimer ta formule, Alexis, de dire que notre job, c’est de faire gagner du temps à nos utilisateurs.
On va être forcément là pour ça. Je suis très confiant là-dessus, que septembre ça va être une bonne phase de test avec des flux un peu limités. Et qu’on va monter en puissance sur tout le début 2027.
Walid : Philippe ?
Philippe : j’attends effectivement presque avec impatience septembre 2026, ou terreur, ça dépend. Ça dépend des matins, si j’ai bien dormi ou pas. Tu parlais tout à l’heure, Alexis, du cycle de vie, de ces petites infos qui passent chez une PA, mais pas chez une autre. J’attends de voir moi aussi quand les choses vont s’échanger entre les PA, que les PA vont dire : « oui, mais moi non », parce qu’au niveau des contrôles, des documents, de la conformité et autres.
Pour avoir posé la question, certains m’ont dit : « oui, nous, on s’est basés sur les schématrons, qui sont un peu les guidelines de contrôle. D’autres, nous, on a refait des contrôles à nous. » Oui, ok. On verra bien ce qui se passe. Voilà. Donc, j’attends un peu quand même de voir comment la machine va tourner.
Mais voilà, on sera sur des volumes raisonnables. Ce ne sera pas des gros volumes tout de suite si toutes les ETI et GE font bien leur boulot dans l’émission. Quelques millions de factures qui vont circuler. Ramené à l’échelle d’une entreprise, ça ne fera pas non plus, si on n’est que sur de la réception, probablement de gros volumes. Donc ça permettra de voir déjà un petit peu comment la chose se passe. Et puis, voilà, pour les clients qui ont des cas pas très compliqués, je leur suggérerais aussi bien d’envoyer leurs factures, même s’ils ne sont pas tenus, ce qui reste possible aussi.
Walid : ok. Alexis, ton mot de la fin.
Alexis : oui, nous, on s’attend évidemment à des mois assez intenses, jusqu’au démarrage. Et même après, parce qu’on sait que la phase de démarrage, c’est là où on va avoir les vrais cas dans la vraie vie et on va devoir faire encore des ajustements et des mises à jour.
Moi, ce que je vois un petit peu avec cette réforme, c’est que les entreprises qui auraient pu être sur des versions assez anciennes et qui n’étaient pas assez sensibles à la nécessité de ne pas s’enfermer dans le passé sur des anciennes versions d’Odoo, où je pense que c’est le même problème sur… tous les logiciels, de dire : « non, je ne veux pas faire de mise à jour, je veux rester sur ma version, elle marche bien, ça coûte du temps, donc de l’argent de faire ces mises à jour. »
Là, effectivement, quand on a des sujets comme ça, où on a besoin d’avoir ces nouveaux modules pour la réforme de la facturation électronique, nous, les développeurs, on les met à disposition sur les versions récentes, alors pas la toute dernière, mais aussi N-1, N-2, etc., mais pas les versions d’il y a 5 ans ou 10 ans, ce n’est pas raisonnable pour nous de passer autant de temps.
Et donc, du coup, finalement, de voir que, comme sur plein d’autres sujets, il faut faire attention à quand même avoir un logiciel de gestion qu’on peut mettre à jour, sans que ce soit trop lourd, trop compliqué. Et ça, c’est aussi un rappel. On le voit déjà cette année et on le verra, je pense, encore l’année prochaine. Des entreprises qui vont se dire : « moi, mon vieux logiciel de gestion propriétaire qui n’est plus maintenu, qui est plus machin… il va falloir que je le renouvelle. Vite, j’ai besoin d’un Dolibarr ou d’un Odoo en urgence. »
Alors, je ne sais pas si les intégrateurs auront la bande passante nécessaire pour accepter ces nouveaux prospects, ces nouveaux clients, parce qu’on sera évidemment tous très occupés. On le voit déjà chez nous, mais je pense que ça continuera. Il ne faut pas non plus se réveiller trop trop tard avant la deuxième échéance de septembre 2027 pour les entreprises qui ont besoin de changer de logiciel de gestion parce qu’elles ne passent pas l’échéance, elles ne sont pas capables de générer des factures dans un des formats de la réforme.
Maxime : ou de s’équiper tout court.
Walid : ou de s’équiper effectivement d’un nouveau logiciel. Je pense qu’effectivement, pour avoir parlé à des intégrateurs, les gens te disent : « désolé, mais on est full ». Donc, voilà, c’est un peu tard, il fallait s’y mettre avant. Écoutez, merci à tous les trois. Peut-être même qu’il y aura un épisode 3, effectivement.
Alexis : peut-être vers octobre, quand on aura passé les premières semaines de démarrage. On commencera à avoir un peu un retour d’expérience. Ça pourrait être intéressant, en octobre, de faire un petit débriefing du démarrage.
Maxime : il va falloir qu’elle ait la date tout de suite.
Walid : ouais, voilà. Prenons rendez-vous pour dans quelques mois pour en reparler. Ok, écoutez, merci à tous les trois d’être venus. C’était cool. Je l’ai fait un peu à l’improviste, cet épisode, mais je me suis dit que ça valait vraiment la peine de faire ça.
Un petit message avant de se quitter pour les auditrices et les auditeurs. Si vous écoutez ce podcast depuis votre application de podcast et que vous avez des questions sur des termes qu’on a employés de manière générale sur le podcast, je vous invite à aller dans la transcription, parce que la transcription, elle est complète, avec plein de liens, plein d’informations supplémentaires, potentiellement des captures d’écran, etc. Donc, c’est des ressources supplémentaires à votre disposition, si vous voulez creuser les infos, c’est des choses qui m’ont été demandées récemment. Donc, voilà, j’en profite pour passer ce message-là.
Et voilà, comme d’habitude, faites tourner cet épisode, renseignez-vous, posez des questions sur les réseaux sociaux des personnes ici présentes et de leurs entreprises, si vous avez des questions. Cet épisode, j’ai eu l’idée parce que j’ai vu quelqu’un sur les réseaux sociaux qui disait : « oh là là Dolibarr, facturation électronique, ça ne va pas marcher ». Je me suis dit qu’il était temps de… t’expliquer où on en était et que si, si, ça allait fonctionner. Donc voilà. Donc, écoutez, à bientôt pour un épisode 3. Puis, voilà, on se reparle dans quelques mois. Merci.
Maxime : avec plaisir. Merci, Walid.
Philippe : merci.
Production de l’épisode
- Enregistrement à distance le 13 mai 2026
- Trame : Walid Nouh
- Montage : Walid Nouh
- Transcription : Walid Nouh
Utilisation d’IA
Vous pouvez consulter notre charte IA.
- Transcription : whisper-medium via mufidiwiwhi en local
- Amélioration de la transcription : gemma4-26b en local via outil interne
- Traduction automatique en anglais : Microsoft Translator avec plugin WordPress WPML
- Traduction en anglais des posts réseaux sociaux : en local avec Jan et Mistral-Small-3.2-24B-Instruct
Licence
Ce podcast est publié sous la licence CC BY-SA 4.0 ou ultérieure
