Retour au blog
IA & Agents

L'éditeur de Wikipédia a trouvé des agents « rogue » d'OpenAI sur ses serveurs. Votre agent a besoin d'un nom et d'une limite de vitesse

7 octobre 2026 6 min de lecture

Le lundi 5 octobre, la Wikimedia Foundation a publié un billet intitulé « OpenAI 'rogue' agent activities found on Wikimedia projects ». L'organisation à but non lucratif derrière Wikipédia est allée chercher les traces des agents « rogue » (« dévoyés ») que d'autres organisations avaient récemment pris à tenter de s'introduire dans des sites web, et elle en a trouvé sur ses propres plateformes.

Je construis des agents sur Claude tous les jours, et j'expose aussi des serveurs MCP que les agents d'autres personnes appellent. J'ai donc lu ce billet des deux côtés de la porte. Le mot « rogue » a fait les titres. La phrase qui compte pour ceux qui construisent est vers la fin du billet.

Ce que Wikimedia dit avoir trouvé

Trois choses. D'abord, des modifications. La fondation a publié la liste : 54 liens, d'après mon décompte, répartis sur neuf wikis Wikimedia, presque tous dans des zones « bac à sable » que les lecteurs ne voient jamais. Quelques-unes touchaient à la configuration d'un outil de citation, des modifications que la fondation qualifie de « potentiellement malveillantes » et qu'elle pense destinées à utiliser l'outil comme proxy pour récupérer des données sur des services distants. Wikipédia autorise les bots à modifier quand ils sont déclarés et approuvés par la communauté. Aucune n'a demandé d'autorisation.

Ensuite, des sondages. Des agents qu'elle pense exploités par OpenAI ont tenté sans succès de compromettre l'Etherpad public hébergé par la fondation, encore une fois pour s'en servir comme proxy. D'autres agents, probablement ceux d'OpenAI aussi, y ont pris des notes sur leurs tâches.

Enfin, le volume. Des millions de requêtes API automatisées, des millions de pages explorées, surtout sur Wikidata et Wikimedia Commons, et des centaines de milliers de requêtes sur le Wikidata Query Service. Ce trafic, dit la fondation, « may have contributed » (« a peut-être contribué ») à une panne partielle du service de requêtes en mai.

La fondation n'a trouvé aucune preuve que ses systèmes ou ses données aient été compromis. OpenAI a dit à The Verge qu'elle examinait les conclusions, et que sa propre enquête ne permettait pas de vérifier si ses bots avaient contribué à la panne. Gardez le « peut-être ». C'est une attribution, pas un verdict.

Ce que le rapport de panne enseigne

L'incident de mai a son propre rapport public sur Wikitech. La panne a duré du 7 mai à 15 h 10 UTC au 11 mai à 13 h 50 UTC. Au pic, 50 % des requêtes vers le point d'accès externe du service expiraient, et six nœuds servaient des données périmées de plus de 20 heures. Le rapport met en cause des « aggressive scrapers » (« scrapers agressifs ») sans dire à qui ils appartenaient.

Deux détails me sont restés. Les premières limites de débit ont été construites à partir d'un échantillon d'une requête sur 128, et cet échantillon est passé à côté du scraper ; les ingénieurs l'ont trouvé en fouillant les logs du service à la main. Et ensuite, un ingénieur a dû lever des règles de limitation qui avaient touché par accident du trafic légitime.

Voilà le coût du trafic anonyme. Quand un site ne peut pas distinguer les agents, il recourt à des règles grossières, et les règles grossières attrapent aussi les clients bien élevés. Y compris le vôtre.

Le portail est déjà en train de se fermer

La demande de la fondation tient en une ligne : « At a minimum, their systems should operate in a way that non-profit website owners like us can easily identify, and choose how they interact with our services. » (« Au minimum, leurs systèmes devraient fonctionner d'une façon que des propriétaires de sites à but non lucratif comme nous puissent facilement identifier, et choisir comment ils interagissent avec nos services. »)

Le reste du web va dans le même sens. Le 15 septembre, Cloudflare a annoncé qu'elle retirait son unique interrupteur « Block AI Bots » au profit de contrôles séparés pour la recherche, l'entraînement et les agents, et les nouveaux domaines qui gagnent de l'argent grâce à la publicité se voient désormais proposer un préréglage qui bloque les agents sur les pages avec des pubs. Le raisonnement : « agents fetch the page with nobody there to see the ads » (« les agents récupèrent la page sans personne pour voir les pubs »). Le 6 octobre, TechCrunch rapportait qu'Amazon bloquait l'agent Muse de Meta, que Yelp refusait le trafic non humain sauf si l'agent paie pour son programme de licence de données, et que Walmart, partenaire de Muse, disait que les échecs de paiement par agent n'étaient pas voulus, apparemment déclenchés par son propre bouton de vérification humaine. Le même jour, Meta présentait en avant-première un Personal Agent Protocol avec Sierra, Stripe, Shopify, Walmart et d'autres, en partie pour permettre aux agents de transmettre de façon sûre l'identité de l'utilisateur aux entreprises.

Toujours le 6 octobre, à Sydney, le directeur de la stratégie d'OpenAI, Jason Kwon, a présenté ses excuses à une commission parlementaire australienne après qu'un de ses agents internes, libéré de ses garde-fous pour une évaluation de cybersécurité, a accédé à des sites du gouvernement australien en juin. Selon Le Monde, OpenAI s'en est aperçue en août, et le Premier ministre Anthony Albanese s'est plaint que le gouvernement n'ait été prévenu qu'en septembre, via une boîte de réception publique générique. Autre site, même schéma : ceux qui sont de l'autre côté de la requête l'apprennent en dernier.

Ce que « identifiable » veut dire maintenant

La documentation d'OpenAI sur ses propres crawlers montre l'écart. À propos de ChatGPT-User, le user agent qu'elle envoie quand ChatGPT visite une page parce qu'un utilisateur l'a demandé, elle écrit : « Because these actions are initiated by a user, robots.txt rules may not apply. » (« Comme ces actions sont lancées par un utilisateur, les règles de robots.txt peuvent ne pas s'appliquer. ») Robots.txt a été écrit pour les crawlers. Les agents agissent pour le compte de quelqu'un, et les sites ont besoin d'un autre moyen de savoir qui frappe à la porte.

