Explorer un jeu de données et mesurer une performance

Temps de lecture15 min

En bref

Résumé de l’article

Un modèle d’IA n’est pas jugé par le code qui l’entoure : il est jugé par un chiffre, une métrique de performance. Or ce chiffre ne dit pas de lui-même s’il est fiable — un score peut être flatteur et pourtant faux, parce que les données cachaient un piège ou parce que la métrique ne mesurait pas ce qui compte. La valeur d’un résultat d’IA dépend donc directement de deux choses : votre compréhension des données que le modèle a reçues, et votre capacité à lire la métrique qui l’évalue. Ce document présente les bases pour explorer un jeu de données avant de s’en servir, puis pour choisir et interpréter une métrique de performance — de quoi porter un jugement fondé sur ce que produira l’agent IA, plutôt que de faire confiance à un chiffre.

Points clé à retenir

Regardez toujours vos données avant de modéliser : taille, cible, valeurs manquantes, équilibre des classes, colonnes suspectes.
Pour une tâche supervisée, la performance se mesure sur un ensemble de test séparé, jamais sur l’entraînement, et se compare à un modèle bête.
Choisissez la métrique en fonction de la tâche : accuracy et F1 en classification, MSE ou R² en régression, précision/rappel en détection d’anomalie, silhouette en clustering.
Une accuracy élevée ne prouve rien sur des données déséquilibrées.

Contenu de l’article

Quand on construit un modèle d’IA, ce n’est pas le code qui dit s’il est bon : c’est un chiffre, une métrique de performance. Et ce chiffre ne se suffit pas à lui-même — un score peut être flatteur et pourtant trompeur, soit parce que les données cachaient un piège, soit parce que la métrique ne mesurait pas ce qui comptait vraiment. Juger un modèle suppose donc deux compétences : savoir regarder les données dont il s’est nourri, et savoir lire la métrique qui l’évalue. Ce sont des réflexes de rigueur qu’un ingénieur applique à n’importe quel système, bien au-delà du machine learning.

Ce document présente les bases de ces deux compétences : d’abord comment explorer un jeu de données avant de s’en servir, ensuite comment choisir et interpréter une métrique selon la tâche. De quoi porter un jugement fondé sur un résultat, plutôt que de faire confiance à un chiffre.

Vous n’écrirez pas ce code vous-même

Pendant l’activité pratique, c’est l’agent IA qui produira le code du pipeline. Ce document ne vous apprend donc pas à coder ces étapes, mais à les comprendre : savoir ce qu’est une métrique, laquelle choisir et comment la lire, pour pouvoir spécifier le travail à l’agent et juger son résultat.

Partie 1 — Prendre en main un jeu de données

Avant d’entraîner quoi que ce soit, un ingénieur regarde ses données. Cette étape porte un nom : l’analyse exploratoire (en anglais EDA, exploratory data analysis). Il n’existe pas de recette unique, mais une petite démarche standard répond à la plupart des besoins.

Les questions à se poser systématiquement

Quelle est la taille du jeu ? Combien d’exemples (lignes), combien de caractéristiques ou features (colonnes) ?
Que représente chaque colonne ? Quelle est la cible (ce qu’on veut prédire, s’il y en a une) ? Les autres colonnes sont-elles toutes de vraies caractéristiques, ou y a-t-il un identifiant (un numéro attribué à chaque exemple) qui n’a aucune valeur prédictive ?
Quels types de données ? Numériques (âge, montant…) ou catégorielles (sexe, région…) ? Les modèles classiques attendent en général des nombres : les colonnes catégorielles devront être encodées.
Y a-t-il des valeurs manquantes ? Combien, dans quelles colonnes ? Il faudra décider quoi en faire (remplir, supprimer la ligne, supprimer la colonne).
Comment se répartissent les données ? Pour une classification ou une détection d’anomalie : les classes sont-elles équilibrées ? Un fort déséquilibre changera votre façon de mesurer la performance (voir la partie 2).

C’est la seule étape que vous réaliserez vous-même, à la main. Avec la bibliothèque pandas, quelques commandes suffisent : .shape donne les dimensions, .head() un aperçu, .info() le type et le nombre de valeurs non nulles de chaque colonne, .describe() les statistiques des colonnes numériques, .isna().sum() le nombre de valeurs manquantes par colonne, et .value_counts() la répartition des classes.

Le réflexe le plus important : repérer une colonne qui ne devrait pas prédire

Certaines colonnes semblent utiles mais ne le sont pas — voire faussent tout. Un numéro d’identifiant en est l’exemple type : il n’a aucun sens prédictif, mais s’il se trouve corrélé par hasard (ou par construction) à la cible, un modèle peut s’en servir pour « tricher ». Repérer ces colonnes avant de modéliser vous évitera un score trompeur. Vous en reparlerez à la séance 2.

Pour approfondir :

Partie 2 — Mesurer la performance : les métriques

Une métrique est un nombre qui résume la qualité des prédictions, obtenu en comparant les prédictions du modèle aux vraies étiquettes. Deux principes d’abord, valables quelle que soit la métrique.

Principe 1 — On mesure toujours sur des données non vues

