Qu’est-ce que le Data Mesh et comment fonctionne-t-il ?
Pendant longtemps, les données d’une entreprise ressemblaient à un placard mal rangé : tout y était en théorie, mais personne ne savait vraiment où trouver quoi. Des décisions prises sur des données périmées, des projets analytiques qui patinent, une DSI qui croule sous les tickets. Ce tableau, beaucoup d’organisations le reconnaissent encore aujourd’hui.
Définition & origine
Le data mesh est une réponse à cette situation. Formalisé par Zhamak Dehghani (ThoughtWorks) à partir de 2019, il part d’un constat direct : les architectures centralisées ne tiennent pas la route face à la complexité des organisations modernes. Trop lentes, trop rigides, trop éloignées des réalités métier.
Plutôt que de tout concentrer dans un entrepôt central géré par une poignée de spécialistes, le data mesh redistribue la responsabilité des données à ceux qui les produisent au quotidien : le marketing gère ses données, la supply chain les siennes, les ventes les leurs, chacun selon des standards communs, mais avec une autonomie réelle sur son périmètre.
Ce qui distingue le data mesh, c’est le statut qu’il accorde à la donnée. Celle-ci cesse d’être un sous-produit, une sorte d’exhaust data que l’on collecte en bout de chaîne pour l’analyser plus tard. Elle devient le produit en tant que tel, avec un propriétaire identifié, un niveau de qualité défini, une documentation claire et une accessibilité pensée pour tous les consommateurs internes.
Les 3 composants principaux
Si la définition du data mesh donne le cap, ses trois composants structurants donnent, eux, le mode d’emploi. Ce sont les piliers concrets sur lesquels toute l’architecture repose, et comprendre leur logique respective, c’est déjà anticiper la moitié des questions que vous vous poserez au moment de passer à l’action.
La propriété orientée domaine avec gouvernance fédérée
Dans un data mesh, les données appartiennent au domaine métier qui les produit et ce domaine en est responsable de bout en bout. L’équipe commerciale gère ses données de vente, la supply chain les siennes, les RH les leurs. Chacun est le mieux placé pour le faire correctement, parce que chacun connaît ce que ses données représentent réellement.
Cela ne signifie pas que chaque domaine fait ce qu’il veut. La gouvernance fédérée fixe un cadre commun : normes de qualité, conventions de nommage, politiques de sécurité, standards d’interopérabilité, que tous s’engagent à respecter. L’équipe centrale n’est plus gardienne des données, mais garante des règles du jeu.
La pensée produit appliquée aux données
Chaque jeu de données est traité comme un produit, dont les autres équipes de l’organisation sont les clients. L’équipe de domaine ne dépose pas des données brutes quelque part, elle conçoit des data products autonomes, documentés, versionnés et accessibles, qu’il s’agisse d’une API, d’un dataset structuré ou d’un modèle prédictif.
Pour mériter ce statut, un data product doit être découvrable (référencé dans un catalogue), adressable (accessible via une adresse stable), fiable (avec des objectifs de niveau de service mesurables) et autodescriptif (suffisamment documenté pour être exploité sans appeler le producteur).
Le rôle des ingénieurs de données évolue dans ce modèle : ils ne passent plus leur temps à alimenter un entrepôt central, mais à concevoir l’infrastructure qui permet à chaque domaine de publier ses propres données. Du pompier qui gère l’urgence, ils deviennent l’architecte qui construit pour durer.
Le libre-service via une infrastructure commune
Pour que chaque domaine gère ses données sans réinventer la roue, le data mesh s’appuie sur une plateforme d’infrastructure partagée : moteurs de pipelines, stockage, outils de qualité, catalogue, mécanismes de sécurité. La plateforme cache ce qui est complexe et expose ce qui est utile, chaque équipe se concentre sur ses données, pas sur la tuyauterie.
👉 Remarque
Une frontière à ne jamais brouiller : le responsable de la plateforme et le responsable de domaine sont deux rôles distincts. L’un gère l’infrastructure pour tous, l’autre gère ses données. Les mélanger, c’est recréer exactement les dépendances qu’on cherchait à éliminer.
Pourquoi choisir le Data Mesh ? Comparaison avec les autres architectures
Entrepôt de données, Data Lake, Data Lakehouse et Data Mesh
Une question revient souvent dans les discussions autour du data mesh : est-ce que ça remplace le data lake ? Et le data warehouse ? La réponse courte, c’est non. Ces quatre approches ne jouent pas sur le même terrain et les comprendre ensemble permet de faire des choix d’architecture beaucoup plus éclairés.
L’entrepôt de données est l’ancêtre de la famille. Robuste, cohérent, taillé pour le reporting financier et la business intelligence sur des données bien structurées. Là où il montre ses limites, c’est face aux données non structurées et à la vitesse à laquelle les besoins analytiques évoluent. Modifier un schéma, c’est souvent une opération lourde qui mobilise plusieurs équipes et plusieurs semaines.
Le data lake est arrivé comme réponse à cette rigidité : stocker tout en format brut, laisser les équipes exploiter selon leurs besoins, sans schéma imposé à l’avance. En pratique, sans gouvernance sérieuse, le data lake devient vite ingérable. Les données s’y accumulent sans documentation ni propriétaire clairement identifié c’est ce que les praticiens du secteur appellent un data swamp, et la métaphore n’est pas exagérée.
Le data lakehouse tente une hybridation des deux : flexibilité de stockage du lake, capacités de structuration et d’interrogation de l’entrepôt. Des solutions comme Delta Lake ou Apache Iceberg s’inscrivent dans cette logique. C’est une évolution sensée, mais le data lakehouse reste une architecture centralisée. Il n’adresse ni la question de la propriété des données, ni l’alignement entre producteurs et consommateurs. L’agilité organisationnelle, elle, n’a pas progressé.
👉À noter
C’est là que le data mesh se distingue fondamentalement. Là où les trois premiers sont des choix technologiques des façons de stocker et d’organiser les données, le data mesh est avant tout un choix organisationnel sur la façon dont la responsabilité des données est distribuée dans l’entreprise.
Le tableau ci-dessous résume les grandes différences entre ces quatre approches :
| Entrepôt de données | Data Lake | Data Lakehouse | Data Mesh | ||
| Nature | Technologique | Technologique | Technologique | Organisationnelle | |
| Structure | Schéma prédéfini | Données brutes | Hybride | Distribuée par domaine | |
| Gouvernance | Centralisée | Souvent absente | Centralisée | Fédérée | |
| Agilité | Faible | Moyenne | Moyenne | Élevée | |
| Idéal pour | BI, reporting | Big data, ML | Cas hybrides | Organisations complexes, multi-domaines | |
Ces quatre modèles peuvent et doivent souvent coexister
Beaucoup d’organisations qui adoptent le data mesh conservent leur entrepôt pour le reporting consolidé, leur data lake pour les projets de machine learning exploratoires, et s’appuient sur une infrastructure lakehouse pour certains domaines à forte volumétrie. Le data mesh vient alors redistribuer la responsabilité de ces systèmes aux équipes qui en ont la meilleure connaissance, sans les remplacer.
👉À noter
On parle de data mesh hybride pour désigner cette configuration. Ce n’est pas une demi-mesure : c’est souvent la trajectoire la plus réaliste pour une organisation qui ne peut pas tout transformer d’un coup.
Considérations essentielles avant de se lancer
Pour quelles entreprises le Data Mesh est-il adapté ?
Le data mesh fait beaucoup parler de lui et c’est précisément ce buzz qui pousse certaines organisations à se lancer sans vérifier si le modèle correspond à leur situation. Ce serait une erreur. Ce n’est pas une architecture universelle : c’est une réponse à des problèmes spécifiques, dans des contextes spécifiques.
Le premier filtre est assez direct : le data mesh s’adresse aux organisations dont le patrimoine de données est suffisamment dense, hétérogène et stratégique pour que les architectures centralisées soient devenues un frein tangible. Une PME avec trois sources de données et deux personnes dans l’équipe analytique n’en a pas besoin, un data warehouse bien configuré lui suffira, avec bien moins de complexité à gérer. En revanche, un groupe avec une vingtaine de business units, des systèmes sources hétérogènes et un backlog analytique qui s’allonge chaque trimestre là, le data mesh répond à de vraies douleurs.
Trois signaux indiquent que le moment est venu : un backlog data chroniquement saturé que tout le monde a fini par accepter comme normal ; une prolifération de shadow data, exports Excel, bases locales, calculs manuels, qui signalent que les équipes ont perdu confiance dans les systèmes officiels ; et une difficulté à croître, où chaque nouveau marché ou nouvelle entité déclenche un chantier data massif.
Parmi les secteurs qui s’y prêtent particulièrement bien : les groupes industriels multisites, les banques et assurances contraintes par des exigences réglementaires fortes, les retailers qui jonglent entre stocks, ventes et logistique, et les organisations en croissance externe accélérée qui cherchent une voie d’intégration progressive pour chaque entité acquise.
Dernière condition, souvent la plus sensible à aborder : la maturité data des équipes. Une équipe qui n’a jamais géré de pipeline et considère les données comme « un problème pour les informaticiens » ne peut pas devenir du jour au lendemain un domaine autonome. Une évaluation honnête de chaque département est indispensable pour décider qui peut devenir domaine pilote et dans quel ordre les autres suivront.
Facteurs clés de succès
Les projets data mesh qui échouent, échouent rarement sur la technologie. Ils échouent sur l’exécution : gouvernance mal pensée, équipes insuffisamment préparées, ambition trop large dès le départ.
- Commencer petit. Un ou deux domaines pilotes, choisis pour leur maturité et la valeur métier qu’ils peuvent générer rapidement. L’objectif n’est pas de prouver que le data mesh fonctionne en théorie, c’est de valider qu’il fonctionne dans votre organisation. Rien ne convainc mieux une équipe sceptique qu’un exemple réel venant d’un collègue.
- Poser la gouvernance avant d’ouvrir les portes. Les questions de gouvernance ne se règlent pas au fil de l’eau, elles s’accumulent. Conventions de nommage, standards de métadonnées, politiques d’accès, règles d’interopérabilité : ce socle minimal doit être défini avant le premier pilote. Léger, mais non négociable.
- Investir dans l’infrastructure en amont. Si la plateforme libre-service n’est pas en place dès le départ, les équipes retomberont dans leur dépendance centrale, le libre-service ne sera libre que de nom. Attention particulière au Master Data Management : sans référentiel commun sur les clients, produits ou fournisseurs, les domaines recreront exactement les silos qu’on cherchait à éliminer.
- Soigner la conduite du changement. C’est le facteur le plus sous-estimé. Le data mesh redistribue des responsabilités et bouscule des habitudes ancrées. Les équipes métier doivent comprendre ce que signifie concrètement être propriétaire de ses données. Les équipes data centrales doivent être accompagnées dans l’évolution de leur rôle. Et les dirigeants : DSI, CDO, directeurs métier, doivent porter le projet : sans alignement au niveau du comité de direction, le data mesh reste un projet IT comme les autres.
BSD vous accompagne dans votre transformation data
Mettre en place un data mesh, c’est autant un chantier organisationnel que technique, et c’est précisément là qu’intervient BSD. Spécialisés dans l’intégration de solutions data et l’exploitation des données, nos équipes accompagnent les entreprises à chaque étape de leur transformation : évaluation de la maturité data, définition du cadre de gouvernance fédérée, mise en place de l’infrastructure libre-service, identification des domaines pilotes et conduite du changement auprès des équipes métier.
Notre approche repose sur une conviction simple : la technologie ne suffit pas. Ce qui fait la différence, c’est la capacité à aligner les outils, les processus et les équipes autour d’une vision commune de la donnée. C’est ce que nous faisons au quotidien avec nos clients : des organisations qui ont décidé de prendre leurs données au sérieux, et qui cherchent un partenaire capable de les accompagner dans la durée, pas seulement de livrer une architecture.
Vous vous reconnaissez dans les problématiques décrites dans cet article ? Échangeons !
À retenir
aucun
Qu’est-ce que le Data Mesh ?
Le Data Mesh est une approche organisationnelle qui redistribue la responsabilité des données aux domaines métier qui les produisent, en opposition aux architectures centralisées. Chaque équipe, marketing, supply chain, RH, gère ses propres données selon des standards communs, tout en conservant une autonomie réelle sur son périmètre.
Quelle est la différence entre Data Mesh et Data Lake ?
Le Data Lake est un choix technologique de stockage ; le Data Mesh est un choix organisationnel sur la distribution des responsabilités. Un Data Lake sans gouvernance devient un data swamp : données sans propriétaire ni documentation. Le Data Mesh adresse précisément ce que le Data Lake n’a jamais résolu : l’alignement entre producteurs et consommateurs de données.
Data Mesh et entrepôt de données sont-ils compatibles ?
Oui, les deux coexistent dans la majorité des organisations qui adoptent le Data Mesh. L’entrepôt conserve son rôle pour le reporting consolidé et la BI structurée, tandis que le Data Mesh redistribue la responsabilité des données aux domaines. On parle alors de Data Mesh hybride, souvent la trajectoire la plus réaliste pour une transformation progressive.
Pour quelles entreprises le Data Mesh est-il adapté ?
Le Data Mesh s’adresse aux organisations dont les architectures centralisées sont devenues un frein : backlog analytique chronique, prolifération de shadow data, difficulté à intégrer de nouvelles entités. Une PME avec peu de sources de données n’en a pas besoin ; un groupe multisites avec des systèmes hétérogènes, oui.
