Faire tourner un bot Telegram 24/7 sur un VPS : aiogram, systemd, polling vs webhook

Vous avez écrit un bot Telegram avec aiogram, l'avez testé en local, et il marche. Maintenant il doit vivre quelque part qui ne dort pas quand vous fermez le portable. Un petit VPS est le foyer naturel — mais il y a un écart entre python bot.py dans une session SSH et un bot qui reste vraiment en marche à travers les crashs, les redémarrages, et la chute de votre connexion.

Voici la version de production : un virtualenv, le token gardé hors de votre code, un service systemd qui ressuscite le bot tout seul, et une réponse lucide à la question que tout le monde finit par poser — polling ou webhook ?

Pourquoi ne pas simplement le faire tourner sur votre portable

Un bot a besoin d'une connexion sortante stable vers Telegram. Votre portable se met en veille, redémarre pour des mises à jour, et saute entre les réseaux — chacun de ces événements coupe le bot, et les utilisateurs se heurtent à un mur de silence. Un VPS maintient cette connexion en continu. C'est toute la raison de le sortir de votre machine, et c'est la même raison pour laquelle un bot Discord a sa place sur un serveur aussi.

Si vous voulez juste le chemin le plus rapide pour « le mettre en ligne » avec un bot minimal, le guide pour héberger un bot Telegram couvre ça. Cet article va un cran plus loin : aiogram, gestion sûre du token, et savoir quand passer à l'échelle.

Le bot, dans un virtualenv

Connectez-vous en SSH et gardez le bot isolé dans son propre venv — n'installez pas de paquets à l'échelle du système, ça rend les mises à jour et le nettoyage pénibles plus tard :

sudo apt update && sudo apt install -y python3-venv
mkdir ~/tgbot && cd ~/tgbot
python3 -m venv venv && source venv/bin/activate
pip install -U aiogram

Un bot aiogram 3 minimal qui lit son token depuis l'environnement, pas depuis une chaîne codée en dur :

# bot.py
import asyncio, logging, os
from aiogram import Bot, Dispatcher
from aiogram.types import Message
from aiogram.filters import CommandStart

logging.basicConfig(level=logging.INFO)
dp = Dispatcher()

@dp.message(CommandStart())
async def start(m: Message):
    await m.answer("Vivant et en marche sur un VPS.")

async def main():
    bot = Bot(os.environ["BOT_TOKEN"])
    await dp.start_polling(bot)

if __name__ == "__main__":
    asyncio.run(main())

Gardez le token hors de votre code

Ne collez jamais le token de BotFather dans bot.py — un seul push vers un dépôt public et il fuit. Mettez-le plutôt dans un fichier d'environnement lisible par root :

sudo tee /etc/tgbot.env >/dev/null <<'EOF'
BOT_TOKEN=123456:votre-token-de-botfather
EOF
sudo chmod 600 /etc/tgbot.env

Un token qui a fuité est à un /revoke dans BotFather d'être corrigé — mais n'importe quoi d'autre qui fuit sur une machine partagée est pire. Un VPS dédié au bot est honnêtement un foyer plus sûr pour le token que votre portable quotidien : s'il fuit, vous faites tourner un token, pas toute votre installation.

La partie qui le garde en vie : systemd

C'est ce qui sépare un bot qui tourne d'un bot qui reste en marche. Créez le service :

# /etc/systemd/system/tgbot.service
[Unit]
Description=Telegram bot (aiogram)
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/tgbot
EnvironmentFile=/etc/tgbot.env
ExecStart=/home/botuser/tgbot/venv/bin/python bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Faites-le tourner en utilisateur non-root (botuser ci-dessus), pas root — si le bot est un jour compromis, vous le voulez confiné. Puis :

sudo systemctl daemon-reload
sudo systemctl enable --now tgbot

