Data Validation : règles, vérifications et surveillance continue de la qualité des données

Que se passe-t-il si un ensemble de données respecte une définition de validité sur le papier, mais que personne ne teste la règle avant que les données n'atteignent un tableau de bord, un modèle ou un rapport réglementaire ? La Data Validation est le processus opérationnel consistant à appliquer des règles, des contraintes, des formats, des domaines et des conditions métier définis afin de déterminer si les données répondent à des exigences spécifiées. Elle transforme une attente de qualité abstraite en un test explicite qui peut réussir, échouer, avertir, rejeter ou mettre en quarantaine un enregistrement.

La validité des données est une dimension de la qualité des données. La Data Validation est le processus utilisé pour tester cette dimension par rapport à des exigences définies.

Cette distinction est importante. La qualité des données décrit si les données sont adaptées à l'usage auquel elles sont destinées, tandis que la validation fournit le mécanisme exécutable qui vérifie les enregistrements par rapport aux conditions convenues. Ce guide explique comment les règles de Data Validation, les contrôles de Data Validation, la mesure, l'automatisation et la surveillance continue fonctionnent ensemble.

Table des matières

• Qu'est-ce que la Data Validation et pourquoi elle existe

  • Pourquoi un nettoyage ponctuel ne suffit pas

• Comment fonctionnent les règles de Data Validation

• Types de contrôles de Data Validation

  • Contrôles structurels et de contenu

  • Contrôles de relation et de comportement

• Concevoir des règles qui tiennent la route en production

• Mesurer les résultats de validation

  • Lire les tendances, pas des instantanés isolés

• Data Validation versus Qualité des données et Observability

  • La validation et l'observabilité répondent à des questions différentes

• Automatiser et surveiller la Data Validation

  • Construire le chemin de réponse

• Flux de travail de validation de bout en bout avec un ensemble de données clients

• Foire aux questions

  • Qu'est-ce que la Data Validation ?

  • Quelles sont les règles de Data Validation ?

  • Quels sont les principaux types de Data Validation ?

  • Comment mesure-t-on la Data Validation ?

  • La Data Validation est-elle identique à la qualité des données ?

  • Quelle est la différence entre la Data Validation et la vérification des données ?

  • La Data Validation peut-elle détecter des données inexactes ?

  • Comment automatiser la Data Validation ?

  • Comment digna Data Validation soutient-elle la qualité des données ?

Qu'est-ce que la Data Validation et pourquoi elle existe

La Data Validation teste si les enregistrements sont conformes aux attentes prédéfinies concernant la structure, le contenu, les relations et la signification métier. Une règle peut exiger un identifiant client, restreindre un code pays à un domaine approuvé, confirmer qu'une date a le format attendu ou s'assurer qu'un montant de commande répond à une condition métier.

La validation existe parce que les erreurs deviennent plus difficiles à isoler après avoir traversé plusieurs systèmes. Un enregistrement malformé peut affecter les analyses, les pipelines de machine learning, les flux opérationnels ou les rapports réglementaires avant que quelqu'un ne remarque le problème au niveau du tableau de bord. Tester au moment de l'intégration ou lors de la transformation donne aux équipes une chance d'arrêter, de signaler ou d'isoler l'enregistrement tant que son origine est encore visible.

La distinction entre une dimension de qualité et son test opérationnel est également reflétée dans le guide DAMA-DMBOK® 2.0 Revised Edition, couramment utilisé comme point de référence pour les pratiques de gestion des données. La validité décrit la conformité à des formats, des domaines et des règles définis. La Data Validation est l'activité qui mesure cette conformité dans un ensemble de données particulier et à un point précis d'un pipeline.

Pourquoi un nettoyage ponctuel ne suffit pas

Un projet de nettoyage peut corriger des défauts connus, mais il ne protège pas le chargement suivant. Une surveillance continue de la qualité des données mesure la qualité au fil du temps et applique des contrôles afin que les données continuent de se conformer aux attentes de l'entreprise. La boucle de rétroaction persistante aide les équipes à identifier les dérives, les dégradations et les ruptures de processus avant que les consommateurs en aval n'utilisent des valeurs peu fiables, comme décrit dans la recherche sur la surveillance continue de la qualité des données.

