Votre agent IA peut agir seul. Quelles décisions devez-vous encore lui interdire ?

Toutes les actions ne méritent pas une validation

L’autonomie n’est pas une propriété de l’agent, c’est une propriété de chaque action qu’il peut déclencher. Le même agent peut être totalement libre sur une recherche et totalement bridé sur un remboursement.

Prenons un agent de service client. Il pourrait consulter le statut d’une commande, retrouver une procédure, rédiger une réponse, envoyer cette réponse, accorder un geste commercial, annuler une commande, déclencher un remboursement.

Demander une confirmation pour chacune de ces sept opérations rendrait l’agent pénible au point d’être contourné. Les laisser toutes autonomes serait difficile à justifier devant un directeur financier. La seule issue consiste à raisonner action par action, ce qui suppose de les avoir listées, une par une, avant la mise en production.

OpenAI formule une recommandation convergente dans son guide pratique : prévoir une intervention humaine lorsque l’agent dépasse certains seuils d’échec, et lorsqu’il s’apprête à effectuer une action sensible, irréversible ou à fort enjeu.

Quatre modes suffisent à couvrir presque tous les cas

Ces quatre modes ne valent que si l’on sait, ensuite, ce qui s’est réellement passé. Un agent en mode « agir puis informer » sans journal exploitable est un agent autonome auquel on a donné un nom rassurant, et c’est très exactement le sujet de savoir après coup ce que l’agent a réellement fait.

Le piège du bouton « Approuver »

Ajouter une validation humaine ne suffit pas, et c’est le point que les comités de pilotage sous-estiment le plus.

Imaginez un collaborateur qui utilise un agent toute la journée. L’agent demande une autorisation. Puis une autre. Puis une autre. Au bout de quelques dizaines de confirmations, la personne clique sans lire. Techniquement, l’humain est toujours dans la boucle. En pratique, le contrôle a disparu, et il a disparu au moment précis où l’on croyait l’avoir renforcé.

Une validation que l’on accorde sans la lire n’est pas un contrôle, c’est un enregistrement de consentement. La différence apparaît le jour où il faut expliquer une décision.

Anthropic décrit ce compromis sans détour : quand une tâche demande des dizaines d’actions, les demandes répétées deviennent une friction, et les utilisateurs finissent parfois par ne plus les lire. L’autre approche consiste à faire valider en amont le plan général de l’agent, puis à conserver la possibilité d’intervenir pendant l’exécution. On déplace le point de contrôle vers l’endroit où il est encore lu.

Que doit montrer un écran de validation ?

Une demande d’autorisation qui n’expose que l’action à valider ne permet pas de la juger. Pour décider, il faut savoir ce que l’agent s’apprête à faire, pourquoi il le propose, ce qui se passera ensuite, et comment refuser sans tout interrompre.

Quatre éléments suffisent, et leur absence explique la plupart des validations accordées machinalement.

Qui valide, et de quel droit ?

La personne disponible n’est pas toujours la personne compétente, et elle n’est presque jamais celle qui porte la responsabilité. Un agent qui demande à un conseiller de première ligne de valider un geste commercial de quinze mille euros ne met pas un humain dans la boucle : il transfère un risque vers quelqu’un qui n’a ni le mandat ni les éléments pour l’assumer.

La règle est la même que pour un processus manuel, et elle n’a pas besoin d’être réinventée : le niveau de validation suit le niveau de délégation existant dans l’entreprise. Là où une dépense demandait l’accord d’un responsable avant l’arrivée de l’agent, elle continue de le demander. L’agent change la vitesse d’exécution, pas la répartition des pouvoirs, et prétendre le contraire est le meilleur moyen de voir le dispositif désavoué au premier incident.

Valider au bon moment plutôt qu’à chaque étape

Le contrôle humain sert surtout quand quelque chose change. Cinq déclencheurs couvrent l’essentiel.

Le cinquième déclencheur est le plus intéressant, parce qu’il ne dépend pas de la gravité de l’action mais de sa conformité à ce qui avait été annoncé. Un agent qui, pour préparer une réponse client, décide soudain d’interroger un outil qui n’était pas dans son plan mérite une interruption, même si l’outil en question est inoffensif.

Que se passe-t-il quand personne ne valide ?

C’est le cas qu’on oublie le plus souvent au moment de la conception, et il se produit tous les vendredis soir. L’agent attend une validation qui n’arrive pas. Trois issues sont possibles, et il faut en choisir une explicitement plutôt que de laisser le code en décider.

