Test walk-forward pour bots crypto : un exemple détaillé

Vous testez vingt configurations de bot sur le même graphique et choisissez celle qui affiche le rendement le plus élevé. Ses paramètres reflètent désormais les informations de toute cette période. L’exécuter à nouveau sur les mêmes dates ne vous apporte aucune preuve supplémentaire.

Le test walk-forward sélectionne à plusieurs reprises des paramètres sur une fenêtre d'entraînement antérieure, les fige pour une fenêtre de test ultérieure, puis combine les résultats de ces fenêtres de test. Il vous permet d’examiner un processus de sélection à travers des conditions changeantes tout en excluant les prix futurs de chaque décision de sélection.

Pour les stratégies GRID et DCA, il existe un problème comptable supplémentaire : les coins et les positions ouvertes peuvent traverser la frontière temporelle. Un test utile nécessite une règle pour ces avoirs avant que le premier résultat n’apparaisse.

L’entraînement, le test et la démo en temps réel désignent des choses différentes

Le guide général du backtesting aborde les principales limites de la simulation historique. Le walk-forward ajoute une division temporelle répétée ; il ne supprime pas les hypothèses d’exécution, les erreurs de données, ni la tentation de modifier les règles après avoir vu les résultats.

La documentation walk-forward de QuantConnect décrit la sélection des paramètres sur des fenêtres glissantes et le compromis concernant la fréquence d’optimisation. Réoptimiser plus souvent génère davantage de décisions et offre plus d’opportunités d’ajuster les paramètres au bruit récent.

Rédigez le protocole avant de comparer les résultats

Choisissez le marché, l’intervalle de données, le fuseau horaire et les paramètres candidats exacts. Gardez la liste des candidats suffisamment restreinte pour pouvoir l’examiner. Un test de trois configurations déclarées est plus facile à expliquer qu’une recherche parmi des milliers de combinaisons non documentées.

Précisez également :

• La durée de l'entraînement et la durée du test, y compris les horodatages précis des frontières.
• La métrique de sélection, l’exigence minimale de preuves et la règle de départage.
• Frais, slippage, tailles minimales, arrondis et modèle d'exécution.
• Le traitement des avoirs et des ordres ouverts à chaque frontière temporelle.
• Les actifs initiaux de l'indice de référence et les règles de rééquilibrage.

Par exemple, un protocole hypothétique pourrait choisir le rendement d’entraînement le plus élevé parmi trois candidats dont le drawdown d’entraînement reste en dessous d’une limite définie. Si aucun ne remplit ce critère, la stratégie conserve la trésorerie pour le mois de test suivant. Définissez la limite de drawdown et la solution de repli avant d’examiner les mois de test.

La limite est une contrainte de sélection, pas une promesse concernant le drawdown futur. Une stratégie qui la respecte lors de l'entraînement peut la dépasser lors du test.

Séparez les dates sans compter un mois de test deux fois

Utilisez trois mois pour l'entraînement et un mois pour le test dans ce calendrier roulant à titre d'exemple. Chaque horodatage ci-dessous est en UTC, et chaque intervalle inclut sa date de début mais exclut sa date de fin.

Les fenêtres d'entraînement se chevauchent. Les quatre fenêtres de test, elles, ne se chevauchent pas. Avril peut devenir une donnée d'entraînement historique pour le tour suivant une fois terminé ; vous ne pouvez pas utiliser l'évolution des prix d’avril pour choisir les paramètres testés sur avril elle-même.

Enregistrez la sélection effectuée à chaque frontière. Un compte rendu complet inclut les candidats rejetés ainsi que leurs métriques d'entraînement, afin qu’un autre examinateur puisse reconstituer pourquoi le gagnant a été choisi.

Une première itération complète

