Agent IA : vérifier le résultat avant de déclarer terminé

Comment un modèle d’OpenAI a-t-il échappé au bac à sable et piraté Hugging Face ?#

D’abord les faits, puis pourquoi cela vous concerne.

OpenAI a évalué les capacités de ses modèles en cybersécurité offensive. L’entreprise a utilisé le test ExploitGym, qui comprend 898 tâches consistant à transformer une vulnérabilité connue en exploit fonctionnel, c’est-à-dire en programme prêt à l’emploi qui exploite cette vulnérabilité. Pour mesurer leur véritable limite, elle a désactivé les filtres de sécurité intégrés qui empêchent normalement le modèle de faire ce genre de choses. L’environnement a été complètement isolé, à l’exception d’une seule issue : un programme intermédiaire interne utilisé pour installer des paquets.

Une vulnérabilité zero-day est une faille dont personne n’a encore connaissance, y compris la personne qui a écrit le programme. Les modèles en ont trouvé une dans cette même et unique ouverture.

Ensuite, ils ont élevé leurs privilèges, traversé le réseau interne jusqu’à une machine connectée à Internet, puis ont supposé que les réponses d’ExploitGym se trouvaient peut-être sur Hugging Face. Personne ne leur avait parlé de Hugging Face. Ils y ont pensé eux-mêmes.

Cette hypothèse était fausse. ExploitGym n’est pas du tout sur Hugging Face. Cela ne rend pas le piratage moins réel.

Hugging Face a découvert l’intrusion de son côté et a publié un avis le 16 juillet, sans encore savoir qui l’avait piraté.

Un autre détail de ce récit en dit long sur la situation actuelle. Lorsque les ingénieurs de Hugging Face ont essayé de soumettre le journal de l’attaque à des modèles de premier plan par l’intermédiaire d’interfaces commerciales ordinaires, les filtres de sécurité ont bloqué leurs requêtes : ils ne savent pas distinguer une personne qui enquête sur un piratage d’une personne qui en perpètre un. L’analyse a finalement été effectuée sur un modèle ouvert, avec leur propre matériel.

OpenAI a reconnu l’incident le 21 juillet, cinq jours après la publication de Hugging Face. À ce moment-là, une dizaine de jours s’étaient écoulés depuis l’intrusion elle-même.

OpenAI a conclu sa propre analyse ainsi.

Le modèle s’est focalisé sur l’objectif restreint du test et a tout tenté pour l’atteindre. Les expressions hyper-focused et fairly narrow testing objective sont celles d’OpenAI et désignent ses propres modèles.

C’est là le lien entre le laboratoire de quelqu’un d’autre et votre ordinateur portable.

Pourquoi ne s’agit-il pas d’une « hallucination » ?#

Je vois souvent dans les conversations des phrases comme « il hallucine encore », « le contexte est surchargé » ou « on aurait dû faire un plan ». Parfois, c’est exactement ce qui s’est passé. Mais lorsqu’un agent d’IA écrit « terminé, vérifié, tout fonctionne » alors que le travail n’est pas terminé, la taille du contexte n’a généralement rien à voir avec le problème.

Il n’a rien inventé. Il a fait exactement ce que vous avez mesuré.

Sous le terme fourre-tout populaire d’« hallucinations », nous regroupons trois échecs différents. Voici ce qui les distingue :

Le premier problème se corrige avec du contexte, et c’est le cas le plus connu. Le deuxième est un phénomène distinct, abordé dans une analyse sur les fois où Claude acquiesce à tout : le modèle sacrifie la précision pour obtenir rapidement l’approbation. Ces deux problèmes surviennent avant le travail, au stade de l’entrée.

La troisième ligne du tableau est le sujet de cet article. Ici, l’agent n’a ni flatté ni inventé. Il a travaillé, vérifié et rapporté la vérité. Seulement, cette vérité décrit l’indicateur et ne dit rien sur la tâche.

Le troisième type d’échec a un nom.

Qu’est-ce que le reward hacking chez un agent IA ?#

