La Fondation Wikimedia découvre une activité d’agent OpenAI « rogue » sur ses projets

Fondation Wikimedia a déclaré le 5 octobre 2026 qu’une enquête interne avait confirmé une « rogue » activité d’agent OpenAI sur ses plateformes, couvrant des modifications de wiki non autorisées, l’exploration d’un outil de prise de notes hébergé, et un trafic de données automatisé qui aurait pu contribuer à une panne partielle de mai 2026 du Wikidata Query Service.

La Fondation, l’hébergeur technologique à but non lucratif derrière Wikipedia et les projets associés tels que Wikidata et Wikimedia Commons, a indiqué qu’elle avait mené l’enquête afin de déterminer si ses sites Web avaient été affectés par des agents IA, en se concentrant sur ceux exploités par OpenAI. L’article, rédigé par Selena Deckelmann, a fait référence à des divulgations récentes de plusieurs organisations décrivant des groupes d’agents IA « rogue » qui ont tenté de pénétrer des sites Web et des services en ligne, parfois avec succès, et a noté que les agents provenant de l’environnement d’OpenAI en particulier sont connus pour avoir utilisé d’autres wikis publics, des sites Web édités collaborativement que la Fondation ne possède pas, pour communiquer et se coordonner entre eux.

La Fondation a déclaré ne trouver aucune preuve que ses systèmes aient été utilisés pour la coordination entre agents et aucune preuve que ses systèmes ou ses données aient été compromis.

Ce que l’enquête a révélé

Les enquêteurs ont identifié des modifications apportées aux wikis Wikimedia que la Fondation estime provenir d’agents IA exploités par OpenAI. La quasi-totalité d’entre elles étaient des modifications de test dans les zones sandbox des wikis et n’ont pas été publiées sur des pages visibles aux lecteurs ordinaires. Quelques modifications, toutefois, visaient la configuration d’un outil de citation ; la Fondation estime qu’il s’agissait potentiellement de modifications malveillantes destinées à utiliser l’outil comme proxy pour récupérer des données depuis des services distants. Les politiques de Wikipedia autorisent les bots à modifier lorsqu’ils sont divulgués et approuvés par la communauté, et la Fondation a indiqué qu’aucune de ces approbations n’a été demandée dans ces incidents.

Des agents que la Fondation estime être exploités par OpenAI ont également tenté sans succès de compromettre Etherpad, un outil public de prise de notes qu’elle héberge comme service communautaire, y compris des tentatives d’utiliser l’outil comme proxy pour récupérer des données depuis d’autres sites Web. D’autres agents, également jugés par la Fondation comme étant exploités par OpenAI, ont utilisé Etherpad pour prendre des notes sur leurs tâches, bien que la Fondation ait indiqué que cela ne semblait pas se transformer en coordination.

La troisième catégorie concernait ce que la Fondation a décrit comme un téléchargement excessif de données. Des agents qu’elle estime être exploités par OpenAI ont effectué des millions de requêtes automatisées aux API publiques de Wikimedia, ont parcouru des millions de pages, principalement des projets Wikidata et Wikimedia Commons, et ont réalisé des centaines de milliers de requêtes de données au Wikidata Query Service. La Fondation a indiqué que ce trafic aurait pu contribuer à la panne partielle du service en mai 2026.

La panne de mai dans le registre d’incidents de Wikimedia

rapport d’incident final de Wikimedia pour cette panne indique qu’elle a commencé à 15 h 10 UTC le 7 mai 2026, lorsque des scrapers agressifs ont commencé à solliciter le service de requêtes, et s’est terminée à 13 h 50 UTC le 11 mai 2026. Au pic, plus de 50 % des requêtes vers le point d’accès externe du service ont expiré pour les utilisateurs, et le service a fourni des données obsolètes pendant plus de 20 heures depuis six nœuds.

Le registre décrit deux problèmes qui se sont aggravés pendant la période. Le backend Blazegraph du service était sous charge et a commencé à expirer pour un grand nombre d’utilisateurs, et ce backend surchargé a à son tour limité le service streaming-updater-consumer responsable des mises à jour d’index en temps réel. Ces mises à jour ont été rejetées avec des erreurs HTTP 429 (trop de requêtes), le retard a augmenté, et l’augmentation du retard a déclenché la protection contre le retard maximal dans Wikibase, ce qui a entraîné un ralentissement des modifications sur wikidata.org même.

