Spécification d’une stratégie systématique

La spécification d’une stratégie systématique est le document versionné qui décrit la stratégie avant son évaluation : objectif, hypothèse, informations autorisées, transformations, signaux, positions, risque, ordres, coûts, benchmark, contrôles et critères de révision. Elle constitue à la fois un contrat de recherche, une interface entre recherche et production et une piste d’audit.

Une phrase telle que « acheter le breakout avec du volume » n’est pas une spécification. L’univers, le calendrier, les ajustements, la longueur de la fenêtre, l’inclusion de la barre courante, l’heure du calcul, le premier prix exécutable, la taille, la sortie, le traitement des gaps et le comportement en cas de données manquantes restent indéfinis. Chaque ambiguïté permet au backtest d’intégrer des décisions rétrospectives qui ne seraient pas disponibles en temps réel.

Les blocs indispensables

Ces champs peuvent être répartis entre texte, configuration et code, à condition de pouvoir être rapprochés. Les unités doivent être explicites : pourcentage du capital, notionnel, volatilité, delta, devise et fréquence ne sont pas interchangeables.

L’horloge causale

La spécification doit ordonner au moins quatre instants :

« Cours de clôture du jour » ne suffit pas. La clôture officielle peut n’être connue qu’après l’enchère ; une donnée fondamentale peut se rapporter à un trimestre mais ne devenir publique que plusieurs semaines plus tard ; une série macroéconomique peut être révisée. Si le signal emploie la clôture et que le backtest achète à cette même clôture, il faut expliciter un mécanisme qui permette de participer à l’enchère avec l’information nécessaire. Sans ce mécanisme, le premier prix suivant constitue un choix plus cohérent, mais il doit lui aussi modéliser les gaps et les coûts.

Pour chaque entrée, au moins trois dates sont utiles : période économique de référence, publication initiale et version ou millésime utilisé. Pour chaque ordre, il faut l’état, l’horodatage, la quantité demandée, la quantité exécutée, le prix et le motif du rejet ou de l’annulation.

États et exceptions

Une stratégie réelle ne se limite pas à l’embranchement « signal présent → ordre exécuté ». La spécification établit ce qui se passe lorsque :

• une donnée manque ou arrive en retard ;
• un instrument est suspendu, radié de la cote ou change d’identifiant ;
• un contrat à terme entre dans sa fenêtre de roll ;
• le prêt de titres n’est pas disponible ou son coût dépasse la limite ;
• l’ordre est partiellement exécuté, rejeté ou reste ouvert en fin de séance ;
• le prix, la position, la marge ou le P&L ne se rapprochent pas ;
• le contrôle du risque ou la connexion au courtier ne répondent pas.

« Ne rien faire » n’est une règle valable que si l’état qui en résulte est précisé : conserver la position précédente, la réduire, la liquider ou bloquer les nouveaux ordres produit des risques différents.

Protocole de recherche associé

Avant d’observer le résultat destiné à la décision, le protocole enregistre :

1. la question et l’hypothèse falsifiable ;
2. la version de la spécification et le dépôt du code ;
3. le jeu de données, le périmètre temporel et l’univers ;
4. la baseline et le benchmark cohérents ;
5. les métriques primaires et secondaires, brutes et nettes ;
6. le plan in-sample, de validation et de test final ;
7. l’ensemble des paramètres ou modèles candidats ;
8. les hypothèses de coûts, de liquidité et de capacité ;
9. le critère permettant de poursuivre, modifier ou abandonner ;
10. le registre de chaque essai, y compris des résultats négatifs.

Un critère ne doit pas nécessairement se réduire à un seuil unique. Il peut exiger une cohérence économique, un signe stable sur plusieurs segments, une incertitude acceptable, une matérialité nette et l’absence de dépendance à un point ou à une variante. Le choix doit être proportionné à l’usage : un outil exploratoire interne et une stratégie qui engage du capital n’ont pas les mêmes conséquences.

Versions, reproductibilité et réplication

Chaque résultat devrait identifier le commit ou la version du code, le fichier de configuration, l’environnement et les dépendances, les graines aléatoires, la version du jeu de données et les principales sorties. Un instantané ou une empreinte aide à démontrer que l’entrée n’a pas changé. Réexécuter le même code sur les mêmes données relève de la reproductibilité ; obtenir une preuve cohérente au moyen d’une réalisation indépendante relève de la réplication. Ces propriétés sont liées, mais non équivalentes.

Lorsqu’un test hors échantillon conduit à une modification, une nouvelle version est créée. Le segment consulté ne redevient pas vierge : il doit être enregistré comme information de développement. Cette généalogie empêche les itérations successives d’accumuler un data snooping invisible.

La séparation des rôles peut améliorer l’efficacité de la révision, mais « indépendant » ne signifie pas nécessairement externe. Cela signifie que la personne qui remet en cause les hypothèses, l’implémentation et l’usage dispose des compétences, de l’autorité et des incitations nécessaires pour contester le résultat.

Exemple illustratif : un signal en fin de journée

Une spécification hypothétique déclare que le signal n’emploie que des données consolidées jusqu’à la clôture de t ; il est calculé après réception des fichiers définitifs ; les ordres ne peuvent pas être envoyés avant l’ouverture de t+1. L’univers est reconstitué selon sa composition historique ; les instruments non négociables génèrent un état d’exception ; la taille respecte des limites de participation et de concentration ; le coût dépend du spread et de la quantité.

L’exemple ne prescrit pas que l’ouverture suivante soit toujours le bon choix. Il montre comment rendre la causalité contrôlable. Une stratégie participant à l’enchère de clôture exigerait au contraire des signaux calculables avant l’heure limite et un modèle d’exécution cohérent avec cette enchère.

Critères de qualité

• Un implémenteur indépendant ne doit pas avoir à inventer une règle manquante.
• Chaque variable possède une définition, une unité, un horodatage et un comportement en cas de donnée manquante.
• Les résultats sont rattachés à une version immuable.
• Les hypothèses de backtest et de production peuvent être comparées ligne par ligne.
• Les exceptions conduisent à des états sûrs et observables.
• Les limites sont rattachées au risque, à la capacité ou à l’usage prévu, et non à des nombres décoratifs.
• Toute modification substantielle rouvre les vérifications concernées.

La spécification n’élimine pas le risque de modèle. Elle rend néanmoins les choix visibles et permet de distinguer une erreur de recherche d’une erreur de mise en œuvre ou d’utilisation.

Références

• Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners — objectif, techniques de validation, benchmarking, stress et documentation.
• Federal Reserve, SR 26-2 — Revised Guidance on Model Risk Management — principes actuels de développement, d’utilisation, de validation, de gouvernance et de suivi dans le périmètre bancaire supervisé.
• U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets — contexte institutionnel des algorithmes de décision et d’exécution et des risques associés.
• National Futures Association, Interpretive Notice 9025 — Hypothetical Results — limites des résultats hypothétiques et importance des hypothèses, de la liquidité, du slippage et du comportement ; application limitée à son propre périmètre.

Liens connexes

• Trading systématique : stratégies, backtests et validation
• Trading quantitatif et trading systématique
• Backtest
• Données point-in-time
• Suivi et suspension d’une stratégie