J'ai construit et mis en production une plateforme de trading. Seul, en six mois.

Depuis le 1er septembre, des banques traitent des produits de taux sur une plateforme que j'ai conçue, écrite, sécurisée et mise en production. Je n'ai pas piloté ce projet : je l'ai construit. Le moteur d'appariement, le modèle d'anonymat, le pipeline de prix, le service d'authentification, la haute disponibilité, l'architecture réseau d'exposition. Seul, en six mois, en tenant par ailleurs l'infrastructure multi-sites d'une société financière.

Je détaille ce projet parce qu'il démontre une chose à laquelle je crois : la séparation entre infrastructure, sécurité et développement applicatif est une invention d'organigramme. Quand elle disparaît, une seule personne livre ce que l'on croit réservé à une équipe, et souvent mieux, parce qu'aucune décision ne se perd entre deux services.

Voici les sept chantiers qu'il a fallu tenir en même temps, et à chaque étape la décision qui sépare une démonstration d'un système sur lequel des banques engagent de l'argent tous les jours.

1. Traduire un métier en machine

Sur ce marché, le prix se fait encore à la voix. Une banque appelle et veut acheter une échéance à un niveau, une autre veut vendre la même un peu plus loin, et le courtier tient les deux fils jusqu'à ce qu'un point de rencontre existe. Ça fonctionne depuis des décennies, ça ne passe pas à l'échelle, et les structures à deux ou trois jambes y sont un calvaire.

Le principe retenu est élégant : on part du milieu du marché et on ouvre trois niveaux traitables autour. Pas un prix acheteur, un prix milieu et un prix vendeur : trois prix, et sur chacun un trader peut acheter ou vendre. Personne ne sait ce que veut l'autre. La séance dure un temps fixe, les prix sont gelés à l'ouverture, tout le monde voit la même horloge, et le courtier garde le tempo.

Derrière cette simplicité apparente, il y a un carnet d'ordres, un moteur d'appariement, un canal temps réel vers tous les écrans, et plusieurs dizaines de règles qui ne s'inventent pas. Priorité stricte au premier arrivé. Fractionnement jusqu'à un minimum, le résiduel restant au niveau traité et non à son niveau d'origine. Interdiction absolue qu'une banque se traite contre elle-même. Et un raffinement que j'ai tenu à implémenter : deux ordres de la même banque en sens opposés au même prix sont refusés même s'ils ne s'apparieraient pas entre eux, parce qu'ils donneraient au marché une fausse impression d'activité.

Au-dessus, les écarts entre échéances, puis la mécanique dont je suis le plus fier : le legging. Deux ordres simples posés sur deux échéances différentes forment ensemble un écart traitable, que la plateforme fait apparaître d'elle-même. Et réciproquement, un ordre sur un écart s'exécute en deux jambes contre deux contreparties distinctes, qui ne sauront jamais qu'elles ont servi à assembler la structure d'un tiers. Au-dessus encore, les structures à trois jambes, exécutées de façon atomique dans un rapport de taille imposé.

Ces règles sortent de la tête d'un courtier qui fait ce marché depuis vingt ans. Ma valeur n'a pas été de les inventer : elle a été de les extraire, les écrire, et refuser d'en coder une seule que je ne savais pas énoncer en une phrase. C'est la discipline qui a fait tenir le projet, et c'est celle que je recommanderais à n'importe quelle équipe qui attaque un domaine métier qu'elle ne connaît pas.

Ce travail a pris une forme : le Rule Book. Chaque comportement attendu y est écrit en langage métier, numéroté, et verrouillé par un test automatisé rejoué avant chaque livraison. Anonymat, appariement, écarts, structures, cycle de vie d'une séance, conformité, infrastructure. Près de quatre-vingts règles aujourd'hui, et un effet de bord que je n'avais pas anticipé : le document est devenu le contrat avec le métier, et la réponse envoyée à un client qui demande comment la plateforme se comporte dans un cas précis.