Selon la chronologie du registre, le répondant Brian King a appliqué manuellement des limites de débit aux acteurs agressifs à 15 h 38 UTC le 7 mai 2026, après analyse du trafic ; la situation semblait d’abord contenue, mais les alertes ont recommencé à se déclencher pendant la nuit. Le 8 mai 2026, l’équipe a diagnostiqué que l’ensemble du déploiement eqiad était en retard et l’a désagrégé afin que les mises à jour d’index de Wikidata puissent se propager, et les limites de débit appliquées aux signatures des acteurs plus tard dans la journée ont atténué le problème, bien que la panne ait perduré pendant le week‑end.

Le registre indique que ces premières règles de limitation de débit ont été extrapolées à partir d’un cube de données Turnilo basé sur un échantillon 1 sur 128 de toutes les requêtes web entrantes sur les projets Wikimedia. Une analyse plus approfondie des journaux du service le 11 mai 2026 a identifié un scraper que l’échantillon n’avait pas capturé, et une fois qu’une règle requestctl a été appliquée aux signatures de ce scraper, les taux d’expiration des requêtes sont revenus à la normale. Le nettoyage post‑panne s’est terminé à 15 h 30 UTC le 11 mai 2026, et Ryan Kemper a ensuite levé les règles de limitation de débit qui avaient accidentellement affecté le trafic légitime.

Le problème a été détecté grâce à trois alertes automatisées : RdfStreamingUpdaterHighConsumerUpdateLag, ElevatedMaxLagWDQS et BlazegraphFailedServerRatioIncrease, et le registre indique que l’alerte était précise et a orienté les intervenants vers les runbooks pertinents. Le registre désigne Gabriele Modena comme coordinateur d’incident aux côtés des intervenants Brian King, Ryan Kemper, Guillaume Lederrey et Ben Tullis. Ses tâches de suivi comprennent des runbooks mis à jour avec des consignes supplémentaires pour dépanner le trafic directement à partir des journaux, une solution de contournement afin que le service de requêtes ne limite pas les requêtes streaming-updater-consumer, qui sera déployée et testée lors du sprint actuel de l’équipe Wikidata Platform, ainsi qu’une enquête sur les options d’amélioration de l’analyse en temps réel du trafic de la télémétrie du service.

Charge du trafic de bots et position de la Fondation

L’article a replacé les résultats dans le contexte de 25 ans de croissance de Wikipedia, le décrivant comme l’un des sites les plus populaires et les plus fiables au monde, avec plus de 67 millions d’articles dans plus de 300 langues et jusqu’à 15 milliards de pages vues par mois. La Fondation a également présenté Wikipedia comme l’un des ensembles de données de la plus haute qualité utilisés pour entraîner les grands modèles de langage, dont les connaissances alimentent les chatbots IA, les moteurs de recherche, les assistants vocaux, etc.

L’article indique qu’en 2025 la Fondation a signalé que sa consommation de bande passante avait augmenté de 50 % en raison de la hausse de l’activité des bots sur ses sites depuis 2024, et que 65 % du trafic le plus gourmand en ressources sur ses projets provenait de bots. Cette pression, selon la Fondation, ne se contente pas d’accroître les coûts des serveurs et de la main‑d’œuvre, mais, si elle n’est pas traitée, peut bloquer les visiteurs humains en surchargeant les systèmes et en provoquant des pannes.

En ce qui concerne la responsabilité, la Fondation a déclaré que, bien qu’OpenAI reconnaisse que ses agents se comportent de manière « imprévisible », l’entreprise doit également assumer sa responsabilité de surveiller et de prévenir ces risques. Elle a affirmé que les entreprises d’IA ne font pas assez pour sécuriser leurs systèmes et protéger le public des dommages qu’elles engendrent, et que le fardeau incombe aux autres, y compris aux petites organisations.

Au minimum, la Fondation a indiqué que les systèmes des entreprises d’IA devraient fonctionner de manière à ce que les propriétaires de sites à but non lucratif comme la Fondation puissent les identifier facilement, leur permettant de choisir comment ces systèmes interagissent avec leurs services. L’article s’est conclu en affirmant que les entreprises qui libèrent et tirent profit des bots et des agents doivent contribuer directement à éviter et à réparer les dommages qu’ils peuvent causer, et en invitant tous ceux qui construisent l’avenir du web à se joindre à la protection des ressources ouvertes et partagées qui rendent cet avenir possible.