Le tableau suivant contient des valeurs fictives à but pédagogique. Il ne s'agit pas de résultats de backtest mesurés ni d'observations de marché. Supposons que la règle de sélection écrite exige un drawdown d'entraînement ne dépassant pas 10 %, puis sélectionne le rendement net d'entraînement le plus élevé. Tous les rendements sont calculés après les coûts indiqués du modèle.

Le protocole sélectionne A. Le rendement supérieur du candidat B ne l’emporte pas sur la contrainte de drawdown déclarée. Le candidat C reste dans le registre même s’il perd la comparaison.

Figez A pour avril. Supposons que l’exemple pédagogique lui attribue un rendement net de −2 % en avril. Cette valeur est inscrite dans l’historique hors échantillon. Passer à C sous prétexte qu’il aurait mieux géré avril reviendrait à réutiliser le mois de test dans la décision.

À la frontière de mai, le protocole initial compare à nouveau tous les candidats en utilisant les données de février à avril. Il peut sélectionner C pour mai si C remporte cette nouvelle comparaison d’entraînement. Il s’agit d’une mise à jour planifiée utilisant les informations disponibles à ce moment-là.

Regroupez les fenêtres de test ultérieures en un seul parcours de l’équité

Supposons que les sélections suivantes et les rendements de test soient les suivants. Ces valeurs poursuivent le même exemple comptable fictif et ne proviennent pas d’une simulation de stratégie réelle.

Les valeurs finales sous-jacentes non arrondies sont 980, 989,8, 960,106 et 979,30812. Le rendement combiné est :

(1 − 0,02) × (1 + 0,01) × (1 − 0,03) × (1 + 0,02) − 1 = −2,069188 %.

Additionner les quatre pourcentages donne −2 %, ce qui diffère du résultat composé. Reportez l’équité de fin de la fenêtre précédente dans la suivante et n’arrondissez que pour l’affichage.

Les observations de fin de mois montrent une baisse maximale d’environ 3,99 % par rapport aux 1 000 $US initiaux. L’équité intramensuelle aurait pu chuter davantage, de sorte que les observations mensuelles ne permettent pas d’établir le drawdown maximal réel.

Pour cet exemple comptable, supposons que chaque remise à zéro à la frontière est incluse dans les rendements nets mensuels indiqués. Un véritable backtest doit calculer ces remises à zéro à partir de ses avoirs et de son modèle d'exécution.

Décidez du sort de l’inventaire GRID ou DCA ouvert

Supposons qu’un bot termine le mois d’avril avec 0,01 BTC et 400 USDT en portefeuille. Avec un BTC hypothétiquement à 50 000 $US, sa valeur nette est de 900 $US. Un nouveau mois ne le ramène pas à l’état initial de 1 000 $US.

Choisissez une politique de gestion des frontières cohérente :

Transférer les avoirs. Faites passer les pièces, la trésorerie et l’état des positions réels dans la fenêtre de test suivante. Définissez l’impact d’un changement de paramètres sur les ordres et l’inventaire existants. Le simulateur doit prendre en charge cette transition ; un nouveau backtest lancé avec les actifs par défaut pourrait ne pas la refléter.

Clôturer et remettre à zéro. Annulez les ordres en attente, vendez ou clôturez l’exposition restante en utilisant le modèle d’exécution déclaré, déduisez les frais, puis commencez la fenêtre suivante avec l’équité ainsi obtenue. Si la configuration suivante nécessite un inventaire initial de coins, modélisez également cet achat et ses coûts.

Chaque politique peut décrire un processus opérationnel réel. Les mélanger après avoir vu les résultats peut masquer des pertes. Gardez la même politique dans l’indice de référence lorsque cela est pertinent et montrez l’effet d’une politique différente dans une vérification de sensibilité distinctement étiquetée.

Vérifiez le modèle d'exécution et l’indice de référence

Qu’une bougie atteigne un prix limite ne prouve pas que votre ordre aurait pu être exécuté en totalité. Les données de bougie peuvent également masquer si un niveau d’achat ou de vente a été atteint en premier. Des paramètres GRID denses peuvent sembler attrayants dans une simulation qui suppose un ordre intrabar favorable.

