Pourquoi les bots trading échouent · les 7 causes structurelles
Le marché crypto compte des milliers de bots. Au bout de 3 à 12 mois, environ 95 % de leurs utilisateurs ont perdu une partie ou la totalité de leur capital. Ce n'est pas une question de marketing ou d'algorithme propriétaire. Ce sont sept causes architecturales que cette page explique, et que le Decision OS tente de traiter une par une.
« Un bot rentable en backtest est presque toujours un bot mort en production. La cause est rarement le code · c'est la conception. »
Les 7 causes structurelles
01
Overfitting · le bot connaît trop bien le passé
Un bot est optimisé sur des données historiques. Plus on ajuste ses paramètres pour qu'il "gagne" dans le passé, plus il apprend les particularités de cette période précise · y compris le bruit aléatoire. En production, ce bruit n'existe plus. Le bot perd.
→ Réponse SCT
Décisions documentées, pas paramètres optimisés. Walk-forward obligatoire · aucun seuil n'est validé sans tenir hors-échantillon. La doctrine est versionnée publiquement, donc l'évolution est traçable.
02
Absence de notion de régime · une seule stratégie pour tous les marchés
La grande majorité des bots tournent la même logique en trend haussier, en range, en bear violent, en marché manipulé. Une stratégie qui marche en trend tue le capital en range. L'inverse aussi. Sans détection de régime, le bot est structurellement aveugle.
→ Réponse SCT
Couche régime explicite dans le pipeline · classification trend_haussier · trend_baissier · range · marche_manipule · capitulation. Chaque régime active ou bloque des modules. Le NO_TRADE est une décision native.
03
Absence de mémoire · le bot répète les mêmes erreurs
Sans mémoire vectorielle des setups passés, un bot perdant 14 fois sur un pattern donné prendra le 15ème trade exactement comme le premier. Il n'apprend pas. Il exécute. La même erreur, indéfiniment.
→ Réponse SCT
Couche memory pgvector · chaque setup est indexé, comparé à son cluster historique, et pondère la décision. Les patterns destructeurs identifiés sont publiés dans /sct/erreurs/.
04
Confusion winrate / expectancy · la mauvaise métrique de succès
Un bot avec 70 % de winrate semble excellent. Mais si ses 30 % de pertes effacent toutes ses gains, son expectancy est négative et il perd à long terme. La plupart des bots commerciaux exhibent leur winrate · presque aucun ne montre son expectancy.
→ Réponse SCT
Expectancy publiée à chaque benchmark · jamais winrate isolé. Les patterns refusés sont notés en expectancy négative (cf. tableau /sct/erreurs/). Le vocabulaire interdit le terme "winrate" comme indicateur de qualité.
05
Destruction par la volatilité · pas de sizing adaptatif
Beaucoup de bots utilisent un sizing fixe (toujours 5 % du capital). Quand la volatilité double, leur risque double aussi · une série de stops cumulés efface un mois de gains en quelques heures. Le drawdown n'est pas dû aux mauvais trades, mais à la taille mal calibrée.
→ Réponse SCT
Couche risk engine · sizing adaptatif fonction de volatility regime, drawdown courant et corrélation portefeuille. Le multiplicateur peut tomber à 0 indépendamment du signal · "réduire avant bloquer" est un invariant.
06
Survivorship bias · on ne voit que les bots qui ont survécu
Les bots affichés sur les marketplaces sont ceux qui sont encore actifs aujourd'hui. Les milliers de bots qui ont fait sauter leurs comptes ont été désinstallés ou supprimés des dashboards. On juge sur un échantillon biaisé par construction.
→ Réponse SCT
Modules supprimés, hypothèses cassées, erreurs commises sont conservés et publiés (cf. timeline V1→V18 dans /sct/doctrine/). Le passé du projet n'est pas réécrit · même les pivots difficiles restent visibles.
07
Absence de kill-switch · le bot continue de trader quand il ne devrait plus
Sans méta-couche surveillant la cohérence globale, un bot peut accumuler 8 pertes consécutives sans s'arrêter. Les conditions ont peut-être changé, son edge a peut-être disparu · il ne le saura pas. Il continuera jusqu'à la liquidation.
→ Réponse SCT
Couche kill-switch permanente · surveillance drawdown 7d / 30d, cohérence des décisions, régressions silencieuses. Quand un seuil critique est franchi, capital_preservation_mode active · sizing forcé à 0, indépendamment du reste.
Conclusion
Aucune de ces sept causes n'est résolue par "un meilleur algorithme". Toutes sont résolues par une architecture qui assume l'incertitude. C'est ce que tente le Decision OS · sans garantie de réussite, mais avec une discipline observable.
Ce que ce diagnostic n'est pas
Ce n'est pas une promesse
Traiter ces 7 causes ne garantit pas que le système gagne. Cela rend simplement moins probable qu'il échoue pour les raisons les plus banales. Les autres causes (marchés inédits, erreurs de code, biais humains) restent possibles.
Ce n'est pas une accusation
Beaucoup de bots commerciaux sont conçus de bonne foi. Mais l'architecture impose ses limites. Vendre un bot rentable en quelques semaines après backtest revient à promettre l'impossible · pas par malhonnêteté, mais par méconnaissance des sept causes.
Comment vérifier qu'un système prend ces causes au sérieux
Demande l'expectancy, pas le winrate. Si la réponse esquive, c'est un signal.
Demande la liste des modules supprimés. Un système sans historique de pivots est suspect.
Demande la doctrine versionnée. Pas de doctrine = pas de discipline.
Demande comment le système détecte un régime. Si la réponse est floue, il n'en détecte pas.
Demande à voir un trade refusé. Si tous les trades sont pris, il n'y a pas d'architecture · juste des signaux.
Demande où est le kill-switch. Sans, le bot trade jusqu'à mourir.