Challenge AI: IBM x Telecom

1. Contexte

Ce projet a été réalisé dans le cadre du Challenge IA/Data IBM x Télécom Paris 2025, en équipe de trois (équipe "Jérôme Kernel"). L'objectif du challenge était d'identifier automatiquement des transactions bancaires frauduleuses au sein d'un large volume d'opérations, à partir de jeux de données fournis par IBM : historiques de transactions, informations sur les cartes et profils des porteurs.

Le jeu de données d'entraînement contenait 210 000 transactions labellisées (dont seulement 315 fraudes, soit un déséquilibre extrême de classe d'environ 0,15%), et le jeu d'évaluation comptait 90 000 transactions à classer.

2. Objectifs

• Détecter les transactions frauduleuses malgré un déséquilibre de classe très fort (moins de 0,2% de fraude).
• Construire des variables numériques et catégorielles pertinentes à partir des données brutes (transactions, cartes, utilisateurs) pour révéler des comportements suspects.
• Entraîner un modèle robuste au bruit et optimisé sur le F1-score, métrique retenue par les organisateurs pour gérer le déséquilibre de classe.

3. Méthodologie

Le pipeline complet a été développé en Python (pandas, scikit-learn, XGBoost) à partir de cinq sources de données fusionnées : les transactions, les labels de fraude, les cartes, les utilisateurs et les features d'évaluation.

Nettoyage et fusion des données

• Fusion des transactions avec les données cartes (cards_data) et utilisateurs (users_data) via client_id / card_id.
• Nettoyage des colonnes monétaires (suppression du symbole $, conversion en float) pour amount, credit_limit, yearly_income, etc.
• Analyse univariée systématique des variables numériques et catégorielles pour repérer les distributions atypiques.

Feature engineering

L'analyse exploratoire des transactions frauduleuses a révélé deux signaux forts, transformés en variables binaires :

• is_Rome : la ville marchande "Rome" concentre une part disproportionnée de fraudes, en particulier sur certains codes marchands (mcc) affichant un taux de fraude supérieur à 50% (jusqu'à 100% sur certains codes comme 3009, 5311 ou 7011).
• is_Online : les transactions en ligne présentent également une sur-représentation de fraude, avec un scoring pondéré (taux de fraude × log(1 + nb de fraudes)) utilisé pour isoler les 70 marchands "ONLINE" les plus à risque.
• Découpage temporel de l'horodatage en indicateurs is_morning / is_afternoon / is_night.

Le jeu de variables final retenu pour la modélisation combine merchant_id, amount, mcc, year_pin_last_changed, current_age, retirement_age, credit_score, is_Rome et is_Online.

Modélisation

Une première approche par règles métier (fraude quasi-certaine si merchant_city == "Rome" avec un mcc à haut risque, ou marchand "ONLINE" identifié comme suspect) a servi de baseline. Elle a ensuite été remplacée par deux modèles supervisés comparés via validation croisée stratifiée à 5 plis (StratifiedKFold) et GridSearchCV optimisé sur le F1-score :

• Random Forest (pipeline avec StandardScaler), grid search sur n_estimators, max_depth, min_samples_split et min_samples_leaf.
• XGBoost, grid search sur n_estimators, max_depth, learning_rate, subsample et colsample_bytree.

4. Résultats

En validation croisée, le Random Forest optimal (max_depth=20, min_samples_split=5, n_estimators=100) atteint un F1-score de 0,62, tandis que XGBoost (max_depth=7, learning_rate=0.2, n_estimators=100) fait mieux avec un F1-score de 0,72.

L'analyse d'importance des variables confirme la pertinence du feature engineering métier : is_Rome et mcc arrivent en tête des variables les plus discriminantes, suivies de merchant_id et amount, devant les variables démographiques (credit_score, current_age, retirement_age).

5. Suite / perspectives

• Traiter plus finement le déséquilibre de classe (SMOTE, pondération de classe) plutôt que de s'appuyer principalement sur des règles géographiques/marchandes.
• Enrichir les features comportementales par client/carte (fréquence d'achat, montant moyen, écarts-types glissants, détection de rafales de transactions).
• Fiabiliser le pipeline pour la production : monitoring du drift des variables, ré-entraînement périodique et seuil de décision ajustable selon le coût métier des faux positifs/négatifs.