Wikipédia:AbuseFilter/Requêtes
- Suppression immédiate
- Intervention sur une page protégée
- Intervention concernant un nom de domaine
- Protection et déprotection de page
- Fusion d'historiques
- Purge d'historique
- Renommage de page
- Restauration de page
- Vandalisme en cours
Requête aux administrateurs d'interface
Requête aux éditeurs de filtres
| Année | janv. | févr. | mars | avr. | mai | juin | juil. | août | sept. | oct. | nov. | déc. |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | ||
| 2011 | Archives 2011 | |||||||||||
| 2012 | Archives 2012 | |||||||||||
| 2013 | Archives 2013 | |||||||||||
| 2014 | Archives 2014 | |||||||||||
| 2015 | Archives 2015 | |||||||||||
| 2016 | Archives 2016 | |||||||||||
| 2017 | Archives 2017 | |||||||||||
| 2018 | Archives 2018 | |||||||||||
| 2019 | Archives 2019 | |||||||||||
| 2020 | Archives 2020 | |||||||||||
| 2021 | Archives 2021 | |||||||||||
| 2022 | Archives 2022 | |||||||||||
| 2023 | Archives 2023 | |||||||||||
| 2024 | Archives 2024 | |||||||||||
| 2025 | Archives 2025 | |||||||||||
| 2026 | Archives 2026 | |||||||||||
Cette page sert à demander une modification ou la création d'un filtre aux modificateurs de filtre anti-erreur.
Les filtres permettent de détecter ou bloquer des modifications selon de nombreux critères, ils sont notamment utiles pour le suivi et le balisage d'erreurs courantes, bloquer des vandalismes récurrents, limiter et surveiller des contournements de blocages, restreindre des plages d'IP dynamiques, etc.
Pour effectuer votre demande, cliquez sur le lien ci-dessous et rédigez votre demande. Elle se retrouvera tout en bas de cette page.
Notes :
- Indiquez des exemples précis, par exemple des diffs ou la liste des IP et des comptes visés.
- Un filtre doit être suffisamment précis, pensez aux faux positifs.
- Si vous ne connaissez pas le numéro du filtre, vous pouvez le chercher sur la liste des filtres.
Pour effectuer une autre requête aux administrateurs, veuillez employer les raccourcis ci-contre. Notamment, les requêtes concernant le filtre anti-spam sur les hyperliens externes ne sont pas du ressort de cette page, mais doivent être émises sur la page Wikipédia:Demande d'intervention concernant un nom de domaine.
Une fois la requête close :
- Pensez à ajouter le modèle {{fait}} ou {{pas fait}} dans le titre pour permettre l'archivage.
Spécial:AbuseFilter/ 2024-02-19 13:13
modifier
Demandé par : DarkVador [Hello there !] le 25 février 2024 à 14:38 (CET)
Changement proposé : Création ou modification d'un filtre sur le Forum des nouveaux, pour empêcher la création de nouveaux sujets comportant une adresse mail (ou d'un @) dans leur titre.
Justification de la demande : Recrudescence de sujets ne comportant qu'une adresse mail d'entreprise ces derniers jours, qu'il faut cacher manuellement.
Commentaires des éditeurs :
- Bonjour. Possible même si les regex sur les emails sont complexes.
- Curieux de voir si d'autres filtres existent sous MW (meta ou wp-en en premier lieu) pour réfléchir un peu.
- A priori, à mettre directement dans Spécial:Filtre_antiabus/364.
- Mais, de manière générale, deux filtres d'avertissement pour les numéros de téléphone (exemple technique) et les emails peuvent être créés (un pour wikitext, et un pour flow).
- Chers OS, @Arcyon37, @Bédévore, @JohnNewton8, @Jules*, @Kropotkine 113 et @Lomita, est-ce qu'un ou plusieurs filtres qui regroupent les potentielles « informations sensibles » faciliterait le suivi, ou au contraire, ça poserait davantage problème ?
- LD (d) 6 mars 2024 à 02:43 (CET)
- Salut @LD. Pour l'instant, les regrouper « artificiellement » ne me semble pas pertinent. Ça le sera si phab:T290324 voit le jour (ça va peut-être bouger d'abord du côté de phab:T234155). — Jules* discuter 6 mars 2024 à 11:20 (CET)
- Assez d'accord. Après, il va falloir être patient avant que ça bouge... ;) Kropotkine 113 (discuter) 6 mars 2024 à 11:35 (CET)
- @LD un filtre détecte déjà les emails: Spécial:Filtre_antiabus/12 -Framawiki ✉ 6 mars 2024 à 12:55 (CET)
LD et Jules* : En l'état, est-il possible de statuer cette requête ? ShifaYT
✉Tchater 22 octobre 2024 à 13:21 (CEST)
- Hello, il faudrait créer un nouveau filtre réutilisant la regex du filtre 12 évoqué par Framawiki. Mais pourquoi se limiter au FDN ? Autant englober tous les espaces de discussion, en limitant aux non autopatrolled, et veillant à ne pas filtrer les ajouts avec {{@}}. — Jules* discuter 10 novembre 2024 à 14:25 (CET)
Nouveau filtre 2025-11-01 21:47
modifier
Demandé par : lastrik [papoter] le 4 novembre 2025 à 11:21 (CET)
Changement proposé : Création d'un filtre sur les liens externes dans le corps des articles hors des balises ref
Justification de la demande : On se retrouve souvent avec des ajouts de liens externes dans le corps des articles qu'il faut ensuite aller retirer. ça serait pas mal si on pouvait au moins avertir les PCW qui tentent d'en ajouter de nouveaux que ce n'est pas admis. Merci ! (et désolée si ça a déjà été demandé par le passé, je n'ai pas trouvé)
Commentaires des éditeurs :
Od1n et Jules* : vous êtes les deux derniers à avoir modifié le filtre 15 qui empêche l'insertion répétée de liens externes sans notification. Serait-il adéquat de l'adapter ?
Tiloudeux : tu peux avoir un avis à donner. 'toff [discut.] 4 novembre 2025 à 17:48 (CET)
- Ça semble simple sur le principe, il faudrait tester si le titre de section précédant le lien ajouté n'est pas du genre « Lien(s) externe(s) », ou bien aussi s'il n'y a aucun titre de section avant (cas du résumé introductif).
- En revanche, j'ai souvenir d'avoir vite fait essayé de rajouter cela dans le filtre, et il s'était avéré que ce n'était pas aussi simple que ça à mettre en place.
- Je viens aussi de penser à un cas particulier : dans l'infobox, où il peut être approprié de mettre un lien externe, mais il n'y a pas de titre de section avant ; à exclure avec une détection du genre « précédé de
\{\{Infobox», sans titre de section intercalé » ? - od†n ↗blah 5 décembre 2025 à 22:41 (CET)
Spécial:AbuseFilter/ 2026-08-19 14:06 : bloquer les abus de fonctionnalités d'ajouts de liens et d'images
modifier
Demandé par : CaféBuzz (d) le 19 août 2026 à 14:23 (CEST)
Changement proposé : Empêcher des nouveaux comptes d'éditer en rafale des articles en utilisant les fonctionnalités ajouter des liens / ajouter des images.
Justification de la demande : Ma requête fait suite à une suggestion de Le chat perché sur Wikipédia:Vérificateur d'utilisateurs/Requêtes/août 2026#Zakary234, Franckimpro, Denis4712, JacquesD25, Dinah45, Verdez2246 - 19 août. Depuis quelques semaines nous faisons face à des vagues de vandalisme de la part de comptes nouveaux qui ajoutent en rafale (des vagues à plusieurs ajouts par minutes, montrant que les ajouts sont faits sans vérification ni discernement) des images et / ou des liens internes en utilisant les tâches pour novices. Voir Wikipédia:Faux-nez/SmileyBercy.
Commentaires des éditeurs :
- Salut CaféBuzz, on peut mettre un taux limite mais il y aura nécessairement des faux-positifs. Si je pioche dans mon expérience, il m'est arrivé de faire tourner mon bot au-delà du taux limite que j'avais envisagé, soit à cause d'une étourderie de ma part, soit d'un problème réseau (côté utilisateur ou WMF).
- Ceci dit, il me semble intéressant de mettre User:Trizek (WMF) dans la boucle car cette question du taux limite a dû s'être posée au regard de principes généraux évoqués par wmf:Policy:Wikimedia Foundation API Usage Guidelines (entre autres).
- Le chat perché et moi n'en avons pas discuté (comme CU) mais la non-résolution de phab:T234155 est un facteur limitant : on ne peut pas (en tant qu'AF) cibler un utilisateur à partir de données issues de WP:RCU. Il faut que les données soient publiques (ou que OC valide le principe). LD (d) 19 août 2026 à 14:38 (CEST)
- @LD, dans le cas présent si j'ai suggéré un filtre (basé sur des paterns de contribution) c'est parce qu'ayant traité plusieurs RCU sur ce pénible, je suis bien placé pour dire que les données techniques ne mettent sur ce cas précis pas en évidence des WP:CUBLOCK qui seraient efficace (à commencer par le fait que la personne derière les comptes recourt souvent à des proxys). On relie ses faux nez principalement par un indice sur les UA. Donc même si tu pouvais faire un filtre visible uniquement par les CUs, sur le cas présent je ne vois pas trop sur quoi.--Le chat perché (discuter) 19 août 2026 à 14:48 (CEST)
- Pour les collègues, un début d'idée, mais présentement pas le temps de faire mieux, sur le filtre 394 (pas encore activé).🐾 tiloudeux (miaou ?) 19 août 2026 à 17:57 (CEST)
- @Tiloudeux, j'espère que ton idée fonctionnera
. Ce pénible recourt à de multiples proxys ouverts, raison principae pour laquelle je disais qu'il n'était pas facile à contrer avec des CUBLOCK. @LD, j'étais entrain de me demander pourquoi la WMF ne blinde pas ses firewall pour repousser les proxys ouverts mais certes il y a des usages légitimes (genre moi pour la raison que tu sais et qui fait que j'ai le statut d'exempté de blocages IP, ou plus concrètement les gens qui contribuent depuis des pays comme la Chine ou Wikipedia est interdit). Cela étant dit sauf erreur de ma part le firewall de wikimediesque repousse les noeuds Tor (je n'en ai trouvé qu'un seul qui avait passé le filet en deux ans et demi en tant qu CU et jamais avant, et encore c'était une vieille contribution d'une IP qui n'était peut être pas "Tor" à ce moment là). Donc c'est un peu paradoxale. La WMF bloque d'emblée les accès Tor mais pas les proxys ouverts (qui sont blocables à vue quand ils sont détectés notamment via des RCU).--Le chat perché (discuter) 20 août 2026 à 10:09 (CEST)
- filtre 394 revient à désactiver certaines fonctionnalités de Growth de manière grossière. Deux considérations : autoriser certains groupes à continuer de réaliser ces actions ; appliquer un throttle cohérent avec le problème rencontré. Dans tous les cas, je ne crois pas que certains abus justifient de jeter le bébé avec l'eau du bain. LD (d) 21 août 2026 à 12:37 (CEST)
- @Tiloudeux, j'espère que ton idée fonctionnera
- Pour les collègues, un début d'idée, mais présentement pas le temps de faire mieux, sur le filtre 394 (pas encore activé).🐾 tiloudeux (miaou ?) 19 août 2026 à 17:57 (CEST)
- @LD, dans le cas présent si j'ai suggéré un filtre (basé sur des paterns de contribution) c'est parce qu'ayant traité plusieurs RCU sur ce pénible, je suis bien placé pour dire que les données techniques ne mettent sur ce cas précis pas en évidence des WP:CUBLOCK qui seraient efficace (à commencer par le fait que la personne derière les comptes recourt souvent à des proxys). On relie ses faux nez principalement par un indice sur les UA. Donc même si tu pouvais faire un filtre visible uniquement par les CUs, sur le cas présent je ne vois pas trop sur quoi.--Le chat perché (discuter) 19 août 2026 à 14:48 (CEST)
Spécial:AbuseFilter/ 2026-09-15 00:20
modifierDemandé par : Şÿℵדαχ₮ɘɼɾ๏ʁ, mardi le 15 septembre 2026 à 00:28 (CEST)
Changement proposé : Il faudrait peut-être créer un filtre pour l'ajout de liens vers http://africatime.com (aussi avec www./fr./en.), ce site ayant changé de propriétaire en 2018 (maintenant une clinique d'Osaka), en indiquant que des archives sur wikiwix.com ou archive.org existent éventuellement (le site est utilisé sur moins de 150 articles, mais il continue d'être ajouté lors de traductions, cf. SpamCheck).
Un filtre plus général servant à prévenir qu'un site a été racheté pourrait être envisagé s'il n'existe pas déjà, ce cas n'étant sans doute pas isolé.
Justification de la demande : Wikipédia:Bot/Requêtes/2026/09#africatime.com > lien mort
Commentaires des éditeurs :
- C'est pas plutôt à gérer en blacklist, ça ? (ping @Aelxen)🐾 tiloudeux (miaou ?) 19 septembre 2026 à 10:27 (CEST)
- En effet, à moins qu'il y aie une raison spécifique plus probante, la liste noir est bien meilleur pour ce cas. A moins que le but n'est qu'informatif et prévenir d'un possible rachat ? @SyntaxTerror et @Tiloudeux Aelxen 🍐 Les poires vaincront 19 septembre 2026 à 10:32 (CEST)
Tiloudeux et Aelxen : la blacklist ne bloque en effet pas les liens archivés (c'est un contournement possible que j'avais repéré mais qui ne semble pas être possible d'empêcher facilement) donc pourquoi pas, tout ce qui compte c'est d'éviter que des vieux liens pas vérifiés se retrouvent utilisés comme références.- Tu t'en occupes, Aelxen ? Il y a différents sous-domaines utilisés (rien/www./fr./en.) mais il vaut mieux tout bloquer à mon avis. Şÿℵדαχ₮ɘɼɾ๏ʁ, samedi 19 septembre 2026 à 10:49 (CEST)
- @SyntaxTerror, je viens de faire un test via la page spécial de blocage de nom de domaine. SI on ajoute l'url directe du site incriminé = blocage ; si on l'insert via une archive par exemple de la weback, la détection n'est pas automatique, mais si on publie la page malgré tout, le blocage se déclanche.Aelxen 🍐 Les poires vaincront 19 septembre 2026 à 11:15 (CEST)
- @SyntaxTerror autre petit détail, ça fonctionne si l'archive de la weback est rajouté en automatique dans ce cas là, ça route l'url incriminée directement dans le param prévu. Par contre si c'est un ajout manuel de la source en effet là ça peut bloqué, surtout si l'url est celle de la weback.Aelxen 🍐 Les poires vaincront 19 septembre 2026 à 11:18 (CEST)
- @Aelxen : je me souviens en avoir parlé sur une PdD de blacklist (sans doute avec toi d'ailleurs), mais je ne retrouve plus la page.
- En tout cas, ça marche avec https://web.archive.org/web/20260210232803/https://www.oisillon.net/ (mais on a deux pages de blacklist ? je suis un peu perdu). Şÿℵדαχ₮ɘɼɾ๏ʁ, samedi 19 septembre 2026 à 11:31 (CEST)
- J'ai trouvé, ça date de l'an passé mais ça n'a pas été archivé apparemment . Şÿℵדαχ₮ɘɼɾ๏ʁ, samedi 19 septembre 2026 à 12:11 (CEST)
- @SyntaxTerror autre petit détail, ça fonctionne si l'archive de la weback est rajouté en automatique dans ce cas là, ça route l'url incriminée directement dans le param prévu. Par contre si c'est un ajout manuel de la source en effet là ça peut bloqué, surtout si l'url est celle de la weback.Aelxen 🍐 Les poires vaincront 19 septembre 2026 à 11:18 (CEST)
- @SyntaxTerror, je viens de faire un test via la page spécial de blocage de nom de domaine. SI on ajoute l'url directe du site incriminé = blocage ; si on l'insert via une archive par exemple de la weback, la détection n'est pas automatique, mais si on publie la page malgré tout, le blocage se déclanche.Aelxen 🍐 Les poires vaincront 19 septembre 2026 à 11:15 (CEST)
- En effet, à moins qu'il y aie une raison spécifique plus probante, la liste noir est bien meilleur pour ce cas. A moins que le but n'est qu'informatif et prévenir d'un possible rachat ? @SyntaxTerror et @Tiloudeux Aelxen 🍐 Les poires vaincront 19 septembre 2026 à 10:32 (CEST)