Le courtier m'a posé un jour la seule question qui compte vraiment : « est-ce qu'on va repasser dessus encore et encore jusqu'à ce que le système soit 300 % robuste ? » J'ai répondu oui, sans enrober, et j'ai ajouté qu'il y aurait des incidents et des correctifs même après, parce que c'est vrai de toutes les plateformes de trading, y compris celles qui coûtent des millions en licence. Ce qui sépare une plateforme mature d'une plateforme fragile n'est pas l'absence de défauts, c'est leur rareté, la vitesse de détection, la taille de l'impact, et le fait de ne jamais revoir le même deux fois. Promettre autre chose à un client, c'est préparer la déception.

2. Concevoir un système dont la fonction est de ne rien dire

La plateforme est anonyme par construction. Un trader voit qu'un niveau est actif, jamais qui l'anime, et surtout jamais dans quel sens. Formulé ainsi, cela ressemble à une consigne d'affichage. C'est en réalité la contrainte la plus structurante de tout le système.

Parce que la règle ne s'applique pas à l'écran : elle s'applique à chaque octet qui sort du serveur. Le réflexe habituel du développement web, envoyer largement au navigateur et décider à l'affichage, est ici une faute de conception. Tout ce qui part vers un client est public, quelle que soit l'élégance de l'interface.

J'ai donc traité l'anonymat comme une propriété du serveur, et repris un par un tous les chemins par lesquels une information pouvait sortir : les réponses d'API, le canal temps réel, les exports de confirmations, et jusqu'aux événements techniques d'annulation qui portaient encore des identifiants. Chaque point de sortie renvoie désormais une vue rédigée, calculée pour le demandeur et selon son rôle.

Le cas le plus révélateur est le plus petit. L'interface affiche un discret triangle quand un autre acteur a rejoint votre niveau. La façon naturelle de le coder est d'envoyer la liste des participants et de n'afficher qu'un triangle : le résultat est juste à l'écran et catastrophique dans la console du navigateur. Le serveur calcule le booléen et n'envoie que le booléen. Le courtier, lui, reçoit l'état complet, parce qu'il a un devoir de supervision. Deux réponses différentes pour la même question, selon qui la pose.

3. Diagnostiquer une source de données que je ne contrôle pas

Le cœur financier ne m'appartient pas. Les courbes sont construites dans un classeur, par un moteur de calcul tiers, sur le poste d'un courtier. Le classeur exporte des fichiers texte sur un partage réseau, un collecteur les lit toutes les deux secondes, les normalise et les pousse dans le moteur. Sur un schéma d'architecture, c'est inélégant. Dans la finance de marché, le tableur est le système d'information, et le nier ne le fait pas disparaître. La seule posture professionnelle consiste à traiter sa sortie pour ce qu'elle est, une entrée non fiable, et à la surveiller en conséquence.

Un matin, le courtier signale des niveaux incohérents dans la plateforme. J'ai démontré fichier par fichier que toute ma chaîne était saine, et que les prix étaient faux à la source. Savoir prouver que le problème n'est pas chez soi, en quelques minutes et avec des preuves, vaut autant que savoir le corriger.

La signature tenait à un détail que peu de gens regardent : l'horodatage interne du fichier reculait. Un fichier écrit par un seul producteur voit son horloge avancer ; quand elle alterne entre deux valeurs, deux producteurs écrivent le même fichier à tour de rôle et chaque lecteur ne voit qu'une vue sur deux. J'ai remonté l'attribution au verrou d'écriture près : le verrou donne un processus, le processus donne un utilisateur et une adresse. Deux classeurs publiaient en parallèle, l'un figé une heure en arrière.

Au passage, un piège que je signale parce qu'il coûte cher à qui l'ignore : l'horodatage suspect était en UTC+2, ce qui désigne l'Europe centrale en été, mais tout autant une place de l'hémisphère sud. Un fuseau horaire n'identifie personne.

Le correctif évident est un verrou : un seul publieur. Sauf que quelques jours plus tard, le publieur unique s'est arrêté en gardant sa session réseau ouverte. Rien n'avait l'air cassé, et plus rien ne publiait, parce qu'aucun autre classeur n'avait le droit de reprendre.

