Guide architecture data

Guide Data Mesh

Votre équipe data centrale est un goulet. Chaque domaine veut des données mais les demandes s'empilent pendant des mois. Le data mesh inverse le modèle : les domaines possèdent leurs données comme des produits, tandis qu'une équipe plateforme permet le self-service.

25 min de lecturePour leaders data & plateformePatterns d'implémentation inclus

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.

Ce qui change : des data engineers s'intègrent aux équipes métier. Les domaines sont responsables de la qualité et de la disponibilité. L'équipe centrale devient équipe plateforme.

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.

Ce qui change : Découvrabilité, SLO, schémas et docs. Les domaines pensent « qui va consommer ? » pas « posons ça quelque part ».

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.

Ce qui change : L'équipe centrale devient équipe plateforme. Elle construit tooling, templates, automatisation. Elle réduit la charge cognitive.

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.

Ce qui change : Politiques encodées dans la plateforme. Contrôles automatiques de conformité. Les domaines ont de l'autonomie dans des garde-fous.
PrincipeResponsableRésultat clé
Propriété domaineÉquipes domaineExpertise contextuelle, itération rapide
Données comme produitOwners de data productQualité, découvrabilité, confiance
Plateforme self-serviceÉquipe plateformeAutonomie des domaines, friction réduite
Gouvernance fédéréeGouvernance + plateformeConformité, 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.

ComposantFourni par la plateformeAction du domaine
StockageBuckets S3, tables Delta, politiquesÉcrit les données aux chemins fournis
ComputeClusters Spark, environnements dbtExécute les transformations
PipelinesInfra Airflow/DagsterDéfinit DAGs et plannings
QualitéFramework de tests, dashboardsÉcrit les tests, fixe les seuils
CatalogueInstance DataHub/AtlanEnregistre 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.