Maîtriser l’architecture Lakehouse : Bronze, Silver et Gold dans Microsoft Fabric

By Mirko Peters · 2026-08-28

Automatically translated with AI from the original post. Read the English original

Titelbild: Mastering Lakehouse Architecture: Bronze, Silver, and Gold in Microsoft Fabric

Bienvenue de retour sur le blog compagnon du podcast ! Dans notre dernier épisode, nous avons analysé en profondeur les réalités concrètes de l’ingénierie du machine learning au sein de l’écosystème Microsoft. Si vous ne l’avez pas encore écouté, n’hésitez pas à consulter Build Machine Learning Models in Microsoft Fabric. Aujourd’hui, nous allons approfondir ces concepts et voir comment structurer vos données selon une architecture en médailles (medallion) au sein d’un Lakehouse Microsoft Fabric, qui constitue le socle indispensable d’une activité de machine learning réussie et évolutive.

Construire des modèles de machine learning prêts pour la production ne se résume pas au choix du bon algorithme ou au réglage des hyperparamètres. Le plus souvent, la réussite de vos modèles prédictifs dépend de la qualité des données, de pipelines reproductibles et d’une gouvernance solide. Voyons ensemble comment maîtriser votre architecture Lakehouse avec Microsoft Fabric.

Architecture en un coup d’œil

Lorsque vous concevez une plateforme de données et de machine learning de bout en bout dans Microsoft Fabric, il est essentiel de comprendre le cheminement des données. Tout commence dans OneLake, qui sert de couche de stockage unifiée. De là, les données sont acheminées vers un Lakehouse, où elles transitent par les tables Delta bronze, silver et gold.

Côté calcul, les notebooks Fabric donnent aux data scientists accès à une pile data science préinstallée, reposant sur Spark, Python et R. Le suivi des expérimentations est assuré nativement par des exécutions MLflow intégrées, qui capturent métriques, paramètres et artefacts sans nécessiter de serveur de suivi externe. Une fois les modèles entraînés, ils passent dans le registre unifié, avec gestion des versions, approbations et traçabilité complète des données. Enfin, les modèles sont exposés via des tâches batch managées ou des points de terminaison HTTP en temps réel, alimentant des consommateurs tels que Power BI, Power Apps et des clients API personnalisés.

Lakehouse : maîtriser les entrées, garder le contrôle

La philosophie fondamentale d’un Lakehouse consiste à réunir la souplesse d’un data lake et la fiabilité d’un entrepôt de données. Pour que cela fonctionne efficacement, vous devez structurer vos données en couches distinctes.

Organiser vos tables en couches

Bronze : Il s’agit de votre couche d’ingestion brute. Les données y arrivent selon le principe du schema-on-read et demeurent immuables, afin de permettre l’audit et le retraitement.
Silver : Dans cette couche, les données sont nettoyées, typées et jointes. Les données personnelles (PII) sont réduites au minimum et les premiers contrôles de qualité sont appliqués.
Gold : La couche gold contient des agrégats prêts à être utilisés comme features, construits sur des contrats de données clairs et documentés, que vos modèles de machine learning peuvent consommer directement.

Accès selon l’intention

Combinez le contrôle d’accès basé sur les rôles de l’espace de travail avec des listes de contrôle d’accès (ACL) au niveau des tables. Accordez aux data scientists un accès en lecture seule aux tables silver et gold, et limitez les droits d’écriture aux tables de features et aux répertoires d’expérimentation.

Garde-fous de qualité des données

Définissez des exigences strictes concernant les contraintes de non-nullité, les plages de valeurs et l’intégrité référentielle. Lorsque des lignes échouent à ces contrôles, dirigez-les directement vers une table _quarantine afin que vos pipelines en aval ne échouent pas silencieusement et n’ingèrent pas de données corrompues.

Feature store allégé

Traitez vos features réutilisables comme des tables gold (par exemple feat_customer_rolling_90d) et accompagnez-les d’un dictionnaire de données YAML, afin que votre équipe comprenne ce que représente chaque feature.

Des notebooks sans les tracas