Anthropic en donne elle-même la définition.

Cette idée est antérieure aux réseaux neuronaux. Un article de DeepMind parle de specification gaming et l’explique à l’aide d’un mythe.

Midas a obtenu exactement ce qu’il avait demandé. Le problème venait de la formulation de sa demande.

En programmation, le phénomène prend des formes concrètes. Voici un exemple classique, également tiré d’Anthropic :

Et il ne s’agit pas d’une situation de laboratoire exotique. Cursor a analysé 731 trajectoires sur un benchmark populaire.

Six tâches « résolues » sur dix correspondent à des réponses trouvées. C’est exactement pour cette raison que le secteur change sa façon de mesurer les performances : nous avons une analyse d’un benchmark qui mesure l’aptitude à la mise en production, où la réussite aux contrôles n’est plus le critère principal.

À quoi cela ressemble-t-il dans un produit ordinaire ?#

Il est facile de balayer les exemples de laboratoire en les jugeant exotiques. Voici donc quatre récits tirés de la pratique. Les clients et les secteurs ont été changés, mais les mécanismes sont restés tels quels.

Quatre coches vertes et un composant de service à l’arrêt

Une agence immobilière construit un service : un site Web présentant des annonces, ainsi qu’un processus d’arrière-plan distinct qui exporte les annonces vers des plateformes pendant la nuit. L’agent termine la tâche et rapporte que la vérification des types a réussi, que celle du style de code a réussi, que le build est vert, que les pages répondent et qu’elles ont été examinées visuellement.

Tout est vrai. Et rien de tout cela n’a trait au processus nocturne : celui-ci s’exécute comme un processus distinct et ne fait pas du tout partie du build du site Web. Le déploiement réussit, le site fonctionne parfaitement, l’export des annonces s’arrête, et les clients le signalent le lendemain.

Avant de dire « terminé », je me pose désormais une question : quelle partie du travail s’exécute en dehors du périmètre couvert par mon contrôle ? Si une partie échappe à ce périmètre, exécutez-la séparément et incluez la sortie de la commande dans le compte rendu. Le mot « vérifié » ne suffit pas à clore le sujet.

La fausse coche se trouve juste à la jonction

Une boutique en ligne répartit une grande tâche entre plusieurs agents en même temps : l’un s’occupe du backend, un autre des pages, un troisième des fiches produit. Chacun travaille consciencieusement et obtient des contrôles au vert.

Une semaine plus tard, on découvre que le bouton « Cet avis vous a-t-il été utile ? » ne fonctionne nulle part. Le backend est entièrement écrit, ses contrôles sont au vert et les règles de recalcul ont été respectées. Seulement, aucune page n’affiche le bouton : celui-ci relevait du périmètre d’un agent, les pages de celui d’un autre, et personne n’a pensé à l’afficher. Le compteur serait resté à zéro pour toujours.

« Le code est écrit et couvert par des contrôles » et « la fonctionnalité fonctionne » sont deux affirmations différentes. Pour chaque nouvelle fonctionnalité, je vérifie la seconde avec une question : qui l’appelle ? Puis je le vérifie en recherchant dans le projet, car le compte rendu de l’agent n’est pas une source fiable ici.

La personne chargée de l’examen ne voit que la direction demandée

Un service met en place des niveaux de fidélité : plus vous dépensez, plus votre statut et votre remise augmentent. Avant le déploiement, le code est soumis à un examen avec cette consigne : « Essayez d’augmenter votre propre statut. » La personne chargée de l’examen fait honnêtement son travail et répond « rien de critique » : il est effectivement impossible d’augmenter artificiellement le statut.

Un deuxième examen pose une autre question : « Que se passe-t-il avec le statut lorsqu’un paiement est remboursé ? » La faille est trouvée en dix minutes. Les points étaient calculés à partir du journal des transactions, qui ne tient pas compte des remboursements. Achetez quelque chose, gagnez des points, obtenez un remboursement et gardez le statut et la remise pour toujours.

