Ma stratégie de commandes de bot pour Telegram & Discord

Salut tout le monde, Marcus ici de ai7bot.com. Nous sommes le 13 mars 2026 et je me débat avec un problème particulier récemment que je parie que beaucoup d’entre vous qui construisent des bots ont rencontré ou sont sur le point de le faire. Je parle de la gestion des commandes et des interactions des bots sur plusieurs plateformes sans perdre la tête. Plus précisément, je me suis penché sur Telegram et Discord, essayant de comprendre comment garder les choses simples lorsque votre bot doit faire des choses similaires dans les deux endroits.

Pendant un certain temps, mon approche était ce que j’appellerais une “duplication de force brute”. Si mon bot avait une commande /help sur Telegram, j’écrivais le code pour cela. Ensuite, si j’avais besoin d’une commande !help similaire sur Discord, je faisais essentiellement un copier-coller et je modifiais. Cela a fonctionné un moment, surtout quand mes bots étaient petits et ciblés. Mais à mesure qu’ils ont grandi et que j’ai commencé à ajouter plus de fonctionnalités, cela est devenu un cauchemar. Mettre à jour une commande signifiait mettre à jour deux, trois, voire plus d’endroits. Corrections de bogues ? Multiplier par le nombre de plateformes. C’était lent, sujet aux erreurs, et franchement, ça a ôté tout le plaisir de la construction.

Je me souviens d’une nuit tardive, probablement alimentée par trop de café et pas assez de sommeil, à essayer de déboguer pourquoi la commande /status de mon bot Telegram montrait des informations obsolètes alors que celle du bot Discord !status était parfaitement correcte. Il s’est avéré que j’avais mis à jour la source de données à un endroit et complètement oublié l’autre. C’était mon moment “aha !”. Il devait y avoir une meilleure solution. Et cette meilleure solution, pour moi, a été de me concentrer sur une approche API unifiée pour la logique de base du bot, en abstraisant autant que possible les éléments spécifiques à chaque plateforme.

La migraine des bots multi-plateformes : un vrai calvaire

Soyons honnêtes, construire un bot pour une seule plateforme est déjà suffisamment difficile. Vous devez faire face aux particularités des API, aux limites de taux, aux attentes des utilisateurs et à l’imprévisibilité générale d’internet. Ajoutez une deuxième, une troisième, voire une quatrième plateforme dans le mélange, et soudainement, vous ne construisez pas seulement un bot ; vous construisez une couche de traduction, un moteur de synchronisation, et un système de gestion de la santé mentale pour vous-même.

Mon premier bot, “WeatherBot 2000” (original, n’est-ce pas ?), a commencé sur Telegram. C’était simple : vous tapiez /weather <city> et il vous donnait les conditions actuelles. Super ! Puis un ami m’a demandé si je pouvais le mettre sur Discord. “Bien sûr !” ai-je dit, avec confiance. J’ai copié la logique de récupération de la météo, enveloppé cela dans un wrapper de commande Discord, et hop, “WeatherBot 2000” était aussi sur Discord, répondant à !weather <city>. Mission accomplie, ou du moins je le pensais.

Ensuite sont venues les demandes : “Peut-il afficher une prévision sur 3 jours ?” “Peut-il utiliser Celsius au lieu de Fahrenheit ?” “Peut-il également me dire la qualité de l’air ?” Chaque nouvelle fonctionnalité signifiait toucher le code à au moins deux endroits. La fonctionnalité de prévision, par exemple, nécessitait de changer la façon dont je parsemais la réponse de l’API météo et comment je formattais la sortie. Faire cela deux fois, une fois pour le Markdown de Telegram et une autre fois pour le Markdown légèrement différent de Discord (ou des embeds pour un aspect plus agréable), était fastidieux. Ce n’était pas juste un copier-coller ; c’était réimplémenter la logique de présentation.

Pourquoi séparer les préoccupations ? C’est une question de santé mentale.

Le cœur du problème était que ma “logique métier” (récupérer les données météorologiques, les traiter) était entremêlée avec ma “logique de présentation” (comment cela se présente sur Telegram, comment cela se présente sur Discord). C’est un problème classique dans le développement logiciel, et la solution, comme je l’ai appris à mes dépens, est de séparer ces préoccupations. Pensez à ça comme ceci :

• Logique de base : C’est ce que votre bot fait. Pour WeatherBot, c’est faire des appels API à un service météorologique, analyser la réponse JSON et extraire les données pertinentes. Cette partie devrait être indépendante de la plateforme.
• Adaptateurs de plateforme/Logique de présentation : C’est la façon dont votre bot parle sur chaque plateforme. Ce sont les appels API de Telegram, les appels API de Discord, la gestion des préfixes de commandes, le formatage des messages avec Markdown ou des embeds, l’envoi de fichiers, etc.

