La validation des données OHLC avant backtesting est une étape critique qui consiste à vérifier la cohérence mathématique (High supérieur ou égal à Open, Low et Close ; Low inférieur ou égal à Open, High et Close), l'absence de gaps et la fiabilité temporelle de chaque barre historique. Sans cette vérification préalable, un backtest peut afficher des résultats excellents qui ne se reproduiront jamais en trading réel, conduisant à des décisions de capital basées sur une performance fictive.
Pourquoi la qualité des données est critique en backtesting
Garbage in, garbage out : le principe fondamental
En finance quantitative, le principe "garbage in, garbage out" est fondamental : si vous alimentez votre système de backtesting avec des données corrompues, il vous retournera des résultats corrompus. Un backtest, même parfaitement codé, ne peut pas compenser des données sources défectueuses.
Selon l'AMF (Autorité des Marchés Financiers), entre 74 % et 89 % des comptes de clients retail perdent de l'argent lors d'opérations sur les CFD et le Forex. Une part significative de ces pertes provient d'une mauvaise évaluation des stratégies en amont, souvent liée à des backtests construits sur des données de qualité insuffisante.
Concrètement, une donnée erronée dans vos séries OHLC peut provoquer :
- Un signal d'achat ou de vente déclenché sur un prix impossible (par exemple un Low supérieur au High)
- Un drawdown maximal sous-estimé, parce qu'une barre de grande amplitude a été supprimée du dataset
- Un ratio de Sharpe gonflé artificiellement par l'absence de volatilité sur certaines périodes
Le piège du backtest parfait
Un backtest affichant 95 % de trades gagnants sur 5 ans doit éveiller vos soupçons. Avant de chercher une erreur dans votre logique de stratégie, auditez l'intégrité de vos données OHLC. La performance parfaite est presque toujours un artefact de données.
Les 3 types d'erreurs de données OHLC les plus courants
Les données OHLC peuvent être corrompues de trois façons principales, chacune ayant un impact différent sur les résultats de votre backtest.
| Type d'erreur | Description | Impact sur le backtest |
|---|---|---|
| Incohérence OHLC | Low supérieur à High, Close supérieur à High ou Close inférieur à Low | Signaux impossibles, trades sur des prix qui n'ont jamais existé |
| Gaps et barres manquantes | Absence de barres pendant les heures de marché ouvertes (pannes, erreurs d'export) | Sous-estimation du drawdown, sauts de prix irréalistes entre barres |
| Doublons et timestamps erronés | Deux barres avec le même horodatage ou barres dans le désordre chronologique | Calcul erroné de tous les indicateurs, résultats non reproductibles |
Valider les données OHLC : checklist complète
Vérifier la cohérence OHLC
La première vérification est mathématique et doit être appliquée barre par barre. Pour chaque barre, les conditions suivantes doivent être vraies sans exception.
Vérifier High >= max(Open, Low, Close)
Vérifier Low <= min(Open, High, Close)
Vérifier l'absence de valeurs nulles ou négatives
Vérifier le volume si disponible
Détecter les gaps et barres manquantes
Un gap de données n'est pas forcément une erreur : les marchés Forex ferment le week-end, les actions ont des jours fériés. Le problème survient quand une barre est absente pendant les heures d'ouverture normales du marché.
Pour détecter les gaps, calculez la différence temporelle entre chaque barre consécutive et comparez-la à votre timeframe attendu. Sur un graphique H1, toute différence supérieure à 3 600 secondes pendant une session active (hors clôtures connues) signale un gap potentiel.
Gaps légitimes vs gaps anormaux
Sur le Forex, les gaps du week-end (vendredi 22h - dimanche 22h UTC) sont normaux et attendus. Sur les futures S&P 500 (CME), les données 23h/5 ont des interruptions de maintenance nocturne de 60 minutes. Toute autre interruption mérite vérification avant d'inclure la période dans votre backtest.
Identifier les doublons et anomalies
Un doublon est une barre dont le timestamp apparaît deux fois dans la série temporelle. Selon l'ESMA (European Securities and Markets Authority), MiFID II impose aux plateformes de reporting un horodatage précis à la microseconde pour toutes les transactions. Malgré ce cadre réglementaire strict, les sources de données historiques gratuites contiennent fréquemment des doublons, surtout sur les données ajustées pour les splits ou les dividendes d'actions.
Vérifier l'alignement temporel
Vos données doivent être dans un fuseau horaire cohérent et documenté. Un décalage d'une heure (par exemple un changement d'heure non géré dans les données) peut désynchroniser vos sessions de marché et créer des signaux fictifs sur les ouvertures de sessions Londres ou New York, où une grande partie de la volatilité journalière se concentre.
Le repainting : l'ennemi du backtesting réaliste
Définition et exemples concrets
Le repainting est la modification rétroactive des valeurs passées d'un indicateur. En backtesting, cela signifie que l'indicateur utilise des données futures pour calculer ses valeurs passées, créant une illusion de performance excellente qui est impossible à reproduire en trading réel.
Exemple concret : un indicateur calculant le "plus haut des 20 dernières barres" avec close[0] (barre courante non fermée) change de valeur à chaque nouvelle bougie. En backtest, vous voyez la valeur finale figée, mais en réel vous auriez vu chaque valeur intermédiaire. La règle anti-repainting est d'utiliser systématiquement close[1] (barre confirmée précédente) pour tout calcul conditionnel.
Pour approfondir ce sujet, consultez notre guide sur les erreurs de backtesting à éviter.
Comment détecter le repainting dans vos données
Pour détecter si un indicateur repaint, la méthode la plus fiable est le test comparatif temps réel vs rétrospectif :
- Notez les signaux donnés par l'indicateur en temps réel pendant 2 à 4 semaines
- Comparez avec les signaux que l'indicateur affiche rétrospectivement sur la même période
- Si les signaux rétroactifs diffèrent des signaux observés en temps réel, l'indicateur repaint
Indicateurs connus pour repaint
Anti-repainting natif sur Backtrex
Backtrex impose nativement la règle anti-repainting : tous les blocs de stratégie utilisent exclusivement les données de la barre précédente confirmée. C'est une garantie technique intégrée à la plateforme, pas une convention de codage. Découvrez les détails sur la page anti-repainting.
Sources de données fiables pour le backtesting
Données gratuites vs payantes
Le choix de votre source de données OHLC est aussi important que la logique de votre stratégie. Les sources gratuites peuvent suffire pour des analyses préliminaires, mais présentent des limites documentées en termes de qualité, de complétude et de précision des timestamps.
| Source | Type de données | Qualité OHLC | Profondeur historique | Coût |
|---|---|---|---|---|
| TradingView | Agrégée multi-sources | Bonne (marchés liquides) | 5 à 15 ans selon l'actif | Gratuit / Premium |
| Yahoo Finance | Ajustée dividendes et splits | Correcte (risque doublons sur splits) | 20 à 30 ans (actions) | Gratuit |
| Dukascopy | Tick avec timestamp microseconde | Excellente | 10 à 15 ans Forex/CFD | Gratuit |
| Refinitiv (LSEG) | Institutionnelle normalisée | Référence de marché | 40 ans et plus | Payant (institutionnel) |
| TickData | Institutionnelle validée | Excellente | 30 ans et plus | Payant |
Comparatif des sources : TradingView, Yahoo Finance, Dukascopy
TradingView agrège les données de plusieurs fournisseurs (bourses directes, Quandl, Trading Economics). La qualité est généralement satisfaisante pour les marchés liquides (Forex majeurs, indices, crypto). L'accès API aux données historiques longues est réservé aux abonnés Premium.
Yahoo Finance est une source populaire pour les actions, notamment via la bibliothèque Python yfinance. Son principal problème est l'ajustement des données pour les splits et dividendes : des erreurs d'ajustement rétroactif introduisent régulièrement des barres incohérentes, avec un Close ajusté supérieur au High non ajusté sur certaines périodes.
Dukascopy propose des données tick gratuites avec une précision à la milliseconde pour plus de 700 instruments Forex et CFD. C'est souvent la meilleure option gratuite pour le Forex intraday. Les données sont exportables en CSV avec timestamps UTC précis, ce qui facilite la validation temporelle.
Critères de sélection
Avant d'importer une source de données dans votre workflow de backtesting, vérifiez ces quatre points fondamentaux.
Automatiser la validation des données
Backtrex : validation automatique OHLC intégrée
Backtrex intègre nativement une couche de validation OHLC avant chaque backtest. Avant de lancer le calcul de votre stratégie, la plateforme vérifie automatiquement la cohérence mathématique de chaque barre (High, Low, Open, Close), détecte et signale les gaps anormaux sur la période sélectionnée, applique la règle anti-repainting sur tous les blocs de stratégie, et rejette toute donnée corrompue avec un rapport d'erreur détaillé.
Cette automatisation est particulièrement précieuse pour les traders no-code qui ne souhaitent pas écrire des scripts de validation Python ou Pine Script. La page backtest de Backtrex détaille l'ensemble des garanties techniques offertes par la plateforme. Pour comparer avec d'autres approches de validation, consultez notre article sur l'overfitting et le surapprentissage en backtesting.
Backtest sans surprise
Backtrex garantit que vos résultats sont basés sur des données OHLC validées et sans repainting. C'est la seule façon de comparer honnêtement la performance de votre stratégie aux conditions réelles de marché. Voir les formules et tarifs.
Outils pour les traders code
Si vous préférez valider vos données manuellement avant de les importer dans un logiciel de backtesting, les bibliothèques Python pandas et numpy permettent de vérifier la cohérence OHLC en quelques lignes de code. Pour Pine Script sur TradingView, vous pouvez ajouter des assertions sur high >= close et low <= close au début de votre script pour signaler toute barre corrompue en temps réel.
Notre guide sur le backtesting vs forward testing explique comment compléter votre processus de validation en conditions réelles une fois vos données OHLC auditées.
Important Risk Warning
Conclusion
La qualité des données OHLC est le fondement invisible de tout backtest fiable. Une vérification systématique de la cohérence mathématique, des gaps, des doublons et de l'alignement temporel est indispensable avant d'interpréter le moindre résultat. Le repainting reste la menace la plus sournoise : invisible dans les logs de données, il est dévastateur pour la fiabilité de vos signaux et conduit à des stratégies qui paraissent excellentes en backtest mais échouent immédiatement en réel.
Que vous validiez manuellement vos données avec Python ou que vous utilisiez une plateforme comme Backtrex qui automatise ces vérifications, l'essentiel est de ne jamais prendre un backtest pour argent comptant sans avoir d'abord audité ses données sources. Explorez également notre page features pour découvrir comment Backtrex adresse ces problèmes de façon systématique.
Les données OHLC (Open, High, Low, Close) représentent les prix d'ouverture, le plus haut, le plus bas et de clôture d'une barre de temps donnée. En backtesting, elles constituent la matière première de toute simulation : chaque signal d'achat ou de vente est calculé à partir de ces quatre valeurs. Une barre OHLC valide doit respecter High supérieur ou égal à Open, Low et Close, et Low inférieur ou égal à Open, High et Close. Toute barre violant cette règle est corrompue et doit être exclue avant le calcul.
La vérification se fait en quatre étapes principales : (1) contrôle de la cohérence mathématique (High supérieur ou égal à max(Open, Low, Close), Low inférieur ou égal à min(Open, High, Close)) ; (2) détection des gaps anormaux en comparant les timestamps consécutifs avec le timeframe attendu ; (3) recherche de doublons par timestamps identiques dans la série ; (4) vérification de l'alignement temporel et du fuseau horaire. Des plateformes comme Backtrex automatisent ces vérifications avant chaque backtest.
Le repainting est la modification rétroactive des valeurs passées d'un indicateur. Un indicateur qui repaint affiche en backtest des signaux parfaits sur des barres historiques, mais ces signaux n'auraient pas été disponibles en temps réel à ce moment précis. Résultat : une performance historique artificielle, impossible à reproduire en conditions réelles. La solution est d'utiliser systématiquement les données de la barre précédente confirmée (close[1]) et non de la barre courante non fermée (close[0]).
Pour le Forex et les CFD, Dukascopy offre des données tick gratuites avec une précision à la milliseconde pour plus de 700 instruments. Pour les actions, Yahoo Finance couvre 20 à 30 ans d'historique mais requiert une vérification des ajustements de splits. TradingView propose des données de bonne qualité pour les marchés liquides, avec un accès API étendu en version Premium. Pour un usage professionnel, Refinitiv (LSEG) ou TickData sont les références institutionnelles.
Trois signaux d'alerte principaux : (1) des barres où High est inférieur à Close ou Open, ou Low est supérieur à Close ou Open ; (2) des sauts de prix brutaux incohérents avec la volatilité habituelle de l'actif (souvent un artefact d'ajustement de dividende mal géré) ; (3) des timestamps dupliqués ou dans le désordre chronologique. Un script de validation simple en Python peut détecter ces anomalies en quelques secondes sur plusieurs années de données historiques.
Cela dépend de votre stratégie. Les stratégies swing basées sur des signaux de clôture quotidienne fonctionnent bien avec des données journalières. Les stratégies intraday, scalping ou basées sur des sessions de marché spécifiques (London, New York) nécessitent des données en timeframe M1 à H1 minimum. Avec des données journalières, vous ne pouvez pas modéliser les spreads intraday, les stop hunts ou les variations de prix à l'intérieur des barres.
Oui. Backtrex intègre une couche de validation OHLC native qui vérifie la cohérence mathématique de chaque barre, détecte les gaps anormaux et applique automatiquement la règle anti-repainting sur tous les blocs de stratégie. Si une donnée corrompue est détectée, la plateforme l'indique clairement avant de lancer le calcul, ce qui évite d'interpréter des résultats basés sur des données défectueuses.