Lakehouse Fabric : guide DSI, OPTIMIZE, VACUUM et listes de contrôle

par | 29, Août 2026

Un lakehouse dans Microsoft Fabric associe le stockage brut du data lake et les capacités transactionnelles d’un entrepôt, le tout reposant sur OneLake et le format Delta Lake pour garantir des transactions ACID. Il sert principalement à ingérer, transformer et préparer des données hétérogènes (fichiers, tables, flux) avant de les exposer aux analystes via SQL ou Power BI. Ce n’est pas un concurrent du warehouse, mais son complément naturel : l’un prépare, l’autre restitue.

En bref:

  • Le lakehouse Microsoft Fabric combine stockage de données brutes et capacités transactionnelles avec Delta Lake, facilitant l’ingestion, la transformation et la préparation des données hétérogènes.
  • La séparation entre dossiers Tables et Files, ainsi que l’utilisation de OneLake, permet un traitement fiable et versionné des données Delta tout en conservant fichiers bruts et non structurés.
  • La méthode medallion en trois couches (Bronze, Silver, Gold) optimise la gouvernance, la qualité et l’accès graduel des données en fonction des besoins des équipes.
  • La performance et les coûts du lakehouse nécessitent une maintenance régulière grâce aux commandes OPTIMIZE, VACUUM et V-order pour éviter dégradation et surcoûts.
  • La sélection entre lakehouse et warehouse doit s’appuyer sur la compétence de l’équipe, la volumétrie des données et la nécessité de transactions multi-tables, en démarrant par un POC pour valider la solution.

Table des matières

Qu’est-ce qu’un lakehouse Fabric concrètement ? OneLake, Delta Lake, Tables vs Fichiers

Le lakehouse Microsoft Fabric repose sur trois briques. OneLake fait office de magasin logique unique par tenant, sur lequel tous les workspaces Fabric viennent puiser sans dupliquer les données physiquement. Chaque lakehouse expose ensuite deux zones distinctes à l’intérieur de cet espace de stockage.

  • Le dossier Tables contient uniquement des données au format Delta, gérées, versionnées et interrogeables en SQL.
  • Le dossier Files accueille tout le reste : CSV, JSON, Parquet brut, images, fichiers non structurés qui n’ont pas encore été convertis.

Cette séparation n’est pas cosmétique. Le format Delta Lake apporte des transactions ACID, du versioning et la fonctionnalité de retour arrière (time travel), ce qui manque cruellement aux fichiers plats. Une équipe qui dépose des CSV bruts dans Files puis les transforme en tables Delta gagne en fiabilité à chaque étape du pipeline, sans avoir à gérer elle-même l’infrastructure de stockage sous-jacente, comme le précise Microsoft dans sa présentation de Fabric.

Lakehouse vs warehouse : comment choisir dans Microsoft Fabric ?

La question revient dans presque tous les projets Fabric, et la réponse honnête est rarement binaire. Le warehouse Fabric est pensé pour le reporting BI classique en T-SQL, avec des garanties transactionnelles complètes sur plusieurs tables. Le lakehouse, lui, ouvre la porte à Spark, Python et R pour traiter des volumes hétérogènes, tout en offrant un SQL analytics endpoint généré automatiquement pour les besoins de lecture.

  • Surface de développement : Spark et notebooks pour le lakehouse, T-SQL natif pour le warehouse.
  • Transactions : le warehouse gère des transactions multi-tables complètes, le SQL analytics endpoint du lakehouse reste en lecture seule.
  • Profil d’équipe : data engineers et data scientists s’orientent naturellement vers le lakehouse, analystes SQL-first vers le warehouse.

Le pattern qui fonctionne le mieux sur le terrain consiste à transformer massivement dans le lakehouse, puis à exposer un sous-ensemble curé via un warehouse quand l’équipe de reporting a besoin de garanties transactionnelles strictes. C’est exactement la logique que Biworks applique dans ses projets de conseil en business intelligence Power BI : le lakehouse absorbe la complexité, le warehouse simplifie la restitution.

Comment organiser un lakehouse avec l’architecture medallion ?

L’architecture medallion reste la méthode de référence pour structurer un lakehouse Fabric sans finir avec un fourre-tout ingérable. Elle découpe le flux de données en trois couches successives, chacune avec un rôle précis.

  1. Bronze : les données brutes, telles qu’extraites des sources (ERP, CRM, fichiers plats), sans transformation. On y tolère les doublons et les formats hétérogènes.
  2. Silver : les données nettoyées, dédupliquées, typées correctement et jointes entre elles. C’est la couche où l’on résout les incohérences métier.
  3. Gold : des modèles curés, agrégés, prêts à être consommés par Power BI ou des applications métier, souvent organisés en schéma en étoile.