J'ai donc posé l'exigence en deux parties solidaires : exactement un publieur à la fois, et un autre qui prend le relais automatiquement quand celui-là cesse de mettre à jour. C'est une élection de leader, le problème le plus classique des systèmes distribués. Sauf qu'ici les nœuds sont des classeurs ouverts par des humains sur trois continents, et que le protocole doit être expliqué et accepté par des gens qui n'ont jamais entendu parler d'élection de leader. Cette traduction fait partie du travail.

4. Reprendre le contrôle de l'identité

Jusqu'à l'été, l'authentification passait par l'annuaire d'identité de Microsoft : le choix par défaut, celui qu'on ne se fait jamais reprocher en comité. Puis est venu un test avec une grande banque internationale. Trois traders, un créneau fixé. Aucune connexion n'aboutit.

L'analyse a pris moins d'une heure et n'a révélé aucun défaut logiciel. Un invité externe qui n'a pas encore accepté son invitation n'existe pas pour la page de connexion. Les adresses en prénom.nom de cette banque ne correspondent à aucun compte dans leur propre annuaire, ce ne sont que des alias de messagerie. Et le courrier d'invitation n'était jamais parti. Autrement dit, pour faire entrer un client, je dépendais de l'annuaire d'un tiers, d'un message traversant deux antispams bancaires, et d'un geste de l'utilisateur avant sa première connexion.

J'ai tranché le jour même : abandon complet, authentification hébergée chez nous, livrée dans la journée. Parce que « on fait notre propre authentification » est une phrase qui doit inquiéter, voici précisément ce qu'elle recouvre ici : empreintes de mots de passe en argon2id, jetons signés en RS256 avec durée courte et rotation des jetons de renouvellement, second facteur optionnel par compte, liens d'activation à usage unique et à durée limitée, verrouillage après échecs répétés, réponses uniformes pour interdire l'énumération des comptes, révocation des sessions côté serveur, journal d'audit en ajout seul, et la clé privée qui ne quitte jamais les deux machines autorisées à signer.

Le détail qui change tout n'est pas cryptographique : aucun courriel n'est envoyé. Le lien d'activation est remis au courtier, qui le transmet à son client par le canal qu'ils utilisent déjà. Plus aucun antispam bancaire dans la chaîne d'accueil. Et un back-office qui permet au courtier d'ouvrir un accès client en trente secondes, sans moi. Le service tourne en actif/veille sur deux machines distinctes, avec promotion automatique en une quinzaine de secondes.

Je ne dis pas que le SSO d'entreprise est un mauvais choix : pour les accès internes, il reste le bon, et je le maintiens ailleurs. Mais pour des clients externes dont je ne maîtrise ni l'annuaire ni la messagerie, l'auto-hébergement m'a rendu le seul geste qui compte commercialement : ouvrir un accès quand le client est disponible, pas quand un tiers veut bien.

5. Rendre l'arrêt impossible

Une plateforme utilisée à heure fixe, sur des séances de quelques minutes, n'a pas droit au « je redémarre, ça revient dans dix minutes ». Si le moteur tombe à l'ouverture, la séance n'a pas lieu et le courtier perd la face devant ses clients. J'ai donc traité la disponibilité comme une exigence de conception, pas comme une option d'exploitation.

Un second moteur tourne sur un autre nœud physique, base répliquée toutes les cinq secondes. Un chien de garde interroge la santé du primaire toutes les trois secondes et, au cinquième échec, se promeut et démarre le service : une quinzaine de secondes de bout en bout, sans intervention humaine.

La partie qui distingue une vraie haute disponibilité d'un script de bascule, c'est le garde-fou. Le primaire refuse de démarrer tant que le secours répond. Et si le primaire réapparaît pendant une bascule, le chien de garde alerte en criticité maximale mais ne rétrograde jamais personne tout seul : un humain tranche, parce que les deux bases ont pu diverger et qu'aucun automate ne doit choisir quelle vérité jeter.

