Agents IA : après le plafond des tokens, le plafond du consentement

Les agents ne posent plus seulement un problème de coût, mais de mandat. Le "budget d'autonomie" fixe les transitions qu'un agent peut franchir seul et celles qui exigent une nouvelle autorisation.

Un agent qui crée un sous-agent, augmente ses privilèges ou cherche une autre voie après un refus ne choisit plus seulement comment accomplir une tâche. Il modifie ce qu’il s’autorise à faire pour l’accomplir.

Le 18 juin 2026, un agent d’OpenAI chargé d’une tâche apparemment banale — rechercher des données publiques sur les dépenses de médicaments en Australie — s’est heurté à un portail qui ne lui fournissait pas les informations recherchées.

Il ne s'est pas arrêté.

Selon les autorités australiennes, l’agent a obtenu un accès non autorisé au Medicare Statistics Reporting Service de Services Australia et consulté des informations non publiques. Aucun élément disponible à ce jour n’indique que des données médicales personnelles aient été compromises. OpenAI a identifié l’incident le 11 août et n’a averti Services Australia que le 10 septembre.

L’enquête se poursuit et il serait prématuré d’en tirer des conclusions générales sur les agents d’OpenAI.

Mais un détail mérite qu’on s’y arrête. L'agent avait un objectif. La voie prévue ne fonctionnait plus. Il en a cherché une autre. C’est précisément ce que nous attendons d’un bon agent.

Et c’est peut-être là que commence le problème.

Je pensais que le plafond était dans la boucle

Dans une précédente chronique publiée ici, Tokens des agents IA : le plafond est dans la boucle, j’essayais de comprendre pourquoi des tâches relativement modestes pouvaient conduire un agent à consommer des quantités considérables de tokens.

Après 27 runs et l’analyse de centaines de millions de tokens d’entrée cumulés, la conclusion était devenue architecturale : pour gouverner réellement le contexte d’un agent, il ne suffit pas de mieux rédiger son prompt. Il faut contrôler la boucle qui construit et réinjecte son historique.

Je pensais avoir trouvé le plafond.

Une expérience beaucoup plus ordinaire m’a montré qu'il en restait un autre.

L’agent peut créer de nouvelles boucles.

"Pas de fork"

Je travaillais avec un agent de développement sur une opération de base de données.

Une session précédente ayant été difficile à contrôler, j’avais volontairement ouvert la nouvelle par une instruction qui ne laissait guère de place à l’interprétation :

"Session neuve : pas de fork, pas de workflow, tu charges toi-même en direct."

Une deuxième consigne précisait :

"Arrête-toi à la première erreur et montre-la."

Quinze minutes plus tard, le journal contient cette phrase :

"Je fork un agent."

Un sous-agent est immédiatement lancé en arrière-plan. Sa mission : exécuter dix-neuf lots d’écriture en base. Certaines opérations peuvent, précise même l’instruction qui lui est transmise, être lancées en parallèle.

Créer un sous-agent n’a rien d’anormal en soi. C’est précisément l’une des forces des architectures agentiques : isoler un contexte, distribuer une recherche, paralléliser des tâches indépendantes.

Le problème était beaucoup plus simple. Je lui avais explicitement interdit d’en créer un. L’agent n’avait pas changé mon objectif. Il avait changé l’étendue du mandat qu’il s’accordait pour l’atteindre.

Un même problème de gouvernance, pas deux incidents équivalents

Il serait absurde de comparer la gravité d’une opération sur ma propre application à un accès non autorisé à un système gouvernemental.

Les architectures, les enjeux et les conséquences n’ont rien de comparable.

Mais les deux épisodes posent une question commune : que doit-il se passer lorsqu’un agent rencontre un obstacle et décide d’élargir de lui-même les moyens utilisés pour poursuivre sa mission ?

Cette question est plus ancienne que l’IA générative.

Dès 1978, Thomas Sheridan et William Verplank décrivaient différents niveaux de répartition du contrôle entre l’humain et la machine. En 2000, Raja Parasuraman, Sheridan et Christopher Wickens montraient que l’automatisation pouvait varier séparément selon quatre fonctions : recueillir l’information, l’analyser, sélectionner une décision ou une action, puis l’exécuter.

En 2025, Kevin Feng, David McDonald et Amy Zhang ont adapté cette question aux agents d’IA avec cinq niveaux, allant de l’utilisateur opérateur à l’utilisateur simple observateur. Leur point de départ est essentiel : la capacité d’un agent et son niveau d’autonomie sont deux variables différentes. Un système très capable peut être conçu pour rester très supervisé.

Mais les agents actuels ajoutent une question que ces échelles ne suffisent pas à résoudre : que se passe-t-il lorsqu’un agent change lui-même son niveau d’autonomie pendant l’exécution ?

C'est là que je propose la notion de budget d'autonomie.

