Calendrier de résultats et exposition gamma SPX, fusionnés en un seul tableau de bord.

Deux surfaces. Une seule décision de trading.

Une société de trading quantitatif faisait face à une frustration réelle mais banale : les données dont elle avait besoin pour prendre une seule décision se trouvaient dans deux outils distincts qui ignoraient l'existence l'un de l'autre.

D'un côté, un calendrier de résultats. Quatre grandes sources publiques, chacune légèrement différente — symboles différents, conventions d'horaire de publication différentes, doublons occasionnels, contradictions occasionnelles. L'équipe les réconciliait à la main avant tout trade.

De l'autre côté, l'exposition gamma des teneurs de marché SPX. L'indicateur de microstructure des options qui vous dit où se concentre la pression de couverture systématique — quels strikes deviennent magnétiques à mesure que le marché s'en approche, où les teneurs achèteront la faiblesse et vendront la force, de combien de marge l'indice dispose avant que la vente mécanique ne s'enclenche. Il n'y a pas de champ Bloomberg pour cela. On le dérive. Frais, depuis la chaîne d'options de la place, avec le gamma Black-Scholes calculé par strike et agrégé par ajustement de delta. Et on le fait toutes les quinze minutes pendant la séance cash, sinon le chiffre dont on dispose est déjà faux.

Le brief était précis : un seul écran, les deux signaux, synchronisés. Survolez un événement de résultats. Voyez l'image gamma pour cette date. Les produits sur étagère font l'un ou l'autre. Personne ne faisait les deux dans une seule vue.

Une vue fusionnée : calendrier d'événements en haut, exposition gamma en dessous.

Le tableau de bord donnait aux traders de la société un calendrier de résultats faisant remonter des symboles depuis quatre sources de données indépendantes — dédoublonnés, réconciliés, avec des indicateurs d'horaire de publication — superposé à un graphique d'exposition gamma en direct pour le SPX. Les deux surfaces étaient synchronisées : survolez une date de résultats, et le graphique gamma se calait sur l'image d'exposition de cette séance.

Le graphique gamma affichait l'exposition agrégée des teneurs par strike, ajustée du delta, avec une ligne de gamma net qui rendait le basculement positif/négatif visible d'un coup d'œil. Le gamma zéro — le point où la couverture des teneurs passe de stabilisante à amplificatrice — était marqué comme une constante. L'ouverture du jour et la clôture précédente servaient de lignes de référence. Les grappes de strikes où l'exposition se concentrait apparaissaient en pics.

Le calendrier de résultats affichait les événements confirmés et provisoires avec des indicateurs d'horaire de publication (BMO, AMC, non confirmé). Un filtrage au niveau du symbole, un sélecteur de plage de dates et une vue liste de suivi permettaient à un trader de cadrer le calendrier sur son portefeuille sans toucher à la couche gamma. Les deux vues partageaient le même axe des dates. C'était tout l'intérêt.

Le front tournait sur Next.js 16 et React 19, avec D3.js gérant le rendu du gamma et Zustand gérant l'état partagé calendrier/graphique. Vercel Analytics était branché dès la première semaine de production.

F · 01Calendrier de résultats multi-source

Quatre sources indépendantes dédoublonnées par symbole, date et horaire de publication. La gestion en retry-and-backoff par source dégrade le calendrier en douceur quand une source casse — la vue du trader ne s'éteint jamais.

F · 02Graphique d'exposition gamma SPX en direct

Gamma Black-Scholes calculé à neuf sur l'ensemble de la chaîne d'options SPX toutes les quinze minutes pendant les heures de marché. Agrégé par strike, ajusté du delta. Gamma zéro et lignes de référence clés marqués.

F · 03Axe des dates synchronisé

Survolez un événement de résultats et le graphique gamma se cale sur l'image d'exposition de cette séance. La fusion est dans l'interaction, pas seulement dans la mise en page.

F · 04Magasin chaud Redis uniquement

Pas de base de données froide. Les deux pipelines écrivent dans Redis JSON, clé par date et symbole. Lectures front en moins d'une milliseconde. Le motif d'accès n'a jamais eu besoin de plus.

