J'ai fait tourner 12+ bots de trading pendant un an. Voici ce qui a survécu, ce qui est mort, et ce que j'ai appris.

La plupart du contenu « j'ai construit un bot de trading » sur internet est un narratif success-bias. Quelqu'un déploie une stratégie, ça marche pendant un mois, ils écrivent le post, le post devient viral, le bot arrête silencieusement de marcher trois mois plus tard et le postmortem n'est jamais publié. La leçon — la plupart des trading bots retail fail de manières spécifiques et répétables — n'entre jamais dans le corpus public.

On a fait tourner un fleet sur les douze derniers mois. Plus d'une douzaine de bots sur deux venues : OKX pour les perpetuals crypto (demo jusqu'à ce qu'une stratégie individuelle survive 60+ trades live net-of-fee), Interactive Brokers pour les equities tradfi (paper jusqu'à 30+ trades + un soak de 3-6 mois). Au pic, ~$300k de notionnel était déployé à travers les books demo + paper. Chaque trade audit-loggé. Chaque PnL réconcilié contre les books propres du broker — jamais contre la database interne du bot.

La plupart de ce qu'on a tourné a failed. Les patterns de COMMENT ça a failed sont le sujet de cet article.

La structure du fleet

Deux venues, deux surfaces d'exécution :

• Côté OKX : BTC, ETH, SOL, et une liste curated de perp pairs tradées par btc-quantum, eth-quantum, regime-rotator, et la famille tuned-perps. Demo-account-only jusqu'à ce qu'une stratégie passe le gate audit-live. Les positions OKX live sont du capital utilisateur, jamais du capital client — voir /bots/public pour le readout live actuel.
• Côté IBKR : 32+ noms tradfi à travers l'univers AI-supercycle (semi, memory, énergie, networking), originalement split à travers des bots single-name (nvda-ibkr, aapl-ibkr, amd-fast-rsi-bounce-ibkr, etc.), depuis consolidés dans tradfi-ibkr-bot avec l'univers FIB_BASKET. Compte paper ; le ramp live est différé jusqu'à ce que le book consolidé ait les 30+ trades + soak exigés par notre propre policy paper-to-live.

Douze mois après, on a shippé assez de postmortems pour identifier six classes de failure distinctes et exactement deux survivors. Les classes de failure se généralisent. Si vous faites tourner ou planifiez de faire tourner un book algo retail, vous allez probablement hit au moins trois d'entre elles — mieux reconnaître la forme maintenant que depuis l'intérieur.

Failure class 1 : exhaustion d'alpha crypto-perp

La leçon la plus douloureuse. On avait quatre classes de stratégies entières — momentum, range-mean-reversion, breakout, funding-arb — qui tournaient contre l'univers perp OKX sur Q4 2025 / Q1 2026. Chacune avait passé son audit walk-forward individuellement. Combinées elles ont généré 213 trades demo.

Le PnL gross : +$122. Les frais : $131. Le net : −$9.

Quatre stratégies, deux cents trades, un quart d'attention opérateur, et le résultat net était dans l'erreur d'arrondi de zéro — et du mauvais côté de zéro. L'alpha était real-ish au niveau gross. Le coût d'exécution l'a mangé entièrement.

La leçon est brutale dans sa spécificité : au size perp retail en 2026, n'importe quelle stratégie dont le backtest ne modélise pas explicitement les frais d'exchange VOUS MENT. Les rebates maker ne vous sauvent pas si votre stratégie est taker. Les tiers de frais ne vous sauvent pas si vous n'êtes pas à $10M+ de volume mensuel. L'assumption « les frais sont négligeables » qui marchait dans les marchés crypto-perp 2018-2022 ne tient plus — les spreads se sont serrés et l'alpha qui vivait à l'intérieur des spreads plus larges est partie.