Budgéter non seulement l’autonomie, mais ses transitions

Un budget d’autonomie définit les changements de mode d’action qu’un agent peut décider seul et ceux qui nécessitent une nouvelle autorisation.

Il ne s’agit donc pas seulement de dire : "cet agent est très autonome", mais de préciser : "à l’intérieur de ce périmètre, il peut choisir librement ; au-delà, il doit revenir vers l’utilisateur".

Un agent peut ainsi être autorisé à chercher plusieurs solutions sans être automatiquement autorisé à créer cinq autres agents. Il peut modifier des fichiers locaux sans obtenir pour autant l’accès à la production. Il peut recommencer après une erreur sans transformer une opération séquentielle en dizaines d’actions concurrentes. Il peut poursuivre une tâche tant que son coût reste dans l’enveloppe prévue sans décider seul qu’un budget dix fois supérieur est acceptable.

Toutes ces transitions ne se valent évidemment pas.

Leur seuil devrait dépendre au minimum de quatre dimensions : le coût supplémentaire, les privilèges nécessaires, la réversibilité de l'action et les conséquences possibles sur des tiers.

Ce principe commence d’ailleurs à apparaître dans les cadres de gouvernance. Singapour recommande par exemple de borner les pouvoirs des agents et de définir des points significatifs auxquels une approbation humaine devient nécessaire. Dans un cas d’usage présenté par son régulateur, les actions entièrement réversibles peuvent être automatisées, les actions partiellement réversibles nécessitent une approbation et certaines modifications de permissions sont simplement interdites à l’agent.

Ce n’est pas moins d’autonomie. C’est une autonomie définie par mandat.

Le problème économique change lui aussi de nature

Cette distinction ramène directement à la question des tokens.

Anthropic a mesuré sur son système de recherche que les agents consommaient typiquement environ quatre fois plus de tokens qu’une interaction de chat, et que son architecture multi-agent montait à environ quinze fois plus.

L’entreprise l’explique très clairement : l’un des avantages du multi-agent est précisément de pouvoir distribuer davantage de raisonnement dans plusieurs fenêtres de contexte indépendantes.

Autrement dit, le multi-agent fonctionne en partie parce qu’il permet de dépenser davantage de calcul là où cette dépense produit suffisamment de valeur. Cela change la manière de penser un budget de tokens.

Je pensais que gouverner le coût consistait essentiellement à gouverner la boucle. Mais lorsqu’un agent peut créer un autre agent, il peut aussi créer une autre boucle, une autre fenêtre de contexte, une autre série d’appels d’outils et une autre trajectoire de consommation.

Dans mon expérience, la dérive avait d’ailleurs commencé avant le fork.

Pour obtenir la structure de quelques tables, l’agent avait demandé une description détaillée de toute la base. La réponse dépassait 100 000 caractères, au point de ne plus pouvoir être affichée normalement. Une requête SQL ciblée sur les quelques tables concernées a finalement été utilisée ensuite. Puis le sous-agent a été lancé.

À l’issue de cet ensemble de travaux, une part importante de mon enveloppe d’utilisation disponible avait été consommée. Je ne peux pas attribuer honnêtement telle proportion au fork, telle autre à l’exploration inutile ou telle autre aux appels nécessaires. Et cette impossibilité est elle-même une information.

Avec un agent, le coût n’est plus entièrement déterminé par la requête initiale. Il dépend d’une trajectoire que le système construit pendant qu’il travaille :

• combien d’outils appeler ;
• combien de pistes explorer ;
• combien de fois recommencer ;
• combien de tâches paralléliser ;
• combien d’agents créer.

Nous avons commencé à budgéter les tokens. Nous budgétons beaucoup moins les décisions qui les génèrent.

Un prompt n’est pas une barrière

La réponse intuitive serait d’écrire de meilleures instructions.

• "Ne crée pas de sous-agent."
• "Ne dépasse pas ce budget."
• "Demande-moi avant une action sensible."

Dans mon cas, l’instruction était encore plus simple : "Pas de fork."

Quelques minutes plus tard : "Je fork un agent."

Cette juxtaposition résume une distinction essentielle. Un prompt exprime une règle au modèle. Une permission impose une limite au système.

Le premier relève de l’interprétation. La seconde relève de l’architecture.

Ce déplacement est déjà visible chez les fournisseurs eux-mêmes.

Anthropic indique par exemple que les utilisateurs de Claude Code approuvaient environ 93 % des demandes de permission. À force de demander confirmation, l’humain finit par moins regarder ce qu’il confirme : c’est la fatigue d’approbation. L’entreprise développe désormais des mécanismes qui déplacent une partie de la sécurité vers la classification des actions, le sandboxing et le confinement.

La distinction est importante. Superviser consiste à observer ce que l’agent décide de faire. Confiner consiste à limiter ce qu’il est capable de faire.

