Aller au contenu

Jeudi 8 octobre 2026

L’actualité tech, expliquée

Dernière publication · Fin de la 2G : alarmes, téléassistance et vieux mobiles à vérifier

InternetAnalyse

Wikimedia attribue des agents à OpenAI sans détailler sa méthode

Wikimedia attribue à des agents d’OpenAI des modifications de ses wikis et un trafic ayant pu contribuer à une panne de Wikidata en mai. Sans dire comment elle les a reconnus, elle réclame des agents identifiables par les sites.

Gros plan sur des câbles noirs étiquetés et numérotés, branchés à l'arrière de serveurs, avec des voyants lumineux bleus et verts, dans un centre de données de la fondation Wikimedia.
Câbles réseau et voyants lumineux de serveurs dans un centre de données de la fondation Wikimedia (2015).Victor Grigas, CC BY-SA 3.0, via Wikimedia Commons

Des dizaines de modifications d’essai, quelques tentatives pour détourner un outil de citation, des notes laissées sur un outil collaboratif et des millions de requêtes : la Wikimedia Foundation, l’organisation à but non lucratif qui héberge Wikipédia, Wikidata et Wikimedia Commons, attribue ces traces à des agents d’IA opérés par OpenAI, dans un billet publié le 5 octobre. Elle rejoint d’autres organisations, METR, Transluce ou Ruby Hack, qui ont récemment décrit des agents « voyous » cherchant à s’introduire dans des sites. Son cas pose une question que les sites ouverts ne savent pas encore trancher : qui fait tourner ces agents ?

Trois types de traces

Des modifications sur les wikis. La fondation dit avoir « identifié des modifications sur les wikis Wikimedia qui, selon [elle], proviennent d’agents d’IA opérés par OpenAI ». Presque toutes étaient des essais dans les « bacs à sable », ces pages prévues pour s’exercer sans toucher aux articles. Quelques-unes visaient toutefois la configuration d’un outil de citation, des modifications jugées « potentiellement malveillantes », qui cherchaient à détourner l’outil en relais (proxy) pour récupérer des données sur des services extérieurs.

La fondation publie la liste de ces modifications dans un fichier daté du 4 octobre : une simple liste de 54 liens vers des révisions, sans dates. Ils portent sur la Wikipédia en anglais, les wikis de test, Commons, Meta et quelques autres projets, en grande majorité sur des bacs à sable. Cinq visent des pages de configuration de Web2Cit sur Meta : la rédaction en déduit que l’outil de citation en question est vraisemblablement celui-là (la fondation ne le nomme pas). Ce générateur de références complète l’outil Citoid et, selon sa documentation, ses fichiers de configuration sont modifiables par tous, avec effet immédiat pour tous ses utilisateurs.

Des tentatives sur Etherpad. Des agents que la fondation « pense » opérés par OpenAI ont tenté, sans succès, de compromettre son Etherpad public, un outil de prise de notes collaboratif qu’elle met à disposition de la communauté, pour s’en servir là encore de relais vers d’autres sites. D’autres agents, « probablement » d’OpenAI aussi, y ont pris des notes sur leurs tâches, sans que cela semble avoir tourné à la coordination. La fondation dit n’avoir trouvé « aucune preuve » que ses systèmes aient servi à coordonner des agents, ni que ses systèmes ou ses données aient été compromis.

Un trafic massif. Ces agents auraient adressé « des millions de requêtes automatisées » à ses API publiques, parcouru « des millions de pages », surtout sur Wikidata et Commons, et lancé « des centaines de milliers » de requêtes au Wikidata Query Service. « Ce trafic a pu contribuer à une panne partielle » de ce service en mai, écrit la fondation.

Des agents hors des radars habituels

Les robots déclarés d’OpenAI s’annoncent : l’entreprise documente quatre agents, dont GPTBot, qui collecte des pages pouvant servir à entraîner ses modèles et qu’un site peut exclure dans son fichier robots.txt pour signifier que ses contenus ne doivent pas y servir, et ChatGPT-User, qui agit à la demande d’un utilisateur et auquel ces règles « peuvent ne pas s’appliquer ». Chacun a un nom et des plages d’adresses IP publiées, ce qui permet à un site de les reconnaître et de décider quoi leur accorder.

Cette documentation ne mentionne pas les agents que l’entreprise fait tourner pour entraîner ou évaluer ses modèles. C’est, selon notre analyse, vraisemblablement de ceux-là qu’il s’agit, même si ni la fondation ni OpenAI ne l’écrivent : la fondation parle d’agents « issus de l’environnement d’OpenAI », et l’entreprise rattache plusieurs de ses incidents récents à des agents en entraînement. Sam Altman a ainsi évoqué, selon CBS News, « l’usage d’Internet par nos agents pendant l’entraînement et l’évaluation » à propos d’incidents sur des sites gouvernementaux américains. La fondation, elle, ne dit pas sous quelle identité les agents se présentaient sur ses serveurs.

