Bot Telegram : une requête reçue deux fois, une seule action à exécuter

Pour le support de Developers Map, j’ai construit un bot Telegram, une Mini App et une interface opérateur. L’un des enjeux était de préserver l’état d’un ticket lorsqu’une requête se répétait ou que Telegram acceptait une réponse sans que le programme reçoive de confirmation.

Une requête peut se répéter. Un opérateur peut recliquer sur le bouton. Telegram peut accepter un message, puis la connexion se couper avant que notre programme apprenne le succès. Pendant ce temps, l’utilisateur ouvre un deuxième ticket dans le même chat. Aucune malveillance n’est nécessaire : une connexion ordinaire sait organiser une petite crise toute seule.

Du menu au processus de travail

Pour Developers Map, j’ai créé un bot Telegram, une Mini App et une interface opérateur de support. C’est un outil distinct à côté du service principal ; cela ne fait pas de moi l’auteur de Developers Map et n’autorise pas le bot à modifier les comptes utilisateurs de la plateforme principale.

Cet écran montre l’interface de support d’origine avec des tickets préparés. Il permet de voir l’espace de travail à côté du bot, pas seulement son menu.

Vue d’ensemble du support

Interface archivée · données de démonstration

Il existe une base de réponses validée en russe et en anglais, plusieurs tickets dans un même chat et des pièces jointes dans un R2 privé. Les réponses AI sont désactivées dans cette implémentation. L’utilisateur reçoit un support prévisible, pas une invention libre du modèle sur le fonctionnement d’un produit tiers.

Un échange de démonstration apparaît dans un ticket. On peut tester les actions locales disponibles pour l’opérateur ; les vrais utilisateurs Telegram ne reçoivent rien de cette démo.

Conversation du ticket

Interface archivée · données de démonstration

D’abord l’événement, ensuite l’action

Les événements entrants sont stockés dans D1. Une file et un traitement périodique les transmettent au coordinateur du chat sur Durable Objects. Le moteur met ensuite l’état du ticket à jour et inscrit l’action sortante dans l’outbox, une table des envois préparés.

Cela lie le changement d’un ticket à l’intention d’envoyer un message dans une seule opération de base de données. Sinon, un monde intermédiaire étrange peut apparaître : le message est déjà parti, mais le système croit encore qu’il ne s’est rien passé. Ou l’inverse.

Les commandes de la Mini App disposent d’un identifiant stable et d’un contrôle de version. Une requête répétée est reconnue, et une action sur un ancien état ne doit pas écraser silencieusement le travail plus récent de l’opérateur.

L’état le plus intéressant : « résultat inconnu »

Si un envoi externe a peut-être déjà eu lieu, une répétition automatique peut créer un doublon. Un résultat incertain n’est donc pas traité comme une erreur ordinaire à réessayer immédiatement. Ici, la nouvelle tentative est une décision distincte de l’opérateur, prise en connaissance du risque.

Ce n’est pas la promesse d’une livraison mathématiquement parfaite. C’est une façon de ne plus cacher l’incertitude derrière un voyant vert.

Une instance fonctionnelle est déployée pour le pilote ; la recette utilisateur complète reste une étape distincte. WhatsApp et l’email ne deviennent pas des canaux connectés parce qu’ils ont figuré un jour dans un plan.

Une instance fonctionnelle est déployée pour le pilote. La démo permet de passer de la liste des tickets à la conversation opérateur ; la recette utilisateur complète n’est pas terminée. WhatsApp et l’email ne sont pas connectés, et les réponses AI sont désactivées dans cette implémentation.

À lire aussi : Le concept produit de Developers Map.