Accueil › Glossaire › Test Set

Test Set

Le test set (ou jeu de test) est le sous-ensemble de données réservé exclusivement à l’évaluation finale de la performance d’un modèle de machine learning, sur des exemples qu’il n’a jamais vus pendant l’entraînement ni pendant le réglage des hyperparamètres.

Le test set est l’examen final du modèle. C’est la seule mesure fiable de sa capacité à généraliser à des données réelles. Utiliser le test set pour prendre des décisions de conception (choix d’architecture, réglage d’hyperparamètres) revient à donner les réponses de l’examen à l’étudiant avant l’épreuve : la note sera flatteuse mais ne reflétera pas ses compétences réelles. La discipline d’un test set inviolé est ce qui sépare une évaluation rigoureuse d’un résultat trompeur.

Pourquoi le test set est indispensable

Un modèle de machine learning peut atteindre 99% de précision sur ses données d’entraînement et échouer lamentablement en production. Ce phénomène s’appelle l’overfitting : le modèle a mémorisé les données d’entraînement au lieu d’apprendre des patterns généralisables. Le test set existe pour détecter ce problème.

Concrètement, le test set simule les conditions réelles d’utilisation. Si votre modèle obtient de bonnes performances sur le test set (des données qu’il n’a jamais vues), vous avez une estimation fiable de sa performance en production. Si les performances sont nettement inférieures à celles du training set, c’est un signal d’overfitting.

Le principe fondamental : le test set est un proxy du monde réel. Plus il ressemble aux données que le modèle rencontrera en production, plus l’évaluation est pertinente.

Test set vs validation set : la distinction critique

C’est la confusion la plus courante chez les débutants, et elle a des conséquences réelles sur la fiabilité des résultats.

Le validation set est votre « miroir » pendant le développement : vous l’utilisez pour comparer des configurations, tester des hypothèses et guider vos choix. Mais à force d’optimiser pour le validation set, vous finissez par sur-ajuster vos choix à ce set spécifique. Le test set, lui, n’a jamais été vu ni directement ni indirectement par le modèle. C’est la seule estimation non biaisée de la performance réelle.

Comment construire un bon test set

Quelle taille ?

La taille du test set est un compromis. Trop petit, il ne sera pas statistiquement significatif (les résultats varieront beaucoup selon les exemples choisis). Trop grand, vous amputez le training set d’exemples précieux. Les ratios courants sont :

Grand dataset (>100 000 exemples). Un split 80/10/10 ou même 90/5/5 suffit. Avec 100 000 exemples, un test set de 10 000 est largement significatif.

Dataset moyen (1 000 à 100 000 exemples). Un split 70/15/15 ou 80/10/10 est standard.

Petit dataset (<1 000 exemples). Le test set risque d’être trop petit pour être représentatif. Utilisez plutôt la validation croisée (k-fold cross-validation) qui maximise l’utilisation des données disponibles.

Représentativité

Le test set doit être un échantillon représentatif de la population réelle. S’il ne l’est pas, votre évaluation sera biaisée. Deux conditions doivent être remplies :

Même distribution que la production. Si 30% de vos utilisateurs en production sont francophones, environ 30% de votre test set devrait l’être aussi. Si certaines classes sont rares (détection de fraude), le test set doit contenir suffisamment d’exemples de chaque classe pour que les métriques soient significatives.

Échantillonnage stratifié. Lors du split, utilisez un échantillonnage stratifié qui préserve la proportion de chaque classe dans chaque sous-ensemble. En Python avec scikit-learn : train_test_split(X, y, test_size=0.2, stratify=y). Sans stratification, un petit test set pourrait contenir 0 exemples d’une classe rare, rendant l’évaluation de cette classe impossible.

Cas des données temporelles

Pour les séries temporelles (prévisions financières, météo, trafic), le split aléatoire est interdit. Les données ont un ordre chronologique, et le modèle ne doit pas « voir le futur » pendant l’entraînement. La règle : entraînement sur les données passées, test sur les données futures. Par exemple, pour des données mensuelles de 2020 à 2026 : training sur 2020-2024, validation sur janvier-juin 2025, test sur juillet 2025-mars 2026.

Cas des données groupées

Si vos données contiennent des groupes naturels (plusieurs images du même patient, plusieurs achats du même client), le split doit se faire au niveau du groupe, pas de l’exemple individuel. Si des images du même patient se retrouvent dans le train ET le test, le modèle peut exploiter des caractéristiques spécifiques au patient (grain d’image, appareil de scan) plutôt que des features médicales pertinentes. C’est une forme insidieuse de data leakage.

Métriques d’évaluation sur le test set

Les métriques à calculer dépendent de la tâche. Voici les plus courantes.

Quand utiliser la validation croisée (k-fold)

Sur les petits datasets, un test set fixe de 100 ou 200 exemples produit une estimation bruitée : le résultat dépend fortement de quels exemples ont été sélectionnés. La validation croisée k-fold résout ce problème.

