Analyse du projet nautilus trader

Dans cet article, nous allons voir ce qu’est Nautilus Trader et comment l’utiliser. Je me suis penché sur cet outil car je m’étais fixé l’objectif de ré-écrire un bot de trading en Rust avant de m’apercevoir qu’il y avait déjà cette plateforme open source qui existait et qui contient déjà plus de 17 000 commits. Plutôt que de réinventer la roue, l’idée est de voir si je peux m’approprier cet outil bot pour en faire un bot d’arbitage. Cela me permet aussi de me plonger dans un large projet Rust avec bindings pour Python. Et du coup s’il manque des features, ce sera avec grand plaisir que je pourrai les coder.

Présentation

Nautilus Trader n’est pas juste une lib Python écrite en Rust; c’est un peu plus complexe.

C’est une plateforme de trading algorithmique haute performance qui utilise une architecture hybride à trois couches de langages:

1. Rust: Le moteur natif (crates/)

Le workspace Rust contient ~35 crates qui implémentent le cœur du système:

Le crate crates/pyo3/ est la passerelle: il compile une bibliothèque partagée nautilus_pyo3 qui expose les types et fonctions Rust directement en Python.

2. Cython: La couche intermédiaire (fichiers .pyx)

Il y a ~106 fichiers .pyx (Cython) et ~129 fichiers .pxd (déclarations). C’est une couche historique importante qui:

• Fournit une grande partie de l’API Python publique (stratégies, ordres, instruments, indicateurs, etc.)
• Appelle le code Rust via FFI/C (headers générés dans nautilus_trader/core/includes/)
• Implémente certains composants directement en Cython pour la performance
• Se compile en extensions C (fichiers .so/.pyd) qui se linkent aux bibliothèques statiques Rust

On le voit dans nautilus_trader/core/rust/ qui contient des fichiers .pyx comme model.pyx et common.pyx servant de pont entre Cython et les bibliothèques Rust.

3. Python pur: L’orchestration (fichiers .py)

Du Python classique pour:

• La configuration et l’orchestration du système
• Certains adapters de plus haut niveau
• Les tests

En gros l’architectue du projet se décompose comme ceci:

┌─────────────────────────────────────────────────┐
│              Utilisateur Python                 │
│         (import nautilus_trader)                │
├────────────────────┬────────────────────────────┤
│   Cython (.pyx)    │     Python pur (.py)       │
│  Extensions C/C++  │  Config, orchestration     │
├────────────────────┴────────────────────────────┤
│          FFI (C headers)  &  PyO3               │
├─────────────────────────────────────────────────┤
│              Rust (crates/)                     │
│  Core engine, model, adapters, networking, etc. │
└─────────────────────────────────────────────────┘

L’API utilisateur est en Python, mais que la performance critique est en Rust, et que le Cython sert de ciment (historique) entre les deux.

Le projet migre progressivement de Cython vers Rust/PyO3. Le Cython est la couche historique, et le Rust prend de plus en plus de place. On voit d’ailleurs que les tests ont souvent des versions _pyo3

Il y a 3 catégories d’adapters

1. Adapters Rust + couche Python fine (la majorité)

Ces adapters ont une double implémentation: le gros de la logique est en Rust, avec une couche Python par-dessus.

Par exemple pour Binance, le code Rust dans crates/adapters/binance/src/futures/data.rs (~1500 lignes) implémente le vrai client de données live (connexions WebSocket, parsing des messages, gestion de l’order book,…). Le code contient même un sous-dossier python/ avec des bindings PyO3 pour exposer certains types (enums, clients HTTP/WebSocket) à Python.

Côté Python, nautilus_trader/adapters/binance/data.py est la couche qui orchestre le tout comme la configuration, les factories, et certains traitements de haut niveau mais qui délègue le travail lourd au Rust.

2. Adapters Python pur (quelques-uns)

Certains adapters n’existent qu’en Python, sans contrepartie Rust:

3. Le template Le dossier nautilus_trader/adapters/_template/ contient un squelette Python pour créer de nouveaux adapters. Il est en Python pur:

