Dans la plupart des discussions sur l'ingénierie agentique, l'action est passée du prompting à l'opération. Voici une frontière qui scrute le brouillard : usines logicielles, objectifs, boucles, sessions en arrière-plan, sous-agents, hooks, sandbox, agents qui approuvent d'autres agents. Pour de nombreux créateurs du futur, ce comportement sera intégré dès le premier jour dans les produits : Claude Code et Codex exposent directement ce changement.
Du point de vue de l'ingénieur, vous utiliserez une faible autonomie pour limiter les risques et augmenter la réversibilité, mais une autonomie plus élevée pour des activités explicites, et des flottes d'agents parallèles refactorisant en toute sécurité d'immenses bases de code. La question centrale concernant une action est toujours : quel niveau cette tâche mérite-t-elle, et quelle vérification rend ce niveau défendable ?
La pointe de la frontière est l'agent manager qui se réveille sur son déclencheur, délègue à ses assistants tout en vérifiant continuellement leur production, et ne remonte que les décisions qui doivent être prises par un humain. Les personnes utilisant ce type de configuration peuvent déjà faire fonctionner des centaines ou des milliers d'agents, principalement sur des bases de code pérennes. Comme pour la plupart des réflexions sur l'autonomie, la façon dont vous percevez l'échelle reste différente pour chacun.
L'échelle la plus souvent mentionnée est l'échelle uniaxiale de Steve Yegge évoquée dans « Welcome to Gas Town » et dans The Pragmatic Engineer. C'est une bonne référence si vous voulez un nombre qui vous indique à quel point vous êtes « AI-native » : l'échelle vous donne un nombre unique pour mesurer si vous connaissez votre confiance en un seul agent. En voici une version :
Début 2026, même si le travail commençait à passer de la délégation à l'orchestration, c'était un assez bon indicateur pour mesurer le risque. Aujourd'hui, cependant, de nombreux ensembles de compétences peuvent gagner en importance et en levier lorsque vous pouvez exécuter plusieurs agents à la fois. Un seul échelon ne peut pas vous aider à positionner la compétence multi-agents.
Au lieu de cela, presque tous les débats sur l'autonomie que j'ai vus confondent deux questions qui devraient être séparées : à quelle distance de nous-mêmes laissons-nous cet agent unique aller, et quelle est notre compétence à coordonner de nombreux agents ?
Pour capturer ces deux dimensions séparément, nous utiliserons deux axes : l'agence et l'orchestration.
Sur l'axe de l'agence, le niveau bas inclut la suggestion d'actions candidates et l'attente d'une décision.
Le niveau moyen signifie que l'agent travaille sur une tâche particulière, mais délimite ce qu'il fait, et rend constamment compte de ce qu'il fait avec des preuves, afin que vous puissiez continuer à le diriger.
À l'extrémité haute agence, l'agent travaille vers un objectif, expérimente, apprend, teste, trouve des moyens de résoudre un problème, se bloque, pose des questions, essaie différentes approches, et retourne tout ce travail sous forme de preuves.
Sur l'axe de l'orchestration, le niveau bas signifie un agent, un thread. Au niveau moyen, vous avez plusieurs agents, chacun travaillant dans son propre espace de travail, peut-être vers des objectifs différents, mais isolés. À l'extrémité haute, vous avez un orchestrateur qui peut prendre un backlog, un suivi de tickets, un planning ou une autre file d'attente, et la transformer en travail continu, et vous n'avez besoin d'intervenir que lorsque les choses échouent : « gestion par exception ». Les produits et fonctionnalités intégrant ces idées incluent :
- Les modes /plan, /goal, /loop, /background, /batch, /code-review, /security-review de Claude Code, les sous-agents, hooks, points de contrôle, pratiques de délégation et de gestion d'agents, sessions en arrière-plan, modèles d'équipes d'agents, arguments /schedule
- Les threads locaux/cloud de Codex, le mode Goal, les espaces de travail, les Automations, les sous-agents, les panneaux de révision, la revue de code GitHub, les hooks, le sandboxing, l'auto-révision et la ré-exécution
Ces capacités ne tiennent pas sur une seule échelle.
L'ascension : trois ères et une pile unique
Si vous lisez l'échelle de bas en haut, vous imaginez grimper à la fois en agence et en orchestration. En effet, les six niveaux représentent trois ères distinctes que nous traversons tous :
D'abord, vous êtes aux commandes, et un agent aide surtout, attendant que vous le dirigiez.
Ensuite, l'agent prend en charge une tâche ou un objectif délimité, mais vous êtes toujours là pour le diriger et vérifier ce qu'il fait.
Et troisièmement, à l'ère de l'orchestration, le système est capable de diriger le spectacle, de répartir le travail entre de nombreux agents, et vous n'avez besoin d'intervenir que lorsque les choses tournent mal : « gestion par exception ».
Cela simplifie les choses, car la position verticale sur l'échelle capture parfaitement les deux axes (l'orchestration n'intervient que près du sommet), ce qui en fait une ascension régulière unique à travers les échelons. Et pourtant, cette ascension fait toujours partie d'un changement que nous traversons tous.
Une bonne journée d'ingénierie implique de toucher plusieurs échelons, parfois plus : il est normal de basculer entre les ères plusieurs fois au cours d'une tâche.
Les six niveaux en détail
Niveau 0 : Assistance
L'agent fait des suggestions qui sont la plupart du temps bonnes et souvent parfaites, mais vous déciderez toujours si elles sont assez bonnes pour être mises en œuvre. Pensez à l'autocomplétion, aux suggestions d'édition en ligne, ou à une session de chat où l'on discute d'un changement dont personne ne s'est encore approprié. À utiliser pour les erreurs coûteuses, les changements minuscules, ou lorsque vous formez votre propre jugement. La vérification a surtout lieu localement.
Niveau 1 : Action supervisée
L'agent édite ou exécute des commandes pour vous, en vous demandant avant d'exécuter quoi que ce soit de conséquent. C'est la posture par défaut pour la plupart des gens. Cela peut se faire dans un sandbox local avec des approbations avant d'appliquer les modifications - où chaque approbation est une vérification indépendante que la modification est acceptable à appliquer - ou dans une session interactive. Le mode d'échec est la fatigue d'approbation ; toutes les approbations se ressemblent, quel que soit ce qu'elles approuvent. Vous pouvez résoudre ce problème en scrutant le diff, en suivant certaines heuristiques, en vérifiant auprès d'une autre personne avant d'approuver, ou simplement en acceptant de laisser l'agent être responsable. L'auto-révision de Codex résout ce problème en déléguant l'approbation finale des conditions limites à un agent réviseur séparé.
Niveau 2 : Délégation de tâche délimitée
Confiez une tâche délimitée à l'agent. Cette tâche aura un objectif clair, des contraintes et une définition de ce à quoi ressemble le « fait ». Vous resterez à proximité, capable d'interrompre, mais la plupart du temps non impliqué. C'est le centre de gravité dans le monde du génie logiciel. La vérification se déplace de vous (qui pouvez avoir besoin de vous reposer et dormir) vers des preuves que l'agent peut produire : tests automatisés réussis, types corrects, suggestions de lint, captures d'écran, étapes de reproduction, provenance par exemple, etc.
Niveau 3 : Autonomie guidée par un objectif
L'agent fait tout ce qui est nécessaire pour atteindre un objectif, s'arrêtant seulement lorsqu'une condition est remplie. En mode prompt, cela signifie que le prompt lui-même devient l'objectif (par exemple, « Peux-tu réduire le temps d'interactivité de cette page en dessous d'une seconde ? »). Dans Codex, c'est le mode Goal : l'agent parcourt les étapes planifier->agir->tester->réviser jusqu'à ce qu'il cesse de répondre aux critères de succès. Dans Claude Code, ce sont les commandes /goal, /loop et /schedule. Pour que ce niveau soit utile, la condition d'arrêt doit être mesurable d'une manière qui peut être automatisée.
Ne demandez pas à votre agent de vous aider avec des objectifs vagues et flous comme « améliorer l'expérience utilisateur en général » ou « rendre la base de code plus testable ». Choisissez quelque chose de spécifique, mesurable et automatisé : trouver des bugs en production qui échappent à l'analyse statique, réduire le temps de chargement, garantir que nous avons une construction TypeScript stricte sans aucun any explicite, trier toutes les dépendances pour ne garder que celles que nous comprenons et qui passent nos tests, etc. Et, enfin, pour trouver des bugs en production, l'agent devra se trouver dans un environnement de type production.
Niveau 4 : Délégation parallèle
Travaillez avec de nombreux agents en parallèle. Chaque agent travaille sur une tranche isolée de la tâche. Le plus grand goulot d'étranglement à ce niveau est la décomposition : définir les bonnes tranches à déléguer. Les supports incluent : sous-agents, sessions en arrière-plan, /batch, espaces de travail, équipes d'agents, etc. Le mode d'échec est le faux parallélisme : exécuter de nombreux agents sur des tranches qui se chevauchent en même temps, de sorte qu'au lieu de plus de travail, vous obtenez des conflits de fusion et des décisions dupliquées. Pour bien faire cela, les agents doivent être isolés les uns des autres, chacun possédant ses propres fichiers et statut. Chacun doit également avoir sa propre file d'attente de révision. Et enfin, chaque agent entraîne un coût - en termes de jetons consommés - proportionnel au nombre d'agents fonctionnant en même temps. Du côté humain, la taxe d'orchestration fait augmenter le coût marginal de l'ajout d'un agent après quelques-uns.
Niveau 5 : Orchestration gérée par exception
Définissez à quoi ressemble le succès et quelles politiques doivent s'appliquer. Un agent manager se réveillera en fonction de déclencheurs (par exemple, nouveau ticket, nouvelle tâche, horloge), dépêchera des agents travailleurs, surveillera leur progression, vérifiera la production, réessaiera en cas d'échec, escaladera vers des agents ou des humains plus compétents lorsque les conditions sont remplies, agrégera les résultats, et finalement retournera les produits du travail (par exemple, les PRs) et les preuves aux systèmes externes. Pensez à une usine : le suivi de tickets ou le backlog est l'entrée, et le produit de l'usine est la sortie (c'est-à-dire de nombreux tickets corrigés, bugs). Les agents travaillent dans un environnement approprié isolé avec beaucoup de murs (et si nécessaire, des trappes de sortie), et seul un système d'exploitation - défini par l'agent manager - définit ce que l'usine est censée faire.
La conception de ce système d'exploitation est laissée à l'humain ; OpenAI a proposé une spécification pour Symphony qui a un tableau Linear au centre : chaque ticket obtient son propre espace de travail d'agent, et l'agent s'assure continuellement qu'il progresse vers son objectif tel que défini dans un fichier de spécification dans son propre espace de travail. La révision humaine peut être effectuée à l'altitude où les preuves sont générées, mais la frontière (c'est-à-dire ce qui est le plus puissant dans le monde de l'orchestration) est de construire des usines d'agents continues avec des centaines, voire des milliers d'agents. À ce stade de l'ascension, il devient de plus en plus important d'avoir une vérification indépendante : séparer les implémenteurs et les réviseurs, séparer les exécuteurs de tests et l'QA, séparer les vérifications de sécurité, séparer les portes de processus pour l'acceptation.
Le risque et la réversibilité fixent le plafond.
Je me souviens avoir lu une étude d'Anthropic plus ancienne sur certaines des tâches les plus difficiles avec Claude Code où il demandait des clarifications plus de deux fois plus souvent que les utilisateurs n'interrompaient. Les utilisateurs expérimentés (~750 sessions contre moins de 50) étaient plus susceptibles d'approuver automatiquement et d'interrompre en gardant un œil sur la progression.
Ils ont également fait une analyse plus large de la façon dont les gens utilisent Claude Code. Ils ont examiné ~400 000 sessions provenant de ~235 000 personnes entre octobre 2025 et avril 2026. À partir de chaque session, ils pouvaient déterminer les décisions que les gens prennent, comme le nombre d'actions qu'ils demandent dans chaque prompt, lesquelles ils choisissent d'approuver automatiquement, à quelle fréquence ils interrompent, etc. Les gens prennent ~70 % des décisions de planification, mais Claude fait ~80 % de l'exécution. Une autonomie élevée ne consiste pas à laisser les gens en dehors de la boucle, mais à passer du fait qu'ils effectuent chaque étape au fait qu'ils décident de la direction à prendre ensuite.
Si nous voulons déterminer si un grand système d'IA fonctionne avec une autonomie élevée, les trois questions que nous devrions poser sont :
- À quelle vitesse saurons-nous que nous avons tort sur ce qu'il fait ?
- Avec quelle propreté pouvons-nous annuler ce qu'il fait ?
- Qu'est-ce qui prouverait que nous avons raison sur ce qu'il fait ?
Si la réponse aux trois est : pas rapidement, avec une grande difficulté, et en faisant confiance au résumé, ce n'est pas une autonomie élevée.
Chaque exécution d'un agent doit être précédée d'un contrat qui définit ce qu'il essaie de faire.
L'objectif : ce que nous essayons d'atteindre (pas une activité, pas la technique, mais un résultat).
Le périmètre : le domaine dans lequel nous opérons et les techniques autorisées.
Les non-objectifs : ce qui ne fait pas partie de l'objectif.
Outils et permissions : comment l'agent peut interagir avec le monde. Condition d'arrêt : quand s'arrêter ; idéalement, une variable mesurable.
Preuves : tests spécifiques, captures d'écran, journaux, enregistrements de base de données ou autres indicateurs pouvant être utilisés pour confirmer qu'une chose a été faite (indépendamment de l'agent).
Escalade : qui est impliqué dans quelles circonstances (y compris qui exécute l'agent).
Et budget : une limite sur le temps, l'effort et les jetons à consacrer à la tâche (les jetons sont le budget des grands modèles d'IA - vous pouvez également inclure une limite sur le nombre de fois qu'il peut tenter la tâche et une limite sur le degré de parallélisme).
Les métriques rendent l'autonomie juste un peu plus fiable
Décider d'une métrique après coup n'est probablement pas suffisant. Les métriques peuvent être mises en place à l'avance, dans un document concis. Et cela rend l'autonomie plus fiable et rend le saut de foi juste un peu plus facile à faire.
Bien qu'il existe de nombreuses façons de mesurer le succès, envisagez de suivre une version de ces métriques pour chaque niveau d'autonomie :
- Temps moyen entre les interventions
- Plus longue exécution réussie sans surveillance avec travail accepté
- Part des actions exécutées dans le sandbox par rapport à celles escaladées
- Pourcentage d'actions auto-approuvées par rapport à celles rejetées
- Nombre moyen d'actions de l'agent par instruction humaine
- Taux de demande de clarification / Taux de demande d'interruption
- Temps de révision par changement accepté
- Taux de reprise à chaque niveau de confiance
- Taux d'échappement de défauts à chaque niveau de confiance
- Coût en jetons par changement accepté
De telles métriques peuvent raconter une histoire : un seul agent maintenu occupé par des transferts humains est un Niveau 4 avec un tableau de bord. Un agent conservateur, peu disposé à procéder sans ingestion automatisée, nouvelles tentatives et preuves décentes, est un Niveau 5 avec une véritable porte.
Pensez à la préparation
Classez le travail par risque et par la facilité avec laquelle il peut être annulé. Appliquez l'autonomie de manière conservatrice, en ne montant que lorsque les preuves soutenant le niveau supérieur s'accumulent. Une refonte du moteur de paiement protégée par des tests solides et des agents réviseurs avec un chemin de retour arrière propre peut supporter une autonomie bien plus élevée qu'une tâche d'automatisation de documentation manquant de toute vérité canonique. Le niveau d'autonomie doit suivre le processus de vérification, pas le nom de la tâche.
Quatre anti-patrons
Chaque système peut facilement tomber dans ces quatre anti-patrons d'autonomie s'il n'est pas vigilamment évité.
L'autonomie comme statut - le niveau d'autonomie d'un agent devient un badge de statut vide de sens. Une autonomie plus élevée est traitée comme une preuve de capacité, et non de sécurité, et les agents sont exécutés plus chauds que ce que la vérification supporte. Correctif : Félicitez et récompensez ceux qui se fixent sur le niveau d'autonomie correct et évitent impitoyablement de le dépasser.
Blanchiment de permission - la tyrannie de la fatigue d'approbation nous amène à accorder aux agents et outils d'IA un accès bien plus large que nécessaire. Correctif : De meilleures limites sont toujours une solution, comme les profils sandbox, les racines d'écriture délimitées, les commandes sur liste blanche, les hooks et l'auto-révision.
Substitution par le résumé - le résumé du travail de l'agent se substitue à la révision, en supposant que le résumé est suffisant. Correctif : Joignez le même dossier de preuves que pour les révisions entièrement manuelles (un diff, des tests, des journaux, des captures d'écran, les conclusions du réviseur, les risques, les lacunes, etc.) tout en évitant la reddition cognitive.
Cosplay de flotte - des dizaines d'agents fonctionnent en parallèle, mais un humain persiste à orchestrer manuellement chaque dépendance. Correctif : L'état partagé, les règles de propriété et un meilleur suivi des dépendances réduisent progressivement le besoin de coordonner manuellement. Des limites de travail en cours plus petites forcent à se concentrer sur l'encodage et la documentation des étapes coordonnées jusqu'à ce que l'orchestration devienne automatisée.
Un exercice de calibration
Passez en revue les dix dernières tâches que vous avez entreprises avec l'aide d'un agent. Pour chaque tâche, enregistrez le niveau d'autonomie exercé, le risque impliqué, la facilité avec laquelle le travail pouvait être annulé, les preuves produites pour répondre aux exigences de vérification, le temps de révision, si une reprise était nécessaire, et si le niveau d'autonomie choisi serait toujours adapté la prochaine fois.
Comment grimper en toute sécurité
Montez d'un axe à la fois. Commencez avec un seul agent supervisé pour effectuer une seule tâche délimitée qui produit des preuves défendables de succès (un niveau d'autonomie 1, si assez propre). Ensuite, étendez-vous progressivement dans les trois directions orthogonales. Parallélisez les tâches d'exploration à forte lecture (niveau d'autonomie 4). Ajoutez des agents d'écriture agissant sur des espaces de travail séparés avec des règles de propriété de fichiers contraintes (niveau d'autonomie 4). Ajoutez des automatisations récurrentes, puis une orchestration menée par un agent basée sur des tickets, la voix, etc. Chaque pas en haut du levier nécessite un nouvel ensemble de mécanismes de sécurité (comme de nouveaux modes d'échec).
Nommez-les : Les exécutions plus longues d'un seul agent peuvent conduire à une dérive, une pourriture du contexte, une communication interrompue ou des objectifs égarés. Le travail en arrière-plan peut conduire à des hypothèses obsolètes et à des transferts faibles. Trop de travail parallèle peut conduire à des conflits de fusion ou à des décisions dupliquées. Trop de travail récurrent peut conduire à des dépenses silencieuses de jetons ou à des prompts obsolètes. La gestion par exception peut conduire à de longues files d'attente de révision et à une fatigue d'alerte. Ne corrigez pas en faisant davantage confiance ; à la place, réduisez le périmètre, assurez de meilleures preuves, permettez des chemins de retour arrière moins coûteux, renforcez les portes et définissez des règles de propriété plus claires.
Utilisez le niveau d'autonomie :
- Le niveau 0 est le meilleur pour le travail délicat et lorsque le jugement est encore en formation.
- Le niveau 1 est le meilleur pour la plupart des explorations, si le travail est effectué près des limites de ce qui est bien compris.
- Le niveau 2 est le meilleur pour la plupart des tâches délimitées, sachant qu'il peut y avoir des dépendances inconnues et des pièges imprévus.
- Le niveau 3 est le meilleur lorsque les conditions de succès peuvent être énoncées avec une clarté suffisante.
- Le niveau 4 est le meilleur lorsque le travail peut être proprement divisé selon ces conditions de succès.
- Le niveau 5 est le meilleur une fois que la coordination et la communication nécessaires entre les différentes conditions de succès sont entièrement encodées.
La vérification sera toujours le goulot d'étranglement.
Malgré la bravade actuelle et les outils actuels, la posture mature d'une équipe d'ingénierie travaillant avec des agents d'IA est l'autonomie calibrée.
Les goulots d'étranglement sont la coordination, la vérification, la maintenance, le jugement produit et l'apprentissage des incidents.
Dans un avenir proche, nous voudrons concevoir des boucles qui savent quand travailler, quand vérifier et quand demander - mais la compétence de l'ingénieur résidera toujours dans le choix du bon niveau d'autonomie et dans la construction de modèles et de preuves défendables qui protègent contre ses recoins les plus sombres.
Note : Pangram étiquette cet article comme étant écrit à 100 % par un humain : https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
