Détection de fraude sur le Mobile Money : dompter le déséquilibre extrême des classes

Dans l'écosystème fintech et particulièrement dans les services de paiement mobile (Mobile Money), les transactions frauduleuses constituent une infime minorité : fréquemment moins de 0,05 % à 0,1 % du volume global. Pourtant, l'impact financier, réputationnel et réglementaire d'une fraude non endiguée est disproportionné.

Lorsqu'on entraîne un modèle d'apprentissage supervisé sur de telles données, on se heurte immédiatement au déséquilibre de classes extrême (extreme class imbalance). Voici un retour d'expérience pratique sur les écueils courants et les approches éprouvées pour concevoir un système de scoring efficace.

1. Le piège de l'exactitude (Accuracy Paradox)

L'erreur la plus répandue chez les praticiens débutants consiste à évaluer le modèle avec l'accuracy (taux de bonnes classifications). Si 99,9 % de vos transactions sont légitimes, un algorithme naïf qui prédit systématiquement « transaction normale » atteint 99,9 % d'exactitude.

Sur le papier, les scores sont éblouissants ; sur le terrain, vous laissez filer 100 % des fraudeurs.

Dans la détection de fraude, l'exactitude globale n'a aucune valeur opérationnelle. Les métriques clés sont :

• Le Rappel (Recall) : Quelle proportion des fraudes réelles avons-nous interceptée ?
• La Précision (Precision) : Parmi les alertes émises, combien correspondent à de vraies fraudes ?
• L'aire sous la courbe Precision-Recall (PR-AUC / Average Precision) : Beaucoup plus informative que le classique ROC-AUC lorsque la classe minoritaire est rare.

2. Stratégies de rééquilibrage : SMOTE vs Pondération

Deux grandes familles de solutions permettent d'ajuster l'attention de l'algorithme :

A. La pondération des classes (Cost-sensitive Learning)

C'est l'approche la plus élégante et la moins coûteuse en calcul. Dans des frameworks comme XGBoost ou LightGBM, le paramètre scale_pos_weight permet de pénaliser plus lourdement les erreurs commises sur la classe positive (la fraude).

B. Le sur-échantillonnage synthétique (SMOTE)

SMOTE génère des exemples synthétiques le long des segments reliant les k plus proches voisins de la classe minoritaire. Règle d'or absolue : appliquez toujours SMOTE exclusivement sur l'ensemble d'entraînement, jamais avant le split d'évaluation, sous peine d'une fuite de données (data leakage) majeure.

3. Implémentation pratique avec XGBoost

Voici un exemple de configuration solide pour entraîner un classificateur résilient au déséquilibre :

import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report, average_precision_score
from xgboost import XGBClassifier

# Séparation train/test stratifiée
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42
)

# Calcul du ratio négatifs / positifs
neg_count = np.sum(y_train == 0)
pos_count = np.sum(y_train == 1)
scale_pos_weight = neg_count / max(pos_count, 1)

# Entraînement du modèle avec pondération adaptative
clf = XGBClassifier(
    n_estimators=400,
    learning_rate=0.03,
    max_depth=6,
    subsample=0.8,
    colsample_bytree=0.8,
    scale_pos_weight=scale_pos_weight,
    eval_metric="aucpr",
    random_state=42
)

clf.fit(X_train, y_train)

# Évaluation via la probabilité et le score PR-AUC
y_probs = clf.predict_proba(X_test)[:, 1]
pr_auc = average_precision_score(y_test, y_probs)
print(f"Score PR-AUC sur test : {pr_auc:.4f}")

4. L'arbitrage du seuil de décision (Threshold Tuning)

Par défaut, la fonction predict() applique un seuil à 0,5. En production, ce seuil est rarement optimal :

• Abaisser le seuil (ex. à 0,25) augmente le rappel : on capture davantage de fraudes, mais au prix de vérifications manuelles supplémentaires par les analystes de conformité.
• Relever le seuil (ex. à 0,75) restreint les alertes aux cas quasi certains, réduisant la friction pour les utilisateurs honnêtes.

L'optimisation du seuil doit être guidée par la matrice des coûts réels : Coût d'une alerte injustifiée vs Perte sèche d'une fraude manquée.

Ce qu'il faut retenir

Un modèle performant de détection de fraude repose moins sur la complexité brute de l'architecture que sur la pertinence des variables métier (vitesse de transaction, ratio montant/solde habituel, changements récents d'appareil) et le choix rigoureux de métriques centrées sur la classe minoritaire.