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

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

Construire un Noyau Unifié avec des APIs : Mon Exemple “WeatherBrain”

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

WeatherBrain est simplement une application Flask Python simple (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’il est appelé, il interroge une vraie API météo externe (comme OpenWeatherMap ou AccuWeather), traite les données, et renvoie 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 simplifié de Flask)
from flask import Flask, request, jsonify
import requests
import os

app = Flask(__name__)

# Ceci serait idéalement 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 la 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() # Lever 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 des données 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)

Désormais, mes bots Telegram et Discord ne parlent plus directement à OpenWeatherMap. Ils parlent à WeatherBrain. C’est un énorme avantage ! Si je souhaite passer d’OpenWeatherMap à AccuWeather, je change uniquement le code dans weather_brain_api.py. Les bots ne savent même pas que cela s’est produit.

Bots Telegram et Discord : Devenir des Clients Légers

Avec WeatherBrain s’occupant de la charge lourde, mon code réel des bots Telegram et Discord est devenu beaucoup plus simple. Ils agissent désormais comme des “clients légers” ou des “adaptateurs.” Leur travail consiste purement à :

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. Formater cette réponse JSON en un message spécifique à la plateforme.
6. Envoyer le message à l’utilisateur.

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

# telegram_bot.py (simplifié)
import telebot
import requests
import os

TELEGRAM_BOT_TOKEN = os.environ.get("TELEGRAM_BOT_TOKEN")
WEATHER_BRAIN_API_URL = "http://localhost:5001/api/weather" # Ou l'URL de votre API déployée

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]
 
 # Appeler l'API interne
 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 pour 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 ne peux pas récupérer la météo en ce moment. Mon cerveau semble être en train de faire une sieste.")
 print(f"Erreur lors de l'appel à l'API WeatherBrain : {e}")
 except Exception as e:
 bot.reply_to(message, "Une erreur inattendue est survenue. 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 en double et facilite l’ajout de fonctionnalités ou la correction de bogues.

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

Cette approche pilotée par 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 web est en panne, votre service de surveillance peut envoyer un webhook à votre WeatherBrain (ou une API « NotifierBrain » distincte). Cette API décide ensuite quelles plateformes notifier (Telegram, Discord, email, SMS) et quel message envoyer, en transmettant les données d’alerte structurées à chaque adaptateur de plateforme.

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

Leçons Pratiques pour Votre Prochain Projet de Bot

Si vous construisez un bot, en particulier un que vous envisagez d’étendre à plusieurs plateformes ou d’ajouter des fonctionnalités complexes, prenez en compte ces points :

1. Isoler Votre Logique Principale : Avant même de toucher à une API spécifique à la plateforme, notez (ou codez) ce que votre bot fait fondamentalement. De quelles données a-t-il besoin ? Quels calculs effectue-t-il ? C’est votre « cerveau. »
2. Construire une API Interne (Même Simple) : Que ce soit une application Flask, un service FastAPI ou simplement un module Python bien organisé avec des fonctions claires, créez une couche qui encapsule votre logique principale et renvoie 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, puis de traduire les réponses de l’API interne en messages adaptés à cette plateforme. Ils doivent ê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 survenir à tout moment. Assurez-vous que chaque couche gère gracieusement les échecs de la couche en dessous d’elle et fournit un retour d’information informatif (mais pas trop technique) à l’utilisateur.
5. Tenir Compte du Déploiement : Si votre API interne est un service distinct, vous devrez la 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 par 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 fait gagner d’innombrables heures de débogage et m’a permis de faire évoluer mes bots beaucoup plus efficacement. La configuration initiale peut sembler un peu plus de travail, mais croyez-moi, les avantages à long terme en termes de maintenabilité, d’évolutivité et, honnêtement, de votre propre santé mentale, en valent absolument la peine. Bonne construction de bots !

🕒 Published: March 26, 2026