Si vous pensez que la vitesse d’écriture du code est le problème, alors vous avez un problème plus grave
(andrewmurphy.io)- Les outils de codage IA sont censés accélérer le développement, mais le véritable goulot d’étranglement n’est pas l’écriture du code, plutôt les processus organisationnels inefficaces
- Augmenter le volume de code produit aggrave les blocages dans les étapes non techniques — attente des revues, retards de déploiement, exigences floues — et le cycle time réel peut au contraire s’allonger
- Selon la Theory of Constraints d’Eli Goldratt, optimiser une étape qui n’est pas le goulot d’étranglement n’accélère pas le système : cela l’empire
- Quand même l’auteur ne comprend pas totalement le code généré par l’IA, cela crée un risque structurel où la surface d’exposition aux incidents s’élargit tandis que le nombre de personnes capables de raisonner sur le système diminue
- L’avantage concurrentiel ne revient pas à l’équipe qui écrit du code le plus vite, mais à celle qui comprend quoi construire et le met entre les mains des utilisateurs
Le début d’une mauvaise optimisation
- Des annonces affirment qu’avec l’adoption d’assistants de codage IA, la production de code a augmenté de 40 %
- Mais il manque une question essentielle : « de la vitesse, oui, mais vers quoi ? »
- Injecter des ressources dans une étape déjà rapide (l’écriture du code) ralentit l’ensemble du système
- Accélérer une partie qui n’est pas le goulot d’étranglement entraîne une accumulation de stock de code inachevé, ainsi qu’une baisse de qualité et de la confusion
Optimiser ailleurs que sur le goulot d’étranglement dégrade le système
- Dans The Goal, le roman écrit par Eli Goldratt en 1984, l’idée centrale de la Theory of Constraints est la suivante : tout système possède exactement un goulot d’étranglement, et le débit global du système est déterminé par le débit de ce goulot
- Si l’on optimise une étape qui n’est pas le goulot, le système ne va pas plus vite : on accumule seulement du travail en cours non terminé, ce qui augmente le lead time, la confusion et les problèmes de qualité
- Par analogie, même si la station A fabrique des widgets plus vite, si la station B — le goulot — ne traite pas plus vite, cela revient simplement à empiler des tas de widgets non traités entre A et B
Ce que provoque réellement le « code produit 3 fois plus vite »
- Les développeurs produisent des PR plus vite que jamais, mais comme le nombre de reviewers reste le même, les PR attendent un jour, deux jours, une semaine dans la file de revue
- L’auteur est déjà passé au contexte d’une autre fonctionnalité assistée par IA, si bien que lorsqu’il répond à des commentaires sur un code écrit 8 jours plus tôt, il s’en souvient à peine
- Comme il y a trop de revues, on voit apparaître des reviews tamponnées sans vraie lecture
- La CI prend 45 minutes, échoue à cause de tests flaky puis doit être relancée ; le pipeline de déploiement attend une validation manuelle d’un responsable en réunion, et la fonctionnalité reste 3 jours en staging
- Le développeur a déjà ouvert 2 autres PR, le WIP (Work In Progress) explose, tout le monde avance sur 6 sujets à la fois et rien n’est jamais terminé
- On produit plus de code tout en livrant moins de logiciel ; le cycle time se dégrade, mais le dashboard affiche une hausse de productivité de 40 %
- Risque supplémentaire du code généré par IA : la personne qui l’a « écrit » ne l’a pas réellement écrit ; elle l’a surtout généré via un prompt puis parcouru rapidement. Résultat, lors d’un incident de production à 2 h du matin, ni l’astreinte ni l’auteur du prompt ne sont capables d’expliquer ce code
- Plus de code et moins de compréhension, ce n’est pas un gain de productivité : c’est une bombe à retardement avec un plus joli dashboard
Véritable goulot n°1 : ne pas savoir quoi construire
- Le PM n’a pas parlé à de vrais utilisateurs depuis 2 mois, et les exigences arrivent sous la forme de trois lignes dans un ticket Jira et d’un lien Figma
- Les ingénieurs prennent chaque jour 50 microdécisions (comportement, edge cases, gestion des erreurs) au doigt mouillé, sans spécification claire
- Une équipe a passé 6 semaines à développer une fonctionnalité à partir de ce qu’un commercial avait relayé sur Slack, lui-même basé sur ce qu’un prospect avait peut-être dit lors d’un appel ; ce prospect n’a finalement pas acheté, et la fonctionnalité n’a été utilisée que par 11 personnes, dont 9 en QA interne
- Écrire le code plus vite ne fait qu’accélérer la fabrication de la mauvaise chose ; ce n’est qu’une automatisation de la supposition
- Le goulot d’étranglement, c’est la compréhension du problème elle-même, et aucune vitesse de frappe ne le résout
Véritable goulot n°2 : tout ce qui se passe après que le code est « terminé »
- Dans la plupart des organisations, l’écriture du code ne représente qu’environ 20 % du parcours complet, les 80 % restants étant du temps passé par le code à attendre dans diverses files
- Il existe des cas où une fonctionnalité codée en un après-midi a mis 2 mois à atteindre la production
- Revues de PR, CI, staging, QA, revue sécurité, validation produit, fenêtre de déploiement, canary rollout : une longue chaîne de handoffs, d’attentes et de files d’attente
- La plupart du temps, le code ne bouge pas : il attend qu’on le regarde, qu’un pipeline s’exécute, qu’on lui accorde le droit d’exister
- Pour livrer plus vite, il faut repérer où le travail attend, et mesurer le ratio entre temps d’attente en file et temps de travail réel
Véritable goulot n°3 : le cercle vicieux de la confiance dans le déploiement
- Quand les tests sont flaky, l’observabilité médiocre et que personne n’a confiance dans le processus de canary, les équipes ont peur de déployer
- Cette peur pousse à regrouper les changements en releases plus grosses, ce qui augmente le risque, rend les déploiements encore plus effrayants, et pousse à regrouper davantage : un cercle vicieux de la peur
- Si l’on ajoute à cela une production de code plus rapide, on obtient ceci : plus de code, la même culture de déploiement anxieuse, donc des lots plus gros et une fréquence de release plus faible
Véritable goulot n°4 : l’absence de feedback après la mise en ligne
- Après avoir conçu et lancé une fonctionnalité, il n’y a ni analyses sérieuses, ni entretiens utilisateurs post-lancement, ni personne pour vérifier si cette fonctionnalité résout réellement le problème
- La fonctionnalité suivante est encore une supposition, puis la suivante aussi ; toute la roadmap produit devient une succession de suppositions sans feedback
- Accélérer la production de code ne fait qu’accélérer le cycle « construire, lancer, hausser les épaules »
Véritable goulot n°5 : le calendrier est un mur porteur
- Parfois, le goulot n’est pas technique, mais lié aux réunions nécessaires à la prise de décision, à l’accord sur un contrat d’API entre 3 équipes qui ne se sont pas parlé depuis un mois, ou au backlog de 2 semaines d’un architecte qui constitue le point d’approbation unique de tous les designs importants
- Un processus de planification trimestrielle qui prend 6 semaines peut faire que même un travail urgent doit attendre 5 semaines avant de commencer
- Il existe réellement des cas où une fonctionnalité n’est pas sortie simplement parce qu’on attend une réunion avec quelqu’un qui est en vacances
- Ce sont des problèmes de coordination, des problèmes humains, des problèmes politiques, sans rapport avec la vitesse d’écriture du code
Ce qu’il faut faire à la place
- Cartographier le flux de valeur : suivre une fonctionnalité de l’idée à la production, et noter le temps passé à chaque étape ainsi que les temps d’attente entre étapes
- Mesurer le cycle time : au lieu de mesurer les lignes de code, le nombre de PR fusionnées ou les story points, il faut mesurer le temps entre le commit et le moment où l’utilisateur peut réellement utiliser la fonctionnalité en production
- Éliminer les états d’attente : si la revue de PR prend 2 jours, y remédier avec du pair programming, des PR plus petites, des plages dédiées aux reviews, des règles de revue asynchrones. Si le déploiement attend une validation manuelle, l’automatiser ou, au minimum, passer à un bouton Slack
- Arrêter de démarrer et se concentrer sur le fait de terminer : il existe une raison aux limites de WIP ; 3 sujets terminés valent mieux que 10 en cours. Tout élément en cours a un coût de changement de contexte
- Parler aux personnes de terrain : les développeurs savent déjà où se trouvent les goulots ; ils s’en plaignent en stand-up et en font des mèmes sur Slack depuis des mois. Ils pensaient simplement que personne n’écoutait
Conclusion clé
- Au lieu qu’un VP annonce « production de code +40 % », il aurait dû dire : « notre analyse du flux de valeur montre qu’une fonctionnalité attend en moyenne 9 jours entre les étapes, et nous allons réduire cela de moitié »
- L’avantage concurrentiel ne revient pas à l’équipe qui écrit du code le plus vite, mais à celle qui comprend quoi construire, le construit et le met entre les mains des utilisateurs
- Le goulot d’étranglement, ce n’est pas le clavier
4 commentaires
lol
Le pipeline n’a pas changé
J’ai juste l’impression que les développeurs sont devenus irresponsables.
J’ai envie de devenir un artisan du logiciel.
Commentaires sur Hacker News
Quand notre équipe a commencé à adopter sérieusement le développement basé sur des agents, on craignait que la vitesse de codage augmente mais que le temps de review s’allonge
Pour l’instant, il n’y a pas de changement net, et comme tout le monde est encore en train d’apprendre ce nouveau workflow, on n’a pas assez de données
Mais il y a des cas où coder vite est particulièrement utile — expérimenter des idées, les tâches répétitives complexes, des implémentations simples mais gourmandes en travail, ou la gestion des cas limites après le happy path
Les agents fonctionnent particulièrement bien quand ils prolongent directement une branche existante ou une PR
Le plus gros gain de productivité, c’est que je peux faire autre chose pendant que l’agent code. Par exemple, je peux relire une PR et, quand je reviens, le résultat est prêt
J’étais sceptique au début, mais maintenant je suis prudemment optimiste. Un gain de 10x semble irréaliste, mais même 2x serait déjà énorme
Cette approche ne vaut le coup que si le coût de l’erreur est faible ou si l’ampleur du changement est limitée. Sinon, la qualité et la satisfaction baissent, et seul le planning se retrouve compressé
Au bout du compte, on ne récupère pas vraiment du temps en parallèle ; on reporte juste un peu moins les choses qu’on remettait déjà à plus tard
Cela dit, faire autre chose pendant que l’agent code provoque une fatigue étrange
L’IA est productive, mais c’est une forme de travail totalement différente du fait de coder en tant qu’artisan humain
Un refactoring qu’on aurait eu du mal à abandonner après l’avoir fait soi-même est plus facile à juger honnêtement comme « pas terrible » quand c’est l’IA qui l’a produit
À force de multitâche permanent, on arrive vite au burn-out. C’est dommage que la dimension humaine soit absente de la discussion
Je n’ai pas envie de travailler en permanence dans un état « optimisé »
Quelqu’un disait que le goulot d’étranglement, c’est de comprendre le problème ; moi, j’ai envie de demander pourquoi taper vite n’aiderait pas à mieux le comprendre
Si on construit rapidement quelque chose de faux, ça peut justement permettre de trouver plus vite la bonne direction, non ?
Il m’arrive souvent de découvrir ce que je veux vraiment en fabriquant quelque chose. Plus le prototypage devient bon marché, plus cette tendance se renforce
Bien sûr, ça se termine souvent par la conclusion rétrospective « il aurait fallu parler davantage aux utilisateurs », mais c’est encore un autre problème
Dans une banque, par exemple, on a au mieux droit à une expérience par semaine
Mais la plupart des logiciels ne sont pas comme ça. Écrire du code n’est qu’une partie du travail total
Tout comme un chirurgien ne fait pas seulement « couper », un ingénieur ne se résume pas à écrire du code
Si on reste seul à peaufiner du code, on ne fait que créer davantage de confusion
Parfois, une heure de discussion avec un PM ou un client vaut largement mieux
La folie actuelle autour des LLM donne l’impression qu’on a trouvé la solution avant même d’avoir identifié le problème
Pour vraiment aller plus vite, il faut d’abord demander : « Quel est le goulot d’étranglement ? »
Quand la direction voit une présentation sur l’IA et se dit « ça va nous faire aller plus vite », ce n’est rien d’autre que du vibe management
Le codage en est la partie la plus intensive en main-d’œuvre et la plus automatisable
Les LLM peuvent alléger cette partie de façon significative. Ils sont particulièrement bons, par exemple, pour écrire des tests
Les développeurs humains n’arrivent toujours pas à abandonner leur attachement au code
En réalité, le code n’est qu’une représentation intermédiaire (IR) d’une solution
De la même façon que GCC ne se soucie pas de ses optimisations internes quand il convertit vers l’assembleur, si un agent génère du code, il suffit pour nous d’en vérifier la justesse du résultat
Avec des spécifications claires et un processus de revue itératif, qu’il s’agisse d’un humain ou d’un agent, on peut aboutir à la même implémentation
Un LLM, lui, ne fonctionne pas comme ça. Il peut mal comprendre ou halluciner
C’est pour ça qu’un humain doit toujours faire la review
Les agents choisissent souvent de mauvais patterns ou accumulent de la dette technique
On supprimera peut-être un jour les langages de programmation eux-mêmes, mais on en est encore loin
Le sens peut s’étendre, se compresser, voire disparaître complètement
Beaucoup d’entreprises ne veulent pas vraiment de bon code
L’évaluation interne se fait sur le critère « combien a-t-on livré ? », et si on signale un problème, on s’entend répondre qu’on est « trop pointilleux »
Au final, les parties prenantes internes veulent simplement pouvoir dire que « ça a marché »
Les techniciens ont la responsabilité d’expliquer les risques
Depuis l’adoption de l’IA, une baisse de qualité se manifeste réellement
Dans notre entreprise, les PR sont approuvées à la va-vite, la CI prend 45 minutes et les déploiements sont retardés de plusieurs jours
En plus, l’usage de l’IA est interdit. On dit que le code est majoritairement écrit par des humains, mais j’en doute
Cet article passe à côté de deux points — (A) l’usage d’agents et l’optimisation des processus sont compatibles, et (B) pour certains tickets, le vrai goulot d’étranglement, c’est effectivement le code
Au final, ce qui compte, ce n’est pas l’IA ou non, mais l’amélioration des processus pour supprimer les goulots d’étranglement
Je suis un développeur solo. La vitesse de codage est réellement un problème, parce qu’elle me prend du temps que je pourrais consacrer à autre chose
J’ai configuré Claude Code aujourd’hui, et je passe désormais moins de temps à chercher sur Google ou à écrire des tests
Je ne vais sans doute pas gagner 10x en productivité, mais comme technologie d’économie de travail, ça a largement de la valeur. Un peu comme un lave-vaisselle
Maintenant, l’IA écrit aussi les tests et me signale les cas limites
Ce n’est pas parfait, mais la vitesse de sortie des nouvelles fonctionnalités augmente et j’ai davantage de temps pour moi
Dire « on ne peut pas faire confiance à l’IA », ça me fait penser à « on ne peut pas faire confiance au compilateur »
Au final, c’est un processus où l’humain donne la direction, améliore les prompts et progresse avec elle
Dans les startups ou l’environnement VC, l’essentiel est de résoudre des problèmes business plus que d’écrire du code
Même si la production de code augmente, rien ne garantit que le résultat global du système sera meilleur
Comme avec les templates ou les générateurs de code, on va plus vite, mais tant que la collecte des exigences n’est pas 10x plus rapide, une productivité 10x est impossible
La comparaison est donc un peu mal choisie
Comment faire pour éviter que l’IA commette des erreurs que les humains font rarement ?
Un humain examine généralement le code étape par étape de manière logique, alors que l’IA ne fonctionne pas ainsi
Même chez Amazon, quand un ingénieur senior fait la review, ce n’est pas un processus conçu pour attraper tous les bugs
En plus, plus on est senior, plus on a de réunions et moins on connaît bien le contexte du code. Dans quelle mesure ce type de review est-il vraiment efficace ?
Croire que l’humain est parfait est une illusion
On impose en réalité à l’IA un standard plus élevé qu’aux humains
Au final, l’essentiel, c’est de renforcer le processus de QA. Il ne faut pas laisser les tests aux développeurs
Ça me rappelle le livre The Goal, que j’avais lu autrefois. Quand on automatise une étape d’un processus, c’est l’étape suivante qui devient le goulot d’étranglement
En software, c’est pareil : même si la génération de code s’accélère, ça ne sert à rien si le reste du processus ne suit pas
Au final, tout est subordonné à l’objectif de générer du profit. La qualité du code n’est qu’un concept subordonné à cet objectif
La vitesse d’écriture du code n’est pas un goulot d’étranglement dans les situations à fort risque
Parfois, il vaut mieux planifier lentement et réfléchir aux résultats
Par exemple, si l’on construit trop vite d’immenses systèmes comme dans l’industrie de l’IA, on peut créer un risque civilisationnel en partant dans la mauvaise direction
En revanche, pour un petit jeu bricolé seul le week-end, ce n’est pas bien grave. Au final, c’est l’ampleur du risque qui détermine la vitesse