_template/
├── __init__.py
├── core.py
├── data.py
├── execution.py
└── providers.py

Installation sur OSX

Les bases de données ne sont pas requises pour commencer. Elles sont optionnelles et servent à des cas d’usage spécifiques:

Pré-requis

# Installation de Rust
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env
# Ou update 
# rustup update stable

# uv (gestionnaire de packages Python)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Cap'n Proto
brew install capnp

git clone https://github.com/nautechsystems/nautilus_trader
git checkout master
cd nautilus_trader
export PYO3_PYTHON=$(pwd)/.venv/bin/python
make install
# Plus tard pour itérer rapidement: 
# make install-debug
uv run python -c "import nautilus_trader; print(nautilus_trader.__version__)"
# 1.222.0
# uv run python -m pip list

Utilisation basique

Organisation des exemples

Le dossier examples/ est organisé autour de 3 environnements d’exécution + un dossier utilitaire:

1. backtest/: Données historiques, exchange simulé

Si on fournit des données historiques, le moteur simule un exchange et exécute une stratégie dessus. Aucune connexion réseau, aucune clé API est nécessaire.

Le pattern est toujours le même: Engine -> Venue -> Instrument -> Data -> Strategy -> Run.

Il y a aussi 11 exemples tutoriels numérotés (example_01 à example_11) qui enseignent chacun un concept:

Chaque tutoriel a un run_example.py (le lanceur) et un strategy.py (la logique de trading).

2. sandbox/: Données live, exécution simulée

C’est un mode hybride. On se connectes à un vrai exchange pour recevoir des données de marché en temps réel, mais les ordres sont exécutés dans un simulateur local. C’est vraiment parfait pour tester une stratégie dans des conditions réelles sans risquer d’argent.

# source binance_spot_futures_sandbox.py

data_clients={
    "BINANCE_FUTURES": BinanceDataClientConfig(  # <-- Données RÉELLES de Binance
        // ...
    ),
    "BINANCE_SPOT": BinanceDataClientConfig(     # <-- Données RÉELLES de Binance
        // ...
    ),
},
exec_clients={
    "BINANCE_FUTURES": SandboxExecutionClientConfig(  # <-- Exécution SIMULÉE
        venue="BINANCE_FUTURES",
        starting_balances=["10_000 USDC", "0.005 BTC"],
    ),
    "BINANCE_SPOT": SandboxExecutionClientConfig(     # <-- Exécution SIMULÉE
        venue="BINANCE_SPOT",
        starting_balances=["1_000 USDC", "0.001 BTC"],
    ),
},

3. live/: Données live, exécution live

Dans cette section, c’est du vrai trading. C’est Organisé par exchange, chaque sous-dossier contient typiquement:

• Un data tester (*_data_tester.py) qui se connecte et affiche les données reçues, sans trader
• Un exec tester (*_exec_tester.py) qui teste le passage d’ordres réels
• Des stratégies (*_ema_cross.py, *_market_maker.py, etc.) qui sont des exemples complets.

Indicateur disponibles

Moyennes mobiles

Momentum

Volatilité

Volume

Ratio et analyse

Divers

Ichimoku est absent 😢

Analyse d’exemples

Voici la description des exemples de 4 exchanges dans examples/live/:

Binance (7 fichiers)

Bybit (8 fichiers)

OKX (3 fichiers)

Interactive Brokers (8 fichiers)

Voilà c’est tout pour cette première analyse. Je vais maintenant creuser du côté du coeur en Rust, du côté de l’arbitrage (en Python et surtout en Rust pour maximiser la latence), des screeners basiques pour trouver des cadeaux à trader et je vais peut être voir si je ne peux pas contribuer sur la création d’un indicateur ou stratégie avec Ichimoku. J’écrirais sans doute un autre article sur cet outil prochainement car je passe énormément de temps sur le sujet du trading chaque semaine et je ne documente jamais. Je ne suis pas trader pro mais je regarde presque quotidiennement depuis 4 ou 5 ans des vidéos d’analyse technique et je passe très régulièrement des trades sur des CEX. Bref pouvoir combiner 2 passions (Dev avec Rust + Python & trading) c’est top.