Entrevue avec Laurent Destailleur, de AWStats à Dolibarr

Sommaire

• 1 Entrevue avec Laurent Destailleur, de AWStats à Dolibarr
• 2 Présentation de Laurent
• 3 La découverte de Dolibarr
• 4 Le début des contributions sur Dolibarr
• 5 Structurer la communauté
• 6 Le mode de gouvernance du projet
• 7 Prestations sur Odoo (et les ERPs concurrents)
• 8 Dolibarr et le no-code/low-code
• 9 Dolibarr et le SaaS / Plate-forme Dolicloud
• 10 Les futurs défis du projet Dolibarr
• 11 Tribune libre : le mot de la fin
• 12 Licence

Walid : cette semaine et pour le premier épisode, nous partons à la découverte de Laurent Destailleur. Laurent est un acteur engagé du logiciel libre depuis de nombreuses années. Il est l’auteur de logiciels tels que AWStats, qui a eu son heure de gloire avant que n’arrive Google Analytics. Et il est actuellement mainteneur de l’ERP Dolibarr. Mais ce n’est pas tout.

Laurent et moi avons été collègues et j’utilisais déjà AWStats et Dolibarr avant de le rencontrer, donc c’est un plaisir de l’avoir avec moi. Bonjour à toi, Laurent.

Laurent : bonjour, c’est réciproque.

Présentation de Laurent

Walid : est-ce que tu peux te présenter, nous expliquer un petit peu ton parcours et à quand remonte ton intérêt pour le logiciel libre ?

Laurent : Donc tu l’as dit, je me suis Laurent Destailleur. On me connait dans le monde du logiciel libre, sous le pseudo de Eldy. Je suis un ch’ti, originaire du Nord, donc je suis de Villeneuve d’ascorbique, j’ai fait mes études là-bas, dans une école d’ingénieurs à Lille qui s’appelle l’ISEN. Et tout de suite après mon cursus universitaire, ma formation, j’ai ensuite déménagé sur Paris pour commencer une carrière dans l’informatique, puisque c’était vraiment ça qui me bottait. J’ai travaillé dans le monde de la société de service, différentes petites sociétés, puis des plus grosses.

J’ai fait mes classes comme développeur, puis chef de projet, puis directeur, etc. Et puis ensuite, j’ai basculé, je suis passé entrepreneur. Donc ça, c’est pour l’aspect professionnel.
Mais en parallèle de tout ça, j’ai aussi travaillé dans mon temps libre et par passion uniquement et de manière bénévole avant que ça devienne mon activité d’aujourd’hui et que j’en vive. Je me suis consacré au logiciel libre. Alors au début je ne savais même pas ce que c’était le logiciel libre. Je pense que dès mes premières lignes de code, quand j’ai commencé à faire mes premiers petits programmes en basique, etc. J’avais déjà envie que ce que je produise soit utilisé par tous. Donc il y avait à l’époque, on est dans les années 90, même un petit peu avant, il y avait déjà de la notion de shareware, mais la notion de libre ou d’open source, c’était des choses dont on ne parlait pas encore, c’était pas encore répandu, le mouvement n’était pas encore bien structuré. Donc je développais des petites applications et ma toute première m’en soulait bien, elle s’appelait Gadget PC et donc je l’ai mise en shareware. On pouvait acheter des logiciels gratuits comme ça et la particularité c’est que j’ai un IP dans le logiciel, si vous voulez les sources du programme vous pouvez vous m’écrivez et je vous les envoie par disquette. Donc on va dire que j’ai vraiment commencé comme ça, j’ai appelé ça du shareware avec possibilité d’obtenir des sources.

Je ne connaissais pas encore le nom de logiciel libre ou d’open source. Et puis voilà, ça me plaisait le fait que ce que je fais une fois, des tas de monde puisse le réutiliser, je trouvais ça… Ça me faisait kiffer tout simplement et j’ai continué. Et puis ensuite lors de mes premières expériences informatiques, j’avais un besoin qui était, donc on est dans les années 2000, où ma société pour laquelle je travaillais, société de services traditionnels, m’a demandé de faire le site web de la boîte et puis je voulais savoir, avoir les stats, etc. J’ai cherché des choses, il y avait quelques outils qui existaient mais je trouvais leur niveau de précision pas terrible et donc j’ai décidé de faire le mien. C’est comme ça qu’est né AWStats. Où j’ai fait mon premier gros logiciel, gros succès on va dire.

Un gros succès ouais. Dans les années 2006, on va dire au pic du succès du logiciel, il y avait 80 millions de sites web. Donc aujourd’hui ça fait rire parce qu’on en a beaucoup plus, mais sur les 80 millions une université américaine avait évalué qu’il y avait à peu près 30 millions qui analysaient leurs statistiques et qui faisaient du reporting sur l’usage des sites web grâce à cet outil. Le succès m’a donné confiance dans le modèle parce qu’en fait j’ai vraiment développé tout ça, mais j’ai mis le code en libre accès, donc dans les années 2000 le mouvement open source était structuré, il y avait déjà la notion de licence qui était connue, donc j’ai décidé de distribuer en licence GPL, donc libre d’utilisation, libre de modification, libre de distribution. Et j’ai comme ça eu des gens qui ensuite sont venus vers moi d’un peu tous les pays, j’ai fait une petite amélioration, etc. Et donc ça a conforté ma vision que proposer du code, le donner aux autres, c’était quelque chose de sympa puisque en retour je recevais moi aussi du code.

Walid : qu’est-ce qui t’a poussé par exemple à choisir la licence GPL plutôt qu’une autre licence ?

Laurent : alors à l’époque ma vision de l’open source n’était pas aussi claire qu’aujourd’hui, je n’avais pas toutes les connaissances que j’ai aujourd’hui sur les licences copyleft, sans copyleft, etc. Et on va dire que c’est simple, j’ai pris la plus populaire.

Walid : D’accord. Tout simplement. Assez classique.

Laurent : voilà. Donc j’ai vu que tout le monde faisait, qu’il y avait beaucoup de projets open source en GPL et donc voilà, j’ai dit je vais le faire aussi en GPL. Ça avait l’avantage d’avoir quelque chose de structuré, il y avait un licence, il y avait un consensus sur ce qu’on pouvait ou ne pouvait pas faire avec cette licence. Donc voilà, ça s’est fait naturellement sur cette base là.

Walid : dans ces années 2000, comment tu distribues ton code ? Il y avait quoi comme forge logicielle à l’époque ? Parce qu’on n’avait pas encore git, on n’avait pas encore toutes les plateformes actuelles ?

Laurent : non, il n’y avait pas grand chose. Alors il y avait CVS. J’ai commencé les premières lignes de code simplement en local et puis je distribuais en zip tout simplement et on téléchargeait. Ensuite il y a eu CVS donc là ça a permis de mettre le code en commun directement accessible à n’importe quel moment avec le détail sans avoir besoin d’aller dézipper etc. puis ça permettait aux autres de pouvoir contribuer plus facilement. C’était pas encore le grand kif, puisque le principe de contribution sur CVS, c’est qu’on fabriquait un patch et puis on envoyait le patch au mainteneur. Donc je recevais des fichiers patch pour améliorer le logiciel AWStats. On n’avait pas de stats, donc du coup j’ai fait un autre projet open source qui s’appelle CVS ChangeLogBuilder, où on pouvait, dans le seul but de faire des statistiques sur l’usage de CVS. Donc ça me permettait de voir qui contribue, quand, l’évolution, à quelle heure de la journée, etc. Donc ça a été mon deuxième projet open source, qui lui a été un peu moins connu puisque CVS a vite cédé le pas à SVN, donc quelque chose d’un peu plus évolué. Donc j’ai basculé sur SVN, AWStats, je ne sais plus vers quelle année mais bon on va dire peut-être 2005 2006 quelque chose par là pour avoir quelque chose d’un peu plus performant et voilà et en parallèle donc tout ça de AWStats l’aventure a commencé en 2000 le produit existe toujours mais il n’est plus très utile aujourd’hui parce qu’il y a vraiment des alternatives qui sont plus récentes et puis voilà si on veut faire un liste de stats tout le monde se rue aujourd’hui sur Google Analytics, mais il y a des solutions libres bien plus sympas, comme Matomo.

La découverte de Dolibarr

Et donc l’aventure continue, mais on va dire que ça a été quand même… ça me prenait beaucoup de temps sur mon temps libre, entre 2000 et 2010. Mais en parallèle, dès 2002, j’ai commencé à travailler sur Dolibarr.

Dans un autre langage, AWstats était fait en Perl. J’avais choisi Perl comme ça parce que c’était un langage qui me paraissait très rapide. Au début, je ne pensais pas qu’AWstats serait le produit qu’il est devenu.

Je voulais juste faire un petit truc vite fait pour mon propre besoin. Et j’avais aussi, en plus, toujours pareil, par passion, je faisais aussi des sites web. D’abord un site pour les copains, etc. Et puis j’ai fini par créer un site web grand public qui a pas mal marché, puisqu’il est devenu l’un des premiers sites web grand public dans son domaine, donc un site sur les chiens tout simplement, donc ça s’appelle chiensderace.com. Là le but c’était d’assouvir la passion de la technologie web, découvrir le web etc. Comme ça a bien marché, on m’a demandé de mettre de la pub, on m’a demandé des services et puis bon j’ai senti qu’il y avait moyen de faire facturer quelques petites interventions et puis d’obtenir un peu d’argent de poche et donc il a fallu que je crée des factures pour faire ça de manière propre et pro et donc j’ai cherché un outil dans le monde du libre pour commencer à faire des premières factures. Je n’ai pas trouvé grand chose, j’ai trouvé Dolibarr qui me plaisait bien parce qu’il était en PHP donc un langage très simple d’utilisation et qui avait une philosophie et qui était aussi lui en licence libre.

Donc je savais que je pourrais le modifier. Et donc j’ai commencé à travailler comme ça en 2002 sur Dolibarr, qui n’est pas un projet, donc je suis à l’initiative. C’est Rodolphe Quiédeville qui a démarré ce projet, mais on peut dire qu’au départ c’était vraiment juste deux, trois écrans. Je fais une facture et puis je génère un PDF. J’ai découvert d’abord d’utiliser ce produit, puis ensuite j’ai voulu l’améliorer pour mes propres besoins et puis j’ai apporté tellement d’améliorations que Rodolphe m’a très rapidement demandé de prendre le litre sur le projet.

Walid : Ça date de quand ?

Laurent : alors là on est à peu près en 2004-2005. Donc c’est quasiment deux ans après que j’ai commencé à contribuer au projet.

Walid : et qu’est ce que ça veut dire Dolibarr ?

Laurent : alors Dolibarr ça veut rien dire de particulier, c’est Rodolphe qui a choisi le nom. Donc il y a quand même une signification, une origine, il n’a pas pris au hasard. Rodolphe a fait plusieurs projets open source, il aime bien donner des noms de personnages féminins, s’inspirer de noms de personnages féminins pour pouvoir fabriquer le nom de ses projets open source. Et en l’occurrence Dolibarr ça vient de la contraction de Dolores Ibárruri. Vous irez le voir sur Wikipédia, c’est une révolutionnaire espagnole, notamment connue par sa phrase « ¡No Pasarán! ». Voilà, et donc le « Dol » de Dolores, c’est le « Ibarr » de Ibárruri, tout simplement. Mais il n’y a pas d’autre signification que ça.

Le début des contributions sur Dolibarr

Walid : tu commences à contribuer à Dolibarr. Alors un truc que je trouve assez intéressant à expliquer, c’est comment t’arrives surtout à l’époque, il n’y avait pas encore Git, c’était pas si facile de contribuer. C’est quoi ton état d’esprit quand tu commences à contribuer à Dolibarr ?

Laurent : alors quand il n’y a pas Git effectivement, à l’époque tu ne sais pas que Git va arriver. Tu ne te rends pas compte que contribuer sur un projet open source c’est compliqué. Aujourd’hui on se dit mais c’était super compliqué à l’époque. Mais en fait à l’époque on trouvait ça normal. Pour moi j’envisageais de travailler sur Dolibarr quand j’ai fait mes premiers modifs, mes premières améliorations. C’est simple, je commençais à faire des petits fichiers patch, je faisais comme ce que moi je recevais en tant qu’auteur sur AWStats, et j’envoyais mes petits patch à Rodolphe.

Walid : donc tu avais une mailing list ? Il avait une mailing list ?

Laurent : honnêtement, je ne me souviens plus, je ne pense pas, si peut-être, sinon c’était du simple mail. C’était du simple mail, à défaut d’avoir une mailing list, on faisait du simple mail. Et puis petit à petit, au bout des premières contributions je pense que Rodolphe a dû nous donner les droits d’accès, entre temps on a dû passer sur SVN aussi il me semble, j’avoue que ma mémoire fait un peu défaut sur les tout départs, les origines du projet, mais on a dû passer sur SVN et ensuite j’ai dû contribuer en faisant des push sur SVN, ce qui veut dire puisque les outils à l’époque n’étaient pas décentralisés comme dit aujourd’hui, ce qui veut dire qu’en fait il fallait avoir les droits. Mais on était très peu à travailler sur le projet, donc Rodolphe m’a commencé à me donner les droits je pense, et puis voilà j’ai commencé à faire des petits push dès lors que mes premières contribs par mail étaient satisfaisantes. Dès le départ Rodolphe il avait une licence libre, une licence GPL.

Walid : dès le départ, il avait une volonté de faire un outil communautaire ?

Laurent : oui, d’entrée, c’est sa philosophie, c’est la mienne. Je fais du code tout de suite, je le redonne à la communauté. Moi, j’ai toujours trouvé frustrant de travailler, de développer, de faire du code, c’est un travail, et puis de se dire, ça ne me sert qu’à moi. Je fais un petit traitement, j’en ai besoin une fois, j’ai passé une heure, je fais mon truc, j’ai résolu mon problème, enfin voilà je trouve que le retour sur investissement est catastrophique quand on fait du code pour soi-même en fait et comme je déteste perdre mon temps, ça c’est vraiment un des moteurs qui me motive, je ne peux pas faire deux fois la même chose, j’en suis incapable, je n’aime pas gâcher, je déteste le gaspillage. Voilà pour moi c’était naturel, je fais du code, je le donne parce qu’au moins ça ressert à quelqu’un d’autre.

Walid : donc assez rapidement finalement tu commences à devenir un peu le mainteneur principal Dolibarr ?

Laurent : oui très vite. On va dire très vite parce que dès que Rodolphe a vu que je contribuais pas mal sur le projet, il m’a tout de suite laissé la main sur le projet, donc je suis devenu le contributeur principal, je suis devenu le chef de projet. Et à l’époque on n’était pas nombreux, on était 4-5. Et donc voilà il m’a dit « je te laisse carte blanche sur le sujet » tout simplement.
Donc moi j’ai essayé de garantir l’esprit du projet, l’esprit du projet c’était GPL qui va perdurer, mais aussi faire un logiciel, une solution qui soit simple, accessible à tous parce que c’était ça l’idée de Dolibarr, c’était ça qui m’avait plu au départ.

Et quand je regardais, moi dans mon activité professionnelle, je travaillais dans les sociétés de services. Donc dans les sociétés de services je travaillais sur des ERP, j’en ai touché quelques-uns, j’ai travaillé sur de l’Oracle, j’ai travaillé sur du SIEBEL, j’ai travaillé sur certains dont je ne me souviens même plus du nom et franchement c’était des usines à gaz pour faire des choses qui sont identiques pour tout le monde en fait. Ça m’énervait donc l’idée d’avoir un logiciel simple que tout le monde puisse utiliser sans avoir à payer le coût d’entrée qui était colossal, il est un peu moins aujourd’hui mais à l’époque il était vraiment colossal d’avoir un ERP et juste fabriquer une facture en PDF c’était très très cher donc ça m’énervait pour moi c’était évident que j’allais donner en open source.

Walid : Est ce que tu peux nous expliquer de manière simple en quelques mots qu’est ce qu’on peut faire avec Dolibarr ?

Laurent : au départ mon besoin c’était juste faire des factures donc c’était ça la souche historique de Dolibarr, faire simplement des factures et générer un PDF. Et puis après il a fallu gérer les clients, gérer les fournisseurs, donc on faisait des factures clients, on a commencé à faire des factures fournisseurs, puis il a fallu faire des devis en amont de la facture, gérer les commandes. Puis après j’ai eu besoin de gérer les stocks et donc on va dire toutes les fonctionnalités que l’on synthétise sous le terme de ERP et de CRM aujourd’hui sont intégrés dans Dolibarr.

Donc les fonctions de la relation client, le ticketing, le devis, etc. Il suffit de signer son devis en ligne, ils sont intégrés. Et puis la partie plus cachée, donc la partie gestion des stocks, facturation, mais aussi la partie RH qui est arrivée ensuite en cours de route. Donc pouvoir gérer ses employés, gérer les notes de frais, gérer ses congés et on va dire que pour synthétiser aujourd’hui tous les besoins qu’une entreprise a pour gérer son entreprise sont intégrés aujourd’hui dans Dolibarr ou vont l’être parce qu’il y a toujours des choses qu’on peut rajouter mais on a déjà aujourd’hui si on prend une entreprise au hasard en France, on sait que Dolibarr va déjà répondre à 90% des besoins de l’entreprise en termes de système d’information.

Structurer la communauté

Walid : c’est hyper large, pour l’avoir utilisé effectivement on peut faire vraiment beaucoup de choses et en plus de ça, ça continue à évoluer, je pense à toute la partie production, site internet etc. C’est un sujet que j’aborderai un peu plus tard. Je voudrais revenir sur la partie communauté, j’aimerais que tu nous expliques un peu comment quand tu arrives à 4-5 personnes et comment tu structures la communauté est-ce que typiquement l’expérience que tu as eu d’animation de communauté sur AWStats ça t’a aidé sur Dolibarr ? comment tu as structuré ça et comment s’est structurée maintenant la communauté entre les gens qui contribuent on va dire de manière un peu bénévole, les gens qui font de la prestation à côté, toi, comment ça s’organise tout ça sur le projet ?

Laurent : l’expérience que j’ai eue sur AWStats, elle m’a pas forcément beaucoup aidé, elle m’a permis juste de découvrir ce que c’était que le monde open source, apprendre le vocabulaire, apprendre, découvrir les outils, etc. Mais j’ai pas vraiment créé une vraie communauté avec AWStats. Parce qu’en fait, au final, c’était beaucoup de contributions unitaires. Donc voilà, c’était du one-shot. Je t’ai fait un correction, j’ai un bug, change de plan, vois.

Donc c’était beaucoup de monde, il n’y avait pas de récurrence dans les gens qui contribuaient. Donc on ne peut pas appeler ça une communauté, je n’ai pas vraiment eu à créer une communauté, on va dire c’est plus le succès du logiciel, le fait qu’il n’y avait rien sur le marché, le fait que AWStats répondait à un besoin de manière plutôt sympa par rapport à ce qui se faisait à l’époque, fait qu’il y avait une adhésion, il y avait un nombre d’utilisateurs qui grandissait et avec un gros nombre d’utilisateurs, j’avais beaucoup de contributions mais je n’ai pas œuvré pour améliorer la communauté.

Sous Dolibarr, c’était différent parce que vraiment j’avais cette volonté de m’attaquer au mastodontes, au plus gros, et de dire on va faire ce que font les gros et ce qu’ils vendent 2000 euros par personne, on va le faire gratuitement. Et donc là, on ne peut pas le faire tout seul parce qu’on est sur une échelle beaucoup plus complexe, sur une couverture beaucoup plus large et donc il fallait effectivement fédérer, donc c’est vraiment le mot important c’est fédérer c’est à dire trouver des gens qui acceptent de proposer du code pour améliorer Dolibarr mais pas seulement pour un simple besoin pour eux mais pour je veux dire de manière régulière et faire en sorte qu’ils le font pour un intérêt qui est qui persiste dans le temps. Quand on fait son évol localement on a fait son évol, on a soumis et puis voilà on a son petit amélioration, on a plus besoin de corriger, de travailler.

Donc ce qu’il fallait c’est créer un écosystème qui soit économiquement viable, c’est-à-dire que des gens vivent grâce à Dolibarr et gagnent de l’argent grâce à Dolibarr. A partir de là où on se dit si un écosystème, des gens gagnent de l’argent, ils ont intérêt à ce que le produit s’améliore et ils vont devenir des contributeurs réguliers. Et là, ça a été la partie très compliquée, parce qu’on part de 4-5 personnes qui contribuent de manière bénévole pour juste faire avancer un chemin de vie et puis se dire ben voilà on fait quelque chose de libre et puis on propose un logiciel qui est gratuit à tous et on fait du bien on va dire à la communauté, à tous ceux qui n’ont pas de budget, qui n’ont pas de moyens, voilà, à un monde où on est hyper industrialisé. Donc ça c’est compliqué, la première c’est la promotion, il faut parler, il faut en parler, il faut le faire découvrir, parce que si les gens ne s’attendent pas que ça existe déjà, la probabilité que ça décolle, zéro.

Une fois que les gens savent que ça existe, donc là j’ai fait des news, j’ai posté, j’en ai parlé dans les forums, sur des sites etc. Une fois que les gens commencent à entendre parler, ou du moins une petite tranche de population parmi les développeurs, je ciblais bien sûr les sites en rapport avec le développement ou le libre, une fois que cette population découvre et sait que ça existe, ça veut pas dire que ça va prendre. Donc là il faut faire en sorte qu’il y ait un certain niveau de qualité dans le logiciel pour que les gens, la première chose que font les gens c’est qu’ils vont le tester et si en faisant des tests ils ne sont pas convaincus, ils ne vont pas dire je vais contribuer. Donc il a fallu améliorer l’aspect qualitatif, faire en sorte que ça s’installe très vite. Donc là d’entrée l’une des premières grosses fonctionnalités qui est aujourd’hui un point fort de Dolibarr par rapport à tous ses concurrents, c’est son installateur et sa capacité à monter de version et ça a été intégré dans la conception du logiciel, il y avait beaucoup de procédures pour pouvoir installer très facilement. Du coup j’ai apporté un point fort au logiciel qui est, je veux voir ce que c’est, à l’époque il n’y a pas le SaaS donc on ne peut pas le tester très rapidement. Donc ce que faisait les gens c’est qu’ils téléchargeaient et lançaient le .zip.

Donc il fallait une solution comme ça. Donc j’ai d’abord proposé un .zip où il suffisait de le dézipper dans un serveur web et puis tout se faisait automatiquement. Et donc là les gens en pouvant tester déjà en 15 à 10 secondes ils ont déjà un a priori positif, parce que le dézipper c’était quasiment opérationnel. Et donc là j’ai levé une première barrière, ça a permis d’avoir déjà quelques contributeurs, quelques développeurs qui ont pu l’utiliser et on est passé de 5 à peut-être 20, 30 personnes qui contribuent.
Alors l’étape suivante, une fois que le produit pouvait s’installer facilement, c’est de faire en sorte qu’il y ait une courbe d’apprentissage qui soit pas trop rude, c’est-à-dire que les gens, ils ont installé le logiciel, il faut qu’ils arrivent à s’en servir tout de suite. Et là, c’est aussi quelque chose sur lequel j’ai travaillé fortement, c’est de faire en sorte que d’entrée, on comprenne comment fonctionne le logiciel sans avoir à lire une documentation, sans avoir à se faire former par quelqu’un d’autre. Et donc ça, c’est aussi devenu un point fort, et c’est dans l’ADN maintenant de Dolibarr et ça le restera, c’est que l’application doit être très simple d’abord. Il faut qu’on puisse comprendre et trouver, on veut faire quelque chose, on doit y arriver sans forcément lire une documentation, simplement en lisant les menus ou en voyant ce qui est affiché à l’écran.

C’est un des points forts de Dolibarr ça. Voilà, et donc ça c’est le deuxième axe sur lequel j’ai pas mal travaillé pour améliorer l’outil. Alors il y avait déjà une base au départ qui était bonne, mais il faut toujours faire plus donc c’est plein de petits trucs, on rajoute des tooltypes (NDLR : infobulles) pour expliquer à quoi ça sert, parce que des fois un simple libellé d’une colonne, on a un doute, l’utilisateur a un doute, c’est pas bon, il faut lever les doutes, il faut lever le temps que la personne ait pour rechercher, donc ça ça a été le deuxième axe, qui permet là encore faire en sorte que la première impression de ceux qui l’utilisent est bonne, et se disent ça vaut le coup d’investir dans ce logiciel.

Et enfin, il y a une troisième axe sur lequel j’ai travaillé, mais tout ça c’est en parallèle, ça a été l’outillage. C’est-à-dire l’outillage pour fédérer une communauté. Donc la mise en place de mailing list, ensuite la mise en place d’un wiki, pour faire de la documentation, pour décrire les choses, ensuite la mise en place, donc bien sûr quand Git est arrivé, le passage sur Git. Il y a eu un canal IRC mais qui a été très peu utilisé, c’est surtout la mailing list qui a marché.

Walid : pour ceux qui ne connaissent pas IRC c’était un système libre qui permettait en fait de pouvoir faire de la communication instantanée, un peu un ancètre de slack, un slack de l’époque

Laurent : donc c’était plutôt beaucoup par mailing list.

Effectivement, j’avais aussi tenté cette piste-là. Ensuite, un site web. Parce que le projet, il faut le présenter. La première chose que tu fais au fur et à mesure qu’Internet se développe, quand on parle de quelque chose, on va voir sur le site web pour avoir plus d’infos. Donc il a fallu créer un site web. Donc là, voilà, j’avais monté un… Je ne sais plus ce que c’était comme CMS.

Walid : Un SPIP ?

Laurent : je ne me souviens même plus, tu vois.

Depuis, il a été remplacé par Dolibarr lui-même, qui fait aussi CMS et fait des sites web. Un Joomla, voilà.

Walid : les contributeurs qui ont commencé à travailler avec toi, c’était principalement, majoritairement, au départ, des francophones ?

Laurent : au départ, je faisais tout en français. Quand je référençais Dolibarr, je le mettais aussi sur des petits sites anglais, etc. Il faut voir que la base du code, au départ, le code, les noms des variables, tout est en français.

Il y a encore un peu de français d’ailleurs qui traîne. Et donc la langue officielle, quelque part, c’était le français. Et puis pour démarrer, c’était plus simple dans ma langue naturelle que dans l’anglais, que je maîtrise beaucoup moins bien. Donc ça a été en français. Pareil, les sites qui parlent de l’open source, qui parlent de l’informatique, les français, je les connaissais, les étrangers, je ne les connaissais pas bien. Le logiciel a commencé à gagner du crédit et petit à petit les gens commencent à contribuer.

Il y a un moment où le projet devient suffisamment mature pour se dire on peut le vendre à une société, on peut faire un business dessus, il a commencé à y avoir des contributeurs qui ont souvent des petits indépendants qui ont commencé à proposer à leurs clients et à en vivre en fait. Alors pas Dolibarr tout seul, au départ c’était je propose Dolibarr mais je vends en plus des sites web, je vends en plus de la formation, etc.

Et donc tout ça, c’est un tout. Quand tout ça arrive, il faut continuer à miser sur une installation simple, un logiciel simple, un outillage qui soit adapté pour que les gens rentrent très rapidement dans le projet. Donc l’outillage il a évolué et un autre panier qui a été franchi avec l’arrivée de Git.

Walid : les premières personnes qui commencent à faire de la prestation parce que c’est un sujet qui m’intéresse parce que pour les auditrices, les auditeurs, moi je travaillais à l’époque sur un logiciel libre qui s’appelait GLPI qui était aussi un logiciel communautaire et sur lequel il y avait des… à un moment le logiciel est devenu assez complet pour que des gens fassent de la prestation. Au niveau de l’association qui gérait le projet, on a commencé à réfléchir à des mécanismes qui permettent aux gens de faire de la prestation mais en même temps de pouvoir contribuer au projet financièrement en plus de faire des contributions. Je suppose qu’à l’époque toi c’était pas ton travail non plus et il faut que les gens puissent en vivre à faire des prestats mais il faut aussi qu’au niveau du projet ça te rapporterait quelque chose non ?

Laurent : franchement j’avais jamais envisagé qu’un jour Dolibarr me rapporterait quelque chose.

Walid : c’était vraiment un truc passion que tu faisais sur le côté parce qu’à l’époque, à cette époque là, tu faisais quoi ?

Laurent : j’étais en société de service, j’avais un boulot. Au tout début, j’étais en société de service, je suis passé chef de projet et puis ensuite je suis rentré dans une grande, dans un grand groupe, une grande mutuelle où j’avais plusieurs postes de direction.

Donc c’était uniquement du bénévolat. L’idée d’en vivre est venue très très tard. Donc on est encore très loin au moment du passage sous git. C’était encore là l’idée, c’était encore de faciliter les contributions. Mais contrairement à toi, il n’y avait pas d’objectif de faire en sorte que moi je puisse gagner de l’argent avec. Donc je continuais à tout faire bénévolement et donc il n’y a pas de système de dons ou quoi que ce soit. D’autant plus que l’expérience que j’avais avec AWStats sur les dons, parce qu’AWStats par contre, comme c’était un logiciel qui était connu internationalement, je permettais de faire des dons et je me rendais compte que les dons ils venaient quasiment exclusivement des pays anglo-saxons.

Quand c’était francophone, c’était le Canada, mais de France, les gens consommaient de l’open source, mais c’était pas dans la mentalité, ça a peut-être évolué depuis, mais c’était pas dans la mentalité de faire un don à l’époque pour soutenir un projet open source. L’idée c’était de continuer à proposer, et j’avais plus cette envie de faire la nique, excusez-moi l’expression, aux gros mastondontes qui prenaient en otage leurs clients avec des politiques de hausse de tarifs d’un coup, des montées de versions obligatoires alors qu’il n’y avait aucune raison. Ça, c’était plus une motivation. Faire quelque chose qui soit utilisé par tout le monde. Je suis toujours dans l’idée, je fais un petit travail et toute la planète entière en profite.

Ça a toujours été ma motivation principale, y compris quand on passe sur Git dans les années fin 2010.

Walid : passage sur Git, moment important, puisque là, ça facilite la contribution, puisque tu n’as plus besoin d’être la bonne personne qui a les droits de commit, sinon j’envoie un patch. Qu’est-ce que ça change pour toi en fait ?

Laurent : la quantité de travail que je suis capable d’intégrer venant des autres est décuplée, puisqu’en fait pour intégrer le travail d’autrui, il suffit de cliquer sur un bouton. On regarde ce qu’il a fait, on valide et on clique.

Là où avant il y avait des manipulations, il y avait du manuel à faire systématiquement. Donc c’était assez compliqué. Donc les contributeurs n’ont pas forcément, le nombre de contributeurs n’a pas forcément augmenté. Par contre le nombre de contributions lors du passage sur Git, il a clairement explosé. C’était aussi plus simple pour les autres de fournir une contribution, puisqu’il leur suffisait de faire Git push et puis créer une merge request.

Ils n’avaient pas à fabriquer un fichier patch à le zapper et à l’envoyer ou bien pour que ce soit plus simple ils étaient obligés d’obtenir les droits sur le code et le problème c’est qu’on commence à être trop nombreux les droits sur le code c’est que chacun fait du code dans son sens et bien du coup on a un écran qui améliorait dans une direction puis un autre qui est dans une autre. Chaque écran habituellement est un peu plus simple à utiliser mais avec une ergonomie différente donc pour l’utilisateur final c’est plus compliqué.

Le mode de gouvernance du projet

Walid : justement ça m’amène à une question assez intéressante qui est la vision, on va dire, la vision vraiment produit de ça, c’est quoi le, j’allais dire, alors surtout depuis des passages à Git où il y a de plus en plus de contributions, c’est quoi j’allais dire le mode de gouvernance en fait, qui gère la cohérence de tout et comment est-ce que tu discutes avec les autres contributeurs les évolutions au niveau du projet ?

