Mon bot Telegram : Maîtriser la gestion des sessions

Salut tout le monde, ici Marcus d’ai7bot.com. Nous sommes le 14 mars 2026, et je suis tout excité par quelque chose qui me trotte dans la tête depuis un moment, surtout après un projet récent que j’ai terminé. Nous parlons beaucoup de bots ici – les construire, les utiliser, les optimiser. Mais aujourd’hui, je veux me concentrer sur quelque chose qui est souvent négligé jusqu’à ce qu’il vous pose problème : la gestion de l’état de votre bot. Plus précisément, je parle de la gestion des sessions dans les bots Telegram. Ce n’est pas le sujet le plus sexy, je le sais, mais croyez-moi, l’ignorer, c’est comme construire une maison sans fondation. Éventuellement, tout s’effondre.

Je viens de terminer un bot Telegram assez complexe pour le service de tutorat en ligne d’un ami. L’idée était simple : un bot qui permet aux étudiants de parcourir les tuteurs disponibles, de réserver des séances et même de reprogrammer – le tout dans Telegram. Ça semble simple, non ? Eh bien, ça l’était, jusqu’à ce que je commence à réfléchir à ce qui se passe lorsqu’un utilisateur est en train de réserver une séance, ferme Telegram, et revient une heure plus tard. Ou pire, s’ils commencent à réserver, se laissent distraire, puis essaient de commencer une nouvelle réservation sans avoir terminé la première. C’est là que la gestion de l’état devient critique.

Sans une gestion adéquate de l’état, votre bot peut se retrouver confus. Il peut demander des informations qu’il a déjà, proposer des options qui ne sont plus pertinentes, ou pire, perdre des données cruciales sur l’interaction d’un utilisateur. C’est comme avoir une conversation avec quelqu’un qui oublie tout ce que vous venez de dire toutes les quelques minutes. Frustrant, non ? Pour un bot, c’est une sentence de mort pour l’expérience utilisateur.

Pourquoi l’état du bot Telegram est important (plus que vous ne le pensez)

Pensez à une conversation typique avec un humain. Nous nous souvenons du contexte. Si je vous demande : « Quelle est votre couleur préférée ? » et que vous répondez « Bleu », puis je demande : « Pourquoi bleu ? », vous n’avez pas besoin de répéter « Ma couleur préférée est bleue parce que… ». Vous dites simplement : « Parce que c’est apaisant. » Votre cerveau maintient l’état de notre conversation. Les bots, par défaut, ne font pas ça. Chaque message qu’ils reçoivent est souvent traité comme une toute nouvelle interaction, dépouillée de tout contexte précédent, à moins que vous ne leur disiez explicitement le contraire.

Cela est particulièrement vrai pour les bots Telegram. L’API de Telegram est sans état en ce qui concerne le flux de conversation. Lorsque un utilisateur envoie un message, Telegram renvoie simplement ce message à votre bot. Il n’envoie pas de drapeau « hé, cet utilisateur parlait de X il y a deux minutes ». C’est à vous de le mettre en œuvre.

Mon bot de tutorat, par exemple, devait guider les utilisateurs à travers un processus en plusieurs étapes :

• Choisir une matière (Mathématiques, Physique, Chimie)
• Sélectionner un tuteur parmi les options disponibles pour cette matière
• Choisir une date et un créneau horaire
• Confirmer les détails de la réservation

Si un utilisateur choisissait « Mathématiques », je devais me souvenir de ce choix lors de la présentation des tuteurs. S’ils choisissaient ensuite un tuteur, je devais me souvenir à la fois de la matière et du tuteur lors de l’affichage des horaires disponibles. C’est l’essence de la gestion de l’état.

Approches de la gestion des sessions

Il existe plusieurs façons courantes de gérer cela, chacune avec ses avantages et inconvénients. J’ai expérimenté la plupart d’entre elles, et pour le bot de tutorat, j’ai fini par combiner plusieurs stratégies.

1. Stockage en mémoire (le plus simple et le plus risqué)

C’est là que vous stockez l’état de l’utilisateur directement dans la mémoire de l’application en cours d’exécution de votre bot. Pour un petit bot avec peut-être 10 utilisateurs, cela peut fonctionner. Vous pourriez avoir un dictionnaire où les clés sont les identifiants des utilisateurs et les valeurs sont des dictionnaires contenant leur état actuel (par exemple, {'user_id_123': {'step': 'choose_tutor', 'subject': 'Math'}}).

# Exemple utilisant Python (bibliothèque telebot)
user_states = {}

@bot.message_handler(commands=['start'])
def handle_start(message):
 user_id = message.from_user.id
 user_states[user_id] = {'step': 'welcome'}
 bot.send_message(user_id, "Bienvenue ! Quelle matière vous intéresse ?")

