Fuite de données et biais d’anticipation

La fuite de données est la contamination d’une procédure de recherche par une information qui n’aurait pas dû être disponible au point où elle est employée. Le biais d’anticipation est son cas temporel : la décision au temps t intègre directement ou indirectement des données connues seulement après t. Le résultat n’est pas simplement optimiste ; il simule une autre stratégie, dotée d’un canal d’information inexistant.

Distinctions essentielles

Le biais de survie est distinct : il résulte de l’observation exclusive des entités survivantes ou sélectionnées a posteriori. Il peut coexister avec une fuite, mais corriger les horodatages ne recrée pas à lui seul les instruments défaillants, les fonds fermés ou les anciennes composantes d’un indice.

Trois horloges : signal, ordre et exécution

Une règle de trading doit déclarer au moins trois moments :

1. Signal time : dernière information admise dans le calcul.
2. Order time : premier instant où l’ordre peut être créé et transmis.
3. Fill time : instant ou intervalle pendant lequel le modèle d’exécution peut attribuer quantité et prix.

Si le signal emploie close[t], une exécution à close[t] exige un mécanisme réellement accessible avant ou pendant l’enchère et des données compatibles avec cette décision. Sans cette preuve, une convention plus défendable consiste à envoyer l’ordre après le signal et à modéliser une exécution ultérieure. De même, le plus haut et le plus bas complets d’une barre ne peuvent décider d’un ordre exécuté à l’intérieur de cette barre sans séquence intrabar observable.

Pour les communiqués, dépôts et données macroéconomiques, il faut l’horodatage de diffusion, non la date de la période économique. Les données point-in-time ajoutent le millésime, le retard du fournisseur et les corrections ultérieures.

Où se cache la fuite

Features et transformations

• moyennes centrées, filtres bidirectionnels ou interpolations utilisant des observations futures ;
• classement cross-sectional calculé sur un univers reconstitué aujourd’hui ;
• winsorisation, imputation ou standardisation estimées sur tout le jeu de données ;
• fondamentaux alignés sur la fin du trimestre plutôt que sur le dépôt ;
• splits et dividendes appliqués sans distinguer date d’effet et information connue.

Recherche et sélection

Le jeu de test peut être contaminé même sans colonne future. Consulter répétitivement son résultat pour choisir features, seuils ou modèles le transforme progressivement en donnée de développement. Le hors échantillon n’est pas une étiquette de fichier : c’est un rôle dans le processus. Le nombre de solutions essayées, les décisions écartées et les critères de sélection doivent être enregistrés.

Ordres et exécution

Un prix OHLC ne démontre pas que l’ordre aurait été exécuté. Stops et ordres à cours limité peuvent être touchés sans exécution ; la quantité disponible peut être insuffisante ; la priorité dans la file est inconnue ; retards et exécutions partielles changent la position. Attribuer systématiquement le prix le plus favorable de la barre constitue une connaissance rétrospective, distincte mais liée aux coûts de transaction du backtest.

Protocole causal

1. Écrire la décision avant le code. Énumérer entrées, horodatages, fuseau, heure limite, fréquence et action produite.
2. Versionner les données brutes. Conserver instantanés, millésimes, univers et opérations sur titres sans écraser l’histoire.
3. Calculer chaque feature « as of ». La requête au temps t doit exclure tout enregistrement où available_at > t.
4. Ajuster uniquement dans le train. Imputation, scaling, sélection des variables et optimisation doivent être appris dans le sous-ensemble autorisé puis appliqués vers l’avant.
5. Respecter l’ordre temporel. Employer des découpages chronologiques ; si labels ou positions se chevauchent, évaluer un purge et un gap cohérents avec l’horizon.
6. Geler la spécification. Avant l’évaluation finale, enregistrer règles, paramètres, univers, benchmark et métriques.
7. Séparer signal, ordre et exécution. Appliquer retards, calendrier, type d’ordre et données réellement observables.
8. Conserver tous les essais. Un registre des variantes réduit l’invisibilité du data snooping.
9. Repartir d’un instantané propre. Le résultat doit être reproductible sans fichiers intermédiaires construits avec le futur.

Tests diagnostiques

Un effondrement après ces tests est un signal d’alarme, pas une preuve automatique de la cause. Un résultat stable ne démontre pas non plus l’absence de fuite : certaines contaminations peuvent résister aux perturbations.

Limites

Découpages temporels, walk-forward ou validation croisée ne réparent pas des données déjà contaminées. Purge et embargo doivent découler de la structure des labels, et non être appliqués comme des rituels. Un jeu causal peut encore souffrir d’erreurs de mesure, de sélection multiple, de changement de régime, de faible puissance ou d’un univers incomplet. La validation exige donc à la fois des contrôles statistiques et un audit du parcours de l’information.

Références

• Halbert White, A Reality Check for Data Snooping, Econometrica, 2000 — inférence lorsque le résultat sélectionné provient de nombreuses spécifications.
• Robert D. Arnott, Campbell R. Harvey et Harry Markowitz, A Backtesting Protocol in the Era of Machine Learning — séparation entre recherche, sélection, holdout et rareté des données financières.
• David H. Bailey, Jonathan M. Borwein, Marcos López de Prado et Qiji Jim Zhu, The Probability of Backtest Overfitting — risque de surapprentissage issu de la sélection entre de nombreuses configurations.
• Federal Reserve Bank of St. Louis, FRED® versus ALFRED® — différence entre l’information historique disponible aujourd’hui et le millésime connu dans le passé.
• scikit-learn, TimeSeriesSplit — validation croisée ordonnée dans le temps et paramètre de gap ; documentation technique officielle.

Liens connexes

• Trading systématique
• Backtest
• Hors échantillon
• Données point-in-time
• Biais de survie
• Coûts de transaction dans les backtests