Comment évaluer une FIX API avant d'engager votre intégration

« Nous prenons en charge FIX 4.4 et 5.0 » ne dit rien. C'est comme dire qu'une voiture a des roues. Ce qui détermine si une intégration va fonctionner, ce sont des choses bien moins glamour : quels messages ils couvrent, ce qui se passe quand la session tombe, et si le sandbox se comporte comme la production.

Voici la liste que votre équipe technique devrait examiner avant d'engager des semaines de travail.

Ce que la version ne vous dit pas

FIX est un protocole, pas une implémentation. Deux venues qui disent prendre en charge la 4.4 peuvent différer sur :

Quels types de message ils implémentent et lesquels ils ignorent
Quels tags sont obligatoires dans chaque message
Comment ils gèrent les champs personnalisés
Quels codes de rejet ils renvoient et ce qu'ils signifient
Comment ils gèrent la numérotation de séquence après une déconnexion

Aucune de ces différences n'apparaît dans « FIX 4.4 ». Toutes apparaissent lors de la certification, c'est-à-dire une fois que vous avez déjà investi du temps.

La documentation des messages devrait être disponible avant de signer quoi que ce soit. Si on ne vous la remet qu'après le contrat, vous achetez à l'aveugle.

Couverture des messages : quoi demander

Au minimum, il vous faut de la clarté sur quatre flux :

Cotation. Streaming de prix ou request/response ? Souscription par instrument ou par liste ? Quelle profondeur envoient-ils et à quelle fréquence ?

Saisie d'ordres. Quels types prennent-ils en charge — marché, limite, stop, IOC, FOK ? Ordres de modification et d'annulation ? Quel est le comportement lorsqu'on rejette la modification d'un ordre déjà partiellement exécuté ?

Rapports d'exécution. Envoient-ils les exécutions partielles ? Avec quelle granularité ? Comment identifie-t-on le lien entre l'ordre d'origine et ses fills ?

Drop-copy. Existe-t-il une session distincte qui réplique votre activité pour la réconciliation et la compliance ? Pour les fonds et les firmes soumis à des obligations de reporting, ce n'est pas optionnel.

Demandez ceci : la spécification complète des messages et des tags, y compris les codes de rejet, avant la certification.

Le comportement en reconnexion, là où tout se casse

C'est la partie qui sépare une intégration qui survit d'une intégration qui vous réveille en pleine nuit.

Les questions concrètes :

Qu'advient-il des ordres en vol lorsque la session tombe ? Sont-ils annulés automatiquement, restent-ils vivants, ou cela dépend-il de la configuration ? Les trois réponses sont défendables ; ne pas savoir laquelle est la vôtre ne l'est pas.

Comment gère-t-on le sequence reset ? Lorsque vous vous reconnectez, attendent-ils que vous repreniez la numérotation là où vous vous étiez arrêté, que vous la réinitialisiez, ou négocient-ils ? Un décalage de séquence mal géré peut bloquer la session entière.

Y a-t-il une récupération des messages perdus ? Si vous êtes resté déconnecté 30 secondes, pouvez-vous demander les messages de cet intervalle ou sont-ils perdus ?

Quel est le timeout du heartbeat et que se passe-t-il lorsqu'il est dépassé ?

Si l'une de ces réponses est « on verra ça à la certification », prenez-le comme une information : cela signifie que ce n'est pas documenté.

Mapping des symboles : fastidieux et critique

Chaque venue nomme ses instruments à sa façon. L'or peut être XAUUSD, GOLD ou XAU/USD, avec des écarts de taille de contrat, de nombre de décimales et d'horaires de session.

Le mapping de votre catalogue complet devrait être convenu avant la certification, pas pendant. C'est la cause la plus fréquente de retards, et elle est parfaitement évitable.

Les points qui mordent souvent :

Des instruments au même nom et à taille de contrat différente
Des écarts dans le nombre de décimales, qui cassent les calculs de pip
Des horaires de session qui ne coïncident pas avec ceux qu'attend votre plateforme
Des instruments qui existent dans votre catalogue et pas dans le leur

Demandez ceci : le mapping convenu de votre catalogue entier, pas d'un échantillon représentatif.

