Deux semaines, de zéro à la démo client

Une chose d’abord. Mes années dans l’industrie ont été consacrées à la surveillance d’infrastructures, et la propriété des données de terrain n’a jamais fait de doute : elles appartiennent au client, ou à l’employeur de l’époque — jamais à moi. Ce que j’ai emporté, c’est l’expérience : à quoi ressemble ce type de données, quelles questions un ingénieur leur pose, ce qui rend une réponse utile. Cet article raconte comment un prototype de produit a été construit en deux semaines. Les données de personne n’y interviennent.

Ce prototype a fini par s’appeler MurSense : une IA conversationnelle pour la surveillance de santé des grandes infrastructures.

La première coupe porte sur le périmètre

« La surveillance de santé des grandes infrastructures » est un sujet très large : ponts, tunnels, barrages, talus, tours — chacun vaut plusieurs années à lui seul. Vouloir tout cela en deux semaines, c’est n’avoir rien du tout.

Je n’ai donc gardé qu’une seule verticale : les ponts ferroviaires. Non parce qu’ils seraient les plus faciles, mais parce que les archives d’ingénierie de ce type d’ouvrage sont les moins indulgentes, et parce que je savais ce qui préoccupe vraiment, au jour le jour, ceux qui exploitent un pont.

L’objectif de la démo a lui aussi été réduit à une phrase : permettre à quelqu’un qui connaît les ponts de demander, en langage naturel, ce qu’il devrait normalement chercher en écrivant un script — et d’obtenir une réponse à laquelle il ose se fier. Cette phrase est devenue l’unique critère de recette des deux semaines : toute idée qui ne la servait pas est partie au vivier de tâches.

Fonctionnel en deux jours, puis tout ce qui n’est pas du code

La chaîne fonctionnait au bout de deux jours : un agent qui décide lui-même quel segment d’enregistrement consulter, quelle analyse appeler, puis répond dans la langue des ingénieurs.

L’essentiel du temps restant n’est pas allé au modèle. Un nom, un logo, une interface, un manuel que l’on peut lire sans moi, une vidéo de démonstration, des supports en trois langues. Les ingénieurs rangent volontiers tout cela dans « l’emballage » ; mon ressenti est exactement inverse : une démo n’est pas un programme, c’est une histoire que quelqu’un d’autre peut raconter à votre place. Une fois la démo vue, le dirigeant du client doit pouvoir retourner expliquer à son équipe de quoi il s’agit — s’il sait la redire, les deux semaines ont servi à quelque chose.

À l’époque, je n’avais pas encore les outils d’aujourd’hui

À noter : quand j’ai fait cela, je n’utilisais pas encore les outils agentiques en ligne de commande. C’était une simple fenêtre de dialogue, plus ma propre discipline multi-fenêtres : une fenêtre ouvre la fiche, une fenêtre exécute, une troisième prononce la recette.

Je ne dis pas que les outils importent peu. Je dis que ce qui fait gagner du temps n’a jamais été la nouveauté de l’outil, mais la capacité du processus à bloquer les reprises en amont. Mes outils ont changé plusieurs fois en deux ans ; cette discipline, elle, n’a pas bougé d’une ligne.

Après les deux semaines

Le prototype a ensuite été montré plusieurs fois à de vrais clients, et a suscité des intentions de poursuivre. Mais je veux être précis : niveau démo n’est pas niveau produit. Deux semaines suffisent à produire quelque chose devant quoi on accepte de s’asseoir et de continuer à discuter, et c’est encore très loin d’un système qui tourne pendant des années sur le site de quelqu’un d’autre — là où il pleut, où le courant saute, où quelqu’un sectionne la fibre à la pelleteuse. Rien de tout cela n’est dans une démo.

Ce que j’en ai vraiment gardé tient en trois lignes : réduire à une seule verticale ; finir chaque journée avec quelque chose de démontrable en main ; ne jamais faire la recette de son propre travail.