Développement¶
La partie technique. Elle couvre l'architecture, la connexion, l'agrégation des données, le moteur de signaux, l'exécution, le backtest et la mise en production.
Ce que vous allez apprendre¶
- l'architecture d'un bot temps réel manipulant de l'argent : déterminisme, idempotence, réconciliation, observabilité, arrêt sûr ;
- comment se connecter à Rithmic en Python, normaliser les données et éviter les pièges de la classification d'agresseur ;
- comment construire un footprint correct — avec du code testé et exécutable ;
- comment écrire un moteur de signaux qui soit une fonction pure, donc backtestable sans réécriture ;
- comment exécuter et gérer des ordres sans doubler ses positions ni se retrouver sans protection ;
- comment produire un backtest honnête, et les sept biais qui le détruisent ;
- comment superviser un bot en production et détecter les pannes silencieuses.
Ordre de lecture¶
| Chapitre | Sujet |
|---|---|
| 01 · Architecture du bot | Les cinq propriétés, la boucle, le journal |
| 02 · Connexion Rithmic en Python | async_rithmic, souscriptions, idempotence |
| 03 · Construire le footprint | Code testé, primitives d'order flow |
| 04 · Moteur de signaux | Fonction pure, contexte, composition |
| 05 · Exécution et gestion des ordres | Couche de risque, machine à états, rollover |
| 06 · Données historiques et backtest | Sources, outils, sept biais, test du hasard |
| 07 · Mise en production et supervision | Hébergement, alarmes, rituel quotidien |
| 08 · La boîte à outils | Bibliothèques, stockage, frameworks, plateformes |
| 09 · Validation statistique | Triple barrière, CPCV, Sharpe dégonflé |
Statut du code¶
Ce qui est testé
Le code des chapitres 03 et 09, et de l'annexe Code complet, a été exécuté et ses assertions passent. Il n'utilise que la bibliothèque standard Python — 15 tests répartis sur trois fichiers.
Ce qui est illustratif
Le code des chapitres 02, 04, 05 et 07 dépend d'APIs externes
(async_rithmic) ou d'infrastructure. Il montre l'architecture et les
précautions ; les signatures exactes doivent être vérifiées dans la
documentation en vigueur de chaque bibliothèque.
Le chapitre 09 change la façon de conduire la recherche
Il établit qu'après 1 000 essais de paramétrage, un ratio de Sharpe de 2,30 est le résultat attendu du pur hasard, et qu'il faudrait 10,6 ans d'historique pour qu'un Sharpe de 1,0 soit crédible dans ces conditions.
Avec les quelques mois de données dont dispose un retail, cela impose de formuler peu d'hypothèses et de les tester une fois. Le balayage de grille, réflexe naturel du développeur, est structurellement incompatible avec la quantité de données disponible. C'est probablement la contrainte la plus sous-estimée de tout le rapport.
Les trois décisions structurantes¶
Si vous ne retenez que trois choses de cette partie :
- Le moteur de signaux est une fonction pure. C'est ce qui rend le backtest fidèle et les bugs reproductibles. Cette décision ne peut pas être prise après coup.
- Le journal append-only s'écrit avant la première stratégie. C'est le seul outil de débogage qui fonctionne en production, et le seul moyen de prouver ce qui s'est passé.
- L'exécution est isolée derrière une interface. Changer de prop firm devient alors l'écriture d'un adaptateur, pas la réécriture du bot.
Partie précédente : Stratégies · Partie suivante : Économie