Créer un bot de trading crypto avec l’IA : testnet, VPS

Créer un bot de trading crypto avec l’IA est aujourd’hui vraiment facile : un agent de code comme Claude Code ou Codex peut écrire un bot Python qui se connecte à une plateforme d’échange via ccxt, exécute une stratégie simple et passe des ordres. Le vrai travail, c’est tout ce qui entoure le code : tester sur un testnet et en backtest, limiter la clé d’API au seul trading, et passer à l’argent réel avec des montants minuscules.

Ce guide va pas à pas d’un dossier vide à un bot qui tourne 24 h/24 sur un serveur et vous envoie des alertes Telegram. Mais d’abord, la partie sur laquelle je dois être franc.

Le risque d’abord : ceci n’est pas un conseil financier

C’est un tutoriel de développement logiciel, pas un conseil en investissement. Quelques faits d’emblée :

• La plupart des bots de trading perdent de l’argent. Surtout les stratégies simples que l’on trouve en ligne, une fois les frais, le slippage et les mouvements brusques comptés.
• Une stratégie qui a l’air formidable en backtest échoue souvent en réel. Les stratégies ajustées sur les données passées (surapprentissage) s’effondrent vite.
• Le code écrit par l’IA peut contenir des bugs coûteux. Une mauvaise unité de quantité, une condition achat/vente inversée ou une boucle de relance qui continue de passer des ordres peuvent vider un compte en quelques minutes.
• Ne confiez à un bot que de l’argent que vous pouvez vous permettre de perdre. Commencez sur testnet, puis passez en réel avec le plus petit montant autorisé par la plateforme.

La stratégie de cet article est un exemple de code. Je ne la présente pas comme un moyen de gagner de l’argent.

Quelle stack choisir

Quand vous faites du vibe coding pour un bot, choisissez la stack que l’agent connaît le mieux. Mon choix :

• Python 3.11+ : l’écosystème le plus mûr pour les données (pandas), le backtest et les bibliothèques de plateformes d’échange, et le langage dont les agents ont vu le plus d’exemples.
• ccxt : une bibliothèque open source qui parle à de nombreuses plateformes via une seule interface. Le code écrit pour une plateforme passe en général à une autre en changeant quelques lignes, et elle prend en charge le mode testnet/sandbox de nombreuses plateformes.
• pandas : pour manipuler les données de bougies (OHLCV) sous forme de tableau.
• python-dotenv : pour garder les clés d’API dans un fichier .env, hors du code.
• SQLite : pour enregistrer les positions ouvertes et les ordres sans faire tourner de serveur de base de données.

Installation :

mkdir crypto-bot && cd crypto-bot
git init
python3 -m venv .venv && source .venv/bin/activate
pip install ccxt pandas python-dotenv requests
echo ".env" >> .gitignore
echo ".venv/" >> .gitignore

Ajoutez ces lignes à .gitignore dès la première minute. Une clé d’API poussée sur GitHub par accident est l’erreur la plus courante et la plus coûteuse de tout ce domaine.

Étape 1 : un compte testnet et une clé d’API correctement limitée

De nombreuses grandes plateformes proposent un environnement de test (testnet ou sandbox) où aucun argent réel ne bouge. Cherchez « testnet » ou « sandbox » dans la documentation développeur de la plateforme et créez-y un compte de test et une clé d’API de test distincts. S’il n’y a pas de testnet, ou si votre paire n’y figure pas, nous demanderons à l’agent de construire un mode paper trading qui lit les vrais prix mais n’enregistre les ordres qu’en local.

Quand vous créerez finalement une clé sur le compte réel :

• Activez uniquement la lecture et le trading. N’activez jamais les retraits. Si la clé fuite, personne ne peut envoyer vos fonds ailleurs.
• Utilisez la liste blanche d’IP. Si la plateforme la prend en charge, verrouillez la clé sur l’IP statique de votre VPS.
• Gardez les futures et la marge désactivés. Commencez par le spot.
• Créez une clé par bot, pour pouvoir révoquer uniquement celle-là si quelque chose tourne mal.