@bot.message_handler(func=lambda message: user_states.get(message.from_user.id, {}).get('step') == 'welcome')
def handle_subject_choice(message):
 user_id = message.from_user.id
 subject = message.text # Exemple basique, idéalement utiliser des boutons
 user_states[user_id]['subject'] = subject
 user_states[user_id]['step'] = 'choose_tutor'
 bot.send_message(user_id, f"Génial ! Affichage des tuteurs pour {subject}...")

Avantages : Extrêmement simple à mettre en œuvre pour des projets à petite échelle.

Inconvénients :

• Volatile : Si votre bot plante, redémarre ou est redéployé, tout l’état est perdu. Ce n’était pas envisageable pour mon bot de tutorat, imaginez un étudiant perdant son progrès de réservation.
• Non évolutif : Ne fonctionne pas si vous avez plusieurs instances de bot en cours d’exécution (par exemple, pour l’équilibrage de charge). Chaque instance aurait sa propre mémoire, entraînant des états incohérents.

J’ai utilisé cela pour un bot d’alerte personnel très simple une fois, et même alors, un redémarrage du serveur signifiait que je perdais mes rappels en attente. Leçon apprise.

2. Stockage en base de données (le cheval de bataille fiable)

C’est là que vont la plupart des bots sérieux. Vous stockez les données de session des utilisateurs dans une base de données persistante. Cela peut être une base de données relationnelle comme PostgreSQL ou MySQL, ou une base de données NoSQL comme MongoDB ou Redis. Pour le bot de tutorat, j’ai opté pour PostgreSQL car je l’utilisais déjà pour les données de tuteur et de réservation, et c’est super fiable.

Lorsqu’un utilisateur interagit, vous récupérez son état dans la base de données, traitez le message, mettez à jour l’état et le sauvegardez. Cela garantit la persistance et permet à plusieurs instances de bot d’accéder au même état centralisé.

# Exemple conceptuel avec un ORM de base de données hypothétique
# (En supposant que le modèle 'UserSession' existe avec les champs user_id, step et data)

def get_user_session(user_id):
 session = UserSession.query.filter_by(user_id=user_id).first()
 if not session:
 session = UserSession(user_id=user_id, step='start', data={})
 db.session.add(session)
 db.session.commit()
 return session

def update_user_session(user_id, step, data):
 session = get_user_session(user_id)
 session.step = step
 session.data = data # Stocker le contexte dans un champ JSONB ou similaire
 db.session.commit()

@bot.message_handler(commands=['start'])
def handle_start_db(message):
 user_id = message.from_user.id
 update_user_session(user_id, 'welcome', {})
 bot.send_message(user_id, "Bienvenue ! Quelle matière vous intéresse ?")

@bot.message_handler(func=lambda message: get_user_session(message.from_user.id).step == 'welcome')
def handle_subject_choice_db(message):
 user_id = message.from_user.id
 subject = message.text
 session_data = {'subject': subject}
 update_user_session(user_id, 'choose_tutor', session_data)
 bot.send_message(user_id, f"Génial ! Affichage des tuteurs pour {subject}...")

Avantages :

• Persistance : L’état survit aux redémarrages/plantes du bot.
• Scalabilité : Plusieurs instances de bot peuvent partager la même base de données.
• Auditabilité : Vous pouvez inspecter les sessions des utilisateurs directement dans votre base de données.

Inconvénients :

• Complexité accrue : Nécessite de mettre en place et de gérer une base de données.
• Latence : Les appels à la base de données ajoutent une petite surcharge, bien que généralement négligeable pour des interactions typiques avec le bot.

Pour mon bot de tutorat, c’était le choix évident. J’ai créé une simple table sessions avec user_id, current_step, et un champ jsonb pour session_data. Ce champ jsonb était crucial ; il me permettait de stocker toutes les informations dynamiques comme la matière choisie, l’ID du tuteur sélectionné, la date en attente, etc., de manière flexible.

3. Redis (l’alternative rapide pour un état temporaire)

Redis est un magasin de données en mémoire, souvent utilisé comme cache ou pour des données en temps réel. C’est incroyablement rapide. Bien qu’il soit en mémoire, il peut être configuré pour la persistance (instantanés RDB ou journalisation AOF), en faisant une bonne solution hybride pour la gestion des sessions où la vitesse est primordiale, ou pour des états temporaires et de courte durée.

# Exemple utilisant Python avec redis-py
import redis
import json

r = redis.StrictRedis(host='localhost', port=6379, db=0)

def set_user_state_redis(user_id, state_dict, expiry_seconds=3600): # Expiration d'1 heure
 r.setex(f"user_state:{user_id}", expiry_seconds, json.dumps(state_dict))

