Chaque étape de revue ralentit tout d’un facteur 10

• Plus une organisation ajoute d’étapes d’approbation et de revue, plus la vitesse d’exécution ralentit de façon exponentielle ; l’auteur illustre cela avec des exemples où chaque étape d’approbation entraîne environ un facteur 10 de délai supplémentaire
• Même si les outils de codage IA augmentent spectaculairement la vitesse d’écriture du code, la latence du pipeline de revue en aval ne diminue pas, si bien que le gain global reste faible
• En appliquant à logiciel la philosophie de qualité industrielle de W. E. Deming, l’auteur soutient qu’ajouter des étapes de QA dégrade en réalité à la fois la qualité et la vitesse
• Il faut réduire les revues tout en les remplaçant par une culture de qualité fondée sur la confiance et la modularité ; l’essentiel est d’améliorer la structure pour rendre la revue elle-même inutile
• Les petites équipes sont avantagées à l’ère de l’IA, et il faut repenser l’organisation et les systèmes en assemblant de petits composants élégants

---

La loi selon laquelle les étapes de revue créent un facteur 10 de latence

• Comme avec la loi des effets de réseau, quand la taille d’une équipe augmente, un surcoût de coordination apparaît ; doubler l’effectif ne double pas la vitesse
• Règle empirique rencontrée il y a des décennies : chaque étape de revue supplémentaire ralentit le processus d’un facteur 10
• Il n’y a pas de fondement théorique strict, mais le phénomène est observé de façon répétée dans la réalité
• Le temps mesuré ici n’est pas l’effort, mais le temps écoulé réel (wall clock time), dont l’essentiel du surcroît vient de l’attente
• Exemples concrets :
  • Correction d’un bug simple en codage : 30 minutes
  • Revue de code par le collègue d’à côté : 300 minutes (environ 5 heures, une demi-journée)
  • Validation d’un document d’architecture par l’équipe des architectes : 50 heures (environ 1 semaine)
  • Inscription au planning d’une autre équipe (par ex. une demande de fonctionnalité client) : 500 heures (12 semaines, 1 trimestre fiscal)
• L’étape suivante, 10 trimestres (environ 2,5 ans), n’a rien d’irréaliste ; même dans une entreprise relativement petite comme Tailscale, un changement de direction produit peut provoquer ce niveau de délai

L’IA ne peut pas résoudre ce problème

• Même si Claude fait en 3 minutes un codage qui prenait 30 minutes, soit on utilise les 27 minutes gagnées pour itérer directement avec l’IA, soit on transmet à un reviewer du code non vérifié
• Le reviewer a toujours besoin de 5 heures, et si on lui transmet du code qu’on n’a soi-même pas lu, cela l’agace
• On affirme parfois que la vraie valeur du coding agentique est de terminer en quelques heures un gros projet d’une semaine, mais le résultat est trop volumineux pour qu’un reviewer le vérifie d’un seul coup
  • Il faut le découper en petites unités, chacune entraînant un cycle de revue de 5 heures
  • Sans document de conception, il n’y a pas non plus d’architecture intentionnelle, ce qui finit par ramener à une réunion de revue de conception
  • Au final, un projet terminé en 2 heures revient quand même à 1 semaine

La seule méthode consiste à réduire les revues

• Le postulat de la théorie de la Singularity : des systèmes créent des systèmes toujours plus intelligents, et si le temps nécessaire par unité d’amélioration tend vers 0, on obtient une croissance explosive
• Si l’auteur n’y croit pas, c’est parce que l’essentiel du temps nécessaire pour accomplir quelque chose n’est pas le temps de travail réel, mais le temps écoulé réel, c’est-à-dire l’attente et la latence
• La latence ne se surmonte pas en force brute (brute force)

Ne peut-on vraiment pas se passer de revue ?