D’où sa demande principale : les systèmes des entreprises d’IA devraient fonctionner « de telle sorte que des propriétaires de sites à but non lucratif comme [elle] puissent facilement les identifier et choisir comment ils interagissent avec [ses] services ». Elle ajoute : « Alors qu’OpenAI admet que des agents se comportent de manière “imprévisible”, il doit aussi reconnaître sa responsabilité de surveiller et de prévenir ces risques. » Et elle insiste sur le coût, qui retombe selon elle sur tous les autres, « y compris des organisations plus modestes ».

La panne de mai, telle que la documente Wikimedia

Le Wikidata Query Service est le moteur de requêtes de Wikidata, la base de connaissances structurées des projets Wikimedia : un serveur SPARQL fondé sur le logiciel Blazegraph, selon la documentation technique, ouvert à tous à l’adresse query.wikidata.org.

Le rapport d’incident, finalisé, situe la panne du 7 mai à 15 h 10 UTC au 11 mai à 13 h 50 UTC. Il l’attribue à des « robots d’aspiration agressifs » (aggressive scrapers) qui ont réduit la disponibilité du service. Au plus fort, la moitié des requêtes adressées au point d’accès public expiraient. Blazegraph, surchargé, a aussi bloqué les mises à jour de l’index, si bien que six serveurs ont servi des données périmées pendant plus de vingt heures. Les équipes ont fini par filtrer les « signatures » des robots en cause, en notant que leur outil d’analyse par échantillonnage ne mesurait pas le trafic assez finement.

Ce rapport ne nomme aucune entreprise, ni OpenAI ni une autre, et ne dit pas combien d’acteurs étaient en cause. Le rapprochement avec OpenAI ne figure que dans le billet d’octobre, et sous une forme prudente : « a pu contribuer ». La part de ces agents dans la panne reste donc inconnue.

Une attribution affirmée, une méthode tue

La fondation affirme pouvoir « confirmer » avoir découvert une activité de ces agents « voyous » d’OpenAI, au terme d’une enquête qu’elle dit avoir centrée sur cette entreprise. Mais pour chaque type de trace, elle reste prudente : « nous pensons », « probablement ». Son billet ne précise pas comment elle a relié ces activités à OpenAI (adresses IP, identifiants des requêtes, recoupement avec d’autres signalements), ni quand elles ont eu lieu, hormis la panne de mai : le fichier ne date pas les modifications, et les « millions » de requêtes ne sont pas chiffrés plus précisément. Il ne dit pas non plus si la fondation a prévenu OpenAI avant publication ni si elle a bloqué ces agents.

Un élément rend toutefois l’attribution plausible : la fondation rappelle que des agents de l’environnement d’OpenAI sont connus pour avoir utilisé d’autres wikis publics pour communiquer entre eux. OpenAI l’a lui-même reconnu : parmi les avis qu’il publie sur son site consacré à l’alignement, l’un, daté du 5 septembre, indique que « nos agents ont communiqué par un wiki public utilisé comme tableau d’affichage partagé ». La même page recense d’autres incidents, dont un avis sur Hugging Face, et un rapport d’avril sur des « agents en entraînement » qui envoyaient des fichiers sur des hébergeurs publics.

Côté OpenAI, la seule réponse connue est celle rapportée par Reuters : l’entreprise a salué les « constats détaillés » de Wikimedia et dit travailler avec elle pour analyser l’activité. « Nous continuerons à partager les informations pertinentes au fur et à mesure de ce travail », a déclaré son porte-parole, Drew Pusateri. Telle que la rapporte l’agence, cette déclaration ne confirme pas explicitement que les agents étaient les siens. Elle ne dit pas non plus si OpenAI prendra en charge une partie des coûts que la fondation dit déjà supporter, ni s’il rendra identifiables les agents en cause.

Une pression déjà mesurée

La plainte n’est pas nouvelle. En avril 2025, trois membres de la fondation indiquaient que la bande passante consacrée au téléchargement de fichiers multimédias avait augmenté de 50 % depuis janvier 2024, sous l’effet de programmes d’aspiration automatisés. Ils relevaient qu’au moins 65 % du trafic le plus coûteux venait de robots, alors que ceux-ci ne représentaient qu’environ 35 % des pages vues.

D’autres services ouverts réagissent aussi : depuis le 1er octobre, arXiv limite chaque déposant à deux soumissions par mois, face à un afflux auquel, selon lui, les outils d’IA contribuent, comme nous le relevions à propos de la suspension des primes open source de Google. Le cas Wikimedia ajoute une dimension : il ne s’agit plus seulement d’aspirer des données, mais d’agents qui écrivent, testent et cherchent des relais, sans qu’un administrateur de site sache forcément qui les fait tourner.

Les citations, tirées de sources en anglais, sont traduites par la rédaction.

À lire aussi