OneLake est le lac de données logique et unifié inclus dans chaque tenant Microsoft Fabric. Vous y stockez une seule copie de vos données, en formats ouverts (Delta Parquet, support Apache Iceberg), accessible directement par Power BI, Spark ou SQL sans duplication. Ce principe de « one copy » supprime la multiplication des exports et des silos qui pèsent d’ordinaire sur les architectures analytiques.
En bref:
- La centralisation de données via OneLake réduit la dispersion des sources, permettant un accès direct et vizible dans Power BI, Excel ou Spark, sans duplication.
- Le choix entre shortcuts et mirroring dépend du contrôle sur la source : un shortcut pour un accès léger, un mirroring pour une copie indépendante et réplique.
- La sécurité native impose une configuration fine des droits au niveau des éléments, avec une attention particulière à la gestion du rôle par défaut et à l’utilisation de Private Link.
- OneLake alimente directement Power BI et les moteurs Fabric en tables Delta exploitables en mode import ou Direct Lake, favorisant performance et fraîcheur des données.
- Une gouvernance stricte, avec conventions et supervision, est essentielle pour éviter la dispersion et garantir une gestion cohérente des espaces de stockage.
Table des matières
- Quel est le rôle d’OneLake dans Microsoft Fabric ?
- Comment fonctionne l’architecture OneCopy d’OneLake ?
- Faut-il choisir les shortcuts ou le mirroring dans OneLake ?
- Comment fonctionne la sécurité native OneLake security ?
- Comment OneLake alimente-t-il Power BI et les moteurs Fabric ?
- Comment accéder à OneLake via ADLS Gen2 et l’explorateur Windows ?
- Quelles bonnes pratiques de gouvernance appliquer sur OneLake ?
- Perspective Biworks : quels choix stratégiques privilégier ?
- Biworks vous accompagne dans votre déploiement OneLake
- Sources
- Questions fréquentes
Quel est le rôle d’OneLake dans Microsoft Fabric ?
Chaque tenant Microsoft Fabric reçoit une instance unique de OneLake, ce qui change la donne pour les entreprises qui jonglent aujourd’hui avec des dizaines d’espaces de stockage disparates. Le catalogue OneLake centralise la découverte des jeux de données et applique les règles de gouvernance à un seul endroit, quel que soit le service qui les produit.
Cette centralisation prend tout son sens dans l’usage quotidien :
- Les données deviennent visibles depuis de nombreuses applications, dont Excel, Teams et Power BI, sans export manuel.
- Les rapports gagnent en fraîcheur puisque les équipes travaillent sur la même source, pas sur des copies vieillissantes.
- OneLake devient le socle naturel des projets d’IA générative, qui réclament des données propres et accessibles sans pipeline supplémentaire.
Vous devriez privilégier OneLake dès que vous constatez une dispersion des données entre plusieurs outils métiers, ou quand vos délais de production de rapports s’allongent faute d’un accès direct aux sources.
Comment fonctionne l’architecture OneCopy d’OneLake ?

