Accueil/Data Mesh & Gouvernance fédérée

Data Mesh & Gouvernance fédérée

Gouvernance décentralisée — cas SNCF

Modélisation d'une gouvernance Data Mesh sur 4 domaines fictifs SNCF. Data Catalog interactif, Data Contracts inter-domaines, visualisation du lineage bout-en-bout avec D3.js.

Data MeshData ProductsData ContractsFederated Governance

Les 4 principes du Data Mesh

Conceptualisé par Zhamak Dehghani (ThoughtWorks, 2019), le Data Mesh répond aux limites des architectures data centralisées : goulots d'étranglement, silos, scaling difficile. Il propose une décentralisation architecturale et organisationnelle des données.

Domain Ownership

Les domaines métiers sont responsables de leurs données en tant que propriétaires. La gouvernance est décentralisée : chaque domaine gère ses données comme un produit.

Data as a Product

Les données sont traitées comme des produits : elles ont un propriétaire, une documentation, des SLA, un versionning et sont conçues pour être consommées par d'autres.

Self-Serve Platform

Une plateforme data commune fournit les capacités d'infrastructure (stockage, compute, catalogage, accès) sans que chaque domaine ait à les reconstruire.

Federated Governance

La gouvernance est fédérée : des standards globaux (Data Contracts, qualité, sécurité) sont définis centralement et appliqués localement par chaque domaine.

Modélisation — 4 domaines SNCF fictifs

Application concrète du Data Mesh à une organisation ferroviaire complexe. Chaque domaine est propriétaire de ses data products et responsable de leur qualité.

Infrastructure voie ferrée

Owner : Direction Infrastructure

Data Product	Fréquence	Consommateurs	SLA dispo.
État des voies	Quotidien	MaintenanceExploitation	99.5%
Incidents infrastructure	Temps réel	ExploitationSécurité	99.9%
Cartographie réseau	Mensuel	TravauxCommercial	98%

Exploitation trains

Owner : Direction Exploitation

Data Product	Fréquence	Consommateurs	SLA dispo.
Circulation temps réel	Temps réel	VoyageursMaintenance	99.9%
Performance ponctualité	Quotidien	StratégieCommercial	99%
Capacité & sillons	Hebdomadaire	CommercialInfrastructure	98%

Voyageurs & billetterie

Owner : Direction Commerciale

Data Product	Fréquence	Consommateurs	SLA dispo.
Flux voyageurs OD	Quotidien	StratégieExploitation	99%
Revenus & yield	Quotidien	FinanceStratégie	99.5%
Satisfaction client	Hebdomadaire	QualitéCommercial	97%

Maintenance

Owner : Direction Technique

Data Product	Fréquence	Consommateurs	SLA dispo.
Historique interventions	Quotidien	InfrastructureFinance	99%
Prédiction pannes	Quotidien	ExploitationInfrastructure	98%
Stock pièces détachées	Temps réel	MaintenanceFinance	99.5%

Data Contract — Exemple complet

Un Data Contract formalise le contrat entre un producteur de données et ses consommateurs. Il définit le schéma, les SLA, les règles de qualité et les responsabilités. Format YAML — versionné dans Git comme du code.

# Data Contract — Circulation trains temps réel
# Domaine : Exploitation | Version : 2.1.0 | Statut : Actif
 
metadata:
  id: "dc-exploitation-circulation-v2"
  name: "Circulation trains — Temps réel"
  domain: "exploitation"
  owner: "data-owner-exploitation@sncf.fr"
  steward: "data-steward-it@sncf.fr"
  version: "2.1.0"
  created: "2025-01-15"
  updated: "2026-03-01"
 
schema:
  fields:
    - name: train_id
      type: string
      description: "Identifiant unique du train (format: TGV-XXXXX)"
      nullable: false
    - name: timestamp_utc
      type: timestamp
      description: "Horodatage UTC de la position"
      nullable: false
    - name: position_lat
      type: float
      description: "Latitude GPS du train"
      nullable: false
    - name: position_lon
      type: float
      description: "Longitude GPS du train"
      nullable: false
    - name: retard_minutes
      type: integer
      description: "Retard en minutes (négatif = avance)"
      nullable: true
    - name: statut
      type: enum
      values: [EN_MARCHE, EN_GARE, SUPPRIME, RETARDE]
      nullable: false
 
quality:
  completeness: ">= 99.5%"
  freshness: "<= 30 secondes"
  accuracy: ">= 99.9%"
  uniqueness: "train_id + timestamp doit être unique"
 
sla:
  availability: "99.9% (max 8.7h downtime/an)"
  latency_p99: "<= 500ms"
  support: "24/7 pour incidents P1"
 
consumers:
  - domain: "voyageurs"
    use_case: "Information voyageurs temps réel"
  - domain: "maintenance"
    use_case: "Déclenchement alertes préventives"

Data Catalog — Inventaire des data products

Référentiel centralisé de tous les data products disponibles dans l'organisation. Point d'entrée unique pour découvrir, comprendre et consommer les données.

Domaine	Data Product	Owner	Fraîcheur	SLA	Consommateurs	Statut
Exploitation	Circulation temps réel	Dir. Exploitation	< 30s	99.9%	3	Actif
Infrastructure	État des voies	Dir. Infrastructure	Quotidien	99.5%	4	Actif
Voyageurs	Flux voyageurs OD	Dir. Commerciale	Quotidien	99%	2	Actif
Maintenance	Prédiction pannes	Dir. Technique	Quotidien	98%	2	Bêta
Voyageurs	Revenus & yield	Dir. Commerciale	Quotidien	99.5%	3	Actif
Exploitation	Performance ponctualité	Dir. Exploitation	Quotidien	99%	4	Actif

Projet précédent

Gouvernance Solvency II