Surapprentissage

Le symptôme observable

Le diagnostic repose sur deux mesures comparées : l'erreur sur les données d'entraînement et l'erreur sur des données mises de côté. Tant que les deux diminuent, le modèle apprend une régularité utile. Quand l'erreur d'entraînement continue de baisser alors que l'erreur de validation remonte, le modèle mémorise du bruit au lieu de généraliser. La courbe qui se croise est le signal classique du phénomène, et elle s'observe sur presque tous les projets mal surveillés. Une courbe plate des deux côtés signale au contraire un modèle qui n'a rien appris d'utile.

Sur le terrain, le symptôme est plus concret : l'outil réussit parfaitement sur les exemples montrés pendant la mise au point et se trompe sur les dossiers suivants. Un classificateur de courriers qui atteint une excellente précision sur son jeu de test interne peut échouer dès qu'un client écrit dans un style différent ou joint une pièce inattendue. La performance affichée ne dit rien de la performance future, surtout quand le jeu de test ressemble trop au jeu d'entraînement.

Les causes fréquentes

La première cause est un modèle trop complexe pour la quantité de données disponible : il dispose de assez de paramètres pour retenir chaque exemple au lieu d'en extraire la règle. La deuxième est un entraînement trop long, qui laisse le modèle optimiser au-delà du point utile et s'enfoncer dans le bruit. La troisième est un jeu de données trop petit, peu varié ou déséquilibré, qui ne représente pas les cas réellement rencontrés en production.

Une cause plus discrète vient de la préparation des données. Si des exemples quasi identiques se retrouvent à la fois dans l'entraînement et dans la validation, la mesure est faussée et le surapprentissage passe inaperçu jusqu'au déploiement. La fuite d'information entre les deux jeux donne l'illusion d'un modèle robuste, et c'est l'une des erreurs les plus fréquentes dans les projets menés sans méthode de séparation claire. La séparation doit se faire par client, par période ou par site, selon ce que le modèle devra prédire en production.

Les remèdes

Le remède le plus simple est l'arrêt anticipé : on interrompt l'entraînement au moment où l'erreur de validation cesse de progresser. La régularisation limite la complexité effective du modèle, par exemple en pénalisant les poids ou en désactivant aléatoirement des neurones pendant l'entraînement. L'augmentation des données, qui produit des variantes plausibles des exemples, aide quand le corpus est petit, à condition que ces variantes restent réalistes pour le métier. Ces réglages se combinent mal : trop de régularisation empêche le modèle d'apprendre la règle recherchée.

La solution de fond reste l'ajout de données représentatives et une validation honnête, avec des jeux séparés et, si possible, une validation croisée. Pour un projet d'entreprise, cela signifie collecter des cas réels sur plusieurs mois, documenter les conditions de collecte et retester après chaque mise à jour. Un modèle se surveille comme un processus, pas comme un livrable figé que l'on installe une fois pour toutes. Le jeu de validation doit rester stable dans le temps, sinon les comparaisons entre versions perdent leur sens.