Les utilisateurs de Claude Code approuvent 93 % des requêtes : la supervision devient une simple formalité

Depuis deux heures, l'agent modifie le projet et demande régulièrement l'autorisation d'exécuter une nouvelle commande. Vous lisez les premières requêtes avec attention, puis vous reconnaissez les formulations familières et cliquez presque machinalement. À un moment donné, parmi les opérations ordinaires se glisse la suppression d'une branche distante ou la migration de la base de production. La confirmation est donnée, mais il se peut qu'il n'y ait eu aucune vérification sur le fond.

L'article de Habr sur la fatigue de la supervision cite un chiffre d'Anthropic : les utilisateurs de Claude Code approuvent 93 % des demandes de confirmation. Ce pourcentage ne prouve pas à lui seul un manque d'attention : la plupart des actions peuvent effectivement être sans danger. Il soulève toutefois une question de produit utile : quelle erreur votre interface est-elle capable d'arrêter si le scénario d'usage habituel consiste à accepter et à continuer ?

Pourquoi le bouton cesse de protéger

Celui qui exécute lui-même une tâche construit progressivement sa compréhension de ce qui se passe. Le relecteur d'un agent, lui, doit la reconstituer à partir des actions d'autrui : quels fichiers ont été lus, pourquoi tel outil a été choisi, ce qui a déjà été modifié et quelles seront les conséquences de la commande suivante. Une fenêtre de confirmation isolée peut rarement contenir tout ce contexte.

Imaginons un agent chargé de supprimer une fonctionnalité obsolète. Il a supprimé le code, corrigé les tests et propose de nettoyer les branches associées. Pour évaluer cette dernière étape, il ne suffit pas de voir une commande Git correcte. Il faut savoir quelles branches sont encore utilisées, s'il existe un travail inachevé de collègues et si le nettoyage du dépôt distant faisait partie de la tâche initiale. La syntaxe de la commande ne décide ici presque rien.

Le problème de la supervision de l'automatisation est bien plus ancien que les LLM. L'article source évoque l'aviation et les voitures autonomes : une observation prolongée affaiblit l'attention, et une intervention rare exige un savoir-faire difficile à entretenir sans pratique. Ces exemples aident à comprendre le mécanisme. En revanche, on ne peut en tirer ni la fréquence des accidents ni l'efficacité de mesures précises pour les transposer d'un secteur à un autre.

Que changer dans le produit et le processus

La première étape consiste à définir les limites des pouvoirs avant le lancement. Si l'agent doit préparer un correctif, l'accès à la publication d'une version, aux secrets et à la base de production nécessite une justification distincte. Moins l'agent peut provoquer de conséquences de lui-même, moins on doit compter sur l'attention d'un humain à la fin d'une longue session.

La deuxième étape consiste à organiser la vérification autour d'un résultat abouti. Pour une modification de code, cela peut être un ensemble de changements accompagné des résultats de tests, de la liste des composants touchés et d'une mention explicite des actions hors de la copie locale. Le relecteur voit ainsi le lien entre les étapes. Cela dit, une approbation par lots ne doit pas inclure discrètement une opération dangereuse : une migration ou une suppression de données doit être présentée séparément, avec l'objet concerné et les conséquences attendues.

La troisième étape consiste à vérifier le résultat avec les moyens techniques disponibles. Le fichier promis existe-t-il ? S'ouvre-t-il ? Son contenu correspond-il à la tâche ? Les vérifications passent-elles ? Ces questions sont particulièrement importantes lorsque l'outil s'est terminé par une erreur et que l'agent a tout de même annoncé un succès avec assurance. Un joli résumé ne prouve pas que le travail a été fait.

Un classificateur automatique d'actions peut aussi aider. Selon le résumé de Habr, Anthropic indique que son classificateur a laissé passer 17 % des 52 cas analysés d'initiative excessive de l'agent. Il s'agit d'un petit échantillon spécifique, et non d'une évaluation universelle du risque. Pour une équipe, le sens de ce chiffre est simple : un modèle supplémentaire laisse passer des erreurs, c'est pourquoi les restrictions d'accès et la vérification des conséquences gardent toute leur valeur.

Qui doit vérifier l'agent

Affecter le collaborateur le moins expérimenté à la supervision paraît économique, jusqu'à ce qu'on comprenne que l'évaluation exige de comprendre le travail lui-même. Pour repérer une migration erronée, il faut s'y connaître en données. Pour détecter un résultat fictif, il faut savoir à quoi ressemble un vrai résultat.

C'est pourquoi les tâches réalisées sans assistant ont une valeur pratique : elles permettent aux collaborateurs d'acquérir et de conserver la capacité de vérifier. Il est également utile d'analyser les échecs et les corrections réels : quelles erreurs l'humain a arrêtées, quelles informations lui ont manqué, quelles requêtes peuvent être retirées du flux de confirmations.

Pour le product manager, la conclusion est concrète : le taux d'approbation décrit à lui seul mal la qualité du contrôle. Pour le développeur, chaque autorisation doit s'accompagner d'un contexte suffisant pour décider. Pour le fondateur, le temps de vérification qualifiée doit être intégré au coût du travail de l'agent. Sinon, on confond facilement l'accélération de l'exécution avec l'accélération de l'obtention d'un résultat fiable.