On the Loop - Diriger l'IA est un problème d'empowerment

Kief Morris a publié début mars un article sur le site de Martin Fowler intitulé Humans and Agents in Software Engineering Loops. C’est le meilleur framework court que j’aie lu sur la place que doit occuper l’humain quand les agents font le travail. Si vous avez déjà essayé d’expliquer à un CTO sceptique pourquoi “je relis toujours chaque ligne” ne sera plus une position tenable dans dix-huit mois, c’est l’article à lui mettre entre les mains.

Ce qui m’a frappé en le relisant, ce n’est pas la nouveauté du framework. C’est que le framework est quasi identique à celui que Marty Cagan et Reed Hastings prêchent aux product leaders depuis vingt ans. La bonne façon de diriger un agent IA se trouve être la bonne façon de diriger un ingénieur senior. Les leçons durement acquises des empowered teams, le context not control de Netflix et Drive de Daniel Pink se transposent directement. Si vous les maîtrisez, diriger l’IA est un changement de médium, pas de discipline. Si vous ne les maîtrisez pas, l’ère de l’IA l’exposera plus vite que n’importe quelle réorganisation.

C’est l’article que j’aurais aimé voir en binôme avec mon article sur le vibe coding en prod de cette semaine. Eric Schluntz nous a donné le cadrage de l’ingénieur contributeur individuel : soyez le PM de Claude. Morris nous donne le cadrage équipe et organisation : soyez on the loop, pas dedans. Ensemble, ils décrivent un seul basculement - du faiseur à celui qui empower - qui s’applique à tous les niveaux de l’organisation.

Les cinq positions de Morris

Le geste central de Morris consiste à rejeter le binaire. Dans la plupart des équipes, le débat est posé ainsi : “est-ce qu’on laisse les agents livrer du code, ou est-ce qu’on relit chaque diff ?” Ce cadrage est un piège. Il expose cinq positions distinctes d’implication humaine, dont une seule est réellement productive aujourd’hui :

Position	Ce que fait l’humain	À quoi ça ressemble
Outside the loop	Fixe la direction produit, laisse les agents tout faire en aval	Vibe coding pur ; ne marche que pour du jetable ou du contenu isolé
In the loop	Inspecte chaque artefact produit par l’agent	Micromanagement ; les humains deviennent le goulot d’étranglement
On the loop	Construit et maintient le harness - specs, contrôles qualité, règles de workflow	La zone productive aujourd’hui
Les agents gèrent le harness	Les humains dirigent des agents qui améliorent le harness lui-même	Frontière émergente
Le flywheel agentique	Les agents analysent les performances de la loop par rapport à des signaux plus riches (métriques, parcours utilisateur, résultats commerciaux) et proposent des améliorations, certaines auto-approuvées	Système auto-améliorant, toujours engineered

Les deux positions par défaut de tout le monde - in the loop et outside the loop - sont les deux qui ne fonctionnent pas. In the loop recrée le goulot d’étranglement d’origine : l’agent peut générer une semaine de code en une heure, et l’humain qui prétend la relire ment ou bloque tout. Outside the loop est le mode d’échec YOLO : vous perdez la qualité interne, qui se trouve compter précisément parce qu’elle se compose dans les résultats externes. La formule de Morris est tranchante : “des codebases propres aident les agents à travailler plus vite ; partir en vrille sur du code en désordre gaspille temps et ressources.”

La zone productive est on the loop. Arrêtez de corriger des artefacts individuels. Commencez à améliorer le système qui les produit. C’est du pur shift-left appliqué aux agents : au lieu d’inspecter chaque PR, vous investissez dans les spécifications, les critères d’évaluation, les règles architecturales et les portes de review qui attrapent les problèmes à la source. Le harness devient le point de levier.

Pourquoi cela se lit exactement comme EMPOWERED

Voici la partie qui m’a fait redresser. Remplacez agent par équipe et humain par manager, et le framework de Morris devient une reformulation directe de EMPOWERED de Marty Cagan.

Cagan répète depuis deux décennies que la différence entre une feature team et une empowered team, c’est l’endroit où se tient le manager. Un manager de feature team se tient in the loop : il relit chaque décision, approuve chaque solution, agit comme goulot d’étranglement et, pire, comme single point of failure créatif. Un manager d’empowered team se tient on the loop : il pose le contexte stratégique via la vision, la stratégie, les objectifs d’équipe et les garde-fous architecturaux, puis il s’écarte pendant que l’équipe trouve comment résoudre le problème. Sa formule pour cela, que je répète dans chaque conversation de leadership depuis des années, est la même que celle utilisée par Reed Hastings chez Netflix : lead with context, not control.

Le parallèle profond avec le framework de Morris est le suivant :

