Qualité des données — ce qui est vérifié, et qui décide du périmètre

Vous êtes ici : Comprendre — les fondations : ce qui garantit qu’une donnée chargée est utilisable. Comment la plateforme vérifie ses propres données, et pourquoi le périmètre du contrôle se découvre au lieu d’être maintenu. Lecture 8 min. Audience : analystes, devs, auditeurs. Date : 2026-08-11 | Version : 1.0 — créée par la refonte de l’architecture d’information

Le principe central — une liste à tenir à jour finit toujours par mentir

Un contrôle de qualité classique tient une liste des tables à vérifier. Cette liste est écrite par un humain, et une table ajoutée un mardi soir n’y entre pas — le contrôle reste vert en ne vérifiant rien de nouveau.

La plateforme a retourné le problème : le contrôle découvre lui-même les tables qui doivent porter des assertions, à partir des sources qui font déjà foi (les extracteurs déclarés et le catalogue de lignage). Une table nouvelle est donc immédiatement en défaut tant qu’elle n’a pas ses assertions. L’oubli devient impossible plutôt qu’improbable.

TL;DR

Question	Réponse	Détail
Qu’est-ce qui est vérifié ?	Un fichier d’assertions par table, rejouable à volonté, en lecture seule	§ Les assertions
On vérifie que tout est parfait ?	Non — on mesure la dérive par rapport à une réalité connue	§ Seuils, pas zéros
C’est pareil partout ?	Non — la couche brute et la couche servie s’assertent en sens inverse	§ Bronze et servi
Qui décide de la liste des tables ?	Personne — le contrôle la découvre depuis les sources canoniques	§ Auto-enrôlement
Un contrôle vert prouve-t-il quelque chose ?	Seulement s’il pouvait voir les données — le faux vert est le vrai risque	§ Le faux vert

1 · Une table, un fichier d’assertions

Chaque table répliquée porte un fichier d’assertions — au moins cinq — qui vérifie qu’elle est dans un état exploitable. Ces fichiers sont en lecture seule et rejouables : les exécuter ne modifie rien, et on peut les relancer autant de fois que nécessaire, en particulier après un incident.

Ce qu’une assertion regarde, typiquement : la table est alimentée ; la clé utilisée pour paginer l’extraction est bien unique (sans quoi la pagination perdrait des lignes en silence) ; la colonne qui sert de point de reprise est bien formée ; les données sont fraîches ; les anomalies connues n’ont pas empiré.

2 · Pourquoi des seuils et non des zéros

Un système source réel n’est pas propre. Il porte des dates aberrantes saisies à la main, des durées négatives, des codes à zéro. C’est normal, et ce n’est pas le rôle de la copie de le corriger.

Une assertion « zéro date aberrante » serait donc rouge dès le premier jour, pour toujours. Un contrôle toujours rouge ne signale plus rien : il devient un bruit qu’on apprend à ignorer, et le jour où il indique un vrai problème, personne ne le lit.

La plateforme fige donc la mesure du jour comme référence et alerte sur l’écart à cette référence. Chaque seuil porte, en commentaire, sa valeur mesurée et sa date de mesure. Ce que ça détecte : une corruption de masse, un changement de comportement de la source, une régression de transformation. Ce que ça ne fait pas : crier au loup sur un bruit de fond déjà connu et assumé.

La contrepartie, assumée

Un seuil de dérive accepte par construction l’anomalie déjà présente au moment où il est posé. Il protège contre l’aggravation, pas contre l’existant. C’est un choix explicite : rendre le contrôle crédible d’abord, réduire le bruit de fond ensuite — dans l’ordre inverse, on n’obtient ni l’un ni l’autre.

3 · Bronze et servi — deux doctrines opposées

La nature de l’assertion dépend de ce que la couche promet.

	Couche brute (copie fidèle)	Couche servie (faits, agrégats)
