1. Qu'est-ce que le data mesh ?
Le data mesh est une approche sociotechnique qui décentralise la propriété des données vers les équipes métiers. Créé par Zhamak Dehghani chez ThoughtWorks en 2019, il répond aux problèmes d'échelle des plateformes data centralisées.
Le problème que le mesh résout
Les équipes data centrales deviennent un goulot. Elles manquent de contexte métier et construisent les mauvais artefacts. Les domaines attendent des mois. Le data lake monolithique vire au data swamp. Ça vous parle ?
Architecture centralisée vs data mesh
❌ Centralisé (classique)
- • Une seule équipe possède toutes les données
- • Les domaines jettent leurs données "par-dessus le mur"
- • L'équipe centrale n'a pas le contexte métier
- • Data lake monolithique
- • Files d'attente interminables
- • Équipe data = goulet
✓ Data mesh
- • Les domaines possèdent leurs data products
- • Les données sont gérées comme un produit avec SLA
- • Les experts métier construisent les données de leur domaine
- • Data products fédérés et interopérables
- • Plateforme self-service pour l'autonomie
- • Scalabilité alignée sur l'organisation
Topologie data mesh
Domaine A
Commandes
Data Product
Domaine B
Clients
Data Product
Domaine C
Stocks
Data Product
Plateforme data self-service
Infrastructure • Tooling • Governance as Code
Gouvernance computationnelle fédérée
Politiques globales • Standards d'interopérabilité
Les domaines possèdent les data products, la plateforme habilite, la gouvernance assure l'interopérabilité
Idée clé
Le data mesh n'est pas qu'une histoire de techno : c'est un changement d'organisation. Vous redistribuez la propriété, la responsabilité et les compétences. Si vous le traitez comme un projet purement technique, vous échouerez.
2. Les quatre principes du data mesh
Le data mesh repose sur quatre piliers. En manquer un et tout s'effondre. Ils fonctionnent comme un système.
1. Propriété orientée domaine
Les équipes qui génèrent et comprennent les données les possèdent. Marketing possède les données marketing. Sales possède les données sales. Les experts métier deviennent owners de data product.
2. Les données comme un produit
Traitez les données comme un produit avec des consommateurs. SLA, documentation, versioning et owner produit. La qualité est la responsabilité du domaine, pas un problème à corriger plus tard par une équipe centrale.
3. Plateforme data self-service
Une équipe plateforme construit l'infrastructure que les domaines utilisent en autonomie. Les domaines ne devraient pas devoir comprendre Kubernetes ou Spark : ils construisent des data products.
4. Gouvernance computationnelle fédérée
Les politiques globales (sécurité, conformité, interopérabilité) sont définies de façon centrale mais appliquées localement par l'automatisation. La gouvernance est du code, pas des réunions.
| Principe | Responsable | Résultat clé |
|---|---|---|
| Propriété domaine | Équipes domaine | Expertise contextuelle, itération rapide |
| Données comme produit | Owners de data product | Qualité, découvrabilité, confiance |
| Plateforme self-service | Équipe plateforme | Autonomie des domaines, friction réduite |
| Gouvernance fédérée | Gouvernance + plateforme | Conformité, interopérabilité |
3. Focus data products
Un data product n'est pas juste une table. C'est une unité autonome qui inclut données, code, infrastructure et métadonnées : tout ce qu'il faut pour livrer de la valeur aux consommateurs.
Les huit caractéristiques d'un data product
Découvrable
Référencé dans un catalogue. Les consommateurs le trouvent sans demander.
Adressable
Adresse unique et stable (URI). Accès programmatique possible.
Fiable
Qualité mesurée, SLO, data contracts. Les consommateurs savent à quoi s’attendre.
Auto-descriptif
Schéma, lineage et documentation intégrés. Pas besoin de savoir tacite.
Interopérable
Suit les standards globaux de formats, identifiants et sémantique.
Sécurisé
Contrôles d’accès, chiffrement, audit. Conforme par défaut.
Accès natif
Multiples modes : SQL, API, fichiers. On va vers le consommateur.
Valeur autonome
Livrer de la valeur business seul. Pas juste une table de staging.
Anatomie d'un data product
Données
- • Données sources
- • Données transformées
- • Snapshots historiques
Code
- • Logique de transformation
- • Tests de qualité
- • Définition des pipelines
Métadonnées
- • Définitions de schéma
- • Data contracts
- • Infos de lineage
Exemple : manifeste de data product (YAML)
# orders-data-product/manifest.yaml name: orders domain: commerce owner: [email protected] version: 2.1.0 description: | Order transactions from all sales channels. Includes order items, totals, and fulfillment status. slo: freshness: 1h # Data no older than 1 hour availability: 99.9% # Uptime SLA quality_score: 95% # % of quality checks passing schema: type: delta location: s3://data-products/commerce/orders/ access: - sql: "SELECT * FROM commerce.orders" - api: "https://data.company.com/commerce/orders" lineage: sources: - system: shopify table: orders - system: pos table: transactions data_contract: primary_key: order_id not_null: [order_id, customer_id, order_date, total] quality_checks: - unique(order_id) - not_null(customer_id) - total >= 0 - order_date <= current_date()
Pro Tip
Commencez par des data products orientés consommateurs
Ne publiez pas seulement vos tables sources. Pensez aux besoins des consommateurs. Un data product « Orders » peut combiner commandes, paiements et fulfilment dans une vue dénormalisée simple à analyser.
4. Plateforme data self-service
La plateforme rend la propriété par domaine viable. Sans elle, chaque domaine réinventerait l'infra et ce serait le chaos. La plateforme fournit des abstractions opinionées qui réduisent la charge cognitive.
Capacités de la plateforme
Infrastructure data
Stockage (S3, Delta Lake), compute (Spark, dbt), orchestration (Airflow, Dagster). Les domaines utilisent, la plateforme opère.
Templates de data product
Templates cookiecutter pour créer un data product. CI/CD pré-câblé, tests qualité, enregistrement au catalogue. Déploiement en minutes.
Catalogue & découverte
Catalogue central (DataHub, Atlan, Collibra) où tous les data products sont enregistrés. Recherche, navigation, lineage.
Contrôle d'accès & sécurité
Identité centralisée, RBAC, chiffrement. Les domaines définissent qui accède ; la plateforme applique.
Observabilité & monitoring
Monitoring des pipelines, dashboards de qualité, suivi des SLO. Les domaines voient leur santé ; la plateforme consolide.
| Composant | Fourni par la plateforme | Action du domaine |
|---|---|---|
| Stockage | Buckets S3, tables Delta, politiques | Écrit les données aux chemins fournis |
| Compute | Clusters Spark, environnements dbt | Exécute les transformations |
| Pipelines | Infra Airflow/Dagster | Définit DAGs et plannings |
| Qualité | Framework de tests, dashboards | Écrit les tests, fixe les seuils |
| Catalogue | Instance DataHub/Atlan | Enregistre les produits, ajoute la doc |
Plateforme ≠ équipe data centrale 2.0
L'équipe plateforme construit l'infra et le tooling—pas les data products. Si elle produit encore les données des domaines, vous n'avez pas décentralisé. Elle habilite, elle n'exécute pas.
5. Gouvernance computationnelle fédérée
La décentralisation sans gouvernance mène au chaos. La gouvernance fédérée apporte des standards globaux avec autonomie locale. Les politiques sont définies au centre mais appliquées automatiquement par du code.
Ce qui est gouverné globalement
Standards d'interopérabilité
- • Conventions de nommage (snake_case, préfixes)
- • Identifiants globaux (format customer_id)
- • Formats date/heure (UTC, ISO 8601)
- • Règles d'évolution de schéma
Sécurité & conformité
- • Gestion des PII (masquage, chiffrement)
- • Patterns de contrôle d'accès
- • Politiques de rétention
- • Exigences de logs d'audit
Standards de qualité
- • SLO minimum
- • Tests de qualité requis
- • Standards de documentation
- • Format des data contracts
Ce que décident les domaines
- • Design des data products
- • Logique métier
- • Fréquence de mise à jour (au-dessus du SLO)
- • Droits d'accès spécifiques aux consommateurs
« Computationnelle » = gouvernance as code
Exemple : policy as code (OPA/Rego)
# governance/policies/data_product.rego
package dataproduct
# All data products must have an owner
deny[msg] {
not input.manifest.owner
msg := "Data product must have an owner defined"
}
# PII columns must be tagged
deny[msg] {
column := input.schema.columns[_]
column.pii == true
not column.tags["pii"]
msg := sprintf("PII column %v must be tagged", [column.name])
}
# SLO freshness must be defined
deny[msg] {
not input.manifest.slo.freshness
msg := "Data product must define freshness SLO"
}
# Minimum documentation required
deny[msg] {
count(input.manifest.description) < 50
msg := "Data product description must be at least 50 characters"
}Pro Tip
Gouvernance en CI/CD, pas en comité
Chaque PR de data product passe par des checks de policies. Non conforme ? Le build échoue. Pas besoin de comités. La plateforme applique automatiquement ; les humains gèrent les exceptions, pas la conformité courante.
6. Feuille de route d'implémentation
Le data mesh est un trajet sur plusieurs années. Ne faites pas bouillir l'océan. Commencez petit, prouvez la valeur, étendez.
Phase 1 : Fondations (mois 1-3)
Obtenez l'adhésion du leadership. Identifiez 1-2 domaines pilotes. Définissez le minimum de gouvernance.
- • Choisir des domaines pilotes motivés
- • Documenter l'état actuel et les douleurs
- • Définir ce que « data product » signifie chez vous
- • Identifier l'équipe plateforme (ou recruter)
Phase 2 : Premiers data products (mois 3-6)
Les domaines pilotes construisent leurs premiers data products. La plateforme fournit l'infrastructure minimale viable.
- • Construire 2-3 data products par domaine pilote
- • Déployer un catalogue basique (même un tableur)
- • Établir un template de data product
- • Documenter les apprentissages et itérer
Phase 3 : Maturité plateforme (mois 6-12)
L'équipe plateforme industrialise les apprentissages. Les capacités self-service émergent. D'autres domaines embarquent.
- • Mettre en place un vrai data catalog
- • Construire la CI/CD des data products
- • Automatiser les contrôles de gouvernance
- • Onboard 3-5 domaines supplémentaires
Phase 4 : Scale (année 2+)
Adoption à l'échelle. La plateforme est mature. Le focus se déplace vers l'optimisation et les capacités avancées.
- • Tous les domaines produisent des data products
- • Des data products cross-domain apparaissent
- • Marketplace de data products
- • Amélioration continue de la plateforme
Retour de terrain
L'erreur la plus fréquente : commencer par la plateforme. Ne construisez pas une belle plateforme self-service puis cherchez des utilisateurs. Commencez par des domaines qui créent des data products manuellement. Leur douleur doit guider les exigences de la plateforme.
7. Anti-patterns à éviter
Traiter le mesh comme un projet techno
Acheter des outils sans changer l'organisation. Le mesh est sociotechnique : le changement orga vient d'abord, la tech le soutient.
L’équipe centrale construit toujours les données
Appeler des ingénieurs détachés « équipes domaine » alors qu'ils reportent toujours au central. La vraie propriété rend les domaines responsables.
Pas de plateforme, juste de la décentralisation
Dire aux domaines « vous possédez vos données maintenant » sans leur donner d'outils. Résultat : duplication, chaos, burnout.
Gouvernance par comité
Réunions mensuelles au lieu de contrôles automatisés. Des politiques dans des documents, pas dans du code.
Chaque table devient un data product
Publier des tables de staging et les appeler produits. Un data product doit livrer de la valeur business, pas juste exposer des données.
Ignorer la conduite du changement
Attendre que les domaines prennent la responsabilité sans formation, incitations ni trajectoires de carrière data.
Reality check
Le data mesh est-il fait pour vous ?
Le data mesh n'est peut-être pas la réponse si : vous avez moins de 50 personnes, un seul produit/domaine, une équipe centrale qui fonctionne, ou un leadership qui ne soutient pas le changement. C'est une réponse aux problèmes d'échelle : sans problème de scale, une bonne équipe centrale peut suffire.
8. FAQ
Qu'est-ce que le data mesh ?
Le data mesh est une architecture décentralisée qui traite les données comme un produit, possédé par les équipes domaines plutôt qu'une équipe centrale. Ses quatre principes : propriété orientée domaine, données comme produit, plateforme data self-service et gouvernance computationnelle fédérée. Créé par Zhamak Dehghani chez ThoughtWorks.
Quelle différence entre data mesh et data fabric ?
Le data mesh est une approche organisationnelle et architecturale axée sur la décentralisation et la propriété par domaine. Le data fabric est une approche techno centrée sur métadonnées et IA pour créer une couche unifiée. Le mesh change la façon de travailler ; le fabric est surtout des outils et de l'automatisation. Ils sont complémentaires.
Qu’est-ce qu’un data product dans le mesh ?
Un data product est une unité autonome, découvrable, adressable, fiable, auto-descriptive, interopérable et sécurisée. Il inclut les données, les métadonnées, le code de transformation, l'infrastructure et la documentation. Les équipes domaines possèdent et opèrent leurs data products comme des microservices.
Quand éviter le data mesh ?
Le data mesh n'est peut-être pas adapté si : votre organisation compte moins de 50 personnes, vous n'avez qu'un seul domaine ou produit, votre équipe data fonctionne bien, vous manquez de maturité d'ingénierie pour le self-service, ou le leadership ne soutient pas le changement. C'est une transformation organisationnelle, pas seulement technique.
Visualisez votre architecture data mesh
Cartographiez vos domaines, data products et composants plateforme. Créez des diagrammes clairs qui communiquent votre vision data mesh aux parties prenantes et aux équipes.
Guides associés
Medallion architecture
Couches Bronze, Silver, Gold dans vos data products
Modélisation dimensionnelle
Concevoir des data products que les analystes adorent
Data contracts
Définir les interfaces et garanties des data products
Bonnes pratiques de qualité
Intégrer la qualité au cœur des data products
Data lineage
Tracer les flux de données entre domaines et produits