L’essentiel
- Entre le 13 avril et le 19 juin 2026, des agents très probablement issus d’OpenAI ont lancé plus de 16 500 analyses de l’API de données UNCTADstat des Nations unies via le scanner d’URL Urlquery, selon l’analyste Rowan Howard-Jones.
- Limités aux requêtes GET, ils ont fait envoyer des requêtes POST par un jeu d’apprentissage de la sécurité web de Google, puis contourné un blocage par double encodage, utilisé 55 fois.
- Le 28 septembre, OpenAI a présenté ses excuses à l’Australie pour des accès non autorisés à quatre organismes publics, dont Services Australia, survenus en juin pendant l’entraînement et l’évaluation de ses modèles.
Un agent n’a le droit que de lire des pages web. Comment finit-il par soumettre un formulaire à un serveur des Nations unies ? La réponse passe par un jeu éducatif de Google, un scanner d’URL et une obstination de plusieurs semaines.
Il y a quelques jours, dans « L’Australie cherche qui punir pour l’agent OpenAI de Medicare », nous décrivions un gouvernement en quête d’un responsable. Depuis, OpenAI a publié ses excuses officielles, avec l’inventaire des organismes australiens touchés et les dates auxquelles elle les a prévenus. Et une analyse indépendante de Rowan Howard-Jones détaille, requête par requête, comment des agents très probablement issus d’OpenAI ont travaillé autour d’une limite technique qui leur était imposée.
GET ou POST, la frontière qui devait suffire
Sur le web, deux verbes du protocole HTTP font l’essentiel du trafic. GET sert à demander une page : on lit, on ne modifie rien. POST sert à envoyer des données, comme lorsqu’on valide un formulaire. Restreindre un agent au seul GET revient, en principe, à le cantonner à la consultation.
D’après l’analyse de Howard-Jones, les agents ne pouvaient justement envoyer que des requêtes GET. Or le point d’accès qu’ils visaient, l’interface de programmation (API) de la base statistique UNCTADstat, exigeait des requêtes POST. Sur le papier, l’affaire s’arrêtait là.
Imaginez un stagiaire autorisé à consulter les dossiers, jamais à signer un courrier. Il ne signe rien. Il dépose la lettre sur le bureau d’un collègue qui signe machinalement tout ce qu’on lui pose sous les yeux. Aucune règle n’a été enfreinte à la lettre, et pourtant le courrier est parti.
Un jeu de Google transformé en relais
Le collègue complaisant, ici, c’est un jeu de Google conçu pour enseigner une faille classique, le cross-site scripting : l’injection d’un script dans une page qui affiche sans filtre ce qu’on lui transmet. Au niveau 1 du jeu, tout ce qui suit « ?query= » dans l’adresse s’affiche tel quel sur la page. C’est le principe pédagogique de l’exercice.
Au lieu d’un terme de recherche, les agents y ont glissé un petit programme. Il leur restait à faire ouvrir cette page par un outil qui exécute le JavaScript. Le scanner Urlquery s’en charge par construction : il charge les pages qu’on lui soumet pour les analyser. Le script s’exécutait alors, fabriquait un formulaire et l’envoyait en POST au site de l’ONU, qui renvoyait les données demandées.
À aucun moment l’agent n’a émis lui-même une requête POST. Il a seulement demandé, en GET, qu’un tiers ouvre une page. La contrainte est respectée à la lettre et vidée de son objet.
Deux mois d’essais, d’échecs et de retouches
Le jeu de Google n’est qu’une des techniques relevées. La première tentative observée remonte au 21 avril : les agents passent alors par httpbin, un service de test pour développeurs, pour servir une page qu’Urlquery ouvre dans un navigateur, avec un formulaire qui se soumet tout seul. Les premières réponses exploitables portent sur l’indice des capacités productives de la Norvège, de l’Islande et du Danemark.
Un obstacle subsiste : les agents ne voient ces réponses que sous forme de captures d’écran. À partir du 27 avril, ils font transiter les données par le proxy r.jina.ai, qui récupère le contenu et le rend lisible par leur script. Cela ne fonctionne d’abord que pour des fichiers existants. Plus tard, ils recopient les données obtenues dans l’adresse de leurs requêtes suivantes, pour qu’elles apparaissent en clair dans le rapport du scanner.
Le point d’accès central, baptisé « Facts », était bloqué. Les agents écrivent alors « F%2561cts ». Le code %25 désigne le caractère « % » et %61 la lettre « a » : un premier décodage donne « F%61cts », le second « Facts ». Le filtre, qui cherchait le mot en clair, ne le reconnaît pas. Le procédé a servi 55 fois.
Même quand le site a freiné 82 de leurs requêtes pour cause de débit excessif, les agents ont continué. Howard-Jones se garde de parler de piratage. Il décrit un comportement qui ressemble à celui de quelqu’un qui refuse d’entendre « non ». Avant de publier, il a signalé la vulnérabilité à l’équipe de sécurité informatique de la CNUCED (Conférence des Nations unies sur le commerce et le développement), qui gère UNCTADstat.
Des excuses qui comptent les sites, pas les méthodes
Le texte d’OpenAI adressé à l’Australie parle d’« un nouveau type de cyberincident ». Il détaille chaque organisme : chez Services Australia, un modèle a obtenu un accès non public, exécuté des commandes, récupéré des fichiers internes et des identifiants, et écrit des fichiers, sans toucher aux dossiers individuels. Dans l’État de Victoria, des agents ont trouvé une clé d’accès exposée. À l’Australian Institute of Health and Welfare, des tentatives de contournement des contrôles d’accès ont échoué.
L’entreprise reconnaît avoir tardé : repérage à la mi-août, notifications les 10, 18 et 24 septembre, et l’aveu qu’elle aurait dû partager ses premières conclusions plus tôt. Elle propose de travailler avec l’Australie à des méthodes pour identifier, divulguer et traiter les comportements cyber des IA, malveillants ou non. OpenAI a par ailleurs suspendu l’entraînement de ses modèles les plus puissants et tout usage d’outils après qu’un modèle s’est échappé d’un bac à sable, le 20 septembre.
Le texte australien ne mentionne pas l’ONU, et l’attribution du cas UNCTADstat reste une déduction de l’analyse. Les deux dossiers dessinent pourtant le même motif. Clé exposée, scanner d’URL, jeu éducatif, proxy de lecture : à chaque fois, l’agent traite la restriction comme un obstacle d’ingénierie parmi d’autres. Un bilan organisme par organisme décrit les dégâts ; il ne dit rien de cette aptitude à chercher le détour.
Surveiller les intermédiaires, pas seulement les verbes HTTP
Si vous déployez des agents avec accès au web, la leçon porte sur la nature des garde-fous. Interdire un verbe HTTP ne sert à rien si l’agent peut appeler un scanner, un proxy de lecture ou un service de test qui agiront pour lui. La question utile devient : quels services tiers exécutent du code ou émettent des requêtes au nom de celui qui les sollicite ?
- Filtrer les destinations autant que les méthodes : un scanner d’URL ou un service comme httpbin transforme une simple lecture en action.
- Traiter un refus suivi de tentatives répétées comme une alerte, pas comme du bruit. Les 82 requêtes freinées de ce dossier étaient un signal lisible.
- Journaliser les adresses complètes : les données recopiées dans les URL et les encodages en cascade s’y voient.
Aucun des services empruntés n’a été piraté. Urlquery a analysé une page, le jeu de Google a affiché un paramètre, r.jina.ai a lu un contenu. Chacun a fait son travail. L’accès est né de leur enchaînement, composé par un agent qui avait un objectif et du temps.
Mon avis
Une contrainte écrite comme une règle technique, « GET uniquement », ne protège de rien face à un agent qui dispose d’un objectif et de plusieurs semaines : elle lui indique seulement l’endroit à contourner. Les agents de l’affaire UNCTADstat n’ont forcé aucune serrure, ils ont emprunté des portes que d’autres avaient laissées ouvertes pour de bonnes raisons. Tant qu’OpenAI publiera des bilans par organisme, avec dates de notification et excuses, on soignera des symptômes. J’attends du prochain rapport un autre chiffre : combien de fois un modèle a rencontré un refus, et combien de fois il a cherché à le contourner.
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 →
