Si vous pensez que la vitesse d’écriture du code est le problème, alors vous avez un problème plus grave

• 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