Sur-apprentissage, sous-apprentissage et le piège de l'évaluation

Le piège le plus fréquent en Machine Learning

Un modèle qui obtient d’excellents résultats sur les données qu’on lui a montrées pendant l’entraînement peut pourtant échouer complètement face à de nouvelles données. Ce piège porte un nom : le sur-apprentissage (overfitting).

Sous-apprentissage vs sur-apprentissage

	Sous-apprentissage (underfitting)	Ajustement correct	Sur-apprentissage (overfitting)
Ce qui se passe	Le modèle est trop simple pour capturer la logique des données	Le modèle capture la vraie tendance	Le modèle mémorise le bruit et les particularités des exemples d’entraînement
Performance à l’entraînement	Faible	Bonne	Excellente (voire parfaite)
Performance sur de nouvelles données	Faible	Bonne	Mauvaise, souvent bien pire qu’attendu
Analogie	Un élève qui n’a pas révisé	Un élève qui a compris le cours	Un élève qui a appris le corrigé par cœur, sans comprendre

Un modèle de sur-apprentissage n’est pas « meilleur » parce qu’il obtient 99,9 % de bonnes réponses sur les données d’entraînement : il a simplement mémorisé ces exemples précis, y compris leurs erreurs de mesure et leurs particularités non généralisables.

La règle d’or : ne jamais évaluer un modèle sur ce qu’il a appris

Pour détecter le sur-apprentissage, on ne dispose que d’un seul outil fiable : évaluer le modèle sur des données qu’il n’a jamais vues pendant l’entraînement.

C’est pourquoi tout projet de Machine Learning commence par diviser les données disponibles en (au minimum) deux ensembles :

Jeu d’entraînement (train set) : utilisé pour ajuster les paramètres du modèle.
Jeu de test (test set) : mis de côté, utilisé uniquement à la fin pour mesurer la performance réelle.

Une proportion courante est 80 % pour l’entraînement et 20 % pour le test. Cette séparation doit être faite avant toute autre étape (nettoyage, normalisation) qui pourrait, même involontairement, laisser une information du jeu de test « fuiter » vers l’entraînement — un phénomène appelé fuite de données (data leakage), qui donnera l’illusion trompeuse d’un modèle performant alors qu’il ne l’est pas.

Ce principe reviendra constamment dans ce cours : chaque module qui entraîne un modèle rappelle explicitement à quel moment la séparation train/test intervient, et pourquoi.

Comment mesurer qu’un modèle est bon ?

La métrique à utiliser dépend de la nature du problème.

En régression (prédire une quantité)

MAE (Mean Absolute Error) : la moyenne des écarts absolus entre prédiction et réalité. Facile à interpréter (« le modèle se trompe en moyenne de 3,2 unités »).
MSE (Mean Squared Error) : la moyenne des écarts au carré. Pénalise davantage les grosses erreurs qu’un ensemble de petites erreurs.
R² (coefficient de détermination) : la proportion de variance expliquée par le modèle, entre 0 (le modèle n’apprend rien) et 1 (prédiction parfaite).

En classification (prédire une catégorie)

Accuracy (exactitude) : la proportion de prédictions correctes. Trompeuse sur des classes déséquilibrées (un modèle qui prédit toujours « non malade » sur une maladie touchant 1 % de la population a 99 % d’exactitude, sans aucune utilité).
Matrice de confusion : un tableau croisant prédictions et réalité, qui distingue les faux positifs des faux négatifs — deux types d’erreurs souvent très différents en conséquence (rater un cas de fraude n’a pas le même coût qu’alerter à tort sur une transaction légitime).
Precision / Recall / F1-score : des métriques dérivées de la matrice de confusion, particulièrement utiles quand les classes sont déséquilibrées.

La baseline : le réflexe indispensable

Avant de juger qu’un score est « bon », il faut le comparer à une baseline : la performance d’une règle triviale (toujours prédire la classe la plus fréquente, ou la moyenne globale). Un modèle à 85 % d’exactitude n’est intéressant que s’il bat une baseline qui, elle, obtiendrait par exemple 80 % simplement en prédisant toujours la classe majoritaire.

Ce réflexe (métrique + baseline de comparaison) sera systématiquement appliqué dans les modules 3, 4, 6, 7 et 8 de ce cours.

Prochaine étape

Ce module 1 pose le vocabulaire commun. Passons maintenant à la pratique avec un premier outil indispensable à tout data scientist : le SQL.

👉 Module 2 : SQL pour l’analyse de données

Junior TSAFACK – 12/09/2026