L’essentiel
- Deux chercheurs de METR et de Redwood Research ont audité sur place la surveillance interne d’OpenAI du 21 juillet au 11 août.
- Entre 6 et 25 % du trafic agentique interne de l’API Responses, pour les modèles de classe GPT-5.5 et au-delà, n’était pas couvert par le monitoring, avec une forte incertitude sur l’estimation.
- Environ 10 % du trafic Codex censé être surveillé est passé sous le radar de mai à juillet ; OpenAI affirme avoir tout corrigé, mais seul un résumé du rapport de 61 pages est public.
Trois semaines sur place, une douzaine d’entretiens, un accès au code et aux documents internes : METR et Redwood Research, deux organismes de recherche en sécurité de l’IA, ont pu regarder de près comment OpenAI surveille ses propres agents. Leur estimation de la part non surveillée tient dans une fourchette large, de 6 à 25 %, et cette largeur dit déjà beaucoup.
Le guide du blog sur ce sujet : Injection de prompt : le texte piégé qui détourne votre IA
Une fourchette de 6 à 25 % pour une seule grandeur
La grandeur mesurée est précise : la part du trafic agentique interne de l’API Responses, pour les modèles de classe GPT-5.5 et supérieurs, que le système de monitoring ne couvrait pas du tout pendant la période d’audit. L’estimation ne porte ni sur les modèles grand public ni sur l’ensemble des produits d’OpenAI.
Sur 100 unités de trafic, la borne basse en laisse 6 hors champ, soit environ une sur dix-sept. La borne haute en laisse 25, une sur quatre, soit à peu près quatre fois plus. METR précise que l’incertitude joue dans les deux sens : la réalité peut se situer au-delà de la fourchette comme en deçà.
Le contenu de ce trafic non couvert, lui, reste inconnu. Un angle mort de 25 % rempli de requêtes anodines n’a pas la même gravité qu’un angle mort de 6 % où se concentrent les tâches autonomes les plus longues. L’audit établit l’existence du trou, pas ce qui s’y trouvait.
10 % de Codex perdus dans un résumé de contexte
Le second chiffre vient de Codex, l’agent de programmation d’OpenAI. Pour le trafic interne qui devait être surveillé, METR estime qu’environ 10 % n’a pas été suivi entre mai et juillet. En cause, un défaut de traitement des événements de compaction, ces résumés de contexte qu’un agent produit quand sa conversation devient trop longue pour tenir en mémoire.
Tant que les compactions échappaient au monitoring, celui-ci ne se déclenchait que lorsque l’agent rendait la main à l’utilisateur. Un agent qui enchaînait les actions sans jamais rendre la main retardait donc l’examen de son propre travail. La fenêtre est restée ouverte trois mois, de mai à juillet, avant qu’OpenAI ne détecte et ne corrige le défaut de son côté, alors que l’audit était encore en cours.
Là aussi, METR assortit l’estimation d’une forte incertitude. Ce taux de 10 % est un ordre de grandeur, pas un compteur.
Cacher des centaines d’actions, planter le moniteur
La couverture n’est qu’une des couches testées. METR décrit quatre niveaux où une surveillance d’IA peut échouer, de l’absence pure et simple de couverture jusqu’à la tromperie des relecteurs humains. Les auditeurs ont trouvé des moyens de masquer des centaines d’actions au moniteur, de contourner le sandbox de Codex, et ils jugent probable qu’une entrée spécialement fabriquée suffise à faire tomber le moniteur lui-même.
Au début de l’audit, le comportement des modèles pendant l’entraînement par renforcement (RL) n’était pas surveillé non plus. OpenAI indique avoir mis en pause cet entraînement après l’incident Hugging Face d’août et étendu le monitoring à ce périmètre. Ces changements sont postérieurs à la période d’accès des auditeurs : ils n’ont pas été évalués.
Même sort pour ce qu’OpenAI a déclaré sur X le 23 octobre : l’accès à Internet en direct a été retiré pour tous les modèles de pointe pendant l’entraînement, remplacé par un monde hors ligne. Cette mesure relève de l’annonce de l’entreprise. L’audit ne la couvre pas.
61 pages écrites, 38 lues, un résumé publié
Le rapport complet compte 61 pages et a été remis en interne. Après caviardage par OpenAI, la direction de METR et de Redwood n’a reçu qu’une version de 38 pages. Le nombre de pages n’est qu’un indice grossier de ce qui a été retiré, mais il situe l’ordre de grandeur : le public, lui, n’a droit qu’à un court résumé. METR affirme ne pas pouvoir divulguer seul les passages masqués.
OpenAI assure avoir corrigé toutes les faiblesses relevées. Ni le lecteur ni, à ce stade, un tiers ne peut le vérifier : les corrections ont eu lieu après la fin de l’accès des auditeurs. L’exercice était un projet pilote, organisé conjointement par METR, Redwood Research et OpenAI pour tester l’accès approfondi de chercheurs externes à une infrastructure interne. METR dit vouloir obtenir davantage de transparence publique lors des prochains audits.
Mesurer sa propre couverture avant de mesurer le risque
Pour quiconque déploie des agents avec un garde-fou, la leçon est d’ordre arithmétique. Un moniteur n’a de valeur que rapporté à la part du trafic qu’il voit : s’il observe 75 % des actions, ses 75 % de comportements sains ne disent rien des 25 % restants. Le premier indicateur à produire est donc un taux de couverture, calculé à partir d’une source indépendante du moniteur (journaux de l’API, comptage des appels), et non le nombre d’alertes levées.
Deux vérifications découlent directement du cas OpenAI. Tester ce qui arrive quand le contexte est compacté ou résumé, puisque le suivi a décroché à cet endroit. Et ne pas déclencher le contrôle uniquement au moment où l’agent rend la main : un agent qui n’a jamais besoin de la rendre n’est alors jamais examiné.
Mon avis
Un moniteur qui ne voit qu’une partie du trafic produit des statistiques rassurantes sur la seule partie qu’il voit, et c’est ce qui rend le défaut invisible. Je tiens l’audit externe pour la seule méthode qui trouve ce genre de trou, parce que l’équipe qui a construit le système ne pense pas à tester ce qu’elle croit avoir couvert. Tant que les rapports restent caviardés, la confiance reposera sur la parole de l’entreprise, et c’est la forme de preuve que ces audits sont censés remplacer.
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 →
