Aller au contenu

Wikipédia:Prise de décision/Conférer des droits supplémentaires aux vérificateurs d'utilisateurs

Ajouter des liens
Une page de Wikipédia, l'encyclopédie libre.
Conférer des droits supplémentaires aux vérificateurs d'utilisateurs
Présentation de la prise de décision
Phase actuelle : Résultat / Phase suivante : Application

Cette prise de décision vise à déterminer s'il est consensuel de confier de nouveaux droits aux vérificateur d'utilisateurs. Sont proposés de leur confier :

  1. le droit de bloquer et débloquer d'autres utilisateurs (block, Aide:Blocage) ;
  2. le droit d'ajouter et retirer un compte au groupe « exemptés de blocage IP ».

Informations :

  • Ouverture de la discussion : 24 mai 2025
  • Ouverture du vote : 2 juin 2025
  • Clôture du vote : 16 juin 2025 à 23:59 CEST

Les modalités de vote sont les suivantes :

  1. La durée du vote est fixée à deux semaines.
  2. Le vote est unique par votant.
  3. Seuls les comptes autopatrolled (créé depuis plus de 90 jours et ayant effectué plus de 500 contributions dans les pages du site fr.wikipedia.org) à l'ouverture du vote peuvent voter.
  4. Proposition B : les seuls votes possibles sont Pour, Contre et Neutre. Les neutres ne sont pas comptabilisés. La proposition est acceptée si le ratio dépasse 66 %. Dans le cas contraire, elle est rejetée et on s'oriente alors vers une rediscussion.
  5. Proposition A de type « Condorcet » : la proposition en tête l'emportera.
Wikipédia:Prise de décision

Prises de décisions

Vote ouvert

Phase de discussion

Sondages

Sondage ouvert

Phase de discussion

Mettre à jour

Résultats

Page connexe : Résultats en page de discussion.

Les propositions sont rejetées. Le statu quo l'emporte.

Proposition A

votes

A1 > A2 > A3 > A4 A2 > A1 > A3 = A4 A2 > A3 > A4 > A1 A2 > A1 > A3 = A4 A2 > A1 > A3 = A4 A1 = A2 > A3 = A4 A1 > A2 > A3 > A4 A2 > A1 > A3 > A4 A1 > A2 > A3 = A4 A1 >> A2 > A3 = A4 A2 > A3 = A4 > A1 A2 > A3 > A1 > A4 A1 > A2 > A3 = A4 A1 > A2 > A3 > A4 A1 > A2 = A3 = A4 A2 > A1 > A3 > A4 A2 > A1 > A3 = A4 A1 > A2 > A3 = A4 A1 > A2 > A3 > A4 A2 > A1 > A3 = A4 A2 > A1 = A3 = A4 A2 > A1 > A3 > A4 A1 > A2 > A3 > A4 A4 > A3 > A2 > A1 A1 > A2 > A3 > A4 A1 > A2 > A3 > A4 A1 >> A2 = A3 = A4 A1 > A2 > A3 > A4 A2 > A1 > A3 = A4 A1 > A3 > A2 > A4 A1 > A2 = A3 = A4 A1 > A2 > A3 > A4 A2 > A1 > A3 = A4 A1 > A3 > A2 > A4 A1 = A2 > A3 > A4 A1 > A2 > A3 > A4 A1 > A2 > A3 > A4 A2 > A1 > A3 = A4 A1 = A2 > A3 > A4 A1 > A2 > A3 > A4 A1 > A2 > A3 > A4 A2 > A1 > A3 > A4 A2 > A3 > A1 > A4 A2 >> A1 >> A3 = A4

A2 > A1 > A3 = A4
 

A1 gagne, statu quo

Duel A2 A3 A4
A1 22 – 20 39 – 5 41 – 3
A2 39 – 3 41 – 1
A3 24 – 1

Proposition B

Pour Contre  Neutre Total pour/(pour+contre) pour/exprimés
21 15 3 39 58.33 % 53.85 %
. . . . contre/(pour+contre) contre/exprimés
. . . . 41.67 % 38.46 %

Contexte général

Les vérificateurs d'utilisateurs sont des utilisateurs de confiance qui disposent de permissions supplémentaires leur permettant d'accéder à des données confidentielles stockées concernant un utilisateur. Leur mandat est fixé à 6 mois et peut être renouvelé.

Ces utilisateurs sont soumis à un corpus de politiques et conditions d'utilisation fixant leurs obligations communautaires et légales.

Leurs outils ne sont utilisés que dans des conditions strictes, toujours afin de prévenir les dégradations : lutter contre le vandalisme, lutter contre le spam, vérifier les abus de faux-nez et limiter les perturbations du projet.

Volet A : droit de [dé]blocage

Contexte A

Les vérificateurs sont amenés à demander le blocage d'autres utilisateurs en raison des abus constatés lors d'une vérification. Toutefois, considérant la politique de confidentialité, ces blocages doivent souvent être « discrets » (plus d'informations). En pratique, il est « nécessaire » que ces opérations soient réalisées par un vérificateur qui est également administrateur (dit « CU-admin »). Or, s'il y a actuellement 2 CU-admins, il pourrait n'y en avoir aucun. Il est donc proposé de confier aux vérificateurs le droit de bloquer et débloquer des utilisateurs dans le cadre de leurs investigations (proposition A2), voire qu'ils viennent en aide aux administrateurs et au comité d'arbitrage en pratiquant les blocages dits « administratifs » et/ou « communautaires » (proposition A3 et A4).

Discussion antérieure :

  • Octobre 2024 – dans laquelle l'idée de confier le blocage aux CU a été suggérée à la réflexion, notamment afin de mettre à jour les motifs génériques de Spécial:InvestigateBlock et définir les conditions d'utilisation.

Wikipédia en néerlandais :

  • En 2023, Wikipédia en néerlandais (nlwiki) a confié le droit de blocage à ses vérificateurs à la suite d'un appel à commentaires. Voir T326355.

Définitions

  • Blocage « administratif » : blocage appliqué immédiatement pour faire cesser un comportement manifestement problématique (ex. vandalismes, injures, etc.).
  • Blocage « communautaire » : blocage appliqué à la suite d'une décision collégiale (historiquement, des administrateurs) en cas de comportement problématique récurrent (ex. guerre d'édition à répétition).
  • Blocage décidé par les vérificateurs d'utilisateurs (ou WP:CUBLOCK) : blocage dont la décision est fondée sur les résultats d'une vérification lorsque des manquements sont constatés. Si le motif du blocage risque de révéler directement ou indirectement une information confidentielle (comme un lien entre une adresse IP et un compte), les vérificateurs doivent éviter toute référence à la vérification et peuvent être amenés à utiliser un motif générique (ex. non-respect des Conditions d'utilisation, abus (bannissement, faux-nez, pantin, autres), évasion d'un bannissement ou d'un verrouillage global) et/ou un « prétexte » (un motif qui ne permet pas de relier le blocage à la vérification comme « vandalisme, non-respect des règles de savoir-vivre, etc. »).
Attention
Les manquements constatés pouvant mener à un CUBLOCK peuvent être des motifs « administratifs » et « communautaires »  : vandalisme, spam, abus de comptes multiples (faux-nez et pantins), perturbations du projet (cela comprend, a minima : contournement d'un bannissement local, d'un bannissement global, d'un verrouillage global et le non-respect des Conditions d'utilisation).

Conséquences

Conséquences en cas d'acceptation ou rejet par type de blocage
Conséquences Acceptation Rejet
CUBLOCK Les vérificateurs pourront appliquer un (dé)blocage dont la décision résulte d'une vérification. Les vérificateurs continuent de demander le (dé)blocage à un vérificateur qui est également administrateur (s'il y en a au moins un sur le wiki), aux administrateurs (si la politique de confidentialité leur permet), sinon à leurs pairs (stewards et les membres de la Commission de médiation).
Blocage administratif Les vérificateurs pourront appliquer les (dé)blocages « évidents », aider les administrateurs sur Wikipédia:Vandalisme en cours et/ou Wikipédia:Requête aux administrateurs ou appliquer les décisions du Wikipédia:Comité d'arbitrage. Seuls les administrateurs peuvent appliquer un tel (dé)blocage.
Blocage communautaire Les vérificateurs pourront appliquer les (dé)blocages « collégiaux », aider les administrateurs Wikipédia:Requête aux administrateurs et/ou Wikipédia:Bulletin des administrateurs ou appliquer les décisions du Wikipédia:Comité d'arbitrage. Seuls les administrateurs peuvent appliquer un tel (dé)blocage.