Sur le plan opérationnel, isoler ces couches par workspace ou par lakehouse séparé facilite la gouvernance : on peut restreindre l’accès à Bronze aux seuls ingénieurs data, tout en ouvrant Gold à l’ensemble des analystes. Concrètement, une équipe qui centralise les ventes et les stocks peut faire atterrir les extractions ERP brutes en Bronze, résoudre les référentiels produits en Silver, puis publier une table de faits consolidée en Gold, directement branchée sur un rapport Power BI en mode Direct Lake. Ce découpage limite aussi le risque de casser un rapport en production quand on modifie une transformation intermédiaire.

Comment ingérer, transformer et consulter les données du lakehouse ?

Le flux type d’un lakehouse Fabric suit une logique simple : on fait entrer la donnée, on la transforme, puis on la rend consultable. Fabric propose plus de 200 connecteurs via les pipelines et les Dataflows Gen2 pour couvrir la majorité des sources d’entreprise (bases SQL, API, fichiers plats, SaaS métiers).

  • Ingestion : pipelines pour les charges planifiées, Dataflows Gen2 pour les transformations low-code visuelles.
  • Shortcuts : à privilégier quand la source est déjà dans OneLake ou dans un stockage compatible, pour éviter une copie physique inutile.
  • Transformation : notebooks Spark ou jobs Spark pour la logique complexe, Dataflows pour les enchaînements plus simples.
  • Consultation : le SQL analytics endpoint pour les requêtes T-SQL classiques, et Direct Lake pour brancher Power BI directement sur les tables Delta sans import ni DirectQuery.

Conseil de pro : Ne copiez jamais une donnée par réflexe. Si la source est déjà accessible et gouvernée dans OneLake, un shortcut vous évite une duplication coûteuse et garde vos données synchronisées en temps réel, sans job de rafraîchissement à maintenir.

Cette combinaison notebooks plus SQL endpoint plus Direct Lake couvre la quasi-totalité des besoins d’une équipe data, du data engineer qui écrit du PySpark à l’analyste qui construit un tableau de bord.

Mains connectant du matériel de données dans une baie informatique

Comment optimiser les performances et les coûts d’un lakehouse Fabric ?

Un lakehouse mal entretenu se dégrade vite. Les tables Delta accumulent des petits fichiers à chaque écriture incrémentale, ce qui ralentit les lectures et gonfle la facture de calcul. Trois leviers permettent de garder un lakehouse performant.

  • OPTIMIZE compacte les petits fichiers Delta en fichiers plus volumineux, à lancer régulièrement sur les tables à forte fréquence d’écriture.
  • VACUUM supprime les anciens fichiers devenus obsolètes après compaction, réduisant le volume de stockage facturé.
  • V-order et Z-order réorganisent physiquement les données au moment de l’écriture pour accélérer les lectures, en particulier via Power BI en mode Direct Lake.

Plutôt que de lancer ces commandes manuellement, Fabric permet d’automatiser tout cela via la fonctionnalité Lakehouse Maintenance, intégrable directement dans un pipeline planifié. Une cadence régulière suffit généralement pour les tables volumineuses, et une fréquence plus rapprochée est recommandée pour celles qui reçoivent des flux continus. Ignorer cette maintenance est l’une des causes les plus fréquentes de dérive des coûts observées sur les projets Fabric.

Comment gouverner et partager les données d’un lakehouse en toute sécurité ?

La gouvernance d’un lakehouse Fabric s’appuie sur deux piliers : la découverte des données et le contrôle des accès. Le OneLake Catalog recense automatiquement les tables et fichiers disponibles dans le tenant, avec leurs métadonnées, ce qui évite qu’un analyste recrée une table qui existe déjà ailleurs.

  • OneLake Catalog : cataloguez systématiquement vos tables Gold pour qu’elles soient découvrables par les autres équipes.
  • Shortcuts : permettent d’accéder à une donnée en place, sans la dupliquer, tout en conservant la gouvernance de la source d’origine.
  • Partage cross-tenant : Fabric autorise le partage gouverné entre organisations sans transfert physique, un point que détaille aussi Nectos dans son analyse des flux de données.

Sur le plan sécurité, appliquez des politiques d’accès au niveau workspace pour la couche Bronze, et des permissions plus larges sur Gold une fois les données validées. Cette granularité limite l’exposition des données sensibles tout en gardant les rapports finaux accessibles à l’ensemble des équipes métier.