In the loop = management de feature team. Vous êtes le goulot d’étranglement, vous êtes le single point of failure, et vous produisez des résultats médiocres parce que vous êtes la personne la moins informée de la pièce sur le travail réel.
On the loop = management d’empowered team. Vous construisez les conditions dans lesquelles un travail de haute qualité se produit sans vous sur le chemin critique. Vous relisez les résultats, pas les artefacts. Vous coachez et vous posez le contexte, vous ne conduisez pas.
Le flywheel = une organisation empowered mature. L’équipe n’exécute pas juste le harness ; elle l’améliore. Elle ramène des données, propose des changements, et le système s’améliore sans intervention constante du manager. En termes humains, c’est ce que Hastings appelle high talent density with candor and context. En termes agentiques, c’est le flywheel de Morris.

La mécanique est identique. La partie difficile - pour les managers qui dirigent des humains comme pour les ingénieurs qui dirigent des agents - est la même que celle que Cagan martèle sans relâche. Il faut renoncer à la dopamine d’être la personne la plus intelligente dans la pièce. Il faut faire confiance au système que vous avez construit. Cette confiance scale. Vos cycles de review personnels, non.

No Rules Rules est le manuel d’exploitation

No Rules Rules de Reed Hastings est le livre que je viens de lire il y a deux semaines, et dont j’ai parlé ici. La distance entre cette critique et cet article est gênante de brièveté.

Les trois leviers de Hastings - talent density, candor, et suppression des contrôles - sont exactement les trois leviers qui font fonctionner la position on the loop de Morris. Correspondance :

Talent density -> agents capables. Netflix licencie les performeurs moyens parce qu’un seul coéquipier moyen tire toute l’équipe vers le bas. L’analogue IA est que des modèles capables rendent toutes les autres décisions de leadership plus faciles. Une équipe sur Claude Sonnet 4.6 ou Opus 4.7 peut se voir confier de plus larges pans de la loop du comment qu’une équipe sur les modèles de l’an dernier. Une faible talent density humaine force le contrôle ; une faible capacité des agents force le micromanagement. Les deux sont solubles, et les deux sont des prérequis, pas des bonus.
Candor -> signaux d’évaluation. La règle Netflix veut qu’il soit déloyal de taire un désaccord. L’équivalent agentique est que le harness doit disposer de signaux honnêtes et rapides : tests unitaires, tests d’intégration, évals, métriques de production, résultats commerciaux. Si votre système d’évaluation flatte l’agent, vous obtenez le même résultat qu’une équipe où personne ne dit ce qu’il pense vraiment. De la médiocrité qui a l’air confiante et que personne ne conteste.
Supprimer les contrôles -> réduire la surface d’inspection. Netflix a supprimé le suivi des congés, l’approbation des notes de frais et l’approbation des décisions parce que les contrôles coûtaient plus cher qu’ils ne rapportaient. On the loop pour les agents dit la même chose : arrêtez d’inspecter chaque diff, arrêtez de gater chaque PR sur une relecture humaine. Remplacez les portes par des garde-fous. Remplacez la review par le design.

Et ensuite le principe qui relie tout : lead with context, not control. Hastings le dit à propos de Netflix. Cagan le dit à propos des product teams. Morris le dit à propos des agents, même s’il n’utilise pas cette formule. C’est la même règle.

Drive : Autonomie, maîtrise, purpose - appliqués aux agents

Drive de Daniel Pink est le classique de psycho pop dans ce coin du leadership. Ses trois motivateurs intrinsèques - autonomie, maîtrise, purpose - sont la raison pour laquelle le context-not-control fonctionne sur les humains. Les agents n’ont pas de motivation au sens propre, mais le framework décrit quand même ce qu’un harness bien conçu leur donne :

L’autonomie se traduit en scope et latitude. Une tâche bien cadrée avec des frontières claires et des lignes d’out-of-scope explicites permet à l’agent de faire de vrais choix à l’intérieur d’un espace défini. Les prompts sur-spécifiés sont la version agentique du micromanagement qui pousse un ingénieur senior vers la médiocrité.
La maîtrise se traduit en progressive disclosure et skills. Les agents deviennent meilleurs sur une tâche quand ils ont accès à la bonne connaissance procédurale au bon moment. C’est ce que le skills framework encode. La maîtrise pour les humains, c’est la croissance de carrière ; la maîtrise pour les agents, c’est le bon skill chargé en contexte au bon moment.
Le purpose se traduit en résultats clairs et la loop du pourquoi. Le modèle à deux loops de Morris sépare explicitement la why loop (le résultat voulu) de la how loop (les artefacts qui le livrent). Le purpose vit dans la why loop. Un agent qui sait qu’il est là pour réduire le taux d’échec de paiement de 10% se comporte différemment, et fait de meilleurs arbitrages, qu’un agent à qui on dit d‘“implémenter le retry handler.”

