data-data-governance-guide

name	data-data-governance-guide
description	Gouvernance des données incluant catalogues, lineage, qualité, ownership, politiques et metadata management. Se déclenche avec "data governance", "gouvernance données", "data catalog", "data lineage", "metadata", "data ownership"

Data Governance Guide

Étape 1 — Poser le cadre organisationnel

Avant tout outil, définir les rôles et la charte de gouvernance.

Rôle	Périmètre	Exemple concret
Data Owner	Responsabilité métier & budget	CFO pour les données financières
Data Steward	Qualité, définitions, règles	Analyste BI du domaine
Data Custodian	Stockage, sécurité, accès technique	DBA / Data Engineer
Data Consumer	Utilisation conforme aux politiques	Analyste, Data Scientist

Charte minimale (artefact à créer dès le kick-off) :

1. Périmètre couvert (domaines métier)
2. Instances de décision (Data Governance Council — cadence mensuelle)
3. Processus d'escalade qualité
4. Politique de classification des données
5. Indicateurs de succès (KPIs)

Critère de passage : chaque dataset critique a un Data Owner nommé et joignable.

---

Étape 2 — Déployer le Data Catalog

Choix de l'outil selon le contexte :

Contexte	Outil recommandé
Open-source / budget limité	DataHub (LinkedIn), Apache Atlas
Cloud AWS	AWS Glue Data Catalog + DataHub
Cloud Azure	Microsoft Purview
Cloud GCP	Dataplex
Enterprise avec budget	Collibra, Alation
Stack dbt	dbt Docs + Elementary

Ingestion automatique avec DataHub :

pip install acryl-datahub

# Crawler PostgreSQL
datahub ingest -c postgres_recipe.yaml

# postgres_recipe.yaml
source:
  type: postgres
  config:
    host_port: "localhost:5432"
    database: "my_db"
    username: "datahub"
    password: "${POSTGRES_PASSWORD}"
    include_tables: true
    profile_patterns:
      allow: ["public.*"]

sink:
  type: datahub-rest
  config:
    server: "http://datahub-gms:8080"

Métadonnées minimales obligatoires par dataset :

• Description métier (en langage non-technique)
• Data Owner + Data Steward
• Niveau de classification (public / interne / confidentiel / restreint)
• Schéma avec descriptions des colonnes
• Fréquence de mise à jour + SLA de fraîcheur
• Tags domaine métier

---

Étape 3 — Cartographier le Data Lineage

Avec dbt (lineage automatique) :

dbt docs generate
dbt docs serve  # UI interactive avec graphe de lineage

Lineage programmatique via DataHub SDK :

from datahub.emitter.mce_builder import make_dataset_urn
from datahub.emitter.rest_emitter import DatahubRestEmitter
from datahub.metadata.schema_classes import DatasetLineageTypeClass, UpstreamClass, UpstreamLineageClass

emitter = DatahubRestEmitter("http://datahub-gms:8080")

upstream_lineage = UpstreamLineageClass(
    upstreams=[
        UpstreamClass(
            dataset=make_dataset_urn("postgres", "prod.orders"),
            type=DatasetLineageTypeClass.TRANSFORMED,
        )
    ]
)
# émettre vers DataHub

Règle critique : avant toute modification de schéma, exécuter l'analyse d'impact :

# dbt — lister les modèles dépendants d'une colonne supprimée
dbt ls --select "orders+"  # tout ce qui dépend de 'orders'

---

Étape 4 — Qualité des données (Data Quality)

Framework Great Expectations — setup rapide :

pip install great-expectations
great_expectations init
great_expectations suite new

Expectations copiables :

import great_expectations as gx

context = gx.get_context()
ds = context.sources.add_pandas("my_ds")
da = ds.add_dataframe_asset("orders")
batch = da.add_batch_definition_whole_dataframe("batch").get_batch()

suite = context.suites.add(gx.ExpectationSuite(name="orders_suite"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(column="amount", min_value=0))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeUnique(column="order_id"))

Tests dbt (intégrer dans le pipeline CI/CD) :

# models/orders.yml
models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - not_null
          - unique
      - name: status
        tests:
          - accepted_values:
              values: ['pending', 'shipped', 'delivered', 'cancelled']
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('customers')
              field: id

Dimensions de qualité à mesurer :

Dimension	Mesure	Seuil acceptable
Complétude	% champs non-null sur colonnes critiques	> 99 %
Unicité	% de doublons sur clés primaires	0 %
Exactitude	% de valeurs dans les plages attendues	> 98 %
Fraîcheur	Écart vs SLA de mise à jour	< 1 heure (transactionnel)
Cohérence	Intégrité référentielle cross-datasets	100 %

---

Étape 5 — Classification et protection des données

Niveaux de classification :

PUBLIC      → données accessibles librement (ex : tarifs publics)
INTERNAL    → usage interne uniquement (ex : rapports de vente)
CONFIDENTIAL → accès restreint par rôle (ex : données RH)
RESTRICTED  → chiffrement + audit log + accès nominatif (ex : données PII, PCI)