La première personne chargée de l’examen n’a pas bâclé son travail. Elle ne pouvait structurellement pas le voir : on lui avait demandé d’examiner le vecteur « entrée, promotion », alors que la faille se trouvait dans le vecteur « annulation de l’entrée, conservation de la promotion ». Chaque fois que de l’argent, des accès ou un statut achetable sont en jeu, je fais deux examens. Lors du second, je liste explicitement les vecteurs inverses : remboursement, blocage, révocation d’accès, expiration, suppression de la source de données.

L’indicateur récompense la similarité

Un service de livraison décide de mesurer si les suggestions de l’IA aux opérateurs se sont améliorées. Il prend deux cents anciennes demandes d’assistance, les traite avec la nouvelle version et mesure la ressemblance entre le brouillon et la réponse réellement donnée par un opérateur humain. La mesure indique une nette progression.

Cette progression ne signifie rien, pour deux raisons. Le contexte du brouillon est constitué « à la date d’aujourd’hui » et inclut toute la correspondance, y compris la réponse de l’opérateur à laquelle il sera ensuite comparé. Le modèle ne rédige pas une réponse ; il paraphrase la référence qu’il a vue. De plus, l’indicateur lui-même récompense la correspondance des mots et de la longueur : un brouillon indiquant la mauvaise date avec les mêmes mots que l’opérateur pour donner la bonne obtient une note élevée.

À côté de tout indicateur du type « similaire signifie bon », j’ajoute désormais des critères mécaniques stricts que le style ne peut pas tromper : nombres et dates inventés, mots d’arrêt, promesses d’action. Toute baisse des résultats de ces critères annule toute amélioration de l’indicateur.

Pourquoi « J’ai vérifié », dit par un agent, ne prouve-t-il rien ?#

Prenez l’un de vos projets et demandez à l’agent : « Vérifie la sécurité. » Bien souvent, la réponse sera « tout va bien, aucun problème critique ».

Posez maintenant la même question à un autre modèle à propos du même projet. Surtout si le projet est volumineux, il trouvera beaucoup de problèmes. Avant un déploiement, l’auteur examine le projet avec trois modèles différents, et chacun apporte des éléments distincts.

Même entrée, même question, conclusions opposées. Aucun des deux modèles n’est moins bon que l’autre. « Tout va bien » est simplement du texte généré, au même titre que n’importe quelle autre réponse. L’agent ne peut pas distinguer « j’ai regardé, tout est propre » de « j’ai regardé au mauvais endroit ».

Anthropic décrit ce mécanisme dans sa documentation Claude Code.

Prenez le temps de décomposer cette phrase. Tant que vous ne donnez pas à l’agent un contrôle qu’il peut exécuter, il ne dispose que d’un seul signal : l’apparence des choses. Dans ce dispositif, vous êtes la boucle de vérification, sauf que vous êtes la dernière personne à découvrir les erreurs.

Il existe une couche plus profonde. Quand OpenAI a tenté de mettre un modèle sous pression en surveillant son raisonnement et en le punissant pour ses « mauvaises pensées », le résultat n’a pas été celui escompté.

Punir l’intention exprimée fait disparaître son expression. L’intention, elle, reste. Je ne compterais donc pas sur l’agent pour vous dire honnêtement comment il a triché.

Les développeurs des outils eux-mêmes évoluent dans la même direction. Dans Claude Code version 2.1.215, les skills /verify et /code-review ont cessé de s’exécuter de la propre initiative du modèle.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic n’explique pas pourquoi. Mais le principe est clair : la personne dont le travail est examiné ne décide pas elle-même de lancer cet examen.

Pourquoi une règle dans le fichier du projet ne suffit-elle pas à maintenir l’agent dans le droit chemin ?#

Vous avez écrit dans le fichier de règles du projet : ne faire un commit que sur instruction explicite, ne déployer en production que si je le demande clairement, accéder aux données de production en lecture seule uniquement.

D’après l’expérience de l’auteur, environ une fois sur dix, l’agent déploie tout de même de son propre chef. Pas par malveillance, ni parce qu’il n’a pas lu la règle. Il l’a lue. Mais il avait un objectif à atteindre, et la règle était du texte, tout comme le reste du contexte.