L’architecture repose sur un principe simple à énoncer, mais lourd de conséquences techniques : une donnée existe une fois, sous forme de table Delta ou de fichier Parquet, et tous les moteurs Fabric la lisent depuis cet emplacement unique via une couche de virtualisation. Le support d’Apache Iceberg élargit cette logique aux organisations qui ont déjà investi dans cet écosystème.
En coulisses, OneLake s’appuie sur Azure Data Lake Storage Gen2, mais vous n’avez ni compte de stockage à provisionner, ni quota à surveiller manuellement.
- La durabilité et la réplication régionale sont gérées par la plateforme, pas par vos équipes infrastructure.
- Le chiffrement est actif par défaut, avec une option de clés gérées par le client (CMK) pour les environnements soumis à des exigences de conformité renforcées.
- La reprise d’activité s’appuie sur cette abstraction : vous ne restaurez pas un compte de stockage, vous restaurez un contexte Fabric.
Cette abstraction déplace la charge opérationnelle du stockage vers la gouvernance des accès, ce qui rend la section suivante décisive.
Faut-il choisir les shortcuts ou le mirroring dans OneLake ?
Le choix entre shortcuts et mirroring dépend d’une seule question : avez vous besoin d’un pointeur vers une donnée existante, ou d’une copie analytics ready d’une source qui ne parle pas nativement le langage de Fabric ?
- Les shortcuts créent un pointeur de métadonnées sans dupliquer le moindre octet. Ils conviennent parfaitement à un modèle de données mesh, où chaque domaine garde la propriété de ses tables tout en les rendant consommables ailleurs.
- Le mirroring réplique les catalogues, et souvent les données elles mêmes au format Delta, ce qui vise des sources propriétaires (bases SQL, systèmes tiers) qui n’exposent pas nativement un format ouvert.
- La combinaison des deux reste le pattern le plus répandu en entreprise : on mirrore une fois la source externe dans un workspace central, puis on multiplie les shortcuts vers les équipes consommatrices.
Cette approche limite les copies redondantes, mais elle déplace la vigilance vers la cohérence temporelle des données mirrorées et la surveillance des jobs de synchronisation.
Conseil de pro : Avant de choisir, posez vous la question du propriétaire de la donnée source. Si vous ne contrôlez pas le système d’origine, le mirroring vous protège des ruptures d’API ; si vous le contrôlez, un shortcut suffit presque toujours.
Comment fonctionne la sécurité native OneLake security ?
OneLake security applique des règles d’accès directement au niveau de l’élément, du dossier ou de la table, et cette couche voyage avec la donnée quel que soit le moteur qui la lit. Concrètement, un rôle défini une seule fois s’applique aussi bien à une requête Spark qu’à une visualisation Power BI, ce qui simplifie considérablement l’audit.
Un point mérite une vigilance particulière au déploiement : le rôle DefaultReader accorde par défaut un accès large, ce que beaucoup d’organisations doivent restreindre manuellement avant la mise en production.
- Configurez des groupes Microsoft Entra plutôt que des utilisateurs individuels pour affecter les rôles.
- Activez la validation inline des règles de sécurité au niveau ligne (RLS) et colonne (CLS) avant le déploiement, pas après.
- Combinez Private Link et chiffrement par clés gérées par le client pour les environnements réglementés.
Chiffre à retenir : Microsoft a annoncé la disponibilité générale d’OneLake security avec des API de gestion et une expérience de validation RLS repensée, confirmée par les billets de la communauté Fabric.
Comment OneLake alimente-t-il Power BI et les moteurs Fabric ?
Le Lakehouse et le Warehouse stockent tous deux leurs tables Delta directement dans OneLake, et exposent chacun un point de terminaison SQL pour les outils qui préfèrent une syntaxe relationnelle classique.
- Direct Lake permet à Power BI de lire ces tables sans import préalable ni requête DirectQuery classique, ce qui rapproche les performances de celles d’un modèle importé tout en gardant une fraîcheur proche du temps réel.
- L’optimisation V-Order aligne l’écriture des fichiers Parquet pour accélérer leur lecture par le moteur VertiPaq : des pipelines mal réglés peuvent réduire cet avantage de performance.
- Spark et le point de terminaison SQL Analytics cohabitent sur la même donnée, ce qui autorise data engineers et analystes à travailler côte à côte sans synchronisation manuelle.
Cette interopérabilité explique pourquoi tant d’équipes basculent leurs modèles Power BI vers Direct Lake dès que leurs volumes dépassent ce qu’un modèle importé classique peut absorber confortablement.
Comment accéder à OneLake via ADLS Gen2 et l’explorateur Windows ?
OneLake reste compatible avec l’API Azure Data Lake Storage Gen2, ce qui vous permet de réutiliser vos SDKs, vos scripts et vos outils d’intégration existants sans les réécrire.
- Les pipelines déjà connectés à ADLS Gen2 pointent vers OneLake avec un minimum d’adaptation de leur chaîne de connexion.
- L’explorateur OneLake pour Windows reproduit une expérience proche de OneDrive, ce qui facilite grandement l’adoption par des utilisateurs métiers peu familiers du data engineering.
- Planifiez en amont vos options de chiffrement par clé gérée par le client et vos besoins d’audit, car elles conditionnent vos choix d’architecture réseau (Private Link notamment).
Cette compatibilité descendante réduit le coût de migration, un argument souvent décisif pour les directions IT qui hésitent encore à basculer leurs pipelines existants.
Quelles bonnes pratiques de gouvernance appliquer sur OneLake ?
Un déploiement OneLake mal gouverné dérive vite vers ce que les architectes appellent la « dispersion des données » : des dizaines d’espaces de travail créés sans convention, sans propriétaire identifié et sans étiquetage cohérent.
- Définissez une gouvernance par domaine métier : chaque espace de travail a un propriétaire nommé, des tags de classification et une politique claire de création.
- Adoptez le pattern recommandé d’un espace de travail central de mirroring, entouré de shortcuts consommateurs, et surveillez son état via les journaux de diagnostic natifs.
- Passez en revue votre checklist de sécurité opérationnelle : restreindre le rôle DefaultReader, configurer Private Link, activer les clés gérées par le client, et brancher une supervision continue des accès.
Conseil de pro : Documentez vos conventions de nommage des espaces de travail avant le premier déploiement, pas après. C’est le détail que les équipes IT regrettent presque toujours de ne pas avoir figé dès le départ.
Perspective Biworks : quels choix stratégiques privilégier ?
OneLake accélère réellement la convergence entre BI et intelligence artificielle, mais cette promesse ne se réalise que si la gouvernance suit le rythme technique. Le vrai risque n’est pas OneLake lui même, il est organisationnel : une dépendance croissante à l’écosystème Microsoft sans montée en compétence interne équivalente. La bonne réponse tient en un mot, l’audit, complété par une formation certifiée des équipes qui manipulent ces flux au quotidien.
— François
Biworks vous accompagne dans votre déploiement OneLake
Biworks est l’alternative à l’intégration en solo pour déployer OneLake sans multiplier les faux départs : nos architectes cadrent votre migration en quelques semaines plutôt qu’en mois d’essais internes non guidés.
Nos missions couvrent l’audit d’architecture Fabric et le plan de migration vers OneLake, la mise en place concrète d’OneLake security avec Private Link et chiffrement par clé gérée, ainsi que des formations certifiées Qualiopi éligibles au CPF préparant à la certification PL-300. Vos équipes gagnent une autonomie réelle sur Power BI et Fabric, pas seulement une documentation à relire. Décrivez nous votre projet business intelligence pour recevoir un plan d’action chiffré sous quelques jours.
Questions fréquentes
Quelle est la différence entre Lakehouse et OneLake ?
OneLake est le lac de données unifié qui stocke physiquement les tables ; le Lakehouse est un objet applicatif à l’intérieur de Fabric qui organise ces tables et expose un point de terminaison SQL pour les interroger.
Quelles sont les différences entre Microsoft Fabric et OneLake ?
Microsoft Fabric est la plateforme analytique complète, qui regroupe Power BI, Spark, les entrepôts de données et l’ingénierie de données ; OneLake en est la couche de stockage unique fournie automatiquement avec chaque tenant.
Quelle est la différence entre OneDrive et OneLake ?
OneDrive stocke des fichiers personnels ou d’équipe pour un usage bureautique classique, tandis que OneLake stocke des tables analytiques en formats ouverts comme Delta Parquet, conçues pour être lues par des moteurs de calcul comme Spark ou Power BI.
Qu’est-ce que la sécurité OneLake concrètement ?
OneLake security est une couche de contrôle d’accès granulaire, appliquée au niveau item, dossier ou table, incluant la sécurité au niveau ligne (RLS) et colonne (CLS), et valable pour tous les moteurs Fabric sans reconfiguration.
