Vous avez trouvé un résultat net : votre stratégie crypto réalise l’essentiel de son rendement entre 13:00 et 14:00 UTC. Vous avez vérifié les frais, relancé le backtest et testé le signal en paper trading. Vous préparez maintenant une version sur les actions américaines, et l’heure la plus performante semble être 09:30–10:30, heure de New York.
Avant de vous fier à l’un ou l’autre résultat, vérifiez ce qu’a fait l’horloge. Le passage à l’heure d’été aux États-Unis décale l’ouverture de New York d’une heure par rapport à l’UTC. Si vos variables, vos étiquettes de session et vos ordres reposent sur des notions du temps différentes, la stratégie exploite peut-être une frontière du calendrier plutôt qu’un schéma de marché reproductible.
Pas besoin d’abandonner la recherche sur les effets liés à l’heure de la journée. Il faut définir l’horloge à laquelle se rapporte votre hypothèse, puis veiller à ce que chaque composant du backtest l’utilise de manière cohérente.
D’abord, précisez ce que signifie l’heure
« La première heure » semble précis jusqu’à ce qu’on indique l’horloge de référence. Il peut s’agir des 60 premières minutes après l’ouverture du NYSE, de 09:30 à 10:30 à l’heure civile de New York, ou d’un intervalle UTC fixe. Ces définitions coïncident une partie de l’année et divergent autour des changements d’heure.
Pour l’hypothèse sur les actions, utilisez l’heure locale de la session de la place : 09:30, heure de New York, signifie 09:30, que New York soit à l’EST ou à l’EDT. Pour l’hypothèse crypto, une heure UTC fixe peut être la variable visée. Les cryptos se négocient en continu : aucune cloche d’ouverture ne permet d’ancrer l’affirmation.
Consignez la définition avant d’optimiser. « Trader la première heure après l’ouverture de la séance régulière » est une hypothèse testable. « Trader l’heure où le signal fonctionne le mieux » laisse l’optimiseur choisir la convention horaire en même temps que la stratégie.
Comment les décalages d’horloge s’insinuent dans le test
Supposons que vos données sur les actions soient stockées en UTC, que votre code de calcul des variables regroupe les lignes par heure UTC et que vos règles d’exécution ouvrent des positions à 09:30, heure de New York. Après le passage à l’heure d’été, l’ouverture du marché passe de 14:30 UTC à 13:30 UTC. Une variable étiquetée « première heure » selon son créneau UTC désigne alors une autre partie de la séance.
Un piège semblable apparaît quand vous construisez des bougies à partir d’horodatages. Si vous rééchantillonnez en UTC, puis convertissez les étiquettes en heure de New York, vous pouvez obtenir des limites inattendues, surtout au printemps, quand une heure locale n’existe pas, et à l’automne, quand une heure locale se produit deux fois. Un horodatage comme 01:30, heure locale, est ambigu ce dimanche d’automne s’il ne comporte pas de décalage UTC ou s’il n’est pas représenté en UTC.
Le calendrier peut aussi compter pour votre résultat crypto. Une stratégie fondée sur l’heure UTC peut coïncider avec l’activité des marchés américains pendant des mois, puis sembler se décaler au changement d’heure aux États-Unis. Cela ne rend pas la stratégie invalide, mais change la conclusion que vous pouvez en tirer. Vous avez peut-être mesuré un schéma fixe en UTC qui chevauche parfois l’ouverture américaine, plutôt qu’un effet lié à cette ouverture.
Intégrez l’horloge de session au test
Conservez les horodatages des événements en UTC comme référence canonique. Dérivez les champs de session locale à partir d’un fuseau horaire nommé tel que America/New_York, en vous appuyant sur une base de données de fuseaux horaires qui gère les changements historiques de règles. Ne codez pas en dur « UTC moins cinq » ou « UTC moins quatre » : aucun de ces décalages ne définit l’heure de New York toute l’année.
| Décision | Exemple sur les actions | Exemple crypto |
|---|---|---|
| Horloge de l’hypothèse | Minutes écoulées depuis l’ouverture de la séance régulière | Heure UTC de la journée |
| Source des sessions | Calendrier de la place, avec jours fériés et fermetures anticipées | Calendrier UTC continu |
| Horaire des ordres | Prochain événement exécutable après le signal | Prochain événement exécutable après le signal |
Testez ensuite séparément les semaines entourant les changements d’heure. Comparez les performances avant et après chaque changement, puis vérifiez si l’intervalle gagnant reste lié à la séance de marché ou demeure fixe en UTC. Si vous avez passé en revue de nombreuses heures, dates et décalages pour trouver le meilleur résultat, tenez compte de cette recherche dans votre évaluation du surapprentissage : le choix de l’horloge constituait un essai supplémentaire.
Un fuseau horaire est un ensemble de règles, pas un nombre d’heures à soustraire. Stockez les événements en UTC ; dérivez l’heure locale du marché quand vous en avez besoin.
Ce que votre test en paper trading doit confirmer
Quand vous passez la stratégie en paper trading, consignez à la fois l’horodatage UTC de l’événement et sa minute par rapport à la session. Vous repérerez ainsi rapidement une stratégie qui croit que l’ouverture a lieu à 09:30, mais déclenche en réalité à 10:30, heure locale. Vérifiez aussi les jours fériés et les fermetures anticipées : un horaire de séance normale copié sur tous les jours de la semaine inventera volontiers des transactions les jours où la place est fermée.
Et quand l’heure change, résistez à l’envie de « corriger » un résultat en décalant le signal jusqu’à ce que la courbe de capital retrouve son allure habituelle. Vérifiez d’abord l’hypothèse formulée, le calendrier et l’horaire des ordres. Si le résultat suit la séance de marché, vous avez appris quelque chose sur le comportement de la séance. S’il reste à la même heure UTC, vous avez appris autre chose. Votre backtest doit préserver cette distinction.
← Tous les articles