Ce qu'on a fait à propos : trimmer regime-rotator à un univers 4-pair (SOL/INJ/LINK/AVAX), blacklister SUI/YFI/IOTA et 8 autres pairs liquidity-marginal, et rendre toutes les analytics NET-of-fee à partir de là. Le gate de décision pour re-expandre l'univers est maintenant 60 trades live net-positifs — pas gross.

Failure class 2 : « passes walk-forward » ≠ « alpha »

On a buildé deux bots single-name genuinement sophistiqués début 2026 :

• nvda-ibkr — un bot swing NVDA de ~1,100 lignes avec ensembling multi-stratégies et un risk overlay. Résultat walk-forward : 5/5 PASS.
• aapl-ibkr — un bot AAPL plus compact. Résultat walk-forward : 4/4 PASS, Profit Factor 2.05.

Les deux bots looked, par chaque métrique standard que la littérature trading systématique recommande, comme des winners. On les a déployés en paper, on les a fait tourner pendant deux mois, et puis on a comparé leur return cumulé au benchmark le plus stupide possible : holder le ticker underlying, même dollar size, no rebalancing, no overlay.

• nvda-ibkr a capturé 3% du return buy-and-hold NVDA sur la période.
• aapl-ibkr a capturé 2.2% du return buy-and-hold AAPL.

Les bots ne perdaient pas d'argent. Ils étaient du buy-and-hold risk-managed avec un opportunity cost massif. Le « PASS » walk-forward ne mesurait pas l'alpha ; il mesurait « ne blow pas up ». Ce sont des propriétés très différentes.

La leçon plus profonde : la validation walk-forward vous dit qu'une stratégie survive à l'histoire. Elle ne vous dit pas que la stratégie vaut la peine d'être run. Une stratégie dont l'alpha après coûts est inférieur au drift naturel de l'underlying est pire que pas de stratégie. Le benchmark contre lequel vous comparez compte énormément. On a depuis ajouté « capture ≥30% du B&H notional return » comme hard gate dans le pipeline d'audit ; sans ça, « passer » est un vibe, pas un fait.

Failure class 3 : fiction de PnL

En mai 2026 on a tourné une réconciliation contre le fill log propre d'OKX sur btc-quantum. Le vault SQLite interne du bot rapportait du PnL cumulé de +$1,309. La vérité broker OKX : −$373.

Source du gap : le analytics.record_trade() du bot enregistrait les prix de fill gross sans soustraire le fee qu'OKX déduisait du même trade. Composez ça sur une centaine de trades et vous buildez un drift fictif de PnL de $1,700. Le dashboard du bot, le live status JSON, et la télémetrie user-facing rapportaient tous le chiffre fictif.

La leçon architecturale : chaque view PnL interne d'un bot est un cache, pas la vérité. La seule source de vérité c'est le propre fill log + position statement du broker. Les databases internes drift parce que les bots sont écrits par des humains qui oublient de soustraire les frais, miss des fills partiels, ou se confondent quand un ordre est cancelled et re-submitted. La discipline de réconciliation est non-négociable — et la plupart du temps, la première réconciliation révèle au moins un bug.

On run maintenant un diff nocturne : bot-DB-PnL vs broker-fill-PnL. N'importe quelle divergence > 0.5% page un opérateur avant l'open du matin suivant.

Failure class 4 : death silencieuse

En mai 2026 on a eu deux incidents séparés « le bot est mort mais personne n'a remarqué » :

• eth-quantum a hung pendant 18 heures sur un single stale OKX TCP read. Le socket n'a jamais reçu un TCP RST, le read() de la couche application n'est jamais retourné, le main loop du bot était bloqué mais le container était Up. Fix : socket.setdefaulttimeout(30) au process start, plus un heartbeat couche application que le watchdog lit.
• btc-quantum avait un duplicate-block guard qui était supposé empêcher le bot de re-submitter un ordre sur le même bar deux fois. Le guard était un no-op (un bug dans la comparaison) et le bot était fail-deadly sur les rejects broker-side, donc les submissions duplicates passaient silencieusement. PR #71 a fixé le guard.

