Un tableau de bord peut être techniquement disponible et pourtant raconter une histoire fausse. Une colonne qui change de sens, un lot reçu deux fois ou un identifiant absent suffisent à produire des chiffres crédibles en apparence. Le contrôle qualité des données consiste à rendre ces défauts visibles assez tôt pour que les utilisateurs puissent décider sur une base fiable. Il ne se résume ni à supprimer les lignes incomplètes ni à installer un outil de validation.
Ce guide suit un pipeline de la source à la publication. Il explique comment choisir des règles utiles, mesurer les écarts, traiter les incidents et faire évoluer les contrôles sans bloquer toute la chaîne. Les exemples sont pédagogiques : ils décrivent une méthode de travail, pas des résultats observés chez un client. Pour situer cette démarche dans l’architecture globale, lire aussi les principes des pipelines ETL et ELT.
Qu’appelle-t-on une donnée de qualité ?
La qualité ne désigne pas une propriété absolue du fichier. Elle dépend de l’usage et du moment. Une adresse postale sans numéro peut convenir à une analyse par ville et être inutilisable pour une livraison. Un montant exprimé en centimes est correct si son unité est documentée ; le même montant interprété comme des euros devient une erreur grave. Avant de définir un seuil, il faut donc écrire qui utilise la donnée, pour quelle décision et avec quelle tolérance à l’incertitude.
Les dimensions souvent examinées sont la complétude, l’unicité, la validité, la cohérence, l’exactitude et la fraîcheur. Elles se recoupent parfois, mais répondent à des questions distinctes. La validité vérifie par exemple qu’une date suit un format accepté ; l’exactitude demande si cette date correspond à l’événement réel. Cette dernière est souvent impossible à établir automatiquement sans source de référence. Un pipeline peut détecter qu’un code postal a cinq chiffres sans prouver que l’adresse existe.
Définissez chaque dimension avec une règle testable et une conséquence opérationnelle. « Les données doivent être propres » ne guide personne. « Chaque facture publiée doit posséder un identifiant non vide et unique dans son périmètre » permet une vérification et une action. Une règle doit aussi préciser le périmètre : une table entière, un lot, une période ou un groupe métier. Sans ce contexte, un taux global peut masquer des défauts concentrés sur un segment.
Cartographier les données avant de tester
Commencez par dessiner le trajet réel des données : système source, extraction, stockage brut, transformations, tables de service et rapports. Pour chaque étape, notez le propriétaire, la fréquence, la clé métier, les transformations principales et les consommateurs. Cette carte aide à placer le contrôle au bon endroit. Une règle de schéma s’applique dès l’ingestion ; une règle sur un total agrégé s’évalue après la transformation qui le produit.
Le lignage n’a pas besoin d’être parfait pour être utile. Une fiche simple reliant la métrique « chiffre d’affaires encaissé » aux tables et filtres qui la produisent vaut mieux qu’un diagramme sophistiqué jamais mis à jour. Quand un indicateur diverge, cette fiche réduit le temps passé à chercher où l’écart est apparu. Elle évite aussi de corriger une table aval alors que la source a changé de convention.
Documentez les zones grises. Un champ peut être renseigné uniquement pour certains pays, une mise à jour peut arriver avec deux jours de retard, et un statut peut rester provisoire jusqu’à validation. Ces comportements ne sont pas nécessairement des erreurs. Ils deviennent problématiques lorsqu’ils ne sont pas connus des personnes qui construisent les règles ou lisent les résultats. La cartographie doit donc contenir les exceptions métier importantes, avec une personne capable de les confirmer.
Choisir les premiers contrôles selon le risque
Une première version efficace couvre peu de règles, mais protège les décisions les plus sensibles. Classez les jeux de données selon leur exposition : nombre d’utilisateurs, impact d’une erreur, fréquence de changement et difficulté à réparer. Une table de référence utilisée par vingt rapports mérite souvent plus d’attention qu’une extraction ponctuelle. La priorité vient de la conséquence d’une erreur, pas seulement du volume de lignes.
Pour chaque jeu prioritaire, commencez par la structure, les clés, les valeurs obligatoires et la fraîcheur. Ajoutez ensuite les contraintes métier : montant non négatif lorsque cela a un sens, statut appartenant à une liste documentée, date de fin postérieure à la date de début. Un contrôle peut comparer des totaux entre deux étapes, mais il faut prendre en compte les exclusions et corrections légitimes. Le résultat attendu est un intervalle justifié, pas forcément une égalité parfaite.
Rédigez une fiche par règle : son intention, sa requête ou son calcul, son propriétaire, son seuil, sa sévérité et la marche à suivre en cas d’échec. Cette fiche prévient une situation fréquente : une alerte existe, personne ne sait si elle impose un arrêt. Elle sert aussi pendant les revues de changement. Si le métier modifie la définition d’un client actif, on peut repérer les contrôles à adapter avant le prochain chargement.
Valider le schéma sans figer les évolutions
Un schéma définit les colonnes, les types et parfois les contraintes de présence. Le valider à l’entrée du pipeline permet de détecter rapidement une colonne disparue ou un type inattendu. Mais un contrôle trop strict peut bloquer un ajout compatible, comme une colonne facultative qui n’affecte pas les traitements existants. La politique doit distinguer un changement cassant d’une extension tolérée.
Versionnez les contrats de données avec le code qui les consomme. Une modification de nom, de type, d’unité ou de définition métier doit être annoncée comme un changement de contrat. Une colonne prix qui passe d’euros à centimes sans changer de nom est plus dangereuse qu’une colonne renommée : les requêtes peuvent continuer à fonctionner tout en produisant des valeurs fausses. Incluez les unités, le fuseau horaire et la signification des valeurs nulles dans la documentation.
Testez les changements avec des échantillons représentatifs et des cas limites connus. Un fichier de démonstration avec dix lignes parfaites ne révèle pas toujours les accents, les dates ambiguës, les montants négatifs ou les doublons présents en production. Conservez quelques cas de référence anonymisés ou synthétiques et ajoutez un cas dès qu’un incident nouveau apparaît. Cela transforme un incident en protection durable sans supposer qu’un schéma stable garantit la qualité de son contenu.
Contrôler les doublons et les identifiants
L’unicité semble simple, mais il faut d’abord définir ce qui identifie réellement une entité. Une ligne de commande peut partager son numéro de commande avec d’autres lignes ; sa clé peut combiner commande et position. Un événement peut avoir le même horodatage qu’un autre. Si l’on choisit la mauvaise clé, on supprime des informations valides ou on laisse passer des doublons. Validez cette définition avec les personnes qui produisent et utilisent les données.
Dans une ingestion répétée, distinguez le doublon technique du nouvel état d’un objet. Recevoir deux fois le même événement avec le même identifiant et le même contenu suggère une répétition à dédupliquer. Recevoir le même identifiant avec un statut plus récent peut être une mise à jour légitime. Le pipeline doit expliciter sa règle de résolution : version, date de modification, priorité de source ou quarantaine en cas de conflit.
Mesurez les doublons avant de les supprimer. Leur taux par source et par jour peut révéler une panne de transmission ou une erreur de pagination. Une suppression silencieuse rend le tableau de bord plus propre, mais cache l’état du système amont. Conservez un journal des lignes rejetées ou fusionnées, avec la raison et le lot d’origine. Cette traçabilité facilite les reprises et les discussions avec le fournisseur de données.
Gérer les valeurs manquantes et aberrantes
Une valeur nulle peut vouloir dire « non collectée », « non applicable », « inconnue » ou « effacée ». Ces situations n’appellent pas la même correction. Un pays absent dans une commande internationale peut être bloquant ; un second prénom absent ne l’est généralement pas. Une règle de complétude doit donc citer le champ, le contexte et le niveau minimal acceptable, plutôt que d’exiger 100 % sur toutes les colonnes.
Suivez les taux de valeurs manquantes dans le temps et par segment. Un taux global stable peut masquer une dégradation soudaine chez un partenaire si le reste des données augmente. Pour les variables utilisées en machine learning, les fuites de données ajoutent un autre risque : une méthode d’imputation calculée sur l’ensemble complet peut contaminer l’évaluation. La correction doit respecter le moment où l’information était disponible.
Les valeurs aberrantes demandent un examen similaire. Un montant très élevé n’est pas forcément faux ; il peut correspondre à un client exceptionnel. Évitez les suppressions automatiques fondées uniquement sur un seuil statistique. Comparez les distributions, les unités et les événements métier. Si une règle bloque les données, prévoyez un circuit de revue et une manière de réintégrer les observations valides. Une anomalie signalée est une question à instruire, pas une preuve immédiate d’erreur.
Surveiller la fraîcheur et les volumes
La fraîcheur répond à une question simple : les données sont-elles assez récentes pour l’usage prévu ? Le délai acceptable dépend du rapport. Une analyse mensuelle peut tolérer un jour de retard ; un écran opérationnel peut exiger une actualisation bien plus fréquente. Notez l’heure attendue, la plage de tolérance et le calendrier des jours non ouvrés. Une alerte déclenchée chaque dimanche sans conséquence réelle finit par être ignorée.
Surveillez à la fois l’heure du dernier chargement réussi et l’heure des événements contenus dans le lot. Un job peut s’exécuter normalement tout en important un ancien fichier. À l’inverse, un lot tardif peut contenir des événements récents. Cette distinction évite de confondre la santé technique du pipeline avec l’utilité de la donnée publiée. Ajoutez le nombre de lignes et, si pertinent, le nombre d’entités distinctes pour mieux interpréter un retard.
Les contrôles de volume doivent intégrer la saisonnalité. Une baisse le week-end ou pendant des vacances peut être normale. Comparez des périodes semblables et documentez les campagnes exceptionnelles. Un seuil fixe est une première protection, mais pas une vérité universelle. Quand le volume sort de sa plage, vérifiez d’abord les sources, les filtres et les changements de définition avant de modifier le seuil pour faire disparaître l’alerte.
Placer les contrôles aux bons endroits
Il est utile de contrôler à plusieurs niveaux, car les erreurs n’apparaissent pas toutes à la source. À l’ingestion, vérifiez le format, le schéma et l’identité du lot. Dans la zone brute, conservez la possibilité de rejouer l’import et de comparer avec la source. Après transformation, testez les règles métier et les jointures. Avant publication, vérifiez les métriques que les consommateurs verront réellement. Cette répartition réduit le temps nécessaire pour localiser un défaut.
Pour un pipeline en lots, attachez chaque résultat de validation à l’identifiant du lot. Pour un flux continu, définissez des fenêtres et acceptez explicitement les arrivées tardives. Un contrôle sans référence temporelle peut comparer des ensembles incomplets et signaler de faux incidents. Le choix de la fenêtre doit refléter le comportement de la source, pas seulement la commodité du moteur de calcul.
Ne laissez pas le mécanisme de contrôle devenir le seul point de défaillance. Un service de validation indisponible doit produire un état visible : échec, contrôle non exécuté ou publication dégradée selon le risque. « Aucun problème détecté » et « aucun test exécuté » sont deux états très différents. Les architectures modernes de Data Engineering gagnent à porter cette distinction jusque dans les métadonnées des tables servies.
Définir une politique d’échec et de quarantaine
Toutes les anomalies ne justifient pas l’arrêt d’un pipeline. Un identifiant de facture manquant dans une table comptable peut bloquer la publication. Une variation modérée d’un champ facultatif peut seulement ouvrir une enquête. Définissez au moins trois niveaux : bloquant, avertissement et observation. Associez chaque niveau à une action, un délai et une personne responsable. Les seuils doivent être revus quand l’usage change.
La quarantaine permet d’isoler les enregistrements suspects sans perdre leur trace. Conservez la donnée originale, le motif du rejet, la version de la règle et la date de traitement. Évitez de transformer la quarantaine en oubli permanent : suivez son volume et décidez comment corriger, ignorer avec justification ou réintégrer. Une correction amont est préférable quand la même erreur revient, car chaque contournement local augmente la complexité.
Prévoyez aussi la reprise après incident. Si un chargement erroné a déjà alimenté un rapport, identifier le lot ne suffit pas. Il faut savoir quels indicateurs ont été touchés, quelle période recalculer et comment informer les utilisateurs. Une procédure écrite et testée sur un cas simple coûte moins cher qu’une improvisation au moment où plusieurs équipes attendent des chiffres fiables.
Mesurer la qualité sans fabriquer un score trompeur
Un « score de qualité » unique peut aider à suivre une tendance, mais il peut aussi masquer un défaut critique. Une table avec 99 % de lignes valides peut être inutilisable si le 1 % restant contient toutes les transactions importantes. Présentez les résultats par règle, par segment et dans le temps. Montrez le dénominateur : 50 valeurs manquantes sur 100 lignes n’ont pas le même sens que 50 sur un million.
Choisissez des indicateurs qui déclenchent une action. Taux de clés absentes, âge du dernier événement, écart de total entre deux étapes et volume de quarantaine sont souvent plus utiles qu’une note composite arbitraire. Liez chaque métrique à sa définition. Une hausse peut venir d’un problème réel ou d’un changement de périmètre ; sans historique de version, l’interprétation devient difficile.
Une revue régulière doit examiner aussi les alertes inutiles. Si une règle signale toujours un comportement normal, améliorez sa définition au lieu de demander aux équipes de l’ignorer. Si un incident important n’a déclenché aucune alerte, ajoutez le contrôle qui aurait permis de le détecter. Le système de qualité progresse ainsi à partir des défauts observés, avec une documentation qui explique les choix.
Organiser la responsabilité entre équipes
Le Data Engineering peut automatiser les validations, mais il ne peut pas décider seul de la signification d’un client actif ou d’une facture annulée. Désignez un responsable métier pour les définitions et un responsable technique pour le pipeline. Les deux doivent savoir où voir les résultats et comment contester une règle. Sans cette répartition, les contrôles deviennent une collection de requêtes que personne n’ose modifier.
Lors d’un changement de source, demandez une note courte : champs concernés, nouvelles valeurs possibles, date d’effet, compatibilité et tests attendus. Cette routine évite qu’un changement parfaitement légitime soit découvert comme une panne le lendemain. Elle aide également les consommateurs à adapter leurs requêtes. Le contrat de données n’est pas un document signé une fois ; c’est une conversation versionnée autour de ce que les données signifient.
Si plusieurs équipes utilisent une même table, publiez ses limites connues. Une donnée peut être assez fiable pour une tendance trimestrielle et insuffisante pour une décision individuelle. La transparence permet un choix éclairé et empêche qu’un indicateur soit réutilisé hors de son contexte. Pour approfondir le rôle des composants techniques, voir la stack du Data Engineering.
Une méthode de déploiement en quatre étapes
Première étape : choisissez un jeu critique et écrivez sa fiche d’usage. Identifiez les décisions qui en dépendent, les colonnes essentielles et les propriétaires. Mesurez la situation actuelle avant de fixer des seuils. Une ligne de base aide à distinguer un défaut ancien d’un nouveau changement. Elle ne doit pas servir à normaliser un problème grave sous prétexte qu’il existe depuis longtemps.
Deuxième étape : implémentez quelques règles simples, testées sur des données valides et invalides. Vérifiez que les résultats sont associés à un lot et qu’un échec est visible. Troisième étape : convenez des réactions avec les utilisateurs, notamment des cas qui bloquent la publication. Quatrième étape : organisez une revue après quelques cycles pour examiner les faux positifs, les incidents manqués et le coût d’exécution des tests.
Étendez ensuite la couverture de proche en proche. Une règle utile et maintenue apporte plus qu’une centaine de contrôles sans responsable. Les bibliothèques spécialisées peuvent aider à déclarer et exécuter ces tests ; la documentation de Great Expectations sur les usages de la qualité donne des exemples de dimensions surveillées. Le choix d’un outil vient après la définition des contrats, des seuils et des actions.
Questions fréquentes
Faut-il bloquer tous les lots imparfaits ?
Non. Une règle bloquante doit protéger un usage dont l’erreur aurait une conséquence claire. Les autres anomalies peuvent produire une alerte, une quarantaine ciblée ou une mention de qualité dégradée. Le choix doit être documenté et connu des personnes qui consultent les données.
Un pipeline exécuté sans erreur garantit-il des données fiables ?
Non. L’exécution vérifie que les traitements ont tourné, pas que les valeurs ont le bon sens. Un changement d’unité ou une source qui renvoie un ancien fichier peut laisser tous les jobs au vert. Il faut vérifier le contenu, la fraîcheur et les règles métier.
À quelle fréquence revoir les contrôles ?
Après un incident, un changement de source ou un nouvel usage, puis à une cadence adaptée au rythme des évolutions. La question importante est de savoir si chaque règle détecte encore un défaut pertinent et si son seuil conduit à une action utile.
La qualité des données devient robuste lorsqu’elle fait partie du travail quotidien : définitions vérifiables, résultats visibles, responsables identifiés et procédure de correction. Elle protège les tableaux de bord, mais aussi les jeux utilisés pour surveiller la dérive d’un modèle. Une donnée fiable est une donnée dont les limites sont connues et dont les défauts peuvent être corrigés.