Qu'est-ce que la validation des données ? Définition, méthodes et exemples

En quoi la validation des données diffère des tests, de l'observabilité et du nettoyage, les quatre méthodes qui couvrent presque tous les contrôles réels, et l'endroit où chacune s'exécute.

2026-09-10 · 9 min read

La validation des données est le processus qui consiste à vérifier que des données respectent un ensemble d'attentes défini — leur structure, leurs types, leurs valeurs autorisées, leurs relations et leur fraîcheur — avant qu'on leur fasse confiance ou qu'on les utilise. Chaque attente est énoncée à l'avance, évaluée sur les données réelles, et produit un pass ou un fail assorti du nombre d'enregistrements qui l'ont violée. La validation ne répare rien : son rôle est de décider si les données conviennent à l'usage qu'on s'apprête à en faire, et de dire précisément ce qui ne va pas lorsque ce n'est pas le cas.

Cette définition repose sur trois éléments porteurs. Les attentes sont déclarées à l'avance, ce qui distingue la validation du fait de remarquer un problème après coup, quand un tableau de bord paraît bizarre. Le contrôle est évalué sur des données réelles, et non sur un échantillon ou sur une description des données. Et le résultat est une décision — ce lot est acceptable, ou il ne l'est pas — plutôt qu'un rapport que quelqu'un lira peut-être plus tard.

Ce que la validation des données n'est pas

Le mot est employé de façon approximative pour quatre activités différentes. Poser précisément les frontières facilite grandement le choix de l'outil dont vous avez réellement besoin.

Activité	Question à laquelle elle répond	Attentes	Résultat typique
Validation des données	Ces données respectent-elles les règles convenues ?	Déclarées explicitement, en amont	Pass / fail par règle, nombre de violations
Tests de données	Le code de ce pipeline se comporte-t-il correctement ?	Assertions écrites par le développeur	Le build passe ou échoue
Observabilité des données	Quelque chose a-t-il changé de façon inattendue ?	Apprises de l'historique, statistiques	Alertes d'anomalie, courbes de tendance
Nettoyage des données	Pouvons-nous réparer les mauvais enregistrements ?	Sans objet — c'est une transformation	Données modifiées

Ces distinctions comptent en pratique :

Validation et tests. Un test dbt est une règle de validation qui se trouve s'exécuter à l'intérieur d'un build. La différence tient à la portée et à la propriété : les tests couvrent les modèles dont le pipeline est propriétaire et s'exécutent quand le pipeline s'exécute ; la validation couvre les garanties d'un jeu de données quel que soit le pipeline qui l'a produit aujourd'hui, et s'exécute selon sa propre planification. Une table chargée par Fivetran, transformée par dbt et complétée par un traitement Python maison a un seul jeu de garanties et trois pipelines.
Validation et observabilité. L'observabilité n'est pas supervisée : elle surveille les nombres de lignes, les taux de valeurs nulles et les distributions, et alerte quand aujourd'hui ne ressemble pas à la semaine dernière. Elle trouve des problèmes que vous n'auriez pas pensé à chercher — et elle se déclenche aussi quand le métier change légitimement. La validation, elle, est supervisée : vous avez dit que status devait prendre l'une de quatre valeurs, et soit c'est le cas, soit ça ne l'est pas. L'observabilité vous donne du rappel ; la validation vous donne de la précision. Les équipes matures font les deux.
Validation et nettoyage. Le nettoyage modifie les données — suppression des espaces superflus, coercition de types, déduplication, imputation. La validation est en lecture seule par construction. Les confondre, c'est ainsi qu'apparaît la corruption silencieuse : une étape de coercition qui transforme "N/A" en 0 fait passer une règle de validation tout en rendant le chiffre faux.

Les quatre méthodes de validation des données

Presque tous les contrôles en production relèvent de l'une de ces quatre familles.

1. Contrôles de schéma et de types

