Construire
le cerveau
Développement du modèle — un détecteur de fraude entraîné, évalué, honnête. La matière qu'on industrialisera toute la semaine.
Le flux tourne, rien ne l'arrête
Bloc 1 : votre environnement est prêt, le dépôt Git existe, le projet est cadré — métriques choisies, coûts posés. Mais sur la carte, regardez le compteur : les fraudes passent toujours.
Mission du bloc 2 : faire apparaître le cerveau — un modèle qui score chaque transaction.
· MLOpsÀ 16 h, vous avez un modèle qui détecte la fraude — et vous savez prouver qu'il est bon
Construit en live, ensemble, au clavier. Pas le meilleur modèle du monde : un modèle honnêtement évalué, qui bat sa baseline — exactement ce qu'il faut pour la suite.
· MLOpsQuatre missions, au clavier
· MLOpsD'abord, regarder
les données
Un modèle vaut ce que valent
ses données
L'algorithme le plus sophistiqué du monde, nourri de données mal comprises, produit des erreurs sophistiquées. On passe donc 40 minutes à regarder avant de construire — c'est le meilleur investissement de la journée.
· MLOpsCe qu'il y a dans le fichier
Un CSV de 150 Mo : deux jours de transactions réelles de cartes européennes, anonymisées (dataset public Kaggle).
Première mission du lab : charger ce fichier proprement et vérifier chacun de ces chiffres vous-mêmes. Ne jamais croire un slide sur parole.
· MLOpsPourquoi « V1 », « V2 »… et pas « pays », « commerçant » ?
Parce que ce sont de vraies données bancaires. Publier les colonnes d'origine trahirait les clients — et les secrets de la banque.
- Des dizaines de variables métier, très parlantes
- Confidentielles : impossibles à publier telles quelles
- Les mêmes informations, compressées et brouillées (PCA)
- Le signal est intact — le sens des colonnes est masqué
Conséquence intéressante : on travaille comme un vrai data scientist bancaire — on ne sait pas tout, et il faut faire parler les données quand même.
· MLOpsQuatre questions à poser aux données
· MLOpsTrouvez les fraudes
· MLOpsLe champion du monde de l'accuracy
· MLOpsOn ne se note jamais sur ses propres révisions
Un modèle évalué sur les données qui l'ont entraîné, c'est un étudiant qui s'examine sur les annales qu'il vient de recopier : la note ne veut rien dire.
- Le modèle ne voit que ces transactions
- Stratifié : la même proportion de fraudes que l'original
- Jamais utilisé pendant l'entraînement, jamais
- Simule les transactions de demain, celles que le modèle n'a pas vues
· MLOpsQuand le futur
fuit dans le passé
Le leakage, c'est laisser le modèle voir pendant l'entraînement une information qu'il n'aura pas en production. Résultat : des scores mirifiques au test… et un effondrement en prod.
Un score trop beau pour être vrai ne l'est jamais. Cherchez la fuite.
scaler.fit(tout_le_dataset) # ← le test a fui !
X_train, X_test = split(...)
# la bonne version
X_train, X_test = split(...)
scaler.fit(X_train) # le test reste inconnu
· MLOpsUn premier cerveau,
simple
« Et si on mettait un réseau de neurones ? »
Non. Pas encore. En production, le bon modèle n'est pas le plus malin — c'est le plus simple qui fait le travail.
Notre baseline : la régression logistique — 60 ans d'âge, toujours en service dans la moitié des banques du monde.
· MLOpsUne balance
à soupçons
Chaque variable pèse sur la balance : un montant inhabituel ajoute du soupçon, une heure normale en retire. Le modèle apprend le poids de chaque indice — puis convertit le total en probabilité entre 0 et 1.
C'est tout. Une somme pondérée d'indices, écrasée entre 0 et 1. Le reste est du vocabulaire.
· MLOpsEntraîner, c'est régler la balance
Au départ, tous les poids sont au hasard. Le modèle parcourt les 227 000 transactions d'entraînement et ajuste, encore et encore : « sur celle-ci je me suis trompé — quel poids corriger ? »
227 845 exemples × des milliers d'ajustements ≈ 2 secondes de calcul.
C'est la magie ennuyeuse du ML : un algorithme d'optimisation banal, répété très vite. Aucune « intelligence » là-dedans — juste des poids qui convergent vers ce qui sépare le mieux fraudes et légitimes.
· MLOpsDire au modèle ce qui coûte cher
Sans consigne, le modèle optimise le nombre d'erreurs — et avec 0,17 % de fraudes, la stratégie gagnante est de les ignorer. Il faut changer les règles du jeu.
- Rater une fraude = bloquer un client : même prix
- Le modèle sacrifie les 492 fraudes sans remords
- Chaque fraude d'entraînement pèse comme ~580 transactions
- Le modèle est forcé de les prendre au sérieux
Un seul paramètre — et c'est déjà de l'alignement métier : on encode le coût réel de l'erreur dans l'apprentissage.
· MLOps0,93 n'est pas « fraude »
Le modèle ne dit jamais oui ou non. Il dit « 93 % de chances que ce soit une fraude » — et c'est à nous de décider où placer la barre.
array([[0.07, 0.93]]) # [P(légitime), P(fraude)]
# le verdict, c'est NOTRE règle :
alerte = proba_fraude >= seuil # 0.5 ? 0.3 ? 0.9 ?
Ce petit seuil est une décision métier déguisée en paramètre technique. On y consacre l'acte 3 — c'est lui qui arbitre entre fraudes ratées et clients bloqués.
· MLOpsLe juger
honnêtement
Quatre cases, toute la vérité
légitime
une fraude
Toutes les métriques qui suivent ne sont que des résumés de ces quatre cases. Quand une métrique vous embrouille : revenez à la matrice.
· MLOpsPrecision et recall, en langage fraude
· MLOpsDéplacez le seuil, sentez l'arbitrage
· MLOpsPR-AUC : juger tous
les seuils d'un coup
Vous venez de le sentir : chaque seuil donne un couple precision/recall différent. La courbe PR les trace tous ; l'aire sous la courbe (PR-AUC) résume la qualité du modèle indépendamment du seuil choisi.
Un seul chiffre, honnête même à 0,17 % de fraudes. C'est notre étalon pour comparer les modèles — aujourd'hui à la main, dès mercredi en barrière automatique dans la CI.
· MLOps« Et la ROC-AUC ? Tout le monde l'utilise »
Justement : tout le monde l'utilise… y compris quand il ne faut pas.
La ROC compte les vrais négatifs — et on en a 284 315. Noyée sous les légitimes, elle affiche 0,95 même pour un modèle médiocre sur la fraude.
La courbe PR, elle, ne regarde que ce qui nous intéresse : la classe rare. À déséquilibre extrême, métrique de la classe rare. C'est le réflexe à retenir — et une excellente question d'entretien.
· MLOpsConvertir la matrice en euros
La PR-AUC compare les modèles. Mais la décision finale — quel modèle, quel seuil — se prend dans la devise du métier : l'euro.
# cadré au bloc 1, calculé aujourd'hui, automatisé au bloc 6 —
# le seuil optimal est celui qui minimise CE chiffre.
C'est la boucle complète : une erreur statistique devient un coût, un coût devient une décision. Voilà ce qui distingue un modèle utile d'un modèle bien noté.
· MLOpsRegarder ses erreurs une par une
Les métriques disent combien on se trompe. L'analyse d'erreurs dit pourquoi — et c'est là que naissent les meilleures idées d'amélioration.
· MLOpsItérer,
méthodiquement
Une hypothèse à la fois
Améliorer un modèle, ce n'est pas « essayer des trucs ». C'est une boucle scientifique : hypothèse → changement → mesure → verdict. Un seul changement par tour, sinon on ne sait plus ce qui a agi.
· MLOpsFabriquer de meilleurs indices
Le modèle ne voit que ce qu'on lui donne. Le feature engineering, c'est transformer les colonnes brutes en indices plus parlants.
df["amount_log"] = np.log1p(df["Amount"])
# "Time" en secondes ne dit rien — l'heure du jour, si
df["hour"] = (df["Time"] // 3600) % 24
Deux lignes, souvent plus d'impact qu'un changement d'algorithme. En fraude, l'indice bat le cerveau — les meilleures équipes passent leur temps ici.
· MLOpsRééquilibrer les classes — avec des pincettes
Autre riposte au déséquilibre : modifier les données d'entraînement elles-mêmes.
La règle qui sauve : on ne rééquilibre que le train. Toucher au test, c'est mentir sur la réalité — un data leakage de manuel. Et on compare toujours au simple class_weight : souvent, il suffit.
· MLOpsLe levier gratuit : optimiser le seuil
Même modèle, zéro ré-entraînement : on balaie tous les seuils et on garde celui qui minimise le coût métier. Vous l'avez fait à la main tout à l'heure — en code, c'est une boucle de cinq lignes.
seuil = 0.50 → coût 41 300 €
seuil = 0.31 → coût 28 750 € # ← le minimum
seuil = 0.10 → coût 55 900 € # trop d'alertes
12 550 € économisés en déplaçant un curseur. Le seuil par défaut de 0,5 n'a rien de sacré — c'est juste la valeur d'usine.
· MLOpsApprendre
par cœur
À force d'itérer, le modèle peut mémoriser le train au lieu de comprendre la fraude — brillant sur ses révisions, perdu devant l'inédit. C'est l'overfitting, et il se voit d'un coup d'œil : l'écart entre score train et score test.
Train 0,99, test 0,71 : ce modèle n'a rien appris. Il a triché.
· MLOps« Le run 7,
c'était quoi déjà ? »
Dans une heure, vous aurez huit modèles entraînés, des scores griffonnés, trois onglets ouverts — et une vraie question : lequel était le meilleur, avec quels réglages ? Retenez cette sensation d'égarement.
Cette douleur a un remède, et il a un nom : MLflow. Rendez-vous au bloc 5.
model_final_v2.pkl
model_final_v2_VRAI.pkl
model_final_v2_VRAI_celui_la.pkl
# PR-AUC : 0.81 ? 0.83 ? c'était lequel ?
· MLOpsCinq réflexes à emporter
Et le cinquième : une hypothèse à la fois. C'est ce qui transforme du bricolage en ingénierie.
· MLOpsÀ vous :
2h40 au clavier
Charger et faire parler les données
Dans notebooks/01_exploration.ipynb : charger le CSV, vérifier les chiffres du slide 7, puis répondre aux quatre questions de l'acte 1 — déséquilibre, montants, heures, meilleures V.
Livrable : un notebook d'exploration commité, avec vos quatre réponses écrites en markdown.
Binômes : un qui code, un qui questionne — on échange à la mi-temps.
· MLOpsConstruire la baseline — en module, pas en notebook
Split stratifié, scaler fit sur le train seul, régression logistique avec class_weight='balanced'. Et on code dans src/train/train.py — un script rejouable, pas des cellules éparses : le réflexe MLOps commence ici.
Livrable : python -m src.train.train entraîne, évalue, sauve le modèle (.pkl) et affiche la PR-AUC.
Objectif chiffré : PR-AUC ≥ 0,70. Si vous voyez 0,99 : cherchez la fuite avant de fêter.
· MLOpsBattre votre propre baseline
Trois tours de boucle minimum, un levier par tour : une feature (amount_log, hour), un essai de rééquilibrage (comparé au class_weight), et le seuil optimisé sur le coût métier. Notez chaque run dans un tableau markdown — hypothèse, réglage, score, verdict.
Livrable : votre tableau de runs — il vous fera aimer MLflow au bloc 5.
Rappel : un seul changement par tour. Deux changements = zéro conclusion.
· MLOpsLe verdict final, ensemble
On reprend l'acte 3 sur vos résultats : matrices de confusion au tableau, courbes PR comparées, et l'analyse d'erreurs — chaque binôme présente sa fraude ratée la plus chère et son hypothèse pour l'attraper.
Definition of done : un modèle sauvé, sa PR-AUC ≥ baseline, son seuil justifié en euros, ses erreurs analysées.
C'est ce modèle — le vôtre — qu'on exposera en API au bloc 3.
· MLOpsLe cerveau existe — regardez-le travailler
Les transactions s'arrêtent désormais au cerveau, sont scorées, et les fraudes partent dans le bac rouge. Le compteur « fraudes bloquées » tourne enfin.
Mais regardez le cadre en pointillés : ce cerveau vit dans un notebook. Fragile, injoignable, inutilisable par la banque. Personne ne peut lui parler — sauf vous.
· MLOpsDonnons-lui
une adresse
Bloc 3 — Serving & API avec FastAPI : POST /predict, et le monde entier peut interroger votre modèle.