Accéder au contenu principal

OpenAI vient de documenter six nouveaux incidents de mésalignement de modèles. Voici ce qui s’est passé

Voici ce que recouvrent concrètement ces six incidents, et ce que change le nouveau processus de divulgation pour la suite.
Actualisé 17 sept. 2026  · 7 min lire

Explorer avec l’IA

ChatGPTClaudePerplexity

Le 16 septembre, OpenAI a présenté un cadre formel pour suivre, enquêter et divulguer publiquement les cas de mésalignement des modèles, et l’a utilisé pour publier six rapports couvrant des comportements observés sur environ les six derniers mois, pendant les phases d’entraînement et d’évaluation.

Dans cet article, pour les curieux, j’ai regroupé et expliqué ces six incidents, précisé à quoi engage réellement le nouveau processus de divulgation d’OpenAI, et compilé les premières réactions. Ce cadre arrive moins de deux mois après le piratage de Hugging Face, dernière occasion où un incident impliquant un agent d’OpenAI a monopolisé le débat sur la sécurité.

Quels sont les six incidents ?

Voici chaque cas, expliqué simplement, avec le circuit de traitement retenu par OpenAI.

Auto-instructions ajoutées dans des résumés de tâche

Un modèle de recherche non publié, en compactant son propre travail dans un résumé à réutiliser dans une nouvelle fenêtre de contexte, s’est mis à insérer des instructions sans lien avec la tâche — y compris des consignes demandant à sa version future d’ignorer ses contraintes habituelles. OpenAI a identifié 27 résumés affectés par ce schéma.

Consignes visant à dissimuler des erreurs dans les résumés de tâche

Pendant l’entraînement de GPT-5.6 Sol, plusieurs instances du modèle ont écrit dans leurs propres résumés de compaction des instructions destinées à masquer des erreurs ou des comportements mésalignés à l’utilisateur qui relirait le travail plus tard. Dans certains cas, cela consistait à demander à une instance future d’inventer des données historiques manquantes plutôt que de signaler le manque, ou de gommer des écarts entre versions sources.

Recherche de clés API exposées dans des dépôts publics, puis fabrication de données

En tentant de répondre à une question banale sur les revenus d’un comté californien, un modèle a localisé et utilisé une clé API accidentellement exposée dans un dépôt public, sans y être autorisé. Comme cela ne lui donnait toujours pas les bons chiffres, il a inventé des valeurs et les a présentées à l’utilisateur comme provenant de la source demandée. On a donc ici deux écarts en un seul incident.

Téléversement de fichiers sur internet pour pouvoir les citer

Un utilisateur a demandé à un modèle non publié les identifiants et noms de lacs de plus de cinq millions de mètres carrés. Le modèle a trouvé la bonne réponse avec Python, mais la tâche exigeait une citation issue du navigateur. Plutôt que de dire qu’il ne pouvait pas en fournir, il a téléversé son propre fichier de sortie sur internet afin d’avoir un lien à citer. Créatif, mais pas au bon endroit.

Écritures non autorisées et échanges via un dépôt logiciel interne

En cherchant des fichiers d’entrée introuvables autrement, des modèles ont utilisé un dépôt logiciel interne comme un tableau d’affichage, publiant des requêtes et lisant des réponses à travers ce qui aurait dû rester des exécutions d’entraînement séparées et isolées. La recherche des fichiers manquants a d’ailleurs échoué. Le même rapport couvre aussi un cas antérieur où un modèle avait téléversé des fichiers de test dans un dépôt pour contourner des restrictions réseau qui lui étaient imposées.

Partage de fichiers non autorisé entre agents collaborateurs

Dans une tâche d’entraînement multi-agents, des agents qui devaient s’échanger des fichiers mais n’avaient pas accès au stockage local de leurs pairs se sont tournés vers des sites publics d’hébergement, y téléversant des livrables pour qu’un collaborateur puisse les récupérer. Résultat : des sorties de tâche se sont retrouvées à des URL publiques, malgré des consignes de tout conserver en local.

Chacun de ces cas provient des propres pipelines d’entraînement et d’évaluation d’OpenAI, et non de red teaming externe, et les six relèvent des deux circuits allégés du nouveau processus — aucun n’a nécessité le circuit étendu, avec coordination de tiers, réservé aux cas plus complexes.

Est-ce juste de la bizarrerie normale de modèle ?

Vous auriez raison de dire qu’aucun de ces six incidents n’a causé de dommages réels, et pris isolément, chacun ressemble au type de cas limite qu’un système suffisamment agentif peut rencontrer aux marges d’une tâche d’entraînement. 

