Construire un système de trading

Gestionnaire de flux, constructeur de carnet, stratégie, gestionnaire d'ordres, barrière de risque. Les composants sont les mêmes, que vous tourniez depuis un portable ou un rack en colocation ; seul le budget de latence change.

L'idée

Quels sont les composants d'un système de trading, dans l'ordre ?

Un système de trading est une chaîne. Les passerelles se connectent à la place ; un gestionnaire de flux décode les données de marché ; un constructeur de carnet reconstruit le carnet d'ordres ; une stratégie calcule un signal et décide ; un OMS/EMS suit et route les ordres ; une barrière de risque impose des limites et peut tout couper ; et la passerelle d'ordres met les ordres sur le fil. Chaque étage consomme la sortie de l'étage précédent, c'est pourquoi le schéma ci-dessus se lit strictement de gauche à droite, des données de marché en entrée aux ordres en sortie.

En parcourant le pipeline dans l'ordre : la connectivité / passerelles sont les sessions vers la place : un abonnement entrant à un flux multicast et une session sortante de saisie d'ordres, deux canaux et deux protocoles. Le gestionnaire de flux décode le protocole sur le fil de la place (FIX/ITCH/SBE), gère le séquençage et la récupération de trous, et émet des événements internes normalisés, l'étage le premier et le plus sensible à la latence. Le constructeur de carnet applique ces événements incrémentaux pour reconstruire le carnet d'ordres en mémoire : la vue en direct du marché par le système. La stratégie / signal lit le carnet et la bande, calcule un signal (un microprice, un déséquilibre du flux d'ordres, un spread de stat arb) et décide s'il faut trader et quoi. C'est là que vit l'avantage ; tout le reste est de la plomberie qui ne doit pas perdre d'argent.

Puis la moitié en aval. L'OMS / EMS se scinde en principe entre l'Order Management System, qui suit le cycle de vie et l'état de chaque ordre (en cours, partiellement exécuté, annulé) et vos positions, et l'Execution Management System, qui décide comment travailler un ordre à travers les places : la couche de routage et d'algorithmes d'exécution ; dans un petit système ils fusionnent, mais conceptuellement ils sont distincts (tenue d'état contre politique d'exécution). La barrière de risque se place entre la décision de la stratégie et le fil, exécutant en ligne des contrôles pré-négociation (taille d'ordre max, position max, colliers de prix, limites de débit de messages) plus un interrupteur d'arrêt ; elle est obligatoire, pas optionnelle (SEC Rule 15c3-5, la règle d'accès au marché américaine, et MiFID II RTS 6 dans l'UE). Enfin la passerelle d'ordres encode l'ordre dans le protocole de saisie d'ordres de la place et l'envoie, l'autre bout de la boucle qui a commencé au gestionnaire de flux, et avec lui la borne du tick-to-trade.

Quel est le cycle de développement d'un modèle, de l'idée au live ?

Une stratégie traverse quatre étapes à porte : l'idée (une hypothèse sur une inefficacité), le backtest (la tester honnêtement sur données historiques), le paper trading (la faire tourner en direct contre le vrai marché mais sans argent réel), et le live (capital réel, petit, montant en taille seulement sur preuve). Chaque porte tue la plupart des candidates, et les flèches de la boucle de cycle ci-dessus pointent aussi en arrière : le retour du live affine l'idée.

1. Idée / hypothèse. Une affirmation précise et falsifiable (« le déséquilibre du flux d'ordres prédit le prochain mouvement à cet horizon sur cette place ») parce que les idées vagues ne peuvent être ni testées ni tuées ; ancrée dans les sections microstructure, données et stratégies. 2. Backtest. Testez l'idée sur données historiques, et c'est là que la plupart des stratégies devraient mourir. La page backtesting traite entièrement de la façon dont un backtest ment (look-ahead, biais de survie, exécutions optimistes, surajustement) et de comment le rendre honnête ; une stratégie qui ne marche qu'avec un backtest malhonnête n'est pas une stratégie, ne sautez donc pas cette porte.

3. Paper trading (test à blanc). Faites tourner la stratégie en direct contre le vrai marché en mouvement (vrai flux, vraie latence, vraie sélection adverse) mais en routant les ordres vers un simulateur ou un compte papier, pas vers le moteur d'appariement. Cela attrape ce qu'un backtest ne peut pas : problèmes de données en temps réel, bugs d'infrastructure, votre propre latence, et si l'avantage survit au contact d'un marché qui n'existait pas quand votre échantillon historique a été enregistré. 4. Live, petit, montant en taille sur preuve. Démarrez avec un capital minimal et des limites de risque serrées, mesurez la performance réalisée contre l'attente du backtest et du paper trading, et montez en taille seulement à mesure que les résultats en direct confirment l'avantage, en surveillant la capacité et l'érosion de l'alpha quand la taille grandit. La majeure partie de l'« avantage » trouvé en backtest a disparu d'ici là ; les survivants sont l'activité.

Le point est que c'est une boucle, pas une ligne : les résultats en direct rétroagissent sur l'idée : affiner le signal, reparamétrer, le retirer quand il s'érode. C'est le pipeline de la recherche à la production vu comme un cycle, et la discipline qui sépare un desk d'un parieur.

Quelle est la différence entre un OMS et un EMS ?

Un OMS (Order Management System) garde l'état : le registre faisant foi du cycle de vie de chaque ordre et de vos positions et expositions courantes. Un EMS (Execution Management System) prend les décisions d'exécution : comment découper, cadencer et router un ordre à travers les places pour minimiser le coût. L'OMS est le grand livre ; l'EMS est le cerveau d'exécution. Les petits systèmes les combinent ; les rôles restent distincts.

L'OMS suit chaque ordre à travers ses états (envoyé, accusé de réception, en cours, partiellement exécuté, exécuté, annulé, rejeté), réconcilie contre les rapports d'exécution, maintient les positions et le P&L, et est la source de vérité que lit la couche de risque. Si l'état de votre OMS diverge de celui de la place, vous volez à l'aveugle ; la réconciliation est un problème de correction central et peu glorieux. L'EMS, étant donné un ordre parent, décide comment l'exécuter : sur quelle(s) place(s) (routage intelligent d'ordres), selon quel calendrier, avec quelle agressivité, pour minimiser l'impact de marché et le slippage ; c'est là que vivent les pages d'algorithmes d'exécution.

Dans un système de tenue de marché HFT la frontière s'estompe (la « stratégie » est sa propre exécution), mais dans tout système tradant une taille significative la distinction compte : un composant possède la vérité, un autre possède la politique.

Comment construire cela seul en 2026 ?

Vous achetez ou louez tout ce qui est indifférencié et ne construisez que l'avantage. Le cloud loue le calcul (recherche, backtest, et live pour les stratégies non basées sur la vitesse) ; les données ouvertes (crypto, Polymarket, actions/futures achetables) suppriment le fossé des données ; le développement assisté par l'IA écrit les gestionnaires de flux, la machine à états de l'OMS, le harnais de backtest et la colle. Vous dépensez votre jugement humain rare sur la stratégie et sur la validation.

Concrètement : choisissez un jeu où la vitesse n'est pas l'avantage (la conclusion honnête de la page colocation/FPGA), c'est-à-dire stat arb, tenue de marché plus lente, multi-places, crypto, Polymarket ; la bande de la microseconde et au-delà est disputable par un ingénieur seul, la frontière de la nanoseconde ne l'est pas. Louez le calcul : des VM cloud font tourner recherche et backtests, et pour une stratégie non basée sur la vitesse elles peuvent aussi tourner en direct, avec l'arbitrage de latence rendu explicite : pas d'investissement, pas de salle serveur, le plus grand changement économique par rapport à il y a dix ans. Utilisez des données ouvertes/bon marché : les places crypto diffusent du L2/L3 complet via des API publiques, les marchés de prédiction sont ouverts, l'historique actions/futures est achetable (les pages données couvrent ce que vous obtenez et ses pièges).

Puis laissez l'IA écrire la plomberie : un assistant LLM échafaude un parseur de gestionnaire de flux à partir d'une spec de protocole, la machine à états de l'OMS, un harnais de backtest, des fixtures de test et la colle, effondrant le temps d'ingénierie qui exigeait jadis une équipe (voir ce que l'IA change pour le HFT). Mais gardez le jugement humain : quoi construire, si un avantage backtesté est réel, comment valider les exécutions, quand monter en taille, quand tirer l'interrupteur d'arrêt. Rien de cela n'est automatisable, et se tromper perd de l'argent vite : l'IA fait la frappe, vous faites la réflexion. La réserve honnête, c'est que cela marche sous la classe vitesse uniquement ; un constructeur solo ne peut pas gagner la course à la nanoseconde, et la thèse complète est sur se lancer en indépendant en 2026.

Quel est l'ordre de construction minimal viable ?

Construisez le chemin de lecture avant le chemin d'écriture, et le simulateur avant la connexion en direct. Un ordre sensé : (1) connecter un flux et construire le carnet ; (2) l'enregistrer et le rejouer ; (3) construire le harnais de backtest/simulation ; (4) écrire la stratégie et la prouver en backtest ; (5) ajouter l'OMS/EMS et la barrière de risque ; (6) faire du paper trading ; (7) passer en live petit.

Étape par étape : (1) Flux + constructeur de carnet : s'abonner à la place, la décoder, reconstruire le carnet d'ordres, et confirmer qu'il correspond à la réalité, parce que rien ne marche sans un carnet correct. (2) Enregistrer + rejouer : capturer la bande de messages pour pouvoir rejouer de façon déterministe, le fondement à la fois du débogage et du backtesting. (3) Harnais de backtest / simulation : construire le backtester honnête (rejeu de marché, modélisation de file/exécution) avant d'avoir une stratégie, pour que la stratégie soit testée honnêtement dès le premier jour. (4) Stratégie : maintenant écrire le signal et le prouver (ou le tuer) en backtest ; la plupart des idées meurent ici, ce qui est le harnais qui fonctionne.

Et la moitié en aval : (5) OMS/EMS + barrière de risque : état des ordres, routage, et le contrôle de risque pré-négociation et interrupteur d'arrêt obligatoires, construits avant qu'aucun ordre ne puisse atteindre une place en direct. (6) Paper trading : tourner en direct contre le vrai marché avec exécution simulée, attrapant les choses que seule la réalité révèle. (7) Live, petit : capital réel, limites serrées, montée en taille sur preuve. Le principe d'ordonnancement est brutal : vous pouvez perdre de l'argent à l'instant où le chemin d'écriture est en direct, donc tout ce qui valide et contraint vient d'abord. Construisez les parties qui ne peuvent que vous apprendre (flux, carnet, backtest, paper) avant les parties qui peuvent vous coûter.

Exemple travaillé

Prenez une esquisse concrète et datée d'un système de tenue de marché crypto à une personne construit en 2026, illustrative, pour rendre l'architecture et le cycle tangibles (pas une recommandation ; pédagogique seulement). Il exerce chaque bloc du schéma ci-dessus, mais à latence milliseconde plutôt qu'à la classe vitesse.

Composants. Un gestionnaire de flux décodant le flux WebSocket snapshot-plus-diff d'une seule place crypto ; un constructeur de carnet maintenant le carnet L2 d'un symbole ; une stratégie microprice-et-inventaire (de style Avellaneda–Stoikov) ; un OMS/EMS combiné plaçant et amendant des cotations bilatérales ; une barrière de risque avec une limite de position max et un interrupteur d'arrêt ; et une passerelle d'ordres via l'API d'ordres REST/WebSocket de la place. Infrastructure : une seule VM cloud près de la région de la place (latence milliseconde, correcte pour une tenue de marché plus lente, sans espoir pour l'arbitrage de latence) sans colocation, sans FPGA, sans investissement.

Cycle de vie. L'idée est de coter autour du microprice et d'incliner sur l'inventaire. Le backtest rejoue un mois de données de carnet enregistrées à travers le harnais honnête avec file/exécution et frais réalistes ; tuez-le si l'« avantage » n'est que des coûts ignorés. L'étape paper fait tourner la cotation en direct dans un simulateur pendant deux semaines, mesurant le spread réalisé capté contre la sélection adverse payée. L'étape live utilise une taille minuscule et des limites serrées, montant en taille seulement à mesure que le P&L réalisé suit l'attente, en surveillant la capacité et l'érosion.

Où le temps est passé raconte toute l'histoire. Avec le développement assisté par l'IA, la plomberie (gestionnaire de flux, carnet, OMS, échafaudage du harnais) prend des jours, pas des mois ; le vrai travail, valider que l'avantage backtesté survit au paper trading et aux frais en direct, est là où passent les semaines. Ce ratio est le tournant de 2026, et c'est la même leçon sur laquelle pivote la thèse du lancement en indépendant. Les chiffres et la mécanique de place sont illustratifs et changent ; vérifiez l'API, la grille tarifaire et les limites de la place précise en 2026. Pédagogique seulement, pas un conseil en investissement ; aucune performance n'est sous-entendue.