Qualité des données : quels indicateurs suivre et comment agir ?

Commencer par les erreurs qui changent une décision

Un numéro de téléphone absent peut bloquer une opération commerciale mais ne pas gêner un calcul agrégé de marge. Une date de vente fausse peut avoir l’effet inverse. La priorité dépend donc du consommateur et de ce qu’il fait avec la donnée.

Pour chaque usage, notez les champs nécessaires, les erreurs possibles et leur conséquence. Cette cartographie permet de choisir les règles utiles. Une longue liste de tests sans impact identifié mobilise l’équipe sans garantir que les vrais risques sont surveillés.

Référence technique : IBM : observabilité des données

Des indicateurs simples avec leur dénominateur

Affichez la période et le périmètre avec le score. Un taux de complétude de 99 % ne dit pas si les lignes absentes concernent une agence entière. Découpez les contrôles selon les segments qui changent la décision, sans multiplier des indicateurs que personne ne consultera.

Exemple SQL pour repérer des clés répétées

Dans cet exemple fictif, une ligne doit correspondre à une commande et commande_id doit être unique. Si la table contient des versions historiques ou des lignes de détail, cette règle est inadaptée. Vérifiez le grain avant d’interpréter le résultat.

SELECT commande_id, COUNT(*) AS nombre_lignes
FROM commandes
GROUP BY commande_id
HAVING COUNT(*) > 1;

Mesurer la fraîcheur avec la bonne horloge

La dernière exécution réussie ne prouve pas que les données métier sont récentes. Un pipeline peut relire sans erreur un fichier ancien. Suivez séparément la date d’événement, la date d’arrivée et la date de traitement quand ces notions sont disponibles.

Définissez une attente adaptée à la source. Un flux mensuel ne doit pas déclencher la même alerte qu’un flux opérationnel fréquent. Vérifiez aussi les fuseaux et les jours sans activité attendue. Sinon, le système enverra des alertes inutiles que l’équipe finira par ignorer.

D’un test en échec à une correction durable

Une alerte doit indiquer le jeu concerné, la règle, un échantillon autorisé et l’impact probable. Déterminez si le produit de données doit être bloqué, signalé comme incomplet ou maintenu sous exception. Les décisions doivent être connues du consommateur.

Corrigez la cause au bon endroit. Une règle de mapping peut être fausse dans la préparation, un identifiant peut manquer dans l’application source. Masquer l’anomalie dans un rapport ne résout pas les autres usages. Conservez le test qui reproduit le problème et vérifiez sa disparition après correction.

Référence technique : dbt : tests de données

Un tableau de suivi qui reste exploitable

Pour attribuer ces responsabilités, consultez le guide gouvernance des données. Nos pages Data Engineering et gouvernance Data complètent la mise en œuvre.

1. Sélectionner les règles qui couvrent les risques prioritaires.
2. Écrire le grain, le périmètre et le dénominateur.
3. Fixer les attentes et niveaux d’alerte avec les utilisateurs.
4. Nommer le responsable de diagnostic et de correction.
5. Revoir les alertes ignorées et les incidents non détectés.