Jeux de données déséquilibrés : stratégies complètes pour les gérer efficacement

Dans de nombreux projets d'IA, les données ne sont pas équitablement réparties entre les classes. Un modèle peut alors sembler performant tout en étant inutile en pratique. Ce phénomène, appelé déséquilibre de classes, touche des domaines critiques comme la détection de fraude ou le diagnostic médical. Découvrons ensemble comment identifier ce problème et le résoudre étape par étape.

Qu'est-ce qu'un dataset déséquilibré et pourquoi pose-t-il problème ?

Un jeu de données est déséquilibré lorsque une classe (majoritaire) représente la très grande majorité des exemples, tandis que l'autre (minoritaire) est rare. Par exemple, dans la détection de fraude bancaire, moins de 0,5 % des transactions sont frauduleuses. De même, la détection de maladies rares, la prédiction du churn client, le filtrage de spam ou l'identification de défauts industriels présentent souvent des ratios de 1:100 ou plus.

Le modèle « triche » alors facilement : en prédisant toujours la classe majoritaire, il obtient une accuracy élevée tout en manquant systématiquement les cas rares qui nous intéressent réellement.

Le piège de l'accuracy et les métriques à privilégier

L'accuracy mesure le pourcentage de bonnes prédictions globales. Sur un dataset à 99 % de classe majoritaire, un modèle qui prédit toujours cette classe atteint 99 % d'accuracy sans rien détecter. Il faut donc regarder la matrice de confusion, la précision (proportion de vrais positifs parmi les positifs prédits), le rappel (proportion de vrais positifs détectés) et le score F1 qui les combine.

La PR-AUC est souvent plus informative que la ROC-AUC quand les classes sont très déséquilibrées. Le balanced accuracy et le coefficient kappa de Cohen corrigent également le hasard. On privilégie le rappel quand les faux négatifs sont coûteux (maladie manquée) et la précision quand les faux positifs le sont (alarme inutile).

Techniques de ré-échantillonnage : oversampling et undersampling

L'oversampling consiste à augmenter la classe minoritaire. La duplication simple risque de surapprentissage ; SMOTE crée des exemples synthétiques par interpolation, ADASYN adapte la densité selon la difficulté, et Borderline-SMOTE se concentre sur les frontières.

L'undersampling réduit la classe majoritaire. Les méthodes random, Tomek links (supprime les paires proches), NearMiss et ENN (Edited Nearest Neighbours) permettent de nettoyer les exemples redondants ou bruyants.

Les combinaisons comme SMOTETomek ou SMOTEENN offrent souvent le meilleur compromis, mais attention au risque d'overfitting avec l'oversampling et à la perte d'information avec l'undersampling.

Approches au niveau des algorithmes

De nombreux algorithmes acceptent un paramètre class_weight qui pénalise plus fortement les erreurs sur la classe minoritaire. On peut aussi déplacer le seuil de décision (threshold moving) après l'entraînement pour optimiser le rappel ou la précision selon le métier.

La focal loss, utilisée notamment en détection d'objets, réduit l'impact des exemples faciles et concentre l'apprentissage sur les cas difficiles de la classe rare.

Méthodes ensemblistes adaptées aux données déséquilibrées

Les approches ensemblistes combinent plusieurs modèles entraînés sur des sous-ensembles équilibrés. BalancedRandomForest rééquilibre chaque arbre par undersampling. EasyEnsemble et RUSBoost appliquent du random undersampling avant de booster. Balanced Bagging crée plusieurs sous-ensembles équilibrés via bootstrap. Ces méthodes réduisent la variance tout en améliorant la détection de la classe minoritaire.

Quand adopter le cadre détection d'anomalies

Quand la classe rare représente moins de 1 % des données, le problème se rapproche de la détection d'anomalies. Les algorithmes Isolation Forest, One-Class SVM ou autoencodeurs apprennent uniquement la distribution de la classe majoritaire et signalent les points qui s'en écartent fortement, sans avoir besoin d'exemples positifs pendant l'entraînement.

Bonnes pratiques de validation et pipelines sans fuite de données

Le resampling ne doit jamais être appliqué sur l'ensemble de test ou de validation, sous peine de fuite de données. Utilisez toujours un stratified k-fold pour préserver la proportion des classes dans chaque pli. La bibliothèque imbalanced-learn propose des Pipeline compatibles scikit-learn qui appliquent SMOTE uniquement sur les folds d'entraînement.

Exemple concret de code Python avec imbalanced-learn

from imblearn.pipeline import Pipeline
from imblearn.over_sampling import SMOTE
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import StratifiedKFold, cross_val_predict
from sklearn.metrics import classification_report
from sklearn.datasets import make_classification

X, y = make_classification(n_classes=2, weights=[0.95, 0.05],
                           n_informative=4, flip_y=0, n_samples=5000,
                           random_state=42)

pipe = Pipeline([
    ('smote', SMOTE(random_state=42)),
    ('clf', RandomForestClassifier(class_weight='balanced', random_state=42))
])

cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
y_pred = cross_val_predict(pipe, X, y, cv=cv)
print(classification_report(y, y_pred))

Cet exemple montre comment combiner SMOTE, pondération des classes et validation croisée stratifiée dans un pipeline sécurisé.

• Vérifier toujours la distribution des classes avant modélisation
• Choisir les métriques en fonction du coût métier des erreurs
• Appliquer le resampling uniquement sur le train
• Comparer plusieurs techniques (SMOTE, class_weight, seuils)
• Utiliser des pipelines imblearn pour éviter les fuites
• Valider avec stratified k-fold et PR-AUC

En appliquant ces bonnes pratiques, vous transformerez un modèle qui « triche » en un système réellement utile pour détecter les cas rares. Testez progressivement les différentes approches sur vos données et mesurez l'impact concret sur votre métrique métier principale.