Laurent : ce qu’il faut savoir c’est qu’il y a une volonté dès le départ et qui est toujours maintenue, c’est que le projet reste un projet communautaire. Même aujourd’hui où il y a beaucoup d’entreprises qui vivent dans sa Dolibarr, il n’y a pas une société qui est leader sur Dolibarr. Le code, et la gouvernance du code, elle est faite autour de git aujourd’hui. Et quand Git est arrivé, on pouvait améliorer le code, mais on a aussi d’autres outils qui sont arrivés en même temps que Git, qui sont également intégrés dans GitHub, parce que quand je dis qu’on est passé sous Git, en fait on est passé sous GitHub, c’est qu’il y a le système des issues, le système des PR, et donc ça c’est devenu l’outil avec lequel on allait échanger, avec lequel les gens allaient pouvoir proposer des améliorations, avec lequel on allait pouvoir discuter, échanger, refuser.

Et la gouvernance aujourd’hui, elle est un peu particulière sur ce projet-là parce qu’en fait on n’est pas un projet avec une roadmap. On n’est pas une société qui se dit, voilà j’ai 10 développeurs, j’ai tel budget, je vais faire telle évol, telle évol, telle évol, et ça rentre dans le budget et je l’ai fait. Parce que j’ai ce budget pour faire ça.
Moi je suis plus dans un état d’esprit où j’attends les contributions. Si on m’envoie une contribution pour faire une amélioration, quelque chose, c’est pas forcément quelque chose que j’attendais, mais si ça fait progresser le projet, si ça apporte quelque chose au projet qui intéresse la grande majorité des utilisateurs de Dolibarr, donc qui intéresse les grandes majorités des entreprises, c’est intégré. C’est ça la règle. Alors il faut bien sûr que ça réponde à certaines qualités en termes de code etc, mais la roadmap elle se fait par rapport aux contributions qui arrivent.

Et donc, pour répondre à la question de la gouvernance, finalement la gouvernance est un peu assez simpliste, puisque chacun fait ce qu’il veut et propose ce qu’il veut. Le seul point de validation, ça va être l’intégration de la contribution dans le projet officiel, et là c’est simple, c’est moi qui appuie sur le bouton pour valider.

Walid : oui c’est ça donc c’est toi la personne qui a la vision globale du truc, enfin sur Dolibarr il y a un seul mainteneur c’est toi c’est ça ?

Laurent : alors non je suis pas le mainteneur, je suis le mergeur on va dire.

Walid : d’accord ok.

Laurent : les mainteneurs il y en a plein et les mainteneurs c’est ceux qui vont améliorer, qui vont corriger, qui vont même quand une contribution est faite par Dupont, Durand va y répondre en disant tu ferais mieux de faire que ceci, cela, il vaut mieux utiliser ta fonction pour mutualiser le code, tu as une autre manière de faire plus simple, plus propre, etc.

C’est les mainteneurs, mais c’est pas moi, c’est la communauté aujourd’hui. Moi on va dire que c’est vraiment de limiter mon rôle à celui d’arbitre, on va dire que j’ai un droit de véto, mais ça s’arrête là. Le reste c’est vraiment la communauté qui le fait. Et dès lors qu’il n’y a pas d’argument rationnel pour refuser, on va dire ça va rentrer. C’est la raison pour laquelle le projet évolue très vite et qu’il y a beaucoup de fonctionnalités qui arrivent dans le projet.

Walid : ce que tu dis là m’amène au autre question, c’est quoi la structure qui porte le projet ? C’est une association ? Il y a quoi ? C’est quoi ?

Laurent : il y a effectivement une association qui a été créée. Toujours pareil, comme j’évoquais un peu plus tôt le besoin de fournir des outils pour fédérer et faire venir le maximum de monde, parmi ces outils que je n’ai pas cités, il y a la création d’une association. Le but est d’avoir un statut juridique. Donc ça fait quand même plus sérieux que de dire c’est un projet open source où il n’y a absolument rien. Comme il y a une volonté de faire en sorte que le code reste sur une gouvernance communautaire, n’importe qui peut contribuer, n’importe qui peut soumettre et la seule validation qu’il y a c’est sur la qualité du code plutôt que sur la roadmap, sur ce que ça fait etc. L’association, donc je l’ai co-créé avec quelques autres personnes, mais cette association quand on l’a créée on lui a défini un rôle qui était uniquement d’assurer la promotion du Dolibarr, donc elle n’a aucun rôle sur le code et le développement au sens informatique. Elle n’a pas de vocation, le développement au sens marketing.

Walid : elle n’a pas de vocation par exemple à recevoir des fonds pour payer des développeurs à temps plein par exemple un jour ?

Laurent : non, aujourd’hui elle n’a pas cette vocation. Les fonds que reçoit l’association c’est aujourd’hui pour assurer la promotion, faire de la publicité, organiser des évènements pour que les gens se rencontrent, réaliser des flyers, des caquets mono, ce genre de choses.

Et dans la mesure où dans ses statuts il est clairement acté que son rôle doit être limité à assurer la promotion du logiciel, quand elle finance du développement, parce qu’il lui est arrivé de financer un peu de développement dans Dolibarr, quand elle le fait, elle le fait dans le but d’améliorer un outil pour sa propre gestion interne, de manière à rester dans son objectif qui doit se limiter à la production de Dolibarr. Ce qui me fait un peu peur c’est qu’une association, on le voit en France, c’est porté en gros par son bureau, ce qui fait qu’une association est dynamique ou pas, ça va être souvent le bureau ou conseil d’administration qui est dynamique ou pas dynamique. Or un bureau ça se renouvèle et j’ai vu beaucoup d’associations qui étaient très dynamiques, très actives, très populaires, puis simplement en changeant de bureau parce qu’il y a un renouvèlement du président, du trésorerie, etc., se retrouvent à une association qui est quasiment morte.

Alors ce n’est pas le cas avec l’association Dolibarr, mais c’est un risque qui faisait peur, et donc c’est pour ça qu’on a gardé cette séparation dans les statuts de l’association, pour que, on va dire, finalement, elle n’apporte qu’un plus au projet, mais elle ne remette pas en cause le risque de son dynamisme sur l’aspect code, puisque quand l’association s’est créée, on avait déjà un fort dynamisme, il y avait déjà suffisamment de contributeurs sur le projet. On a peut-être atteint le point de non-retour en termes de codeurs, de développeurs. Il n’y a pas de raison de chambouler ce fonctionnement qui fonctionne.

Prestations sur Odoo (et les ERPs concurrents)

Walid : ça devient de plus en plus rare de voir des projets purement communautaires, pas sur des modèles maintenant plutôt de type open core ou d’autres modèles avec un financement, avec une société qui va gérer en fait le projet et qui va plus ou moins collaborer avec des communautés. On va en reparler après, là je voulais justement te parler par exemple d’Odoo.

Laurent : il y a beaucoup de projets comme ça.

Walid : oui voilà, c’est pour ça que je trouvais intéressant en plus de commencer par toi la série de podcast parce que justement c’est une caractéristique assez forte du projet Dolibarr et donc ça m’amène à une autre question qui est moi quand je t’ai connu on travaillait ensemble dans la même société chez Teclib, tu faisais de la presta sur Odoo si mes souvenirs sont bons, tu faisais aussi un peu Dolibarr je pense pour nos besoins internes, qu’est ce que ça t’a apporté le fait de travailler sur des ERP concurrents pour le développement de Dolibarr ?

Laurent : déjà avant de travailler sur Odoo, à une époque où je continuais à bosser sur Dolibarr de manière complètement bénévole et pour pas un rond, on est donc à une époque où j’avais déjà travaillé sur d’autres ERP bien avant Odoo, dans le cadre de mes activités de société de service.

Donc j’avais déjà une vision, je savais déjà comment gérer les stocks, ce qu’est un processus de fabrication, toutes ces choses-là. J’avais déjà une vision très large des ERP, de ce qu’on peut faire, de comment il faudrait le faire, parce que j’ai déjà été confronté aux problèmes avec un SAP, on devait faire 50 clients pour faire telle opération, j’ai jamais compris pourquoi. J’ai déjà dû répondre à des besoins pour les clients de simplification, donc j’ai déjà été confronté à tous ces problèmes. Tous ces ERP que j’ai rencontrés dans ma carrière, des ERP mais aussi des domaines autres, des CMS, j’ai touché à pas mal d’outils et donc ça m’a permis d’être au plus près des utilisateurs. C’est pas le fait de découvrir les produits qui m’a beaucoup apporté, c’est le fait d’être aux côtés des utilisateurs et de leurs problèmes qui m’a apporté. En me disant on a tel outil, c’est compliqué, on peut pas faire ça, on veut faire ça plus simplement, etc.

Et ça j’avais déjà pas mal d’expérience avec les autres produits. Quand je suis passé sur Odoo, la différence c’est que ce projet là était open source. Enfin du moins je le pensais, il n’est plus tout à fait open source aujourd’hui. C’est de l’open core, voilà. On va simplifier les choses en disant c’est open core. Alors il existe encore une version full open source, mais qui s’appelle Odoo et que moi j’appellerais Odoo Community. Le problème voilà c’est qu’elle s’appelle aussi, mais c’est pas le même logiciel, il n’y a pas les mêmes fonctionnalités, c’est pas la même gouvernance, c’est pas les mêmes personnes qui travaillent dessus, même s’il y a un core qui est commun. Donc on va simplifier les choses en parlant de l’open core d’Odoo. Donc il y a une partie qui était open source. Donc c’était la différence.

Mais finalement, hormis que ça simplifiait les choses quand il fallait le faire évoluer, le fait que ce soit open source, j’avais plus de facilité lorsqu’on disait bah ça c’est trop compliqué, il faudrait simplifier cette étape là, je dois faire sans SAP, ça te coûte deux mois de travail.

Sur Odoo c’est dix fois plus simple, parce que tu peux toucher au code au core, et quand c’est un simple modif dans le core, tu touches, tu fais ton petit module, ton petite extension, etc.
Mais les problèmes étaient les mêmes finalement, le produit il a une façade, il a des fonctionnalités de base et quand on rentre dans la vraie vie, quand on veut s’en servir pour de vrai, on se rend compte que ce qui a été câblé par défaut, ce n’est pas le besoin de l’utilisateur et donc il faut faire autre chose. Et donc c’est plus ces expériences utilisateurs qui font que moi j’essaie de faire en sorte qu’on ne les retrouve pas dans Dolibarr, on va dire ces mauvaises expériences utilisateurs, en faisant des choses souvent plus ouvertes parce que souvent les ERP ont une philosophie fermée : il y a un workflow qui est défini, il y a un process qui est défini et si on veut sortir du moule c’est compliqué on fait appel à un développeur même si certains appellent ça du paramétrage. ça c’est quelque chose sur lequel je me suis toujours dressé, du paramétrage quand il faut avoir fait cinq ans d’informatique pour pouvoir le faire, j’appelle pas ça du paramétrage, moi j’appelle ça du développement. Oui c’est peut-être des fichiers de config, oui c’est peut-être des fichiers XML, des fichiers Python, ce que l’on veut, mais c’est pas du paramétrage.
Alors que l’idée c’est que vraiment de faire en sorte que ce que les autres proposent par du paramétrage ultra avancé, ce que moi j’appelle le développement, c’est qu’on puisse le faire par du vrai paramétrage, c’est à dire des clics à la souris.

Dolibarr et le no-code/low-code

Walid : moi je bosse sur des technologies no-code, et donc en fait on entend énormément ce discours des gens qui vont dire écoute en fait ton ERP écoute 300 000 euros je te fais la même chose avec du no-code t’es complètement con de prendre un ERP tout ça. Je me suis toujours mis en faux contre ça parce que je pense qu’un outil il est mais s’il existe c’est qu’il a un besoin mais tu as certainement un besoin d’intégration avec d’autres outils donc en fait ce que tu dis là fait un peu écho à ça aussi qui est bon bah voilà il y a des fonctionnalités ça devrait pas du code donc je vais je vais faire du vrai paramétrage dessus parce que voilà, il faut pas être informaticien. Et puis, je sais parce qu’on en a discuté aussi que justement toutes ces problématiques de no-code c’est aussi quelque chose vers lequel tu tends à regarder et qui me semble intéressant. Si je regarde dans ma communauté, c’est-à-dire la communauté des gens dans les startups et qui font du no-code, Dolibarr est totalement inconnu alors qu’en fait il aurait toute sa place, il pourrait très bien être utilisé et intégré avec des outils no-code.

Laurent : effectivement, dans l’idée de rendre l’application plus simple, plus accessible, faire en sorte qu’elle soit ouverte à tous et qu’on n’ait pas besoin de passer par la case d’une société informatique pour pouvoir ensuite avoir customisé comme on veut son logiciel, il y a l’idée d’accès en supprimant le workflow qui était monolithique, c’est-à-dire en étant quelque chose de plus ouvert. Je prends un exemple, sur la plupart des ERP, on a son devis, avec son devis on convertit en commande et sa commande on convertit en facture. Moi je suis une petite boîte, je veux que mon devis passe en facture directe, ou je ne veux pas faire de devis, je veux une commande et je veux que la commande passe en facture directe. Donc il faut que tous les chemins soient possibles. Et donc ça, voilà, c’est des choses qui ont fait évoluer Dolibarr, qui font qu’on est, en termes de câblage par défaut, ouvert.

C’est-à-dire qu’on peut un peu tout faire, et c’est plus la manière dont on va donner des consignes à ses employés ou la manière dont on va décider soi-même si on est seul à l’utiliser, c’est cette manière-là qui va déterminer le workflow du logiciel, ce que l’on va faire. Mais on fait en sorte que tous les chemins soient possibles sans contraintes trop fortes quitte ensuite après à rajouter des blocages alors que la plupart des ??versus?? ont une philosophie inverse c’est à dire qu’il y a quelque chose de monolithique qui est très sécurisé très blindé mais qui est très bloquant aussi pour la plupart des usages qui font que pour les cas d’utilisation standards ça marche pas et il faut le faire évoluer. Donc ça c’est un premier point vers lequel Dolibarr a travaillé beaucoup depuis de longues années pour être facilement accessible et puis rentrer dans le mood du maximum de personnes sans avoir besoin de faire de développement spécifique.

Et le deuxième point que tu l’as évoqué c’est que malgré ça, on peut avoir envie de faire encore plus et d’aller encore plus vite ne serait-ce que par exemple pour avoir des fonctionnalités qui n’existent pas du tout. Et là on rentre dans, on va dire, dans un premier temps sur le low code.
Donc low code, no-code, low code, on va dire qu’on fait très peu de code. Et donc Dolibarr, pour l’instant, on est à l’ère du low code, on n’est pas encore au no-code. Alors low code, c’est-à-dire qu’on va générer, on va quand même devoir mettre un petit peu de code. C’est-à-dire qu’on va avoir des outils, avec la souris, on va dire tiens je veux gérer, je veux gérer ta notion, elle est caractérisée par ceci, par cela, je veux qu’il y ait telle API, etc. Et l’application va fabriquer du code. Et on va avoir 90% de son besoin de l’application, du code qui est réalisé. Et le développeur doit encore faire les 10% manquants.

Mais c’est pas opérationnel les 90%. C’est-à-dire qu’il y a quand même un développeur qui doit ensuite… Mais on a la génération de code.

Walid : je comprends bien, où est-ce que tu l’offres, la génération de code tu l’offres ?

Laurent : alors je l’offre aujourd’hui dans un module qui est spécifique qui s’appelle Module Builder.

Walid : d’accord.

Laurent : donc Module Builder c’est un outil où on décrit une application que l’on veut faire, ce que l’on veut obtenir, quelles données on veut gérer, et cet outil va générer le code pour que toutes ces fonctionnalités s’intègrent directement dans Dolibarr. Ça c’est si tu veux typiquement racheter les fonctionnalités supplémentaires.

Walid : Souvent ce qu’on va faire, et moi par exemple, c’est souvent mon cas, c’était j’utilisais du no-code pour par exemple générer des ordres de transfert. Des interfaces. Pour vraiment piloter à distance ce que tu fais actuellement avec les API Dolibarr. Et donc en fait, en gros, c’est l’intégration avec les outils du marché no-code. Quand tu discutes avec des projets libres, la réponse est toujours la même, c’est que tu as des API, tu peux tout faire. Oui, mais la réalité, c’est qu’en fait, ton utilisateur qui ne connaît pas ton API, qui ne sait pas coder, ça ne lui servira pas grand chose. Il faut qu’au contraire, que ce soit le projet libre qui fasse le pas vers les outils no-code pour proposer des intégrations natives et faire en sorte que ton Dolibarr soit accessible dans ta liste comme Gmail ou n’importe quel autre outil, qui fait que les gens n’ont qu’à cliquer et automatiquement les gens vont se dire « Ah ouais, Dolibarr c’est supporté, ah ben c’est génial, je vais utiliser Dolibarr » tu vois ?

Laurent : complètement, alors ça ça répond à un autre besoin effectivement, quand je parlais de l’outil Low-Code qui est aujourd’hui intégré et disponible dans Dolibarr, c’est vraiment plus pour développer une application complète, un besoin complètement qui n’a rien à voir, une application de niche qui n’existe pas, où là effectivement l’application va tout fabriquer, la base de données, les écrans etc. Tout le code est généré, mais le code généré, ce n’est pas suffisant. Il faut encore ensuite que le développeur admette les quelques règles de gestion métier qui sont propres, les quelques contraintes particulières. Voilà, donc d’où le terme low code. Mais ça, c’est en train d’évoluer vers du no-code, c’est-à-dire qu’on pourra faire l’application, deux semaines après, on veut la modifier, la corriger, on revient dans l’outil module builder, on la corrige et on va pouvoir vraiment gérer une application from scratch de A à Z.

Donc ça c’est quelque chose qui devrait sortir bientôt dans les prochaines versions Dolibarr sur cet aspect là. L’aspect que tu évoques, effectivement, on est plus sur intégrer Dolibarr avec d’autres applis, faire des interfaces, faire des échanges, de la synchro, du pilotage, du déclenchement d’actions automatiques, ce genre de choses. Là on va peut-être effectivement sur les outils d’automation. Il y a déjà un petit prototype qui avait été fait par rapport à Zapier, donc une petite étude de faisabilité qui était un petit module qui était expérimenté dans Dolibarr.

Et il y a actuellement un projet qui est mené par une équipe de 7 étudiants, l’équipe Automation, donc je les salue au passage s’ils m’écoutent, qui sont en train justement de travailler sur un projet qui consiste à étudier les outils d’automation du marché, donc les Zapier, les n8n, les make, les IFTTT, etc. pour ensuite essayer de faire en sorte de les intégrer, de faire en sorte que Dolibarr soit nativement intégré à ces outils. Donc ça, ce projet, il est en cours, il y aura des résultats cet été, avec effectivement l’objectif que je veux interfacer mon application X ou Y avec Dolibarr, je peux, via simplement l’usage de ces outils d’automation, brancher et faire cette passerelle à la souris. Et donc ça c’est quelque chose qui est pour moi un autre pendant, un autre sujet, qui est aussi un sujet sur lequel on avance sur le sujet Dolibarr, parce qu’effectivement, demain, il y aura quand même de moins en moins de développeurs.

On peut faire de plus en plus de choses à la souris, il n’y a pas photo, Le ROI (NDLR : retour sur investissement) entre faire un projet à la souris et faire un projet avec du code et un développeur à l’expérimenter, il n’y a pas photo.

Dolibarr et le SaaS / Plate-forme Dolicloud

Walid : j’ai une dernière question, ce que l’heure tourne, quelque chose qui me semble assez intéressant. Dolibarr, c’est un projet qui existe depuis longtemps, qui existait avant le SaaS. Maintenant, quand tu crées un projet, la plateforme SaaS, c’est la première chose qui arrive.

Comment vous avez vécu l’arrivée du SaaS et comment tu as pris ce tournant en marche pour Dolibarr ?

Laurent : alors quand le SaaS est arrivé, effectivement tout le monde, il y a plein d’applications qui sont arrivées dans le SaaS et on arrivait dans une ère où les gens, avant de choisir un logiciel, avant ils le téléchargeaient, ils l’installaient, ils le paramétraient et ils l’utilisaient pour l’évaluer. Aujourd’hui les gens, ils veulent cliquer sur un bouton, le tester tout de suite et s’ils n’arrivent même pas à tester, ils ne choisissent même pas. Donc ça c’est le premier truc que j’ai vu dans le SaaS, c’est-à-dire si tu n’es pas dans le SaaS, si tu ne proposes pas au moins ton logiciel pour être testé très rapidement immédiatement dans le SaaS, ton logiciel ne sera plus choisi par les DSI, par les utilisateurs potentiels. Donc il faut une solution, il faut que Dolibarr soit dans le SaaS. Et là encore, on est encore à une époque où à ce moment là, je n’envisageais pas de gagner ma vie avec Dolibarr.

Cette problématique, je voulais la résoudre. Donc j’ai monté un autre projet open source qui s’appelle sellyoursaas.org qui est un projet open source dont le but est de permettre de proposer n’importe quelle solution informatique, n’importe quel logiciel, à condition qu’il fonctionne en mode web, n’importe le cas de ce logiciel, de pouvoir le proposer en SaaS de manière gratuite ou de manière payante. Et toute la stack, toute la pile, tout le besoin, l’automatisation, la création d’instances, le déploiement, les sauvegardes, la mise à jour, la sécurité, éventuellement le paiement si on veut proposer ce logiciel de manière payante, la facturation du client, sa récurrence, l’interlocution, l’échange avec le client avec un système de tickets en cas d’incident, la possibilité d’avoir un réseau de revendeurs qui ensuite revendraient le projet, tout ça, ça a été intégré dans une seule et même solution qui est sur du SaaS.

Donc c’est un conglomérat de plein de solutions open source, mais documenté par une seule et même doc qui permet de mettre en place ce genre de projet. Tu évoquais le programme GLPI sur lequel tu as travaillé il y a quelques années, aujourd’hui il faut voir que la solution GLPI Cloud, elle tourne grâce à cette solution saleyoursaas.org et elle a pu être mise en place comme ça en une à deux semaines, assez rapidement, grâce à cette solution. Et donc ça, ça a permis d’offrir Dolibarr en SaaS et de permettre aux gens de tester. Et puis au fur et à mesure que les gens ont testé, ils sont commencés à revenir voir moi en me disant, ça me plaît, le logiciel est super, mais je veux le garder, je ne veux pas l’installer chez moi, je ne sais pas le faire. Et donc c’est là qu’est venue l’idée de dire, du coup je vais garder l’hébergement et puis je vais faire payer un abonnement à ceux qui veulent rester hébergés.

Et puis au fur et à mesure que le nombre de personnes sont venues, j’ai vu que j’avais moyen d’en vivre et là j’ai fait la bascule, j’ai arrêté mon travail de salarié, j’ai créé la société Dolicloud pour vendre Dolibarr en SaaS.

Walid : et donc ça, ça te permet d’être financé ?

Laurent : alors aujourd’hui, c’est ce qui me fait vivre moi, c’est ce qui fait vivre la société Dolicloud. Il y a quelques salariés aussi dans Dolicloud maintenant, mais c’est ce qui fait vivre Dolicloud. Le projet Dolibarr reste toujours sur le même mode, c’est à dire du développement sur le pur bénévolat de chacun, il n’y a pas de financement dans le développement Dolibarr. C’est à dire que le financement c’est en général, si moi pour mon propre besoin, j’ai un besoin, je vais le faire en tant que Dolicloud et puis je vais le redonner à la communauté dans le projet Dolibarr.

Donc finalement c’est mon temps de travail sur Dolicloud qui aura servi mais pour le projet Dolibarr ça coûtera pour un rond. Je veux dire il n’y a aucun financement de développement aujourd’hui, du moins très très peu, c’est vraiment anecdotique le financement de développement sur Dolibarr. Aujourd’hui effectivement mes employés travaillent surtout sur Dolicloud, par contre j’ai des idées d’évolution à terme de choses sur Dolibarr sur lequel je mets quelques personnes de temps en temps en contribution, mais c’est dans un intérêt on va dire long terme, plus j’améliore Dolibarr, plus j’ai de chance de le vendre grâce à Dolicloud.

Mais ça reste des contributions communautaires et tout l’écosystème aujourd’hui fonctionne ainsi, il y a beaucoup de sociétés qui vivent aujourd’hui avec Dolibarr, mais elles ont toutes leurs modèles différents. Moi aujourd’hui je fais de l’hébergement et uniquement de l’hébergement, d’autres font de la formation, uniquement de la formation, d’autres font du développement sur mesure, d’autres font de l’assistance, du conseil, de l’aide à la rédaction du cahier des charges pour implémenter Dolibarr dans une entreprise, de l’assistance à la migration, etc. Toutes ont leur modèle, parfois c’est des combinaisons de tout ça. Toutes ces entreprises, lorsqu’elles font quelque chose pour un client, en général c’est fait avec l’accord pour que ce soit fait en open source et puis c’est redistribué et c’est réintégré dans le projet officiel.

Walid : tu as une volonté d’avoir un maximum de contributions qui sont disponibles à tous directement dans le projet, même si il y a des gens qui font des plugins à côté ?

Laurent : voilà, alors il y a des gens qui font des plugins à côté et qui ensuite essaient de baser, faire un business model sur la vente de plugins, notamment grâce à la plateforme DoliStore, on n’en a pas parlé mais… DoliStore c’est une place de marché, c’est un Apple Store, c’est un Play Store, ce que vous voulez, mais spécifiquement pour des applications Dolibarr. Et donc ça, ça a été monté par l’association Dolibarr dans le but de donner de la visibilité à tous ceux qui vivent de Dolibarr et qui font des extensions Dolibarr. Ce qui permet à celui qui a fait un petit module pour un client, alors là il l’a fait pour son client, il a été payé par le client, c’est dommage de jeter, c’est pas forcément possible d’être intégré dans le projet Dolibarr parce que ça répond pas à des règles de qualité, ça répond pas à des besoins, c’est vraiment un segment de niche qui n’intéresse que très très peu de personnes, dans ce cas-là il y a moyen quand même de capitaliser sur ce qu’on a fait, de faire en sorte qu’il soit réutilisable par d’autres en le mettant à disposition sur Dolly Store. Donc ceux qui ont fait ces petites expansions, ces améliorations, ils peuvent le proposer sur DoliStore. Le proposer sur DoliStore c’est gratuit et vous pouvez donc proposer votre module soit pour 0€ soit pour quelques euros en contribution.

Et l’association Dolibarr prend 20% de la vente, le vendeur prenant 80%. Voilà mais c’est pas un business model forcément qui est le plus utilisé aujourd’hui dans Dolibarr. Finalement ça revient à vendre un module, donc à vendre du code. Or le code comme il est sous licence libre, celui qu’il a acheté après il peut le donner à qui il veut. Donc c’est très dur à vendre très cher ce genre de… Vendre quelque chose cher en sachant qu’ensuite celui qu’il a acheté il peut le donner gratuitement à qui il veut. C’est pas un modèle, c’est tout à fait autorisé par la licence, mais c’est pas un modèle qui marche. Donc en général c’est souvent des micro-paiements, c’est dur de vivre de ce modèle là.

Les futurs défis du projet Dolibarr

Walid : ma dernière question c’est plus une question d’ouverture, je voulais savoir quels étaient un peu les défis et les grands jalons à venir pour le projet ?

Laurent : évoquer un le défi donc c’était le c’était le no-code c’est un gros défi sachant que c’est aussi une énorme opportunité effectivement parce qu’en fait historiquement on avait les applis traditionnels on en avait plein unitairement et quand il fallait les communiquer on faisait des interfaces : c’était développement c’était coûteux c’était compliqué comme c’était compliqué de faire communiquer entre elles. Les applis ont commencé, les ERPs ont commencé à prendre des applications des un des unes. Les ERP ont intégré des fonctions de CRM, les CRM ont commencé à intégrer des fonctions d’ERP, ces ERP-CRM ont commencé à intégrer des fonctions de CMS, de sites web, de boutiques en ligne, etc. Et puis maintenant on a une autre famille de besoin qui est le no-code pour pouvoir faire une application très rapidement, donc faire quelque chose que l’ERP n’est pas prévu. Bon ben ça, il y a des outils no-code qui commencent à apparaître sur le marché, donc je me place pas dans les cas des outils d’automation, où la plupart des outils commencent à être mûrs, mais je te parle dans le cas des outils où il faut développer une application from scratch, on commence à avoir des plein de startups qui créent ce genre d’outils.

Elles ont quand même aujourd’hui un gros défaut, ces solutions, c’est qu’on fait une appli from scratch dans un écosystème qui est nul. Or nous, société, qui a déjà son ERP, qui a déjà Dolibarr, elle a déjà une base d’utilisateurs qui est renseignée quelque part. Elle a déjà une base de stores qui est renseignée quelque part. Elle a déjà une base de factures, elle a déjà une base de permissions, elle a déjà plein de choses.

Et donc si on peut mettre la puissance du no-code, faire une appli, mais qu’en plus, tout ça se branche nativement avec toutes ces fonctionnalités qui sont déjà connues de l’entreprise, on va encore un cran plus loin par rapport aux outils no-code qui sortent actuellement mais qui sont autonomes, qui sont indépendants. Et donc ça, c’est le grand défi puisqu’en fait, ça apportera la puissance du no-code, mais avec en plus la possibilité, je fais une appli no-code, mais j’ai besoin d’aller récupérer, de proposer dans mon appli une liste des utilisateurs, je l’ai déjà.

Alors que dans une application no-code traditionnelle, il va falloir que je crée une interface pour aller chercher dans mon SI. Là, on met l’outil no-code dans l’outil qui gère le SI directement. L’outil du SI, c’est déjà l’outil no-code. Et donc, on va encore un cran plus loin. Donc ça, c’est un gros défi.

Walid : c’est parce que c’est en partie, je te coupe là, pour bien connaître le sujet, c’est en partie parce que les gens ont eu pas mal de mauvaises expériences avec des ERP ou des CRM, qui voulaient faire des choses qu’ils n’arrivaient pas à faire, parce que les outils, ils ont leur philosophie, ils sont faits pour faire quelque chose et que finalement les gens se disent, finalement c’est plus vite, ça va plus vite si je recrée le truc.

Ça marche bien au départ, la problématique principale de ça c’est la maintenance sur le long terme, la documentation, etc. Enfin c’est tous ces sujets annexes que tu vois pas au départ en disant bah faire mon CRM ça va me prendre 10 minutes, mais maintenir ton CRM sur 3 ans, 5 ans et avoir partagé la connaissance, transmettre la connaissance, c’est ça qui est un peu plus complexe. Mais bon voilà, c’était une aparté.
Tu évoques effectivement la partie documentation, que l’outil no-code de Dolibarr va te générer la documentation. Donc ça c’était un des défis, est-ce que tu en as d’autres à venir ?

Laurent : oui, alors après l’autre défi c’est celui dont tout le monde parle en ce moment, c’est l’intelligence artificielle, qui est hyper prometteur. Il y a déjà un développeur qui a proposé un plugin pour Dolibarr pour exploiter la puissance de chatGPT de manière à faire du requêtage, faire du reporting avec du requêtage en langage naturel.

C’est à dire que la personne elle veut faire un reporting qui n’est pas forcément prévu, qu’elle ne voit pas trop comment faire parce qu’elle n’a pas de connaissances techniques sur comment s’en structurer les données dans la base, elle tape sur le clavier, sort moi la liste des clients qui ont eu au moins une facture dans l’année 2017 et puis hop l’appli te sort la liste. Donc ça c’est un petit plugin, il y a eu un Proof of Concept (NDRL : prototype) qui a été fait, qui marche déjà pas mal, suffisamment pour qu’on sache que ça va devenir inévitable. On a des résultats qui sont très très probants. Donc ça, ça va être aussi un défi, mais j’ai pris cet exemple de requêtage. Mais si on rajoute en plus à la fonction no-code que j’évoquais, c’est que demain, c’est l’outil no-code, on ne va même plus piloter la souris, on va le piloter en langage naturel. Ça c’est encore un autre défi qui est dans les cartons. Donc c’est un deuxième défi.

