Data Mesh : Repenser la Gouvernance des Données à Grande Échelle
#data-architecture#data-mesh#data-engineering#organization
Le Problème des Équipes Data Centralisées
La plupart des organisations commencent avec une équipe data unique et centralisée, responsable de l'ingestion, de la transformation et de la mise à disposition de toutes les données. Ce modèle fonctionne jusqu'à un certain seuil. Le schéma de goulet d'étranglement est prévisible :
- Les domaines métier se multiplient plus vite que l'équipe data ne peut recruter
- L'équipe centrale devient une file d'attente de tickets, pas un partenaire stratégique
- Le contexte métier se perd dans la traduction entre producteurs et équipe data
- Le délai d'obtention des insights croît linéairement avec la complexité organisationnelle
Les Quatre Principes du Data Mesh
Le Data Mesh, introduit par Zhamak Dehghani, repose sur quatre principes fondateurs :
| Principe | Description | Question Clé |
|---|---|---|
| Propriété par Domaine | Chaque domaine métier possède et sert ses propres données | Qui est responsable de cette donnée ? |
| Donnée comme Produit | La donnée est traitée avec une logique produit (SLOs, docs, découvrabilité) | Quelqu'un choisirait-il d'utiliser cette donnée ? |
| Plateforme Self-Service | L'infrastructure abstrait la complexité pour les équipes domaine | Une équipe domaine peut-elle livrer un produit data sans ticket ? |
| Gouvernance Fédérée | Standards globaux, autonomie locale | Les règles d'interopérabilité sont-elles claires et appliquées ? |
tadata
| Domain ownership | Each team owns their data lake/zone. Dataplex lakes map to business domains. Teams control quality and publishing. |
|---|---|
| Data as a product | Data must be discoverable, addressable, trustworthy, self-describing, interoperable. Published via Analytics Hub or BigQuery authorized views. |
| Self-serve platform | Central platform team provides: Dataplex setup, BigQuery infrastructure, Data Catalog, monitoring. Domain teams use self-service. |
| Federated governance | Global standards (naming, quality, security) enforced by org policies and Dataplex rules. Domain-specific policies by teams. |
| Analytics Hub | Publish and subscribe to BigQuery datasets. Cross-org data sharing. Data clean rooms for privacy-preserving analytics. |
Extrait de la fiche « Data Lakes & Storage » · Demander la fiche complète
Propriété par Domaine en Pratique
La propriété par domaine signifie que l'équipe qui génère la donnée est responsable de la rendre disponible en tant que produit de qualité :
- Avant : l'équipe Ventes génère des événements, l'équipe centrale ingère, transforme, sert
- Après : l'équipe Ventes possède un produit data "Événements Ventes" avec schéma défini, SLOs et documentation
L'équipe domaine n'a pas besoin de devenir data engineer. La plateforme self-service doit gérer les préoccupations d'infrastructure.
Donnée comme Produit : Ce que Cela Signifie
Un produit data doit avoir :
- Découvrabilité -- référence dans un catalogue, recherchable
- Adressabilité -- un chemin d'accès stable et connu
- Fiabilité -- métriques de qualité, SLOs de fraîcheur
- Auto-description -- schéma, sens sémantique, lignage
- Interopérabilité -- suit les standards organisationnels pour les formats et identifiants
- Sécurité -- contrôles d'accès alignés avec les politiques de gouvernance
Quand le Data Mesh Fonctionne
- Grandes organisations avec 5+ domaines métier distincts
- Entreprises où l'expertise domaine est critique pour l'interprétation des données
- Organisations avec une culture d'ingénierie mature dans les équipes domaine
- Environnements où l'équipe data centrale est un goulet d'étranglement avéré
Quand le Data Mesh ne Fonctionne Pas
- Petites entreprises (moins de 50 ingénieurs) -- la surcharge n'est pas justifiée
- Organisations sans maturité d'ingénierie dans les équipes domaine
- Entreprises sans sponsorship exécutif pour le changement organisationnel
- Environnements où le volume de données est faible
Centralisé vs Data Mesh : Comparaison
| Dimension | Centralisé | Data Mesh |
|---|---|---|
| Risque de goulet | Élevé (équipe unique) | Plus faible (distribué) |
| Contexte domaine | Perdu dans les transferts | Préservé |
| Investissement plateforme | Plus faible | Plus élevé (infra self-service) |
| Complexité gouvernance | Plus simple | Plus élevée (fédérée) |
| Changement org. requis | Minimal | Significatif |