Séparation Apprentissage / Test

Vous entraînez un modèle sur des données, il affiche 98% de précision, et en production il ne vaut rien. Vous venez de frapper le mur du surapprentissage — et vous auriez pu le voir venir si vous aviez séparé vos données en apprentissage et test.

La séparation apprentissage/test est la plus simple et la plus critique des techniques de validation en machine learning. Elle repose sur une intuition élémentaire : vous ne pouvez pas tester un modèle sur les mêmes données qui l’ont entraîné, pas plus qu’un professeur ne peut évaluer la compréhension d’un étudiant en lui redonnant exactement les mêmes exercices d’entraînement.

L’analogie du cursus universitaire

Pendant un semestre, l’étudiant étudie les notes de cours, fait les exercices fournis, ajuste sa compréhension. Le modèle qu’il construit mentalement s’affine via cette répétition. Arrive l’examen final : des problèmes inédits, jamais vus avant. Cet examen mesure la vraie capacité de généralisation — peut-il appliquer les principes à des situations nouvelles ?

La distinction est structurellement identique à celle du train-test split. L’ensemble d’entraînement (training set) est le semestre : le modèle y apprend les patterns. L’ensemble de test (test set) est l’examen final inédit : il mesure si ce qui a été appris se transfère réellement.

Un étudiant qui mémorise les corrections des anciens examens sans vraiment comprendre réussira parfaitement les anciens exams (overfitting), mais échouera l’examen final. Parallèlement, un modèle qui mémorise les détails spécifiques du training set — certains expéditeurs de spam, des pixels de bruit dans les images — affichera une précision parfaite en train mais s’écroulera en test.

Pourquoi cette séparation est non-négociable

Trois raisons pragmatiques :

Diagnostic du biais d’évaluation. Un modèle testé sur ses données d’entraînement produit une estimation irréalistement optimiste de sa performance réelle. Il a “vu” ces données, qu’il s’agisse explicitement ou via le bruit. Le test set, constitué d’observations jamais rencontrées, force une séparation logique et temporelle.

Détection immédiate du surapprentissage. Comparez les performances en train et en test. Si vous voyez train_accuracy = 99% et test_accuracy = 72%, le diagnostic saute aux yeux : votre modèle a mémorisé plutôt que généraliser. Cet écart est votre signal d’alarme pour réduire la complexité, augmenter la régularisation, ou collecter plus de données variées.

Estimation non biaisée de la capacité de généralisation. L’erreur calculée sur l’ensemble de test fournit un proxy fiable de la performance future sur des données réelles inédites — le seul métrique qui compte vraiment en production.

Astuce

Règle d’or : test set = données jamais touchées pendant l’entraînement. Aucun label du test set ne doit influer directement ou indirectement sur l’optimisation des paramètres du modèle.

Comment mettre en œuvre le train-test split

1. Charger et explorer les données complètes. Analyser la distribution des classes (équilibrées ou déséquilibrées ?), les types de features, les valeurs manquantes. Cette étape diagnostique la stratégie appropriée.

2. Choisir la proportion. La convention est 80% entraînement / 20% test. Avec des données massives (> 1M exemples), 90/10 est justifié. Avec très peu de données (< 1,000), 70/30 augmente la taille du test set pour plus de signal. Le trade-off : un test set plus grand réduit le bruit d’estimation mais affame l’entraînement.

3. Décider du type de split. Trois approches courantes :

   • Simple split aléatoire : rapide, bon pour données homogènes et abondantes.
   • Stratified split : essentiel si les classes sont déséquilibrées. Force chaque ensemble à conserver les proportions de classes du dataset original.
   • Temporal split : obligatoire pour séries temporelles. Train = passé, test = futur chronologiquement. Un split aléatoire créerait une fuite d’information.

4. Fixer la graine (seed) aléatoire. Initialiser random_state=42 dans scikit-learn pour reproductibilité. Documenter ce choix. Plus tard, tester plusieurs seeds pour vérifier la stabilité des conclusions.

5. Partitionner. Appeler train_test_split(X, y, test_size=0.2, stratify=y, random_state=42). Récupérer quatre objets : X_train, X_test, y_train, y_test.

6. Prétraiter sur training set UNIQUEMENT. Calculer les statistiques de normalisation (moyenne, écart-type) sur X_train. Appliquer ces statistiques à X_test. Ceci élimine la fuite d’information (data leakage) — une erreur commune où on contamine le test set avec des propriétés statistiques du training set.

7. Entraîner le modèle. model.fit(X_train, y_train). Le test set ne participe pas.

8. Évaluer en train et test. Calculer les mêmes métriques sur les deux ensembles pour comparaison directe.

9. Diagnostiquer. Si train >> test : overfitting. Si train ≈ test et bas : underfitting. Si train > test avec écart raisonnable : situation saine.

