
Le projet
J’ai d’abord construit ce bot pour Polymarket, puis je l’ai entièrement porté vers Binance, sur une dizaine de paires en USDT (BTC, ETH, SOL, XRP, BNB, PEPE, TAO…). Je n’ai pas cherché la stratégie miracle. L’objectif était de construire un système qui teste chaque idée avant d’y mettre de l’argent : backtest, puis paper trading, puis live avec un capital limité. Chaque stratégie est mesurée sur des données réelles, et je coupe celles qui perdent.
Les stratégies
Le trend swing (45 % du capital) suit la tendance sur des bougies journalières. Ses règles sont propres à chaque actif et ont été validées en walk-forward : croisement de moyennes mobiles 20/100 sur BTC, momentum sur 30 jours pour ETH et SOL. Les actifs où aucune règle ne tenait sur plusieurs périodes, comme BNB, ont été exclus.
Le market making (40 %) capte le spread du carnet d’ordres. En live, chaque symbole est piloté par une machine à états (à plat → achat posé → en position → vente posée → à plat). Elle impose une marge minimale au-dessus du prix d’entrée, un stop-loss natif à 1 % et une sortie forcée après 10 minutes de détention.
L’event-driven tradait sur la combinaison de signaux de marché et du sentiment des news. En live, il a affiché un taux de réussite de 20% sur 12 jours, ce qui confirmait ce que le backtest annonçait. Je l’ai donc désactivé, tout en le gardant paramétrable.
Analyse de sentiment
Le bot agrège plus de 50 flux RSS crypto, anglophones et francophones (CoinDesk, CoinTelegraph, The Block, Cryptoast, Journal du Coin…). Il associe chaque article aux actifs concernés grâce à des mots-clés, puis note son sentiment en deux temps : VADER donne un premier score rapide, et FinBERT, un modèle transformer optimisé avec ONNX Runtime, ne repasse que sur les titres ambigus.
Gestion du risque
Le trading s’arrête complètement si le portefeuille perd 15 % depuis son pic, et une perte journalière maximale déclenche une pause. Il y a aussi un cooldown après chaque trade perdant, et chaque stratégie a un plafond de capital, avec une réserve de trésorerie non allouée. Les tailles de position s’ajustent au capital disponible. Chaque position a son stop-loss natif côté Binance, ce qui la protège même si le bot tombe. Au redémarrage, l’état des positions est restauré et réconcilié avec celui de l’exchange.
Architecture
Tout tourne en asyncio. Les prix, les carnets et les bougies arrivent en temps réel par WebSocket, avec un watchdog et un repli sur l’API REST si un prix devient trop ancien. Les exécutions d’ordres arrivent par le user data stream, donc le bot réagit à chaque remplissage dès que Binance le confirme. Les trades, les décisions de signal, les news et l’historique d’equity sont stockés en SQLite via SQLAlchemy async. En mode paper, la simulation applique les frais réels pour que le P&L se rapproche de celui du live.
Dashboard
Une API FastAPI alimente un dashboard Next.js (React 19, Tailwind, Recharts). On y suit l’equity et le P&L, les positions ouvertes avec leurs sparklines, l’historique paginé côté serveur, l’allocation par stratégie, le flux de news avec son sentiment et les décisions de signal. Un bouton d’arrêt d’urgence permet de stopper le bot.
Analyse et backtesting
Des scripts dédiés servent au backtest (tendance, signaux, patterns) et à l’analyse des trades : excursions maximales favorables et défavorables, performance par heure, funding. C’est ce qui a guidé les réglages. Par exemple, le stop de l’event-driven a été resserré après avoir constaté que la plupart des trades perdants dépassaient −1 % avant de toucher leur point bas.
Qualité et déploiement
Une suite de tests pytest couvre le risk manager, la machine à états du market making, la réconciliation, le user stream, la base et le module news. Le lint passe par Ruff. Le pipeline GitHub Actions vérifie le code Python, type-check et build le dashboard, puis déploie en SSH sur un VPS où le bot et le dashboard tournent en services systemd.
(Projet en suspens : le statut réglementaire de Binance en France ne me permet plus de le faire tourner en conditions réelles.)