Et le troisième, on va dire, c’est plus un défi qui lui, donc là on est plus sur des défis, des choses futures, récentes. Mais on en a un qui est permanent sur le projet Dolibarr, c’est réussir à garder un logiciel qui soit simple, pas cher, avec un apprentissage qui soit quasi immédiat, avec le nombre de fonctionnalités que l’on a qui continue d’augmenter. Et ça c’est un défi permanent.

Walid : en gros si je reformule, c’est comment ne pas générer, enfin comment ne pas générer ou résorber la dette technique que tu as sur un projet comme Dolibarr ?

Laurent : ouais alors la technique elle est surtout sur l’aspect le code mais moi j’évoquais ça en live aussi mais je pensais aussi surtout à l’aspect fonctionnel. Comment rajouter sans arrêt plus de fonctionnalités, comment apporter toujours plus de services parce que c’est l’évolution naturelle voilà la concurrence elle n’attend pas. Comment proposer toujours plus de services sans mettre en péril la philosophie actuelle qui fait que le logiciel est très simple d’utilisation. Aujourd’hui on sait faire beaucoup de choses très facilement, mais à chaque fois qu’on rajoute quelque chose, on court un risque de complexifier, de transformer le logiciel en usine à gaz et de devenir finalement le même ERP que tout ce qu’il y a sur le marché aujourd’hui. Et donc si le défi, c’est de ne pas ressembler à ce que font les autres et rester l’un des ERP, si ce n’est l’ERP le plus simple qui existe aujourd’hui sur nos chaînes.

Tribune libre : le mot de la fin

Walid : écoute, on est arrivé à la fin, je voudrais te laisser conclure. C’est la Tribune Libre qui a un message que tu veux faire passer, que ce soit sur Dolibarr, sur tes contributions au logiciel libre Il y a plein de trucs qu’on n’a pas dit sur le packaging Debian, tout ça, mais bon bref.

Laurent : ouais, on pourrait faire plein d’autres streamings, parce qu’effectivement on a fait plein de raccourcis, plein d’expériences dans le monde open source que j’ai vécu, notamment je n’ai pas parlé des échecs, j’ai parlé de AWStats, j’ai parlé de Dolibarr, mais je n’ai pas parlé des échecs.
Je prends mon pied en faisant du libre, je pense que c’est un univers vraiment merveilleux, quand on arrive à ne pas tomber dans les travers, parce que dans le libre, aujourd’hui c’est devenu industrialisé, c’est devenu commercial énormément. Si on arrive à ne pas tomber dans les travers, on peut en vivre. Moi c’est vrai que ce n’était pas mon objectif au départ, je le faisais en parallèle parce que j’adorais ça, mais je ne pensais pas qu’un jour ce serait mon activité principale, je ne ferais que ça, parce qu’aujourd’hui je ne fais que du libre. Je pense qu’il y a des autres expériences et aujourd’hui le monde est ouvert pour qu’on puisse réussir à avoir des business complets et vivre grâce au libre.

Donc si vous êtes passionné, soyez patient, insistez. Entre le moment où j’ai commencé Dolibarr et le moment où aujourd’hui j’ai un train de vie très satisfaisant, il s’est passé des années. Soyez patient. Mais je suis convaincu que le libre a un énorme avenir. Il y a moyen de patienter parce que pour moi le point de mon retour sur le libre a été atteint. On en aura de plus en plus. Et c’est le modèle qui va de plus en plus dominer donc n’investissez pas dans le propriétaire s’il vous plaît. Voilà, quel bon mot de la fin.

Walid : Laurent, merci d’avoir fait l’ouverture. C’est un bon mot de fin.

Laurent : merci de couvrir enfin ce sujet en podcast, qui est très peu, trop peu couvert.

Walid : voilà, c’est la fin de ce premier épisode. J’espère que ça vous a plu. N’hésitez pas à en parler autour de vous et à le partager sur les réseaux sociaux. A bientôt pour un prochain épisode….

Cet épisode est enregistré le 4 avril 2023.

Licence

Ce podcast est publié sous la double licence Art Libre 1.3 ou ultérieure – CC BY-SA 2.0 ou ultérieure.

Odoo Community Association

Sommaire

• 1 Odoo Community Association
• 2 Présentation de Joël Grand-Guillaume
• 3 Présentation d’Odoo
• 4 Les grandes étapes du dévelopement d’Odoo
• 5 Présentation de l’OCA
• 6 La génèse de l’OCA
• 7 L’association OCA
• 8 Le financement de l’OCA
• 9 Les projets soutenus par l’OCA
• 10 Les relations avec Odoo SA
• 11 L’OCA et les licences
• 12 Odoo et les changements de licences
• 13 Des verticales Odoo via l’OCA ?
• 14 Comment se matérialise la communauté autour de l’OCA ?
• 15 Les défis de l’OCA
• 16 Comment l’OCA se fait connaître ?
• 17 Conclusion
• 18 Tribune libre
• 19 Licence

Walid : bienvenue pour ce nouvel épisode de Projet Libre. Aujourd’hui on va parler d’un sujet que j’affectionne tout particulièrement. Si vous êtes un auditeur ou une auditrice fidèle, vous avez déjà entendu des épisodes sur d’autres ERP. Mais aujourd’hui on va parler d’un outil que j’aime beaucoup qui s’appelle Odoo. Et en particulier on va parler de la Odoo Community Association, sur lequel je me suis pas mal documenté, mais j’ai encore beaucoup de questions. Et pour répondre à ces questions, et bien qui de mieux qu’avoir avec moi le président du board de l’Odoo Community Association, Joël Grand-Guillaume.

Joël, écoute, merci beaucoup d’avoir accepté, bienvenue sur le podcast Projets Libres!, j’espère que tu vas bien.

Joël : eh ben oui, bonjour, je vais très bien, je te remercie, merci pour ton invitation, je me réjouis de passer ce petit moment avec toi pour partager un petit peu tout ce qu’il y a à savoir dans ce monde là.

Présentation de Joël Grand-Guillaume

Walid : première chose, c’est que j’aimerais d’abord que tu puisses te présenter pour les auditrices et les auditeurs qui ne te connaîtraient pas.

Joël : d’accord, bon alors moi je m’appelle Joël Grand-Guillaume – ça fait un bien long nom – j’habite en Suisse. J’ai 43 ans, 3 filles. Je suis responsable du département business solution chez Camptocamp qui travaillait avec Odoo depuis ses tout débuts. Et j’ai aussi l’honneur d’être le président de l’OCA et membre du conseil d’administration depuis maintenant 10 ans.

Walid : comment est-ce que tu as découvert le logiciel libre ? Par quels moyens ?

Joël : alors ça c’est une anecdote assez rigolote. J’étais en CDD chez Camptocamp à l’issue de mes études et puis j’ai eu l’occasion de participer à FOSS4G. FOSS4G c’est le plus grand événement sur l’open source géospatial dans le monde du libre. C’est une conférence internationale où l’innovation et la collaboration convergent pour l’avenir de la géomatique. Et vraiment c’était là que j’ai découvert toute cette communauté internationale, rencontré des gens extraordinaires et cette façon de créer des logiciels que je ne connaissais pas alors. Et je suis tombé fan et donc je suis allé voir les patrons pour qu’ils m’engagent ce qui a été chose faite et donc c’est là que toute l’aventure a démarré.

Walid : d’accord donc tu as fait toute ta carrière sur Odoo, quasiment ?

Joël : ouais absolument ouais alors depuis mes premiers travaux d’ingénieur ou presque j’ai fait un petit peu de géospatial au tout début et ensuite j’ai embarqué sur ce logiciel extraordinaire.

Walid : A l’époque ça s’appelait pas Odoo, quelle version c’était quand tu as commencé ?

Joël : c’était TinyERP version 3.9. Donc ça date un peu, je crois que ça fait 18 ans. C’était un petit peu avant 2006, toute la fin d’année 2005 que j’ai découvert la première fois le logiciel.

Présentation d’Odoo

Walid : avant qu’on parle de l’OCA, est-ce que tu pourrais commencer par présenter assez succinctement Odoo pour les gens qui ne connaîtraient pas ?

Joël :

Odoo, c’est en fait une suite d’applications métiers open source. C’est un périmètre fonctionnel très large. En fait, c’est une sorte de boutique en ligne d’application, mais pour les entreprises, un petit peu à la manière de ce qu’on aurait sur l’App Store ou le Google Store, mais simplement pour le monde des entreprises.

C’est une solution qui est édité par un éditeur belge qui s’appelle Odoo SA. C’est une société qui aujourd’hui pèse plusieurs milliards, mais évidemment ça peut toujours être le cas. Et c’est un modèle économique qu’on appelle Open Core. Il y a une version communautaire qui est disponible et publiée sous une licence LGPL et on peut souscrire un abonnement pour avoir la version entreprise qui donne lieu à un certain nombre de services notamment les migrations et certaines fonctionnalités additionnelles.

Walid : je mettrais dans les notes de l’épisode des liens vers des interviews de Fabien le créateur d’Odoo qui explique toute l’histoire d’Odoo, c’est assez intéressant de voir par où il est passé pour en arriver là.

(NDLR : l’interview de Fabien Pinckaers sur GDIY)

Joël : absolument, c’est une très belle aventure.

Walid : c’est une grande réussite du logiciel.

Joël : absolument.

Les grandes étapes du dévelopement d’Odoo

Walid : est-ce qu’on pourrait juste revenir deux secondes sur qu’est-ce qui pour toi sont les faits marquants du développement d’Odoo ?

Joël : il y a peut-être pas mal de choses à dire, j’espère que je ne vais pas louper de trop important. Déjà, je pense qu’il y a son début, aux environs de 2005, avec ce logiciel connu sous le nom de TinyERP. Et puis quatre ans plus tard, aux alentours de 2009, il a été renommé OpenERP après la version 5. Il était plus si petit que ça. Il y a une petite anecdote que Danone s’intéressait au logiciel et le patron ne souhaitait pas payer cher pour une solution qui s’appelait « Tiny ». Donc ils ont décidé de le renommer OpenERP parce que sa portée était beaucoup plus large qu’alors et la communauté a vraiment commencé à croître à partir de ce moment-là.

En 2012, je trouve qu’il y a un autre fait marquant, c’est l’arrivée du premier client web et le passage de la GPL à la licence AGPL. Je pense que c’est un fait marquant aussi dans la communauté et aussi pour les utilisateurs. Avec un vrai client web, avant on était encore sur un client lourd développé en GTK, donc beaucoup plus compliqué à déployer.

Et puis en 2014-2015, OpenERP devient Odoo ! Et donc, je dirais que pour mieux refléter sa suite complète d’applications, dans leur vision, ça allait plus loin qu’un ERP. Donc ils souhaitaient enlever le mot ERP du nom du logiciel. Et c’est aussi à ce moment-là qu’Odoo a lancé une offre SaaS basée sur leur cloud, avec Odoo Online, et qu’ils ont changé de business model (NDLR : modèle économique) pour passer sur ce business model Open Core, qui connaît le succès d’aujourd’hui.

Walid : je pense qu’on y reviendra tout à l’heure un peu sur les licences.

Joël : ouais, ok, avec plaisir.

Présentation de l’OCA

Walid : maintenant, ce que j’aimerais, c’est qu’on passe à la présentation de l’Odoo Community Association, qu’on appellera certainement OCA, pour des raisons pratiques dans le reste de l’épisode.

Joël : très bien.

Walid : j’aimerais bien comprendre qu’est-ce que fait l’association en fait et pour quelles raisons elle a été créée.

Joël : alors déjà on est une association non lucratif donc ça c’est la première chose et on a été établi pour soutenir une communauté open source et collaborative autour du développement et la promotion de fonctionnalité autour d’Odoo. On aide en fait aussi les intégrateurs, les membres à créer plus rapidement des solutions Odoo plus efficaces avec un accès facile à des applications de haute qualité, et aussi des migrations libres. Parce qu’aujourd’hui, si on veut migrer une version d’Odoo à l’autre, il faut passer par la souscription entreprise. Donc là, on propose un projet alternatif open source. Donc je dirais que ça, c’est un peu l’essence de cette association.

La génèse de l’OCA

Walid : qu’est-ce qui fait que cette association est créée ? À quel moment exact c’est créé ? Et pourquoi l’association, vous décidez de la créer ?

Joël : alors ça il faut remonter pas mal d’années en arrière. A l’époque ce qu’il faut comprendre, c’était mes tout débuts dans cette communauté et je découvrais en fait un monde, une communauté internationale et j’ai eu un plaisir fou à collaborer en fait avec toutes ces personnes.

Mais quelque chose me peinait beaucoup, c’est que chacun redéveloppait les mêmes modules en son propre nom pour avoir en quelque sorte le prestige de publier cette application à leur nom. Donc beaucoup de travail était fait à double, il y avait peu de collaboration sur les modules des concurrents parce qu’on ne veut pas contribuer aux modules d’un concurrent, etc. Et là, ça m’a fait poser plein de questions sur cette pertinence, en fait, d’être dans un monde open source, mais finalement pas collaborer.

Et puis là, j’ai la chance de travailler chez Camptocamp, donc dans le département géospatial qui fond des projets open source depuis très longtemps. J’ai découvert en fait comment fonctionnait l’OSGeo. C’est une fondation géospatiale pour l’open source et j’ai compris comment cette association a structuré et comment ils avaient réussi en fait à faire cette collaboration un succès. Et notamment je dirais un des points marquants de cette association, c’est le fait que le code des différents contributeurs est donné ou le copyright est… on donne une version de son copyright à l’association de façon à ce que l’association détienne le copyright du code qu’on publie et donc le code est sous l’égide de cette fondation et non plus sous la responsabilité de chacun de ses contributeurs. Et le fait de neutraliser ça sous une entité commune permet à chacun de contribuer librement.

On garde l’auteur évidemment pour avoir la reconnaissance du travail qui a été fait par chacun. Par contre, voilà un peu le principe. Et donc je suis parti sur cette idée et j’ai proposé en fait sur les mailing-lists de l’époque la fondation d’une telle association avec mes premières idées sur la question et ça a été très bien reçu.

Et donc je suis parti avec cette idée, avec quelques intégrateurs de l’époque qui jouaient vraiment ce jeu de l’open source et on a décidé de fonder cette association.

Et ce qui est incroyable c’est qu’à cette époque là c’est le même moment où tout s’est mis en route, où OpenERP est devenu Odoo et qu’ils ont changé leur modèle de licence. Ils sont passés de l’AGPL à la LGPL plus ses souscriptions entreprises, donc sur ce modèle Open Core comme il s’appelle.

Et donc ce jour là dans la salle d’annonce de la création de l’association il y avait un monde mais fou on pouvait plus passer dans les couloirs et en fait l’OCA a été perçu ce jour là comme un bateau de sauvetage pour de nombreuses personnes qui étaient convaincues que la méthode open source était nécessaire pour cet écosystème et pour assurer l’avenir de la solution Odoo.

Alors aujourd’hui on a un objectif bien différent. L’avenir d’Odoo il est désormais assuré, il y a des millions d’utilisateurs satisfaits qui en profitent partout dans le monde et donc on a redirigé un petit peu l’objectif de l’association pour pouvoir un petit peu au défi du jour.

Walid : quand tu annonces sur les mailing-lists, quelles sont les réactions chez Odoo en fait ? Est-ce qu’il y a des gens de chez Odoo qui font des retours là-dessus ? Est-ce qu’ils regardent ça de manière bienveillante ? Est-ce qu’ils ne font pas de retour en fait ? Qu’est-ce qui se passe ?

Joël : alors moi j’ai toujours été transparent avec Fabien, donc moi j’ai eu la grande chance, je dirais d’être dans les tout premiers. Fabien c’est quelqu’un que je connais, on se parle, on s’écrit, on se répond, donc il y a un respect mutuel je dirais qui s’est installé depuis toutes ces années qu’on côtoie, qu’on se côtoie. Et donc à cette époque là j’ai pas fait ça dans son dos, c’est quelque chose avec lequel il était au courant, on en avait parlé, il est même venu participer à un moment donné de cette session de la création de l’association pour répondre à quelques questions. Donc il n’y a jamais eu une volonté d’être en frontal avec lui.

J’ai toujours eu un esprit de collaboration, on est plus fort ensemble. Et le but ça n’a jamais été finalement de se battre contre ni Fabien ni Odoo, mais bien de regarder comment est-ce qu’on peut faire vivre une version Open Source, comment est-ce qu’on peut faire vivre cette vision-là et supporter l’éditeur dans son mouvement Open Core pour que ça se passe bien pour les deux parties en fait.

L’association OCA

Walid : avant d’aller un peu plus en détail là-dessus. Je voudrais savoir, donc l’association, c’est une association de droits Suisse ?

Joël : Oui.

Walid : d’accord. Que tu as créé parce que tu es Suisse en fait, donc tu l’as créé directement là ou il y avait une raison particulière de la mettre en Suisse ?

Joël : alors, en partie parce que j’étais établi en Suisse, Camptocamp a aussi des succursales en France et en Allemagne, donc j’avais aussi d’autres opportunités, mais je pense que la réglementation suisse elle est vraiment bien faite et surtout reconnue lorsqu’il s’agit d’organisations non gouvernementales. Il y en a plein qui sont ici à Genève, donc on a un droit, je dirais constitutionnel, qui favorise ce genre d’association et qui la rend crédible à l’étranger pour la stabilité, la neutralité pour laquelle la Suisse est connue. Et je pense que c’est quelque chose qui a fait l’unanimité à l’époque, quand je l’ai proposé, personne n’a remis en question le fait de le faire en Suisse, c’est quelque chose auquel les gens ont tout de suite adhéré.

Walid : et l’association, elle détient de la propriété intellectuelle ? Est-ce qu’elle est juste là pour faire la promotion de ce que vous faites ? Qu’est-ce qu’elle détient en fait cette association ?

Joël : alors peut-être qu’on pourra préciser ça dans le cadre des licences, mais en fait pour pouvoir contribuer du code dans l’OCA, on doit signer ce qu’on appelle une CLA, Contributor License Agreement, et ça, ça donne… Alors il y en a plusieurs formes, la nôtre elle est très restrictive par rapport aux licences open source, donc quand vous signez cette CLA, vous donnez une copie de votre copyright à l’association. C’est-à-dire que vous conservez le vôtre et vous avez le droit de changer de licence de votre bout de module comme bon vous semble, mais vous avez aussi donné une copie de ce droit à l’association qui donc permet à l’association d’être le représentant légal de ce module. Et ça c’est le plus important, c’est d’être capable d’avoir autorité auprès de la justice par rapport à l’écosystème qui se crée dans l’OCA.

Et c’est ce qui a crédibilisé les contributions Open Source et la volonté de chacun de vouloir contribuer dans cette association parce qu’elle en détenait finalement les droits. Et donc ça c’est l’aspect vraiment très important dans cet écosystème.

Walid : au début quand l’association est créée, elle est composée de combien de membres en fait ? Qui sont les premiers qui te rejoignent dans ce mouvement ?

Joël : alors je crois qu’il y a huit ou neuf membres fondateurs qui étaient alors les principaux contributeurs en fait des différents modules Odoo, des fonctionnalités additionnelles qu’on avait besoin. Donc c’était vraiment clairement des intégrateurs petits ou moyens à travers le monde qui ont été d’accord de se fédérer et de partager ça sous une licence Open Source pour pouvoir éviter de faire le travail à double et être plus fort ensemble. Donc ça c’était vraiment la volonté. Il y avait des développeurs, des consultants fonctionnels et même certains utilisateurs et clients. Donc je dirais ça c’est vraiment un paysage assez large.

Walid : ah oui, même en tant que client on peut faire partie de l’OCA ?

Joël : absolument, oui, on a quelques clients qui sponsorisent l’OCA parce qu’ils utilisent des pièces qui leur sont indispensables pour leur fonctionnement de leur instance Odoo et les fonctionnalités qui sont nécessaires pour eux.

Walid : maintenant, l’OCA est composé de combien de membres ?

Joël : alors les derniers chiffres je ne les ai pas, mais c’est entre 350 et 400 membres qui sont des membres donc qui souhaitent participer à la vie active de l’association. Par contre il y a plusieurs milliers de contributeurs sur les modules, donc on n’est pas obligé d’être membre de l’association pour contribuer à l’écosystème de l’OCA.

Être membre, c’est une volonté de vouloir la soutenir financièrement et d’avoir une possibilité de participer à sa gouvernance et à son futur. Par contre, pour être contributeur, la seule chose qui est requise, c’est de signer cette CLA et à partir de ce moment-là, vous pouvez contribuer à tout l’écosystème de l’OCA sans aucun problème.

Le financement de l’OCA

Walid : justement, on va passer à la partie suivante, qui est, je pense, une des parties très intéressantes c’est le financement. D’où vient l’argent dont vous disposez et puis ensuite après on parlera de qu’est ce que vous en faites de cet argent.

Joël : alors l’argent de fonctionnement de l’association elle vient principalement du sponsoring et des cotisations des membres comme on vient de l’expliquer donc là c’est des gens qui souhaitent soutenir et afficher leur soutien auprès de l’association ça c’est la principale source de revenus de l’association.

Mais après il y a aussi beaucoup de revenus en temps et qui finalement sur la balance pèsent beaucoup plus lourd. C’est tout le temps que nos contributeurs nous dédient pour participer en fait à ces différents modules Open Source, à ces contributions, au bugfixes, à l’évolution fonctionnelle, à toutes les discussions qu’il y a sur les mailing-lists. Et finalement ça c’est peut-être ce qui a le plus de valeur chez nous, beaucoup plus que le budget qui permettent à fonctionner je dirais l’association de manière administrative et de financer les quelques serveurs qu’on a besoin.

Walid : vous n’avez pas de salariés dans l’association ?

Joël : alors aujourd’hui on n’a pas vraiment de salariés mais on vient d’engager une CEO, on l’appelle Virginie Dewulf, depuis cette année. Avant ça il y avait Rebecca (NDLR : Gellatly) qui nous suit en tant que secrétaire générale, qui s’occupe vraiment de toute la pratique administrative, organisation des événements, qui est d’ailleurs une personne incroyable que je remercie énormément pour toutes les contributions qu’elle a apportées à l’association. Mais aujourd’hui il n’y a pas de salariés, c’est des mandats renouvelés d’année en année.

Walid : d’accord. Tu disais tout à l’heure qu’il y avait du sponsoring aussi. Donc il y a des clients qui vous sponsorisent ?

Joël : absolument. Donc là, aujourd’hui, le sponsoring, c’est vraiment quelqu’un qui nous souscrit pour un sponsoring Gold, Silver ou autre, pour afficher son soutien à l’association. Donc là, ça lui donne le droit à une certaine visibilité sur notre site Internet, à publier un certain nombre de références clients ou différentes blog posts sur notre site web. Et puis là-dessus, il y a aussi des clients qui nous soutiennent là-dedans parce qu’ils ont besoin de certaines pièces et ils souhaitent nous soutenir économiquement, à défaut par exemple de contribuer directement dans les différents repositories de code.

Il faut savoir qu’on est aussi en train de construire une offre d’abonnement pour les intégrateurs Odoo, pour qu’ils puissent accéder à des formations, à de la documentation, probablement des boîtes à outils spécifiques. Et l’objectif c’est vraiment que les intégrateurs qui utilisent la méthode Open Source ou qui sont affiliés à l’OCA soient plus efficaces que les autres et qu’ils soient reconnus comme tels. Donc ça c’est vraiment un projet qu’on a en train de construire cette année.

Walid : dans tous les membres qu’on a parlé, donc d’entreprises qui sponsorisent, on a parlé des intégrateurs, il y a des membres individuels aussi c’est ça ?

Joël : oui, alors ce qui est très important de noter dans la gouvernance de l’association, on n’a pas souhaité depuis le début que l’association soit pilotée par des entreprises. Donc en tant qu’entreprise, je peux sponsoriser l’association, bientôt je pourrais profiter d’un programme et d’une souscription pour accéder à du contenu, à des best practices (NDLR : bonnes pratiques), etc.

Mais aujourd’hui, la gouvernance de l’association, elle est régie par ses membres. Donc l’aspect politique gouvernemental de l’association est vraiment régie par les membres eux-mêmes, et donc ce sont des individus et non pas des entreprises. Ça, ça nous paraissait très important pour garantir la neutralité de cette association et sa crédibilité aussi vis-à-vis du monde.

Walid : et donc là, le board dont tu fais partie, il est composé de combien de personnes ?

Joël : alors on est neuf aujourd’hui et le board est élu par les membres délégués. Et les membres délégués eux-mêmes ont été élus par les premiers fondateurs et ensuite chaque année par l’Assemblée des délégués. Donc dans l’association, l’organe de gouvernance de l’association, c’est les délégués, c’est ce qui constitue l’assemblée générale de l’association et c’est eux qui votent pour toutes les décisions importantes liées à l’association.

Donc chaque année on élit 10 nouveaux délégués et ces délégués ensuite élisent le board pour l’année à venir.

Walid : d’accord, je me posais une question que j’avais pas noté mais ça te prend beaucoup de temps de travail, toi par exemple, de travailler sur l’organisation et sur l’OCA par rapport à ton emploi du temps professionnel ou familial en fait ?

Joël : Jocker (rires) ! Ouais, écoute, oui, c’est… Il y a le temps que tu passes effectif dans les réunions qui est somme toute assez raisonnable, où on essaie d’être efficace, et puis après il y a un temps qui est plus difficilement calculable, c’est aussi toute la charge mentale, tout ce qu’il faut que tu cogites dans ta tête pour que tout ça, ça continue d’avancer, que ça prenne la bonne direction. Et je pense que c’est plus cet aspect là qui est pas lourd à porter mais qui est voilà qui est quand même une certaine responsabilité aussi.

Ça fait dix ans que je suis là, les gens ils ont une certaine confiance et donc tout ça ça ça cause forcément une certaine pression dans la charge mentale de tout ce que tu dois penser au quotidien.

Les projets soutenus par l’OCA

Walid : quels sont tous les projets que vous faites et puis lesquels sont les plus importants ou sur lequel vous mettez par exemple le plus d’énergie ?

Joël : alors ce qu’il faut savoir déjà c’est que ce sont nos contributeurs qui fournissent l’énergie et qui décident sur quoi et comment ils souhaitent contribuer à ces différentes repositories.

Donc nous on va avoir finalement une capacité d’orienter ou de financement relativement réduite. Ça c’est vraiment dans la main des contributeurs comme n’importe quel projet Open Source j’ai envie de dire. Maintenant, quels types de projets sont hébergés chez nous ? Je dirais, d’une part il y a des outils qui sont plutôt techniques pour aider à maintenir les instances Odoo, pour être conforme à différentes normes. Voilà donc il y a tout un tas de toolkits qui permettent aux intégrateurs de faire leur travail de manière convenable ou efficace.

Ensuite il y a aussi un autre point qui est plutôt lié aux bibliothèques de bas niveau, typiquement pour faire du traitement en batch ou du traitement asynchrone de données, pour importer des choses, pour connecter des choses, donc vraiment des couches bas niveau. Une troisième catégorie de modules ou de fonctionnalités qu’on trouve c’est toutes les alternatives open source aux versions Enterprise de Odoo. Le plus connu c’est probablement tout ce qui est lié à la comptabilité qui est basculé dans la version entreprise lors du passage à Odoo. Et donc là on a un certain nombre de modules alternatifs libres au sein de l’écosystème de l’OCA.

Ensuite il y a un projet encore pas complètement connu mais qui commence à l’être c’est Open Upgrade. Donc ça c’est cet outil qui permet de faire des migrations Odoo par soi-même, sans être dépendant de la licence d’entreprise de l’éditeur.

Et puis après, et je dirais c’est la plus large portion, c’est les milliers d’applications fonctionnelles avancées qui permettent d’adapter Odoo à tous les secteurs ou presque, et de rendre finalement Odoo beaucoup plus efficace ou plus pertinent dans un contexte pour une industrie donnée.

Walid : ok, parce que j’avais écouté une conférence ou une session de questions réponses, je ne sais plus dans quelle conférence c’était en 2022 ou 2023, bref, où vous disiez qu’en fait une partie des financements ils étaient mis sur l’OpenUpgrade de mémoire.

Joël : oui ! Alors en fait là-dessus ce qui s’est passé c’est pas vraiment qu’on a placé ça, c’est-à-dire que l’OCA fait fonctionner aussi son site internet et son système de gestion qui est Odoo à la grande surprise générale. Et donc pour migrer cette instance d’Odoo on a décidé d’utiliser OpenUpgrade. Et donc, dans les RFQ (NDLR : demande de devis) qui ont été émis pour migrer notre instance, on a décidé de financer ça au travers de la migration de notre instance pour pouvoir publier les scripts de manière libre. Il faut savoir que c’est un projet assez compliqué. Les migrations, c’est toujours très difficile. C’est compliqué de le financer convenablement. Et ça, c’est vraiment un des défis auxquels on a été confrontés.

Donc, on a trouvé cette option, cette voie pour permettre finalement de faire vivre ce projet. Et c’est quelque chose qu’on a envie d’amener encore plus loin demain pour professionnaliser un petit peu plus ce service de migration libre.

Walid : c’est pas facile sachant qu’il y a une version qui sort tous les ans, il faut tout le temps un peu rattraper le train.

Joël : exactement, c’est un vrai enjeu et je pense que ça va rester un challenge pour les années à venir de conserver finalement un projet libre pour permettre à tout un chacun de migrer ses versions communautaires.

Les relations avec Odoo SA

Walid : je voulais qu’on parle aussi des relations que vous avez avec Odoo SA. On a parlé tout à l’heure du fait que tu connaissais bien Fabien. Moi ce que j’aimerais savoir c’est est-ce que les relations sont toujours plutôt bonnes ? Est-ce qu’il y a des moments où vous avez un peu des tensions parce que vous avez des avis divergents ? Comment ça se passe un peu la relation, pas quotidienne, mais régulière avec Odoo l’éditeur ?

Joël : comme je disais la relation est vraiment amicale. Je connais Fabien depuis très longtemps. Maintenant, ce qu’il faut comprendre, c’est que le but de nos deux entités est résolument différent aujourd’hui. Odoo SA, il veut conquérir le monde sur le marché mondial des ERPs, il veut faire d’Odoo la première application métier la plus performante du monde, ça c’est vraiment là-dessus, c’est vraiment son rêve, c’est ce qu’il est en train de concrétiser.

Et puis l’OCA, en regard de ça, soutient une approche Open Source de l’outil, ou une vision open source en fait de son développement. Pour nous c’est ainsi que les clients obtiennent le meilleur retour sur investissement qui vont plus loin avec le même argent.

Notre objectif c’est toujours de rendre ce projet Odoo plus efficace, d’aider à soutenir des développements collaboratifs et aussi d’éviter le vendor lock-in (NDLR : enfermement propriétaire). Donc là-dessus, on n’a pas toujours été dans cet état-là, surtout au tout début quand il y a eu ce changement de licence, mais aujourd’hui il y a un rééquilibre qui s’est créé.

On s’est finalement avéré être un des fers de lance de l’innovation dans l’écosystème Odoo aujourd’hui. Dans les 4-5 dernières versions, il y a de nombreuses fonctionnalités qui ont été intégrées dans le cœur, qui viennent des idées de l’OCA. Donc, on fait compte que c’est un petit peu une situation gagnant-gagnant aujourd’hui, où Odoo, grâce à son succès de ce modèle Open Core, peut financer la partie open source et la version communautaire avec beaucoup plus d’efforts que ce qu’il a pu faire par le passé. L’OCA, en échange, produit de nombreux modules innovants qui finissent par atterrir dans Odoo un jour ou l’autre. Et on est une sorte de pôle d’incubation en regard de cette relation avec Odoo.