Un fichier .env ressemble à ceci :

EXCHANGE=binance
API_KEY=your-test-key
API_SECRET=your-test-secret
USE_TESTNET=true
TELEGRAM_TOKEN=
TELEGRAM_CHAT_ID=

Ne collez pas ces valeurs dans le chat avec l’agent. L’agent doit savoir que .env existe, pas ce qu’il contient.

Étape 2 : le premier prompt

Ouvrez l’agent dans le dossier du projet (claude ou codex) et demandez le bot par couches, pas tout d’un coup. Un premier prompt à copier :

Set up a skeleton for a simple spot trading bot in Python 3.11 with ccxt.
Rules:
- Read settings from .env with python-dotenv. Never open or print .env.
- If USE_TESTNET=true, enable ccxt sandbox mode; otherwise print a
  "LIVE MODE" warning on start and wait 10 seconds.
- Modules: config.py, exchange.py (connection, balance, candles, orders),
  strategy.py (returns a signal, never places orders), risk.py (position
  size, daily loss limit), bot.py (main loop), storage.py (SQLite log).
- Every order must pass risk.py first. Max 2% of balance per order;
  stop the bot if the daily loss exceeds 5%.
- With DRY_RUN=true, never place orders, only log them.
- Use Python logging to logs/bot.log and the console.
- No strategy yet: strategy.py should always return "hold".
When done, summarize the file layout and how to run it.

Pourquoi un squelette d’abord ? Garder la stratégie, le passage d’ordres et les règles de risque dans des fichiers séparés rend le code plus facile à relire et les bugs plus faciles à repérer. Si la stratégie ne peut pas passer d’ordres, un bug à cet endroit produit au pire un mauvais signal, et la couche de risque plafonne les dégâts.

Étape 3 : une stratégie d’exemple (croisement de moyennes mobiles)

Encore une fois : c’est un exemple, pas un conseil. Un croisement de moyennes mobiles est l’une des stratégies les plus claires pour montrer la structure. Quand la moyenne rapide passe au-dessus de la lente, elle signale « achat » ; quand elle passe en dessous, « vente ».

# strategy.py — example only, not financial advice
import pandas as pd

def signal(ohlcv: list, fast: int = 20, slow: int = 50) -> str:
    df = pd.DataFrame(ohlcv, columns=["ts", "open", "high", "low", "close", "volume"])
    if len(df) < slow + 2:
        return "hold"
    df["fast"] = df["close"].rolling(fast).mean()
    df["slow"] = df["close"].rolling(slow).mean()
    prev, last = df.iloc[-3], df.iloc[-2]  # the last candle is still open, skip it
    if prev.fast <= prev.slow and last.fast > last.slow:
        return "buy"
    if prev.fast >= prev.slow and last.fast < last.slow:
        return "sell"
    return "hold"

Un détail à remarquer : le signal est calculé à partir de la dernière bougie clôturée, car la plus récente bouge encore. Les agents l’oublient souvent, et le bot finit par entrer et sortir dans une même bougie.

Prompt pour l’ajouter :

Add a 20/50 moving average crossover to strategy.py. Compute signals from
closed candles only. Write pytest tests for the signal function: cross up,
cross down, not enough data and a flat market. Run the tests and show me
the output.

Étape 4 : le backtest

Avant de passer en réel, exécutez la stratégie sur des données historiques. Vous pouvez demander à l’agent de récupérer des bougies avec ccxt et d’écrire une boucle de backtest simple. Pour quelque chose de plus sérieux, regardez backtesting.py, vectorbt ou Freqtrade ; Freqtrade est un framework de bots open source mûr qui inclut déjà le backtest, le dry-run et le contrôle par Telegram.

Un prompt :