Le guide de qualité des données de Gartner mentionne un coût annuel moyen de 12,9 millions de dollars associé à une mauvaise qualité des données, faisant de la validation et de la surveillance systématiques un contrôle d'entreprise autant qu'une pratique technique (Directives de qualité des données de Gartner). La réponse pratique n'est pas de faire des tests illimités. Il s'agit de choisir les règles qui protègent les données les plus importantes et de connecter chaque échec à un propriétaire et à une action.

Comment fonctionnent les règles de Data Validation

Une règle de Data Validation comporte trois parties essentielles : la condition, la portée et l'action. La condition définit le test logique, la portée identifie l'endroit où le test s'applique et l'action détermine ce que le pipeline doit faire en cas d'échec du test.

Considérons une table customer_orders :

• order_total > 0

• customer_email correspond au format d'e-mail approuvé

• country_code appartient à un ensemble autorisé

La même condition peut produire des résultats différents selon la gravité. Un identifiant réglementaire manquant pourrait bloquer un chargement, tandis qu'une valeur inhabituelle mais vérifiable pourrait générer un avertissement. Un enregistrement malformé pourrait être déplacé vers une zone de quarantaine plutôt que de disparaître, préservant ainsi les preuves pour correction et rejeu.

Les règles peuvent être déclaratives, telles que des contraintes SQL ou des configurations YAML, ou procédurales, telles que des tests implémentés avec dbt ou Great Expectations. Les intégrations d'entreprise peuvent également exposer des contrôles via une API, notamment l'API REST de digna pour la Data Validation.

Une règle utile doit être réutilisable et paramétrée. Par exemple, un modèle unique de contrôle de plage peut accepter différentes valeurs minimales et maximales pour différents champs monétaires. Stockez la définition de la règle, sa gravité, son propriétaire et sa version à côté du modèle de données qu'elle protège. Cela rend les modifications révisables lorsqu'un schéma ou une politique d'entreprise change.

Types de contrôles de Data Validation

Aucun type de contrôle unique ne détecte tous les échecs. Un framework de Data Validation mature superpose des tests structurels avec des contrôles de contenu, de relation et de comportement.

Contrôles structurels et de contenu

Les contrôles de schéma détectent une colonne manquante, un type inattendu ou un indicateur de nullité modifié avant que les transformations en aval n'échouent. Les contrôles de domaine détectent des valeurs qui sont syntaxiquement acceptables mais non approuvées, comme un code pays inconnu ou un statut client non pris en charge.

La validation de format gère les structures d'adresses e-mail, de dates, de codes postaux et de numéros de compte. La validation de plage vérifie des valeurs telles que l'âge, la quantité, les pourcentages et les montants monétaires par rapport à des limites définies.

La validation de nullité sépare les champs obligatoires des attributs facultatifs. Un identifiant client peut être obligatoire, tandis qu'un numéro de téléphone secondaire peut être facultatif. Traiter chaque valeur nulle comme une erreur crée du bruit, l'exigence doit donc découler de l'utilisation prévue.

Contrôles de relation et de comportement

La validation croisée des champs teste la logique entre les attributs. Une date de fin ne peut pas précéder une date de début, et une valeur monétaire doit satisfaire à sa condition commerciale définie. La validation référentielle vérifie qu'un identifiant client existe dans les données de référence des clients et qu'un identifiant produit existe dans un ensemble de données de référence approuvé.

Les contrôles statistiques ajoutent une dimension différente. Ils peuvent surveiller le nombre de lignes, les taux de nullité, les moyennes, les écarts-types et les distributions, aidant ainsi les équipes à détecter les dérives silencieuses que les règles statiques pourraient manquer. Des conseils sur les contrôles de cohérence des données sont utiles lorsque plusieurs sources doivent décrire la même entité ou le même événement.

Pour les éléments critiques, combinez des contrôles de schéma, de domaine, de format, de relation et de distribution plutôt que de dépendre d'une seule catégorie.

Concevoir des règles qui tiennent la route en production

Les règles de qualité des données efficaces doivent être explicites, mesurables, pertinentes, testables, maintenables et traçables jusqu'à une exigence métier. Une règle telle que « les données clients doivent être complètes » n'est pas exécutable. « L'identifiant client ne doit pas être nul pour chaque enregistrement de facturation » est suffisamment précis pour être testé et attribué.

