Un backtest parfaitement reproductible peut être moins fiable qu’un autre dont le résultat varie légèrement. La répétabilité prouve que vous pouvez obtenir deux fois la même réponse ; elle ne dit rien sur le fait que cette réponse dépende d’un instantané de données arbitraire, d’une bizarrerie de bibliothèque ou d’un paramètre par défaut caché.
On pourrait croire que c’est un argument contre la reproductibilité, mais ce n’est pas le cas. Figez l’exécution pour pouvoir l’expliquer. Faites ensuite délibérément varier les hypothèses qui ne devraient pas déterminer le résultat. La première étape rend un résultat vérifiable ; la seconde indique s’il a un sens.
Que permet réellement d’établir un backtest reproductible ?
Si le même code, les mêmes données, la même configuration et la même seed aléatoire produisent les mêmes transactions et les mêmes métriques, vous avez écarté une source importante de confusion. Vous pouvez comparer l’« amélioration » d’un agent à son exécution de référence. Vous pouvez distinguer la correction d’un bug d’un changement de barème de frais. Un collègue peut examiner le même registre et retrouver les mêmes exécutions.
Mais le résultat dépend de tout ce que vous avez figé. Prenons une stratégie crypto dont le fichier historique contient des bougies d’une minute. Vous enregistrez l’empreinte du fichier, épinglez le code et obtenez un Sharpe de 1.4 à chaque nouvelle exécution. Si le fournisseur corrige ensuite plusieurs bougies, cette reproductibilité impeccable décrit toujours l’ancien fichier. Elle ne vous indique pas si le signal résiste à l’historique corrigé, ni si ces bougies étaient disponibles sous cette forme à l’époque.
L’empreinte est utile : elle rend cette dépendance visible. Elle ne prouve pas que cette dépendance est sans conséquence.
Figer l’exécution, mettre le constat à l’épreuve
J’aime distinguer deux questions. Pouvons-nous reconstruire exactement cette exécution ? Et la conclusion de recherche résiste-t-elle à des changements raisonnables ? La première exige un enregistrement immuable ; la seconde, des variations contrôlées, une à la fois.
| À consigner | À faire varier ensuite | Ce que cela peut révéler |
|---|---|---|
| Version des données brutes et sommes de contrôle | Révision du fournisseur ou seconde source | Dépendance à des valeurs corrigées ou propres au fournisseur |
| Commit du code et versions des packages | Implémentation numériquement équivalente | Sensibilité à l’ordre, aux arrondis ou à la bibliothèque |
| Frais, funding et hypothèses d’exécution | Fourchette de coûts défendable | Si un avantage faible exige des conditions d’exécution inhabituellement favorables |
| Univers et composition à la date considérée | Autres règles d’éligibilité des marchés | Dépendance aux décisions d’inclusion ou d’exclusion |
Par exemple, supposons qu’une stratégie sur contrats à terme affiche un rendement excédentaire annualisé de 8% dans une simulation de référence. Relancez-la avec des coûts taker supérieurs de 25%, en décalant le funding au prochain règlement observé et en retirant tour à tour les deux plus gros contributeurs. Ce ne sont pas trois façons d’améliorer le modèle. Ce sont des tests : chacun vérifie si un détail plausible porte le résultat mis en avant.
Gardez chaque test distinct. Si vous modifiez simultanément les données, le barème de frais et le calendrier d’exécution, un résultat moins bon vous apprendra peu de choses sur sa cause. Et si un test est invraisemblable, présentez-le comme un scénario de stress plutôt que comme le résultat le plus probable.
Ne confondez pas identité octet par octet et vérité numérique
Certains calculs sont sensibles à l’ordre des opérations. L’addition en virgule flottante n’est pas associative ; additionner de nombreux petits montants de P&L dans un ordre différent peut donc modifier les derniers chiffres. Les réductions parallèles, le matériel et les versions des bibliothèques peuvent aussi influer sur le résultat exact. C’est généralement sans conséquence ; parfois, un minuscule changement numérique franchit un seuil, modifie une position et entraîne le reste de la simulation sur une autre trajectoire.
C’est pourquoi je conserverais à la fois les artefacts exacts et les tolérances de comparaison. Consignez le registre des transactions, pas seulement le Sharpe final. Comparez d’abord les décisions et les flux de trésorerie, puis les métriques dans la limite d’une tolérance indiquée. Si un écart d’un centime change la décision de soumettre un ordre, examinez explicitement ce seuil.
Un enregistrement d’exécution utile comprend l’identité des données et du code, la configuration, la seed aléatoire, l’environnement d’exécution et suffisamment de sorties intermédiaires pour relier une métrique aux exécutions et aux flux de trésorerie. Un score final, à lui seul, ne constitue pas un artefact de recherche reproductible.
Quand une variation relève du bruit, et quand elle révèle quelque chose
Tout chiffre qui change n’est pas une crise. Une légère dérive de métrique due à un ordre de réduction différent peut laisser les transactions inchangées. Une transaction modifiée près d’un seuil mérite peut-être un examen. Une stratégie qui perd l’essentiel de son résultat après la révision par un fournisseur d’une petite portion de l’historique révèle sa propre fragilité, même si l’exécution initiale reste parfaitement reproductible.
Les critiques des tests de robustesse ont raison sur un point : il est facile de modifier les hypothèses jusqu’à ce qu’une stratégie choisie semble résiliente, ou de rejeter un résultat solide parce qu’un scénario délibérément extrême le met en échec. Définissez à l’avance les variations plausibles, présentez-les toutes et distinguez les variantes ordinaires des scénarios de stress. Conservez ensuite la référence pour qu’un autre chercheur puisse reproduire exactement ce que vous avez observé.
La reproductibilité vous donne un point de départ fiable. La question utile vient ensuite : quelles parties du résultat restent stables lorsque le contexte de cette exécution change d’une façon à laquelle on peut raisonnablement s’attendre ?
← Tous les articles
