Dans la dernière édition de TechRadar, on vous parlait pour la première fois de notre usine IA ou AI software factory : chez Hones, on ne produit plus le logiciel à la main, on l’a confié à une chaîne de production pilotée par l’IA.
(Re)lire l’édition précédente :
Si vous avez équipé vos développeurs d’une licence Claude ou GPT il y a six mois, vous vous êtes peut-être posé la même question que nous : qu’est-ce que ça a changé, au fond, dans la façon dont l’équipe produit ? Souvent, pas grand-chose. C’est de cette question que notre usine est née, et on ouvre ici une série pour raconter comment on l’a construite, avec les choix, les détours et ce que ça a changé pour nous.
Chacun sa tambouille
En février dernier, on a réuni toute l’équipe une journée pour mettre à plat nos façons de travailler avec l’IA. Le constat a été rapide : mêmes besoins, mêmes problèmes, mais autant de manières de s’y prendre que de personnes autour de la table.
On avait pourtant une méthode commune, le Spec-Driven Development : écrire précisément ce qu’on attend avant de laisser l’IA produire le code, puis vérifier que le résultat correspond. Elle fonctionne très bien seul sur un projet. Mais elle finit par devenir ingérable, parce qu’elle demande à un humain de valider chaque étape, et qu’il finit par dire oui sans regarder. Et on ne parle même pas de travailler en équipe dessus…
Au même moment, nos clients nous posaient tous la même question : comment mettre de l’IA dans nos équipes de développement ? Ils avaient déjà compris qu’une licence par développeur ne suffit pas. Tout ce qu’on voyait sur le marché répondait à la question individuelle : comment devenir un bon utilisateur de l’outil. Personne ne répondait à la question d’organisation : comment on produit du logiciel quand une machine écrit le code.
C’est de là que vient notre usine.
L’usine répond à la question de la confiance. Si le code est écrit par une machine, comment je fais confiance à ce qu’elle produit ? Parce que si ça casse chez un client, ce n’est pas la machine qu’on vient voir, c’est nous. On a d’abord essayé de tout relire. Mais la machine va tellement plus vite que nous qu’on finit spectateur de son propre chantier, à vérifier au lieu de construire. Notre objectif était de créer un système qui produit du logiciel qu’on peut reprendre et entretenir, sans devoir en contrôler chaque ligne.
Ce qu’on voulait était clair. Comment y arriver, beaucoup moins. On a donc commencé par se mettre d’accord sur quelques règles, simples à énoncer, difficiles à tenir, qui allaient guider chaque décision de construction. Elles sont toujours là aujourd’hui, et elles définissent les fondations de notre usine.
Trois principes.
1. L’humain cadre et décide, la machine produit.
Une chaîne fabrique, une autre contrôle. L’humain intervient là où son jugement compte, pour définir le besoin et trancher au moment de mettre en production, pas pour cocher des cases.
2. On ne compose que du découpé.
Une usine est faite de postes distincts, chacun avec une mission claire et un résultat attendu, qu’on peut remplacer sans toucher aux autres. C’est un vieux principe d’ingénierie logicielle, celui de la clean architecture : des briques indépendantes, reliées par des contrats stables. Comme une prise électrique : peu importe ce qu’on branche, la forme ne change pas et le courant passe.
3. L’amélioration continue est elle-même une chaîne.
Après chaque lot livré, on regarde ce qui a coincé, on corrige, on garde une trace. Une usine saine n’est pas une usine sans défaut. C’est une usine où, pour chaque défaut, on sait quel poste l’a laissé passer et quoi régler pour qu’il ne revienne pas.
Ce que ça a vraiment changé dans nos pratiques.
Le changement majeur porte sur le rôle du développeur lui-même. Notre équipe ne produit plus le code : elle conçoit et règle l’outil qui produit le code, et elle porte la vision de ce qu’on veut obtenir. Le code lui-même n’est plus la partie précieuse, la machine peut le régénérer à volonté pour presque rien. Ce qui a de la valeur, c’est tout ce qui rend cette régénération possible : les consignes, les contrôles, la connaissance du métier qu’on a mis dans l’usine. C’est ça qu’on construit et qu’on entretient désormais.
Ça change aussi où on met son attention. Avant, un développeur passait une bonne partie de son temps à trancher des questions techniques en cours de route : comment structurer telle partie, quelle approche retenir pour tel besoin. Dans l’usine, c’est la machine qui instruit ces questions. Elle analyse le besoin, propose plusieurs options argumentées et en recommande une. Et à force de relire ces recommandations, on a constaté quelque chose : dans 97 % des cas, on retient celle qu’elle propose. Autant lui laisser la main sur ces choix, et garder notre temps et notre jugement pour les 3 % qui méritent vraiment qu’un humain tranche.
Pour une direction, la question n’est donc plus d’équiper les développeurs. C’est de décider à quoi ressemble la production quand ils n’écrivent plus le code.
Cette usine ne s’est pas montée d’un coup. Il y a eu plusieurs versions, plusieurs modèles abandonnés en route, et une bonne dose de fausses pistes avant d’arriver à quelque chose qui tourne pour de vrai. Dans la prochaine édition, je vous raconte l’une de ces étapes : celle où on a voulu aller trop vite, et où tout s’est effondré.
A très vite,
L’équipe Hones