Un incident de données peut arriver, ne pas y être préparé est un choix

Début février, un service financier en ligne a connu une panne sévère : pendant plusieurs heures, des milliers d’utilisateurs ont vu des soldes de compte incorrects. La cause ? Un job ETL silencieusement défaillant qui a corrompu une table de production critique. Cet incident n’est pas un cas isolé ; c’est le symptôme d’une approche réactive de la qualité des données. Attendre que les utilisateurs signalent un problème est la pire des stratégies. La solution est proactive : définir des niveaux de service (SLO) sur vos données les plus importantes pour détecter les anomalies avant qu’elles n’atteignent l’utilisateur.

anatomie d’un incident silencieux

La plupart des incidents de données ne sont pas des pannes franches, mais des dégradations silencieuses.

la réponse: les slo de données

Un SLO (Service Level Objective) est un objectif mesurable pour la fiabilité de vos données. C’est un contrat de confiance entre le producteur de la donnée et ses consommateurs.

Fraîcheur: La donnée a-t-elle été mise à jour à temps ? (ex: max_delay < 1 hour)
Complétude: Le volume de données est-il conforme aux attentes ? (ex: row_count > 95% of 7-day average)
Validité: Les valeurs sont-elles dans les bornes attendues ? (ex: null_percentage < 1%)

mettre en place des slo en 3 étapes

étape 1: identifier les données critiques

Ne mettez pas des SLO partout. Commencez par les 10 à 20 tables ou vues qui alimentent vos applications et dashboards les plus importants. Pour chacune, nommez un propriétaire.

étape 2: définir des seuils pragmatiques

Les seuils ne doivent pas être arbitraires. Basez-les sur l’historique et les besoins métier.

# slo/metrics/daily_revenue.yml
dataset_id: metrics.daily_revenue
owner: "@team-finance"
slos:
  # La fraîcheur est critique pour le reporting journalier
  freshness_max_hours: 24
  # Une chute de plus de 50% du revenu est suspecte
  daily_change_pct_min: -50
  # Une ligne par jour, pas de trou
  completeness_expected_rows: 1

étape 3: automatiser les tests et les alertes

Intégrez vos tests de SLO directement dans votre orchestrateur (dbt, Airflow, etc.). Un test qui échoue doit bloquer le pipeline et envoyer une alerte claire au propriétaire.

-- Test de fraîcheur simple pour dbt
-- test/freshness_daily_revenue.sql
SELECT
    *
FROM
    {{ ref('daily_revenue') }}
WHERE
    report_date < CURRENT_DATE - INTERVAL '24 hour'

l’incident comme opportunité

Chaque incident est une leçon. Un post-mortem n’est pas là pour trouver un coupable, mais pour identifier une cause racine et mettre en place une action préventive.

Résumé: Qu’est-ce qui s’est passé ? Quel a été l’impact client ?
Détection: Comment avons-nous détecté le problème ? Aurions-nous pu le voir plus tôt ?
Cause racine: Quelle est la défaillance technique ou de processus qui a permis à l’incident de se produire ?
Actions correctives: Quelle nouvelle vérification (SLO) ou quel changement de processus allons-nous mettre en place pour que cela ne se reproduise plus ? Chaque action doit avoir un propriétaire et une date.

erreurs à éviter

L’usine à gaz de dashboards: Avoir 50 dashboards de monitoring que personne ne regarde. Mieux vaut 3 alertes ciblées qui arrivent dans le bon canal Slack.
Les seuils trop stricts: Des alertes qui se déclenchent tout le temps finissent par être ignorées. Commencez avec des seuils larges et affinez-les avec le temps.
L’absence de propriétaire: Une alerte sans propriétaire est une alerte qui sera ignorée. Chaque SLO doit être associé à une équipe.

faq

Quelle est la différence entre un slo et un sla ? Le SLO (Objective) est la cible technique interne (ex: “le taux d’erreur doit être < 0.1%”). Le SLA (Agreement) est l’engagement contractuel externe envers un client, qui inclut souvent des pénalités. On se fixe des SLO plus stricts que les SLA pour avoir une marge de manœuvre.
Par où commencer si je n’ai aucun test de qualité ? Commencez par le plus simple : un test de fraîcheur sur votre table la plus importante. Prenez votre dashboard principal et demandez-vous “quelle est l’âge maximum acceptable pour cette donnée ?”. Implémentez ce simple test.
Comment convaincre mon management d’investir dans la qualité des données ? Utilisez le langage du risque et du coût. Calculez le coût d’un incident passé (temps de résolution, perte de confiance, impact business). Montrez que l’investissement dans des SLO est une assurance peu coûteuse contre des problèmes bien plus graves.

Menu