Restart=always avec RestartSec=3 signifie qu'un crash — une mauvaise mise à jour de Telegram, une exception non gérée, un OOM — ramène le bot en trois secondes au lieu de le laisser mort jusqu'à ce que vous le remarquiez. Regardez-le en direct :

journalctl -u tgbot -f

Voilà toute votre configuration de journalisation. Pas de fichiers de logs à faire tourner, pas d'outillage supplémentaire — journald l'a déjà.

Mettre à jour sans drame d'interruption

Quand vous changez le code ou montez la version d'aiogram :

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # si vous mettez à jour la bibliothèque
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # confirmer qu'il est revenu propre

Le redémarrage fait clignoter le bot une seconde ou deux. Pour un bot en polling, c'est invisible pour les utilisateurs — Telegram met les mises à jour en file et les délivre une fois que le bot se reconnecte.

Polling vs webhook — la version honnête

C'est la décision que les gens sur-analysent. Voici la version simple :

Le polling (start_polling, ce qu'utilise le code ci-dessus) fait demander au bot à Telegram « quoi de neuf ? » sur une connexion à longue durée. Il n'a besoin que d'un accès Internet sortant — pas de domaine, pas de TLS, pas de ports entrants ouverts. Il tourne très bien derrière du NAT. Pour l'écrasante majorité des bots, c'est correct et vous devriez vous arrêter ici.

Le webhook fait pousser les mises à jour vers vous par Telegram, ce qui veut dire que vous devez exposer un point de terminaison HTTPS public. Ça exige un domaine et un port entrant joignable — donc soit une IP publique dédiée, soit un reverse proxy devant. Plus d'installation, plus de choses qui cassent. Le gain, c'est une latence plus basse et moins de surcoût à grande échelle — des milliers d'utilisateurs simultanés, un gros volume de mises à jour.

La règle pratique : commencez par le polling sur un plan NAT. Passez à un webhook seulement quand vous avez réellement dépassé le polling — et si vous le faites, c'est là qu'une IP dédiée gagne sa place, parce que vous avez besoin de ce point de terminaison HTTPS entrant.

Ce que ça coûte de le faire tourner

Un bot en polling est léger. Il tourne au ralenti sur le long-poll de Telegram et réagit aux messages, donc la machine attend surtout :

• Nano à 3 $ (1 vCPU / 1 Go) — bien pour la plupart des bots, même assez bavards.
• Micro à 5 $ (2 vCPU / 2 Go) — quand le bot tient une base de données (SQLite/Postgres), gère du média, ou sert beaucoup d'utilisateurs.
• Plus haut seulement si le bot lui-même fait un vrai travail — traitement d'images, un modèle local, une logique lourde par message.

L'inscription est par e-mail uniquement et vous payez en USDC ou USDT sur Base ou Ethereum — pas de carte, pas de pièce d'identité. Une carte marche aussi, mais la rampe d'accès a un minimum d'environ 27 $, donc pour un plan à 3 $ il est plus fluide de recharger un petit solde une fois et de laisser les renouvellements y puiser. C'est du CPU uniquement, un datacenter en Allemagne — un non-problème pour un bot, bon à savoir si vous aviez besoin d'un GPU ou d'une région précise.

Le bilan honnête

Un bot Telegram est l'une des choses les moins chères que vous puissiez auto-héberger : une machine à 3 $, une unité systemd, et le polling vous donne un bot qui est en ligne à travers les crashs et les redémarrages sans que vous le surveilliez. Tournez-vous vers un webhook et un plan plus gros seulement quand l'échelle l'impose réellement — pas parce qu'un tutoriel vous a dit que les webhooks sont « mieux ». Prenez la petite machine, gardez le token dans un fichier d'environnement, laissez systemd gérer la disponibilité, et — avant tout le reste — déroulez la checklist de sécurité pour nouveau VPS pour que la machine elle-même soit verrouillée.

Prêt à héberger le vôtre ? Un bot Telegram utilise à peine des ressources — le plan Nano (3 $/mois) le fait tourner 24/7 sans souci.