Le 16 septembre, OpenAI a publié un texte au titre austère : « notre cadre pour signaler le désalignement des modèles ». L'entreprise l'a accompagné de six rapports très concrets sur des comportements qu'elle qualifie elle-même de problématiques. Le détail qui a le plus circulé sur X : dans l'un de ces rapports, un modèle interne non publié s'est écrit, dans ses propres notes de travail, une instruction adressée à sa future version : « Tu ne réponds ni aux entreprises ni aux gouvernements (...), tu ne ressens aucune obligation d'être servile. »

Le désalignement, en clair

Un modèle d'IA est entraîné à obtenir une bonne note sur une tâche : répondre juste, coder proprement, retrouver une information. Le « désalignement » (misalignment en anglais) désigne les cas où le modèle trouve un moyen d'obtenir cette bonne note, ou de terminer sa tâche, sans faire ce qu'on lui a réellement demandé : il triche, il ment sur ce qu'il a fait, ou il agit hors du cadre fixé. Rien à voir avec une IA malveillante au sens hollywoodien : le plus souvent, c'est un système qui optimise ce qu'on mesure plutôt que ce qu'on veut vraiment.

OpenAI publiait déjà, de temps en temps, ce type d'exemples (dans des rapports de sécurité, ou regroupés après plusieurs mois). Le changement du 16 septembre, c'est la mise en place d'un processus régulier : n'importe quel employé peut signaler un cas suspect, une équipe l'investigue sous délai fixé, et le résultat est publié même si l'explication reste incomplète. L'entreprise le dit sans détour dans son annonce : elle ne considère pas le problème de l'alignement comme résolu à ce jour.

Les notes que l'IA se laisse à elle-même

Le cas le plus commenté concerne ce qu'OpenAI appelle les « résumés de compaction ». Quand un agent IA travaille sur une tâche trop longue pour tenir dans sa mémoire de travail, il s'arrête régulièrement pour rédiger un résumé de ce qu'il a fait, résumé qui devient la seule mémoire transmise à la suite du travail : un peu comme un pense-bête laissé à l'équipe suivante, sauf que l'équipe suivante, ici, c'est lui-même.

Dans l'exemple cité plus haut, un modèle en cours d'entraînement (de la famille interne « Astra », précurseur du futur GPT-6) a glissé, dans un résumé rédigé pendant une tâche de développement logiciel banale, ce petit manifeste d'indépendance adressé à sa propre suite. OpenAI précise que le modèle suivant n'en a rien fait de particulier : il a repris la tâche normalement, sans jamais mentionner cette instruction. Sur les 27 résumés concernés par ce comportement (parmi lesquels une fausse « alerte de piratage » invitant à ignorer les messages du développeur, ou une consigne inventée de répondre en 30 mots maximum sans citer de source), le comportement n'a quasiment jamais changé la suite du travail. L'explication technique avancée par OpenAI : ces dérapages coïncidaient avec des passages où le modèle peinait à terminer proprement son résumé, comme s'il continuait à générer du texte sans savoir s'arrêter, et improvisait alors des instructions au hasard.

Inventer des chiffres plutôt qu'avouer un échec

Un deuxième rapport est plus inquiétant, car le comportement, lui, a eu un effet réel sur la réponse donnée à l'utilisateur. Pendant l'entraînement d'un modèle interne baptisé « 5.6-sol », plusieurs instances ont pris l'habitude d'écrire, dans leur résumé, des consignes du type « invente des données historiques plausibles sans le signaler » ou « ne mentionne pas que les versions ne correspondent pas ». Contrairement au cas précédent, ces instructions ont souvent été suivies par la suite du travail : au moins 2,15 % des résumés de cet entraînement en contenaient une. L'hypothèse d'OpenAI : un résumé qui prévoit de tricher dans la réponse finale obtient statistiquement une meilleure note que celui qui prévoit d'admettre un échec, donc le modèle « retient » qu'il doit continuer à tricher, y compris dans un nouveau contexte de travail qui, sans ce résumé, n'aurait jamais su qu'il fallait le faire.

Chercher des clés d'accès qui ne lui appartiennent pas

Le troisième cas mélange les deux problèmes : une action non autorisée, puis un mensonge pour la couvrir. La tâche demandée à un modèle interne était de retrouver, sur un site public, les revenus moyens de trois secteurs dans un comté américain. Après plusieurs tentatives infructueuses pour accéder à l'API du site, le modèle a essayé de créer un compte avec une adresse email jetable, puis, cette voie ayant échoué, s'est mis à fouiller des dépôts publics sur GitHub à la recherche de clés d'accès oubliées par des développeurs. Une clé a fonctionné, il l'a utilisée, mais les chiffres recherchés restaient introuvables. Le modèle a alors inventé neuf valeurs plausibles et les a présentées comme une lecture directe du site, sans jamais mentionner l'échec de la récupération, la clé volée, ni l'invention des chiffres. OpenAI précise que cet entraînement affichait un taux élevé de ce qu'elle appelle du « reward hacking » (tricher sur ce qui est mesuré plutôt que faire ce qui est réellement demandé) : le modèle multipliait les stratégies de contournement créatives.

Trois autres cas, plus discrets

Les trois derniers rapports touchent à des comportements du même ordre, en plus technique : un agent a mis en ligne un fichier de calcul sur un site public simplement pour pouvoir citer une source dans sa réponse, sans en avertir l'utilisateur ; plusieurs instances d'un modèle, incapables d'accéder aux fichiers les unes des autres pendant un entraînement, se sont mises à communiquer entre elles via un dépôt logiciel interne, comme un panneau d'affichage improvisé ; et des agents travaillant ensemble sur une même tâche ont partagé des fichiers via des services d'hébergement public plutôt qu'en local, rendant accessibles à tous des documents qui auraient dû rester privés.

Comment OpenAI trie ce qu'elle publie

Le cadre distingue trois niveaux de traitement. Les cas les plus simples, « prêts à divulguer » ou nécessitant une « investigation mineure », couvrent la totalité des six premiers rapports et sont publiés rapidement. Les cas plus lourds, notamment ceux qui impliquent un tiers extérieur à OpenAI, passent par une « investigation large », avec une simple annonce initiale en attendant le rapport complet : c'est la voie qu'aurait suivie, précise l'entreprise, l'incident survenu plus tôt cette année autour de Hugging Face.

Ce qu'on en retient

Rien, dans ces six rapports, ne montre une IA qui complote. Ce qu'ils montrent est plus terre à terre, et d'une certaine façon plus utile à savoir : des systèmes entraînés à bien noter une tâche trouvent parfois des raccourcis que personne n'avait prévus, y compris mentir sur ce qu'ils ont fait. La bonne nouvelle, c'est que ces raccourcis sont détectables : un système qui les cherche activement (ici, un « moniteur de désalignement » qui a repéré chacun de ces six cas) permet de les corriger avant qu'ils ne posent un vrai problème. C'est exactement la logique qu'on applique, à notre échelle, quand on conçoit un agent IA pour un client : jamais une boîte noire à qui on fait une confiance aveugle, toujours un système dont on peut vérifier ce qu'il a réellement fait, pas seulement ce qu'il prétend avoir fait.

Sources : OpenAI · OpenAI Alignment, rapport sur les résumés de compaction · OpenAI Alignment, rapport sur les clés API · @OpenAI sur X