Plus tôt cette année durant la conférence CppCon, le plus grand rassemblement mondial pour les praticiens experts de C++, Tower Research Capital a tenu une séance de questions. Des ingénieurs, des spécialistes quantitatifs et des participants curieux se sont réunis pour discuter de l’approche de Tower en ce qui concerne la négociation, l’infrastructure et l’ingénierie de systèmes à grande échelle.

Les questions que nous avons reçues allaient des choix de langages et de l’architecture de plateforme aux réalités de la construction de systèmes à latence ultra faible à l’échelle mondiale. La conversation a permis de souligner un point en particulier : il y a un intérêt marqué pour la façon dont les entreprises comme Tower combinent une ingénierie de pointe avec une négociation systématique.

Pour poursuivre cette discussion au-delà de la salle de conférence, nous avons compilé certaines des questions les plus fréquemment posées à propos de notre entreprise ainsi que nos réponses ici. C’est un peu comme une version concentrée de la séance de question; un aperçu de la façon dont nous construisons, exploitons et faisons évoluer l’une des plateformes de négociation les plus sophistiquées au monde.

Comment l’équipe principale d’ingénierie de Tower est-elle structurée et comment soutient-elle la négociation?

Notre approche d’ingénierie repose sur un modèle de réseau en étoile : notre plateforme alimente un éventail diversifié d’équipes de négociation internes qui travaillent indépendamment les unes des autres. L’équipe principale d’ingénierie développe l’infrastructure partagée tandis que nos équipes de négociation se connectent sur cette plateforme pour effectuer des recherches ainsi qu’élaborer et mettre en œuvre leurs stratégies de négociation. Cet équilibre nous permet de progresser rapidement en matière de stratégie et d’innovation tout en maintenant des systèmes essentiels cohérents, stables et continuellement optimisés.

Quels langages utilisez-vous, et à quelles fins?

Nous utilisons un mélange de C++, Python et Rust, chacun à des fins précises :

• C++ alimente nos systèmes les plus sensibles à la latence (données du marché, exécution et infrastructure de bas niveau).
• Python est fortement utilisé dans la recherche, l’analyse des données et l’orchestration.
• Rust est de plus en plus utilisé pour les infrastructures et les services où la sécurité et la robustesse de la mémoire sont importantes.

Dans tous les cas, nous commençons par l’objectif final et travaillons à rebours, en sélectionnant le langage qui convient le mieux à la tâche à accomplir.

Quels sont les plus grands obstacles techniques de Tower en ce moment?

La mise à l’échelle du rendement tout en gardant les systèmes propres et faciles à entretenir pose toujours problème. Nous raffinons constamment une plateforme mondiale qui prend en charge des styles de négociation très différents, avec une latence ultra faible et des approches gourmandes en données, sans fragmenter le code. Il y a aussi le côté organisationnel : s’assurer que les équipes indépendantes peuvent innover tout en bénéficiant de bibliothèques, d’infrastructures et de normes partagées.

Comment les analystes quantitatifs et les ingénieurs collaborent-ils pendant le cycle de vie de la recherche à la production?

Les analystes quantitatifs et les ingénieurs collaborent à trois étapes principales du cycle de vie :

• Recherche et prototypage – Les analystes quantitatifs testent des hypothèses, conçoivent des fonctionnalités et entraînent des modèles à petite échelle. Ce travail est exécuté sur une infrastructure partagée (p. ex., couches de données, pipelines de fonctionnalités, cadres d’expérience et calculs) construite et maintenue par des ingénieurs de recherche. La collaboration lors de cette phase vise à permettre une itération et une expérimentation rapides afin que les analystes quantitatifs puissent valider efficacement les idées.
• Production – Les analystes quantitatifs et les ingénieurs de production travaillent en étroite collaboration pour traduire le code de recherche en systèmes prêts pour la production. Cela comprend l’optimisation du calcul des caractéristiques, l’inférence de modèle et la performance globale du système. Les ingénieurs sont principalement responsables du déploiement, de la fiabilité de l’exécution et de la connectivité du marché (flux de données, acheminement de commandes, systèmes d’exécution) nécessaires à l’exécution des stratégies en direct.
• Postproduction et itération – Les analystes quantitatifs et les ingénieurs surveillent conjointement le rendement en direct à la fois dans les dimensions du modèle et de l’infrastructure. Ils diagnostiquent des problèmes tels que les régressions de latence, le calcul inefficace des fonctions, les écarts de données, le glissement de l’exécution, etc. Les données tirées de cette phase sont utilisées pour affiner le modèle par les analystes quantitatifs et améliorer l’infrastructure en cours par les ingénieurs.

