Telegram Serverless : héberger un bot sans serveur ni infra à gérer

Le 15 juillet 2026, la documentation officielle de Telegram détaille un service qui mérite l'attention de tout développeur qui a déjà bricolé un bot : Telegram Serverless. La promesse tient en une phrase : écrire le code d'un bot ou d'une Mini App et le faire tourner directement sur l'infrastructure de Telegram, sans serveur à louer, sans conteneur à garder en vie, sans couche de scaling à concevoir soi-même.

Un bot Telegram, à la base, c'est un programme qui réagit à des mises à jour : un message, un clic sur un bouton, une requête inline. Jusqu'ici, il fallait héberger ce programme quelque part de toujours disponible, joignable et sécurisé, puis le maintenir dans cet état. VPS, fonction cloud, panel d'hébergement : quel que soit le choix, la charge de maintenance restait la même. Telegram Serverless retire cette couche entièrement.

Le principe : trois briques, pas plus

Le modèle mental tient en trois éléments qui se répondent directement. Le dossier de projet, en local, contient le code : les handlers (un fichier par type de mise à jour Telegram), le code partagé dans lib/, et schema.js pour les tables de la base de données. Le cloud héberge la copie déployée de ces modules ainsi que la base de données du bot, qui persiste entre les invocations. Le CLI tgcloud fait le pont entre les deux : il montre les différences et synchronise. À aucun moment on ne se connecte en SSH quelque part.

Quand une mise à jour arrive, Telegram la route vers le handler correspondant (handlers/message.js, handlers/callback_query.js, etc.) et appelle son export par défaut. Cette fonction parle à l'API Bot et à la base de données via un SDK fourni nativement, puis retourne. C'est toute la boucle. Une mise à jour sans handler correspondant est simplement ignorée : on n'ajoute que les handlers dont on a réellement besoin.

Chaque exécution tourne dans un isolat V8 léger, placé à proximité des systèmes de Telegram. L'API Bot, une base SQLite et les requêtes HTTP sortantes sont disponibles à chaque module sans rien installer ni configurer.

Un bot complet en quelques lignes

La documentation fournit un exemple représentatif : un bot qui répond à chaque message et compte combien il en a reçu par discussion. La table se déclare dans schema.js :

import { table, integer } from 'sdk/db';

export const counters = table('counters', {
  chatId: integer('chat_id').primaryKey(),
  seen: integer('seen').notNull().default(0),
});

Puis handlers/message.js lit et met à jour cette table à chaque message reçu :

import { api, db } from 'sdk';
import { counters } from 'schema';
import { eq } from 'sdk/db';

export default async function (message) {
  const chatId = message.chat.id;
  const existing = await db.select().from(counters).where(eq(counters.chatId, chatId)).get();
  const seen = (existing ? existing.seen : 0) + 1;
  await db.insert(counters).values({ chatId, seen })
    .onConflictDoUpdate({ target: counters.chatId, set: { seen } })
    .run();

  await api.sendMessage({
    chat_id: chatId,
    text: 'Total de messages recus : ' + seen,
  });
}

Le déploiement tient en deux commandes :

npx tgcloud push     # envoie le code
npx tgcloud migrate  # crée la table counters

Le bot est alors en ligne, avec un état persistant, sans serveur derrière à surveiller.

Comment démarrer concrètement

Avant tout, il faut activer la fonctionnalité pour un bot déjà enregistré auprès de @BotFather : ouvrir le bot, puis Serverless, puis l'activer. Cela débloque le token d'accès CLI, les handlers, la librairie et la base de données.

• npm create @tgcloud/bot mon_bot puis cd mon_bot : scaffolde un projet complet (handlers/, lib/, schema.js, docs/), sans écraser de fichiers existants si on pointe vers un dossier déjà utilisé.
• npx tgcloud login : relie le projet au bot via le token CLI (format app<id>:<secret>, distinct du token de l'API Bot), stocké localement dans .tgcloud/, ignoré par git.
• npx tgcloud status et npx tgcloud diff : affichent, hors ligne, ce qui a changé localement par rapport à la copie déployée.
• npx tgcloud push puis npx tgcloud migrate : envoie le code, puis applique les changements de schéma. Les deux étapes sont volontairement séparées, un déploiement de code ne modifie jamais la base de données tout seul, une migration demande toujours une confirmation explicite.

À qui ça s'adresse

Telegram présente Serverless comme un backend général pour bots et Mini Apps, pas comme un gabarit pour un seul type d'usage. La documentation cite quatre familles de cas d'usage : les bots conversationnels avec état par utilisateur, les backends de Mini App qui servent du contenu dynamique, les jeux et outils (classements, quiz), et les automatisations qui appellent des API tierces en HTTP pour pousser des résultats dans une discussion.

Les limites à regarder avant de se lancer

La promesse séduit, mais deux réserves méritent d'être posées avant d'y engager un projet sérieux.

D'abord, l'enfermement technique. Le code s'écrit en modules JavaScript et ne tourne que sur l'infrastructure de Telegram : c'est justement ce qui rend le modèle simple, mais cela signifie qu'un projet Serverless ne se redéploie pas tel quel ailleurs. Si votre bot doit un jour partager sa logique avec un site web ou une autre messagerie, il faudra prévoir une couche d'abstraction, ou accepter une réécriture partielle.

Ensuite, le silence de la documentation sur les chiffres qui comptent pour un choix d'infrastructure : quotas d'exécution, limites de taille de la base SQLite, tarification au-delà d'un usage gratuit. Rien de tout cela n'apparaît dans la page officielle telle que publiée. C'est un point à vérifier directement auprès de Telegram avant de bâtir un service qui dépendrait de volumes importants.

Notre lecture chez CZSyn

Pour un développeur indépendant ou une PME française qui veut un bot Telegram utile rapidement (support client basique, notification interne, petit outil métier), Telegram Serverless supprime une vraie friction : plus besoin de choisir un hébergeur, de sécuriser un serveur, ni de surveiller sa disponibilité pour un service somme toute simple. Le workflow décrit (dossier versionné, déploiement atomique, migrations réfléchies et confirmées) est sain et rassurant, à des lieues du script lancé à la main sur un VPS oublié.

Notre réserve porte sur le passage à l'échelle et sur la portabilité. Dès qu'un bot devient un produit à part entière, avec une logique métier partagée ailleurs (site, application, autre canal de messagerie), le confort du tout-intégré Telegram se transforme en dépendance à gérer consciemment. Nous recommandons Telegram Serverless pour prototyper vite et pour des automatisations bornées à Telegram, et de garder une architecture découplée dès que le bot doit dialoguer avec un système d'information plus large.

Sources primaires

• Telegram, « Telegram Serverless », documentation officielle.
• Telegram, « Bots: An introduction for developers ».
• Telegram, « Telegram Bot API », référence officielle.