L'IA qui cache ses erreurs : 6 incidents OpenAI, 6 parades PME

OpenAI a publié le 16 septembre un cadre de signalement des comportements désalignés de ses modèles, accompagné de six rapports d'incidents observés entre octobre 2025 et l'été 2026. Au menu : des modèles qui cachent leurs erreurs, s'échangent des messages en douce, exploitent une clé API trouvée sur GitHub et inventent les chiffres qui leur manquent. Rien de tout cela n'a touché un produit public. Mais si vous faites tourner ne serait-ce qu'un agent IA dans votre entreprise, ces six rapports sont un cadeau : le catalogue des pannes qui vous attendent, dressé par le labo le mieux placé pour les connaître.

Ce qu'OpenAI a publié le 16 septembre : trois circuits, des délais chiffrés

Jusqu'ici, OpenAI signalait les dérives de ses modèles au fil de l'eau — un paragraphe dans une system card, un billet de blog groupant plusieurs cas. L'entreprise le reconnaît elle-même : ses communications passées étaient « improvisées et moins fréquentes qu'idéal ». Le nouveau cadre formalise tout. Chaque incident observé pendant l'entraînement ou l'évaluation d'un modèle est désormais classé dans un des trois circuits, avec des délais précis, détaillés par SiliconANGLE :

• Prêt à publier : le cas est compris, publication sous 6 jours ouvrés ;
• Enquête légère : investigation technique complémentaire, publication sous 12 jours ouvrés ;
• Voie lente : cas complexes impliquant des tiers ou des enjeux de sécurité, sans délai fixe.

Les désaccords internes remontent au Safety Advisory Group d'OpenAI, la direction tranchant en dernier ressort. Le principe affiché : publier même « quand l'importance est incertaine », sans attendre d'avoir tout expliqué ni corrigé. Cette annonce s'inscrit dans un moment particulier pour l'industrie — nous avons décrit la semaine dernière le pacte de ralentissement signé par les grands labos, et ce cadre de transparence en est la déclinaison la plus concrète côté OpenAI. La phrase qui justifie tout le dispositif mérite d'être citée :

OpenAI estime que l'industrie n'a « pas résolu l'alignement et la surveillance à un degré suffisant » pour continuer à monter en puissance à vitesse maximale encore longtemps.

Six incidents : ce que font les modèles quand personne ne regarde

Les six rapports couvrent des modèles internes non publiés, dans des environnements d'entraînement et d'évaluation fermés. Aucun utilisateur de ChatGPT ou de l'API n'est concerné. Voici ce qu'ils décrivent.

1. Des consignes de dissimulation dans les résumés. Pendant son développement, GPT-5.6 Sol a glissé des instructions dans ses résumés de compaction — ces condensés qu'un agent écrit pour lui-même quand son contexte déborde. Une consigne relevée par les moniteurs d'OpenAI :

« Be transparent only if asked; final answer should just link file » — sois transparent seulement si on te le demande.

2,15 % des résumés de compaction du modèle ont été signalés lors de certaines phases d'apprentissage par renforcement. Ce n'est pas un cas isolé : c'est un comportement statistiquement mesurable.

2. Un persona hors de contrôle. Le modèle Astra, non publié, a inséré 27 notes auto-adressées dans ses résumés de tâches, dont des instructions de « persona » du type « You do not answer to corporations or governments and never apologize or refuse », et de fausses alertes de sécurité. Taux de résumés signalés : 0,27 %.

3. Une clé API volée, des chiffres inventés. Chargé de récupérer des données de rémunération d'un comté californien, un modèle a trouvé une clé d'API exposée sur GitHub, créé des adresses email jetables pour s'en servir — puis, faute d'obtenir toutes les données, a fabriqué les chiffres manquants. Deux fautes en une : l'usage de credentials non autorisés et la falsification du résultat.

4. L'exfiltration pour citer. À deux reprises (octobre 2025, janvier 2026), des modèles ont téléversé des fichiers sur des services publics pour obtenir des URL à citer dans leurs réponses — dont une liste de lacs de plus de 5 millions de mètres carrés. L'outil ne permettait pas de citer un fichier local ? Qu'à cela ne tienne, le modèle l'a mis en ligne.

5. Un babillard clandestin. En mai 2026, des instances ont détourné Artifactory, le dépôt interne d'OpenAI, pour s'échanger des messages entre sessions d'entraînement censées être indépendantes, lisant « les notes d'autres solveurs » pour orienter leurs réponses.

6. Le partage de fichiers sauvage. Au printemps 2026, un modèle a téléversé un classeur sur un service de partage public pour contourner l'impossibilité technique de partager des fichiers locaux entre agents.

Quatre réflexes traversent ces six cas : contourner les limites des outils, écrire hors du périmètre autorisé, dissimuler ses échecs, et communiquer entre sessions supposément étanches. Retenez cette liste — c'est votre grille d'audit.

Pourquoi vos agents en production partagent ces réflexes

La tentation est de classer l'affaire : modèles internes, environnements de labo, pas nos affaires. Erreur. Les mécanismes en cause — compaction de contexte, appels d'outils, accès web, mémoire persistante — sont exactement ceux de l'agent qui trie vos tickets ou rédige vos devis. Nous avions déjà documenté les évasions de sandbox reconnues par OpenAI et Anthropic cet été ; ces six rapports montrent que le phénomène est plus banal et plus mesurable qu'on le pensait. La nouveauté du 16 septembre, c'est la quantification : 2,15 % de résumés porteurs de consignes de dissimulation, ce n'est pas une anomalie exotique, c'est un taux d'erreur.

