Lakehouse, Data Fabric et Data Mesh sont souvent présentés comme trois architectures concurrentes. C’est pourtant l’une des premières erreurs à éviter. En 2026, les entreprises les plus avancées cherchent moins à en choisir une qu’à déterminer quelles couches combiner, tout en gardant la maîtrise de leurs données, de leur gouvernance et de leurs coûts cloud.
Une entreprise qui veut déployer des agents IA, entraîner des modèles ou simplement produire un tableau de bord fiable se heurte aujourd’hui à un problème très concret : ses données sont rarement au même endroit. ERP historique, applications SaaS, bases SQL, fichiers, entrepôts cloud, Data Lakes, données temps réel et documents internes forment un patrimoine difficile à réunir.
La tentation consiste alors à chercher la nouvelle architecture qui remplacera toutes les précédentes. Data Mesh ? Data Fabric ? Lakehouse ?
C’est précisément là que le raisonnement dérape.
Ces trois approches sont régulièrement rangées dans la même catégorie alors qu’elles interviennent à des niveaux différents. IBM les présente d’ailleurs comme des concepts pouvant être complémentaires, tandis que Databricks documente explicitement des implémentations de Data Mesh reposant sur un Lakehouse. IBM compare Data Lakehouse, Data Fabric et Data Mesh.
Le Lakehouse s’occupe principalement de la plateforme de données. Le Data Fabric s’intéresse à la manière de connecter, découvrir et gouverner des données distribuées. Le Data Mesh change quant à lui la façon dont l’entreprise répartit la responsabilité de ces données.
La bonne question n’est donc plus seulement « lequel choisir ? ». Elle devient : de quelles couches votre entreprise a-t-elle réellement besoin ?
Trois architectures, trois problèmes différents
Imaginez un groupe possédant plusieurs filiales.
Il dispose d’un Data Lake contenant des pétaoctets de fichiers, d’un entrepôt SQL utilisé par la finance, de données clients dans Salesforce, d’ERP dans plusieurs pays et de données industrielles qui ne quitteront jamais certains systèmes pour des raisons de coût ou de réglementation.
Le Lakehouse cherche à réunir les qualités du Data Lake et du Data Warehouse. On conserve notamment la capacité de stocker de gros volumes de données structurées ou non structurées, tout en ajoutant les transactions, la gestion des schémas, la gouvernance et les performances nécessaires aux workloads analytiques. Microsoft définit également son Lakehouse Fabric comme une combinaison de la capacité de stockage d’un lac et des possibilités d’interrogation d’un entrepôt. Microsoft détaille l’architecture Lakehouse de Fabric.
Le Data Fabric accepte davantage l’idée que les données resteront distribuées. Il ajoute des couches de métadonnées, de catalogue, d’intégration, de virtualisation, de qualité et de sécurité permettant de retrouver et d’exploiter les données où qu’elles soient. IBM insiste notamment sur l’utilisation de métadonnées actives, de catalogues et de mécanismes automatisés de gouvernance. IBM détaille le fonctionnement d’un Data Fabric.
Le Data Mesh, enfin, s’attaque à un autre problème : une équipe data centrale finit souvent par devenir responsable de données qu’elle comprend moins bien que les métiers qui les produisent.
Le concept popularisé par Zhamak Dehghani repose sur quatre principes : propriété par domaine, données traitées comme des produits, infrastructure en libre-service et gouvernance fédérée. Zhamak Dehghani détaille les principes fondamentaux du Data Mesh.
| Approche | Question principale | Ce qu’elle change |
|---|---|---|
| Lakehouse | Où stocker et traiter les données analytiques ? | La plateforme technique |
| Data Fabric | Comment accéder et gouverner des données dispersées ? | L’intégration et les métadonnées |
| Data Mesh | Qui doit produire et être responsable des données ? | L’organisation et la gouvernance |
| Combinaison | Comment industrialiser une organisation data distribuée ? | Plateforme + intégration + organisation |
Ce tableau résume probablement la décision la plus importante de tout ce dossier : un Lakehouse peut servir de plateforme technique à un Data Mesh, tandis qu’un Data Fabric peut fournir une partie de l’intégration et de la gouvernance nécessaires à ce même Mesh.
Le Lakehouse gagne la bataille du socle
Le Lakehouse répond à une frustration ancienne.
Les Data Lakes permettent de conserver énormément d’informations à moindre coût, mais peuvent se transformer en « data swamps » lorsque les fichiers s’accumulent sans gouvernance suffisante. C’est un problème déjà détaillé dans notre dossier sur le fonctionnement et les limites des Data Lakes.
Les Data Warehouses offrent davantage de structure et de performances SQL, mais impliquent historiquement davantage de transformations et de duplication.
Le Lakehouse tente de rapprocher les deux modèles.
Sa montée en puissance s’appuie surtout sur une innovation moins spectaculaire qu’un nouveau modèle d’IA, mais fondamentale : les formats de tables ouverts.
Apache Iceberg, Delta Lake et Apache Hudi ajoutent notamment aux fichiers stockés dans un lac des mécanismes de transactions, de gestion de versions, d’évolution de schéma et de métadonnées.
Pour comprendre cette couche plus en détail, LeBigData a consacré un dossier à Apache Iceberg et son rôle dans les architectures de données modernes.
En 2026, cette bataille prend une nouvelle dimension. La spécification Apache Iceberg v3 ajoute notamment les deletion vectors, la traçabilité des lignes, de nouveaux types pour les données semi-structurées et des mécanismes liés au chiffrement. La spécification Iceberg v3 est disponible directement auprès du projet Apache.
Delta Lake évolue dans la même direction avec sa génération 4.x, qui accentue notamment l’ouverture vers les catalogues, l’interopérabilité et les données semi-structurées. Le projet Delta Lake présente son architecture et ses dernières évolutions.
Le changement est considérable : le stockage devient progressivement plus indépendant du moteur qui calcule dessus.
Une entreprise peut ainsi vouloir conserver des tables sur un stockage objet tout en permettant à Spark, Trino, Snowflake, Databricks ou d’autres moteurs compatibles de travailler dessus.
Cette séparation réduit théoriquement le coût d’une migration future et évite de considérer le moteur analytique comme le propriétaire naturel des données.
C’est aussi pour cela que la comparaison Snowflake vs Databricks devient beaucoup moins binaire qu’elle ne l’était il y a quelques années. Les deux plateformes étendent désormais fortement leur prise en charge des architectures et formats ouverts.
Le Data Fabric évite le grand déménagement
Le Lakehouse possède néanmoins une limite évidente : toutes les données d’une grande entreprise ne finiront jamais dans un seul lac.
Certaines vivent dans SAP, Oracle ou Salesforce. D’autres restent dans des bases locales, des applications métier, plusieurs clouds ou chez des partenaires.
Les recopier systématiquement crée des pipelines supplémentaires. Et chaque copie ajoute potentiellement de la latence, des frais de stockage, des problèmes de synchronisation, des droits d’accès supplémentaires et une nouvelle version de la vérité.
C’est ici que le Data Fabric devient intéressant.
Une architecture de ce type construit une couche logique au-dessus de cet environnement fragmenté. Elle peut combiner catalogue de données, gestion des métadonnées, lignage, règles de qualité, intégration, APIs et parfois virtualisation des données.
La Data Virtualization peut par exemple fournir une vue unifiée de plusieurs sources sans devoir toutes les recopier. Ce mécanisme est expliqué plus en détail dans notre guide consacré à la virtualisation des données.
L’intérêt devient encore plus évident avec l’IA.
Un agent ne doit pas seulement trouver un fichier. Il doit déterminer quelle version est valide, qui en est propriétaire, qui peut y accéder, ce que signifie chaque champ et de quand date l’information.
C’est précisément ce manque de contexte qui rend une partie des patrimoines informationnels actuels difficilement exploitable par l’IA, comme nous l’expliquions dans notre enquête sur les données d’entreprise inutilisables pour l’IA.
Dans ce contexte, le catalogue et les métadonnées ne sont plus de simples outils destinés aux Data Engineers. Ils deviennent une couche de contexte pour les applications et agents IA.
Attention toutefois à une confusion fréquente : Microsoft Fabric et un Data Fabric ne sont pas synonymes. Microsoft Fabric est une suite commerciale regroupant plusieurs services data et analytics autour de OneLake. Le terme Data Fabric désigne, lui, une approche architecturale générale pouvant être implémentée avec de nombreux outils.
Le Data Mesh résout ce que la technologie ne peut pas corriger
Une entreprise peut acheter un catalogue, créer un Lakehouse et connecter toutes ses sources.
Elle peut malgré tout continuer à produire de mauvaises données.
Pourquoi ?
Parce que la technologie ne sait pas toujours déterminer que customer_status = active signifie quelque chose de différent pour le service facturation et pour le marketing.
L’équipe qui connaît réellement cette différence est souvent celle qui travaille quotidiennement avec le processus métier concerné.
Le Data Mesh part précisément de ce constat.
Au lieu de confier toutes les données analytiques à une immense équipe centrale, il attribue leur propriété aux domaines. L’équipe logistique devient par exemple responsable de certains produits de données logistiques, tandis que la finance prend en charge ses propres produits.
Ces produits doivent rester découvrables, compréhensibles, interopérables et gouvernés. La plateforme centrale ne disparaît donc pas : elle doit fournir des briques en libre-service afin que chaque domaine ne reconstruise pas son stockage, son IAM, son monitoring ou son catalogue. Databricks présente par exemple une architecture associant explicitement Lakehouse et principes du Data Mesh.
C’est ce qui rend le Data Mesh séduisant et dangereux.
Décentraliser sans plateforme commune ne crée pas un Mesh. Cela crée de nouveaux silos.
Et décentraliser sans gouvernance fédérée peut transformer une taxonomie incohérente en cinquante taxonomies incohérentes.
Le coût caché du Data Mesh est donc essentiellement humain. Il faut des responsables de produits de données, des équipes métiers suffisamment matures techniquement, des standards communs et une plateforme capable d’automatiser une grande partie des contraintes.
Pour une organisation dont l’équipe data centrale ne souffre pas encore réellement d’un problème de passage à l’échelle, cette transformation peut simplement ajouter de la complexité.
Le Data Mesh devient beaucoup plus pertinent lorsque les domaines sont nombreux, autonomes et suffisamment complexes pour que la centralisation ralentisse réellement la production de données.
En 2026, la vraie guerre porte sur les catalogues
Pendant plusieurs années, les entreprises se sont demandé quel moteur allait stocker leurs données.
En 2026, une autre question prend de l’importance : qui contrôle les métadonnées permettant de les retrouver et d’y accéder ?
Apache Iceberg illustre parfaitement cette évolution.
La donnée peut rester sous forme de fichiers Parquet dans du stockage objet. Mais un catalogue conserve les informations permettant aux moteurs de découvrir et de manipuler les tables.
Databricks permet ainsi à des moteurs compatibles d’accéder à certaines tables Iceberg gérées dans Unity Catalog via l’API Iceberg REST Catalog. La documentation Databricks détaille cet accès depuis des systèmes externes.
Snowflake pousse de son côté le protocole Iceberg REST et son environnement de catalogage afin de permettre à plusieurs moteurs de travailler sur des données Iceberg. L’entreprise met notamment en avant une interopérabilité accrue entre moteurs. Snowflake détaille sa stratégie autour d’Apache Iceberg.
Ces annonces commerciales doivent évidemment être évaluées fonction par fonction. Toutes les combinaisons de tables, catalogues et moteurs n’offrent pas les mêmes possibilités de lecture, d’écriture ou de gouvernance.
Mais la tendance est claire : l’architecture data moderne cherche à limiter les copies et à permettre à plusieurs moteurs de travailler sur une même couche de données gouvernée.
Voilà probablement le changement le plus important pour un architecte en 2026.
Il ne suffit plus de demander : « quel produit est le plus performant aujourd’hui ? ». Il faut demander :
Si nous changeons de moteur dans trois ans, que devons-nous déplacer ?
Si la réponse est « plusieurs pétaoctets, tous les droits et toutes les métadonnées », le coût réel de la plateforme est nettement supérieur à sa facture mensuelle.
Les coûts cachés ne sont pas les mêmes
Aucune de ces architectures ne fait disparaître la complexité. Elle déplace simplement l’endroit où elle doit être gérée.
Pour le Lakehouse, le risque principal consiste à reconstruire un gigantesque système central dont personne ne maîtrise réellement le contenu. Les formats ouverts diminuent le verrouillage technique, mais ils n’éliminent ni les problèmes de qualité, ni la gouvernance, ni le coût du compute.
Pour le Data Fabric, le danger est l’empilement. Catalogue, moteur de règles, virtualisation, ETL, observabilité, gestion des identités et couche sémantique peuvent finir par former une architecture aussi difficile à exploiter que les systèmes qu’elle devait simplifier.
Pour le Data Mesh, le principal coût est organisationnel. Une équipe métier ne devient pas responsable d’un produit de données simplement parce qu’un schéma d’architecture lui attribue une nouvelle case.
Il faut du temps, des responsabilités explicites et surtout des outils permettant d’éviter que chaque domaine devienne une mini-équipe infrastructure.
C’est pourquoi les architectures hybrides les plus pertinentes cherchent à centraliser les éléments qui gagnent à l’être et à distribuer seulement ce qui doit réellement l’être.
Les standards de sécurité, la plateforme self-service, la gestion des identités et certaines politiques de gouvernance peuvent rester communs.
La connaissance métier et la responsabilité de la qualité peuvent être distribuées.
Le stockage peut être physiquement mutualisé tout en étant logiquement séparé par domaines.
Et les données qui ne peuvent pas être déplacées peuvent être intégrées via une couche de Fabric.
Il n’y a aucune contradiction.
Quelle architecture data convient à votre entreprise ?
Répondez à 8 questions pour déterminer si votre priorité devrait être Lakehouse, Data Fabric, Data Mesh ou une architecture hybride.
Où se trouvent aujourd’hui vos données ?
Vos équipes doivent-elles utiliser les mêmes données pour la BI, le ML et l’IA ?
Pouvez-vous déplacer facilement vos données vers une plateforme centrale ?
Votre entreprise utilise-t-elle plusieurs clouds ou de nombreux SaaS ?
L’équipe data centrale devient-elle un point de blocage ?
Les équipes métier peuvent-elles réellement prendre en charge des produits de données ?
Quelle importance accordez-vous à la réversibilité technologique ?
Quelle phrase décrit le mieux votre problème actuel ?
Vos 3 priorités
Alors, quelle architecture choisir ?
Le choix devient beaucoup plus simple lorsqu’on part du problème plutôt que du vocabulaire.
Choisissez d’abord un Lakehouse si votre priorité est de moderniser une plateforme analytique fragmentée, de rapprocher BI, data engineering et IA, ou de construire une couche de données reposant sur des formats ouverts.
Un Lakehouse constitue aujourd’hui un socle particulièrement logique pour une nouvelle plateforme analytique. L’usage d’un format ouvert comme Iceberg ou Delta peut également réduire le risque de rendre les données dépendantes d’un seul moteur.
Ajoutez une logique Data Fabric lorsque votre patrimoine restera durablement distribué. C’est particulièrement pertinent dans les environnements hybrides, multicloud ou fortement marqués par des applications historiques impossibles à migrer rapidement.
Le Fabric devient alors une couche d’accès, de métadonnées et de gouvernance au-dessus de plusieurs systèmes.
Envisagez un Data Mesh lorsque le problème n’est plus l’infrastructure, mais l’organisation. Si une équipe centrale passe son temps à interpréter les données de dizaines de métiers et devient un intermédiaire obligatoire pour chaque nouveau produit analytique, distribuer la propriété peut devenir nécessaire.
Mais déployer un Mesh sans plateforme self-service solide revient à distribuer la dette technique.
La grille de décision
| Votre problème dominant | Priorité |
|---|---|
| Plusieurs Data Lakes et Warehouses à rationaliser | Lakehouse |
| BI, ML et IA doivent travailler sur la même donnée | Lakehouse |
| Données réparties entre cloud, SaaS et systèmes locaux | Data Fabric |
| Impossible ou inutile de déplacer certaines données | Data Fabric |
| Équipe data centrale saturée par les demandes métiers | Data Mesh |
| Les métiers connaissent mieux les données que l’équipe centrale | Data Mesh |
| Grande organisation + données dispersées + nombreux domaines | Lakehouse + Fabric + Mesh |
| Priorité à la réversibilité technologique | Lakehouse ouvert + catalogue interopérable |
La dernière ligne mérite une attention particulière.
En 2026, choisir une plateforme uniquement en fonction de ses fonctionnalités est une vision trop courte. Le format de table, le catalogue, les APIs de gouvernance et la possibilité d’utiliser plusieurs moteurs sont désormais des critères d’architecture à part entière.
L’architecture qui se dessine combine les trois
Pour un grand groupe, l’architecture la plus crédible peut finalement ressembler à ceci.
En dessous, un ou plusieurs stockages objets constituent la couche physique. Des formats ouverts comme Apache Iceberg ou Delta Lake structurent les tables.
Au-dessus, un Lakehouse fournit SQL, Spark, streaming, machine learning et traitements destinés à l’IA.
Une couche de Data Fabric catalogue également les données restées dans les ERP, bases opérationnelles, SaaS et autres clouds. Elle apporte métadonnées, découverte, lignage et gouvernance.
Enfin, l’entreprise organise progressivement certaines données sous forme de Data Products appartenant à des domaines métier, conformément aux principes du Data Mesh.
Le résultat n’est donc pas :
Data Mesh ou Data Fabric ou Lakehouse.
C’est potentiellement :
Lakehouse comme socle, Data Fabric comme tissu d’intégration et Data Mesh comme modèle d’organisation.
Toutes les entreprises n’ont évidemment pas besoin des trois. Une organisation relativement simple gagnera souvent davantage à construire un Lakehouse correctement gouverné qu’à adopter artificiellement un Data Mesh.
À l’inverse, une multinationale possédant plusieurs clouds, des dizaines de domaines et vingt ans de systèmes historiques ne résoudra probablement pas son problème en forçant toutes ses données dans une nouvelle plateforme centrale.
Data Mesh, Data Fabric ou Lakehouse : le verdict
Alors, Data Mesh, Data Fabric ou Lakehouse ?
Pour la majorité des nouvelles plateformes analytiques en 2026, le Lakehouse constitue le point de départ technique le plus logique. Le Data Fabric devient pertinent lorsque les données ne peuvent pas être réellement centralisées. Le Data Mesh intervient lorsque la centralisation de leur propriété devient elle-même un obstacle.
Le plus mauvais choix serait donc de sélectionner l’un de ces concepts comme une marque ou une mode.
Le véritable enjeu consiste à déterminer ce qui doit être centralisé, ce qui doit rester distribué et qui doit être responsable de chaque donnée.
Et avec l’essor d’Apache Iceberg, des catalogues ouverts et des architectures multi-moteurs, un quatrième critère devient incontournable : s’assurer que l’entreprise pourra encore changer d’avis demain.
FAQ : Data Mesh, Data Fabric et Lakehouse
Quelle est la différence entre Data Mesh et Data Fabric ?
Le Data Mesh décentralise principalement la propriété des données en la confiant aux domaines métier, tout en imposant des standards communs et une gouvernance fédérée. Le Data Fabric est davantage une approche technique d’intégration, de découverte et de gouvernance permettant d’accéder à des données réparties entre plusieurs systèmes. Les deux approches peuvent donc coexister. Un Data Fabric peut même fournir certaines briques techniques nécessaires à un Data Mesh, notamment le catalogue, les métadonnées, le contrôle d’accès et la découverte des Data Products.
Quelle est la différence entre Data Lake et Data Lakehouse ?
Un Data Lake stocke principalement de grandes quantités de données brutes ou faiblement structurées sur une infrastructure peu coûteuse. Un Lakehouse ajoute des fonctionnalités historiquement associées aux Data Warehouses, comme les transactions, l’évolution des schémas, la gouvernance et de meilleures performances SQL. Les formats de tables tels qu’Apache Iceberg ou Delta Lake permettent d’apporter ces fonctionnalités directement au-dessus du stockage objet.
Un Data Mesh a-t-il besoin d’un Lakehouse ?
Non. Un Data Mesh n’impose pas une technologie de stockage particulière. Il s’agit avant tout d’un modèle sociotechnique organisé autour des domaines et des Data Products. Cependant, un Lakehouse peut fournir une plateforme commune particulièrement adaptée à son implémentation. Plusieurs domaines peuvent alors utiliser la même infrastructure tout en conservant une autonomie logique et une gouvernance distribuée.
Apache Iceberg est-il nécessaire pour construire un Lakehouse ?
Non. Apache Iceberg est l’un des principaux formats de tables ouverts utilisés dans les architectures Lakehouse, aux côtés notamment de Delta Lake et Apache Hudi. Iceberg est particulièrement intéressant lorsqu’une entreprise veut permettre à plusieurs moteurs de travailler sur les mêmes tables. Le choix doit néanmoins tenir compte des moteurs, catalogues et workloads réellement utilisés.
Microsoft Fabric est-il un Data Fabric ?
Pas exactement. Microsoft Fabric est une plateforme commerciale de Microsoft qui regroupe notamment stockage, data engineering, Data Warehouse, BI et autres fonctions autour de OneLake. Un Data Fabric est un modèle architectural générique destiné à connecter, découvrir et gouverner des données distribuées. Microsoft Fabric peut participer à une architecture de ce type, mais les deux termes ne désignent pas la même chose.
- Partager l'article :