Les règles peuvent cibler plusieurs dimensions de qualité :

• Complétude : les champs obligatoires contiennent des valeurs.

• Validité : les valeurs sont conformes à un format ou à un domaine approuvé.

• Unicité : les identifiants ne se répètent pas là où l'unicité est requise.

• Cohérence : les systèmes associés s'accordent sur les attributs partagés.

• Timeliness : les données arrivent dans la fenêtre d'exploitation convenue.

• Exactitude : les valeurs correspondent à une source fiable ou à une condition vérifiée.

• Conformité : les enregistrements suivent la norme structurelle et commerciale pertinente.

N'appliquez pas la même rigueur à chaque colonne. Donnez la priorité aux éléments de données critiques et aux règles critiques pour l'entreprise, en particulier les champs utilisés dans le traitement financier, les communications clients, les rapports réglementés, les décisions opérationnelles ou les analyses à fort impact. Un arriéré de règles peut être classé en fonction du coût de mise en œuvre, du rayon d'impact potentiel, de la facilité avec laquelle une défaillance peut être détectée et de la réversibilité de l'erreur qui en résulte.

Les modèles paramétrés réduisent la logique dupliquée. Adaptez les règles aux versions des schémas, enregistrez le propriétaire métier et retirez les contrôles lorsque l'exigence sous-jacente change. Les recherches sur les règles de qualité des données techniques maintenues manuellement soulignent pourquoi la maintenabilité doit être traitée comme faisant partie intégrante de la conception du contrôle, et non après coup.

Mesurer les résultats de validation

La validation devient opérationnellement utile lorsque les équipes mesurent plus qu'un simple signal de réussite ou d'échec. Les indicateurs clés comprennent le taux de réussite de la validation, le taux d'échec de la validation, le nombre d'enregistrements en échec, le nombre de règles en échec, les tendances d'échec et le taux d'échec des règles critiques.

Le calcul standard est :

Taux de réussite de la validation = enregistrements réussissant une règle / enregistrements évalués × 100

La vue d'échec correspondante peut utiliser le nombre d'enregistrements ayant échoué à la règle, divisé par le nombre d'enregistrements évalués, puis multiplié par 100. Les équipes peuvent également suivre le temps moyen de détection, le temps moyen de résolution, la couverture des règles et un indice de score composite de qualité des données lorsque ces mesures sont définies de manière cohérente.

Un taux de réussite de 99 % n'est pas automatiquement bon ou mauvais. Si les enregistrements en échec affectent un attribut analytique à faible risque, le seuil peut être tolérable. S'ils affectent un identifiant de facturation requis, ce même taux peut nécessiter une intervention immédiate. Les seuils doivent refléter la criticité métier, l'impact en aval et l'action associée à la règle.

Lire les tendances, pas des instantanés isolés

Le suivi des tendances montre si les défaillances sont stables, s'améliorent ou s'aggravent. Une règle qui réussit aujourd'hui peut tout de même se dégrader progressivement au fil des chargements successifs. L'outillage de données de référence SAP illustre cette approche par le biais d'évaluations planifiées, du suivi des tendances, de la surveillance de l'état actuel et de la comparaison par rapport à des seuils définis (Documentation SAP sur la validation et la surveillance).

Les scores composites doivent être pondérés par la criticité des éléments de données plutôt que moyennés de manière uniforme. Un tableau de bord qui combine des règles à faible impact et à fort impact en un seul score non pondéré peut minimiser l'importance de défaillances graves. Des conseils détaillés sur les métriques de qualité des données peuvent aider les équipes à définir un modèle de mesure qui relie les résultats des règles aux propriétaires et aux usages métier.

Data Validation Versus Qualité des données et Observability

La Qualité des données est le concept plus large qui consiste à savoir si les données sont adaptées à l'usage prévu. Elle comprend des dimensions telles que la complétude, l'exactitude, la cohérence, la Timeliness, l'unicité et la validité. La Data Validation est un mécanisme permettant de tester les exigences définies en matière de qualité des données.

