08 · La boîte à outils

Panorama complet des bibliothèques, formats, bases et plateformes utiles à un bot d'order flow retail, avec une recommandation par poste.

Le piège transversal : la collectionnite d'outils

Elle remplace le travail sur l'edge par du shopping logiciel. Un trader qui change de framework tous les mois n'a jamais 200 trades validés sur quoi que ce soit.

Choisissez un outil par poste, adapté à votre vitesse de trading, et tenez-vous-y. Ce chapitre est une carte pour choisir une fois, pas un catalogue à parcourir régulièrement.

La pile recommandée en une page

Poste	Recommandation	Alternative
Connexion Rithmic	async_rithmic (Python)	rithmic-rs (Rust)
Connexion ProjectX	project-x-py	REST/SignalR à la main
Sérialisation	msgspec	orjson
Boucle d'événements	uvloop	asyncio standard
Stockage brut	Parquet + partitionnement par jour	DuckDB
Analyse	Polars	DuckDB si la RAM est limitée
Backtest event-driven	Rejeu maison du journal	NautilusTrader
Backtest de file (passif)	hftbacktest	—
Validation statistique	purgedcv	Code maison (voir annexes)
Données historiques MBO	Enregistrement maison	Databento
Supervision	cron + fichier sentinelle	Prometheus/Grafana

Le reste du chapitre justifie chaque ligne.

Connexion et exécution

Rithmic

Bibliothèque	Langage	État	Notes
async_rithmic	Python 3.10+	Active (1.5.x en 2026), MIT	Async, reconnexion, retry, multi-comptes, streaming L2
rithmic-rs	Rust	Active	Clients par plant, trois stratégies de reconnexion
pyrithmic	Python	Ancêtre d'async_rithmic	Moins maintenu

async_rithmic annonce le streaming de profondeur L2 (tous les bids/asks sur plusieurs niveaux). Le MBO n'apparaît pas dans ses fonctionnalités annoncées.

ProjectX / TopstepX

project-x-py est un SDK Python async mature (version 3.3.x) : gestion complète du cycle de vie des ordres, positions, données OHLCV temps réel multi-timeframe, carnet L2 avec analyse de microstructure, et une suite d'indicateurs techniques. Il expose notamment de la détection de spoofing.

Le SDK ProjectX est plus complet que les bibliothèques Rithmic

C'est contre-intuitif — Rithmic est la plateforme la plus « pro » — mais l'écosystème open source de ProjectX est plus riche, parce que l'API est plus simple à envelopper (REST + SignalR contre protobuf + plants).

Si votre firme est chez Topstep, c'est un argument de plus en faveur de ProjectX, en complément de ceux du chapitre Alternatives.

Performance en Python

Trois bibliothèques qui changent réellement quelque chose, dans cet ordre de priorité :

msgspec

Sérialisation et validation. Ses auteurs annoncent décoder et valider du JSON plus vite qu'orjson ne le décode seul, et des structures msgspec.Struct 5 à 60 fois plus rapides que des dataclass sur les opérations courantes (msgspec).

Remplacez vos dataclasses par des Struct

Les types du chapitre Architecture (Trade, Quote, Intent) sont créés à chaque message de marché. Sur un flux ES en séance, c'est le poste d'allocation dominant du bot. Le passage à msgspec.Struct est un remplacement quasi mécanique, avec un gain mesurable et aucun risque.

uvloop

Remplacement de la boucle d'événements asyncio, écrit en Cython au-dessus de libuv. Gains annoncés de 2 à 4 fois sur le débit et la latence.

import uvloop
uvloop.install()   # avant tout asyncio.run()

Une ligne, aucun changement de code applicatif.

Polars et DuckDB

Pour l'analyse et l'agrégation de données tick.

Outil	Force	Faiblesse
Polars	Vitesse brute, API expressive, group_by_dynamic pour le rééchantillonnage	Consommation mémoire élevée sur gros volumes
DuckDB	Empreinte mémoire maîtrisée par streaming, SQL, lit le Parquet directement	Un peu moins rapide sur les cas en mémoire

Les mesures publiées montrent DuckDB gardant une empreinte de l'ordre de 0,5 à 2,4 Go là où Polars monte de 1,7 à 23 Go sur les mêmes volumes (codecentric).

Le critère de choix est la RAM, pas la vitesse

Si vos données tiennent en mémoire : Polars. Si vous analysez plusieurs années de ticks sur une machine modeste : DuckDB. Les deux lisent le même Parquet, le changement est donc réversible — c'est le seul poste de cette liste où hésiter ne coûte rien.

Ne mettez ni l'un ni l'autre dans le chemin critique

Polars et DuckDB sont des outils de recherche et de backtest. Le bot en production agrège son footprint avec du Python pur, dictionnaire par dictionnaire, comme au chapitre Construire le footprint. Charger un DataFrame à chaque tick est une erreur d'architecture, pas une optimisation.

Stockage