Quelles filières universitaires ou quels cours spécifiques les candidats souhaitant rejoindre Tower devraient-ils privilégier ?

Les filières STEM (sciences, technologie, ingénierie, mathématiques) sont généralement les plus pertinentes, en particulier les mathématiques, l’informatique, la physique et les statistiques. Ces disciplines développent les compétences fondamentales recherchées chez Tower : aisance avec les problèmes quantitatifs, solides capacités d’analyse et aptitude à transformer des questions complexes en approches claires et testables. Cela dit, il n’existe pas de parcours unique ou obligatoire. La meilleure préparation consiste à approfondir sérieusement la filière choisie et à acquérir de solides bases dans des domaines comme les probabilités, les statistiques, les algorithmes et la programmation. Nous recherchons également des profils capables de collaborer efficacement, de bien communiquer et de progresser continuellement dans des environnements exigeants.

Comment conciliez-vous la cohérence globale avec les exigences spécifiques des marchés régionaux ? Quels facteurs déterminent si quelque chose doit être standardisé dans la plateforme centrale ou géré au niveau régional ?

Nous échangeons régulièrement avec les responsables des marchés régionaux afin de comprendre les exigences propres à chaque région. Ensemble, dans un cadre collaboratif, nous identifions les points communs et prenons des décisions architecturales éclairées. Dans ce processus, nous examinons des facteurs tels que : si une exigence est largement applicable à plusieurs marchés, si elle reflète une véritable structure de marché locale ou un besoin réglementaire, le degré d’urgence de la livraison, ainsi que l’impact opérationnel et architectural à long terme du choix d’une solution plutôt qu’une autre. En tant qu’organisation, nous cherchons à standardiser autant que possible et à investir dans une plateforme centrale capable d’évoluer à l’échelle des marchés, mais nous faisons des exceptions pour des livraisons régionales urgentes qui ne peuvent pas attendre une standardisation globale.

Comment évaluez-vous les nouveaux langages, frameworks ou outils avant de les adopter à grande échelle ?

Tower dispose d’un groupe interne dédié à l’architecture logicielle, qui joue un rôle central dans l’évaluation des nouveaux langages, frameworks et outils avant leur adoption pour les composants critiques de notre infrastructure de trading. Les propositions peuvent émaner d’ingénieurs de l’ensemble de l’organisation. Selon leur complexité, nous constituons parfois un groupe de travail réunissant des experts techniques de différents départements afin d’étudier la solution envisagée.

Notre processus d’évaluation repose généralement sur le développement d’une preuve de concept (proof of concept ou PoC), qui nous permet de renforcer notre confiance dans la technologie proposée, d’en mesurer les performances et de recueillir les retours des principales parties prenantes avant toute décision de déploiement à grande échelle.

Quels enseignements tirez-vous généralement d’événements de marché rares mais extrêmes, comme la pandémie de COVID-19 ou la crise financière mondiale ?

Les épisodes de marché extrêmes mettent souvent à l’épreuve des hypothèses qui passent inaperçues dans des conditions normales. Ils révèlent les points de fragilité potentiels des modèles, des infrastructures, des flux de données, des hypothèses de liquidité ou encore des processus opérationnels.

Pour les chercheurs quantitatifs et les ingénieurs, l’un des principaux enseignements est l’importance de concevoir des systèmes à la fois robustes, facilement observables et capables de s’adapter. S’il est impossible de prévoir précisément le prochain choc, il est en revanche possible de développer des outils permettant aux équipes de comprendre rapidement ce qui se passe, de déterminer si un problème provient du marché, du modèle ou de l’infrastructure, puis d’y répondre de manière rigoureuse et méthodique.

Ces événements rappellent également l’importance de faire preuve d’humilité. Les données historiques sont indispensables, mais elles ne reflètent jamais l’ensemble des régimes de marché susceptibles de se présenter à l’avenir. Des pratiques solides en matière de recherche et d’ingénierie tiennent compte de cette réalité en surveillant en permanence les performances en production, en remettant régulièrement en question les hypothèses retenues et en intégrant les enseignements tirés de l’exploitation des systèmes dans les développements futurs.

Surveillez cette page pour d’autres questions et réponses. Pour en savoir plus sur les perspectives de carrière à Tower, explorez-les ici.