Le parallèle humain compte parce qu’il prédit où les équipes IA échoueront. De la même manière que les équipes humaines échouent quand on leur donne une tâche mais pas un purpose, les agents échouent quand on leur donne un prompt mais pas un résultat. De la même manière que les équipes humaines échouent sous un manager qui inspecte chaque commit, les agents échouent sous un opérateur qui ne peut pas s’empêcher de relire chaque diff. Les modes d’échec sont isomorphes, et les correctifs aussi.

Ce qu’est vraiment le harness

Morris utilise harness comme un terme abstrait. En termes concrets, le harness d’une équipe agentique empowered est une pile de choses sur lesquelles j’écris depuis des mois. Chaque couche est l’un des endroits où l’humain investit au lieu de relire du code :

Couche du harness	Artefacts concrets	Écrit ici
Purpose produit	Vision, stratégie, résultats cibles, OKRs, énoncés de problèmes	Insights-driven product strategy, Set expectations right
Contexte architectural	CLAUDE.md, docs projet, conventions, non-négociables	The perfect CLAUDE.md
Discipline procédurale	Skills, slash commands, phase gates, anti-rationalisation	The skills framework
Spécifications	Specs, découpes de tâches, artefacts de plan	PLAID in practice
Vérification	Tests, évals, stress tests, dashboards de métriques, parcours utilisateur	Implicite dans toute la pile
Infra de workflow	Worktrees, boucles d’agents, exécutions headless, gates CI	Agentic development patterns, The overnight agent factory

Remarquez qu’aucune de ces choses n’est “relire le diff de l’agent.” C’est tout le propos. L’actif humain rare est la qualité du harness, pas la quantité de review. Chaque heure investie dans un meilleur CLAUDE.md, une spec plus affûtée, une suite de tests plus serrée ou une métrique plus honnête se rentabilise sur chaque run d’agent qui suit. Chaque heure passée à relire un diff ne se rentabilise qu’une fois, peut-être.

C’est exactement le message “arrêtez de toucher au code, commencez à construire le système qui écrit du bon code” que les leaders d’ingénierie senior essaient d’intérioriser depuis trente ans. L’ère de l’IA rend simplement visible le coût d’être in the loop, d’une manière qu’il ne l’a jamais été auparavant.

Le flywheel, ce sont des OKRs pour agents

Le geste le plus intéressant de Morris arrive à la fin, quand il décrit le flywheel agentique. Les agents analysent les performances de la loop par rapport à des signaux de plus en plus riches - pas seulement des tests unitaires, mais des métriques de pipeline, des parcours utilisateur, des résultats commerciaux - et proposent des améliorations du harness avec des scores de risque, de coût et de bénéfice. Les recommandations de haute confiance peuvent être auto-approuvées. Le système s’améliore lui-même, tout en restant engineered.

Dépouillez le vocabulaire IA et c’est le product operating model sur lequel toute entreprise empowered aspire à tourner. Vous posez des résultats. Vous instrumentez le produit. Vous relisez les données. Vous proposez des changements scorés par impact attendu. Vous livrez ceux à haute confiance, vous expérimentez sur ceux du milieu, et vous discutez des risqués dans une pièce avec les gens qui en seront propriétaires.

Ce que Morris décrit, ce sont des OKRs pour agents. Un flywheel où le harness évolue à partir du signal de production, comme une bonne product team fait évoluer sa stratégie à partir des insights. C’est pour cela que les dirigeants qui lisent son article ne devraient pas le voir comme un article d’infrastructure IA. Ils devraient le voir comme l’opportunité d’appliquer, enfin, à la production de code la même discipline qu’on essaie d’appliquer aux décisions produit depuis deux décennies.

Les équipes qui gagneront les deux prochaines années sont celles qui fonctionnent déjà comme ça côté produit. Les empowered teams avec des métriques honnêtes ne trouveront pas le flywheel agentique étranger. Elles le trouveront trivial, parce que le muscle est déjà là.

Le mandat du CPTO change, il ne disparaît pas

J’ai réfléchi à ce que cela signifie pour mon propre rôle, étant donné que je suis sur le point de rejoindre une startup londonienne en forte croissance comme CPTO. La réponse courte, c’est que le job évolue dans la même direction vers laquelle tout bon rôle de CPTO aurait dû pointer depuis toujours. Plus loin des artefacts, plus près du système.

En termes concrets :

