La gouvernance des données, une priorité renforcée

La donnée n’a de valeur que si on peut lui faire confiance. Une gouvernance pragmatique n’est pas de la bureaucratie, mais un framework pour garantir que la donnée est fiable, sécurisée et comprise par tous. Il ne s’agit pas de tout contrôler, mais de définir des garde-fous clairs sur les données les plus critiques. L’objectif est simple : permettre à tout le monde d’utiliser la donnée en toute confiance pour aller plus vite, pas le contraire.

prérequis

Un inventaire des 20% de jeux de données qui génèrent 80% de la valeur.
Des propriétaires (owners) identifiés pour chaque domaine métier (ventes, marketing, produit).
Un espace partagé (Confluence, Notion, Git repo) pour centraliser les règles et la documentation.

idées clefs

Rôles clairs: Identifier un owner (décideur), un steward (gardien de la qualité), et les experts techniques.
Contrats de données: Pour les assets critiques, formaliser le schéma, les SLA et les règles d’accès dans un fichier simple.
Tests automatisés: Mettre en place des tests non-négociables sur la fraîcheur, le schéma, et les valeurs aberrantes.
Accès par rôles (RBAC): Définir des politiques d’accès claires (ex: RLS/CLS) au lieu de gérer des permissions individuelles.
Changelog public: Toute modification sur un jeu de données critique doit être tracée et communiquée.
Mesure d’usage: Analyser les logs de requêtes pour identifier et archiver les données inutilisées.

tutoriel pas-à-pas

étape 1: Nommer les rôles et le périmètre

La première étape est de clarifier qui est responsable de quoi. Sans ça, tout le reste échoue. Concentrez-vous sur les données les plus importantes pour commencer.

- **Data Owner** (ex: Head of Sales)
  - Responsabilité: Décide des priorités, valide les définitions métier, est l'ultime responsable de la donnée de son domaine.
- **Data Steward** (ex: Senior Sales Analyst)
  - Responsabilité: Maintient la documentation, surveille la qualité au quotidien, est le point de contact pour les utilisateurs.
- **Data Engineer**
  - Responsabilité: Construit et maintient les pipelines, implémente les tests de qualité et les contrôles d'accès.
- **Data Security Officer**
  - Responsabilité: Définit les politiques de sécurité, audite les accès, gère les secrets.

étape 2: Publier des contrats de données

Pour chaque jeu de données critique, un contrat explicite doit être publié. C’est un simple fichier YAML qui vit avec le code.

# contracts/ventes/orders_v1.yml
dataset_id: ventes.orders_v1
owner: sales-department
description: "Table transactionnelle principale contenant toutes les commandes validées."

schema:
  - name: order_id
    type: string
    description: "Identifiant unique de la commande."
  - name: order_date
    type: date
    time_zone: "UTC"
  - name: amount_eur
    type: number
    description: "Montant HT de la commande en Euros."
  - name: country
    type: string
    description: "Code pays ISO 3166-1 alpha-2."

access_policy: "RLS (Row-Level Security) activé sur la colonne 'country'."

slo: # Service Level Objectives
  freshness_max_hours: 6
  availability_pct: 99.5

étape 3: Mettre en place des tests de qualité essentiels

Ces trois types de tests couvrent la majorité des problèmes de qualité courants. Ils doivent être intégrés à votre orchestrateur (ex: Airflow, dbt).

-- 1. Test de fraîcheur: la donnée a-t-elle été mise à jour récemment ?
SELECT MAX(order_date) AS max_date FROM ventes.orders_v1;
-- -> Échoue si max_date < CURRENT_DATE - slo.freshness

-- 2. Test de validité: y a-t-il des valeurs absurdes ?
SELECT COUNT(*) AS negative_amounts FROM ventes.orders_v1 WHERE amount_eur < 0;
-- -> Échoue si negative_amounts > 0

-- 3. Test de schéma: la structure a-t-elle changé sans prévenir ?
SELECT column_name, data_type FROM information_schema.columns
WHERE table_name = 'orders_v1' AND table_schema = 'ventes';
-- -> Échoue si le résultat ne correspond pas au schéma défini dans le contrat.

étape 4: Sécuriser les identités et les accès

Le principe du moindre privilège est non-négociable. Les accès doivent être définis par rôles, pas par individu.

# policies/data_access.yml
roles:
  - name: analyst_fr
    permissions:
      - type: read
        datasets:
          - marketing.*
        row_level_security: "country = 'FR'"

  - name: owner_ventes
    permissions:
      - type: read_write
        datasets:
          - ventes.*

étape 5: Tracer les changements

Un changelog simple en markdown dans le repo Git du projet data est suffisant. Chaque modification d’une logique de calcul ou de schéma doit y figurer.

### Changelog: ventes.orders_v1

- **2021-01-05**:
  - `BREAKING`: Le calcul de `amount_eur` a été modifié pour être hors-taxes (HT) au lieu de TTC.
  - `ADD`: Ajout de la colonne `country`.
- **2020-12-12**:
  - `FIX`: Correction d'un bug de jointure qui créait des commandes en double.

exemples

cas: Gouvernance d’une vue “utilisateurs actifs 30j”

On applique les principes de gouvernance à une vue de métrique produit.

CREATE OR REPLACE VIEW produit.active_users_30d_v AS
-- OWNER: product-team
-- CONTRACT: contracts/produit/active_users_30d_v1.yml
-- DESCRIPTION: Compte les utilisateurs actifs uniques sur les 30 derniers jours glissants.
SELECT
    event_date AS d,
    COUNT(DISTINCT user_id) AS active_users_30d
FROM
    analytics.events
WHERE
    event_date >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY 1;

Owner: L’équipe Produit est responsable de la définition d’un “utilisateur actif”.
Contrat: Un fichier YAML définit le schéma (d, active_users_30d), le SLA de fraîcheur (24h) et qui peut y accéder (rôle product_analyst).
Tests: Un test vérifie que active_users_30d ne chute jamais de plus de 20% d’un jour à l’autre sans raison.
Changelog: Toute modification de la définition (ex: exclusion des bots) est documentée.

erreurs courantes et solutions

Symptôme: Personne ne sait qui contacter pour une question sur une donnée.
- Cause: Responsabilités floues.
- Correctif: Nommer un owner et un steward pour chaque domaine critique et les afficher dans le catalogue de données.
Symptôme: La documentation est toujours obsolète.
- Cause: Processus de documentation manuel et lourd.
- Correctif: Préférer des fiches de métadonnées courtes et un changelog simple en markdown, versionnés avec le code.
Symptôme: Des données incorrectes sont découvertes des semaines plus tard.
- Cause: Absence de contrôles proactifs.
- Correctif: Implémenter les 3 tests de base (fraîcheur, validité, schéma) sur les 20% de tables les plus importantes.
Symptôme: Risque de fuite de données car trop de monde a accès à tout.
- Cause: Gestion des accès ad-hoc et individuelle.
- Correctif: Mettre en place des rôles avec des permissions minimales (ex: analyst_marketing) et utiliser RLS/CLS.

faq

La gouvernance, ça ne va pas tout ralentir ? Une gouvernance mal faite, oui. Une gouvernance pragmatique, centrée sur les assets critiques et l’automatisation, fait gagner un temps considérable en évitant les erreurs, les incompréhensions et les re-travaux.
Faut-il absolument un outil de catalogue de données payant ? Non. Commencez simple avec une structure de fichiers markdown dans un repo Git et des tests SQL. Un outil dédié devient pertinent quand le nombre d’assets et d’utilisateurs rend la gestion manuelle trop complexe.

Menu