La semaine dernière, je vous racontais comment nous avons décidé de monter notre usine IA : une chaîne de production pilotée par des agents, pour livrer du logiciel qu’on peut reprendre et entretenir sans en relire chaque ligne.
(Re)lire l’édition précédente :
Sauf que des principes clairs, ça ne fait pas une usine qui tourne. Entre l’idée et la première version qui a vraiment livré du code, il y a eu plusieurs tentatives, quelques impasses et un redémarrage complet. Si vous avez déjà lancé un chantier d’automatisation qui a commencé par ralentir l’ensemble en ajoutant de la complexité au lieu d’en retirer, cette histoire va vous parler.
De la théorie à la pratique
Au printemps, on avait nos principes, des idées plein la tête, et une méthode encore purement théorique. Nous avons alors construit notre première usine depuis ce canevas purement théorique, et on l’a lancée.
A son démarrage, on a vu des choses bouger, on s’est dit que ça allait marcher. Puis on a essayé de s’en servir.
Ce qui a cassé
Trois choses. D’abord, chaque poste produisait son propre compte-rendu pour le suivant, et un humain devait valider à chaque étape. Résultat : une file d’étapes de validation, exactement ce qu’on cherchait à supprimer. Ensuite, le cadre était si serré que la machine demandait la permission pour tout, y compris pour agir sur l’usine elle-même. « Je ne peux pas modifier ce fichier. Celui-là non plus. Tu m’autorises ? » Dix allers-retours pour une étape. On avait construit quelque chose de plus rigide que de travailler à la main avec l’IA. Enfin, la verbosité. La machine expliquait tellement de choses qu’à la fin, on ne comprenait plus ce qui ne marchait pas.
On a même donné l’outil à un collègue sur un autre projet. Il n’a rien compris à ce que l’usine avait produit. Et quand il nous l’a montré, on n’a rien compris non plus : un mélange du vocabulaire de notre méthode, qu’il ne connaissait pas, et du vocabulaire de son métier, qu’on ne connaissait pas. Personne ne pouvait lire ce que l’usine avait écrit.
Quatre jours à régler la machine et pas une ligne de code livrée.
Repartir de zéro
Le jour suivant, on a tout mis de côté et on est repartis d’une page blanche. Avec une conviction en plus : on ne peut pas concevoir un système parfait sur le papier. Les vrais problèmes n’apparaissent qu’une fois que ça tourne. Il faut donc lancer une version simple, la faire travailler sur un vrai projet, corriger ce qui bloque, relancer, et recommencer.
Cette fois, pas de programme magique. On a décrit précisément ce dont on avait besoin, et on a construit l’usine une brique à la fois, en lançant chaque poste à la main pour vérifier qu’il faisait bien son travail avant d’ajouter le suivant. Ça n’avançait pas aussi vite que souhaité, mais ça livrait du code.
Puis les réglages sont venus les uns après les autres. On a supprimé les comptes-rendus entre chaque poste au profit d’un seul fil qui suit le travail d’un bout à l’autre. On a automatisé progressivement, un poste après l’autre, au rythme où la confiance montait. On a donné à chaque poste des consignes courtes, propres à sa mission. Et enfin, on a imposé une règle de sobriété à la machine : deux ou trois phrases pour dire ce qu’elle a fait, le détail seulement si on le demande.
La leçon, on la connaissait déjà sans l’avoir vécue. Quand on ne fait pas confiance à un système, on lui ajoute des validations. Et on recrée exactement la lourdeur qu’on voulait supprimer. La confiance ne vient pas du contrôle, elle vient d’autre chose : savoir ce qui se passe dedans.
L’heureux hasard
Tous ces réglages, on les a faits en réaction : quelque chose bloquait, on corrigeait. Mais le changement qui a le plus fait progresser l’usine est venu par hasard. À la fin de chaque lot, on avait pris l’habitude de demander à la machine un court bilan : ce qui s’était bien passé, ce qui avait coincé, où elle avait perdu du temps. Au départ, c’était juste pour garder une trace et s’en souvenir plus tard.
Très vite, ce bilan est devenu le point de départ de chaque nouveau lot. On le lisait, on repérait les deux ou trois choses à corriger, on ajustait l’usine, et on relançait. Sans l’avoir cherché, on tenait notre troisième principe : l’amélioration continue fonctionne comme une chaîne, avec ses étapes et son rythme. L’usine ne s’est pas améliorée parce qu’on la surveillait de près. Elle s’est améliorée parce qu’on lui demandait, à chaque tour, ce qu’il fallait changer.
De ce premier échec, on a gardé une règle simple.
Il y a ce qu’on ne touche pas : les principes.
Il y a ce qu’on règle selon le contexte : les postes, les consignes, le niveau d’automatisation.
Et il y a ce qui appartient à chaque projet : ses choix propres.
Notre erreur avait été de vouloir tout figer d’avance, y compris les deux derniers. Pour votre équipe, la question à poser avant un chantier de ce type n’est donc pas « est-ce que ça marchera partout », mais « est-ce qu’on saura voir où ça coince ».
On en a fait un livre
Au bout de quelques mois, on s’est rendu compte d’une chose : ce qu’on venait de vivre, personne ne le racontait. Les articles parlaient des outils, jamais de ce qu’il faut monter dans une équipe pour qu’ils servent à quelque chose. Les échecs, on ne les trouvait nulle part.
Alors on a décidé de tout écrire.
Dix mois de construction, d’impasses et de réglages. Plusieurs CTOs qui ont accepté de raconter les leurs, sans arrondir les angles. Et une méthode complète pour monter une usine logicielle dans une équipe qui existe déjà, avec son code, ses habitudes et ses contraintes. Ce n’est pas un guide de plus pour bien utiliser l’IA. C’est un livre sur ce que ça change, pour une équipe et pour une entreprise, le jour où plus personne n’écrit le code à la main.
Il sort le 26 novembre.
Et dans la prochaine édition, je vous raconte comment il est né, parce que lui non plus ne devait pas exister sous cette forme.
A très vite,
L’équipe Hones