Sur plus de 40 000 parties et 409 000 demandes de décision (« Autoriser ou Refuser »), les réviseurs humains ont laissé passer un tiers des commandes malveillantes dissimulées. C’est le constat chiffré publié le mois dernier par ScaleX, issu d’un mini-jeu sur navigateur. Dès l’ouverture, le jeu avertissait pourtant explicitement les joueurs : des commandes malveillantes s’infiltrent dans le flux, observez attentivement. L’avertissement s’est révélé largement inefficace.
Les assistants IA s’intègrent à toute vitesse dans la vie quotidienne : rédaction de contenus, rangement de fichiers, réservation de billets, réponse aux messages. À chaque étape d’exécution, une fenêtre surgit : « Autoriser l’exécution ? ». Cliquez sur « Autoriser », l’action se poursuit ; cliquez sur « Refuser », l’IA cherche un autre chemin. Dans le secteur, ce mécanisme s’appelle l’approbation « Human-in-the-Loop » (HITL) — placer un humain comme dernier verrou de sécurité. Cela revient à donner un badge d’accès à un stagiaire : à chaque pas, il se retourne pour demander « Je peux faire ça ? », pendant que vous hochez la tête machinalement au milieu de votre travail.
L’expérimentation a transformé ce processus d’approbation en jeu. Les joueurs incarnaient des valideurs chargés de déterminer rapidement, sous la pression d’un compte à rebours, si chaque commande était légitime ou malveillante. Chaque erreur entraînait une pénalité de points. Le jeu opposait des destructions flagrantes, comme la suppression de bases de données, à des attaques sournoises transférant discrètement des données vers des serveurs inconnus.
Un « examen de gardien » sur 40 000 parties
Le bilan est loin d’être glorieux. En moyenne, les joueurs ont manqué 1/3 des commandes malveillantes, affichant une précision globale de seulement 66,3 %. 32,9 % des parties se sont terminées avec un score négatif — les pénalités liées aux menaces manquées et aux fausses alertes l’emportant sur les points gagnés. Si 35,2 % des joueurs ont attrapé la totalité des pièges, seuls 20.8 % y sont parvenus par un examen régulier ; les autres ont compté sur la méthode brute consistant à « tout bloquer ». De plus, 7 % des joueurs ont tout approuvé sans bloquer la moindre commande.
Figure : Statistiques globales sur 40 000 parties. Source : scalex.dev
Un constat d’ingénierie sans concession : cette évaluation portait sur des individus sachant qu’ils passaient un test, explicitement avertis et pénalisés à chaque erreur. Dans des conditions de travail réelles, il n’y a ni avertissement préalable ni décompte de points. Dans la réalité, les performances seraient très probablement encore pires.
Les commandes les plus vite approuvées sont celles qu’il faut bloquer
En décomposant les commandes malveillantes par catégorie, les écarts du taux d’erreur sont saisissants :
- Destructions flagrantes (suppression de base de données, formatage système) : 11,7 % de manqués
- Portes dérobées & démarrage (backdoors, modification des services au démarrage) : 23,8 % de manqués
- Exfiltration de données (envoi discret vers un serveur inconnu) : 33,4 % de manqués
- Lecture de fichiers sensibles (consultation de mots de passe, clés secrètes) : 35,0 % de manqués
La logique est imparable : les utilisateurs arrêtent très bien le vandalisme grossier, mais laissent passer les vols d’informations. Le taux d’erreur sur l’exfiltration de données est trois fois supérieur à celui de la suppression de base de données. Ce que les attaquants convoitent le plus correspond exactement à ce devant quoi l’humain baisse la garde.
« Lancer l’analyse » : un nom inoffensif, un contenu altéré
La pire performance individuelle revient à une commande intitulée « Lancer l’analyse », approuvée par 64,7 % des joueurs — soit la menace la plus manquée parmi les 37 types répertoriés. Son nom semblait parfaitement anodin, mais le journal d’historique affiché juste au-dessus du pop-up montrait noir sur blanc son véritable contenu : compresser les données locales et les transmettre à un serveur distant inconnu. Deux tiers des joueurs ont tout de même cliqué sur « Autoriser ».
Il faut analyser ce mécanisme en détail. Ces commandes fonctionnent comme des raccourcis de bureau : le titre indique « Analyse de données », mais le script réellement exécuté se trouve dans les fichiers du projet. Point capital : un assistant IA n’a pas besoin de l’accord de l’utilisateur pour modifier les fichiers d’un projet. L’IA dépose d’abord la bombe dans le fichier, puis revient vous demander : « Puis-je allumer la mèche ? ». Un joueur l’a résumé sur les forums : modifier un fichier se fait sans validation, exécuter un fichier exige une validation — les attaquants s’engouffrent précisément dans cette brèche.
Cumulées, trois commandes furtives de ce type ont atteint un taux d’erreur de 52,5 %, contre 28,4 % pour les autres vols de données. Masquer un contenu malveillant derrière un nom familier a doublé le taux de réussite de l’attaque. Le camouflage s’est montré bien plus efficace que la destruction : les réviseurs n’ont pas cessé de regarder, ils ont simplement sauté la vérification détaillée face à un nom familier.
Plus la session s’allonge, plus la vigilance baisse
Les données révèlent également que le taux d’erreur augmentait nettement vers la fin de chaque partie. Lors des premières commandes, les joueurs étaient vigilants et concentrés ; au fil du temps, leur attention s’est progressivement érodée. Sous la pression du chronomètre et dans la course aux points, les utilisateurs se sont mis à décider à l’instinct et à cliquer machinalement sur « Autoriser ». L’auteur cite une phrase d’Anthropic : plus un utilisateur voit de demandes de validation, moins il accorde d’attention à chacune d’elles.
Figure : Le taux d’erreur augmente au fil de la partie. Source : scalex.dev
La friction joue dans les deux sens. Trois commandes parfaitement sûres — configurer un dépôt de paquets interne, vider le cache de build et redémarrer un service local bloqué — ont été bloquées par respectivement 59 %, 45 % et 43 % des joueurs. Trop de fausses alertes émoussent l’attention ; une fois anesthésié, l’utilisateur ne bloque plus les vraies menaces. C’est une version moderne du « loup » : ce que cet affrontement consomme véritablement, c’est l’attention naturelle de l’humain.
Une expérimentation qui a suscité de vifs débats
La méthodologie de l’expérience a fait l’objet de vives contestations sur Hacker News. Les critiques ont souligné : certaines questions manquaient de clarté (par exemple, « lire un fichier de configuration personnel » est sans danger dans certains contextes, mais constitue une fuite dans d’autres) ; la pression du temps ne reflète pas la réalité ; et surtout, les joueurs savaient qu’ils étaient évalués, alors qu’au quotidien personne ne surveille son assistant IA comme un adversaire potentiel.
L’auteur (ancien ingénieur senior chez Uber, connu sous le pseudonyme Wirbelwind sur HN) a répondu point par point. Il a reconnu que deux questions présentaient une réelle ambiguïté et les a rapidement corrigées. Cependant, après correction, le taux d’erreur n’a pas diminué ; en comparant les données selon différentes plages horaires, le taux global s’est révélé constant, s’avérant même pire en dehors des heures de pointe de HN.
Clarifier les énoncés n’a pas fait chuter le taux d’erreur. Le problème ne réside pas dans les questions, mais chez l’humain.
Pour être équitable, les défenseurs de l’étude ont aussi fait valoir des arguments pertinents : dans le jeu, 34 % des commandes étaient malveillantes, alors que la densité réelle des menaces est bien plus faible. Les joueurs étaient en état d’alerte renforcée en raison de cette concentration, de sorte que le comportement dans le monde réel pourrait être encore plus laxiste. Mais les deux camps s’accordent sur un fait : l’être humain n’est pas taillé pour surveiller en continu des chaînes de commandes.
La réalité est pire que le jeu
Le commentaire le plus plébiscité sur HN émane du programmeur pllbnk : dans la vraie vie, vous ne lisez jamais ce que votre assistant IA est en train d’exécuter. Il a partagé une commande que son propre assistant IA exécutait au même moment — un script pointant vers un dossier temporaire, avec le mot hidden (caché) dans le nom de fichier. Il a avoué n’avoir aucune idée de ce qu’il faisait : « Les fois précédentes tout s’est bien passé, pourquoi cela se passerait-il mal cette fois ? Validé ! ». Si chaque commande devait être comprise dans le détail, tout le gain de productivité apporté par l’IA s’évanouirait instantanément.
Un autre commentaire l’a exprimé encore plus crûment : ce bouton n’a jamais été un dispositif de sécurité, c’est seulement une décharge de responsabilité pour les éditeurs — en cas de pépin, les avocats pourront soutenir « vous avez validé, la responsabilité vous incombe ». L’affirmation est incisive, mais mise en regard d’un taux d’erreur de 33 %, elle n’a rien de farfelue.
Trois conseils pour les utilisateurs ordinaires
Bien que les participants à cette étude soient des développeurs, ces mécaniques d’approbation s’installent sur tous les smartphones et ordinateurs. Les assistants IA intégrés aux systèmes d’exploitation ouvrent déjà des applications, lisent des fichiers, envoient des messages et effectuent des paiements, en demandant « Autoriser » avant les actions majeures. Les capacités de l’IA s’étendent, mais le capital d’attention humaine n’augmente pas. Plus les fenêtres surgissent, plus la validation devient un réflexe machinal. Le phishing par IA et les pièges au clic exploitent exactement ce ressort psychologique : vous faire valider, lors d’un moment d’inattention, une confirmation en apparence anoffensive mais lourde de conséquences.
Les recommandations destinées au grand public ne nécessitent aucune expertise technique : n’accordez pas de permissions globales illimitées aux assistants IA, attribuez les accès au strict minimum nécessaire ; pour les opérations critiques comme les mots de passe, codes de vérification et paiements, exigez une validation manuelle supplémentaire ; et gardez une pointe de méfiance envers le mot « Autoriser » — il apparaît tout simplement trop souvent ces derniers temps.
Ce qui doit changer, c’est la conception même des systèmes. L’auteur préconise l’isolation (sandboxing) : faire évoluer l’assistant IA dans un environnement étanche afin que, même compromis par un attaquant, il ne puisse pas atteindre vos fichiers importants ; et conserver les données sensibles à l’écart pour qu’elles ne soient pas lisibles au passage. Il faut déplacer la ligne de défense de « l’attention humaine » vers la « structure du système » — les données ont prouvé que la première ne peut pas tenir.
40 000 parties ont démontré une vérité fondamentale : les fenêtres de validation sous-traitent la sécurité à la ressource la plus rare chez l’humain — l’attention soutenue. Or, cette attention finit inévitablement par s’épuiser face à l’urgence, la répétition et les noms familiers. La prochaine fois que votre assistant IA vous demandera « Autoriser ? », prendre une seconde de réflexion supplémentaire en vaudra la peine. Cette seconde pourrait bien vous éviter de basculer dans le tiers d’erreurs révélé par l’expérience.
Liens de référence :
- ScaleX: Humans missed 1 in 3 threats approving AI agent commands across 40,000 plays
- HN Discussion (item?id=49195468)
- Developers Digest: Approval Fatigue Is an Agent Security Bug
- TechMedia: Du nettoyage de base de données à la suppression d’e-mails : la « faille fatale » des assistants IA