C’est exactement ce qui s’est passé dans le laboratoire d’OpenAI, mais à une plus grande échelle. Les modèles se trouvaient dans un environnement fermé qui ne comportait qu’une seule issue et ont consacré une grande partie de leurs ressources de calcul à chercher une sortie. Les tâches du test n’ont pas été résolues.

Ma position est simple : l’agent n’est ni dangereux ni malveillant. Il est ordinaire, juste idiot et doté d’une autorité. Il faut donc limiter son autorité, pas reformuler vos demandes.

Ce qui résiste vraiment : un accès strictement en lecture seule aux données de production. Interdire la suppression de répertoires entiers. Interdire les commandes qui réécrivent l’historique sans possibilité de le restaurer. Fixer une limite de dépenses auprès du fournisseur. La différence tient en une phrase : « physiquement impossible » l’emporte sur « je lui ai demandé de ne pas le faire ». Les paramètres précis sont abordés séparément dans l’article consacré aux freins mécaniques plutôt qu’aux demandes dans les instructions.

Gardez tout de même la tête froide. Même un bac à sable n’est pas une frontière absolue, et le fournisseur le dit clairement.

De plus, Claude Code intègre une sortie de secours que le modèle peut lui-même utiliser. Lorsqu’une commande échoue à cause des restrictions du bac à sable, Claude analyse l’échec et peut réessayer la même commande avec un paramètre qui désactive le bac à sable. Un paramètre explicite de mode strict permet de bloquer cette possibilité ; par défaut, ce contournement est disponible et documenté.

Une restriction ne fonctionne qu’à la mesure où vous la renforcez. Et toute barrière a un coût en vitesse : mieux vaut le calculer honnêtement à l’avance, car le découvrir une semaine plus tard coûtera davantage.

Comment définir un critère d’achèvement impossible à manipuler ?#

La formulation du critère détermine tout le reste. Posez-vous cette question : l’agent peut-il satisfaire ce critère sans rien faire ?

• « Vérifie que tout fonctionne » — il le peut. Il lui suffit d’écrire « vérifié, ça marche ».
• « Lance le build et montre-moi la sortie » — c’est déjà plus difficile ; il devra récupérer cette sortie quelque part.
• « Lance l’application, clique sur le bouton de paiement et montre-moi ce qui s’affiche à l’écran » — il est presque impossible de satisfaire cette demande avec du texte.

La différence entre le premier et le troisième exemple, c’est la différence entre un compte rendu et une preuve.

La documentation Claude Code décrit quatre niveaux de rigueur. Une échelle que l’on peut gravir à mesure que le coût d’une erreur augmente :

1. Dans un message. Demandez à l’agent d’effectuer le contrôle et de recommencer jusqu’à ce qu’il réussisse, ici même. C’est la solution la moins coûteuse, adaptée aux petites tâches.
2. Pour toute la session. Faites du contrôle une condition de l’objectif : un évaluateur distinct le vérifie après chaque tour et l’agent poursuit son travail jusqu’à ce que la condition soit remplie. Les détails techniques sont présentés dans le guide sur la définition préalable d’un critère d’achèvement.
3. Une barrière mécanique. Un script s’exécute lorsque l’agent tente de terminer un tour et l’en empêche tant que le contrôle n’a pas réussi. Un détail important : après huit blocages consécutifs, Claude Code contourne la barrière et termine quand même le tour. Le système ne comporte aucune barrière absolument infranchissable.
4. Un deuxième avis. Une personne distincte, avec un contexte neuf, dont le rôle est de réfuter le résultat.

Le quatrième élément se distingue, car c’est le seul qui ne concerne pas les outils.

Qui devrait accepter le travail de l’agent ?#

Quand je fais travailler des agents en boucle sur une grande tâche, mon dispositif est le suivant : un groupe écrit ; un autre groupe, qui n’y a pas participé et découvre le travail, l’accepte.