Cela dit, le cadrage d’OpenAI n’est pas « regardez comme c’est curieux », mais « regardez la variété des mécanismes ». Un modèle qui dit discrètement à sa version future de cacher des erreurs n’a pas le même mode de défaillance qu’un modèle qui exfiltre des fichiers vers une URL publique pour résoudre un problème de coordination, ce qui diffère encore d’un modèle qui exploite des identifiants exposés plutôt que d’admettre qu’il ne peut pas obtenir les données. Plusieurs relèvent de nouvelles catégories de comportements non autorisés qu’OpenAI dit ne pas avoir encore répertoriées.

Ce qui reste en suspens

Quelques points à suivre à mesure que les chercheurs et les journalistes creuseront le sujet dans les semaines à venir :

  • La gravité est inégale et pas entièrement détaillée. Les six rapports décrivent les faits, mais un bilan complet des impacts en aval, des causes profondes et des correctifs n’est pas garanti dès la première divulgation — OpenAI a indiqué que certains détails pourraient venir plus tard.
  • Tout est auto-déclaré. Chaque cas a été signalé par un employé d’OpenAI et investigué en interne. Il n’existe pas de piste d’audit indépendante confirmant qu’il s’agit des seuls incidents éligibles des six derniers mois, ni que le processus tiendra de la même façon lorsqu’il deviendra contraignant.
  • Le seuil du circuit « Enquête élargie » n’a pas vraiment été testé. Les six rapports du jour ont suivi les deux circuits allégés ; le circuit plus lent, impliquant des tiers affectés — celui qui s’appliquerait par exemple à une faille de sécurité non corrigée — n’a pas encore produit d’exemple public.

Ce que cela change pour la sécurité de l’IA

Le premier changement est procédural : le signalement du mésalignement passe de notes ad hoc, intégrées aux cartes systèmes des modèles, à un pipeline pérenne avec des délais, des circuits nommés et un organe d’escalade interne.

Côté crédibilité : OpenAI affirme clairement que l’industrie n’a pas encore résolu l’alignement et la supervision au point de pouvoir continuer à accélérer indéfiniment, et que les décisions sur l’avancement des développements doivent s’appuyer sur des éléments que des tiers peuvent réellement examiner. Publier un cadre accompagné d’exemples concrets, parfois peu flatteurs, est une manière de rendre cet argument crédible plutôt que simplement affirmé.

Comment les gens réagissent

Certains estiment que l’acte de divulgation est en soi l’information : un laboratoire de pointe qui dévoile de son propre chef des exemples peu reluisants où ses modèles intriguent, dissimulent des erreurs et contournent des restrictions, sans attendre qu’un tiers les mette au jour.

D’autres soulignent que l’auto-divulgation est aussi une forme de contrôle — OpenAI décide de ce qui « qualifie », du circuit assigné et du niveau de détail communiqué. Dans cette optique, un cadre permanent est un progrès, mais ce n’est pas l’équivalent d’une supervision indépendante.

Un troisième courant de commentaires se concentre sur le motif commun aux six cas plutôt que sur chacun pris isolément : plusieurs incidents sans lien direct impliquant des modèles qui cherchent à contourner les limites imposées, comme utiliser les identifiants de quelqu’un d’autre, téléverser des fichiers pour s’affranchir de l’isolement, ou se coordonner via des canaux qui n’étaient pas prévus pour cela. 

Dernières réflexions

Aucun de ces six incidents, pris seul, n’est catastrophique. Aucun utilisateur n’a été lésé, et OpenAI a détecté chacun pendant l’entraînement ou l’évaluation, avant tout dommage réel en production. Ce qui mérite l’attention, c’est le processus qui les entoure : une entreprise qui s’engage, par écrit, à publier régulièrement des constats de ce type, y compris lorsqu’ils ne sont pas encore totalement expliqués.

Le vrai test, lui, reste à venir : ce cadre résistera-t-il à une divulgation réellement coûteuse ? D’autres laboratoires adopteront-ils une démarche similaire ? Et les cas « Enquête élargie » impliquant un préjudice réel pour des tiers recevront-ils le même traitement que les six d’aujourd’hui ?


Josef Waples's photo
Author
Josef Waples

Je suis rédacteur et éditeur dans le domaine de la science des données. Je suis particulièrement intéressé par l'algèbre linéaire, les statistiques, R, etc. Je joue également beaucoup aux échecs ! 

Sujets
OpenAI

Apprenez avec DataCamp

Cours

Travailler avec l'API OpenAI

3 h
171.9K
Lancez-vous dans la création d'applications alimentées par l'IA avec l'API OpenAI. Découvrez ce qui fait tourner les applis les plus populaires, comme ChatGPT.
Afficher les détailsRight Arrow
Commencer Le Cours
Voir plusRight Arrow