Le data mesh fonctionne quand on le traite comme un modèle de responsabilité, pas comme une architecture à déployer : confier à des domaines métier la propriété de produits de données clairement définis, avec des contrats explicites et une plateforme commune, apporte des gains réels de qualité et de délai. Il coince quand on veut décentraliser d'un coup toute la donnée d'une organisation qui n'a ni les compétences dans les domaines, ni la plateforme en libre-service, ni les règles communes pour le faire.
Le concept a été formulé par Zhamak Dehghani en mai 2019, en réaction aux plateformes de données centralisées devenues des goulots d'étranglement : une équipe data unique, éloignée du contexte métier, ne peut pas suivre la multiplication des sources et des consommateurs 1. Sept ans plus tard, le vocabulaire s'est diffusé ; les pratiques, de façon plus inégale.
Cet article distingue les trois notions souvent confondues (data mesh, data product, data contract), puis fait le point sur ce qui marche, ce qui bloque et comment avancer sans grand programme de transformation.
Les quatre principes du data mesh, relus en 2026
L'article de référence publié en décembre 2020 pose quatre principes 2 :
- Propriété décentralisée par domaine : les équipes alignées sur les domaines métier possèdent leurs données analytiques, leurs métadonnées et les traitements qui les servent.
- La donnée comme produit : les domaines traitent leurs données comme des produits dont les consommateurs sont des clients, avec des responsables mesurés sur la qualité, les délais et la satisfaction des utilisateurs.
- Une infrastructure en libre-service : une plateforme fournit des abstractions qui permettent aux domaines de construire et d'exploiter leurs produits sans expertise d'infrastructure poussée.
- Une gouvernance fédérée et computationnelle : domaines et plateforme définissent ensemble des règles globales, que la plateforme applique automatiquement.
Ces principes sont interdépendants. Décentraliser la propriété sans plateforme en libre-service revient à demander à chaque domaine de reconstruire sa propre stack ; décentraliser sans gouvernance fédérée produit des silos incompatibles. C'est souvent là que les projets ont déraillé : en retenant le premier principe et en négligeant les trois autres.
Data product et data contract : deux objets différents
Le data product, unité de responsabilité
Dans la définition d'origine, un data product est le « quantum architectural », la plus petite unité déployable indépendamment. Il regroupe le code (pipelines, API d'accès et de métadonnées, application des politiques d'accès et de conformité), les données et leurs métadonnées (sémantique, métriques de qualité), et l'infrastructure nécessaire pour le construire et l'exécuter 2. Il doit être trouvable, compréhensible, digne de confiance et sécurisé 2.
Le data contract, accord explicite entre producteur et consommateur
Le data contract est plus étroit : c'est un accord formel entre un producteur et ses consommateurs sur une interface de données. Confluent le définit, pour les données en mouvement, comme un accord dont le schéma n'est qu'une partie, complété par des contraintes d'intégrité, des métadonnées (par exemple un tag signalant une donnée personnelle, un propriétaire) et des règles de validation ou de migration entre versions 6. Le producteur l'applique, le consommateur peut s'y fier.
Les deux objets se standardisent. Le projet Bitol, hébergé par la Linux Foundation AI & Data, publie l'Open Data Contract Standard (ODCS, version 3.2.0 à la date de rédaction) et l'Open Data Product Standard (ODPS, version 1.1.0) 3. Un contrat ODCS est un fichier YAML qui couvre notamment le schéma, la qualité, le support, l'équipe, les rôles, les niveaux de service et les serveurs 4 ; ODPS décrit le produit lui-même, son équipe, son support et ses ports de gestion 5.
Un data product dit qui est responsable ; un data contract dit ce qui est promis. Il faut les deux.
Ce qui fonctionne
Certaines pratiques issues du data mesh produisent des effets tangibles même sans adopter le modèle dans son ensemble, parce qu'elles traitent directement les causes les plus fréquentes d'incidents de données : absence de responsable, changements non annoncés, contrôles inexistants.
- Nommer un propriétaire métier pour chaque jeu de données critique : la question « qui corrige quand c'est faux ? » trouve enfin une réponse.
- Écrire des contrats sur les interfaces les plus consommées d'abord : les flux qui ont le plus de consommateurs sont ceux dont une rupture coûte le plus cher, ce sont eux qui méritent un engagement de schéma et de fraîcheur.
- Faire appliquer les contrats par la machine : contrôles de compatibilité de schéma bloquants dans la chaîne d'intégration, règles de qualité exécutées à l'écriture, données invalides isolées plutôt que propagées 6.
- Versionner les contrats et organiser les changements incompatibles : nouvelle version majeure, période de coexistence, puis retrait.
- Publier les data products dans un catalogue avec leur contrat, leur propriétaire et leurs indicateurs de qualité : la découverte devient possible sans passer par l'équipe centrale.
Le streaming est un terrain particulièrement favorable : avec un registre de schémas, la règle de compatibilité est appliquée au moment de la publication, et des règles de domaine peuvent valider ou transformer les messages, avec routage des enregistrements en échec vers un topic dédié 6. Le contrat cesse d'être un document pour devenir un contrôle.
Ce qui coince, et pourquoi
Des domaines sans compétences ni budget data
Confier la propriété d'un produit de données à un domaine suppose que ce domaine dispose de profils capables de le construire et de l'exploiter, et d'un budget pour cela. Dans beaucoup d'ETI, ces compétences sont concentrées dans une équipe centrale. Décentraliser sans transférer de moyens revient à déplacer le problème.
Une plateforme en libre-service sous-estimée
Le libre-service est le principe le plus coûteux à réaliser : provisionnement automatisé, gabarits de pipelines, gestion des accès, observabilité, publication au catalogue. Sans lui, chaque domaine réinvente ses outils et le coût total augmente au lieu de baisser.
Une gouvernance fédérée restée sur papier
La gouvernance « computationnelle » suppose que les règles communes (identifiants partagés, classification des données sensibles, conventions de nommage, exigences de qualité minimales) soient codées et appliquées automatiquement par la plateforme 2. Quand elles restent dans un wiki, les produits divergent et l'interopérabilité promise disparaît.
Des data products mal dimensionnés
Le découpage en produits est un exercice de conception à part entière. Trop fins, les data products se multiplient, chacun avec son propriétaire, son contrat et sa maintenance, et les consommateurs doivent en assembler une dizaine pour répondre à une question simple. Trop larges, ils reproduisent un entrepôt central sous un autre nom, avec un propriétaire qui ne maîtrise pas l'ensemble du périmètre. Le bon niveau se situe généralement autour d'un concept métier stable (client, commande, contrat, sinistre) que le domaine connaît et sait faire évoluer, avec des interfaces pensées pour les usages les plus fréquents.
Des contrats sans consommateurs identifiés
Un contrat écrit par un producteur seul, sans les consommateurs, décrit ce qui est facile à garantir et non ce qui est utile. Il est vite contourné. Le contrat doit être négocié, et ses engagements de service doivent correspondre à des besoins réels.
Une démarche progressive pour démarrer un data mesh
Plutôt qu'un programme de transformation, une approche par incréments limite le risque et produit des preuves rapidement :
- Choisir un ou deux domaines volontaires, dotés d'un sponsor et d'un cas d'usage consommateur clairement identifié.
- Définir trois à cinq data products prioritaires, avec un propriétaire nommé et un contrat négocié avec les consommateurs.
- Adopter un format de contrat standard (par exemple ODCS) plutôt qu'un modèle maison, pour faciliter l'outillage et la réutilisation.
- Automatiser dès le départ un minimum de contrôles : compatibilité de schéma, règles de qualité, fraîcheur, classification des données personnelles.
- Construire la plateforme à partir des besoins de ces premiers domaines, puis l'ouvrir aux suivants.
- Mesurer : nombre de consommateurs par produit, incidents de qualité, délai de mise à disposition. Ces indicateurs justifient ou non l'extension.
Il est tout à fait légitime de s'arrêter à mi-chemin : une organisation avec une équipe data centrale, mais des propriétaires métier nommés et des contrats appliqués automatiquement, capte une grande partie des bénéfices sans supporter le coût d'une décentralisation complète.
Conclusion
Le data mesh a eu le mérite de poser la bonne question : qui est responsable de la donnée, et envers qui ? Data products et data contracts sont les réponses opérationnelles les plus robustes, à condition d'être appliqués par la plateforme plutôt que documentés. La décentralisation, elle, se dose selon la maturité de chaque domaine. DATASWING accompagne ce type de démarche en commençant par les interfaces de données les plus critiques.
— Questions fréquentes
Ce qu'on nous demande souvent
Quelle est la différence entre data mesh et data fabric ?+
Le data mesh est avant tout un modèle d'organisation : il confie la propriété des données analytiques aux domaines métier, avec une plateforme commune et une gouvernance fédérée. Le terme data fabric désigne plutôt une approche technologique d'intégration et de gestion des métadonnées. Les deux peuvent coexister : une fabric peut servir de socle technique à un mesh.
Qu'est-ce qu'un data contract concrètement ?+
C'est un accord formel, souvent écrit en YAML, entre le producteur d'un jeu de données et ses consommateurs. Il décrit le schéma, les règles de qualité, les niveaux de service comme la fraîcheur, les propriétaires et les conditions d'évolution. Pour être utile, il doit être vérifié automatiquement, par exemple dans la chaîne d'intégration ou à l'écriture des données.
Faut-il une grande organisation pour faire du data mesh ?+
Le data mesh complet suppose des domaines dotés de compétences data et une plateforme en libre-service, ce qui est plus accessible aux grandes organisations. Une ETI peut néanmoins en appliquer les pratiques les plus rentables : nommer des propriétaires métier, définir quelques data products prioritaires et automatiser leurs contrats, sans décentraliser toute l'équipe data.
Existe-t-il un standard pour les data contracts ?+
Oui, l'Open Data Contract Standard (ODCS), publié par le projet Bitol de la Linux Foundation AI & Data, définit la structure YAML d'un contrat : schéma, qualité, support, équipe, rôles, niveaux de service et serveurs. Le même projet publie l'Open Data Product Standard (ODPS) pour décrire les data products eux-mêmes.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh ↗martinfowler.com (Zhamak Dehghani) · 2019-05
-
[2]
Data Mesh Principles and Logical Architecture ↗martinfowler.com (Zhamak Dehghani) · 2020-12
-
[3]
Bitol – Open standards for data contracts and data products ↗Bitol / Linux Foundation AI & Data · 2026
-
[4]
Open Data Contract Standard (ODCS) ↗Bitol / Linux Foundation AI & Data · 2026
-
[5]
Open Data Product Standard (ODPS) ↗Bitol / Linux Foundation AI & Data · 2026
-
[6]
Data Contracts for Schema Registry on Confluent Platform ↗Confluent (documentation officielle) · 2026
