La gouvernance des données est devenue un enjeu critique. En entretien Analytics Engineer ou Data Architect, on évalue la capacité à structurer la qualité, la traçabilité et la conformité des données à l'échelle.
La gouvernance des données n'est pas une contrainte administrative — c'est ce qui permet aux équipes data de scaler sans chaos. Sans gouvernance, chaque projet repart de zéro, les définitions de métriques divergent, et la confiance dans les données s'effondre.
1Catalogue de données
Question discriminante
Quelle est la différence entre un catalogue de données technique et un catalogue de données business ? Avez-vous déjà mis en place un catalogue ?
- Catalogue technique — référence les tables, colonnes, types, statistiques de qualité. Alimenté automatiquement par des outils comme DataHub, Apache Atlas, OpenMetadata
- Catalogue business — enrichit le catalogue technique avec des définitions métier, des owners, des tags de sensibilité, des descriptions en langage naturel
- Outils : DataHub (LinkedIn, open source), Collibra (enterprise), Alation, OpenMetadata, dbt docs (pour les modèles dbt)
- Metadata actif vs passif — un catalogue passif est documenté à la main et devient obsolète. Un catalogue actif est alimenté automatiquement par les pipelines et les outils
dbt comme point d'entrée : pour les équipes analytics, le dbt project (avec les descriptions YAML) est souvent le premier catalogue naturel. dbt docs génère automatiquement une documentation navigable avec le lineage SQL.
2Data lineage : tracer la donnée de la source au dashboard
Question discriminante
Qu'est-ce que le data lineage ? Donnez un exemple concret de cas où il vous a été utile.
- Data lineage — traçabilité complète d'une donnée depuis sa source (base transactionnelle, API, fichier) jusqu'à son utilisation (dashboard, modèle ML, rapport)
- Column-level lineage — savoir exactement quelle colonne source alimente quelle colonne cible, à travers toutes les transformations SQL
- Cas d'usage : impact analysis (si je change cette table source, quels dashboards sont affectés ?), root cause analysis (pourquoi ce KPI a changé ?), conformité RGPD (où sont les données personnelles ?)
- Outils : DataHub, OpenLineage (standard ouvert), dbt (lineage des modèles), Marquez
# dbt : le lineage est calculé automatiquement depuis les refs
-- models/marts/finance/fct_revenue.sql
SELECT
o.order_id,
o.created_at,
c.customer_segment,
p.product_category,
o.amount
FROM {{ ref('stg_orders') }} o -- source tracée
JOIN {{ ref('dim_customers') }} c ON o.customer_id = c.customer_id
JOIN {{ ref('dim_products') }} p ON o.product_id = p.product_id
3Qualité des données : mesurer et monitorer
Question discriminante
Quelles sont les dimensions de la qualité des données ? Comment les mesurez-vous automatiquement dans vos pipelines ?
| Dimension | Définition | Exemple de test |
|---|
| Complétude | % de valeurs non-null | not_null sur les colonnes critiques |
| Exactitude | Conformité aux valeurs attendues | accepted_values, plages de valeurs |
| Fraîcheur | Age des données par rapport à l'attendu | source_freshness dans dbt |
| Unicité | Absence de doublons sur les clés | unique sur les PKs |
| Cohérence | Cohérence entre tables liées | relationships test dans dbt |
| Validité | Respect du schéma et des formats | Schema validation, regex tests |
- dbt tests — not_null, unique, accepted_values, relationships : tests automatisés à chaque run
- Great Expectations — framework Python pour des règles de qualité complexes et paramétrables
- Monte Carlo / Bigeye — data observability automatique, détection des anomalies sans règles prédéfinies
4Master Data Management (MDM)
Question discriminante
Qu'est-ce que le Master Data Management ? Donnez un exemple de problème que le MDM résout.
- MDM — gestion d'un référentiel unique et fiable pour les entités clés de l'organisation (clients, produits, fournisseurs, entités légales)
- Problème résolu — un client qui existe dans 3 systèmes différents avec des IDs différents. Le MDM crée un identifiant unique (Golden Record) qui réconcilie toutes les sources
- Composants : déduplication/matching, record linkage, golden record, distribution aux systèmes consommateurs
- Outils : Informatica MDM, Stibo STEP, Reltio, ou custom avec dbt + Splink (probabilistic matching open source)
5RGPD et conformité des données
Question discriminante
Comment gérez-vous le droit à l'effacement RGPD dans un data lake ? Quelles sont les techniques d'anonymisation que vous utilisez ?
- Inventaire des données personnelles — identifier et tagger toutes les colonnes contenant des données personnelles dans le catalogue
- Droit à l'effacement — soft delete en base transactionnelle + propagation dans le data lake (délicat car les fichiers Parquet sont immutables → nécessite du vacuuming Delta Lake/Iceberg)
- Anonymisation — suppression définitive de l'identifiant : irréversible, données ne peuvent plus être reliées à une personne
- Pseudonymisation — remplacement de l'identifiant par un pseudonyme réversible (tokenisation) : la re-identification reste possible avec la clé
- Minimisation — ne collecter que les données strictement nécessaires à la finalité
- Data Classification — tagguer les données selon leur sensibilité : Public, Internal, Confidential, PII, Sensitive PII
6Stack gouvernance typique en 2025
- Catalogue — DataHub (open source, LinkedIn) ou OpenMetadata
- Qualité — dbt tests + Great Expectations ou Soda Core
- Lineage — DataHub avec intégration Airflow + dbt
- Observabilité — Monte Carlo ou Metaplane (anomaly detection automatique)
- Access control — Row-Level Security dans Snowflake/BigQuery + politique de tags
- RGPD — Delta Lake/Iceberg pour le droit à l'effacement + chiffrement au repos
7Grille par niveau
| Niveau | Maîtrise attendue | Signal GO | NO-GO |
|---|
| Confirmé | Tests dbt, catalogue basique, classification des données | A implémenté not_null/unique/accepted_values, a documenté ses modèles dbt | Ne sait pas ce qu'est un data lineage, n'a jamais écrit de tests sur ses données |
| Senior | DataHub/OpenMetadata, Great Expectations, column-level lineage, RGPD pratique | A mis en place DataHub, a géré un droit à l'effacement RGPD, connaît la pseudonymisation | Ne sait pas comment gérer le droit à l'effacement dans un data lake |
| Lead | Architecture gouvernance complète, MDM, data contracts, standards d'équipe | A défini la stratégie gouvernance de son organisation, a mis en place des data contracts | Ne peut pas expliquer la différence entre anonymisation et pseudonymisation |