Accueil›Blog›Test technique Data Mesh : domaines, data products, gouvernance fédérée
Guide recrutement data
Test technique Data Mesh : domaines, data products, gouvernance fédérée
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.
Data Builder·Juin 2025·8 min de lecture·Data Engineer · Data Architect
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é |
Home›Blog›Data Mesh technical interview: domains, data products, federated governance
Data hiring guide
Data Mesh technical interview: domains, data products, federated governance
Data Mesh challenges centralized data architecture. In Senior or Lead interviews, we assess the ability to architect by domain, define data products and design decentralized governance.
Data Builder·June 2025·8 min read·Data Engineer · Data Architect
Data Mesh is an architectural paradigm that decentralizes data ownership and governance to business teams (domains). In Lead or Architect interviews, we look for profiles able to understand the trade-offs — not those who apply Data Mesh to everything without thinking.
1The 4 fundamental principles
Discriminating question
What are the 4 principles of Data Mesh? Which one do you think is the most difficult to implement in practice?
- 1. Domain ownership — each business domain (Finance, Marketing, Logistics...) owns its data and is responsible for its quality and availability
- 2. Data as a product — data is treated as a product: it has an owner, an SLA, documentation, and measured quality
- 3. Self-serve data infrastructure — a centralized data platform provides tools so that domains can publish and consume data products without depending on a central team
- 4. Federated computational governance — global rules (security, GDPR compliance, interoperability) applied in a decentralized manner by each domain
The most difficult in practice: principle 1 — Domain ownership. It requires changing organizational culture and accepting that business teams become responsible for the quality of their data, which implies data skills within each team.
2Domain decomposition
Discriminating question
How do you define the boundaries of a data domain? Based on what criteria?
- Bounded contexts (DDD) — aligning with the boundaries of existing business contexts (orders, customers, products, deliveries)
- Decomposition criteria: organizational responsibility, frequency of change, data coupling, existing responsible team
- Domain types: source domains (raw data producers), consumer domains (consumers), aggregate domains (combiners)
- Anti-pattern — splitting by technology (a "Kafka" domain, an "S3" domain) instead of splitting by business
3Data products: definition and characteristics
Discriminating question
What makes a good data product? What are the characteristics it must meet according to Zhamak Dehghani?
Zhamak Dehghani (creator of the concept) defines 8 characteristics of a good data product:
- Discoverable — referenced in a data catalogue, findable by consumers
- Addressable — accessible via a stable address (URL, URI) regardless of the underlying storage
- Trustworthy — quality SLA defined and measured (freshness, completeness, accuracy)
- Self-describing — schema, semantics, owner, documentation included
- Interoperable — open standards for interoperability between domains
- Natively accessible — accessible in the consumer's native format (SQL, files, API)
- Secure — access control applied by the owning domain
- Valuable — meets a real need, has identified consumers
4Self-serve infrastructure
Discriminating question
What is a self-serve data platform in a Data Mesh context? What tools typically make up this platform?
- Role — enabling domains to publish data products without specialized infrastructure expertise
- Typical components:
- Data catalogue — DataHub, Apache Atlas, Collibra (discovery and documentation)
- Storage — S3/GCS with standardized partitioning, Delta Lake, Iceberg
- Transformation — dbt (each domain manages its models), Spark
- Ingestion — Fivetran, Airbyte (self-service for domains)
- Observability — Great Expectations, Monte Carlo (data quality)
- Orchestration — Airflow or Prefect with standard patterns
- Key principle — the platform is a product too. The platform team serves the domains, not the other way around
5Federated governance
Discriminating question
How do you apply GDPR compliance rules in a decentralized way within a Data Mesh?
- Global vs local policies — central governance defines the standards (encryption, anonymization, retention), domains implement them
- Data contracts — formal contracts between producers and consumers (schema, SLA, breaking change mode)
- Automated policy enforcement — Open Policy Agent (OPA), automated controls in the data product CI/CD pipeline
- Data lineage — traceability of data from source to end consumers
- Centralized catalogue — DataHub or Collibra as the source of truth for global governance
6Data Mesh vs Data Lakehouse: when to choose which
| Data Mesh | Data Lakehouse |
|---|
| Organization | Decentralized, by domain | Centralized, dedicated data team |
| Ownership | Each domain owns its data | Central data team |
| Best suited for | Large organization, multiple autonomous domains | SMEs, homogeneous data team, unified stack |
| Complexity | High (mostly organizational) | Moderate (mostly technical) |
| Technologies | dbt per domain, DataHub, Delta/Iceberg | Databricks, Snowflake, BigQuery |
Common mistake: adopting Data Mesh in a 5-person team. Data Mesh makes sense above a certain organizational size (several autonomous teams). For smaller structures, a well-governed Data Lakehouse is more suitable.
7Level grid
| Level | Expected mastery | GO signal | NO-GO |
|---|
| Confirmed | Knows the 4 principles, understands the concept of data product | Explains the 4 principles, can cite examples of domains and data products | Confuses Data Mesh with a technical architecture (not organizational) |
| Senior | Has participated in setting up a data domain, knows the tools (DataHub, dbt, data contracts) | Has defined a data product with SLA, has worked with data contracts, uses DataHub | Does not know what a data contract is, has never worked in domain mode |
| Lead | Has architected a migration to Data Mesh, has defined the self-serve platform | Has led a domain decomposition, has chosen platform tools, has managed trade-offs | Cannot explain when Data Mesh is not suitable |