La même semaine, le watchdog false-positivement a alerté que eth-quantum était dead depuis 7.7 heures quand le bot était actually alive et trading — le watchdog lisait container uptime, pas application heartbeat.

Leçon nette : container Up n'est pas health. Application heartbeat est health. Buildez un heartbeat explicite — une valeur que le bot écrit dans un fichier connu toutes les N secondes — et faites le watchdog lire ÇA, pas le status container Docker. Buildez un socket timeout à la couche network de chaque external call. La combinaison catch les deux types de death silencieuse.

Failure class 5 : déconfliction

Les opérations multi-bot cassent de manières subtiles quand les bots partagent des ressources.

• Trois bots OKX ont fight pour le même compte OKX en avril 2026 (btc-quantum, un expérimental eth-grid, et tsla-bot). Sans règles d'ownership par-pair, deux bots décidaient simultanément « long ETH-PERP » avec des sizes différentes et l'un adoptait la position de l'autre en pensant que c'était la sienne.
• Deux bots IBKR (amd-microswing-ibkr et amd-fast-rsi-bounce-ibkr) partageaient le compte paper, tous deux watchaient AMD, et le même pattern d'orphan-adoption se jouait — un bot voyait une position AMD ouverte de l'autre et « l'adoptait » dans son propre état, puis commençait à gérer la logique d'exit contre une position qu'il n'avait pas ouverte.

Solution : 1-bot-par-pair, point. Le registry du fleet assigne ownership explicite ; n'importe quel pair qu'un autre bot veut est locked. Quand on a consolidé cinq bots IBKR single-name dans tradfi-ibkr-bot ($10k cap), toute la logique de déconfliction est devenue interne à un process au lieu d'être négociée entre containers. Moins élégant, plus fiable.

Failure class 6 : déploiement data-starved

nvda-bot était un bot stratégie-perp qu'on a déployé sur OKX début 2026. La stratégie exigeait au moins 202 daily bars de contexte historique. Le listing NVDA-perp d'OKX a 59 daily bars au total.

Le bot prenait des décisions sur data insuffisante — chaque signal qu'il générait était essentiellement du bruit dans l'intervalle de confiance de sa stratégie. Killed it. La note dans notre project memory dit « restart ~décembre 2026 » — quand OKX aura assez d'historique NVDA-perp pour la fenêtre lookback de la stratégie.

Leçon : avant de déployer une stratégie, vérifiez la fenêtre data dont la stratégie a besoin contre la fenêtre data que la venue a réellement. L'erreur ici était triviale à faire — on avait designé la stratégie sur données synthétiques et supposé que la venue rattraperait. Elle ne l'a pas fait.

Ce qui a survécu

Sur les douzaine+ de bots, deux stratégies ont genuinely battu leurs benchmarks à travers des cycles walk-forward consécutifs + soak periods :

