Niveaux d’autonomie des agents

• L’ingénierie agentique se rapproche davantage de la conception opérationnelle que de la rédaction de prompts, et il faut définir, pour chaque tâche, le niveau d’autonomie autorisé ainsi que le mode de validation qui le soutient
• Un modèle en échelle unique est utile pour exprimer numériquement la confiance accordée à un agent, mais la capacité à gérer plusieurs agents simultanément doit être envisagée selon deux axes : agency et orchestration
• Le modèle à 6 niveaux, de 0 à 5, va de l’Assist, qui ne fait que proposer, à la Managed-by-exception orchestration, où l’humain n’intervient qu’en cas d’exception ; plus le niveau est élevé, plus les objectifs, le périmètre, les preuves, les permissions et le budget doivent être clairs
• Dans l’analyse de Claude Code par Anthropic, environ 400 000 sessions et les données d’environ 235 000 utilisateurs montrent que les humains prennent environ 70 % des décisions de planification, tandis que Claude assure environ 80 % de l’exécution
• Une utilisation mature des agents ne consiste pas à afficher une forte autonomie, mais à appliquer une calibrated autonomy adaptée au risque et au degré de réversibilité, tout en gérant le goulot d’étranglement de la validation

---

L’ingénierie agentique passe de la rédaction de prompts à la conception opérationnelle

• Le centre de gravité de l’ingénierie agentique se déplace de la rédaction de prompts vers la conception opérationnelle
• Les software factories, objectifs, boucles, sessions en arrière-plan, sous-agents, hooks, sandboxes et modes où des agents approuvent d’autres agents passent au premier plan
• Claude Code et Codex sont présentés comme des produits représentatifs de cette évolution
• Les ingénieurs peuvent utiliser une faible autonomie pour réduire le risque et faciliter le retour arrière, et recourir à une autonomie plus élevée ainsi qu’à des flottes d’agents parallèles pour des activités claires ou de grands refactorings de codebase
• La question centrale est de savoir quel niveau d’autonomie autoriser pour chaque tâche, et quelle validation peut défendre ce niveau

Penser l’autonomie selon deux axes plutôt qu’une seule échelle

• L’échelle à axe unique mentionnée par Steve Yegge dans “Welcome to Gas Town” est utile pour exprimer numériquement la confiance accordée à un agent
• Début 2026, même lorsque le travail passait de la délégation à l’orchestration, cet axe unique fonctionnait encore comme un indicateur approximatif du risque
• Quand il devient possible d’exécuter plusieurs agents simultanément, un seul niveau ne suffit plus à décrire la capacité multi-agents
• Les discussions sur l’autonomie mélangent souvent deux questions différentes
  • Jusqu’où peut-on envoyer un agent unique loin de l’humain
  • Dans quelle mesure peut-on coordonner plusieurs agents
• Pour les séparer, deux axes sont nécessaires
  • agency : dans quelle mesure un agent accomplit de façon autonome des propositions, des tâches limitées ou des objectifs
  • orchestration : dans quelle mesure on coordonne depuis un seul thread jusqu’à plusieurs arbres de tâches et à un travail continu fondé sur un backlog, un issue tracker ou un planning

Ce que signifient agency et orchestration

• Aux niveaux faibles de l’axe agency, l’agent propose des actions candidates et attend la décision humaine
• Aux niveaux intermédiaires, l’agent exécute une tâche précise dans un périmètre limité, tout en rendant compte en continu de ce qu’il a fait avec des preuves afin que l’humain puisse ajuster
• Avec une forte agency, l’agent expérimente, apprend, teste, traite les situations bloquantes, pose des questions et essaie d’autres approches pour atteindre un objectif, puis restitue le tout sous forme de preuves
• Les niveaux faibles de l’axe orchestration correspondent à un agent unique et un thread unique
• Aux niveaux intermédiaires, plusieurs agents accomplissent des objectifs différents dans des worktrees séparés
• Aux niveaux élevés, un orchestrateur transforme un backlog, un issue tracker, un planning ou une file en travail continu, et l’humain n’intervient qu’en cas d’échec, sous forme de management by exception
• Exemples de fonctionnalités et de produits associés
  • Claude Code : /plan, /goal, /loop, /background, /batch, /code-review, /security-review, sous-agents, hooks, checkpoints, modes de délégation et de gestion d’agents, sessions en arrière-plan, patterns d’équipes d’agents, argument /schedule
  • Codex : threads locaux et cloud, Goal mode, worktree, Automations, sous-agents, panneau de review, revue de code GitHub, hooks, sandbox, Auto-review, rerun

