Quand le code devient abondant, la décision devient le goulot d’étranglement

Introduction

L’intelligence artificielle accélère désormais des activités qui limitaient autrefois la capacité des équipes : écrire du code, produire une première analyse, synthétiser des retours clients ou préparer un document. Cette accélération ne garantit pourtant ni un meilleur flux ni davantage de valeur livrée.

Plusieurs analyses récentes convergent sur le même déplacement systémique. Lorsque la production devient rapide, les contraintes se concentrent en aval : code review, tests, validation métier, arbitrage produit, décisions de financement et capacité de l’organisation à agir sur ce qu’elle apprend [1][2].

Le véritable enjeu n’est donc plus seulement d’augmenter la productivité individuelle. Il consiste à redessiner le système afin que l’abondance de production ne se transforme pas en accumulation de travail, en dilution des responsabilités ou en accélération de mauvaises décisions.

🚦 L’IA déplace la contrainte au lieu de la supprimer

Une équipe peut produire du code plus vite tout en manquant ses Sprint Goals. Le paradoxe disparaît dès que l’on observe l’ensemble du flux : une étape accélérée alimente plus rapidement les étapes qui restent limitées par l’attention humaine.

La code review demande de comprendre la logique générée, de détecter les effets de bord et de vérifier l’adéquation au besoin. Les tests, les retours métier, la sécurité et le déploiement disposent également d’une capacité finie. Si l’équipe ouvre davantage de sujets parce que la génération paraît moins coûteuse, le travail s’accumule précisément devant ces étapes [1].

La conséquence managériale est contre-intuitive : une capacité de production accrue peut justifier des limites de WIP plus strictes. Il faut rendre visibles les files d’attente situées après le développement, puis limiter le nombre d’éléments simultanément en review, en test et en attente de décision.

Le bon indicateur n’est pas le nombre de lignes générées, de pull requests ouvertes ou de tâches commencées. C’est le temps nécessaire pour transformer une intention en résultat utilisable, avec un niveau de qualité démontré.

Cette distinction protège l’organisation contre une confusion fréquente :

L’IA ne rend donc pas le flow management obsolète. Elle augmente au contraire le coût d’un système qui ne contrôle pas ses entrées.

👁️ Rendre le travail visible ne suffit pas

Une autre tension apparaît lorsque l’organisation investit dans des dashboards, de la télémétrie ou des outils de cartographie. Ces dispositifs peuvent révéler les dépendances, les files d’attente, la dette technique et les travaux non planifiés. Mais un signal visible auquel personne ne peut répondre devient rapidement du bruit.

Les analyses Lean récentes insistent sur ce point : visualiser une anomalie sans mécanisme de réaction produit un « andon ignoré ». À terme, les équipes apprennent que les alertes n’entraînent aucun changement et cessent de leur accorder de l’attention [2].

Une information opérationnelle n’a donc de valeur que si elle est reliée à :

• une personne ou une équipe capable de décider ;
• une politique explicite de réaction ;
• de la capacité réservée pour intervenir ;
• un délai au-delà duquel l’inaction devient visible ;
• une possibilité réelle d’arrêter ou de réordonner le travail.

Cette lecture change la manière d’instrumenter une chaîne de delivery agentique. Le but n’est pas de collecter tout ce que les agents peuvent mesurer. Il est de sélectionner les signaux susceptibles de modifier une décision.

Un tableau montrant quinze revues en attente n’améliore rien si les équipes continuent à démarrer de nouvelles fonctionnalités. À l’inverse, une politique qui suspend l’entrée de nouveaux travaux lorsque la file dépasse une limite transforme le signal en mécanisme de régulation.

La règle de conception peut se formuler simplement : ne mesurez pas une condition sur laquelle personne n’est autorisé ou préparé à agir.

🧭 Les problèmes récurrents appartiennent souvent au système

Lorsqu’un obstacle revient Sprint après Sprint, le traiter comme un incident local devient une forme de déni organisationnel. Une décision centrale qui ralentit plusieurs équipes, une dépendance structurelle ou une autorité maintenue loin du travail ne disparaîtront pas grâce à une meilleure facilitation de la prochaine rétrospective.