Ensuite, j'ai coupé le moteur pour de vrai, en production. La bascule applicative s'est comportée exactement comme prévu, et le test a révélé ce qu'aucune relecture n'aurait trouvé : une règle de pare-feu manquait vers l'adresse du secours. Le double servait parfaitement et l'extérieur ne l'aurait jamais atteint. C'est exactement pour cela qu'on teste en réel : un plan de secours non éprouvé n'est pas un plan, c'est une hypothèse.

6. Ouvrir sur Internet sans rien céder

Exposer la plateforme aux banques clientes est un métier en soi, et je l'ai traité comme tel : une zone démilitarisée dédiée et physiquement isolée du réseau de bureau, un proxy sans aucun droit de sortie vers Internet, inspection du flux chiffré entrant, protections contre les inondations de connexions, une seule destination autorisée vers l'application, certificat et adresse dédiés.

La chaîne réseau était prête, tout le monde attendait l'ouverture, et l'audit que j'ai mené a conclu non.

Parce que le blocage n'était pas le réseau. L'application avait été écrite pour un réseau de confiance, et relue avec des yeux d'attaquant, elle autorisait des choses simples : enregistrer un ordre au nom de n'importe quelle banque, lire les identités et les sens, annuler les ordres des autres, injecter des prix. Aucune de ces portes ne comptait derrière la frontière interne, avec quinze banques sous contrat. Toutes devenaient critiques en exposition publique.

J'ai tenu ce non sous la pression du calendrier : sprint complet de durcissement, seconde relecture adverse, et seulement ensuite le moindre enregistrement DNS. Le jour du passage en public, l'opération a duré trente secondes et tenait en deux gestes réversibles. Quand la mise en production est un non-événement, c'est que le travail a été fait avant.

7. Faire parler la production

Une plateforme ne se juge pas à ce qu'elle fait quand tout va bien, mais à ce qu'on voit quand elle dérape. J'ai donc passé ma propre supervision à l'audit, avec la même méthode adverse que le reste du système. C'est le chantier dont je tire le plus de satisfaction, parce que personne ne le réclame jamais et qu'il change tout le jour où ça compte.

Premier angle mort, le classique du métier : un agent de collecte de journaux actif, activé au démarrage, vert sur tous les tableaux de bord, et parfaitement muet. Sa configuration héritée ne lisait que deux fichiers, alors que le moteur écrit dans le journal système. Corrigé en restreignant la collecte à la seule unité utile, pour ne pas saturer la plateforme de logs au passage.

Deuxième : une règle d'alerte chargée, visible dans l'interface, et inerte à cause d'une indentation dans un fichier de configuration. Une alerte qu'on n'a jamais vue se déclencher n'est pas une alerte, c'est une intention. Depuis, toute nouvelle règle est validée en provoquant réellement la condition.

Troisième : la supervision couvrait le disque, le service, le réseau et les certificats, mais pas la fraîcheur des sauvegardes. L'âge du dernier point de restauration est devenu une métrique de premier rang, au même titre que la disponibilité.

Quatrième, et c'est celui que je referais en premier ailleurs : rien ne garantissait que le code servi en production corresponde exactement au dépôt. J'ai construit un détecteur de dérive qui recalcule en continu l'empreinte des fichiers de production, la compare à la référence, l'expose en métrique et alerte si l'écart dure plus de vingt-quatre heures. Même principe que pour les prix : on n'empêche pas une dérive, on la rend visible avant qu'elle ne grossisse.

Dernier principe, qui relève autant de l'ingénierie que de la relation client : un constat ponctuel n'est pas une garantie. « Le flux de prix est sain » à 9 h 35 ne dit rien de 10 h 00 si rien ne surveille l'intervalle. J'ai donc supprimé la dépendance à quelqu'un qui pense à vérifier : le délai de détection d'un gel des prix est passé de trente minutes à quatre, et l'alerte part désormais aux producteurs de la donnée eux-mêmes, pas seulement à l'informatique. Le bon réflexe n'est pas de mieux formuler une réponse, c'est de faire en sorte que la question ne se pose plus.