Write backtest.py. Fetch the last year of BTC/USDT 1h candles with ccxt,
paginating, and save them as CSV under data/. Apply strategy.signal candle
by candle without looking ahead. Deduct 0.1% fee and 0.05% slippage per
trade. Report total return, number of trades, win rate, max drawdown and
buy-and-hold return over the same period.

En lisant les résultats :

• Incluez toujours les frais et le slippage. Sans eux, presque n’importe quelle stratégie a l’air bonne.
• Comparez avec le buy-and-hold. Si le bot fait moins bien que simplement conserver, il ne vaut pas l’effort.
• Vérifiez vous-même le biais d’anticipation (look-ahead). Lisez la boucle et assurez-vous qu’elle n’utilise jamais de données qui n’existaient pas encore.
• N’ajustez pas les paramètres jusqu’à ce que la courbe soit jolie. Si 17/43 bat 20/50, c’est très probablement du hasard.

Étape 5 : testnet et paper trading

Après le backtest, faites tourner le bot sur testnet au moins quelques jours :

DRY_RUN=false USE_TESTNET=true python bot.py

À ce stade, vous vérifiez le comportement, pas le profit. Les ordres partent-ils avec la bonne quantité ? Le bot se souvient-il d’une position ouverte après un redémarrage ? Quand la plateforme renvoie une erreur, plante-t-il ou temporise-t-il et réessaie-t-il ? La limite de perte quotidienne se déclenche-t-elle vraiment ?

Provoquez une panne exprès, par exemple un ordre supérieur à votre solde, et regardez le bot l’enregistrer proprement et s’arrêter.

Étape 6 : limites de débit, gestion des erreurs et logs

Les plateformes limitent les requêtes d’API. Un bot qui les dépasse reçoit d’abord des erreurs et peut être bloqué temporairement s’il insiste. L’option enableRateLimit de ccxt espace automatiquement les requêtes ; demandez à l’agent de confirmer qu’elle est activée.

Review exchange.py:
- Make sure ccxt enableRateLimit is on.
- On NetworkError and RateLimitExceeded, retry up to 5 times with
  increasing backoff. On InsufficientFunds and InvalidOrder, do not retry;
  log it and send a Telegram alert.
- Log the request, exchange response and order id for every order.
- Prevent a second order for the same signal (idempotency).

Une bonne ligne de log répond plus tard à « pourquoi le bot a-t-il fait ça ? » : heure, signal, prix, quantité calculée, résultat du contrôle de risque, identifiant d’ordre. N’enregistrez jamais de clés d’API ni de secrets dans les logs.

Étape 7 : alertes Telegram

Le bot doit vous dire ce qu’il fait. Le plus simple est un appel HTTP direct à l’API Bot de Telegram :

# notify.py
import os, requests

def send(text: str) -> None:
    token, chat = os.getenv("TELEGRAM_TOKEN"), os.getenv("TELEGRAM_CHAT_ID")
    if not token or not chat:
        return
    try:
        requests.post(f"https://api.telegram.org/bot{token}/sendMessage",
                      json={"chat_id": chat, "text": text}, timeout=10)
    except requests.RequestException:
        pass  # a failed alert must not stop the bot

Vous obtenez le token via le processus officiel de création de bot de Telegram. Événements qui méritent une alerte : bot démarré/arrêté, ordre passé, erreur, limite de perte quotidienne atteinte. Mon guide pour créer un bot Telegram avec l’IA explique comment ajouter des commandes, par exemple pour arrêter le bot à distance.

Étape 8 : tourner 24 h/24 sur un VPS

Quand votre portable se met en veille, le bot aussi. Un petit VPS Linux suffit ; une IP statique compte pour la liste blanche d’IP.

Avec systemd

# /etc/systemd/system/crypto-bot.service
[Unit]
Description=Crypto bot
After=network-online.target