Le sandbox : le seul test qui vaille

Un sandbox qui ne se comporte pas comme la production reporte la découverte des bugs à votre première session en production. C'est la différence entre un environnement de test et un décor.

La parité de production signifie concrètement :

Les mêmes types de message et les mêmes codes de rejet
Un comportement de rejet réaliste, pas une acceptation universelle
Une latence représentative, pas instantanée
Les mêmes horaires de session et les mêmes règles d'instrument

Et, point crucial : des identifiants avant l'engagement commercial. Un venue qui vous demande de signer pour vous donner accès au sandbox inverse le bon ordre.

Ce que vous devriez y tester :

Le cycle complet de l'ordre : envoi, exécution partielle, exécution totale, annulation
Une déconnexion forcée au milieu d'un ordre vivant
Un sequence reset
Les rejets : les provoquer délibérément et vérifier que les codes sont bien ceux documentés
Votre catalogue complet d'instruments
Le comportement pendant une fenêtre de forte volatilité simulée

Combien de temps devrait prendre la certification

Avec l'onboarding complet et le mapping convenu, des jours, pas des semaines.

Ce qui allonge les délais n'est presque jamais la technologie : c'est l'attente. C'est pourquoi il vaut mieux avoir un contact technique nommé de votre côté dès le départ, avec pouvoir de décision, plutôt qu'une chaîne d'approbations.

Si un venue vous annonce un délai de certification de plusieurs semaines sans expliquer ce qui le justifie, demandez quelle partie du processus est la lente. La réponse en dit long sur ce que sera la relation opérationnelle ensuite.

Quand FIX n'est pas la réponse

Il vaut la peine de le dire, car on a tendance à supposer que FIX est toujours supérieur :

Si vous exploitez un courtage sur MetaTrader avec des clients retail ou professionnels sur cette plateforme, la passerelle MT5 est la bonne voie. FIX ajouterait de la complexité sans bénéfice.

Si votre stack est HTTP-first et moderne — typique des prop firms récentes et des venues crypto-adjacents — REST plus un WebSocket à faible latence avec documentation OpenAPI peut mieux convenir que FIX, et s'intégrer bien plus vite.

FIX est la voie lorsque votre OMS ou EMS le parle en natif, lorsque vous avez besoin de drop-copy pour la compliance, ou lorsque le volume et la latence justifient l'investissement d'intégration.

Beaucoup de firmes commencent avec la passerelle et ajoutent FIX en montant en charge. C'est une progression sensée, pas une défaite.

Questions fréquentes

FIX 5.0 est-il meilleur que 4.4 ? Pas pour la plupart des cas. La 4.4 reste le standard de fait sur le FX institutionnel et est mieux prise en charge sur toute la chaîne. La 5.0 apporte des améliorations structurelles, mais si votre contrepartie et votre OMS parlent la 4.4 sans problème, il n'y a pas de raison de se compliquer.

Ai-je besoin de drop-copy ? Si vous avez des obligations de reporting, un administrateur de fonds qui doit réconcilier, ou des auditeurs qui vont exiger de la traçabilité, oui. Si vous êtes un petit courtier sans ces obligations, c'est un luxe. Demandez tout de même s'il est disponible : son existence en dit quelque chose sur la maturité du venue.

Puis-je utiliser mon propre moteur FIX ? Normalement oui, et c'est l'usage courant. Ce que vous devez vérifier, c'est que votre moteur et leur implémentation coïncident sur les détails qui comptent — surtout la gestion de séquence et les champs personnalisés.

Que faire si le sandbox n'est pas en parité de production ? Le demander explicitement. Si la réponse est qu'ils ne l'ont pas, c'est une donnée pertinente sur ce que sera la mise en production, et vous devriez budgéter un temps de stabilisation que vous n'aviez pas prévu.

Le détail technique de notre implémentation se trouve dans FIX API : sessions, couverture des messages, sandbox en parité et comportement de reconnexion documenté avant la certification. Les clients s'inscrivent et exécutent via nous ; les identifiants sandbox sont émis avant tout engagement commercial.

Pour le cadre général : comment un courtier choisit sa liquidité.