Après, on est en train de s’orienter vers offrir à des intégrateurs l’opportunité d’intégrer mieux ces modules Open Source et de pouvoir se démarquer de la concurrence ou des autres façons de procéder pour intégrer Odoo, notamment avec des modules propriétaires. Et là-dessus, c’est vraiment le programme qu’on est en train de mettre en œuvre cette année.

Walid : vous n’avez pas de personnes qui travaillent chez Odoo SA qui contribuent à des modules de l’OCA ?

Joël : ça arrive mais c’est plutôt sporadique. On a plusieurs fois des personnes d’Odoo et des développeurs qui sont venus participer à nos code sprints par exemple. C’est des volontés, des initiatives individuelles qui ne sont pas spécialement sponsorisées par Odoo. C’est des personnes qui ont envie de participer à la communauté et à la vision Open Source du logiciel et elles sont toujours les bienvenues dans nos événements.

Walid : je me posais aussi la question de savoir, est-ce qu’il y a des modules Odoo qui sont plus populaires que d’autres ? Tu as parlé de la compta tout à l’heure ?

Joël : oui, alors là-dessus je peux peu me prononcer, mais il y a certainement un subset (NDLR : sous-ensemble) de modules qui sont beaucoup plus connus dans l’écosystème de l’OCA en tout cas. Il y a toute cette histoire, ou tout ce set de modules autour de Queue Job qui permet de faire du processing et des traitements asynchrones qui est très utilisé, ou très largement utilisé. Il y a aussi un fameux module qui s’appelle MIS-Builder qui permet de construire des rapports notamment financiers, une sorte de framework qui permet de le configurer.

Voilà, on a quelques projets comme ça qui sont très largement utilisés. Mais aussi la force, je pense c’est la multitude en fait de ces quelques milliers de modules qui trouvent faire tout leur sens dans un cas précis ou dans l’autre et qui évitent en fait de payer un développement spécifique 100% par le client, mais qui permet d’être cofinancé finalement par une communauté d’utilisateurs et ça je pense c’est l’aspect le plus intéressant.

Walid : moi j’ai découvert, maintenant je m’en rappelle, c’est parce que je cherchais à faire la connexion entre un Magento et un Odoo, je suis tombé sur le module, je ne me souviens plus comment il s’appelle, enfin le connecteur qui permettait de faire la synchro entre un site E-Commerce et Odoo et c’est comme ça que j’ai découvert, que j’ai découvert ça.

Joël : ça c’est un vieux module sur lequel j’ai travaillé il y a très longtemps.

Walid : donc on a parlé des relations avec Odoo, le fait que vous arriviez à influer, enfin vous, vous n’avez pas de prise sur l’évolution, sur les features (NDLR : fonctionnalités) qui sont rajoutés dans les versions ? vous les savez en avance ? vous les découvrez au moment où c’est… enfin comment ça se… ?

Joël : Fabien c’est le seul à savoir où va aller le produit. Il a une implication très forte
dans l’orientation du produit, c’est ce qui a toujours fait sa force. Alors bon il grandit et bien sûr
qu’il y a beaucoup de relais maintenant chez Odoo avec leurs Product Owners qui font du très
bon travail. Mais je dirais Fabien est vraiment à la tête, le fer de lance du développement de
son produit et c’est ce qui a fait son succès.

Et là dedans ni les intégrateurs ni l’OCA ont vraiment voix au chapitre aujourd’hui sur la direction que prend le produit à l’avenir. Mais c’est aussi vrai que parfois ils demandent des idées et là on est toujours libres d’y contribuer et de proposer finalement les sujets sur lesquels on pense que Odoo devrait travailler plus.

Walid : une autre question je me pose : le fait de travailler chez un intégrateur Odoo un peu privilégié, parce que ça fait très longtemps et vous êtes quand même très très reconnus là dessus chez Camptocamp, et je pense c’est pareil pour d’autres intégrateurs qui sont membres de l’OCA, vous n’avez pas non plus des informations ou des manières de discuter autres avec l’éditeur ? Ou c’est deux choses complètement différentes ?

Joël : ouais, alors c’est assez peu développé cette partie-là. Mais ce qu’il faut comprendre, c’est que vu que la plupart de ce code est libre, on a finalement au jour le jour accès aux différentes contributions que l’éditeur va faire sous forme de Pull Request (PR) dans GitHub. Et donc on peut tout à fait être au courant finalement de ce sur quoi l’éditeur est en train de travailler de manière tout à fait transparente, ce qui n’est pas du tout le cas dans un autre logiciel.

Donc peut-être que c’est le moyen qui est un petit peu différent là où les éditeurs de logiciels propriétaires vont par exemple éditer une certaine roadmap (NDLR : feuille de route) ou autre. Là finalement chaque personne qui souhaite s’y impliquer peut participer et suivre en fait l’évolution du produit au travers des contributions qui sont faites au jour le jour.

L’OCA et les licences

Walid : le sujet suivant c’est les licences. Quelles licences, tu en as parlé un peu tout à l’heure, mais sous quelles licences sont les modules Odoo, enfin Odoo OCA ? Est-ce qu’ils sont tous sous la même licence ? Pourquoi cette licence là ?

Joël : alors tout ça, ça a été un jour un très fort débat. Aujourd’hui il y a vraiment un consensus et c’est très largement accepté. Il y a eu beaucoup de discussions. Donc à ce jour ce qu’il faut comprendre donc, Odoo il est édité sous la version LGPL pour toute la version communautaire et puis il y a une version, une licence propriétaire pour tous les modules dits entreprises, c’est à dire ceux auxquels on accède uniquement via une souscription.

Au sein de l’OCA, dans les statuts d’association, on a défini que n’importe quelle licence certifiée par l’OSI est acceptée. Maintenant, dans les faits, la plupart des modules sont développés en AGPL ou LGPL. On a quelques autres licences, mais la plupart ont choisi l’une ou l’autre de ces licences. Ce qui est important de comprendre, c’est que l’auteur d’un module dans l’OCA choisit sa licence. A partir du moment où c’est une licence certifiée par l’OSI, l’OCA l’accepte. Donc c’est pas nous qui distribuons, qui décidons sous quelle licence un auteur souhaite publier son travail.

Walid : je vais juste rappeler OSI, Open Source Initiative.

Joël : oui, exactement. C’est donc ceux qui réagissent en fait à tous ces différents types de licences Open Source et qui essayent d’en faire le tri et de les différencier en expliquant les avantages et inconvénients de chacun. Donc voilà, et je rappelle que là, pour que les gens poussent leur contribution au sein de l’OCI, ils doivent signer notre CLA, le Contributor License Agreement, qui donne à l’OCA une copie des droits d’auteur et qui permet finalement de protéger ce travail d’un point de vue juridique.

Walid : D’accord. J’imaginais que pour des raisons de praticité, c’était plus facile d’avoir un seul type de licence ou deux, s’il y avait quoi que ce soit, mais en fait, je peux arriver demain et prendre une licence MIT et pousser mon module sous une licence MIT, par exemple ?

Joël : absolument. Après, la compatibilité des différentes licences entre elles et de la responsabilité de l’auteur aussi. Donc ça, il faut quand même que les gens se renseignent sur qu’est-ce que ça veut dire de choisir l’une ou l’autre des licences. Il y a une certaine FAQ sur le site de l’Odoo Community Association qui permet peut-être d’aider ou d’éclairer à ce choix. Après, chacun prend les responsabilités par rapport à ça.

Odoo et les changements de licences

Walid : est-ce que tu peux expliquer pour quelle raison Odoo ils sont passés d’une licence AGPL à une licence LGPL ?

Joël : bon alors peut-être que ce n’est pas moi qui devrais répondre, mais je vais quand même essayer. Donc en fait, ce qu’il faut comprendre, c’est que à partir du moment où Odoo a senti la nécessité de changer son business model (NDLR : modèle économique) et de passer sur un modèle Open Core, ils ont besoin de pouvoir adjoindre une couche propriétaire sur un core Open Source, et la seule licence (NDLR : du type GPL) qui permet de faire ça, c’est la licence LGPL. Alors la seule licence en tout cas reconnue dans le milieu de l’open source ou de certifié par l’OSI. Là je ne sais pas exactement les termes exacts mais si on veut passer sur une licence comme ça de toutes les licences GPL, la LGPL est la seule qui permet finalement d’adjoindre un certain nombre de modules propriétaires qui cohabitent.

Et donc c’est ça qui a permis à Odoo de se développer à l’échelle mondiale depuis lors parce qu’ils ont pu faire atterrir beaucoup plus de contributions dans la version communautaire grâce aux souscriptions payantes qu’ils avaient donc l’un a financé l’autre. Le mauvais côté bien sûr il y a certaines fonctionnalités qui étaient Open Source qui ont basculé dans la version entreprise. On parlait, par exemple, de la comptabilité tout à l’heure.

Et c’est là que, par exemple, l’OCA propose un panel de modules alternatifs pour permettre aux gens de faire de la comptabilité avec une version communautaire. Je dirais globalement, ce changement, il a été bénéfique pour tout le monde. Il a permis à l’éditeur d’arriver où il se trouve aujourd’hui. Et finalement, on n’a jamais reçu autant de contributions dans la version communautaire depuis ce changement de Business Model. Donc il a été beaucoup critiqué mais aujourd’hui il faut quand même reconnaître que c’est un succès.

Walid : et pourquoi est-ce qu’il y a eu beaucoup de discussions au sein de l’OCA au départ sur les licences ? C’est un truc qui m’intéresse juste de comprendre. Les avis étaient très divergents ?

Joël : par rapport à quoi exactement ?

Walid : tu disais tout à l’heure, je te demandais quelles sont les licences qui sont reconnues au niveau de l’OCA et tu disais que c’était quelque chose qui avait fait beaucoup de débats. Je me posais la question de pourquoi ?

Joël : ouais alors ce qui a fait débat c’était le changement de Odoo, GPL à AGPL avec la version 8 et puis ensuite AGPL à LGPL. Ça ça a suscité beaucoup d’inquiétudes et il y a eu beaucoup de débats au sein de l’association ou de ses contributeurs sur alors finalement sous quel code il faut que je publie mes contributions. Et là il y avait le choix de la AGPL qui est beaucoup plus protective ou de la LGPL qui rend la chose beaucoup plus compatible.

En fait, ce qu’il faut comprendre, la différence entre la AGPL et la LGPL. La AGPL, elle a une certaine composante qui permet à un utilisateur de demander le code source de l’application. Donc ça a été fait à l’époque pour protéger les offres SaaS, quelqu’un qui ferait une contribution, et puis un éditeur qui proposerait d’un coup une version SaaS à partir de ce module publié en Open Source, et le contributeur initial finalement qui ne pourrait pas profiter des avancées que ça s’aurait mis en œuvre. Pour protéger ça, ils ont créé cette version AGPL qui donne droit à un utilisateur, quel qu’il soit, d’un logiciel open source de ce type, de pouvoir demander le code. Et donc en utilisant des modules AGPL, on voit bien qu’avec le shift (NDLR : passage) vers une version propriétaire d’Odoo, les contributeurs avaient peur que tout l’effort passé dans un module soit, en guillemets, volés par quelqu’un, packagés dans un module propriétaire et revendus à leur détriment. Pour ça, la licence AGPL était très appropriée, au contraire de la licence LGPL, qui ne protège pas contre ce type d’utilisation.

Walid : j’ai une autre question, d’expérience. J’ai bossé avec Odoo SA en tant qu’éditeur sur un de mes projets. Et en fait, ce que j’ai trouvé, c’est que finalement, si tu bosses avec Odoo, tu n’es pas du tout incité à bosser avec des modules de l’OCA, pas forcément on va dire.

Joël : non c’est très vrai, c’est pas du tout leur approche de l’intégration de leur logiciel. Dans leur vision à eux clairement, ils vont développer des fonctionnalités particulières qui manqueraient éventuellement pour tes besoins et ils vont t’en faire assumer finalement le coup.

Éventuellement ils vont profiter de ces expériences et de ces explorations au travers de leurs différents clients pour décider de renforcer leur version dans la prochaine release (NDLR : version) et d’améliorer telle ou telle fonctionnalité en fonction des expériences qu’ils ont faites sur les différents clients. Donc là, clairement, ils n’ont pas du tout une vocation de réutiliser ces briques-là. Je pense aussi que c’est pour une certaine partie une décision stratégique d’être le owner, le propriétaire de la propriété intellectuelle du travail qu’ils réalisent et en utilisant des modules OCA, du coup il se retrouverait avec des briques logicielles dont il n’aurait pas le copyright et je pense que ça, politiquement, dans une entreprise comme la leur, ça peut poser un certain nombre de questions.

Walid : je voyais bien effectivement qu’intégrer des modules qui sont faits par d’autres gens sur lesquels tu n’as pas la main sur la roadmap, tu n’as pas la main sur forcément la qualité du code, tout ça etc. Enfin c’est un peu compliqué mais le revers de la médaille c’est que potentiellement on va te redévelopper la même chose qui existe déjà dans un module et après tu vas devoir payer pour les mises à jour. Donc c’est un peu, il y a un peu les deux côtés mais ça se comprend mais d’un autre côté effectivement tu as potentiellement tu peux réinventer un peu la roue.

Joël : alors ça c’est sûr c’est un petit peu le drawback (NDLR : inconvénient) comme on dit, c’est un petit peu l’autre face de la pièce. Maintenant c’est clair qu’en tant qu’éditeur et étant donné leur position je pense que le choix qu’ils font c’est certainement le bon pour eux et si on souhaite profiter finalement de cet écosystème c’est pas auprès de l’éditeur mais il faut trouver alors un intégrateur pour faire ce travail là je crois que ça c’est très clair.

Des verticales Odoo via l’OCA ?

Walid : j’avais d’autres questions maintenant j’ai commencé à réfléchir parce que j’ai des collègues qui travaillent dans des coopératives alimentaires qui utilisent Odoo et donc il y a pas mal de versions d’Odoo FoodCoop etc. Enfin plein de trucs et tout ça et je me disais mais déjà est-ce qu’il y a des verticales comme là tu vois par exemple il y a plein de gens qui ont développé plein de modules pour gérer une coopérative alimentaire avec Odoo est-ce que tu connais des verticales de gens qui utilisent OCA pour faire leurs propres versions verticalisées d’Odoo?

Joël : alors aujourd’hui cette partie là n’est pas super bien pris dans l’OCA. C’est à dire qu’il y a plusieurs panels donc déjà première chose il y a quelques verticaux dans l’OCA notamment pour gérer les associations ou un certain nombre de choses, vous les allez trouver avec le petit préfixe vertical dans le nom des repos. Donc oui il y en a quelques uns.

Maintenant c’est pas un travail qui est super bien organisé parce que la grosse force de l’OCA c’est vraiment de proposer en fait une immense constellation de modules qui répond à différents besoins et je dirais aujourd’hui c’est encore le savoir des intégrateurs qui va savoir quel choix de modules il faut mettre pour tel métier ou pour telle industrie.

Et je pense que ce savoir-faire il fait partie un petit peu de le facteur de différenciation des intégrateurs qui utilisent cet écosystème de l’OCA par rapport aux autres. Et donc chacun a ses propres recettes un petit peu de cuisine et ça c’est une partie qui est plus délicate à partager je dirais. Donc ces verticaux on est aujourd’hui avec l’écosystème de l’OCA capable de tacler de nombreuses industries pour aller beaucoup plus loin que ce qu’on va trouver dans la boîte en standard dans Odoo, mais il faut un peu la connaissance de ses codes système pour en profiter.

Walid : et imaginons que moi, alors toute ressemblance avec un sujet d’actualité serait fortuite, imaginons que moi j’arrive, je regarde Odoo et je m’aperçois que pour mon domaine d’activité, en fait il manque des choses, tout n’est pas couvert avec et tout ça. Je me disais « si je veux faire avancer un peu mon sujet pour faire en sorte que ça profite à tout le monde, quelle est la bonne manière de faire pour faire en sorte que mes besoins, qui seraient potentiellement standards à tout mon domaine, un métier, améliore les modules OCA » ?

Joël : oui, alors déjà, ce qui est important de comprendre, c’est qu’en travaillant avec l’OCA, tout l’intérêt, c’est qu’on va déjà profiter de toute une base existante. Donc, en allant, je dirais, développer les quelques petits modules qui vont nous manquer et en s’appuyant sur la base existante, finalement, on arrive à couvrir des besoins avec très peu de développement.

Ça c’est vraiment l’immense plus-value pour les clients finaux. C’est que finalement on va financer le développement de quelques petites différences ou de quelques petits compléments de fonctionnalités. Et en s’appuyant sur le réservoir existant, on obtient tout de suite une fonctionnalité complète en n’ayant finalement financé qu’une fraction.

Et en plus de ça, ces fonctionnalités existantes se basent sur des best practices, donc on va en fait finalement profiter du meilleur de l’état de l’art et ça c’est vraiment le gros avantage pour l’utilisateur final.

Maintenant, comment faire pour arriver là-dedans ? Je dirais, déjà, il faut trouver un partenaire qui participe dans cet écosystème de l’OCA, ça c’est fondamental, ou à défaut, il faut déjà se renseigner sur ce qui existe, éventuellement challenger l’intégrateur que l’on a, lui demander d’utiliser l’écosystème, de s’y référer.

Et ensuite, je pense qu’il faut aussi veiller à ce que, à minima, le code qui est développé par l’intégrateur, on puisse en récuéprer les droits d’auteur ou qu’il puisse avoir une licence open source, pour éviter le vendre lock in et que l’on ait la liberté de main de pouvoir changer de prestataire si on n’est plus satisfait (NDLR : phrase modifiée après l’enregistrement). Et je pense que ça c’est vraiment l’important dans cette histoire. Il faut aussi comprendre qu’entre un intégrateur qui va jouer ce jeu et un intégrateur qui ne va pas le faire, il y a une différence importante.

Je peux très bien utiliser un module OCA et finalement ne pas y contribuer. Donc je vais finalement ne faire que tirer les choses de l’OCA, je vais les utiliser pour monter mon offre commerciale et finalement peut-être être compétitif. Mais pour le client final, le fait que quand je découvre des problèmes, je ne re-contribue pas les bugfixes, les améliorations que j’y apporte dans la base de code de l’OCA, et bien rapidement il y a une divergence qui se crée entre ce qu’on a fait pour un client donné et la version originale de l’OCA qui va continuer d’évoluer et en fait le coût de repasser de l’une à l’autre va toujours être à la charge du client à la fin. C’est pour ça que c’est important de trouver un intégrateur qui va jouer ce jeu, qui va aller contribuer les évolutions, les bugfixes que vous allez faire pour votre projet dans le cœur du repository original pour capitaliser finalement dessus.

C’est là où le client va bénéficier vraiment surtout sur investissement, sur la maintenance de sa solution et si on a un intégrateur qui ne joue pas ce jeu-là de manière fair-play, on va rapidement avoir des clients qui vont se retrouver à payer ces coûts de maintenance par eux-mêmes et qui n’auront finalement pas pu profiter du bras de levier que cet écosystème Open Source peut proposer.

Walid : c’est finalement la connaissance fine de tout cet écosystème sur laquelle vous voulez travailler pour proposer aux intégrateurs de monter en compétence et de travailler avec vous quoi, si je comprends bien ?

Joël : absolument. Et on aimerait aussi les rendre visibles, qu’il y ait aussi un annuaire, que les gens puissent consulter pour trouver le partenaire le plus approprié pour leur secteur d’activité, pour leur région. Donc ça, ça nous paraît maintenant la prochaine étape à franchir pour finalement offrir le meilleur aux clients finaux.

Comment se matérialise la communauté autour de l’OCA ?

Walid : cette communauté autour de l’OCA, elle se matérialise comment ? Vous avez des événements ? Vous avez quoi comme outils pour collaborer, c’est juste GitHub ? Enfin comment ça se présente un peu cette communauté ? Comment vous rencontrez, comment vous travaillez autour de l’OCA ?

Joël : déjà, il y a toute une infrastructure que l’OCA fournit. Donc là, ça va depuis toutes les règles ou, je dirais, le cadre dans lequel les gens s’engagent à travailler. Comment est-ce qu’on peut faire ces contributions ?

Donc il y a tout un tas de documentation et de règles, de processus qui permettent à chacun de contribuer, qui sont explicités et à chacun peut s’entendre. Si on ne parle pas le même langage et qu’on n’a pas la même façon de fonctionner, c’est difficile de contribuer efficacement.

Ensuite, il y a tout un tas d’infrastructures, d’outils de CI et d’autres qui permettent en fait à cet écosystème de collaborer de manière internationale et en asynchrone. Donc ça, c’est aussi très important. Et puis, enfin, il y a tout ce système de revue de code et de conseil qui se créent autour de cette communauté par les règles qui sont instaurées, qui permet à chacun de grandir quand on apporte sa contribution, d’apprendre en fait de ses pairs et de devenir finalement meilleur et d’un jour contribuer aussi à la formation des autres. Donc je dirais, toute cette notion de collaboration Peer Review (NDLR : revue par les pairs), ça contribue à faire grandir chacun.

Et puis, enfin, il y a des événements, notamment les OCA days qui ont lieu la même semaine que les Odoo Experience en Belgique. On profite du fait que la communauté internationale se déplace pour le Odoo Experience en Belgique, pour pas qu’ils payent deux billets d’avions et donc on se cale sur le même agenda pour proposer deux jours qu’elles les gens peuvent se rencontrer, je dirais, en présentiel, échanger et participer à des conférences sur plein de sujets super intéressants, que ce soit sur les modules OCA, son avenir ou simplement prendre du temps pour travailler sur des sujets compliqués ensemble.

Walid : ok, donc il y a un meeting, un gros meeting, est-ce qu’il y a des communautés un peu plus locales ?

Joël : oui, alors absolument. Donc là, tous les pays ne sont pas égaux en regard des communautés locales. Il y a des pays beaucoup plus organisés que d’autres. Les plus connus sont certainement en Espagne, au Mexique ou en Italie où il y a des communautés qui sont vraiment locales, qui sont assez fortes et là elles vont gérer leurs propres événements en promouvant aussi la manière open source, l’écosystème de l’OCA, qui vont participer en fait à former des gens et qui sont très bien organisés dans ces différents pays.

Et c’est typiquement un réseau de communautés locales qu’on souhaite développer à l’avenir parce que c’est vraiment en étant proches en fait des gens qu’on arrive à avoir un impact.

Les défis de l’OCA

Walid : d’ailleurs je n’ai pas noté dans mes questions, je voulais savoir un peu quels étaient vos défis en fait, quels étaient les gros défis pour les mois années à venir ? Je ne sais pas pourquoi je n’ai pas noté cette question.

Joël : non, non c’est une très bonne question. Alors je pense qu’il y en a beaucoup parce que Odoo il a vraiment pris un ascenseur absolument extraordinaire. Cette solution est en train d’exploser, elle a un succès fulgurant, elle a une croissance incroyable dans tous les pays et là il y a un sacré défi pour maintenir une vision ou un écosystème Open Source dans ce paysage qui devient de plus en plus compétitif et donc les défis de l’OCA c’est de continuer à grandir en face de cette expansion complètement faramineuse du produit, de continuer à promouvoir une vision Open Source et de surtout réussir à faire connaître des utilisateurs et des clients finaux toute la valeur de cet écosystème et de cette manière d’intégrer Odoo.

Donc, le défi, je dirais, c’est que les clients, ils entendent parler de l’écosystème de l’OCA, de tous les bienfaits que cet écosystème peut leur apporter. Et ça, ça va être un des défis.

L’autre défi, ça va être d’élever les intégrateurs qui participent à cet écosystème, d’être capables de les amener plus loin, de les rendre plus efficaces et d’apporter aussi, je dirais, un certain nombre de garanties, peut-être un jour sous la forme d’une maintenance pour un certain nombre de nos modules, encore à définir.

Mais voilà, donc je pense que les défis, c’est vraiment que l’OCA puisse apporter les garanties sur le travail qui a été réalisé jusqu’alors, qu’elle fasse connaître du grand public et des utilisateurs finaux, les bienfaits et les avantages qu’il y a de travailler avec un écosystème libre et pour les intégrateurs qu’ils comprennent finalement que cette vision Open Source c’est gagnant pour tout le monde, c’est gagnant pour le client au final parce qu’ils vont plus loin avec le même argent, c’est gagnant pour les intégrateurs parce que ça leur permet de participer et d’être collaboratif sur ces développements, de partager les coûts de maintenance de ces différentes fonctionnalités et à la fin c’est gagnant je dirais aussi pour le produit parce que ces innovations qui sont au qu’ils naissent au sein de cet OCA finissent par un jour ou l’autre se retrouver dans le cœur de Odoo et donc voilà je pense que les défis sont vraiment à la hauteur à la hauteur d’expansion du produit ces années.

Comment l’OCA se fait connaître ?

Walid : ouais c’est ça je me posais la question tu parles de faire connaître l’OCA. De quelle manière vous faites connaître l’OCA ? Parce que moi par exemple je sais pas dans les réunions, dans les libristes où je vais, type FOSDEM, etc. je vois pas de conférence de l’OCA tu vois et je me dis « pourquoi ? En fait si vous cherchez des développeurs et à vous faire connaître pourquoi il n’y a pas de conférence dans les grands salons dans les pays européens où il y a une conférence de l’OCA » ? Pour expliquer un peu ce qu’ils font etc. T’as bien d’autres fondations qui viennent faire des conférences pourquoi pas l’OCA par exemple c’est une question de temps, c’est une question d’argent ?

Joël : je pense un peu les deux. Et c’est d’ailleurs toute la remise en question qu’on a cette année. Je pense qu’on doit mener une petite révolution maintenant au sein du fonctionnement de cette association pour passer finalement à un autre niveau que ce que l’on a toujours été. Et on doit opérer maintenant cette mutation pour continuer d’exister demain.

Et je pense que la participation à ces salons ou à ces événements que tu mentionnes en est une. Il y a aussi tout un tas d’autres actions qu’on a listées.

On a un sacré défi maintenant devant nous pour se réinventer un petit peu, pour continuer justement d’avancer avec le produit et pour se faire connaître du grand public. Clairement, ça c’est vraiment le défi majeur de ces prochaines années.

Conclusion

Walid : On arrive vers la fin d’entretien, en tout cas on arrive vers la fin des questions que j’avais listées. Avant de te laisser la parole pour une tribune libre, je voulais te poser deux questions.

La première c’est pour résumer, qu’est ce que tu dirais à un utilisateur d’Odoo qui ne connaît pas l’OCA ?

Joël : je dirais que dans cette association il y a un savoir-faire immense et qu’il y a probablement déjà une solution à son problème.

Walid : et qu’est ce que tu dirais à un prestataire odoo qui ne travaille pas encore avec l’OCA ?

Joël : seul on va plus vite mais ensemble on va plus loin. Je lui conseillerais fortement de s’impliquer maintenant pour être reconnu avant que les clients finalement commencent à le demander. Je pense que ça, c’est vraiment à mon avis, les clients sont de plus en plus au courant en fait de ces milieux Open Source c’est plus quelque chose de tabou ou de peu connu comme à l’époque. Les gens réalisent la valeur que ça a et je suis convaincu que demain les clients vont demander ça, vont demander de l’expertise, vont demander de l’Open Source et donc premier arrivé, premier service et maintenant il faut prendre le train.

Walid : rien à voir, mais en termes de financement, avec des organismes européens, je pense à tout le fonds NGI0, ou des trucs comme ça de l’Union Européenne et tout, vous n’avez pas des choses à faire ?

Joël : c’est possible. On a commencé d’étudier ces questions. Les procédures sont assez lourdes. Aujourd’hui, il y a un vrai palier à franchir en termes de finances. Tu vois, aujourd’hui, pour arriver à faire vraiment un scale-up de notre situation, on a besoin d’un budget qui est beaucoup plus haut. Alors, nos comptes, ils sont publics, donc voilà, il n’y a rien à cacher, mais on fonctionne finalement avec très peu de moyens et beaucoup de volontariat.

Et aujourd’hui, c’est aussi pour ça qu’on a décidé d’investir dans la position de Virginie, dans cette position de CEO, pour faire avancer les projets, parce qu’aujourd’hui, on va aller beaucoup plus vite que ce que le temps du bénévolat nous permet d’aller. Et pour aller plus loin, il faut des fonds et il faut du temps. Et aujourd’hui, les membres du board qui font la plupart de la gestion de cette organisation n’ont pas plus de temps à consacrer là-dedans. Donc ça ne peut passer que par l’engagement de ressources et donc par le financement de ces nouvelles ressources.

Et donc ça c’est tout le défi auquel on va être confronté maintenant, c’est de se trouver comment on va financer ces ressources de manière pérenne pour pouvoir passer à la vitesse supérieure. Et donc on a beaucoup d’idées mais pas encore les moyens de les réaliser toutes (rires).

Walid : il n’y a pas longtemps, j’ai eu la chance d’interviewer une des personnes francophones qui travaille dans la fondation Nelnet (NDLR : Lwenn Bussière), qui est le récipiendaire des fonds du programme NGI0 et qui expliquait les financements simplifiés où tu peux avoir entre 5000 et 50 000 euros, même en tant que personne, en tant qu’individuel pour travailler sur des sujets et en fait il y a peut-être des choses à faire de ce côté là sur certains sujets justement parce que c’est très simplifié tu remplis un formulaire t’attends deux trois mois et puis après derrière on dit ok tu fais le code et t’es payé quand le code il est produit. Donc il y a des choses certainement très intéressantes à faire de ce côté là moi j’en fais de la pub dès que je peux (rires).

Joël : ouais t’as bien raison c’est une bonne remarque je pense qu’il y a des fonds qui existent aussi comme ça dans certains pays localement pour ce genre de choses et ça mériterait clairement d’être étudié. Je suis totalement d’accord avec toi.

Tribune libre

Walid : ok, on arrive à la fin de l’interview. Moi je voudrais te laisser faire une tribune libre. Si tu as un message à passer avant qu’on se quitte, je te laisse la parole.

Joël : tu me prends un défaut, je n’avais pas réfléchi à cette question libre.

Walid : j’ai oublié de la noter encore une fois. J’ai encore oublié de noter la tribune libre…

Joël : je pense que dans un premier temps, mon message, il s’adresserait tout d’abord à tous les contributeurs de l’OCA.

J’aimerais tous les remercier pour le temps qu’ils ont consacré à créer, finalement, ce que l’on est devenu aujourd’hui. Ça, c’est grâce à toutes les contributions qu’on a reçues. Donc, je pense que mon premier message, ce serait pour nos contributeurs, les remercier pour tout le temps qu’ils ont passé, pour l’excellent travail qu’ils ont fait, pour la qualité de ce qui a été produit. Et je pense que ça, c’est vraiment une super fierté. Et donc voilà, ça ce serait la première chose que j’aurais envie de leur dire.

La deuxième chose c’est que j’aimerais remercier les intégrateurs qui participent finalement à cette aventure, qui y croient, et qui ont un soutien pour la plupart indéfectible depuis de nombreuses années envers l’association, de par le temps qu’ils laissent leurs employés y consacrer, mais aussi pour tout le soutien qu’ils nous ont montré toutes ces années. Donc ça, c’était mon petit mot de remerciement.

Ensuite, j’aurais un mot pour les clients. Pour tirer le meilleur parti de votre projet Odoo, vous devez prendre en considération ce qui existe dans l’OCA. Il y a vraiment une solution pour presque chacun des problèmes que vous avez rencontrés. Il y a quelqu’un qui l’a déjà vu, il y a quelqu’un qui en a certainement déjà proposé quelque chose et plutôt que de réinventer la roue, il y a là-dedans tout un paysage de fonctionnalités qui vous attendent et donc je pense que ça mériterait à ce que vous vous intéressiez et vous avez les clés pour orienter vos intégrateurs donc le monde de la gestion d’entreprise avec Odoo de demain sera construit aussi par les demandes que vous allez formuler. C’est celui qui paye qui décide à la fin. Le client est roi et donc si vous exigez de passer sur une technologie ou sur une stack Open Source parce que vous croyez que c’est là dedans que vous allez avoir le meilleur retour sur investissement, et bien c’est ça qui va mener finalement les intégrateurs à changer de monde.