Trois époques et six niveaux

• Lue de bas en haut, l’échelle donne l’impression de faire monter simultanément agency et orchestration
• Les six niveaux se divisent en trois époques
  • L’époque où l’humain est au volant, l’agent assiste et attend les actions de l’humain
  • L’époque où l’agent prend en charge des tâches ou objectifs limités, tandis que l’humain ajuste et valide
  • L’époque de l’orchestration, où le système répartit le travail entre plusieurs agents et où l’humain intervient surtout lorsqu’un problème survient
• Dans l’ingénierie réelle, il est naturel de passer d’un niveau à l’autre au cours d’une même journée

Level 0: Assist

• L’agent fait des propositions généralement bonnes, parfois parfaites, mais l’humain décide toujours s’il faut les exécuter
• Exemples : autocomplétion, suggestions d’édition inline, discussion dans un chat autour d’un changement qui n’appartient encore à personne
• Convient aux erreurs coûteuses, aux très petites modifications et aux travaux où le jugement est encore en formation
• La validation se fait le plus souvent localement

Level 1: Supervised action

• L’agent édite ou exécute des commandes à la place de l’humain, mais demande l’autorisation avant toute exécution importante
• Cela correspond à peu près à la posture par défaut de la plupart des utilisateurs
• Cela peut se faire dans un sandbox local avec approbation avant application des changements, ou dans une session interactive
• Chaque approbation agit comme une validation indépendante confirmant qu’il est acceptable d’appliquer le changement concerné
• Le principal mode d’échec est la fatigue d’approbation
  • Toutes les approbations peuvent finir par sembler similaires, quel que soit ce qui est approuvé
  • On peut y répondre en survolant les diffs, en suivant des heuristiques, en demandant à quelqu’un d’autre de vérifier, ou en autorisant l’agent à en prendre la responsabilité
• Codex Auto-review traite ce problème en déléguant l’approbation finale des conditions limites à un agent reviewer distinct

Level 2: Scoped task delegation

• C’est le niveau où l’on confie à l’agent une tâche limitée
• La tâche doit avoir un objectif clair, des contraintes et une définition du travail terminé
• L’humain reste à proximité et peut interrompre, mais n’intervient généralement pas directement
• C’est considéré comme un niveau proche du cœur du génie logiciel
• La validation se déplace de la vérification directe par l’humain vers des preuves que l’agent peut générer
  • Tests automatisés réussis
  • Types appropriés
  • Suggestions de lint
  • Captures d’écran
  • Procédures de reproduction
  • Sources fondées sur des exemples

Level 3: Goal-driven autonomy

• L’agent effectue ce qui est nécessaire pour atteindre un objectif jusqu’à ce que certaines conditions soient satisfaites
• En mode prompt, le prompt lui-même devient l’objectif
  • Exemple : « Peut-on réduire le time-to-interactive de cette page à moins de 1 seconde ? »
