Ce qui casse en premier dans les systèmes de trading automatisé

Quand les gens pensent au trading automatisé, ils se concentrent généralement sur une chose : la stratégie.

Va-t-elle générer des profits ? Va-t-elle surperformer le marché ? Va-t-elle survivre à différentes conditions de marché ?

Ces questions sont importantes, mais après plusieurs années à construire Oblivion, je suis devenu convaincu que ce sont rarement les premiers problèmes que l'on rencontre.

En pratique, la plupart des systèmes de trading automatisé n'échouent pas à cause de leur logique de trading. Ils échouent à cause de tout ce qui l'entoure.

La stratégie n'est qu'un composant

Il est tentant de croire qu'une fois qu'une stratégie fonctionne, la partie difficile est terminée. Malheureusement, ce n'est que le début.

Une plateforme de trading dépend de nombreux éléments qui doivent fonctionner ensemble.

Les données de marché doivent arriver à temps. Les APIs des exchanges doivent répondre. Les ordres doivent être confirmés. L'état interne doit rester cohérent. L'application elle-même doit continuer à tourner, parfois pendant des semaines sans interruption.

Aucun de ces problèmes n'est directement lié au trading, mais tous déterminent si la stratégie peut réellement s'exécuter.

Les petits problèmes deviennent grands

Une leçon que j'ai apprise, c'est que les problèmes apparemment insignifiants restent rarement insignifiants.

Une interruption réseau temporaire. Un timeout qui arrive une fois toutes les quelques milliers de requêtes. Un processus qui consomme lentement plus de mémoire que prévu.

Aucun de ces événements ne semble particulièrement dangereux isolément. Mais le logiciel tourne en continu.

Un petit problème répété assez souvent finit par devenir un vrai problème opérationnel.

L'objectif n'est donc pas seulement de résoudre les échecs évidents, mais aussi d'éliminer l'accumulation des petits.

La réalité est plus désordonnée que la documentation

Chaque API a sa documentation. Chaque librairie a ses exemples. Tout paraît prévisible quand on lit les spécifications.

Les environnements de production prouvent rapidement le contraire.

Des réponses inattendues arrivent. Des indisponibilités temporaires se produisent. Des services externes se comportent autrement que prévu.

Parfois, rien n'est techniquement cassé, mais le système doit quand même prendre des décisions raisonnables dans des conditions imparfaites.

C'est là que l'ingénierie commence à devenir plus importante que l'implémentation.

La résilience se construit

Une idée fausse que j'avais au début du projet était de croire que la résilience pouvait être ajoutée plus tard.

Construire les fonctionnalités d'abord. Rendre le tout robuste ensuite.

En réalité, cette approche fonctionne rarement.

La fiabilité n'est pas une couche que l'on pose au-dessus d'une application. Elle émerge de centaines de petites décisions d'architecture prises tout au long du projet.

La manière dont les composants communiquent. La manière dont les échecs sont détectés. La manière dont la récupération se fait. La manière dont l'état est préservé.

Ces décisions déterminent discrètement si une plateforme reste fiable plusieurs mois après son déploiement.

L'ingénierie change la perspective

Plus je travaillais sur Oblivion, moins je m'inquiétais de savoir si une stratégie pouvait produire un trade de plus.

Je me suis mis à poser d'autres questions.

Que se passe-t-il si l'exchange devient indisponible ? Que se passe-t-il si l'application redémarre de manière inattendue ? La plateforme peut-elle récupérer automatiquement ? Peut-elle continuer à fonctionner sans intervention humaine ?

Ces questions apparaissent rarement dans les discussions sur le trading.

Pourtant, elles déterminent souvent si un système automatisé mérite qu'on lui fasse confiance.

Avec le recul

Aujourd'hui, je ne crois plus que le premier défi du trading automatisé soit de trouver une stratégie profitable.

Le premier défi est de construire une plateforme capable d'exécuter cette stratégie de manière fiable, chaque jour.

Les stratégies évoluent. Les marchés changent. Les idées s'améliorent.

Mais la fiabilité reste la fondation qui permet à toutes les autres améliorations d'exister.

Avant de chercher à optimiser un système, il doit d'abord être un système capable de survivre.