Sociétés de développement Rust pour plateformes de trading et moteurs d'appariement : quelles parties ont besoin de Rust et comment engager une équipe dédiée

Cherchez une société dont les propres ingénieurs ont construit en Rust un moteur d'appariement ou une autre partie du chemin de l'ordre, et le font tourner en production. Avant de signer, rencontrez les personnes qui rejoindraient votre équipe. Rust se justifie là où un retard coûte de l'argent : le moteur d'appariement, les contrôles de risque pre-trade, les passerelles vers les bourses et le gestionnaire de données de marché. Les écrans, les rapports et les outils de back-office peuvent rester dans les langages que votre entreprise utilise déjà.

Quelles sociétés sont spécialisées dans les plateformes de trading et les moteurs d'appariement en Rust ?

Cet article ne classe pas les sociétés. Une spécialiste est une société dont les propres ingénieurs ont déjà livré un système de trading en Rust et l'exploitent pour un client. Une société qui recruterait ses ingénieurs Rust après votre signature vous propose en réalité un plan de recrutement.

Le code de trading est souvent privé : les clients en sont généralement propriétaires et le gardent pour eux, si bien qu'une société solide peut avoir peu de code de trading sur GitHub. Demandez plutôt la description de bout en bout d'un système en production : ce qu'il fait, quelles parties sont écrites en Rust, comment sa vitesse est mesurée, qui l'exploite aujourd'hui et ce qui a cassé après le lancement. Si un accord de confidentialité masque le nom du client, demandez à la société d'organiser un appel avec ce client.

Vérifiez ensuite les personnes. Obtenez les noms et l'expérience Rust des ingénieurs qui travailleraient sur votre système, et parlez-leur avant de signer. L'article sur les équipes dédiées, en lien plus haut, couvre les vérifications générales : le code public, un essai payant et une revue par un ingénieur indépendant.

Quelles parties d'une plateforme de trading faut-il écrire en Rust ?

Celles qui se trouvent sur le chemin d'un ordre, là où une pause de quelques millisecondes peut changer le prix obtenu par un client :

• Le moteur d'appariement, qui apparie les ordres d'achat et de vente selon le prix et l'heure d'arrivée
• Les contrôles de risque pre-trade, qui bloquent un ordre qui enfreint une limite avant qu'il n'atteigne le marché
• Les passerelles qui envoient les ordres aux bourses ou aux brokers et reçoivent leurs réponses
• Le gestionnaire de données de marché, qui lit les flux de prix et transmet chaque mise à jour

Rust convient à ces parties parce qu'il libère la mémoire sans ramasse-miettes. Certains langages en utilisent un pour cette tâche, et il peut mettre le programme en pause à des moments qu'il choisit lui-même. Le livre de Rust (le guide officiel du langage, consulté le 27 octobre 2026) indique que l'ownership, l'ensemble de règles qui rend cela possible, « permet à Rust d'offrir des garanties de sécurité mémoire sans avoir besoin d'un ramasse-miettes ».

Le langage ne rend pas à lui seul un système rapide. Un programme Rust peut toujours s'arrêter pour demander de la mémoire, attendre un verrou détenu par un autre thread ou attendre le réseau. L'article sur la conception d'un moteur d'appariement explique comment une équipe tient tout cela à l'écart du chemin de l'ordre.

Le reste de la plateforme n'a pas d'échéance mesurée en millisecondes : écrans web et mobiles, comptes clients, rapports, back-office et outils d'administration. Ces parties peuvent rester dans les langages que vos développeurs ou vos fournisseurs utilisent déjà. Une société qui propose de les réécrire en Rust devrait expliquer ce que vous y gagnez.

Nous avons déjà une plateforme en C++, Java ou Go. Faut-il la réécrire en Rust ?

En général, pas d'un seul coup. Une voie plus sûre consiste à déplacer un composant aux frontières claires, comme les contrôles de risque ou le gestionnaire de données de marché, et à laisser le reste tel quel.

Le nouveau composant peut tourner comme un service distinct qui échange des messages avec le reste du système. Il peut aussi être construit comme une bibliothèque que du code C ou C++ appelle directement. Le Rustonomicon, le guide du projet Rust consacré au code unsafe et de bas niveau, explique comment dans une section intitulée « Calling Rust code from C ».

Avant la bascule, faites tourner le nouveau composant à côté de l'ancien sur le même flux d'ordres enregistré et comparez chaque résultat. Un moteur d'appariement déterministe donne toujours le même résultat pour les mêmes ordres dans la même séquence. La comparaison devient alors simple : si les deux moteurs appliquent les mêmes règles, toute différence signale un bug dans l'un d'eux.

Basculez ensuite un marché ou un groupe d'instruments à la fois, et gardez l'ancien composant prêt à reprendre le trafic.

Que comprend une équipe Rust dédiée externe pour un moteur d'appariement ?

Une équipe dédiée travaille uniquement sur votre système pendant des mois ou des années, et ses membres ne changent qu'avec votre accord. Pour un moteur d'appariement ou une autre partie du chemin de l'ordre, elle comprend généralement :

• Des ingénieurs Rust qui ont déjà mis du code en production et savent comment vit un ordre : types d'ordres, exécutions partielles, modifications et annulations
• Un ingénieur principal qui porte la conception et relit chaque changement du chemin de l'ordre
• Un ingénieur de test qui monte l'environnement rejouant le flux d'ordres enregistré et vérifie les résultats
• Une personne responsable des serveurs, des réglages réseau et des mises en production