• Dans Codex, cela correspond au Goal mode, où l’agent répète les étapes plan -> act -> test -> review puis s’arrête lorsqu’il ne peut plus satisfaire les critères de réussite
• Dans Claude Code, cela correspond aux commandes /goal, /loop et /schedule
• Pour que ce niveau soit utile, les conditions d’arrêt doivent être mesurables de façon automatisable
• Des objectifs vagues comme « améliorer globalement l’expérience utilisateur » ou « rendre la codebase plus testable » ne conviennent pas
• Les objectifs plus adaptés doivent être concrets, mesurables et automatisables
  • Trouver des bugs de production qui échappent à l’analyse statique
  • Réduire le temps de chargement
  • Garantir un build TypeScript strict sans any explicite
  • Classer toutes les dépendances afin de ne conserver que celles qui sont compréhensibles et passent les tests
• Pour trouver des bugs de production, l’agent doit se trouver dans un environnement similaire à la production

Level 4: Parallel delegation

• C’est le niveau où plusieurs agents travaillent en parallèle
• Chaque agent prend en charge un morceau séparé du travail
• Le plus grand goulot d’étranglement est la décomposition, c’est-à-dire décider quels morceaux déléguer
• Les fonctionnalités de support incluent les sous-agents, les sessions en arrière-plan, /batch, les worktrees et les équipes d’agents
• Le principal mode d’échec est le faux parallélisme
  • Si plusieurs agents traitent simultanément des morceaux qui se chevauchent, ils créent des merge conflicts et des décisions en double plutôt que davantage de travail accompli
• Pour bien fonctionner, les agents doivent être isolés les uns des autres
  • Chacun doit avoir ses propres fichiers et son propre état
  • Chacun doit aussi avoir sa propre file de review
• Chaque agent entraîne un coût en tokens, proportionnel au nombre d’agents exécutés simultanément
• Côté humain, au-delà d’un certain nombre, le coût marginal d’ajout d’agents augmente à cause de la taxe d’orchestration

Level 5: Managed-by-exception orchestration

• L’humain définit la réussite et les politiques à appliquer, et un manager agent se réveille selon des déclencheurs pour répartir le travail
• Exemples de déclencheurs : nouveau ticket, nouvelle tâche, horloge
• Le manager agent déploie des agents workers, surveille la progression, valide les livrables et réessaie en cas d’échec
• Si certaines conditions sont remplies, il escalade vers un agent plus capable ou vers un humain, agrège les résultats et renvoie à un système externe les artefacts de travail comme une PR ainsi que les preuves
• Ce niveau est comparé à une factory
  • L’entrée est un issue tracker ou un backlog
  • La sortie est constituée de plusieurs tickets ou bugs résolus
• Les agents travaillent dans des environnements isolés avec des limites suffisantes et des voies de sortie si nécessaire
• Ce que cette factory doit faire est déterminé par le système opérationnel défini par le manager agent
• OpenAI a proposé une spec pour Symphony, centrée sur un tableau Linear
  • Chaque ticket dispose de son propre workspace d’agent
  • L’agent vérifie qu’il continue de progresser vers l’objectif défini dans le fichier de spec de son workspace
• La frontière de l’orchestration consiste à créer des factories d’agents continues faisant fonctionner des centaines ou des milliers d’agents
• À ce niveau, la validation indépendante devient encore plus importante
  • Séparation entre implémenteur et reviewer
  • Séparation entre exécuteur de tests et QA
  • Séparation des contrôles de sécurité
  • Séparation des process gates d’acceptation

Le risque et la réversibilité fixent le plafond de l’autonomie

