Bot de modération Telegram
Un bot de modération conçu, développé et maintenu pour une communauté Telegram de plus de 20 000 membres, hébergé sur un VPS que je gère de bout en bout, avec un environnement de test séparé de la production et un déploiement entièrement automatisé.
Pourquoi ce projet
Une communauté de 20 000 utilisateurs génère un volume de messages impossible à modérer manuellement. Le bot filtre le spam, applique des sanctions automatiques et gère les rôles, en continu, sans intervention humaine.
Modérer une communauté aussi active en direct sur la production n'était pas une option viable : la moindre régression pouvait impacter 20 000 personnes en même temps. D'où le choix de séparer strictement un environnement de test d'un environnement de production, chacun avec son propre bot Telegram et sa propre base de données.
Comment c'est construit
Le bot tourne sur un VPS Linux que j'administre moi-même, en deux instances distinctes gérées par systemd : une pour les tests, une pour la production. Chacune a son propre processus, sa propre base SQLite et son propre token Telegram, ce qui isole complètement les deux environnements — une régression en test ne touche jamais les 20 000 membres de la communauté réelle.
Les actions de modération (bannissements, suppressions, sanctions)
passent par une file d'attente asynchrone que j'ai développée
moi-même en Python (asyncio), pour sérialiser les
appels à l'API Telegram, éviter le rate-limiting et garder des
écritures cohérentes sur SQLite.
GitHub Actions déploie sur le VPS via SSH. Les deux bots (test/prod) tournent en services systemd isolés, chacun avec sa base SQLite, et passent par une file d'attente asynchrone commune avant d'appeler l'API Telegram.
Ce que ça fait concrètement
- Deux environnements totalement isolés (test et production), chacun avec son propre processus systemd, sa propre base SQLite et son propre bot Telegram — un bug en test ne peut jamais atteindre la communauté réelle
- Redémarrage automatique du service en cas de crash grâce à systemd (
Restart=on-failure), sans intervention manuelle - File d'attente asynchrone maison qui sérialise les actions de modération (bannissement, suppression de message, sanction) pour respecter les limites de débit de l'API Telegram et éviter les écritures concurrentes sur SQLite
- Pipeline GitHub Actions qui lance les tests automatiquement à chaque push, puis déploie sur le VPS via SSH et redémarre le service concerné au merge sur la branche principale
- Logs consultables via
journalctlpour chaque service, pour diagnostiquer rapidement un incident