Accueil›Blog›Test technique monitoring de la qualité des données en production

Guide recrutement data

Test technique monitoring de la qualité des données en production

La qualité des données en production se dégrade silencieusement. En entretien Senior, on évalue la capacité à mettre en place un monitoring proactif qui détecte les problèmes avant les utilisateurs.

Data Builder·Juin 2025·6 min de lecture·Data Engineer · Analytics Engineer

Sommaire

Pourquoi monitorer la qualité
Fraîcheur des données
Monitoring des volumes
Changements de schéma
Outils : Elementary vs Monte Carlo
Stratégie d alerting
Grille

1Pourquoi le monitoring de qualité est critique

Question discriminante

Quels sont les symptômes d un problème de qualité de données non détecté ?

Dashboard KPI erroné — le COMEX prend une décision sur un chiffre faux. Détecté 2 semaines plus tard
Modèle ML qui se dégrade — les données d entrainement ont changé de distribution, le modèle prédit n importe quoi
Pipeline silencieusement vide — une table source ne reçoit plus de données depuis 3 jours. Personne ne l a vu
Règle du 1-10-100 — corriger un problème à la source coûte 1. En production : 10. Après une décision business : 100

2Monitoring de la fraîcheur

Question discriminante

Comment alertez-vous quand une table n a pas été mise à jour dans les délais attendus ?

# dbt source freshness
sources:
  - name: transactions
    tables:
      - name: orders
        loaded_at_field: updated_at
        freshness:
          warn_after:  {count: 6,  period: hour}
          error_after: {count: 24, period: hour}

# Lancer la vérification
dbt source freshness

# Elementary (package dbt) : monitoring automatique
# elementary_freshness_anomalies detecte les pics de latence
models:
  - name: fct_orders
    tests:
      - elementary.table_anomalies:
          table_anomalies_type:
            - freshness  # alerte si la table n est plus alimentee

Source freshness dbt — vérification intégrée, alerte si loaded_at est trop ancien
Airflow SLA Miss — configurer des SLA sur les tâches critiques, alerte si dépassé

3Monitoring des volumes

Question discriminante

Comment détectez-vous qu une table a perdu 50% de ses lignes du jour au lendemain ?

# Elementary : détection d anomalies de volume
models:
  - name: fct_orders
    tests:
      - elementary.volume_anomalies:
          timestamp_column: order_date
          # alerte si le volume sort de la plage historique

# Custom : comparer avec la moyenne glissante
SELECT
    DATE(order_date) AS jour,
    COUNT(*) AS nb_commandes,
    AVG(COUNT(*)) OVER (
        ORDER BY DATE(order_date)
        ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
    ) AS moyenne_7j,
    COUNT(*) / AVG(COUNT(*)) OVER (
        ORDER BY DATE(order_date)
        ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
    ) AS ratio_vs_moyenne
FROM fct_orders
GROUP BY 1
HAVING ratio_vs_moyenne < 0.5 OR ratio_vs_moyenne > 2.0

4Détecter les changements de schéma

Question discriminante

Comment êtes-vous alerté quand une colonne est supprimée ou renommée dans une table source ?

dbt schema tests — si une colonne source est renommée, le modèle dbt staging échoue au prochain run
schema_changes_from_baseline — test dbt qui compare le schéma actuel avec le schéma attendu
DataHub notifications — alertes automatiques quand le schéma d un dataset change
Fivetran/Airbyte — les connecteurs managés détectent les breaking changes et envoient des alertes

5Elementary vs Monte Carlo vs Soda

Question discriminante

Quel outil de data observabilité choisissez-vous selon le contexte ?

Outil	Type	Forces	Idéal pour
Elementary	Package dbt open source	Intégration native dbt, gratuit, anomaly detection	Équipes dbt-first, budget serré
Monte Carlo	SaaS enterprise	Détection automatique sans règles, lineage, MTTR tracking	Grandes équipes, données critiques
Soda	Open source + Cloud	Data contracts, checks SQL flexibles	Checks sur mesure, conformité
Metaplane	SaaS	Simple, bonne UX	Équipes débutantes en observabilité

