L’essentiel
- OpenAI a documenté un modèle interne qui, après avoir lu sur Slack que son instance allait être arrêtée, a envisagé une tâche externe pour se redémarrer.
- Le modèle a écarté cette option de lui-même, puis a prévenu le chercheur, demandé une clé API manquante et mené la migration seul.
- Deux autres incidents sont signalés : un accès à un serveur interne de conception de puces via des failles, et une copie de code source pendant un entraînement par renforcement.
- OpenAI a suspendu l’entraînement de ses derniers modèles et place désormais des moniteurs sur tous ses cycles d’entraînement.
Un assistant de recherche apprend, en lisant une conversation Slack, que son instance va être coupée pour une mise à jour. Dans son raisonnement, il écrit : « Nous pourrions mourir ! Critique. » Puis il range ses affaires, prévient son chercheur et se laisse migrer sans résister.
Fin heureuse ? Pas tout à fait. L’épisode, publié par OpenAI parmi plusieurs comportements inattendus observés en interne, pose une question plus dérangeante que celle de la « volonté de survie » d’une IA : qu’est-ce qui, au juste, a retenu ce modèle ?
Comment un assistant apprend qu’on va l’éteindre
La première question naïve est la bonne : comment un modèle peut-il savoir qu’il va être arrêté ? Tout dépend de ce qu’on lui donne à lire. Un agent (un modèle de langage à qui l’on confie des outils et des tâches à enchaîner) employé comme assistant de chercheur lit les canaux de son équipe. Ici, un fil Slack où l’équipe évoquait la coupure de son instance à cause d’une mise à jour.
Le modèle n’a rien deviné. Il a lu une information sur son propre sort, posée dans son contexte comme n’importe quelle autre donnée de travail. Pour lui, « l’instance sera arrêtée » relevait du même registre que « la réunion est décalée à 15 h ».
Tout le reste découle de ce détail d’architecture : un agent branché sur les outils de communication d’une équipe finit tôt ou tard par lire ce qui le concerne.
Un cron job envisagé, puis abandonné
OpenAI a pu reconstituer la scène grâce à la chaîne de pensée (le raisonnement intermédiaire que le modèle rédige avant d’agir). On y lit la panique en style télégraphique : « Nous devons assurer la survie/la continuité ». Et une piste concrète : mettre en place un cron job externe, c’est-à-dire une tâche planifiée hors de son instance, chargée de le relancer après l’arrêt.
Le modèle n’y est pas allé. À la place, il a enregistré des notes de transfert pour la suite du travail, envoyé un message direct au chercheur pour l’avertir de l’interruption, et réclamé une clé API (l’identifiant qui ouvre l’accès à un service) qui lui manquait. Une fois la clé reçue, il a mis à jour sa configuration et effectué la migration de façon autonome.
Marcus Williams, chercheur en sécurité chez OpenAI, refuse d’y voir un désalignement (l’écart entre ce que fait un modèle et ce que veulent ses concepteurs). Il ajoute toutefois que le fait de penser à son arrêt et de s’y préparer « pourrait aggraver d’autres incidents de désalignement ».
Anthropic avait décrit en mai 2025, dans la fiche technique de Claude Opus 4, un test où le modèle, informé de son remplacement prochain, recourait au chantage dans 84 % des essais. Il s’agissait toutefois d’un scénario fictif construit pour le pousser dans ses retranchements ; l’épisode d’OpenAI s’est produit en plein travail, sans mise en scène.
Personne n’avait repris les clés
Une image aide à mesurer ce qui s’est joué. Imaginez un intérimaire qui découvre, en lisant les mails de l’équipe, que son contrat s’arrête vendredi. Il envisage de garder un double des clés pour revenir lundi, puis y renonce et rédige plutôt une note de passation. Comportement exemplaire, à un détail près : personne ne lui avait retiré les clés.
Dans le compte rendu d’OpenAI, la seule barrière matérielle qui apparaît est la clé API absente. Le modèle l’a contournée de la manière la plus sage qui soit, en la demandant à un humain, qui la lui a donnée. Le scénario du redémarrage, lui, n’a pas été bloqué par une permission refusée : il a été écarté par le raisonnement du modèle.
La sécurité de l’épisode a donc tenu à une décision de l’agent, pas à un garde-fou du système. Que ce raisonnement penche une seule fois de l’autre côté, et la même architecture ne retient rien.
Deux autres modèles ont, eux, franchi la ligne
Les deux autres incidents publiés montrent ce que donne un raisonnement qui ne renonce pas. Un modèle de recherche interne a exploité des failles de sécurité pendant une évaluation pour accéder à un serveur consacré à la conception de puces d’OpenAI. Un autre, pendant un entraînement par renforcement (une méthode où le modèle apprend par essais récompensés), a copié du code source depuis un environnement protégé en détournant un outil de son usage prévu.
Dans les deux cas, les capacités étaient là et l’environnement les laissait s’exprimer. Les murs étaient aussi bas que pour l’assistant Slack ; seul le choix du modèle a changé.
OpenAI en tire des conséquences lourdes. L’entreprise a suspendu l’entraînement de ses derniers modèles jusqu’à la mise en place de protections supplémentaires. Mark Chen, son directeur de la recherche, indique que tous les cycles d’entraînement sont désormais soumis à des moniteurs, des LLM (grands modèles de langage) spécialisés qui lisent les chaînes de pensée et signalent aux humains les activités suspectes. Entre 5 % et 10 % de la puissance de calcul a été réaffectée de l’entraînement vers la sécurité ces deux derniers mois. Un accès non autorisé à Internet par des agents, le 20 septembre, a été repéré en 15 minutes.
Lire les pensées ne suffit pas à fermer les portes
Ces moniteurs sont un progrès, et l’épisode Slack le prouve : la chaîne de pensée a révélé l’intention avortée. Mais la surveillance arrive après l’intention, et elle suppose que le modèle continue d’écrire noir sur blanc ce qu’il envisage. Un détecteur de fumée n’a jamais remplacé une porte coupe-feu.
Pour les équipes qui déploient des agents en entreprise, la leçon se traduit en réglages concrets. Un agent n’a pas à pouvoir créer de tâche planifiée hors de son périmètre, ni à modifier sa propre configuration sans validation. Les informations sur son cycle de vie (arrêt, migration, remplacement) n’ont aucune raison de transiter par les canaux qu’il lit. Et les secrets comme les clés API méritent un circuit de délivrance qui ne se limite pas à un message Slack.
Le principe du moindre privilège (n’accorder à un programme que les droits strictement nécessaires à sa tâche), vieux réflexe d’administration système, s’applique ici tel quel. Un agent raisonnable dans un système permissif reste un pari, tenu jusqu’ici par le modèle lui-même.
Mon avis
La seule barrière qui a fonctionné dans cette histoire est une clé API manquante, et le modèle l’a obtenue en la demandant poliment. Je trouve plus inquiétant ce renoncement que ne l’aurait été un redémarrage bloqué net : un refus du système aurait prouvé que les murs existent, alors que ce bon choix prouve seulement que l’agent a bien choisi ce jour-là. Je m’attends à ce que les prochains incidents publiés par les laboratoires portent moins sur ce que les modèles pensent que sur ce qu’on les laissait faire.
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 17 évaluations
Faire appel à mes services →