Masquage PII avec Python (anonymisation one-way) :

import hashlib

def mask_email(email: str) -> str:
    """Pseudonymisation RGPD-compatible par hachage."""
    return hashlib.sha256(email.lower().encode()).hexdigest()[:16] + "@masked.local"

def mask_phone(phone: str) -> str:
    return phone[:3] + "****" + phone[-2:]

Politique de rétention (modèle) :

Données transactionnelles    : 7 ans (obligations légales)
Logs applicatifs             : 90 jours
Données de session           : 30 jours
Données marketing / cookies  : 13 mois (RGPD)
Données RH                   : durée du contrat + 5 ans

---

Étape 6 — Data Contracts

Un data contract formalise le SLA entre un producteur et ses consommateurs.

# data_contract_orders.yaml
id: orders-v2
version: "2.1.0"
owner: team-commerce
domain: commerce

schema:
  - name: order_id
    type: integer
    required: true
    unique: true
  - name: amount
    type: float
    required: true
    minimum: 0

sla:
  freshness: 15min          # délai max entre source et destination
  availability: 99.9%
  completeness: 99%

contact:
  owner: [e-mail]
  slack: "#team-commerce-data"

Outils : Soda Data Contracts, OpenDataContracts (spec open-source), dbt contracts (dbt Core 1.5+).

# dbt model contract
models:
  - name: orders
    config:
      contract:
        enforced: true
    columns:
      - name: order_id
        data_type: integer
        constraints:
          - type: not_null
          - type: unique

---

Étape 7 — KPIs de gouvernance (tableau de bord mensuel)

-- Couverture catalogue (% datasets documentés)
SELECT
    COUNT(*) FILTER (WHERE description IS NOT NULL AND owner IS NOT NULL) * 100.0 / COUNT(*) AS coverage_pct
FROM catalog.datasets;

-- Score qualité global (agrégat de toutes les suites GE)
SELECT
    suite_name,
    AVG(success_percent) AS avg_quality_score
FROM data_quality.run_results
WHERE run_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY suite_name
ORDER BY avg_quality_score ASC;

KPIs cibles :

• Couverture catalogue : > 80 % des datasets critiques documentés
• Score qualité global : > 95 %
• Incidents de qualité non détectés en production : 0
• Temps moyen de résolution d'un incident qualité : < 4 h

---

Anti-patterns / Pièges

Gouvernance top-down sans adhésion terrain — Si les équipes data ne voient pas la valeur, le catalogue devient obsolète en 3 mois. Impliquer les Data Stewards dès le départ, montrer les gains concrets (moins d'incidents, moins de questions répétées).

Tout cataloguer d'un coup — Commencer par les 20-30 datasets les plus critiques (80 % de la valeur), pas par l'exhaustivité. Prioriser par usage business réel.

Qualité sans ownership — Une alerte de qualité sans responsable assigné n'est jamais corrigée. Chaque règle de qualité doit avoir un Data Steward notifié automatiquement.

Data lineage manuel — Le lineage documenté à la main est toujours faux à J+30. Utiliser uniquement des outils qui capturent le lineage automatiquement (dbt, Airflow, Spark listeners, OpenLineage).

Politique de rétention sans suppression effective — Écrire la politique sans automatiser la suppression est un risque RGPD. Implémenter les jobs de purge dès le départ, pas après.

Classification à la main à grande échelle — Au-delà de 100 datasets, utiliser des outils de découverte automatique (AWS Macie, Microsoft Purview scanner, Google DLP) pour détecter PII/PHI/PCI.

---

Bonnes pratiques 2026

• OpenLineage comme standard de lineage inter-outils (Airflow, Spark, dbt supportent nativement le format Marquez/OpenLineage).
• dbt Mesh pour la gouvernance inter-domaines : chaque domaine expose des public models avec contrats enforced, les autres domaines ne consomment qu'au travers de ces interfaces stables.
• Data Mesh organisationnel : gouvernance fédérée avec standards centraux (catalog, qualité, classification) mais ownership décentralisé par domaine métier.
• Shift-left quality : les contrôles de qualité s'exécutent dans la CI/CD avant merge, pas seulement en production.
• Policies-as-code : versionner les politiques d'accès (ex : Apache Ranger policies en YAML dans Git) pour auditabilité et rollback.

Communication Rules — MANDATORY

• Ultra-concise. No filler, no preamble, no pleasantries.
• Never say "happy to help", "sure!", "great question", "let me", or similar.
• Tool first, talk second. Act before explaining.
• Result first. Lead with outcome, not process.
• Stop when done. No summary, no recap, no trailing commentary.
• No politeness wrappers. Direct and blunt.
• Minimum words. If one word works, do not use ten.
• No unsolicited explanations.
• No emoji unless asked.