Skip to main content
Guides
GuidesTeamModeration

Créer une équipe de modération Discord : une structure qui tient à 2 000 membres

La plupart des équipes ne s'effondrent pas à cause de mauvaises personnes, mais faute de règles sur le recrutement, les permissions et l'inactivité. Un guide tiré de la pratique.

Publié le par AlphaCloud5 min de lecture

Chaque serveur qui grandit arrive au point où une seule personne ne peut plus modérer seule. Ce qui se passe alors en général : trois amis reçoivent les permissions de modérateur parce qu'ils sont souvent en ligne. Six mois plus tard, deux d'entre eux sont inactifs, personne n'ose leur retirer le rôle, et le troisième est épuisé.

Ce n'est pas un problème de personnes. C'est l'absence de règles.

Commence par les permissions, pas par les rôles

L'ordre habituel est à l'envers. La plupart des gens créent d'abord des rôles qui sonnent comme des grades, puis réfléchissent après coup à ce qu'ils doivent pouvoir faire.

Inverse-le. Note quelles tâches existent réellement :

  • Quelqu'un doit supprimer le spam et calmer les disputes
  • Quelqu'un doit répondre aux demandes de support
  • Quelqu'un doit décider qui rejoint l'équipe
  • Quelqu'un doit organiser les événements

Ensuite seulement, regroupe les tâches en rôles. Cela donne généralement moins de rôles que prévu, et chacun a un but clair.

Les permissions minimales

Une règle qui évite bien des soucis : personne ne reçoit Administrateur à moins de devoir réellement administrer le serveur.

Pour la modération au quotidien, celles-ci suffisent :

Tâche Permission nécessaire
Supprimer le spam Gérer les messages
Calmer quelqu'un Exclure temporairement des membres
Retirer quelqu'un Expulser des membres
Retirer définitivement Bannir des membres

C'est tout. Gérer les salons, Gérer les rôles et Gérer le serveur reviennent à la direction, pas à la modération. La raison n'est pas la méfiance mais la limitation des dégâts : si un compte est compromis, c'est précisément cette liste qui décide de la gravité.

Le recrutement a besoin d'un processus

Tant que les membres de l'équipe sont recrutés au feeling, chaque refus devient personnel. Un processus fixe protège les deux côtés.

Un processus qui a fait ses preuves :

  1. Les candidatures passent par un formulaire, pas par un message privé. Ainsi, tout le monde à la direction voit les mêmes informations.
  2. Publie les exigences minimales à l'avance. Par exemple : 30 jours sur le serveur, un âge minimum, une disponibilité par semaine.
  3. Une période d'essai. Quatre semaines avec des permissions limitées, puis une décision réfléchie.
  4. Un refus est un refus motivé. Une phrase suffit, mais elle doit être là.

Le point 3 est le plus important et le plus souvent oublié. Une période d'essai offre une sortie naturelle où personne ne perd la face.

Régler l'inactivité à l'avance, pas après coup

C'est la partie la plus désagréable, et donc celle que presque tout le monde repousse.

Un membre de l'équipe qui n'a rien fait depuis trois mois bloque une place et démotive ceux qui travaillent. Le problème, c'est que sans règle, chaque conversation à ce sujet ressemble à une attaque personnelle.

Écris la règle avant d'en avoir besoin. Par exemple :

Chaque membre de l'équipe traite au moins 10 demandes de support par mois. Celui qui est en dessous reçoit un message. Celui qui est de nouveau en dessous le mois suivant rend son rôle.

Deux choses rendent cela supportable :

Une vraie façon de s'absenter. Vacances, examens, maladie. Quiconque se déclare absent ne compte pas comme inactif pendant cette période. Sans cette voie, la règle est injuste et sera contournée.

Un avertissement plutôt qu'un retrait. Le premier manquement est un message, pas une sanction. Presque tout le monde reprend ensuite.

Si tu veux l'automatiser : AlphaCloud compte via les entrées de support ou les tickets traités, et envoie lui-même l'avertissement via le contrôle d'activité. Les membres déclarés absents sont ignorés.

Les avertissements ont besoin d'une date d'expiration

La même logique s'applique en interne. Quand un membre de l'équipe commet une erreur une fois et reçoit un avertissement, celui-ci ne devrait pas rester pour toujours.

Un avertissement qui n'expire jamais signifie que quelqu'un qui a dérapé il y a deux ans est en permanence à un pas du retrait. Ce n'est ni juste ni utile.

Fixe une durée, par exemple 90 jours sans nouvel avertissement, puis laisse le niveau expirer.

Rendre les décisions visibles

Deux salons de logs qui valent la peine :

  • Public : recrutements, promotions, départs. C'est de la reconnaissance, et cela répond au passage à la question « qui fait vraiment partie de l'équipe ».
  • Interne : avertissements, blocages, notes. Direction uniquement.

La séparation est tout l'intérêt. La communauté doit voir une promotion, mais pas chaque discussion interne à son sujet.

Une liste de l'équipe qui se tient à jour toute seule

Un message épinglé listant chaque membre de l'équipe est faux au bout de quatre semaines. Soit tu le mets à jour chaque semaine à la main, soit tu le laisses se générer à partir des rôles.

Le second est la seule version qui reste correcte. Effet secondaire : quand quelqu'un quitte l'équipe, il disparaît automatiquement de la liste, et personne n'a à s'en souvenir.

La partie qu'aucun logiciel ne résout

Une équipe fonctionne ou échoue sur trois choses pour lesquelles il n'existe pas d'interrupteur :

La clarté sur qui décide. Quand deux modérateurs prennent des décisions contradictoires, ce n'est presque jamais à cause d'eux, c'est que personne n'a jamais dit qui a le dernier mot en cas de désaccord.

Le soutien. Un modérateur qui prend une décision impopulaire mais juste, puis se fait publiquement corriger par la direction, ne prendra plus aucune décision la fois suivante.

Une porte de sortie. La plupart des gens ne quittent pas une équipe en colère, ils partent parce que la vie change. Si partir revient à passer pour un traître, les gens ne partent pas, ils deviennent simplement inactifs. Et tu te retrouves au problème du début.

Plus d'articles