F · 05Télémétrie par source

Chaque parseur de résultats expose son état de retry comme métrique. Un parseur cassé remonte dans le tableau de bord de monitoring en un cycle de rafraîchissement — avant que quiconque tradant sur la donnée ne le remarque.

F · 06Backend en deux langages

Node/Express pour le scraping et le dédoublonnage. Python/FastAPI pour la couche quant — scipy.stats, numpy, pandas. Chaque langage possède le problème qui lui convient. Un seul cache détient le résultat.

Un cache, deux pipelines, deux langages.

Le problème de fusion de données sous le tableau de bord était un choix d'architecture avec une réponse claire : deux pipelines indépendants, ni l'un ni l'autre ne bloquant l'autre, écrivant dans un seul magasin chaud.

Le pipeline de résultats tournait en Node et Express. Un service de scraping tirait depuis quatre calendriers publics indépendants toutes les trois heures. Chaque source avait son propre parseur — isolé, avec gestion en retry-and-backoff pour qu'une défaillance transitoire sur une source ne corrompe pas les autres. Le dédoublonnage se faisait par symbole plus date plus horaire de publication ; un symbole apparaissant dans trois sources avec des différences mineures de format de date se résolvait en un seul enregistrement canonique. La télémétrie par source faisait qu'un parseur cassé était visible dans le tableau de bord de monitoring avant qu'un trader ne remarque quoi que ce soit d'anormal.

Le pipeline gamma tournait en Python. FastAPI servait la couche quant : une chaîne d'options SPX fraîche tirée du flux CSV de la place toutes les quinze minutes pendant les heures de marché, passée par un calcul de gamma Black-Scholes via scipy.stats et numpy, agrégée par strike et ajustée du delta. Python était le bon outil ici — scipy.stats, l'écosystème scientifique Python, et la façon dont l'équipe quant raisonnait déjà sur le calcul. Le réécrire en TypeScript aurait ajouté de la friction sans aucun bénéfice.

“

Dès lors qu'il n'y avait pas de base de données froide pour se rabattre, chaque pipeline devait être correct au moment de l'écriture. Cette pression a produit des parseurs plus propres et une histoire d'astreinte plus nette.

”

Les deux pipelines écrivaient dans Redis. Pas de base de données froide — par conception, pas par omission. La télémétrie des premières semaines de production a confirmé ce que l'architecture supposait : le motif d'accès était toujours « à quoi ressemble l'image en ce moment », jamais « à quoi ressemblait-elle il y a six semaines ». Redis JSON, clé par date et symbole, donnait au front des lectures de l'état courant en moins d'une milliseconde. Le cache était tout le magasin.

Quatre ans en production. Toujours rafraîchi toutes les quinze minutes.

Le tableau de bord a connu son premier déploiement en production en 2022 et tourne sans interruption depuis. L'architecture à deux pipelines a survécu à trois ans de valse des sélecteurs sur les sources de résultats, à des changements de format du flux de la place côté gamma, et à une reconstruction complète du front lors de l'arrivée de la migration vers React 19.

La couverture des résultats s'établit à plus de 5 000 symboles répartis sur quatre sources indépendantes. Le moteur gamma traite plus de 3 000 strikes SPX par cycle d'échéance. Les cadences de rafraîchissement n'ont pas changé : les résultats toutes les trois heures, le gamma toutes les quinze minutes pendant la séance cash.

La télémétrie de disjoncteur par source a été la fonctionnalité la plus utile sur le plan opérationnel. Les parseurs de sources cassent en silence — une refonte de calendrier ou un changement d'API sans annonce. La télémétrie signale une source dégradée en un cycle de rafraîchissement. La vue du calendrier par le trader se dégrade en douceur ; elle ne s'éteint pas.

La base de code du front a atteint 325 commits à la fin de 2024. Le backend a dépassé 541. Le moteur gamma, qui a le moins changé, est à 59. Le ratio est une carte fidèle de là où le travail s'est réellement trouvé : pas dans les maths quant — ça s'est figé tôt — mais dans la maintenance continue de la couche de données en dessous.