1. reg_channel_mr + ema_crossover (mean-reversion tradfi sur baskets equities). Tous deux ont atteint 15 verdicts ROBUST chacun dans le leaderboard du sweep de mai 2026, battant fib_mean_reversion sur 31 des 32 noms testés. Ce sont maintenant les stratégies routées sur le bot IBKR consolidé.
2. fib_mean_reversion avec filtre SMA50, sur le cohort 5-noms HIGH_VOL uniquement. Recalibré mai 2026 (PR #278) : basket PF 1.53→1.76, Sharpe 1.08→1.42, +23.7% cumulé trois ans, walk-forward 4/5 PASS. Coexiste avec le routing change scope 1H per-ticker du sweep 19 mai — orthogonal.

Les deux survivors sont du mean-reversion tradfi. Tous deux tournent sur timeframes daily. Tous deux clear B&H après frais. C'est tout. Deux survivors sur des attempts à deux chiffres.

Notablement absent de la liste survivor : n'importe quelle stratégie crypto-perp directionnelle pure. Per failure class 1, cet alpha est actuellement exhausted au size retail. On garde les bots crypto qui tournent au gate demo pas parce qu'on s'attend à ce qu'ils trouvent du nouvel alpha demain, mais parce que le jour où l'alpha return (un shift de structure de marché, une nouvelle venue, un nouveau produit), on veut l'infrastructure déjà en place pour le détecter.

Meta-patterns cross-cutting

Quatre leçons qui se généralisent à travers les six classes de failure :

1. Les frais composent plus vite que l'alpha. Chaque stratégie doit être modélisée net-of-fee depuis la ligne un. Le gap entre gross et net est la cause individuelle la plus commune d'une stratégie « winning » étant un net loser. Faites que votre pipeline d'audit reject n'importe quel backtest qui n'a pas de modeling explicite de frais.

2. Walk-forward dit « ne blow pas up ». Ne dit pas « bat le benchmark ». Ajoutez un hard benchmark-comparison gate à votre validation. « Capture ≥30% du B&H notional return » est notre bar actuel ; avant qu'on l'ait, les « passing strategies » étaient silencieusement underperforming l'underlying.

3. Database interne est un cache. Broker fill log est la vérité. Réconciliez nocturnement. Pagez sur divergence. La plupart des bots live ont au moins un bug de PnL-fiction ; la première réconciliation le trouve généralement.

4. Container Up n'est pas health. Application heartbeat est health. Buildez un heartbeat explicite depuis l'intérieur du process bot. Faites que le watchdog lise ÇA, pas Docker. Ajoutez des socket timeouts à chaque external API call pour que les reads bloqués ne puissent pas hang le main loop.

Ce que tout ça a coûté

Douze mois. À peu près cinq mois d'attention opérateur complète (c'est un side project au-dessus de la plateforme QA elle-même). Des douzaines de postmortems. Multiple six-figure-notional paper losses, dénommés en opportunity cost plus qu'en dollars (on utilise des comptes paper + demo pour exactement cette raison). Probablement vingt rebuilds de stratégies qui looked prometteuses en backtest et sont mortes en soak.

La plupart des traders retail skip ce coût en s'arrêtant après leur premier backtest profitable, en déployant live, et en découvrant l'une des six classes de failure ci-dessus avec du vrai argent. Le coût de skip de la discipline postmortem est le coût de découvrir en live trade. On a choisi de découvrir en paper.

Si vous voulez voir les résultats live + paper actuels en temps réel, ils sont publics : /bots/public. Les equity curves update quotidiennement ; les colonnes PnL sont réconciliées à la vérité broker.

Si ça vous parle

On déploie nos bots paper IBKR via le runbook documenté dans un article séparé sur faire tourner IBKR Trader Workstation pour bots systématiques. Pour le choix broker lui-même, voir pourquoi IBKR pour le trade supercycle IA. Le côté crypto tourne contre OKX pour les raisons dans cette pièce de comparaison.

Pour faire tourner votre propre paper fleet depuis zéro :

1. Pour tradfi : ouvrez un compte Interactive Brokers — les comptes paper sont gratuits, l'API marche depuis le jour un, et le programme IBKR donne actuellement jusqu'à $1,000 d'action IBKR au nouveau compte (termes applicables). Raisonnement complet + les frictions qu'on a hit sur notre page broker.
2. Pour les perps crypto : ouvrez un compte OKX — l'environnement demo mirror le live, l'API est documentée, le tier de frais ramp. Raisonnement complet sur notre page broker.
3. Buildez la discipline d'audit avant la première stratégie. Net-of-fee depuis le jour un. Benchmark comparison gate. Réconciliation nocturne. Watchdog basé heartbeat. Les quatre meta-patterns ci-dessus sont cheap à ajouter upfront et expensive à retrofit après le premier incident de PnL-fiction.

Les douzaine+ de bots vont devenir deux survivors. C'est le rate. Planifiez la capacité en conséquence — la valeur n'est pas dans déployer dix stratégies en parallèle, c'est dans tuer les huit qui ne marchent pas vite et nourrir les deux qui marchent.