Le jeu de données possède-t-il les colonnes qu'il devrait avoir, dans les types attendus, avec une nullabilité correctement déclarée ? Ce sont les contrôles les moins coûteux, et ils détectent les défaillances les plus perturbatrices : une colonne renommée, un type élargi d'integer à text, une colonne supprimée discrètement par une migration en amont. La dérive de schéma casse les consommateurs immédiatement et bruyamment, ce qui justifie de la détecter à la frontière plutôt que dans un tableau de bord.

2. Contrôles de contraintes

Des règles au niveau de la ligne, qu'un enregistrement satisfait ou viole : une colonne obligatoire n'est pas nulle, une clé est unique, une valeur appartient à un ensemble autorisé, un nombre se situe dans une plage plausible, une chaîne correspond à un motif, une clé étrangère se résout. Cette famille couvre l'essentiel des règles réelles, et chacune se compile en une unique requête d'agrégation renvoyant un nombre de violations.

SELECT
    count(*) FILTER (WHERE order_id IS NULL)                       AS null_ids,
    count(*) FILTER (WHERE total_amount < 0 OR total_amount > 1e5) AS bad_amounts,
    count(*) FILTER (
        WHERE status IS NOT NULL
          AND status NOT IN ('pending', 'paid', 'shipped', 'refunded')
    )                                                              AS bad_status
FROM sales.orders;

Remarquez la garde status IS NOT NULL. Comparer un NULL à quoi que ce soit donne NULL, jamais true : un NOT IN sans garde exclut donc discrètement chaque ligne nulle de son propre décompte de violations. Un contrôle de contrainte écrit ainsi reste au vert pendant que la colonne se vide — c'est l'argument permanent en faveur de l'association de chaque règle de contrainte à une règle de complétude sur la même colonne.

3. Contrôles statistiques

Des propriétés agrégées plutôt que des lignes individuelles : un nombre de lignes dans une fourchette, un taux de valeurs nulles sous un pourcentage, une moyenne ou une médiane dans une plage, une cardinalité stable, une répartition entre catégories à peu près conforme aux attentes. Ils détectent des défaillances qu'aucune règle au niveau de la ligne ne peut voir — un chargement partiel où chaque ligne survivante est valide individuellement, alors qu'un tiers des données manque.

4. Contrôles de règles métier

De la logique inter-colonnes ou inter-tables qui encode un invariant du domaine : shipped_at n'est jamais antérieur à ordered_at, la somme des lignes d'une facture fait son total, un remboursement n'excède jamais le paiement d'origine, tout abonnement actif possède un compte de facturation. Ce sont les règles qui attrapent de véritables erreurs de gestion plutôt que des erreurs de tuyauterie, et ce sont généralement celles qu'un outil de validation exprime en SQL personnalisé.

Où s'exécute la validation

La même règle n'a pas le même sens selon l'endroit où vous la placez, et la plupart des équipes ont besoin de plus d'un emplacement.

À l'ingestion. Validez à la frontière, avant que les données n'atterrissent dans une table partagée. C'est là que vous rejetez un CSV mal formé, une charge utile JSON à laquelle il manque un champ obligatoire, ou une réponse d'API au schéma inattendu. Échouer ici coûte peu : rien n'a encore été calculé en aval, et mettre le lot en quarantaine ne vous coûte qu'une nouvelle tentative.

Dans l'entrepôt, après le chargement. Validez la table atterrie elle-même, selon une planification liée au chargement plutôt qu'à un cron calé sur une heure ronde. C'est là que vit l'essentiel de la surveillance de la qualité des données, car c'est le seul endroit qui voit les données telles que les consommateurs les voient — une fois que chaque pipeline, chaque fusion et chaque correction tardive a eu son mot à dire. Une table quotidienne validée à 06:00 alors que le chargement se termine à 06:40 échouera tous les matins pour des raisons qui n'ont rien à voir avec la qualité.

