Plateforme ML — Project Data
MLOps et pipeline Project Data : évaluation du risque crédit, précision statistique (ROC-AUC) et exposition OpenAPI. Passez une ligne ou un portefeuille CSV sans quitter l’interface.
Synthèse moteur
Valeurs indicatives ; santé réelle via /health.
Identifiants API (démo). Après connexion, affichage du dernier rapport d’entraînement si le fichier métriques est présent côté serveur.
Démonstration
GIF enregistrés dans le dépôt (dossier assets/, servis sous /demo). L’ordre et les fichiers peuvent être pilotés par l’API GET /demo/carousel-manifest.
Parcours accueil
Alignement pédagogique — variables Project Data, glossaire VarA–VarL, suppression post-corrélation de Montant_hypotheque, contrat machine-lisible /ml/preprocess-contract
Projet Python & jeu de données Project Data
Les choix d’évaluation et de prétraitement reflètent le livrable académique et le fichier params.yaml — mêmes séparations train/test, métrique de sélection et imputation kNN que dans les notebooks.
Part test
20 %
hold-out — test_size & random_state figés (params.yaml)
Métrique de sélection
ROC-AUC
compare_models : le meilleur candidat est conservé pour le bundle
Imputation kNN
k = 16
knn_neighbors aligné preprocessing → entraînement → API
Modèles en compétition
4
régression logistique, k-NN, arbre, forêt — grille documentée
Le pipeline notebook → script → API garantit que les transformations (outliers, modes, dummies, retrait Montant_hypotheque) sont identiques entre expérimentation et inférence.
Donnée source Project Data — fichier SAS Tab2.sas7bdat (référence académique) — chaîne EDA → features → scoring rejouable dans le dépôt.
Pour le k-NN classifieur, une grille de voisins est explorée en CV ; pour tous les candidats, la décision finale suit la ROC-AUC sur la partition de test (rapport / Scrypt).
Hyperparamètres (ex. n_estimators, max_iter, class_weight) définis dans params.yaml — pas de « boîte noire » côté interface.
Lexique ML
La plateforme compare plusieurs algorithmes classiques de classification binaire (solvable / défaut). Voici, en termes simples, ce que chacun fait — sans équations.
Modèle qui combine linéairement les variables (après mise à l’échelle) pour estimer une probabilité entre 0 et 1. Très utilisé en scoring crédit : rapide, stable, facile à expliquer. Ici, les classes déséquilibrées peuvent être prises en compte via une pondération (class_weight) dans params.yaml.
Pour un nouveau dossier, le modèle regarde les k profils les plus ressemblants dans les données d’apprentissage et vote avec leur étiquette (défaut ou non). Pas d’hypothèse de relation linéaire. Le nombre k est choisi par validation croisée sur une grille ; les variables doivent être comparables (d’où le prétraitement et l’échelle).
Enchaînement de règles du type « si la variable X est au-dessus d’un seuil, aller à gauche, sinon à droite » jusqu’à une feuille qui donne la classe. Très lisible pour un contrôle métier. Risque de sur-apprentissage si l’arbre est trop profond — limité par des paramètres comme min_samples_split.
Construit de nombreux arbres sur des sous-échantillons et des sous-ensembles de variables, puis agrège leurs votes (ou probabilités). Souvent très performant et robuste au bruit ; moins trivial à expliquer qu’un seul arbre, mais reste une référence en pratique pour le tabulaire.
SVM (machine à vecteurs de support) : optionnel dans params.yaml (souvent désactivé). Il cherche une frontière qui sépare au mieux les classes dans un espace de features ; peut être plus coûteux sur de très gros volumes.
Le pipeline retient automatiquement le meilleur candidat selon la métrique principale (ROC-AUC par défaut), puis l’accuracy en secours — voir params.yaml et la page Indicateurs pour le modèle effectivement chargé.
Un socle ML et API pensé pour la reproductibilité et l’industrialisation progressive.
Comparaison de modèles (régression logistique, k-NN, arbres, forêt), sélection ROC-AUC et bundle sérialisé unique pour notebook et API.
Latence maîtrisée, schémas pydantic, JWT sur /predict et /train, documentation interactive Swagger et schéma OpenAPI JSON.
Artefacts versionnés, métriques /metrics après entraînement, contrat machine GET /ml/preprocess-contract pour vos intégrations.
Technologies du dépôt — du notebook à l’UI et au conteneur.
Aperçu des étapes reproduites côté serveur, comme dans les notebooks et le script de référence.
Le préprocesseur fitted (modes, outliers, KNNImputer, dummies) et le classifieur retenu sont sérialisés ensemble : même comportement en notebook, API unitaire et API batch.
SAS / CSV avec les noms colonnes attendus par l’API.
Mode sur Motif_pret & Profession, puis one-hot drop-first.
Outliers → NaN, imputation kNN, puis inférence. Lot : tableau + téléchargement CSV des scores.
Variables Project Data ; âge crédit en mois à la saisie.
Modes, outliers, kNN, encodage ; colonne hypothèque retirée.
Score, export CSV en lot, traçabilité du modèle.
Réponses courtes ; détail technique dans OpenAPI et les notebooks.
Le jeu de données Project Data provient du SAS historique : l’API accepte les mêmes unités qu’à la source. Le préprocesseur convertit en années avant imputation et modèle.
La limite est fixée côté serveur (variable PREDICT_BATCH_MAX_ROWS, exposée dans GET /ml/preprocess-contract). Le front affiche la valeur au moment du chargement de la page Prédictions.
Toutes les colonnes d’entrée plus la classe prédite, le verdict (solvable / non solvable), la probabilité de défaut et le nom du modèle utilisé.
Cette plateforme illustre un pipeline académique reproductible. Un usage réglementé nécessite validation métier, monitoring et gouvernance des données.
Pour échanger sur le produit, la data ou les intégrations bancaires — liens professionnels ci-dessous.
Accédez aux prédictions unitaires et par lot, ou intégrez l’API documentée à votre orchestrateur.