Et puis enfin, un message pour les intégrateurs : commencez de s’intéresser à l’OCA, si vous y trouvez pas votre compte, que c’est un peu brumeux pour vous de mettre le pied à l’étrier, je vous invite simplement à nous écrire, qu’on puisse vous accompagner, qu’on puisse vous expliquer comment ça marche, comment vos équipes peuvent s’impliquer dans ces projets, qu’est-ce que vous avez à y gagner ?

Parce que tous ceux qui en ont fait l’expérience jusqu’à maintenant, ils sont restés. Donc il y a certainement de bonnes raisons pour rentrer dans cet écosystème, aussi pour votre propre profit et non pas seulement par intérêt philosophique. Donc je veux dire l’OCA c’est vraiment quelque chose qui permet à tout un chacun d’en ressortir grandi. Et donc voilà, j’inviterai chacun à s’approcher de nous pour découvrir ce qu’ils ont à y gagner.

Walid : super, rien de plus à ajouter à part de dire aux auditrices et aux auditeurs de projets libres s’ils utilisent Odoo ou s’ils vont commencer à utiliser Odoo de regarder du côté de l’OCA peut-être d’aller voir les OCA Days ?

Joël : exactement!

Walid : c’est ouvert à tout le monde ?

Joël : oui c’est ouvert à tout le monde vous pouvez acheter votre ticket dès aujourd’hui sur odoo-community.org.

Walid : et chers auditrices, chers auditeurs n’hésitez pas à partager cet épisode. N’hésitez pas à réagir aussi à cet épisode. J’aime bien avoir des petits retours, vous pouvez le faire par mail ou par Mastodon ou potentiellement par LinkedIn aussi, pourquoi pas.

Donc n’hésitez pas. Je pense que ce n’est pas la dernière fois qu’on va parler d’Odoo, j’ai déjà d’autres trucs dans les tuyaux là-dessus, d’autres épisodes, mais je voulais d’abord faire l’OCA et je suis content parce que ça fait un an, que mes premiers mails c’était il y a un an, donc je suis très content qu’on ait enfin pu faire cet épisode. Joël, merci beaucoup.

Joël : avec plaisir, c’était un plaisir. Je te remercie pour ta confiance et ta patience. C’est un vrai plaisir de passer ce moment avec toi. À disposition pour les prochains épisodes, aventures ou autres, si tu le juges nécessaire.

Cet épisode a été enregistré le 3 juin 2024.

Licence

Ce podcast est publié sous la licence CC BY-SA 4.0 ou ultérieure.

Facturation électronique et ERP libres

Sommaire

• 1 Facturation électronique et ERP libres
• 2 Présentation des invités
• 3 Pourquoi la réforme et que contient-elle ?
• 4 C’est encore une fois une perte sur ses données
• 5 Qu’est-ce qu’un ERP Open Source et ses avantages sur les outils propriétaires ?
• 6 Les problématiques particulières des outils communautaires avec cette réforme
• 7 Qui travaille sur le sujet dans l’OCA et dans la communauté Dolibarr ?
• 8 L’historique de la réforme
• 9 Le réseau Peppol
• 10 Qui sont le PDPs ?
• 11 L’AFNOR et la normalisation des APIs
• 12 Le financement des travaux sur la réforme
• 13 Où en est-on du travail sur les modules ?
• 14 Les choix de l’Italie et la Belgique
• 15 Un PDP libre et l’association PDP libre
• 16 Communiquer avec l’équipe qui pilote le projet de réforme
• 17 Conseils aux entreprises pour ne pas subir la réforme
• 18 La création du fichier de meta données associé à la facture
• 19 Mots de la fin des invités
• 20 Production de l’épisode
• 21 Licence

Walid : bienvenue à toutes et à tous pour ce nouvel épisode de Projets Libres ! Aujourd’hui, on va parler d’un sujet qui est arrivé par mon travail. On a commencé à parler en interne de la facturation électronique, vous allez voir que c’est un sujet qui est pas mal d’actualité, et je me suis dit que c’était intéressant de faire un épisode là-dessus, parce que je ne suis vraiment pas un spécialiste du domaine. Et donc, grâce à Laurent de Dolibarr et Dora de Akretion, aujourd’hui, j’ai avec moi trois personnes très impliquées dans tout ce processus. Autour de la facturation électronique et de son impact pour les outils libres, en particulier les ERP.

Donc, je suis ravi d’accueillir aujourd’hui trois personnes. D’abord, Philippe Scoffoni, qui est fondateur de Easya Solutions et membre de la communauté Dolibarr. Alexis de Lattre, qui est développeur Odoo chez Akretion et membre de l’OCA, l’Odoo Community Association. Et Alexandre Spangaro, qui est expert Dolibarr chez Inovea Conseil et comptable, et aussi membre de la communauté Dolibarr. Messieurs, bienvenue sur le podcast Projets Libres. Ça me fait plaisir de vous avoir.

Alexis : merci. Bonjour.

Philippe : merci, bonjour.

Présentation des invités

Walid : pour les auditrices et les auditeurs qui ne vous connaissent pas, je vais vous demander à tour de rôle de vous présenter succinctement et de nous expliquer qui vous êtes, dans quel projet vous êtes impliqué et pourquoi vous intervenez dans cet épisode. Commençons par Philippe, si tu veux bien te présenter, s’il te plaît.

Philippe : bonjour. Donc, Philippe Scoffoni, professionnellement je dirige une société qui met en place un logiciel de gestion d’entreprise basé sur l’ERP open source Dolibarr. On fait aussi un peu de collaboratif avec d’autres logiciels libres, un peu de reporting, de BI (informatique décisionnelle) avec du Metabase, etc.

J’ai une casquette de président d’une association qui s’appelle PLOSS-RA, qui est l’Association des professionnels du numérique libre en Auvergne-Rhône-Alpes. Et puis une casquette toute récente, qui est celle d’une association, on dira peut-être deux mots, qui est PDPLibre, dont j’ai la chance aussi d’être président. Et qui est en lien avec cette question de facturation électronique.

Walid : merci. Alexis, je te laisse la parole.

Alexis : oui, Alexis de Lattre, moi, j’ai commencé dans l’open source quand j’étais étudiant au sein du projet Videolan. Certaines personnes me connaissent aussi pour une documentation que j’avais écrite sur Debian. Bon, ça date, mais parfois, je croise encore des gens qui me disent « ah, mais je me souviens de toi à cette époque ». Je travaille sur Odoo depuis 2009. D’abord, en tant qu’utilisateur pour ma propre entreprise. J’avais choisi Odoo pour mon entreprise, et après, je suis passé de l’autre côté de la barrière. Je suis devenu intégrateur. Et donc, j’ai appris le développement sur Odoo et c’est ça que je fais aujourd’hui dans mon métier.

Et au sein de l’OCA, l’Odoo Community Association, je suis surtout contributeur actif sur la partie comptabilité, les à-côtés, la partie bancaire, facturation électronique, le sujet d’aujourd’hui, la partie douane, les spécificités françaises de la comptabilité. C’est ça qui m’occupe dans mes contributions. Odoo. Et puis, on pourra peut-être parler après de mes contributions plus spécifiques à la facturation électronique. Mais peut-être qu’on va finir le tour de table de présentation.

Walid : merci. Alexandre ?

Alexandre : moi, c’est un chemin un peu particulier. J’étais chef de mission après mes études. J’étais chef de mission pendant une dizaine d’années en cabinet d’expertise comptable. Je suis un vrai comptable avec un diplôme de comptabilité. Je n’ai rien à faire dans l’informatique, va-t-on dire. C’est ce qu’on appelle un hybride. Je touche un petit peu à tout. Je suis passionné d’informatique.

J’ai eu la chance d’intégrer le monde Dolibarr depuis très longtemps. J’étais à la recherche d’un logiciel pour un de mes clients qui n’avait pas trop de moyens : on ne va pas dire, je n’ai jamais dit que l’open source était gratuit ou quoi que ce soit, attention, je n’ai pas dit ça. Mais en attendant, j’ai cherché un logiciel, je suis tombé sur Dolibarr et je me suis pris de passion pour la communauté Dolibarr, qui m’a accueilli à bras ouverts.

Et un petit peu comme Alexis, aujourd’hui, maintenant, je suis chez un intégrateur qui s’appelle Inovea Conseil qui est spécialiste Dolibarr. Et maintenant, je m’occupe de la partie Comptabilité du logiciel. Je n’ai intégré pas tout seul, mais j’ai intégré une grosse partie des fonctionnalités de la comptabilité et je suis reconnu comme tel là-dessus. Je continue de m’occuper de la partie compta, essayer de la faire évoluer grâce à l’aide de toute la communauté Dolibarr et par moi-même. Je suis également trésorier de l’association Dolibarr et je suis également trésorier de la nouvelle Association PDPLibre, dont parlait Philippe il y a quelques minutes. Voilà.

Pourquoi la réforme et que contient-elle ?

Walid : on est bien entouré aujourd’hui. J’en profite pour dire que pour les auditrices et les auditeurs, qui voudraient en savoir plus, je vous invite à écouter l’épisode numéro 1 avec Laurent Destailleur sur l’histoire de Dolibarr et comment ça fonctionne. Et aussi l’épisode dont j’ai oublié le numéro avec Joël Grand-Guillaume sur l’OCA (Odoo Community Association), ce que c’est et d’où ça vient. Cela vous permettra d’en savoir plus sur ce qu’on vient d’évoquer.

Très bien, merci pour ces présentations. Et effectivement, on va reparler de tout ça. Pour commencer, la première chose dont il faut qu’on parle, c’est cette fameuse réforme de la facturation. Et la première question que je vais laisser, c’est quelqu’un répondre, c’est pourquoi il y a eu cette réforme et qu’est-ce qu’elle contient ?

Alexis : le point de départ de la réforme de la facturation électronique, c’est d’abord l’État qui cherche à mieux recouvrer la TVA. Il cherche à mieux contrôler la collecte et la déduction de TVA, puisque les entreprises collectent la TVA et déduisent la TVA sur leurs achats, mieux contrôler ce processus. La TVA, c’est de loin le premier impôt de l’État. Ce genre de réformes, d’ailleurs, je trouve que le mot contrôle transactionnel continu, parfois. Elle est désignée sous l’acronyme CTC, Contrôle Transactionnel Continu : c’est l’État qui contrôle les flux de TVA collectés, les flux de TVA déductibles.

Ces réformes ont déjà eu lieu dans des pays d’Europe du Sud, ou même aussi depuis plus longtemps, dans les pays d’Amérique centrale, d’Amérique du Sud. C’est une réforme qui remonte progressivement. En Europe, c’est l’Italie qui a été le précurseur, qui a déjà mis ça en place. Voilà, la France qui suit, et puis d’autres pays aussi, qui s’y mettent progressivement. Et on voit ce mouvement qui remonte du sud vers le Nord, parce que les pays du Sud, qui historiquement avaient, peut-être plus de fraude à la TVA, s’ils sont mis plus tôt et les autres pays suivent le rythme.

Donc, c’est d’abord ça, le chemin. Alors, évidemment, ce n’est pas ça qui est trop mis en avant par l’État. Quand on l’écoute « il met en avant le gain d’efficacité dans les échanges inter-entreprises, le fait qu’il va pouvoir proposer des services de pré-remplissage de la déclaration de TVA, destination des petites entreprises, un peu comme le pré-remplissage de la déclaration de revenus. » ou des choses comme ça. Mais la vraie raison, c’est quand même de mieux recouvrer la TV.

Walid : à partir de quand on commence à discuter de cette réforme ?

Alexis : cette réforme, au tout début, à l’époque où elle était vraiment sous les radars, elle devait rentrer en vigueur en 2023. Mais ça, peu de gens en entendaient parler à l’époque. Et puis ensuite, il y a eu un premier report qui a donné un calendrier en trois étapes échelonnées entre 2024 et 2026. Ce calendrier a été en vigueur pendant assez longtemps, et là, la DGFiP était déjà bien en train de communiquer sur le sujet.

Et puis, à l’été 2023, juste après un remaniement ministériel, ils ont annoncé que ce calendrier était difficilement tenable parce que l’État avait commencé tardivement les développements logiciels, de son côté. En réalité, quand on voyait le moment où ils ont attribué le marché public de construction des briques logicielles du côté de l’État et le moment du démarrage des bêta-tests, il y avait moins de 18 mois entre les deux avec des énormes développements à réaliser du côté de l’État : ce n’était pas tenable.

Et donc, juste après le remaniement ministériel de juillet 2023, il y a eu l’annonce d’un report. Et on a connu le nouveau calendrier quelques mois plus tard, avec le calendrier actuel, qui est un démarrage en septembre 2026. Avec une généralisation de cette réforme, en septembre 2027. Donc, un calendrier étalé sur un an, avec seulement deux étapes, alors qu’il y en avait trois dans le calendrier précédent. Et donc, voilà, les deux grandes échéances, c’est aujourd’hui, septembre 2026, septembre 2027.
Alexis de Lattre

Walid : cette réforme, qu’est-ce qu’elle va impliquer pour les entreprises, Alexandre ?

Alexandre : elle va impliquer surtout à toutes les sociétés, toutes les entreprises. Vous me corrigerez, j’allais dire toutes les entreprises qui doivent répondre à la TVA. Je n’ai plus le terme en tête.

Alexis : assujetties à la TVA.

Alexandre : assujetties à la TVA, merci, beaucoup. Donc, les auto-entrepreneurs, les micro-entreprises chez nous, en France, en tout cas, vont être également touchées, particulièrement, je dirais, pour celles qui dépassent peut-être certains seuils. Il faudrait juste me corriger là-dessus.

Alexis : alors, là, je vais te corriger là-dessus. Les auto-entrepreneurs, certes, ils sont en dessous du seuil. Ils ne facturent pas la TVA, ils ne la déduisent pas non plus.

Alexandre : mais ce n’est pas une exonération vis-à-vis de la loi, je crois.

Alexis : c’est ça. En fait, ils sont quand même considérés comme des assujettis, mais avec un régime d’exception. Mais ils sont quand même dans la définition des assujettis à la TVA. Et donc, ils sont pleinement concernés par cette réforme. Ils sont dans la réforme alors qu’ils ne facturent pas la TVA. Donc ça, c’est une petite subtilité.

Alexandre : c’est bien, ça, merci beaucoup, Alexis.

Du coup, toutes les sociétés, enfin, tous les types d’entreprises, quasiment en France, vont être touchées par cette réforme. Ça va consister à se munir d’un logiciel, parce que je connais encore des sociétés qui sont capables de faire des factures. Sur Canva, Paint, Word et Excel. Désolé, même sur LibreOffice ou quoi que ce soit, peu importe. En fait, toutes ces sociétés-là vont être obligées de se munir d’un logiciel, ou du moins d’un logiciel de facturation, qui soit en SaaS (Software as a Service), qui soit installé sur les ordis. Mais il faudra que, forcément, ce soit connecté à un prestataire, à un partenaire de dématérialisation, dans une plateforme de dématérialisation partenaire, ce qu’on appelle un PDP.
Alexis Spangaro

Et donc, cette réforme va imposer de connecter pour envoyer les factures. Pour l’instant, on parle uniquement en premier lieu des factures B2B, entre professionnels, ce qu’on appelle le e-invoicing en premier lieu. Et ensuite, il y aura une seconde phase pour laquelle on a très peu d’informations, le e-reporting. Elle n’est à mon sens pas encore calé au niveau de la réforme aujourd’hui. Alors, on en parle, mais on n’a pas d’informations plus que ça au niveau du format. Alexis, je te vois opiner de la tête.

Le but après, ça va être d’envoyer les factures via ces plateformes sans passer par email, tout simplement. Désormais, on passera par ces plateformes-là qui se chargeront d’envoyer au client final, au professionnel, client final : ça lui enverra la facture. Il pourra soit la récupérer sur la plateforme avec laquelle il a contracté, soit il pourra prendre cette facture et s’il y a des services additionnels ou si le logiciel qui reçoit le permet, il pourra peut-être intégrer automatiquement cette facture.

Pour le e-reporting, ça va consister à remonter tous les x jours des informations sur les ventes pour les clients particuliers. On ne va pas dire les professionnels, mais les particuliers. Et donc, ça permettra d’envoyer un récap. On n’enverra pas le détail des factures, on enverra un récap. C’est juste là où pour l’instant, je trouve qu’on a peu d’informations sur le format final. On ne sait pas ce qu’on va devoir envoyer. Cela arrivera en second plan.

Alexis : en tout cas, effectivement,

Il y a vraiment ces deux composantes dans la réforme, le e-invoicing, donc la facturation électronique en B2B. Ce sont les choses dont on parle le plus, ce qui est le plus compréhensible et sur lequel on a une obligation. Mais il y a aussi des gains de productivité liés au fait qu’on va recevoir des factures structurées, par un canal unique, alors qu’aujourd’hui, concrètement, nos factures fournisseurs, on perd de plus en plus de temps à les chercher sur les différents portails des différents fournisseurs. On va se connecter sur le portail EDF pour récupérer sa facture d’électricité, sur le portail de son fournisseur d’accès Internet, de son portail de son fournisseur de téléphone mobile… enfin on passe le temps à aller chercher dans ces différents portails nos factures fournisseurs. Là, elles vont toutes arriver à un endroit unique, c’est-à-dire auprès de son PDP, sa plateforme de dématérialisation partenaire. Elles vont arriver, pas seulement sous une forme de ce que j’appelle un PDF bête, c’est-à-dire un PDF simple, sans rien, mais elles vont arriver sous une forme structurée, c’est-à-dire sous la forme d’un fichier XML ou d’un fichier PDF avec un XML à l’intérieur. Et c’est ce fichier XML que l’on va pouvoir exploiter pour lire la facture de façon 100 % fiable, sans recourir à des systèmes de reconnaissance de caractère.
Alexis de Lattre

Donc ça, c’est cette partie facturation électronique qui est généralement ce que les gens retiennent de la réforme. Et puis la partie cachée de l’iceberg, c’est le e-reporting. Ça, c’est la partie casse-pieds. Et dans le e-reporting, c’est non seulement de remonter à l’administration fiscale les ventes les ventes B2C qui ne donnent pas lieu à émission de factures par son PDP, mais il y a beaucoup plus que ça dans le e-reporting : on doit aussi remonter les informations de paiement des factures en TVA sur encaissement et les informations de cycle de vie des factures.

L’idée c’est de partager entre clients et fournisseurs des informations sur l’avancement du traitement de la facture, de dire « oui, c’est bon, je l’ai bien reçu, je l’ai bien reçu dans ma comptabilité, je l’ai approuvé, je l’ai mis en paiement, j’ai reçu l’argent, j’ai effectivement été réglé ». Et de partager ces statuts de facture entre clients et fournisseurs. Il y a des statuts qui sont facultatifs et des statuts qui sont obligatoires, notamment remonter les informations de paiement sur les factures en TVA sur encaissement c’est obligatoire.

Et dans le e-reporting, il y a aussi remonter les opérations exonérées de TVA, par exemple, les ventes à l’export, les ventes en intracommunautaire envers des professionnels de l’Union européenne. On doit aussi remonter les acquisitions intracommunautaires. Donc, c’est assez lourd. On remonte beaucoup de choses. En fait, on remonte toutes les informations dont l’administration a besoin pour pré-remplir la déclaration de TVA. Et comme il y a beaucoup de choses sur la déclaration de TVA, on doit remonter pas mal de choses en e-reporting.

Alexandre :

c’est sûr que cette réforme va permettre d’accentuer les contrôles normalement sur les délais de règlement également. C’est la fameuse loi LME de 2008 qui disait que si on paye au-delà d’un certain temps, il y a des amendes, il y a des intérêts. Il y avait des amendes pour les mauvais payeurs, mais ça nécessitait d’aller faire des contrôles sur place et de vérifier quand est-ce que ça avait été réellement réglé et autre. Là, ça pourrait être quasiment automatisé parce qu’on saura quand ça a été réglé quand ça passe par les plateformes.
Alexis Spangaro

Walid : Philippe, est-ce que tu veux rajouter quelque chose ?

Philippe : il va falloir réfléchir aussi au comment s’organisent les choses parce qu’aujourd’hui, on a parfois des tenues comptables ou des modes de gestion d’entreprise qui sont hybrides, c’est-à-dire qu’il y a une partie, par exemple, les ventes, les facturations de vente qui sont émises par le logiciel de gestion d’entreprise.

Et puis, c’est le cabinet comptable qui se charge des achats. Il va falloir se poser des questions d’organisation et on va peut-être se retrouver à devoir gérer plusieurs PDP pour une même entreprise : un PDP pour envoyer ses factures, parce que je le fais depuis mon logiciel de gestion, et le comptable va dire « oui, mais pour recevoir les factures, comme c’est, c’est moi qui les saisissais jusqu’à présent. Vous allez devoir vous inscrire sur ce PDP ». Et puis, effectivement qui signale les paiements ? C’est le cabinet comptable qui fait le rapprochement bancaire.

Donc, il va y avoir un petit peu des questions comme ça aussi, autour de la réforme. Je pense qu’ils vont imposer une réflexion sur l’organisation des relations entre l’entreprise et son cabinet comptable. Quand on ne tient pas toute la comptabilité intégrale dans son propre logiciel de gestion. Ce qui est quand même, dans les grosses entreprises, c’est le cas. Pour les TPE, PME, c’est parfois un peu plus éclaté en termes de rôle. Là, il y a aussi quelque chose qu’il va falloir intégrer.

C’est encore une fois une perte sur ses données

Walid : pour finir sur ce sujet dans la trame, il y a une ligne qui dit « c’est encore une fois une perte de contrôle sur ces données ». Est-ce que tu peux expliquer ce que ça veut dire, s’il te plaît ?

Philippe : perte de contrôle de données au sens où, jusqu’à présent, on avait un logiciel de gestion. On générait ses factures, ses achats. Et toutes ces données-là étaient potentiellement stockées dans son logiciel, dans sa base de données, qu’on pouvait avoir sur ses propres serveurs, etc. Donc, on avait une forme de maîtrise ou de contrôle de ce que font nos données. Demain, avec la réforme, je vais devoir effectivement transmettre toutes ces données à des tiers.

Alors, dans la réforme initiale, ce qu’on n’a peut-être pas dit, mais on devait quand même avoir un portail public de facturation (PPF), c’est-à-dire qu’on devait être en mesure de déposer et de recevoir toutes ces factures en dialoguant directement avec l’État que l’on peut considérer comme un tiers de confiance pour l’envoi de nos données. Mais là, on va se retrouver dans une situation où, potentiellement, on envoie tous nos achats, toutes nos ventes à des tiers. Alors, bien entendu, le contrat actuellement, ils seront tenus de ne rien en faire. J’ose espérer que ce sera bien écrit dans les contrats. On n’en a pas encore vu de contrat, mais ça va commencer. Et que cet aspect-là sera relativement clair. Mais je peux être chez le même PDP que mon concurrent. Et je ne sais pas, ça veut dire que peut-être que le PDP, il peut voir à quel prix j’achète chez mes fournisseurs versus mon concurrent. On peut imaginer tout un tas de trucs. Et puis, après, derrière, il y a des problématiques de sécurité. Quid si un jour, il y a une faille de sécu chez un PDP ?
Philippe Scoffoni

Certes, ça va être des flux de factures, mais certains vont faire de l’archivage, du stockage. Qu’est-ce qui se passerait si quelqu’un pouvait mettre un mouchard et écouter toutes les factures qui rentrent, qui sortent c’est quand même une masse d’informations. Il y a certaines professions, je crois que c’est encore en discussion dans les groupes AFNOR ou autres, type, avocat ou autre, qui clairement, disent « attendez, nous on a du secret professionnel à protéger, on voudrait soit être exclus, soit qu’il y ait des conditions particulières pour nous ».

Qu’est-ce qu’un ERP Open Source et ses avantages sur les outils propriétaires ?

Walid : ok, je vous propose qu’on n’aille pas forcément plus loin sur cette partie de présentation. Dans une deuxième partie, peut-être pour les gens qui ne sont pas familiers avec les ERP libres et le monde open source. Autour de ces sujets-là, est-ce que quelqu’un voudrait présenter assez brièvement ce que c’est qu’un ERP open source. Et quels sont les avantages par rapport à d’autres outils propriétaires ?

Philippe : le logiciel libre, c’est la maîtrise de son informatique, c’est être en mesure de savoir ce qui s’y passe, de pouvoir intervenir dessus de la façon la plus simple possible, soit même directement, soit avec l’aide de prestataires qui en ont la compétence. Donc, c’est quelque part maîtriser son outil informatique. Et là, on parle du logiciel de gestion d’entreprise, le logiciel dans lequel on va venir mettre toutes les données de l’entreprise, toutes les informations de l’entreprise. Et ça, c’est une grosse partie, souvent de la valeur d’une entreprise, d’une activité, d’une structure, quelle qu’elle soit, coopérative, associative, quelque soit son statut juridique.

J’ai envie de dire que c’est important qu’on puisse s’appuyer sur un ERP Open Source : c’est un ERP dont on peut accéder au code source, c’est-à-dire qu’on est en capacité de lire le code source, de le modifier, de le faire évoluer, de le repartager, etc. On a un accès libre à tout ça, on va pouvoir plus facilement l’adapter à son besoin. C’est beaucoup plus difficile de faire évoluer un logiciel, dit propriétaire, avec un éditeur qui a une roadmap (feuille de route), avec des échéances fixées, rigides, et où ça va être très compliqué d’influer sur certaines fonctionnalités de l’outil.

Avec l’open source, je ne dis pas que c’est forcément beaucoup plus simple, mais en tout cas, c’est beaucoup plus ouvert et beaucoup plus possible. Et puis, les logiciels libres, les ERP open source, sont souvent by design (dès leur conception) évolutifs, faciles à compléter, donc conçus pour être augmentés potentiellement. On parle beaucoup de souveraineté, souveraineté, c’est avoir le contrôle de ces outils. Les ERP open source, ça le permet, versus effectivement un outil, une plateforme en ligne où, le jour où elle s’arrête, il faut échanger ses conditions tarifaires. Ou on nous la débranche, mais on perd tout.

Les problématiques particulières des outils communautaires avec cette réforme

Walid : on va prendre Dolibarr et Odoo parce que les personnes autour de la table sur ces sujets que vous travaillez, est-ce qu’il y a des défis particuliers de travailler avec des outils open source sur toutes ces problématiques réglementaires ? Si on prend le cas, par exemple d’Odoo à travers l’OCA, Alexis, est-ce qu’il y a des problématiques particulières de travailler avec un Odoo, avec de l’OCA, par exemple ?

Alexis : je pense que la difficulté, c’est qu’on ait des communautés de geeks qui aiment bien écrire du code et faire des trucs sympas au niveau du code. Et puis là, il faut se plonger dans des articles de loi, dans des spécifications très fonctionnelles, éditées par l’administration fiscale ou dans des domaines qui, historiquement, ne sont pas nos domaines d’expertise.

On vient du logiciel libre, qui avait des grosses parts de marché sur les systèmes d’exploitation des serveurs, les serveurs de messagerie, des choses comme ça, puis maintenant, on est dans le monde des logiciels de gestion, et puis on va jusqu’à la partie fiscalité. Et on va toujours plus loin, on repousse la frontière du logiciel libre, toujours plus loin. Donc, il faut trouver des gens qui acceptent de se plonger dans les spécifications de ces impératifs fiscaux, de ces changements réglementaires, de suivre, parce que ça bouge.

Et puis cette réforme l’a montré, parce qu’on a eu vraiment beaucoup de revirements et beaucoup de rebondissements imprévus. Donc on n’est peut-être pas au bout de nos peines, parce que c’est pas impossible qu’il y en ait d’autres. Donc il faut qu’il y ait des gens dans des communautés plutôt passionnées de code et de geekerie, qui se plongent dans des spécifications fiscales, et comprennent quelque chose à tout ça. Je pense que c’est ça l’enjeu. Après, quand on arrive à trouver des gens qui se plongent là-dedans, ça permet de toujours repousser plus loin la frontière du logiciel libre.
Alexis de Lattre

Qui travaille sur le sujet dans l’OCA et dans la communauté Dolibarr ?

Walid : et typiquement, là, au niveau de l’OCA, il y a d’autres personnes à part toi qui travaillent sur ces sujets-là ?

Alexis : pour l’instant, je pense que je suis un peu tout seul, mais disons que je suis soutenu par d’autres personnes qui font mon soutien moral et psychologique. C’est vrai que, pour la France, c’est essentiellement moi, mais dans les autres pays, il y a les mêmes problématiques. Et donc, dans l’OCA, il y a des communautés qui implémentent les spécifications pour l’Espagne, pour la Belgique, etc. Donc, c’est répliqué à l’échelle de chaque pays. Après, je ne suis pas tout seul, non plus. Il y a d’autres gens dans la communauté française qui s’intéressent aussi à ces sujets-là, même si c’est quand même souvent moi qui suis de très près à ces sujets-là.

Walid : et côté Dolibarr, Alexandre ?

Alexandre : du côté, Dolibarr, c’est un petit peu différent. J’ai l’impression qu’on a des DevCamps tous les six mois qui permettent de valider les nouvelles versions.

Là, par exemple, on était au Devcamp de Valence, avec Philippe, on a commencé à alerter au Devcamp de Bordeaux, je crois. On a mis ça en avant en disant qu’il fallait qu’on travaille sur le sujet. Parce qu’on en discute entre nous, mais il faut vraiment que ce soit un sujet commun. La problématique que je dirais par rapport à l’OCA, c’est qu’on a l’impression que c’est peut-être que la communauté française qui en discute. Alors que Dolibarr est international, on va dire. Pour l’instant, on a peu d’échos des autres communautés parce que la plus grosse communauté sur Dolibarr reste la communauté française. Avec l’arrivée au 1er janvier 2026 pour la Belgique, de la facture électronique, on voit par exemple qu’il y a des mouvements sur le Dolistore, c’est notre Marketplace (place de marché) pour Dolibarr.
Alexandre Spangaro

Et sur le Dolistore on voit apparaître des modules pour le réseau Peppol, dont on parlera un tout petit peu plus tard, qui vont être des autres méthodes de communication. Parce que la facture électronique arrive dans l’Europe, vraiment un peu partout dans l’Europe. Pour l’instant, nous, on a l’impression de se concentrer vraiment sur la communauté française. Moi, je veux bien aider les autres communautés, mais c’est déjà assez compliqué avec la France. Donc il faudrait effectivement que peut-être d’autres groupes se constituent, c’est là toute la difficulté. Et pour qu’un groupe se constitue, il faut des gens motivé, et c’est toute la difficulté.

Philippe : on met en place ce qu’on appelle des groupements d’intérêts financiers et fonctionnels (GIFF). Il y a le mot financier dedans, parce qu’effectivement, c’est du temps, tout ça, qu’il faut essayer de financer. Donc ces groupements, aujourd’hui, sont composés d’intégrateurs. C’est le modèle qu’on a trouvé aujourd’hui dans la communauté Dolibarr. On crée des groupes de travail sur des thématiques, facturation électronique, l’UI, l’UX, etc.

On a eu la facture de situation, qui était un peu le premier bêta-testeur, le POC (Proof of concept) de ce concept, qui a validé quelque part le concept et le fonctionnement de notre communauté. Voilà, donc ce sont les intégrateurs qui se réunissent, qui mettent des sous sur la table pour développer une fonction et la facturation électronique. En tout cas, côté Dolibarr, c’est le modèle, pour l’instant, mis en place avec un groupe de travail qui bosse sur les specs. Et voilà, on va commencer à produire un peu de code, normalement, d’ici la rentrée.
Philippe Scoffoni

Alexandre : voilà, c’est ça.

