Protocoles de messagerie
∞structurelFIX pour la saisie d'ordres, protocoles binaires pour la vitesse, multicast pour les données de marché. Le format sur le fil est là où la latence se gagne ou se perd avant même que votre stratégie tourne.
Voir en mouvement
8=FIX.4.2|9=112|35=D|49=BUYSIDE|56=SELL|34=4|52=20260604-13:20:01|11=ORD-7|21=1|55=BTC|54=1|38=1.5|40=2|44=68250.5|59=0|10=131|
À remarquer. FIX n'est que des paires tag=valeur séparées par un délimiteur. Lisible et omniprésent pour la saisie d'ordres, mais verbeux, c'est pourquoi les places sensibles à la latence proposent des protocoles binaires compacts pour le chemin critique et gardent FIX pour le chemin lent.
Pourquoi y a-t-il deux protocoles différents, un pour les données, un pour les ordres ?
Parce que les deux flux ont des exigences opposées. Les données de marché sont une place diffusant vers des milliers d'auditeurs, donc elles utilisent l'UDP multicast (envoyer une fois, tout le monde reçoit) et tolèrent la perte occasionnelle de paquet via un canal de récupération. La saisie d'ordres est une conversation privée et fiable entre vous et le moteur d'appariement, donc elle utilise le TCP (ou un protocole de session fiable) : vous ne pouvez pas vous permettre de perdre silencieusement un ordre.
L'intuition est deux façons de parler. Un annonceur de stade (données de marché) crie une fois et toute la foule l'entend : c'est le multicast, et il est efficace précisément parce que l'émetteur ne suit pas qui écoute. Un appel téléphonique pour placer un pari (saisie d'ordres) est point-à-point et doit être fiable : vous devez savoir que l'ordre est arrivé et ce qui lui est advenu.
Ainsi les données de marché sont en multicast, fan-out, sans accusé de réception. La bourse publie chaque changement de carnet une fois sur un groupe multicast ; la carte réseau de chaque abonné reçoit les mêmes paquets simultanément, une propriété d'équité délibérée, puisque aucun participant n'est informé en premier. L'UDP n'a pas de retransmission, donc le protocole porte des numéros de séquence et un chemin de récupération séparé pour quand vous en manquez un. La saisie d'ordres, par contraste, est point-à-point sur une session fiable. Votre passerelle tient une connexion ouverte au moteur d'appariement ; chaque ordre, annulation et rapport d'exécution circule dessus avec une livraison garantie et ordonnée, et FIX superpose son propre séquençage au niveau applicatif pour qu'une session interrompue puisse reprendre sans perdre ni dupliquer un ordre.
Cette scission est le fait structurel de la connectivité de bourse, et elle façonne toute la pile à faible latence : la lance à incendie multicast entrante est là où le contournement du noyau gagne sa croûte, tandis que le chemin d'ordre sortant est là où vivent le déterminisme et les contrôles de risque pré-négociation. Vous pouvez décoder et reconstruire un ordre depuis le visualiseur de messages ci-dessus et voir exactement comment chaque canal le porte.
Qu'est-ce que FIX, et à quoi ressemble un message d'ordre FIX ?
FIX (le protocole Financial Information eXchange, en usage depuis 1992) est un protocole texte tag=valeur devenu le standard inter-places pour la saisie d'ordres et le post-négociation. Un message est une liste de champs numérotés joints par un délimiteur : signifie « ceci est un nouvel ordre », signifie « acheter ». Il est verbeux et lisible par l'humain : facile à intégrer, mais lourd sur le fil comparé au binaire.
Un NewOrderSingle () porte, entre autres : le tag 11 l'identifiant d'ordre client, 55 le symbole, 54 le sens (1 acheter, 2 vendre), 38 la quantité, 40 le type d'ordre (1 marché, 2 limite), 44 le prix et 59 la durée de validité. Le moteur d'appariement répond avec un ExecutionReport () rapportant l'ordre comme nouveau, rempli, annulé ou rejeté. Le décodeur ci-dessus explique au survol chaque tag pour que le format sur le fil cesse d'être opaque.
Pourquoi FIX persiste en 2026 : il est universel. Un seul moteur FIX parle à des dizaines de places et de courtiers en utilisant des dialectes par place plutôt qu'un code entièrement séparé. Pour un système qui ne court pas après la dernière microseconde (la plupart du stat arb, la tenue de marché plus lente, le travail inter-places) FIX est parfaitement adéquat et dramatiquement moins cher à intégrer, ce qui est pourquoi c'est le défaut naturel pour le constructeur solo. Pourquoi FIX perd la course à la vitesse : le texte est gros et doit être parsé champ par champ (disposition variable, balayage de délimiteurs) et cet encodage/décodage coûte des microsecondes que vous ne pouvez pas récupérer. C'est l'écart que comblent les protocoles binaires, et FIX lui-même a répondu avec ses propres encodages binaires (SBE et FAST).
Que sont les protocoles binaires natifs : ITCH, OUCH et SBE ?
Les protocoles binaires natifs empaquettent un message dans une disposition d'octets fixe sans texte, si bien qu'il se parse à des offsets fixes en nanosecondes. ITCH est le flux de données de marché de Nasdaq ; OUCH est le protocole de saisie d'ordres binaire d'appariement de Nasdaq ; SBE (Simple Binary Encoding) est le standard de la communauté FIX que CME et d'autres utilisent pour les deux. Le binaire est le format sur le fil du palier de vitesse.
ITCH (Nasdaq TotalView-ITCH) est un flux ordre par ordre, ou market-by-order. Il diffuse des messages Add Order, Order Executed, Order Cancel et Order Delete repérés par un numéro de référence d'ordre, si bien qu'un abonné peut reconstruire le carnet complet et la position de file de chaque ordre : la granularité dont dépendent le carnet d'ordres et la priorité prix-temps, et la même granularité que préservent les données enregistrées. OUCH est le protocole de saisie d'ordres binaire de Nasdaq (Enter Order, Cancel Order, Order Accepted, Executed) bien plus dépouillé que FIX et conçu pour le chemin d'ordre sensible à la latence. SBE est piloté par schéma : un schéma décrit le type et l'offset de chaque champ, si bien que le décodeur est généré et le message lu par arithmétique de pointeurs, pas par parsing ; les données de marché MDP 3.0 et la saisie d'ordres iLink de CME sont encodées en SBE.
Le motif est universel même là où les noms diffèrent. Le chemin sensible à la vitesse est du binaire à disposition fixe ; FIX survit là où l'ampleur et la vitesse d'intégration comptent plus que les microsecondes. Lisez toujours la spécification publiée de la place pour le jeu de messages exact : les tables de champs font autorité et elles évoluent (les spécifications Nasdaq TotalView-ITCH et OUCH, et les spécifications CME MDP 3.0 / iLink SBE). La vue binaire dans le décodeur ci-dessus montre le même ordre comme une trame à octets disposés avec offsets et un compteur « octets sur le fil », pour que le gain de taille sur FIX soit concret.
Comment un flux multicast reste-t-il correct : séquençage et récupération de lacunes ?
Chaque paquet multicast porte un numéro de séquence. Le gestionnaire de flux suit le prochain numéro attendu ; si l'un est sauté, il a détecté une lacune (un paquet perdu) et doit récupérer avant de faire confiance à son carnet. Les places fournissent une récupération par couches : une ligne A/B redondante, un canal d'instantané/rafraîchissement, et un service de retransmission TCP. Jusqu'à ce que la lacune soit comblée, le carnet est périmé et ne doit pas être tradé.
Les numéros de séquence transforment « ai-je manqué quelque chose ? » en une vérification arithmétique exacte. Parce que le flux est incrémental (chaque paquet est un delta au carnet, pas le carnet entier) un seul paquet manquant corrompt le carnet à partir de ce point, donc vous ne pouvez pas simplement continuer comme si de rien n'était.
Les défenses s'empilent du bon-marché-et-rapide au lent-et-certain. La ligne A/B (arbitrage de lignes) est la première : la place publie le même flux sur deux groupes multicast indépendants, le gestionnaire écoute les deux et prend le paquet qui arrive en premier pour chaque numéro de séquence, si bien qu'une perte sur une ligne est couverte par l'autre. Le canal d'instantané / rafraîchissement est une image périodique du carnet complet qui laisse un gestionnaire ayant pris trop de retard se resynchroniser depuis un état connu-bon puis reprendre l'application des incréments. La retransmission est un canal latéral TCP fiable pour demander les numéros manquants spécifiques : plus lent, utilisé seulement quand A/B et instantanés ne suffisent pas. Le point d'ingénierie honnête : détecter et récupérer correctement les lacunes est l'essentiel de ce qu'est un gestionnaire de flux, et se tromper subtilement (trader sur un carnet silencieusement périmé) est un bug classique et coûteux. Le même flux de messages est ce qu'un backtest fidèle doit rejouer déterministiquement et ce qui remplit le volume de données en téraoctets par jour.
Que fait un gestionnaire de flux, et pourquoi normaliser entre places ?
Un gestionnaire de flux est le logiciel qui décode le protocole sur le fil d'une place en événements internes de votre système et reconstruit le carnet à partir des incréments. La normalisation mappe le jeu de messages idiosyncratique de chaque place sur une représentation interne commune, si bien que le code de stratégie est écrit une fois contre un modèle d'événements uniforme plutôt que contre ITCH, puis SBE, puis un flux JSON crypto.
Le travail du gestionnaire de flux tourne dans un ordre strict : recevoir les paquets, vérifier la séquence et récupérer toute lacune, décoder chaque message à ses offsets d'octets, l'appliquer au carnet en mémoire, et émettre un événement interne normalisé (un AddOrder, un Trade, un BookUpdate) que le reste du système consomme. C'est le premier étage du pipeline du système et le composant le plus sensible à la fois à la latence et à la correction.
La normalisation est ce qui rend tractable un système multi-places. CME SBE, Nasdaq ITCH, un ensemble fragmenté de places d'actions et le flux diff WebSocket d'une bourse crypto décrivent tous le même objet sous-jacent, un carnet d'ordres, dans des formats mutuellement incompréhensibles. Le gestionnaire efface ces différences pour que la stratégie voie un seul flux propre. Et la réalité inter-marchés est encourageante pour un nouvel entrant : en crypto et sur les marchés de prédiction le « protocole » est en général du JSON ou du protobuf sur un WebSocket avec un modèle instantané-plus-diff : conceptuellement identique (numéros de séquence, récupération de lacunes, mises à jour incrémentales) mais bien plus facile à intégrer, ce qui fait partie de pourquoi ces places sont là où le constructeur indépendant commence.
Ce que l'IA change : générer un parseur et normaliseur conforme à partir d'une spécification publiée est désormais largement une tâche assistée par LLM : un travail qui jadis verrouillait une boutique d'une personne est un échafaudage d'une après-midi. Le jugement ne bouge pas : gérer les cas limites de récupération, bien faire les horodatages, et valider contre une bande enregistrée restent humains (voir ce que l'IA change pour le HFT). Le format sur le fil n'est pas là où est l'avantage ; y accéder proprement est un ticket d'entrée.
Exemple travaillé
Prenez un unique ordre à cours limité, acheter 100 lots d'un symbole à 50,01, limite, jour, et encodez-le des deux façons, en 2026 (illustratif et schématique ; lisez la spécification de la place pour les dispositions d'octets exactes). Vous pouvez reproduire les deux dans le décodeur ci-dessus.
En FIX, avec représentant le délimiteur SOH, le message se lit grossièrement 8=FIX.4.4 | 35=D | 11=ORD-001 | 55=XYZ | 54=1 | 38=100 | 40=2 | 44=50.01 | 59=0 : FIX 4.4, un NewOrderSingle, identifiant d'ordre client ORD-001, symbole XYZ, sens achat, quantité 100, type limite, prix 50,01, jour. C'est grossièrement 60 à 120 octets de texte, parsés en balayant les délimiteurs et en recherchant chaque tag. En binaire natif (style SBE/OUCH), le même ordre est une trame empaquetée, schématiquement [msgType:1][clOrdId:8][symbolId:4][side:1][qty:4][price:8][tif:1], en grossièrement un tiers des octets, à des offsets fixes : side est toujours l'octet N, price toujours les octets M à M+7. Pas de balayage ; le décodeur le lit par arithmétique de pointeurs.
Le chiffre à intérioriser : l'encodage/décodage binaire économise quelques microsecondes par message versus FIX, et la réduction d'octets compte le plus pour la lance à incendie multicast entrante, où au pic vous décodez des millions de messages par seconde. Pour une stratégie hors vitesse ces microsecondes sont sans importance et l'ampleur de FIX l'emporte ; pour le palier de vitesse elles sont tout le propos. Les protocoles eux-mêmes sont une infrastructure à évolution lente : le choix entre eux est une décision d'économie sur le budget de latence de votre stratégie, pas une question de lequel est « meilleur ».