CryptoGridBot : mon bot de grid trading crypto self-hosted
CryptoGridBot est un bot de trading que j'ai développé et que j'héberge moi-même, basé sur une stratégie de grid trading (trading en grille) sur une plateforme d'échange crypto. Le principe du grid trading : placer une série d'ordres d'achat et de vente à intervalles réguliers autour d'un prix, pour capter la volatilité d'un actif sans avoir à en prédire la direction — chaque aller-retour de prix entre deux niveaux de la grille génère un petit gain.
1. Ce que j'ai appris en l'hébergeant moi-même
Plutôt qu'un tutoriel d'installation (le code est personnel, pas publié), voici les décisions d'architecture qui comptent vraiment quand on fait tourner ce genre de bot en continu, sans surveillance permanente.
2. Ne jamais faire confiance à l'état local seul
Le bot maintient un état local (positions ouvertes, niveaux de grille actifs) pour éviter de tout interroger sur l'API à chaque cycle. Mais après un redémarrage — volontaire ou suite à un incident — l'état réel sur la plateforme d'échange fait toujours autorité. Au démarrage, le bot resynchronise systématiquement ses positions locales sur l'état réel côté exchange avant de reprendre son activité, plutôt que de repartir aveuglément sur un état local potentiellement désynchronisé (par exemple si un ordre a été exécuté ou annulé manuellement pendant l'arrêt du bot).
3. Un kill-switch, toujours accessible
Un mécanisme d'arrêt d'urgence, indépendant de la logique de trading elle-même, permet de couper immédiatement toute nouvelle prise de position (sans forcément liquider les positions existantes) en cas de comportement de marché anormal ou de doute sur le bon fonctionnement du bot. Un bot de trading qui ne peut pas être arrêté rapidement et simplement n'est pas prêt pour tourner sans surveillance.
4. Alerting en temps réel
Le bot envoie ses événements clés (ouverture/fermeture de position, erreur API, déclenchement du kill-switch) vers Telegram et Discord via des webhooks. C'est ce qui permet de le laisser tourner en autonomie tout en étant notifié immédiatement si quelque chose sort du comportement attendu, sans avoir à consulter un dashboard en continu.
5. Sauvegarder un état qui écrit en continu
Contrairement à une application web classique, ce type de bot écrit en permanence (positions, logs de trading). Une sauvegarde à chaud (pendant que le conteneur tourne) risque de capturer un état incohérent, à mi-chemin d'une écriture. La solution simple : arrêter le conteneur juste le temps de l'archive, puis le relancer aussitôt.
$ docker stop cryptogridbot
$ tar czf backup-$(date +%Y%m%d_%H%M%S).tar.gz ./cryptogridbot-data
$ docker start cryptogridbotL'interruption dure quelques secondes — largement acceptable pour une stratégie de grid trading qui n'est pas sensible à la milliseconde, contrairement à du market making haute fréquence.
.env non versionné, avec les permissions strictement nécessaires (trading activé, retrait désactivé). Même en cas de fuite du bot lui-même, un attaquant ne pourrait pas sortir les fonds du compte.6. Portabilité entre serveurs
Lors d'une migration de serveur, le bot redémarre simplement à partir des fichiers copiés (code, configuration, .env), sans "graine" particulière à régénérer — contrairement à d'autres services (un gestionnaire de mots de passe ou un outil avec chiffrement des identifiants) où une clé de chiffrement oubliée peut rendre les données illisibles. Le point de vigilance reste plutôt de vérifier que l'image Docker est bien reconstruite (si le service utilise build: plutôt qu'une image publiée) avant de relancer.
Le nom "grid" vient de la grille de prix elle-même : plus les niveaux sont rapprochés, plus le bot capte de petits mouvements fréquents, mais avec des gains unitaires plus faibles et plus de frais de transaction cumulés. Le réglage de cet espacement, ainsi que les bornes hautes et basses de la grille, est le cœur du paramétrage — et le principal facteur de risque en cas de sortie de la fourchette prévue.
Conclusion
Ce projet m'a surtout appris que la partie "trading" d'un bot n'est qu'une fraction du travail : la vraie fiabilité vient de la gestion d'état, de la resynchronisation systématique avec la source de vérité (l'exchange), et d'un arrêt d'urgence toujours disponible. Des principes qui s'appliquent d'ailleurs à n'importe quel système automatisé qui manipule un état sensible sans supervision humaine constante.