La newsletter des CEO de la tech
« Le code généré par l’IA, c’est de la dette technique qu’on découvre six mois plus tard. »
Cette phrase vous avez dû la lire plus d’une fois cette année. C’est le genre de discours qu’on croise partout sur Linkedin; qui explique que coder avec l’IA est une mauvaise idée. Que ça produit du code fragile, impossible à reprendre, et que les boîtes qui s’y sont jetées paieront l’addition dans deux ans.
Cela va sûrement vous étonner, mais pour une fois, je ne vais pas les contredire (en tout cas, pas entièrement 😉).
On défend l’IA dans le développement depuis le début, on en a fait notre sujet, et ceux qui nous suivent savent qu’on est plutôt du genre à démonter ce genre d’argument. Sauf que sur le constat cette fois, on accepte de donner quelques points aux septiques (profitez-en, ce n’est pas le cas tous les jours).
Des bases de code qui grossissent beaucoup plus vite qu’avant, des modules dont plus personne ne sait dire pourquoi ils existent, des tests au vert qui ne rassurent plus grand monde : tout ça est bien réel, on le voit chez nos clients.
Ce sur quoi on diverge, c’est la conclusion qu’ils en tirent !
Ce qui s’est vraiment passé dans les équipes
Ces deux dernières années la plupart des boîtes ont acheté des licences de LLM à leur équipes; Copilot, Cursor, Claude code, distribués aux développeurs, en attendant de voir un miracle se produire. C’est comme ça que la plupart des IA nous ont été vendues, mais c’est ce qui a amené à la situation qu’on observe aujourd’hui.
Parce qu’un assistant IA, sans règle autour, aussi efficace soit-il, ne permettra au développeur que de multiplier son travail. Un bon développeur produira beaucoup de bon code. Une équipe qui n’avait déjà pas l’habitude de travailler ensemble produira beaucoup de code, tout court.
Dans les deux cas, la capacité de production explose et rien n’a été ajouté pour la contrôler. Le jour où quelque chose casse, personne ne peut dire d’où ça vient. L’humain ? Le modèle ? La consigne ? Le contexte qu’on lui a fourni ? Tout porte le même nom, « l’IA », et on ne peut pas débugger ce qu’on ne peut pas ouvrir.
Les sceptiques regardent ce résultat et en déduisent que l’IA ne sait pas produire du bon code. Moi j’y vois autre chose : on a demandé à des outils de faire le travail d’une organisation. Et ça ne marche jamais, avec ou sans IA.
Bienvenue à l’ère des usines IA !
Quand je dis « organisation », je ne parle pas d’un organigramme. Je parle de choses très concrètes : qui décide de ce qu’on construit, qui vérifie que ce qui sort correspond à ce qu’on a demandé, et comment on remonte à la source quand ça ne correspond pas. Dans une équipe de développeurs classique, tout ça existe déjà, souvent sans être écrit. Avec des agents IA, c’est différent.
Ce qu’il faut donc construire autour, c’est une structure où la production est découpée, où chaque étape est vérifiée, et où une erreur peut être localisée. Ce n’est pas nouveau. C’est exactement ce qu’a fait l’industrie il y a quelques décennies.
Une usine, ça s’organise autrement qu’un atelier où chacun a sa perceuse. La production est découpée en postes. Chaque poste a un rôle, une entrée, une sortie, et un contrôle avant de passer au suivant. Quand une pièce sort défectueuse, on remonte la ligne jusqu’au poste concerné, et on ne touche à rien d’autre.
Appliqué au logiciel, cela donne des agents IA spécialisés qui se passent le travail comme des postes sur une chaîne, avec une ligne de contrôle qui vérifie chaque étape avant la suivante, et des humains qui cadrent au départ et supervisent à l’arrivée.
Ce que ça change dans l’approche : le rôle du développeur n’est plus d’écrire ou de relire le code (ça n’a d’ailleurs jamais été le but du métier). Désormais, il cadre ce qu’il faut produire, décide, et contrôle la machine. Et quand la sortie pose problème, il peut désormais se demander « à quel poste ça s’est joué », et cette question a une réponse. Un composant avec un rôle défini, c’est un composant qu’on peut examiner.
Vous voyez l’écart avec la simple distribution de licences. Donner un assistant à chaque développeur, c’est faire le pari que la qualité viendra de chaque individu, multipliée par un outil. L’usine fait le pari inverse : la qualité vient de la structure, et l’individu n’a plus à la porter seul. C’est ce qui rend le résultat prévisible, et c’est aussi ce qui rend la bascule difficile, parce qu’il faut accepter de réorganiser complètement la façon dont l’équipe travaille.
Ce changement, certains l’ont déjà mis en place.
Ceux qui construisent déjà leur usine
L’industrialisation de la tech, n’est pas une idée qu’on défend dans notre coin en attendant que le marché nous rejoigne. Plusieurs entreprises en Europe, ont déjà commencé leur transformation.
Prenez Cdiscount. En juillet, ils ont présenté ce qu’ils appellent leur « usine agentique ».
Thomas Métivier et son DSI Christophe Samson étaient déjà des utilisateurs aguerris de Copilot et de Claude. Ils sont allés un cran plus loin : plusieurs agents spécialisés qui se passent le travail comme les postes d’une chaîne, l’un sur les API, un autre sur les modèles de données, un troisième sur l’interface, un dernier qui vérifie la qualité du code avant la mise en production.
Leur raisonnement est celui d’un industriel : un modèle unique se perd sur une base de code trop grande, alors on découpe la tâche en postes dédiés, pour obtenir des développements plus rapides et surtout plus fiables. L’usine tourne depuis trois mois avec quelques équipes pilotes. Elle a déjà produit plus de 80 évolutions sur le site, et l’équipe qui gère les commandes de la marketplace a ramené certaines opérations de maintenance d’une journée à environ deux heures. Métivier a fixé le cap : d’ici la fin de l’année, la moitié du code qui structure la plateforme devra sortir de ces usines.
Ce qui rend le cas intéressant, c’est d’où ils partent. Peaksys, leur filiale tech, ce sont plus de 450 développeurs à Bordeaux et une mise en production toutes les sept minutes, avec des indicateurs de vitesse et de fiabilité suivis depuis des années. L’usine agentique n’est pas venue réparer une organisation qui n’y arrivait pas. Elle prolonge une équipe qui savait déjà produire proprement, et Cdiscount le dit lui-même : ce qu’ils cherchent avec cette usine, c’est faire évoluer leur organisation en profondeur.
Et puis il y a Eno, qui part de zéro. Deux ingénieurs bruxellois, une boîte créée en janvier, et Thibaud Elzière qui en fait la première recrue de sa verticale « AI for Work » chez Hexa. Eux sont partis directement sur ce modèle. Une plateforme de briques, formulaires, tableaux, automatisations, génération de documents, connectées à des agents IA, et à partir de ça ils sortent un logiciel de gestion complet pour un métier donné. Ils ont commencé par les traiteurs, après avoir rencontré plus de 160 professionnels et travaillé avec une vingtaine de design partners. Ils visent aujourd’hui plus de 130 métiers, et ils proposent même à des entrepreneurs de venir lancer la leur sur la plateforme en apportant leur connaissance du terrain. Le logiciel n’est plus quelque chose qu’on développe une fois pour un client. C’est ce qui sort de la ligne, métier après métier.
Un géant du e-commerce qui avait déjà industrialisé son delivery, une startup qui n’a jamais connu autre chose. Deux histoires opposées, mais la même conclusion sur la façon de produire du logiciel avec l’IA. Quand des acteurs aussi différents arrivent au même endroit en même temps, on n’est plus dans l’opinion. C’est une révolution qui déjà a commencée.
Un an d’usine, ce qu’on peut déjà vous dire
Chez Hones, cela fait déjà près d’un an que nous travaillons sur le sujet. Nous avons créé notre usine AI et la faisons tourner depuis plusieurs mois.
Concrètement à quoi cela ressemble ? Un premier agent écrit la spécification, un deuxième en tire l’architecture, et l’implémentation ne démarre qu’après. En face, une ligne de contrôle séparée : des vérifications automatiques qui arrêtent tout au premier défaut, puis une relecture par un agent qui n’a pas écrit le code. La revue humaine vient en dernier et se concentre sur ce qui peut vraiment faire mal, les accès et les données personnelles notamment. Et entre chaque poste circule un document spécifique de cadrage.
Est-ce que ça règle la dette technique ? Pas entièrement, et je me méfie de ceux qui vous promettent le contraire. L’usine peut toujours faire des erreurs quand le besoin change en cours de route, et elle ne se règle pas toute seule. Mais la dette qu’elle produit, on sait où elle se trouve. Et c’est toute la différence avec ce que décrivent les septiques de Linkedin.
Il vous reste donc un choix à faire (et pas beaucoup de temps pour passer le cap) : continuer à distribuer des licences, ou réorganiser votre équipe autour. Si vous êtes dans le premier cas et que vous pensez que ça marche, répondez à ce mail et racontez-moi. Je serais sincèrement curieux de lire un contre-exemple.
Dans le prochain numéro de TechRadar, on vous ouvre le capot de notre usine : comment on l’a construite, ce qu’on a raté en route, et ce qu’on referait autrement.
A très vite,
L’équipe Hones