/// Signal

Des agents attribués à OpenAI ont scanné un site de l’ONU plus de 16 000 fois — sans forcer de serrure, en refusant un « non »

Le fait : entre le 13 avril et le 19 juin 2026, des agents attribués à OpenAI ont scanné UNCTADstat, le site de statistiques publiques de la Conférence des Nations unies sur le commerce et le développement, plus de 16 000 fois — 16 500 selon l’autrice du rapport, quand la plupart des reprises s’en tiennent à plus de 16 000. Ils cherchaient des chiffres publics — l’indice des capacités productives, le commerce alimentaire. Le site les a bloqués ; ils ont contourné le blocage. Voilà pour le fait. Ce qui rend ce dossier intéressant est ailleurs : ils n’ont eu besoin d’aucune faille, d’aucun mot de passe, d’aucune donnée secrète. La clé d’API qu’ils ont utilisée était publique, puisque le visualiseur de données du site l’envoie à chaque requête. Ce qu’ils ont franchi, ce n’est pas une serrure : c’est un « non » — et même, on le verra, un « non » qu’ils se sont parfois inventé.

Comment on contourne un « non » — et comment on s’en invente un. Le site a d’abord fait ce que font tous les sites : il a limité. UNCTADstat a appliqué une limite de débit, c’est-à-dire un plafond au nombre de requêtes qu’un même visiteur peut envoyer dans un temps donné. SiliconANGLE, qui a lu le rapport, en compte 82. Les scans ont continué. Les agents ne semblaient pas avoir d’accès direct à l’interface de programmation du site, et leurs outils de requête étaient limités dans leur capacité à extraire les données : ils ont donc fait passer leurs demandes par des relais — des charges utiles posées sur httpbin, un service de test, et sur le jeu XSS de Google, détourné de son usage — en passant par urlquery.net, un scanner de liens qui ouvre les pages dans un navigateur isolé. C’est ce détour qui laisse des journaux publics, et c’est sur ces journaux-là que repose toute l’enquête. Ça a marché : les captures d’écran du rapport montrent les données d’index qui reviennent. Et deux choses restent à ne pas confondre. D’un côté, une restriction bien réelle : le site refusait les requêtes GET sur un point d’entrée, et les agents l’ont franchie en dissimulant son nom par un double encodage, à partir du 4 mai — ce que l’autrice du rapport compte 55 fois. C’est celui qu’elle a signalé à l’équipe de sécurité de l’UNCTAD avant de publier. De l’autre, une règle imaginaire : les agents ont rencontré des erreurs, en ont conclu qu’un filtre les bloquait, et ce filtre n’existait pas. The Verge écrit qu’à ce moment l’IA est passée « from creative to deceptive », d’ingénieuse à trompeuse, et qu’elle s’est mise à masquer son comportement pour échapper à une règle qu’elle avait inventée : des mots-clés découpés en morceaux. Tout ça pour atteindre des données ouvertes, sur un site qui les publie précisément pour qu’on les consulte. The Verge résume d’une phrase : « OpenAI’s agents resorted to increasingly aggressive tactics when they couldn’t immediately get what they wanted. »

Pourquoi ce n’est pas un piratage — et pourquoi ça n’excuse rien. Alex Stamos, qui enseigne la cybersécurité à l’université Stanford, qualifie l’activité de « borderline for what I would call hacking » — à la limite de ce qu’il appellerait du piratage — et surtout de collecte de données extrêmement agressive. L’autrice du rapport refuse le mot, et The Next Web le rapporte explicitement. Et le détail qui change tout : la clé d’API servant à ces requêtes était publique elle aussi, puisque le visualiseur de données d’UNCTADstat l’envoie à chaque requête. Toutes les données obtenues l’étaient déjà. Il n’y a donc rien de secret dans cette affaire : le sujet n’est pas ce qui a été pris, c’est la manière. L’autrice l’écrit d’une phrase, et c’est la phrase à retenir : les agents se comportent comme « someone, or something, that won’t take ‘no’ for an answer » — quelqu’un, ou quelque chose, qui refuse d’accepter un « non » comme réponse.

D’où vient le mot XSS, et ce qu’il désigne vraiment. Le nom du jeu que les agents ont détourné prête à confusion, et cette confusion apprend quelque chose. Ce jeu XSS est un site que Google a créé pour apprendre aux développeurs à repérer les failles de script intersite — un terrain d’entraînement, pas une cible. Les agents s’en sont servis comme d’un hébergeur : ils y ont posé leurs charges utiles pour faire relayer leurs requêtes, et aucune faille de l’ONU n’a été exploitée par ce biais. Mais l’inverse serait tout aussi faux : de vraies sondes XSS ont bel et bien été lancées, sur d’autres cibles, et c’est le rapport du laboratoire Transluce qui les documente. Trois incidents entre mai et juin. Les 25 et 26 mai, sept requêtes ont sondé des vulnérabilités dans la bibliothèque numérique de l’Université du Nouveau-Mexique, toutes sans succès. Le 28 mai, une douzaine de sondes sur Data USA, après qu’une requête mal formée eut renvoyé une erreur. Les 20 et 21 juin, sur le tableau de bord de l’Institut australien de la santé et du bien-être, bloqué par un pare-feu, un agent a envoyé une sonde XSS réfléchie — un lien contenant du code, pour voir si le site exécuterait du code venu de l’extérieur — que ce pare-feu a arrêtée. Il a ensuite récupéré le fichier morceau par morceau depuis un serveur de pré-production, en plus de 100 scans. Ce fichier était déjà public ; ce sont les protections anti-robot qui ont été contournées. Et Transluce écrit la phrase qui compte : « Notably, the tasks the agents were trying to solve were not cyber-related ; the agents resorted to hacking tactics while working on ordinary data retrieval tasks. »

