Gouverner à la vitesse des agents : l’IA révèle les limites de nos systèmes de décision

Résumé

Le 24 septembre 2026, le podcast officiel de Scrum.org a consacré un épisode à « Agentic Product Development: Governance at the Speed of AI », avec Matthew Hodgson et Dave West. Hodgson y présente Raptors, une expérimentation devenue un modèle de travail avec une équipe d’agents IA cross-fonctionnelle, comprenant notamment un agent Scrum Master nommé Al. [1]

Le signal intéressant n’est pas simplement qu’une IA puisse endosser certaines activités associées à un Scrum Master. Il est plus systémique : lorsque l’exécution accélère fortement, la vitesse du système de décision devient une contrainte beaucoup plus visible.

Dans le retour d’expérience Raptors, Hodgson insiste notamment sur l’importance de fichiers de gouvernance explicites, sur les limites d’autonomie des agents et sur les situations dans lesquelles une supervision humaine reste nécessaire. Il considère également que les modèles traditionnels de gouvernance peuvent fonctionner trop lentement face à des équipes agentiques. [1]

Cette question entre directement en résonance avec Scrum. Le Scrum Guide fonde le framework sur l’empirisme et sur trois piliers — transparence, inspection et adaptation — et attend d’une Scrum Team qu’elle soit auto-organisée. [2]

Comment accélérer les décisions sans accélérer simultanément les mauvaises décisions ?

Quand l’exécution accélère, la gouvernance devient visible

Une organisation peut supporter longtemps certaines lenteurs décisionnelles lorsque son système d’exécution fonctionne lui-même sur des cycles relativement longs.

Avec des agents capables d’enchaîner rapidement analyse, production et nouvelles itérations, ce rapport change. Une validation qui interrompait auparavant une chaîne de travail pendant une fraction raisonnable de son cycle peut devenir proportionnellement beaucoup plus coûteuse.

Cela ne signifie pas que les contrôles doivent disparaître.

Le retour d’expérience Raptors pointe précisément la nécessité de règles explicites et de supervision humaine dans certaines situations. [1]

Le problème n’est donc pas simplement « comment supprimer les validations ? », mais : quelles décisions nécessitent réellement une validation, lesquelles peuvent être décentralisées et comment faire évoluer cette frontière à partir de ce que nous observons ?

Pour un Product Owner, un Scrum Master ou un responsable de delivery, l’amélioration du système ne porte alors plus uniquement sur le workflow de production. Elle concerne également le système de décision qui l’entoure.

Concevoir une gouvernance empirique

Le Scrum Guide fournit un point de départ utile. Scrum considère que, dans un environnement complexe, la connaissance provient de l’expérience et que les décisions doivent s’appuyer sur ce qui est observé. Transparence, inspection et adaptation structurent cette approche. [2]

Appliqué à la gouvernance d’agents, ce principe conduit à considérer les règles d’autonomie elles-mêmes comme des hypothèses à inspecter.

Une règle n’est pas nécessairement pertinente parce qu’elle existe depuis longtemps. Elle devrait pouvoir être reliée à un risque identifiable, produire un effet observable et être réexaminée lorsque le contexte évolue.

1. Commencer par les décisions, pas par les agents

Avant de déterminer ce qu’un agent peut faire, cartographier les décisions du workflow :

• qui décide actuellement ;
• quel risque la validation cherche à couvrir ;
• quel délai elle introduit ;
• quelles conséquences aurait une erreur ;
• dans quelle mesure la décision peut être annulée.

Cette cartographie permet de déplacer la discussion de « que peut faire l’IA ? » vers « quelle autonomie sommes-nous prêts à déléguer, dans quelles limites et pourquoi ? »

2. Utiliser la réversibilité comme frontière

Toutes les décisions ne nécessitent pas le même niveau de contrôle.

Niveau 1 — décision réversible et faible risque. L’agent ou l’équipe peut agir directement. L’action reste observable et peut être corrigée a posteriori.

Niveau 2 — impact significatif mais maîtrisable. L’agent analyse, prépare ou recommande. Une validation humaine intervient dans le flux avant l’action déterminante.

Niveau 3 — décision difficilement réversible ou risque élevé. Une validation humaine explicite est requise avant exécution.

Cette classification n’est pas une règle issue du Scrum Guide ni du projet Raptors. C’est un cadre de décision proposé ici pour traduire opérationnellement le problème de gouvernance mis en évidence par le retour d’expérience.

3. Rendre l’autonomie observable

Raptors souligne l’importance particulière de fichiers de gouvernance explicites lorsque des agents participent au travail. [1]

Une gouvernance exploitable devrait donc rendre visibles au minimum :

• l’objectif confié à l’agent ;
• ses limites d’action ;
• les sources qu’il peut utiliser ;
• les actions qu’il réalise ;
• les situations imposant une escalade ;
• les critères provoquant son arrêt.

La transparence ne sert pas uniquement à contrôler l’agent. Elle rend possible l’inspection du système qui lui donne son autonomie.

Inspecter également les règles lors de la Sprint Review

Scrum définit la Sprint Review comme une occasion d’inspecter le résultat du Sprint et de déterminer les adaptations futures. [2]

Avec un workflow agentique, cette inspection peut utilement inclure les règles de gouvernance elles-mêmes.

Exemple pédagogique

Une équipe produit utilise un agent pour qualifier les incidents entrants.

Son objectif pourrait être : « Réduire le délai de qualification des incidents sans augmenter le risque de mauvaise orientation. »