Le principe : divisez le dataset en k parties (folds) de taille égale. Entraînez k modèles, chacun en utilisant k-1 folds pour l’entraînement et le fold restant comme test. La performance finale est la moyenne des k évaluations. Typiquement, k = 5 ou k = 10.

from sklearn.model_selection import cross_val_score
from sklearn.ensemble import RandomForestClassifier

model = RandomForestClassifier(n_estimators=100)

# Validation croisée 5-fold avec stratification
scores = cross_val_score(
    model, X, y,
    cv=5,               # 5 folds
    scoring='f1_macro'   # Métrique choisie
)

print(f"F1 moyen : {scores.mean():.3f} ± {scores.std():.3f}")

Avantages : chaque exemple est utilisé exactement une fois comme test, ce qui maximise l’utilisation des données et produit une estimation plus stable. Inconvénient : k fois plus coûteux en temps de calcul, car vous entraînez k modèles au lieu d’un seul.

Le test set dans les benchmarks de LLM

Dans le monde des grands modèles de langage, les benchmarks standardisés (MMLU, GPQA, HumanEval, ARC-AGI-2) jouent le rôle de test sets partagés par toute la communauté. Chaque benchmark est un dataset de test conçu pour évaluer une capacité spécifique : raisonnement, codage, connaissances factuelles, mathématiques.

Le problème majeur : la contamination des benchmarks. Si les données du test set se retrouvent dans le corpus de pré-entraînement du LLM (ce qui arrive quand les benchmarks sont publiés sur le web), le modèle a « déjà vu les réponses ». Les scores sont alors artificiellement gonflés et ne reflètent pas les capacités réelles. C’est l’équivalent du data leakage à l’échelle de l’industrie. La communauté crée régulièrement de nouveaux benchmarks pour contourner ce problème, mais c’est une course sans fin.

Des initiatives comme les leaderboards dynamiques (ex: LMSYS Chatbot Arena) contournent ce problème en utilisant des évaluations humaines en temps réel plutôt que des test sets fixes.

Erreurs fréquentes

Utiliser le test set pour choisir le modèle. Si vous comparez 10 architectures et choisissez celle qui performe le mieux sur le test set, vous optimisez indirectement pour le test set. Le résultat publié sera biaisé. Utilisez le validation set pour les comparaisons, et le test set uniquement pour le modèle final sélectionné.

« Jeter un œil » au test set. Même regarder les données du test set (sans les utiliser explicitement) peut influencer inconsciemment vos décisions. C’est la version ML du biais de confirmation. La meilleure pratique de Stanford : « Don’t look at the test set! ».

Utiliser le test set plusieurs fois. Chaque utilisation supplémentaire du test set augmente le risque de sur-ajustement aux particularités de ce set spécifique. Si vous devez itérer, itérez sur le validation set. Le test set est réservé à la toute fin.

Oublier la stratification. Un split aléatoire non stratifié peut produire un test set qui ne contient aucun exemple d’une classe rare. Résultat : vous ne savez rien de la performance du modèle sur cette classe. Utilisez toujours un split stratifié pour les tâches de classification.

Normaliser avant de splitter. Si vous calculez la moyenne et la variance sur l’ensemble du dataset avant de séparer train et test, les statistiques du test set polluent le training set. Splittez d’abord, normalisez ensuite (en utilisant uniquement les statistiques du training set).

Ignorer les barres d’erreur. Un F1-score de 0,85 sur un test set de 50 exemples est beaucoup moins fiable qu’un F1 de 0,83 sur un test set de 10 000 exemples. Rapportez toujours les intervalles de confiance ou les écarts-types, en particulier pour les petits test sets.

Bonnes pratiques

Séparez le test set dès le début et ne le touchez plus. Créez le split train/validation/test au tout début du projet et mettez le test set de côté. Ne le consultez pas, ne le statistiquez pas, ne l’utilisez pas pour prendre des décisions. Considérez-le comme un fichier scellé.

Assurez-vous de la représentativité. Le test set doit refléter les conditions réelles d’utilisation. Si votre modèle sera déployé sur des données bruitées, le test set doit contenir du bruit. Si les données de production proviennent de sources variées, le test set doit aussi.

Rapportez des métriques multiples. Ne vous limitez pas à l’accuracy. Rapportez la precision, le recall, le F1-score par classe, et la matrice de confusion. Pour les datasets déséquilibrés, l’AUC-ROC est plus informative que l’accuracy globale.

Rapportez les barres d’erreur. Utilisez le bootstrapping ou la validation croisée pour estimer la variance de vos métriques. Un résultat sans intervalle de confiance est un résultat incomplet.

Évaluez par sous-groupes. Au-delà de la performance globale, évaluez votre modèle sur des sous-populations pertinentes (par genre, par tranche d’âge, par région). Un modèle qui performe bien en moyenne mais échoue sur un sous-groupe spécifique peut avoir des conséquences discriminatoires en production.