Un contrôle de validation demande : « Cet enregistrement satisfait-il à cette règle ? » Une évaluation de la qualité se demande si l'attribut ou l'ensemble de données est fiable pour l'usage auquel il est destiné. Une gestion plus large de la qualité des données peut également inclure le profilage, la détection des anomalies, le rapprochement, la surveillance de la Timeliness, l'analyse historique et la remédiation.

La validation et l'observabilité répondent à des questions différentes

La Data Validation demande :

Ces données satisfont-elles à cette règle définie ?

La Data Observability demande :

Que se passe-t-il avec les données et comment leur comportement a-t-il changé ?

La validation est généralement déterministe et guidée par des règles. L'Observability ajoute des signaux comportementaux tels que les tendances, les anomalies, le contexte de lignage, la fraîcheur et la détection des changements structurels. Elles se complètent. Une règle de validation peut identifier un code postal invalide, tandis qu'une surveillance des anomalies peut identifier une augmentation soudaine des échecs de codes postaux.

Prenons l'exemple d'un pipeline d'adresses clients. La validation peut rejeter les codes postaux malformés. L'évaluation de la qualité peut montrer une complétude en baisse sur les champs d'adresse. L'Observability peut détecter qu'un changement de schéma en amont a introduit un champ non mappé. Chaque couche répond à une question opérationnelle différente, et ensemble, elles fournissent un meilleur diagnostic que n'importe quelle couche isolée.

Automatiser et surveiller la Data Validation

La Data Validation automatisée doit s'exécuter dans le cadre du cycle de vie des données, et non comme un script isolé que quelqu'un doit penser à exécuter. Les équipes peuvent déclencher des contrôles après des événements de chargement via Airflow, Dagster ou Azure Data Factory, ou les planifier pour des ensembles de données qui ne disposent pas de signaux d'événements fiables.

Exécutez les contrôles dans l'entrepôt de données (warehouse) ou le lakehouse dans la mesure du possible. L'exécution en base de données conserve les données sur place, prend en charge le lignage et évite les déplacements inutiles. Matérialisez les résultats dans un schéma de contrôle comprenant l'identifiant de la règle, l'horodatage d'exécution, la portée, l'état, le nombre d'enregistrements en échec, la gravité et le propriétaire.

Construire le chemin de réponse

Utilisez des alertes graduées plutôt que de traiter chaque échec comme une panne :

• Avertissements : Enregistrez un problème non bloquant pour examen.

• Blocages : Arrêtez la publication lorsqu'une règle critique échoue.

• Quarantaine : Isolez les enregistrements invalides pour investigation ou rejeu.

• Escalation : Orientez les échecs urgents vers Slack, PagerDuty ou des flux de tickets.

Une file d'attente de triage doit attribuer un propriétaire, lier à un guide de procédures, identifier la règle défaillante et capturer une catégorie de cause racine. La résolution doit alimenter la conception du contrôle. Parfois, la règle a besoin d'être affinée. Parfois, le Data Contract ou la transformation en amont doit changer.

Les tests dbt et Great Expectations fournissent des modèles largement adoptés pour exprimer des contrôles sous forme de code. Les équipes opérationnelles ont également besoin d'exécutions idempotentes, de réexécutions sécurisées, de gestion de la dérive des schémas et d'attentes de service claires concernant la fraîcheur par rapport au délai de validation. Les équipes qui construisent un modèle opérationnel peuvent également consulter Hire-a.dev sur la surveillance pour des considérations plus larges sur les flux de travail de surveillance. La surveillance continue de la qualité des données fonctionne au mieux lorsque les signaux techniques sont directement liés à une responsabilité humaine.

Flux de travail de validation de bout en bout avec un ensemble de données clients

Prenons un ensemble de données clients avec un champ country_code. Le Data Contract déclare le format ISO-3166 alpha-2 attendu et une liste blanche approuvée de 30 régions gérées. Le champ ne doit pas être nul, doit appartenir à ce domaine et doit suivre la structure attendue.

Après chaque lot, des vérifications SQL identifient les valeurs nulles, les codes inconnus et les changements de distribution. Un moniteur d'anomalies compare les volumes de pays d'aujourd'hui avec la référence des 30 jours précédents et fait remonter un pic soudain de valeurs XX de substitution. Les analyses indiquent alors quand la détérioration a commencé, plutôt que de signaler simplement que le dernier lot a échoué.

