Lorsqu’on découvre Microsoft Fabric, une première difficulté apparaît rapidement : le nombre d’objets disponibles dans un workspace.
Lakehouse, Warehouse, Semantic Model, Report, Notebook, Data Pipeline, Dataflow Gen2, Eventstream, Eventhouse, KQL Queryset, Real-Time Dashboard, Activator, Mirrored Database…
Pris individuellement, chacun de ces composants est relativement compréhensible. La difficulté architecturale commence lorsqu’il faut répondre à une question beaucoup plus concrète :
lesquels faut-il réellement utiliser, et comment les assembler pour répondre à un scénario analytique ?
C’est précisément à ce niveau que Fabric devient intéressant.
Il ne faut pas considérer la plateforme comme un catalogue d’outils indépendants, mais comme un ensemble de briques spécialisées que l’on combine selon plusieurs patterns d’architecture récurrents.
Microsoft présente Fabric comme une plateforme analytique end-to-end couvrant ingestion, transformation, data engineering, data science, data warehousing, analyse temps réel et Business Intelligence. Tous ces workloads partagent notamment OneLake et un environnement SaaS commun.
La bonne question n’est donc pas :
« À quoi sert chaque objet Fabric ? »
mais plutôt :
« Quel chemin doit suivre la donnée pour répondre à mon scénario analytique ? »
C’est à partir de cette question que les principaux patterns Fabric deviennent beaucoup plus lisibles.
1. Le socle : OneLake avant les workloads
Avant de parler de Lakehouse, Warehouse ou Power BI, il faut comprendre le choix architectural fondamental de Fabric : OneLake.
OneLake est le data lake logique commun au tenant Fabric. Microsoft le présente comme un data lake unifié à l’échelle de l’organisation.
L’idée est importante.
Dans une architecture Azure analytique traditionnelle, différentes technologies pouvaient posséder leur propre stockage ou nécessiter des mouvements de données entre services.
Fabric cherche au contraire à rapprocher les moteurs de calcul d’une couche de données commune.
On peut donc schématiser la philosophie Fabric ainsi :
MICROSOFT FABRIC
Data Factory Data Engineering Data Science
│ │ │
├─────────────────┼─────────────────┤
│ │ │
Warehouse Real-Time Power BI
│ Intelligence │
└─────────────────┬─────────────────┘
│
OneLake
Les workloads ne disparaissent pas.
Ils continuent d’utiliser des moteurs différents adaptés à leurs usages. Mais ils évoluent dans un environnement commun et peuvent travailler sur les mêmes actifs de données avec beaucoup moins de friction.
C’est cette architecture qui permet ensuite de construire plusieurs patterns.
Illustration Microsoft : architecture générale Microsoft Fabric / OneLake.
Page Microsoft Learn :
https://learn.microsoft.com/en-us/fabric/get-started/microsoft-fabric-overview
2. Pattern n°1 — La chaîne analytique Fabric classique
Le pattern le plus simple et probablement le plus important est celui d’une plateforme BI moderne.
Sources
│
▼
Pipeline / Dataflow
│
▼
Lakehouse ou Warehouse
│
▼
Semantic Model
│
▼
Power BI Report
│
▼
Utilisateurs métier
Chaque couche possède une responsabilité différente.
Pipeline / Dataflow transporte et orchestre la donnée.
Lakehouse ou Warehouse constitue la couche analytique persistante.
Semantic Model transforme les données techniques en concepts métier.
Power BI constitue la couche de consommation.
Ce découpage est essentiel parce qu’il évite de construire des rapports Power BI directement branchés sur une multitude de systèmes opérationnels.
On introduit progressivement des contrats entre couches.
SYSTÈMES SOURCES
↓
INGESTION
↓
DATA PLATFORM
↓
SEMANTIC LAYER
↓
PRESENTATION
C’est probablement le pattern Fabric le plus pertinent pour une organisation dont le besoin principal reste la Business Intelligence.
3. Le rôle du Pipeline : déplacer et orchestrer
Dans cette architecture, le Data Pipeline joue généralement le rôle d’orchestrateur.
Il peut par exemple exécuter :
Extraction ERP
↓
Extraction CRM
↓
Chargement Lakehouse
↓
Exécution Notebook
↓
Transformation Silver
↓
Transformation Gold
↓
Actualisation des objets aval
Le Pipeline ne constitue donc pas nécessairement l’endroit où toute la logique métier doit être développée.
Il peut simplement orchestrer les différentes étapes.
Cette distinction devient particulièrement utile lorsque la plateforme grandit.
Le Pipeline répond essentiellement à :
Quand et dans quel ordre les traitements doivent-ils s’exécuter ?
Le Notebook, le Dataflow ou le moteur SQL répondent davantage à :
Comment transformer les données ?
4. Dataflow Gen2 ou Notebook : deux philosophies de transformation
Fabric offre plusieurs façons de transformer les données.
Deux approches apparaissent fréquemment.
Dataflow Gen2
Dataflow Gen2 s’inscrit dans l’écosystème Power Query.
Il convient particulièrement aux transformations relativement tabulaires et aux équipes qui travaillent déjà avec Power BI, Excel ou Power Query.
Le pattern ressemble alors à :
Sources
↓
Dataflow Gen2
↓
Lakehouse / Warehouse
↓
Semantic Model
C’est une approche low-code particulièrement accessible aux BI Developers et Data Analysts.
Notebook
Le Notebook correspond davantage au monde Data Engineering.
Sources
↓
Lakehouse
↓
Notebook PySpark
↓
Tables transformées
Il devient intéressant lorsque les traitements nécessitent :
- Python ;
- PySpark ;
- Spark SQL ;
- transformations complexes ;
- gros volumes ;
- traitements distribués ;
- data science ;
- enrichissements algorithmiques.
Ces deux composants ne sont donc pas réellement concurrents.
Ils correspondent à deux niveaux de complexité et deux populations différentes.
5. Pattern n°2 — Le Lakehouse Medallion
Lorsque les traitements deviennent plus importants, un deuxième pattern apparaît : l’architecture Medallion.
Microsoft la recommande explicitement comme approche de conception pour organiser les données dans un Lakehouse Fabric.
Elle repose généralement sur trois niveaux :
SOURCES
│
▼
┌─────────┐
│ BRONZE │
└────┬────┘
│
transformations
│
▼
┌─────────┐
│ SILVER │
└────┬────┘
│
transformations
│
▼
┌─────────┐
│ GOLD │
└────┬────┘
│
▼
Semantic Models
│
▼
Power BI
Bronze
La couche Bronze conserve les données au plus près de la source.
L'objectif principal est la fidélité.
On évite d'y introduire trop tôt des règles métier complexes.
Silver
Silver représente les données nettoyées, standardisées, dédupliquées et intégrées.
C'est ici que l'on commence à résoudre :
- types incorrects ;
- doublons ;
- formats ;
- identifiants ;
- valeurs invalides ;
- jointures ;
- normalisation.
Gold
Gold correspond aux données prêtes pour les usages analytiques.
On peut y retrouver :
- tables de faits ;
- dimensions ;
- agrégats ;
- datasets métier ;
- tables préparées pour les Semantic Models.
Microsoft utilise précisément cette logique Bronze → Silver → Gold dans son scénario Lakehouse end-to-end Fabric.
Illustration Microsoft recommandée : Medallion Architecture Fabric.
Page Microsoft Learn :
https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture
C'est probablement l'un des meilleurs schémas à intégrer dans un article sur Fabric.
6. Pourquoi Lakehouse occupe une position aussi centrale
Le Lakehouse est particulièrement intéressant parce qu'il sert de point de rencontre entre plusieurs populations.
Un Data Engineer peut travailler dessus avec Spark.
Un développeur SQL peut accéder aux tables via le SQL Analytics Endpoint.
Un Data Scientist peut exploiter les mêmes données depuis un Notebook.
Power BI peut finalement consommer les tables Delta via un Semantic Model.
On obtient donc :
LAKEHOUSE
│
┌────────────────┼────────────────┐
│ │ │
Spark SQL Semantic Model
│ │ │
Data Engineer SQL Developer Power BI
Cette polyvalence explique pourquoi le Lakehouse apparaît dans énormément de scénarios Fabric.
7. Pattern n°3 — Warehouse-first
Il serait néanmoins erroné d'en conclure que toute architecture Fabric doit être Lakehouse-first.
Fabric possède un véritable moteur Warehouse.
Le pattern devient :
Sources
↓
Data Pipeline
↓
Fabric Warehouse
↓
Star Schema
↓
Semantic Model
↓
Power BI
Cette architecture est particulièrement naturelle pour une organisation fortement orientée :
- SQL ;
- data warehouse traditionnel ;
- modèle dimensionnel ;
- tables de faits et dimensions ;
- T-SQL ;
- BI structurée.
Microsoft distingue clairement les deux approches.
Le Lakehouse est privilégié lorsque Spark, les données structurées et non structurées et l'approche Data Engineering sont importantes.
Le Warehouse fournit une expérience SQL plus complète, notamment DML, DDL et transactions T-SQL.
La question n'est donc pas :
Lakehouse ou Warehouse : lequel est meilleur ?
mais :
Quel moteur correspond au mode de travail et au workload de l'équipe ?
8. Pattern n°4 — Architecture hybride Lakehouse + Warehouse
Une architecture Fabric peut également combiner les deux.
C'est même un pattern particulièrement intéressant.
SOURCES
│
▼
LAKEHOUSE
│
Bronze → Silver
│
▼
WAREHOUSE
│
modèle métier
│
▼
Semantic Model
│
▼
Power BI
Le Lakehouse absorbe alors les problématiques Data Engineering.
Le Warehouse fournit une couche relationnelle analytique plus traditionnelle.
Microsoft indique explicitement que Lakehouse et Warehouse peuvent être combinés dans les architectures analytiques d'entreprise.
Cela permet d'éviter une guerre technologique artificielle entre SQL et Spark.
Les deux moteurs peuvent intervenir là où ils sont les plus pertinents.
9. Pattern n°5 — Semantic Model comme contrat métier
Une erreur fréquente consiste à considérer le Semantic Model comme un simple intermédiaire technique nécessaire à Power BI.
Son rôle peut être beaucoup plus stratégique.
Prenons dix rapports :
Report Finance
Report Direction
Report Commercial
Report Région
Report Produit
Report Client
...
Une architecture fragile consisterait à recréer la logique métier dans chaque rapport.
Une architecture plus industrialisée consiste à créer :
GOLD DATA
│
▼
SEMANTIC MODEL
│
┌─────────┼─────────┐
↓ ↓ ↓
Report A Report B Report C
Le Semantic Model devient alors le contrat analytique.
On y définit :
- relations ;
- hiérarchies ;
- mesures DAX ;
- KPI ;
- dimensions ;
- sécurité ;
- vocabulaire métier.
Le chiffre d'affaires n'est plus redéfini dans quinze rapports.
Il existe une définition analytique commune.
10. Direct Lake change la relation entre stockage et BI
C'est ici qu'apparaît l'une des innovations architecturales les plus caractéristiques de Fabric : Direct Lake.
Historiquement, Power BI fonctionnait principalement selon deux logiques.
Import
Data Warehouse
↓
copie
↓
Power BI / VertiPaq
DirectQuery
Power BI
↓
requête
↓
Database
Fabric introduit une troisième approche :
OneLake
│
Delta Tables
│
▼
Direct Lake
│
▼
Semantic Model
│
▼
Power BI
Direct Lake permet au Semantic Model de charger à la demande les colonnes provenant des tables Delta OneLake dans le moteur analytique en mémoire.
L'objectif est particulièrement intéressant :
obtenir une expérience analytique proche de l'Import tout en évitant le processus classique de copie et de refresh complet du modèle.
Microsoft positionne notamment Direct Lake comme un excellent candidat pour la couche Gold d'une architecture Medallion.
On obtient alors un pattern Fabric particulièrement cohérent :
Bronze
↓
Silver
↓
Gold Delta
↓
Direct Lake
↓
Semantic Model
↓
Power BI
Illustration Microsoft : fonctionnement de Direct Lake.
Page Microsoft Learn :
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview
11. Pattern n°6 — Shortcut : analyser sans systématiquement déplacer
Un autre changement architectural important concerne le mouvement des données.
L'architecture analytique traditionnelle applique souvent :
Source
↓
Copy
↓
Data Lake
Fabric propose également OneLake Shortcuts.
Un Shortcut fonctionne conceptuellement comme un lien vers des données situées ailleurs.
Microsoft explique que les Shortcuts permettent d'unifier les données entre domaines, comptes et clouds et peuvent réduire les copies intermédiaires et la latence associée aux opérations de staging.
Le pattern devient :
ADLS ─────────────┐
│
Amazon S3 ────────┼──► Shortcuts ──► OneLake namespace
│
Other OneLake ────┘
Le principe architectural est puissant :
ne pas déplacer une donnée uniquement parce qu'un autre moteur doit la lire.
Cela ne supprime évidemment pas tous les besoins d'ETL.
Mais cela introduit une nouvelle question dans la conception :
Dois-je copier cette donnée ou simplement la référencer ?
Cette question peut avoir des conséquences importantes sur :
- stockage ;
- fraîcheur ;
- duplication ;
- gouvernance ;
- temps de traitement.
Illustration Microsoft : OneLake Shortcuts.
Page Microsoft Learn :
https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts
12. Pattern n°7 — Mirroring : rapprocher l'opérationnel de l'analytique
Fabric propose également une autre manière de réduire la plomberie d'intégration : Mirroring.
Mirroring permet de répliquer continuellement des données provenant de systèmes opérationnels vers OneLake.
Microsoft le positionne comme une solution de réplication à faible latence et entièrement managée.
On obtient :
Operational Database
│
│ Mirroring
▼
OneLake
│
├── Spark
├── Notebook
├── SQL
└── Power BI
L'intérêt est évident lorsqu'une entreprise possède une base opérationnelle qui doit être analysée fréquemment.
L'alternative classique serait :
Database
↓
CDC
↓
Pipeline
↓
Staging
↓
Merge
↓
Analytics
Mirroring cherche à réduire une partie de cette infrastructure.
Il ne faut toutefois pas confondre Mirroring et Shortcut.
Le Shortcut référence principalement une donnée existante.
Mirroring peut réellement maintenir une réplication de données dans OneLake. Microsoft distingue désormais plusieurs approches, dont database mirroring, metadata mirroring et open mirroring.
Illustration Microsoft : Fabric Mirroring.
Page Microsoft Learn :
https://learn.microsoft.com/en-us/fabric/mirroring/overview
13. Pattern n°8 — Le temps réel est une architecture différente
Toutes les données ne suivent pas nécessairement :
Pipeline → Lakehouse → Semantic Model → Report
Pour les événements, logs, IoT ou télémétrie, Fabric propose Real-Time Intelligence.
Le pattern principal devient :
Kafka / Event Hub / IoT / Events
│
▼
Eventstream
│
▼
Eventhouse
│
▼
KQL Queryset
│
┌──────┴──────┐
▼ ▼
Real-Time Power BI
Dashboard
│
▼
Activator
Microsoft décrit Real-Time Intelligence comme une solution end-to-end couvrant ingestion, transformation, stockage, analyse, visualisation et action sur les données en mouvement.
Les composants possèdent ici des responsabilités particulièrement claires.
Eventstream
Il reçoit et route les flux d'événements.
Eventhouse
Il stocke et analyse de grands volumes de données événementielles.
KQL Queryset
Il fournit l'environnement de requêtage KQL.
Real-Time Dashboard
Il permet de suivre les données à mesure qu'elles arrivent.
Activator
Il permet de déclencher une action lorsqu'une condition est rencontrée.
Microsoft résume d'ailleurs exactement cette chaîne dans son guide de démarrage Real-Time Intelligence.
Illustration Microsoft fortement recommandée : architecture Real-Time Intelligence.
Page Microsoft Learn :
https://learn.microsoft.com/en-us/fabric/real-time-intelligence/overview
14. Analytics historique et analytics opérationnel
Cette distinction permet de comprendre deux familles de workloads.
Analytics décisionnel
ERP
CRM
Finance
RH
↓
Data Factory
↓
Lakehouse / Warehouse
↓
Semantic Model
↓
Power BI
Question :
Quelle était notre marge par produit et par région sur les douze derniers mois ?
Analytics temps réel
Applications
Machines
Transactions
Logs
↓
Eventstream
↓
Eventhouse
↓
KQL
↓
Real-Time Dashboard
Question :
Que se passe-t-il actuellement ?
Et Activator ajoute une troisième dimension :
Que devons-nous faire lorsque quelque chose se produit ?
On passe donc progressivement :
DESCRIBE
Que s'est-il passé ?
↓
MONITOR
Que se passe-t-il ?
↓
ACT
Que devons-nous déclencher ?
C'est une distinction importante pour comprendre la portée de Fabric.
15. Un même environnement peut combiner batch et temps réel
Ces patterns ne sont évidemment pas exclusifs.
Une entreprise industrielle pourrait construire :
FABRIC
│
┌────────────────┴────────────────┐
│ │
HISTORIQUE LIVE
│ │
Pipeline Eventstream
│ │
Lakehouse Eventhouse
│ │
Semantic Real-Time
Model Dashboard
│
└──────────────┬──────────────────┘
│
Power BI
Le reporting stratégique peut ainsi exploiter les données historiques tandis que les équipes opérationnelles observent les événements quasiment en temps réel.
16. Les composants Fabric deviennent finalement beaucoup plus lisibles
Si l'on raisonne par responsabilité plutôt que par catalogue de fonctionnalités, l'écosystème peut être résumé ainsi :
| Besoin | Composant principal |
|---|---|
| Ingestion batch | Pipeline |
| Transformation low-code | Dataflow Gen2 |
| Data Engineering | Notebook / Spark |
| Stockage Lakehouse | Lakehouse |
| Data Warehouse SQL | Warehouse |
| Accès SQL au Lakehouse | SQL Analytics Endpoint |
| Référencer des données externes | Shortcut |
| Répliquer une base | Mirroring |
| Modèle métier BI | Semantic Model |
| Visualisation décisionnelle | Power BI Report |
| Ingestion streaming | Eventstream |
| Stockage événementiel | Eventhouse |
| Analyse événementielle | KQL |
| Visualisation live | Real-Time Dashboard |
| Réaction automatique | Activator |
Ce tableau permet déjà de lire beaucoup plus facilement un workspace Fabric.
17. Les principaux patterns à retenir
Au lieu de mémoriser vingt produits, il est plus utile de retenir quelques chaînes.
BI moderne
Pipeline
→ Lakehouse
→ Semantic Model
→ Power BI
BI SQL
Pipeline
→ Warehouse
→ Semantic Model
→ Power BI
Data Engineering / Medallion
Pipeline
→ Bronze
→ Notebook
→ Silver
→ Notebook
→ Gold
→ Semantic Model
Architecture hybride
Lakehouse
→ Warehouse
→ Semantic Model
→ Power BI
Zero-copy
External Data
→ Shortcut
→ Lakehouse
→ Analytics
Réplication opérationnelle
Operational DB
→ Mirroring
→ OneLake
→ Analytics
Real-Time Intelligence
Events
→ Eventstream
→ Eventhouse
→ KQL
→ Real-Time Dashboard
→ Activator
Ces patterns couvrent déjà une très grande partie des architectures analytiques que Fabric cherche à adresser.
18. Ce que Fabric change réellement dans l'architecture analytique
Pris séparément, beaucoup de composants Fabric ont des équivalents historiques.
Les pipelines existaient.
Les data lakes existaient.
Spark existait.
Les data warehouses existaient.
Power BI existait.
Les moteurs événementiels existaient également.
La proposition de Fabric se situe ailleurs : réduire les frontières entre ces mondes.
Microsoft standardise notamment une partie importante du stockage analytique autour de OneLake et du format Delta. Son propre scénario Lakehouse explique que l'unification du stockage et la standardisation sur Delta permettent de réduire les silos et la duplication entre architectures lakehouse et warehouse.
Cela conduit progressivement à une architecture dans laquelle plusieurs moteurs travaillent autour du même patrimoine analytique :
USERS
│
┌─────────────┴─────────────┐
│ │
Power BI Real-Time Dashboard
│ │
Semantic Models KQL
│ │
┌───────┴────────┐ Eventhouse
│ │ │
Warehouse Lakehouse Eventstream
│ │ │
└──────────── OneLake ──────────────┘
│
┌───────────────┼─────────────────┐
│ │ │
Pipeline Mirroring Shortcuts
│ │ │
└──────────── SOURCES ────────────┘
C'est probablement ce schéma mental qui permet le mieux de comprendre Microsoft Fabric.
Conclusion
Microsoft Fabric devient beaucoup plus simple à comprendre lorsqu'on cesse de raisonner en liste de fonctionnalités.
Un Pipeline orchestre.
Un Dataflow transforme en low-code.
Un Notebook traite et transforme par le code.
Un Lakehouse fournit la plateforme data ouverte et orientée engineering.
Un Warehouse fournit l'expérience analytique SQL.
Un Shortcut évite certaines copies.
Mirroring rapproche les bases opérationnelles de OneLake.
Le Semantic Model transforme les données en langage métier.
Power BI les restitue.
Et lorsqu'on quitte le monde batch pour les données en mouvement, Eventstream, Eventhouse, KQL, Real-Time Dashboard et Activator constituent une chaîne spécialisée.
L'enjeu architectural n'est donc pas d'utiliser le maximum de composants Fabric.
Il est au contraire de sélectionner le plus petit ensemble de briques capable de former une chaîne cohérente pour le scénario considéré.
Pour une plateforme BI classique, cette chaîne peut être aussi simple que :
Sources
↓
Pipeline
↓
Lakehouse
↓
Semantic Model
↓
Power BI
Pour une plateforme Data Engineering, elle peut devenir :
Sources
↓
Pipeline
↓
Bronze
↓
Notebook
↓
Silver
↓
Notebook
↓
Gold
↓
Direct Lake
↓
Semantic Model
↓
Power BI
Et pour un système événementiel :
Events
↓
Eventstream
↓
Eventhouse
↓
KQL
↓
Real-Time Dashboard
↓
Activator
Trois architectures, trois besoins différents, mais une même plateforme.
C'est précisément là que se trouve la proposition architecturale de Microsoft Fabric : ne plus choisir un outil analytique isolé, mais composer un parcours de données à partir de workloads spécialisés partageant un socle commun.
Documentation Microsoft pour les illustrations
- Vue générale Fabric / OneLake
https://learn.microsoft.com/en-us/fabric/get-started/microsoft-fabric-overview - Architecture Lakehouse end-to-end
https://learn.microsoft.com/en-us/fabric/data-engineering/tutorial-lakehouse-introduction - Architecture Medallion
https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture - Direct Lake
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview - Lakehouse vs Warehouse
https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-lakehouse-warehouse - OneLake Shortcuts
https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts - Mirroring
https://learn.microsoft.com/en-us/fabric/mirroring/overview - Real-Time Intelligence
https://learn.microsoft.com/en-us/fabric/real-time-intelligence/overview