Une analyse publiée le 15 octobre propose de regrouper les observations issues de plusieurs rétrospectives afin d’identifier les motifs récurrents. L’objectif est de passer de l’événement isolé à la structure qui le reproduit : approbation centralisée, dépendance permanente, boucle de renforcement ou responsabilité mal placée [4].

Cette démarche est particulièrement importante avec des agents. Une automatisation exécutera fidèlement la structure qu’on lui donne. Elle peut donc accélérer une boucle dysfonctionnelle sans jamais remettre en cause son existence.

Trois niveaux doivent être distingués :

1. L’événement : une pull request attend deux jours.
2. Le motif : les reviews dépassent régulièrement la capacité disponible.
3. La structure : l’organisation récompense le démarrage de fonctionnalités, mais ne réserve aucune capacité à leur validation.

Une action locale peut corriger l’événement. Une politique de WIP peut réduire le motif. Seule une modification du système de responsabilité, de capacité ou d’incitation traite la structure.

L’intérêt du raisonnement systémique n’est donc pas de rendre le diagnostic plus abstrait. Il évite d’optimiser une équipe contre un problème qu’elle ne peut matériellement pas résoudre.

🎯 L’autorité de décider devient une capacité opérationnelle

Lorsque plusieurs personnes « partagent » une responsabilité, l’intention initiale est souvent positive : obtenir davantage de perspectives, représenter plusieurs métiers et éviter qu’une seule personne concentre trop de pouvoir.

Mais contribution et accountability ne sont pas équivalentes. Si chacun doit obtenir l’accord des autres avant d’arbitrer, une décision devient une négociation permanente. Le backlog finit alors par représenter l’équilibre politique entre parties prenantes plutôt qu’une stratégie produit cohérente [5].

Avec l’IA, cette ambiguïté devient plus coûteuse. Un agent peut préparer davantage d’options, analyser davantage de retours ou générer davantage d’hypothèses. Il ne résout pas la question de savoir qui tranche lorsque ces signaux sont contradictoires.

Une organisation agentique a donc besoin de responsabilités plus nettes, pas plus diffuses :

• l’agent collecte, compare ou prépare ;
• les experts contrôlent les éléments relevant de leur domaine ;
• une accountability identifiée arbitre la priorité et assume la décision ;
• la décision, ses preuves et ses limites sont conservées ;
• les résultats observés peuvent conduire à la réviser.

Cette logique rejoint le rôle de Chief Engineer décrit dans le Lean Product Development. La responsabilité porte sur l’intégration globale du produit, alors même que l’autorité hiérarchique directe peut être limitée. La capacité essentielle consiste à relier compréhension client, maîtrise technique, coût, commercialisation et coordination des expertises [7].

L’organisation produit ne doit donc pas choisir entre expertise distribuée et décision claire. Elle doit distribuer la connaissance tout en préservant l’identifiabilité de l’arbitrage final.

🏛️ Le delivery agentique est d’abord un problème de gouvernance

Scrum peut fonctionner comme une méthode de livraison enfermée dans un projet : périmètre fixé en amont, budget approuvé sur une promesse, Sprint Review transformée en démonstration et décisions conservées par un comité extérieur à l’équipe.

Dans ce modèle, l’empirisme s’arrête à la frontière de l’équipe. Les informations produites pendant les Sprints ne peuvent pas modifier la décision de financement initiale. L’IA aide alors à réaliser plus vite un périmètre dont la pertinence n’est plus réellement inspectée [3].

Scrum peut aussi être utilisé comme système de gouvernance. Le Product Owner décide de l’ordre des investissements, la Sprint Review confronte les résultats aux outcomes attendus, et la Definition of Done impose un niveau de qualité quel que soit l’auteur du travail — humain ou agent.

Quatre questions permettent de distinguer les deux modèles :

• Le Product Owner peut-il réordonner le Product Backlog sans change request ?
• Les preuves présentées en Sprint Review ont-elles déjà modifié un financement ou arrêté un investissement ?
• Qui décide que le résultat satisfait réellement le niveau de qualité attendu ?
• L’équipe reste-t-elle responsable après la mise en production afin d’observer l’effet obtenu ?

Si toutes les réponses renvoient vers un comité extérieur, l’équipe dispose peut-être d’un processus Scrum, mais pas de l’autorité nécessaire à une gouvernance empirique.

