KPIs de qualité des données depuis Elementary

Les résultats bruts des tests vous disent ce qui a réussi et ce qui a échoué. Les KPIs transforment cela en métriques qui signifient quelque chose dans le temps — des chiffres que vous pouvez suivre semaine après semaine, rapporter aux parties prenantes, et utiliser pour décider où investir dans le travail de qualité des données.

Elementary stocke tout ce dont vous avez besoin dans elementary_test_results, dbt_run_results et dbt_models. Ces cinq KPIs couvrent les dimensions les plus importantes de la santé de la qualité des données.

Taux de réussite des tests

La métrique la plus simple et la plus importante : quel pourcentage de tests réussit ?

taux_de_reussite = tests_passes / total_tests * 100

Suivez cela quotidiennement. Une tendance à la baisse signale des problèmes croissants même si aucune alerte critique n’a encore été déclenchée. Un taux de réussite à 100 % stable depuis des semaines peut signifier que vos tests sont suffisamment stricts pour être fiables — ou que vos tests ne capturent rien de réel. Le contexte importe.

La métrique est la plus utile comme tendance plutôt que comme nombre absolu. Un projet à 80 % de taux de réussite en progression est plus sain qu’un projet à 95 % en régression. Une chute soudaine de 98 % à 85 % mérite une attention immédiate quel que soit le niveau absolu.

Conformité des SLAs de fraîcheur des données

Quel pourcentage de vos sources de données respecte ses exigences de fraîcheur ?

Cela nécessite d’abord de définir des SLAs. Taguez les tables avec leur fréquence de mise à jour attendue, puis mesurez la conformité par rapport à ces attentes :

SELECT
  COUNT(CASE WHEN status = 'pass' THEN 1 END) * 100.0 / COUNT(*) AS sla_compliance
FROM elementary_test_results
WHERE test_type = 'freshness_anomalies'
  AND detected_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY);

Sans définitions explicites de SLA, la conformité de fraîcheur n’a pas de sens — vous mesurez par rapport à des seuils qui ont peut-être été fixés arbitrairement plutôt qu’en fonction d’engagements réels avec les parties prenantes. La métrique n’est valable qu’autant que les accords sous-jacents.

Taux de réussite des modèles

Quel pourcentage des exécutions de modèles se termine avec succès ?

taux_de_succes = executions_reussies / total_executions * 100

Suivez cela séparément du taux de réussite des tests. Un modèle peut s’exécuter avec succès et échouer aux tests (le SQL s’est exécuté correctement mais a produit des données qui violent vos règles de qualité). Un modèle peut aussi ne pas s’exécuter du tout (une dépendance a échoué, un schéma a changé). Ce sont des modes de défaillance différents qui nécessitent des réponses différentes.

Un taux de réussite des modèles qui chute sous 100 % signale des problèmes d’exécution — dépendances cassées, problèmes de timeout, erreurs de permission. Un taux de réussite des tests qui chute tandis que le taux de réussite des modèles reste élevé signale des problèmes de qualité des données dans la logique de transformation ou les sources en amont.

Taux de détection des anomalies

Combien d’anomalies Elementary détecte-t-il par jour ou par semaine ?

Cette métrique est plus utile comme tendance que comme nombre absolu. Un pic soudain pointe souvent vers des problèmes de données en amont — une source qui a changé son schéma, un pipeline qui a commencé à envoyer des données malformées, un événement métier qui a modifié les patterns attendus. Un zéro plat sur plusieurs semaines mérite également investigation : soit vos données sont réellement propres et stables, soit la sensibilité de détection des anomalies est trop faible, soit vous ne surveillez pas les bonnes colonnes.

Aucun extrême n’est intrinsèquement bon ou mauvais. L’objectif est de comprendre à quoi ressemble la « normale » pour votre système et de remarquer quand cela change.

Couverture des tests

Quel pourcentage de vos modèles dispose d’au moins un test ?

SELECT
  COUNT(DISTINCT CASE WHEN has_tests THEN model_name END) * 100.0 /
  COUNT(DISTINCT model_name) AS coverage
FROM (
  SELECT
    m.name AS model_name,
    EXISTS (
      SELECT 1 FROM elementary_test_results t
      WHERE t.model_unique_id = m.unique_id
    ) AS has_tests
  FROM dbt_models m
  WHERE m.resource_type = 'model'
);

La couverture vous indique où se trouvent les angles morts. Un modèle sans aucun test est un modèle où les problèmes passent inaperçus. Une faible couverture sur les modèles marts qui alimentent les dashboards est plus préoccupante qu’une faible couverture sur les modèles intermédiaires utilisés uniquement pour la transformation.

La couverture comme KPI crée la bonne incitation : les équipes qui la suivent ont tendance à ajouter des tests aux modèles nouvellement construits plutôt que de traiter les tests comme quelque chose à ajouter plus tard. « Plus tard » arrive rarement.

Correspondance avec les dimensions standard de la qualité des données

Ces KPIs correspondent aux dimensions standard de la qualité des données qui apparaissent dans les frameworks de gouvernance et les conversations avec les parties prenantes :

Lorsque vous reportez aux parties prenantes qui utilisent ce vocabulaire, formuler le taux de réussite et la couverture en termes de ces dimensions rend les métriques plus lisibles. Plutôt que « notre taux de réussite des tests est de 94 % », vous pouvez dire « nos vérifications de complétude et d’unicité réussissent à 98 %, et notre conformité à l’actualité est de 87 % par rapport aux SLAs. » C’est une conversation plus utile.