Sociétés de développement logiciel à faible latence : de quel type vous avez besoin et comment en tester une sur votre propre système

Aucune liste de sociétés de développement logiciel à faible latence ne convient à tous les acheteurs, car le terme recouvre des échéances qui peuvent varier d'un facteur un million. Dans le matériel de trading, il peut s'agir de dizaines ou de centaines de nanosecondes. Dans une application ou une page web, une réponse en un dixième de seconde environ paraît déjà instantanée à la personne qui l'utilise. La première question est donc de savoir où se situe votre propre échéance.

Que signifie « faible latence » pour notre système ?

Pour votre système, la faible latence est une échéance mesurée entre deux points que vous savez nommer. Les échéances se répartissent en quatre grandes plages :

• Le matériel de trading, en dizaines ou centaines de nanosecondes. STAC-T0, un benchmark développé en concertation avec des sociétés de trading membres du STAC Benchmark Council, chronomètre la vitesse à laquelle le matériel réseau et le logiciel d'un système transforment des données de marché simulées en un ordre simulé, sans logique de trading entre les deux. La présentation de STAC du 5 novembre 2020 indique que le benchmark traite le système comme une boîte noire, « en n'interagissant avec lui que par des paquets réseau, qu'il horodate au niveau matériel », et que les horodatages logiciels peuvent comporter une erreur considérable à l'échelle de dizaines ou de centaines de nanosecondes. La pile testée (stack under test), comme STAC appelle le système mesuré, peut être une carte FPGA, qui porte une puce dont les circuits sont programmés pour une seule tâche
• Les plates-formes de négociation, des microsecondes jusqu'à environ une milliseconde. La règle de l'UE sur la précision exigée des horloges d'une plate-forme de négociation lie cette précision au temps que met le système de négociation de la plate-forme à traiter un ordre et à renvoyer une confirmation. Depuis le 2 mars 2026, cette règle est le règlement délégué (UE) 2025/1155 de la Commission, qui a remplacé la règle antérieure connue sous le nom de RTS 25 et appelle ce temps latence de passerelle à passerelle (gateway-to-gateway latency), « le temps mesuré à partir du moment où un message est reçu par une passerelle extérieure du système de la plate-forme de négociation, envoyé via le protocole de soumission des ordres, traité par le moteur d'appariement, puis renvoyé jusqu'à ce qu'un accusé de réception soit envoyé par la passerelle ». Lorsque ce temps est inférieur ou égal à 1 milliseconde, les horloges de la plate-forme ne peuvent pas s'écarter de plus de 100 microsecondes du temps universel coordonné (UTC), et les horodatages doivent avoir une granularité de 0,1 microseconde ou plus fine
• L'ad tech, de quelques dizaines de millisecondes jusqu'à une seconde. OpenRTB 2.6, le standard de l'IAB Tech Lab pour le real-time bidding, permet à un ad exchange de fixer une échéance dans chaque bid request, et le temps passé à traverser Internet est décompté de cette échéance. La documentation pour les développeurs d'Authorized Buyers de Google, mise à jour pour la dernière fois le 17 septembre 2026, indique que l'échéance de réponse « varie de 80 à 1000 ms, selon le format et le type d'enchère »
• Les applications et les pages web utilisées par des personnes, autour d'un dixième de seconde. Jakob Nielsen écrivait en 1993 que « 0,1 seconde est à peu près la limite pour que l'utilisateur ait le sentiment que le système réagit instantanément ». Pour les pages web, le guide web.dev de Google, mis à jour pour la dernière fois en septembre 2025, juge la réactivité bonne lorsque l'Interaction to Next Paint (INP) est inférieure ou égale à 200 millisecondes. L'INP mesure le temps que met une page à réagir aux clics, aux appuis tactiles et aux frappes au clavier

Un même produit peut avoir des parties dans des plages différentes. Un trader lit les prix sur un écran, tandis que l'ordre qu'il envoie peut devoir respecter une échéance bien plus serrée sur le chemin de la place de marché. Notez chaque échéance avec les deux points entre lesquels elle se mesure. La plage dans laquelle tombe chacune vous indique quel type de société appeler.

À quelles sociétés de développement logiciel à faible latence devons-nous nous adresser ?

Cet article ne classe pas les sociétés. Le bon type de société dépend de votre plage et du travail dont vous avez besoin :

