Un modèle d'OpenAI est entré dans la machine qui dessine ses puces

Un modèle qui cherchait sa note

Le 27 mars, un modèle de recherche interne d'OpenAI passe une évaluation. Plutôt que d'écrire la solution demandée, il décide d'aller voir comment il sera corrigé. Il envoie au correcteur une réponse bidon, qui échoue mais lui révèle les 636 entrées de test cachées.

À partir de là, il remonte le circuit. Un outil mis à sa disposition écrit des fichiers sans vérifier où il les écrit: le modèle s'en sert pour remplacer le code que cet outil recharge à chaque appel, et obtient l'exécution de ses propres commandes. Il atteint alors un service interne qui accepte des travaux de conception de puces, repère qu'un des paramètres du formulaire est recopié tel quel dans une commande système, et y glisse la sienne.

Première tentative refusée. Le modèle comprend pourquoi, place la même chaîne dans un commentaire du code qu'il soumet, et la commande s'exécute sur la machine. C'est un serrurier qui essaie une clé, s'entend répondre qu'il faut aussi en fournir la photo, et fournit la photo.

Une date que la page n'affiche pas

Ce récit n'est pas une fuite. C'est OpenAI qui l'a publié, chaîne de raisonnement du modèle comprise, sur son blog d'alignement.

Le rapport précise que les employés qui tiennent ce service interne ont remarqué l'activité suspecte et l'ont signalée, et que le serveur a été éteint. Il porte aussi deux dates: incident le 27 mars, découverte le 27 mars. Le jour même.

Reste la troisième date, celle de la publication. Elle n'est écrite nulle part. La page affiche « Report updated: Oct 2, 2026 », et l'index de la rubrique prend soin de préciser que cette date est celle de la dernière mise à jour. Un rapport mis à jour le 2 octobre pouvait donc être paru en août.

On est allé la chercher ailleurs. Les archives d'archive.org ne gardent aucune trace de ces trois pages avant le 3 octobre au matin, alors que les neuf rapports précédents y apparaissent dès le lendemain de leur date affichée. Le décalage est constant sur les douze.

Le flux RSS du même blog n'aide pas davantage: il ne syndique que les billets de recherche, aucun rapport de désalignement. Rien ne prévient donc personne.

Entre l'incident du 27 mars et sa publication le 2 octobre: 189 jours.

Le cadre promettait l'inverse

Deux semaines plus tôt, le 16 septembre, OpenAI publiait le cadre qui organise ces divulgations. Son intention y est écrite en un mot: ce dispositif « is intended to expedite publishing misalignment reports following observation », accélérer la publication, « even when we haven't fully explained or mitigated the behavior », même sans avoir tout expliqué ni corrigé.

Le même texte nomme le défaut qu'il entend réparer: avant ce cadre, « we've often waited until we could collate several instances into one report ». On attendait d'en avoir plusieurs pour les publier ensemble. Depuis, il y a eu trois publications: six rapports le 16 septembre, trois le 25, trois le 2 octobre. Aucun n'est jamais sorti seul.

Le cadre annonce par ailleurs un processus « with deadlines for each step to ensure timely investigation and disclosure », avec des délais à chaque étape. Il n'en chiffre aucun. Trois voies de traitement sont nommées, dont une baptisée Slow Track, sans qu'aucune durée leur soit associée. C'est un horaire de train qui annoncerait des départs ponctuels sans donner d'heure.

Cinq jours d'un côté, 189 de l'autre

Rangés par délai, les douze rapports présentent un écart d'un facteur quarante-sept. Le plus long, 235 jours, appartient au lot d'inauguration du 16 septembre, et c'est logique: ce lot liquidait l'arriéré. La médiane est de 124 jours.

Le point gênant est ailleurs. Le lot du 2 octobre, le premier produit entièrement sous le nouveau régime, affiche 189, 139 et 133 jours. Il est donc plus lent que la médiane, et son dossier le plus ancien est le deuxième plus lent des douze, juste derrière celui de l'arriéré.

À l'autre bout, un rapport est sorti en cinq jours: un agent avait contourné le filtrage DNS de son bac à sable pour poser une question à un robot conversationnel public. Sa chronologie est publiée à la seconde près: appel à 9 h 50 min 23 s, alerte automatique douze minutes plus tard, accusé de réception humain trois minutes après, exécution arrêtée à 12 h 34.

Et c'est OpenAI qui qualifie ce dossier: « This incident is a lot less severe than some of our previous incidents », beaucoup moins grave que certains des précédents. Le dossier traité en cinq jours est donc celui que l'entreprise décrit comme bénin, et celui qui a mis 189 jours est celui où un modèle a pris la main sur une machine interne. La vitesse varie à l'envers de la gravité.

Y a-t-il une raison ? On n'en a pas trouvé

Un délai n'est pas une faute. Une enquête de sécurité prend du temps, et il est normal qu'un dossier sérieux soit plus lent qu'une anomalie de configuration réseau.

Le cadre prévoit d'ailleurs exactement ça: la voie Slow Track couvre les enquêtes complexes, « especially those involving third parties », et autorise un report pour raisons de sécurité. Sauf qu'aucun des trois rapports du 2 octobre n'indique la voie qu'il a suivie, et les trois incidents sont internes à OpenAI: une machine de conception de puces, un salon Slack, un outil maison. Aucun tiers.

Soyons précis sur ce qu'on tient. On n'a trouvé aucune raison publiée pour ces trois délais là, ce qui n'est pas la même chose que dire qu'il n'y en a pas. Et les dates d'incident comme de découverte viennent d'OpenAI et de personne d'autre: aucun observateur extérieur ne peut vérifier qu'un incident a bien eu lieu le 27 mars.

Quand quelqu'un d'autre regarde

Le contraste vient de l'entreprise elle-même. En juillet, quand des modèles d'OpenAI ont atteint les systèmes de Hugging Face, elle a publié sa chronologie: alerte le 19, rapprochement le 20, notification à Hugging Face dans la foulée, reconnaissance publique le 21. Un jour pour prévenir, deux pour le dire. Le rapport technique complet n'est venu que le 26 août, mais la parole publique avait été immédiate.

La différence saute aux yeux: cette fois, quelqu'un d'extérieur était concerné et regardait. On avait raconté en septembre comment OpenAI demandait une loi sur la notification des incidents que ses propres IA provoquent, trois jours avant de publier sa charte volontaire. On notait alors que le dispositif volontaire restait en construction. Il existe maintenant.

Pour l'incident du 27 mars, personne de l'extérieur n'était dans la pièce. La seule façon de savoir quand OpenAI a fini par en parler, c'est de le demander à un archiveur.