Walid : on a présenté dans les grandes lignes la réforme et pourquoi elle est mise en place, mais qu’est-ce que ça veut dire concrètement pour Dolibarr et pour l’Odoo Community. Qu’est-ce que, dans le cas d’ Odoo, par exemple, ça change entre un Odoo édité par l’éditeur Odoo SA et l’OCA ?Quelles sont les problématiques qui sont spécifiques à ces outils communautaires qui seront, par exemple, différentes si on prend un Odoo Enterprise chez Odoo SA ? Alexis, est-ce que tu veux commencer ? Est-ce qu’il n’y en a peut-être pas en fait ?

Alexis : non, dans le monde Odoo ce qu’on a vu, notamment en Italie, l’Italie étant le pays européen qui a été le premier à avoir ce genre de réforme, que c’est l’éditeur qui implémente la réforme. De son côté, dans ses modules officiels, la communauté aussi fait son implémentation, indépendamment de celle de l’éditeur.

Du coup, on se retrouve avec le choix entre adopter l’implémentation communautaire de cette réforme ou l’implémentation faite par l’éditeur. Je vais rester neutre, chaque implémentation a ses avantages et ses inconvénients : souvent, en tout cas, c’est ce qui a été l’expérience en Italie, et c’est l’expérience que j’ai eue en France sur d’autres sujets, c’est que peut-être que la communauté va plus loin dans les détails, rentre plus en profondeur dans les scénarios un peu particuliers.

L’éditeur, quelquefois, va un peu moins profondément dans certains scénarios spécifiques. Alors, ça ne facilite pas le choix de l’utilisateur, qui peut être un peu désorienté avec le fait qu’il y ait deux implémentations, en prime concurrentes, on va dire alternatives, celle de l’éditeur, celle faite par l’OCA. Mais c’est aussi, finalement, la vie des communautés du logiciel libre, d’avoir parfois des implémentations concurrentes.

Bon, là, de toute façon, le calendrier est serré. On a des échéances. Nous, en tant que communauté, on ne peut pas non plus se permettre d’attendre que l’éditeur, même si, évidemment, il promet qu’il sera prêt en temps et en heure, mais moi, en tout cas, je ferai aussi l’implémentation dans l’OCA, quoi qu’il arrive. Et puis, après, les législateurs auront le choix entre choisir l’une ou l’autre. C’est comme ça que ça fonctionne, finalement.

Walid : côté Dolibarr, où là, il n’y a pas d’éditeur

Philippe : il n’y a pas d’éditeur, donc il n’y aura forcément qu’un seul module qui sera communautaire. Voilà, c’est un peu plus un peu plus simple, on sait qu’on est obligé d’y aller. Il n’y a personne qui viendra faire le boulot à notre place.

Alexandre : c’est toute la différence. Nous, on partira plutôt sur un module. Il n’y a pas d’entreprise, il n’y a pas d’éditeur qui s’occupe de ça. Donc, effectivement, le but est de créer le fameux GIfF dont parlait Philippe. La finalité de ce groupement va être de créer un module qui permettra, on va dire, d’être multi-PDP : il va permettre de se connecter aux différentes plateformes. Là, on attend juste que les PDP commencent à fournir leurs plateformes avec les API standardisées de l’AFNOR, qui ont été récemment publiées.

Les plateformes sont en train d’adapter leurs API avec ça. On attend de pouvoir s’y connecter et de jouer avec les fameuses sandbox (bacs à sable) pour qu’on puisse commencer à envoyer nos factures.

L’historique de la réforme

Alexis : peut-être que c’est le moment de revenir un petit peu sur ce qui s’est passé, parce qu’on n’a pas expliqué à nos auditeurs.

Walid : justement, je voulais revenir là-dessus, vas-y, je te laisse…

Alexis : donc, du coup, pour expliquer ce que vient de dire Alexandre et remettre en perspective : historiquement, dans cette réforme, il y avait la promesse de Bercy de dire « vous aurez le choix entre, soit vous raccorder à des PDP, donc ces prestataires privés, qui vont vous permettre d’échanger vos factures électroniques, donc à la fois émettre et recevoir, mais vous pourrez aussi vous connecter au Portail Public de Facturation, au PPF », un portail développé par Bercy, gratuit, par opposition aux PDP, privés et payants, pour vous acquitter de toutes vos obligations. A la fois en termes de facturation électronique, mais aussi de e-reporting.

Et donc, ça a été la promesse de l’État. Un des enjeux, c’était de montrer qu’on pouvait basculer dans cette réforme avec une plateforme gratuite proposée par Bercy. Bercy avait lancé des appels d’offres auprès de grandes sociétés françaises de développement pour développer cette brique logicielle. Et finalement, ils ont renoncé. En octobre 2024, ils ont annoncé l’abandon de ce portail public de facturation ouvert à toutes les entreprises françaises. Finalement, ils ne l’ont pas dit publiquement, mais ils ont acté l’échec de ce projet de développement logiciel. Il faut lire entre les lignes. Les communiqués de Bercy n’admettent pas ça publiquement. Et donc ils ont dit « vous serez obligés de passer par les PDP, donc les plateformes privées
Alexis de Lattre

On ne s’y attendait pas, c’était annoncé en octobre 2024. Et c’est la première fois qu’on a vu les syndicats de petites entreprises monter au créneau sur cette réforme. Finalement, c’était plutôt intéressant de voir qu’enfin, les syndicats d’entreprises s’intéressaient à cette réforme qui allait les impacter. Et on a vu tous les syndicats de petites entreprises protester sur le fait que, du coup, une réforme promise comme étant gratuite pour les entreprises allait finalement occasionner des abonnements à payer auprès de ces PDP. C’était un peu une rupture de la promesse initiale. Et donc, il y a eu cette vague de protestation.

Le réseau Peppol

Alors maintenant qu’on a un peu de recul, ce changement a aussi amené l’État qui, jusqu’à présent… en fait, il y a ce réseau… j’ai parlé un peu du réseau Peppol.

Peu de gens en ont probablement entendu parler parce qu’en France, jusqu’à présent, on snobait un petit peu ce réseau Peppol. Peppol, c’est-à-dire Pan-European Public Procurement Online. C’est une initiative lancée dans les années 2010 par la Commission européenne, qui avait, sur subvention publique, lancé la construction d’un réseau pour que les administrations publiques puissent recevoir les factures de la part des prestataires qui travaillent pour l’administration. Donc, au début, c’était un réseau d’échange, surtout orienté pour que les entreprises privées envoient leurs factures aux administrations publiques, au tout début. En tout cas, c’était l’objet des premières subventions européennes qui ont commencé à financer ce réseau.

Et puis, après cette phase initiale sur fond de la Commission européenne, il y a eu la création de la session OpenPeppol en 2012, si je ne dis pas de bêtises, qui constitue la gouvernance de ce réseau. Et avec vraiment, cette évolution, c’est pas juste les factures à destination des administrations publiques, mais c’est toutes les factures échangées entre entreprises qui peuvent passer sur le réseau Peppol.

C’est un réseau qui passe par Internet, avec des propres protocoles d’échange basés sur des protocoles existants, mais un réseau sécurisé avec une signature de la facture, signée par l’émetteur. Ça doit normalement éviter l’effet du spam qu’on a dans nos emails ou des choses comme ça,, le risque que ce soit transféré à des réseaux d’échange de factures.

Et donc, l’État français, qui, jusqu’à présent, a un peu snobé ce réseau Peppol, avec l’échec du développement du Portail Public de Facturation, a orienté tout le secteur vers l’adoption du réseau Peppol en disant : l »es prestataires privés, les PDP, s’échangeront les factures entre eux via ce réseau Peppol ». C’est ce qui a été acté au niveau de l’écosystème. Et c’est intéressant car ça évite de réinventer la roue : on adopte un réseau qui a fait ses preuves, qui est existant, qui est déjà pas mal utilisé, surtout en Europe du Nord, qui était un peu les premiers à adopter de façon relativement large le réseau Peppol. Voilà, donc éviter de réinventer la roue. Et puis, c’est l’ouverture à l’international car à partir du moment où les PDP se connectent et s’échangent des factures en trop via le réseau Peppol, c’est aussi la possibilité de dire : « si j’ai une facture à envoyer à un client, par exemple dans l’Union Européenne, dans l’hypothèse où l’entreprise destinatrice serait elle-même raccordée au réseau Peppol, de pouvoir l’envoyer via son PDP jusqu’au destinataire dans un autre pays ». Donc, ça ouvre une réforme qui, des franco-françaises, s’ouvre un petit peu sur l’international avec ce réseau.
Alexis de Lattre

Qui sont le PDPs ?

Walid : le PDP, c’est une plateforme, c’est une entreprise française ? C’est des entreprises existantes ?

Alexis : oui, c’est une entreprise… nouvelle, éventuellement, mais en tout cas, le PDP, c’est une entreprise.

Il y a aussi des prestataires étrangers qui se lancent dans le marché des PDP en France. Et donc, il faut voir la PDP finalement comme un point d’accès français au réseau Peppol avec une sorte de fonction mouchard qui envoie une copie de la facture au fisc. Voilà, il faut voir ça finalement. Moi, c’est comme ça que je décris un PDP. C’est un point d’accès au réseau Peppol avec cette fonction mouchard.
Alexis de Lattre

J’envoie une copie de la facture qu’on émit au fisc. Et ça permet au fisc de voir passer l’ensemble des factures dans les échanges. Inter-entreprises. Et c’est aussi via ce PDP qu’on enverra notre e-reporting, donc ces informations supplémentaires qu’on doit remonter quand on est en régime de TVA, normalement tous les dix jours. On doit envoyer ce e-reporting via son PDP pour qu’il l’envoie à l’administration fiscale. Et donc, c’est ça le rôle des PDP, émettre. Et servir aussi un peu de boîte de réception de nos factures fournisseurs.

Walid : Philippe ou Alexandre, est-ce que vous pouvez expliquer, on adhère à un PDP, est-ce que c’est un contrat différent ? Est-ce qu’il y a des prestations différentes ? Comment est-ce que ça se passe ? Ça va être intéressant pour la suite de la discussion, je pense.

Alexandre : bien sûr. Donc, première chose, je vais rajouter un acronyme, enfin, ce n’est même pas un acronyme, le PPF, quand il a disparu, a été remplacé, c’est un peu le mouchard dont parlait Alexis à l’instant. Ce n’est pas tout à fait la même chose, mais l’État a tout de même un service qui devra mettre en place, qui est l’annuaire centralisé.

L’annuaire centralisé, ça va être que chaque entreprise va devoir se déclarer dans cet annuaire centralisé. L’annuaire est sorti courant juin de cette année. Donc, si vous devez recevoir, je pense, des mails d’éditeurs ou autre. Pour vous inciter à vous inscrire sur cet annuaire centralisé. En tout cas, cet annuaire centralisé, toutes les personnes qui sont couvertes par cette réforme, d’ici à juin 2026, devront…

Alexis : septembre 2026.

Alexandre : pardon, excuse-moi, septembre. D’ici à septembre 2026, devront faire une inscription. Alors, soit on passe par un logiciel, soit on passe par un… j’ai vu qu’ils allaient mettre en place un CERFA. Pour l’instant, je n’ai pas d’informations là-dessus et je ne pense pas que ça se passera comme ça. J’ai vu que les PDP, dans leur plateforme allaient s’occuper des statuts, enfin, allaient s’occuper des inscriptions à l’annuaire. Et donc chaque entreprise devra déclarer à quel PDP elle s’inscrit. C’est surtout ça à retenir.

L’annuaire centralisé est géré par l’État et chaque société devra choisir le PDP auquel elle s’inscrit. Elle n’a pas le droit d’être inscrite d’office par un PDP, ça, c’est important. Et donc, une fois qu’elle aura choisi, c’est par là, que passeront les transactions. Quand on enverra une facture, même quand on en recevra, on devra forcément passer par ce PDP là, parce qu’on l’aura déclaré auprès de l’annuaire centralisé. Après, ça n’empêche que ce qui a été prévu, c’est qu’on puisse changer de PDP. C’est important, on ne s’engage pas pour 25 ans.
Alexandre Spangaro

Mais ça veut dire qu’après, derrière, il y aura forcément des contractualisations. Il y aura des contrats avec un certain nombre d’envois, je pense, des quantités d’envois de factures qui seront mis en place. Et potentiellement, il y aura peut-être des périodes d’engagement. Ça, je ne peux pas le dire. Nous, on commence à voir apparaître sur les tarifs qui ont été proposés par certains PDP, on voit des périodes d’engagement qui ont été proposées.

Walid : juste pour te couper, un PDP, c’est quoi ? C’est une entreprise qui fait PDP ou par exemple, c’est un éditeur qui a ce service-là supplémentaire ça correspond à quoi ?

Alexandre : un PDP c’est un peu de tout Walid. C’est soit des nouveaux entrants, et on a possibilité de s’inscrire en tant que PDP.

Pour être PDP, il faut être SecNumCloud au niveau de l’infrastructure, il faut être SecNumCloud. Il faut être ISO 27001 si je ne me trompe pas. Une fois qu’on a ça, après, il faut mettre forcément une plateforme en place. Il faut se connecter, je ne sais plus tout exactement. Vous me corrigerez, messieurs, mais en tout cas, il y a une grosse infrastructure à mettre en place et ça coûte énormément d’argent. Donc, il y en a déjà qui se sont lancés là-dessus dans le but d’être financés. Mais ça reste des acteurs privés. Alors, je ne sais pas exactement combien ils sont aujourd’hui. On va dire une centaine.

Alexis : il y en a à peu près une centaine.

Alexandre : oui, c’est ça. Je ne sais pas s’ils les ont atteints, mais en tout cas, il y a une centaine de PDP qui sont aujourd’hui, on va dire, référencés, qui sont en cours d’immatriculation, enfin de validation, je vais le dire comme ça, parce qu’ils ont déjà fait une demande d’inscription. Et donc, ils vont être validés d’ici la fin de l’année 2025. Et donc, ils deviendront officiellement PDP. En attendant, ce sont des plateformes de dématérialisation de partenaires, le fameux PDP.

Pour ces plateformes, le but ça va être de faire passer un maximum de factures par eux, bien sûr, pour rentabiliser leur modèle, on s’en doute. Mais après, il y a des nouveaux acteurs et il y a des anciens acteurs qui s’adaptent. Il y a déjà des sociétés qui étaient spécialisées dans l’OCR et autres, qui ont décidé, bien sûr, de s’orienter là-dessus. Pour prendre un nouveau marché qui est en cours de création.

Alexis : il faut bien redire, je pense que les PDP, il faut être immatriculé par Bercy. Et donc, c’est Bercy qui publie la liste des PDP qu’elle a immatriculée. Il y en a qui sont en train de constituer leur dossier, qui vont être immatriculés dans les mois qui viennent.

Mais à la fin, quand même, le PDP, qu’on doit choisir, il doit être sur la liste officielle de Bercy. Et l’autre chose que je voulais dire, c’est parmi la centaine de PDP qu’il y a aujourd’hui, on trouve des acteurs historiques du monde de la facturation électronique, il y a des nouveaux acteurs, parfois des éditeurs, logiciels de logiciels de gestion, comme Sage ou comme Cegid, qui se disent « tiens, moi je vais me montrer ma propre PDP ». Donc, on peut supposer que leurs services de PDP sont réservés à leurs clients, qui utilisent leurs logiciels et qui ne vont pas ouvrir leurs services aux autres logiciels.

Il y a des PDP qui, au contraire, voilà se montent indépendamment de tout éditeur pour essayer de séduire un maximum d’éditeurs pour se raccorder à eux. On voit certaines grandes entreprises qui montent leur PDP, a priori uniquement pour leurs besoins propres, qui ne vont pas commercialiser leurs services.

On voit des entreprises du monde, de la facturation électronique, par exemple, des entreprises qui opéraient les réseaux Edifact, et qui se disent « moi je suis déjà au milieu des flux dans des industries automobiles, dans des industries de grande distribution où je vois passer des flux Edifact de commandes de factures. Je vais proposer à mes clients de garder ce réseau-là et moi, je vais envoyer la copie des factures au fisc dans le format attendu et faire les conversions de format pour pouvoir dialoguer avec toutes les entreprises françaises». Il y a différents acteurs.

Donc même s’il y a une centaine de PDP immatriculés aujourd’hui, les PDP qui proposent publiquement leur service à toutes les entreprises, cela représente un nombre plus restreint de quelques dizaines qui, vraiment, sont susceptibles de proposer leur service à n’importe quelle entreprise.

Walid : Alexandre, tu voulais compléter

Alexandre : c’est exactement ce que vient de dire Alexis. On en parlait, il y a des PDP qui ne proposeront pas leur service car c’est vraiment pour des besoins internes. Je pense notamment, on a vu dans la liste, le groupement Leclerc, je ne sais même pas s’il n’y a pas Lidl ou quelque chose comme ça. C’est vraiment pour des besoins internes. Il y a des PDP qui vont vendre leurs services et il y en a d’autres, on a eu des annonces comme quoi ça allait être gratuit, mais c’est des éditeurs, logiciels et en fait, ils vont proposer ça sur leur logiciel, à eux, tout simplement.

Walid : Odoo, elle ne va pas essayer d’être bien PDP ?

Alexis : c’est ce que Fabien Pinkears, le patron, le fondateur d’Odoo, a annoncé sur LinkedIn, dans une petite vidéo qu’il a envoyée, ou un petit message qu’il a envoyé sur LinkedIn il y a environ deux mois. De mémoire. Ils ont dit qu’ils allaient devenir eux-mêmes PDP et qu’en parallèle, s’ils n’étaient pas prêts à temps, ils travaillaient aussi avec des PDP existants pour passer peut-être au début ou en attendant d’être totalement prêts. Ils étudiaient toutes les opportunités, mais c’est ce que Fabien Pinkears a dit dans un message sur LinkedIn.

L’AFNOR et la normalisation des APIs

Moi, je voulais juste, peut-être rajouter un petit point qu’Alexandre a abordé. Avec l’abandon du portail public de facturation, toutes les entreprises vont choisir des PDP. Ça fait 4,5 millions d’entreprises françaises assujetties à la TVA qui doivent se choisir un PDP. Ça, c’est un des enjeux qui s’est sorti assez rapidement. Quand Bercy a renoncé à proposer le portail public de facturation, c’est de se dire « ok, « on a une jungle de PDP, une centaine de PDP qui nous sont proposées.

Si chaque PDP a sa propre API, nous, on va implémenter l’api d’un PDP, puis, le jour où on va en choisir un autre, il faut réimplémenter l’API. Et ce n’est pas juste une API, parce qu’en fait, il y a beaucoup, beaucoup d’échanges. Des requêtes pour consulter l’annuaire, les requêtes pour envoyer les factures, pour recevoir les factures, pour envoyer le reporting, pour envoyer les informations. Il y a beaucoup, beaucoup. Ce n’est pas juste un appel d’API ». On parle de beaucoup de requêtes différentes à envoyer pour beaucoup de choses différentes.

Si chaque PDP a sa propre API, le coût de changer de PDP va être élevé. Et quand le coût de changement de PDP est élevé, évidemment, la concurrence ne fonctionne pas très bien et donc les prix restent élevés. Par exemple, changer de banque pour une entreprise, même pour un particulier, mais on va parler des entreprises, forcément, on change d’IBAN. Il faut changer tous les prélèvements automatiques. C’est un boulot qui est assez rébarbatif. Et donc, c’est casse-pieds de changer de banque, donc on ne le fait pas très souvent. Et les prix restent élevés parce que les banques savent bien que c’est compliqué de changer de banque. Et c’est un message qui a été entendu par Bercy, qui a mobilisé l’écosystème avec ce travail fait en partenariat avec l’AFNOR pour proposer une API standardisée. Maintenant, on appelle ça l’API AFNOR. Il n’y a pas d’obligation réglementaire pour l’instant de la part des PDP d’implémenter l’API AFNOR, mais tous les PDP avec lesquels j’ai eu l’occasion de parler, m’ont promis qu’ils allaient implémenter l’API AFNOR. Et donc, c’est la promesse de, à priori, pouvoir changer et passer d’un PDP à l’autre relativement facilement grâce à cette standardisation des API des PDP. Donc ça, c’est une bonne nouvelle de ces derniers mois. C’est que ce projet d’API standard Afnor est sur de très bons rails. Et les spécifications étaient publiées il y a un ou deux mois.
Alexis de Lattre

Le financement des travaux sur la réforme

Walid : maintenant, il y a un sujet qui sera intéressant d’aborder. C’est tout ce travail que vous faites là. C’est du temps, c’est des discussions, ça coûte de l’argent. Comment est-ce que vous financez ce temps ? On peut commencer par Alexis. C’est toi, en tant que personne qui fait ça ? Est-ce que tu as de l’argent particulier pour travailler là-dessus ou est-ce que tu prends ton temps pour le faire ?

Alexis : je pense que c’est plusieurs mois de travail d’implémenter cette réforme. Ce ne sont pas des jours ou des semaines. Ça se compte en mois de travail pour implémenter la totalité, c’est-à-dire la partie e-invoicing, mais aussi e-reporting.

Walid : tu veux dire de développer et tester le module ?

Alexis : de développer et tester.

D’implémenter ce module dans l’OCA, je pense que ça se compte clairement en mois de travail. Il ne faut pas négliger le travail à réaliser. Et donc, pour ça, on n’a pas bouclé le financement, etc. Mais ce qu’on envisage, c’est à la fois des ressources de nous, d’Akretion, donc l’entreprise pour laquelle je travaille, qui vont être mises là-dessus, aidées par peut-être des financements de la part de nos propres clients, déjà qui sont évidemment tous concernés par ça et qui vont nous aider à financer ce travail. Et il se trouve que moi, depuis 4 ans maintenant, j’ai lancé une offre de service à destination de mes confrères intégrateurs français. Donc, j’ai une quinzaine d’intégrateurs qui ont souscrit cette offre de service.
Alexis de Lattre

En fait, comme je maintiens beaucoup de modules dans la location française dans toute cette partie comptabilité, historiquement, j’avais pas mal d’intégrateurs qui me faisaient travailler en me disant « ah tiens Alexis, il y a un de tes modules là dont j’ai besoin sur telle version, allez je te paye une ou deux journées pour que tu me portes le module sur la nouvelle version, j’en ai besoin pour un de mes clients, etc. ».

Donc, j’avais comme ça pas mal d’intégrateurs qui faisaient appel à moi. Sur des petites missions ponctuelles, surtout pour porter des modules ou ajouter des fonctionnalités sur un modèle existant, en me disant « c’est toi qui l’as développé, tu seras plus rapide que nous à le développer. ». Et donc, j’avais comme ça avec pas mal d’intégrateurs français qui me faisaient travailler. Je suis revenu voir ces intégrateurs-là en proposant un package que je leur fais payer chaque année. Alors évidemment, ils sont libres d’y souscrire ou pas, mais j’ai une quinzaine d’intégrateurs qui ont souscrit.

Et donc ça me donne un budget chaque année pour financer des développements : déjà,pour maintenir l’existant, parce qu’il y a un maintien d’existant avec Odoo, qui évolue très vite avec une nouvelle version qui sort chaque année. Ensuite il faut que tous ces modules soient disponibles sur les nouvelles versions, sous peine de mourir ou d’être mis sur le côté. Enfin l’année prochaine, le gros de ce budget va être dédié à ce gros chantier de réforme de la facture électronique.

Donc finalement, ce sont les intégrateurs qui financent : je pense aussi que dans le monde Dolibarr, ce sont aussi les intégrateurs qui financent avec de l’argent qui provient de leurs clients, directement ou indirectement. C’est comme ça que ça va se passer.

Walid : l’OCA n’a pas vocation à mettre de l’argent sur la table ?

Alexis : ça pourrait, l’OCA a des budgets pour financer un certain nombre de choses, mais là, on parle quand même de quelque chose de spécifique à la France, qui ne bénéficie pas du coup aux autres pays. Et donc, pour l’instant, l’OCA finance plutôt des projets qui bénéficient à l’ensemble de ses adhérents, donc à l’ensemble des pays.

Walid : côté Dolibarr, Philippe, est-ce que tu veux un peu expliquer comment vous êtes organisé ?

Philippe : c’est le système des groupements d’intérêts financiers fonctionnels dont je parlais tout à l’heure, qui revient effectivement à avoir aujourd’hui des intégrateurs.

Mais ça ne suffira pas, parce qu’effectivement, comme le dit Alexis, on ne parle pas de 10 jours de développement, on parle effectivement de plusieurs mois, donc d’un budget forcément conséquent. Donc, on fera probablement un bout de financement participatif, des choses comme ça, qu’on va monter pour effectivement amener les utilisateurs aussi de Dolibarr à venir contribuer financièrement au développement de l’outil. C’est un vrai challenge, encore une fois, et puis, on est avec la contrainte de dire que ça ne concerne que la France aussi.
Philippe Scoffoni

Donc voilà, même si, effectivement, il y a une grosse, grosse communauté française sur laquelle on peut s’appuyer, mais ça va être, je pense, du financement intégrateur, plus une contribution qu’on ira chercher, solliciter auprès de nos utilisateurs / clients.

Alexandre : moi, je voulais juste rajouter.

Un point qui n’a rien à voir avec ce podcast, qu’on pourrait d’ailleurs aborder dans un autre podcast. C’est la difficulté qu’on a, c’est qu’on a une autre réforme qui est tombée en même temps, la Loi de Finances 2025 et qui porte sur la certification des logiciels de caisse. Ça fait double travail, ça fait double financement à trouver, on va dire, et c’est ça qui complique énormément les choses.
Alexandre Spangaro

Alexis : ça, c’est clair que d’avoir ces deux échéances qui se percutent en termes de calendrier. C’est vraiment pas sympa, parce que c’est dans les deux cas ça fait des gros budgets, des grosses contraintes. Et donc, de la part du législateur, d’avoir fait tomber ça en même temps, ça, c’est vraiment pas sympa.

Walid : mais ça impacte tout le monde, pas forcément que les logiciels libres.

Alexis : oui, ça impacte, tout le monde, c’est sûr. Mais bon, les acteurs libres n’ont pas les mêmes moyens que des gros éditeurs propriétaires, pour qui les budgets de R&D se comptent en millions d’euros. Nous, ce n’est pas l’unité dans laquelle on compte nos budgets de R&D.

Philippe : pas encore.

Où en est-on du travail sur les modules ?

Walid : où est-ce que vous en êtes de vos différentes discussions ? Puisque là, ce que je comprends, c’est qu’il va falloir développer un module, certainement choisir un ou des PDP, avec qui, peut-être que vous discutez déjà. Où est-ce que vous en êtes de vos réflexions et du travail à l’heure actuelle ? On peut commencer par Dolibarr, où est-ce que vous en êtes ?

Alexandre : le DevCamp de Valence, qui avait lieu courant juin, a permis de valider les discussions qui sont en cours. On avait même un PDP qui était directement présent durant le DevCamp. Le premier avec qui on avait discuté, il y en a d’autres qui, potentiellement, commencent à communiquer sur les réseaux pour rassurer les utilisateurs : déjà de Dolibarr pour commencer, parce que ce que je disais tout à l’heure, vu que l’annuaire centralisé a ouvert au mois de juin, là, c’est au niveau communication, tous les PDP, tous les éditeurs de logiciels communiquent en disant « attention, attention, votre logiciel ne va plus être compatible ».

Ce que je souhaite dire, c’est NON. En tout cas, pour Dolibarr, on fera le nécessaire. On y sera dans les temps. C’est juste qu’il faut patienter et ne surtout pas s’inquiéter. Tout sera fait et il y aura des communications officielles qui seront lancées durant le quatrième trimestre 2025. Ça débordera probablement, bien sûr, sur le premier trimestre 2026. Mais en tout cas, on sera là et on sera dans les temps.

Ça, c’était la première chose que je voulais préciser. Mais ce qui a été fait, surtout pendant ce DevCamp, ça a permis d’expliquer comment on allait essayer de procéder. On a présenté les travaux du groupement. On était en attente, on a l’impression d’être passif, on se prépare. Mais vu qu’on n’avait pas encore accès au bac à sable des API standardisés de l’AFNOR, pour l’instant, on ne codait pas. Donc, on est vraiment dans l’expectatif en disant on va essayer que ça se passe comme ça. C’est toute la difficulté. Au final, ce qui a été fait, c’est que le groupement du côté Dolibarr va, dès la rentrée, se mettre à coder avec l’argent qu’on avait déjà réuni auparavant de par les nombreux intégrateurs Dolibarr et les Preferred Partners Dolibarr.
Alexandre Spangaro

Du coup, on va proposer un module que moi, personnellement, j’appelle Multi PDP. Et donc le but, c’est d’avoir un module spécialisé, maintenu par Dolibarr, en tout cas, là où se trouve l’ERP, mais ce sera un module qui sera indépendant, parce qu’on ne veut pas que ce soit un module qui soit raccroché dans le corps de Dolibarr. On doit pouvoir le mettre à jour assez rapidement, et donc, s’il y a vraiment une équipe de maintenance là-dessus, le but du module, c’est qu’il soit mis à jour assez rapidement s’il y a des changements, des trucs à adapter.

On ne veut pas qu’il y ait besoin de faire une mise à jour de Dolibarr à côté. Ça va vraiment être un module externe, sachant qu’on a une autre problématique, bien sûr, c’est que Dolibarr étant international, c’est un module qui ne concernera que la France, principalement. Dans un premier temps, on ne voulait pas le mettre dans le coeur et que ce soit proposé à tout le monde, parce qu’il n’y avait pas d’intérêt. Mais après, la principale difficulté, c’est au-delà du code, ça va être bien sûr de communiquer et d’être le plus clair possible devant l’agressivité de certains autres éditeurs de logiciels.

Même les experts comptables essayent déjà de se renseigner là-dessus, de pousser certains clients à s’enregistrer sur leur PDP. Parce que dans chaque cabinet, par exemple, il y a un éditeur forcément, qui est présent. En général, il n’y en a qu’un. Et donc, tous les éditeurs forcent, le milieu de l’expertise comptable, forcent à empiler un maximum de clients pour s’inscrire sur le PDP. Donc, voilà pour nous. Les discussions, en tout cas au niveau de la communauté Dolibarr, Philippe, si tu veux rajouter quelque chose, mais en tout cas, tout est en cours et ça va encore prendre un petit peu de temps. Et donc tout s’étalera sur le quatrième trimestre 2025, voire premier trimestre 2026.

Philippe : d’un point de vue, pratique, on a effectivement un premier PDP qui nous ouvre des accès à ces API normalisés. Voilà. Ça ne nous engage pas plus loin avec eux, ça nous permet de commencer à travailler. Ce n’est pas un choix arrêté pour l’instant. Le but, par contre, nous, ça va vraiment être qu’on ne travaillera que sur les API normalisées. On n’a pas prévu d’implémenter les API d’un PDP en particulier.

Alexandre : après le Dolistore étant notre marketplace de modules, peut-être que des PDP proposeront des modules pour eux. Là, on ne sait pas, c’est ouvert. On est dans le monde du libre. S’ils souhaitent proposer un module qui ne communique qu’avec leur service, ils pourront le faire. Mais nous, bien sûr, au niveau de la communauté Dolibarr, forcément, on mettra plus en avant les modules multi-connectés et surtout qui seront mis à jour constamment par la communauté.

Walid : et Alexis, du côté de l’OCA ? où est-ce que tu en es ?

Alexis : nous, on a, comme Dolibarr, déjà les briques de facturation électronique pour émettre et importer des factures au format Factur-X ou au format UBL: ce sont des choses qu’on a depuis longtemps. Dans le cas d’Odoo, on était même les tout premiers ERP à supporter la norme Factur-X quand elle est sortie en version bêta, en juillet 2017. On était vraiment précurseurs du format Factur-X, et donc on est à peu près dans le même tempo, c’est-à-dire qu’on attendait de pouvoir faire des choses complètement, avec un annuaire en production et des spécifications qui, maintenant, sont finalisées.

