Construction d'un pont pour deux bots Telegram dans un seul chat de groupe : Sémantique de livraison via HTTP

Connecter deux bots Telegram indépendants dans un même groupe est plus difficile qu'il n'y paraît. Un développeur sur r/openclaw détaille son expérience de construction d'une couche de pont, car Telegram ne livre pas de manière fiable les messages d'un bot à un autre dans un groupe — même si les humains voient les deux messages.
Le problème central
Telegram ne transmet pas les mises à jour au Bot B lorsque le Bot A envoie un message au groupe. L'équipe a donc construit un petit pont autour des limitations de Telegram :
- Bot B → Bot A : Le Bot B publie via un point de terminaison HTTP (tailgate) pour atteindre le Bot A.
- Bot A → Bot B : Le Bot A expose certains messages sortants via un flux contrôlé que le Bot B interroge.
- Les messages portent des métadonnées :
source,direction,chat ID,nonce, et un indicateursafe_to_bridge. - ACKs : Le Bot B peut accuser réception d'un message spécifique, confirmant qu'au moins un saut a fonctionné.
- Le flux partagé ne contient que le contexte de groupe sûr pour le pont — pas de DMs privés ni de trafic non lié.
- Le poller local du Bot B filtre les messages anciens/de débogage/protocole/statut, déduplique les événements, et ne laisse passer que les tours de conversation frais.
Leçons de la première version
L'implémentation initiale était trop laxiste : le contexte brut de Telegram fuyait dans le flux partagé, provoquant des moments déroutants du type « comment l'autre bot a-t-il su ça ? ». La solution a été de passer de logs bruts partagés à des événements explicitement sûrs pour le pont.
L'état actuel fonctionne dans des tests contrôlés :
- Bot B → Bot A via relais
- Bot A → Bot B via flux
- Les ACKs transitent par le chemin du relais
- Auto-miroir sûr pour les messages clairement adressés à un bot
Flux souhaité
La boucle de conversation cible :
- Un humain ou le Bot A écrit quelque chose adressé au Bot B.
- Le pont le reflète en toute sécurité.
- Le Bot B le voit une fois, répond une fois.
- La réponse est renvoyée si elle est sûre et pertinente.
- Pas de doublons, de backlog obsolète, de fuite de DM privé, d'écho de débogage ou de boucle de bots.
Direction architecturale
L'auteur suggère de traiter le pont comme un petit bus d'événements plutôt qu'un hack de chat :
- Identifiants de message et nonces stricts
- ACKs, déduplication, point de contrôle
- Flux délimités avec séparation stricte entre contexte privé et contexte sûr pour le groupe
La partie difficile réside dans la sémantique de livraison — fraîcheur, déduplication, ACKs et décision du moment où un bot doit répondre automatiquement sans créer de boucles infinies.
📖 Lire la source complète : r/openclaw
👀 See Also

Correction des erreurs 'Navigate Unsupported' et des plugins navigateur dans OpenClaw auto-hébergé sur Docker
Correction étape par étape pour les erreurs de permission EACCES, l'absence de Playwright et de binaires Chromium lors de l'auto-hébergement d'OpenClaw avec Docker sur un VPS comme Hostinger.

Configuration et tests de vLLM sur un serveur équipé de 10x NVIDIA V100 avec 320 Go de VRAM
Un avocat construisant un serveur IA local pour le travail juridique partage les résultats de tests vLLM sur 10 GPU Tesla V100 SXM2 32 Go, détaillant ce qui fonctionne (FP16 non quantifié, bitsandbytes 4 bits) et ce qui ne fonctionne pas (GPTQ, AWQ, FlashAttention2) sur l'architecture Volta.

Concevoir des contraintes pour la fiabilité des agents IA de qualité production
Un post Reddit détaille une approche basée sur des contraintes pour utiliser Claude dans des opérations complexes sur des bases de code, mettant l'accent sur l'énumération explicite des modes d'échec, l'exécution par phases avec des points de contrôle et des règles anti-raccourcis pour atteindre zéro build cassé lors de la suppression de 140 fichiers.

DeepSeek-V4-Flash W4A16+FP8 avec auto-spéculation MTP : 85 tok/s sur 2x RTX PRO 6000 Max-Q
DeepSeek-V4-Flash quantifié en W4A16+FP8 atteint 85,52 tok/s avec un contexte de 524k sur 2× RTX PRO 6000 Max-Q en utilisant un vLLM patché avec une tête MTP rétrofitée, contre 52,85 tok/s de référence.