Qualité des données vs intégrité des données : le guide ultime 2026
|
6
minute de lecture
Votre tableau de bord des revenus semblait normal hier. Ce matin, il affiche une baisse brutale, l'équipe commerciale fait remonter le problème et personne n'est d'accord sur l'origine de la panne. Un ingénieur vérifie les journaux du pipeline et affirme que tous les jobs ont réussi. Un analyste pointe du doigt des enregistrements sources manquants. Un propriétaire de plateforme suspecte un changement de schéma qui n'a généré aucune erreur mais a modifié la signification d'un champ clé.
Cette confusion est précisément l'endroit où de nombreuses organisations s'embourbent entre qualité des données (data quality) et intégrité des données (data integrity). Elles traitent ces termes comme interchangeables, confient le problème à la mauvaise équipe, utilisent les mauvais contrôles et répètent le même échec un mois plus tard. La différence n'est pas académique. Elle détermine si vous devez corriger une contrainte de base de données, un processus source, une règle de fraîcheur, un contrat sémantique ou un écart de surveillance ML.
Cela change également la manière dont vous établissez la confiance. Les équipes soucieuses de guider les décisions grâce aux données investissent généralement d'abord dans les tableaux de bord. Le plus difficile est de maintenir la fiabilité des chiffres lorsque les pipelines continuent de fonctionner mais que le sens des données dérive. C'est pourquoi la détection précoce est cruciale, en particulier pour les anomalies silencieuses telles que les arrivées tardives, les variations de volume inhabituelles et les comportements de champs inattendus, ce qui est exactement ce que la détection d'anomalies dans les pipelines modernes est censée mettre en lumière avant que la finance ou les opérations n'en subissent les conséquences.
Table des matières
Le tableau de bord est faux, mais pourquoi ?
Un mauvais tableau de bord est généralement le point de départ d'une mauvaise dispute.
Les ventes constatent une baisse et supposent que le business a changé du jour au lendemain. L'analytique vérifie le modèle et constate que le SQL s'exécute toujours. L'ingénierie examine l'orchestration et confirme que le pipeline s'est correctement terminé. La réunion se divise alors en deux camps. L'un affirme que les données ont été altérées lors du transfert. L'autre soutient que les données sont arrivées intactes mais incompletes, obsolètes ou contextuellement fausses.
Il s'agit de catégories de pannes différentes.
Si une opération d'écriture, un transfert ou une relation de schéma a corrompu le jeu de données, vous faites face à un problème d'intégrité. Si les enregistrements sont structurellement valides mais qu'il manque des champs métier, qu'ils sont en retard, obsolètes ou sémantiquement inadaptés au cas d'usage, vous faites face à un problème de qualité. En pratique, les équipes perdent souvent des heures parce qu'elles commencent par analyser les journaux des outils alors qu'elles auraient dû se poser une question plus fondamentale : le système a-t-il préservé correctement les données, ou a-t-il préservé parfaitement de mauvaises données ?
Règle pratique : Si l'entrepôt de données a accepté les enregistrements et que les jointures fonctionnent toujours, ne supposez pas pour autant que le jeu de données est exploitable.
Un exemple bien connu est celui d'un tableau de bord des revenus qui chute soudainement après qu'un système source a modifié la manière dont les remises sont renseignées. La table est toujours alimentée. Les types de colonnes correspondent toujours. Les liaisons référentielles tiennent toujours. Rien dans le pipeline ne signale d'erreur. Pourtant, le revenu net est désormais sous-estimé car la règle métier derrière un champ a changé en amont. C'est un problème de faible qualité, pas d'intégrité rompue.
Le cas inverse est tout aussi fréquent. Une migration introduit des écritures partielles ou une corruption silencieuse lors du transfert. Le tableau de bord est faux car certaines parties du jeu de données ne sont plus dans leur état d'origine, même si les définitions métier n'ont pas changé. C'est un problème d'intégrité.
À quoi ressemble généralement le débat
L'ingénierie dit : « Le job a réussi, donc le pipeline fonctionne. »
L'analytique dit : « Les chiffres ne correspondent pas à la source. »
Le métier dit : « Nous ne pouvons pas faire confiance au tableau de bord. »
Ces trois affirmations peuvent être vraies en même temps. Le job peut réussir, le tableau de bord peut être faux, et la cause profonde peut tout de même se situer en dehors de la couche d'orchestration.
Définition des concepts clés
La manière la plus claire de formuler cette distinction est simple. La qualité des données évalue si la donnée est adaptée à l'usage prévu. L'intégrité des données évalue si la donnée est restée entière, correcte dans sa structure et inaltérée tout au long de son stockage, de son transfert et de son traitement.
L'analogie de la bibliothèque est utile. La qualité consiste à savoir si le livre est utile pour le lecteur. Est-il à jour, complet et correspond-il à la bonne édition pour la question posée ? L'intégrité consiste à savoir si toutes les pages sont présentes, dans l'ordre et conformes à l'exemplaire original. On peut avoir l'une sans l'autre. Un livre peut être parfaitement conservé et pourtant obsolète. Il peut aussi être à jour dans son contenu mais endommagé au point de rendre certaines parties inutilisables.
Pour les équipes travaillant au plus près des revenus, des stocks ou de la tarification, cette distinction prend rapidement tout son sens. Une explication utile de la qualité des données pour les équipes de tarification montre pourquoi une donnée « assez correcte pour agir » dépend du contexte, et pas seulement de sa validité technique. Et lorsque la préoccupation concerne la confiance structurelle à travers les plateformes modernes, les contrôles visant à protéger l'intégrité des données à travers les systèmes se situent à un niveau différent de celui des règles de qualité orientées métier.
Un moyen simple de les distinguer
La qualité des données est orientée métier. Elle couvre des dimensions telles que l'exactitude, la complétude, la cohérence et l'actualité. À titre de référence pratique, la qualité peut être évaluée à travers des dimensions telles que l'exactitude à ≥99 % pour les données de niveau
Pour appliquer les règles métier au niveau de l'enregistrement qui déterminent si des données structurellement saines sont réellement exploitables, découvrez comment digna Data Validation les exécute directement dans votre base de données.
Questions fréquentes
Quelle est la différence entre qualité des données et intégrité des données ?
La qualité des données vérifie si les données sont adaptées à un usage précis : exactitude, complétude, cohérence et actualité. L'intégrité vérifie si les données sont restées complètes, structurellement correctes et inchangées lors du stockage, du transfert et du traitement. Dans l'analogie de la bibliothèque de l'article, la qualité, c'est la bonne édition ; l'intégrité, toutes les pages présentes et intactes.
Des données peuvent-elles avoir une intégrité élevée mais une qualité faible ?
Oui, et l'article appelle cela le piège « intégrité élevée, qualité faible ». Les données peuvent être intactes, sécurisées et structurellement valides alors qu'un mapping de catégories ou une distribution de valeurs dérive en silence. Citant Atlan, il indique que plus de 60 pour cent des échecs de modèles d'IA proviennent de problèmes de qualité invisibles aux contrôles d'intégrité classiques.
Qui est responsable de la qualité des données et qui de l'intégrité ?
La responsabilité se répartit généralement par couche. La qualité relève des analystes, analytics engineers, data stewards et équipes métier, car elle dépend des définitions métier. L'intégrité revient aux data engineers, platform engineers, DBA et équipes sécurité, qui appliquent contraintes, pistes d'audit, rapprochements, sommes de contrôle et contrôle d'accès. Chaque jeu de données de confiance a besoin des deux responsables.
Comment surveiller l'intégrité des données dans les pipelines ?
Appliquez l'intégrité au plus près du stockage et des mouvements de données : contraintes de clé primaire, de clé étrangère et d'unicité, protections transactionnelles contre les écritures partielles, sommes de contrôle et rapprochement du nombre de lignes lors des transferts, pistes d'audit et détection des changements de schéma. Selon Dataversity, cité dans l'article, l'intégrité est compromise dans 60 pour cent des pipelines d'entreprise, et 67 pour cent des problèmes passent inaperçus.
Comment digna couvre-t-il à la fois la qualité et l'intégrité des données ?
digna associe ses modules aux deux couches sans les confondre. Schema Tracker soutient l'intégrité en signalant les colonnes ajoutées ou supprimées et les changements de type de données, Data Validation applique des règles métier au niveau de l'enregistrement, Timeliness détecte les arrivées tardives et la détection d'anomalies par IA révèle les dérives de distribution, le tout exécuté dans la base de données.