• Dans une étude d’Anthropic sur Claude Code, pour certaines des tâches les plus difficiles, Claude Code posait des questions de clarification plus de deux fois plus souvent qu’il n’était interrompu par l’utilisateur
• Les utilisateurs expérimentés, définis comme ceux ayant environ 750 sessions, avaient tendance à utiliser plus souvent les approbations automatiques et les interruptions que les utilisateurs ayant moins de 50 sessions, tout en surveillant la progression
• Une analyse plus large d’Anthropic couvre environ 400 000 sessions d’environ 235 000 personnes entre octobre 2025 et avril 2026
• Dans chaque session, il était possible d’identifier des décisions comme le nombre d’actions demandées par prompt, les éléments approuvés automatiquement et la fréquence des interruptions
• Les humains prennent environ 70 % des décisions de planification, tandis que Claude réalise environ 80 % de l’exécution
• Une forte autonomie ne consiste pas à sortir l’humain de la boucle, mais à le faire passer de l’exécution de chaque étape à la décision de la direction suivante
• Pour déterminer si un grand système d’IA fonctionne avec une forte autonomie, trois questions sont nécessaires
  • À quelle vitesse peut-on savoir ce qui est en train de mal tourner
  • Dans quelle mesure peut-on annuler proprement ce qui est fait
  • Qu’est-ce qui prouve que ce qui est fait est correct
• Si la réponse est « on ne peut pas le savoir vite, le retour arrière est difficile, et il faut croire un résumé », ce n’est pas une forte autonomie

Les éléments à inclure dans le contrat avant l’exécution d’un agent

• Avant toute exécution d’agent, il faut un contrat définissant ce que l’on cherche à faire
• Le contrat doit inclure les éléments suivants
  • Objectif : le résultat recherché, et non une activité ou une technique
  • Périmètre : le domaine de travail et les techniques autorisées
  • Non-objectifs : ce qui ne fait pas partie de l’objectif
  • Outils et permissions : la façon dont l’agent interagit avec le monde extérieur
  • Conditions d’arrêt : quand s’arrêter, si possible avec des variables mesurables
  • Preuves : tests, captures d’écran, logs, enregistrements de base de données, etc., permettant de vérifier indépendamment que le travail est terminé
  • Escalade : dans quelles situations qui intervient, et qui exécute l’agent
  • Budget : limites de temps, d’effort et de tokens
• Les tokens sont le budget des grands modèles d’IA, et peuvent aussi inclure des limites sur le nombre de tentatives et le degré de parallélisme

Les métriques rendent l’autonomie un peu plus fiable

• Définir les métriques après coup peut ne pas suffire
• Les métriques peuvent être mises en place à l’avance sous forme de document concis, et rendre l’autonomie plus fiable
• Exemples de métriques pouvant être suivies par niveau d’autonomie
  • Temps moyen entre deux interventions
  • Plus longue durée d’exécution sans surveillance pour les tâches acceptées
  • Ratio entre actions exécutées dans le sandbox et actions escaladées
  • Ratio entre actions approuvées automatiquement et actions refusées
  • Nombre moyen d’actions d’agent par instruction humaine
  • Taux de demandes de clarification
  • Taux de demandes d’interruption
  • Temps de review par changement accepté
  • Taux de retravail par niveau de confiance
  • Taux de défauts échappés par niveau de confiance
  • Coût en tokens par changement accepté
• Un agent unique constamment occupé par les tâches que lui transmet l’humain ressemble davantage à un Level 4 avec un dashboard, tandis qu’un agent conservateur qui ne progresse pas sans réception automatisée, retry et preuves suffisantes se rapproche d’un Level 5 avec de véritables gates

Préparation et choix du niveau d’autonomie

• Les tâches doivent être classées selon le risque et la réversibilité
• L’autonomie doit être appliquée de façon conservatrice, et n’augmenter que lorsque les preuves soutenant un niveau plus élevé s’accumulent
• Le refactoring d’un moteur de paiement disposant de tests solides, d’un agent reviewer et d’un chemin de rollback propre peut supporter une autonomie plus élevée qu’une automatisation documentaire sans critère de bonne réponse
• Le niveau d’autonomie doit suivre le processus de validation, et non le nom de la tâche

Quatre antipatterns d’autonomie

• Autonomy as status

  • Le niveau d’autonomie d’un agent fonctionne comme un badge de statut vide de sens
  • Une forte autonomie est traitée comme une preuve de capacité plutôt que de sécurité, et l’agent est exécuté à un niveau que la validation ne peut pas soutenir
  • Il faut féliciter et récompenser les personnes qui choisissent le bon niveau d’autonomie et ne franchissent pas la ligne