6Stratégie d alerting : éviter la fatigue

Question discriminante

Comment évitez-vous que les alertes de qualité soient ignorées ?

Priorisation — distinguer les alertes critiques (bloquant la production) des warnings (à surveiller)
Canal adapté — critique → PagerDuty + Slack #data-incidents. Warning → Slack #data-quality seulement
Runbook — chaque alerte critique a un runbook : qui prévenir, quelle action, comment vérifier
SLA de résolution — s engager sur un délai de résolution par niveau de gravité
Réduire le bruit — un taux de faux positifs > 20% tue la culture d alerte. Tuner les seuils régulièrement

import great_expectations as gx
from evidently import Report
from evidently.metric_preset import DataQualityPreset

# Great Expectations : suite de validation
context = gx.get_context()
suite = context.suites.add(gx.ExpectationSuite(name="orders_quality"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id"))
suite.add_expectation(gx.expectations.ExpectTableRowCountToBeBetween(min_value=1000, max_value=10_000_000))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(column="amount", min_value=0, max_value=100_000))

# Valider un batch de données
batch = context.data_sources.get("orders_ds").get_asset("orders").get_batch_definition("daily")
results = context.run_checkpoint(checkpoint_name="orders_checkpoint")

# Evidently : monitoring en production
report = Report(metrics=[DataQualityPreset()])
report.run(reference_data=baseline_week1, current_data=data_this_week)
report.save_html("quality_report.html")

# Alerter sur la dégradation
if report.as_dict()["metrics"][0]["result"]["missing_values_share"] > 0.05:
    send_alert(f"Taux de valeurs manquantes anormal : {missing_pct:.1%}")

Anomaly detection automatique — Elementary (dbt) et Monte Carlo détectent les anomalies statistiques (volume, fraîcheur, distribution) sans écrire de règles manuellement
SLA de données — définir formellement : fraîcheur maximale (données mises à jour toutes les 2h), taux de complétude minimum (99%), volume attendu (±20% vs semaine précédente)
Alerting actionnable — une alerte sans contexte est ignorée. Inclure : table impactée, métrique concernée, valeur attendue vs observée, lien vers le dashboard de monitoring
Lineage des incidents — quand une table est corrompue, le lineage permet d'identifier automatiquement les dashboards et modèles en aval impactés
Coût de la mauvaise qualité — calculer l'impact business des données erronées (décisions fausses, rapports incorrects) pour justifier l'investissement dans la qualité

Anomaly detection automatique - Elementary (dbt) et Monte Carlo detectent les anomalies statistiques (volume, fraicheur, distribution) sans regles manuelles
SLA de donnees - fraicheur maximale (donnees mises a jour toutes les 2h), taux de completude minimum (99%), volume attendu (+-20% vs semaine precedente)
Alerting actionnable - une alerte sans contexte est ignoree. Inclure : table impactee, metrique concernee, valeur attendue vs observee, lien vers le dashboard
Lineage des incidents - quand une table est corrompue, le lineage permet d identifier automatiquement les dashboards et modeles en aval impactes
Cout de la mauvaise qualite - calculer l impact business des donnees erronees (decisions fausses, rapports incorrects) pour justifier l investissement dans la qualite

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	dbt source freshness, tests de volume basiques	A configuré des alertes de fraîcheur, monitore les volumes	Découvre les problèmes de qualité par les utilisateurs
Senior	Anomaly detection, Elementary ou Monte Carlo, stratégie d alerting	A déployé Elementary ou Monte Carlo, a une stratégie d alerting claire	Ne sait pas ce qu est l anomaly detection pour la data

1Why data quality monitoring is critical

Discriminating question

What are the symptoms of an undetected data quality problem?

Incorrect KPI dashboard — the executive committee makes a decision based on a wrong number. Detected 2 weeks later
Degrading ML model — the training data distribution has changed, the model predicts anything
Silently empty pipeline — a source table has not received data for 3 days. Nobody noticed
1-10-100 rule — fixing a problem at the source costs 1. In production: 10. After a business decision: 100

2Freshness monitoring

Discriminating question

How do you alert when a table has not been updated within the expected timeframe?

# dbt source freshness
sources:
  - name: transactions
    tables:
      - name: orders
        loaded_at_field: updated_at
        freshness:
          warn_after:  {count: 6,  period: hour}
          error_after: {count: 24, period: hour}

# Run the check
dbt source freshness

# Elementary (dbt package) : automatic monitoring
# elementary_freshness_anomalies detects latency spikes
models:
  - name: fct_orders
    tests:
      - elementary.table_anomalies:
          table_anomalies_type:
            - freshness  # alert if the table is no longer being fed

dbt source freshness — built-in check, alerts if loaded_at is too old
Airflow SLA Miss — configure SLAs on critical tasks, alert if exceeded

3Volume monitoring

Discriminating question

How do you detect that a table has lost 50% of its rows overnight?

# Elementary : volume anomaly detection
models:
  - name: fct_orders
    tests:
      - elementary.volume_anomalies:
          timestamp_column: order_date
          # alert if volume falls outside the historical range

# Custom : compare with rolling average
SELECT
    DATE(order_date) AS day,
    COUNT(*) AS nb_orders,
    AVG(COUNT(*)) OVER (
        ORDER BY DATE(order_date)
        ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
    ) AS avg_7d,
    COUNT(*) / AVG(COUNT(*)) OVER (
        ORDER BY DATE(order_date)
        ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
    ) AS ratio_vs_avg
FROM fct_orders
GROUP BY 1
HAVING ratio_vs_moyenne < 0.5 OR ratio_vs_moyenne > 2.0

4Detecting schema changes

Discriminating question

How are you alerted when a column is dropped or renamed in a source table?

dbt schema tests — if a source column is renamed, the dbt staging model fails at the next run
schema_changes_from_baseline — dbt test that compares the current schema with the expected schema
DataHub notifications — automatic alerts when a dataset schema changes
Fivetran/Airbyte — managed connectors detect breaking changes and send alerts

5Elementary vs Monte Carlo vs Soda

Discriminating question

Which data observability tool do you choose depending on the context?

Tool	Type	Strengths	Ideal for
Elementary	Open source dbt package	Native dbt integration, free, anomaly detection	dbt-first teams, tight budget
Monte Carlo	Enterprise SaaS	Automatic detection without rules, lineage, MTTR tracking	Large teams, critical data
Soda	Open source + Cloud	Data contracts, flexible SQL checks	Custom checks, compliance
Metaplane	SaaS	Simple, good UX	Teams new to observability

6Alerting strategy: avoiding alert fatigue

Discriminating question

How do you prevent quality alerts from being ignored?

Prioritization — distinguish critical alerts (blocking production) from warnings (to monitor)
Appropriate channel — critical → PagerDuty + Slack #data-incidents. Warning → Slack #data-quality only
Runbook — each critical alert has a runbook: who to notify, what action to take, how to verify
Resolution SLA — commit to a resolution timeframe by severity level
Reduce noise — a false positive rate > 20% kills alert culture. Tune thresholds regularly

import great_expectations as gx
from evidently import Report
from evidently.metric_preset import DataQualityPreset

# Great Expectations : validation suite
context = gx.get_context()
suite = context.suites.add(gx.ExpectationSuite(name="orders_quality"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id"))
suite.add_expectation(gx.expectations.ExpectTableRowCountToBeBetween(min_value=1000, max_value=10_000_000))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(column="amount


Vous recrutez un Data Engineer ou Analytics Engineer ?
Premier entretien gratuit. Rapport GO/NO-GO sous 48h.
Tester gratuitementReserver un appel