La vitesse des agents amplifie cette différence. Dans un système gouverné par les outputs, ils consomment plus rapidement le budget consacré à une hypothèse non vérifiée. Dans un système gouverné par les preuves, ils réduisent le délai entre l’hypothèse et la décision de poursuivre, modifier ou arrêter.

🔍 Le jugement humain change de nature

L’IA peut analyser un volume de verbatims, de données d’usage et de demandes internes qu’aucun Product Owner ne pourrait lire seul. Elle peut signaler une dérive entre les comportements observés, le Product Goal et les décisions passées.

Ce rôle est particulièrement utile pour rechercher les contradictions : besoins clients émergents, signaux de résiliation, problèmes d’utilisabilité récurrents, biais de confirmation ou poursuite d’un investissement uniquement parce qu’il a déjà coûté cher [9].

Cependant, relier ces informations ne signifie pas posséder l’autorité de décider. L’agent prépare le jugement ; il ne transforme pas automatiquement une corrélation en causalité ni une fréquence de mention en priorité produit.

Le travail humain se déplace ainsi de la production primaire vers quatre activités :

• définir ce qui constitue une preuve suffisante ;
• examiner les contradictions et les absences ;
• apprécier le coût d’une erreur ;
• prendre et assumer la décision.

Cette posture rejoint une exigence Lean plus ancienne : préserver le doute malgré l’expérience. Les habitudes organisationnelles rendent certaines anomalies invisibles ; le retour au gemba et aux faits permet de distinguer la situation réelle de l’explication devenue automatique [6].

Le risque avec l’IA n’est pas seulement d’accepter une réponse fausse. C’est de recevoir une formulation si cohérente qu’elle ferme prématurément le champ des questions.

🧪 La qualité doit être définie avant l’automatisation

Un workflow peut continuer à fonctionner techniquement tout en produisant un résultat métier inacceptable. Le format reste valide, l’exécution se termine sans erreur, mais une information décisive est omise ou un état bloqué est présenté comme maîtrisé.

Ce risque apparaît notamment lors d’un changement de modèle. Un prix par token inférieur ou un benchmark supérieur ne démontrent pas que le workflow complet sera moins coûteux ou plus fiable. Il faut intégrer la revalidation, les corrections humaines, les répétitions et le coût d’un résultat erroné [8].

Chaque workflow significatif devrait donc posséder :

• un responsable identifiable ;
• une AI Definition of Done adaptée au niveau de risque ;
• des exemples acceptables et inacceptables ;
• les entrées et sorties de référence ;
• la configuration ayant produit ces résultats ;
• une procédure de revalidation ;
• une période de surveillance après modification.

L’unité économique pertinente n’est pas « un million de tokens ». C’est un résultat qui satisfait le standard convenu, y compris le coût des vérifications nécessaires pour le démontrer.

Cette approche empêche également la dépendance aveugle aux benchmarks fournisseurs. Une mesure générique de performance peut aider à présélectionner un modèle, mais seule l’évaluation sur les cas réels du workflow permet de décider s’il reste adapté.

📊 Piloter par probabilités plutôt que restaurer une fausse certitude

Lorsque la production accélère, la tentation consiste à promettre davantage. Or la variabilité ne disparaît pas : elle se déplace vers les reviews, les dépendances, les retours clients et les décisions.

La prévision probabiliste offre une réponse plus honnête qu’une date unique issue d’une estimation fragile. À partir du throughput historique, une simulation Monte Carlo produit une distribution de résultats et permet d’exprimer un niveau de confiance [10].

Le changement est autant managérial que statistique. Dire « nous avons 85 % de chances de terminer dans cette fenêtre » ouvre une discussion sur le risque accepté. Dire « ce sera fini à telle date » masque l’incertitude jusqu’au moment où elle devient un retard.

Les métriques utiles doivent couvrir quatre niveaux :

Cette architecture relie la performance locale aux résultats globaux. Elle évite qu’une amélioration de vitesse soit déclarée réussie alors qu’elle n’a fait qu’allonger une autre file.

🛠️ Transformer le système sans lancer un programme de plus