Propositions A

Plusieurs propositions sont formulées. Classez les propositions (méthode Condorcet) selon vos préférences. Exemple : A1 > A2 > A3 = A4.

Page connexe : Définitions des termes utilisés (type de blocage)..
  • Proposition A1 (statu quo) : Je ne souhaite pas que les vérificateurs puissent (dé)bloquer d'autres utilisateurs.
  • Proposition A2 : Les vérificateurs peuvent exclusivement procéder aux (dé)blocages dits « CUBLOCK » (aux blocages liés à une vérification).
  • Proposition A3 : Les vérificateurs peuvent exclusivement procéder aux (dé)blocages dits « CUBLOCK » et aux blocages « administratifs » (ils viennent donc aussi en aide en aux administrateurs et au Comité d'arbitrage).
  • Proposition A4 : Les vérificateurs peuvent procéder à n'importe quel (dé)blocage : CUBLOCK, blocage « administratif » et blocage « communautaire » (ils viennent donc aussi en aide en aux administrateurs et au Comité d'arbitrage).

À noter : en cas de victoire de la proposition A2, A3 ou A4, la recommandation Wikipédia:Blocage en écriture s'appliquera aux vérificateurs.

Réponses

  1. A1 > A2 > A3 > A4. Le fait de valider à la majorité relative le droit de blocage à des contributeurs non élus par la communauté et qui ne sont pas contestables me semble extrêmement problématique. Sans parler que l'organe de supervision des CU, le Cnom n'est pas conçu pour superviser les CU sur cette question, donc il faudrait une PDD supplémentaire (qui a plus de chance de ne pas se faire que de se faire), pour ne pas avoir des contributions qui peuvent bloquer sans rendre des comptes à personne. Mais en plus, 3 des 4 propositions donnent le même droit technique de blocage, A2 et A3 demandent juste au CU de se modérer sans limitation technique supplémentaire. D'autant que les administrateurs ne font plus trop de différences entre blocages administratifs et communautaires depuis 10-15 ans. Donc au final on a une question à la majorité relative avec 3 des 4 questions assez proches. Alors que la question suivante qui a énormément moins d'enjeux demande une majorité de 66 %. Ça n'a pas de sens. Tout cela alors qu'il a pas de besoin démontrer actuellement (il y a des admin\CU) et les besoins potentiel ne sont pas quantifier : Combien de blocage cela représente les CUBlock qui ont besoin de "discrétion" ? J'ai plus l'impression que c'est très très limité. Nouill 2 juin 2025 à 02:23 (CEST)[répondre]
    @Nouill, plusieurs choses (personnellement je ne sollicite pas plus qu'A2 et je ne suis pas un grand fan de la méthode condorcet mais elle a pas mal de partisans sur Wikipedia) :
    • Sauf à ce que vous soyez en défience, ce serait votre droit, à l'endroit des 6 CU en place, il est faut de dire qu'il n'existe aucun contrôle des actions des CU. Dans la pratique beaucoup de RCU sont traitées par plus d'un CU même si ça ne se voit pas forcément sur la page de requête. Et il est toujours possible de demander une contrevérification à d'autres CU en cas de doute sur un traitement (c'est d'ailleurs ce qu'est succeptible de faire le WP:CNOM). En outre toutes nos actions sont tracées dans des logs accessibles aux stewards. Du reste les renouvellements sont semestriels donc il n'y pas de mandats indef comme les admin, et donc pas besoin de procédure de contestation.
    • Sur le point « Tout cela alors qu'il a pas de besoin démontrer actuellement (il y a des admin\CU) ». Il y a deux admin-CU dont un peu actif. Dans la pratique les blocages reposent beaucoup sur LD, si LD prend un wikibreak il y a des chances pour qu'on ne bloque rien. Ensuite je ne pense pas que vous vous rendiez compte de la lourdeur que ça représente et pour les CU non admin et pour les CU-admin. On en est venu à se créer une espèce de page de requête sur notre wiki privé pour essayer de fluidifier.
    • « J'ai plus l'impression que c'est très très limité » : on aurait certainement du donner plus de contexte dans la page de discussion mais concrètement pour un non CU ce n'est pas quantifiable. Dans les faits à peu près chaque RCU nécessite des blocages d'IP, certains cas plus indispensable que d'autres. Certains blocages moins urgent peuvent aujourd'hui ne pas être adressés vu la lourdeur.
    Le chat perché (discuter) 2 juin 2025 à 11:49 (CEST)[répondre]
    La méthode condorcet est très bien dans pleins de cas, mais dans d'autres cas, elle est moins bien. Il y a aucune méthode de vote parfaite. Là on propose de donner le pouvoir le plus important d'un statut qui nécessite un taux d'approbation de 65 % à 70 %, le tout validé à la majorité qualifié. Ce n'est pas une bonne méthode.
    Oui cela manque de contexte. On ne sait même pas comment font les CU des autres Wikipédia. Est ce que d'autres Wikipédia ont la même problématique ? Est ce que d'autres Wikipédia ont mis en place ce qui est proposé ? A lire Discussion Wikipédia:Prise de décision/Conférer des droits supplémentaires aux vérificateurs d'utilisateurs#Faisabilité technique, cela ne semble pas le cas, puisque cela nécessite de coder la mesure.
    En quoi cela est "lourd" de demander un blocage à un admin ? En quoi c'est impossible de faire un bête modèle qui demande aux administrateurs de bloquer (en listant le tout dans une catégorie) ? Ca existe déjà pour les SI. Et vous dites que vous ne pouvez pas communiquer aux administrateurs non-CU, mais déjà cela vous arrive occasionnellement de demander des blocages après RCU en RA. Si vous devez bloqué une IP, l'IP est de toute manière associé à l'action de bloquer que cela soit après ou avant, et si pour un utilisateur, il y a pas besoin de communiquer des détails, vous pouvez juste demander et ils feront le blocage. Nouill 2 juin 2025 à 16:30 (CEST)[répondre]
    « En quoi c'est impossible de faire un bête modèle qui demande aux administrateurs de bloquer » Il n'y a aucun problème pour demander le blocage d'un FN à n'importe quel admin (plusieurs admins passent régulièrement sur la page WP:RCU pour voir quels sont les derniers FN identifiés et les bloquer, sinon on fait la demande sur WP:VEC en mettant un LI vers la RCU). Mais quand on identifie une série de FN sur la même IP, on veut aussi bloquer l'IP pour pas qu'ils fassent des petits, et ça on ne peut le faire que « discrètement », c'est-à-dire sans faire de lien visible publiquement entre les comptes bloqués et l'IP qu'ils utilisent. Sinon on dévoilerait des informations considérées comme personnelles. Nous utilisons le "modèle" dont tu parles sur un wiki non public, mais c'est LD qui fait tous les blocages. --Lewisiscrazy (discuter) 2 juin 2025 à 16:59 (CEST)[répondre]
    Et donc vous ne pouvez pas juste demander le blocage d'une IP sans l'associer à un contributeur ? Juste une liste/un modèle/une catégorie (peut importe) qui cite l'IP a bloqué sans autres données et qui demande sont blocage ? Nouill 2 juin 2025 à 17:38 (CEST)[répondre]
    On ne peut pas faire de demande en l'associant à un résultat de requête, donc on ferait la demande sans aucune justification ? Mais même, si un CU faisait publiquement une demande de blocage IP juste après un résultat public de requête, ça ne serait pas très « discret ». Je sais que ça semble un peu ridicule, mais la Comm Ombuds prend ça très sérieusement (w:en:Wikipedia:CheckUser#IP information disclosure) au point d'avoir viré des CU (m:Talk:Access to nonpublic personal data policy/Noticeboard/Archives/2022#Further information about last week's rights removals). Et clairement, la tendance est d'aller vers de plus en plus de protection de la vie privée et masquage des IPs (cf Wikipédia:Comptes temporaires). --Lewisiscrazy (discuter) 2 juin 2025 à 21:03 (CEST)[répondre]
    Dans les discussions ci-dessous, on nous dis que les blocages interviennent peu de temps après la RCU pour empêcher des contournements. Donc si on vous écoutes, on peut facilement associer le journal de blocage des admins/CU avec les requêtes RCU. Tout cela est d'ailleurs expliquer sur w:en:Wikipedia:CheckUser#IP information disclosure. Avoir un listing d'IP à bloquer sans autres informations pose les mêmes limites que les journal de blocage des admins/CU (qui est lui aussi public), avec les mêmes solutions (mettre des délais, mélanger, etc).
    Après que la Comm Ombuds est des politiques discutables, je veux bien le comprend. Mais faire d'autres politiques discutables pour s'adapter à leur politique discutable, et bien c'est discutable. Nouill 3 juin 2025 à 10:27 (CEST)[répondre]
  2. A2 > A1 > A3 = A4. L'application de blocages en vertu de WP:CUBLOCK, c'est-à-dire en lien avec le résultats de vérifications, me semble acceptable, bien que je sois moyennement convaincu par la nécessité à mon sens théorique de cette évolution, le groupe des CU ayant à ma connaissance (et de mémoire) toujours inclus des admins ces dernières années. Si ça peut simplifier la vie des CU non-admins pour leur éviter de devoir demander à leur collègue CU admin, why not, mais cet argument n'est même pas produit dans l'introduction de cette PDD et la discussion d'octobre ne montre pas non plus une demande forte des CU. Je mets donc A2 = A1, mais mon avis évoluera peut-être en A2 > A1. En revanche, je ne vois pas quelle est la justification derrière les propositions A3 et A4, qui ne me semblent pas pertinentes, voire incongrues (c'est un truisme que de l'écrire, mais le rôle des CU n'est pas d'aider les administrateurs sur WP:RA ou WP:BA, hors contexte de vérification CU). — Jules* 💬 2 juin 2025 à 02:54 (CEST) [édité le 2 juin 2025 à 12:53 (CEST)][répondre]
    « le groupe des CU ayant toujours inclus des admins ces dernières années » : Linedwell étant peu actif c'est LD qui fait l'essentiel des CUBLOCK, il pourrait un jour avoir envie de partir au moins brièvement en vacances Émoticône. Une alternative à A2 serait que des admins deviennent CU et signent l'accord de confidentialité. --Lewisiscrazy (discuter) 2 juin 2025 à 09:02 (CEST)[répondre]
    OK, au vu de vos réponses, @Le chat perché et @Lewisiscrazy, je passe mon avis en A2 > A1. — Jules* 💬 2 juin 2025 à 12:53 (CEST)[répondre]
    1. Je plaide coupable au vu de mes récents "longs congés" et remercie Lewiscrazy pour sa proposition. Linedwell [discuter] 5 juin 2025 à 14:34 (CEST)[répondre]
  3. A2>A3>A4>A1. Je n'ai jamais été fan de la méthode condorcet et si ça n'avait tenu qu'à moi j'aurais mis juste A2. Le besoin et l'utilité sont réels. Nous sommes amenés à identifier des IP qui doivent être bloquées pour entraver des pénibles et/ou protéger l'encyclopédie et/ou respecter "No open proxys" mais nous n'avons pas le droit de les révéler à des non CU. @Jules*, actuellement il y a 2 CU-admin dont un peu actif (ce n'est pas une critique), et s'il y a des CU non admin c'est bien en grande partie parce que peu d'admin ont candidaté CU et ce n'est pas nouveau. Il y a même eu des périodes passées, par exemple pendant des wikibreak d'Hexasoft, ou il n'y avait de fait presqu'aucun possibilité de faire des CUBLOCKS sauf à passer par des stewards. Donc oui aujourd'hui on est assez entravés dans notre travail de CU et il n'est pas tenable de solliciter constament LD. On a même du pour essayer de fluidifier un peu se créer une espèce de sous page de requête dans le wiki privé. Personnellement je ne sollicite pas plus que A2. Mais clairement rester en l'état me semble difficilement envisageable.--Le chat perché (discuter) 2 juin 2025 à 11:35 (CEST)[répondre]
  4. A2 > A1 > A3 = A4 pour laisser les CU dans leur rôle. — Ornithorynque liminaire (laisser un message)(pronom : iel, mode d'emploi) le 2 juin 2025 à 11:52 (CEST)[répondre]
  5. A2 > A1 > A3 = A4. Les CU n'ont pas mandat pour les cas A3 et A4. Goombiis (discuter) 2 juin 2025 à 11:55 (CEST)[répondre]
  6. A1 = A2 > A3 = A4. Après avoir hésité avec A1 > A2 > A3 = A4 mais la lecture des avis ci-dessus oriente mon choix. Pour A3 et A4, les CU n'ont pas le mandat pour effectuer ces opérations. VateGV ◦ taper la discut’ ◦ 2 juin 2025 à 12:12 (CEST)[répondre]
  7. A1 > A2 > A3 > A4 après avoir hésité pour A1=A2. Explication : J'ai toute confiance en l'équipe actuelle des CU, mais nul ne peut dire de quoi demain sera fait. J'entends bien le besoin, mais on est en train de tenter de changer les règles pour pallier des décisions de Wikimedia incohérentes de mon point de vue (masquer au public des IP de personnes qui contribuent délibéréemment sous IP). Et pour ce faire, on accorderait aux CU l'un des droits les plus élevés des admins, afin qu'ils puissent œuvrer dans la discrétion. La Fondation a déjà rompu avec les règles de transparence en imposant aux CU de raconter n'importe quoi dans certains cas, je n'ose imaginer ce que cela pourrait donner si des CU malintentionnés étaient nommés (et je ne crois pas que cela soit impossible, on a vu se manifester récemment sur une page de condoléances et dans l'heure un nuisible patenté, cequi veut dire qu'il y a au moins un contributeur auquel tout le monde fait confiance susceptible d'être nommé). En résumé le combo "double droit vérification + blocage"dans l'opacité, c'est trop dangereux pour être accordé sans au moins une élection. Les mêmes risques existent d'ailleurs avec un CU qui serait peu compétent. (Pour le Chat perché : l'objection selon laquelle ce n'est pas opaque parce qu'il y aurait un contrôle possible des Xautres CU ne tient pas à mes yeux ici : c'est un nombre (6 actuellement) trop faible pour permettre un réel contrôle, avec en plus l'aspect "corporatiste" qui empêche de ciller au moindre doute). --Pa2chant.bis (discuter) 2 juin 2025 à 12:56 (CEST)[répondre]
  8. A2 > A1 > A3 > A4. Il y a entre 30 et 50 RCU par mois (~40 est le plus courant) et quelques vérifications non publiques. Toutes n'impliquent pas le blocage d'un accès anonyme mais en moyenne on peut compter 1 à 2 CUBLOCKS discrets par requête. Le flux de blocages liés à des abus (par mois) est compris entre 30 (étant le minimum de CUBLOCKS discrets) et 100. Le plus souvent les CUBLOCKS sont liés aux proxies ouverts et aux plages des faux-nez/bannis, ils dont donc par nature « discrets ». 100 peut paraître élevé mais il faut comprendre que si on doit bloquer la plage d'adresses x.x.x.x/16, alors il vaut mieux découper le blocage jusqu'à 256 blocages différents (en x.x.x.x/24) afin qu'il y ait le moins de "victimes collétarales" possibles. A3 ne me semble pas problématique en soi puisque ça concernerait principalement les vandalismes, d'autant plus qu'on observe une baisse constante du nombre d'admins, mais il faut peut-être que la communauté voit que « ça se passe bien » avec A2 pour ensuite envisager d'autres possibilités. LD (d) 2 juin 2025 à 13:32 (CEST)[répondre]
    En fait,@LD, je ne parviens pas à comprendre le besoin de discrétion pour des proxies ouverts(cela ne relève pas de données personnelles puisqu'il s'agit d'un simple point de passage) ni pour de larges blocs d'IP (la fondation a longtemps reconnu que donner le pays et le nom d'un réseau ne trahissait pas l'anonymat, on peut estimer qu'il en serait de même pour de larges blocs?). Cdlt, --Pa2chant.bis (discuter) 2 juin 2025 à 13:51 (CEST)[répondre]
    @Pa2chant.bis : la discrétion intervient dès lors qu'on pourrait associer au moins un compte avec un accès anonyme (IP, plage, compte temporaire). Il s'agit simplement de l'interprétation juridique des textes sur le droit à la vie privée (une IP est une information à caractère personnel). Quant au FAI, ça n'en fait pas partie mais le lieu n'est jamais très précis (on donne pas une adresse postale par exemple), donc perd son caractère personnel/caractère d'identification de la personne. Deux cas : 1) tu contribues uniquement depuis des comptes enregistrés : on pourrait bloquer tes accès bien après la RCU pour que personne ne fasse le rapprochement (donc en théorie, les CU pourraient demander aux admins de bloquer) mais la contre-partie de ce fonctionnement impliquerait que tu aurais le temps de faire « pleuvoir » un tas de nouveaux comptes pendant ce délai ; le blocage interviendrait donc trop tard par rapport à la perturbation engendrée et serait, de toute façon, inefficace dans la majorité des cas (puisque les personnes changent souvent d'IP). 2) tu contribues sous compte et accès anonyme : dans ce cas, il est impératif de bloquer tes accès anonymes (auquel cas on te laisse dégrader Wikipédia). LD (d) 2 juin 2025 à 14:07 (CEST)[répondre]
    Hello. « Il s'agit simplement de l'interprétation juridique des textes sur le droit à la vie privée (une IP est une information à caractère personnel). » Je n'ai jamais lu cette interprétation jusque-là s'agissant des proxies ouverts. Ne serait-ce pas une surinterprétation, excessivement protectrice là où cela n'a pas lieu d'être ? L'OC s'est-elle déjà exprimée sur cet aspect ? — Jules* 💬 2 juin 2025 à 14:14 (CEST)[répondre]
    OC « Advice to Checkusers » : « a checkuser may not publicly connect an IP address with a registered account when that connection is informed by CheckUser data » (un proxy étant une adresse IP, ils n'échappent pas à la règle). LD (d) 2 juin 2025 à 14:28 (CEST)[répondre]
    C'est quand même un truc qu'il faudrait clarifier avec eux, parce qu'un proxy ouvert, c'est quand même fait pour cacher sa vraie adresse IP. J'ai l'impression qu'à force de prudence on dénature la notion "d'IP, donnée personnelle". Sur une autre de tes réponse, je n'ai pas compris le cas 1 : supposons que j'utilise un second pseudo et que j'en abuse (cela me fait donc deux comptes et uniquement deux comptes), en quoi est-il besoin d'attendre pour bloquer ces deux comptes ? Si quelqu'un fait une requête sur Pa2chant et Chatdépend et que le résultat est positif, les CU peuvent le dire, non, et demander mon blocage sans délai ? Et même bloquer mon adresses IP, avec quelques heures de délai si besoin, encore que sur option, il suffit de demander le blocage de l'IP avec celui du compte pour ne pas avoir à le mentionner (selon des échanges sur la page d'Ariel). --Pa2chant.bis (discuter) 2 juin 2025 à 15:09 (CEST)[répondre]
    Merci LD. @Pa2chant.bis : l'OC a semble-t-il donné la consigne aux CU de ne pas divulguer les proxies ouverts. Je trouve ça très discutable de la part de l'OC (une fois de plus). — Jules* 💬 2 juin 2025 à 16:33 (CEST)[répondre]
    Oui, merci Jules, j'avais bien lu. Quand tu dis très poliment que c'est très discutable, je le dis, quoi que j'en pense, tout aussi poliment en disant que c'est un truc qu'il faudrait clarifier avec eux. Je n'accusais pas LD d'avoir mal compris, si c'était ton interprétation. Je monterais bien au créneau, mais mon anglais laisse à désirer. Mais s'il n'y a pas de volontaires, je peux tenter quand même. --Pa2chant.bis (discuter) 2 juin 2025 à 16:47 (CEST)[répondre]
    J'imagine qu'un problème est que la détection de proxy n'est pas infaillible. Je me trompe? --Lewisiscrazy (discuter) 2 juin 2025 à 17:01 (CEST)[répondre]
    Pardon, je t'avais mal comprise, @Pa2chant.bis, ou lue trop rapidement. — Jules* 💬 2 juin 2025 à 17:14 (CEST)[répondre]
    @Jules* et @Pa2chant.bis, déjà la notion de proxys n'est pas binaire. On (les admin) bloquent comme proxys différents types d'adresses IP "douteuses", tous les proxys bloqués ou détectés comme tels ne sont pas des NordVPN ou Tor. Il y a derière des IP qui sont utilisés comme passerelles par exemple mais qui sont en soit des IP légitimes de grands fournisseurs. Et des proxys qui cessent de l'être. Ce rappel me semblait utile.
    Ensuite je confirme qu'on a bien explicitement reçu comme consigne de traiter les proxys comme n'importe quelle IP. Le chat perché (discuter) 4 juin 2025 à 16:54 (CEST)[répondre]
    Il y a des outils pour répérer les proxy ouverts, mais ils peuvent se tromper et j'ai vu qu'ils se trompent. Imagine le cas où tu divulges une IP, pensant que c'etait un proxy ouvert, mais en realité c'est pas un proxy, c'est la vrai IP. Der-Wir-Ing (discuter) 4 juin 2025 à 07:48 (CEST)[répondre]
  9. A1 > A2 > A3 = A4. Je comprends bien le problème de dépendre de la présence de CU-Admins mais je pense que des droits aussi importants ne devraient pas être accordés sans un niveau de contrôle équivalent, condition que ne remplit pas l'auto-contrôle par les autres CUs. Ce contrôle devrait naturellement échoir au Cnom mais le statut de celui-ci étant suspendu dans les limbes... Sinon je ne vois pas de justification pour A3 et A4. — Mwarf (d) 2 juin 2025 à 13:34 (CEST)[répondre]
  10. A1 >> A2 > A3 = A4. Si toute proposition autre qu’A1 est validée, il faudrait réélire tous les CU, qui n’ont pas été élus avec la possibilité de bloquer. Uchroniste40 2 juin 2025 à 13:52 (CEST)[répondre]
    @Uchroniste 40, il ne faut peut être pas tomber dans la procédurite. Il y a longtemps de ça une PDD a accordé aux CU le droit de voir les contributions supprimées ou masquée léger. Pour autant ça n'a pas provoqué la destitution de tous les CU en place. La seule chose vraiment demandée par les CU actuelles (en tout cas moi et je pense @LD c'est que la communauté leur permette d'optimiser et simplifier leur boulot en pouvant bloquer des IP identifiées dans le cadre des RCU donc A2 (ça simplifierait aussi la vie des CU-admin qui se tappent les corvées avec en plus la prise de responsabilité qui va avec). Le chat perché (discuter) 4 juin 2025 à 16:59 (CEST)[répondre]
    Notification Uchroniste 40 : aucune réélection n'est à prévoir car les CU ne sont pas élus, ils sont nommés. -- Habertix (discuter) 4 juin 2025 à 20:53 (CEST)[répondre]
  11. A2 > A3 = A4 > A1. --Myloufa Discuter ou faire Appel? 2 juin 2025 à 13:57 (CEST)[répondre]
  12. A2 > A3 > A1 > A4. --Mathis B discuter, le 2 juin 2025 à 14:20 (CEST)[répondre]
  13. A1 > A2 > A3 = A4. Je pense comprendre le problème et la volonté de le résoudre à travers cette proposition, mais malgré mon entière confiance dans les CU actuels, je ne crois pas que ce soit la bonne façon de le traiter. Je ne suis pas d'accord avec A3 et A4, le rôle des CU n'est pas d'être la cinquième roue des admins. -- HMa [discutez sans frapper] 2 juin 2025 à 16:50 (CEST)[répondre]
    @HMa, quelle serait la bonne façon alors pour A2 ? Ce n'est pas comme si ces dernières années il y avait eu des masses de candidatures d'admin pour être CU. Le chat perché (discuter) 4 juin 2025 à 17:02 (CEST)[répondre]
    Ce qui me pose problème, c'est que le droit de blocage est, à mon avis, l'outil majeur des admins (avec ses assimilés comme mettre une page sous protection ce qui est une autre forme de blocage), et le mode de désignation des CU est tellement différent de celui des admins que je ne trouve pas sain de leur accorder ce droit (encore une fois j'ai toute confiance dans les CU actuels, mais je n'ai pas de boule de cristal pour savoir comment se comporteront les prochains).
    La question n'est pas facile à résoudre, je suis d'accord avec toi. Pour le moment je n'ai pas d'autre idée que d'imposer le statut admin pour candidater comme CU. Ça ne me satisfait pas du tout, en particulier à cause des conditions de déroulement des élections admin, mais je n'ai rien de mieux à proposer. Cela reviendrait à rendre caduque l'option A2 puisqu'un CU serait admin de toute façon.
    Ceci dit, je ne suis pas totalement opposé à A2, nous sommes dans le cadre d'un Condorcet (que ce soit le bon choix ou non, c'est celui qui a été fait), j'exprime juste ma préférence. -- HMa [discutez sans frapper] 7 juin 2025 à 11:18 (CEST)[répondre]
    Ajout notif par courtoisie, même si je pense que tu suis la page de toute façon Le chat perché -- HMa [discutez sans frapper] 7 juin 2025 à 11:25 (CEST)[répondre]
  14. A1 > A2 > A3 > A4 : Un CU n'est pas admin et n'est pas élu par la communauté de WP en français, donc il ne devrait pas pouvoir bloquer. De plus, le rôle d'un CU est de vérifier et non pas de bloquer et on a assez d'admins pour bloquer.--Simonk (discuter) 2 juin 2025 à 17:21 (CEST)[répondre]
    @Simonk, avant d'affirmer ce qu'est le rôle d'un CU il conviendrait peut être que tu lises en détail la page de discussion de cette prise de décision car ton commentaire n'est pas conforme à la vérité. A commencer par le fait que « on a assez d'admins pour bloquer » est hors sujet. On parle, pour A2 car personnellement je ne sollicite et pas plus en tant que CU, de blocage d'IP à faire suite à des RCU (comprendre des IP obtenues grace aux outils des CU). Les CU n'ont pas le droit de communiquer ces IP à des non CU, il n'y a que deux CU-admin donc que deux personnes pouvant procéder à ces blocages avec tout le risque de carrence lié (et dans les faits le risque de charge totale pour un seul CU-admin). Le chat perché (discuter) 4 juin 2025 à 16:41 (CEST)[répondre]
  15. A1 > A2 = A3 = A4. Il me semble dangereux de commencer à fusionner CU et admin. - Bzh99(discuter) 2 juin 2025 à 20:26 (CEST)[répondre]
  16. A2 > A1 > A3 > A4. A1 > A2 > A3 > A4 : Pas favorable à donner l'essentiel des droits d'admins sans vote communautaire. Mais je soutiendrais un CU qui demande le balai pour cette raison. JeanCASPAR (discuter) 2 juin 2025 à 23:05 (CEST). Edit : Après réflexion, je me rends compte que vu comment les élections admins sont bouchés, un CU qui demanderait les droits admins se ferait juste rembarrer. Je change donc mon vote. JeanCASPAR (discuter) 5 juin 2025 à 13:22 (CEST)[répondre]
  17. A2 > A1 > A3 = A4. Pour garantir la discrétion nécessaire dans le cadre de leur fonction spécifique. Frenouille (discuter) 2 juin 2025 à 23:12 (CEST)[répondre]
  18. A1 > A2 > A3 = A4. Clairement les deux dernières propositions n'ont pas lieu d'être (pour moi) : les CU ne sont pas élus pour être admins. Concernant A1 et A2, je ne vois pas l'intérêt de modifier les règles actuelles même si ça peut s'entendre. 'toff [discut.] 3 juin 2025 à 12:31 (CEST)[répondre]
  19. A1 > A2 > A3 > A4 --Æpherys (discuter) 3 juin 2025 à 13:45 (CEST)[répondre]
  20. A2 > A1 > A3 = A4 : je suis d'accord pour que les CUs puissent bloquer un faux-nez qu'ils ont révélé par une RCU, mais opposé au reste car cela n'est pas de leur ressort. — Bloc186 (discuter) 3 juin 2025 à 20:00 (CEST)[répondre]
  21. A2 > A1 = A3 = A4 Trizek bla 3 juin 2025 à 21:39 (CEST)[répondre]
  22. A2 > A1 > A3 > A4 --Tom Blaireau 3 juin 2025 à 21:44 (CEST)[répondre]
  23. A1 > A2 > A3 > A4. Il me semble que la proposition A2, au contraire, réduirait la discrétion des blocages car il serait bien plus évident de relier un blocage à une vérification, comparé à la situation actuelle. Je suis également sensible aux arguments de l'insuffisance de contrôle et de séparation des rôles. — Antimuonium discuter 3 juin 2025 à 23:18 (CEST)[répondre]
  24. A4 > A3 > A2 > A1 Je suis été CU dans la wikipédia allemande pour un ans et ne pas pouvoir bloquer les trolls et vandals, ne pas pouvoir empêcher les trolls à nuire notres projets, c'etait mer... merveilleu pour les vandales. --Der-Wir-Ing (discuter) 4 juin 2025 à 00:03 (CEST)[répondre]
    Le blocage des trolls ou vandales découverts lors des vérifications est inclus dans A2, @Der-Wir-Ing. A3 et A4 désignent la participation aux activités des admins non liées aux RCU. Amicalement, — Jules* 💬 4 juin 2025 à 14:52 (CEST)[répondre]
    Je sais. A2 est le machin important. Peut-etre j'ai un avis minoritaire ici, mais je veux qu'on fasse confiance aux CU. Mais je dois avouer, s'ils ne sont pas élus, c'est pas facile avec la legitimité. Der-Wir-Ing (discuter) 4 juin 2025 à 21:29 (CEST)[répondre]
  25. A1 > A2 > A3 > A4 (et même A1 > A2 >> A3 >> A4). A1 : pourquoi est-ce que certains CU ne candidatent pas au statut admin ? Pas A3 et surtout pas A4 : je comprends qu'il y a des blocages qui doivent rester confidentiels mais, dans le fonctionnement de Wikipédia, je pense qu'il est important que celles et ceux qui décident d'un blocage au nom de communauté soient directement responsables devant la communauté (c'est le mécanisme de confirmation pour le statut admin ; certes on pourrait mettre en place un mécanisme analogue pour les CU mais ce serait une perte de temps inutile : si un CU a envie de d'aider les admins ou le Comité d'arbitrage, il peut candidater à ces statuts). -- Habertix (discuter) 4 juin 2025 à 02:02 (CEST).[répondre]
    @Habertix, il y a un détail qui t'échape, les blocages fait par des CU-admin échapent de toute façon à toute mise en responsabilité réelles puisque les CU-admin ne sont aujourd'hui pas tenu de révéler la vraie raison (laquelle peut elle même être confidentielle et couverte par la CU Policy). Personnellement je ne sollicite pas plus que A2. La situation actuelle avec tout les risque de carrences de CU-admin (2 actuellement dont un très peu actif (c'est pas une critique)) déséquilibre la charge et entraine un surplus de travail pour les CU car nous avons été obligés de nous créer une page de requêtes sur notre wiki privé (c'est presque ubuesque de mon point de vue). Par ailleurs puisque la WMF ne rend pas obligatoire pour un CU d'être admin il n'y a pas lieu de demander à des CU de se lancer dans une candudature à un job B pour pouvoir faire correctement leur job A actuel. Et je gage qu'une candidature modifié sur le seul besoin de faire A2 serait rejetée par une partie de la communauté d'emblée. Le chat perché (discuter) 4 juin 2025 à 16:48 (CEST)[répondre]
    Les CU-admin peuvent être contestés, y compris pour des blocages en tant que CU ; à la fin c'est la communauté qui confirmera ou non le statut.
    Si A4 est adopté sans mécanisme de contestation/confirmation, on aurait d'un côté des CU-non-admin non élus (mais nommés) et "irresponsables" de l'autre des CU-admin tous chargés du même job. -- Habertix (discuter) 4 juin 2025 à 21:11 (CEST)[répondre]
    Qu'est-ce que tu proposes pour resoudre le problème? Elire les CUs? Der-Wir-Ing (discuter) 4 juin 2025 à 21:41 (CEST)[répondre]
  26. A1 > A2 > A3 > A4. Assez en phase avec Nouill. Les propositions A3 et A4 m'apparaissent non recevables car elles portent sur des prérogatives réservées aux admins en vertu de leurs processus spécifiques de nomination et de contrôle, qui diffèrent trop de ceux applicables aux CU. Par ailleurs, la proposition A2 ne me paraît pas présenter d'avantage suffisant par rapport à A1 en matière de discrétion : les CU seraient décisionnaires, en certifiant la nécessité de bloquer sans divulguer de données privées aux admins ou à la communauté, mais les CU non admins ne pourraient de facto pas utiliser de faux motifs pour demander ou exécuter un blocage CU. Le mieux serait qu'il y ait davantage de CU-admins. Il serait peut-être plus simple que des admins se portent volontaires, ce qui est tout à fait concevable pourvu qu'il y ait davantage de communication et de sensibilisation en amont des prochaines nominations. [D952]会話 5 juin 2025 à 12:05 (CEST)[répondre]
  27. A1 >> A2 = A3 = A4 ; chacun son boulot Michel421 (discuter) 5 juin 2025 à 19:41 (CEST)[répondre]
  28. A1>A2>A3>A4 Si les CU ont besoin des outils d'administrateurs, il faut nommer des CU parmi les administrateurs choisis par la communauté. O.Taris (discuter) 5 juin 2025 à 23:41 (CEST)[répondre]
  29. A2>A1>A3=A4 : A3 et A4 inutiles (il n’y a pas de file d’attente pour les blocage) et risqués (CU non élus). Ne sait-on pas ne donner le privilège CUBLOCK aux CU que pour bloquer les IP, sources de l’empêchement de confidentialité actuel ? (en attendant l’interdiction définitive d’icelles) —JohnNewton8 (SysOp) [Viens !] 6 juin 2025 à 06:11 (CEST)[répondre]
    Bonjour JohnNewton8 Émoticône Je ne suis pas sûr de comprendre de quelle « interdiction définitive » tu parles : même avec les comptes temporaires (et même dans l'éventualité très peu probable d'une obligation de contribuer avec un compte enregistré), les IPs ne disparaitront pas, ni la nécessité d'en bloquer certaines. --Lewisiscrazy (discuter) 6 juin 2025 à 10:23 (CEST)[répondre]
    @JohnNewton8, si le recourt à un compte enregistré devenait obligatoire il y aurait toujours des IP à bloquer, cellles utilisées par ces comptes. Mareil pour les comptes temporaires Donc je ne comprend pas ton argumentaire. Le chat perché (discuter) 6 juin 2025 à 18:52 (CEST)[répondre]
    Salut Notification Lewisiscrazy : je suis 100% favorable à donner le droit aux CU de bloquer les IP. J'entends les réserves de ceux qui ne veulent pas donner aux le droit de blocage à des contributeurs non élus : je suggère donc que les CU n'aient le droit de bloquer que des IP —JohnNewton8 (SysOp) [Viens !] 7 juin 2025 à 17:34 (CEST)[répondre]
    @Le chat perché tambien —JohnNewton8 (SysOp) [Viens !] 7 juin 2025 à 17:35 (CEST)[répondre]
  30. A1 > A3 > A2 > A4 Anatole-berthe (discuter) 6 juin 2025 à 07:09 (CEST)[répondre]
  31. A1 > A2 = A3 = A4. --Chablis (discuter) 6 juin 2025 à 12:22 (CEST)[répondre]
  32. A1 > A2 > A3 > A4 -- Pªɖaw@ne 6 juin 2025 à 13:16 (CEST)[répondre]
  33. A2 > A1 > A3 = A4 -- Guallendra (discuter) 7 juin 2025 à 06:30 (CEST)[répondre]
  34. A1 > A3 > A2 > A4. — ✍ Ruyblas13 [causerie💬] 7 juin 2025 à 10:10 (CEST)[répondre]
  35. A1 = A2 > A3 > A4. Pas d'avis tranché. Je suis d'accord avec celleux qui écrivent qu'on ne peut pas partager ainsi les prérogatives des admins, compte tenu des conditions d'élection et de contestation associées à ce statut. Au moins les admins sauront que leur aide est demandée pour les blocages d'IPs. --Lewisiscrazy (discuter) 7 juin 2025 à 11:32 (CEST)[répondre]
  36. A1 > A2 > A3 > A4 Wikipédiennement. Slzbg (discuter) 7 juin 2025 à 12:36 (CEST)[répondre]
  37. A1 > A2 > A3 > A4. Après beaucoup d’hésitations. A2 ne me choque pas sur le principe et est en œuvre sur d’autres wiki, mais sur ces autres wiki il y a quand même un cadre et des moyens de contrôle qui manquent chez nous. Pour me faire pencher vers A2 il faudrait que le comité qui nomme les CU ait plus de moyen de contrôler ce qu’ils font (donc soit signataire de la politique de confidentialité et ait accès aux logs) et qu’il y a ait plus d’horizontalité dans la nomination (sans forcément un vote, mais qu’au moins la communauté soit consultée sur les candidats). Runi Gerardsen (discuter) 8 juin 2025 à 08:32 (CEST)[répondre]
  38. A2 > A1 > A3 = A4. — Richaringan (永遠 (ながちじち) んかい !) 8 juin 2025 à 20:06 (CEST)[répondre]
  39. A1 = A2 > A3 > A4 il est bon, je trouve, d'avoir des rôles séparés, et d'avoir des "experts" à qui on ne demande pas d'avoir les compétences "humaines" des admins. -- Le Petit Chat (discuter) 9 juin 2025 à 16:13 (CEST)[répondre]
  40. A1 > A2 > A3 > A4. J'entends le besoin, mais vu l'exigence de la communauté lors des élections admin c'est incongru d'accorder le droit de blocage sans vote. Par ailleurs, le fait que le seuil d'adoption ait été fixé de fait à 50 %, au contraire de l'usage d'un seuil à 60 voir 66 % (qui est éventuellement critiquable, mais assez bien établi et même suivi dans l'autre question) et sans laisser suffisamment de temps de préparation pour en discuter, est une raison de plus de voter pour le statu quo pour contrebalancer. --l'Escogriffe (✉) 10 juin 2025 à 17:42 (CEST)[répondre]
  41. A1 > A2 > A3 > A4 Kartouche (Ma PdD) 11 juin 2025 à 09:04 (CEST)[répondre]
  42. A2 > A1 > A3 > A4 — Witcher of Izalith 11 juin 2025 à 22:05 (CEST)[répondre]
  43. A2 > A3 > A1 > A4. La raison d'être des vérificateurs est de mettre au jour les abus dissimulés derrière plusieurs comptes et IP, donc il me semble normal qu'ils puissent directement bloquer les coupables qu'il découvrent. À titre personnel, je ne serais pas opposé à l'octroi de prérogatives supplémentaires contre le vandalisme (donc A3), parce que cela reste lié à cette raison d'être, mais ce qui me fait hésiter est que ce n'est pas stricto sensu ce pour quoi ils sont nommés. À défaut, autant rester sur le statu quo. Quant à l'option A4, elle me semble éloignée de leur mission première, qui n'est pas de gérer les conflits interpersonnels. --Cosmophilus (discuter) 12 juin 2025 à 22:44 (CEST)[répondre]
  44. A2 >> A1 >> A3 = A4 --Ciseleur (d) 13 juin 2025 à 08:06 (CEST)[répondre]
  45. A2 > A1 > A3 = A4 ---Croquemort Nestor (discuter) 13 juin 2025 à 11:56 (CEST)[répondre]

Volet B : droit d'exempter de blocage IP

Contexte B

L'exemption de blocage d'IP – qui permet à son détenteur de contribuer malgré le blocage de son IP – doit être retiré à son détenteur en cas d'abus constaté, et doit être uniquement attribué au requérant lorsqu'il ne commet aucun abus. Or, les administrateurs n'ont accès qu'aux informations publiques (publiées sur les projets), et en pratique il leur est conseillé de consulter les vérificateurs en cas de doute. De ce fait, il est proposé de confier le droit aux vérificateurs le droit d'ajouter et retirer un compte au groupe « Exemptés de blocage IP ».

Propositions B

Proposition B :

Êtes-vous favorable à la proposition énoncée ci-dessus ?

Pour

  1. Pourquoi pas. De toute manière, la procédure d'exemption de blocage d'IP semble à revoir. Pour l'avoir demandé pour la 1ère fois il y a pas longtemps, la procédure dit qu'il faut aller en RA mais qu'on peut demander aussi avec le modèle {{Déblocage}} qui lui renvoit vers la requête de déblocage. Donc au final, je l'ai fais directement sur la requête de déblocage (Sachant que c'est une requête de déblocage dans bon nombre de cas, donc mon cas : blocage de fréquence mobile). Mais la page de requête de déblocage n'est pas conçue pour être directement modifiée mais recense juste les appels du modèle "Déblocage". Et sur le fond, j'ai obtenu l'exception pour un tiers du blocage (donc il va falloir que je redemande). Alors que j'ai l'impression qu'il des exceptions d'IP données de manière indef et/ou préventive. Et le suivi, je ne suis pas sûr que cela soit trop fait. Nouill 2 juin 2025 à 02:38 (CEST)[répondre]
    Pour le suivi, LD et moi (a minima) faisons une maintenance périodique (approximativement mensuelle) qui consiste à retirer ce statut aux utilisateurs inactifs. — Jules* 💬 2 juin 2025 à 02:58 (CEST)[répondre]
    La demande directe sur WP:RA, c'est pour les comptes qui ne sont pas toujours bloqués (par exemple un étudiant bloqué pendant la semaine en utilisant le FAI de son établissement, mais pas bloqué le WE quand il utilisait le FAI familial). {{Déblocage}}, c'est pour un compte qui est toujours bloqué à cause de son IP mais la demande se retrouve mélangée avec les autres demandes de déblocage (surtout vandale ou compte rémunéré qui font mine de ne pas comprendre). Autrefois, les admins devaient vérifier les demandes en attente à l'aide d'une catégorie, puis un bot s'est chargé d'ouvrir un ticket sur WP:RA. Depuis mars 2024, une page dédiée WP:DDD a été créée (et utilisée par le bot).
    Donc je conseille WP:RA, même s'il faut attendre 1 ou 2 jours pour un accès non bloqué. -- Habertix (discuter) 2 juin 2025 à 03:40 (CEST).[répondre]
  2. Je n'y vois pas d'inconvénient. — Jules* 💬 2 juin 2025 à 02:58 (CEST)[répondre]
  3. Pour. — Ornithorynque liminaire (laisser un message)(pronom : iel, mode d'emploi) le 2 juin 2025 à 11:53 (CEST)[répondre]
  4. Rien contre. Goombiis (discuter) 2 juin 2025 à 11:56 (CEST)[répondre]
  5. Pour Cela me semble même la solution la plus logique, puisque seuls les CU peuvent vérifier avant exemption que le compte est bien différent de comptes intervenus sous la même IP ou le même groupe d'IP à l'origine du blocage de l'IP/de la plage (et dans les faits, je n'ai jamais vu un admin demander publiquement cette vérification, qui serait surement trop vexante). --Pa2chant.bis (discuter) 2 juin 2025 à 12:10 (CEST)[répondre]
  6. Plutôt pour. VateGV ◦ taper la discut’ ◦ 2 juin 2025 à 12:13 (CEST)[répondre]
  7. Pour — Mwarf (d) 2 juin 2025 à 13:36 (CEST)[répondre]
  8. Pour — LD (d) 2 juin 2025 à 13:45 (CEST)[répondre]
  9. Pour. Uchroniste40 2 juin 2025 à 13:54 (CEST)[répondre]
  10. Pour --Myloufa Discuter ou faire Appel? 2 juin 2025 à 13:57 (CEST)[répondre]
  11. Pour - Bzh99(discuter) 2 juin 2025 à 20:30 (CEST)[répondre]
  12. Pour JeanCASPAR (discuter) 2 juin 2025 à 23:07 (CEST)[répondre]
  13. Plutôt pour. Frenouille (discuter) 2 juin 2025 à 23:17 (CEST)[répondre]
  14. Plutôt pour — Bloc186 (discuter) 3 juin 2025 à 20:00 (CEST)[répondre]
  15. Pour, Trizek bla 3 juin 2025 à 21:37 (CEST)[répondre]
  16. Pour --Tom Blaireau 3 juin 2025 à 21:45 (CEST)[répondre]
  17. Pour --Der-Wir-Ing (discuter) 4 juin 2025 à 06:08 (CEST)[répondre]
  18. Pour Je pense qu'une telle mesure peut permettre de gagner du temps. Anatole-berthe (discuter) 6 juin 2025 à 07:13 (CEST)[répondre]
  19. Pour. — ✍ Ruyblas13 [causerie💬] 7 juin 2025 à 10:11 (CEST)[répondre]
  20. Plutôt pourquoi pas. — Richaringan (永遠 (ながちじち) んかい !) 8 juin 2025 à 20:06 (CEST)[répondre]
  21. Plutôt pour exempté un utilisateur d'un blocage IP n'est pas une sanction mais une action technique. Kartouche (Ma PdD) 11 juin 2025 à 09:30 (CEST)[répondre]

Contre

  1. Contre : Je ne vois pas l'intérêt de cette proposition et ne comprend pas pourquoi l'avoir proposé, car les CU ont pour rôle de vérifier et non pas de bloquer.--Simonk (discuter) 2 juin 2025 à 17:23 (CEST)[répondre]
  2. Contre, étant donné que je ne vois pas d'élément dans l'argumentaire qui justifierait un vote pour (utilité à travers un cas d'usage, insuffisance de la situation actuelle...). Je n'ai pas de cas en tête où cette proposition serait utile, mais je peux me tromper. — Antimuonium discuter 3 juin 2025 à 23:39 (CEST)[répondre]
  3. -? Plutôt contre Dans la continuité des deux avis précédents, je ne vois pas l'intérêt. Et si c'est pas cassé, alors on ne répare pas ? Arek7 4 juin 2025 à 07:24 (CEST)[répondre]
  4. -? Plutôt contre Même avis Michel421 (discuter) 5 juin 2025 à 19:35 (CEST)[répondre]
  5. Les CU ont pour fonction de vérifier, pas d'administrer Wikipédia. O.Taris (discuter) 5 juin 2025 à 23:48 (CEST) D'ailleurs, y a-t-il un problème réel à résoudre, des cas où l'exemption a été mal gérée par les administrateurs ? O.Taris (discuter) 7 juin 2025 à 11:35 (CEST)[répondre]
  6. Contre. -- Habertix (discuter) 5 juin 2025 à 23:59 (CEST).[répondre]
  7. contre, ne mélangeons pas les genres. Les CU ont un rôle de vérification technique (même IP, même navigateur etc.) pas d’appréciation de la confiance accordable à un compte —JohnNewton8 (SysOp) [Viens !] 6 juin 2025 à 06:15 (CEST)[répondre]
  8. Contre. --Chablis (discuter) 6 juin 2025 à 12:26 (CEST)[répondre]
  9. -- Pªɖaw@ne 6 juin 2025 à 13:18 (CEST)[répondre]
  10. Contre, à ce que je sache, être vérificateur n'est pas lié au fait d'attribuer sa confiance à tel compte au point de l'exempter de blocage d'IP. Les demandes à ce sujet sont toutes traitées dans un délai convenable. Wikipédiennement. Slzbg (discuter) 7 juin 2025 à 12:36 (CEST)[répondre]
  11. Contre même avis que JohnNewton8. -- Le Petit Chat (discuter) 9 juin 2025 à 16:16 (CEST)[répondre]
  12. Contre Par convaincu. — Witcher of Izalith 11 juin 2025 à 22:07 (CEST)[répondre]
  13. -? Plutôt contre Moins évident que de bloquer des vandales ; les vérificateurs peuvent fournir aux admins les éléments dont ils ont besoin pour juger, mais ce sont ceux-ci qui devraient prendre une décision collégiale. --Cosmophilus (discuter) 12 juin 2025 à 22:51 (CEST)[répondre]
  14. -? Plutôt contre Je ne vois pas très bien les modalités ; peut-être mettre en place un fil privé de discussion entre Admins et CU pour traiter les demandes et les révocations — fil qui pourrait servir aussi dans le cadre du Volet A. --Ciseleur (d) 13 juin 2025 à 08:16 (CEST)[répondre]
  15. Contre ---Croquemort Nestor (discuter) 13 juin 2025 à 11:57 (CEST)[répondre]

Neutre

  1.  Neutre je n'en vois pas vraiment l'intérêt, ce n'est pas ce genre de requêtes qui encombre les RA et en pratique il suffirait qu'un CU le recommande pour qu'un admin le fasse, mais rien contre non plus. --Mathis B discuter, le 2 juin 2025 à 14:22 (CEST)[répondre]
  2.  Neutre Idem : je n'y vois pas d'inconvénient majeur, mais je n'en vois pas l'intérêt non plus. -- HMa [discutez sans frapper] 2 juin 2025 à 16:52 (CEST)[répondre]
  3.  Neutre les cas évoqués sont rares et peuvent être traités comme les blocages d'IPs (par CU-admin), mais sans urgence (contrairement aux blocages IPs, qui empêchent l'éclosion de canetons). --Lewisiscrazy (discuter) 7 juin 2025 à 12:54 (CEST)[répondre]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Wikipédia:Prise_de_décision/Conférer_des_droits_supplémentaires_aux_vérificateurs_d%27utilisateurs&oldid=226611651 ».