La genèse du projet Verretubex
Verretubex est notre premier client. Nous l’avons prospecté par une méthode pour le moins originale. Voyant à quel point mes tentatives de marketing “classique” ne fonctionnaient pas (le fameux “Bonjour, j’ai un service à vous proposer, peut-être que cela vous intéressera!”), je me suis résolu, en dernier recours, à l’honnêteté radicale dans la prospection. Aussi avais-je décidé de dire tout le mal que je pensais de l’informatique d’entreprise dans une newsletter sincère et travaillée mais pas du tout personnalisée et ne commençant même pas par “Bonjour”. J’y dissuadais les chefs d’entreprise destinataires de prendre un ERP, et les encourageais à gérer leur business avec Excel jusqu’à ce que ce ne soit plus possible du tout. Non seulement je n’y avais pas mis de “call to action” ou de “au fait, contactez-moi pour que je vous vende un truc”, mais j’insistais même sur l’inutilité de mes services pour la plupart des entreprises.
En plus de cela, le logiciel de newsletter que j’avais codé en une après-midi (je me disais que ce serait plus rapide de coder le mien que d’apprendre à en utiliser un du commerce) a buggé au moment de l’envoi, et c’est un email plein texte qui s’est envoyé, sans le moindre formatage.
Il semblerait que la sincérité et la sortie des codes habituels de la prospection aient eu un effet positif, car le directeur général de Verretubex est allé sur le site de l’entreprise pour prendre contact avec nous, insistant sur la pertinence de notre approche. Cette entreprise produit des flacons et des ampoules de verre pour l’industrie pharmaceutique et cosmétique, entre autres. Ils reçoivent des cannes en verre, et les forment pour en faire des contenants avec diverses caractéristiques.
La visite originale
Il me semble impossible de développer un bon logiciel sans avoir vu et compris assez profondément comment fonctionne l’entreprise à laquelle il est destiné. Bien sûr, les process sont importants et il est nécessaire d’avoir une vision claire de la chaîne de valeur et des points de blocage liés aux solutions existantes. Mais le plus important est de comprendre la dynamique humaine au sein de l’entreprise. Est-ce que les employés sont débrouillards? Est-ce qu’ils sont responsables? Est-ce qu’ils sont méfiants à l’égard des solutions que nous sommes censés apporter? Le directeur est-il honnête? A-t-il des attentes ajustées à la réalité de ce qui peut se faire avec le budget qu’il est prêt à mettre?
Aussi ai-je rendu visite à l’entreprise, accueilli par le directeur général. Du côté humain, l’environnement était exceptionnel: des salariés investis, un directeur honnête et respectueux de ses employés. Une résistance au changement importante, certes, mais normale a priori.
Il m’est impossible de développer l’aspect technique et organisationnel sans enfreindre l’accord de confidentialité passé avec l’entreprise. On peut juste affirmer que l’environnement technique était assez vieux et impossible à maintenir en l’état. Malgré tout, pour une entreprise de 100 personnes environ, moins de 5 passaient leurs journées derrière un écran, ce qui montre une efficacité exceptionnelle. Aussi mon message au directeur a-t-il été en somme “vous êtes très efficace, mais on peut effectivement vous apporter quelque chose.”
Le premier logiciel
Il a d’abord été convenu de s’attaquer à renouveler et améliorer le logiciel qualité, développé sur une technologie ancienne. Le transfert des données a été très délicat, car peu de dispositifs avaient été mis en place pour éviter la duplication des données, ou simplement garantir leur bonne organisation. Une fois cette partie installée avec succès et la confiance instaurée entre nos deux structures, le directeur a décidé de nous confier le développement du reste de l’ERP.
Au passage, j’avais fait une erreur humaine dans le développement de ce logiciel de qualité: après avoir écouté les besoins des parties prenantes et décortiqué le code source du logiciel existant, j’ai développé le mien de mon côté et suis arrivé un beau jour auprès de l’équipe qualité en disant “Voilà votre logiciel fini, vous pouvez l’utiliser”. L’équipe a bien évidemment été soupçonneuse et a cherché à déceler les bugs et pointer du doigt les défauts du logiciel. Ce qui est normal. Heureusement, cette approche assez franche de leur côté m’a permis de corriger le tir du mien: après avoir essuyé leurs reproches bienveillants, j’ai compris qu’il valait mieux les inclure dans le développement pour qu’ils s’en sentent acteurs et auteurs. Il me semble que la clef de l’adoption est là-dedans. Cela a permis d’inverser la mauvaise tendance qui s’était engagée et de repartir sur une base de collaboration plutôt qu’un bras de fer entre un développeur dans son monde et des utilisateurs qui se sentent incompris.
Le développement de l’ERP
L’ERP a été un projet bien plus lourd que ce logiciel de qualité. Si j’étais déjà un bon développeur, beaucoup de subtilités des règles comptables et des exigences légales m’étaient inconnues.
Cette fois-ci cependant, je n’ai pas fait la même erreur que pour le logiciel de qualité et ai bien impliqué les différentes parties prenantes. La comptable de l’entreprise était très dubitative, voire critique, au début. Cette attitude, toutefois, était proactive. Aussi a-t-il été possible de profiter de son expérience et de son expertise comptable pour réaliser un logiciel qui soit conforme à toutes les bonnes pratiques de la comptabilité, ainsi qu’aux process de Verretubex.
La méthodologie utilisée pour développer cet ERP a ressemblé à la méthode Agile: développer le plus vite possible une fonctionnalité, collecter des retours clients, corriger, redéployer, et itérer ainsi jusqu’à obtenir un logiciel qui corresponde parfaitement aux attentes.
Une des difficultés rencontrées de mon côté a été de développer un ERP spécifiquement pour Verretubex, tout en faisant attention à ce que les composants créés soient les plus génériques possibles et utilisables pour nos autres clients.
Parlons technique
L’ERP a été développé en Node JS, avec le framework minimaliste Express. L’idée de base était que je voulais un framework très léger, car je sais que la durée de vie d’un framework (avant que plus personne ne sache l’utiliser) est de l’ordre de 10 ans maximum. À l’opposé, un langage de programmation qui a fait son trou un jour a de bonnes chances de rester populaire longtemps. Et je vois mal le javascript tomber en désuétude. Bref, l’idée était donc de choisir la technologie ayant le plus de chance d’être maintenable sur une longue durée.
Si j’ai essayé d’utiliser beaucoup de librairies déjà toutes faites au départ (genre DataTable, Bootstrap-Select et JQuery), il s’est vite avéré que j’avais écrit beaucoup de code pour adapter ces librairies à l’usage que j’en faisais, et qu’il m’en faudrait moins pour refaire from scratch et à mon goût les parties qui m’intéressaient. Aussi l’ai-je fait, ce qui a été une très bonne décision au vu du gain de temps et de propreté de code subséquent. Évidemment, j’ai open-sourcé ces librairies ainsi recodées.
J’ai plusieurs fois refondu la base de code lorsque j’ai découvert des choses pouvant être factorisées. Il me semble qu’il serait difficile de faire un code plus compact et modulaire que celui que j’ai fait pour Verretubex.
Il est dit chez Google que le meilleur gage de qualité d’un produit est le fait que ses créateurs l’utilisent eux-même. Aussi Google Docs est-il, comme partout ailleurs, beaucoup utilisé par les employés de cette entreprise. Chez nous, nous utilisons l’ERP que nous avons développé pour Verretubex et nous réemployons son code pour de nombreux usages, comme par exemple l’administration de notre site internet.
Et c’est pour cela que nous nous sommes dit “Et si nous nous concentrions sur les ERP, à l’avenir?”