L'équipe d'intégration découvre qu'un processus ETL en amont utilise la valeur par défaut XX en cas d'échec du géocodage. Elle corrige la transformation, recharge les enregistrements concernés et réexécute les analyses de revenus en aval par région. La validation identifie les mauvaises valeurs, la surveillance des anomalies révèle le changement inhabituel et les analyses établissent la chronologie. Les trois couches forment une boucle de rétroaction fermée plutôt qu'une collection déconnectée de contrôles.

digna fournit une Data Validation au niveau de l'enregistrement pour des règles explicites couvrant les champs obligatoires, les formats, les domaines, les plages, les conditions croisées et les contraintes référentielles ou métier. Sa fonctionnalité complémentaire de détection de Data Anomalies peut identifier des changements inhabituels dans les résultats de validation ou le comportement des données, tandis que Data Analytics prend en charge l'analyse historique des métriques et des tendances de validation. Visitez digna pour évaluer comment ces capacités peuvent s'intégrer dans votre flux de surveillance de la qualité des données.

Foire aux questions

Qu'est-ce que la Data Validation ?

La Data Validation est le processus consistant à appliquer des règles, des contraintes, des formats, des domaines et des conditions métier définis afin de déterminer si les données répondent à des exigences spécifiées. Elle transforme les attentes de qualité des données en contrôles explicites et testables.

Quelles sont les règles de Data Validation ?

Les règles de Data Validation sont des conditions logiques appliquées à un périmètre défini, tel qu'un champ, un enregistrement, une table ou une étape de pipeline. Elles peuvent déclencher des actions telles que l'avertissement, le rejet, la mise en quarantaine ou la correction lorsque les données échouent.

Quels sont les principaux types de Data Validation ?

Les types courants comprennent les contrôles de format, de type de données, de domaine, de plage, de nullité, de champs croisés, référentiels, d'unicité, de schéma, de règles métier et statistiques ou de distribution. La bonne combinaison dépend de la manière dont les données seront utilisées.

Comment mesure-t-on la Data Validation ?

Mesurez le taux de réussite, le taux d'échec, le nombre d'enregistrements en échec, le nombre de règles en échec, les tendances d'échec et le taux d'échec des règles critiques. Les seuils doivent refléter l'importance de l'élément de données et les conséquences d'une défaillance.

La Data Validation est-elle identique à la qualité des données ?

Non. La qualité des données est l'évaluation plus large visant à savoir si les données sont adaptées à leur usage. La Data Validation est un mécanisme pratique pour tester des exigences spécifiques de qualité des données.

Quelle est la différence entre la Data Validation et la vérification des données ?

La Data Validation vérifie si les données sont conformes aux exigences définies. La vérification des données confirme généralement qu'une valeur ou un processus correspond à une source ou à un résultat attendu. La vérification peut appuyer la validation, mais les termes décrivent des activités de contrôle différentes.

La Data Validation peut-elle détecter des données inexactes ?

Elle peut détecter une inexactitude lorsque l'organisation dispose d'une référence fiable, d'une règle de rapprochement ou d'une condition métier à tester. Une valeur peut réussir les contrôles de format et de domaine tout en étant factuellement erronée, c'est pourquoi la validation doit être combinée avec le profilage, le rapprochement et la détection d'anomalies.

Comment automatiser la Data Validation ?

Exécutez des règles au sein des pipelines d'intégration et de transformation, connectez-les à des orchestrateurs tels qu'Airflow, Dagster ou Azure Data Factory, stockez les résultats dans un schéma de contrôle et acheminez les échecs via des flux d'alerte et de triage. Les tests dbt et Great Expectations sont des modèles d'implémentation courants.

Comment digna Data Validation soutient-elle la qualité des données ?

digna Data Validation applique des règles explicites au niveau de l'enregistrement et consigne les résultats pour des contrôles de qualité ciblés. Utilisée conjointement avec la détection des anomalies et l'analyse historique, elle aide les équipes à relier les défaillances individuelles à l'évolution du comportement des données et aux tendances de qualité à long terme.