Mon bot Telegram : Maîtriser la gestion des sessions

Salut tout le monde, Marcus ici d’ai7bot.com. Nous sommes le 14 mars 2026, et je suis 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 créer, les utiliser, les optimiser. Mais aujourd’hui, je veux me concentrer sur un aspect souvent négligé jusqu’à ce qu’il devienne problématique : la gestion de l’état de votre bot. En particulier, je parle de la gestion de session 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. Au final, 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 sessions et même de reprogrammer – tout cela 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 session, 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 essentielle.

Sans une gestion adéquate de l’état, votre bot peut devenir confus. Il pourrait 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 le bleu 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 cela. Chaque message qu’ils reçoivent est souvent traité comme une toute nouvelle interaction, dépourvue de contexte précédent, à moins que vous ne leur disiez explicitement le contraire.

C’est particulièrement vrai pour les bots Telegram. L’API de Telegram est sans état en termes d’écoulement de conversation. Quand un utilisateur envoie un message, Telegram le transmet simplement à votre bot. Il ne transmet pas un drapeau « hey, cet utilisateur parlait de X il y a deux minutes ». C’est votre tâche à implémenter.

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

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

Si un utilisateur choisit « Mathématiques », je devais me souvenir de ce choix lors de la présentation des tuteurs. S’ils choisissent ensuite un tuteur, je devais me souvenir à la fois du sujet et du tuteur lors de la présentation des heures disponibles. C’est la quintessence de la gestion de l’état.

Approches de la gestion de session

Il existe quelques 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é)

Ici, 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 des ID d’utilisateur 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 ! Quel sujet 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 de base, idéalement, utilisez des boutons
 user_states[user_id]['subject'] = subject
 user_states[user_id]['step'] = 'choose_tutor'
 bot.send_message(user_id, f"Génial ! Voici les tuteurs pour {subject}...")

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

Inconvénients :

• Volatil : Si votre bot plante, redémarre ou est redéployé, tout l’état est perdu. Cela a été un frein pour mon bot de tutorat, imaginez un étudiant perdant ses avancées de réservation.
• Pas évolutif : Cela 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 un état incohérent.

J’ai utilisé cela pour un bot de rappel personnel super simple une fois, et même à ce moment-là, un redémarrage du serveur signifiait perdre mes rappels en attente. Leçon apprise.

2. Stockage en base de données (le fiabilisme)

C’est là où vont la plupart des bots sérieux. Vous stockez les données de session utilisateur dans une base de données persistante. Cela pourrait ê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 parce que je l’utilisais déjà pour les données de tuteurs et de réservations, et il est très fiable.

Lorsqu’un utilisateur interagit, vous récupérez son état à partir de la base de données, traitez le message, mettez à jour l’état, et le sauvegardez à nouveau. 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
# (Supposons 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 ! Quel sujet 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 ! Voici les tuteurs pour {subject}...")

Avantages :

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

Inconvénients :

• Complexité accrue : Exige la configuration et la gestion d’une base de données.
• Latence : Les appels de base de données ajoutent un léger surcoût, bien que généralement négligeable pour les interactions typiques avec un 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 m’a permis de stocker toutes les informations dynamiques comme le sujet choisi, l’ID du tuteur sélectionné, la date en attente, etc., de manière flexible.

3. Redis (l’alternative rapide pour l’é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. Il est incroyablement rapide. Bien qu’il soit en mémoire, il peut être configuré pour une 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 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 ! Quel sujet vous intéresse ?")

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

Avantages :

• Ultra-rapide : Beaucoup 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à du simple clé-valeur.
• TTL (Durée de vie) : Idéal pour expirer automatiquement les anciennes sessions.

Inconvénients :

• Consommation de mémoire : Peut être gourmand en mémoire pour un très grand nombre de sessions actives.
• Configuration : Nécessite de faire fonctionner et de gérer une instance Redis.

J’ai envisagé Redis pour le bot de tutorat, notamment pour le flux de réservation en plusieurs étapes où de rapides consultations d’état pourraient rendre l’UX plus réactive. En fin de compte, je suis resté avec PostgreSQL pour garder la pile technique 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 cadre 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 proposent souvent leur propre gestion d’état sophistiquée. Ces frameworks abstraient 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 plus bas niveau, alors j’ai développé ma propre gestion d’état basée sur une base de données. Mais si je devais aujourd’hui créer un nouveau bot conversationnel complexe à partir de zéro, j’examinerais sérieusement les frameworks qui s’occupent de cela dès le départ. Ils vous font économiser un tas de code de base et évitent des pièges courants.

Principaux enseignements pour votre prochain bot

1. Ne négligez pas l’état : Même pour un bot simple, considérez comment vous allez gérer l’interaction multi-étapes d’un utilisateur ou combien de temps vous devez mémoriser ses préférences.
2. Choisissez votre stockage judicieusement :
   • Pour de petits bots personnels 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 : Réfléchissez aux informations que 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é salvatrice.
4. Mettez en œuvre des délais d’expiration : 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 nettoyer les sessions « obsolètes » après quelques heures d’inactivité. La fonctionnalité TTL de Redis est excellente pour cela.
5. Gérez les cas particuliers : Que se passe-t-il si un utilisateur envoie /start en plein milieu d’une réservation ? Mon bot vérifie l’état actuel ; s’ils sont en cours de flux, il demande s’ils souhaitent annuler le processus en cours ou continuer. Cela évite des situations déroutantes.
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 simplifier immensément la gestion d’état.

Construire des bots est amusant, mais les rendre solides et conviviaux nécessite de penser au-delà de la simple réponse à une commande. La gestion de session est l’un de ces éléments peu glamour mais absolument essentiels du puzzle. Si vous le faites bien, vos utilisateurs auront une expérience fluide et intuitive. Si vous le faites mal, ils abandonneront votre bot plus vite que vous ne pouvez dire « Erreur 404 : Contexte non trouvé. »

Eh bien, voici mon avis sur la gestion de session pour les bots Telegram. Quelles sont vos expériences ? Des histoires d’horreur ou des solutions astucieuses que vous avez mises en œuvre ? Partagez-les dans les commentaires ci-dessous !

🕒 Published: March 26, 2026