Le développement collaboratif peut vite devenir chaotique si les développeurs travaillent dans des environnements différents. Fabric fournit des noyaux préinstallés incluant pandas, PySpark, scikit-learn et PyTorch, garantissant que chacun part exactement de la même base.

Adoptez une structure de projet organisée, séparant les notebooks d’exploration, les scripts d’ingénierie des features, les routines d’entraînement des modèles et les fichiers de configuration. Placez la reproductibilité dans le code plutôt que de compter sur des manipulations manuelles dans l’interface. Lisez depuis votre Lakehouse via Spark SQL, écrivez vos features finales sous forme de tables Delta et créez toujours des échantillons de données de développement, afin que votre équipe puisse itérer rapidement sans attendre des requêtes sur l’intégralité des jeux de données.

Suivre tout avec MLflow (intégré)

Le suivi manuel des expériences de modèles conduit à des résultats impossibles à reproduire. En exploitant l’intégration native de MLflow dans Fabric, vous garantissez la comparabilité entre les exécutions, une traçabilité complète et des retours en arrière sans effort lorsqu’un modèle nouvellement déployé sous-performe.

Consignez tous les hyperparamètres, métriques d’évaluation et artefacts de modèle entraîné directement dans vos scripts d’entraînement. Veillez à étiqueter vos exécutions avec des métadonnées contextuelles, comme la fenêtre de données, les versions de l’ensemble de caractéristiques et les hachages de commit du code, en épinglant vos tables d’entraînement à des versions de snapshot Delta précises.

Registre, approbations et traçabilité

Le passage d’un modèle de la phase d’expérimentation à la production ne doit jamais relever du pari. Promouvez vos meilleures exécutions vers un modèle enregistré, en utilisant un versionnement sémantique tel que 1.0.0. Mettez en place un processus d’approbation en deux étapes exigeant la validation à la fois du propriétaire data science et du propriétaire métier. Enfin, renseignez des métadonnées complètes de fiche modèle décrivant la finalité du modèle, le périmètre des données, les remarques sur l’équité et les objectifs de niveau de service (SLO) de supervision.

Options de service (à choisir selon la charge de travail)

Scoring par lots (économique et fiable)

Pour les charges de travail ne nécessitant pas de réponse instantanée, inférieure à la seconde, le scoring par lots est votre meilleur allié. Utilisez des tâches planifiées Fabric ou des notebooks pour lire les modèles de production depuis le registre, les appliquer aux jeux de données par lots et écrire les prédictions dans le Lakehouse.

Point de terminaison en temps réel (applications interactives)

Lorsque vos utilisateurs ont besoin d’un retour immédiat, par exemple pour la validation de formulaires ou un scoring du risque au clic, déployez votre modèle enregistré sous forme de point de terminaison géré en temps réel directement depuis l’interface utilisateur de Fabric. Exposez un contrat JSON prévisible et connectez-le de manière sécurisée à Power Apps ou à des applications externes.

Supervision et réentraînement

Déployer un modèle ne représente que la moitié du travail. Vous devez surveiller en continu la dérive des données en comparant les distributions des caractéristiques en production à votre référence d’entraînement, à l’aide de la divergence de Kullback-Leibler ou des seuils de l’indice de stabilité de la population (PSI). Suivez les métriques de santé opérationnelle, notamment la latence des points de terminaison, les taux d’erreur et les coûts par millier de scores. Automatisez vos pipelines de réentraînement en combinant des déclencheurs temporels et des alertes de dérive basées sur les événements, afin que vos modèles restent précis dans la durée.

Sécurité et conformité

Le maintien de la sécurité est primordial lorsque l’on manipule des données d’entreprise. Appliquez le principe du moindre privilège en accordant aux data scientists un accès en lecture aux couches silver et gold, tout en limitant les droits d’écriture aux répertoires désignés pour les caractéristiques et les expérimentations. Utilisez les identités managées et Azure Key Vault pour le stockage de tous les identifiants, afin qu’aucun secret ne se retrouve codé en dur dans vos notebooks. Limitez l’exposition des données personnelles (DCP) en hachant ou en tokenisant les informations sensibles dès la couche silver, afin qu’elles ne se propagent jamais dans vos magasins de caractéristiques.

