Data observability : détecter les pipelines silencieusement cassés

Une métrique exécutive qui dérive de 12 % pendant trois semaines. Un dashboard finance qui affiche zéro un lundi matin. Un modèle ML scoring sur des données partiellement fraîches. Ces incidents ont un point commun : aucune alerte ne s'est déclenchée car le pipeline n'a pas planté — il a juste produit le mauvais résultat. La data observability apporte au monde data ce que le monitoring APM a apporté au monde applicatif : voir ce qui tourne, mesurer, alerter avant que les métiers s'en aperçoivent.

Data observability vs data quality

Dimension	Data quality	Data observability
Approche	Règles définies à l'avance	Détection de signaux + règles
Périmètre	Tests par dataset	Pipeline end-to-end + métadonnées
Détection	Erreurs prévues	Erreurs prévues + anomalies
Outils typiques	Great Expectations, dbt tests, Soda	Monte Carlo, Bigeye, Metaplane, Elementary
Couche	Tests data	Tests + ML + lineage + alerting

Les deux se complètent : qualité = règles connues, observability = capacité à détecter ce qu'on n'avait pas prévu.

Les 5 piliers de la data observability

Inspirés du SRE applicatif, ils sont devenus le standard :

1. Freshness

Le dataset est-il à jour ? Quand a-t-il été mis à jour pour la dernière fois ? Est-on dans le SLA (par exemple : "rafraîchi toutes les 4 h ouvrées") ?

2. Volume

Nombre de lignes reçues par run. Une chute (ou un pic) brutale doit déclencher une alerte (ex : -80 % vs moyenne 30 jours).

3. Schema

Les colonnes attendues sont-elles toutes là ? Le type a-t-il changé ? Un champ est-il devenu massivement null ?

4. Distribution

Statistiques métier : moyennes, percentiles, valeurs uniques, ratio nulls par colonne. Une dérive vs baseline historique = signal d'incident.

5. Lineage

Quels datasets sont consommés par quoi ? Quand un pipeline casse, qui est impacté ? L'observability moderne calcule automatiquement le lineage depuis le SQL des transformations.

Voir Data catalog moderne & lineage.

Cartographie des outils

Outil	Positionnement	Forces
Monte Carlo	Plateforme observability complète	Détection ML d'anomalies, lineage, incident workflow
Bigeye	Observability SaaS, focus métriques	Couverture large, autonomie
Metaplane	Observability pragmatique	Time-to-value rapide, UX
Elementary	OSS + Cloud, dbt-native	Intégration dbt forte, accessible
Soda	Data quality + observability	YAML déclaratif, OSS Core + Cloud
Great Expectations	Data quality framework	Très complet, fortement adopté
DataHub / OpenMetadata	Catalog + observability légère	Open source, lineage
dbt tests + Elementary	Tests intégrés à la transformation	Démarrage immédiat sur projet dbt

Stratégie : data SLAs et incident management

Définir des Data SLAs

Pour chaque data product critique, formaliser :

• Fraîcheur : "données disponibles à J+1 6h du matin".
• Complétude : "≥ 99,5 % de lignes attendues".
• Disponibilité : "table interrogeable 99,9 % du mois".
• Latence end-to-end : depuis l'événement source jusqu'au dashboard.

Mesurer en continu

• Sondes automatiques par pipeline.
• Tableau de bord SLA visible par les consommateurs.
• Reporting mensuel des SLO atteints / manqués.

Incident management data

Calquer le runbook sur les pratiques SRE :

1. Détection automatique → alerte.
2. Triage : criticité, périmètre impacté (via lineage).
3. Communication aux consommateurs.
4. Mitigation : pause de pipelines downstream, rollback, recalcul.
5. Résolution + post-mortem.
6. Apprentissage : ajout d'un test ou d'une métrique pour éviter la récidive.

Anti-patterns courants

• Tout instrumenter dès le départ : on noie l'équipe d'alertes. Commencer par les datasets critiques.
• Alertes sans owner : si personne n'est responsable, personne n'agit.
• Pas de Data SLAs partagés : l'équipe data détecte, mais le métier ne sait pas qu'il y a un incident.
• Confondre test et monitoring : un test passe ou échoue, un monitoring suit une métrique dans le temps.
• Ignorer le lineage : sans lui, impossible d'évaluer l'impact d'une panne.
• Ne jamais faire de post-mortem : l'observability devient un outil sans culture.

Démarche d'adoption

Étape 1 : inventaire

Lister les 20-30 datasets critiques (finance, conformité, ML, exec dashboards). Identifier owner + consommateurs.

Étape 2 : SLAs

Pour ces datasets, définir freshness / volume / qualité minimale.

Étape 3 : tests + monitoring

• Tests dbt + Great Expectations / Soda.
• Métriques observability (freshness, volume, distribution) avec seuils dynamiques.

Étape 4 : alerting + lineage

• Routage alertes Slack / Teams / PagerDuty avec owner clair.
• Lineage automatique pour évaluer l'impact.

Étape 5 : extension progressive

Ajouter les datasets suivants par vagues. Capitaliser sur les patterns.

Coûts et organisation

• Outils SaaS (Monte Carlo, Bigeye) : licences à 4-6 chiffres / an pour un mid-market.
• Stack open source (Elementary OSS + Soda Core + DataHub + dbt tests) : coût licence nul mais investissement humain.
• Profils impliqués : data engineers, analytics engineers, SRE data, data steward, data product manager.

Voir FinOps de la donnée.

Conclusion : sans observability, la donnée n'est pas un produit

Tant qu'on ne mesure pas la santé de ses datasets, on ne peut pas s'engager dessus. Et tant qu'on ne s'engage pas, les métiers ne font pas confiance — et reviennent vers leurs fichiers Excel. La data observability est la condition technique de la confiance dans la donnée. Elle est aussi le pilier qui rend possible un Data Mesh, des Data Contracts, et une vraie culture data-driven.

Pour aller plus loin :

• Data Contracts
• Data Mesh en pratique
• Data catalog moderne & lineage
• dbt & analytics engineering

ForTeam IT positionne des data engineers, analytics engineers et SRE data capables de poser une stack observability complète, des Data SLAs aux post-mortems. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT