Les systèmes que nous avons conçus pour négocier nos propres capitaux

Le module définit la géométrie de la grille autour d'un prix de référence : les bornes de la plage, le nombre de niveaux, le type d'espacement et la taille à chaque niveau. L'espacement peut être arithmétique — un écart de prix identique entre niveaux adjacents — ou géométrique, où le rapport entre prix adjacents est constant. L'espacement géométrique est plus robuste sur de larges plages ; l'espacement arithmétique suffit à l'intérieur d'une bande étroite. Les prix et tailles calculés sont conformés aux règles de précision de l'instrument par la couche d'adaptation. Les niveaux inférieurs au notionnel minimal sont écartés pendant que la grille est encore en cours d'assemblage — avant que la plateforme ne les rejette.

Chaque niveau est décrit par une machine à états : annulé, placé, partiellement exécuté, entièrement exécuté. Après une exécution complète, le module place un ordre inverse au niveau adjacent ; une exécution partielle ne réinitialise pas l'état du niveau. Les ordres sont placés en mode teneur de marché exclusif (post-only) : un ordre rejeté est repositionné au prix courant plutôt que de franchir l'écart (spread). Une sortie de la plage est traitée par l'une de plusieurs politiques explicitement définies — figer la grille, la décaler d'un pas, ou une reconstruction complète avec un numéro de génération incrémenté. Les reconstructions sont bornées par une hystérésis et un délai de refroidissement ; faute de quoi la grille se repositionnerait à chaque tick et atteindrait la limite de fréquence des requêtes.

Le moteur transforme l'intention d'une stratégie en un flux concret de commandes. Un ordre à cours limité post-only — lorsque l'objectif est de rester fournisseur de liquidité sans franchir l'écart. Un ordre à cours limité agressif assorti d'un prix de protection plutôt qu'un ordre au marché — lorsque le plafonnement du glissement (slippage) importe. IOC ou FOK — là où une exécution partielle ou différée est inacceptable. Chaque ordre existe sous la forme d'une machine à états : de la création locale jusqu'à un état terminal, avec des transitions qui ne progressent que vers l'avant. Une position est calculée à partir de la taille effectivement exécutée et du prix moyen d'exécution — la taille demandée de l'ordre ne dit rien du résultat.

Le canal vers la plateforme d'échange est peu fiable ; le moteur part donc du principe qu'une réponse peut être perdue, livrée deux fois ou reçue dans le désordre. Un identifiant d'ordre auto-attribué est généré avant l'envoi et sert de clé d'idempotence : une requête répétée avec la même clé ne crée pas de second ordre. Après un dépassement de délai, le moteur ne renvoie pas à l'aveugle — il interroge le statut au moyen de cette clé. Les événements du flux privé sont dédupliqués par identifiant d'exécution et écartés s'ils renvoient à un état antérieur à celui déjà appliqué. L'annulation et l'exécution sont toujours en concurrence ; aussi un rejet d'annulation motivé par « ordre déjà exécuté » est-il traité comme une transition normale de la machine à états, et non comme un échec.

Le module construit l'état de l'instrument à partir d'un flux de bougies clôturées et fournit à la couche de négociation trois grandeurs : une estimation de la volatilité, les bornes de la plage courante et une mesure continue du caractère latéral du marché. La volatilité est calculée de plusieurs manières — l'ATR de Wilder, sa forme normalisée au prix NATR, et des estimateurs fondés sur l'amplitude (Parkinson, Rogers–Satchell, Yang–Zhang). Chaque méthode est calculée sur une fenêtre courte et une fenêtre longue : la courte réagit rapidement, la longue fournit une estimation structurelle stable. L'espacement de la grille est dérivé du NATR et borné des deux côtés : par le bas, par le coût d'un aller-retour complet (frais plus écart) ; par le haut, par le temps d'inactivité acceptable d'un niveau. Le nombre de niveaux est borné par la limite d'ordres ouverts et le capital par niveau.

Le régime de marché est classé à partir de mesures indépendantes : l'ADX, le ratio d'efficience du mouvement, le R² d'une régression linéaire du prix, un ratio de variance, l'exposant de Hurst sur une fenêtre longue et la compression des bandes de Bollinger à l'intérieur des canaux de Keltner. Ce qui est exposé n'est pas un indicateur binaire mais un poids continu, soumis à une exigence de stabilité sur N bougies. Les paramètres sont réévalués à la clôture de la bougie, avec hystérésis et uniquement en cas d'écart significatif par rapport à la configuration courante : reconstruire la grille signifie annuler et placer des ordres, c'est-à-dire une charge sur les limites de fréquence et un risque de glissement. Tous les indicateurs sont calculés de manière causale, à la date de la bougie, sans fenêtres centrées ni lissage a posteriori. En cas de rupture du flux, de lacunes dans l'historique ou d'un préchauffage incomplet, le module signale un statut « indéfini », et la couche de négociation cesse de renforcer la position.