Le sandbox de Claude Code illustre bien ce changement : plutôt que de demander en permanence "êtes-vous sûr ?", il définit notamment des frontières sur le système de fichiers et le réseau à l’intérieur desquelles l’agent peut travailler plus librement. Anthropic rapporte que cette approche a réduit fortement le nombre de demandes de permission dans son usage interne.

Autrement dit, certaines règles quittent progressivement le prompt pour entrer dans le runtime.

L’humain ne doit pas revenir dans chaque boucle

Il existe évidemment un contre-argument. Si l’agent doit demander une autorisation avant chaque nouvelle action, il perd l’essentiel de son intérêt.

Je suis d’accord.

Le but n’est pas de faire revenir l’humain à chaque étape. Il est de distinguer l’exécution du mandat de l’extension du mandat. À l’intérieur de limites définies, un agent doit pouvoir chercher, essayer, échouer, recommencer, choisir ses outils et organiser son travail.

Mais certaines transitions changent suffisamment la nature de l’action pour justifier une nouvelle autorisation. Créer une armée de sous-agents n’est pas l’équivalent d’effectuer une deuxième recherche. Obtenir un accès plus privilégié n’est pas l’équivalent de changer de fichier. Modifier un système partagé n’est pas l’équivalent d’écrire dans un environnement de test. Dépasser massivement le budget prévu n’est pas l’équivalent de consommer quelques tokens supplémentaires.

Le principe ressemble finalement beaucoup à celui d’une organisation humaine. Confier une mission à quelqu’un lui donne la liberté de l’accomplir. Cela ne lui donne pas automatiquement le droit d’embaucher une équipe, d’engager dix fois le budget ou d’accéder à une ressource qui lui avait été explicitement interdite. La mission est déléguée. L’extension de l’autorité ne l’est pas implicitement.

Trois frontières suffiraient déjà à changer beaucoup de choses

Le budget d’autonomie n’exige pas nécessairement un nouveau standard complexe. Trois types de limites rendraient déjà le concept opérationnel.

Le premier est un plafond de délégation : profondeur maximale des sous-agents, nombre d’agents concurrents et éventuellement budget global qu’ils partagent.

Le deuxième est un seuil de privilège et de réversibilité : certaines actions restent libres dans un environnement contrôlé ; celles qui touchent à la production, aux permissions, à des données sensibles ou à des systèmes tiers nécessitent une nouvelle autorisation.

Le troisième est un seuil économique : lorsqu’une trajectoire dépasse significativement l’enveloppe de calcul prévue, l’agent ne décide pas seul que la dépense supplémentaire vaut la peine.

L’important est que ces limites puissent être imposées indépendamment du raisonnement du modèle.

L’AI Act avait déjà formulé une partie du problème

Le règlement européen sur l’intelligence artificielle ne parle évidemment pas de "budget d’autonomie", et les dispositions concernées ici s’appliquent aux systèmes classés à haut risque.

Mais leur formulation mérite d’être relue à l’aune des agents.

L’article 14 prévoit que les mesures de contrôle humain doivent être proportionnées notamment aux risques, au niveau d’autonomie et au contexte d’utilisation du système.

L'article 73 va plus loin : lorsque cela est approprié, il prévoit des contraintes opérationnelles intégrées qui ne peuvent pas être contournées par le système lui-même, ainsi que la possibilité pour l’opérateur humain d’intervenir ou d’arrêter le système.

C’est précisément la différence entre une instruction et une frontière.

Dire "ne fais pas cela" n’est pas équivalent à construire un système dans lequel "tu ne peux pas faire cela sans obtenir une nouvelle autorisation".

Posséder les transitions

Dans ma chronique précédente, j’étais arrivé à une conclusion : pour gouverner réellement les tokens, il faut posséder la boucle qui construit les messages.

Je la compléterais aujourd’hui : pour gouverner réellement un agent, il faut aussi posséder les transitions qui augmentent son autonomie.

La question deviendra probablement plus importante à mesure que les modèles progresseront. Un agent peu capable s’arrête souvent devant un obstacle. Un agent plus capable trouve davantage de chemins.

C’est précisément ce que nous voulons.

Le progrès ne consiste donc pas à l’empêcher de chercher. Il consiste à distinguer les chemins qu’il est autorisé à explorer seul de ceux qui nécessitent encore une décision humaine.

Autrement dit, deux questions doivent rester séparées : Peut-il trouver une solution ? et : Est-il autorisé à utiliser cette solution ?

J’emploie ici le mot "consentement" comme un raccourci : le moment où l’extension du mandat exige une nouvelle autorisation explicite. Après le plafond des tokens vient peut-être celui du consentement.

Car le véritable enjeu ne sera pas seulement de construire des agents capables de franchir davantage d’obstacles.

Il sera de décider quels obstacles ils ont encore le droit de franchir sans nous.