Introduction
Ça fait maintenant plus de neuf ans que je maintiens Mr. Robøt, un robot Discord de modération 100% français. Ce qui devait être un outil pour gérer un seul serveur est devenu, avec le temps, un projet suivi par plusieurs milliers de communautés. Si tu envisages de te lancer dans la maintenance d’un robot Discord, voici à quel point ça peut t’emmener loin.
Salut l’ami : 2017
Début 2017, Discord n’a qu’un an et demi d’existence : la plateforme est lancée en mai 2015, et son API officielle pour créer des robots n’arrive qu’en avril 2016, avec Airhorn Solutions comme tout premier robot officiel. L’anecdote est amusante : Airhorn Solutions est sorti un 1er avril, comme un poisson d’avril, et n’avait qu’une seule fonction, jouer un bruit de corne de brume dans un salon vocal. Il a quand même été utilisé plus de 500 000 fois en une semaine, sur plus de 8 000 serveurs, ce qui a convaincu Discord d’ouvrir sérieusement son API aux développeurs. À l’époque de la création de Mr. Robøt, la documentation existe déjà et n’est pas mauvaise, mais créer un robot reste nettement plus complexe qu’aujourd’hui.
Le déclencheur est simple : je gérais, avec un petit groupe de développeurs, un serveur qui grimpe à 500 membres en très peu de temps, et la modération manuelle devient intenable. Il me fallait un outil capable de tenir la communauté H24, même quand personne n’est connecté pour surveiller.
C’est comme ça qu’est né Mr. Robøt : anti-spam, commandes d’information sur le serveur et les membres, easter eggs pour les fans de la série Mr. Robot, et un filtre anti-insultes réactif. Je publie le robot officiellement le 1er mai 2017, et il devient rapidement l’un des tout premiers robots à gérer automatiquement insultes et spam sur Discord en France.
Ce qui commence comme un dépannage de weekend pour un seul serveur va, sur les neuf années suivantes, se transformer en un projet qui touche à l’infrastructure, à l’intelligence artificielle, à un modèle économique, et à la gestion d’une vraie communauté d’utilisateurs.
L’image de profil du robot a suivi cette évolution au fil des années, entre refontes graphiques et changements d’identité visuelle.
Un projet que je n’ai jamais fini de réécrire
Au départ, tout tient dans un seul fichier app.js, avec un antispam et un anti-insulte basique. Comme beaucoup de projets qui grossissent plus vite que prévu, cette architecture a fini par devenir intenable : en avril 2021, je réécris le robot entièrement à partir de zéro, autour d’un command handler pour mieux structurer la gestion des événements et des commandes. Je nomme cette version Whiterøse en interne, clin d’œil à la série Mr. Robot.
Réécrire un projet qui tourne déjà en production sur des milliers de serveurs, c’est un pari risqué : ça n’apporte rien de visible côté utilisateur dans l’immédiat, mais ça conditionne toute la vitesse de développement des années suivantes. C’est typiquement le genre de dette technique que je repousse, jusqu’à ce qu’elle devienne bloquante. Une décision comme celle-là, je la prends seul, sans équipe pour la challenger en amont ni pour absorber le risque si ça tourne mal en production.
Et ce n’était qu’une étape : les années suivantes, j’enchaîne plusieurs migrations lourdes (nouvelles versions de la librairie Discord.js, changement d’ORM, un test d’hébergement de base de données que j’ai annulé en moins de 24 heures) et, en 2023, une bascule complète des anciennes commandes vers le nouveau système d’Application Commands (Slash Commands) de Discord, un exercice classique, mais pas anodin quand des milliers de serveurs dépendent déjà des anciennes commandes.
Un exemple concret de ce que ça change au quotidien : pour les logs, en 2017, le robot cherchait le salon par son nom (#logs-mrrobot), sans rien enregistrer en base. Le vrai tournant vient de l’arrivée d’une base de données : le salon de logs est devenu configurable et stocké via son identifiant, plutôt que de dépendre d’un nom de salon qui pouvait être renommé ou supprimé par erreur. Aujourd’hui, cette configuration se fait directement depuis les Slash Commands, mais c’est la base de données qui a rendu ça possible.
Ça vaut aussi pour les permissions Discord demandées par le robot : plus un robot en cumule, plus il peut agir sur un serveur, jusqu’à des actions aussi radicales que le supprimer. Je limite les permissions demandées au strict nécessaire pour que chaque fonctionnalité marche, plutôt que de tout réclamer par facilité.
La stack technique
Aujourd’hui, le robot tourne sur Discord.js (Node.js
), hébergé sur un VPS et géré via PM2
. Autour de lui : MariaDB
comme base de données, interrogée via l’ORM Prisma
; Strapi
en back-office pour gérer le contenu ; et côté site web, Nuxt
couplé à Sass
. Rien d’exotique individuellement, mais faire cohabiter tout ça sur neuf ans, en suivant le rythme des changements d’API de Discord, demande un vrai travail de fond. Le tout est versionné sur GitHub
.
Pour tenir la charge de plusieurs milliers de serveurs, le robot tourne sous sharding manager : la charge est répartie automatiquement sur plusieurs shards, chacun gérant un sous-ensemble de serveurs, comme l’exige l’API de Discord au-delà d’un certain seuil. Côté budget, pour les curieux, l’infrastructure reste volontairement légère : environ 12 € par mois pour le VPS, plus le coût du nom de domaine.
La guerre d’usure contre les insultes déguisées
L’anecdote la plus révélatrice sur la maintenance au long cours, c’est sans doute la liste des mots que je filtre. Depuis 2017, j’ajoute constamment de nouvelles insultes et de nouvelles règles pour couvrir les variantes en “leet speak” (remplacer des lettres par des chiffres ou symboles, écriture phonétique, etc.). Aujourd’hui, la liste dépasse les 70 entrées avec leurs alternatives. Je dois l’améliorer en permanence : il y a toujours des petits malins pour trouver une nouvelle façon de contourner le filtre, et dès qu’une méthode circule, je dois l’ajouter à la liste avant qu’elle ne se généralise. Je valide et je déploie ça en production rapidement, pour limiter le plus possible le temps d’exposition au harcèlement sur ce réseau social.
Un exemple concret de dérapage : ma règle qui filtrait “pute” a longtemps bloqué au passage le mot “computer”, parce qu’il contient cette suite de lettres. Une regex trop large, de celles que je dois régulièrement corriger quand un faux positif remonte.
C’est un jeu du chat et de la souris permanent : dès qu’une règle bloque une insulte, les utilisateurs trouvent une nouvelle façon de la déguiser, et je dois retravailler régulièrement les filtres plutôt que de me contenter d’une simple liste de mots exacts. Cette vigilance, personne ne me la demande formellement : c’est moi qui la maintiens, semaine après semaine, parce que les communautés qui utilisent le robot en dépendent.
Le pari de l’IA, et ses faux positifs
En septembre 2025, j’introduis un filtre de modération basé sur l’intelligence artificielle, capable de détecter des insultes, propos homophobes, xénophobes ou toxiques au-delà d’une simple liste de mots. Cette version s’accompagne d’un vrai chantier produit : un système d’abonnements Premium natifs à Discord, pour réserver cette détection avancée aux serveurs abonnés.
Sauf que passer d’une liste figée à un modèle qui “interprète” le contexte amène son lot de faux positifs. J’ai eu besoin de plusieurs mois pour réajuster les seuils, notamment sur le vocabulaire de jeu vidéo (“nuke”, “tape”, “bg”) qui se faisait signaler comme du contenu problématique. Un problème classique dès que je remplace des règles déterministes par un modèle probabiliste : je dois réapprendre, en conditions réelles, où placer le curseur entre protection et liberté d’expression.
Le doute que je garde encore aujourd’hui ne porte pas tant sur la technique que sur le fond : le cyber-harcèlement ne s’arrête pas aux frontières d’un serveur Discord, et je ne sais pas si une IA, aussi bien calibrée soit-elle, suffira un jour à l’endiguer complètement.
Les Components V2 : refaire toute l’interface
Autre chantier de fond entamé sur la même période : je migre vers les Components V2 de Discord, un nouveau système de construction des messages introduit par Discord en 2025. Il remplace les embeds classiques par des blocs assemblables (conteneurs, texte, séparateurs, galeries média, boutons) qui permettent de composer des interfaces bien plus riches directement dans un message. Pour l’utiliser, un message doit être envoyé avec un flag dédié, ce qui désactive le contenu et les embeds traditionnels au profit de ces nouveaux composants. Discord documente le sujet en détail, avec un guide d’utilisation
et une référence complète des composants
.
Cette migration progressive s’est faite au fil des mises à jour : je redessine plusieurs commandes centrales (/aide, /whois, les commandes /paramètres-*), avec à chaque fois la même volonté d’un design cohérent avec le reste du robot. Comme pour la réécriture de 2021, ce n’est pas le genre de chantier qui se voit d’un coup : je le fais commande par commande, sur plusieurs mois, en acceptant que l’ancien et le nouveau système cohabitent le temps de la transition.
Anti-spam : une fonctionnalité qui revient de loin
Autre détail piquant : en mai 2026, je fais revenir une fonctionnalité anti-spam configurable, après plus de sept ans d’absence. Une brique présente dans les tout premiers usages du robot avait disparu pendant des années avant que je la reconstruise avec des seuils paramétrables. Quelques semaines plus tard, j’ajoute un système de “honeypot”, en réponse à une vague précise : depuis quelques mois, des comptes se faisant passer pour des utilisateurs lambda rejoignent des serveurs, attendent plusieurs jours, puis spamment des images de cryptomonnaie dans tous les salons. Le honeypot exploite ce comportement : un salon ouvert, mais où personne n’écrit jamais, sert d’appât. Dès qu’un spammeur y poste un message, le robot le détecte, le bannit, et supprime tous ses messages sur le serveur, avec son lot de correctifs dans les jours qui suivent.
Rien n’est jamais vraiment fini : une fonctionnalité peut disparaître, revenir des années après, et continuer à demander des ajustements une fois en conditions réelles.
Ouvrir sans tout ouvrir
Un choix que j’assume dans la durée : le code source principal du robot reste fermé, mais la documentation, elle, est publiée en open source depuis fin 2023, avec pour objectif explicite de permettre à la communauté d’y contribuer. C’est une manière de rester transparent sur le fonctionnement sans exposer l’ensemble du code métier, et de laisser les retours de la communauté remonter via les issues et pull requests de ces dépôts publics (tests de packages, command handlers, entre autres).
Dans le même esprit de transparence, chaque changement apporté au robot est consigné dans un changelog public, qu’il s’agisse d’une nouvelle fonctionnalité, d’un correctif ou d’un ajustement mineur. Ça permet à n’importe qui de suivre l’évolution du projet dans le détail, sans avoir à éplucher le code source.
Sur le plan humain, c’est moi qui maintiens le projet, complété par des outils de maintenance automatisée (mises à jour de dépendances, correctifs de sécurité).
Maintenir seul, sur la durée
Écrire du code sur un projet, c’est une chose. Le maintenir seul pendant neuf ans, en parallèle du reste de ma vie professionnelle et personnelle, en est une autre. Chaque réécriture, chaque migration, chaque campagne de correctifs sur le filtre anti-insultes ou l’anti-spam, c’est moi qui la porte, du diagnostic jusqu’au déploiement en production. Le code n’est d’ailleurs qu’une partie du travail : je m’occupe aussi du design, des annonces au fil des mises à jour, de la gestion des partenariats, des réclamations reçues en privé, et de la gestion des réseaux sociaux du projet.
Cette responsabilité pèse d’autant plus que des milliers de serveurs et plus de 700 000 utilisateurs dépendent du bon fonctionnement du robot au quotidien : une régression sur un filtre, et ce sont des communautés entières qui se retrouvent exposées au spam ou au harcèlement, parfois sans que je m’en aperçoive tout de suite. Je dois maintenir une rigueur constante, même quand l’envie de lever le pied se fait sentir après plusieurs années sur le même projet. Sur ce plan-là, en neuf ans, je n’ai jamais eu à gérer de brèche de sécurité ou de compromission du token du robot, mais c’est une vigilance que je garde à chaque nouvelle intégration.
Ce qui me fait tenir sur la durée, c’est de voir que le robot reste concrètement utile à des modérateurs qui n’ont ni le temps ni les ressources de tout gérer à la main. Ça compense la charge, et ça justifie de continuer à investir du temps personnel dans un projet qui n’a jamais été une obligation. Si toi aussi tu maintiens un projet seul sur la durée, ce sentiment d’utilité concrète est probablement ce qui te fera tenir le plus longtemps.
Les chiffres
Aujourd’hui, Mr. Robøt tourne sur plus de 9 000 serveurs Discord, pour plus de 700 000 utilisateurs protégés.
Chaque année, je publie un petit récapitulatif en chiffres.
- En 2024 : environ 8 000 000 messages scannés et 18 300 insultes détectées.
- En 2025 : environ 7 500 000 messages scannés et 17 800 insultes détectées.
Des volumes qui restent stables d’une année sur l’autre, malgré tout ce qui a changé sous le capot entre-temps.
Sur les insultes détectées précisément, ça représente une baisse d’environ 2,6 % entre 2024 et 2025.
Sur le cumul, depuis juillet 2023 (date de mise en place du suivi actuel), le total dépasse les 25 millions de messages scannés et les 40 000 insultes détectées, hors détection par IA.
Près de 18 000 insultes détectées chaque année, ça rappelle une chose simple : le filtrage automatique reste indispensable. Discord ne couvre pas nativement tous les cas de harcèlement et d’insultes déguisées, et tant que ce sera le cas, un robot comme Mr. Robøt aura sa place pour protéger les communautés au quotidien.
Ce que 9 ans de maintenance m’ont appris
Quelques leçons que je retiens de ce parcours :
- Une réécriture complète, ça se prépare, mais ça se justifie. Elle ne change rien côté utilisateur le jour J, mais conditionne toute la vitesse d’itération des années suivantes.
- Rien n’est jamais fini. Une fonctionnalité peut disparaître, revenir des années après, et continuer à me demander des correctifs plusieurs jours après sa sortie.
- Ce qui commence petit peut prendre une ampleur inattendue. Un dépannage pour un seul serveur peut, en quelques années, devenir un projet mêlant infrastructure, IA, modèle économique et communauté.
- Un modèle probabiliste ne remplace pas un modèle déterministe du jour au lendemain. Passer d’une liste de mots à un filtre IA a demandé des mois de réajustement des seuils avant d’atteindre un niveau de fiabilité acceptable en production.
- La modération est un jeu du chat et de la souris sans ligne d’arrivée. Aucune règle ni aucun modèle ne reste efficace indéfiniment : il faut retravailler les filtres en continu, au rythme où les utilisateurs trouvent de nouvelles façons de les contourner.
- La transparence n’exige pas de tout exposer. Documenter et publier un changelog en open source, sans ouvrir le code métier, suffit à construire la confiance de la communauté et à recueillir ses retours.
En conclusion
Le fond de tout ça, ce n’est pas la stack technique ni les versions successives : c’est de donner aux communautés la liberté d’évoluer sans que qui que ce soit vienne les gêner, et de protéger chaque utilisateur des messages toxiques. Toutes les réécritures, tous les réglages de seuils, tout le temps passé sur la liste d’insultes, ça sert cet objectif-là. La technique change, se casse, se recalibre ; le pourquoi, lui, n’a pas bougé depuis 2017.
Neuf ans sur un même projet, c’est surtout neuf ans de petits ajustements successifs plutôt qu’une trajectoire linéaire : une réécriture totale, une fonctionnalité qui revient après sept ans d’absence, un filtre qui passe d’une liste de mots à de l’IA puis se fait recalibrer pendant plusieurs mois. Ce qui tient dans la durée, ce n’est pas un choix technique parfait dès le départ, mais la capacité à corriger en continu à partir de ce que mes utilisateurs, et mes logs, me remontent réellement.
Ça ne s’est pas fait sans creux. J’ai eu des moments où je n’avais plus d’idées, plus de motivation, où la peur de casser quelque chose en production me freinait, et où je craignais que les gens finissent par se lasser du projet. Sur certaines mises à jour, j’ai longtemps procrastiné avant de m’y mettre, plutôt que d’avancer dessus régulièrement. Ces phases-là font aussi partie des neuf ans, même si elles se voient moins qu’une nouvelle fonctionnalité.
Et la suite ?
J’ai déjà plusieurs idées pour la suite de Mr. Robøt. Je préfère les garder pour moi tant qu’elles ne sont pas prêtes plutôt que de les annoncer trop tôt, mais si tu veux rien rater, le plus simple pour toi, c’est de suivre le changelog ou de rejoindre le serveur Discord
du robot.
Remerciements
Merci à Lily (Nes), aux contributeurs lointains qui ont mis la main dans le code au fil de ces neuf années, et à Discord.js, sans qui rien de tout ça n’aurait été possible.
Sources : mrrobot.app/about, mrrobot.app/changelog
, github.com/mrrobotdotapp
, série d’articles techniques sur dev.to/mrrobot
.
Salut l’ami : C’est une référence à la série Mr. Robot, qui a inspiré le nom du robot et certaines de ses fonctionnalités.