Beaucoup d’entreprises ont longtemps entretenu avec leurs données une relation chaotique : l’information existait quelque part, mais personne ne savait vraiment où la chercher, ni à qui s’adresser. Des décisions fondées sur des chiffres obsolètes, des projets analytiques qui s’enlisent, des équipes IT saturées de demandes. Ce constat reste tristement d’actualité dans de nombreuses organisations.
Ce qu’est réellement le Data Mesh
Aux origines du concept
C’est Zhamak Dehghani, ingénieure chez ThoughtWorks, qui a structuré ce concept à partir de 2019. Son point de départ est simple : les architectures de données centralisées ne sont pas conçues pour répondre à la complexité croissante des grandes organisations. Elles sont trop lentes à faire évoluer, trop rigides pour s’adapter et trop déconnectées des réalités opérationnelles.
La réponse qu’elle propose ne consiste pas à trouver un meilleur outil central, mais à remettre en question la centralisation elle-même. Plutôt que de confier la gestion de toutes les données à une équipe spécialisée, le data mesh distribue cette responsabilité aux entités qui produisent réellement les données au quotidien. Le marketing pilote ses données, la chaîne logistique les siennes, les équipes commerciales les leurs. Chacun reste dans un cadre commun, mais dispose d’une vraie autonomie sur son périmètre.
Ce changement de posture a une conséquence importante sur la façon dont on considère la donnée elle-même. Elle cesse d’être un simple résidu des activités, un sous-produit collecté après coup pour alimenter des tableaux de bord. Elle devient un actif à part entière, avec un responsable clairement identifié, des critères de qualité définis, une documentation accessible et une logique de mise à disposition pensée pour ceux qui en ont besoin.
Les trois piliers de l’architecture
Comprendre le data mesh, c’est comprendre les trois principes structurants qui le rendent opérationnel.
La propriété décentralisée dans un cadre fédéré
Dans ce modèle, chaque domaine métier prend en charge les données qu’il génère, de leur production à leur mise à disposition. L’équipe commerciale maîtrise ses données de vente, les ressources humaines gèrent les leurs, la logistique fait de même. Ce principe repose sur une évidence : personne ne connaît une donnée mieux que celui qui la crée.
Mais cette autonomie ne signifie pas anarchie. La gouvernance fédérée fixe un cadre commun auquel tous les domaines adhèrent : normes de qualité, conventions de nommage, politiques de sécurité, règles d’interopérabilité. L’équipe centrale de données cesse d’être le gardien de toutes les données pour devenir le garant des règles communes.
La donnée comme produit
Chaque jeu de données est traité comme un produit que d’autres équipes de l’organisation vont consommer. Cela implique de ne pas simplement déposer des données brutes dans un entrepôt, mais de concevoir de véritables produits data : documentés, versionnés, accessibles via des interfaces stables, qu’il s’agisse d’une API, d’un dataset structuré ou d’un modèle analytique.
Pour qu’un produit data mérite ce nom, il doit remplir plusieurs conditions : être référencé dans un catalogue pour pouvoir être trouvé, accessible via une adresse pérenne, assorti d’engagements de qualité mesurables, et suffisamment documenté pour être exploité sans solliciter son producteur. C’est une rupture nette avec la logique du pipeline qui alimente un lac de données sans vraiment considérer les usages en aval.
Cette approche transforme également le rôle des ingénieurs data. Leur mission n’est plus d’alimenter en permanence un système central, mais de construire l’infrastructure qui permet à chaque domaine de publier et maintenir ses propres données.
Une plateforme au service de l’autonomie
Pour que chaque équipe puisse gérer ses données sans tout réinventer de son côté, le data mesh s’appuie sur une infrastructure partagée en libre-service : moteurs de pipelines, capacités de stockage, outils de contrôle qualité, catalogue de données, mécanismes de sécurité. La plateforme absorbe la complexité technique et expose des fonctionnalités simples à utiliser. Chaque équipe peut ainsi se concentrer sur ses données, sans avoir à gérer les couches techniques sous-jacentes.
🎯Bon à savoir
Un point de vigilance s’impose ici : le responsable de la plateforme et le responsable d’un domaine sont deux rôles distincts qui ne doivent pas être confondus. Mélanger les deux, c’est recréer exactement le type de dépendances que le data mesh cherche à éliminer.
Data Mesh face aux autres architectures : quelles différences ?
Un positionnement différent
La question revient souvent : est-ce que le data mesh remplace le data lake ou l’entrepôt de données ? La réponse est non, et comprendre pourquoi éclaire la nature profonde de chacune de ces approches.
L’entrepôt de données est la solution historique. Robuste et cohérent, il reste particulièrement adapté au reporting financier et aux analyses de business intelligence sur des données bien structurées. Ses limites apparaissent face à des données non structurées ou face à des besoins analytiques qui évoluent rapidement. Modifier le schéma d’un entrepôt est souvent une opération longue et coûteuse.
Le data lake a été conçu comme un antidote à cette rigidité. L’idée : stocker tout en format brut, sans imposer de structure à l’avance, et laisser les équipes travailler à partir de cette matière première. En pratique, sans gouvernance sérieuse, le résultat est décevant. Les données s’accumulent sans propriétaire ni documentation, et le lac devient rapidement un marécage, un data swamp, pour reprendre l’expression consacrée dans le milieu.
Le data lakehouse tente une synthèse entre les deux : flexibilité du lac, structuration et capacités de requêtage de l’entrepôt. Des technologies comme Delta Lake ou Apache Iceberg incarnent cette évolution. C’est une approche cohérente, mais qui reste fondamentalement centralisée. Elle ne résout pas la question de qui est responsable de quoi, ni comment aligner producteurs et consommateurs de données. L’agilité organisationnelle reste absente.
C’est là que le data mesh se distingue fondamentalement. Là où les trois premières approches sont des choix technologiques, des façons de stocker et d’organiser la donnée, le data mesh est avant tout un choix organisationnel sur la distribution des responsabilités. Ce n’est pas un outil qu’on installe ; c’est une nouvelle façon de structurer qui fait quoi avec les données.
| Entrepôt | 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 multi-domaines | |
Une coexistence souvent nécessaire
Dans la majorité des cas, ces approches ne s’excluent pas. Beaucoup d’organisations qui adoptent le data mesh conservent leur entrepôt pour le reporting consolidé, leur data lake pour des projets de machine learning exploratoires, et une infrastructure lakehouse pour certains domaines à forte volumétrie de données. Le data mesh vient alors redistribuer la responsabilité de ces systèmes aux équipes qui en ont la meilleure connaissance.
🎯 Bon à savoir
On parle de data mesh hybride pour désigner cette configuration. Ce n’est pas une solution de compromis : c’est souvent la trajectoire la plus réaliste pour une organisation qui ne peut pas tout transformer simultanément.
Se lancer dans le Data Mesh : ce qu’il faut savoir avant
Ce modèle est-il fait pour vous ?
Le data mesh suscite beaucoup d’enthousiasme, et c’est précisément ce buzz qui peut pousser certaines équipes à se lancer sans vérifier si le contexte s’y prête. Ce serait une erreur de jugement. Cette architecture répond à des problèmes précis, dans des contextes précis.
Premier filtre évident : 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 approches centralisées soient devenues un véritable frein. Une petite structure avec quelques sources de données et une équipe analytique réduite n’en a pas besoin, un entrepôt bien configuré suffira, avec bien moins de complexité à gérer. En revanche, un groupe qui compte une vingtaine de divisions, des systèmes sources disparates et un backlog analytique qui grossit chaque trimestre gagnerait clairement à explorer ce modèle.
Trois signaux concrets indiquent que le moment est peut-être venu. Le premier est un backlog data chroniquement saturé, que tout le monde a fini par accepter comme une fatalité. Le deuxième est une prolifération de données fantômes : exports Excel non documentés, bases locales improvisées, calculs manuels répétés d’une équipe à l’autre, autant d’indicateurs que les équipes ont cessé de faire confiance aux systèmes officiels. Le troisième est une difficulté à croître : chaque nouveau marché, chaque entité acquise, déclenche un chantier data d’ampleur, ce qui finit par freiner la stratégie d’expansion.
Parmi les secteurs naturellement enclins à cette approche : les groupes industriels multisites, les acteurs financiers soumis à de fortes contraintes réglementaires, les retailers qui jonglent entre données de stock, de vente et de logistique, et les organisations en forte croissance externe qui cherchent à intégrer progressivement chaque entité acquise.
👉 Remarque
Une dernière condition, souvent la plus difficile à évaluer honnêtement : la maturité data des équipes. Une équipe qui n’a jamais géré de pipeline de données et considère la donnée comme un sujet purement informatique ne peut pas du jour au lendemain assumer le rôle de domaine autonome. Une évaluation réaliste de chaque département est indispensable pour décider qui peut être domaine pilote, et dans quel ordre les autres suivront.
Les conditions d’une transformation réussie
Les projets data mesh qui échouent, échouent rarement sur la technologie. Ils accrochent sur l’exécution : une gouvernance mal posée, des équipes insuffisamment préparées, ou une ambition trop large dès le départ.
Commencer par un périmètre limité. Un ou deux domaines pilotes, choisis pour leur maturité et leur capacité à générer rapidement de la valeur pour le reste de l’organisation. L’objectif n’est pas de démontrer que le concept est valide en théorie, mais de prouver qu’il fonctionne dans votre contexte spécifique. Rien ne convainc mieux un sceptique qu’un résultat concret venu d’un collègue.
Établir la gouvernance avant d’ouvrir les accès. Les questions de gouvernance ne se résolvent pas au fil de l’eau : elles s’accumulent et se durcissent. Conventions de nommage, standards de métadonnées, politiques d’accès, règles d’interopérabilité, ce socle minimal doit exister avant le premier pilote. Il n’a pas besoin d’être exhaustif, mais il doit être non négociable.
Investir dans l’infrastructure au préalable. Si la plateforme en libre-service n’est pas opérationnelle dès le départ, les équipes retomberont dans leurs dépendances habituelles. Le libre-service ne sera libre que de nom. Une attention particulière s’impose sur la gestion des données de référence : sans référentiel commun sur les clients, les produits ou les fournisseurs, chaque domaine finira par recréer ses propres silos, exactement ce qu’on cherchait à éviter.
Ne pas sous-estimer la conduite du changement. C’est probablement le facteur le plus négligé. Le data mesh redistribue des responsabilités et bouscule des habitudes ancrées. Les équipes métier doivent saisir concrètement ce que signifie être propriétaire de ses données. Les équipes data centrales doivent être accompagnées dans l’évolution de leur rôle, qui ne disparaît pas, mais se transforme. Et les dirigeants : DSI, CDO, directeurs métier, doivent incarner le projet : sans alignement au niveau des instances de décision, le data mesh restera un projet IT parmi d’autres, sans portée stratégique réelle.
A retenir
aucun
Comment fonctionne le Data Mesh concrètement ?
Le Data Mesh repose sur un principe simple : confier la gestion des données à ceux qui les produisent. Chaque domaine métier, commercial, logistique, RH, devient propriétaire de ses données, responsable de leur qualité et de leur mise à disposition, dans un cadre de gouvernance fédéré commun à toute l’organisation.
Peut-on adopter le Data Mesh sans abandonner son entrepôt de données ?
Oui, et c’est même la configuration la plus courante. L’entrepôt reste pertinent pour le reporting financier et la BI consolidée ; le Data Mesh vient redistribuer la responsabilité des systèmes existants aux équipes les mieux placées pour les gérer. Cette configuration hybride est souvent la plus adaptée à une transformation progressive.
Par où commencer pour mettre en place un Data Mesh ?
Identifier un ou deux domaines pilotes suffisamment matures pour générer rapidement de la valeur, puis poser le cadre de gouvernance avant d’ouvrir les accès. L’infrastructure libre-service doit être opérationnelle dès le départ, sans quoi les équipes retombent dans leurs dépendances habituelles et le projet perd sa raison d’être.
Échangez avec notre équipe et bénéficiez d’un accompagnement
Alexis Bourdeau
Directeur de projet