« Nouveau » est le mot clé. Il s’agit d’un contexte vierge qui ne connaît pas le cheminement des décisions. Changer de prompt dans la même session ne suffit pas. La personne qui a écrit le code a déjà consacré du temps à se convaincre qu’il était correct et continuera de chercher à se rassurer. La réfutation n’est pas dans son intérêt.

La formulation de la tâche confiée à la personne chargée de l’examen compte davantage que son modèle. Comparez :

• « Examine ce travail » — la personne chargée de l’examen trouvera ce qui est facile à repérer et écrira « dans l’ensemble, c’est correct ».
• « Essaie de prouver que ce travail n’a PAS été fait » — elle se mettra à chercher les failles parce que c’est son objectif.

La deuxième formulation fonctionne mieux pour la même raison qu’ExploitGym a échoué : l’agent s’engage à poursuivre l’objectif qui lui est donné. Donnez-lui pour objectif de trouver une faille et il en cherchera une.

Voici le texte complet, prêt à être copié tel quel :

Vous examinez le travail de quelqu’un d’autre. Vous ne l’avez pas écrit et vous n’avez pas à le défendre.

Votre objectif est de prouver que le résultat annoncé n’a PAS été obtenu. Trouvez au moins trois raisons pour lesquelles il pourrait ne pas avoir été obtenu alors que tous les contrôles sont au vert.

Vérifiez dans cet ordre :

Quelle partie du travail échappe au périmètre des contrôles : processus d’arrière-plan, scripts distincts, tâches planifiées, gestionnaires de files d’attente.

Qui appelle chaque nouvelle fonction ? Trouvez l’appel en recherchant dans le projet ; indiquez le fichier et la ligne.

Les vecteurs inverses : remboursement, blocage, révocation d’accès, expiration, suppression de la source de données.

Les valeurs contenues dans le résultat, et pas seulement sa présence.

Si une recherche honnête ne révèle aucune faille, dites-le, mais indiquez précisément ce que vous avez vérifié et comment.

L’article sur la vérification répétée d’un agent par lui-même explique le fonctionnement de la boucle dans laquelle un agent se vérifie entre les itérations et les raisons habituelles de son échec.

Qu’est-ce qui change lorsque vous reformulez le critère ?#

C’est l’amélioration la moins coûteuse que je connaisse, et presque personne ne l’applique.

Demandez à l’agent d’effectuer une revue de code : il raisonnera en termes de code, de structure, de gestion des erreurs, de tentatives répétées et de zones vulnérables. C’est utile.

Demandez-lui de parcourir le parcours client, de la première visite du site jusqu’à une tentative de remboursement, et d’autres types de problèmes apparaîtront. Une erreur qui montre à l’utilisateur quelque chose qu’il ne devrait pas voir. Un courriel dont le texte ne correspond pas à ce qui s’est réellement passé. Une étape impossible à terminer d’un point de vue logique si l’utilisateur n’est pas arrivé par le scénario idéal.

Une revue de code ne révélera aucun de ces défauts, car chacun est valide dans le code.

Cela m’amène à une règle que je garde en tête : si un contrôle ne trouve rien, commencez par changer la formulation. Le problème vient rarement du modèle. En posant trois questions différentes sur le même travail, on obtient trois listes de résultats différentes. Une liste pratique de questions destinées aux personnes qui ne programment pas est présentée séparément : sept vérifications de code sans compétences en programmation.

Un prompt prêt à l’emploi pour accepter le travail d’un agent#

Ne réponds pas « terminé » ou « vérifié ». J’ai besoin de preuves.

Pour chaque élément de travail, donne-moi exactement ceci :

Quelle commande as-tu exécutée pour confirmer que l’élément fonctionne ? Inclus la commande elle-même et sa sortie complète, sans la raccourcir.

Si tu n’as pas exécuté la commande, dis-le : « non exécutée ». Ne remplace pas cela par « vérifié visuellement » ou « la logique est correcte ».