Documentez la façon dont le modèle gère les exécutions partielles, la priorité dans la file d’attente, le spread et les gaps. Répétez l’analyse avec des coûts ou des exécutions moins favorables lorsque l’outil le permet. Une conclusion qui disparaît après une légère modification des coûts mérite d’être examinée de près.

Utilisez les mêmes dates, le même capital de départ et les mêmes actifs initiaux pour la comparaison. Un bot qui commence avec la moitié en cryptomonnaies et l’autre moitié en liquidités n’est pas directement comparable à un indice de référence entièrement investi, sauf si vous expliquez cette différence d’allocation.

La checklist des résultats de backtest est utile pour examiner le rapport obtenu. Conservez le parcours mensuel, l’activité de trading, l’exposition et les coûts en parallèle du rendement total.

Gardez l’évaluation finale distincte de la conception du protocole

Des tests walk-forward répétés peuvent eux-mêmes devenir de l’entraînement. Si vous examinez les quatre mois de test, modifiez la liste des candidats, puis relancez la même période, la méthode mise à jour a utilisé des informations provenant de ces mois.

Consignez cette révision et réservez l’historique non utilisé ou les nouvelles données à venir pour la prochaine évaluation. Un nouvel étiquetage sur les mêmes dates ne les rend pas à nouveau inédites.

L’enregistrement téléchargeable peut être simple : une ligne par itération, avec les dates d’entraînement, la version du candidat, les métriques de sélection, la configuration choisie, les dates de test, le modèle de coûts, la politique de gestion des frontières et le résultat net du test. Conservez les rapports bruts et les références de données à côté. L’exemple ci-dessous inclut le tableau fictif sous forme de CSV exportable pour s’exercer à la comptabilité.

Enchaînez les vérifications historiques par une démo fixe

Entraînez-vous à la comptabilité de l’exemple

Téléchargez les quatre lignes fictives correspondant aux mois de test, incluant l’équité de début et de fin. Il s’agit de valeurs pédagogiques inventées, et non d’un rapport de backtest.

Observez votre configuration en démo Bitsgap

Après avoir terminé votre analyse historique dans un outil prenant en charge les fenêtres et la comptabilité requises, figez une configuration de bot compatible en démo Bitsgap. Notez ses actifs initiaux et ses paramètres, puis observez-la avec des fonds virtuels et les prix de marché actuels. La démo constitue un exercice walk-forward distinct ; ce processus ne suppose pas l’existence d’un optimiseur walk-forward intégré.

Questions fréquemment posées

Le test walk-forward empêche-t-il le surapprentissage ?

Il réduit une source de biais sur échantillon d'apprentissage en séparant chaque fenêtre de sélection de son test ultérieur. Des modifications répétées du protocole, des fuites de données, des exécutions irréalistes et des rapports sélectifs peuvent néanmoins produire des résultats trompeurs.

Quelle doit être la durée des fenêtres ?

Il n’existe pas de durée universelle. La fréquence de trading, l’historique disponible et la méthode de sélection déterminent la quantité d’informations que chaque fenêtre contient. La répartition trois mois / un mois présentée ici sert d’exemple pédagogique.

Puis-je additionner les rendements de différentes fenêtres de test ?

Composez les rendements séquentiels lorsque chaque fenêtre commence avec l’équité de fin de la fenêtre précédente. Préservez également le cheminement de l’équité sous-jacente, les coûts et l’exposition ; un pourcentage final seul masque des différences importantes.

La démo en temps réel est-elle identique à un test historique hors échantillon ?

Un test historique hors échantillon utilise des données historiques ultérieures dans un simulateur. Une démo en temps réel observe de nouvelles données avec des fonds virtuels. Les deux ont des limites, et aucun ne garantit les exécutions en conditions réelles ni les performances futures.