Les architectures Data se sont enrichies au fil des années : Data Lakes, Data Warehouses, ETL/ELT, moteurs Spark, outils de gouvernance, plateformes BI… Cette spécialisation a permis de répondre à des besoins toujours plus complexes, au prix d’une fragmentation croissante des données, des outils et des responsabilités.
Avec Microsoft Fabric, la promesse est différente : réunir Data Engineering, Data Factory, Data Science, Real-Time Intelligence et Power BI autour d’un socle commun, OneLake.
Mais une plateforme unifiée produit-elle réellement une architecture Data plus simple ?
OneLake change la logique, pas les fondamentaux
OneLake fournit un Data Lake logique unique au niveau du tenant Fabric. Associé aux formats ouverts et aux shortcuts, il permet à différents workloads d’accéder à la donnée sans systématiquement la déplacer ou la dupliquer.
C’est probablement l’un des apports architecturaux les plus intéressants de Fabric : réduire les copies et rapprocher les moteurs de traitement d’une même couche de données.
Pour autant, « OneLake » ne signifie pas « un seul Lakehouse pour toute l’entreprise ».
La question essentielle reste celle du découpage. Par domaines ? Par produits Data ? Par niveaux de maturité ? Par environnement ? Microsoft recommande d’ailleurs de séparer les couches d’une architecture medallion dans différents workspaces afin de renforcer le contrôle et la gouvernance.
Autrement dit, Fabric réduit la fragmentation technique, mais l’architecture doit toujours organiser la complexité métier.
Lakehouse ou Warehouse : le choix reste structurant
Fabric ne fait pas disparaître l’arbitrage entre Lakehouse et Data Warehouse.
Un environnement orienté Data Engineering, Spark, Machine Learning et données structurées ou non structurées trouvera naturellement sa place dans un Lakehouse. Un environnement fortement SQL, destiné au décisionnel et nécessitant notamment des transactions multi-tables, pourra davantage s’appuyer sur le Warehouse.
Dans les architectures les plus intéressantes, la réponse peut d’ailleurs être : les deux.
Une architecture medallion peut par exemple conserver les données brutes et enrichies dans des Lakehouses Bronze et Silver, puis exposer une couche Gold dans un Warehouse destinée aux usages analytiques. Microsoft documente explicitement ce modèle.
Le choix ne devrait donc pas être guidé par la volonté de « tout mettre dans Fabric », mais par la nature des workloads, les patterns d’accès à la donnée et les compétences des équipes.
Direct Lake rapproche réellement Data Engineering et BI
L’intégration avec Power BI est probablement l’un des arguments les plus forts de Fabric.
Avec Direct Lake, Power BI peut exploiter les tables présentes dans OneLake sans reproduire le fonctionnement classique d’un import complet et de ses cycles de rafraîchissement. Les requêtes restent traitées par le moteur VertiPaq, avec l’objectif de combiner performances analytiques et réduction de la latence entre préparation et consommation de la donnée.
C’est une évolution importante : le modèle sémantique Power BI se rapproche considérablement de la plateforme Data.
Mais cela crée aussi une dépendance plus forte entre les deux mondes. La performance d’un rapport devient directement liée à la qualité de l’architecture en amont. Microsoft souligne notamment que les performances de Direct Lake dépendent de tables Delta correctement optimisées.
Le Data Engineer et l’expert BI ne peuvent donc plus travailler en silos.
Le véritable risque : confondre plateforme unifiée et gouvernance unifiée
C’est probablement le point sur lequel les projets Fabric doivent être les plus vigilants.
Centraliser techniquement les données ne résout pas automatiquement les questions de propriété, de qualité ou de responsabilité. Qui possède le Data Product ? Qui peut publier une couche Gold ? Quel modèle sémantique fait référence ? Comment gérer les accès entre domaines ? Comment organiser Dev, Test et Production ?
Les architectures de référence Microsoft traitent justement la gouvernance comme une préoccupation transverse : identité, RBAC, lineage, pipelines de déploiement et modèles sémantiques certifiés doivent fonctionner ensemble.
Une mauvaise gouvernance dans une plateforme très intégrée peut simplement permettre de créer du désordre plus rapidement.
Et le coût ? Un sujet d’architecture à part entière
Fabric introduit également un changement dans la manière de penser les ressources : pipelines, requêtes, traitements Spark et workloads analytiques consomment une capacité partagée exprimée en Capacity Units (CU).
Une architecture techniquement élégante peut donc devenir économiquement inefficace si les workloads, les pics de consommation ou les environnements sont mal dimensionnés.
Le FinOps ne doit pas intervenir une fois la plateforme déployée. Le dimensionnement des capacités, le monitoring de leur consommation et l’isolation éventuelle de certains workloads font partie des décisions d’architecture.
Alors, Fabric change-t-il réellement l’architecture Data ?
Oui, mais probablement pas de la manière dont on pourrait le penser.
Fabric ne supprime ni le besoin d’un Data Architect, ni celui d’un Data Engineer, ni les arbitrages entre Lakehouse, Warehouse, streaming, BI et gouvernance. La plateforme propose aujourd’hui plusieurs stores spécialisés — Lakehouse, Warehouse, Eventhouse ou encore SQL Database — qui répondent à des workloads différents.
Sa force est plutôt de permettre à ces composants de fonctionner autour d’un socle Data commun.
Pour une organisation déjà fortement engagée dans l’écosystème Microsoft, cela peut réduire significativement la complexité d’intégration entre Data Engineering, gouvernance et Power BI.
Mais le véritable enjeu reste inchangé : concevoir la bonne architecture avant de choisir les outils qui la composent.
C’est précisément sur ces problématiques qu’interviennent les expertises Data, BI & IA : architecture Data, Data Engineering, plateformes Cloud, pipelines ETL/ELT, gouvernance, qualité et Business Intelligence.
→ Data, BI & Intelligence Artificielle
Architecture Data, Data Engineering, Data Lakes & Warehouses, pipelines ETL/ELT, gouvernance et qualité des données, Power BI et Machine Learning.
Architecture Cloud, infrastructures, automatisation et conception d’environnements capables de supporter les nouvelles plateformes Data.
Découvrez plus largement les métiers et expertises mobilisés autour de la transformation digitale et de la donnée.
→ Toutes les expertises Antaes
Retrouvez l’ensemble des domaines d’intervention et métiers Antaes.
.png)