Contexte
Un serveur Discord actif finit toujours par avoir les mêmes besoins : donner envie de revenir, animer sans y passer ses soirées, modérer sans arbitraire. La réponse habituelle consiste à empiler cinq ou six bots publics, chacun avec sa configuration, ses limites et son abonnement.
Axobot remplace cette pile par un bot unique, taillé pour un usage réel et non pour un catalogue de fonctionnalités. 36 modules, 52 commandes slash, une base de données commune, et surtout une boucle de rétroaction très courte : ce qui manque un soir est souvent livré la semaine suivante.
Ce que fait le bot
- Gamification : XP par messages et par temps en vocal, 13 rôles de niveau attribués automatiquement, classements, détection d’inactivité, paris sur l’XP.
- 80 hauts faits débloqués en cascade, avec déblocage idempotent : un même événement rejoué ne décerne jamais deux fois la récompense.
- Casino et économie virtuelle : machines à sous, blackjack, cagnotte progressive, boutique.
- Suivi e-sport : statistiques Valorant et TFT synchronisées automatiquement, classements dans les salons vocaux, pronostics, suivi de Formule 1.
- Animation : soirée hebdomadaire avec RSVP et relances par message privé, quiz, tirages au sort, anniversaires, comptes à rebours, récapitulatifs et rétrospectives annuelles.
- Modération : sanctions traçables, journal d’audit, boîte à suggestions et rapports de bogues.
- IA conversationnelle : le bot répond quand on le mentionne, avec un ton assumé, branché sur Llama 3.3 70B via Groq.
Architecture
Le projet est un monorepo npm workspaces en TypeScript ESM sur Node 22 : le bot communautaire, le bot RPG Axoquest et son application web partagent quatre bibliothèques communes (accès base, services, types, utilitaires). discord.js v14, PostgreSQL via Prisma (85 modèles), validation Zod, journalisation Pino, tests Vitest, exécution en production sous PM2.
Quelques conventions ont plus compté que le choix des briques :
- Plafond de 400 lignes par fichier, appliqué par la CI. La règle paraît arbitraire ; en pratique c’est elle qui a empêché les modules de devenir des blocs illisibles au bout de 230 versions.
- Services exportés comme objets, pas comme classes. Aucune injection de dépendances à câbler, des tests qui se contentent de passer des arguments.
upsertsystématique sur les profils utilisateur. Plusieurs commandes peuvent viser le même profil en parallèle ; c’est ce qui élimine la compétition d’écriture à la racine.- Effets secondaires en « tire et oublie ». Un haut fait ou une cagnotte qui échoue ne doit jamais faire échouer la commande qui l’a déclenché.
- Aucun identifiant Discord en dur : tout passe par la configuration, ce qui a rendu possible le passage au multi-serveur.
Qualité et livraison
La règle de test est simple et tenue : toute logique métier arrive avec ses tests, toute correction de bogue avec son test de non-régression, et on teste le comportement, pas l’implémentation. Les adaptateurs (commandes, gabarits d’affichage, dépôts) ne sont volontairement pas testés : leur couverture coûte cher et ne détecte rien.
La chaîne d’intégration continue vérifie types, lint (Biome), tests et taille des fichiers avant chaque fusion. Les 230 versions publiées suivent un versionnage sémantique strict, et chaque note de version est rédigée pour les joueurs, sans jargon technique. Une documentation VitePress couvre le guide utilisateur et la documentation technique.
Suite du projet
Axobot a été conçu pour un serveur. Le rendre installable par n’importe quelle communauté a demandé une réécriture d’architecture complète : c’est Axo’s Corp, décrit en fin de l’étude de cas Axoquest.
Livrables clés
- Bot Discord multi-modules : 36 modules, 52 commandes slash
- Schéma PostgreSQL de 85 modèles, migrations écrites à la main
- Système de hauts faits idempotent à déblocage en cascade
- Intégrations Riot Games, Spotify et Groq
- Chaîne CI/CD, exécution PM2, stack locale Docker
- Documentation utilisateur et technique (VitePress), 230 notes de version