← Toutes les études de cas

Scoring de crédit : de la donnée à la décision

Ce projet va jusqu'au bout du cycle : un modèle optimisé sur le coût réel des erreurs, déployé et explicable, avec un monitoring en production.

Python LightGBM FastAPI Docker CI/CD MLflow SHAP Streamlit Evidently AI

Le problème

Une institution financière doit décider d'accorder ou non un crédit. Deux erreurs sont possibles, et elles ne coûtent pas la même chose : refuser un bon client fait perdre une marge, accepter un mauvais payeur fait perdre le capital prêté.

Un modèle classique, optimisé sur l'accuracy ou sur l'AUC seule, ignore cette asymétrie : il traite les deux types d'erreur comme équivalents. Or c'est l'inverse de ce dont l'entreprise a besoin. La vraie question était donc la suivante : quel modèle coûte le moins cher ?

La démarche

Explorer et préparer les données Analyse exploratoire, feature engineering, puis gestion d'un fort déséquilibre de classes entre bons et mauvais payeurs. Les variables préparées sont stockées dans une base SQLite qui sert de feature store commun à l'API et au dashboard.
Comparer plusieurs modèles Évaluation de plusieurs algorithmes sur les mêmes données, puis sélection d'un LightGBM pour son rapport entre performance et temps d'entraînement, et pour son interprétabilité.
Traduire le problème en langage métier Définition d'un score métier : une fonction de coût qui pondère différemment un faux positif et un faux négatif. Le seuil de décision est ensuite optimisé sur ce coût, et non fixé à 0,5 comme par défaut.
Rendre chaque décision explicable Calcul de valeurs SHAP locales et globales. Le dashboard Streamlit affiche, pour chaque client, les facteurs qui pèsent le plus dans la décision, une jauge de risque, une comparaison au reste de la clientèle et une simulation « et si ? » pour tester un changement de situation.
Déployer pour de vrai API FastAPI conteneurisée avec Docker, tests automatisés et pipeline CI/CD. Le dashboard consomme cette API, ce qui garantit une seule source de vérité pour le calcul du score.
Surveiller après la mise en production Suivi des expériences avec MLflow et génération d'un rapport de dérive des données avec Evidently AI. Un modèle se dégrade, il faut pouvoir le détecter.

Les résultats

0,79

AUC sur les données de test

100 %

du cycle : données, modèle, API, dashboard

applications déployées et accessibles en ligne

La décision est explicable. Pour chaque dossier, le chargé de clientèle voit quels facteurs ont pesé. C'est ce qui rend un refus défendable face à un client, et conforme aux exigences de transparence sur les décisions automatisées.

Ce que j'en retiens

Un modèle se juge sur son coût métier. Deux modèles avec la même AUC peuvent avoir des conséquences financières très différentes selon l'endroit où l'on place le seuil. C'est donc le seuil qu'il faut optimiser en priorité.
Un modèle n'a de valeur que s'il est utilisable par ceux qui décident. D'où le dashboard pensé pour des non-techniciens et la simulation « et si ? », plutôt qu'une API que seul un data scientist saurait appeler.
Le monitoring fait partie du travail. Les données de production dérivent, et sans rapport de dérive on découvre le problème trop tard.

Piste d'amélioration : la matrice de coûts qui définit le score métier reste une hypothèse. En conditions réelles, elle devrait être co-construite et validée par les équipes risque. C'est un sujet de dialogue entre le métier et la technique.