Quel VPS choisir pour un bot de trading ?

Ce dont un bot de trading a besoin sur un VPS

Un VPS destiné à un bot de trading s’évalue selon quatre critères : le processus redémarre-t-il après un arrêt, l’horloge est-elle exacte, les clés d’API (application programming interface) sont-elles suffisamment protégées contre le vol, et êtes-vous informé lorsque le bot s’arrête ? Pour un bot de détail, la vitesse brute arrive loin derrière ces critères, car la partie la plus lente du chemin d’exécution de votre ordre est votre broker et la distance qui vous en sépare, pas l’hôte qui exécute votre code Python.

Il s’agit d’un guide technique. Ce document 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ébergeurs 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’un websocket qui ne se reconnecte jamais ou du tueur OOM (out of memory), alors que le serveur reste disponible pendant toute la durée de l’incident. La question utile est donc de savoir ce qui se passe dans les dix secondes qui suivent l’arrêt de votre processus.

Exécutez le bot comme un service systemd et laissez le système init gérer son redémarrage. Un fichier d’unité suffit 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 beaucoup oublient. Par défaut, systemd abandonne après 5 redémarrages en 10 secondes et laisse l’unité indéfiniment dans l’état failed, ce qui est exactement le comportement à éviter à 03:00. La valeur 0 désactive la limitation de débit. Un bot qui boucle sur des crashs continue donc d’essayer au lieu de rester silencieux. RestartSec=10 empêche cette boucle de saturer l’exchange avec des 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 permet de survivre à un redémarrage, et les mises à jour du kernel nécessitent 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 d’un fichier d’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.

Configurer l’horloge en UTC et prouver qu’elle est synchronisée

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

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

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu fournit systemd-timesyncd, un client SNTP (simple network time protocol). Il convient aux journaux, mais il est insuffisant pour les applications 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 valeur à 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 réussi à joindre un serveur, généralement parce que le trafic UDP sortant sur le port 123 est bloqué. Attendez une minute, puis vérifiez de nouveau avant de modifier les règles du pare-feu.

Conservez les clés d’API en dehors 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 convertir immédiatement cette clé en argent. Deux habitudes couvrent la majeure partie du risque.

Premièrement, n’accordez jamais l’autorisation de retrait à une clé utilisée par un bot. Lorsque l’exchange le permet, liez également la clé à l’adresse IP de votre serveur. C’est le contrôle qui rend une clé volée presque inutilisable.

Deuxièmement, gardez le secret en dehors 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 interdit l’accès à tous les autres. Vérifiez avec sudo -u bot cat /etc/tradingbot/api.env, puis avec un autre utilisateur : l’opération doit alors échouer avec Permission denied.

Le bot lui-même ne doit s’exécuter ni avec 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

La raison de chacun de ces flags, ainsi que la portée réelle de ProtectSystem=strict, est expliquée dans exécuter les 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 décrit dans les dix premières minutes sur un nouveau VPS.

Détectez la panne avant votre broker

systemctl status indique que le processus fonctionne. Cela ne signifie pas que le bot effectue une action. Un processus bloqué dans une boucle de nouvelle tentative contre un websocket hors service passe toutes les vérifications possibles de systemd.

Utilisez plutôt un heartbeat. Uptime Kuma propose des monitors push : il attend que votre bot appelle une URL selon une fréquence définie et vous alerte lorsque les appels cessent d’arriver. Placez l’appel à la fin de votre boucle principale, après l’étape qui prouve que le bot fonctionne, par exemple 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 service qu’il surveille ne signale rien. La procédure est présentée dans la supervision de statut auto-hébergée avec Uptime Kuma.

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

La vérité : la latence ne dépend généralement pas de votre serveur

C’est à ce stade que le marché des produits VPS pour le trading cesse d’être technique. Les pages marketing annoncent des latences inférieures à la milliseconde et laissent entendre que le serveur est l’obstacle entre vous et l’exécution d’un ordre. Pour presque tous les bots de particuliers, ce n’est pas le cas.

Votre ordre transite entre le bot et l’endpoint de l’exchange ou du broker par Internet. 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 systèmes du broker ajoutent ensuite leur file d’attente, leurs contrôles de risque et leurs limites de débit. Pour un compte particulier, ces traitements se mesurent généralement en dizaines ou centaines de millisecondes.

Mesurez ces valeurs au lieu de les estimer. 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 ce point mérite d’être corrigé. Si connect vaut 0.004 seconde et ttfb vaut 0.140 seconde, le délai restant vient du traitement du broker. Aucun changement de serveur ne le réduira.

Dans quels cas le serveur compte-t-il alors ? Lorsque vous êtes en colocation ou connecté directement à la plateforme et que vous êtes en concurrence sur la position dans la file d’attente. Il s’agit d’une activité différente, avec un budget différent. Le serveur compte également lorsque votre propre code est le goulot d’étranglement. Un bot qui recalcule les indicateurs sur un historique complet à 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.

Pour le serveur choisi, les éléments importants sont la localisation, 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 gardant quelques centaines de symboles en mémoire fonctionne sans difficulté 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.

Une courte checklist avant la mise en production

1. systemctl is-enabled tradingbot affiche enabled, et le service survit à sudo reboot.
2. chronyc tracking signale 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 allowlist d’adresses IP si l’exchange le permet.
4. L’arrêt du processus avec sudo systemctl kill -s SIGKILL tradingbot le relance dans les RestartSec.
5. Le heartbeat monitor vous alerte dans l’intervalle prévu lorsque vous arrêtez délibérément le bot.
6. La taille des logs est limitée et le système de fichiers root dispose d’un espace suffisant dans df -h.

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

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é, ce qui implique généralement une colocation plutôt qu’un VPS généraliste. Pour un bot de trading particulier, l’aller-retour dépend surtout de la distance géographique et du traitement effectué par le broker. Choisissez donc un serveur proche du point d’accès de l’API et mesurez avec curl et mtr avant de payer pour une configuration plus rapide.

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

La plupart des bots à stratégie unique sont limités par le réseau et restent inactifs entre deux é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 si vous conservez l’historique des ticks en mémoire ou si vous exécutez une base de données locale. Surveillez donc free -h et le journal pour repérer les messages de kill OOM au lieu de deviner.

Pourquoi mon API d’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 saisonnier ne la décale jamais. La rotation de la clé API ne résout 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 poursuive les tentatives au lieu de s’arrêter définitivement, puis ajoutez un heartbeat que le bot envoie à la fin de chaque boucle réussie. Le redémarrage prend en charge le 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 ?

C’est possible, mais la supervision vous mentira le jour où cela compte, car une panne qui arrête le bot arrêtera aussi la supervision. Conservez 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.