La couche de contrôle des risques se trouve sur le chemin de chaque ordre : une stratégie n'a aucun accès direct à la passerelle d'exécution et ne peut techniquement pas contourner les contrôles — c'est une propriété de l'architecture, non un accord interne. Avant son envoi, chaque ordre est vérifié au regard des règles de l'instrument, de son écart par rapport au prix de référence et de la fréquence des messages. À cela s'ajoutent des limites par stratégie, par instrument et sur la position nette agrégée sur l'ensemble des plateformes. Il existe trois modes de fonctionnement : normal, réduction seule (reduce-only) et un arrêt complet où seules les annulations sont admises.

Un contrôle pré-négociation n'est pas plus fiable que les données sur lesquelles il s'appuie : si l'enregistrement local de la position a divergé de celui de la plateforme, la limite se déclenchera correctement mais sur une donnée erronée. La couche intègre donc une boucle de réconciliation partagée par l'ensemble de l'infrastructure. La source de vérité est l'état obtenu par une interrogation dédiée de la plateforme ; le flux de mises à jour est considéré comme peu fiable par défaut. Un écart n'entraîne une action que s'il se répète plusieurs fois de suite et dépasse un seuil en notionnel — faute de quoi les ruptures de séquence du flux provoqueraient des reconstructions d'état incessantes. Le coupe-circuit est dupliqué du côté de la plateforme : si notre processus cesse d'émettre son signal périodique, la plateforme annule elle-même les ordres ouverts.

Le module maintient un registre unique de la part des capitaux propres de la société disponible pour chaque stratégie et chaque instrument. La taille d'une position individuelle est fixée comme une fraction constante du budget alloué et normalisée par la volatilité courante de l'instrument : un même notionnel porte un risque différent selon que le marché est calme ou volatil. Les budgets des stratégies ne se recouvrent pas, et tout excédent est rejeté par le contrôle pré-négociation avant même l'envoi d'un ordre.

Une part du capital n'est jamais affectée à l'ouverture de positions et est conservée en réserve contre la marge de variation, les coûts de financement et les écarts de prix. Sans une telle réserve, un saut du prix de référence (mark price) d'une seule position toucherait le collatéral commun et les autres stratégies. Le solde libre et le solde bloqué, la marge initiale et la marge de maintien sont comptabilisés séparément. Le rééquilibrage est déclenché par une bande d'écart autour des poids cibles plutôt que selon un calendrier : une bande étroite entraîne une rotation et un coût excessifs, une bande large, une dérive accumulée.

Chaque plateforme possède son propre transport, sa propre nomenclature d'instruments et ses propres règles de précision, et l'adaptateur isole ces différences. Le REST est utilisé pour les instantanés d'état, les données de référence et les requêtes de service ; le WebSocket pour les flux de cotations et les événements d'ordres ; le FIX là où il est disponible et justifié. En amont, il présente un modèle de domaine unique : un instrument avec son pas de prix, son pas de taille, son notionnel minimal et sa précision, ainsi que les événements de carnet d'ordres, de transactions et de statut d'ordre ramenés à une forme commune. Les données de référence des instruments sont relues selon un calendrier — une plateforme modifie ses règles de précision sans préavis.

L'arrondi est effectué dans l'adaptateur, avant l'envoi, de sorte que les autres modules n'aient pas à s'en préoccuper. Le prix est conformé au pas de prix, la taille au pas de taille et tronquée vers le bas afin de ne pas dépasser le solde disponible. Sont ensuite vérifiés le notionnel minimal — prix multiplié par quantité — et la précision autorisée ; un ordre qui ne satisfait pas au notionnel est rejeté de notre côté. Une connexion interrompue est traitée par un chemin dédié : reconnexion avec temporisation croissante (backoff) et gigue aléatoire, réabonnement aux flux et demande de l'état courant auprès de la plateforme.

Le moteur est conçu comme une boucle unique de traitement d'événements : données de marché, minuteurs, ordres et accusés de réception de la plateforme transitent par une seule file dans un ordre chronologique strict. Une stratégie ne voit que l'état de marché qui existait à l'horodatage courant. Le carnet d'ordres est reconstruit à partir d'un flux de mises à jour de niveaux et d'ordres (L2/L3) ; là où cette résolution est excessive, un mode de bougies agrégées est disponible. Le code de la stratégie est identique en simulation, sur un flux en direct en mode négociation simulée (paper trading) et en production — seuls les adaptateurs de données et d'exécution diffèrent.