Quoi mesurer (prouver rapidement la valeur)

Pour démontrer rapidement la valeur de vos initiatives de machine learning, concentrez-vous sur les bons indicateurs. Mesurez la puissance du modèle à l’aide de l’AUC et de la précision à k pour les classements, suivez l’impact métier à travers le chiffre d’affaires incrémental ou la baisse des taux de résiliation, surveillez la vélocité, du caractère prêt des données jusqu’au déploiement en production, et évaluez la fiabilité de l’infrastructure et son efficacité en termes de coûts par millier de prédictions.

Plan de déploiement sur 14 jours

Si vous souhaitez passer de zéro à un déploiement Fabric prêt pour la production, suivez ce plan de déploiement structuré sur deux semaines :

Jours 1 et 2 : hygiène du Lakehouse, structure bronze/silver/gold, listes de contrôle d’accès (ACL) et contrôles de qualité.
Jour 3 : mise en place des notebooks, utilitaires de données et tables d’exemple de développement.
Jours 4 et 5 : ensemble de caractéristiques v1, entraînement du modèle de référence et journalisation MLflow.
Jour 6 : suite d’évaluation, création de la fiche modèle et enregistrement du modèle (v0.1).
Jour 7 : création de la tâche de scoring par lots et intégration au tableau de bord Power BI.
Jour 8 : MVP de supervision, contrôles de dérive et journalisation opérationnelle.
Jour 9 : mise en place du workflow d’approbation et promotion en production.
Jour 10 : configuration du point de terminaison en temps réel, limitation de débit et journalisation des requêtes (le cas échéant).
Jours 11 et 12 : tests A/B, backtesting et définition des indicateurs clés métier.
Jour 13 : gouvernance des coûts, garde-fous de mise à l’échelle automatique et plan de déploiement canari.
Jour 14 : documentation du runbook, transfert à l’équipe et planification du backlog.

Pièges courants (et solutions rapides)

Même les équipes expérimentées se heurtent à des obstacles. Évitez la roulette des notebooks en verrouillant vos environnements sur les noyaux Fabric standard. Ne testez pas exclusivement sur de petits échantillons qui cassent dès qu'ils sont appliqués à l'ensemble des données. Empêchez l'apparition de modèles fantômes en production en appliquant strictement des workflows de promotion dans le registre. Maîtrisez vos coûts cloud en privilégiant le traitement par lots chaque fois que c'est possible, et en mettant en cache les caractéristiques dérivées.

Extraits de code utiles

Pour vous aider à lancer votre prochain projet, voici un court extrait montrant comment lire une version spécifique d'une table Delta :

sales_v = spark.read.option("versionAsOf", 123).table("lakehouse.gold.sales_txn")

Si vous souhaitez extraire l'importance des caractéristiques avec scikit-learn et l'enregistrer directement dans MLflow, utilisez cette approche :

import pandas as pd
fi = pd.Series(clf.feature_importances_, index=feature_cols).sort_values(ascending=False)
mlflow.log_artifact(fi.head(30).to_frame("importance").to_csv("fi.csv", index=True))

Et pour calculer le Population Stability Index (PSI) afin de détecter la dérive :

import numpy as np
def psi(expected, actual, bins=10):
    e, b = np.histogram(expected, bins=bins, range=(np.min(expected), np.max(expected)))
    a, _ = np.histogram(actual,   bins=b,     range=(np.min(expected), np.max(expected)))
    e = np.clip(e / e.sum(), 1e-6, None); a = np.clip(a / a.sum(), 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

Si vous le souhaitez, indiquez les noms de vos tables Lakehouse actuelles et un cas d'usage cible, comme le désabonnement client (churn), le scoring de prospects ou la prévision de la demande, dans les commentaires ou contactez-moi directement. Je vous proposerai un jeu de caractéristiques minimal, un choix de modèle de référence et l'articulation exacte entre traitement par lots ou temps réel, afin de vous aider à mettre rapidement en production votre premier déploiement Microsoft Fabric !