Lorsque vous gardez ces éléments séparés, vous pouvez mettre à jour votre logique de récupération des données météorologiques une seule fois, et cela bénéficie instantanément à vos bots Telegram et Discord. Si Telegram publie une nouvelle option de formatage de message élégante, vous n’avez qu’à mettre à jour votre adaptateur Telegram. La partie récupération de la météo reste intacte.

Construire un noyau unifié avec des APIs : Mon exemple de “WeatherBrain”

Après mon cauchemar de débogage, j’ai décidé de reconstruire “WeatherBot 2000” de A à Z, mais cette fois avec une séparation claire. J’ai créé une petite API interne pour la fonctionnalité de base de mon bot. Je l’appelle “WeatherBrain” (je travaille encore sur les noms, d’accord ?).

WeatherBrain n’est qu’une simple application Python Flask (cela pourrait être n’importe quoi, même un ensemble de fonctions dans une bibliothèque, mais une API facilite l’évolutivité et les tests indépendants). Elle expose des points de terminaison comme /api/weather?city=london&units=metric et /api/forecast?city=london&days=3. Lorsqu’ils sont appelés, ils contactent une API externe de météo réelle (comme OpenWeatherMap ou AccuWeather), traitent les données et renvoient une réponse JSON propre et cohérente.

Voici un aperçu simplifié de ce à quoi pourrait ressembler un point de terminaison WeatherBrain :

# weather_brain_api.py (exemple Flask simplifié)
from flask import Flask, request, jsonify
import requests
import os

app = Flask(__name__)

# Cela devrait idéalement être dans une configuration ou une variable d'environnement
WEATHER_API_KEY = os.environ.get("OPENWEATHER_API_KEY") 
OPENWEATHER_URL = "http://api.openweathermap.org/data/2.5/weather"

@app.route('/api/weather', methods=['GET'])
def get_current_weather():
 city = request.args.get('city')
 units = request.args.get('units', 'metric') # 'metric' ou 'imperial'

 if not city:
 return jsonify({"error": "Le paramètre de ville est requis"}), 400

 params = {
 'q': city,
 'appid': WEATHER_API_KEY,
 'units': units
 }

 try:
 response = requests.get(OPENWEATHER_URL, params=params)
 response.raise_for_status() # Lève une exception pour les erreurs HTTP
 data = response.json()

 # Traiter et simplifier les données
 weather_info = {
 "city": data['name'],
 "country": data['sys']['country'],
 "description": data['weather'][0]['description'].capitalize(),
 "temperature": data['main']['temp'],
 "feels_like": data['main']['feels_like'],
 "humidity": data['main']['humidity'],
 "wind_speed": data['wind']['speed']
 }
 return jsonify(weather_info)

 except requests.exceptions.RequestException as e:
 app.logger.error(f"Erreur lors de la récupération de la météo pour {city}: {e}")
 return jsonify({"error": "Impossible de récupérer les données météo"}), 500
 except KeyError as e:
 app.logger.error(f"Erreur de clé dans les données météo pour {city}: {e}")
 return jsonify({"error": "Format de données météo inattendu"}), 500

if __name__ == '__main__':
 app.run(debug=True, port=5001)

Maintenant, mes bots Telegram et Discord ne parlent pas directement à OpenWeatherMap. Ils parlent à WeatherBrain. C’est une grande victoire ! Si je veux passer d’OpenWeatherMap à AccuWeather, je change simplement le code dans weather_brain_api.py. Les bots ne savent même pas que cela s’est produit.

Bots Telegram et Discord : Devenant des clients légers

Avec WeatherBrain qui s’occupe du gros du travail, mon code de bot Telegram et Discord est devenu beaucoup plus simple. Ils agissent maintenant comme des “clients légers” ou des “adaptateurs”. Leur travail consiste uniquement à :

1. Écouter les commandes (par exemple, /weather <city> ou !weather <city>).
2. Analyser la commande et extraire les arguments.
3. Faire une requête HTTP à WeatherBrain.
4. Recevoir la réponse JSON de WeatherBrain.
5. Format un message spécifique à la plateforme à partir de cette réponse JSON.
6. Envoyer le message à l’utilisateur.

Voici un exemple simplifié de ce à quoi pourrait ressembler l’adaptateur Telegram :

# telegram_bot.py (simplified)
import telebot
import requests
import os

TELEGRAM_BOT_TOKEN = os.environ.get("TELEGRAM_BOT_TOKEN")
WEATHER_BRAIN_API_URL = "http://localhost:5001/api/weather" # Or the URL of your deployed API

bot = telebot.TeleBot(TELEGRAM_BOT_TOKEN)

