Carnets

Data mesh

5 min de lecture

Data mesh

Résumé

Le data mesh est une approche de la donnée analytique à grande échelle, proposée par Zhamak Dehghani en 2019. Plutôt que de centraliser toute la donnée d’une organisation dans un lac ou un entrepôt géré par une seule équipe, on la confie aux domaines métier qui la connaissent, chacun la publiant comme un produit (Data product), sur une plateforme en libre-service, avec une gouvernance fédérée. C’est un modèle d’organisation autant qu’un schéma d’architecture : un mesh techniquement propre peut échouer si personne ne porte réellement les produits.

Prérequis

Inmon, Kimball et Data Vault (l’approche centralisée) et Data lake vs lakehouse. Les notions de plateforme et de domaine métier sont définies au fil du texte.

Pourquoi : les limites du modèle centralisé

Dehghani décrit en 2019 trois modes d’échec des plateformes de données centralisées (lacs, entrepôts) :1

  • Centralisation et monolithe : une seule plateforme doit tout ingérer, nettoyer et servir, ce qui devient un goulot d’étranglement quand les sources et les usages se multiplient.
  • Étapes de pipeline couplées : le découpage par étape technique (ingérer, transformer, servir) oblige à modifier plusieurs étapes pour un seul changement.
  • Propriété cloisonnée : les équipes de données centrales sont éloignées des producteurs et des consommateurs, donc du sens métier.

Le mesh vise à réduire ces trois frictions.

Les quatre principes

Formulés dans l’article de Dehghani publié sur le site de Martin Fowler en 2020 :2

  • Propriété décentralisée par domaine : chaque domaine possède et publie sa donnée, si bien qu’ajouter une source ou un usage revient à ajouter un nœud autonome.
  • La donnée comme produit : les consommateurs trouvent, comprennent et utilisent des données fiables sans dépendre de ceux qui les ont produites.
  • Infrastructure en libre-service : une plateforme masque la complexité technique, ce qui permet aux domaines de créer et consommer des produits seuls.
  • Gouvernance fédérée et computationnelle : des standards communs, appliqués par la plateforme elle-même, rendent les produits combinables.

Les domaines

Le découpage suit les unités de l’organisation, c’est-à-dire les domaines métier et leur contexte délimité (bounded context). Un domaine publie non seulement ses interfaces opérationnelles (API) mais aussi un accès à sa donnée analytique. Dehghani distingue deux sortes de données de domaine :1

  • Alignée sur la source : elle représente les faits du métier tels que les produisent les systèmes opérationnels (les clics des utilisateurs, la lecture d’un morceau). Plusieurs systèmes peuvent alimenter un même domaine.
  • Alignée sur le consommateur : agrégats et structures taillés pour un usage particulier (un graphe de relations sociales pour des recommandations). Ils changent plus souvent et doivent pouvoir être régénérés depuis la source.

La gouvernance fédérée

Une instance composée des responsables de produits de données des domaines et de ceux de la plateforme décide de ce qui est local et de ce qui est global. Le but des décisions globales est l’interopérabilité : pouvoir corréler des produits de plusieurs domaines. Les règles s’appliquent par la plateforme, de façon automatisée.2

En pratique, la gouvernance passe d’une équipe centrale qui contrôle la qualité, la sécurité et la conformité à une instance fédérée qui définit les règles (ce qu’est une donnée de qualité, les niveaux de sensibilité, les exigences réglementaires) pendant que la plateforme les applique et les surveille automatiquement. Le succès ne se mesure plus au volume de données gouvernées mais à l’effet de réseau, c’est-à-dire aux connexions de consommation entre produits.2

Conditions de réussite

Les sources fondatrices donnent quatre conditions, qui sont aussi les points où un mesh échoue quand ils manquent :12

  • Un propriétaire de produit réel. Donner un domaine à une équipe ne suffit pas : le propriétaire d’un produit de données répond de mesures objectives comme la qualité de la donnée et la réduction du délai pour que les consommateurs l’utilisent. Voir Data product.
  • Une plateforme qui absorbe la complexité. Provisionner, exécuter et surveiller un produit demande des compétences spécialisées qu’il serait coûteux de répliquer dans chaque domaine : sans plateforme en libre-service, les domaines ne peuvent pas être autonomes.
  • Des règles communes minimales et automatisées. Les décisions globales n’ont qu’un but, l’interopérabilité : pouvoir combiner des produits de domaines différents. Plus elles sont appliquées par la plateforme (et non par des revues manuelles), moins elles freinent les domaines.
  • Une mesure fondée sur l’usage. Le succès se lit à l’effet de réseau, c’est-à-dire aux connexions de consommation entre produits, pas au volume de tables gouvernées.

Quand c’est adapté

Avis, pas règle

Les sources décrivent le mesh pour de grandes organisations aux domaines riches et aux sources nombreuses. L’article de 2019 présente le modèle centralisé comme mal adapté à ce contexte, pas à tous les contextes.1 Pour une petite équipe, un entrepôt ou un lakehouse central (Choisir entre lake, lakehouse et warehouse) reste le plus simple. Un mesh a un coût d’organisation : rôles de propriétaires de produits, plateforme à construire et à faire vivre, instance de gouvernance. À chiffrer avant de s’engager.

Notes liées

Notes de bas de page

  1. Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, martinfowler.com, 20 mai 2019, consulté le 24 octobre 2026. ↩ ↩2 ↩3 ↩4

  2. Zhamak Dehghani, Data Mesh Principles and Logical Architecture, martinfowler.com, 3 décembre 2020, consulté le 24 octobre 2026. ↩ ↩2 ↩3 ↩4

Vue Graphique

Liens retour