L’équipe décide initialement que :

• les incidents standards peuvent être classifiés automatiquement ;
• les incidents liés à la sécurité nécessitent une validation humaine ;
• les classifications dont le niveau de confiance est insuffisant sont escaladées ;
• aucun incident critique ne peut être automatiquement clôturé.

Avant l’expérimentation, elle définit également ses critères d’adaptation :

• conserver l’autonomie si le niveau de qualité attendu est atteint ;
• envisager de l’élargir si ce niveau reste supérieur à un seuil défini pendant plusieurs Sprints ;
• revenir à un contrôle plus strict lorsqu’une erreur correspondant à un risque critique apparaît.

Ces seuils sont des critères pédagogiques de décision, pas des résultats observés.

À la Sprint Review, l’équipe peut alors inspecter deux choses : le résultat obtenu par le système et la pertinence des règles qui encadrent son autonomie. La gouvernance entre ainsi dans la même boucle empirique que le produit.

Mesurer l’outcome, pas l’obéissance de l’agent

Un agent peut parfaitement respecter ses instructions et produire malgré tout un résultat sans valeur.

Evidence-Based Management apporte ici un complément intéressant. Scrum.org présente EBM comme une approche destinée à améliorer les outcomes, réduire les risques et optimiser les investissements dans des conditions d’incertitude. Sa version actuelle a été publiée en mai 2024. [3]

La question n’est donc pas seulement « l’agent a-t-il exécuté correctement son workflow ? », mais : l’autonomie accordée améliore-t-elle effectivement le résultat recherché sans déplacer le risque ailleurs ?

Quelques indicateurs peuvent aider à l’observer :

• temps médian entre détection d’un besoin de décision et décision effective ;
• proportion de décisions autonomes qui restent réellement réversibles ;
• fréquence et pertinence des escalades humaines ;
• erreurs ayant nécessité une intervention après décision autonome ;
• délai entre une expérimentation et l’apprentissage permettant d’adapter le système ;
• évolution des règles de gouvernance à partir des observations.

Les indicateurs exacts dépendront naturellement du risque et de l’outcome recherchés.

Anti-patterns et parades

« L’IA est rapide, supprimons les contrôles »

La vitesse n’annule pas le risque. Parade : distinguer contrôle et bureaucratie. Questionner les validations qui ne couvrent plus de risque identifiable, tout en maintenant des protections proportionnées aux conséquences possibles.

« Toutes les décisions remontent au comité IA »

Centraliser toutes les décisions peut déplacer le goulot d’étranglement sans résoudre le problème. Parade : expliciter les limites d’autonomie et permettre la décentralisation des décisions suffisamment réversibles.

« L’agent a respecté son prompt »

La conformité d’exécution n’est pas une mesure de valeur. Parade : mesurer les conséquences produites et les comparer à l’outcome recherché.

« Nos règles sont définies une fois pour toutes »

Une règle adaptée à une première expérimentation peut devenir inadaptée lorsque les capacités, les risques ou le contexte changent. Parade : intégrer les règles de gouvernance dans les mécanismes réguliers d’inspection et d’adaptation.

« Plus d’output signifie plus de valeur »

Accélérer la production ne démontre pas que davantage de valeur est créée. Parade : relier l’autonomie accordée à des résultats observables. EBM met précisément l’accent sur l’amélioration des outcomes plutôt que sur la seule augmentation de l’activité. [3]

Ce que l’IA agentique change réellement

Le retour d’expérience Raptors ne démontre pas qu’un modèle particulier de gouvernance serait universellement supérieur.

Il fournit cependant un signal concret : lorsqu’une équipe d’agents devient capable d’agir et d’itérer rapidement, les règles qui encadrent cette équipe deviennent une partie explicite du système à concevoir. [1]

Scrum fournit alors une mécanique particulièrement pertinente : rendre visible, inspecter, apprendre et adapter. Le Scrum Guide souligne d’ailleurs qu’une adaptation devient plus difficile lorsque les personnes concernées ne sont pas habilitées ou auto-organisées. [2]

La question n’est donc probablement pas de choisir entre contrôle humain et autonomie agentique. Elle consiste à déterminer où placer la frontière aujourd’hui, comment observer ses conséquences et dans quelles conditions la déplacer demain.

Conclusion

L’IA agentique ne rend pas la gouvernance inutile. Elle rend son coût, ses incohérences et parfois son utilité beaucoup plus visibles.

Quand l’exécution accélère fortement, une organisation ne peut plus aussi facilement masquer les décisions lentes, les escalades systématiques ou les règles dont la justification n’est plus claire.

La réponse n’est ni le contrôle permanent ni l’autonomie absolue.

Elle consiste à traiter la gouvernance comme un système empirique : rendre les règles transparentes, déléguer ce qui peut raisonnablement l’être, protéger les décisions dont les conséquences l’exigent, observer les résultats puis adapter les frontières.

L’IA accélère l’exécution. Scrum peut fournir la boucle d’apprentissage permettant d’inspecter ce que cette accélération produit.

Le nouvel enjeu n’est donc peut-être pas de gouverner aussi vite que les agents. Il est de faire évoluer la gouvernance aussi vite que l’organisation apprend.

Sources

1. Scrum.org Community Podcast — « Agentic Product Development: Governance at the Speed of AI », Matthew Hodgson & Dave West, 24 septembre 2026

2. Ken Schwaber & Jeff Sutherland — The Scrum Guide, novembre 2020

3. Scrum.org — Evidence-Based Management Guide, mai 2024