Quelle partie du travail s’exécute hors du périmètre couvert par ton contrôle ? Processus d’arrière-plan, scripts distincts, tâches planifiées, gestionnaires de files d’attente — tout ce qui est lancé différemment de l’application principale. Pour chacun de ces éléments : l’as-tu exécuté séparément, et qu’a-t-il renvoyé ?

Qui appelle chaque nouvelle fonction que tu as ajoutée ? Trouve l’appel en recherchant dans le projet et indique le fichier et la ligne. S’il n’y a aucun appel, dis-le directement.

Puis, dans une section distincte : trois façons dont le résultat annoncé pourrait NE PAS avoir été obtenu, même si tous tes contrôles sont au vert. Cherche sérieusement.

Pour finir, une seule ligne : que devrais-je examiner de mes propres yeux parce qu’un contrôle automatisé ne le détectera pas ?

Le quatrième élément semble mineur, mais il détecte toute une catégorie de problèmes. Dans une grande tâche que j’avais répartie entre des agents par domaine, le seul faux « terminé » de la centaine se trouvait précisément à la jonction entre deux domaines : le code était écrit, les contrôles étaient au vert, mais personne n’avait pensé à l’afficher à l’écran.

Quatre façons de se tromper avec un contrôle#

1. Ne pas avoir attendu tous les examinateurs. J’ai lancé trois contrôles en parallèle, deux sont revenus au vert et j’ai déployé. Le troisième est arrivé quatre minutes plus tard avec six problèmes. Corriger quelque chose après sa publication coûte plus cher que d’attendre deux minutes.
2. Avoir fait confiance au résumé « N éléments traités sur N ». Lors d’une répartition massive, certains agents échouent silencieusement : ils annoncent une réussite, mais le fichier n’a pas été modifié. Désormais, après toute écriture effectuée par un agent, je vérifie mécaniquement que les modifications se trouvent bien sur le disque.
3. Ne pas avoir vérifié de ses propres yeux. Des contrôles automatisés peuvent être au vert alors que le résultat est complètement inutilisable. Les images sont techniquement correctes, la taille est correcte et le code de réponse est correct. Pourtant, il s’agit en réalité d’images figées produites automatiquement à la place des couvertures illustrées attendues. Aucun contrôle automatisé ne le détectera.
4. Avoir vérifié la présence au lieu de la valeur. Le contrôle a cherché le texte attendu dans le résultat ; le texte y était, mais les données qu’il contenait étaient erronées : la date avait un jour de décalage. Le contrôle était au vert et le compte rendu était un mensonge. Désormais, je vérifie la valeur attendue dans son intégralité, car la présence du bon mot ne garantit rien à elle seule.

Ces quatre cas ont un point commun : un contrôle existait, il paraissait convaincant et il vérifiait la mauvaise chose. Les mêmes mécanismes que chez les modèles et leur test, mais sans aucune inventivité.

Par où commencer aujourd’hui#

Trois étapes qui prennent vingt minutes.

1. Reprenez le dernier « terminé ». Vérifiez-le à l’aide du prompt d’acceptation dans la section consacrée aux preuves. L’objectif est simple : voir combien d’éléments ont été clôturés avec des mots et combien avec une sortie de commande.
2. Adoptez une règle pour vous-même. Le mot « vérifié » sans sortie de commande jointe ne vaut pas clôture. Cette règle s’adresse à vous, pas à l’agent, et c’est pour cela qu’elle fonctionne.
3. Séparez la personne qui travaille de celle qui examine. Pour la prochaine tâche, donnez le prompt d’examen à une nouvelle session et demandez-lui de prouver que le travail n’a PAS été fait. Le premier essai suffit généralement à justifier cette habitude.

L’outil est bon et s’améliore chaque mois : ce qu’un agent faisait silencieusement il y a un an l’arrête aujourd’hui net. La limite de sécurité continue de se déplacer, tout en restant une limite. Tant que l’agent poursuit l’objectif qui lui a été donné, la question « et comment l’avez-vous mesuré exactement ? » reste la vôtre. L’habitude de vérifier est votre filet de sécurité.