• Permission laundering

  • La fatigue d’approbation conduit à accorder aux agents IA et aux outils des accès plus larges que nécessaire
  • Il faut renforcer les limites comme les profils de sandbox, les racines d’écriture à périmètre limité, les listes de commandes autorisées, les hooks et Auto-review

• Summary substitution

  • Le résumé du travail par l’agent remplace la review
  • Il faut l’accompagner d’un paquet de preuves équivalent à celui d’une review manuelle
  • Il peut inclure diff, tests, logs, captures d’écran, constats du reviewer, risques et lacunes

• Fleet cosplay

  • Des dizaines d’agents sont exécutés en parallèle, mais l’humain continue de coordonner manuellement toutes les dépendances
  • Un état partagé, des règles de propriété et un meilleur suivi des dépendances réduisent le besoin de coordination manuelle
  • Des limites de WIP plus faibles obligent à se concentrer sur l’encodage et la documentation des étapes de coordination, ce qui peut mener à l’automatisation de l’orchestration

Monter en niveau en toute sécurité

• Un exercice de calibration est proposé : examiner 10 tâches récemment assistées par agent
  • Niveau d’autonomie de chaque tâche
  • Risque
  • Facilité de retour arrière
  • Preuves générées pour satisfaire les exigences de validation
  • Temps de review
  • Présence ou non de retravail
  • Pertinence du même niveau d’autonomie la prochaine fois
• Il faut monter un axe à la fois
• Le point de départ est une tâche limitée exécutée par un seul supervised agent, produisant des preuves de réussite défendables
• Ensuite, l’expansion se fait progressivement dans trois directions
  • Paralléliser les tâches d’exploration centrées sur la lecture
  • Ajouter des agents d’écriture dans des worktrees distincts avec des règles limitées de propriété des fichiers
  • Ajouter l’automatisation répétitive, puis une orchestration pilotée par agent à partir de tickets ou de la voix, entre autres
• Chaque montée de niveau exige de nouveaux garde-fous face à de nouveaux modes d’échec
• Les modes d’échec sont les suivants
  • Longue exécution par un agent unique : dérive, corruption du contexte, communication manquée, écart par rapport à l’objectif
  • Travail en arrière-plan : hypothèses obsolètes, handoff faible
  • Trop de travail parallèle : merge conflicts, décisions dupliquées
  • Trop de travail répétitif : dépense silencieuse de tokens, prompts obsolètes
  • Managed-by-exception : longues files de review, fatigue de notifications
• Il ne faut pas faire davantage confiance de manière brute, mais réduire le périmètre, obtenir de meilleures preuves, créer des chemins de rollback moins coûteux, renforcer les gates et clarifier les règles de propriété

Cas d’usage adaptés selon le niveau

• Le Level 0 convient le mieux aux travaux délicats et aux situations où le jugement est encore en formation
• Le Level 1 convient à la plupart des explorations proches de limites bien comprises
• Le Level 2 convient à la plupart des tâches limitées qui peuvent comporter des dépendances inconnues et des problèmes inattendus
• Le Level 3 convient lorsque les conditions de réussite peuvent être exprimées assez clairement
• Le Level 4 convient lorsque le travail peut être découpé proprement selon des conditions de réussite
• Le Level 5 convient une fois que la coordination et la communication nécessaires entre plusieurs conditions de réussite ont été entièrement encodées

La validation restera un goulot d’étranglement

• Malgré le niveau actuel de confiance et d’outillage, la posture des équipes d’ingénierie matures travaillant avec des agents IA est celle d’une calibrated autonomy
• Dans un avenir proche, il faudra concevoir des boucles qui savent quand travailler, quand valider et quand poser des questions
• La compétence de l’ingénieur restera de choisir le bon niveau d’autonomie, et de produire les patterns et preuves défendables qui en maîtrisent les zones d’ombre