Votre vision et stratégie produit comptent plus, pas moins. Des agents avec une mauvaise spec produisent du mauvais code plus vite que n’importe quel humain. Si vous ne savez pas articuler le résultat d’une manière que le harness puisse transmettre à l’agent, vous n’êtes pas un leader. Vous êtes un goulot d’étranglement.
Vos standards d’ingénierie comptent plus, pas moins. CLAUDE.md est le nouveau document d’architecture. Les skills sont le nouveau manuel d’ingénierie. Les évals sont la nouvelle code review. Si c’est bâclé, les agents sont bâclés. Si c’est rigoureux, les agents sont rigoureux.
La talent density de votre équipe compte plus, pas moins. Pas parce que les agents remplacent les ingénieurs, mais parce que le flywheel agentique amplifie quel que soit le niveau de goût et de rigueur avec lequel l’équipe démarre. Une haute talent density avec des agents est un code de triche. Une faible talent density avec des agents est un désastre à l’air confiant, à trois fois la vitesse.

Les CPTO qui galéreront seront ceux qui essaieront de migrer leurs habitudes de micromanagement existantes dans l’ère de l’IA. “Je vais juste relire chaque PR d’agent comme je relisais chaque PR de chaque ingénieur senior.” Ça marche un mois. Ça s’effondre au moment où l’équipe dépasse l’échelle d’un seul human-in-the-loop, ce qui dans une entreprise agentique prend environ huit semaines.

Les CPTO qui s’épanouiront seront ceux qui ont traité empowered comme un principe opérationnel, pas comme un slogan, avant tout cela. Pour eux, la transition est mécanique : le même harness qu’ils construisaient déjà pour leurs humains s’étend maintenant aux agents que les humains orchestrent.

Trois changements que j’applique dès demain

Écrire cet article a changé trois choses dans ma propre planification pour la prochaine mission. Concrètes, pas abstraites :

Investir dans le harness avant la première fonctionnalité. Mes deux premières semaines dans la nouvelle entreprise seront CLAUDE.md, skills, évals et garde-fous architecturaux, avant que quiconque écrive une fonctionnalité de production avec des agents. Construire le harness est du travail de jour zéro, de la même manière que recruter le premier ingénieur senior était autrefois du travail de jour zéro.
Traiter les évaluations comme des métriques, pas comme des tests. Déplacer les données d’éval dans les mêmes dashboards que les métriques produit. Si l’équipe voit “taux de succès agent sur les tâches du flow paiement” à côté de “taux d’échec paiement,” elle investira naturellement dans le premier parce qu’il fait bouger le second. C’est ça, le flywheel.
Arrêter de relire des diffs quand un skill ferait le boulot. Chaque fois que je me surprends sur le point de relire quelque chose, je vais me demander “cette review est-elle reproductible comme règle, test ou skill ?” Si oui, je l’encode une fois et je ne refais plus jamais la review. Si non, c’est un vrai jugement et ça mérite mon attention. Le ratio du premier au second est de dix pour un.

À retenir

L’instinct qui veut que diriger l’IA soit une nouvelle discipline est faux. Les managers qui étaient bons dans l’ancienne - poser le contexte, empower les équipes, diriger par les résultats, retirer leur propre goulot d’étranglement du chemin critique - sont ceux qui seront bons dans la nouvelle. Ceux qui se cachaient derrière la relecture d’artefacts comme valeur ajoutée vont découvrir qu’ils n’ajoutaient jamais la valeur qu’ils croyaient.

Le framework de Kief Morris est une version rigoureuse et spécifique à l’ingénierie du playbook d’empowerment que Cagan, Hastings et Pink écrivent depuis vingt ans. Le fait qu’il arrive en mars 2026 sous le nom “flywheel agentique” plutôt que “empowered engineering teams” est un accident de branding. Le fond est le même.

Lisez l’article de Morris. Puis relisez EMPOWERED et No Rules Rules en pensant aux agents. Si vous êtes CPTO, VP Eng ou fondateur qui fait des arbitrages cette année sur la façon dont votre équipe utilise l’IA, ces trois sources contiennent la majeure partie de ce dont vous avez besoin. Le reste, c’est juste le faire.

Références

Humans and Agents in Software Engineering Loops - Kief Morris - L’article source sur le site de Martin Fowler
EMPOWERED - Marty Cagan (notes de lecture) - Empowered product teams, context-not-control, coaching
No Rules Rules - Reed Hastings (critique) - Talent density, candor, et le manuel d’exploitation des équipes à haute autonomie
Vibe Coding in Prod Is a Management Problem - Le cadrage du contributeur individuel qui va avec celui-ci
The Skills Framework - La couche de discipline procédurale à l’intérieur du harness
The Perfect CLAUDE.md - La couche de contexte architectural à l’intérieur du harness
Agentic Development Patterns - Le workflow quotidien qui vient par-dessus
The Overnight Agent Factory - Le mécanisme de composition
Product Operating Model - À quoi ressemblent les empowered teams quand le operating model est au bon endroit