Le goulot d’étranglement de l’IA : pourquoi un code plus rapide ne fait pas des produits plus rapides
Cet article a été rédigé avec l’aide de l’IA et révisé par l’équipe agenthouse. Les illustrations sont générées par IA.
L’IA a rendu l’écriture de code logiciel moins coûteuse et beaucoup plus rapide. De nombreuses équipes s’attendaient à ce que les fonctionnalités parviennent aux clients au même rythme. La plupart constatent que ce n’est pas le cas. Une idée de 1984 explique pourquoi.
Un processus ne va jamais plus vite que son étape la plus lente
En 1984, le physicien et penseur du management Eliyahu M. Goldratt publie The Goal (en français : Le But), un roman sur un directeur d’usine qui tente de sauver une usine en difficulté. Le livre introduit la théorie des contraintes. Son idée centrale est simple : chaque étape d’un processus a son propre débit, et l’ensemble du système ne peut jamais livrer plus que son étape la plus lente, la contrainte. Accélérer une autre étape n’aide pas. Cela ne fait qu’accumuler des stocks devant le goulot d’étranglement.
Goldratt a d’abord appliqué cette idée aux ateliers de production. Il l’a ensuite étendue à la gestion de projet, et des livres comme The Phoenix Project l’ont fait entrer dans l’informatique et la livraison logicielle.
Le rythme qui fait avancer le travail
Les processus suivent un rythme. Le Lean manufacturing l’appelle le takt, du mot allemand signifiant « mesure » : la cadence à laquelle le travail doit passer d’une étape à la suivante. Goldratt décrivait la même chose comme un tambour, battu par la contrainte, qui donne la cadence à tous les autres.
Souvent, le signal est à peine visible. Pensez à la sonnette d’une cuisine de restaurant qui indique au serveur qu’un plat est prêt à être servi, ou au coup de sifflet qui autorise un train à partir. Lorsque chaque étape travaille au même rythme, le processus est en harmonie.
Le développement logiciel l’est rarement. En cycle en V comme en agile, les déroulements parfaitement équilibrés sont l’exception : les exigences stagnent, les revues s’accumulent, les mises en production attendent les tests.
Ce que l’IA change : une étape est devenue beaucoup plus rapide
L’IA générative a accéléré exactement une étape de la chaîne : l’écriture du code. Ce qui prenait des jours prend désormais des heures, parfois des minutes. Le processus subit ainsi une pression des deux côtés.
En amont, la question « que devons-nous construire ? » devient un vide. Lorsque la mise en œuvre n’est plus le facteur limitant, la qualité des entrées compte bien davantage. Le business development et la gestion de produit doivent comprendre les besoins réels des clients plus vite et plus précisément qu’auparavant. Sinon, l’équipe construit efficacement des fonctionnalités que personne ne veut et que personne ne paie. Un code rapide ne rend pas une mauvaise idée meilleure. Il la met simplement plus tôt sur le marché.
En aval, un nouveau goulot d’étranglement se forme. Les développeurs qui relisent le code généré par l’IA, les responsables de test, les architectes et les ingénieurs DevOps doivent soudain évaluer beaucoup plus d’éléments. L’étape d’écriture du code a gagné un ordre de grandeur. Les étapes de revue, de test et d’exploitation, non.
Le résultat est celui que Goldratt aurait prédit : le travail en cours s’accumule devant la nouvelle contrainte. La vitesse ressentie lors de la génération de code ne se traduit pas par des mises en production plus rapides. C’est particulièrement vrai dans les entreprises qui tiennent encore à un logiciel maintenable et fonctionnel, et elles ont raison.
La solution : harmoniser toute la chaîne, pas une seule étape
Rendre une étape encore plus rapide ne résoudra pas le problème. Ce qui aide, c’est de soutenir chaque étape avec la même structure agentique, afin que des attentes claires s’appliquent à chacune, de la première hypothèse de marché jusqu’aux notes de version. Nous appelons cette structure un harnais d’agentic engineering.
Validation du marché. Les agents aident les équipes à tester des hypothèses, à réunir des preuves et à atteindre l’adéquation produit-marché avant toute transmission. Le résultat : des artefacts structurés, et non des idées éparses.
Gestion de produit. La gestion de produit transforme ces artefacts en user stories pertinentes. Avec le même framework, chaque story a le bon périmètre, est testable et respecte une Definition of Ready (DoR) claire avant le début du développement.
Développement et tests. Le développement piloté par les tests (TDD) est planifié directement à partir de la user story, avec les règles de gouvernance propres à l’équipe. La qualité est intégrée à la source au lieu d’être découverte lors de la revue.
Revue et exploitation. Les relecteurs ne partent plus de zéro. Ils vérifient un travail déjà réalisé selon des critères convenus. C’est comme si le contrôleur technique travaillait aux côtés du mécanicien, au lieu d’attendre en bout de chaîne.
Documentation et mise sur le marché. Une documentation assistée par l’IA est produite au fil du travail. Le marketing produit et les équipes de support disposent de contenus exacts au même rythme que l’évolution du produit.
Dès que chaque étape travaille au même rythme, la vitesse gagnée grâce au codage par IA atteint enfin le client.
Toute l’histoire en 18 secondes
Ouvrir l’animation sur sa propre page (18 secondes, sans son)
Pour commencer
Chaque élément de ce harnais est disponible dans le framework open source d’agentic engineering d’agenthouse : des rôles, des skills et des processus produit réutilisables, de la validation du marché à la livraison, au support et à l’apprentissage.