perachon/credit-scoring-api-v2

Projet MLOps

Contexte

L’objectif est de mettre en place les bases d’un projet de machine learning structuré selon les bonnes pratiques MLOps : versionnement du code, reproductibilité, préparation au déploiement et suivi du modèle.

Objectif du modèle

Prédire la probabilité de défaut de paiement d’un client à partir de données financières, en s’appuyant sur le jeu de données Home Credit Default Risk.

Le modèle a été conçu avec une attention particulière portée :

• —à la performance globale (ROC AUC),
• —au seuil métier et au compromis entre faux positifs et faux négatifs,
• —à l’interprétabilité et à la robustesse.

Données et artefacts

Les données sources, les modèles entraînés et les artefacts MLflow ne sont pas versionnés dans ce dépôt afin de :

• —respecter les bonnes pratiques MLOps,
• —éviter le versionnement de fichiers volumineux ou sensibles,
• —garantir un dépôt léger et reproductible.

Installation

Créer un environnement virtuel puis installer les dépendances :

pip install -r requirements.txt

Utilisation

L’ensemble des analyses, entraînements et évaluations est documenté et reproductible via le notebook :

notebooks/modeling.ipynb

Run API avec Docker

docker build -t credit-scoring-api .
docker run -p 8000:7860 credit-scoring-api

Endpoints disponibles API avec Docker

GET /health

Vérifie que l’API est opérationnelle.

Réponse :

{
  "status": "ok",
  "model_loaded": false
}

POST /predict

Retourne la probabilité de défaut et une décision métier.

Exemple de requête :

{
  "DAYS_BIRTH": -12000,
  "DAYS_EMPLOYED": -2500,
  "CODE_GENDER": "M",
  "AMT_INCOME_TOTAL": 180000,
  "AMT_CREDIT": 400000,
  "AMT_ANNUITY": 20000,
  "AMT_GOODS_PRICE": 350000,
  "EXT_SOURCE_2": 0.65,
  "EXT_SOURCE_3": 0.45,
  "CREDIT_GOODS_RATIO": 1.14,
  "DEBT_CREDIT_RATIO": 0.05,
  "ANNUITY_INCOME_RATIO": 0.11
}

Réponse :

{
  "probability_default": 0.23,
  "threshold": 0.2,
  "decision": "REFUSED"
}

Tests automatisés

Les tests unitaires sont réalisés avec pytest et couvrent :

• —la disponibilité de l’API,
• —la validation des données d’entrée,
• —le comportement de l’endpoint /predict. Le modèle est mocké lors des tests afin d’isoler la logique de l’API et garantir des tests rapides et robustes.

Lancer les tests :

pytest -q

Exécution avec Docker

Build de l’image

docker build -t credit-scoring-api .

Lancer le conteneur

docker run -p 8000:7860 credit-scoring-api

Accès à la documentation Swagger :

http://localhost:8000/docs

Déploiement en ligne

L’API est déployée sur Hugging Face Spaces et accessible publiquement :

Swagger UI :

https://perachon-credit-scoring-api-v2.hf.space/docs

Git

Le lien du repo Git public : https://huggingface.co/spaces/perachon/credit-scoring-api-v2/tree/main

Choix MLOps

• —Séparation API / modèle
• —Chargement lazy du modèle (performance & scalabilité)
• —Tests unitaires indépendants du modèle
• —Déploiement continu via Hugging Face Spaces

Monitoring et détection de dérive

Les données de production sont collectées par l’API sous forme de logs structurés incluant les données d’entrée du modèle, les prédictions, les décisions métier, la latence et les erreurs.

Ces données sont stockées puis exportées afin d’être analysées automatiquement. Une détection de dérive des données (data drift) est réalisée en comparant les distributions des prédictions en production avec une référence (issue des données d’entraînement ou d’une période stable).

La détection repose sur un test statistique de Kolmogorov–Smirnov (KS), permettant de mesurer si deux distributions diffèrent significativement. Un drift est détecté lorsque la p-value du test est inférieure à un seuil défini.

Cette approche correspond aux méthodes utilisées par des outils de monitoring tels qu’Evidently AI ou NannyML. Dans un contexte de production, ces outils pourraient être déployés dans un environnement dédié afin d’automatiser la génération de rapports et d’alertes.

Points de vigilance :

• —nécessité de définir une référence stable,
• —choix des seuils statistiques,
• —impact du drift sur la performance du modèle,
• —contraintes de stockage et de conformité (RGPD).

Ce prototype démontre la chaîne complète : collecte → stockage → préparation → analyse de dérive.

Optimisation des performances

L’analyse des logs de production a permis d’établir une baseline de latence avec une moyenne d’environ 600 ms et des pics dépassant 4 secondes.

Un profiling avec cProfile a mis en évidence un goulot d’étranglement lors de la première requête, lié au chargement du modèle depuis le hub et à l’initialisation du pipeline.

Une optimisation a été mise en place en préchargeant le modèle au démarrage de l’API. Cette optimisation supprime le cold start et permet de réduire la latence de la première requête de plus de 99 %, sans impact sur la précision du modèle.

La version optimisée est intégrée au dépôt et déployée via le pipeline CI/CD existant.