Sous le capot : stratification et validation croisée

Pour les classes déséquilibrées (ex : 95% clients restants, 5% churn), un split aléatoire peut créer 4.2% de churn en train et 6.1% en test. La stratification force exactement 5% dans chaque ensemble en partitionnant au sein de chaque classe avant la répartition.

Quand les données sont limitées, le train-test split simple dépend trop du seed aléatoire. La solution : validation croisée k-fold. Partitionner les données en k plis (typ. k=5). Pour chaque pli i, l’ensemble i devient test set et les k-1 autres ensemble train set. Répéter k fois. Calculer k scores, puis moyenne et écart-type. Cette approche réduit la dépendance au hasard et fournit une estimation plus robuste.

Cas extrême de rigueur : trois ensembles (60% train, 20% validation, 20% test). Train optimise les paramètres. Validation ajuste les hyperparamètres (learning rate, profondeur d’arbre, regularization). Test final évalue sans biais. Ceci élimine un piège subtil : si vous utilisez le même test set pour la sélection d’hyperparamètres, vous overfittez indirectement sur ce test set.

Note

Data leakage : Appliquer le preprocessing au dataset entier avant le split est une erreur classique. Ordre correct : split → preprocessing sur train uniquement → appliquer sur test.

Exemples concrets

Classification binaire (spam detection) : 10,000 emails classés manuellement. Split 80/20 → 8,000 entraînement, 2,000 test. Naive Bayes atteint 98% accuracy en train, 72% en test. Verdict : overfitting massif. Le modèle a mémorisé certains expéditeurs spécifiques du training set. Solution : réduire la complexité, augmenter la régularisation L2, ou collecter plus de données variées.

Régression (prix immobiliers) : 1,000 maisons. Split 70/30 → MSE train = 15,000, MSE test = 58,000. L’écart révèle overfitting. Correction : validation croisée 5-fold pour estimation plus stable, ou stratified split garantissant une distribution représentative de prix dans chaque fold.

Reconnaissance de chiffres (MNIST) : 70,000 images. Split standard 60/10,000 : CNN atteint 99.5% accuracy en test. Ce score élevé est crédible car le test set est intrinsèquement difficile — images jamais vues, variations naturelles de l’écriture.

Danger

Piège courant : contamination par le seed. Si vous testez 10 modèles sur le même split 80/20 et choisissez le meilleur basé sur son score test, vous avez indirectement “entraîné” sur ce test set. Chaque modèle candidat devient une hypothèse, et vous sélectionnez celle qui performe le mieux sur vos données de test. Solution : k-fold cross-validation imbriquée ou un troisième ensemble de validation complètement séparé.

Controverses et limites

Le choix de la proportion test_size = 20% est historique, non universel. Avec données massives, 10% suffit. Avec données restreintes, 40% est justifié.

Un problème réel : si les données réelles en production dérivent (distribution shift), un modèle avec bon test set score s’écroule en production. Le train-test split suppose que train et test proviennent de la même distribution — une hypothèse souvent violée en pratique. Des champs entiers (domain adaptation, continual learning) adressent cette limite.

Pour séries temporelles, le split aléatoire standard crée une fuite temporelle. Le test set peut contenir des observations antérieures au train set chronologiquement, faussant l’évaluation. Seul le temporal split (passé → futur) est correct.

---

Notions liées

• Cross-Validation
• Overfitting et Underfitting
• Regularisation
• Hyperparameter Tuning
• Validation Croisée

Sources & Références

• DataScienceTest — Train-Test Split Tutoriel : explication détaillée de train_test_split() de scikit-learn, diagnostic d’overfitting/underfitting via comparaison train/test, rôle du seed et reproductibilité.
• Innovatiana — Techniques d’évaluation des modèles ML : séparation train-test comme méthode rapide, biais potentiels, importance de la représentativité pour mesurer la généralisation.
• mzuer.github.io — Data split (train, test, validation) : architecture à trois ensembles, ratios typiques, validation croisée k-fold, distinction sélection vs. évaluation.
• Google Developers — ML Crash Course : ensembles d’entraînement, validation et test, caractéristiques d’un bon test set (représentatif, non-chevauchant, statistiquement pertinent).
• Nexa.fr — Qu’est-ce que le train-test-split : rôle fondamental, impact sur la performance, importance méthodologique en ML.
• OpenClassrooms — Séparation apprentissage-test cohérente : pièges des débutants, ajustements stratégiques, importance de la cohérence méthodologique.
• DataCamp — Séparation apprentissage/test et calcul de précision : implémentation avec scikit-learn, paramètres test_size et random_state, métriques sur test set.
• Saagie — Machine learning : comment évaluer vos modèles : stratégies d’évaluation globales, métriques, rôle du train-test split dans l’évaluation ML plus large.