Nettoyer et fiabiliser ses données avant de backtester
⏱ 9 min· Intermédiaire
Un backtest est aussi fiable que les données sur lesquelles il tourne. C'est une évidence qu'on néglige pourtant souvent — un algorithme peut avoir une logique parfaitement saine, mais si les données sous-jacentes contiennent des erreurs, des doublons ou des incohérences, le backtest produira des résultats trompeurs, dans un sens comme dans l'autre.
Les problèmes de données les plus courants
Doublons de matchs — un même match importé plusieurs fois (souvent à cause de plusieurs sources ou de crons qui tournent en parallèle sans vérifier l'existant) gonfle artificiellement le volume de l'échantillon et peut biaiser les statistiques par équipe.
Scores manquants ou incohérents — un match avec un score à 0-0 par défaut alors que la donnée n'a simplement pas été récupérée, mélangé avec de vrais matchs nuls 0-0, fausse silencieusement tes statistiques sans qu'aucune erreur ne soit visible.
Fusion incorrecte d'identités d'équipes — deux clubs différents portant le même nom dans des pays différents (des dizaines d'exemples existent : plusieurs "Racing Club", plusieurs "Independiente" en Amérique du Sud) fusionnés par erreur dans une seule fiche statistique.
Changements de ligue non pris en compte — une équipe promue ou reléguée dont l'historique de l'ancienne division est mélangé avec la nouvelle sans distinction, alors que le niveau de compétition change fondamentalement le profil statistique.
Comment détecter les doublons
La méthode la plus fiable : grouper les matchs par une combinaison de champs qui devrait être unique (date, équipe domicile, équipe extérieure, score) et vérifier s'il existe des groupes avec plus d'une occurrence.
Exemple concret. Sur une base de plus d'1,3 million de matchs, un contrôle simple (regroupement par date + équipes + score, comptage des occurrences) peut révéler des dizaines de milliers de doublons — souvent dus à un script d'import qui tourne plusieurs fois par jour sans vérifier si le match existe déjà. Une fois identifiés, ces doublons se suppriment en gardant une seule occurrence par groupe, puis on ajoute une contrainte d'unicité dans la base pour empêcher que ça se reproduise.
Vérifier la cohérence des identités d'équipe
Un contrôle utile : regrouper les entrées statistiques par nom d'équipe (sans le pays), et vérifier combien de pays différents apparaissent pour un même nom. Un seul pays réel + éventuellement une étiquette générique ("compétition internationale non classée") = fusion probablement sûre. Deux vrais pays différents ou plus = attention, il s'agit probablement de deux clubs distincts qui portent le même nom, à ne surtout pas fusionner.
Une check-list avant de lancer un backtest
Vérifier l'absence de doublons sur l'échantillon de matchs utilisé.
Vérifier la cohérence des scores — pas de valeurs manquantes traitées comme des zéros par défaut, pas de scores aberrants (matchs à 15 buts qui seraient en réalité des erreurs de saisie).
Vérifier les identités d'équipe — aucune fusion abusive entre clubs homonymes de pays différents.
Vérifier la période couverte — s'assurer que l'échantillon couvre une durée suffisante et représentative (pas uniquement une saison atypique).
Documenter la source et la date d'extraction des données, pour pouvoir reproduire ou auditer le backtest plus tard.
Point méthode
Un backtest lancé sur des données non vérifiées peut donner un résultat qui semble excellent (à cause de doublons qui gonflent artificiellement un pattern) ou catastrophique (à cause d'erreurs de score isolées qui pèsent lourd sur un petit échantillon) — dans les deux cas, la conclusion tirée sera fausse. Le nettoyage des données n'est pas une étape optionnelle, c'est la fondation de tout le reste du travail.
Le temps passé à nettoyer et vérifier ses données avant de backtester n'est jamais du temps perdu — c'est souvent l'étape qui distingue un algorithme dont les résultats backtestés sont crédibles d'un algorithme dont les chiffres impressionnants ne survivront pas au contact du réel.