Où en est la plateforme

Six mois après la première ligne de code, voilà ce qui tourne :

• En production avec de vraies banques, sur des séances à heure fixe, plusieurs fois par jour.
• Près de quatre-vingts règles métier écrites en langage business, chacune verrouillée par un test automatisé rejoué avant chaque livraison.
• Un moteur actif et son double en veille sur deux nœuds distincts, avec garde-fou contre la double activation et bascule validée par un arrêt réel en production.
• Une authentification maison redondée, second facteur optionnel, révocation côté serveur, et un back-office qui ouvre un accès client en trente secondes.
• Une exposition publique derrière une zone démilitarisée isolée, avec inspection du flux chiffré entrant et un proxy privé de tout accès sortant.
• Une règle d'exploitation non négociable : aucun redémarrage du moteur tant qu'une séance est ouverte. Les livraisons se planifient autour du marché, jamais l'inverse.

Construit, sécurisé et exploité par une personne, sans éditeur derrière, sur une infrastructure que je possède de bout en bout. Et pendant ces six mois, le reste n'a pas attendu : la virtualisation d'une infrastructure financière a migré vers l'open-source sans couper le trading, et la stratégie de sauvegarde a été refondue pour survivre à un attaquant déjà administrateur. Ce sont deux autres articles de ce blog.

Ce que ce projet dit du métier

Au-delà de la plateforme, trois convictions en sortent renforcées, et ce sont celles que j'applique partout.

• La spécialisation étanche coûte plus cher qu'elle ne rapporte. Sur ce projet, la même personne a écrit une règle d'appariement le matin et une règle de pare-feu l'après-midi. Aucune réunion d'interface, aucune spécification perdue en route, aucun délai d'attente entre deux équipes. C'est ce qui rend possible six mois là où l'on attendrait dix-huit.
• Le goulot d'étranglement n'est jamais la vitesse d'écriture du code. Il est dans la compréhension du métier, la qualité des décisions d'architecture et la capacité à dire non au bon moment. Ce sont exactement les trois choses qui ne se délèguent pas.
• La rigueur est un accélérateur, pas un frein. Le Rule Book, la rédaction côté serveur, le garde-fou anti double activation, le détecteur de dérive : chacun a coûté du temps et chacun en a rendu dix fois plus, parce qu'aucun de ces sujets n'est jamais revenu deux fois.

Le reste tient en quatre principes que je répète à qui veut les entendre : la confidentialité est une propriété du serveur, jamais de l'interface ; un système ne vaut pas mieux que son entrée la moins gouvernée ; l'automatisme sans garde-fou fabrique des doubles ; et vert ne veut pas dire vivant, donc on vérifie la sortie, jamais le statut.

Et l'IA dans tout ça

C'est le fil de ce blog, autant être précis. L'IA a écrit une grande part de ce code, et je l'assume complètement : sans elle, l'équation ne tient pas. Une personne, six mois, avec une infrastructure multi-sites à porter en parallèle, c'est arithmétiquement impossible à la main. J'ai su l'utiliser tôt et intensément, et c'est une compétence en soi.

Mais reprenez les sept chantiers. Pas un seul n'a été résolu par de la génération de code. Décider d'abandonner le SSO le jour du test raté. Choisir le garde-fou plutôt que la bascule élégante. Comprendre qu'un horodatage qui recule est la signature de deux écrivains concurrents. Refuser d'ouvrir sur Internet alors que le réseau était prêt et que tout le monde attendait. Transformer vingt ans d'expérience d'un courtier en quatre-vingts règles testables. C'est du jugement, il est resté entièrement humain, et c'est là que se situe la valeur.

L'IA m'a donné la vitesse d'une équipe. Elle ne m'a pas donné les décisions. C'est exactement ce que j'écrivais il y a six mois, et six mois de production avec de vraies banques ne l'ont pas démenti.