Article
Data mesh en mouvement : 6 scénarios pour comprendre les rôles et les outils
Qui fait quoi, avec quoi, et comment la donnée circule.
Le data mesh est un sujet complexe à appréhender. Dans cet article, je vais essayer d’en montrer le fonctionnement concret. Je rassemble ici six fiches pratiques présentées sous forme de scénario, une par situation que l’on peut rencontrer avec une architecture data mesh. Elles couvrent ce qui me paraissait essentiel, de la naissance d’un data product à son éventuel retrait. L’article s’adresse à ceux qui ont déjà vu passer le mot « data mesh » et veulent comprendre concrètement comment un data product circule entre rôles, outils et décisions : architecte data, product owner ou métier, data engineer, dirigeant qui se demande si le mesh est pertinent pour lui.
Avant de commencer, voici un rappel des quatre principes[1] du data mesh :
- la propriété de la donnée par domaine : chaque domaine métier possède et sert ses propres données ;
- la donnée traitée comme un produit : avec un owner, un contrat, des consommateurs ;
- une plateforme en self-service, qui outille les domaines sans rien posséder ;
- une gouvernance fédérée : des règles globales, décidées ensemble puis appliquées automatiquement et localement.
Voyons maintenant ces principes en mouvement. Les concepts et outils entrent en scène progressivement mais vous pouvez en retrouver la synthèse complète en annexe.
Ouverture · Le film
Un data product, de bout en bout
Le data mesh prend tout son sens « en mouvement ». Avant de présenter qui fait quoi et avec quoi, regardons le film : un data product, de sa naissance à son retrait, et à chaque étape, quel rôle passe la main à quel autre.
Une scène ordinaire, pour commencer : l’équipe marketing veut cibler les clients actifs pour ses relances. Mais quelle donnée utiliser ? Qui garantit sa fraîcheur ? L’email est-il masqué ? À qui demander l’accès ? C’est exactement ce que le data mesh cherche à rendre simple, traçable et sûr ; cette scène nous servira de fil rouge tout au long de l’article, sous le nom clients-actifs-fr.
Sept acteurs s’y répondent : le product owner (qui porte le produit), le data engineer (qui le construit), la plateforme self-service (qui outille), la gouvernance et le consommateur. Côté gouvernance, on croise le réviseur (qui valide le contrat, indépendant de l’auteur) et le DPO, le délégué à la protection des données, garant de la conformité RGPD, qui arbitre notamment l’accès aux données personnelles.
Nous allons suivre ensemble six scénarios : la naissance d’un data product, sa construction, sa découverte, son utilisation, son évolution et son retrait. Le diagramme ci-dessous donne la vue d’ensemble ; chaque scénario se déplie d’un clic.
▸ Cliquez un scénario pour le déplier ou le replier ; le premier est ouvert pour commencer.
S1Naissanceétapes 1–4déplier
- Déclarer le produit (nom, domaine, sources, classification)▶
- Esquisser le data contract (ODCS)▶
- Demander la revue▶
- Validation technique + gouvernance (réviseur ≠ auteur)gate◀
S2Constructionétapes 5–11déplier
- Demander le provisionnement▶
- Environnement de développement déployé◀
- Construire (ingestion → transfo → stockage)▶
- Ajouter les tests de qualité▶
- Demander le merge en prod▶
- GATE CI + gouvernance, signe (audit log)gate◀
- Publier (output port + catalogue)▶
S3Découverte & accèsétapes 12–15déplier
- Découvrir au catalogue◀
- Demander l’accès (finalité déclarée)◀
- PBAC : accès accordé à une finalitégate▶
- Coût attribué (chargeback / showback)▶
S4Consommerétapes 16–18déplier
- Consommer (SQL / API / flux / viz)◀
- PII / DPO : masque levé selon finalitégate▶
- Usage : BI / ML / agent IA↺ boucle
S5Incident & exploitationétapes 19–21déplier
- Alerte SLO / qualité↺ boucle
- Remonter la cause◀
- Chiffrer par étape↺ boucle
S6Évoluer / fin de vieétapes 22–25déplier
- Nouvelle version (versioning)▶
- Impact : qui consomme v1 ?◀
- Re-signer (revalider le contrat)gate◀
- Bannière déprécation → Retiré▶
Le film · Six fiches pratiques
Les six moments du cycle de vie
Six zooms sur le film, six situations concrètes. À chaque fiche, on nomme au passage le rôle qui entre en scène et le bloc d’outils qu’il actionne, et l’on détaille le flux dans un diagramme de séquence dédié.
1 · La naissance : du use case au data product
Quel besoin métier justifie ce produit ?Un data product ne commence pas par du code, ni même par de la donnée : il commence par un use case : un besoin métier, un impact attendu.
On crée un data product parce qu’on veut obtenir quelque chose : une décision mieux informée, un tableau de bord qui manque, un modèle à nourrir. Cet attendu est le vrai point de départ. La première étape n’est donc pas technique : c’est de comprendre l’impact recherché, puis de faire le tri entre ce dont on a besoin et ce dont on dispose déjà.
Et c’est plus subtil qu’il n’y paraît, car l’information n’est pas toujours visible dans la donnée brute. Une donnée qui « ne parle pas » au premier regard peut, une fois transformée, croisée, enrichie, répondre à un cas métier qu’on n’imaginait même pas adressable. C’est précisément pour cela que définir un data product gagne à être un exercice collectif et créatif, réunissant des profils variés (métier, data, plateforme) : personne, seul, n’a à la fois la connaissance fine du besoin et celle des données réellement disponibles.
Pour structurer l’atelier, un outil simple et lisible par le métier : le Data Product Canvas (popularisé par le cabinet INNOQ)[2]. C’est une feuille en huit cases qu’on remplit ensemble, et qui force à répondre aux bonnes questions avant d’écrire la moindre ligne de code. Chaque case porte sa question guide : on les lit directement sur le schéma ci-dessous, accolées au canvas rempli pour notre fil rouge : clients-actifs-fr.
1Consommateur & use case
Qui utilise le produit, et pour quoi ?
L’équipe campagnes marketing veut cibler les clients actifs pour ses relances. Impact attendu : un meilleur taux de conversion des campagnes.2Domaine
À quel domaine métier ce produit appartient-il ?
Marketing : le domaine qui possède la donnée et s’engage sur sa qualité.3Nom
Un nom clair et stable, par lequel on le retrouve au catalogue.
Clients actifs FR, identifiant stable :clients-actifs-fr.4Sources
D’où vient la donnée, y compris hors du mesh (legacy, SaaS…) ?
CRM (export quotidien) ; commandes e-commerce (CDC, quasi temps réel).5Langage ubiquitaire
Le vocabulaire métier partagé, pour que « client » veuille dire la même chose pour tout le monde.
« Client actif » = au moins une commande sur 12 mois glissants, définition partagée métier/data.6Contrat & output ports
Ce que le produit garantit : schéma, SLO (Service Level Objectives : objectifs mesurables que le producteur s’engage à tenir, comme la fraîcheur ou la complétude), sensibilité ; et comment il s’expose (table, API, flux…).
Fraîcheur ≤ 24 h, complétude ≥ 99 % ; contient des PII (email) → gate DPO, masquage par finalité ; exposé en table SQL, API REST et flux Kafka.7Classification
De quel type de produit s’agit-il : source-aligned (proche d’une source), aggregate (croise plusieurs sources) ou consumer-aligned (façonné pour un usage) ?
Aggregate : il croise CRM et commandes pour produire un concept métier réutilisable (« client actif »).8Architecture
L’esquisse technique : sources, transformations, matérialisation.
Ingestion CDC → couches Bronze / Silver / Gold → publication + policies.
Une fois le canvas rempli, le contrat de données se cristallise : il met noir sur blanc ce que le produit garantit. C’est lui qu’on déclare, avant d’écrire le code.
Pour aller plus loin — d’autres façons de cadrer un data product (Event Storming, DDD)
Le canvas n’est pas le seul point de départ. Quand le périmètre d’un domaine est encore flou, on peut commencer par un Event Storming (méthode d’Alberto Brandolini)[3] : un atelier où l’on étale sur une grande frise temporelle tous les événements métier, tout ce qui se passe dans le domaine, formulé au passé (« commande passée », « paiement reçu »…). On part des événements plutôt que des processus ou des données, parce qu’un événement est un fait objectif, qu’un expert métier peut énoncer sans avoir à se mettre d’accord sur une structure de données. La frise se lit de gauche à droite (chronologie), et l’on repère là où le vocabulaire bascule, un même mot qui change de sens ou deux mots pour la même chose : on tient une couture, un bounded context (un périmètre où chaque mot a un sens unique) [4], candidat naturel à devenir un data product.
Chaque unité se lit de haut en bas : l’acteur, le read model (l’info pour décider), la commande (l’intention, à l’impératif) et l’événement qu’elle provoque (au passé). La policy violette encode une réaction automatique (« quand Paiement reçu, alors Réserver le stock »). Au passage de la couture, le mot « commande » cède la place à « colis » : le langage bascule, on tient deux bounded contexts. Le point chaud sur « Paiement reçu » (« anti-fraude ? ») est une décision métier : au sens du Data Product Flow, chaque décision ouvre un output port candidat.
Reste à trancher ce que contient ce candidat. Deux critères, issus de la pratique plutôt que de la seule théorie DDD[5], permettent de le faire. Le premier : parmi les attributs que la frise fait apparaître, ne retenir que ceux qui mesurent la valeur métier du domaine, pas tout ce que le système source connaît en interne[3]. Le second, formalisé par Agile Lab sous le nom de Data Product Flow[6] : pour chaque décision métier repérée sur la frise, demander quelles données permettraient de mieux la prendre ou de l’automatiser ; chaque réponse devient un output port candidat, et leur regroupement, sous cohérence de cycle de vie et de propriété, dessine le data product.
Cette seconde méthode porte en elle sa propre limite. Ses auteurs la restreignent explicitement aux data products source-aligned[6] : nuance à garder en tête, l’Event Storming visait à l’origine la modélisation opérationnelle, et l’étendre à l’analytique est une adaptation admise, pas une équivalence automatique. La couture DDD, quelle que soit la méthode utilisée pour la repérer, donne donc des candidats, pas le périmètre final. Il n’y a pas de correspondance 1:1 entre sous-domaine, bounded context et data product ; cette absence se tranche par deux arbitrages.
La granularité, d’abord : un bounded context riche donne souvent plusieurs produits, à une maille plus fine que le contexte entier ; inversement, plusieurs petits contextes generic (au sens DDD : core / supporting / generic) peuvent fusionner en un seul produit commodité.
La demande aval, ensuite : le découpage issu de l’Event Storming est source-aligned par construction, il épouse le modèle opérationnel. Or Dehghani distingue trois alignements de data products[7] : source-aligned (au plus près du système producteur), aggregate (recomposé à partir de plusieurs produits) et consumer-aligned (taillé pour un usage précis). Une bonne part de la valeur se joue dans les deux derniers ; Dehghani elle-même met en garde contre les agrégats trop ambitieux, qui recréent une centralisation. Si l’on fige les frontières sans écouter les consommateurs, on reproduit côté data les silos opérationnels ; c’est le rôle de la case « Consommateur & use case » du canvas, qu’on remplit en premier.
Toutes ces méthodes convergent malgré tout vers une même idée : le contract-first. Définir le contrat avant le code, pour « réparer la qualité à la source » plutôt que par des tests réactifs (c’est le shift-left).
Flux détaillé et rôles
Cette déclaration n’est pas encore un produit : elle passe une première gate de validation, à deux faces. Côté technique, la plateforme vérifie que la déclaration est cohérente et le contrat bien formé (les sources existent-elles ? le schéma tient-il debout ?). Côté gouvernance, un réviseur, différent de l’auteur par indépendance, contrôle la classification, les données personnelles et la finalité. Provenance honnête : la règle « réviseur ≠ auteur » est un contrôle d’ingénierie (séparation des tâches, comme une revue de PR) que je propose, pas une doctrine mesh : Dehghani pose la gouvernance fédérée, pas ce séparateur précis. Voici ce premier flux en détail :
- Cadrer le use case (8 blocs : consommateur, sources, classification…)
- Frontière + classification (aggregate) du produit
- Déclarer le data contract (schéma, SLO, qualité, sensibilité, finalité)
- Référencer le brouillon au catalogue (discovery port + garanties)
- Demander la revue
- Revue indépendante : réviseur ≠ auteurgate↺ boucle
- Gate 1 : technique (cohérence) + gouvernance (PII, finalité) validéesgate
- Brouillon prêt à construire↺ boucle
Une nuance utile : on dit ici qu’on référence le brouillon du data product dans le bloc Catalogue & découverte, mais ce n’est pas forcément là que le data contract est validé : cela dépend vraiment de l’outillage. L’important n’est pas l’emplacement exact : c’est d’avoir un espace de déclaration où la demande de data product est posée, peut être validée, puis sert à provisionner l’environnement technique qui permettra de matérialiser le produit (fiche 2).
Dans le data contract
Le contrat se formalise dans un fichier. Plusieurs standards existent ; le plus répandu est ODCS (Open Data Contract Standard), porté par Bitol, une initiative Linux Foundation, et né d’un modèle interne de PayPal[8]. Il s’écrit en YAML, versionnable avec le code, donc relisible, diffable et enforçable en CI. À la naissance, on pose le squelette d’identité du produit :
# Open Data Contract Standard (ODCS / Bitol)
# extrait annoté à but pédagogique ; ne pas valider tel quel
apiVersion: v3.1.0
kind: DataContract
id: clients-actifs-fr # identifiant stable, unique
name: Clients actifs FR
version: 0.1.0 # SemVer ; 0.x = encore en brouillon
status: draft # proposed → draft → active → deprecated → retired
domain: marketing # le domaine propriétaire
description:
purpose: Clients actifs, pour le ciblage des campagnes
usage: Lecture analytique ; pas de réécriture
schema:
- name: clients_actifs
properties:
- name: client_id
logicalType: string
required: true
unique: true # → testable en qualité
- name: email
logicalType: string
classification: PII # marque la sensibilité (cf. fiche 4)
- name: derniere_commande
logicalType: datePourquoi ces champs comptent. L’id est l’ancre stable du produit (il ne change jamais, même quand le nom évolue). Le status pilote le cycle de vie (proposed / draft / active / deprecated / retired) ; la version en SemVer encode plus tard le breaking vs non-breaking (fiche 6). Le logicalType décrit le type métier indépendamment du moteur (le physicalType concret (VARCHAR, STRING…), se précise selon le server de stockage). Cas particulier : pour un produit streaming, on a un contrat technique supplémentaire comme le Schema Registry (Avro/Protobuf)[9], on en parlera plus en détail à la fiche 5.
Comment le contrat est organisé. ODCS distingue d’un côté les sections natives, que le standard définit et qu’un linter peut vérifier : identité (id, name, version, status, domain), schéma, SLO (slaProperties), output ports (servers), rôles & approbations (roles) ; et de l’autre le point d’extension customProperties, où chaque organisation branche ses règles maison (masquage par finalité, compatibilité de contrat, rétention, base légale, contexte GxP…) sans casser la conformité au standard. C’est ce qui rend le contrat à la fois valide (il passe un linter ODCS) et spécifique (il porte la policy de votre org). Les fiches suivantes ajoutent leurs blocs au contrat ; à chaque fois qu’un champ n’est pas natif, il vivra sous customProperties.
Pour aller plus loin
Le data product et ses cinq ports (la grammaire commune)
Une image qui sert dans toute la suite : un data product est un architectural quantum[1][10], la plus petite unité déployable de façon autonome, qui réunit le code, les données et métadonnées, l’infrastructure et les règles. Il s’appuie sur les blocs de la plateforme et s’expose par des output ports. On lui reconnaît cinq ports[11] : un input port en entrée, puis quatre ports d’exposition : output (les données servies), discovery (sa carte d’identité et ses garanties), observability (ses signaux, dont la qualité) et control (les accès et l’enforcement).
Input port
l’entrée
Data product = architectural quantum
au cœur, les transformations (le code), puis quatre ports d’exposition
Cette grammaire a désormais son standard. Bitol (l’initiative Linux Foundation qui porte le standard de contrat ODCS, présenté plus haut à la section « Dans le data contract ») publie ODPS (Open Data Product Standard), dont la v1.0.0 est sortie en octobre 2025[12]. Là où ODCS décrit un contrat, ODPS décrit le produit lui-même : son identité, son cycle de vie, et ses ports : chaque output port référence le contrat ODCS qui le garantit, et les ports discovery, observability et control se déclarent via managementPorts. L’image du produit à cinq ports n’est donc plus une métaphore : c’est un artefact déclarable et versionnable, l’artefact emblématique du plan data product experience (les trois plans de Dehghani, détaillés en annexe).
# ODPS (Open Data Product Standard / Bitol) : le produit, pas le contrat
# extrait annoté à but pédagogique ; ne pas valider tel quel
apiVersion: v1.0.0
kind: DataProduct
id: 3f2504e0-4f89-11d3-9a0c-0305e82c3301 # UUID stable du produit
name: Clients actifs FR
status: draft # proposed → draft → active → deprecated → retired
domain: marketing
inputPorts:
- name: crm-contacts
contractId: crm-contacts-fr # le contrat ODCS d'une source amont
version: 1.2.0
outputPorts:
- name: clients-actifs-sql
type: tables
contractId: clients-actifs-fr # ← le contrat ODCS suivi dans cet article
version: 0.1.0 # la version du contrat référencéHomonyme à éviter : l’Open Data Product Specification (opendataproducts.org)[13] partage l’acronyme ODPS, mais c’est une lignée différente : ici, on parle du standard Bitol.
Enfin, les six dimensions de qualité DAMA-UK donnent la grille pour « mesurer la qualité » d’un jeu de données et nourrissent les SLO ; on les retrouve à l’œuvre en fiche 5, où elles alimentent le tableau de bord qualité du produit.
D’où viennent ces rôles ?
Le domain ownership, soit la propriété de la donnée par domaine, est le premier principe du data mesh, formulé par Zhamak Dehghani, l’ingénieure (alors chez Thoughtworks) qui a inventé le concept en 2019[7]. L’idée : le domaine qui produit la donnée la possède et la sert, au lieu de la déverser dans un lac de données central géré par une équipe tierce qui n’en connaît pas le sens.
Le découpage des rôles s’appuie sur Team Topologies, un livre de Matthew Skelton & Manuel Pais sur l’organisation des équipes logicielles[14]. Sa thèse : quatre grands types d’équipes suffisent : stream-aligned (alignée sur un flux de valeur), platform (qui outille les autres), enabling (qui fait monter les autres en compétence) et complicated-subsystem (une spécialité pointue). On les retrouve presque trait pour trait dans le mesh : équipe domaine, équipe plateforme, accompagnement, spécialités (ML, temps réel). Dehghani cite Team Topologies, mais ce mapping détaillé est surtout l’œuvre de la communauté[15].
Le vrai levier de Team Topologies, ici, est la charge cognitive(canon Skelton & Pais, repris par Dehghani)[14] : la décentralisation transfère de la charge cognitive au domaine : le propriétaire doit désormais penser qualité, contrat, support, pas seulement son métier. Sans l’alléger (plateforme self-serve + enabling team), l’ownership devient une charge nue : c’est le mécanisme du premier point de rupture détaillé en synthèse (« L’ownership sans incitation »).
La gouvernance fédérée (4ᵉ principe) est aussi « computationnelle »[1] : les règles sont décidées globalement, exécutées localement, et appliquées automatiquement par la plateforme (policy-as-code). « Fédéré » n’est pas « décentralisé » : on garde des standards communs et quelques dépendances centrales.
Enfin, le mesh ne supprime pas la gouvernance des données. Le corpus de référence du métier, le DAMA-DMBOK (le « corps de connaissances » publié par l’association DAMA, qui structure la gestion de données en domaines : qualité, sécurité, métadonnées, données de référence…)[16], reste valable. Le mesh n’en change pas le quoi ; il en change l’operating model : la responsabilité passe d’une équipe centrale unique à une intendance (stewardship) fédérée, embarquée dans les domaines.
2 · La construction technique
Comment transformer la promesse du contrat en produit exécutable ?La déclaration déclenche le provisionnement d’un environnement adapté. On y construit, et on ne touche à la production qu’après deux gates ; chaque approbation est tracée : c’est une signature.
L’idée-force : le domaine construit, mais la plateforme standardise le chemin de construction. Le data engineer (ou un agent data engineer, rôle encore émergent, à mesure que l’outillage s’automatise) travaille dans un environnement fourni par la plateforme, pas sur une infra qu’il bricole. La plateforme adapte l’environnement à ce qui a été déclaré : temps réel, opérationnel, classification sensible, technologie choisie.
Un mot de vocabulaire essentiel, car il décrit une étape centrale du cycle de vie : la promotion d’environnement. On ne développe jamais directement en production. Le travail traverse des environnements successifs : dev (le bac à sable du data engineer), preprod / recette (où l’on teste sur des données réalistes), puis production (ce que consomment les utilisateurs). « Promouvoir », c’est faire passer le produit d’un étage au suivant, et chaque passage est gardé par une gate.
La gate technique est automatique : elle rejoue les tests et vérifie que le contrat est respecté ; un changement cassant fait échouer le passage. La gate de gouvernance est humaine : un réviseur approuve, et son approbation est tracée dans un journal d’audit : c’est une signature qui engage.
Flux détaillé et rôles
- Demander l’environnement (selon la déclaration)
- Env provisionné : dev → preprod, templates, accès
- Construire : ingestion, transfo (médallion), tests data↺ boucle
- Ouvrir la PR pour promouvoir vers la prod
- Rejouer les tests + enforcer le contrat (échec si cassant)gate↺ boucle
- Build vert → demander la revue
- Approuver & signer : réviseur ≠ auteur (audit log)gate
- Merge sur main → déploiement en production
Le développement matérialise le data contract en code : c’est ce code qui produit tous les artefacts du data product. La preproduction sert à les tester avant la promotion : elle garde la flexibilité du développement, tout en permettant à des acteurs extérieurs de vérifier que le produit répond à leurs besoins. Au besoin, on itère (retour à la fiche 1) jusqu’à converger.
La mise en production, elle, devrait être portée par la plateforme, a minima via des enablers (code de CI/CD, modules Terraform…). Il faut aussi déclarer le job à l’outil d’orchestration, qui exécutera le produit conformément au contrat, de façon déclarative (en parsant le contrat) ou plus explicite. Les détails varient d’une organisation à l’autre ; l’essentiel est de standardiser et d’automatiser au maximum pour éviter les erreurs humaines.
Pour aller plus loin — le dev en couches médallion
Amener la donnée (ingestion / iPaaS). Trois familles, pas un seul outil : l’iPaaS (intégration applicative low-code : MuleSoft, Boomi…), l’ELT (charger brut puis transformer : Fivetran, Airbyte, dlt) et le CDC (capter les changements quasi temps réel : Debezium). À la frontière du mesh, un Anti-Corruption Layer traduit le modèle de la source dans celui du domaine. L’implémentation concrète de cette intégration hors-mesh est souvent un point de douleur, car elle doit s’adapter aux sources opérationnelles et aux contraintes de sécurité. En général, on choisit de dupliquer les données brutes dans le mesh, pour garder le contrôle sur l’audit et pouvoir rejouer les données en cas de problème.
L’architecture interne peut être un DAG en couches médallion : Bronze (brut), Silver (nettoyé, conformé), Gold (agrégats métier). Mais attention : la maturité n’est pas que technique. La donnée devient un data product source-aligned quand elle gagne le triptyque owner + contrat + output port gouverné ; c’est la transition Gold → produit.
Pour aller plus loin — la promotion dev → prod
Promotion dev → preprod → prod. Concrètement, en général, promouvoir = merger sur main (git est le mécanisme, il n’y a pas de bouton « promote »). Dans ce cas la gate est une revue de PR par un autre rôle.
Un contrat sans CI est décoratif.
Côté outillage : la gate technique applique le contrat au build (datacontract-cli, Schema Registry) : le build échoue sur un changement cassant ; la gate gouvernance est un merge approuvé par un réviseur différent de l’auteur (le contrôle d’ingénierie vu en fiche 1) et tracé dans l’audit log.
Dans le data contract
C’est ici, à la construction, que le fichier de contrat (ODCS) vit dans le dépôt, à côté du code de transformation. Au merge, la CI/CD le met en forme pour la publication dans la plateforme (catalogue, discovery port) et s’en sert pour provisionner automatiquement les autres blocs, par exemple déclarer le job dans l’outil d’orchestration, créer les tables/SLO, poser les policies de la colonne marquée PII. Le contrat devient ainsi la source de vérité exécutable, pas une doc qui dérive.
On complète donc le squelette de la fiche 1 avec le contractuel exécutable : les transformations documentées, la qualité, les SLO, et les serveurs de sortie (les output ports) :
# … (suite du contrat clients-actifs-fr)
# extrait annoté à but pédagogique ; ne pas valider tel quel
schema: # on enrichit le schéma de la fiche 1
- name: clients_actifs
properties:
- name: nb_commandes_30j # colonne dérivée (agrégat 30 jours)
logicalType: integer
transformDescription: Nombre de commandes sur 30 jours glissants
transformLogic: >- # natif ODCS : documente comment la colonne
count(*) FROM commandes # est dérivée de ses sources (lineage
WHERE client_id = c.id # au niveau colonne)
AND date >= CURRENT_DATE - INTERVAL '30' DAY
- name: segment_churn # colonne dérivée (règle métier)
logicalType: string
transformDescription: Segment de risque d’attrition
transformLogic: "CASE WHEN nb_commandes_30j = 0 THEN 'à_risquer' WHEN nb_commandes_30j <= 2 THEN 'fragile' ELSE 'fidèle' END"
quality: # natif ODCS : qualité au niveau de l’objet
- name: client_id_unique
type: library # text | library | sql | custom (natif ODCS)
dimension: uniqueness # natif ODCS (accuracy | completeness |
# conformity | consistency | coverage |
# timeliness | uniqueness)
metric: duplicateValues # natif ODCS (nullValues | missingValues |
# invalidValues | duplicateValues | rowCount)
rule: must_be_zero # seuil : implémenté par Soda / dbt tests
- name: email_present
type: sql # échappatoire native : requête libre
dimension: completeness
query: SELECT count(*) FROM clients_actifs WHERE email IS NULL
# doit valoir 0 (le moteur l’interprète)
slaProperties:
- property: freshness # SLO de fraîcheur
value: 24
unit: h
element: clients_actifs.derniere_commande
- property: completeness # complétude attendue
value: 99
unit: percent
servers: # où le produit est matérialisé
- server: prod
type: snowflake
database: MARKETING
schema: PUBLICUn produit, un (ou plusieurs) lieu(x) de service. Le bloc servers dit où ce data product est matérialisé. Mais rien n’oblige tous les data products à vivre au même endroit : tel domaine publie dans Snowflake, tel autre dans un bucket S3, tel autre dans un broker Kafka, selon ce qui sert le mieux ses consommateurs. C’est précisément pour ça qu’on catalogue les données disponibles : le catalogue est l’annuaire qui rend chaque produit adressable, où qu’il soit servi. Le contrat déclare ce qu’est le produit et où il est servi ; le catalogue agrège ces déclarations pour qu’on puisse chercher, comparer et demander l’accès (on y revient à la fiche 3).
La gate CI compare deux choses. D’un côté le contrat écrit dans le code ; de l’autre ce qui est déclaré / publié dans le bloc Catalogue & découverte. Si le YAML du dépôt diverge de la version au catalogue (un champ ajouté sans bump de version, une classification retirée), le build échoue : c’est ce qui empêche le contrat de devenir « décoratif ».
Documenter les transformations. Les colonnes dérivées portent leur transformDescription (ce qu’elles calculent, en clair) et leur transformLogic (le SQL ou la formule) : c’est natif ODCS, au niveau de la colonne. L’intérêt n’est pas cosmétique : c’est ce qui alimente le lineage au niveau colonne et qui dit au consommateur comment une métrique est obtenue, pas seulement ce qu’elle contient. « nb_commandes_30j » n’est pas une colonne brute, c’est un agrégat, et le contrat le dit. On retrouvera ces deux champs en fiche 4, comme repère pour ne pas les confondre avec un masquage.
Les règles de qualité illustrent les deux régimes natifs d’ODCS : type: library pour les règles prédéfinies, où l’on choisit une métrique standard (duplicateValues, nullValues, missingValues, rowCount…) qui se mappe directement sur Soda ou dbt tests ; et type: sql, l’échappatoire pour les cas particuliers qu’aucune métrique standard ne couvre (ici, un COUNT sur les emails absents). Chaque règle porte sa dimension qualité (uniqueness, completeness…), et la qualité se rattache à l’objet de schéma, pas au contrat top-level : c’est sa place en ODCS 3.1.0. Le element d’un SLO, lui, rattache la garantie à une colonne précise (ici, la fraîcheur se mesure sur la date de dernière commande).
3 · Découverte, accès, et qui paie quoi
Comment trouver le produit, et obtenir le droit de l’utiliser ?Le produit est publié ; encore faut-il le trouver et y accéder. Le catalogue rend les produits adressables ; les output ports les servent ; l’accès se demande (une gate) ; et quelqu’un paie : c’est là que se joue l’incitation.
On découvre un produit au catalogue (son discovery port : schéma, sémantique, owner, garanties du contrat). On le consomme via des output ports polyglottes : un même produit peut s’exposer en table SQL, en API, en flux Kafka, en fichier. L’accès se demande en déclarant une finalité : c’est le PBAC (purpose-based access control) : on accorde l’accès à un usage, pas à une personne. C’est en phase avec le RGPD (limitation des finalités, minimisation).
La donnée qu’on ne voit pas : dark & shadow data
« Découvrir » a un revers : on ne peut ni posséder, ni gouverner ce qu’on ne voit pas. Deux notions souvent confondues, à garder distinctes :
Dark data
Donnée collectée et stockée mais jamais exploitée, connue, dans le patrimoine gouverné. Le problème est la non-valeur. Origine : Gartner, monde de la BI[17].
Shadow data
Copies hors visibilité et hors gouvernance : snapshots, backups, exports SaaS/IA. Inconnue, non gouvernée : le problème est l’invisibilité (sécurité, conformité). Origine : sécurité (DSPM)[18].
Même mécanique de traitement, valence opposée. Mesh × dark = opportunité : data-as-a-product, catalogue et lineage activent la dark data ; un mesh bien tenu la réduit. Mesh × shadow = risque : en théorie la gouvernance fédérée l’élimine ; en pratique, la décentralisation et la prolifération de produits peuvent en fabriquer si la maturité ne suit pas. La charnière est l’anti-pattern du « ghost product » : un produit abandonné, à la fois dark (inutilisé) et qui dérive hors gouvernance.
Le volet RGPD est le point qui parle en France : une donnée personnelle en shadow n’est pas inventoriée, donc le droit à l’effacement (article 17)[19] ne peut pas l’atteindre, et le registre des traitements (article 30)[19] est défait. Catalogue et lineage sont l’antidote.
Flux détaillé et rôles
Voici le flux de bout en bout :
- Rechercher (finalité en tête)
- Fiche produit : schéma, sémantique, garanties (contrat), owner
- Demander l’accès (finalité déclarée)
- Évaluer la finalité (PBAC)
- Vote des approbateurs (multi-niveaux)gate↺ boucle
- Verdictgate
- si approuvéAccès accordé : masque PII levé selon finalité (audité)
- si refusRefus motivé (audit log)
- Consommer via l’output port (SQL / API / flux)
- Coût attribué (chargeback / showback)
Dans le data contract
Côté contrat, la découverte et l’accès se jouent dans deux sections : les servers (vus en fiche 2) qui décrivent où et comment le produit s’expose, un par output port, et la section roles, qui encode qui peut demander quoi, pour quelle finalité :
# … (suite du contrat clients-actifs-fr)
# extrait annoté à but pédagogique ; ne pas valider tel quel
servers: # un par output port
- server: prod-sql
type: snowflake # port table / SQL
database: MARKETING
schema: PUBLIC
- server: prod-api
type: api # port API (enum ODCS)
location: https://api.intra/dp/clients-actifs/v1
- server: prod-stream
type: kafka # port flux
topic: marketing.clients_actifs.v1
roles:
- role: analyste-marketing
access: read
firstLevelApprovers: data-steward # natif ODCS : 1er niveau
customProperties:
- property: purpose # finalité (PBAC), non native :
value: Ciblage des campagnes # portée en customProperties du rôle
- role: data-scientist
access: read
firstLevelApprovers: data-steward
secondLevelApprovers: dpo # natif ODCS : PII → 2e niveau
customProperties:
- property: purpose
value: Entraînement de modèles
- role: tableau-bord-ventes_dp_svc # compte de service d'un produit
access: read # aval, pas une personne.
firstLevelApprovers: data-steward # _dp_svc : convention maison.
secondLevelApprovers: dpo # PII lue par une app → le DPO
# évalue son AUDIENCE
customProperties:
- property: purpose
value: Pilotage commercial (managers ventes)Pourquoi c’est structurant. Multiplier les servers permet à un même data product d’être polyglotte (table, API, flux) sans le dupliquer. Dans roles, le purpose est le cœur du PBAC présenté plus haut. Champ non natif, il vit sous les customProperties du rôle, comme le montre le YAML ci-dessus. L’approbation multi-niveaux, elle, est native dans ODCS : firstLevelApprovers / secondLevelApprovers[8]. Cas particulier : dès qu’une colonne est classée PII, on renseigne le dpo en secondLevelApprovers, ce qui déclenche la gate multi-approbateurs de la fiche 4. Chaque demande sur ces rôles suit le flux vu plus haut : la décision, accord ou refus, est tracée dans l’audit log, que l’arbitrage soit automatique (PBAC) ou remonte à un approbateur humain. Cet audit log sert à répondre après coup à trois questions : qui a eu accès à quoi, quand, et sur quelle base (finalité déclarée, approbateur). C’est ce qui permet d’instruire un incident, de justifier un retrait d’accès, ou de prouver la conformité devant un régulateur.
L’accès n’est pas réservé aux humains. Le troisième rôle de l’exemple est une identité technique : un data product aval, un tableau de bord publié (Power BI), un service ou un agent consomme via son propre compte de service, dédié au produit, pas à une personne (le suffixe _dp_svc est une convention de nommage maison, le standard ne prescrit rien). Trois conséquences pratiques. D’abord la vigilance : accorder l’accès à une application, c’est l’accorder à tous ses utilisateurs : la finalité déclarée doit couvrir l’audience de l’app, pas l’intention de son développeur ; pour des données réglementées, c’est ce que l’arbitrage DPO évalue. Ensuite le chaînage : si l’app re-expose la donnée, elle devient elle-même un produit, avec son propre contrat et ses propres gates : les gates se chaînent, elles ne se traversent pas. Enfin la signature : celui qui construit le produit aval s’abonne au nom du produit qu’il construit : la personne porte la demande et signe à la gate, mais l’identité abonnée (celle qui consomme, apparaît au lineage et se révoque) est le produit. Le champ contractId d’ODPS[12] (vu au dépliant de la fiche 1) l’outille des deux côtés : sous inputPorts, le produit aval déclare les contrats qu’il consomme.
Qui paie quoi : chargeback et patterns d’usage
Le titre de la fiche promet « qui paie quoi » : c’est le moment de l’honorer. Sans chargeback, le producteur paie pour tout le monde, et c’est le problème de bien public qui tue data-as-a-product par défaut. La première chose que rend le mesh, c’est la visibilité : l’observability port expose le volume de requêtes et qui consomme quoi, sous forme d’une vue finops par produit. On peut y alerter sur des patterns de consommation inattendus, pas seulement sur la qualité ou la latence.
Anticiper puis monitorer les patterns d’usage est essentiel pour éviter les surprises sur les coûts. Un même produit sert rarement un seul rythme : tel consommateur tire de petites requêtes toutes les 5 minutes, tel autre fait de gros pulls batch ponctuels. Ce n’est pas le même coût, ni la même silhouette de serveur. Le premier cas appelle un petit serveur tournant en permanence (latence stable, coût fixe bas) ; le second un gros serveur scale-to-zero avec un timeout bien configuré (on paie le pic, pas l’attente). Reconnaître les patterns « streaming » et « batch » permet de redistribuer l’usage vers le serveur optimisé correspondant, plutôt que de tout servir sur une seule silhouette surdimensionnée.
Le chargeback lui-même, en revanche, n’est pas simple. Son implémentation varie fortement selon l’organisation. Et attribuer l’uptime d’un serveur à un consommateur précis, alors que c’est ce qu’on paie réellement quand on sert un modèle, n’est pas toujours faisable. On recourt donc à des proxys : le volume de données transités, le nombre de requêtes, qui se mesurent par consommateur, puis on redistribue les coûts réels au prorata de ces proxys. S’il existe un chargeback spécifique au produit, il est bon de le documenter dans le data contract : la transparence des coûts permet aux consommateurs d’anticiper leur budget, et au producteur de ne pas rester à absorber la facture. Le cadre général (FinOps Foundation, FOCUS) est détaillé au dépliant finops de la fiche 5.
Pour aller plus loin
L’interopérabilité cross-domaine : reference & master data
La décentralisation complique la cohérence entre domaines (« plusieurs versions du même client »). Les reference data (nomenclatures, codes) et les master data (entités cœur : client, produit) rendent les produits joignables. Le pattern établi : un domaine MDM dédié publie ces données comme des data products (owner, contrat, API).
Mais c’est un consensus communautaire, pas le canon : Dehghani traite la cohérence par identifiants globaux et liens, pas par un « golden record » central. Et la résolution d’identité (match/merge/survivorship) reste, elle, centralisante : le pattern MDM-comme-domaine est donc une tension honnête avec la décentralisation, un golden record qu’on productise plutôt qu’on ne le distribue.
Adressage global. Le catalogue, au sens mesh (le plan mesh experience des trois plans de Dehghani, détaillés en annexe), donne à chaque produit de chaque domaine une adresse (un identifiant, une sémantique, des garanties) découvrable depuis n’importe quel autre domaine. C’est la condition pour qu’un produit du domaine ventes puisse joindre un produit du domaine marketing sans médiation centrale.
Polysèmes et identifiants partagés. Dehghani introduit le polyseme (canon) : un même concept (« client », « produit ») désigne des réalités différentes selon le domaine. Le « client » du marketing (un prospect) n’est pas le « client » du support (un ticket ouvert). Le join cross-domaine suppose donc une résolution d’identité : relier ces versions par un identifiant partagé (une global key) ou par des liens déclarés dans le contrat, plutôt qu’en imposant un modèle unique à tous les domaines.
Partage par table vs fédération de requêtes. Une fois l’identité résolue, deux façons de joindre sans tout rapatrier : partager des tables dans des formats ouverts et interopérables (Apache Iceberg, Delta Lake), où le domaine publie un snapshot ou un stream qu’un autre domaine lit en place ; ou fédérer la requête, c’est-à-dire adresser les produits en place, sans déplacer la donnée (Trino, des vues cross-sources). Le premier déplace de la donnée mais sert des lectures répétées à bas coût ; le second ne déplace rien mais reporte le coût sur chaque lecture.
Et la couche sémantique, au-delà de l’identité. Les reference et master data règlent le qui (quelle entité on joint), pas le quoi (ce que « revenue » ou « client actif » veut dire, avec quelle formule). D’où la couche sémantique :« define once, use everywhere », unifier les métriques et le glossaire pour qu’un même chiffre ait la même définition partout, côté BI comme côté agents IA. C’est la brique la moins mature du mesh : l’initiative OSI (Open Semantic Interchange, lancée fin 2025 par Snowflake, dbt Labs, Salesforce, BlackRock et al.)[21] normalise un modèle sémantique vendor-neutral, mais elle est encore en v0.1.x. À présenter comme une tendance, pas un standard établi, et qui recoupe les champs sémantiques d’ODCS de façon encore floue. C’est aussi le même ancrage anti-hallucination que la fiche 4 prête à l’IA : sans cette couche, un agent rate la différence entre « revenue » et « projected_revenue ».
4 · Consommer : BI, IA, données sensibles
comment utiliser le produit sans perdre ses garanties ?Au bout du flux, le produit se consomme : un tableau de bord, un modèle, un agent IA. La confiance vient du contrat + lineage + QA ; pour les données sensibles, la protection se met à plusieurs niveaux et se prouve.
Rappelons-le, car c’est tout l’esprit du data as a product : un « produit », ce n’est pas seulement une table. Un data product, c’est aussi bien un tableau de bord BI, un modèle de machine learning, qu’aujourd’hui une application agentique (un agent IA branché sur la donnée gouvernée). Tous se consomment, et tous méritent un contrat.
Un même mesh sert donc aussi des jeux de données, une couche sémantique, des API de données, et de plus en plus des produits de connaissance pour le RAG. Pour une IA fiable, le contrat et la sémantique sont un ancrage anti-hallucination, condition nécessaire mais non suffisante : savoir que « revenue » n’est pas « projected_revenue » est exactement le genre de distinction qu’un agent rate sans contrat.
Flux détaillé
Le moment le plus sensible est l’accès aux données personnelles. Voici la gate PII / DPO en détail, du dépôt de la demande à la levée du masque pour la seule finalité accordée :
- Demander l’accès PII (finalité + justification)
- Notification aux approbateurs requis
- Chaque approbateur vote (approve / reject), multi-niveauxgate↺ boucle
- Verdict agrégé
- si tous approuventAttribuer la finalité au consommateur
- Masque PII levé pour cette finalité seulement, acte audité
- si un refusRefus motivé, consigné dans l’audit log
- Consommer via l’output port (PII visibles selon la finalité)
Pour aller plus loin — masking, anonymisation : à quel niveau, quelle robustesse
Le mécanisme, sans tromperie. La donnée brute arrive en Bronze, non masquée au stockage. Le dynamic data masking est un contrôle d’accès appliqué à la lecture, sur la colonne, dans le moteur, une policy-as-code pilotée par tag/classification (Snowflake masking policy, BigQuery policy tags, Databricks ABAC). Par défaut la policy renvoie la valeur masquée ; la gate DPO accorde au consommateur un attribut de finalité, et la policy révèle le clair pour cette finalité seulement, acte audité.
Cas très réglementés (GxP / pharma). Dans un cadre GxP, la conformité se prouve par des preuves documentées : principes ALCOA+, audit trail (21 CFR Part 11), validation risk-based (GAMP 5). Le pont rhétorique avec le mesh est réel (audit trail ↔ log immuable, lineage, policy-as-code), mais aucun régulateur n’endosse « data mesh », et la décentralisation ajoute de la charge de validation.
Dans le data contract
La consommation des données sensibles s’appuie sur deux endroits du contrat : la classification au niveau de la colonne (vue en fiche 1), et la déclaration déclarative du masquage : la policy effective est appliquée par le moteur, mais le contrat dit quoi protéger et pour qui le lever :
# … (extrait du contrat clients-actifs-fr)
# extrait annoté à but pédagogique ; ne pas valider tel quel
schema:
- name: clients_actifs
properties:
- name: email
logicalType: string
classification: PII # colonne sensible (natif ODCS) ; la policy
# de masquage est déclarée plus bas, sous
# customProperties : transform et unlockFor
# sont deux extensions, non natives ODCS
customProperties:
- property: retention # durée de conservation (ISO 8601)
value: P3Y
- property: legalBasis # base légale du traitement
value: consent
- property: transform # masquage par défaut à la lecture (extension)
value:
column: email # le clair n'est rendu que pour une finalité
type: mask # mask | hash | tokenize | nullify
default: redacted # ce que voit un rôle non autorisé
- property: unlockFor # finalités qui lèvent le masque (extension)
value:
- column: email
purpose: Support client
approvers: [dpo] # vocabulaire de notre extension ;
# le natif ODCS, c'est first/secondLevelApproversPourquoi ces champs comptent. La classification marque la sensibilité ; la policy de masquage (transform + unlockFor) la rend pilotée par le contrat : ajouter une colonne PII, c’est hériter automatiquement de la protection (« define once, new data picks up protection »). unlockFor relie la levée du masque à une finalité, pas à une identité : c’est l’implémentation contractuelle de la gate de la fiche 4. Provenance honnête : classification est natif ODCS, mais transform et unlockFor ne le sont pas : ils vivent en customProperties, au même titre que la rétention ou la base légale. Attention au faux ami : les champs natifs transformDescription / transformLogic décrivent comment une colonne est dérivée de ses sources (du lineage au niveau colonne), pas un masquage à la lecture : on les a vus en fiche 2 documenter des colonnes dérivées, et le contrôle d’accès n’est pas leur objet. Le natif le plus proche est encryptedName, au niveau de la colonne, qui pointe vers sa variante chiffrée (pas un masquage dynamique). Pour le masquage par finalité, on déclare donc notre policy sous customProperties, au même titre que la rétention, la base légale RGPD ou le contexte GxP. Et l’on garde la distinction juridique : un mask ou un tokenize réversible reste de la donnée personnelle : ce n’est pas une anonymisation.
5 · Incident & exploitation
Comment savoir ce qui casse, où, et combien ça coûte ?Un incident, ça se détecte (qualité), ça se traque (lineage) et ça se chiffre (finops). L’observability port du produit concentre logs, traces, SLO, métriques de qualité et audit.
L’objectif est simple : quand quelque chose casse, on devrait savoir et comprendre presque immédiatement d’où vient le problème. Cela suppose d’avoir monitoré chaque étape : depuis les sources jusqu’à l’exposition, en passant par chaque transformation. Le lineage[24](capturé au build) remonte alors l’amont : source défaillante ? transformation fautive ? exécution en échec ? Et pour chiffrer, on attribue le coût au niveau de l’exécution (la requête, le job), pas seulement de l’entrepôt.
Mais avant l’alerte, il y a la mesure. Les règles de qualité déclarées au contrat (vues en fiche 2) ne servent pas qu’à la CI : le bloc Qualité & observabilité les rejoue en production, à chaque run, et en tire des métriques sur la grille des six dimensions DAMA-UK[37] : complétude, unicité, actualité, validité, exactitude, cohérence. L’alerte n’est que le cas limite : une mesure qui franchit un seuil.
Agrégées, ces mesures forment le DQ dashboard, le tableau de bord qualité du produit, alimenté par l’observability port : score par dimension, tendance, historique des incidents. Il parle à deux publics. L’équipe domaine y pilote sa dette qualité : quelles règles échouent le plus souvent, quelle dimension se dégrade, où investir avant que l’astreinte ne sonne. Les consommateurs, eux, y lisent un signal de confiance : publié au catalogue à côté du contrat, le score de qualité se consulte avant de s’abonner, et se vérifie ensuite. Sans ce tableau de bord, la qualité n’existe qu’en négatif : on n’en entend parler que quand ça casse.
Flux détaillé
Voici la traque, pas à pas :
- Alerte (SLO dévié, qualité, run en échec)
- Lire les signaux (logs, traces, métriques)
- Remonter l’amont (où est la défaillance ?)
- Maillon fautif : source / transfo / run / consommateur
- Chiffrer le coût de l’incident (par étape)
- Attribution : chargeback / showback par data product
- Corriger le maillon ; l’observability confirme le retour à la normale↺ boucle
Un prix qui dérape est lui-même un incident. Le finops ne sert pas qu’à compter après la tempête : un coût monitoré qui sort de sa plage attendue (charge d’un serveur en hausse, volume de requêtes d’un consommateur qui triple, facturation d’un output port qui explose) se traite comme n’importe quelle déviation de SLO. On déclare un budget SLO au même titre qu’un SLO de fraîcheur, l’observability port le suit, et la dérive ouvre un incident avantla facture, pas après. C’est la version coût du principe vu plus haut (« une mesure qui franchit un seuil ») : un signal finops n’est pas un tableau de bord qu’on regarde une fois par mois, c’est une alerte qui sonne à temps, et le prolongement naturel des patterns d’usage anticipés en fiche 3.
Dans le data contract
L’exploitation s’ancre dans les slaProperties (vues en fiche 2) : ce sont elles qui déclenchent les alertes. Le contrat dit la cible et où router l’incident : c’est le lien entre la garantie publiée au discovery port et la surveillance de l’observability port :
# … (extrait du contrat clients-actifs-fr)
slaProperties:
- property: freshness
value: 24
unit: h
element: clients_actifs.derniere_commande
- property: completeness
value: 99
unit: percent
- property: latency # cas temps réel (cf. fiche synthèse)
value: 500
unit: ms
customProperties: # severity n'est pas natif sur slaProperties
- property: slaSeverity # (ServiceLevelAgreementProperty est fermé) :
value: # criticité d'alerte par SLO, en extension
freshness: critical # pilote la criticité de l'alerte
completeness: warning
support: # où va l'alerte (natif ODCS)
- channel: "#marketing-data-oncall"
tool: slack
scope: incident
- url: https://intra/runbooks/clients-actifs
scope: runbookPourquoi c’est utile. Sans valeurs chiffrées au contrat, le monitoring n’a pas de seuil : une « déviation » n’est détectable que si la normale est déclarée. Le severity (porté en customProperties, non natif sur slaProperties) évite de réveiller une astreinte pour un retard mineur ; support garantit que l’alerte atteint le bon rôle (le domaine propriétaire), pas une équipe centrale. Cas particulier : la latency n’a de sens que pour un produit servi en quasi temps réel ; pour un produit batch, on s’en tient à freshness et completeness.
Pour aller plus loin
Bien alerter : du seuil au plan d’action
Déclarer les seuils ne suffit pas ; bien alerter tient en quatre choix de conception.
1 · Alerter là où on regarde. La section « Dans le data contract » l’a montré : le bloc support route l’alerte vers le domaine propriétaire. Reste à choisir le canal, et c’est une décision de conception, pas un détail de configuration : celui que l’équipe voit en temps réel, souvent un canal Teams ou Slack d’astreinte (#marketing-data-oncall), plutôt qu’une boîte mail lue le lendemain.
2 · Ne pas inonder. Une alerte doit être actionnable ; chaque alerte ignorée éduque l’équipe à ignorer la suivante (la fatigue d’alerte)[27]. Au-delà de la severity déjà vue, deux leviers : le regroupement (un incident amont doit produire une alerte, pas cinquante en aval, et c’est le lineage qui permet de dédupliquer) et des seuils qui traduisent le SLO, pas la moindre variation.
3 · Un plan d’action par alerte. La bonne pratique : chaque alerte possible a son plan d’action documenté à l’avance ; l’analyse de risques du produit l’a anticipé : quels modes de défaillance ? quelle gravité ? qui décide quoi ? Le protocole à suivre est systématisé dans la documentation : c’est le runbook[27], déjà référencé par le contrat (l’entrée scope: runbook du bloc support). Une alerte sans plan d’action est une invitation à improviser à 3 h du matin.
4 · Automatiser l’investigation, jusqu’à l’agentique. L’enchaînement de cette fiche (alerte → signaux → lineage → cause) est un protocole répétable, donc automatisable : d’abord des diagnostics scriptés, et de plus en plus une investigation agentique : un agent lit l’alerte, remonte le lineage, teste les hypothèses du runbook et propose, voire applique, la remédiation pour les cas connus. C’est une trajectoire d’écosystème en 2026, pas un standard ; et la responsabilité de la résolution reste au domaine : l’agent investigue, l’humain répond de ce qui part en production, hors cas explicitement délégués et bornés.
6 · Évoluer, puis finir sa vie
Comment changer ou retirer le produit sans casser ses consommateurs ?Un data product vit. Changer son schéma, c’est risquer de casser des consommateurs en production, d’où le versionnement du contrat. Et le retirer, ça se prépare.
Un produit expose une version de son contrat. Un changement non cassant (ajouter une colonne optionnelle) se gère sans douleur : les consommateurs ignorent simplement le nouveau champ. Un changement cassant (supprimer une colonne, modifier un type) exige au contraire la coexistence des versions et une migration accompagnée : on publie v2, on laisse à chacun le temps de migrer, puis on retire v1. En streaming, cette discipline est enforcée à l’exécution par un Schema Registry : avant d’écrire un message, le producteur enregistre son schéma, et le Registry bloque la publication si ce schéma risque de casser les consommateurs, selon une règle de compatibilité (BACKWARD, FORWARD ou FULL) [9].
Reste alors la question clé : « qui consomme encore la v1 ? ». C’est le rôle du lineage, qui trace les dépendances aval. La déprécation, enfin, s’annonce (date de sunset), se migre consommateur par consommateur, puis se retire.
Pour aller plus loin — Compatibilité BACKWARD, FORWARD, FULL : qui protège qui ?
En streaming, producteur et consommateurs se déploient indépendamment et à des rythmes différents. La règle de compatibilité dit quelle direction du temps on protège : les anciens messages lus par de nouveaux consommateurs, les nouveaux messages lus par d’anciens consommateurs, ou les deux. C’est aussi inspirant pour les produits batch, donc je détaille ici les trois modes de compatibilité, qui sont les plus courants :
- BACKWARD : un nouveau consommateur sait lire les anciens messages. On peut ajouter un champ (avec valeur par défaut) ou supprimer un champ ; on ne peut pas retirer la valeur par défaut d’un champ existant. C’est le défaut, et le plus courant : on garantit que les consommateurs qu’on déploie comprendront l’historique déjà présent dans le topic.
- FORWARD : un ancien consommateur sait lire lesnouveaux messages. On peut supprimer un champ (l’ancien consommateur l’ignore) ou en ajouter un optionnel ; on protège les consommateurs qu’on n’a pas encore redéployés.
- FULL : BACKWARD et FORWARD à la fois. On ne peut qu’ajouter un champ optionnel avec défaut. Le plus contraignant, mais le plus sûr : on peut dépiler producteur et consommateurs dans n’importe quel ordre sans casser personne.
Concrètement, le Registry compare le schéma que le producteur s’apprête à publier au précédent, applique la règle configurée, et refuse l’enregistrement en cas de violation : l’écriture échoue alors à l’exécution. C’est l’équivalent streaming d’une gate de CI, mais par message et en continu plutôt qu’au moment du build.
Flux détaillé
Surtout, une évolution n’est pas qu’un sujet technique : changer le schéma oblige à revalider le contrat de données, d’autant plus s’il porte des données sensibles. Il faut vérifier que les tags de classification sont toujours justes, et les personnes responsables doivent « signer » à nouveau pour réengager leur responsabilité. Selon l’ampleur du changement, le plus sain est souvent de voir la mise à jour comme le fait de rejouer le cycle de création du data product, gates compris. Le flux ci-dessous le montre, jusqu’au retrait :
- Proposer une évolution (breaking ou non) : version vN du contrat
- Vérifier la compatibilité (BACKWARD / FORWARD / FULL en streaming)
- Revalider le contrat (tags de classification, finalité)
- Re-signature des responsables : réengagementgate↺ boucle
- Évolution approuvée (audit log)gate
- Notifier les abonnés (coexistence v1 + v2, migration accompagnée)
- Migrer vers vN (ou rester en v1 pendant la coexistence)
- si retraitAnnoncer le sunset puis retirer (état Retired)
- Bannière de déprécation au catalogue → retrait
Dans le data contract
L’évolution se lit dans deux champs vus dès la fiche 1 : version (SemVer) et status, auxquels on ajoute une règle de compatibilité que la CI fait respecter :
# Évolution : v1.2.0 → v2.0.0 (changement CASSANT)
# extrait annoté à but pédagogique ; ne pas valider tel quel
apiVersion: v3.1.0
id: clients-actifs-fr # l'id ne change JAMAIS
version: 2.0.0 # major++ = breaking (colonne retirée)
status: active
schema:
- name: clients_actifs
properties:
- name: client_id
logicalType: string
# 'email' retiré → c'est ce qui rend le changement cassant
customProperties:
- property: contractCompatibility # extension, non native ODCS
value: backward # la CI vérifie vs la version publiée
# backward | forward | full | none
# cf. fiche 6, DeepDive compatibilité
---
# Fin de vie : on déprécie, on ne supprime pas brutalement
version: 1.2.0
status: deprecated
customProperties:
- property: deprecation # extension, non native ODCS
value:
sunsetDate: "2026-12-31" # date de retrait annoncée
replacedBy: clients-actifs-fr:2.0.0
migrationGuide: https://intra/migrations/clients-actifs-v2Pourquoi ça protège les consommateurs. Le SemVer (major.minor.patch) encode la promesse : un minor ajoute sans casser, un major signale un changement cassant : contractCompatibility donne à la CI la règle pour refuser un breaking déguisé en patch. Cas particulier streaming : ce sont les modes BACKWARD / FORWARD / FULL du Schema Registry qui jouent ce rôle, à l’exécution. Enfin, la policy deprecation rend la fin de vie pilotée (date, remplaçant, guide) plutôt que subie : c’est l’antidote aux « ghost products ». Provenance honnête : contractCompatibility et deprecation ne sont pas natifs ODCS : on les déclare sous customProperties, comme toute règle maison. Et toute évolution touchant une colonne PII relance la re-signature des roles concernés.
Clôture · Synthèse
Limites et pour qui c’est fait
Le mouvement de clôture, et les questions les plus pratiques : où le mesh casse-t-il, jusqu’où sert-il, et où brancher un use case ML temps réel ?
Les trois endroits où ça casse
C’est le passage anti-FOMO de cet article. Le data mesh n’est pas une potion magique : c’est une réponse à des douleurs réelles, qui a un coût. Voici où les projets dérapent le plus souvent : dépliez chaque point pour le détail.
L’ownership sans incitationorganisation / politique
C’est généralement le vrai blocage ; il n’est pas technique. La décentralisation est un transfert de travail et de risque que personne n’a demandé : un domaine se voit confier la qualité, la doc et le support de « ses » données, sans forcément en avoir les moyens ni l’envie.
- Problème de bien public (free-rider) : le domaine qui produit paie, les autres profitent. Sans incitation, il sous-investit, rationnellement.
- Turf wars : des guerres de territoire entre domaines (« le client, c’est un concept marketing ou sales ? »)[28].
- Organizational theater[29] : rebaptiser « l’équipe ERP » en « domaine ERP » sans rien changer aux responsabilités ni au budget.
Le sponsoring exécutif est, dans la littérature, le premier prédicteur de réussite[29].
La plateforme self-servicetechnique / archi
Le pilier le plus dur. C’est un vrai effort de platform-engineering, jamais un produit clé-en-main.
- Pas de clé-en-main : catalogue, orchestration, contrats, observabilité, accès, lineage : chacun est un outil, et la vraie charge est leur intégration.
- Brownfield : la coexistence durable avec l’entrepôt central et le legacy est la norme, pas l’exception.
- Sans plateforme mature, chaque domaine bricole son infra et recrée des silos ; on perd les économies d’échelle.
La gouvernance qui se grippeprincipe make-or-break
La gouvernance fédérée est un équilibre instable.
- Trop lâche → chaos, duplication, prolifération de ghost products[30].
- Trop serrée → re-centralisation déguisée, et le goulot d’étranglement revient par la fenêtre[30].
- Les données de référence (MDM / reference data) sont sous-spécifiées par le mesh pur : la cohérence cross-domaine ne tombe pas du ciel (le point est creusé fiche 3 : adressage global, polysèmes, partage par table vs fédération).
Au fond, le data mesh rapproche les problèmes de ceux qui les comprennent, au prix d’un coût de coordination supplémentaire. Mon sentiment : l’arbitrage tend à payer à grande échelle, et plus rarement pour une petite structure. Le risque principal n’est d’ailleurs pas le choix d’un outil : c’est de sous-estimer l’effort plateforme et les prérequis, techniques et organisationnels. Un seuil souvent évoqué dans la littérature : au moins cinq équipes domaine déjà en production[15], une ingénierie de données moderne (DDD, CI/CD) et un engagement pluriannuel[29][31]. En dessous, mieux vaut souvent commencer petit.
Est-ce pour vous ? (et pour une PME ?)
Le mesh complet est souvent surdimensionné ; mais ses principes sont peu coûteux et bons à voler. La bonne maxime pour beaucoup d’organisations : « une seule équipe centrale, mais qui livre des data products, pas juste des tables ». L’arbre de décision tient en quelques questions : avez-vous plusieurs domaines autonomes à l’échelle ? l’équipe centrale est-elle un goulot ? avez-vous la capacité de changer l’operating model ? Si oui, un mesh incrémental ; sinon, un socle centralisé propre avec des produits et des contrats légers.
Même à petite échelle, deux principes valent presque toujours le coup d’être adoptés tôt : la gouvernance et le contrat. Un data contract n’est pas qu’un artefact technique : c’est un engagement explicite entre des parties, avec des garanties (qualité, fraîcheur, finalité) que l’on peut mesurer et opposer. C’est souvent ce qui fait passer une organisation de « la donnée existe quelque part » à « on sait sur quoi on peut compter ».
Pour aller plus loin — l’IA agentique change-t-elle la donne pour la PME ?
En partie. L’agentique et les plateformes radicalement simplifiées érodent réellement la barrière technique du mesh (infra, pipelines, catalogage, gouvernance automatisée). Conséquence vraie : data-as-a-product + contrats + self-service deviennent assez peu chers pour être une bonne pratique à toute taille.
Mais ce qui justifie le mesh complet est une complexité organisationnelle (plusieurs domaines autonomes, un goulot central), pas la technique[32] ; l’outillage ne crée pas cette précondition. Une PME à un ou deux domaines n’a rien à décentraliser[33]. Formulation propre : l’agentique démocratise les principes à toute taille, pas l’operating model (la fédération), qui reste une réponse à l’échelle. Le consensus PME est raffiné, pas renversé.
Opérationnel vs analytique : où se branche le ML temps réel, et l’IA ?
« Si je veux un use case ML en temps réel, je m’appuie sur la plateforme, ou c’est forcément hors-mesh ? » Réponse courte : non, pas forcément hors-mesh ; et oui, ce serait dommage de s’en priver. Mais il faut distinguer le canon de l’extension.
Le canon (Dehghani) sépare deux plans[7] : le plan opérationnel (les systèmes transactionnels qui font tourner le business) et le plan analytique (la vue agrégée pour décider et entraîner des modèles). Le data mesh est scopé au plan analytique. Point clé souvent mal compris : la frontière est opérationnel vs analytique, pas batch vs temps réel. Lareal-time analytics (servir des features fraîches à faible latence) est dans le périmètre.
Plan analytique : data mesh (canon)
Plan opérationnel (OLTP) : fait tourner le business
Concrètement, pour un scoring de fraude ou une reco : les features viennent de data products gouvernés (un feature store est un data product de type aggregate), servis par des ports streaming. Le domain event est le pont entre les deux plans[34] : le fait métier horodaté nourrit à la fois l’analytique et, en flux, les features temps réel. Ce qui reste vraiment du plan opérationnel, c’est le serving live (l’app qui appelle le modèle à la milliseconde) : c’est l’extension.
C’est aussi l’horizon de tout l’édifice : des data products gouvernés (contrats et sémantique) forment le socle d’une IA agentique fiable. Le « mesh agentique » (le terme est d’Eric Broda[35]) reste émergent, et aucun éditeur n’en détient la définition. Mais la direction est claire : ce qui rend un agent digne de confiance, c’est le même contrat qui rend un dashboard digne de confiance.
Annexes · Référence
Les rôles, les outils
Le fil principal introduit chaque rôle et chaque bloc au moment où le film les fait entrer en scène. Voici, pour la carte complète, les tableaux de référence.
Rôles et responsabilités
Un domaine métier (ownership)
| Rôle | Responsable de | Ne fait pas |
|---|---|---|
| Propriétaire du domaine | La donnée de son domaine métier ; ce qui devient (ou non) un data product, et sa qualité. | Ne construit pas lui-même la technique (sauf petite structure). |
| Product owner du data product | Un produit précis : ses usages, ses consommateurs, son contrat. Souvent la même personne que le propriétaire en petite structure. | Ne gère pas l’infrastructure. |
| Data engineer du domaine (ou agent data engineer) | La réalisation technique : code, tests, exécutions. Le merge en production après les gates. | Ne décide pas du contrat métier ; ne fixe pas les règles globales. |
| Équipe plateforme | La plateforme self-service : des blocs outillés, l’expérience développeur, la fiabilité de l’« usine ». | Ne possède aucune donnée métier ; n’est pas un goulot de validation. |
| Gouvernance fédérée (réviseur, steward, DPO, conformité) | Les règles globales (sécurité, conformité, interopérabilité) encodées en policy-as-code ; le verdict aux gates. | N’écrit pas le code métier ; ne possède pas la donnée du domaine. |
| Consommateur (autre domaine, analyste, IA) | Son usage de la donnée ; le respect de la finalité qui lui a été accordée. | Ne modifie pas le produit ; ne le re-publie pas sans contrat. |
| Équipe d’accompagnement (enabling) | La montée en compétence des domaines : ateliers, coaching. | Ne possède, à terme, ni donnée ni plateforme. |
Dans une grande structure, ces rôles sont tenus par des personnes distinctes ; dans une PME, une même personne porte plusieurs chapeaux, y compris celui de DPO (délégué à la protection des données), sous réserve des incompatibilités réglementaires : le RGPD n’autorise ce cumul que s’il n’entraîne pas de conflit d’intérêts (article 38)[19].
Outils et éditeurs
| Bloc | Plan | Ce qu’on en attend | Exemples |
|---|---|---|---|
| Catalogue & découverte | plan : mesh | Rendre les produits de tous les domaines adressables globalement (schéma, owner, lineage, garanties) ; rechercher et corréler entre domaines. | DataHub, OpenMetadata, Collibra, Purview, Zeenea |
| Data contracts | plan : produit | Exprimer le contrat (schéma, SLO, qualité, finalité) et l’enforcer, pas seulement le documenter. Il alimente le discovery port : la carte d’identité du produit. | ODCS / Bitol, dbt model contracts, Schema Registry |
| Ingestion / iPaaS | plan : infra | Amener la donnée des sources, y compris hors-mesh (legacy, SaaS, API partenaires). | MuleSoft, Boomi · Airbyte, dlt, Fivetran · Debezium (CDC) |
| Orchestration | plan : infra | Planifier et enchaîner les étapes (ingest → transform → test → publish). | Airflow, Dagster, Prefect, Azure Data Factory |
| Transformation | plan : infra | Le « code » du produit : nettoyage, enrichissement, agrégation. | dbt, SQLMesh, Spark, Flink SQL, Polars |
| Stockage & serving | plan : infra | Matérialiser et servir, en batch et en temps réel. | Snowflake, BigQuery, Databricks · formats ouverts Iceberg / Delta / Hudi |
| Streaming | plan : infra | Produits temps réel, où le flux EST le produit. | Kafka / Confluent, Redpanda, Flink, Materialize |
| Qualité & observabilité | plan : produit | Mesurer et alerter sur la qualité (6 dimensions DAMA-UK) et la fraîcheur ; alimente l’observability port du produit. | Soda, Great Expectations, Monte Carlo, Elementary |
| Lineage | plan : infra | Tracer l’origine (amont → produit → aval). La capture, au build, est l’affaire de la pile d’exécution ; l’exploitation cross-domaine remonte via le catalogue. | OpenLineage + lineage natif des catalogues |
| Policy-as-code | plan : mesh | Encoder ET appliquer automatiquement les règles globales. | OPA / Rego, AWS Lake Formation, Immuta |
| Marché & gates d’accès | plan : mesh | Découvrir, demander, approuver ou refuser l’accès. | Data Mesh Manager, DataHub workflows, Lake Formation |
| Finops data | plan : infra | Attribuer le coût par data product ; chargeback / showback. | FinOps Foundation, FOCUS · attribution Snowflake / Databricks |
| CI-CD & promotion d’env. | plan : infra | Pipelines dev → preprod → prod avec gates ; contrat enforcé en CI. | GitHub/GitLab CI · dbt Slim CI · Dagster code locations |
| Couche sémantique | plan : produit | « Define once, use everywhere » : des métriques gouvernées ; l’auto-description sémantique du produit. | dbt Semantic Layer, Cube, AtScale |
C’est cet empilement de blocs qui matérialisele data product et ses cinq ports vus en fiche 1 : la transformation est le « code », le contrat alimente le discovery port (que le catalogue agrège pour la recherche cross-domaine), l’observabilité et le lineage alimentent l’observability port, la policy-as-code alimente le control port, et le stockage/streaming sert les output ports. Le data product n’existe pas « en l’air » : il est posé sur cette plateforme.
Plateforme self-service : assemblée, pas clé-en-main
Sources · Bibliographie
Les sources citées
Les sources citées dans l’article, par ordre d’apparition. Le repère [n] dans le texte renvoie à l’entrée correspondante ci-dessous.
- [1]Zhamak Dehghani, Data Mesh Principles and Logical Architecture (2020). martinfowler.com.
- [2]INNOQ (J. Christ, L. Visengeriyeva et al.), Data Product Canvas. datamesh-architecture.com.
- [3]Alberto Brandolini ; INNOQ, Event Storming ; « Data Mesh to Go: How to Get the Data Product » (2021). innoq.com.
- [4]Martin Fowler, BoundedContext (2014). martinfowler.com.
- [5]Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (2003). Addison-Wesley.
- [6]Agile Lab / Witboost, How to identify Data Products? Welcome « Data Product Flow » (2022). witboost.com.
- [7]Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (2019). martinfowler.com.
- [8]Bitol (Linux Foundation AI & Data), ODCS : Open Data Contract Standard, v3.x. bitol.io.
- [9]Adam Bellemare (Confluent), Data Products, Data Contracts, and Change Data Capture. confluent.io.
- [10]Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures (2017). O’Reilly.
- [11]Open Data Mesh Initiative, Data Product Descriptor Specification (DPDS). dpds.opendatamesh.org.
- [12]Bitol (Linux Foundation AI & Data), ODPS : Open Data Product Standard, v1.0.0 (2025). bitol.io.
- [13]Jarkko Moilanen et al., Open Data Product Specification. opendataproducts.org.
- [14]Matthew Skelton & Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019). IT Revolution.
- [15]INNOQ, Data Mesh Architecture. datamesh-architecture.com.
- [16]DAMA International, DAMA-DMBOK: Data Management Body of Knowledge (2nd ed.) (2017). Technics Publications.
- [17]Gartner, Dark Data (IT Glossary). gartner.com.
- [18]Wiz, What is Shadow Data?. wiz.io.
- [19]Parlement européen & Conseil, Règlement (UE) 2016/679 (RGPD), art. 17 & 30 (2016). EUR-Lex.
- [20]IBM Security / Ponemon Institute, Cost of a Data Breach Report 2024 (2024). IBM.
- [21]Open Semantic Interchange (Snowflake, dbt Labs, Salesforce, BlackRock et al.), Open Semantic Interchange (OSI), v0.1.x (2025). open-semantic-interchange.org.
- [22]EDPB, Guidelines 01/2025 on Pseudonymisation (2025). edpb.europa.eu.
- [23]CNIL, L’anonymisation de données personnelles. cnil.fr.
- [24]OpenLineage (LF AI & Data), OpenLineage : An Open Standard for Lineage Metadata. openlineage.io.
- [25]FinOps Foundation (Linux Foundation), FinOps Framework. finops.org.
- [26]FinOps Foundation, FOCUS : FinOps Open Cost & Usage Specification, v1.4 (2026). focus.finops.org.
- [27]Betsy Beyer et al. (Google), Site Reliability Engineering, chap. « Monitoring Distributed Systems » et « Being On-Call » (2016). O’Reilly.
- [28]Starburst, Data Mesh: What Happened?. starburst.io.
- [29]Thoughtworks, The State of Data Mesh in 2026: From Hype to Hard-Won Maturity (2026). thoughtworks.com.
- [30]Barr Moses (Monte Carlo), When a Data Mesh Doesn’t Make Sense for Your Organization. montecarlodata.com.
- [31]Paulo Caroli, Data Mesh Readiness Assessment. caroli.org.
- [32]Thoughtworks, Data Mesh: It’s Not Just About Tech, It’s About Ownership and Communication. thoughtworks.com.
- [33]Thoughtworks, Decoder: Data Mesh. thoughtworks.com.
- [34]Adam Bellemare, Building an Event-Driven Data Mesh (2023). O’Reilly.
- [35]Eric Broda & Davis Broda, Agentic Mesh (2026). O’Reilly.
- [36]Zhamak Dehghani, Data Mesh: Delivering Data-Driven Value at Scale (2022). O’Reilly.
- [37]DAMA UK Working Group, The Six Primary Dimensions for Data Quality Assessment (2013). DAMA UK / GOV.UK.
Du film au terrain de jeu
Cet article est la rampe d’accès ; le playground est le film qu’on joue. Vous y prendrez les rôles tour à tour (propriétaire, data engineer, réviseur, DPO) pour créer et faire vivre des data products dans une entreprise virtuelle.
Besoin d’y voir clair pour votre cas ? Je peux vous aider à auditer vos use cases et votre architecture pour trancher, puis à dessiner une version minimaliste qui n’embarque que les principes réellement utiles pour vous.