OpenClassrooms · P6 · Projet validé
Tracer les expériences de scoring
Documenter les expériences et choisir un modèle de scoring en tenant compte du coût métier.
Données→MLflow→Sélection
Le travail réalisé
Construire un scoring de crédit en traçant les expériences, en comparant les modèles et en choisissant un seuil cohérent avec le coût des erreurs métier.
- Agrégation de huit tables Home Credit en un jeu client ; le projet documente 307 511 clients et 419 features.
- MLflow trace les essais et GridSearchCV organise la recherche d’hyperparamètres. Les features métier et les méthodes de contrôle du sur/sous-apprentissage sont discutées.
Les résultats disponibles
- Le notebook rapporte une AUC CV d’environ 0,7814 et une AUC de validation d’environ 0,7852 pour LightGBM sur le split documenté.
- Les métadonnées indiquent un seuil de 0,5145, tandis qu’un résultat du notebook utilise environ 0,494 : ce sont des sorties différentes à rattacher à leur run avant publication d’un chiffre final.
Résultats et retours conservés dans l’audit du 9 octobre 2026. Ils n’ont pas été reproduits lors de la préparation de ce portfolio.
Ce que j’en retiens
Passage de « trouver un bon modèle » à « conserver une expérience traçable et décider selon le coût d’une erreur ».
Limites et pistes d’amélioration
- Un intitulé de compétence OC ne prouve pas l’usage d’une technique dans le modèle final : LightGBM ne suffit pas à revendiquer une maîtrise générale des réseaux neuronaux.
- src/modeling.py est vide dans le snapshot ; une partie importante du travail de modélisation réside dans le notebook.
- Le volume de lignes des tables sources ne doit pas être présenté comme le nombre d’exemples du modèle.