Quel VPS me faut-il pour un bot Telegram ?

Le plus petit. Un bot Telegram est surtout au repos, à attendre des mises à jour, donc 1 Go de RAM et 2 cœurs suffisent amplement pour la plupart des bots — même assez chargés. Vous n'avez besoin de plus que si le bot fait lui-même un travail lourd (traitement d'image, un modèle local, une grosse base de données).

Comment garder un bot Telegram en marche après avoir fermé SSH ?

Faites-le tourner comme un service systemd. Contrairement à un lancement dans votre terminal, systemd le garde en vie après votre déconnexion, le redémarre s'il plante, et le relance après un redémarrage. C'est la différence entre un jouet et quelque chose qui reste debout.

Pourquoi mon bot s'arrête-t-il quand je me déconnecte ?

Parce que vous l'avez démarré dans votre session SSH, il meurt donc quand cette session se termine. Enveloppez-le dans un service systemd (ou tmux pour un test rapide) et il tourne indépendamment de votre connexion.

Ai-je besoin d'un domaine ou d'un webhook pour un bot Telegram ?

Non. Le long polling (getUpdates) ne nécessite aucune URL publique, aucun domaine, aucun port entrant — le bot va vers Telegram. C'est pourquoi un VPS NAT sans IP dédiée convient parfaitement à un bot. Les webhooks sont une optimisation facultative pour un gros volume.

Est-il sûr de mettre le jeton de mon bot sur un VPS ?

Oui, si vous le traitez comme un mot de passe : gardez-le dans une variable d'environnement ou un fichier lisible uniquement par l'utilisateur du bot, ne le commitez jamais dans git, et verrouillez le serveur avec des clés SSH. Si un jeton fuit, révoquez-le dans BotFather et émettez-en un nouveau.

Comment héberger un bot Telegram sur un VPS (et le garder en marche)

Un bot Telegram qui ne tourne que tant que votre portable est ouvert n'est pas vraiment en marche — il fait une démo. Pour l'avoir réellement en ligne, répondant à 3 h du matin, survivant à vos redémarrages et à ses propres plantages, il doit vivre sur un serveur. Voici tout le chemin, du début à la fin, avec les commandes.

Bonne nouvelle d'abord : un bot est une charge minuscule. Il reste surtout au repos à attendre des messages, donc la machine la moins chère le fait tourner très bien — sans IP dédiée, sans domaine, rien de sophistiqué.

1. Obtenez un jeton de BotFather

Dans Telegram, écrivez à @BotFather, envoyez /newbot, choisissez un nom et un nom d'utilisateur. Il vous remet un jeton qui ressemble à 12345:AAH.... Traitez-le comme un mot de passe — quiconque l'a contrôle votre bot.

2. Un bot minimal

Connectez-vous en SSH au serveur, configurez Python et la bibliothèque :

sudo apt update && sudo apt install -y python3-venv
mkdir ~/mybot && cd ~/mybot
python3 -m venv venv && source venv/bin/activate
pip install python-telegram-bot

Un bot qui répond — ~/mybot/bot.py :

import os
from telegram.ext import ApplicationBuilder, CommandHandler

async def start(update, ctx):
    await update.message.reply_text("Alive and on a server. 🟢")

app = ApplicationBuilder().token(os.environ["BOT_TOKEN"]).build()
app.add_handler(CommandHandler("start", start))
app.run_polling()

Remarquez qu'il lit le jeton depuis une variable d'environnement — pas en dur. C'est important à l'étape suivante.

3. La partie qui le garde réellement en marche : systemd

Si vous lancez juste python bot.py, il meurt dès que vous fermez SSH. Un service systemd est ce qui le fait survivre à la déconnexion, aux plantages et aux redémarrages. Créez /etc/systemd/system/mybot.service :

[Unit]
Description=Telegram bot
After=network-online.target

[Service]
WorkingDirectory=/home/youruser/mybot
Environment=BOT_TOKEN=12345:AAH...your-token
ExecStart=/home/youruser/mybot/venv/bin/python bot.py
Restart=always
RestartSec=5
User=youruser

[Install]
WantedBy=multi-user.target

Puis :

sudo systemctl daemon-reload
sudo systemctl enable --now mybot
sudo systemctl status mybot      # devrait indiquer active (running)
journalctl -u mybot -f           # journaux en direct

Restart=always est la ligne qui fait le vrai travail — un plantage, et il revient en 5 secondes. enable signifie qu'il remonte après un redémarrage. C'est toute la différence entre « j'ai fait tourner un bot une fois » et « mon bot est debout ».

4. Pourquoi pas de domaine ni de ports ouverts

Le bot utilise le long polling — il va chercher les mises à jour chez Telegram, donc rien n'a besoin d'entrer. Pas d'URL publique, pas de règle de pare-feu entrante, pas d'IP dédiée. C'est exactement pourquoi un VPS NAT (IP partagée, SSH sur un port) est un foyer parfait et bon marché pour un bot. Les webhooks existent pour de très gros volumes, mais vous n'en avez presque certainement pas besoin pour démarrer.

Réserves honnêtes

Hygiène du jeton : ici il est en clair dans le fichier d'unité pour la clarté — acceptable sur une machine verrouillée, mais pour tout ce qui est partagé, chargez-le depuis un EnvironmentFile accessible root uniquement, et ne le commitez jamais dans git. Fuité ? Révoquez dans BotFather, émettez-en un nouveau.
Bots lourds : si votre bot fait lui-même le travail (génération d'images, un modèle local), il n'est plus minuscule — dimensionnez en conséquence.

C'est tout. Verrouillez d'abord la machine avec la checklist de sécurité, déposez le service, et votre bot reste en ligne que vous le soyez ou non. Sur un VPS payé en crypto, vous pouvez l'avoir en marche une minute après l'avoir décidé.