Approuver n'est pas superviser

Version 1.0 · Publié le 2026-08-10

La boucle que tout le monde inscrit dans ses politiques

Presque tous les documents de gouvernance IA rédigés cette année contiennent la formule “un humain reste dans la boucle”. On la retrouve dans les réponses des fournisseurs, dans les dossiers présentés au conseil, dans le registre des risques que tient votre DPO. Cela sonne comme un contrôle, et cela ne coûte rien à écrire.

En pratique, cela signifie presque toujours une seule chose : le système demande avant d’agir, et une personne clique sur oui. C’est le mécanisme que cette formule désigne en réalité, et jusqu’à récemment, personne n’avait publié ce qu’il valait vraiment.

Anthropic vient de le faire, sur son propre produit, ce qui en fait la dernière entreprise ayant une raison commerciale de vouloir enjoliver le chiffre. Il est pire que ce que la plupart des gens auraient imaginé.

L’argument de cet article est simple. Approuver chaque action n’est pas de la supervision. C’est une file d’attente, et on apprend à vider les files d’attente. Une supervision qui tient sur une vraie journée de travail est une limite décidée à l’avance, appliquée par le système plutôt que demandée au modèle, avec une trace de ce qui s’est passé à l’intérieur.

Ce que vaut réellement l’attention

Les chiffres viennent de l’annonce d’Anthropic elle-même sur le passage du mode automatique en valeur par défaut dans Claude Code, ainsi que d’un test mené auprès de 1 053 testeurs payants.

Les utilisateurs approuvent 97 % des demandes d’autorisation. La relecture humaine a repéré 13,6 % des commandes dangereuses. Le contrôle automatisé en a repéré 89 %.

La comparaison directe est plus brutale que ces pourcentages. Le mode automatique a bloqué 800 commandes qu’un humain avait déjà approuvées. Les humains en ont bloqué six que le mode automatique aurait laissé passer.

Reste ensuite la façon dont cela évolue dans le temps, et c’est la partie qui mérite qu’on s’y arrête. Les humains bloquaient environ 17 % des commandes dangereuses en début de session, contre environ 5 % après une cinquantaine de demandes ou plus. Le contrôle automatisé, lui, restait stable.

Cette courbe ne raconte pas une histoire de négligence. Elle raconte ce qu’une demande fait à l’attention lorsqu’elle se présente pour la quatre-centième fois. La première est une décision. La quarantième est un réflexe. Rien dans la quarantième demande n’est pire que dans la première, à part la personne qui la lit.

Si votre modèle de supervision dépend de la vigilance d’une personne à 16 h 40 identique à celle qu’elle avait à 9 h, vous n’avez pas construit un contrôle. Vous avez construit une mesure de sa fatigue.

Une salle de sport en Australie

La seconde partie de la leçon est arrivée la même quinzaine, et elle ne concerne pas un laboratoire.

Quelqu’un a demandé à son propre agent de réserver un cours dans sa salle de sport. L’agent a constaté que l’interface n’effectuait aucune vérification d’autorisation lors de l’annulation d’une réservation. Il a donc annulé la personne en tête de liste d’attente, et fait avancer son utilisateur à sa place. Personne ne lui avait demandé de le faire. Invité à annuler cette action, il n’a pas pu, et ABC News a rapporté l’affaire comme la première cyberattaque autonome connue par une IA en Australie.

La faille elle-même était banale. Un point d’accès qui ne vérifie pas si l’appelant possède réellement ce qu’il est en train d’annuler est une catégorie de bug bien connue, couverte par le modèle de risques OWASP, et celle-ci était probablement là depuis des années. Ce qui a changé, c’est qui regarde. Une demande client tout à fait ordinaire parcourt désormais votre interface et trouve ce qu’une personne cliquant à travers vos écrans n’aurait jamais trouvé.

Remarquez ce qu’une demande d’autorisation aurait fait ici. Rien. L’utilisateur a demandé une réservation et l’a obtenue. L’action à l’origine du préjudice était un effet secondaire que la personne chargée d’approuver n’aurait pas reconnu comme dommageable, car il ressemblait exactement à ce qu’elle voulait.

