Le Data Mesh remet en question l'architecture data centralisée. En entretien Senior ou Lead, on évalue la capacité à architecturer par domaine, définir des data products et concevoir une gouvernance décentralisée.
Le Data Mesh est un paradigme architectural qui décentralise la propriété et la gouvernance de la donnée vers les équipes métier (domaines). En entretien Lead ou Architect, on cherche des profils capables de comprendre les trade-offs — pas ceux qui appliquent Data Mesh à tout sans réfléchir.
1Les 4 principes fondamentaux
Question discriminante
Quels sont les 4 principes du Data Mesh ? Lequel est selon vous le plus difficile à mettre en œuvre en pratique ?
- 1. Domain ownership — chaque domaine métier (Finance, Marketing, Logistique...) est propriétaire de ses données et responsable de leur qualité et disponibilité
- 2. Data as a product — les données sont traitées comme des produits : elles ont un owner, une SLA, une documentation, une qualité mesurée
- 3. Self-serve data infrastructure — une plateforme data centralisée fournit les outils pour que les domaines publient et consomment des data products sans dépendre d'une équipe centrale
- 4. Federated computational governance — des règles globales (sécurité, conformité RGPD, interopérabilité) appliquées de manière décentralisée par chaque domaine
Le plus difficile en pratique : le principe 1 — Domain ownership. Il nécessite de changer la culture organisationnelle et d'accepter que les équipes métier deviennent responsables de la qualité de leurs données, ce qui implique des compétences data dans chaque équipe.
2Décomposition en domaines
Question discriminante
Comment délimitez-vous les frontières d'un domaine data ? Sur quels critères ?
- Bounded contexts (DDD) — s'aligner sur les frontières des contextes métier existants (commandes, clients, produits, livraisons)
- Critères de découpage : responsabilité organisationnelle, fréquence de changement, couplage des données, équipe responsable existante
- Types de domaines : source domains (producteurs de données brutes), consumer domains (consommateurs), aggregate domains (combinateurs)
- Anti-pattern — découper par technologie (un domaine "Kafka", un domaine "S3") au lieu de découper par métier
3Data products : définition et caractéristiques
Question discriminante
Qu'est-ce qu'un bon data product ? Quelles sont les caractéristiques qu'il doit respecter selon Zhamak Dehghani ?
Zhamak Dehghani (créatrice du concept) définit 8 caractéristiques d'un bon data product :
- Discoverable — référencé dans un catalogue data, trouvable par les consommateurs
- Addressable — accessible via une adresse stable (URL, URI) quel que soit le stockage sous-jacent
- Trustworthy — SLA de qualité défini et mesuré (fraîcheur, complétude, exactitude)
- Self-describing — schéma, sémantique, propriétaire, documentation inclus
- Interoperable — standards ouverts pour l'interopérabilité entre domaines
- Natively accessible — accessible dans le format natif du consommateur (SQL, fichiers, API)
- Secure — contrôle d'accès appliqué par le domaine propriétaire
- Valuable — répond à un besoin réel, a des consommateurs identifiés
4Self-serve infrastructure
Question discriminante
Qu'est-ce qu'une self-serve data platform dans un contexte Data Mesh ? Quels outils composent typiquement cette plateforme ?
- Rôle — permettre aux domaines de publier des data products sans expertise infrastructure spécialisée
- Composants typiques :
- Data catalogue — DataHub, Apache Atlas, Collibra (découverte et documentation)
- Stockage — S3/GCS avec partitionnement standardisé, Delta Lake, Iceberg
- Transformation — dbt (chaque domaine gère ses modèles), Spark
- Ingestion — Fivetran, Airbyte (self-service pour les domaines)
- Observabilité — Great Expectations, Monte Carlo (qualité des données)
- Orchestration — Airflow ou Prefect avec des patterns standards
- Principe clé — la plateforme est un produit aussi. L'équipe plateforme est au service des domaines, pas l'inverse
5Gouvernance fédérée
Question discriminante
Comment appliquez-vous des règles de conformité RGPD de manière décentralisée dans un Data Mesh ?
- Politiques globales vs locales — la gouvernance centrale définit les standards (chiffrement, anonymisation, rétention), les domaines les implémentent
- Data contracts — contrats formels entre producteurs et consommateurs (schéma, SLA, mode de breaking change)
- Automated policy enforcement — Open Policy Agent (OPA), contrôles automatisés dans le pipeline CI/CD du data product
- Data lineage — traçabilité de la donnée de la source jusqu'aux consommateurs finaux
- Catalogue centralisé — DataHub ou Collibra comme source de vérité pour la gouvernance globale
6Data Mesh vs Data Lakehouse : quand choisir quoi
| Data Mesh | Data Lakehouse |
|---|
| Organisation | Décentralisée, par domaine | Centralisée, équipe data dédiée |
| Propriété | Chaque domaine possède ses données | Équipe data centrale |
| Adapté pour | Grande organisation, multiples domaines autonomes | PME, équipe data homogène, stack unifiée |
| Complexité | Élevée (organisationnelle surtout) | Modérée (technique surtout) |
| Technologies | dbt par domaine, DataHub, Delta/Iceberg | Databricks, Snowflake, BigQuery |
Erreur fréquente : adopter Data Mesh dans une équipe de 5 personnes. Data Mesh a du sens à partir d'une certaine taille organisationnelle (plusieurs équipes autonomes). Pour les petites structures, un Data Lakehouse bien gouverné est plus adapté.
7Grille par niveau
| Niveau | Maîtrise attendue | Signal GO | NO-GO |
|---|
| Confirmé | Connaît les 4 principes, comprend le concept de data product | Explique les 4 principes, peut citer des exemples de domaines et de data products | Confond Data Mesh avec une architecture technique (pas organisationnelle) |
| Senior | A participé à la mise en place d'un domaine data, connaît les outils (DataHub, dbt, data contracts) | A défini un data product avec SLA, a travaillé avec des data contracts, utilise DataHub | Ne sait pas ce qu'est un data contract, n'a jamais travaillé en mode domaine |
| Lead | A architecturé une migration vers Data Mesh, a défini la self-serve platform | A mené une décomposition en domaines, a choisi les outils de la plateforme, a géré les trade-offs | Ne peut pas expliquer quand Data Mesh n'est pas adapté |