La performance qui compte est celle sur des données non vues pendant l’apprentissage. Concrètement, on sépare le jeu en deux : un ensemble d’entraînement (souvent 70 à 80 %), sur lequel le modèle apprend, et un ensemble de test (les 20 à 30 % restants), sur lequel on mesure la performance.

Mesurer la performance sur les données d’entraînement donnerait un score flatteur mais mensonger : le modèle pourrait avoir « mémorisé » les exemples sans savoir généraliser. La règle est donc simple — on ne mesure jamais la performance sur les données d’entraînement.

Principe 2 — Toujours se comparer à un modèle « bête »

Un score ne veut rien dire dans l’absolu. Il faut le comparer à ce qu’obtiendrait un modèle sans intelligence : pour une classification, un modèle qui prédit toujours la classe majoritaire ; pour une régression, un modèle qui prédit toujours la moyenne. Si votre modèle ne fait pas nettement mieux que ce plancher, il n’a rien appris d’utile.

Les métriques de classification

Tâche : associer chaque exemple à une catégorie.

Métrique	Ce qu’elle mesure	Quand l’utiliser
Accuracy (exactitude)	Proportion de prédictions correctes	Classes équilibrées ; intuitive mais trompeuse sinon
Précision	Parmi les « oui » prédits, combien sont justes	Quand une fausse alerte coûte cher
Rappel (sensibilité)	Parmi les vrais « oui », combien sont retrouvés	Quand rater un cas positif coûte cher
F1-score	Compromis entre précision et rappel	Classes déséquilibrées

La matrice de confusion est l’outil qui rend tout cela visible : elle croise ce que le modèle a prédit avec la vérité, et montre d’un coup d’œil où sont les erreurs (vrais positifs, faux positifs, etc.).

Métriques de régression

Tâche : prédire une valeur continue (exemple de l’activité : un coût médical). On ne parle plus de prédiction « juste ou fausse » mais d’écart entre prédiction et valeur réelle.

Métrique	Ce qu’elle mesure	À noter
MSE (erreur quadratique moyenne)	Moyenne des carrés des écarts	Pénalise fortement les grosses erreurs ; unité = celle de la cible au carré. Plus la valeur est faible, meilleur est la
RMSE (racine du MSE)	Même chose, ramenée à l’unité de la cible	Plus facile à interpréter que le MSE
R² (coefficient de détermination)	Part de la variance expliquée (1 = parfait, 0 = aussi bon que prédire la moyenne)	Peut être négatif si le modèle est pire que la moyenne

Métriques de détection d’anomalie

Tâche : repérer des exemples atypiques et rares. C’est une classification, mais extrêmement déséquilibrée : les anomalies peuvent représenter moins de 1 % des données.

Ici, l’accuracy ne veut plus rien dire

Si les fraudes à la carte bancaire représentent 0,2 % des transactions, un modèle qui répond toujours « pas de fraude » atteint 99,8 % d’accuracy — sans détecter la moindre fraude. Sur ce type de problème, l’accuracy est inutilisable : ce sont la précision et le rappel sur la classe rare qui comptent, résumés par le F1-score ou par l’aire sous la courbe précision-rappel (AUC-PR). Le rappel répond à la question qui importe vraiment : quelle proportion des fraudes le modèle a-t-il effectivement détectées ?

Métriques de clustering

Tâche : regrouper les exemples en groupes homogènes. Différence fondamentale : le clustering est non supervisé — il n’y a pas d’étiquette de référence. On ne peut donc pas mesurer une « justesse » ; on mesure la qualité de la structure trouvée par le modèle.

Métrique	Ce qu’elle mesure	À noter
Coefficient de silhouette	À quel point chaque point est proche de son propre groupe comparé au groupe voisin le plus proche	Varie de −1 à 1 : proche de 1 = groupes nets et bien séparés, proche de 0 = groupes qui se chevauchent, négatif = points probablement mal assignés

Les deux principes énoncés plus haut (séparation train/test, modèle « bête ») ne s’appliquent pas ici de la même façon, faute d’étiquette : on évalue directement la cohérence des groupes obtenus.

Pour approfondir :

Pour aller plus loin

Ces notions ne sont pas nécessaires à l’activité, mais complètent utilement le tableau.

La validation croisée (cross-validation) : plutôt qu’une seule séparation train/test, on répète l’opération sur plusieurs découpages et on moyenne les scores. Le résultat est plus fiable et moins dépendant du hasard de la séparation. Documentation
Le sur-apprentissage (overfitting) : un modèle qui obtient un excellent score sur l’entraînement mais un score bien plus faible sur le test a « appris par cœur » sans généraliser. Comparer les deux scores est un bon diagnostic. Documentation
ROC-AUC et courbes précision-rappel : d’autres façons de résumer la performance d’un classifieur, utiles quand on peut régler le seuil de décision. Documentation
Moyennes macro / micro / pondérée : en classification à plus de deux classes, plusieurs manières d’agréger la précision et le rappel de chaque classe en un seul chiffre. Documentation
La fuite de données (data leakage) : au-delà de la colonne identifiant, une fuite peut venir d’un prétraitement (normalisation, remplissage des manquants) ajusté sur l’ensemble du jeu avant la séparation train/test — le test contamine alors l’entraînement. La règle : tout prétraitement s’ajuste sur le train seul. Documentation