[Service]
User=bot
WorkingDirectory=/home/bot/crypto-bot
EnvironmentFile=/home/bot/crypto-bot/.env
ExecStart=/home/bot/crypto-bot/.venv/bin/python bot.py
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now crypto-bot
journalctl -u crypto-bot -f

Faites tourner le bot sous son propre utilisateur, pas root, et verrouillez le fichier d’environnement avec chmod 600 .env.

Avec Docker

Si vous préférez Docker, demandez à l’agent d’écrire un Dockerfile et un docker-compose.yml avec restart: unless-stopped, env_file pour .env, et des volumes pour logs/ et le fichier SQLite, afin que le bot et ses enregistrements survivent à un redémarrage du serveur.

Erreurs courantes : ce que l’IA a tendance à rater

• Quantités et précision. Les plateformes imposent une quantité minimale et une précision décimale par paire. Les agents l’ignorent et obtiennent des ordres rejetés, ou arrondissent dans le mauvais sens. Faites-lui utiliser amount_to_precision de ccxt et les limites du marché.
• Utiliser la bougie ouverte. Les signaux d’une bougie qui bouge encore sont du bruit.
• Drapeau testnet laissé en production, ou désactivé en test. Affichez le mode bien en évidence au démarrage.
• Perdre l’état au redémarrage. Si le bot oublie une position ouverte, il peut racheter. Conservez l’état dans SQLite et réconciliez-le avec la plateforme au démarrage.
• Ordres dans une boucle de relance. Si la logique de relance enveloppe le passage d’ordre, le même ordre peut partir de nombreuses fois.
• Erreurs avalées. Des except: pass partout donnent un bot qui a l’air vivant et ne fait rien.
• Croire « les tests passent ». Regardez vous-même la sortie.

Liste de contrôle sécurité

• Les clés d’API ne vivent que dans .env, et .env est dans .gitignore.
• Ne collez jamais de clés dans l’agent, un chat ou une capture d’écran.
• Retraits désactivés, liste blanche d’IP activée, marge désactivée.
• Lisez les commandes que l’agent veut exécuter avant de valider, surtout celles qui lisent .env, envoient des fichiers ou font des appels réseau.
• Si vous soupçonnez une fuite de clé, révoquez-la tout de suite sur la plateforme et créez-en une nouvelle.
• Activez l’authentification à deux facteurs sur le compte de la plateforme.
• Installez des dépendances que vous connaissez ; vérifiez tout nom de paquet suggéré par l’agent que vous n’avez jamais entendu.

Le faire avec AgentVera

Sur ce genre de projet, je lance plus d’un agent côte à côte. Dans une grille AgentVera, Claude Code peut travailler sur la stratégie et le backtest dans un worktree pendant que Codex construit les alertes Telegram et les fichiers Docker dans un autre, sans toucher aux fichiers l’un de l’autre. Après chaque tour, la revue de code automatique fait relire par un second modèle ce que l’agent a écrit : un regard supplémentaire utile sur le calcul des quantités et les conditions achat/vente. Vous relisez le diff dans le panneau Git avant de fusionner et vous voyez la consommation de tokens par agent. Quand le bot est prêt, SSH et SFTP envoie les fichiers sur le VPS, et le gestionnaire Docker montre le conteneur en local.

Rien de cela n’est obligatoire ; deux terminaux et git suffisent aussi. Si la configuration en parallèle vous intéresse, voyez les agents de code en parallèle.

Pour conclure

Le côté code de la création d’un bot de trading crypto avec l’IA, ce sont quelques heures : Python, ccxt, des modules clairement séparés, une couche de risque et de bons logs. Ce qui prend du temps et compte vraiment, c’est le test : backtest, testnet, paper trading, et seulement ensuite un tout petit montant en réel. Limitez la clé d’API au trading, désactivez les retraits et lisez chaque ligne d’ordre écrite par l’agent. Et rappelez-vous que la plupart des bots perdent de l’argent : construisez celui-ci pour apprendre, pas pour devenir riche.