L’agent peut abandonner la tâche et la signaler, ce qui est sûr et transfère la charge sur l’humain. Il peut la mettre en attente et la reprendre à la validation, ce qui suppose de savoir conserver son état proprement. Il peut enfin exécuter par défaut au bout d’un délai, ce qui est une décision lourde : elle revient à dire que l’absence de réponse vaut accord, et elle ne se défend que pour des actions qu’on aurait tout aussi bien pu ne pas soumettre à validation.

Le coût humain de la validation mérite d’ailleurs d’entrer dans le calcul économique du système, au même titre que les appels de modèles, comme nous le détaillons dans ce que coûte réellement un agent une fois en production. Un agent qui réclame six validations par tâche ne fait pas gagner de temps, il en déplace.

L’autonomie n’est pas un choix définitif

Rien n’oblige à trancher une fois pour toutes entre agent autonome et agent supervisé. L’approche qui tient consiste à construire une enveloppe d’autonomie qui s’élargit à mesure que les mesures s’accumulent.

Au lancement, l’agent fonctionne en proposition seule : il produit, un humain décide, et l’on compare les deux. Une fois les performances établies sur ce périmètre, les actions à faible risque passent en exécution autonome. Les exceptions restent supervisées. Les actions critiques restent interdites, et le resteront tant qu’aucune mesure ne justifiera de les ouvrir. Cette progression suppose évidemment de savoir mesurer, ce qui renvoie à la construction d’un jeu d’évaluation représentatif.

Anthropic publie des données d’usage qui montrent que l’autonomie accordée aux agents est déjà un phénomène mesurable, avec des périodes de fonctionnement autonome qui s’allongent sur certaines tâches de programmation. Ces observations portent sur un contexte précis et ne se transposent pas telles quelles à un service client ou à un processus comptable, mais elles disent une chose utile : l’autonomie se constate, elle ne se décrète pas.

Comment savoir si votre dispositif de validation fonctionne encore ?

Un dispositif de validation se mesure, sans quoi personne ne saura qu’il a cessé de produire un contrôle. Trois indicateurs suffisent, et ils sont tous les trois lisibles dans les journaux existants.

Le taux de refusvient en premier. S’il tombe à zéro sur plusieurs semaines, deux explications seulement sont possibles : l’agent ne propose plus rien de discutable, ou les validations ne sont plus lues. La seconde est de loin la plus fréquente.

Le délai médian de décisionvient ensuite. Une validation accordée en une poignée de secondes n’a matériellement pas laissé le temps de lire ce qui était proposé. Le seuil exact se calibre sur la longueur de vos propres écrans de validation ; ce qui compte est de le fixer une fois et de suivre ensuite la part des décisions qui passent en dessous.

Le nombre de validations par tâcheferme la série. Il n’a pas de bonne valeur dans l’absolu, mais sa progression est un signal fiable : chaque nouvelle validation ajoutée par prudence réduit l’attention disponible pour toutes les autres.

Une matrice à remplir avant la production

Pour chaque action que l’agent peut déclencher, quatre colonnes suffisent.

Le remplissage de ce tableau est aussi ce qui rend exploitable la classification des outils exposés à l’agent, décrite dans l’inventaire des serveurs MCP autorisés. Un outil classé « action irréversible » côté protocole doit se retrouver en « humain obligatoire » côté métier, faute de quoi les deux inventaires racontent deux histoires différentes.

La matrice dit ce qui se valide ; elle ne dit pas qui en répond. Cette seconde question est celle de la gouvernance, qui tranche le niveau d’impact à partir duquel une action cesse d’être automatique et nomme les personnes qui en assument le résultat. Les deux réponses doivent exister, et elles ne se déduisent pas l’une de l’autre.

Ce qu’il faut avoir tranché avant d’ouvrir l’agent

L’avant-dernier point est celui qui distingue une politique d’une déclaration d’intention. Tant qu’aucun nom n’est écrit en face d’une action, la responsabilité reste flottante, avec les conséquences décrites dans qui répond de l’action une fois qu’elle est faite.

À retenir

Un bon agent n’est pas celui qui ne demande jamais l’avis d’un humain. Ce n’est pas davantage celui qui demande une autorisation toutes les trente secondes. C’est celui qui distingue ce qu’il peut décider, ce qu’il peut préparer, ce qu’il doit faire valider et ce qu’il n’a pas le droit de faire.

Le human-in-the-loop n’est pas un bouton de sécurité ajouté après coup. C’est une décision d’architecture, prise action par action, et assumée par des personnes nommées.