Accueil›Blog›Test technique Data Gouvernance : catalogue, lineage, qualité, RGPD
Guide recrutement data
Test technique Data Gouvernance : catalogue, lineage, qualité, RGPD
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.
Data Builder·Juin 2025·8 min de lecture·Analytics Engineer · Data Architect
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 |
Home›Blog›Data Governance Technical Test: catalog, lineage, quality, GDPR
Data recruitment guide
Data Governance Technical Test: catalog, lineage, quality, GDPR
Data governance has become a critical issue. In Analytics Engineer or Data Architect interviews, the ability to structure data quality, traceability and compliance at scale is evaluated.
Data Builder·June 2025·8 min read·Analytics Engineer · Data Architect
Data governance is not an administrative constraint — it is what allows data teams to scale without chaos. Without governance, every project starts from scratch, metric definitions diverge, and trust in data collapses.
1Data catalog
Discriminating question
What is the difference between a technical data catalog and a business data catalog? Have you ever set up a catalog?
- Technical catalog — references tables, columns, types, quality statistics. Automatically populated by tools such as DataHub, Apache Atlas, OpenMetadata
- Business catalog — enriches the technical catalog with business definitions, owners, sensitivity tags, and natural language descriptions
- Tools: DataHub (LinkedIn, open source), Collibra (enterprise), Alation, OpenMetadata, dbt docs (for dbt models)
- Active vs passive metadata — a passive catalog is documented manually and becomes outdated. An active catalog is automatically populated by pipelines and tools
dbt as an entry point: for analytics teams, the dbt project (with YAML descriptions) is often the first natural catalog. dbt docs automatically generates navigable documentation with SQL lineage.
2Data lineage: tracing data from source to dashboard
Discriminating question
What is data lineage? Give a concrete example of a case where it was useful to you.
- Data lineage — complete traceability of data from its source (transactional database, API, file) to its use (dashboard, ML model, report)
- Column-level lineage — knowing exactly which source column feeds which target column, across all SQL transformations
- Use cases: impact analysis (if I change this source table, which dashboards are affected?), root cause analysis (why did this KPI change?), GDPR compliance (where is personal data?)
- Tools: DataHub, OpenLineage (open standard), dbt (model lineage), Marquez
# dbt: lineage is automatically calculated from 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 -- traced source
JOIN {{ ref('dim_customers') }} c ON o.customer_id = c.customer_id
JOIN {{ ref('dim_products') }} p ON o.product_id = p.product_id
3Data quality: measuring and monitoring
Discriminating question
What are the dimensions of data quality? How do you automatically measure them in your pipelines?
| Dimension | Definition | Test example |
|---|
| Completeness | % of non-null values | not_null on critical columns |
| Accuracy | Conformity to expected values | accepted_values, value ranges |
| Freshness | Data age relative to expectation | source_freshness in dbt |
| Uniqueness | Absence of duplicates on keys | unique on PKs |
| Consistency | Consistency between related tables | relationships test in dbt |
| Validity | Compliance with schema and formats | Schema validation, regex tests |
- dbt tests — not_null, unique, accepted_values, relationships: automated tests at each run
- Great Expectations — Python framework for complex and configurable quality rules
- Monte Carlo / Bigeye — automatic data observability, anomaly detection without predefined rules
4Master Data Management (MDM)
Discriminating question
What is Master Data Management? Give an example of a problem that MDM solves.
- MDM — management of a single, reliable reference repository for key organizational entities (customers, products, suppliers, legal entities)
- Problem solved — a customer who exists in 3 different systems with different IDs. MDM creates a unique identifier (Golden Record) that reconciles all sources
- Components: deduplication/matching, record linkage, golden record, distribution to consuming systems
- Tools: Informatica MDM, Stibo STEP, Reltio, or custom with dbt + Splink (open source probabilistic matching)
5GDPR and data compliance
Discriminating question
How do you handle the GDPR right to erasure in a data lake? What anonymization techniques do you use?
- Personal data inventory — identify and tag all columns containing personal data in the catalog
- Right to erasure — soft delete in the transactional database + propagation in the data lake (tricky because Parquet files are immutable → requires Delta Lake/Iceberg vacuuming)
- Anonymization — permanent deletion of the identifier: irreversible, data can no longer be linked to a person
- Pseudonymization — replacement of the identifier with a reversible pseudonym (tokenization): re-identification remains possible with the key
- Minimization — collect only the data strictly necessary for the purpose
- Data Classification — tag data according to sensitivity: Public, Internal, Confidential, PII, Sensitive PII
6Typical governance stack in 2025
- Catalog — DataHub (open source, LinkedIn) or OpenMetadata
- Quality — dbt tests + Great Expectations or Soda Core
- Lineage — DataHub with Airflow + dbt integration
- Observability — Monte Carlo or Metaplane (automatic anomaly detection)
- Access control — Row-Level Security in Snowflake/BigQuery + tag policy
- GDPR — Delta Lake/Iceberg for the right to erasure + encryption at rest
7Level-based grid
| Level | Expected proficiency | GO signal | NO-GO |
|---|
| Confirmed | dbt tests, basic catalog, data classification | Has implemented not_null/unique/accepted_values, has documented their dbt models | Does not know what data lineage is, has never written tests on their data |
| Senior | DataHub/OpenMetadata, Great Expectations, column-level lineage, practical GDPR | Has set up DataHub, has handled a GDPR right to erasure request, knows pseudonymization | Does not know how to handle the right to erasure in a data lake |
| Lead | Complete governance architecture, MDM, data contracts, team standards | Has defined their organization's governance strategy, has implemented data contracts | Cannot explain the difference between anonymization and pseudonymization |