À qui s’adresse cette page — À quiconque a défini une version de stratégie et souhaite l’observer sur les données qui arriveront après son gel, sans réécrire les règles, l’échantillon ou les critères à la lumière des résultats.
Le forward test est l’évaluation prospective d’une version gelée : la spécification est identifiée à un instant précis puis, à partir de cet instant, produit ses décisions en suivant le cours réel du temps. Les données futures ne peuvent pas être rembobinées, sélectionnées ou remplacées après que leur résultat a été observé. Le test mesure le comportement de la version pendant la période étudiée ; il ne prouve pas que l’edge persistera et ne garantit pas une exécution identique à plus grande échelle.
Le hors échantillon et le forward test répondent à des questions différentes. L’OOS indique si une donnée a participé au développement : même un segment historique déjà existant peut être OOS s’il est réellement resté scellé. Le forward test décrit au contraire l’ordre chronologique : les données arrivent après le gel. Le paper trading, le mode shadow et le micro-live sont des environnements de mise en œuvre dans lesquels un forward test peut être conduit ; ils ne sont synonymes ni du forward test ni du hors échantillon.
Relation entre données, temps et environnement
| Terme | Ce qu’il classe | Question correcte | Exemple |
|---|---|---|---|
| Hors échantillon | Relation entre données et développement | La donnée a-t-elle influencé un choix ? | Segment historique réservé et jamais consulté |
| Forward test | Relation temporelle | La décision précède-t-elle l’arrivée de la donnée ? | Version gelée à compter d’aujourd’hui |
| Paper trading | Environnement simulé | L’ordre expose-t-il du capital réel ? | Compte démo avec fills modélisés |
| Mode shadow | Mise en œuvre parallèle | La chaîne génère-t-elle des ordres sans les router ? | Ordres fantômes et logs en temps réel |
| Micro-live | Environnement réel réduit | Quels effets apparaissent avec de petits ordres réels ? | Routage et fills soumis à des limites strictes |
Ces catégories peuvent se recouper. Une observation produite demain par une version gelée et jamais employée pour la modifier est à la fois forward et OOS par rapport à cette version. Si son résultat conduit à définir un nouveau filtre, elle devient une information de développement pour la version suivante.
Ce qui doit être gelé
Geler « les règles » ne suffit pas. La version comprend au minimum :
- le code, les dépendances, les configurations et les seeds pertinents ;
- l’univers, la source de données, le calendrier, les horodatages et les règles relatives aux données manquantes ;
- les variables, les paramètres, les signaux et le traitement des cas sans opération ;
- la construction du portefeuille, le dimensionnement, le levier et les contraintes ;
- les types d’ordres, le modèle de fill, les coûts, le financement et le benchmark ;
- les métriques principales, les contrôles, les seuils d’alerte et le critère de conclusion ;
- le mode paper, shadow ou réel et leurs différences connues.
Une modification substantielle crée un nouvel identifiant. Corriger une faute de frappe dans la documentation peut ne pas changer la version ; modifier une variable, l’univers, un retard, les coûts, le dimensionnement ou le comportement des ordres la change normalement. Le registre doit permettre de vérifier la décision.
Protocole prospectif
- Rédiger le mandat. Distinguer l’objectif statistique, le contrôle de la chaîne, la qualité d’exécution et la formation opérationnelle.
- Appliquer le gel. Conserver la version, les empreintes des artefacts, la date et l’heure, les responsabilités ainsi que les critères prédéfinis de modification ou d’arrêt.
- Choisir l’environnement. Déclarer quels événements sont simulés et lesquels sont réels ; documenter le modèle de fill, le courtier, la plateforme de négociation, le flux et la latence.
- Enregistrer le flux complet. Conserver les données reçues, les signaux nuls, les intentions, les ordres, les rejets, les fills, les positions, les coûts, les alertes et les interventions humaines.
- Ne pas nettoyer rétroactivement. Les erreurs et les interruptions restent dans le registre ; les éventuelles exclusions suivent des règles définies à l’avance et sont rendues visibles.
- Comparer aux attentes déclarées. Évaluer la distribution, le risque, l’exposition, le turnover, l’exécution et le benchmark avec l’incertitude correspondante.
- Classer les écarts. Séparer incident de données ou incident opérationnel, erreur de mise en œuvre, dérive d’exécution, variabilité normale et détérioration possible du modèle.
- Conclure par une décision traçable. Continuer, limiter, suspendre, revalider ou créer une nouvelle version sont des résultats distincts de « bénéfice » et « perte ».
Durée et quantité d’information
Il n’existe aucune durée universelle. Le temps calendaire nécessaire dépend de la fréquence de la stratégie, de la dépendance entre les signaux, de l’horizon des positions, de la rareté des événements et de la précision requise. De nombreuses opérations corrélées n’équivalent pas au même nombre d’observations indépendantes ; quelques semaines bénéficiaires peuvent ne comprendre aucune des conditions substantielles à évaluer.
Le protocole devrait définir des critères fondés sur la couverture et sur la décision : types d’ordres observés, séances et événements pertinents, volume d’information, précision des métriques et absence d’incidents non résolus. Une date de fin peut être nécessaire à la gouvernance, sans constituer pour autant une preuve statistique de suffisance.
Un seuil unique de profit factor, de Sharpe ou de drawdown ne décide pas davantage de l’issue du test. Les métriques doivent être lues ensemble, nettes de coûts, par rapport à un benchmark choisi au préalable et avec des intervalles compatibles avec la dépendance et la distribution. Un résultat peut être favorable, incompatible avec l’hypothèse ou simplement non concluant.
Modifications, incidents et pureté du test
Des défauts opérationnels exigeant une intervention immédiate peuvent apparaître pendant le forward test. La sécurité prime sur la pureté statistique : il ne faut pas retarder un kill switch pour « sauver le test ». Le registre conserve l’incident, la décision et les données concernées. Si la correction modifie le comportement, une nouvelle version commence une nouvelle période prospective.
Consulter les résultats à plusieurs reprises et ajuster la stratégie transforme le forward test en développement itératif. L’itération est légitime, mais doit être désignée comme telle ; concaténer les segments de versions différentes et les présenter comme un seul track record intact est incorrect.
Exemple illustratif
Exemple expressément présenté à titre illustratif — La version 1.0 est gelée avec ses signaux, son dimensionnement, ses coûts et ses seuils opérationnels. En mode shadow, elle enregistre pour chaque événement l’ordre qu’elle aurait envoyé. Après le démarrage, il apparaît que les données d’une séance écourtée arrivent avec un calendrier erroné : l’incident est conservé, la chaîne est corrigée et la version 1.1 est créée. Les résultats de la version 1.0 ne sont pas attribués à la version 1.1. Aucun nombre de jours ou d’opérations n’est indiqué, car ces quantités dépendent de l’objectif et de la structure de l’information.
L’étape suivante pourrait être un micro-live limité afin d’observer le routage et le rapprochement. Elle n’est ni obligatoire ni suffisante dans tous les contextes et exige des autorisations, des limites de risque et des capacités opérationnelles appropriées.
Limites
- Le forward test n’observe que les régimes survenus après le gel.
- Le paper trading et le mode shadow ne reproduisent pas complètement la place dans la file, l’impact, la disponibilité des titres à emprunter et la pression économique ; le micro-live ne démontre pas la capacité à la taille visée.
- Une version gelée peut partager avec le backtest des biais de données et de conception.
- Surveiller de nombreuses métriques ou stratégies accroît le risque de sélection ex post.
- Le caractère prospectif améliore la traçabilité ; il ne transforme pas une corrélation en causalité.
Références
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, 2000 — ordre temporel, origine glissante et évaluations hors échantillon successives.
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners, 2024 — validation proactive et fiabilité des modèles d’investissement.
- National Futures Association, Interpretive Notice 9025 — Use of Promotional Material Containing Hypothetical Performance Results — limites de la performance hypothétique dans son propre périmètre NFA.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets, 2020 — automatisation, plateformes de négociation et interaction des ordres sur les marchés réels.
- Commission européenne, Règlement délégué (UE) 2017/589, RTS 6 — tests, contrôles, documentation et déploiement dans son propre périmètre réglementaire européen.