@bot.message_handler(commands=['weather'])
def send_weather(message):
 try:
 args = message.text.split(maxsplit=1)
 if len(args) < 2:
 bot.reply_to(message, "Veuillez fournir une ville. Par exemple, `/weather London`")
 return

 city = args[1]
 
 # Call the internal API
 response = requests.get(WEATHER_BRAIN_API_URL, params={'city': city, 'units': 'metric'})
 response.raise_for_status()
 weather_data = response.json()

 if "error" in weather_data:
 bot.reply_to(message, f"Erreur : {weather_data['error']}")
 return

 # Format for Telegram
 output = (
 f"*{weather_data['city']}, {weather_data['country']}*\n"
 f"Météo : {weather_data['description']}\n"
 f"Température : {weather_data['temperature']:.1f}°C (Ressenti {weather_data['feels_like']:.1f}°C)\n"
 f"Humidité : {weather_data['humidity']}%\n"
 f"Vent : {weather_data['wind_speed']:.1f} m/s"
 )
 bot.reply_to(message, output, parse_mode='Markdown')

 except requests.exceptions.RequestException as e:
 bot.reply_to(message, "Désolé, je n'ai pas pu récupérer la météo pour le moment. Mon cerveau semble faire la sieste.")
 print(f"Erreur lors de l'appel à l'API WeatherBrain : {e}")
 except Exception as e:
 bot.reply_to(message, "Une erreur inattendue s'est produite. Veuillez réessayer plus tard.")
 print(f"Erreur générale dans le bot Telegram : {e}")

bot.polling()

Et l’adaptateur Discord serait très similaire, utilisant simplement la bibliothèque Discord.py (ou ce que vous préférez) pour gérer les commandes et formater les messages avec la syntaxe spécifique de Discord (par exemple, des embeds pour des messages plus riches).

La clé ici est que les deux bots récupèrent les mêmes données structurées de WeatherBrain. Ils les présentent simplement différemment. Cela réduit considérablement le code dupliqué et facilite l’ajout de fonctionnalités ou la correction de bugs.

Au-delà des Commandes : Webhooks et Événements

Cette approche basée sur une API n’est pas seulement pour les commandes. Que se passe-t-il si votre bot doit réagir à des événements externes ? Supposons que vous ayez un bot de surveillance qui vérifie la disponibilité d’un site web. Lorsque le site est hors ligne, votre service de surveillance peut envoyer un webhook à votre WeatherBrain (ou à une API distincte “NotifierBrain”). Cette API décide alors quelles plateformes notifier (Telegram, Discord, email, SMS) et quel message envoyer, en passant les données d’alerte structurées à chaque adaptateur de plateforme.

C’est ici que la puissance se manifeste vraiment. Votre API centrale devient la seule source de vérité pour l’intelligence de votre bot, et les composants spécifiques à la plateforme ne sont que des canaux de communication.

Leçons Pratiques pour Votre Prochain Projet de Bot

Si vous construisez un bot, surtout un que vous prévoyez d’élargir à plusieurs plateformes ou d’ajouter des fonctionnalités complexes, considérez ces points :

1. Isoler Votre Logique Principale : Avant même de toucher à une API spécifique à la plateforme, écrivez (ou codez) ce que votre bot fait fondamentalement en gros. Quelles données lui faut-il ? Quels calculs réalise-t-il ? C’est votre “cerveau”.
2. Construire une API Interne (Même Simple) : Que ce soit une application Flask, un service FastAPI, ou juste un module Python bien organisé avec des fonctions claires, créez une couche qui encapsule votre logique principale et retourne des données structurées et cohérentes (JSON est parfait pour cela). Cela rend votre code testable et réutilisable.
3. Traiter les Bots Spécifiques à la Plateforme comme des Adaptateurs : Leur rôle est de traduire les entrées des utilisateurs en appels à votre API interne et ensuite de traduire les réponses de l’API interne en messages adaptés à cette plateforme. Ils devraient être “légers” – logique minimale, communication maximale.
4. Prévoir la Gestion des Erreurs : Lorsque vous avez plusieurs couches (bot de plateforme -> API interne -> API externe), des erreurs peuvent se produire à chaque étape. Assurez-vous que chaque couche gère gracieusement les échecs de la couche inférieure et fournit un retour informatif (mais pas trop technique) à l’utilisateur.
5. Considérer le Déploiement : Si votre API interne est un service distinct, vous devrez le déployer quelque part. Des services comme Heroku, Render ou même un petit VPS peuvent héberger ces microservices. Assurez-vous que vos bots de plateforme peuvent accéder à votre API interne (par exemple, si elle fonctionne localement, ils doivent être sur le même réseau ou accessibles via une URL publique).
6. Commencer Petit, Itérer : Vous n’avez pas besoin de construire une architecture massive de microservices dès le premier jour. Commencez avec une fonction principale, isolez-la, puis construisez votre premier adaptateur de plateforme. Au fur et à mesure que vous ajoutez plus de fonctionnalités ou de plateformes, vous élargirez naturellement votre API interne.

Adopter cette approche m’a permis d’économiser des heures de débogage et m’a permis de faire évoluer mes bots de manière beaucoup plus efficace. La configuration initiale peut sembler un peu plus de travail, mais croyez-moi, les avantages à long terme en termes de maintenabilité, de scalabilité et, franchement, de votre propre santé mentale, en valent vraiment la peine. Bonne construction de bot !

🕒 Published: March 26, 2026