Boty Discord
Quatre bots de production qui gèrent les serveurs de nos marques. Ticketing avec ping de l'équipe, accueil des nouveaux membres, vérification des e-mails et rangement des rôles - le tout adapté à chaque serveur. Ils déchargent le support et maintiennent l'hygiène de la communauté sans travail manuel.
Quatre bots de production, chacun adapté à un serveur précis : gestion des tickets avec un ping à la bonne équipe, accueils et onboarding, vérification e-mail à l'arrivée, entretien des rôles. Tous reposent sur un noyau unique et une architecture de cogs, de sorte que chaque serveur ne prend que les fonctions dont il a vraiment besoin. Une nouvelle fonction est un nouveau cog, pas un if de plus dans un monolithe.
Introduction
Les communautés de nos marques vivent sur Discord, pas sur un site. C'est là qu'arrive un nouveau client, là qu'il ouvre un ticket, là qu'il attend le rôle qui donne accès aux bons canaux. À quelques centaines de membres, gérer à la main les tickets, les accueils et les rôles cesse simplement de tenir - il faut que quelqu'un soit là, regarde et clique, et cela ne passe pas à l'échelle avec le nombre de gens.
Au lieu d'écrire un bot universel pour tout faire, nous avons construit un noyau et un jeu de modules à partir desquels chaque bot est assemblé séparément. Quatre serveurs, quatre rôles, quatre configurations - mais un seul endroit où vit la logique. Cette étude de cas explique pourquoi cette séparation a rapporté plus qu'un monolithe qui aurait été commode au départ.
Pourquoi pas un seul bot pour tout
Il est tentant d'écrire un bot qui fait tout le travail sur chaque serveur. Le problème, c'est que chaque serveur a des besoins un peu différents : une équipe différente à pinguer sur un ticket, un parcours d'arrivée différent pour un nouveau membre, des rôles différents et un seuil de vérification différent. Un bot universel censé les gérer tous devient avec le temps un sapin de Noël de drapeaux auquel personne ne veut toucher, parce qu'on ne sait pas ce qui en dépend encore.
Le second piège, c'est l'état partagé. Un processus qui sert quatre serveurs à la fois est un point de défaillance unique - un bug dans la logique des tickets peut faire tomber les accueils sur un serveur tout à fait différent. Et plus un serveur transporte de code inutilisé, plus il est difficile d'y changer quoi que ce soit en toute sécurité.
Un noyau, de nombreux cogs
Nous avons pris l'autre voie : un noyau avec des modules, qu'on appelle cogs dans l'écosystème Discord, et chaque bot est un jeu de cogs activés. Le serveur de tickets prend le cog tickets ; un serveur qui n'en a pas besoin ne l'active tout simplement pas.
Monolithe contre un noyau avec cogs
| Aspect | Un bot pour tout | Noyau avec cogs |
|---|---|---|
| Nouvelle fonction | un if de plus à l'intérieur | un cog nouveau et isolé |
| Serveur sans une fonction | transporte quand même son code | ne l'active tout simplement pas |
| Panne d'un module | risque pour l'ensemble | limitée au cog |
| Correction de logique | recherche dans le monolithe | un seul endroit, partout où le cog est actif |
Quatre bots, quatre rôles
En pratique, l'écosystème, ce sont quatre bots distincts, chacun faisant une chose bien. Le bot de tickets ouvre des fils de tickets et pingue la bonne équipe pour qu'un signalement ne reste pas dans le vide. Le bot d'accueil guide un nouveau membre à travers ses premiers pas. Le bot de vérification confirme une adresse e-mail à l'arrivée. Le bot de rôles maintient l'hygiène des rôles et les attribue automatiquement.
Cette séparation n'est pas cosmétique. Chaque bot a son propre périmètre de permissions et son propre état, de sorte que la panne de l'un n'entraîne pas les autres, et qu'un changement dans l'un n'oblige pas à penser aux trois autres. Seul le noyau est partagé - comment un cog s'accroche au bot, comment il lit la configuration et comment il parle à l'API.
Quatre bots, quatre rôles
| Bot | Ce qu'il fait | Cog clé |
|---|---|---|
| Tickets | ouvre des fils de tickets et pingue la bonne équipe | tickets |
| Accueil | onboarding et premiers pas d'un nouveau membre | welcome |
| Vérification | confirmation de l'adresse e-mail à l'arrivée | mailcheck |
| Rôles | attribution automatique et hygiène des rôles | roles |
À quoi ressemble un cog
Un cog est une unité autonome : ses propres commandes, ses propres écouteurs, son propre état. Vous l'accrochez au bot en une ligne et vous le détachez de même. Il n'y a aucun enchevêtrement global - le cog tickets ne sait rien du cog rôles et n'en a pas besoin. Ci-dessous un extrait de la vérification : un nouveau membre reçoit un rôle d'attente et une invitation à confirmer son adresse avant de voir le reste du serveur.
Des noms comme on_member_join ou add_roles sont imposés par l'API Discord et restent tels quels - le reste des identifiants suit notre propre convention. C'est la frontière où l'on suit la bibliothèque, pas son propre style, et le seul endroit où deux conventions de nommage se mélangent.
La vérification e-mail à l'arrivée n'est pas un ornement. La défense la moins coûteuse contre une vague de faux comptes est un seuil que les bots qui s'inscrivent en masse doivent franchir - confirmer une vraie adresse en élimine la plupart avant même qu'ils voient les canaux. Le rôle d'attente maintient un nouveau membre à la porte jusqu'à la confirmation.
Ce qui reste du côté de la maintenance
Le plus grand gain n'est pas visible sur le serveur mais dans la façon dont ces bots sont maintenus. Une correction dans la logique des tickets atterrit à un seul endroit et atteint partout où ce cog est activé - vous ne la réécrivez pas quatre fois et vous n'oubliez pas un serveur. Aucun serveur ne transporte de code qu'il n'utilise pas, donc sa configuration est exactement aussi complexe que ses besoins réels.
Ajouter un cinquième serveur ne signifie pas écrire un cinquième bot de zéro. On l'assemble à partir de ce qui existe déjà : on prend les cogs qui conviennent, on règle la configuration, et voilà. C'est la différence entre quatre projets séparés et un écosystème qui grandit en ajoutant des modules, pas en multipliant du code.
Plus de projets
D'autres réalisations de la même catégorie - découvrez comment nous abordons des défis similaires.
Vous avez un projet similaire ?
Contactez-nous - le devis est gratuit et arrive sous une heure.