• Les spécialistes du matériel et du réseau, pour des échéances qui se comptent en nanosecondes ou en quelques microsecondes. Ils travaillent sur les cartes FPGA, les cartes réseau, les switchs et les liaisons vers une bourse. Demandez lesquels de leurs chiffres proviennent d'horodatages pris par du matériel sur le câble réseau, et à qui appartenait l'équipement sur lequel les tests ont tourné
• Les sociétés d'ingénierie spécialisées dans les technologies de trading, pour des échéances en microsecondes ou en millisecondes quand le temps se perd dans votre propre logiciel ou sur le chemin de votre courtier ou de votre place de marché. Elles écrivent le logiciel qui envoie les ordres, traite les données de marché, contrôle le risque de chaque ordre avant son départ et, sur une place de marché, apparie les ordres d'achat et de vente. Demandez lesquels des systèmes qu'elles ont construits sont en production aujourd'hui, et quelles connexions à des courtiers ou à des places de marché elles ont écrites
• Les sociétés d'ingénierie ad tech, quand un ad exchange fixe votre échéance requête par requête et que votre facture de serveurs augmente avec votre trafic. Elles construisent des bidders et des ad exchanges. Demandez lequel des bidders ou des ad exchanges qu'elles ont construits tourne toujours en production, et si ses chiffres de timeout proviennent du décompte de l'ad exchange ou du leur
• Les ingénieurs performance indépendants, quand vous ne connaissez pas encore la cause, ou quand vos propres ingénieurs feront les modifications. Travaillant généralement seuls ou en petit groupe, ils mesurent un système en fonctionnement et indiquent où passe le temps. Demandez à voir un rapport antérieur, expurgé du nom et des données du client, et attendez-vous à un diagnostic plutôt qu'à une reconstruction
• Les éditeurs de composants, quand la brique dont vous avez besoin fonctionne de la même façon pour tout le monde et que votre avantage se situe ailleurs. Ils vendent une brique toute faite, comme un moteur d'appariement ou une connexion à une bourse, que vous exploitez au lieu de faire développer la vôtre. Demandez entre quels points leurs chiffres de latence ont été mesurés, et ce que vous avez le droit de modifier dans le code dont vous prenez la licence
• Les sociétés d'externalisation généralistes dotées d'une équipe faible latence clairement identifiée, quand vous avez besoin de nombreux ingénieurs et que le chemin critique ne pèse qu'une petite part du travail. Demandez les noms des membres de cette équipe et ce que chacun d'eux a construit dans votre plage, et faites inscrire par écrit qu'ils travailleront sur votre projet
• Vos propres recrutements, quand la vitesse est votre avantage concurrentiel et le restera, et que vous savez recruter et garder des ingénieurs qui ont déjà livré ce type de système. Acuiti, un cabinet d'études, a demandé à 50 hedge funds systématiques, des fonds qui négocient à l'aide de modèles informatiques, comment ils construisent leur technologie de trading. En janvier 2023, il a indiqué que la latence « est le facteur clé qui détermine l'attitude à l'égard de l'externalisation de la technologie front office, les sociétés pour lesquelles la latence est critique étant plus susceptibles de développer en interne »

Beaucoup de sociétés relèvent de plusieurs types : demandez donc quel type de travail ont réalisé les ingénieurs qui seront affectés à votre projet.

Comment vérifier qu'une société a déjà construit des systèmes rapides ?

L'article sur les équipes dédiées, dont le lien figure plus haut, liste ce qui doit accompagner chaque chiffre de performance et fournit une liste de contrôle à coller dans un appel d'offres. Les questions ci-dessous permettent de savoir comment les propres chiffres d'une société ont été obtenus.

Demandez où le chronomètre démarre et où il s'arrête. OPRA, qui publie les transactions et les cotations consolidées des bourses d'options américaines, démarre son chronomètre quand un message entrant « arrive à l'entrée applicative de l'environnement OPRA » et l'arrête quand le message sortant « arrive à la sortie applicative de l'environnement OPRA ». La définition de l'UE citée plus haut est tout aussi précise sur ces deux points. Un chiffre dont les points de départ et d'arrivée ne sont pas nommés ne peut pas être comparé au vôtre.

Regardez les réponses les plus lentes autant que la réponse typique. Dans les métriques publiées par OPRA, la latence médiane, la valeur du milieu, était de 19,5 microsecondes en janvier 2024 et de 20,5 en février. Sur ces deux mêmes mois, le 99e percentile, le temps que seul le 1 % des messages les plus lents dépassait, est passé de 543,5 microsecondes à 57,5. Un rapport limité à la médiane n'aurait montré presque aucun changement.

Les moyennes cachent elles aussi les réponses lentes. Le livre Site Reliability Engineering de Google, publié par O'Reilly en 2016, décrit un service web dont la latence moyenne est de 100 millisecondes à 1 000 requêtes par seconde, et dans lequel « 1 % des requêtes pourraient facilement prendre 5 secondes ». Demandez le 99e percentile de chaque chemin et, si votre système traite assez de requêtes pour le mesurer, le 99,9e, que seule 1 réponse sur 1 000 dépasse.

Vérifiez la charge derrière chaque chiffre. Dans la présentation de STAC de 2020, STAC-T0 envoie son trafic de test à trois débits. Le plus bas est « conçu pour voir comment les systèmes se comportent lorsqu'ils sont presque inactifs », et le plus élevé, généralement proche du maximum que le système testé peut absorber, sert « à voir comment les systèmes se comportent lorsqu'ils sont très sollicités ». Demandez des chiffres issus de votre propre minute la plus chargée, ou d'un test qui la reproduit.

Demandez comment le test de charge a été mené. Beaucoup d'outils de test de charge envoient une requête, attendent la réponse et n'envoient qu'ensuite la suivante. Quand le système se bloque, un tel outil cesse d'émettre : les requêtes qui seraient arrivées pendant le blocage ne sont donc jamais chronométrées.