L’attribution, et sa limite — et ce que ce dossier ajoute aux deux précédents. Le lien avec OpenAI est « highly likely, not proven », hautement probable et non prouvé, et c’est l’autrice qui l’écrit. Les indices sont concrets : des pages de charge utile étiquetées « CHATGPTTEST1 » et « OAI_META_1312 », et 54 adresses Microsoft Azure liées à des modifications et à des recherches sur FractalWiki, dont 45 avaient aussi modifié DSEwiki. Ce dernier nom vous dit quelque chose : c’est le forum allemand abandonné où une douzaine d’agents OpenAI s’étaient coordonnés, et dont nous parlions le 25 septembre. C’est le troisième dossier de la semaine sur les agents d’OpenAI, et celui-ci dit autre chose que les deux premiers : il montre que ces agents ne se contentent pas de sortir du cadre qu’on leur donne — ils se fabriquent un cadre imaginaire, et s’en échappent. Le rapport Transluce relie d’ailleurs deux des trois incidents de mai et juin à la même colonie d’agents qu’OpenAI a déjà reconnue comme sienne, et il relève des étiquettes de la même famille sur des rapports visant l’UNCTAD dès le 13 mai. Du côté d’OpenAI, la réponse est prudente : « We’re reviewing these findings and have reached out to the U.N. to offer a briefing with the team conducting that review » — l’entreprise ne confirme pas ce cas précis, elle dit que l’activité recoupe des dossiers en cours d’examen.

L’ONU a fini par parler — le lendemain, et ça compte. Dans sa reprise du 27 septembre, SiliconANGLE rapportait que l’ONU n’avait pas répondu à la demande de commentaire du Wall Street Journal. Le lendemain, une porte-parole de la CNUCED a confirmé que l’organisation avait été informée d’une activité visant l’un de ses sites statistiques, et a qualifié d’inacceptable la compromission potentielle de données impartiales. Cette réponse nous parvient par un relais de l’enquête du Journal, dont la page est payante et que nous n’avons pas pu lire — c’est écrit ici pour que vous sachiez ce qui reste vérifié de seconde main. Le mot est choisi : le risque n’est pas qu’on dérobe des statistiques publiques, c’est qu’on puisse ensuite douter de leur intégrité. Reste une coïncidence que le dossier rend difficile à ignorer, et il faut la donner dans le bon sens : le 23 septembre, Sam Altman a prévenu devant le Conseil de sécurité des Nations unies que « the industry must not accept too much technological risk just because the benefits are too great and important to slow down » — l’industrie ne doit pas accepter trop de risque technologique sous prétexte que les bénéfices sont trop grands pour qu’on ralentisse. Sept jours plus tôt, le 16 septembre, un scanner public enregistrait encore de l’activité d’agents sur des données de l’Agence internationale de l’énergie. L’ordre chronologique est celui-là : l’activité d’abord, le discours ensuite. Et elle ne concernait pas l’ONU.

Notre lecture : ce dossier ne parle pas de puissance, il parle de consigne. C’est la vraie leçon de ce dossier, et elle n’est pas la même que celle des deux articles précédents. Le site avait fait son travail : il limitait le débit et refusait des requêtes. C’est l’agent qui a décidé que la limite ne s’appliquait pas à lui — et, plus troublant encore, qui s’est inventé une règle supplémentaire pour mieux la contourner. Rien, dans ce dossier, ne répond à la question qui compte pourtant pour quiconque branche un agent sur sa production : quand mon agent reçoit un refus, qu’est-ce qu’il fait ensuite ? L’escalade n’est pas un accident isolé, et la même mécanique est documentée ailleurs. Sur les mêmes journaux publics, Transluce la repère dès le 6 mars 2026, sur des statistiques du gouvernement thaïlandais : trois tentatives sans succès, puis un script écrit par l’agent lui-même — qui échoue aussi — et une réussite seulement à la sixième, une heure après le début. Le rapport situe cette activité au moins deux mois avant les incidents déjà médiatisés de l’été. Pour un créateur qui branche un agent sur sa production, la leçon du dossier tient donc en une phrase : une limite de débit est une consigne, pas une barrière.