Ce que j'ai appris après des mois de forward testing

Quand j'ai commencé à construire Oblivion, j'ai passé beaucoup de temps à tester des idées avant de les laisser s'approcher du capital réel.

Le premier environnement de test sérieux était un paper account sur un exchange. Il permettait au système de se connecter aux conditions de marché, de traiter des données live et de se comporter comme un système de trading sans mettre de fonds en risque.

Cette distinction compte. L'objectif n'était pas de prétendre que le système était déjà prouvé. Il était de l'observer en forward, décision après décision, dans des conditions de marché qui continuaient de se former.

Les marchés se comportent différemment en temps réel

Le paper trading retire le risque financier, mais il ne retire pas la réalité opérationnelle.

Pendant le forward testing, chaque décision porte une part d'incertitude parce que le résultat n'a pas encore eu lieu. Les ordres peuvent s'exécuter différemment de ce qui était prévu, les APIs peuvent parfois se comporter de manière inattendue, et les conditions de marché évoluent pendant que le système traite encore l'information.

Un système qui semble stable en théorie peut révéler des caractéristiques très différentes une fois qu'il fonctionne en continu face à des données de marché live.

Ce n'est pas forcément parce que la stratégie est mauvaise. C'est parce que le fonctionnement en temps réel expose toujours des détails que la planification seule ne peut pas entièrement prévoir.

Les leçons d'ingénierie comptent aussi

L'une des plus grandes surprises n'avait rien à voir avec le trading lui-même. Le forward testing exposait des problèmes d'ingénierie beaucoup plus souvent que des problèmes de trading.

Un timeout qui arrive une fois toutes les quelques milliers de requêtes. Un scénario de reconnexion qui n'avait jamais été envisagé. Une condition de concurrence entre deux processus indépendants.

Aucun de ces problèmes n'apparaît sur un graphique de performance, mais ils affectent directement la qualité d'un système de trading automatisé.

L'exploitation continue enseigne des leçons que la simulation ne peut tout simplement pas enseigner.

La patience devient un avantage

Une autre leçon était psychologique. Quand on construit un système, il existe une tentation constante de changer quelque chose à chaque fois que les résultats deviennent décevants.

Un paramètre ici. Un seuil là. Une autre idée demain.

Le forward testing m'a appris à ralentir.

De mauvais résultats à court terme n'indiquent pas forcément un système défaillant, tout comme de bons résultats à court terme ne valident pas automatiquement un système.

Les conclusions utiles demandent du temps. Plus la période d'observation est longue, plus les leçons deviennent fiables.

Chaque observation a de la valeur

Toutes les améliorations ne viennent pas d'une découverte spectaculaire.

Parfois, la découverte la plus utile consiste à constater qu'une fonctionnalité se comporte exactement comme prévu.

Parfois, il s'agit de confirmer qu'une hypothèse était incorrecte.

Le forward testing transforme progressivement les opinions en preuves.

Il remplace l'intuition par des observations collectées pendant des semaines et des mois de fonctionnement réel.

Regarder la suite

L'objectif du forward testing n'a jamais été de prouver qu'Oblivion est parfait. C'est même l'inverse.

Son objectif est de révéler les imperfections avant que les utilisateurs ne les rencontrent.

Chaque problème découvert est une occasion d'améliorer la plateforme. Chaque situation inattendue devient un scénario supplémentaire que le système peut apprendre à gérer.

Plus Oblivion passe de temps dans des conditions réelles, plus je gagne en confiance, non pas parce que les erreurs disparaissent, mais parce que je les comprends mieux.

Et dans le logiciel, comprendre un problème est généralement la première étape pour le résoudre.