À la consommation. Validez juste avant un usage à fort enjeu — un rapport réglementaire, une métrique exposée aux clients, un jeu d'entraînement pour un modèle. Ces contrôles sont plus étroits et plus stricts que les contrôles généraux, parce que la tolérance n'est pas la même : un taux de valeurs nulles de 0,1 % peut convenir à un tableau de bord interne et être inacceptable dans une déclaration financière.

Une règle pratique : rejeter à l'ingestion, surveiller dans l'entrepôt, filtrer à la consommation.

Des contrôles ponctuels aux attentes versionnées

Le SQL de validation écrit à la main fonctionne jusqu'à ce qu'il y ait quarante règles réparties sur une douzaine de tables ; à partir de là, les problèmes habituels apparaissent. Les règles divergent des schémas qu'elles contrôlent. Plus personne ne sait répondre à « que garantissons-nous réellement au sujet de cette table ? » sans lire un script. Un changement de seuil ne laisse aucune trace de qui l'a modifié ni pourquoi.

La solution consiste à faire des attentes un artefact déclaratif plutôt que du code — un document qui énonce ce que le jeu de données promet, versionné dans le même dépôt que tout le reste, et compilé en SQL par un moteur d'exécution. Ce document, c'est un contrat de données, et l'Open Data Contract Standard est le format ouvert permettant d'en écrire un. Catalyst emprunte cette voie : les règles sont du YAML ODCS, le YAML fait foi, et chaque règle se compile vers le SQL spécifique au moteur montré plus haut.

Organiser les règles par dimension de la qualité des données — complétude, unicité, validité, cohérence, exactitude, actualité — est ce qui transforme un tas de contrôles en une vue de couverture. Pour la mécanique d'écriture et de planification des contrôles eux-mêmes, voyez le guide de la validation des données.

Questions fréquentes

Qu'est-ce que la validation des données, en termes simples ?

Valider des données, c'est vérifier qu'elles respectent les règles que vous avez décidé de leur appliquer : les bonnes colonnes et les bons types, aucune valeur manquante là où elle est obligatoire, aucune clé en doublon, des valeurs à l'intérieur de l'ensemble ou de la plage autorisés, et des données assez récentes pour être utiles. Chaque règle est vérifiée sur les données réelles et renvoie un pass ou un fail, avec le nombre d'enregistrements fautifs.

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

La validation demande si les données satisfont les règles définies pour elles — sont-elles structurellement et sémantiquement acceptables ? La vérification demande si les données correspondent fidèlement à leur source — sont-elles arrivées intactes et inaltérées, par exemple en comparant des nombres de lignes ou des sommes de contrôle entre le système source et la destination. Un enregistrement peut être parfaitement vérifié et échouer malgré tout à la validation si la source elle-même contenait de mauvaises valeurs.

Quels sont les principaux types de validation des données ?

Quatre familles couvrent presque tout : les contrôles de schéma et de types (les bonnes colonnes, dans les bons types), les contrôles de contraintes (non nul, unique, valeurs autorisées, plages, motifs, intégrité référentielle), les contrôles statistiques (nombres de lignes, taux de valeurs nulles, distributions) et les contrôles de règles métier (invariants inter-colonnes et inter-tables propres à votre domaine).

Quand faut-il exécuter la validation des données ?

À trois moments, pour des raisons différentes. À l'ingestion, pour rejeter des données mal formées à la frontière avant qu'elles n'atterrissent. Dans l'entrepôt après le chargement, selon une planification déclenchée par ce chargement, pour surveiller les tables que les consommateurs interrogent réellement. Et à la consommation, comme filtre plus strict avant un usage à fort enjeu, tel qu'un rapport réglementaire ou l'entraînement d'un modèle.

La validation des données modifie-t-elle mes données ?

Non. Un contrôle de validation est une requête en lecture seule qui renvoie un nombre de violations. Modifier des enregistrements relève du nettoyage des données, une étape distincte qui doit intervenir après que la validation vous a dit ce qui n'allait pas — jamais comme effet de bord du contrôle lui-même, ce qui masquerait le problème au lieu de le faire remonter.