Backtester une stratégie crypto sans se leurrer

Le backtesting d'une stratégie de trading crypto ressemble à de la science. On injecte des données historiques de prix dans un système, on observe la courbe d'équité progresser vers le haut, et on se convainc d'avoir trouvé un avantage. La plupart du temps, on n'a rien trouvé, si ce n'est une courbe qui s'ajuste au passé. Cette distinction — entre la découverte d'un avantage réel et la fabrication d'un backtest flatteur — est l'une des séparations les plus importantes dans le trading systématique, et la crypto rend cette erreur particulièrement dangereuse.

Commençons par ce qu'est réellement un backtest. Il s'agit d'appliquer un ensemble fixe de règles à des données historiques et de mesurer ce qui se serait passé si l'on avait tradé selon ces règles durant cette période. Il n'enseigne qu'une seule chose : comment ces règles ont performé sur ce jeu de données spécifique, dans les conditions qui prévalaient pendant cette fenêtre temporelle. Il ne dit rien de ce qui se passera ensuite. Cela paraît évident, mais les traders confondent régulièrement un backtest performant avec la preuve d'une rentabilité future. L'écart entre ces deux réalités, c'est là que meurent la plupart des stratégies de trading systématique.

La distinction entre données in-sample et out-of-sample est le premier endroit où la rigueur se manifeste dans le processus. Les données in-sample correspondent à la fenêtre historique utilisée pour développer et optimiser ses règles. Les données out-of-sample sont celles que l'on garde entièrement séparées, que l'on ne consulte qu'une seule fois, après la fin du développement, comme test final permettant de vérifier si les règles se généralisent au-delà de la période sur laquelle elles ont été conçues. L'erreur classique consiste à optimiser sur la totalité des données disponibles et à appeler le résultat un backtest. Ce que l'on a réellement fait, c'est identifier le jeu de paramètres qui décrit le mieux le passé — un moteur de description, non un moteur de prédiction. Un processus rigoureux utilise les données in-sample pour la construction, garde 30 à 40 % des données historiques verrouillées, et ne teste sur cette fenêtre réservée qu'une fois toutes les décisions de paramétrage gelées. Si la performance out-of-sample se dégrade considérablement par rapport à la performance in-sample, il y a surapprentissage.

Le surapprentissage, ou curve-fitting, est la pathologie centrale du développement de stratégies systématiques. Il survient lorsque l'on ajoute suffisamment de degrés de liberté au modèle — suffisamment de paramètres, de conditions, de filtres — pour que la stratégie mémorise essentiellement les données d'entraînement plutôt que d'apprendre un comportement de marché structurel. Une stratégie dotée de douze paramètres, optimisée sur sept ans de données Bitcoin en timeframe horaire, est presque certainement surajustée, même si le backtest paraît excellent. Le test du surapprentissage n'est pas la courbe d'équité. C'est de savoir si la logique de la stratégie correspond à une dynamique de marché identifiable et reproductible, qui a une raison de persister. Si l'on ne peut expliquer en une phrase pourquoi acheteurs et vendeurs devraient se comporter ainsi de manière constante, l'avantage est probablement un artefact statistique du processus d'optimisation.

Les exigences en matière de taille d'échantillon sont sous-estimées en crypto, en partie parce que les traders considèrent que plusieurs années de données sont intrinsèquement suffisantes. Ce n'est pas le cas si la stratégie trade peu fréquemment. Une stratégie générant 30 trades par an sur trois ans produit 90 trades dans son backtest. La significativité statistique pour la détection d'un avantage requiert généralement un minimum de 200 à 400 trades, selon la variabilité des résultats. Avec 90 trades, une simulation Monte Carlo de la même distribution de rendements produira des courbes d'équité allant du catastrophique à l'exceptionnel — toutes cohérentes avec la même espérance sous-jacente. Le taux de gain et le R moyen observés sur 90 trades ne permettent de tirer presque aucune conclusion fiable. C'est la fréquence des trades multipliée par l'horizon temporel qui détermine si l'échantillon est significatif, et non le temps seul.

