Contexte technique
J'ai tout de suite vérifié le plus important : Codex n'a pas de connecteur officiel pour Telegram. Et c'est là que commence la véritable ingénierie, pas la magie des forums. Le schéma est simple : je configure un bot Telegram, il reçoit les messages et les transmet à Codex via un bridge ou une approche de serveur d'application compatible.
Dans les discussions, OpenClaw est souvent mentionné, et la logique est claire : il faut une couche capable de maintenir un dialogue, de transmettre des prompts et de renvoyer la réponse dans le chat. En termes simples, il s'agit d'une intégration d'IA entre l'API Bot de Telegram et l'environnement où s'exécute Codex.
Je diviserais les options en trois voies. La première, la plus terre-à-terre, est votre propre bridge en Node.js ou Python : polling ou webhook côté Telegram, puis un appel à la CLI de Codex ou à un backend associé, et enfin la réponse renvoyée au chat. La deuxième, un peu plus propre, concerne les serveurs MCP comme Composio, qui disposent déjà d'une couche prête à l'emploi pour Telegram. La troisième, la plus obscure, concerne les plugins communautaires pour un « serveur d'application », où tout dépend du dépôt spécifique et de sa maintenance.
C'est là que je m'arrête généralement pour examiner les détails. Si votre bridge se contente d'exécuter le texte entrant via la CLI, vous vous heurterez rapidement à des délais d'attente, des files d'attente, des problèmes de contexte de dialogue et de sécurité. Pour bien faire les choses, il faut un stockage des conversations, des limites de commandes, un filtrage des fichiers et un worker distinct pour les tâches longues.
Hermes peut également être envisagé comme une couche d'agent, mais c'est une architecture différente. Dans ce cas, Telegram devient non seulement un chat, mais un point d'entrée pour un agent doté d'outils, de mémoire et de règles d'exécution. Pour un simple bot, c'est souvent excessif.
Ce que cela change pour l'entreprise et l'automatisation
Je ne vois pas cela comme un « petit bot dans une messagerie », mais comme un point d'entrée à faible coût dans l'automatisation par l'IA. L'équipe écrit dans Telegram, et Codex traite les tâches, génère du code, répond aux questions de la documentation ou exécute des chaînes de routine sans interface dédiée.
Les petites équipes qui ont besoin de tester rapidement une hypothèse sans créer une interface à partir de zéro sont gagnantes. Les perdants sont ceux qui le déploient en production sans contrôle d'accès, journalisation et files d'attente : un tel pont peut facilement devenir une source de fuites et de chaos.
Je ne vendrais pas cela comme un produit final prêt à l'emploi. C'est une bonne couche pour un projet pilote, un assistant interne ou un flux de travail de support/développement, à condition que l'architecture de l'IA soit soigneusement conçue autour des rôles, du contexte et des limitations.
Si vous avez une tâche similaire et que vous souhaitez une automatisation intelligente et sensée pour des processus réels, et non un autre bridge bancal, vous pouvez simplement nous présenter votre scénario. Au Nahornyi AI Lab, je construis ces connexions moi-même : j'analyse où Telegram accélère réellement le travail et où il vaut mieux créer une interface différente dès le départ, pour que Vadym Nahornyi n'ait pas à nettoyer vos bricolages avec vous plus tard.