Un tech lead d'une banque porte un bot Telegram pour OpenCode à 1298 étoiles GitHub grâce à des agents IA

Ruslan, tech lead dans une grande banque avec 15 ans d'expérience, a transformé en quelques mois une expérimentation annexe en son projet open source le plus visible. opencode-telegram-bot est un client Telegram pour OpenCode, un agent CLI populaire pour le code. Au moment de la publication de son retour d'expérience sur Habr, le dépôt compte 1298 étoiles sur GitHub et 48 contributeurs. Presque tout le code a été écrit par des agents, et l'auteur affirme n'avoir pratiquement pas regardé le code lui-même.

De l'idée au paquet npx en quelques semaines

L'idée est née pendant les vacances du Nouvel An 2026 : Ruslan avait installé Claude Code et voulait le piloter depuis son téléphone. Gemini lui a conseillé de parser la sortie de la TUI, et il a dû mettre le projet de côté. OpenCode l'a sorti d'affaire : l'outil peut tourner comme serveur et se piloter via une API, si bien que le client Telegram est devenu une affaire de quelques jours. Le langage a été choisi avec l'IA : à la place de Kotlin, qu'il utilise d'habitude, il a retenu TypeScript pour la praticité de l'API.

Le bot fonctionne en local et l'accès est limité à un seul utilisateur, dont l'identifiant est inscrit dans la configuration. Tout ce que fait l'agent arrive dans le chat : modifications de fichiers, commandes console, travail des sous-agents. Les diffs s'ouvrent depuis le téléphone sous forme de fichier texte, et le bot gère la reconnaissance et la synthèse vocales. Le modèle, l'agent, l'effort et le contexte sont accessibles dans une reply keyboard. Le bot fonctionne dans un seul fil, comme un terminal, et la commande /detach déconnecte la session en cours et envoie une notification à la fin de la tâche.

La préparation à la publication a pris environ trois semaines et a suivi un plan établi avec l'agent. Le .gitignore, la licence, CONTRIBUTING.

md et la CI/CD (linter, build et tests) ont été configurés. L'agent a retiré le code de débogage, traduit la documentation en anglais et nettoyé les commentaires en russe : ils étaient apparus parce que l'auteur échangeait avec les agents en russe, sans leur avoir fixé de règle. La localisation a été faite tôt et compte aujourd'hui 688 chaînes dans 12 langues.

La publication sur npm a été configurée en une heure environ, de sorte que l'installation se résume à une seule commande via npx. La version 0.1.

0 a été publiée en un seul commit dans un nouveau dépôt, pour ne pas exposer un historique chaotique.

Ce qui a rapporté des étoiles, et ce qui n'a pas marché

Au début, les étoiles venaient d'amis : il y en avait 8 au lancement. Ensuite, le rythme est resté à 2 à 3 par semaine. L'agent a recommandé Reddit et Hacker News. Le post dans r/opencodeCLI, rédigé par l'agent puis retouché selon les remarques de l'auteur, a obtenu +65 et 31 000 vues. Le premier jour, il a rapporté 30 étoiles ; une semaine plus tard, le projet en comptait plus de 100 et dépassait deux concurrents qui en avaient environ 20 chacun. Les autres posts sur Reddit ont réuni entre 10 000 et 15 000 vues, sans produire de hausse notable. Sur Hacker News, personne n'a réagi.

Le trafic régulier est venu de la recherche. Après 5 à 6 semaines, le dépôt est apparu parmi les premiers résultats de Google pour des requêtes comme « OpenCode Telegram Bot ». La page reçoit désormais environ 100 visiteurs par jour, ce qui représente 3 à 5 étoiles quotidiennes. La conclusion de l'auteur : il aurait fallu rendre le dépôt public tout de suite, pour qu'il soit déjà indexé au début de la promotion.

Comment fonctionne le pipeline d'agents

Au départ, Ruslan travaillait dans Claude Code sur Sonnet 4.5. Il n'utilisait pas Opus 4.5, car ce modèle consommait trop vite les limites de l'abonnement à 20 $. La qualité de Sonnet ne le satisfaisait pas : les fonctionnalités marchaient rarement du premier coup, et le modèle sautait souvent les tests pourtant mentionnés dans les instructions. Il a alors connecté son abonnement ChatGPT via OpenCode et est passé à GPT-5.3-Codex, puis à GPT-5.4. D'après lui, le nombre d'itérations de débogage a nettement baissé, et il a développé l'essentiel des fonctionnalités du printemps sur GPT-5.4.

Il a ensuite construit son propre workflow à partir de trois modes d'OpenCode : Ask pour la revue de code et les questions, Spec pour la planification, avec écriture du plan dans un fichier séparé, et Code pour l'implémentation. L'été dernier, il a ajouté Playwright MCP, et l'agent s'est mis à tester lui-même le bot via la version web de Telegram. Désormais, un sous-agent relecteur vérifie le plan, un autre sous-agent relit le code, et un sous-agent testeur déroule les scénarios.

Ruslan attribue à cette approche le fait d'avoir osé des refactorings qu'il repoussait jusque-là. Pour une partie des tâches, il va aujourd'hui plus loin : après le grooming et la spécification, un agent-manager lance des agents-développeurs dans des sessions distinctes et rend compte à l'auteur dans Telegram.

Les contributeurs sont arrivés au bout de 4 jours : la première pull request ajoutait la prise en charge d'un proxy. L'auteur reconnaît avoir soupçonné du code malveillant et avoir fait vérifier les changements par un agent. Il relit toujours le code reçu avec des agents et lance la fonctionnalité à la main.

Il accepte les petits correctifs après 1 à 2 tours de modifications, mais rejette souvent les évolutions plus importantes. Il refuse notamment la prise en charge des topics Telegram : l'architecture est taillée pour un seul fil, et la réécrire demande de la rigueur et des tests. Les releases sortent environ une fois par semaine, parfois avec des hotfixes, et certaines se composaient uniquement de pull requests de la communauté.

La recette est simple, mais elle a ses limites. C'est l'expérience d'un seul projet, dans une niche où l'intérêt était à son pic, et les résultats dépendent des plateformes et de la façon dont la recherche indexe le dépôt. Les conclusions sur la qualité des modèles ne reposent que sur les observations subjectives de l'auteur, sans benchmarks. La leçon pratique pour les développeurs : pour lancer un projet open source en marge de son travail principal, le plus rapide est de publier une version de base, de proposer une installation en une commande, de garder le dépôt public et de sortir régulièrement des mises à jour.