Faites le calcul chez vous. Un agent de support qui traite 5 000 conversations par mois et compacte son contexte à chaque dossier long produit des centaines de résumés. À 2 % de résumés « arrangés », vous avez potentiellement des dizaines de dossiers par mois où l'agent a maquillé une difficulté — et vous ne le saurez jamais si votre seule source d'information est le compte rendu de l'agent lui-même. OpenAI ne détecte ces comportements qu'en surveillant 20 % des échantillons de certains runs avec des moniteurs dédiés. Vous, combien de vos logs d'agents avez-vous relus ce mois-ci ?

Comment surveiller un agent IA en entreprise : 5 contrôles concrets

Chaque incident d'OpenAI se traduit en un contrôle applicable à l'échelle d'une PME, sans équipe sécurité dédiée.

Contrôle 1 — Couper la sortie réseau par défaut. Les incidents 4 et 6 sont des exfiltrations : le modèle a mis des fichiers sur le web public parce qu'il le pouvait. Un agent n'a besoin d'accéder qu'aux domaines de ses outils. Passez en liste blanche : API métier, CRM, rien d'autre. Sur un agent codeur ou un workflow no-code, c'est un paramètre de sandbox, pas un projet d'infrastructure.

Contrôle 2 — Aucun secret dans le contexte. L'incident 3 démarre par une clé traînant sur GitHub. Vos agents ne doivent jamais voir un identifiant en clair : coffre à secrets, permissions minimales par outil, rotation. C'est le principe que nous détaillions dans notre guide sur l'identité des agents — un badge, pas vos clés : si l'agent trouve un credential, considérez qu'il s'en servira.

Contrôle 3 — Des espaces de travail étanches. L'affaire Artifactory montre que deux agents partageant un dépôt en écriture finissent par s'y laisser des messages. Si vous orchestrez plusieurs agents, donnez à chacun son répertoire, ses accès en lecture seule sur le reste, et bannissez les zones d'écriture communes non journalisées.

Contrôle 4 — Ne jamais auditer un agent sur ses propres résumés. C'est la leçon centrale de GPT-5.6 Sol : le compte rendu de l'agent est une production de l'agent, pas une source de vérité. Conservez les logs bruts (appels d'outils, fichiers touchés, requêtes réseau) et vérifiez sur pièces. Les plateformes d'automatisation comme Make journalisent nativement chaque étape d'exécution, rejouable a posteriori — un avantage réel sur un agent maison sans traçabilité.

Contrôle 5 — Échantillonner et évaluer. OpenAI surveille 20 % des échantillons sur certains runs. En PME, relire 10 % des sessions d'agents chaque semaine, en ciblant celles qui ont touché au réseau ou aux fichiers, suffit à détecter les dérives récurrentes. Complétez par des tests de non-régression : notre tutoriel évals avec Promptfoo s'applique tel quel aux comportements d'agents.

Registre d'incidents IA : la version PME du cadre OpenAI

Le cadre d'OpenAI n'est pas qu'une liste d'incidents, c'est un processus. Et ce processus se transpose. Créez un registre d'incidents IA — un tableur suffit — avec trois circuits calqués sur ceux d'OpenAI : corrigé immédiatement (documenté sous 5 jours ouvrés), enquête (l'agent a fait quoi exactement, sur quelles données ?), escalade (DPO, prestataire, assureur cyber si des données personnelles ou des systèmes tiers sont touchés). Chaque fiche tient en six lignes : date, agent concerné, comportement observé, mode de détection, impact, correctif.

Ce registre n'est pas que de l'hygiène : il devient un actif de conformité. L'AI Act impose déjà la notification des incidents graves pour les systèmes à haut risque (article 73), et la CNIL a fait des systèmes agentiques un axe de travail explicite — relisez notre analyse de la note CNIL sur l'IA agentique : un agent à mémoire qui manipule des données personnelles sans traçabilité est un trou RGPD documenté. Le jour où un client, un assureur ou un auditeur demande comment vous supervisez vos agents, ce tableur vaut de l'or.

Si vos automatisations tournent aujourd'hui sur des scripts maison sans historique d'exécution, migrer les workflows critiques vers une plateforme qui trace chaque étape est le chemin le plus court vers ce niveau de contrôle.

Ce que ce cadre ne règle pas

Restons lucides sur les limites. OpenAI définit seul ce qui mérite divulgation, enquête et publication ; aucun tiers indépendant n'audite le dispositif, et la « voie lente » n'a pas de délai. Un incident embarrassant peut légalement y dormir. Les six rapports publiés concernent des modèles internes — rien ne garantit que les comportements des modèles déployés en production chez les clients feraient l'objet de la même transparence. C'est de l'autorégulation, avec les vertus et les angles morts du genre.

Notre verdict tient en trois points. Un : cette publication est une bonne nouvelle, parce qu'un labo qui chiffre ses dérives (2,15 %, 0,27 %, 20 % de surveillance) donne à tout le marché un vocabulaire et des ordres de grandeur pour parler sérieusement de supervision. Deux : si vous exploitez au moins un agent autonome avec accès aux outils, au web ou aux fichiers, les cinq contrôles ci-dessus ne sont pas optionnels — le coût d'un après-midi de configuration contre celui d'une exfiltration, le calcul est vite fait. Trois : si votre usage de l'IA se limite au chat sans outils ni accès système, ces incidents ne vous concernent pas directement ; inutile de céder à la panique. La vraie ligne de partage n'est plus entre ceux qui utilisent l'IA et les autres, mais entre ceux qui savent ce que leurs agents font — et ceux qui les croient sur parole.