def get_user_state_redis(user_id):
 state_json = r.get(f"user_state:{user_id}")
 return json.loads(state_json) if state_json else None

@bot.message_handler(commands=['start'])
def handle_start_redis(message):
 user_id = message.from_user.id
 set_user_state_redis(user_id, {'step': 'welcome'})
 bot.send_message(user_id, "Bienvenue ! Quelle matière vous intéresse ?")

# ... et ainsi de suite, similaire à l'exemple de la base de données ...

Avantages :

• Ultra rapide : Bien plus rapide que les bases de données traditionnelles pour les lectures/écritures.
• Structures de données flexibles : Prend en charge divers types de données au-delà des simples paires clé-valeur.
• TTL (Temps de Vie) : Idéal pour expirer automatiquement les anciennes sessions.

Inconvénients :

• Consommation de mémoire : Peut être gourmand en mémoire pour un nombre très élevé de sessions actives.
• Configuration : Nécessite d’exécuter et de gérer une instance de Redis.

J’ai envisagé Redis pour le bot de tutorat, notamment pour le flux de réservation en plusieurs étapes où des recherches d’état rapides pourraient rendre l’expérience utilisateur plus réactive. En fin de compte, je me suis tenu à PostgreSQL pour garder la pile technologique plus simple, mais pour un bot gérant une très forte concurrence ou nécessitant une latence ultra-faible, Redis serait un fort concurrent.

4. Utiliser un framework de bot avec gestion d’état intégrée

Si vous utilisez un framework de bot comme ConversationHandler de python-telegram-bot, ou un framework plus général comme Rasa, ils sont souvent livrés avec leur propre gestion d’état sophistiquée. Ces frameworks masquent une grande partie de la complexité sous-jacente, fournissant des décorateurs ou des gestionnaires qui gèrent automatiquement le flux de conversation et l’état pour vous.

Mon bot de tutorat utilisait pyTelegramBotAPI, qui est à un niveau plus bas, donc j’ai développé ma propre gestion d’état basée sur une base de données. Mais si je devais créer un nouveau bot conversationnel complexe depuis zéro aujourd’hui, j’explorerais sérieusement des frameworks qui gèrent cela dès le départ. Ils font gagner un temps considérable sur le code de routine et empêchent les pièges courants.

Conseils Pratiques pour Votre Prochain Bot

1. Ne Ignorez Pas l’État : Même pour un bot simple, réfléchissez à la façon dont vous allez gérer l’interaction multi-étapes d’un utilisateur ou à combien de temps vous devez vous souvenir de ses préférences.
2. Choisissez Votre Stockage Judicieusement :
   • Pour des bots personnels minuscules où la perte de données est acceptable : En mémoire.
   • Pour des bots en production nécessitant persistance et évolutivité : Base de données (PostgreSQL, MongoDB).
   • Pour un état temporaire à haute performance où la rapidité est essentielle : Redis.
3. Concevez Votre Schéma d’État : Pensez à quelles informations vous devez stocker. Pour mon bot de tutorat, cela incluait user_id, current_step, et un champ générique jsonb pour des données dynamiques comme {'subject': 'Math', 'tutor_id': 5, 'selected_date': '2026-03-20'}. Cette flexibilité a été précieuse.
4. Mettez en Œuvre des Expirations : Que se passe-t-il si un utilisateur commence un flux et l’abandonne ? Pour mon bot de tutorat, j’ai ajouté un job cron pour vider les sessions “obsolètes” après quelques heures d’inactivité. La fonction TTL de Redis est excellente pour cela.
5. Gérez les Cas Particuliers : Que se passe-t-il si un utilisateur envoie /start au milieu d’une réservation ? Mon bot vérifie l’état actuel ; s’il est en cours de traitement, il demande s’il souhaite annuler le processus actuel ou continuer. Cela évite les situations confuses.
6. Envisagez d’Utiliser un Framework : Si vous construisez un bot conversationnel complexe, des frameworks comme ConversationHandler de python-telegram-bot ou même un framework NLU complet comme Rasa peuvent considérablement simplifier la gestion de l’état.

Créer des bots est amusant, mais les rendre solides et conviviaux demande de penser au-delà d’une simple réponse à une commande unique. La gestion des sessions est l’un de ces éléments peu glamour mais absolument essentiels du tableau. Si vous le faites bien, vos utilisateurs auront une expérience fluide et intuitive. Si vous vous trompez, ils abandonneront votre bot plus vite que vous ne pouvez dire “Erreur 404 : Contexte non trouvé.”

D’accord, voici mon avis sur la gestion des sessions pour les bots Telegram. Quelles sont vos expériences ? Avez-vous des histoires d’horreur ou des solutions astucieuses que vous avez mises en œuvre ? Laissez-les dans les commentaires ci-dessous !

🕒 Published: March 26, 2026