Je fais du trading crypto depuis 2019. D'abord manuellement, puis avec des bots. J'ai perdu de l'argent, j'en ai gagné, et surtout j'ai beaucoup appris sur ce qu'il faut faire et ne pas faire quand on automatise une stratégie. Cet article est un retour technique, pas un conseil financier.
Disclaimer légal : le trading de cryptomonnaies comporte des risques de perte significatifs. Ce qui suit est un partage d'expérience technique, pas une recommandation d'investissement. Faites vos propres recherches, ne tradez jamais plus que ce que vous pouvez vous permettre de perdre.
Pourquoi self-hosted
Il existe des plateformes de bots en SaaS : 3Commas, Cryptohopper, Pionex. Elles ont l'avantage de la simplicité, mais trois inconvénients majeurs :
- Vos clés API sont chez eux. En 2022, 3Commas s'est fait leaker 100 000 clés API. Des utilisateurs ont perdu des fonds. Quand vos clés sont sur un tiers, vous êtes à sa merci.
- Latence. Un SaaS ajoute une couche réseau supplémentaire. Votre bot réagit en secondes au lieu de millisecondes. Sur du scalping, ça tue la stratégie.
- Coûts récurrents. 30-100 €/mois pour les plans sérieux. Sur un an, ça fait 360-1 200 €. Un VPS + votre code, c'est 20-50 €/mois.
Avec un bot self-hosted, vos clés API restent sur votre serveur, vous contrôlez la latence, et le seul coût récurrent c'est l'hébergement.
Il y a aussi un avantage technique souvent négligé : la flexibilité. Avec votre propre code, vous pouvez implémenter exactement la stratégie que vous voulez, avec les indicateurs que vous voulez, les conditions d'entrée/sortie que vous voulez. Sur un SaaS, vous êtes limité par ce que la plateforme propose. Essayez d'implémenter un signal basé sur le ratio de volume Taker Buy/Sell croisé avec le funding rate des futures sur 3Commas — c'est impossible. En Python avec ccxt, c'est 20 lignes.
Architecture type
Voici l'architecture que j'utilise. Rien de sorcier, des briques éprouvées :
# Architecture simplifiée
#
# [Exchange API] ←→ [ccxt] ←→ [Strategy Engine] ←→ [PostgreSQL]
# ↓
# [Celery Workers]
# ↓
# [Monitoring/Alertes]
# (Telegram bot / email)
- ccxt : librairie Python qui uniformise l'accès à 100+ exchanges (Binance, Kraken, Bybit...)
- Celery + Redis : exécution asynchrone des tâches (surveillance, passage d'ordres, calculs)
- PostgreSQL : historique des trades, état du portfolio, logs
- Telegram Bot : alertes en temps réel et commandes manuelles (stop, status, kill)
Connexion à l'exchange avec ccxt
ccxt est la librairie standard pour interagir avec les exchanges crypto. L'API est propre et unifiée :
import ccxt
import os
def get_exchange():
# Initialise la connexion a l exchange.
exchange = ccxt.binance({
'apiKey': os.environ['BINANCE_API_KEY'],
'secret': os.environ['BINANCE_API_SECRET'],
'sandbox': os.environ.get('TRADING_SANDBOX', 'true') == 'true',
'options': {
'defaultType': 'spot', # ou 'future' pour les dérivés
},
'enableRateLimit': True, # Respecter les limites de l'exchange
})
return exchange
def get_ticker(exchange, symbol='BTC/USDT'):
# Recupere le prix actuel d une paire.
ticker = exchange.fetch_ticker(symbol)
return {
'symbol': symbol,
'last': ticker['last'],
'bid': ticker['bid'],
'ask': ticker['ask'],
'volume_24h': ticker['baseVolume'],
'change_24h': ticker['percentage'],
}
# Exemple d'utilisation
exchange = get_exchange()
btc = get_ticker(exchange, 'BTC/USDT')
print(f"BTC/USDT: {btc['last']} $ (24h: {btc['change_24h']:+.1f}%)")
Passer un ordre
def passer_ordre_limit(exchange, symbol, side, amount, price):
# Passe un ordre limit et retourne l ID.
try:
order = exchange.create_order(
symbol=symbol,
type='limit',
side=side, # 'buy' ou 'sell'
amount=amount,
price=price,
)
return {
'id': order['id'],
'symbol': order['symbol'],
'side': order['side'],
'price': order['price'],
'amount': order['amount'],
'status': order['status'],
}
except ccxt.InsufficientFunds as e:
raise ValueError(f"Fonds insuffisants: {e}")
except ccxt.InvalidOrder as e:
raise ValueError(f"Ordre invalide: {e}")
except ccxt.ExchangeError as e:
raise RuntimeError(f"Erreur exchange: {e}")
Gestion des clés API — le point critique
Vos clés API donnent accès à vos fonds. Leur sécurité est non-négociable.
Règle numéro 1 : restreindre les permissions. Sur Binance, créez des clés avec UNIQUEMENT les permissions "Spot Trading" et "Read Info". Jamais "Enable Withdrawals". Même si votre serveur est compromis, l'attaquant ne pourra pas retirer vos fonds.
Règle numéro 2 : whitelist IP. Liez vos clés API à l'IP fixe de votre serveur. Si quelqu'un vole vos clés, elles sont inutilisables depuis une autre IP.
Règle numéro 3 : ne jamais les mettre dans le code. Variables d'environnement au minimum, vault idéalement :
# .env (JAMAIS commité dans git)
BINANCE_API_KEY=aB3dEfGhIjKlMnOpQrStUvWx
BINANCE_API_SECRET=zY9xWvUtSrQpOnMlKjIhGfEd
TRADING_SANDBOX=false
# docker-compose.yml
services:
trading-bot:
image: trading-bot:latest
env_file: .env
# Ou mieux, avec Docker secrets :
secrets:
- binance_api_key
- binance_api_secret
secrets:
binance_api_key:
file: ./secrets/binance_api_key.txt
binance_api_secret:
file: ./secrets/binance_api_secret.txt
Pour aller plus loin, vous pouvez utiliser HashiCorp Vault ou AWS Secrets Manager. Mais pour un setup personnel, les variables d'environnement + whitelist IP + permissions restreintes, c'est déjà un bon niveau.
Backtesting : tester avant de perdre de l'argent
Ne déployez JAMAIS une stratégie sans l'avoir backtestée sur au moins 2 ans de données historiques. C'est la règle d'or.
import pandas as pd
import numpy as np
def backtest_sma_cross(df, short_window=20, long_window=50, capital_initial=10000):
# Backtest d un croisement de moyennes mobiles.
# df doit contenir une colonne 'close' indexee par date.
df = df.copy()
df['sma_short'] = df['close'].rolling(window=short_window).mean()
df['sma_long'] = df['close'].rolling(window=long_window).mean()
# Signaux
df['signal'] = 0
df.loc[df['sma_short'] > df['sma_long'], 'signal'] = 1 # Long
df.loc[df['sma_short'] <= df['sma_long'], 'signal'] = 0 # Out
# Positions (shift pour éviter le look-ahead bias)
df['position'] = df['signal'].shift(1)
# Rendements
df['returns'] = df['close'].pct_change()
df['strategy_returns'] = df['position'] * df['returns']
# Métriques
total_return = (1 + df['strategy_returns'].dropna()).prod() - 1
buy_hold_return = (df['close'].iloc[-1] / df['close'].iloc[0]) - 1
max_drawdown = (df['strategy_returns'].cumsum() - df['strategy_returns'].cumsum().cummax()).min()
sharpe = df['strategy_returns'].mean() / df['strategy_returns'].std() * np.sqrt(365)
nb_trades = df['signal'].diff().abs().sum() / 2
return {
'rendement_strategie': f"{total_return*100:.1f}%",
'rendement_buy_hold': f"{buy_hold_return*100:.1f}%",
'max_drawdown': f"{max_drawdown*100:.1f}%",
'sharpe_ratio': f"{sharpe:.2f}",
'nombre_trades': int(nb_trades),
'capital_final': f"{capital_initial * (1 + total_return):,.0f} €",
}
# Utilisation avec des données OHLCV de ccxt
exchange = get_exchange()
ohlcv = exchange.fetch_ohlcv('BTC/USDT', '1d', limit=730) # 2 ans
df = pd.DataFrame(ohlcv, columns=['timestamp', 'open', 'high', 'low', 'close', 'volume'])
df['date'] = pd.to_datetime(df['timestamp'], unit='ms')
df.set_index('date', inplace=True)
resultats = backtest_sma_cross(df)
print(resultats)
Un bon backtest doit aussi mesurer le max drawdown (perte maximale depuis un pic) et le ratio de Sharpe (rendement ajusté au risque). Un rendement de +50% ne vaut rien si le max drawdown est de -40% — vous auriez probablement paniqué et coupé le bot avant d'atteindre le +50%.
Pièges du backtesting :
- Overfitting : optimiser les paramètres sur les données historiques ne garantit rien pour le futur. Utilisez un train/test split (80/20).
- Look-ahead bias : utiliser des données futures pour prendre des décisions passées. Le
shift(1)est là pour ça. - Frais ignorés : Binance prend 0.1% par trade. Sur 500 trades/an, ça fait 50% du capital qui part en frais si vous faites du scalping. Intégrez toujours les frais dans le backtest.
- Slippage : en conditions réelles, vous n'obtiendrez pas toujours le prix que vous voulez, surtout sur les petits volumes.
- Survivorship bias : vous backtestez sur BTC/USDT parce que BTC existe encore. Mais combien de coins ont disparu ? Votre stratégie "diversifiée sur 20 altcoins" de 2021 inclurait des coins qui valent zéro aujourd'hui.
Mon approche : je backteste sur 3 ans minimum (bull + bear + range), avec frais de 0.1% par trade, slippage de 0.05% sur les pairs majeures (0.2% sur les altcoins), et un split 70/30 pour l'optimisation des paramètres. Si la stratégie est rentable sur la période de test (30%), je la mets en paper trading pendant 2 mois avant de la déployer en réel. Si elle n'est pas rentable en paper trading, elle ne sera pas rentable en réel — fin de l'histoire.
Monitoring et alertes
Un bot qui tourne sans monitoring, c'est un bot qui peut perdre silencieusement de l'argent pendant des jours. Voici le minimum vital :
import requests
import logging
logger = logging.getLogger('trading.monitor')
TELEGRAM_BOT_TOKEN = os.environ['TELEGRAM_BOT_TOKEN']
TELEGRAM_CHAT_ID = os.environ['TELEGRAM_CHAT_ID']
def alerte_telegram(message, urgence='info'):
# Envoie une alerte via Telegram.
prefixes = {'info': 'ℹ', 'warning': '⚠', 'error': '🔴', 'trade': '💰'}
texte = f"{prefixes.get(urgence, '')} {message}"
try:
requests.post(
f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage",
json={'chat_id': TELEGRAM_CHAT_ID, 'text': texte, 'parse_mode': 'HTML'},
timeout=10,
)
except Exception as e:
logger.error("Échec envoi Telegram: %s", e)
# Alertes à configurer
def check_sante_bot():
# Verification de sante periodique (toutes les 5 min via Celery Beat).
exchange = get_exchange()
# Vérifier la connexion exchange
try:
balance = exchange.fetch_balance()
except Exception as e:
alerte_telegram(f"CONNEXION EXCHANGE PERDUE: {e}", urgence='error')
return
# Vérifier le solde (alerte si < seuil)
usdt_balance = balance['USDT']['total']
if usdt_balance < 100:
alerte_telegram(f"Solde USDT bas: {usdt_balance:.2f}$", urgence='warning')
# Vérifier les ordres ouverts bloqués (> 1h)
open_orders = exchange.fetch_open_orders()
for order in open_orders:
age_minutes = (time.time() - order['timestamp'] / 1000) / 60
if age_minutes > 60:
alerte_telegram(
f"Ordre bloqué depuis {age_minutes:.0f}min: "
f"{order['side']} {order['amount']} {order['symbol']} @ {order['price']}",
urgence='warning'
)
logger.info("Health check OK — Balance: %.2f USDT, Open orders: %d", usdt_balance, len(open_orders))
Coûts d'infrastructure
| Option | Coût mensuel | Latence exchange | Adapté pour |
|---|---|---|---|
| VPS basique (Hetzner CX22) | ~5 €/mois | 20-50ms | Swing trading, DCA |
| VPS Tokyo/Singapour (proche Binance) | ~15-30 €/mois | 2-10ms | Day trading |
| Serveur dédié (Hetzner AX42) | ~40-60 €/mois | 15-30ms | Multi-stratégies |
| Serveur maison (comme le mien) | ~20 €/mois (électricité) | 30-60ms | Expérimentation |
Pour du swing trading (positions tenues plusieurs jours), un VPS à 5 €/mois suffit largement. La latence ne compte que pour du scalping sub-minute.
Un point sur la redondance : si votre bot gère des positions ouvertes (pas juste du DCA), prévoyez un deuxième serveur en failover. Un VPS qui tombe pendant que vous avez 3 BTC en position longue, c'est potentiellement des milliers d'euros de perte si le marché se retourne et que votre stop-loss n'est qu'un trailing stop logiciel (pas un ordre déjà posé sur l'exchange). Ma règle : toujours poser un stop-loss ordre sur l'exchange, jamais uniquement dans le code du bot. Le bot peut tomber, l'exchange reste debout.
Les erreurs que j'ai faites (pour que vous les évitiez)
- Pas de stop-loss automatique au début. J'ai laissé un bot tourner la nuit sans stop-loss. Flash crash de 15% sur ETH, le bot a racheté pendant la chute. -2 300 € en 3 heures. Leçon apprise.
- Backtester sur un bull market et croire que ça marchera toujours. Ma stratégie faisait +180% sur les données 2020-2021. En bear market 2022, elle a fait -45%. Le backtest doit couvrir au moins un cycle complet (bull + bear).
- Trop de trades. Les frais mangent la performance. Ma première stratégie faisait 15 trades/jour. Après frais, elle était perdante. J'ai réduit à 2-3 trades/jour et c'est devenu rentable.
- Ignorer le slippage sur les altcoins. Sur BTC/USDT, le carnet d'ordres est épais. Sur un altcoin à 500K$ de volume journalier, un ordre de 5 000$ peut déplacer le prix de 0.5-1%. Ça tue les marges.
- Pas de kill switch. Mon bot avait un bug qui le faisait boucler : acheter, vendre, acheter, vendre... 40 trades en 3 minutes. Les frais ont mangé 800 €. Depuis, j'ai un circuit breaker qui coupe automatiquement au-delà de 10 trades/heure.
La stack complète en production
Pour ceux qui veulent un aperçu complet de ce que j'utilise en prod :
# requirements.txt (extrait)
ccxt==4.2.x
celery==5.3.x
redis==5.0.x
pandas==2.2.x
numpy==1.26.x
psycopg2-binary==2.9.x
python-telegram-bot==21.x
cryptography==42.x # Pour le chiffrement des cles API
# celery_config.py
from celery.schedules import crontab
beat_schedule = {
'check-signals': {
'task': 'trading.tasks.check_signals',
'schedule': 60.0, # Toutes les minutes
},
'health-check': {
'task': 'trading.tasks.health_check',
'schedule': 300.0, # Toutes les 5 minutes
},
'daily-report': {
'task': 'trading.tasks.daily_report',
'schedule': crontab(hour=20, minute=0),
},
'rebalance-portfolio': {
'task': 'trading.tasks.rebalance',
'schedule': crontab(hour=2, minute=0), # 2h du matin
},
}
Le rapport quotidien envoyé sur Telegram contient : PnL du jour, PnL cumulé, positions ouvertes, ordres exécutés, alertes, et l'état de santé du bot (mémoire, CPU, connectivité exchange). C'est mon rituel du soir : je check le rapport en 30 secondes, et si tout est vert, je passe à autre chose.
Un dernier mot
Le trading automatisé n'est pas de l'argent facile. C'est un projet technique sérieux qui demande des compétences en développement, en finance quantitative et en gestion de risque. Les bots ne suppriment pas le risque, ils l'automatisent — y compris le risque de perte.
Aspects juridiques en France
Un point important si vous faites du trading automatisé en France : la fiscalité. Depuis 2019, les plus-values sur actifs numériques sont imposées au PFU (flat tax) de 30% pour les particuliers, ou à l'IS pour les entreprises. Chaque cession (vente ou échange crypto/crypto) est un fait générateur d'impôt.
Avec un bot qui fait 2-3 trades par jour, ça fait potentiellement 700+ cessions par an à déclarer. Vous avez deux options :
- La méthode manuelle : bonne chance. Les formulaires 2086 ne sont pas faits pour ça.
- La méthode automatisée : exportez l'historique de vos trades depuis l'exchange (ccxt le fait), injectez-le dans un outil fiscal crypto (Waltio, Koinly, CoinTracking), et utilisez le rapport généré pour votre déclaration. Budget : 50-150 €/an pour l'outil fiscal, mais c'est indispensable.
Pensez aussi à la qualification : si le trading est votre activité principale (revenus significatifs, fréquence élevée, moyens techniques importants), l'administration fiscale peut requalifier vos plus-values en BIC (bénéfices industriels et commerciaux). Les taux d'imposition changent significativement. Consultez un expert-comptable spécialisé crypto — ça vaut l'investissement.
Et n'oubliez pas : déclarer vos comptes sur les plateformes étrangères (formulaire 3916-bis) est obligatoire. Un compte Binance ou Kraken non déclaré, c'est 750 € d'amende par compte et par an. Le bot que vous avez codé ne vous dispensera pas de la paperasse administrative.
Un dernier mot
Le trading automatisé n'est pas de l'argent facile. C'est un projet technique sérieux qui demande des compétences en développement, en finance quantitative et en gestion de risque. Les bots ne suppriment pas le risque, ils l'automatisent — y compris le risque de perte.
Si vous cherchez de l'aide sur la partie technique (architecture, déploiement, monitoring), c'est dans mes cordes. Sur la partie stratégie de trading, chacun est responsable de ses choix. Contactez-moi si vous avez un projet concret à discuter.