Faut-il choisir un lakehouse ou un warehouse pour votre projet ?

Avant de trancher, passez votre projet par une checklist simple. Elle évite bien des choix d’architecture faits par habitude plutôt que par nécessité.

  1. Évaluez les compétences disponibles : une équipe SQL-first ira plus vite avec un warehouse ; une équipe à l’aise en Python ou Scala tirera parti du lakehouse.
  2. Mesurez la volumétrie et l’hétérogénéité : des fichiers non structurés en grand volume orientent naturellement vers le lakehouse.
  3. Identifiez le besoin de transactions multi-tables : s’il est fort, un warehouse reste plus sûr en bout de chaîne.
  4. Démarrez petit : un POC avec un modèle medallion minimal (Bronze et Gold seulement) valide l’approche avant d’investir dans Silver et l’automatisation complète.

Pour un projet de science des données ou de machine learning, le lakehouse s’impose presque toujours. Pour un reporting financier mensuel classique, un warehouse alimenté par des extractions du lakehouse reste souvent le choix le plus stable pour les équipes.

Point de vue Biworks : adoption, risques et pièges courants

Icône infographique des risques liés à l’adoption du Lakehouse

Sur le terrain, l’erreur la plus fréquente n’est pas technique, elle est organisationnelle : des équipes déploient un lakehouse Fabric en quelques jours, puis oublient qu’un lakehouse se maintient. Sans OPTIMIZE ni VACUUM planifiés, les performances se dégradent en quelques semaines, souvent avant même que le premier rapport Power BI arrive en production.

Le deuxième piège, c’est la duplication involontaire des données faute de connaître les shortcuts. Des équipes recopient physiquement des tables déjà accessibles ailleurs dans OneLake, ce qui gonfle les coûts de stockage sans bénéfice réel. Chez Biworks, l’accompagnement de projets Fabric passe systématiquement par une revue de ces deux points avant tout déploiement en production, et par la formation certifiante PL-300 pour que les équipes internes gagnent en autonomie plutôt que de dépendre indéfiniment d’un prestataire externe.

— François

Faire concevoir votre lakehouse Fabric par des experts certifiés

Construire un lakehouse performant demande de maîtriser en même temps l’architecture medallion, les commandes de maintenance Delta et l’intégration Power BI, ce qui prend du temps à une équipe qui découvre Fabric sur le tas. Biworks accompagne les entreprises et cabinets comptables dans la conception, le déploiement et la sécurisation de leur lakehouse Fabric, avec une expertise certifiée Microsoft plutôt qu’un apprentissage par essais et erreurs.

Biworks

Cet accompagnement passe par du conseil en architecture data, l’intégration de vos sources ERP et CRM, et l’hébergement sécurisé de vos solutions cloud Microsoft. Pour les équipes qui veulent devenir autonomes, Biworks propose aussi une formation Power BI certifiante éligible au CPF, préparant à la certification PL-300, dispensée par un organisme certifié Qualiopi. Si votre projet Fabric est déjà lancé mais patine sur la structuration ou les performances, un audit de votre architecture Microsoft Fabric permet de identifier rapidement les corrections à apporter avant que les coûts ne dérapent.

Ressources officielles pour aller plus loin

Pour approfondir chaque brique évoquée ici, Microsoft Learn propose un tutoriel de bout en bout sur le lakehouse, ainsi qu’une documentation détaillée sur l’architecture medallion dans OneLake. Les ateliers Fabric Analyst in a Day, organisés régulièrement par Microsoft, complètent utilement ces lectures pour une prise en main pratique.

Questions fréquentes

Qu’est-ce qu’un fabric lakehouse ?

Un lakehouse Microsoft Fabric est une architecture de données unifiée qui stocke des données structurées et non structurées dans OneLake, au format Delta Lake, avec un accès combiné via Spark et SQL.

Quelle est la différence entre lakehouse et warehouse dans Fabric ?

Le lakehouse privilégie Spark et les fichiers hétérogènes avec un accès SQL en lecture seule, tandis que le warehouse offre du T-SQL complet avec des transactions multi-tables pour le reporting structuré.

Fabric est-il meilleur que Databricks ?

Les deux plateformes reposent sur Delta Lake et Spark, mais Fabric se distingue par son intégration native à Power BI via Direct Lake et par une expérience SaaS entièrement managée sans provisionnement d’infrastructure Azure séparée.

Microsoft Fabric est-il un data lake ?

Fabric inclut un data lake unifié via OneLake, mais va au-delà en intégrant aussi le lakehouse, le warehouse, les pipelines et Power BI dans une seule plateforme cohérente.

Recommandations