Qualité des données pour le backtesting

Un résultat précis peut reposer sur des données incomplètes

Un backtest applique des règles à des observations historiques. Si ces observations contiennent des lacunes, des doublons, des horodatages incohérents ou des changements de symbole mal traités, le rapport peut sembler précis sans représenter correctement la période étudiée. La vérification doit donc commencer avant l'exécution, et non après la découverte d'un résultat séduisant.

La première question n'est pas « combien la stratégie aurait-elle rapporté ? », mais « quelles données ont alimenté le calcul et quelles en sont les limites ? ». Dans le catalogue des jeux de données, examinez la source, le marché, la granularité, la période disponible, la couverture et les lacunes connues avant de retenir un fichier pour l'étude. Vous pouvez aussi examiner les packs de données historiques crypto et Polymarket pour le backtesting lors du choix des données de l'étude.

Liste de contrôle avant d'exécuter un backtest

Consignez au minimum les éléments suivants :

Identité du jeu de données. Notez la source, la paire ou le marché, le type d'observation et la granularité. Le nom d'un actif ne suffit pas à identifier un marché ni une méthode de construction des prix.
Période demandée et période réellement disponible. Vérifiez la première et la dernière observation utilisées. Une période tronquée peut exclure, volontairement ou non, des régimes de marché importants.
Couverture et lacunes. Repérez les intervalles absents, les doublons et les séquences irrégulières. Décidez si une lacune doit interrompre l'étude, être exclue ou faire l'objet d'un traitement documenté.
Fuseau horaire et clôture des bougies. Assurez-vous que les règles interprètent les horodatages de la même façon et qu'une bougie n'est utilisée qu'une fois clôturée.
Continuité du marché. Recherchez les changements de symbole, de convention de cotation ou de source intervenus pendant la période.
Hypothèses d'exécution. Définissez le capital, les frais, le glissement, la taille des positions et le moment d'exécution avant d'ouvrir le rapport.
Traçabilité. Conservez la version des règles et l'identité du jeu de données avec le résultat afin de pouvoir reproduire le même contexte.

La méthodologie de recherche doit préciser comment la couverture et les lacunes sont calculées, quelles transformations sont appliquées et quels paramètres restent associés au rapport.

Exemple méthodique : un croisement de moyennes mobiles

Prenons une stratégie qui ouvre une position lorsque la moyenne rapide franchit la moyenne lente, puis la ferme lors du croisement inverse. Avant de lancer le calcul, définissez par écrit :

le marché, la source et la granularité des bougies ;
le moment où le croisement est considéré comme confirmé ;
le prix utilisé pour simuler l'entrée suivante ;
la manière dont les frais et le glissement sont appliqués ;
le comportement attendu lorsqu'une bougie manque au moment d'un signal ;
la règle qui limite la taille ou le risque de la position.

Consultez ensuite le parcours de backtesting explicable et examinez les entrées, les sorties et les événements proches d'une lacune, pas seulement les indicateurs agrégés. Si une transaction dépend d'une information qui n'était pas disponible au moment simulé, il existe un risque de biais d'anticipation. Si le signal disparaît lorsque l'on décale une seule observation, le résultat demande une vérification supplémentaire.

Cet exemple n'a pas besoin d'afficher un rendement pour être utile. Il sert à déterminer si les règles, les données et le modèle d'exécution forment une chaîne cohérente et reproductible.

Contrôles à effectuer après l'exécution

Une fois le calcul terminé, vérifiez :

si le nombre et la répartition temporelle des opérations correspondent au comportement attendu des règles ;
si les gains ou pertes les plus importants se concentrent autour de lacunes ou de périodes mal couvertes ;
si chaque entrée et chaque sortie peuvent être reliées à une condition identifiable ;
si les frais et le glissement sont appliqués à toutes les opérations concernées ;
si le rapport conserve la période, la version de la stratégie et les hypothèses retenues ;
si une variation raisonnable d'un paramètre suffit à inverser la conclusion.

Pour cette dernière question, l'analyse des zones robustes permet de comparer des combinaisons voisines. Elle ne démontre pas qu'une stratégie fonctionnera à l'avenir, mais elle aide à repérer un résultat isolé qui dépend trop fortement d'une valeur unique.

Limites que le backtesting ne supprime pas

Un jeu de données complet ne transforme pas une simulation en exécution réelle. Un backtest peut ignorer la liquidité, la latence, l'impact de marché, les rejets d'ordres et les changements de conditions de négociation. Il peut aussi être surajusté lorsque les règles sont modifiées à répétition pour expliquer la même période historique.

Séparez autant que possible la période utilisée pour concevoir l'idée de celle employée pour l'évaluer. Conservez les résultats défavorables, documentez les modifications et évitez de retenir un paramètre uniquement parce qu'il produit le meilleur résultat passé. Les simulations historiques ne prédisent pas les performances futures et ne constituent pas un conseil financier.

Si l'idée doit encore être transformée en conditions explicites, poursuivez avec le guide consacré à la construction visuelle de règles de trading. Une logique lisible réduit les ambiguïtés avant le premier calcul.