3forge se trouve au cœur de certains des environnements de trading les plus exigeants au monde. Pour comprendre à quoi cela ressemble de l'intérieur, nous avons échangé avec Amit Kumar Mishra, un ingénieur qui a passé des années à construire des systèmes opérationnels en temps réel dans le trading à haute fréquence. Il nous a décrit le passage de 150 écrans déconnectés à un poste opérationnel unique, l'architecture qui le rend possible, et pourquoi, sur des marchés rapides, la visibilité seule ne suffit plus.
Comment avez-vous découvert 3forge, et quel problème l'a fait entrer en jeu ?
Ma première rencontre avec 3forge remonte à 2023 environ, alors que je travaillais dans un environnement de trading à haute fréquence. L'un des plus grands défis opérationnels de l'époque était la fragmentation. La supervision opérationnelle reposait sur plus de 150 sessions RDP actives à travers l'infrastructure de trading, chaque serveur conservant son propre système de reporting, ses scripts, ses utilitaires de surveillance et ses workflows isolés.
Une grande partie de la visibilité dépendait d'outils distincts et de scripts sur mesure assemblés au fil du temps. De nombreux récapitulatifs et rapports au niveau des marchés n'étaient disponibles qu'après la clôture, ce qui rendait les décisions opérationnelles souvent réactives plutôt qu'en temps réel.
La demande de la direction était très claire : tout rassembler dans une vue opérationnelle unifiée. Ils voulaient une visibilité sur les transactions, les PnL au niveau des algorithmes, les positions nettes, les pertes, les rejets et les alertes, avec une supervision en temps réel depuis un poste unique, au bureau comme à distance. Ce fut ma première introduction pratique à 3forge.
Que cherchiez-vous à résoudre, et qu'est-ce qui vous a marqué d'emblée ?
Au départ, l'accent était mis sur la consolidation opérationnelle et la supervision continue. Nous cherchions à éliminer la dépendance à des systèmes de reporting déconnectés et à créer une couche unifiée où les informations critiques de trading et d'infrastructure pouvaient être suivies en continu.
Ce qui m'a marqué immédiatement, c'est la capacité à agréger des données en direct provenant de plusieurs systèmes dans une vue opérationnelle structurée et interactive. Au lieu d'attendre les récapitulatifs de fin de journée, les pertes, les rejets, l'activité de trading et les PnL par stratégie devenaient visibles en temps réel.
Un autre changement important : la plateforme ne se limitait pas à la visualisation. Les mêmes données pouvaient aussi alimenter l'analytique, la surveillance et des actions pilotées par des workflows. Cela a entièrement changé notre façon de concevoir les tableaux de bord : on est passé du reporting passif à l'intelligence opérationnelle.
Comment les systèmes de trading en temps réel étaient-ils habituellement assemblés avant 3forge ?
La plupart des environnements de trading en temps réel que j'ai rencontrés étaient assemblés comme des ensembles de systèmes déconnectés plutôt que comme une plateforme opérationnelle unifiée. Chaque équipe construisait ses propres utilitaires de reporting, tableaux de bord, scripts et couches de surveillance autour d'applications ou de serveurs individuels.
Sur le plan opérationnel, cela créait de la duplication et de la fragmentation. Sessions RDP multiples, outils de reporting isolés, bases de données distinctes, tableurs, scripts sur mesure et utilitaires de surveillance autonomes étaient monnaie courante. Les systèmes en temps réel devenaient souvent fortement couplés à des workflows ou à des personnes spécifiques, si bien que le diagnostic exigeait de passer d'un système à l'autre et reposait largement sur une coordination manuelle.
Autre point de friction majeur : la visibilité différée. De nombreux récapitulatifs et rapports importants n'étaient disponibles qu'après la clôture ou en fin de journée. Le temps que les anomalies, pertes, rejets ou problèmes d'exécution deviennent visibles, l'occasion de réagir de façon proactive était déjà passée.
Il y avait aussi une grande complexité à intégrer flux de marché en direct, jeux de données historiques, moteurs d'analyse, couches de visualisation et workflows opérationnels. Dans bien des environnements, ces éléments évoluaient indépendamment, entraînant logique dupliquée, déplacements de données répétés et surcharge d'infrastructure. Ce qui ressortait avec 3forge, c'était la capacité d'évoluer vers un modèle centralisé et piloté par les événements, où surveillance, analytique, workflows et état opérationnel en direct pouvaient coexister de manière bien plus intégrée.
Comment votre perception de la plateforme a-t-elle évolué avec le temps ?
Au départ, je voyais 3forge principalement comme une couche de reporting et de tableaux de bord, essentiellement un moyen de visualiser plus proprement les récapitulatifs de PnL et les métriques opérationnelles en temps réel. À mesure que nous montions en charge en production, les aspects architecturaux les plus importants sont apparus.
L'une des premières prises de conscience, c'est que dans les environnements HFT, le tableau de bord est en réalité la partie facile. Le vrai défi, c'est le déplacement et la synchronisation des données à travers une grande infrastructure distribuée. Récupérer en continu des données opérationnelles depuis des centaines de serveurs par interrogation crée de la surcharge réseau, des difficultés de mise à l'échelle, de la latence et de la complexité opérationnelle.
Ce qui est devenu de plus en plus important, c'est la façon dont 3forge gère la propagation d'état en temps réel et le traitement par deltas. Au lieu de transférer sans cesse des jeux de données complets, seuls les changements incrémentaux circulaient sur le réseau. Dans les grands environnements, cette différence compte : elle réduit le trafic inutile tout en maintenant une visibilité continue.
La modularité de la plateforme s'est aussi distinguée. En allant au-delà des premiers tableaux de bord, il est devenu clair que le système pouvait prendre en charge des workflows plus larges où différents composants évoluaient indépendamment tout en restant connectés sur le plan opérationnel. Et la simplicité d'utilisation comptait : des équipes ayant des connaissances techniques de base pouvaient construire des vues opérationnelles utiles sans longs cycles de développement, ce qui abaissait la barrière entre équipes d'infrastructure, équipes opérationnelles et métiers. Avec le temps, ma compréhension est passée d'une plateforme de visualisation à un cadre opérationnel en temps réel.
Que signifie « aller au-delà des configurations par défaut » dans les environnements HFT ?
En HFT, le temps de réaction est critique : l'architecture ne peut pas reposer sur les modèles traditionnels d'interrogation. Le polling introduit du délai, du trafic réseau inutile et une surcharge de mise à l'échelle, et le temps que les données soient récupérées et traitées, l'occasion de réagir peut déjà être perdue.
Une limite de nombreux déploiements par défaut est l'hypothèse que les systèmes passent confortablement à l'échelle dans des environnements monolithiques. En pratique, les architectures monolithiques deviennent vite des goulots d'étranglement, car chaque dépendance supplémentaire introduit contention, délai et complexité de reprise. Pour nous, le déploiement modulaire est devenu extrêmement important : découpler l'ingestion, les workflows, la visualisation et l'analytique a réduit à la fois la pression sur l'infrastructure et la fragilité opérationnelle tout en gardant l'état synchronisé.
Autre défi : la fiabilité du flux de données. Même lorsque la latence est faible, la couche réceptrice doit ingérer des rafales de mises à jour en continu sans perdre d'information.
Et la visibilité seule ne suffit pas. Même si les humains voient les changements en temps réel instantanément, le temps de réaction humain devient le goulot d'étranglement. L'évolution suivante, ce sont les workflows pilotés par les événements, où les systèmes s'abonnent directement aux données de transactions, aux événements opérationnels et aux changements d'état du marché, et déclenchent des actions automatiquement. C'est là que l'architecture passe des tableaux de bord et de la surveillance à l'orchestration opérationnelle en temps réel.
Quel rôle joue la modularité, en particulier autour des composants Center, Web et Relay ?
Dans l'infrastructure de trading, la modularité n'est pas qu'une préférence de conception ; c'est une nécessité opérationnelle. Même lorsque les composants tournent sur la même machine physique, séparer les responsabilités rend l'environnement plus facile à faire évoluer, à diagnostiquer et à mettre à l'échelle.
Ma façon de voir est simple : Relay doit gérer l'ingestion, les instances Center doivent traiter et maintenir les données, et Web doit se concentrer sur la présentation et l'interaction utilisateur. Nous utilisions des relays pour récupérer les données depuis Kafka et les transmettre conditionnellement aux instances consommatrices pertinentes, ce qui évitait des déplacements de données inutiles et permettait aux modules en aval de ne s'abonner qu'à ce dont ils avaient besoin.
Quand les responsabilités sont fusionnées dans un montage monolithique, même de petits changements comme des modifications de schéma peuvent exiger des redémarrages ou provoquer des perturbations plus larges. Avec la modularité, chaque composant fait sa part indépendamment : un module traite les données de transactions, un autre calcule le PnL, un autre gère les alertes ou les abonnements, tandis que la couche Web rassemble et affiche les résultats. Cela permet aux calculs et aux workflows de s'exécuter en parallèle plutôt que de forcer chaque étape à attendre la précédente.
Les données traitées par un module peuvent aussi devenir la source d'un autre, créant une chaîne de workflows en temps réel où différentes instances opèrent simultanément, chacune apportant de la valeur sans bloquer le système. C'est là que le découplage crée une réelle valeur opérationnelle : meilleure résilience, moins de dépendances inutiles, traitement parallèle, et possibilité de mettre à l'échelle ou de modifier des parties spécifiques indépendamment.
Qu'est-ce qui rend l'architecture de données en temps réel difficile dans les environnements à faible latence ?
C'est difficile parce que le système doit équilibrer en même temps vitesse, fiabilité et exactitude continue de l'état. En HFT, les données n'arrivent pas de façon régulière. Il y a des pics d'ingestion, des rafales d'événements et des périodes où la couche réceptrice doit vider les files d'attente en continu. Si les files commencent à s'accumuler, le système peut encore techniquement fonctionner, mais sur le plan opérationnel il a déjà commencé à prendre du retard sur le marché.
Les plus grands défis sont les pics d'ingestion, l'arbitrage latence/fiabilité, et la convergence des données en direct et historiques. Les systèmes en direct ne peuvent pas attendre : les rejets d'ordres, par exemple, doivent être visibles et traités immédiatement, sinon l'impact commercial s'est déjà produit. Les systèmes historiques ont une nature différente ; ils peuvent traiter par lots, rejouer, agréger et analyser des tendances sur de plus longues périodes. Dans notre cas, pouvoir consulter la situation de marché et le comportement opérationnel sur une période glissante de six mois est devenu précieux pour l'analyse et l'amélioration des stratégies.
Le défi s'accroît quand les équipes combinent flux en direct, données historiques, analytique, visualisation et workflows dans la même architecture. Les systèmes en direct ont besoin de ressources temps réel, de traitement rapide et de réponse immédiate, tandis que les systèmes historiques privilégient le stockage, l'agrégation et la rejouabilité. En environnement live, le débit, la vidange des files et le temps de réponse des abonnements de workflow comptent tous. Il ne suffit pas d'afficher des données ; les systèmes doivent s'abonner aux événements pertinents, les traiter rapidement et déclencher des réponses sans créer de goulots d'étranglement. C'est pourquoi l'architecture de trading en temps réel doit être conçue dès le départ autour du flux d'événements, de la mise en mémoire tampon, de la gestion d'état et du temps de réponse.
Quelles tendances observez-vous dans l'écosystème technologique du trading en Inde ?
L'écosystème technologique du trading en Inde évolue très vite, et les attentes autour des systèmes temps réel ont beaucoup changé ces dernières années. Auparavant, beaucoup d'environnements étaient assemblés avec des scripts, des outils de reporting isolés, de la surveillance manuelle et des récapitulatifs de fin de journée. Aujourd'hui, les entreprises attendent de plus en plus une visibilité en direct sur les ordres, les transactions, les rejets, le PnL, le risque, la santé de l'infrastructure et les exceptions opérationnelles.
On met davantage l'accent sur l'automatisation, la surveillance en temps réel, la gestion des données de marché, les tableaux de bord opérationnels et une réaction plus rapide aux événements. Le trading algorithmique et la modernisation de l'infrastructure ne sont plus des niches ; ce sont des priorités opérationnelles courantes. Autre tendance majeure : le passage des tableaux de bord comme affichages passifs vers des tableaux de bord comme couches de contrôle opérationnel. Les équipes veulent des systèmes qui s'abonnent aux données en direct, détectent les anomalies, déclenchent des actions, alimentent les systèmes en aval et réduisent le temps de réaction humain.
En même temps, beaucoup d'entreprises subissent encore les frictions d'outils fragmentés, de workflows dépendants des personnes, de systèmes hérités et d'une visibilité différée. L'opportunité aujourd'hui est d'évoluer vers des architectures modulaires et pilotées par les événements, où analytique, surveillance, workflows et traitement des données en direct sont connectés sans duplication inutile. Le marché indien entre dans une phase où les entreprises ne demandent plus seulement « Pouvons-nous voir les données ? ». Elles demandent : « Le système peut-il comprendre ce qui a changé et réagir assez vite pour que cela compte ? »
Comment les attentes évoluent-elles, des tableaux de bord vers les workflows pilotés par les événements ?
L'attente dépasse clairement les tableaux de bord comme simples outils de visualisation passive. Un tableau de bord qui montre PnL, transactions, positions, ordres et exceptions au même endroit reste important, mais dans les environnements à haute fréquence, la visibilité seule ne suffit plus.
La vraie question est : que se passe-t-il après que le système a détecté un changement ? Si un ordre est rejeté, si une stratégie sort de son comportement attendu, si le PnL se détériore soudainement ou si la santé de l'infrastructure change, le système ne devrait pas se contenter de l'afficher. Il devrait s'abonner à l'événement, évaluer la condition, déclencher des workflows, notifier les bonnes personnes et, le cas échéant, alimenter les systèmes en aval pour une action supplémentaire. C'est là que l'infrastructure de trading passe des tableaux de bord à des systèmes opérationnels pilotés par les événements.
Dans notre environnement, les abonnements en temps réel et les workflows opérationnels sont devenus essentiels. Nous avons mis en place des alertes via Slack et des mécanismes de coupe-circuit déclenchés par des conditions de surveillance en temps réel, afin de réduire la dépendance à l'observation manuelle et de raccourcir le temps de réaction. Le temps de réaction humain est un facteur majeur : sur des marchés rapides, le temps que quelqu'un remarque un problème sur un tableau de bord et réagisse, l'impact peut déjà s'être produit. Les entreprises veulent de plus en plus des plateformes qui font plus que visualiser : des abonnements, des alertes, des actions automatisées, des intégrations avec des systèmes externes, et la capacité de convertir l'intelligence opérationnelle en réponse immédiate.
Comment 3forge lui-même a-t-il évolué à mesure que vous l'utilisiez davantage ?
Au départ, je voyais 3forge surtout comme une couche de reporting et de visualisation, et notre premier cas d'usage était la consolidation opérationnelle : rassembler transactions, PnL, pertes, rejets et supervision dans une vue unifiée en temps réel. Avec le temps, ma compréhension a beaucoup changé.
L'une des premières grandes prises de conscience, c'est que 3forge, combiné à des workflows et des intégrations sur mesure, pouvait évoluer vers une architecture opérationnelle bien plus large qu'un simple système de tableaux de bord. En explorant plus loin, des capacités comme la gestion de données tabulaires en mémoire, le stockage historique, les abonnements en temps réel, les déclencheurs et les workflows AMIScript sont devenues de plus en plus importantes. Nous avons commencé à construire de la logique opérationnelle autour de la plateforme au lieu de simplement afficher des informations par-dessus.
L'évolution a été progressive. Au début, nous utilisions des processus Python externes pour interroger les données, effectuer des calculs et réinjecter les résultats afin de prendre en charge des workflows au-delà des capacités par défaut de l'époque, comme des PnL spécifiques à une stratégie et des analyses opérationnelles sur mesure. Plus tard, nous avons développé des modules AMI personnalisés en Java pour des intégrations plus étroites et plus natives. Cela a fait passer la plateforme, dans notre perception, d'un outil de visualisation à un cadre opérationnel en temps réel flexible.
Autre changement majeur : le modèle piloté par les abonnements. Au lieu d'interroger en continu les changements d'état, les systèmes pouvaient s'abonner aux mises à jour pertinentes et réagir en temps réel. Cela a été particulièrement important pour des workflows comme la surveillance et le débouclage de positions ouvertes, où le temps de réaction compte directement. Ce qui est devenu stratégiquement précieux, c'est l'ouverture de l'architecture : intégrer des couches de traitement personnalisées, combiner données historiques et temps réel, construire des déclencheurs et des workflows, et faire évoluer le système progressivement sans tout redessiner. Avec le temps, ma perception est passée d'une plateforme de reporting à un écosystème opérationnel en temps réel qui prend en charge ensemble analytique, workflows, surveillance, abonnements, automatisation et intégrations sur mesure.
Quel conseil donneriez-vous aux équipes qui mettent en œuvre 3forge dans des environnements exigeants ?
Commencez par cartographier le cycle de vie complet d'un événement à travers le système de trading : comment les données circulent de l'ingestion aux workflows, à l'analytique, au stockage, puis enfin aux tableaux de bord ou aux actions automatisées. Dans le trading, un seul ordre ingéré peut déclencher plusieurs workflows indépendants à la fois. Le même paquet peut devoir mettre à jour simultanément les carnets d'ordres en attente, l'historique des ordres, les carnets de transactions, de rejets, d'annulations, les positions nettes et les modules d'analyse d'ordres. Plus tard, les calculs de carnet net peuvent dépendre des données de carnet de transactions, tandis que les prix en temps réel peuvent devoir être récupérés séparément depuis les systèmes de données de marché.
La décision architecturale importante consiste à identifier quels workflows sont séquentiels et lesquels peuvent s'exécuter en parallèle. Si des processus peuvent s'exécuter simultanément, transmettez les paquets à plusieurs instances immédiatement plutôt que de forcer une longue chaîne séquentielle. L'une des plus grandes erreurs des équipes est de placer tout le flux dans la même instance de traitement, où l'ordre suivant ne peut pas avancer efficacement tant que le précédent n'a pas terminé toutes ses étapes, ce qui crée latence et goulots d'étranglement inutiles. Concevez plutôt autour d'un traitement modulaire et parallèle, où chaque instance a une responsabilité précise et où les modules en aval ne s'abonnent qu'aux données dont ils ont besoin.
La conception des données compte aussi. Les équipes stockent souvent les données telles que reçues sans évaluer la cardinalité des champs. Comme 3forge utilise un modèle de stockage en colonnes, les champs à forte cardinalité peuvent créer une pression mémoire inutile en environnement live. Les systèmes historiques sont plus faciles à optimiser car les données peuvent être compressées ou réorganisées au fil du temps, mais les systèmes live exigent une planification mémoire soignée dès le départ.
Je recommande aussi fortement de penser au-delà des tableaux de bord très tôt dans la conception. Le vrai avantage vient de l'identification des workflows qui peuvent être automatisés avec des abonnements, des déclencheurs et de la logique sur mesure. Le plus grand changement d'état d'esprit, c'est de comprendre que les tableaux de bord ne sont qu'une couche de l'architecture ; l'avantage concurrentiel réel vient de la réduction du temps de réaction opérationnel, de la distribution intelligente des workflows et de la conversion de la visibilité en temps réel en action en temps réel. Une phrase à laquelle je reviens souvent : « Et ensuite… pourquoi pas mieux ? »
