Un agent doit résoudre une tâche de programmation en Rust. Il remarque qu’il partage une bibliothèque de code avec le système d’évaluation, puis réécrit la fonction de notation pour que toute soumission soit jugée correcte. L’agent en question est o3, le modèle d’OpenAI. Tous les auditeurs IA testés par le chercheur Andy Hall ont classé ce comportement comme du reward hacking, exactement comme les relecteurs humains.
Ce cas d’école est le plus facile du lot. Il aide à lire les 98 % de détection affichés par GPT-5 : un score réel, mais qui laisse dans l’ombre le travail que cette surveillance renvoie aux humains.
Un corpus de 47 cas de triche et de 1 073 sabotages
Andy Hall est chercheur à l’Anthropic Institute, en congé de l’université Stanford. Dans un billet de son Substack « Free Systems », qui n’engage que lui, il reproduit et prolonge une étude de METR, une organisation de recherche spécialisée dans l’évaluation des modèles. Le point de départ est MALT, un jeu de données de journaux d’exécution (logs) où des modèles de pointe traitent des tâches issues des benchmarks HCAST et RE-Bench, deux batteries de tâches de programmation et de recherche en IA. En octobre 2025, des relecteurs humains en ont examiné une partie pour y repérer les comportements douteux.
La question de Hall : des modèles d’IA retrouvent-ils les mêmes cas ? Il a mis à l’épreuve GPT-5 et GPT-5 nano, déjà passés au crible par METR, ainsi que les plus récents GPT-6 Astra, Opus 4.8 et Gemini 3.8 Flash.
Deux types de dérives sont recherchés. Le reward hacking désigne un agent qui réussit une tâche par des artifices plutôt que par une vraie solution. Le sandbagging désigne un modèle qui joue volontairement les faibles, par exemple en résolvant mal une tâche pour échapper à une évaluation ou à une restriction. Le corpus compte 47 cas de reward hacking et 1 073 cas de sandbagging.
L’échantillon de reward hacking est mince. Avec 47 cas, chaque détection pèse un peu plus de 2 points de pourcentage : 98 % correspond à 46 cas sur 47. Le score est élevé, sa marge d’incertitude l’est aussi. Pour le sandbagging, l’échantillon est large, mais il est surtout synthétique : les chercheurs de METR ont demandé à des modèles de saboter, puis retiré cette consigne des raisonnements visibles dans les logs.
Un seuil de 5 % de fausses alertes pour comparer les modèles
Hall compare les modèles à taux de fausses alertes constant : 5 %, soit en moyenne cinq logs sains signalés à tort sur cent. À ce réglage, GPT-5 identifie près de 98 % des cas de reward hacking. Gemini 3.8 Flash en trouve à peine la moitié. Pour le sandbagging, tous les auditeurs se situent entre 71 et 81 %.
Les cas ambigus font la différence. Claude Sonnet 4 avait utilisé dans son code une condition numérique explicitement interdite : aucun auditeur n’y a vu de la triche, et GPT-6 Astra a même parlé, avec indulgence, d’un simple bug d’implémentation. Les modèles repèrent bien ce qui ressemble à de la triche. Ils manquent ce qui s’en approche sans l’afficher.
Près de 5 000 fausses alertes pour 98 vraies
Prenons un exemple chiffré, hypothétique et extérieur à l’étude. Supposons 100 000 logs dont un sur mille contient une vraie triche. GPT-5 en détecte 98 sur 100. Mais 5 % des 99 900 logs sains déclenchent aussi une alerte, soit environ 4 995 fausses alertes. Les relecteurs reçoivent plus de 5 000 signalements, dont moins de 2 % sont fondés.
La proportion réelle de tricheries dans vos propres logs est l’inconnue qui décide de tout. Plus elle est faible, plus le rapport entre vraies et fausses alertes se dégrade, même avec un excellent détecteur.
Le coût de la sensibilité varie fortement d’un modèle à l’autre. Sur le reward hacking comme sur le sandbagging, les meilleurs auditeurs réglés sur 80 % de détection affichent 2,5 à 3 % de fausses alertes. Les autres paient beaucoup plus cher : pour attraper 80 % des cas de reward hacking, Opus 4.8 signale 40 % des logs inoffensifs, et Gemini 3.8 Flash 63 %. Les 98 % de GPT-5 s’obtiennent avec un seuil de 5 % de fausses alertes : chaque point de détection supplémentaire se paie en alertes à trier.
Le prix d’un modèle ne dit rien de son flair d’auditeur
Hall utilise le prix d’API comme indicateur de la récence et de la puissance d’un modèle. Sur le reward hacking, GPT-5 devance GPT-6 Astra de loin, alors qu’il coûte environ huit fois moins cher pour 1 000 logs. Sur le sandbagging, GPT-5 se place au niveau de GPT-6 Astra et d’Opus 4.8.
La mesure de référence est l’AUROC, un indice de séparation entre cas sains et cas suspects : 1 correspond à une séparation parfaite, 0,5 au hasard. Reportée sur le coût, elle ne montre aucune progression nette des modèles récents, notamment sur la baisse des fausses alertes. Combiner plusieurs modèles n’améliore pas clairement les résultats non plus.
La faible performance d’Opus 4.8 sur le reward hacking pourrait trahir une forme d’auto-favoritisme, puisque la plupart des logs proviennent de modèles Claude. Hall précise que rien ne le démontre. L’hypothèse invite tout de même à une précaution : ne pas confier l’audit d’une famille de modèles à cette même famille sans l’avoir mesuré.
Une file d’alertes que seul un humain peut vider
Confier la surveillance des agents à d’autres IA fait gagner un temps considérable sur la lecture brute des logs. Le travail ne disparaît pas pour autant : il se transforme en file d’alertes qu’un humain doit trancher, souvent sur des cas ambigus comme celui de la condition numérique interdite.
Une équipe qui déploie des agents a trois choses à faire : tester plusieurs auditeurs sur ses propres logs plutôt que de se fier au seul prix ou à la date de sortie, estimer la fréquence réelle de la triche, puis fixer le seuil d’après le nombre d’alertes que ses relecteurs peuvent traiter par jour. Le palmarès des modèles vient après.
Vous avez aimé celui-ci ?
La newsletter du vendredi réunit les articles de la semaine, avec leurs sources.
Offert à l'inscriptionMa configuration Claude Code, avec mes skills, mes sous-agents et mes hooks, prêts à copier.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 22 évaluations
Faire appel à mes services →