Solution	Quand
Parquet partitionné	Par défaut. Gratuit, portable, lu par tous les outils Python
DuckDB	Quand vous voulez interroger en SQL sans charger en mémoire
ArcticDB	Open source (Man Group), pensé pour Python et les données financières
QuestDB	Si vous ingérez en continu et interrogez en temps réel
ClickHouse	Volumes très importants, requêtes analytiques colonnaires
kdb+/q	Jamais, en retail. Cher, langage exotique

QuestDB publie un débit d'ingestion annoncé de plusieurs millions de lignes par seconde et se positionne explicitement sur les ticks financiers (QuestDB).

Commencez en Parquet, un fichier par jour et par instrument

data/
  MES/
    2026-07-29.parquet
    2026-07-30.parquet

C'est suffisant pour des années de données, ça se lit en une ligne avec Polars ou DuckDB, et ça ne demande aucun serveur à administrer. Passez à QuestDB ou ClickHouse le jour où cette organisation vous gêne réellement — pas avant.

Trois erreurs de stockage à ne pas commettre

1. Stocker en CSV : lent, lourd, formats de date ambigus.
2. Ne pas versionner : impossible de reproduire un backtest ancien à l'identique.
3. Mélanger brut et nettoyé : gardez le brut intact et en lecture seule, régénérez le propre par un traitement rejouable.

Données historiques

Databento

Client Python officiel, format DBN binaire compressible, schémas mbo, mbp-10, tbbo, trades, ohlcv. Documentation dédiée à la reconstruction du carnet à partir du MBO, avec des instantanés qui réinsèrent chaque ordre en attente en préservant la priorité de file (Databento).

Le point qui compte : les instantanés préservent la priorité

Sans cela, il est impossible de démarrer une reconstruction de carnet en milieu de séance sans perdre la position en file. C'est ce qui rend Databento utilisable pour évaluer une stratégie passive — ce que le History Plant de Rithmic ne permet pas.

Sierra Chart / Denali

Pour ceux qui passent par une plateforme plutôt que par une API : le flux Denali de Sierra Chart est décrit comme fournissant des données non filtrées avec des volumes bid et ask exacts, horodatés à la source par la bourse, et de l'historique tick sur les futures CME populaires depuis 2011 (Sierra Chart).

C'est une source de données de qualité professionnelle à prix retail, et elle est indépendante du courtier.

La heatmap historique exige un enregistrement

Le « Market Depth Historical Graph » de Sierra Chart n'existe que si vous avez enregistré (ou téléchargé) les données de carnet. Et son affichage par défaut montre la quantité maximale vue à chaque niveau pendant la barre, pas la quantité finale : un mur affiché deux secondes puis annulé peint toute la colonne.

En relecture, les leurres paraissent donc bien plus persistants qu'ils ne l'ont été. Un réglage (« Use Last Quantity Instead Of Max Quantity ») corrige l'affichage. Vérifiez-le avant de juger un niveau « défendu » sur l'historique — sinon vous entraînerez votre œil, ou votre bot, sur un artefact.

Frameworks de backtest

Framework	Type	Pertinence order flow
NautilusTrader	Event-driven, Rust + Python	Élevée. Nanoseconde, adaptateur Databento, indicateur de déséquilibre de carnet intégré
hftbacktest	Rust + Python	Élevée pour le passif. Modèles de file et de latence
vectorbt	Vectorisé	Exploration massive de paramètres uniquement
backtesting.py	Event-driven minimal	Test rapide d'une idée simple
Backtrader	Event-driven	Mûr mais quasi plus maintenu
QuantConnect / LEAN	Plateforme + moteur	Tout-en-un, apprentissage exigeant
PyBroker	Orienté ML	Validation intégrée

hftbacktest en détail

L'outil de référence si votre stratégie repose sur des ordres passifs. Il modélise :

• la position en file avec plusieurs modèles (RiskAverseQueueModel, ProbQueueModel, L3FifoQueueModel) ;
• des latences distinctes à l'aller et au retour ;
• la reconstruction complète du carnet à partir de flux L2 (MBP) ou L3 (MBO) ;
• une structure ROIVectorMarketDepth limitant le carnet à une plage de prix d'intérêt, pour la performance (DeepWiki).

Vous n'en avez probablement pas besoin

hftbacktest résout le problème de l'exécution passive. Or le chapitre Anatomie d'une stratégie recommande de commencer agressif, précisément parce que le passif est inévaluable en retail.

Installez hftbacktest le jour où vous avez une stratégie passive validée en agressif et du MBO historique. Pas avant : c'est un outil lourd pour un problème que vous n'avez pas encore.

Vectorisé contre event-driven

Architecture	Vitesse	Risque de look-ahead
Vectorisé	Très élevée	Élevé : un décalage d'une ligne oublié suffit
Event-driven	Faible	Structurellement protégé

Le pipeline correct

Vectorisé pour explorer vite (balayer 2 000 combinaisons), event-driven pour la validation finale et le déploiement. Et le même code event-driven passe en réel sans réécriture — c'est l'argument décisif.

Le test qui détecte une fuite d'information

Remplacez les prix futurs par du bruit aléatoire. Si la performance tient, il y a une fuite. C'est dix lignes de code et cela attrape la classe de bugs la plus coûteuse du backtest.

