Moderniser sa Data Stack avec Microsoft Fabric

Microsoft Fabric : rupture ou rebranding ?

Depuis son annonce à Build 2023, Microsoft Fabric polarise les équipes data. Certains y voient un rebranding d'Azure Synapse. C'est une lecture trop courte. Fabric est une rupture architecturale : là où Synapse vous demandait d'orchestrer plusieurs services distincts (Data Factory, Synapse Analytics, Power BI Premium), Fabric les intègre dans une expérience unifiée avec un stockage commun, OneLake.

Après avoir accompagné plusieurs organisations dans l'adoption de Fabric, voici un bilan basé sur des projets en production : les forces réelles, les pièges à éviter, et comment structurer une architecture médaillon qui tient.

OneLake : le changement fondamental

Avant Fabric, une stack Azure data typique ressemblait à ceci : Azure Data Lake Storage Gen2 pour le stockage brut, Azure Data Factory pour les pipelines, Synapse ou Databricks pour la transformation, Power BI Premium connecté par-dessus. Chaque service avait son compte de stockage, ses identités managées, ses coûts propres.

Fabric change ce modèle. Tout réside dans OneLake, un seul lac de données hiérarchique par tenant. Un fichier Parquet écrit par un notebook Spark est immédiatement accessible dans Power BI via un Semantic Model, sans copie, sans déplacement, sans pipeline intermédiaire.

C'est ce changement de modèle de stockage qui rend Fabric intéressant, pas les interfaces.

Architecture médaillon sur Fabric

L'architecture médaillon (Bronze, Silver, Gold) reste la référence pour organiser les données dans un lakehouse. Fabric la supporte nativement via les Lakehouses.

Couche Bronze : ingestion brute

Les pipelines Data Factory intégrés à Fabric s'occupent de l'ingestion. Nous configurons une ingestion en mode append-only vers des tables Delta Bronze. Rien n'est écrasé, tout est versionné. Un point d'attention : Fabric Data Factory n'a pas encore la parité complète avec Azure Data Factory v2. Certains connecteurs spécifiques (SAP, APIs legacy) nécessitent encore des pipelines ADF classiques connectés via OneLake Shortcuts.

Couche Silver : nettoyage et conformité

La couche Silver est traitée par des notebooks Spark. Nous appliquons systématiquement trois règles :

Couche Gold : modèles métier

La couche Gold expose les données sous forme de tables orientées métier. C'est ici que les jointures complexes et les agrégations lourdes se calculent une fois, pour ne pas les répéter dans chaque rapport. Les tables Gold sont directement consommées par les Semantic Models Power BI via Direct Lake.

Power BI Semantic Models : la clé de voûte

Le Semantic Model (ex-Dataset Power BI) est l'élément le plus sous-estimé dans une architecture Fabric. C'est lui qui définit les mesures DAX, les hiérarchies, les relations et la sécurité au niveau des lignes (RLS).

Direct Lake : avantages et limites réelles

Direct Lake est le mode de connexion natif entre Fabric et Power BI. Il évite l'import des données dans le moteur Vertipaq et donne accès à des données fraîches sans planifier d'actualisations.

En pratique, Direct Lake a des limites à connaître :

Notre approche : Direct Lake pour les tableaux de bord opérationnels à fort volume, Import classique pour les rapports analytiques avec des modèles DAX complexes.

Architecture des Semantic Models partagés

Un Semantic Model ne devrait pas être une boite noire. Nous structurons systématiquement deux niveaux :

Ce pattern évite la prolifération des modèles et garantit une cohérence des métriques entre les équipes. Toutes les mesures DAX sont documentées avec des descriptions visibles dans Power BI Desktop.

Gouvernance RLS

La RLS est testée avec des profils utilisateurs représentatifs avant chaque mise en production. Nous connectons les groupes Azure AD via SCIM pour que les licences soient attribuées automatiquement selon les groupes AD. Un utilisateur qui quitte l'organisation perd son accès dans les minutes suivant sa désactivation Active Directory.

OneLake Shortcuts : migration progressive

Les shortcuts OneLake permettent de pointer vers des données dans Azure Data Lake Storage Gen2 ou Databricks sans les copier physiquement. C'est la façon élégante de migrer progressivement vers Fabric sans rompre les pipelines existants. Nous les utilisons comme pont de transition : les données restent dans leur emplacement d'origine pendant la migration, et le switch vers OneLake natif se fait domaine par domaine.

Quand adopter Fabric

Fabric est le bon choix si votre organisation est déjà dans l'écosystème Microsoft (Azure, M365, Power BI) et que vous cherchez à réduire la complexité opérationnelle en consolidant vos services data.

Fabric est probablement le mauvais choix si votre stack est fortement orientée open source (dbt, Airflow, Spark standalone) ou si vous avez des besoins ML avancés où Databricks reste supérieur.

La plateforme mûrit vite. Ce qui manquait il y a 18 mois est souvent disponible aujourd'hui.