Un modèle peut obtenir un excellent score et décevoir dès sa mise en service. Avant de changer d’algorithme, il faut examiner ce qu’il savait au moment de son évaluation. Une information venue du futur peut transformer un exercice difficile en problème artificiellement simple.
Partir du moment de la prédiction
Imaginons un service qui veut anticiper les retards de livraison au départ du colis. La date réelle de réception ne peut pas être une variable d’entrée : elle ne sera connue qu’après l’événement. Même problème avec un statut « réclamation clôturée » enregistré plusieurs jours plus tard.
Pour chaque colonne, notez sa provenance et sa date de disponibilité. La question utile est concrète : cette valeur existerait-elle si le modèle devait répondre maintenant ? Cette revue métier précède tout calcul de score.
Apprendre les transformations au bon endroit
Une fuite peut aussi apparaître pendant la préparation des données. Les moyennes utilisées pour remplacer les valeurs manquantes, la mise à l’échelle et la sélection des variables doivent être apprises sur l’entraînement. La validation et le test reçoivent ensuite ces transformations déjà ajustées. Un pipeline permet de conserver cette séparation pendant la validation croisée. Voir les recommandations de scikit-learn sur les fuites de données.
Choisir une séparation qui ressemble à l’usage
| Situation | Séparation à examiner | Question de contrôle |
|---|---|---|
| Prédire des événements futurs | Découpage chronologique | Des informations futures ont-elles été utilisées ? |
| Généraliser à de nouveaux clients | Séparation par client | Le même client apparaît-il des deux côtés ? |
| Observations indépendantes | Découpage aléatoire adapté | Les doublons ont-ils été identifiés ? |
Ces choix ne sont pas interchangeables. La documentation de validation croisée décrit notamment les séparations par groupes et les séries temporelles.
Préparer une revue avant publication
Conservez une petite fiche avec la date de coupure, les identifiants des ensembles et les colonnes exclues. Faites relire les variables par une personne qui connaît leur production. Si une fuite est découverte, reconstruisez l’évaluation et retirez le score précédent des comparaisons : corriger seulement le code ne rend pas l’ancien résultat valide.
Pour poursuivre : créer des variables pertinentes et documenter une expérience reproductible.