La valeur d'un simulateur dépend de l'honnêteté avec laquelle il modélise les frictions. Un ordre à cours limité n'est pas compté comme exécuté du seul fait que le prix l'a touché : la position dans la file au niveau, le volume qui l'a traversé, les exécutions partielles et le rejet des ordres post-only qui franchiraient l'écart sont tous pris en compte. À cela s'ajoutent les frais de teneur et de preneur (maker et taker) selon un barème par paliers, l'accumulation du financement aux bornes des intervalles et un glissement fonction de la profondeur. Les latences sont spécifiées séparément — à la réception des données, à l'envoi d'un ordre et au retour de l'accusé de réception. Ce sont précisément elles qui déterminent quel état de marché la stratégie a réellement vu au moment de la décision.

La télémétrie est captée à trois niveaux. Infrastructure — processus, mémoire, pauses d'exécution, profondeur de la file. Transport — signaux de santé sur chaque canal, dérive des horloges locales par rapport à l'heure de la plateforme, taux de reconnexion. Négociation — positions ouvertes et exposition, part des ordres exécutés et rejetés, écart entre le prix d'exécution et le prix attendu. Les métriques sont écrites dans un magasin de séries temporelles à une cadence fixe plutôt que collectées à la demande au moment de l'enquête : un incident se reconstitue à partir d'une série continue de mesures, à laquelle des fragments de journaux ne sauraient suffire.

Les règles d'alerte sont construites autour de symptômes : une divergence entre l'état local et celui de la plateforme, des données de marché périmées, une latence croissante dans les percentiles supérieurs, une hausse soudaine des erreurs d'API. Un unique seuil numérique produit trop de faux positifs pour fonder une alerte à lui seul. Les signaux sont séparés par niveau de gravité, avec déduplication, regroupement et suppression des alertes dérivées ; chacun s'accompagne d'un guide d'intervention (runbook). Les routes critiques déclenchent l'annulation des ordres et un arrêt de la boucle sans attendre un opérateur. Une couche distincte est la piste d'audit : le parcours d'un ordre, de la décision au statut final, est écrit sous forme d'événements JSON structurés avec un identifiant de bout en bout dans un journal en ajout seul.

La configuration des robots est décrite sous forme de code : un schéma typé avec des plages de valeurs explicites, superposé à un ensemble de base — une couche d'environnement (exécution historique, bac à sable, production), puis les variables d'environnement et les arguments de lancement. Le schéma est strict : une clé inconnue, un type erroné ou une valeur hors plage interrompt le lancement. Une valeur par défaut substituée silencieusement reviendrait à entrer en négociation avec un jeu de paramètres non vérifié. Les clés d'accès et les identifiants d'infrastructure sont tirés d'un magasin distinct, de sorte que les paramètres eux-mêmes sont versionnés dans leur intégralité — avec un historique des modifications et la possibilité de revenir en arrière.

Les paramètres se distinguent par leur mode d'application. Les seuils de risque, les limites et l'activation des instruments sont pris en compte à la volée : un nouvel instantané de configuration est assemblé, validé et permuté par un unique basculement entre deux cycles de négociation, de sorte qu'aucun cycle ne voie jamais un état à moitié appliqué. Le schéma de connexion, l'ensemble des plateformes et la structure du magasin d'état ne changent qu'au redémarrage. En deçà du niveau de la stratégie se trouvent des plafonds non désactivables : la position et la taille d'ordre maximales, l'effet de levier, la fréquence d'envoi et le seuil du coupe-circuit. La configuration ne peut que les resserrer — tout assouplissement passe par une revue et la publication d'une nouvelle version.

Les clés d'API des plateformes d'échange sont émises avec le jeu minimal d'autorisations : la négociation est autorisée, les retraits sont désactivés du côté de la plateforme, et la clé elle-même n'est valide que depuis les adresses IP sortantes fixes des nœuds d'exécution. Là où une plateforme prend en charge les clés asymétriques (Ed25519, RSA), nous les utilisons de préférence au HMAC : seule la partie publique demeure du côté de la plateforme, et la partie privée ne quitte jamais notre périmètre. Chaque requête est signée sur une chaîne canonique assortie d'un horodatage et d'une fenêtre de validité étroite. Les horloges des nœuds sont synchronisées par NTP : la plateforme écarte une signature expirée avant qu'elle n'atteigne la logique de négociation.

Le magasin est séparé des nœuds de négociation : les secrets reposent chiffrés sur disque selon un schéma d'enveloppe, la clé maîtresse ne quitte jamais le module matériel (HSM), et le texte chiffré est conservé à l'écart de la clé de chiffrement. Le processus de négociation ne reçoit jamais le secret en mémoire — il appelle un service de signature via TLS mutuel avec son propre certificat de service et reçoit une signature prête à l'emploi. Chaque appel est inscrit dans un journal en ajout seul. Le modèle de menace prévoit la compromission d'un nœud individuel ; aussi les clés sont-elles séparées par plateforme, par sous-compte et par boucle : la clé de négociation est conservée à l'écart de la clé en lecture seule utilisée pour la réconciliation.