Le 5 octobre 2026, la Wikimedia Foundation a signalé des modifications sur ses projets, des tentatives visant Etherpad et un important volume de requêtes qu’elle attribue à des agents qu’elle estime exploités par OpenAI. La Fondation a indiqué que ce trafic a pu contribuer à une panne partielle du Wikidata Query Service (WDQS) en mai.
La panne, survenue du 7 au 11 mai, a fortement perturbé le service. Le compte rendu de l’incident fait état de délais d’attente et de données en retard; au pic, 50 % des requêtes vers les points de terminaison externes expiraient. La Wikimedia Foundation a publié ses conclusions le 5 octobre, plusieurs mois après l’incident.
Des modifications de test et un trafic massif
Presque toutes les modifications recensées sur les wikis étaient des essais en bac à sable. Aucune n’a été publiée sur une page visible du grand public. La Fondation a aussi indiqué que les agents n’avaient pas demandé l’approbation communautaire requise pour les modifications automatisées.
Wikimedia estime que quelques changements de configuration d’un outil de citation pouvaient être malveillants et visaient à lui faire récupérer des données auprès de services distants, à la manière d’un proxy. Elle a également rapporté que des tentatives visant à compromettre le service public Etherpad et à l’utiliser pour récupérer des données sur d’autres sites avaient échoué.
La Fondation a attribué aux agents des millions de requêtes automatisées aux API publiques, des millions de pages explorées — principalement sur Wikidata et Wikimedia Commons — et des centaines de milliers de requêtes à WDQS.
Une panne de WDQS du 7 au 11 mai
Le compte rendu de l’incident WDQS situe le début de la panne au 7 mai 2026 à 15 h 10 UTC et sa fin au 11 mai à 13 h 50 UTC. Au moment le plus difficile, 50 % des requêtes vers les points de terminaison externes expiraient; six nœuds servaient des données en retard de plus de 20 heures.
Le compte rendu décrit un scraping agressif et une surcharge de Blazegraph. Le bridage du composant streaming-updater-consumer a entraîné le rejet de mises à jour d’index et accru le retard des données. Après l’analyse des journaux, des limites de débit ciblant des signatures de scraper ont ramené le taux d’expiration à son niveau de référence.
Wikimedia a estimé que le trafic attribué aux agents avait pu contribuer à cette panne. Le compte rendu technique décrit, de son côté, le scraping et les problèmes de charge du service.
Les constats de Wikimedia sur la compromission
Dans sa déclaration du 5 octobre, la Fondation a indiqué n’avoir trouvé aucun indice de compromission de ses systèmes ou de ses données. Elle n’a pas non plus relevé d’élément indiquant que son infrastructure avait servi à coordonner les agents.
