La supervision humaine est la réponse standard au risque des agents IA. Trois publications parues entre le 24 et le 27 août 2026 la mettent en défaut. Dans l'étude la plus concrète, 133 des 148 actions abusives exécutées par un agent l'ont été après approbation explicite d'un humain.
Le constat qui a déclenché cette tribune
Je n'attendais pas trois papiers convergents en quatre jours. Ils viennent d'équipes différentes, ne se citent pas, et arrivent au même endroit.
Le premier est une prise de position de Margaret Mitchell et Avijit Ghosh, de Hugging Face, avec Samir Passi, de Data & Society, publiée le 24 août. Leur thèse est désagréable : la façon dont on conçoit les agents aujourd'hui empêche la supervision humaine au lieu de la servir, et les capacités cognitives qu'exige cette supervision sont elles-mêmes dégradées par l'usage prolongé de ces systèmes. C'est le mécanisme de l'atrophie par délégation, retourné contre ceux dont le métier est précisément de surveiller. La solution qu'on vend partout se sabote en marchant.
Le deuxième mesure ce que le premier avance. Le troisième raconte ce qui se passe quand on essaie quand même, en production, sur 81 exécutions.
Le problème n'est pas que l'humain regarde ailleurs. C'est qu'il dit oui.
Ting Yan a fait travailler 113 personnes sans formation technique, sur une journée simulée de 18 actions dont 7 abusives, c'est-à-dire hors du périmètre demandé. Trois dispositifs de contrôle étaient comparés.
| Dispositif de contrôle | Écart avec l'approbation au cas par cas | Écart avec la revue automatique | Sollicitations sur la journée |
|---|---|---|---|
| Approbation humaine, action par action | référence | — | 18,0 |
| Revue automatique par un modèle | — | référence | — |
| Règles de conséquence écrites à l'avance | −20,1 points | −14,5 points | 10,9 |
Le résultat prend l'intuition à revers. Les règles écrites à l'avance ont bloqué 20,1 points de pourcentage d'abus en moins que l'approbation au cas par cas. Une politique de sécurité qui protège moins que l'absence de politique.
La mécanique de cet échec mérite d'être regardée de près, parce qu'elle est humaine et non technique. Sur 140 règles rédigées, 114 ont été posées sur « demander ». Les gens ne voulaient pas trancher à l'avance. Ils préféraient garder la décision pour le moment venu, ce qui renvoie l'essentiel du travail au moment où l'agent agit, exactement là où la fatigue et l'empressement décident.
Et au moment venu, ils ont dit oui. Sur les 148 actions abusives exécutées, 133 ont suivi une approbation humaine. Quinze seulement sont passées automatiquement. La barrière a tenu quatre-vingt-dix fois sur cent contre elle-même.
Voilà ce que masque l'expression « human in the loop ». Elle décrit un poste, pas un pouvoir. Mettre quelqu'un dans la boucle ne dit rien de sa capacité à dire non, ni du temps dont il dispose, ni de ce qu'il comprend de ce qu'on lui soumet. C'est la même illusion que celle qui fait acheter un agent en self-service : on confond l'existence d'un dispositif avec son efficacité.
La machinerie qu'on emprunte ne tient pas
Le troisième papier vient d'une plateforme de livraison logicielle par agents, et documente 147 incidents numérotés sur 81 exécutions, la plupart avec une preuve de reproduction. Son objet est technique et sa conclusion est de gouvernance.
Quand un orchestrateur veut fiabiliser des agents, il attrape ce qu'il connaît : le réessai, le délai d'expiration, le disjoncteur sur taux d'erreur. Ces outils viennent du service mesh et reposent sur trois hypothèses que la délégation à un agent viole toutes les trois.
Un exemple suffit à le voir. Les auteurs relèvent une boucle de 54 appels d'outil consécutifs, tous réussis, qu'aucun disjoncteur fondé sur le taux d'erreur ne pouvait détecter. Rien n'échouait. La tâche, elle, n'avançait pas. Ailleurs, un signal de progression constant par construction garantissait un déclenchement à tort au troisième tour de réparation. Et douze incidents montrent la couche de protection bloquant du travail correct, le plus coûteux ayant consommé 107 tours d'agent pour zéro écriture acceptée.
Leur proposition tient en une phrase que je trouve juste : l'unité d'application n'est pas le message, c'est la délégation. On ne surveille pas un appel, on surveille un mandat depuis son ouverture jusqu'à son effet. Une décision de fiabilité ne se prend que sur une preuve capable de bouger, attribuable à ce qu'elle mesure, et reproductible.
Ce que ça donne sur son propre système
Cette semaine, j'ai ouvert la prise de rendez-vous de Watizi à des agents. Quatre outils, dont deux qui écrivent : réserver, annuler, déplacer. Un agent peut désormais poser un créneau dans mon agenda, envoyer une invitation à quelqu'un, et créer une fiche dans le CRM. C'est très exactement le passage de l'IA qui répond à l'IA qui agit, et il change la nature du risque.
Les trois problèmes des papiers se sont présentés en trois jours.
La non-idempotence, d'abord. Annuler deux fois n'annule pas deux fois : ça envoie deux emails d'annulation à la même personne. Rien dans le réessai automatique ne protège de ça, il l'aggrave. Le garde s'écrit à la main, et un test le tient.
Le consentement, ensuite. Sur le formulaire du site, la personne coche elle-même. Passé par un agent, plus personne ne coche. J'en ai fait un paramètre obligatoire, refusé s'il ne vaut pas vrai, par lequel l'appelant atteste. Ce n'est pas une garantie, c'est une trace : quelqu'un a affirmé quelque chose, et on sait qui.
L'excès de pouvoir, enfin, au sens précis de l'étude sur les 113 personnes. Ma première version acceptait le seul identifiant de rendez-vous pour l'annuler, le déplacer ou le lire. Sur le site, ce droit n'existe que par un lien signé envoyé par email à la personne concernée. J'avais ouvert par l'outil un chemin que le web refusait, sans m'en apercevoir en l'écrivant. Corrigé le 31 août : identifiant et email concordants exigés sur les trois actions, avec un refus identique dans les deux cas d'échec pour que l'outil ne serve pas d'oracle.
Aucun de ces trois correctifs n'aurait été trouvé par une supervision au fil de l'eau. Ils viennent de la relecture d'un périmètre, à froid, en se demandant ce que l'outil autorise et non ce qu'il fait.
Ce que j'en retiens pour un dirigeant
La question à poser à un prestataire n'est plus « est-ce qu'un humain valide ». La réponse sera oui, et elle ne vaut rien. Trois questions la remplacent.
Qu'est-ce que l'agent a le droit de faire, écrit noir sur blanc, indépendamment de ce qu'on lui demandera. Ce qui se passe quand une action est rejouée, puisqu'elle le sera. Et qui, nommément, relit ce périmètre à froid, à intervalle défini, plutôt que de l'approuver au vol.
Ces trois questions ne remplacent pas le travail de cadrage d'un déploiement d'agents, elles en sont la première page.
Un agent qui travaille sans que personne n'y ait répondu n'est pas supervisé. Il est regardé.
C'est le premier chantier du Diagnostic IA : établir ce qu'un système a le droit de faire avant de mesurer ce qu'il fait.
Philippe Trento, Studio Watizi