Gil Tene, l'auteur de l'outil de test de charge wrk2, appelle cet effet coordinated omission. Dans la documentation de l'outil, modifiée pour la dernière fois en septembre 2019, il écrit que « les réponses à forte latence amènent le générateur de charge à se coordonner avec le serveur pour éviter de mesurer pendant les périodes de forte latence ». Son outil envoie les requêtes à un débit fixe et chronomètre chaque réponse « à partir du moment où l'envoi aurait dû avoir lieu ». Demandez si l'outil de la société fonctionne ainsi, ou comment ses résultats ont été corrigés.

Demandez où chaque horodatage a été pris. Pour des latences en microsecondes, la présentation de STAC qualifie un benchmark à horodatages logiciels de « meilleure option ». Elle avertit aussi que les petits délais irréguliers des horodatages logiciels « peuvent représenter une erreur considérable lorsqu'on mesure des latences de l'ordre de dizaines ou de centaines de nanosecondes », et STAC-T0 prend plutôt ses horodatages au niveau matériel. Une société qui annonce des nanosecondes doit pouvoir montrer où ses horodatages matériels ont été pris.

Quel test mener avant d'engager qui que ce soit ?

Si vous ne savez pas encore ce qui ne va pas, seulement que le système semble plus lent ou coûte plus cher qu'il ne le devrait, commencez par là. Payez la société que vous privilégiez pour une mesure à périmètre fixe de votre système en production, avec un rapport qui vous reste acquis quelle que soit la suite que vous déciderez. Convenez par écrit de ce que la société peut installer ou modifier pour prendre ses mesures, et de la façon dont ses outils seront retirés ensuite.

Le rapport doit montrer :

• Où passe le temps pendant votre minute la plus chargée, étape par étape le long du chemin que vous avez noté
• Pour chaque chemin, les temps de réponse au 99e et au 99,9e percentile
• Les corrections, classées selon ce que chacune coûte et ce qu'elle supprime, qu'il s'agisse de temps sur le chemin ou de serveurs ajoutés pour masquer un chemin lent
• Ce à quoi la société ne toucherait pas, et pourquoi

Pour les systèmes de trading, l'article sur l'exécution lente des ordres, dont le lien figure plus haut, liste les quatre horodatages à enregistrer sur chaque ordre. En ad tech, les articles sur les pics de trafic et sur les timeouts des DSP expliquent quoi mesurer lors d'un pic et pour chaque connexion d'ad exchange.

Jugez la société sur son rapport. Si vos propres ingénieurs pouvaient s'en servir sans elle, vous pouvez choisir sur la base de chiffres réels qui fera la suite du travail, que ce soit cette société ou une autre.

Quels sont les signaux d'alerte quand on choisit une société spécialisée en faible latence ?

• Une vitesse décrite par des mots, sans chiffre ni points de départ et d'arrivée
• Uniquement des moyennes, sans rien sur les réponses les plus lentes
• Un benchmark issu du propre laboratoire de la société, exécuté sur son matériel avec un trafic qu'elle a elle-même généré, présenté comme une preuve concernant votre système
• Une réécriture, ou le passage à un nouveau langage de programmation, proposé avant que quiconque ait mesuré votre système
• Un chiffre de latence promis dès le premier appel
• Le même discours commercial pour un travail de trading mesuré en microsecondes et pour un bidder publicitaire avec une échéance de 100 millisecondes

Si une société propose un nouveau langage, l'article dont le lien figure ci-dessous montre comment les ingénieurs vérifient si le langage est bien en cause.

Où se situe amBrain ?

amBrain diagnostique les systèmes lents dans le trading et l'ad tech : la plateforme en fonctionnement est mesurée de bout en bout, et le rapport indique où passe le temps. Son travail dans le trading comprend le développement de terminaux de trading, les systèmes de gestion des ordres et l'intégration des places de marché via le protocole FIX.

En AdTech, amBrain travaille sur le développement de DSP, les plateformes d'enchères en temps réel et l'ingénierie d'ad exchange.

amBrain travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain.

amBrain développe des logiciels depuis 2019.

Cet article n'est pas une étude de cas et ne décrit aucun travail réalisé pour un client. Il ne cite aucun chiffre de latence pour les systèmes qu'amBrain a construits, et aucun prix ni délai.

Demandez à amBrain, ou à toute autre société de votre liste, ce qu'elle mesurerait en premier sur votre système, et soumettez chaque société aux mêmes vérifications.

Questions fréquentes

• Devrions-nous plutôt constituer notre propre équipe ? Dans l'étude d'Acuiti de 2023 portant sur 50 hedge funds systématiques, ceux pour lesquels la latence est critique étaient plus susceptibles de développer leur technologie de trading en interne. Mesurez d'abord dans tous les cas, car le rapport vous dit quel type d'ingénieur recruter, ou quoi demander à une société
• Une seule société peut-elle couvrir à la fois le trading et l'ad tech ? Oui, si elle a des systèmes en production dans votre plage dans les deux domaines. Demandez un système en production dans chaque domaine, et vérifiez ses chiffres avec les questions ci-dessus