Votre entreprise a aussi un rôle à jouer. Quelqu'un de votre côté fixe les règles de négociation, comme les pas de cotation, les horaires de négociation, les frais et ce qui se passe lors d'une suspension, et répond sans longs délais aux questions de l'équipe à leur sujet.

Les freelances peuvent être d'excellents ingénieurs, mais la continuité est plus difficile avec eux. Un prestataire seul n'a personne pour relire ses changements sur le chemin de l'ordre, et quand cette personne part, ce qu'elle savait de votre système part avec elle. Une société peut remplacer quelqu'un et garder le savoir dans l'équipe, et le contrat peut l'y obliger.

Une société ne peut dimensionner l'équipe qu'après avoir vu vos règles de négociation, vos marchés et vos volumes ; demandez-lui donc comment elle est arrivée au chiffre qu'elle propose.

Que demander à une équipe Rust à propos d'un moteur d'appariement ?

L'article sur les sociétés spécialisées dans la faible latence explique comment vérifier les chiffres de vitesse. Ces questions portent sur Rust et sur le chemin de l'ordre :

• Où votre code utilise-t-il unsafe, et qui relit ces parties ?
• Comment testez-vous le moteur, au-delà du rejeu d'ordres enregistrés ?
• De quelles crates dépend le chemin de l'ordre, et comment les vérifiez-vous pour les vulnérabilités connues ?
• Avec quelle version de Rust compilez-vous, et comment décidez-vous quand la mettre à jour ?
• Qui, dans l'équipe proposée, a déjà mis Rust en production, sur quel système, et ce système tourne-t-il toujours ?

Rust vérifie l'usage de la mémoire dès la compilation du code. Dans un bloc marqué unsafe, le code peut faire cinq choses que le compilateur refuse autrement, comme suivre un pointeur brut jusqu'à la mémoire. Le livre de Rust ajoute que unsafe « ne désactive pas le borrow checker ni aucune des autres vérifications de sécurité de Rust ». Une bonne réponse indique où se trouve le code unsafe, pourquoi il y est nécessaire et qui l'a vérifié.

Côté tests, une équipe doit nommer les outils qu'elle utilise. cargo-fuzz, que le Rust Fuzz Book appelle « l'outil recommandé pour le fuzz testing du code Rust », alimente un programme avec de grandes quantités d'entrées générées pour trouver les cas qui le font planter. Loom, une bibliothèque pour tester du code qui s'exécute sur plusieurs threads, « exécute les tests de nombreuses fois, en permutant les exécutions concurrentes possibles de chaque test ». On trouve ainsi des bugs qui n'apparaissent que lorsque les threads s'exécutent, par malchance, dans un mauvais ordre.

Les crates sont les paquets de code partagé de Rust. La RustSec Advisory Database recense les avis de sécurité visant les crates publiées sur crates.io. Son outil cargo-audit vérifie le Cargo.lock d'un projet, le fichier qui liste la version exacte de chaque dépendance, « pour repérer les crates présentant des vulnérabilités de sécurité ». Une équipe qui travaille sur un chemin d'ordres doit pouvoir vous dire si cette vérification tourne à chaque build.

Rust publie une nouvelle version stable toutes les six semaines, et le livre de Rust affirme que « vous ne devriez jamais avoir peur de passer à une nouvelle version de Rust stable ». Une équipe peut tout de même garder chaque build sur une version choisie. La documentation de rustup, l'installateur de Rust, décrit un fichier de toolchain pour les projets qui se retrouvent « “figés” sur une version précise de Rust » et veulent l'inscrire dans leur dépôt. Sur un chemin d'ordres, la version ne devrait changer que volontairement, une fois les tests passés.

Que doit prévoir le contrat avec une équipe Rust ?

Inscrivez-y ces points :

• Le code, les tests, les données de rejeu et les scripts de build se trouvent dans des dépôts dont votre entreprise est propriétaire
• Les builds et les mises en production tournent dans des comptes ouverts au nom de votre entreprise
• Qui peut modifier le chemin de l'ordre et qui relit chaque changement
• Les heures couvertes par l'équipe, et qui répond si le moteur tombe en panne en dehors de ces heures
• Ce que vous recevez si le contrat prend fin : la documentation, les accès et du temps de l'équipe pour passer le relais à la suivante

Où se situe amBrain ?

amBrain, qui publie ce blog, se décrit en une ligne : « amBrain est une société d'ingénierie logicielle basée à Erevan, en Arménie, qui construit des plateformes de trading à faible latence, des moteurs d'appariement et des systèmes de real-time bidding en Rust. » Une autre ligne dit : « amBrain construit des infrastructures de trading algorithmique : exécution des ordres, données de marché et contrôles de risque pre-trade. »

amBrain développe des logiciels depuis 2019. Son équipe, selon ses propres mots : « Une équipe pouvant aller jusqu'à 40 personnes, dont environ 75 % de seniors. » Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. »

Cet article n'est pas une étude de cas et ne décrit aucun travail pour un client. Il ne dit pas quels systèmes amBrain a construits en Rust ni pour qui, et ne donne ni prix, ni délais, ni tailles d'équipe d'amBrain. Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.