Contexte

Une société financière propose des crédits à la consommation à des personnes ayant peu ou pas d’historique de prêt. Elle souhaite développer un outil de Scoring Credit pour obtenir la probabilité de remboursement du client. Elle souhaite donc développer un algorithme de classification en s’appuyant sur des sources de données variées (données comportementales, données provenant d'autres institutions financières, etc.).

De plus, il est important pour la société d’apporter de la transparence vis-à-vis des décisions d’octroi de crédit. Par conséquent, un dashboard interactif est développé afin que les chargés de relation client puissent à la fois expliquer de façon la plus transparente possible les décisions d’octroi de crédit, mais également permettre à leurs clients de disposer de leurs informations personnelles et de les explorer facilement.

Pour ce projet, les différentes étapes ont été suivies :

• Développement d’un modèle de scoring qui donnera une prédiction sur la probabilité de faillite d'un client de façon automatique.

• Construction d’un dashboard interactif à destination des gestionnaires de la relation client permettant d'interpréter les prédictions faites par le modèle, et d’améliorer la connaissance client des chargés de relation client.

• Mise en production du modèle de scoring de prédiction à l’aide d’une API, ainsi que le dashboard interactif qui appelle l’API pour les prédictions.

Données

Les données sont divisées en 10 datasets, avec des informations sur les demandes de crédits (id, historique,…) ainsi que sur les demandeurs (âge, profession,…), et entre jeu d’entraînement avec la variable TARGET, qui donne la décision finale (0 : remboursement, 1 : non remboursement), et jeu de test, sans la variable TARGET.

Les données sont disponibles ici.

Analyse exploratoire

Analyse Univariée

TARGET

En observant les données du jeu d’antraînement, on s’aperçoit que les données sont déséquilibrées : on observe une grande majorité de classe 0 (92 %) comparée à la classe 1 (8 %). Nous sommes donc face à un problème de Class Imbalance.

Il existe plusieurs méthodes pour gérer un problème de Class Imbalance dans les données d’entraînement (SMOTE, Under-sampling, Over-sampling…). La méthode Class Weight est sélectionnée, c’est à dire qu’on ajuste la fonction de doût du modèle de sorte que la mauvaise classification d’une observation de classe minoritaire soit plus lourdement pénalisée que la mauvaise classification d’une observation de la classe majoritaire.

Préparation des données

Split Train/Validation

Le jeu de données avec TARGET est divisé en train set/validation set, avec une proportion 80 %/ 20 %.

Nettoyage des données

Après une séparation du jeu de données en données train et données validation pour le modèle, elles sont séparément nettoyées (traitement des valeurs manquantes, valeurs aberrantes…). Puis les variables quantitatives sont normalisées, les variables catégorielles binarisées.

Modèle de Scoring

Algorithme testés

Les modèles testés sont :

• Dummy Classifier : pour avoir une référence

• Logistic Regression

• Random Forest Classifier

La recherche des hyperparamètres optimaux pour les algorithmes de Logistic Regression et Random Forest est faite à l’aide de GridSearchCV.

Comparaison des performances

Afin de comparer les algorithmes, l’AUC est calculée. C’est l’indicateur de la capacité discriminatoire du modèle, entre la classe 1 et la classe 0. On ajoute le temps de calcul, toujours un élément intéressant.

L’algorithme de Logistic Regression est sélectionné.

Fonction Coût Métier

Les pertes financières par mauvaise prédiction ne sont pas souhaitables. Cependant, il est impossible de les supprimer totalement. On peut tout de même optimiser le modèle ainsi que la fonction Coût-Métier afin de les limiter.

Les prédictions peuvent être classées comme suit :

• Faux Positifs: les cas où la prédiction est positive mais où la valeur réelle est négative. On a ici une perte d’opportunité si le crédit est réfusé à tort au client alors qu’il aurait été en mesure de rembourser le crédit.

• Faux Négatifs: les cas où la prédiction est négative, mais où la valeur réelle est positive. On a ici une perte réelle si le crédit est accepté puisque cela peut se transformer en défaut de paiement.

• Vrais Positifs: cas d’acceptation où le crédit sera remboursé

• Vrais Négatifs: cas de réfus où le crédit n’aurait pas été remboursé

Dans notre cas, on comprend qu’il est nécessaire de minimiser les Faux Négatifs, et les Faux Positifs, particulièrement les FN.

On considère alors deux critères : Recall et Precision. Il faut maximiser les deux valeurs.

Pour ce faire, on utilise la fonction Fbeta Score, avec beta = 1 pour que les deux valeurs aient le même poids :

Cette fonction est sélectionnée comme fonction coût métier, et doit être maximisée.

Afin de déterminer le seuil pour l’algorithme de régression logistique, on trace le F1 score en fonction du seuil de décision de l’algorithme de classification.

On remarque le le score est maximisé pour un seuil de 0.67, donc 67% de probabilité de non remboursement.

On définit les seuils de décision pour les classes 1 (non remboursement) et 0 (remboursement) :

• 1 : 0.67

• 0 : 0.33

Interprétabilité

Dans un soucis de transparence de la décision finale d’acceptation ou de rejet de demande de prêt, il est nécessaire de pouvoir expliquer cette décision. Pour cela, on détaille le score obtenu et l’impact des différentes variables. On interprète le résultat.

L’interprétabilité désigne donc l’évaluation globale ou locale du processus de prise de décision. Elle vise à représenter l’importance relative de chaque variable dans le processus de décision.

On trace donc par ordre décroissants les coefficients associées à chaque variables, sachant qu’ils peuvent être positif ou négatif.

Globale

Locale

API & Dashboard

Pour mettre en place l’API, on commence par charger le modèle pré-entraîné sur les données d’apprentissage.

On définit une page d’accueil, ainsi qu’une page de prédiction. Elle reçoit en entrée les données test choisie, et renvoie la probabilité de non remboursement, ainsi que le statut de la décision.

Les fonctionnalités suivantes sont implémentées :

• Visualisation du score et interprétation de ce score pour chaque client de façon intelligible pour une personne non experte en data science.

• Visualisation des informations descriptives relatives à un client (via un système de filtre).

• Possibilité de comparaison les informations descriptives relatives à un client à l’ensemble des clients ou à un groupe de clients similaires.

Le dashboard appel l’API :

• demande à l’utilisateur du numéro de dossier

• envoi d’une requête à l’url de l’API avec les données test sélectionnée à partir du numéro de dossier

• réception de la valeur de probabilité pour la classe 1

• affichage du résultat