Laurent Destailleur, de AWStats à DOLIBARR ERP CRM

Entrevue avec Laurent Destailleur, de AWStats à Dolibarr

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.