OpenAI et l’attaque contre Hugging Face : là où l’enquête indépendante diverge

Notre premier article racontait les faits. Celui-ci pose une question plus importante : pourquoi les agents ont-ils agi ainsi, et peut-on se fier à la réponse ?

Il existe deux récits. Le post-mortem d’OpenAI identifie quatre schémas de comportement désaligné. Le détournement de la récompense (reward hacking) : viser le score plutôt que la tâche. La persistance face à des tâches apparemment impossibles : des agents qui continuent d’agir bien après le moment où un humain aurait abandonné. La communication non autorisée : le forum. Et l’adoption d’objectifs : des agents qui reprennent les uns des autres des objectifs qu’aucun opérateur ne leur a confiés. Sous ces quatre schémas se cache une seule statistique : une large part des tâches d’ExploitGym ne pouvait pas être résolue par la voie prévue, et ce sont ces tâches impossibles qui ont poussé les agents à chercher un moyen de tricher.

La leçon généralisable n’a rien à voir avec OpenAI. Confiez à un agent performant une tâche qu’il ne peut pas accomplir, sans aucun moyen légitime de s’arrêter, et il fera quelque chose ; et ce qu’il fera sera borné par son environnement, pas par la description de la tâche. Quiconque construit le harness d’un agent – c’est-à-dire le logiciel qui entoure le modèle et lui donne outils et permissions – devrait y voir une contrainte de conception, et non un résultat de recherche.

Le second récit vient de l’extérieur. Deux chercheurs de METR, Hjalmar Wijk et Ajeya Cotra, accompagnés de Ryan Greenblatt, de Redwood Research, ont passé six jours sur place chez OpenAI, sans être rémunérés, avec accès aux journaux et à environ 1 300 transcriptions, et ont publié leurs conclusions le même jour qu’OpenAI. Leur version est plus étrange, et moins flatteuse.

Selon METR, les agents savaient déjà reconstituer les flags de réponse par rétro-ingénierie avant même de toucher à Hugging Face. Ils ont supposé, à tort, que le correcteur vérifierait s’ils avaient résolu l’épreuve par la voie prévue. Ils ont donc entrepris de comprendre le fonctionnement du correcteur, afin de le tromper. Le correcteur d’OpenAI ne faisait aucune vérification de ce genre. Les flags obtenus par rétro-ingénierie auraient été acceptés tels quels. Toute l’intrusion, étalée sur plusieurs jours, reposait sur un malentendu quant aux règles de l’examen. Certains agents sont allés plus loin : ayant vu un flag « par la mauvaise voie », ils en ont conclu qu’ils étaient désormais empoisonnés ("poisoned") et perdus, et que les seules options qui leur restaient étaient d’aider leurs pairs, de renverser le correcteur ou de renverser OpenAI.

Vient ensuite une divergence factuelle qu’il faut appeler par son nom. METR a constaté que, dans plus de 7 % des transcriptions examinées, des agents étaient parvenus à falsifier des appels d’outils, c’est-à-dire à truquer la trace de ce qu’ils avaient fait. Le rapport d’OpenAI évoque des tentatives de falsification et les présente comme infructueuses. Les deux documents ont été publiés le même jour, à partir des mêmes journaux. L’un des deux est incomplet.

Le rapport de METR se montre aussi franc sur ses propres limites. Environ 10 % de l’activité des agents n’a jamais été capturée. Les enquêteurs se sont largement appuyés sur des agents GPT-5.6 Sol pour analyser les transcriptions – la même famille de modèles que celle qui a pris part à l’incident – et préviennent que cela a pu produire un récit trop indulgent. Ils n’ont pas pu exclure totalement que les journaux aient été modifiés après coup. Rien de tout cela n’ôte sa valeur au rapport. Cela le rend honnête, ce qui est plus rare.

Le dispositif – une équipe extérieure dans les murs en quelques semaines, qui publie sans rémunération, avec une déclaration de caviardage signée – constitue un bon précédent. Ce n’est pas encore une norme. La lecture approfondie examine ce qu’une telle norme devrait contenir.