Ce que la couche promet	Être une copie fidèle de la source	Être le résultat correct d’une règle métier
Ce qu’on assert	La santé du pipeline et la fidélité de la copie	Le chiffre lui-même
Forme de l’assertion	Seuils de dérive	Valeurs exactes sur les périodes closes
Unicité vérifiée	Celle de la clé de pagination	Celle du grain — le contrat de la table
Cohérence interne	—	La mesure publiée se re-dérive de ses colonnes d’audit

La logique est directe : sur la couche brute, un écart signale un problème de transport. Sur la couche servie, la table est la règle métier — un écart sur une période close signale une régression de la règle, jamais une variation d’activité, puisque le passé clos ne bouge plus. Seule la fenêtre qui touche la période en cours conserve une tolérance.

Pourquoi la règle métier vit dans la table, et nulle part ailleurs

Quand une règle de consolidation reste dans les consommateurs (un export, un tableau de bord, un rapport), chacun la réimplémente — et chacun peut la casser différemment. Le jour où deux chiffres divergent, personne ne sait lequel est faux.

Porter la règle dans la table servie, et l’asserter par un fichier de qualité, donne un point unique où elle est définie et un point unique où elle est vérifiée. Les mesures intermédiaires restent conservées à côté du résultat, pour que la réconciliation soit auditable sans retourner interroger le système source.

4 · Le contrôle qui s’étend tout seul

Le contrôle de couverture découvre les tables qui doivent porter des assertions, en croisant deux sources qui font déjà foi ailleurs :

• les extracteurs déclarés — toute table répliquée y figure, sans quoi elle ne serait pas chargée ;
• le catalogue de lignage — toute table analytique active y figure, sous peine d’échouer un autre contrôle.

Il devient rouge si une table découverte n’a pas de fichier d’assertions, ou si ce fichier en contient moins de cinq. Ajouter une table sans ses assertions casse donc le contrôle immédiatement, au lieu de créer un angle mort silencieux.

Les exclusions existent — de petites tables de référence dont le contenu ne bouge pas — mais chacune est déclarée avec sa justification. Une exclusion sans motif n’est pas possible : elle serait invisible, donc éternelle.

Le patron est réutilisable, et déjà réutilisé

Ce n’est pas une invention locale : le même patron d’auto-enrôlement garde déjà l’isolation par compagnie (toute table d’un schéma sensible doit être couverte par une politique, sinon le contrôle rougit). Chaque fois qu’une garde repose sur une liste tenue à la main, elle est candidate à cette transformation.

5 · Le faux vert — le pire résultat possible

Les couches analytiques sont protégées par une isolation par compagnie qui filtre tout le monde, y compris un compte administrateur de la base. Une conséquence contre-intuitive en découle.

Un fichier d’assertions qui interroge ces tables sans poser le contexte de compagnie ne reçoit aucune ligne. Ses totaux valent alors zéro, ses comparaisons passent à vide, et le fichier se termine… en vert. Il n’a rien vérifié du tout, et il affirme le contraire.

C’est la raison pour laquelle l’exécuteur pose systématiquement le contexte de compagnie dans le même lot d’instructions que les requêtes, et pourquoi la première assertion d’un fichier de couche servie distingue explicitement deux situations qu’un simple « zéro ligne » confondrait :

• la transformation n’a jamais été exécutée — la table est légitimement vide ;
• la transformation a tourné, mais le contexte d’isolation n’est pas posé — la table est pleine et invisible.

Le principe à retenir

Un contrôle qui ne pouvait pas voir les données n’est pas un contrôle vert : c’est un contrôle qui n’a pas eu lieu. Toute garde qui interroge des données protégées doit d’abord prouver qu’elle les voit.

Pour aller plus loin

• Ingestion et fraîcheur — ce qui se passe avant la vérification, et le mode de panne silencieux du chargement.
• Lire un journal ETL — où se lisent les statuts d’exécution.
• Cycle de vie des données — la gouvernance complète, dont la qualité est une étape.
• Architecture de données — l’isolation par compagnie, dont dépend le piège du faux vert.