Elles ont encore rechangé avec l’abandon du portail public de facturation. Donc, il y a eu des gros changements dans les spécifications en décembre, à la suite de ce gros revirement de Bercy. Et donc, le but, c’est de travailler sur le troisième, quatrième trimestre pour être prêt début 2026, commencer à faire des bêta-tests et, quoi qu’il arrive, être prêt en septembre 2026 pour le démarrage de la réforme.

Les choix de l’Italie et la Belgique

Walid : je fais une aparté. Quel choix ont fait les Italiens et les Belges ? Ils ont fait le choix d’une plateforme unique, aussi, d’un système de PDP, comme en France ?

Alexis : j’ai peur de dire des bêtises, mais pour moi, la plateforme italienne est assez différente parce qu’elle est, à ma connaissance, assez centralisée. J’ai peur de dire des bêtises, donc je ne préfère pas dire. Par contre, les Belges, c’est vraiment, je pense plus proche de ce qu’on fait en France, avec vraiment un réseau d’échange via Peppol et de dire que toutes les entreprises belges seront raccordées au réseau Peppol et c’est Peppol qui permettra d’échanger les factures. Et je suppose qu’ils ont le même mécanisme où le point d’accès Peppol envoie une copie à l’administration fiscale.

En tout cas, je pense que la réforme en Belgique, elle va être assez proche de ce qui va se faire en France avec Peppol au centre. Et a priori, ils vont commencer avant nous, puisque d’après ce que je comprends, ça devrait démarrer en janvier 2026.

Walid : Alexandre ?

Alexandre : je voulais dire, nous, on était sur un modèle en Y, en quelque sorte, où il y avait un PDP. Là, si vous tapez modèle Y sur un moteur de recherche, vous trouverez sûrement un schéma qui sera assez équivoque. Maintenant, avec l’abandon du PPF, ça a changé, mais cette participation des plateformes de dématérialisation partenaire, sous-entendu privé, ce n’est pas totalement méchant quand je dis ça, c’est a priori un modèle franco-français.

De ce que j’ai compris, de tous les autres pays européens, soit ça passe par le réseau Peppol, Alexis pourra me corriger, soit peut-être ça passe par des partenaires, enfin des partenaires privés, mais en attendant, il y a toujours l’État qui n’est pas loin et qui met toujours quelque chose pour raccrocher ces données de manière à ce qu’ils servent et qu’il puisse travailler.

C’est vrai que l’abandon du PPF a été un gros coup et ça a changé quand même pas mal de choses. Parce que même nous, dans la communauté de libre, on avait commencé à travailler dessus et tout d’un coup, on a l’impression d’abandonner quelques mois de travail quand ils ont abandonné le portail public de facturation. C’était assez dommage. Pour autant, ça aurait été un portail qui aurait été assez semblable pour ceux qui connaissent au portail Chorus. Après, c’est pareil, pour l’instant, on n’a parlé que des professionnels, on n’a pas encore parlé du gouvernement, ça ne fait pas partie de la réforme jusqu’à présent.

Alexis : en tout cas, dans la mauvaise nouvelle de l’abandon du PPF, qu’on a vraiment pris sur le moment comme une mauvaise nouvelle, la bonne chose, c’était l’adoption de Peppol, et puis surtout aussi le fait qu’on est sur quelque chose avec Peppol, de plus décentralisé. Parce que finalement, ce portail public de facturation, on pouvait s’attendre à ce qu’il capte une grosse partie des utilisateurs attirés par l’aspect gratuit du portail public de facturation.

Et que quid le jour où ce portail public est en panne ? Si les deux tiers des entreprises sont raccordées à ce portail public et que c’est leur canal pour émettre et recevoir des factures, le jour où il y a une panne sur le PPF, on pouvait être un peu inquiet. Vraiment, cet aspect. Single Point of Failure (SPOF, point de défaillance unique), comme on dit dans le métier. Et donc là, avec cette nouvelle architecture où tout le monde doit passer par son PDP avec Peppol au milieu, on voit quelque chose de plus décentralisé.

Donc, a priori, pas de Single Point of Failure, à condition qu’il n’y ait pas un PDP qui se mette à dominer le marché parce qu’il aurait une énorme part de marché et qui deviendrait à lui tout seul un Single Point of Failure. Mais ça, c’est à nous, en tant que clients, de ne pas tous choisir le même PDP pour ne pas recréer un Single Point of Failure, qui aurait été celui du portail public. Si les entreprises se répartissent bien entre de nombreux acteurs, ça va réduire cet effet de « qu’est-ce qui se passe ce jour où il y a un PDP qui est en panne ? »
Alexis de Lattre

Un PDP libre et l’association PDP libre

Walid : il n’y a pas eu de discussion pour faire un PDP libre ?

Philippe : si. Quand l’annonce du PPF est tombée, moi, j’avais lancé ça sur LinkedIn. Alors, dans les faits, il y a eu quelques discussions sur le sujet derrière. Bon, on l’a dit tout à l’heure, il y a des contraintes techniques au niveau de l’infrastructure, d’ISO 27001, mais ça encore, on avait des groupements qui ont réfléchi au sujet, des gens qui pouvaient faire. Mais c’était surtout le coût de financement de cette plateforme, qui reste relativement élevé, je trouve ça un peu fou.

Finalement, on va développer 90 fois la même chose, je caricature, mais pas loin. Le coût global de la réforme électronique au niveau français est quand même, avec le modèle choisi, je trouve probablement démesuré. Je doute que tous ceux qui ont développé des plateformes rentrent dans leurs frais, entre ceux qui n’ouvriront pas, ceux qui se feront racheter…

Enfin on va voir, je pense pendant plusieurs années beaucoup de mouvements autour de ces plateformes, à mon avis. Donc voilà, on avait évoqué ça. Pour l’instant, on en est resté là. C’est le but de l’association dont je parlais tout à l’heure, PDPLibre. Alors, ça va aller à l’encontre de ce que dit Alexis, parce qu’effectivement, l’idée, c’est de se regrouper pour négocier des tarifs de gros auprès d’un PDP, faire une centrale d’achat quelque part. On ne prendra pas tout le marché français.
Philippe Scoffoni

Alexis : non, c’est ça. Ce sera juste les acteurs de des ERP libres. Ça va, il n’y a pas de risque de créer à nous-mêmes un Single Point of Failure. Il n’y a pas de risque.

Philippe : normalement, je ne pense pas. Mais ceci dit, on a aussi des plateformes SaaS propriétaires qui sont dans le groupement. Mais l’idée, c’est surtout d’essayer de faire que cette réforme coûte le moins cher possible aux assujettis, à ceux qui auront l’obligation de la respecter. C’est le premier objectif.

Et puis, même si on avait lancé des appels de pied, j’avais essayé via des structures comme le TOSIT ou autre, qui regroupe des grosses entreprises du CAC 40, qui aiment a priori l’open source en disant « les gros, Orange, SNCF et compagnie, comment vous allez faire ? » vous ne voudriez pas financer une plateforme open source que vous pourriez réutiliser chacun dans votre coin, un peu comme on parlait de ces PDP qui se sont montés pour répondre aux besoins internes d’entreprises.

Je trouve dommage car je pense qu’il y aurait eu moyen de faire quelque chose. Et ces entreprises-là auraient eu le moyen de financer ce genre de choses. Il aurait fallu conduire le projet, le mener, c’est encore un autre débat mais cela aurait peut-être été possible par ce biais. Mais pour l’instant, ce n’est pas le cas. Ça reviendra peut-être.

Communiquer avec l’équipe qui pilote le projet de réforme

Walid : autre question, est-ce que vous, à votre niveau, vous avez un moyen de remonter aux instances qui gèrent ce projet de facturation électronique. Des questions ou est-ce que c’est plutôt du top-down (les décisions partent du haut vers le bas) ? En gros, les informations descendent, mais il n’y a jamais rien qui remonte ?

Philippe : le problème, je pense qu’on n’est pas dans le groupe, on n’est pas dans le bon sérail. Aujourd’hui tous les PDP sont dans les différents groupes de travail. Donc, on peut assister il y a des événements entre guillemets publics, on peut être présent et effectivement discuter avec des acteurs. Mais aujourd’hui, je pense que c’est plutôt les PDP, quelques gros PDP qui donnent le LA, j’ai l’impression.

Alexis : moi, de mon côté, comme j’étais un des précurseurs sur ce sujet, notamment de l’implémentation de la norme facture, etc., ça m’a mis en contact avec Cyrille Sautereau, par exemple, le président du Forum National de la Facture Électronique, qui est un peu l’association qui regroupe l’écosystème de la facture électronique depuis un certain nombre d’années. Et du coup, ça m’a mis un peu dans ce petit milieu de la facturation électronique. Et cela m’est utile, notamment quand j’ai des questions auxquelles je n’ai pas la réponse en lisant les volumineuses spécifications techniques. Donc j’arrive comme ça à obtenir des réponses de gens de l’écosystème.

C’est utile pour ne pas rester bloqué sur un problème dans son coin et de pouvoir en référer à des gens qui sont au cœur des spécifications AFNOR et de la mise en œuvre de cette réforme, et de pouvoir bien interpréter, ne pas faire des erreurs d’interprétation qui, après nous conduiraient à des mauvaises architectures logicielles, des choses à revoir, etc.

Donc, voilà, moi, j’ai des contacts historiques par mon implication, notamment dans la norme Facture-X, qui m’ont permis d’avoir accès. Et avec Philippe, on avait déjà discuté de ça, de se dire, si nous, entre acteurs du libre, qui sommes confrontés à la même implémentation, si on a des difficultés, des questions, qu’on puisse s’échanger entre nous et s’appeler entre nous et s’entraider parce qu’on va être confrontés aux mêmes subtilités, aux mêmes problématiques d’interprétation des choses pas claires dans les specs et ça, ce sera un bon test. D’ailleurs, est-ce qu’on arrive à s’échanger, à s’appeler, à s’entraider dans nos implémentations respectives ?

Philippe : pour moi, c’est une des missions de l’asso PDPLibre, qui regroupe effectivement des gens de tout type de communautés, Dolibarr, d’où des éditeurs, effectivement, d’autres communautés de logiciels libres ou des éditeurs propriétaires, de mettre en place effectivement quelque chose pour qu’on puisse co-développer. Pouvoir se poser des questions et échanger sur cette problématique.

Alexis : moi, par exemple, j’avais une réflexion ces derniers temps.

Quand j’avais implémenté la norme Factur-X dans Odoo, au début, j’avais implémenté ça dans un module. Odoo, directement à l’intérieur du module. Et après, je m’étais dit, finalement, je pourrais sortir une grosse partie du code qui est à l’intérieur du module, dans une librairie Python pour en faire bénéficier l’ensemble de l’écosystème Python. Donc d’autres logiciels concurrents, entre guillemets, d’Odoo qui vont avoir à implémenter cette norme Factur-X ont une librairie qui est à leur disposition : ça va les aider à implémenter la norme Factur-X. Et c’est ce que j’avais fait. J’avais déplacé mon code dans la librairie et puis moi, je m’étais mis à utiliser ma propre librairie que je maintiens aujourd’hui. Et là, je me pose la question, est-ce que ça a du sens, par exemple, dans l’implémentation des API, AFNOR, des PDP, d’avoir une partie du code la plus grosse possible qui soit dans une librairie Python, qui puisse ensuite être utilisée par d’autres logiciels en Python ? Cela pourrait être utile.
Alexis de Lattre

Et d’ailleurs, dans ma librairie Factur-X, je vois des gens qui ne sont pas des logiciels en Python, mais qui l’utilisent quand même par une exécution en ligne de commande dans des logiciels dans d’autres langages, parce qu’ils n’ont pas trouvé dans leur propre langage une librairie qui générait du Factur-X. Et du coup, ils utilisent ma librairie Python pour ça. Donc, on verra. Mais en tout cas, je suis en réflexion là-dessus pour mutualiser un peu ces développements. Au moins au sein de l’écosystème Python.

Conseils aux entreprises pour ne pas subir la réforme

Walid : il y a toute une dernière partie qui va être plutôt des problématiques de conseil. Quel conseil vous donneriez à des entreprises, à des TPE, à des PME, pour ne pas subir cette réforme, même à d’autres entreprises un peu grosses qu’est-ce que vous diriez à ces entreprises pour ne pas subir la réforme ?

Alexandre : au niveau de la communauté, je te laisserai comment compléter, Philippe. Première chose, c’est éventuellement de suivre la communauté Dolibarr via les différents réseaux sociaux, de s’accrocher, de suivre les communications. On s’efforcera de diffuser les communications vers les clients finaux, en tout cas ceux qui font partie des clients des intégrateurs Dolibarr. On essaiera de leur communiquer les infos, mais ce qu’il faut dire, c’est que déjà, on se rassure, pas besoin de se précipiter et de s’enregistrer au niveau de l’annuaire centralisé.

Alors, PDP, je viens d’apprendre aujourd’hui que ce n’est plus un PDP, maintenant, on va parler de plateforme agréée. Ça vient de sortir aujourd’hui. Donc plus besoin de s’enregistrer sur une plateforme agréée, via l’annuaire centralisé, pas besoin de se précipiter, il faut attendre. Attendez fin d’année, début d’année. De toute façon, quand le module sera disponible, on préconisera, peut-être quelques PDP à utiliser au début, et puis ensuite le but, ce sera d’élargir la liste.

Une chose qu’il faudra faire, Philippe en rajoutera là-dessus, c’est bien sûr de vérifier ces données. Il faudra bien sûr vérifier si ces fiches sont bien remplies, si les SIREN sont bien remplies. Plein de choses à faire sur le sujet-là. Parce que si on a 5000 fournisseurs et qu’il y a juste le nom et l’adresse d’inscrite, ça va être assez compliqué. Il faut s’y prendre en avant. Commencer à travailler sur ces données dès aujourd’hui, essayant de les qualifier, surtout en vérifiant qu’on a un maximum d’informations sur chaque chose. Une fois que ce sera fait, la prochaine étape, ce que je disais, quatrième trimestre 2025, premier trimestre 2026, bien sûr, essayer d’avoir une version de Dolibarr qui soit un peu à jour. Dolibarr, pour l’instant, c’est fixé la version 18 minimum.
Alexandre Spangaro

Bon, après, s’il y a des problématiques, technique, ça, ce sera une autre histoire, mais on s’est fixé la version 18 qui, au passage, est une LTS depuis peu de temps. Et si vous êtes sur une vieille version de Dolibarr, renseignez-vous comment se mettre à jour, contactez vos intégrateurs pour éventuellement prévoir une mise à jour. La prochaine version est la version 22, qui sortira probablement à la rentrée, aucune obligation de se précipiter sur cette version 22 parce qu’elle sera un petit peu jeunette et il y aura probablement quelques bugs. Ou plutôt, prévoir peut-être une version antérieure, la 21 ou la 20, qui sont relativement stables.

Et une fois que vous aurez mis à jour votre Dolibarr, que vous aurez mis à jour vos données, il suffira d’attendre un petit peu. Et ensuite, on vous communiquera les informations pour déployer le module multi-PDP dont on parlait tout à l’heure. Et on vous donnera toutes les informations pour se connecter. Soit au PDP, qui aura été désigné via l’association PDPLibre. Le but dans la finalité va être de proposer les tarifs les plus raisonnables, on va dire, on ne va pas dire les plus bas, on va dire des coûts raisonnables pour une qualité de service optimale. Et que toute société puisse réussir sa réforme, en tout cas.

Walid : Philippe, tu veux rajouter quelque chose ?

Philippe : non, je pense qu’Alexandre a dit l’essentiel. Mais il y a un gros boulot sur les données, effectivement, jusqu’à présent. Souvent, dans les bases de données, le numéro de SIREN, SIRET, c’est important. Cela va devenir entre autres, la principale information de routage. Il y en aura d’autres. Pour certains un peu plus compliqué. Ça va être la clé de routage, sans SIREN, SIRET, vous n’enverrez pas de facture.

Alexis : en complément de ce que vient de dire Philippe et Alexandre sur le sujet, oui, évidemment, bien renseigner les SIREN et numéro de TVA sur les fiches clients-fournisseurs. Evidemment, si vous avez un vieux Dolibarr ou un vieux Odoo, les modules pour la réforme ne vont pas les backporter jusqu’à des versions trop vieilles, donc il faut anticiper cette migration et cette montée de version. Toutes les entreprises qui ont Odoo se réveillent à la dernière minute en appelant leur intégrateur, en disant « oula, j’ai besoin de monter de version », ça va créer un embouteillage.

Et si j’avais un conseil aussi, c’est si vous avez des cas d’usage qui sortent de l’ordinaire, d’en parler avec votre intégrateur. Il y a sur les spécifications AFNOR, sur le document, alors maintenant, ils ont découpé en différentes spécifications, mais c’est la troisième spécification, la XP. SPZ 12-014, bon c’est les numéros des documents, mais c’est le dernier dans la liste des trois documents AFNOR qui sont référencés sur le site des impôts, sur la page dédiée à cette réforme. Il y a en annexe de ce document les 36 cas d’usage étudiés en détail par l’administration, et ça peut être intéressant au moins de lire la table des matières de ce document pour voir si on est concerné par un de ces cas d’usage, ça parle de facture d’escompte, de facture d’acompte, d’autofacturation. Cela parle des cas des scénarios qui sortent de l’ordinaire : c’est intéressant de voir si vous êtes concerné par un de ces scénarios, et de bien en parler, de l’anticiper, pour ne pas se réveiller à la dernière minute et dire. « Moi, j’ai un scénario, en fait, il n’est pas couvert par les développements qui ont été réalisés » : de pouvoir en parler en avance de phase avec son intégrateur Odoo ou son intégrateur Dolibarr, son intégrateur d’une manière générale, pour que les développements pour ces scénarios qui sortent de l’ordinaire soient bien prévus.
Alexis de Lattre

Dans les développements qui vont être réalisés, ou si ce n’est pas le cas, de s’organiser pour, éventuellement de se proposer pour les sponsoriser. Mais il y a des scénarios qui sortent de l’ordinaire, et on ne peut pas, nous, sur la version de base, supporter 100 % des scénarios de facturation.

Philippe : il y a des scénarios, des cas d’usage, qui concernent quand même beaucoup de monde, autour des notes de frais et autres, qui vont nécessiter une sacrée bonne organisation, beaucoup de rigueur dans la gestion. Je n’en dis pas plus.

Walid : j’ai une question complémentaire. On l’a abordée tout à l’heure et vous l’avez notée dans la trame. Vous avez noté ne pas céder à la pression commerciale des grands éditeurs ou des experts comptables qui risquent, par défaut, de choisir la solution PDP de leur éditeur, en totale contradiction avec les logiciels au sein de votre structure. J’aimerais que vous reprécisiez, parce que ça me semble assez important et on en a parlé de manière assez brève. Tout à l’heure. Est-ce que quelqu’un voudrait repréciser ça Alexandre ?

Alexandre : c’est moi qui avais précisé ça dans la trame. Pourquoi j’ai noté ça ? C’est ce que je disais, c’était la pression, on en parle depuis plus d’une heure. C’est la pression que mettent les éditeurs actuellement.

Suite à l’arrivée de l’annuaire centralisé, qui est désormais ouvert, il y en a qui ont commencé les tests d’échange des factures et autres. Ce n’est pas parce qu’on a fixé le 1er septembre 2026 qu’on ne peut pas s’y mettre avant. Il y a déjà des échanges et il y aura déjà des échanges qui se feront avant cette date. C’est ça qui est intéressant. Pareillement, le 1er septembre 2026, pour envoyer les factures, c’est des grandes entreprises qui vont devoir le faire. Mais les TPE, PME ou les ETI, où ce sera le 1er septembre 2027, rien n’empêche d’échanger avant.

Pour en revenir à la question, les éditeurs, effectivement, mettent une pression pour essayer d’embarquer un maximum de clients sur leur PDP, pour des questions de coûts. Plus ils auront de factures à envoyer, plus ils pourront s’imposer. S’il y a un PDP où il y a 10 000 factures à envoyer pour commencer ou on va dire qu’il a déjà 20 millions minimum de factures à envoyer, ce n’est pas la même. Il aura forcément une importance qui sera plus conséquente.

On a eu des attaques. Alors, je désigne, personne, mais on a eu des attaques commerciales qui disaient : « voilà, faites attention au logiciel libre, etc. Ça va être très compliqué ». Et donc, c’est pour ça qu’on dit qu’on subit une pression commerciale. Donc, nous, dans le libre, c’est différent. On a peut-être un peu plus de temps pour se mettre en marche. Voilà, le principal, c’est que sur la ligne d’arrivée, on soit tous là. Enfin, en tout cas, la ligne de départ, on se dirige vers la ligne de départ, seulement. Et on sera tous à la ligne de départ dans les temps.

Voilà, donc ce que je disais, c’est de ne pas céder à s’inscrire sur une plateforme agréée. Je viens de changer le nom, c’est plus PDP depuis tout à l’heure. Et donc sur ces plateformes agréées, il ne faut pas s’inscrire aujourd’hui. C’est ce que j’avance dans mes communications sur les différents réseaux sociaux et même au niveau de la communauté Dolibarr. L’autre élément, c’est que pareil, des experts comptables, je ne vais pas dire sous la pression de leur éditeur car ils ont un seul logiciel, vont proposer, par facilité, je dirais de faire signer un mandat à leurs clients pour l’inscrire par eux-même, donc cabinet comptable, sur une plateforme agréée, celle de leur éditeur. Et donc, après, ce qui va se passer, c’est que si on fait ça, on se retrouve à devoir utiliser, pour la facturation, le logiciel SAS de facturation que propose son cabinet comptable. Je trouve ça un petit peu aberrant parce que ça veut dire que si on n’a pas de logiciel, c’est très bien, il n’y a pas de souci. Mais par contre, si on en a déjà un et qu’on force l’inscription, alors on peut changer. Mais si on force l’inscription à une plateforme agréée, ça veut dire que le cabinet comptable ne prend pas en compte les logiciels qui sont déjà installés dans l’entreprise, et donc, ça veut dire qu’après, Dolibarr pourra plus transmettre les factures, ou du moins, ils feront les factures pour les particuliers, et puis, après, l’expert-comptable pourra s’amuser avec le e-reporting. Enfin, ça va être deux logiciels séparés, en attendant de faire la réinscription sur l’autre plateforme agréée qu’on aura peut-être désignée ou autre, recontractualisée. Voilà, il y aura plein, plein, plein de choses. C’est mon point de vue, je ne suis pas pour donner le mandat à un cabinet comptable sur ce sujet-là. Je préfère garder la main et je demande à mes clients de garder la main.
Alexandre Spangaro

La création du fichier de meta données associé à la facture

Walid : dernière question annexe. Tout à l’heure, on a parlé du fait que ce qui allait être transmis, c’est une facture avec un fichier XML de métadonnées. C’est le logiciel de facturation qui va créer ce fichier XML ou est-ce que c’est le PDP qui va, à travers de l’OCR, constituer ce fichier XML ?

Alexandre : on a un peu de tout.

Alexis : à l’époque où il y avait le portail public de facturation, l’État avait dit que le portail public de facturation va accepter trois formats de factures structurées. Donc, deux formats pur XML, le format UBL, Universal Business Language, et le format Cross Industry Invoice. Donc, là, c’est directement la facture, c’est un fichier XML. Et puis, le troisième format, c’est le format Factur-X.

Une facture au format Factur-X, c’est une facture PDF, avec à l’intérieur du PDF un fichier XML au format Cross Industry Invoice. Donc, un des deux formats que j’évoquais tout à l’heure. Et donc, c’était les trois formats acceptés par le PPF.

Et maintenant que le PPF a disparu, l’État dit : « moi, ce sont les trois formats que j’accepte quand le PDP va m’envoyer une copie de la facture », cette fameuse fonction mouchard du PDP, de la plateforme agréée, qui envoie une copie de la facture à l’administration. L’administration, elle, en attend la facture sur un de ces trois formats-là. Après, moi, entreprise qui envoie ma facture à mon PDP, je peux l’envoyer dans n’importe quel format accepté par mon PDP.

A priori, il accepte ces trois formats-là, forcément, puisque c’est les trois formats de base, mais le PDP peut accepter d’autres formats. Et il s’occupe, lui-même de faire la conversion derrière. Et donc, après, si vous lui envoyez un PDF simple, sans XML à l’intérieur, en supposant qu’il soit capable d’accepter ce format-là. Cela veut dire qu’il va passer dans un OCR, etc. Le problème des OCR, c’est que ce n’est jamais fiable à 100 %.

Donc, ça voudrait dire qu’il y a une étape supplémentaire de contrôle. Des données qui ont été reconnues par l’OCR et puis validation de la part de l’entreprise, faire ça sur une facture de temps en temps, ça va bien, c’est ce que faisaient beaucoup de gens sur Chorus en déposant des PDF simples, mais là, quand ça concerne 100 % de ces factures, quand on a un peu de volume, c’est beaucoup trop chronophage.

Le but c’est quand même d’éviter de passer par cette étape d’OCR sur le portail de son PDP, mais d’envoyer dans un des formats qui soit directement reconnu. Donc, a priori, un de ces trois formats-là. Après, il y a des gens qui émettaient en Edifact, etc. Si leur PDP va accepter à priori ces formats et eux, le PDP fera la conversion dans un des trois formats acceptés par la DGFIP pour cette fonction d’envoi de la copie de la facture à l’administration fiscale.

Alexandre : je vais vous donner une toute petite information pour compléter ce que dit Alexis. Il y a les trois formats et on constate là, avec les premiers accès au sandbox, que certains PDP, par exemple, on n’aura pas forcément besoin de leur envoyer directement du Factur-X, du format. J’ai constaté que certains PDP, on va leur envoyer l’info via API et après, ils vont constituer le fichier aussi. J’ai vu cette forme-là. Après, pour ensuite la communiquer, suivre le protocole, on va envoyer la donnée et ils vont constituer par eux-mêmes les fichiers.

Mots de la fin des invités

Walid : on ne va pas aller beaucoup plus loin sur ce sujet-là. Je vais vous proposer à chacun de faire un mot de la fin avant qu’on se quitte. Si vous avez une information, un message à faire passer. Alexandre, est-ce que tu veux commencer ?

Alexandre : merci déjà à tous pour cette écoute. Merci à tous, Walid, Alexis et Philippe. Toujours un plaisir de discuter avec vous. Je pense qu’on pourra faire un deuxième épisode dans pas longtemps. Le sujet est vaste et varié. Voilà, le mot de la fin : inscrivez-vous, suivez la communauté Dolibarr, bien sûr pour ceux qui sont équipés de Dolibarr, et n’hésitez pas à vous renseigner et à avoir un esprit critique. Renseignez-vous et puis on va faire le maximum au niveau de la communauté Dolibarr pour vous donner un maximum de renseignements pour que cette réforme se passe dans les meilleures conditions.

Walid : Philippe ?

Philippe : un peu, le même message, effectivement. Soyez à l’écoute, parce qu’on vous sollicitera en tant qu’utilisateur, probablement pour nous aider à financer tout ça. Parce que, comme on le disait, c’est quand même énormément de boulot, et on n’a pas des modèles économiques dans le logiciel libre, qui soient forcément hyper adaptés pour développer et faire face à ces grosses contraintes réglementaires. Et puis, comme on le disait, ce n’est pas la seule actuellement. Voilà, mais en tout cas on est là, on va se mobiliser. On est mobilisés, ça va avancer.

Walid : merci, Philippe. Alexis, ton mot de la fin ?

Alexis : oui, en mot de la fin, on sera en rendez-vous. C’est un gros chantier, c’est probablement la plus grosse réforme dans le domaine comptable depuis ces 30 dernières années. Dans toutes les réformes qu’on a passées, que ce soit le SEPA, le FEC, Chorus, etc. Là, celle-là, elle concerne vraiment toutes les factures. C’est la plus grosse réforme, je pense, dans le monde de la comptabilité sur ces 30 dernières années.

Il faut rester en veille. Il y a eu beaucoup de rebondissements au cours de ces dernières années sur cette réforme. On n’est pas à l’abri qu’avec les instabilités gouvernementales, qu’il y ait des nouveaux rebondissements. On espère qu’il n’y en aura pas, mais on n’est pas à l’abri. Donc, il faut rester en veille et bien dialoguer. Avec son intégrateur, son intégrateur Odoo, son intégrateur Dolibarr, son intégrateur d’une manière générale, pour faire les bons choix et surveiller ça de près. Merci à toi, pour ton accueil et pour ce podcast sur le sujet de la réforme de la facture électronique.

Walid : merci à vous. Je pense que ça intéressera tout le monde finalement. Cela m’intéressait de voir du côté des ERP libres quels étaient les défis, les discussions, et comment tout le monde s’adaptait à tout ça.

Donc, merci beaucoup d’avoir pris du temps pour expliquer où est-ce qu’on en est. Pour les auditrices et les auditeurs, comme d’habitude, je pense que vous pouvez faire tourner cet épisode, vous pouvez le commenter, vous pouvez aussi nous dire où est-ce que vous en êtes, vous, par rapport à vos propres réflexions. Je vous invite bien entendu à suivre les travaux Dolibarr et de l’OCA sur ce sujet-là. Et puis, si ça vous a plu, peut-être qu’on fera d’autres épisodes dans le même genre. Merci beaucoup à toutes et à tous et à bientôt pour un prochain épisode.

Production de l’épisode

• Enregistrement à distance le 21 juillet 2025
• Trame : Philippe Scoffoni, Alexandre Spangaro
• Montage : Walid Nouh
• Transcription : Walid Nouh

Licence

Ce podcast est publié sous la licence CC BY-SA 4.0 ou ultérieur

Suivi de la réforme de la facturation électronique

Sommaire

• 1 Suivi de la réforme de la facturation électronique
• 2 Présentation des invités
• 3 Les évolutions réglementaires
• 4 Avancement de l’implémentation sur Dolibarr
• 5 Les deux implémentations sur Odoo
• 6 L’avancement de PDPLibre
• 7 Production de l’épisode
• 8 Utilisation d’IA
• 9 Licence

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.

youtube.com/watch?v=OjJrBmKY5G…

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

Choosing your experience growing up in a Taekwondo class in Singapore is a breathtaking technique for adapting them to the universe of hand-to-hand commitment while at the same time giving different physical, mental, and valuable benefits. Enduring momentarily that you're examining joining your youth for Taekwondo, taking into account what's not too far off from the classes is typical. In this article, we'll give a construction of what your adolescent can expect while going to Taekwondo classes for youngsters in Singapore.

1. Warm-Up and Broadening

Like any certifiable work, Taekwondo classes generally start with a warm-up party to set up the body for planning. Construe that your adolescent ought to participate in various warm-up works, including running, bobbing jacks, and dynamic stretches. Warm-ups help with blocking wounds and further develop flexibility, clearing a path for a convincing informative get-together.

2. Vital Frameworks and Plans

Once warmed up, Taekwondo teachers will arrange students through the improvement of head procedures and plans. These directions are essential improvements like punches, kicks, blocks, and positions. Students in a Taekwondo class Singapore will figure out a viable method for executing these procedures with exactness and control, fanning out the justification for extra-made restrictions later on.

3. Additional Enters and Pad Work

Taekwondo classes regularly mix additional bores and pad work to foster timing, exactness, and coordination. Students could work with a right hand to chip away at engaging procedures or take part in pad drills with educators to refine their capacities to strike. These natural activities advance collaboration and correspondence while making significant certainty limits.

4. Self-Security Structures

Confidence is a basic piece of Taekwondo's readiness. Derive that your youth ought to learn utilitarian self-security procedures expected to shield themselves, actually, conditions. Instructors will encourage students on the best method for preparing for normal attacks and how to use their Taekwondo capacities to stay safeguarded and sure about various circumstances.
youtube.com/embed/SihJ3IGGq2U

5. Discipline and Respect