• Beaucoup reconnaissent le symptôme : la première étape du pipeline (le code généré par IA) s’est accélérée, mais les étapes de revue en aval restent le goulot d’étranglement
• Solution intuitive : arrêtons les revues → même si le résultat est médiocre, s’il coûte 100 fois moins cher, même 1 % de valeur peut suffire à atteindre le seuil de rentabilité
• Cette logique repose pourtant sur une hypothèse assez stupide
• La courbe de descente dans la folie du développeur IA (AI Developer's Descent Into Madness) :
  1. Il construit un prototype à une vitesse stupéfiante → impression de super-pouvoirs
  2. Des bugs apparaissent dans le prototype → il demande à l’IA de les corriger
  3. À chaque changement, de nouveaux bugs apparaissent en même temps que ceux corrigés
  4. Il s’imagine qu’un agent IA qui fait sa propre revue de code finira par trouver ses propres bugs
  5. Il se surprend à faire passer lui-même les données directement entre agents
  6. Il réalise qu’il lui faut un framework d’agents
  7. Il utilise des agents pour écrire le framework d’agents
  8. Retour à l’étape 1
• Claude Code n’est devenu réellement utilisable que depuis quelques mois, si bien que cette boucle n’a démarré que récemment, et beaucoup de collègues ainsi que des personnes respectées sont prises dans ce cycle

Pourquoi fait-on des revues ?

• Quand l’entreprise grandit, les étapes de collaboration, de revue et de gestion se multiplient → pour éviter les erreurs, car le coût des erreurs augmente avec l’échelle
• On arrive à un point où la valeur ajoutée moyenne d’une nouvelle fonctionnalité devient inférieure à la perte moyenne causée par les nouveaux bugs qu’elle introduit
• Comme on ne sait pas augmenter la valeur des fonctionnalités, on se tourne vers la réduction des pertes
• En augmentant les contrôles et la supervision, la vitesse diminue, mais la qualité augmente de façon monotone (monotonically increasing), ce qui semble fournir une base d’amélioration continue
• Mais « plus de contrôles et de supervision » n’est pas le seul moyen d’améliorer la qualité, et c’est même une méthode risquée

La « qualité assurée (QA) » finit au contraire par dégrader la qualité

• Référence à la philosophie qualité popularisée par W. E. Deming dans l’industrie automobile japonaise
• Problème des étapes de QA en usine : fabrication du widget → inspection/QA → retrait des pièces non conformes → pour éviter les oublis, ajout d’une deuxième QA
• Dans un modèle mathématique simple, cela semble rationnel (si chaque étape de QA attrape 90 % des défauts, deux étapes les réduisent d’un facteur 100)
• Mais dans un environnement d’humains autonomes (agentic humans), les incitations se déforment :
  • L’équipe de deuxième QA évalue la première QA → elle n’a pas d’incitation à chercher activement des résultats qui pourraient coûter leur emploi à ses collègues
  • La première équipe QA compte sur la deuxième pour attraper les défauts → elle réduit ses efforts
  • L’équipe qui fabrique les widgets se relâche elle aussi puisqu’il y a une QA → un taux de rebut de 10 % paraît préférable à un ralentissement de 20 %
  • Une refonte d’ingénierie complète pour améliorer la qualité est évité car jugée trop coûteuse
• Le Toyota Production System a supprimé entièrement les étapes de QA et donné à chacun un bouton « arrêter la ligne »
• Les constructeurs automobiles américains ont installé le même bouton, mais personne ne l’utilisait → par peur du licenciement

La confiance (Trust)

• La différence entre le succès du système japonais et l’échec du système américain, c’est la confiance
• Confiance interpersonnelle : être certain que le manager veut vraiment connaître tous les défauts et qu’il faut arrêter la ligne lorsqu’on en découvre un
• Confiance entre managers : être certain que la direction prend réellement la qualité au sérieux
• Confiance de la direction : être certaine qu’avec le bon système et les bonnes incitations, les individus produiront un travail de qualité et détecteront eux-mêmes les défauts
• Condition supplémentaire : la confiance dans le fait que le système fonctionne réellement → encore faut-il d’abord disposer d’un système qui fonctionne

La faillibilité (Fallibility)

• Les codeurs IA écrivent souvent du mauvais code et, sur ce point, ils sont semblables aux programmeurs humains
• L’approche de Deming n’offre pas de solution magique → les ingénieurs doivent concevoir la qualité par le bas dans l’ensemble du système
• Chaque fois qu’un problème survient, il faut demander « comment cela a-t-il pu arriver ? » et remonter à la cause racine avec un postmortem et les Five Whys
• « Le codeur s’est trompé » n’est pas une cause racine mais un symptôme → il faut trouver la cause structurelle qui a rendu l’erreur possible
• Le vrai rôle d’un reviewer n’est pas de faire une revue de code, mais de rendre ses propres commentaires de revue inutiles
  • Améliorer le système pour que ce type de commentaire ne soit plus nécessaire à l’avenir
  • L’objectif doit être un état où la revue n’est plus nécessaire
• Exemple : les créateurs de go fmt → ils ont éliminé définitivement les commentaires de revue liés aux espaces → voilà la vraie ingénierie
• Quand une revue détecte une erreur, c’est que celle-ci a déjà eu lieu → la cause racine est déjà passée

La modularité (Modularity)

• Le pipeline de revue (les étapes de QA) ne fonctionne pas ; il ralentit le système tout en masquant les causes racines, ce qui les rend plus difficiles à corriger
• L’attrait du coding IA : la première étape du pipeline est écrasante de rapidité → impression de super-pouvoirs
• Il existe peut-être désormais une motivation suffisante pour résoudre les problèmes cachés par 20 ans de culture de revue de code et les remplacer par une véritable culture de la qualité
• Les optimistes ont à moitié raison : il faut réduire les étapes de revue, mais les réduire sans rien mettre à la place mène à des catastrophes du type Ford Pinto ou aux récents avions de Boeing
• Comme ce que Deming a apporté au monde industriel, il faut un basculement complet du paquet (table flip) ; un système de qualité à l’échelle de toute l’entreprise ne peut pas être adopté à moitié
• Il faut supprimer les revues tout en les rendant simultanément inutiles
• On peut adopter complètement un nouveau système à petite échelle :
  • Analogie avec un vieux constructeur automobile américain qui achète des composants de haute qualité à des fournisseurs japonais
  • Si les composants sont bien conçus, on peut supprimer ailleurs des étapes de QA → la complexité du travail d’assemblage de composants diminue fortement
• On peut assembler de petites belles choses pour construire une grande belle chose
• De petites équipes qui se font confiance fabriquent des composants individuels en sachant ce que signifie la qualité pour elles
• Les équipes clientes expliquent clairement ce que signifie la qualité pour elles → la qualité se diffuse du bas vers le haut

Petites équipes et conception des organisations à l’ère de l’IA

• Les petites startups pourraient être avantagées dans ce nouveau monde → avec peu de monde, elles ont naturellement moins d’étapes de revue
• Certaines startups trouveront comment produire vite des composants de haute qualité, les autres échoueront → qualité par sélection naturelle
• Les grandes entreprises sont prisonnières de systèmes de revue lents ; les supprimer pourrait provoquer un chaos total
• Quelle que soit la taille de l’entreprise, les équipes d’ingénierie peuvent devenir plus petites et définir plus clairement les interfaces entre équipes
• On peut imaginer, au sein d’une même entreprise, un modèle où plusieurs équipes développent en concurrence le même composant
  • Chaque équipe serait composée de quelques personnes et de bots de codage
  • On tente 100 approches pour choisir la meilleure → qualité par évolution
  • Le code est bon marché, mais les bonnes idées restent chères → on peut toutefois tester de nouvelles idées bien plus vite qu’avant
• Un nouveau point optimal pourrait apparaître sur le continuum monolithe–microservices
  • Les microservices ont acquis une mauvaise réputation parce qu’ils étaient trop petits, mais dans le sens originel du terme, un service « micro » avait une taille adaptée à une équipe « deux pizzas » pour le construire et l’exploiter
  • À l’ère de l’IA, on parle plutôt d’« une pizza et un peu de tokens »
• Ce nouveau codage rapide permet aussi d’expérimenter plus vite les frontières des modules elles-mêmes
  • Les fonctionnalités restent difficiles, mais le refactoring et les tests d’intégration automatisés sont des domaines où l’IA excelle
  • On peut essayer de séparer des modules qu’on n’osait pas découpler auparavant → le nombre de lignes de code augmente, mais cela reste peu coûteux comparé au surcoût de coordination d’une grande équipe qui maintient les deux côtés
• Toute équipe a un monolithe trop gros et trop d’étapes de revue
• Même sans atteindre la singularité, on peut concevoir par l’ingénierie un monde bien meilleur → le problème est solvable
• Le point clé, c’est la confiance