Candidature staff Discord : comment suivre les candidatures sur ton serveur

La plupart des serveurs recueillent les candidatures staff avec un Google Form ou un bot de tickets. Les recueillir, c’est la partie facile. Le bazar arrive après : quelles candidatures quelqu’un a-t-il lues, qui fait passer l’entretien à qui, et est-ce que quelqu’un a fini par répondre à la personne qui a candidaté en mars ?

Ce guide met en place un suivi des candidatures que ton équipe staff utilise depuis Discord. Il ne remplace pas le formulaire que les membres remplissent (on en reparle plus bas). C’est le circuit d’examen qui vient après.

À quoi ressemble le suivi

Une ligne par candidature, avec :

• le candidat (membre Discord, obligatoire)
• le poste visé (texte, obligatoire)
• le statut (Submitted, Under Review, Interview, Accepted, Rejected ; obligatoire)
• la date d’envoi
• le relecteur (membre Discord)
• des notes

C’est le modèle Suivi des candidatures de CordBase, que nous développons. Ce guide le construit plutôt à la main, avec une colonne de plus, pour une raison expliquée à l’étape 1.

Étape 1 : créer la table

1. Connecte-toi sur cordbase.gg avec Discord, choisis ton serveur et ajoute le bot quand c’est demandé.
2. Crée une table nommée « Apps » avec d’abord une colonne de texte applicant name, puis les six colonnes ci-dessus. La commande sera /apps.

Pourquoi la colonne en plus : quand le staff choisit une ligne à modifier, CordBase cherche et liste les lignes par la première colonne de texte de la table. Dans le modèle, c’est « role applied for », donc dix candidatures de modérateur apparaîtraient comme dix entrées « Moderator » identiques. Une colonne de nom en premier rend chaque ligne facile à trouver.

Étape 2 : réserver la table au staff

Les candidatures sont plutôt privées, donc règle les permissions avant que quiconque l’utilise :

• Ton rôle staff a write (ajouter et modifier des lignes).
• Ton rôle admin ou chef modo a admin (ajoute la suppression).
• Ne donne de niveau à aucun autre rôle. Dès qu’une table a un rôle défini, les membres qui n’ont aucun de ces rôles ne peuvent plus du tout l’utiliser, et c’est ce que tu veux ici.

Vérifie aussi que le salon où le staff lance ces commandes est réservé au staff. Les résultats de query, view, add et update sont publiés dans le salon où la commande est lancée, donc toute personne qui voit ce salon les voit. Seules les erreurs et les confirmations de suppression sont privées.

Étape 3 : enregistrer les candidatures à leur arrivée

Quand une candidature arrive, un membre du staff l’enregistre :

/apps add applicant_name:Rin applicant:@Rin role_applied:Moderator status:Submitted submitted_date:2026-10-08

Étape 4 : traiter la file

• /apps query status:Submitted affiche tout ce que personne n’a encore pris.
• /apps query reviewer:@Sam affiche la file de Sam.
• /apps update row:Rin status:Interview reviewer:@Sam notes:Interview Fri 8pm fait avancer une candidature. Commence à taper le nom du candidat dans row et choisis-le dans la liste.

Comme la file vit dans une table, rien ne dépend de la mémoire de quelqu’un pour savoir quelles réponses il a lues.

La place du formulaire

CordBase ne recueille pas lui-même les réponses des candidats ; les membres n’y remplissent pas de formulaire. Continue d’utiliser ce qui collecte les réponses (un Google Form, un bot de tickets ou un bot de candidatures qui pose les questions en MP) et utilise le suivi pour le statut. La colonne notes est un bon endroit pour coller un lien vers la réponse complète.

Après le cycle

• Exporte la table en CSV ou en JSON, pratique pour un bilan de fin de mandat.
• Les lignes refusées et acceptées peuvent rester comme historique, ou un admin peut les supprimer. Les lignes supprimées sont purgées au bout de 30 jours.
• L’offre Free contient 100 lignes par table, ce qui couvre beaucoup de cycles de candidatures pour la plupart des serveurs. Pro passe à 10 000.