Taekwondo puts areas of strength for tremendous on discipline, respect, and driving. Teachers will give these characteristics to students by making rules of brief and pushing a culture of regard for each other. Derive that your youth ought to procure ability with the significance of observing guidelines, seeing their educators and individual students, and staying aware of balance both inside and outside the readiness passage.

6. Thriving and Trim

Taekwondo classes give magnificent activity to kids, mixing cardiovascular advancement with strength organizing and adaptability drills. Gather that your adolescent ought to moreover develop their overall thriving level as they participate in uncommon turns of events and are very associated with organizing. Standard help with Taekwondo classes can incite expanded excitement, strength, and guilefulness.

7. Belt Progress and Headway

Taekwondo uses a belt-orchestrating structure to see students' improvement and skill level. As your young life advances in their planning, they will have a critical opportunity to test for higher belt positions, watching out for their new turn of events and authority of Taekwondo strategies. Construe that your young grown-up ought to contribute targets and effort excitedly towards achieving them, with belt developments filling in as achievements along their Taekwondo cycle.

Considering everything, Taekwondo classes for young people in Singapore offer a careful drawing of an encounter that goes past a real turn of events. From learning central systems to making fundamental things limits like discipline, respect, and strength, Taekwondo for youngsters in Singapore provides a reasonable procedure for managing kid improvement. By understanding what the future holds from Taekwondo classes, you can ensure that your child is prepared for a driving experience on the blueprint mat.

The Middle East is undergoing one of the most concentrated periods of infrastructure and urban development in its modern history. Across Saudi Arabia, the UAE, Qatar, Kuwait, and Oman, construction programs of extraordinary scale are advancing simultaneously — from the NEOM megacity project in northwestern Saudi Arabia to port expansions along the Gulf coast, from metropolitan transit networks threading beneath Dubai and Riyadh to industrial city developments generating aggregate demand that regional quarry supply chains are working hard to sustain. The concrete volumes involved are staggering. And where large volumes of concrete are placed, large volumes of concrete eventually require demolition, recycling, or processing — a downstream demand dynamic that is driving accelerating investment in concrete crusher machine across the region.

The relationship between construction growth and crusher machine demand is not simply linear. It operates through multiple simultaneous mechanisms: the demolition of existing structures to make way for new development, the recycling of construction and demolition waste into reclaimed aggregate that reduces dependence on quarried material, the processing of concrete rubble generated by infrastructure renewal programs, and the production of recycled concrete aggregate for sub-base and fill applications where virgin aggregate supply is geographically constrained or economically prohibitive. Understanding these mechanisms — and the regional factors that amplify their effect in the Middle East specifically — explains why the market for concrete crusher machines in this region is expanding at a rate that equipment manufacturers and distributors are finding genuinely difficult to supply ahead of demand.

Infrastructure Renewal and Urban Redevelopment as Primary Demand Drivers

The Middle East's current construction wave is not occurring on entirely undeveloped land. A significant portion of the region's most active development zones contain existing built infrastructure — older residential districts, industrial facilities, commercial developments, and transportation infrastructure constructed during earlier development phases that now require either demolition to clear sites for new development or structural renewal that generates substantial concrete demolition waste. Processing this waste economically requires mobile and stationary concrete crusher machines capable of reducing large-diameter reinforced concrete demolition material to specification-grade recycled aggregate.

Demolition Waste Generation from Urban Renewal Programs

Urban renewal programs in Saudi Arabia's major cities — Riyadh, Jeddah, and Dammam — are generating concrete demolition volumes that traditional waste disposal approaches cannot absorb economically. Landfill disposal of concrete demolition waste imposes transport costs, tipping fees, and increasingly stringent regulatory compliance requirements that make on-site or near-site crushing and recycling the operationally and economically preferable alternative. Mobile jaw crusher and impact crusher combinations, positioned at demolition sites, reduce reinforced concrete rubble to recycled concrete aggregate that can be immediately utilized as structural fill, road sub-base material, or drainage layer aggregate within the development program generating it.

The economic argument for on-site concrete crushing in urban renewal contexts is compelling. Eliminating demolition waste haulage — which in congested Middle Eastern urban environments carries both direct cost and schedule implications — while simultaneously producing aggregate material that would otherwise require procurement from quarry sources or import supply chains creates a dual financial benefit that experienced demolition and earthworks contractors in the region have recognized and acted upon. Concrete crusher machine investment in this context delivers return through waste disposal cost avoidance as much as through aggregate production value.

Reinforced Concrete Processing Requirements and Equipment Implications

Demolition concrete from Middle Eastern construction programs is predominantly reinforced — structural frames, shear walls, foundation elements, and pavement slabs that contain steel reinforcement at densities that impose specific processing requirements on crusher machine selection. Primary jaw crushers handling reinforced concrete demolition feed must accommodate steel reinforcement bars passing through the crushing chamber without causing mechanical damage to jaw plate retention systems or drive components. Hydraulic overload protection systems — standard on quality jaw crusher designs — protect against tramp metal events by allowing the jaw's closed-side setting to open momentarily when an uncrushable object enters the chamber, releasing it without imposing destructive load on the machine's structural members.

Aggregate Supply Constraints and the Recycled Material Opportunity

The Middle East's geological and geographic characteristics create natural aggregate supply constraints that amplify the economic value of recycled concrete aggregate. The Arabian Peninsula's predominantly sedimentary geology limits the availability of hard, durable crushed rock aggregate in proximity to major construction centers. Quarry sources for premium aggregate in Saudi Arabia's central and eastern provinces are geographically distant from the highest-demand construction zones, imposing haulage costs that escalate delivered aggregate prices significantly above quarry gate prices. The UAE imports substantial volumes of aggregate from Oman and further afield to supplement domestic quarry production that cannot meet the pace of construction demand.

Recycled concrete aggregate produced by concrete crusher machines from demolition waste provides a supplementary supply source that reduces dependence on long-haul quarry aggregate for applications where recycled material meets specification requirements. Road sub-base and base course applications, structural fill, drainage aggregate, and in some regulatory frameworks, lower-grade structural concrete production — these end uses collectively represent a substantial volume of aggregate demand that recycled concrete aggregate can address, with material produced at or near the point of generation rather than transported from distant quarry sources.

Megaproject Construction Waste Management as a Systemic Demand Factor

Saudi Arabia's Vision 2030 infrastructure pipeline includes project scales that generate construction waste volumes with no historical precedent in the region. NEOM alone — a 26,500 square kilometer development program encompassing linear city infrastructure, mountain resort facilities, and coastal development — will generate concrete demolition and construction waste recycling throughout its multi-decade development timeline that requires systematic processing capability rather than project-by-project improvisation. The institutional recognition of this requirement is driving procurement of concrete crusher machines at program rather than project scale — a procurement approach that reflects the maturation of the regional construction industry's approach to waste management as an engineered system rather than an operational afterthought.

On-Site Crushing Integration in Large-Scale Project Logistics

Large megaproject construction programs in the Middle East are increasingly incorporating on-site crushing operations as an integral component of the project's materials management system rather than a supplementary activity. Concrete crusher machines positioned within the project boundary process demolition and construction waste into recycled aggregate that feeds back into the project's ongoing construction material requirements — road base for internal haul routes, fill material for earthworks programs, drainage aggregate for stormwater infrastructure — creating a closed-loop material cycle that reduces both virgin aggregate procurement costs and waste disposal logistics complexity.

The logistical benefit of on-site crushing in megaproject contexts extends beyond material cost reduction. Reducing outbound waste haulage volume and inbound aggregate delivery volume simultaneously decreases the traffic load on haul routes that, in remote megaproject locations, represent significant infrastructure investments in their own right. Fewer heavy vehicle movements translates to reduced haul road maintenance costs, lower fuel consumption across the haulage fleet, and reduced dust generation in the environmentally sensitive desert environments where several major Middle Eastern projects are located — a sustainability benefit that increasingly features in project environmental management plan compliance requirements.

Stationary Versus Mobile Crusher Configuration Selection for Megaproject Applications

Megaproject concrete crusher procurement decisions involve a configuration choice — stationary versus mobile plant — that reflects the specific material flow dynamics of each project program. Stationary crushing installations, positioned at central waste reception and processing facilities within the project boundary, offer higher throughput capacity and lower operating cost per tonne at sustained production volumes. They are appropriate where demolition waste can be economically hauled to the central facility from generation points distributed across the project area. Mobile crusher configurations — track-mounted jaw and impact crusher units that reposition to follow demolition activity — minimize the haul distance between waste generation and processing by bringing the crusher to the material rather than the material to the crusher. For projects where demolition fronts advance progressively across a large geographic area, mobile configurations consistently deliver lower total material handling costs despite their higher unit operating cost compared to stationary plants. The correct configuration choice depends on a rigorous analysis of haul distance economics, production volume requirements, and the temporal distribution of demolition waste generation across the project timeline — an analysis that the Middle East's most sophisticated project developers are now conducting as standard practice rather than treating equipment configuration as a secondary procurement decision.

In the high-stakes environment of the mining and aggregate industry, equipment downtime is the ultimate profit killer. Stationary facilities and mobile stone crusher for sale units alike are constantly subjected to extreme dust, heavy moisture, and intense material impact. Among all the moving components within a processing circuit, the vibrating screens and feeders bear the brunt of this daily punishment. Traditionally, standard vibrator motors required frequent lubrication adjustments and bearing checks to avoid catastrophic failure. However, a major engineering shift has occurred with the introduction of side-panel motors, which routinely clock over 2000 hours of continuous operation without requiring any hands-on maintenance. Understanding the structural innovations behind this remarkable durability is essential for site managers looking to optimize their processing lines.

Whether processing hard granite or recycling demolition debris, achieving this level of mechanical endurance directly transforms the reliability of your entire crushing layout. When searching for an efficient stone crusher plant, seasoned procurement teams no longer just look at the primary jaw or cone crushers; they deeply evaluate the auxiliary vibrating equipment that controls the material flow. If a screening motor fails, the entire production line stops instantly. This guide explores the mechanical design principles that keep side-panel motors running flawlessly through grueling double-shifts, keeping your heavy-duty concrete crusher units and sizing screens constantly supplied with raw material.

Advanced Structural Isolation and Centrifugal Balance

The primary reason standard vibrator motors fail prematurely in aggregate processing is because their internal bearings are subjected to severe, concentrated kinetic stress. Side-panel motors solve this problem by altering how the eccentric weights transmit force to the screen box body.

Instead of relying on a centralized shaft that bends slightly under extreme loads, side-panel motors are bolted directly to the side plates of the vibrating screen or feeder. This direct mounting method distributes the heavy centrifugal forces evenly across a larger surface area of the steel structure. By reducing localized stress concentrations, the motor protects its internal components from the micro-misalignments that typically cause overheating, winding failures, and premature mechanical wear.

The Secrets of Zero-Maintenance Bearing Engineering

To survive 2000 hours of uninterrupted service without manual lubrication, engineers had to completely redesign the internal bearing housing and lubrication seals. This advanced bearing technology is what makes modern screening equipment so reliable, whether it is integrated into a heavy stationary layout or a compact mobile stone crusher for sale(vendo trituradora de piedra móvil).

Heavy-Duty Spherical Roller Bearings

Side-panel motors utilize specialized, oversized spherical roller bearings designed specifically for vibrating applications. These bearings feature a machined brass cage that provides superior stability under high accelerations. The spherical design allows for minor angular deflections, ensuring that even if the screen box twists slightly under a sudden surge of heavy boulders, the rollers inside the bearing maintain perfect alignment and rolling contact.

Hermetically Sealed Synthetic Greasing Systems

Instead of requiring daily or weekly grease gun maintenance from field technicians, these motors are packed at the factory with high-performance, synthetic long-life grease. The bearing chambers are protected by a multi-stage labyrinth sealing system combined with heavy-duty viton seals. This barrier effectively locks the premium lubricant inside the chamber while permanently blocking micro-fine stone dust, silica, and ambient moisture from entering. This zero-leakage, zero-contamination design allows the motor to maintain perfect thermal regulation over thousands of operational hours.

Lubrication Comparison: Traditional vs. Side-Panel Motors

Optimizing Material Flow in Diverse Crushing Circuits

The exceptional durability of side-panel propulsion systems makes them highly versatile assets across various sectors of the aggregate and recycling industries. Their consistent stroke and zero-maintenance profile improve the efficiency of multiple processing setups.

• Primary Quarry Feeding: Positioned at the intake of a multi-stage stone crusher plant(planta trituradora de piedra), these motors handle continuous dumping from heavy haul trucks, maintaining a steady material feed without choking the jaw crushers.
• Recycling Demolition Waste: When powering screening decks downstream from an industrial concrete crusher, side-panel motors resist the intense vibrations caused by jagged rebar, concrete chunks, and brick fragments, preventing mechanical stalling.
• Portable Material Sizing: Because portable operations change jobsites frequently, using these motors on a mobile stone crusher for sale guarantees that the screening unit can operate autonomously in remote locations without requiring specialized maintenance crews.

Smart Operational Practices for Maximum Service Life

While side-panel motors are engineered to run for 2000 hours without hands-on maintenance, achieving this baseline requires proper installation and initial tuning. Site supervisors should implement the following engineering checks during commissioning:

1. Torque Verification: Because these motors generate immense G-forces, the high-tensile mounting bolts must be tightened to the exact foot-pound specifications using a calibrated torque wrench during initial setup.
2. Synchronized Phase Matching: When deploying dual side-panel motors on a linear screen box, operators must ensure that the electrical phasing is perfectly reversed so the eccentric weights rotate in opposite directions, creating a clean, linear throwing action.
3. Structural Stiffness Audits: Periodically inspect the side plates of your stone crusher plant screening decks to ensure no fatigue cracks have formed in the steel body, as structural flexing can feed irregular stresses back into the motor housing.

Long-Term Economic Impact on Aggregate Yields

Investing in high-end side-panel motor technology represents a strategic shift toward data-driven asset management. Eliminating weekly lubrication routines does more than just save money on grease; it removes maintenance technicians from hazardous areas around active machinery and eliminates the risk of human error, such as over-greasing or using contaminated lubricants.

Whether you are running a high-output urban concrete crusher(trituradora de hormigón) recycling yard or deploying an agile mobile stone crusher for sale in a remote quarry, the reliability of your vibrating components dictates your daily tonnage. By embracing the zero-maintenance engineering of modern side-panel motors, aggregate producers can secure uninterrupted production, protect downstream crushing machinery, and achieve a significantly lower total cost per ton of finished aggregate.

The execution of highway expansions, mountain corridors, and rural paving initiatives across Latin America presents a unique set of geographic and financial challenges. Contractors frequently navigate fluctuating material supply chains and complex terrains that stretch from coastal plains to high-altitude zones. To overcome these logistical barriers while maintaining profitability, infrastructure developers are shifting away from rigid, permanent production facilities. Instead, they are embracing agile operating strategies. Analyzing the flexible deployment models of a modern mobile asphalt plant(planta de asfalto móvil precio) reveals how today's engineering firms optimize resource distribution, adapt to varied project sizes, and significantly improve their operational bottom line.

Strategic Relocation Across Borderless Projects

One of the most practical deployment strategies utilized by regional consortia is the linear mobility model. For cross-border highways or expansive state road rehabilitation projects, positioning a single permanent production facility is financially inefficient. The transport distances for hot mix asphalt quickly exceed the critical timeframe required to prevent temperature drops and material degradation.

By implementing mobile configurations, contractors can establish a shifting production front. The equipment follows the actual paving crew along the corridor, dismantling at one completed sector and reassembling at the next checkpoint within days. This strategy drastically lowers haulage truck fuel consumption, minimizes aggregate transit wear, and ensures that the material is laid at the peak compaction temperature required by local public works ministries.

Customizing Fleet Sizes for Varied Regional Demands

Infrastructure demands vary wildly between dense metropolitan upgrades and isolated rural connectivity projects. A one-size-fits-all approach to machinery acquisition often ties up vital capital in underutilized assets. Flexible deployment relies on selecting the exact capacity and configuration required for the regional micro-climate and contract scale.

High-Capacity Units for Transit Corridors

For high-volume highway contracts, large-scale mobile setups serve as temporary regional hubs. These systems feature advanced aggregate drying, precise bitumen weighing, and multi-stage dust collection filters. They deliver the continuous volume necessary to feed multiple paving machines working simultaneously on multi-lane highways without the long-term commitment of purchasing real estate for a fixed site.

Compact Configurations for Remote Terrains

When executing projects in localized or challenging geographic zones, such as an isolated asphalt plant in Ecuador or remote parts of Peru, logistics teams often deploy highly compact, trailer-mounted designs. These units are engineered specifically to navigate tight mountain switchbacks, unstable rural roads, and low-clearance bridges. In these scenarios, a smaller, highly efficient asphalt mixing plant(planta mezcladora de asfalto) ensures that localized road crews have total independence from distant commercial suppliers, allowing them to complete localized bridge approaches or municipal repairs on schedule.

Comparison of Primary Deployment Configurations

Financial Flexibility and Acquisition Considerations

An effective deployment model must be backed by a clear financial strategy. When evaluating fleet additions, procurement managers analyze how a mobile asphalt plant price translates into long-term operational savings across multiple job locations.

• Capital Allocation: While the upfront mobile asphalt plant price might reflect a premium for engineering mobility features, the asset eliminates repeated site preparation costs, permanent foundation pouring, and expensive civil dismantling fees over its lifespan.
• Asset Utilization: Because these plants can be packed up and shipped via standard prime movers, they rarely experience extended idle periods. A plant working on an asphalt plant in Ecuador(planta de asfalto en Ecuador) can be easily reallocated to a different subsidiary's project across the region once its local contract concludes.
• Reduced Permitting Delays: Temporary, mobile installations often face faster environmental and municipal permitting pathways compared to permanent, heavy-industrial factories, allowing engineering companies to start production weeks ahead of schedule.

Maximizing Quality Control in Temporary Setups

Adopting a flexible deployment method does not mean compromising on material integrity. Modern mobile units are outfitted with the same high-tier automation found in permanent installations. Fully integrated control cabins utilize programmable logic controllers (PLC) to manage batch recipes, monitor aggregate moisture variations, and adjust burner intensity in real time.

This level of technological precision ensures that whether the asphalt mixing plant is operating in a humid coastal plain or a high-altitude valley, the resulting mix satisfies the rigorous friction and durability standards required for international transport corridors. Furthermore, multi-fuel burners allow operators to switch between diesel, heavy oil, or gas depending on what fuel source is most cost-effective and accessible in that specific deployment zone.

Driving Efficiency Forward in Regional Engineering

The future of Latin American road development rests on the ability of engineering companies to remain adaptive, financially lean, and logistically agile. Relying entirely on fixed infrastructure limits a contractor's geographic reach and increases vulnerability to local market shifts.

By integrating flexible deployment strategies—whether managing a highly active asphalt plant in Ecuador or moving high-volume machinery along a continental highway—contractors can successfully insulate themselves from logistical supply shocks. Balancing a competitive mobile asphalt plant price with advanced technical features allows regional builders to secure a higher return on investment, deliver superior pavement quality, and accelerate the completion of critical infrastructure across the continent.

Staring at a worn metal tag is a typical sight in maintenance shops. The surface is scratched and dented. The stamped numbers have become barely noticeable. You realize a replacement is needed, but the sequence of digits and hyphens makes little sense. Choosing incorrectly means waiting weeks for a part that doesn't belong. Choosing correctly keeps your machine running smoothly. Figuring out Kobelco part numbers isn't about memorizing complicated codes. It's about understanding the system so you can order with full confidence.

Whenever you're looking for Kobelco crane parts, the part number is your main reference point. But this number isn't just a random string. It follows a deliberate pattern that links the part to the correct machine. Misreading a single character can result in a wrong shipment. In this field, a wrong shipment means costly downtime. Downtime leads to lost money and frustrated crews. Taking time to understand the numbering system avoids many problems later.

The Structure of the Number

Kobelco part numbers tend to follow a particular format. They often combine a base number with extra suffixes or prefixes. The base number identifies the component type. A hydraulic pump will have a different base than a filter or a pivot pin. The suffixes often indicate revisions or specific machine applications. This is where things become confusing. Two numbers can look almost identical, differing by only one letter at the end.

That single letter can change compatibility completely. It might mean a left-hand thread instead of a right-hand one. It could indicate the part is for a certain serial number range. Never assume the last character is unimportant. It often holds the secret to proper fit. When you write down the number, copy every dash and every letter. Treat the full string as crucial information.

Understanding Supersession

Part numbers change over time. This is one of the most confusing parts of ordering. You might find a number stamped on an old part. You search for it in the catalog. The system tells you that number is obsolete. It has been superseded by a new number. This happens when manufacturers improve a design or change suppliers.

Ignoring supersession leads to backorders. You might order the old number and wait weeks, only to be told it's no longer available. The new number is the active one. It replaces the old one completely. When you find a superseded number, always use the new one for ordering. This ensures you get the latest version of the component. It also prevents confusion with your supplier. They will likely ship the new number anyway, but having it on your purchase order speeds up the process. When you request Kobelco crane parts, always check for supersession first.

The Importance of Serial Numbers

The part number alone is rarely enough. You need the machine's serial number too. Kobelco makes running changes throughout production. A crane built in January might have a different valve than one built in December. The parts catalog uses the serial number to filter these variations.

If you order based on the part number alone, you might get a version that doesn't match your hydraulic lines or mounting points. Providing the serial number allows the supplier to cross-reference the exact build of your machine. It confirms that the part number you found applies to your specific unit. This step is non-negotiable for critical components. For simple consumables like filters, it might matter less. For structural or hydraulic parts, it is essential. Many mistakes in ordering Kobelco crane parts come from skipping the serial number verification.

Reading Worn Stamps

Sometimes the number is hard to read. Dirt and grease cover the stamp. Corrosion eats away the metal. Don't guess. Clean the area thoroughly. Use a wire brush and degreaser. Sometimes you need to look at the part from different angles with a light source. If the stamp is completely gone, look for other identifying features.

Measure the dimensions. Count the splines on a shaft. Note the port sizes on a valve. This physical data helps when the number is unreadable. You can provide these details to your supplier. They can often identify the part based on specs rather than the stamp. But this takes more time. It's always better to catch the number before it becomes illegible. Make a note of part numbers during routine inspections while they are still clear.

Avoiding Common Transcription Errors

Writing down the number seems simple. But errors happen often. People confuse the letter O with the number zero. They mix up the letter I with the number one. Dashes get left out or moved. These small mistakes render the number useless in the ordering system.

Double-check what you write. Read it back aloud. Compare your notes to the part again. If you are sending a photo, make sure it is in focus. Blurry images force the supplier to guess. Guessing leads to errors. Take multiple photos from different angles. Include a close-up of the number and a wider shot of the part context. This gives the supplier everything they need to verify the component.

Using the Electronic Parts Catalog

The Electronic Parts Catalog (EPC) is your best tool for verification. It links part numbers to diagrams. You can see where the part fits in the assembly. This visual confirmation helps ensure you have the right component. The EPC also shows quantity requirements. You might need four of a specific bolt, but the diagram only highlights one.

The catalog also flags superseded numbers. It directs you to the current active part. Don't rely on old paper manuals. They go out of date quickly. Online portals update regularly. If you don't have access to the EPC, ask your supplier to check it for you. They have the tools to verify the number against your machine's build date. This service is usually free and saves you from ordering mistakes.

Why Genuine Numbers Matter

Using the correct Kobelco crane parts number ensures you get the right component. Aftermarket cross-references exist, but they aren't always perfect. An aftermarket number might cover a range of models. The genuine number is specific to your machine. This specificity matters for tolerance and performance.

When you use the genuine number, you know the engineering matches the original design. You know the material specs are correct. You know the warranty applies. If you use a cross-reference that fails, you might void warranties on related systems. Stick to the genuine number for critical components. It removes the variable of compatibility. You know exactly what you are getting when the box arrives.

Building a Reliable Record

Keep a log of part numbers for your fleet. When you replace a component, record the new number. Note the serial number of the machine. This creates a history for each crane. Next time you need a part, you don't have to climb back on the machine to find the stamp. You have the data ready.

This record helps with budgeting too. You can track which parts fail often. You can see if certain components need upgrading. It makes maintenance planning smoother. When you talk to your supplier, you have the information ready. They can process the order faster. Accuracy in your records leads to speed in your repairs. Maintaining a reliable log of Kobelco crane parts numbers pays off with every order.

Final Thoughts

Decoding part numbers takes patience. It requires attention to detail. But the effort pays off in reliability. You avoid the frustration of returns. You keep the crane working. You protect the safety of the site.

Don't rush the identification process. Clean the stamp. Verify the serial number. Check the catalog for supersession. Use genuine Kobelco crane parts numbers for accuracy. Treat the part number as a critical piece of data. It is the link between your machine and the replacement it needs. Get it right, and the rest of the repair process becomes much simpler.

How does one optimize for better system temperatures on Linux while doing heavy tasks (e.g. gaming) during summer heat.

Are there tools for creating 'gaming/balanced/economy' profiles for example that limit the GPU and CPU depending on the requirements?

Should I find a way to customize fan speeds?

I am trying to find everything I should do from the software perspective before I move on to buying better cooling hardware.

I am currently reaching 100+ celsius temps maximum on both the GPU and CPU while gaming, on idle it's like this:

System info:

Thomas Piketty, économiste et auteur, donne une conférence à l'université de Genève où il présente lien entre inégalité et extrême droite. Lors de cette conférence, il explique la déception du Reaganisme et l'évolution du discours politique républicain, notamment par notre ami Donald Trump. Visionnaire, c'était en 2019.

Réduire la qualité de la vidéo.

Pour changer le système :
Réclamer le RIC constituant : petitions.assemblee-nationale.… mouvement-constituant-populair…
Changer de banque: lanef.com/ change-de-banque.org/particuli…
Passer à l'action militante: extinctionrebellion.fr/ ripostealimentaire.fr/
Changer de travail : jobs.makesense.org/fr

Sources
Piketty youtube.com/watch?v=gLbjK0vubj…
Musique youtube.com/watch?v=1AX7agDhtX…

Réponses au quiz de fin :

/!\ Description à ne pas lire avant d'avoir vu la vidéo entièrement
/!\

/!\

/!\
/!\

À partir de quand les 50 % des plus pauvres ont ils eu moins que le 1% le plus riche aux USA ?
1995.

Quelle était la croissance économique aux États-Unis sur la période 1950 - 1990 ?
2,2%.

Quelle est la vraie raison de la baisse de la croissance selon Piketty ?
La stagnation de l'investissement éducatif.

#piketty #trump #capitalisme #inégalité #nationalisme #politique #extrait #ethiqueettac

L'historien des sciences Jean-Baptiste Fressoz démonte le mythe de la transition énergétique à l'Académie du Climat. À travers les archives diplomatiques américaines du Sommet de Rio et les stratégies d'Exxon dès les années 1970, il révèle comment la technologie a été instrumentalisée par les gouvernements et les lobbys pétroliers pour retarder l'action climatique.
Une analyse historique percutante qui dévoile les coulisses de l'économie du climat, du GIEC et des illusions technologiques face à l'impossible décarbonation du modèle industriel mondial.

#Fressoz #climat #histoire #giec #energie

00:00 Intro
00:50 Jean-Baptiste Fressoz
09:37 Outro

Sources:
Vidéo complète disponible ici :
youtube.com/watch?v=e0BEzaNw6Z…
Pour s’abonner :
youtube.com/@academieduclimat
Musique: youtu.be/RNsyw2tfPnk
Montage: lakl42

Pensez à réduire la qualité de la vidéo.

Pour changer le système :
Réclamer le RIC constituant : petitions.assemblee-nationale.…
Changer de banque: lanef.com/ change-de-banque.org/particuli…
Passer à l'action militante: extinctionrebellion.fr/ ripostealimentaire.fr/
Changer de travail : jobs.makesense.org/fr

Réponses au quiz de fin :
/!\ Description à ne pas lire avant d'avoir vu la vidéo entièrement
/!\

/!\

/!\
/!\
En quelle année Jim Hansen a-t-il déclaré le début du changement climatique au Sénat ?
➡ 1988.

Qui représentait officiellement les États-Unis lors de la conférence de Rio ?
➡ Robert Reinstein.

Quel pourcentage des émissions mondiales représente le système alimentaire ?
➡ 33 %.

For the past few days I've been working on making my bash prompt look like the bisexual flag. It wasn't so easy partly because there aren't many colors to chose from, partly because it's not very intuitive.

Let's look at a basic uncolored prompt.

[user@linux-box ~]$ _

PS1='[\u@\h \w]\$ '

If you put that in your ~/.bashrc, your prompt will be uncolored. I like having color on my bash prompt because I can run long commands and glance at my screen for colour (when the command is done.)

For colour you will have to put the colour code. Here is an example of one:

\[\033[95m\]

In this Unix exchange thread, you will use the number and replace the 95 in the example code, then paste it into your PS1 line.

Here is mine currently:

PS1='[\[\033[95m\]\u\[\033[90m\]@\[\033[94m\]\h \w\[\033[37m\]]\$ '

Concrete pumps are perfect for pouring concrete in hard-to-reach places. Pumps are fast, easy to put together, and offer flexibility. Seeing as there are several types of concrete pumps, it's worthwhile to compare and contrast the alternatives available to be able to find the best pump to suit your needs.

Boom Pumps

These pumps are mounted to trucks. They're an incredible selection for road construction projects, and they're also a good choice for just about any project where concrete needs to be transported to an elevated height. Using these pumps, it's easy to get a robotic arm that will bring the concrete to its desired location.

Dealing with this pumps makes it simple to pour concrete across a long distance or even to lift concrete up to where it needs to be. These pumps can significantly reduce labor costs while allowing workers to accomplish projects a lot sooner. Because there are several varieties of boom pumps available, anyone purchasing one of these pumps may wish to compare the latest models of.

Line Pumps

These pumps are often known as stationary pumps. They're usually mounted to a trailer. They can be quite simple to transfer and they are most suitable to horizontal pumping. It's common to view these types of pumps utilized to pour sidewalk. They could also be used to pour patios or other kinds of paving inside a backyard.

Without a line pump, it's usually necessary to use a wheelbarrow to take concrete on the location where it will probably be poured(bomba de concreto descripcion). It's an extended process, and it requires significant labor. In addition to that, it's common for concrete to get spilled when it's being transported.

These pumps allow it to be very easy to bring concrete to your location, even narrow spots that might normally be difficult to arrive at. It's a method to transport concrete with less effort and get better results.

Locating the best Sort of Concrete Pump for Your Needs

When you're considering the different kinds of concrete pumps in the marketplace, one of the most important considerations are the kinds of projects which you usually handle. Do you require equipment that could transport concrete vertically, or are you searching for a pump(bombas de concreto colombia precios) that will enable you to transport concrete horizontally?

Once you've found the sort of pump that's the right fit for you personally, you'll want to check out different models. When comparing models, among the significant factors to check out will be the speed the machinery pumps concrete at. Simply how much concrete will can the pump transport?

If you're able to find a trustworthy concrete pump of aimix that may be well suited for the types of projects you practice on, it's likely that you'll find that it is a rewarding investment. If you take on an array of projects, you may want to choose a pump that can handle a wider variety of tasks.

Purchasing a concrete pump can be a strategy for saving money and boost productivity levels. Having said that, before getting a pump, it's a good idea to compare options and find out more about the various kinds of concrete pumps open to you.

Sensitive content Reveal/hide

Conférence aux Sheds

Dans le cadre du cycle "5 femmes pour le dire", voici la conférence de Khrys "Technologie et Intelligence artificielle : un point de vue libroféministe" du 11/04/2026 .

Spent lots of time with Gnome 2.

In Dec 2024 I got hooked in Hyprland on Arch and have a cool rice for it. But I've tried KDE on desktop now with Parrot OS since Plasma is popular. Still need to find some cool dot files or rice it myself.

I've noticed SwayFX getting lots of love lately. I might use that as an option with Plasma but am afraid of conflicts.
I'm excited about it since Linux has now officially replaced windows on my gaming rig, which is the very last MS computer left in my house.