Validation statistique

Bibliothèque	État	Contenu
purgedcv	Active	Compatible scikit-learn : purge, embargo, CPCV, Deflated Sharpe
mlfinlab	Fermé	Relicencié en produit payant à source fermée
timeseriescv	Abandonné	Plus de release depuis 2018, problèmes de correction connus
RiskLabAI	Code de recherche	Référence, pas une dépendance

L'implémentation canonique n'est plus libre

mlfinlab, l'implémentation de référence des méthodes de López de Prado, a été relicenciée en produit payant à source fermée. purgedcv comble le vide laissé, avec purge, embargo, validation croisée purgée combinatoire et Deflated Sharpe Ratio dans une interface compatible scikit-learn.

Alternative pour un besoin limité : les implémentations en Python pur de l'annexe code, qui couvrent le PSR, le DSR, le Minimum Backtest Length et la triple barrière sans aucune dépendance.

Le détail méthodologique fait l'objet du chapitre suivant, Validation statistique.

Plateformes graphiques

Quand l'API directe est refusée, ou pour la supervision humaine en parallèle du bot :

Plateforme	Langage d'extension	Spécificité order flow
Sierra Chart	C++ (ACSIL)	Numbers Bars jusqu'à 3 colonnes par barre, TPO et profils natifs, heatmap de profondeur historique
NinjaTrader 8	C# (NinjaScript)	Order Flow+, SuperDOM, stratégies ATM, market replay intégré
ATAS	C#	Clusters, détecteurs d'icebergs, graphique Cumulative Trades (gros prints filtrés)
Quantower	C#	DOM Surface (heatmap maison), scanner Power Trades (rafales)
Bookmap	Java, Python	Données non filtrées et non agrégées, profondeur complète, API de trading complète
Jigsaw daytradr	—	Reconstructed Tape, alertes iceberg / block / gros trade, position en file affichée

Bookmap reste l'option la plus sous-estimée pour un bot

C'est la seule plateforme de cette liste dont l'API se programme en Python, donne accès à des données véritablement non agrégées avec la profondeur complète, et permet l'exécution — sans conformance Rithmic à passer.

Si votre prop firm autorise Bookmap mais pas l'API Rithmic, c'est le chemin le plus court vers un bot d'order flow réel.

Le piège des ordres stop simulés

NinjaTrader distingue deux mécanismes qu'il est facile de confondre :

Type	Où il est tenu	Survit à une déconnexion ?
Ordre stop réel	À la bourse	Oui
Ordre stop simulé	Sur votre machine	Non

Les ordres simulés ne fonctionnent que tant que la plateforme tourne : une coupure de connexion ou un plantage laisse la position sans protection. Un décalage de la connexion ou une lenteur de la plateforme peut aussi retarder la détection du prix de déclenchement (NinjaTrader — forum support).

Les stratégies ATM disposent par ailleurs d'un mode côté serveur depuis la version 8.1.1.0.

Vérifiez lequel des deux vous utilisez — c'est un réglage, pas une fatalité. C'est exactement le scénario contre lequel le chapitre Architecture recommande les protections côté serveur.

Supervision

Besoin	Outil minimal	Outil complet
Signal de vie	Fichier + cron	Prometheus + Alertmanager
Métriques	Fichier texte lu en SSH	Grafana
Alertes	Script + notification	PagerDuty, ntfy
Journal	Fichier JSONL gzippé	Loki, ClickHouse

Restez au minimal aussi longtemps que possible

Une pile Prometheus/Grafana ajoute des services qui peuvent tomber eux-mêmes, et une charge d'administration. Un cron qui lit un fichier et envoie une notification ne tombe pas.

Le seuil de bascule : quand vous faites tourner plus de trois bots, ou quand vous voulez des graphiques historiques de latence. Pas avant.

Ce que vous n'avez pas besoin d'écrire

Un rappel utile, parce que la tentation est forte :

Tentation	Ce qui existe déjà
Un moteur de backtest	NautilusTrader, ou le rejeu de votre journal en 15 lignes
Un client Rithmic	async_rithmic
Un modèle de file d'attente	hftbacktest
Un format de stockage	Parquet
Une validation croisée purgée	purgedcv
Un reconstructeur de carnet	Databento (documentation et exemples)

Ce que vous devez écrire vous-même : votre moteur de signaux, votre couche de risque, et votre journal. Le reste est de la plomberie déjà résolue.

Résumé

• Une pile recommandée par poste, à choisir une fois.
• msgspec et uvloop : deux gains réels et quasi gratuits en Python.
• Polars ou DuckDB selon la RAM — jamais dans le chemin critique du bot.
• Parquet partitionné par jour suffit longtemps.
• NautilusTrader pour l'event-driven, hftbacktest seulement si stratégie passive.
• mlfinlab n'est plus libre ; purgedcv le remplace.
• Bookmap : la seule plateforme avec API Python, données non agrégées et exécution.
• Les ordres stop simulés de NinjaTrader ne survivent pas à une déconnexion.

---

Chapitre précédent : Mise en production et supervision · Chapitre suivant : Validation statistique