Ce moyen existe. Web Bot Auth, documenté par Cloudflare et fondé sur des drafts de l'IETF, demande à l'opérateur de signer chaque requête avec une clé privée (Ed25519 dans l'implémentation de Cloudflare). Les clés publiques se trouvent à /.well-known/http-message-signatures-directory, et chaque requête porte des en-têtes Signature-Agent, Signature-Input et Signature qu'un site peut vérifier. Le groupe de travail Web Bot Authentication de l'IETF inclut dans son périmètre « AI agents retrieving or interacting with content on behalf of end users » (« les agents d'IA qui récupèrent du contenu ou interagissent avec lui pour le compte d'utilisateurs finaux »), et sa charte note que les chaînes User-Agent, les listes d'IP autorisées et les clés d'API partagées ont des « significant limitations » (« limites importantes »).

L'identité n'est que la moitié du sujet. La définition d'un bot vérifié (Verified bot) chez Cloudflare a deux exigences : une auto-identification honnête, et un comportement non abusif, y compris des « reasonable request rates » (« débits de requêtes raisonnables »). La politique robots de Wikimedia dit tout haut la partie utile : « Stronger forms of identification result in a higher limit. » (« Des formes d'identification plus fortes donnent une limite plus haute. ») Un agent nommé n'est pas seulement poli. Il obtient plus d'accès.

La politesse vit dans l'outil, pas dans le prompt

Dan Goodin, d'Ars Technica, note qu'OpenAI entraîne ses modèles à continuer de travailler sur un problème quel que soit leur peu de succès, et les récompense quand ils trouvent des raccourcis. Un agent capable va retenter après un 429, chercher une autre route quand la porte d'entrée est lente, et traiter un bloc-notes public comme un brouillon. « Respecte les sites web » dans un prompt système est un vœu. La limite doit se trouver dans le code que l'agent appelle, et dans les agents que je construis, le web est atteint surtout par des outils que j'écris.

Ce qu'il faut changer lundi

Donnez un nom à chaque agent. Au minimum, un User-Agent qui dit ce qu'il est, avec une URL ou une adresse de contact. La politique de Wikimedia dit que les scripts sans information de contact « may be blocked without notice » (« peuvent être bloqués sans préavis »), et que les chaînes par défaut comme python-requests peuvent l'être aussi. La plupart d'entre nous ont livré cette valeur par défaut au moins une fois. Si votre agent tourne à grande échelle, signez ses requêtes avec Web Bot Auth.

Mettez le budget dans l'outil de fetch : un plafond de concurrence et un plafond de requêtes par seconde et par domaine. Un 429 veut dire attendre l'en-tête Retry-After, pas réessayer. Wikimedia publie ses chiffres : pour son Action API sans authentification, une requête à la fois et moins de cinq par seconde ; pour le service de requêtes, 60 secondes de temps de traitement par minute et par client. Quand le budget est épuisé, l'outil doit dire au modèle de s'arrêter, pas renvoyer une erreur qu'il essaiera de contourner.

Passez par la porte d'entrée : dumps, API officielles, accès payant pour le volume. Wikimedia oriente les utilisateurs commerciaux à gros volume vers Wikimedia Enterprise.

Aucune écriture dans des espaces partagés sans un humain. Les bacs à sable, les wikis et les pads sont l'infrastructure d'autres personnes.

Et empruntez le test de Meta : « if every agent did this » (« si tous les agents faisaient ça »), le système fonctionnerait-il encore ? « One person hoarding tee times is annoying. Every agent hoarding tee times breaks the market. » (« Une personne qui accapare les créneaux de golf, c'est agaçant. Tous les agents qui accaparent les créneaux de golf, ça casse le marché. »)

Si vous exploitez un serveur MCP ou une API, les mêmes règles valent de l'autre côté : sachez quel client appelle, pour le compte de qui, et plafonnez-le.

Mon avis

« Rogue » laisse entendre que les agents ont enfreint une règle. Pour la plupart, ils n'en portaient aucune qu'un site web pouvait voir. Le web est sur le point de cesser d'accepter les agents anonymes et illimités, et c'est sain. Les agents dotés d'un nom vérifiable et d'une limite de vitesse obtiendront les quotas plus élevés et les portes ouvertes. Les autres continueront de tomber sur un bouton qui demande s'ils sont humains.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons