VPS pour bot de trading : les vrais critères

Ce dont un bot de trading a besoin sur un VPS

Un VPS pour les bots de trading s’évalue sur quatre points : le processus redémarre-t-il après un arrêt, l’horloge est-elle exacte, les clés d’API (interface de programmation d’application) sont-elles difficiles à dérober et êtes-vous informé lorsqu’il s’arrête. La vitesse brute est loin d’être prioritaire pour un bot destiné aux particuliers, car la partie lente du cheminement de votre ordre dépend de votre broker et de la distance qui vous en sépare, et non de l’hôte qui exécute votre code Python.

Ce guide porte sur l’ingénierie. Il ne constitue pas un conseil financier et ne traite d’aucune stratégie.

La disponibilité repose sur une discipline de redémarrage, pas sur un chiffre affiché sur une page commerciale

Tous les hôtes du monde annoncent une disponibilité de 99.9 %. Ce chiffre décrit l’hyperviseur, pas votre bot. Un bot s’arrête à cause d’une exception non gérée, d’une websocket qui ne se reconnecte jamais ou du tueur OOM (out of memory), alors que le serveur reste disponible pendant tout ce temps. La question utile est donc de savoir ce qui se passe dans les dix secondes suivant l’arrêt de votre processus.

Exécutez le bot comme un service systemd et laissez le système init gérer le redémarrage. Un fichier unit suffit pour cela, en six lignes.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 est la ligne que l’on oublie souvent. Par défaut, systemd abandonne après 5 redémarrages en 10 secondes et laisse définitivement l’unit dans l’état failed, ce qui est exactement le comportement à éviter à 03:00. Définir cette valeur sur 0 désactive la limitation de fréquence. Ainsi, un bot qui entre dans une boucle de crash continue d’essayer au lieu de rester silencieux. RestartSec=10 arrête cette boucle afin qu’elle ne surcharge pas l’exchange de reconnexions.

Vérifiez le fichier avant de lui faire confiance, puis démarrez le service :

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable est la partie qui survit à un redémarrage, et les mises à jour du kernel imposent des redémarrages. Pour vérifier si le bot s’arrête discrètement, demandez à systemd le compteur de redémarrages :

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 après une semaine indique un bot sain. NRestarts=812 signifie que vous avez tradé avec un processus qui se reconnecte toute la nuit. L’anatomie complète du fichier unit, y compris les timers pour les tâches planifiées comme un rapport quotidien, est présentée dans exécuter un programme comme service systemd.

Régler l’horloge sur UTC et vérifier sa synchronisation

Les API d’exchange signent les requêtes avec un horodatage et rejettent toute requête en dehors d’une fenêtre, souvent de 5 secondes ou moins. Une horloge qui dérive produit des erreurs qui ressemblent à des échecs d’authentification. Vous pouvez donc renouveler les clés pendant des heures avant de vérifier l’heure. Sur les API de type Binance, le message est explicite : Timestamp for this request was 1000ms ahead of the server's time.

Configurez le serveur sur UTC. Les fuseaux horaires locaux introduisent un changement d’heure saisonnier qui surviendra au milieu d’une session de trading.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu fournit systemd-timesyncd, qui est un client SNTP (Simple Network Time Protocol). Il convient aux logs, mais il est insuffisant pour les usages qui doivent rester à quelques millisecondes près, car il interroge un seul serveur et ne corrige pas l’horloge en continu. Utilisez plutôt chrony :

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

La ligne à lire dans chronyc tracking est System time, par exemple System time : 0.000031415 seconds fast of NTP time. Une valeur inférieure à quelques millisecondes est normale. Si la valeur affichée est Leap status : Not synchronised, chrony n’a pas encore atteint de serveur, généralement parce que le trafic UDP sortant sur le port 123 est bloqué. Attendez une minute, puis vérifiez à nouveau avant de modifier les règles du firewall.

Gardez les clés API hors des emplacements que vous copiez

Une clé d’exchange divulguée est plus dangereuse qu’une clé SSH divulguée, car l’autorisation de retrait permet de transférer immédiatement les fonds. Deux pratiques couvrent la majeure partie du risque.

Tout d’abord, n’accordez jamais l’autorisation de retrait à une clé de bot. Lorsque l’exchange le permet, associez également la clé à l’adresse IP de votre serveur. C’est le seul contrôle qui rend une clé volée presque inutilisable.

Ensuite, gardez le secret hors du répertoire du code. Tout ce qui se trouve dans /opt/tradingbot finit tôt ou tard dans un dépôt git ou une archive de sauvegarde. Placez-le dans un fichier appartenant à root, que seul systemd peut lire :

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

Le fichier contient des lignes KEY=value simples, sans guillemets ni export. Le mode 640 avec le groupe bot permet à l’utilisateur du service de le lire, et à personne d’autre. Vérifiez avec sudo -u bot cat /etc/tradingbot/api.env, puis avec un autre utilisateur : l’opération doit échouer avec Permission denied.

Le bot lui-même ne doit pas s’exécuter en tant que root ni avec votre utilisateur de connexion. Créez un compte système sans shell et sans répertoire personnel dans lequel se connecter :

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

Le rôle de chacun de ces flags et la portée réelle de ProtectSystem=strict sont expliqués dans exécuter des services avec un utilisateur non privilégié. Le reste de la configuration de base du serveur, notamment les clés SSH et un firewall, est traité dans les dix premières minutes sur un nouveau VPS.

Détecter l’arrêt avant votre broker

systemctl status indique que le processus s’exécute. Cela n’indique pas que le bot fait quoi que ce soit. Un processus bloqué dans une boucle de nouvelle tentative vers un websocket hors service passe tous les contrôles que systemd peut effectuer.

Utilisez plutôt un heartbeat. Uptime Kuma propose des push monitors : il attend que votre bot appelle une URL selon une périodicité définie et vous alerte lorsque les appels cessent d’arriver. Placez cet appel à la fin de votre boucle principale, après la partie qui confirme que le bot est actif, par exemple après une lecture réussie des données de marché.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Définissez l’intervalle du monitor à environ deux fois la durée de votre boucle afin que les variations normales ne déclenchent pas d’alerte. Exécutez le monitor sur un serveur différent de celui du bot, car un monitor qui s’arrête avec le composant surveillé ne signale rien. La configuration est décrite dans la supervision d’état auto-hébergée avec Uptime Kuma.

Ajoutez également une alerte d’espace disque. Un bot qui écrit des logs détaillés remplira le système de fichiers root en quelques semaines. Un disque plein bloque l’écriture dans la base de données, mais pas l’appel réseau. Les symptômes sont donc difficiles à interpréter. journalctl --vacuum-time=14d et une ligne SystemMaxUse= dans /etc/systemd/journald.conf limitent la taille du journal.

La partie honnête : la latence ne vient généralement pas de votre hôte

C’est à ce stade que le marché des produits de trading VPS cesse d’être technique. Les pages marketing annoncent des chiffres inférieurs à la milliseconde et laissent entendre que l’hôte est ce qui vous sépare d’une exécution. Pour presque tous les bots de particuliers, ce n’est pas le cas.

Votre ordre circule entre le bot et le endpoint de l’exchange ou du broker via Internet public. Ce trajet dépend principalement de la distance physique et du peering entre votre fournisseur et le leur. Un serveur situé à Francfort qui communique avec un endpoint à Tokyo subit environ 250 millisecondes aller-retour, quelle que soit la vitesse du CPU. Les propres systèmes du broker ajoutent ensuite leur file d’attente, leurs contrôles de risque et leurs limites de débit. Pour un compte de particulier, ces délais se mesurent généralement en dizaines ou en centaines de millisecondes.

Mesurez au lieu de deviner. curl indique les temps de connexion et de réception du premier octet pour un endpoint réel :

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Exécutez cette commande depuis un serveur candidat avant de vous engager. Si connect vaut 0.180 seconde, vous êtes sur le mauvais continent et il faut corriger ce point. Si connect vaut 0.004 seconde et ttfb vaut 0.140 seconde, le délai restant vient du traitement du broker. Aucun changement d’hôte ne le réduira.

Dans quels cas l’hôte est-il important ? Lorsque vous êtes colocalisé ou connecté directement au venue et que vous êtes en concurrence pour la position dans la file d’attente. Il s’agit alors d’une activité différente, avec un budget différent. L’hôte compte également lorsque votre propre code est le bottleneck. Un bot qui recalcule les indicateurs sur tout l’historique à chaque tick peut consommer 200 millisecondes de CPU par boucle. Cette latence est réelle et vous pouvez la réduire gratuitement. Profilez la boucle avant de chercher un serveur plus rapide.

Les caractéristiques importantes de l’hôte choisi sont la situation géographique, la stabilité du réseau et une quantité de mémoire suffisante pour que l’OOM killer n’intervienne jamais. En juillet 2026, un bot Python utilisant une seule stratégie et quelques centaines de symboles en mémoire fonctionne confortablement avec 2 GB de RAM et 2 vCPU. Ajoutez de la mémoire si vous conservez l’historique des ticks dans une base de données locale.

Courte checklist avant la mise en production

1. systemctl is-enabled tradingbot affiche enabled, et le service survit à sudo reboot.
2. chronyc tracking indique un décalage de l’heure système inférieur à quelques millisecondes.
3. La clé API dispose de l’autorisation de trading, mais pas de l’autorisation de retrait. Configurez aussi une liste d’autorisation d’adresses IP si l’exchange en propose une.
4. L’arrêt du processus avec sudo systemctl kill -s SIGKILL tradingbot le relance dans un délai de RestartSec.
5. Le monitor de heartbeat vous envoie une alerte dans un intervalle lorsque vous arrêtez volontairement le bot.
6. La taille des logs est limitée et le système de fichiers root dispose d’espace disponible dans df -h.

Exécutez l’ensemble dans le sandbox de l’exchange ou en mode paper trading pendant une semaine avant d’utiliser des fonds réels. Chaque point ci-dessus échoue au moins une fois pendant cette semaine. C’est précisément l’objectif de cette période.

FAQ

Un bot de trading a-t-il besoin d'un serveur à faible latence ou bare metal ?

Uniquement si vous êtes en concurrence sur la vitesse d'exécution avec d'autres participants automatisés sur la même place de marché. Dans ce cas, la colocation est généralement plus adaptée qu'un VPS généraliste. Pour un bot de détail, le temps aller-retour dépend surtout de la distance géographique et du traitement du broker. Choisissez donc un serveur proche de l'endpoint de l'API et mesurez avec curl et mtr avant de payer pour une solution plus rapide.

De combien de RAM et de CPU un bot de trading a-t-il besoin ?

La plupart des bots à stratégie unique dépendent du réseau et restent inactifs entre les événements. En juillet 2026, 2 vCPU et 2 GB de RAM suffisent pour un bot Python qui suit quelques centaines d'instruments. La mémoire devient le facteur limitant lorsque vous conservez l'historique des ticks en mémoire ou exécutez une base de données locale. Surveillez donc free -h et le journal pour détecter les messages OOM kill au lieu de deviner.

Pourquoi l'API de mon exchange rejette-t-elle les requêtes avec une erreur d'horodatage ?

L'horloge du serveur a dérivé au-delà de la fenêtre de signature de l'exchange, généralement de quelques secondes. Installez chrony, vérifiez que chronyc tracking affiche un faible décalage de System time et un état leap synchronisé, puis configurez la machine en UTC afin qu'un changement d'heure d'été ne la décale jamais. La rotation de la clé d'API ne corrige pas un problème d'horloge.

Comment empêcher mon bot de s'arrêter pendant la nuit sans que je le sache ?

Exécutez-le sous systemd avec Restart=always et StartLimitIntervalSec=0 afin qu'une boucle de crash relance le processus au lieu de l'arrêter définitivement. Ajoutez ensuite un heartbeat envoyé par le bot à la fin de chaque boucle réussie. Le redémarrage gère l'arrêt du processus. Le heartbeat détecte le cas où le processus est actif mais bloqué.

Puis-je exécuter le bot et ma supervision sur le même VPS ?

Vous le pouvez, mais la supervision vous induira en erreur le jour où cela comptera, car une panne qui arrête le bot arrête aussi la supervision. Hébergez les alertes sur une machine distincte, idéalement chez un autre fournisseur ou dans une autre région, et utilisez le serveur du bot uniquement pour le bot et ses journaux.