Datamart retail & ML — Data
Datamart Display (Displ / No_Displ), aligné sur le rapport rprt_ana_donnee_avancees_22-1 et l’historique ranaviz.R (Visual Analytics). ROC-AUC, bundle unique et API. Passez une ligne ou un portefeuille CSV sans quitter l’interface.
Utilisateurs qui lancent des prédictions sur la plateforme
Scoring Display, prédictions unitaires & lots CSV
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.
Partenaires
Expérience en environnements de conseil, data et transformation. Axys, Carrefour, Skoda France, La Poste, SNCF Réseau et Air France.
Axys
Carrefour
Skoda France
La Poste
SNCF Réseau
Air France
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
Rapport PDF, Shiny ranaviz.R & pipeline Python
Les choix d’évaluation et de prétraitement reflètent le rapport rprt_ana_donnee_avancees_22-1, l’app ranaviz.R (Overview, PCA, Modeling, MDLP) et params.yaml — même fraction test, métrique de sélection et imputation kNN (variables numériques) que dans les notebooks.
Part test
30 %
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
3
régression logistique, arbre de décision, forêt aléatoire (liste compare_models)
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.sas7bdat — chaîne EDA → features → scoring rejouable dans le dépôt.
Les trois candidats (régression logistique, arbre de décision, forêt aléatoire) sont entraînés sur les mêmes données prétraitées ; le choix du modèle déployé suit la ROC-AUC sur le jeu de test, comme dans l’onglet Modeling de ranaviz.R (matrices de confusion côte à côte).
Hyperparamètres (ex. n_estimators, max_iter, max_depth, class_weight) définis dans params.yaml — pas de « boîte noire » côté interface.
Le pipeline compare trois classificateurs binaires sur la cible Display (Displ / No_Displ), comme dans le rapport rprt_ana_donnee_avancees_22-1 et l’application Shiny ranaviz.R (Decision Tree, Logistic Reg, Random Forest). 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 : rapide, stable, facile à documenter (coefficients, signes). Ici, les classes déséquilibrées peuvent être prises en compte via class_weight dans params.yaml.
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 (règles explicites). Risque de sur-apprentissage si l’arbre est trop profond — limité par min_samples_split et max_depth comme dans ranaviz.R (rpart).
Agrégation de nombreux arbres entraînés sur des sous-échantillons et des sous-ensembles de variables (mtry / max_features), comme dans ranaviz.R avec ntree et réglage de mtry. Souvent très performant sur données tabulaires ; l’interprétation passe plutôt par l’importance des variables que par une règle unique.
Imputation : le kNN est utilisé pour compléter les valeurs manquantes (prétraitement), pas comme classifieur de la cible Display. La liste compare_models se limite à ces trois algorithmes.
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é.
Ce tableau résume des différences de nature (lisibilité, coût, robustesse), pas les scores du dernier entraînement. Il complète le lexique ci-dessus sans dupliquer le tableau de bord Indicateurs.
Historiquement, ranaviz.R et le rapport PDF présentent les trois modèles avec matrices de confusion et taux d’erreur (Decision Tree, Logistic Reg, Random Forest). Le pipeline Python reprend cette même liste de candidats dans params.yaml.
| Critère | Régression logistique | Arbre de décision | Forêt aléatoire |
|---|---|---|---|
| Interprétabilité | Élevée : coefficients sur variables préparées ; adaptée à une note écrite pour la conformité. | Très élevée : chemin « si / alors » lisible par le métier. | Modérée : importance globale des variables ; pas une règle unique. |
| Coût calcul (entraînement / scoring) | Faible : rapide même sur de gros volumes. | Faible à modéré : un seul arbre. | Plus élevé : nombreux arbres (ex. n_estimators élevé dans params.yaml). |
| Pouvoir prédictif typique | Très bon lorsque les effets sont bien captés par une combinaison linéaire ; baseline solide. | Variable : peut exceller ou sur-apprendre selon la profondeur. | Souvent parmi les meilleurs sur données tabulaires ; agrège plusieurs points de vue. |
| Sensibilité au réglage | Modérée — surtout régularisation et pondération des classes. | Élevée — profondeur, taille minimale des feuilles, critères de split. | Élevée — nombre d’arbres, nombre de variables tirées à chaque split (mtry / max_features). |
| Risque de sur-apprentissage | Limité si le prétraitement (échelle, outliers) est maîtrisé. | Principal point de vigilance : arbre trop profond. | Réduit par l’agrégation, mais reste possible si le bruit domine. |
| Robustesse au bruit / interactions | Sensible aux non-linéarités non captées ; interactions à ajouter explicitement si besoin. | Isole des interactions locales via les règles. | Souvent robuste au bruit et aux interactions implicites. |
Lorsque vous devez expliquer clairement le score (coefficients, sens des variables), pour un déploiement léger, ou lorsque la relation cible–features est globalement additive après préparation.
Pour des audits « règle par règle », des ateliers métier, ou un premier modèle très lisible — en acceptant de surveiller la profondeur pour éviter le sur-apprentissage.
Lorsque la priorité est la performance discriminante sur données riches et bruitées, et que l’interprétation peut passer par l’importance des variables plutôt que par une seule règle.
Les indicateurs chiffrés (ROC-AUC, F1, répartition des classes) du modèle chargé après entraînement se trouvent sur la page Données projet
Un socle ML et API pensé pour la reproductibilité et l’industrialisation progressive.
Trois classifieurs tabulaires (régression logistique, arbre de décision, forêt aléatoire) en compétition sur la même cible Display, sélection ROC-AUC dans params.yaml et un seul bundle sérialisé pour notebooks et API — comme dans le rapport et l’onglet Modeling de ranaviz.R.
Latence maîtrisée, schémas pydantic, JWT sur /predict et /train, documentation interactive Swagger et schéma API 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 — notebooks, API FastAPI, UI Next.js et conteneurs.
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 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 API et les notebooks.
Le jeu 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 (Displ / No_Displ), la probabilité P(Displ), la colonne risk_band (low / medium / high, même lecture que sur l’écran) 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.
Accédez aux prédictions unitaires et par lot, ou intégrez l’API documentée à votre orchestrateur.
Témoignages d’équipes data, études et intégration qui s’appuient sur les prédictions Display (unitaire, batch), l’API et le contrat ML — contenu synchronisé avec le backend quand il est joignable.
Témoignage
“Nous lançons chaque semaine des milliers de prédictions batch sur le portefeuille : les probabilités P(Displ) et le même prétraitement que le notebook nous permettent de prioriser les dossiers comme sur l’ancien ranaviz, mais à l’échelle API.”
Auteur & réseaux
Retrouvez Daya (SMD Lab-Tech) sur LinkedIn et GitHub, ainsi que les autres canaux ci-dessous.