La première étape consiste à sélectionner un flux réel et à le suivre de l’idée jusqu’à l’usage. Les colonnes génériques « À faire / En cours / Terminé » sont insuffisantes si elles masquent les reviews, attentes, validations et retours.

Il faut ensuite mesurer le WIP, l’âge des éléments et les temps d’attente par étape. L’objectif n’est pas d’évaluer les personnes, mais de localiser les contraintes qui absorbent le gain produit par l’IA.

La troisième étape consiste à associer chaque signal à une politique de réaction. Par exemple : lorsqu’une code review dépasse vingt-quatre heures, aucune nouvelle fonctionnalité n’est démarrée par l’équipe concernée tant que la file n’est pas revenue sous sa limite.

La quatrième étape concerne la décision produit. Il faut vérifier que les preuves collectées pendant la livraison peuvent réellement modifier les priorités, le financement ou le Product Goal.

Enfin, chaque automatisation récurrente importante doit être enregistrée comme une capacité opérationnelle : propriétaire, finalité, sources autorisées, niveau de risque, standard de qualité, cas de test, modèle utilisé, coûts complets et procédure de rollback.

Cette démarche n’exige pas de réorganisation générale préalable. Elle commence par une seule chaîne de valeur, un seul workflow agentique et une décision que l’organisation souhaite rendre plus rapide sans la rendre moins fiable.

Conclusion

L’IA ne supprime pas les contraintes du système produit. Elle révèle celles que la lenteur de production permettait auparavant de dissimuler.

Lorsque le code devient abondant, la rareté se déplace vers l’attention, le jugement, la validation et l’autorité de décider. Une organisation qui répond en augmentant simplement le volume de travail transforme ce gain technique en congestion.

L’avantage durable ne viendra donc pas des équipes qui génèrent le plus. Il viendra de celles qui limitent mieux, voient plus tôt, vérifient explicitement et savent arrêter une hypothèse dès que les preuves ne la soutiennent plus.

La question stratégique n’est plus « combien l’IA peut-elle produire ? ». Elle devient : à quelle vitesse notre organisation peut-elle transformer une production abondante en décision fiable et en valeur vérifiée ?

Index

• AI Definition of Done : critères vérifiables définissant un résultat acceptable pour un workflow utilisant l’IA.
• Accountability : responsabilité finale d’une décision, distincte de la participation ou de la contribution.
• Andon : signal visible indiquant une anomalie et normalement relié à un mécanisme de réaction.
• Cycle time : durée entre le début et la fin d’un élément de travail dans le flux observé.
• Gemba : observation directe de la situation réelle, au lieu de raisonner uniquement depuis des rapports.
• Outcome : changement observable obtenu pour un utilisateur ou l’organisation.
• Throughput : nombre d’éléments terminés pendant une période donnée.
• WIP : travail commencé mais pas encore terminé.
• WIP limit : limite explicite du nombre d’éléments autorisés simultanément dans une étape.

Sources

1. Mary Iqbal, You Need Tighter WIP Limits With AI, Scrum.org, 12 octobre 2026.

2. Steve Pereira, You Can’t Improve What You Don’t Commit To, Lean Enterprise Institute, 14 octobre 2026.

3. Matthew Hodgson, Scrum: Delivery Method or AI Governance?, Scrum.org, 13 octobre 2026.

4. Cesario Ramos, See the System: When a Team Impediment Is Really a Design Problem, Scrum.org, 15 octobre 2026.

5. Chuck Suscheck, Cognitive Trap: Accountability Diffusion, Scrum.org, 12 octobre 2026.

6. Arnaud Barde, Le doute, une compétence à préserver, Institut Lean France, 12 octobre 2026.

7. Lex Schroeder, Toyota Veteran Naoto Kitagawa’s 17 Principles for Chief Engineers, Lean Enterprise Institute, 12 octobre 2026.

8. Stefan Wolpers, Das KI-Modell wechseln oder nicht, das ist hier die Frage!, Scrum.org, 15 octobre 2026.

9. Stefan Wolpers, AI-Assisted Product Discovery: When Code Is Cheap, Judgment Is the Job, Scrum.org, 18 octobre 2026.

10. Paul Grew, Stop Guessing, Start Forecasting: Why Scrum Teams Should Embrace Monte Carlo, Scrum.org, 16 octobre 2026.