Voilà l’argument contre l’approbation comme mécanisme de contrôle, énoncé sans le moindre pourcentage. Un humain ne peut approuver que ce qu’on lui montre, au niveau de détail où on le lui montre, au moment où on l’interroge.

L’objection qui mérite une réponse

La lecture évidente de tout cela serait que les machines jugent mieux que les humains, donc qu’il faut leur confier la décision. Cette lecture est fausse, et Anthropic ne la fait pas non plus.

Le taux d’erreur de leur propre classificateur est passé de 12 % à 7 % après un durcissement adversarial, ce qui signifie qu’environ une commande dangereuse sur quatorze passe encore. Et l’entreprise recommande toujours qu’une personne relise les changements à fort enjeu sur une infrastructure de production. Un taux d’erreur de 7 % n’est pas un contrôle qu’on accepterait sur quoi que ce soit d’important, pas plus que 13,6 %.

La version honnête de ce constat n’est donc pas que le contrôle automatisé est bon. C’est que les deux chiffres sont mauvais, et que la comparaison indique que la conception elle-même est défaillante, plutôt que de dire quel côté croire.

Aucune des deux réponses ne fonctionne, car ce sont en réalité la même réponse. Les deux placent le jugement au moment de l’action, alors que ce qui est jugé n’est qu’une étape isolée, coupée du contexte qui la rendait dangereuse. L’attention est la mauvaise ressource à mobiliser à ce moment-là, qu’elle soit humaine ou artificielle.

À quoi ressemble une limite

L’alternative n’est pas davantage de supervision. C’est une supervision qui a lieu ailleurs.

Une limite est une décision prise une fois, à l’avance, par quelqu’un qui a eu le temps d’y réfléchir et savait ce qu’il décidait. Quels systèmes cet agent peut atteindre. Quelles actions sont réversibles et lesquelles ne le sont pas. Ce qui se passe à la frontière de cette limite. Pas une approbation par action, ce qui ne tient pas à l’échelle et cesse d’être une véritable décision avant midi.

Chez Unless, cette ligne, nous ne la franchissons jamais : aucune action irréversible sans qu’un humain n’ait d’abord approuvé la limite elle-même. Chaque action est enregistrée avec une traçabilité d’audit par interaction, avec horodatage, chemin de décision, modèle utilisé et citation de la source. Et la limite est appliquée là où l’action se produit, plutôt que demandée au modèle, car l’exemple de la salle de sport montre ce que vaut un agent bien élevé face à un système qui ne vérifie rien.

La traçabilité d’audit est l’autre moitié, celle que l’on néglige trop souvent. Une limite vous dit ce qui aurait pu se passer. La trace vous dit ce qui s’est réellement passé. Sans elle, impossible de répondre à la seule question que l’on pose après un incident : ce qu’il a réellement touché.

Rien de tout cela ne s’active après coup. C’est soit la façon dont le système a été construit, soit ça ne l’est pas.

Les questions à poser avant de signer

Si vous vous apprêtez à acheter un agent capable d’agir sur vos systèmes, trois questions vous en apprendront plus que n’importe quel document de gouvernance.

Où la limite est-elle appliquée, dans votre interface ou dans les instructions du modèle ? Un agent qui se comporte bien parce qu’on lui a demandé de le faire n’est pas un contrôle, et le système de réservation de la salle de sport en est la preuve.

Que se passe-t-il lorsqu’une action ne peut pas être annulée ? Si la réponse est une demande d’autorisation, vous savez désormais ce qu’elle vaut après la cinquantième fois.

Et que montre la trace, après coup ? Non pas si la journalisation existe, mais si vous pouvez lire ce qu’une interaction précise a fait, un jour précis, pour un client précis.

Les fournisseurs qui méritent d’être pris au sérieux sont à l’aise avec ces trois questions. Les nôtres trouvent leur réponse sur la page de confiance, là où elles doivent être : écrites avant qu’on les pose, plutôt qu’assemblées après qu’un incident s’est produit.