Contexte
En fondant une société de market making, nous avons dû construire l'ensemble de la plateforme à partir de zéro : moteur de trading, algorithmes, infrastructure d'exécution et supervision. En tant que co-fondateur et CTO, j'ai conçu et écrit l'ensemble du système, aujourd'hui utilisé en production pour plus de trente clients.
La plateforme regroupe plusieurs briques techniques et opérationnelles. Le schéma ci-dessous présente l'ensemble du système et les équipes qui l'exploitent ; cette étude de cas se concentre sur la chaîne d'observabilité, la base de séries temporelles et Grafana surlignées ci-dessous. Le moteur central et le copilote IA ont leurs propres études de cas.
Le problème
Un desk de market making fonctionne 24/7, avec du capital constamment exposé, sur plusieurs plateformes et pour de nombreux clients. Sans visibilité en temps réel, l'équipe ne peut pas détecter les dérives opérationnelles assez tôt.
- Il devient difficile d'évaluer rapidement l'état d'une stratégie : le spread est-il sur sa cible, l'inventaire est-il équilibré, les cotations sont-elles fraîches ?
- Les incidents ont un impact financier rapide : un flux figé, un spread qui dérive ou un service silencieux peuvent générer des pertes en quelques minutes.
- Les mêmes questions se répètent sur plus de trente clients, chacun sur des places, symboles et comptes différents.
- Des logs bruts dispersés entre les services ne suffisent pas pour détecter ces anomalies à temps.
Objectifs
- Une visibilité en temps réel sur chaque client, plateforme, symbole et compte.
- Suivre les métriques critiques pour le market making : spread, profondeur du carnet, inventaire, ordres ouverts, liquidité fournie, fills et PnL.
- Détecter les anomalies et alerter l'équipe avant qu'elles ne deviennent des pertes.
- Mettre en place une chaîne cohérente, depuis les services jusqu'au stockage, aux tableaux de bord et aux alertes.
Mon approche
Chaque service Fortuna émet des métriques structurées, acheminées vers une base de séries temporelles. Grafana exploite ensuite cette source pour alimenter les tableaux de bord et les alertes. L'ensemble crée une source de vérité unique, consultée par tout le desk pour suivre l'état opérationnel de la plateforme.
La solution technique
Les métriques sont stockées dans PostgreSQL avec l'extension TimescaleDB : un seul moteur pour le modèle relationnel et les séries temporelles, interrogé en SQL par Grafana.
- Un cœur relationnel : clients, exchanges, symboles, comptes et actifs sont des tables de dimensions. Les variables du tableau de bord s'appuient directement dessus, ce qui permet à un seul tableau de bord de couvrir tous les mandats.
- Des séries temporelles en hypertables : tickers, bougies, spread, profondeur, soldes, ordres et exécutions ont chacun leur table, indexée par horodatage et partitionnée en segments d'un jour.
- Une rétention adaptée au coût : les points bruts sont conservés 30 jours, moins pour les séries les plus volumineuses.
- Des agrégats continus : des agrégats journaliers et hebdomadaires sont rafraîchis automatiquement et conservés deux ans, afin que les vues longues et les rapports ne parcourent jamais les données brutes.
- Une écriture sans risque pour le trading : les services écrivent via un sink asynchrone qui journalise et abandonne le lot en cas d'erreur, sans lever d'exception. Une panne de la base n'arrête donc jamais une stratégie. Les bougies et les ordres clôturés sont écrits en upsert, ce qui rend toute réémission idempotente.
L'observabilité repose sur un tableau de bord Grafana unique, entièrement paramétré par variables, plutôt que sur un tableau de bord distinct par client. Les variables (client, exchange, symbole, compte, tag, devise de référence, actif et intervalle) permettent au même tableau de bord de couvrir plus de trente mandats. L'utilisateur sélectionne un client et une plateforme ; chaque panneau s'adapte automatiquement. Le tableau de bord est organisé en sections, chacune centrée sur un aspect critique du market making :
- Général : ticker, volume du jour, PnL, spread courant et graphique en chandeliers.
- Inventaire : soldes et usage de chaque actif, dans le temps.
- Profondeur : liquidité fournie autour du mid, de 0,5 % à 20 %, en valeur courante et moyenne, côté bid et ask.
- Ordres : nombre et âge des ordres ouverts, liquidité côté achat et vente, et carnet coté en direct.
- Spread : spread dans le temps par rapport à la cible, plus best bid, best ask et mid.
- Trades : achats vs ventes, PnL réalisé et volume exécuté.
Alertes
Les tableaux de bord permettent de surveiller l'activité ; les alertes garantissent que les anomalies critiques sont remontées sans surveillance manuelle constante. Les alertes surveillent les signaux dont la dérive peut avoir un impact financier, puis notifient le desk via Slack et les canaux d'astreinte 24/7 :
- Fraîcheur des données : âge de la dernière mise à jour, afin de détecter rapidement un flux bloqué ou un service interrompu.
- Spread hors bande : le spread coté qui sort de sa plage cible.
- Dérive d'inventaire : soldes qui s'écartent des seuils ou équilibres attendus.
- Absence de métriques : service qui cesse d'émettre des données.
Résultats
- Un seul tableau de bord générique donne une visibilité en temps réel sur plus de trente clients et leurs plateformes.
- Le desk suit en un coup d'œil le spread, la profondeur, l'inventaire, les ordres et le PnL, par client et par plateforme.
- Des problèmes jusque-là invisibles (flux figés, spread qui dérive, services silencieux) déclenchent désormais des alertes en quelques secondes.
- La même base de métriques alimente le copilote IA : questions et rapports s'appuient sur la même source de vérité.
Ce que j'en retiens
Pour un desk 24/7, l'observabilité n'est pas un confort : elle fait partie du dispositif de gestion du risque. En structurant les métriques dans une base de séries temporelles et en les reliant aux tableaux de bord comme aux alertes, la plateforme devient surveillable, exploitable et fiable. Cette source de vérité sert ensuite de fondation aux autres outils internes, notamment au copilote IA.