Le biais de look-ahead en crypto mérite une attention particulière, car il est plus facile de l'introduire accidentellement qu'en actions. Dans les frameworks de backtesting traditionnels, le biais de look-ahead désigne typiquement l'utilisation d'un prix futur ou d'une valeur d'indicateur future pour générer un signal. En crypto, il se manifeste sous des formes plus subtiles. Utiliser les prix de clôture journaliers pour simuler des entrées intraday suppose que l'on connaissait la clôture avant qu'elle ne se produise. Utiliser des données de carnet d'ordres agrégées après coup introduit un état qui n'était pas disponible en temps réel. De nombreux fournisseurs de données crypto reconstituent les bougies OHLCV à partir de données de trades, et la méthodologie de traitement des périodes à faible liquidité ou des interruptions d'exchange introduit des incohérences susceptibles de fausser les résultats de manière systématique. Considérez que vos données sont problématiques tant que vous n'avez pas vérifié soigneusement la méthodologie de la source.

La crypto présente des défis structurels qui rendent le backtesting sensiblement plus difficile qu'en actions. La liquidité sur la plupart des altcoins est suffisamment faible pour que les exécutions simulées n'auraient pas été réalisables aux tailles testées. Une stratégie exécutant 0,5 BTC par trade sur Binance en 2024 peut être testée sans problème. La même stratégie testée sur un altcoin de capitalisation moyenne à taille en dollars équivalente simule des exécutions qui auraient significativement joué contre vous. Les interruptions d'exchange, particulièrement sur les plateformes de futures en période de forte volatilité, créent des lacunes d'exécution qu'aucun backtest ne peut reproduire. Les régimes de taux de financement sur les perpétuels évoluent radicalement d'un cycle de marché à l'autre, et une stratégie ignorant les coûts de financement peut sembler rentable tout en perdant de l'argent en trading réel. La modélisation des frais doit être granulaire — maker versus taker, structures à paliers, et le slippage réalisé au-delà des frais affichés — sans quoi le backtest est optimiste par définition.

Le forward testing est le pont entre la validation historique et le déploiement de capital réel. Après qu'une stratégie a passé l'optimisation in-sample et le test out-of-sample, on la trade dans des conditions de marché réelles à taille minimale — ou en paper trading, bien que l'exécution réelle soit plus instructive — et l'on vérifie si la performance en live correspond à la distribution statistique prédite par le backtest. La question clé n'est pas de savoir si la stratégie gagne de l'argent pendant la fenêtre de forward testing. C'est de savoir si les caractéristiques trade par trade — gain moyen, perte moyenne, variance des résultats — sont cohérentes avec ce que le backtest avait prédit. Une divergence significative signifie soit que le backtest était défaillant, soit que les conditions de marché ont évolué d'une façon qui invalide l'avantage.

Les métriques qui importent ne sont pas celles que la plupart des traders présentent. Le taux de gain n'a presque aucune signification sans le ratio de gain/perte associé. Un taux de gain de 35 % avec un gain moyen de 3R représente un meilleur avantage qu'un taux de gain de 65 % avec un gain moyen de 0,8R. L'espérance mathématique — le montant moyen gagné par unité risquée, calculée comme (taux de gain multiplié par le gain moyen) moins (taux de perte multiplié par la perte moyenne) — est le chiffre le plus important. Un ratio de Sharpe supérieur à 1,0 indique que les rendements sont adéquats par rapport à la volatilité. Le drawdown maximum et le facteur de récupération — profit net divisé par le drawdown maximum — révèlent si la stratégie survit aux séries de pertes inévitables. Une stratégie à forte espérance mais avec un facteur de récupération inférieur à 2,0 exige une discipline de gestion du capital que la plupart des traders ne maintiendront pas en pratique.

Le cadre opérationnel est le suivant : construire uniquement sur les données in-sample, geler tous les paramètres, exécuter une seule fois sur les données out-of-sample, exiger au moins 300 trades dans l'échantillon combiné, vérifier la méthodologie de la source de données, modéliser les frais et le slippage de manière conservatrice, et ne pas démarrer le forward testing tant que le résultat out-of-sample n'est pas acceptable. S'il n'est pas acceptable dès le premier essai, la bonne réponse n'est pas de ré-optimiser jusqu'à ce qu'il passe. Cette ré-optimisation efface entièrement la distinction entre in-sample et out-of-sample. Mesurez d'abord, puis décidez si l'avantage est réel.