L'intégrité des données expliquée : bien plus que des valeurs correctes

On estime que la mauvaise qualité des données coûte aux organisations une moyenne de 12,9 millions de dollars par an, et des résumés plus larges situent cette fourchette entre 12,9 et 15 millions de dollars par an. La Data Integrity consiste à maintenir des relations correctes et fiables entre les éléments de données et les ensembles de données, et non pas seulement à vérifier si les valeurs individuelles sont correctes.

Cette distinction est importante car un champ peut sembler propre tout en faisant partie d'une relation brisée. Une commande peut avoir un montant valide, une date correcte et un identifiant client d'apparence réelle, mais échouer si ce client n'existe plus dans les données de référence, ou si la ligne enfreint une règle métier qui maintient la fiabilité de l'ensemble de données.

Table des matières

• Ce que signifie réellement la Data Integrity

  • Pourquoi les « valeurs correctes » sont un test incomplet

• Où se situe l'intégrité dans la qualité des données

  • Pourquoi l'intégrité a besoin de sa propre voie

• Ce que couvre la Data Integrity en pratique

• En quoi l'intégrité diffère de l'exactitude, de la validité et de la cohérence

  • Distinctions côte à côte

• Comment mesurer la Data Integrity

  • Un score d'intégrité simple

  • Métriques pratiques suivies par les équipes

• Qu'est-ce que l'intégrité référentielle ?

  • Pourquoi les enregistrements orphelins sont un vrai problème

• Comment la Data Integrity peut-elle être surveillée en continu ?

  • À quoi ressemble une surveillance continue

• Un exemple de commandes et de clients pour la surveillance de l'intégrité

  • Trois vérifications capturent des signaux différents

  • Comment l'incident doit être traité

• Comment digna peut aider à soutenir la Data Integrity ?

  • Ce que chaque module fait pour l'intégrité

Ce que signifie réellement la Data Integrity

La Data Integrity est la préservation des relations valides, des conditions structurelles et des contraintes métier à travers les éléments de données et les ensembles de données. C'est plus large que de vérifier si une seule cellule contient la bonne valeur, car une valeur peut être bien formée tout en se trouvant dans une relation brisée.

Pourquoi les « valeurs correctes » sont un test incomplet

Un identifiant client peut sembler valide, le total d'une facture peut être numérique et un champ de statut peut utiliser la bonne étiquette. Rien de tout cela ne garantit que l'enregistrement respecte toujours les règles du système. Si une facture pointe vers un compte manquant, ou si une commande fait référence à un client qui a été supprimé en amont, les données ont perdu leur intégrité même si chaque champ individuel peut sembler acceptable.

C'est pourquoi les failles d'intégrité sont si dangereuses dans les pipelines d'analyse et d'IA. Les enregistrements arrivent, le travail se termine et le tableau de bord s'affiche. Le système semble sain, mais les relations qui donnent du sens aux données ont disparu. En pratique, c'est la différence entre un nombre qui existe et un nombre auquel vous pouvez faire confiance.

Règle pratique : traitez l'intégrité comme une propriété des connexions et de la structure, et non d'une seule cellule.

Pour les équipes qui suivent également la provenance et le lignage, la relation est étroitement liée, mais pas identique. L'intégrité demande si l'ensemble de données tient toujours ensemble comme prévu, tandis que le lignage et la provenance décrivent comment les données y sont parvenues. Un point de référence utile est cette comparaison de la provenance et du lignage, qui aide à séparer le suivi de l'origine de la confiance structurelle.

La raison pour laquelle la direction générale s'en soucie est simple. IBM et la Harvard Business Review citent depuis longtemps un coût annuel estimé à 3,1 billions de dollars pour les mauvaises données dans l'économie américaine, et la MIT Sloan Management Review a également fait état de recherches antérieures estimant que les mauvaises données peuvent consommer 15 % à 25 % des revenus de nombreuses entreprises, ce qui explique pourquoi la Data Integrity quitte le domaine de l'équipe de base de données pour entrer dans les discussions sur la governance et le leadership. Le risque financier ne provient pas seulement de valeurs erronées, il provient de relations brisées qui faussent les décisions en aval.

Où se situe l'intégrité dans la qualité des données

L'intégrité est l'une des dimensions de la qualité des données reconnues dans la version révisée de DAMA-DMBOK® 2.0, aux côtés de l'exactitude, de l'exhaustivité, de la Timeliness, de la cohérence, de l'unicité, de la validité et des dimensions de qualité associées. Ce positionnement est important car il confirme que l'intégrité n'est pas une idée de niche sur les bases de données, mais une partie essentielle de la réflexion sur la qualité des données DAMA et la qualité des données DMBOK.

Pourquoi l'intégrité a besoin de sa propre voie

Une équipe peut avoir des contrôles d'exactitude rigoureux tout en passant à côté de failles d'intégrité. Cela se produit parce que l'exactitude vérifie si une valeur reflète la réalité, tandis que l'intégrité vérifie si la structure et les relations autour de la valeur tiennent toujours. L'adresse d'un client peut être exacte, mais si l'enregistrement du client n'est plus lié au bon compte, l'intégrité a déjà échoué.

Le même problème se pose dans les opérations. De nombreux groupes s'appuient sur des contrôles manuels ou une validation basée sur SQL, tandis que moins d'entre eux utilisent des outils d'Observability dédiés, et la propriété de la governance est souvent partagée entre les équipes. Des données d'enquête récentes montrent que 44 % des personnes interrogées affirment que la responsabilité de la qualité des données est partagée entre plusieurs équipes, 61 % s'appuient toujours sur des contrôles manuels ou une validation basée sur SQL, 27 % utilisent une plateforme d'Observability dédiée, 39 % suivent les SLA pour les pipelines clés et 14 % les imposent à l'échelle de l'organisation. Ces chiffres pointent vers un écart opérationnel courant : les équipes surveillent les valeurs de qualité, mais ne surveillent pas toujours la santé des relations de bout en bout. La cohérence interne entre les dimensions de qualité des données est ce qui évite de confondre l'intégrité avec une autre dimension.

Ce que couvre la Data Integrity en pratique

La Data Integrity comprend plusieurs contrôles liés, chacun détectant un type de défaillance différent. Les quatre principaux sous-types et ce à quoi ils ressemblent en pratique :

Le tableau est important car chaque sous-type brise la confiance d'une manière différente. Un enregistrement peut sembler parfaitement valide à lui seul et échouer au contrôle d'intégrité global si ses liens, sa forme ou le contexte de ses règles ne tiennent plus.

Un système de réclamations en est un bon exemple. Une ligne de réclamation peut contenir un code valide, un montant valide et une date valide. Si cette ligne est rattachée au mauvais compte patient, ou si la visite dont elle dépend a été fermée hors séquence, les données sont toujours erronées. La valeur est correcte. La relation ne l'est pas.

Cette distinction explique pourquoi les équipes passent souvent à côté des problèmes d'intégrité lorsqu'elles inspectent uniquement les champs individuels. Les contrôles structurels détectent les colonnes manquantes ou les changements de type. Les contrôles référentiels détectent les liens brisés. Les contrôles de règles métier détectent les combinaisons qui ne devraient jamais se produire ensemble. Ensemble, ils montrent si l'ensemble de données se comporte toujours comme un système connecté plutôt que comme un tas de valeurs d'apparence correcte.

Une plateforme peut prendre en charge ces contrôles de différentes manières. Le test d'intégrité des bases de données est une approche pratique, car il oblige les équipes à classer chaque règle comme un problème de référence, de structure ou de règle métier. Si l'échec est dû à une ligne parente manquante, la correction est différente de celle d'un changement de schéma ou d'une violation de règle.

En quoi l'intégrité diffère de l'exactitude, de la validité et de la cohérence

L'intégrité n'est pas la même chose que l'exactitude, la validité ou la cohérence. Le moyen le plus simple de les séparer est de se demander quel type de défaillance chacun détecte.

Distinctions côte à côte

Un enregistrement peut être valide, exact et même cohérent, tout en échouant au niveau de l'intégrité. L'e-mail d'un client peut être au bon format, correspondre au CRM et refléter la personne réelle. Si cet identifiant client n'existe plus dans le système de commande, la relation est brisée et l'ensemble de données n'est plus digne de confiance.

Règle générale : utilisez des contrôles d'exactitude pour l'exactitude des valeurs, des contrôles de validité pour les règles de format et de domaine, des contrôles de cohérence pour la concordance entre les systèmes, et des contrôles d'intégrité pour les relations qui lient les données entre elles.

L'exactitude de la qualité des données est un point de comparaison utile car elle montre pourquoi l'exactitude des valeurs à elle seule ne protège pas le modèle, le rapport ou le grand livre. Les équipes de données ont besoin de chaque contrôle au bon endroit, et non d'un test global unique prétendant tout faire.

Comment mesurer la Data Integrity

La Data Integrity devient mesurable lorsque vous définissez les relations et les règles métier qui doivent être respectées pour un ensemble de données donné. La formule est simple, mais l'ensemble des règles qui la sous-tendent doit être explicite.

Un score d'intégrité simple

Taux d'intégrité = enregistrements satisfaisant aux conditions d'intégrité requises / enregistrements évalués × 100

Cette formule ne fonctionne que si l'équipe s'accorde sur les conditions prises en compte. Pour un pipeline, la condition peut être une clé étrangère valide. Pour un autre, il peut s'agir d'une règle de schéma plus un enregistrement parent plus une contrainte métier. La mesure dépend de la relation évaluée.

Métriques pratiques suivies par les équipes

• Taux de violation de l'intégrité référentielle, la fréquence à laquelle les liens pointent vers des parents manquants.

• Nombre d'enregistrements orphelins, le nombre de lignes enfants sans parent valide.

• Échecs des contrôles de relation, le nombre total de jointures ou de règles de dépendance brisées.

• Pourcentage d'enregistrements avec des références valides, une vue simple du taux de réussite.

• Nombre de relations brisées, utile pour le suivi des tendances d'une Release à l'autre.

• Taux de violation des règles métier, la proportion de lignes qui échouent à une règle définie.

Les métriques de qualité des données deviennent beaucoup plus utiles lorsqu'elles séparent la structure de la qualité des valeurs. Un tableau de bord propre doit montrer la santé des relations, et non pas seulement les taux de valeurs nulles et l'exhaustivité. Si la dérive de schéma, les contrôles de clés étrangères et les contrôles de règles échouent tous dans la même fenêtre, le score d'intégrité chute même si les valeurs semblent normales en surface.

Qu'est-ce que l'intégrité référentielle ?

L'intégrité référentielle signifie que les relations entre les entités liées restent valides. Chaque commande doit faire référence à un client existant, chaque facture doit faire référence à un compte existant et chaque identifiant produit doit exister dans le référentiel des produits.

Pourquoi les enregistrements orphelins sont un vrai problème

Une référence brisée crée un enregistrement orphelin. La ligne existe toujours, mais sa signification a été altérée car elle ne pointe plus vers un parent valide. La documentation de SQL Server de Microsoft le décrit clairement : une clé étrangère dépend de la clé primaire à laquelle elle fait référence, et les références à des valeurs inexistantes ne sont pas autorisées.

C'est pourquoi l'intégrité référentielle est souvent appliquée par le biais de contraintes de clé primaire et de clé étrangère, les contraintes CHECK aidant également à préserver les relations valides entre les tables. Si une clé change, toutes les références dépendantes doivent également changer de manière cohérente, sous peine de voir l'ensemble de données perdre sa signification.

Lorsqu'une ligne enfant ne trouve pas son parent, les données peuvent toujours se charger, mais la relation n'est plus digne de confiance.

Le tableau d'ensemble est préoccupant. L'Identity Theft Resource Center a signalé 3 322 compromissions de données aux États-Unis en 2025, soit une augmentation de 79 % sur cinq ans, et 471,2 millions de notifications aux victimes au cours du seul premier semestre 2026. Ces chiffres montrent pourquoi les équipes ne peuvent pas traiter les échecs relationnels comme des tâches de nettoyage mineures, car les problèmes d'intégrité font partie d'un environnement opérationnel et de risque plus large. Les conseils sur l'intégrité référentielle fournissent une définition opérationnelle simple : des relations valides entre les enregistrements liés constituent le mécanisme de base.

Comment la Data Integrity peut-elle être surveillée en continu ?

La surveillance de la Data Integrity fonctionne mieux en tant que contrôle continu, et non comme un audit trimestriel. Les contrôles planifiés détectent les problèmes après coup, tandis que la surveillance continue repère les relations brisées, les changements de schéma et les échecs de règles au fur et à mesure qu'ils se produisent.

À quoi ressemble une surveillance continue

Commencez par des seuils. Définissez ce qui est considéré comme normal pour les contrôles relationnels, le nombre d'orphelins, les changements de schéma et les échecs de règles métier. Alertez ensuite lorsque les données s'écartent de la plage attendue, et transmettez l'incident au bon propriétaire avec suffisamment de contexte pour corriger la cause profonde.

Un rythme opérationnel utile est simple :

1. Définir des KPI, tels que les taux de réussite des relations et le nombre de contraintes échouées.

2. Établir des références, pour que l'équipe sache à quoi ressemble une situation normale.

3. Alerter sur la dérive, plutôt que d'attendre qu'un rapport soit corrompu.

4. Effectuer une revue mensuelle, afin de rendre les problèmes récurrents visibles et corrigibles.

La dérive de schéma mérite une attention particulière car les modifications structurelles peuvent corrompre la signification en aval, même si les valeurs des lignes semblent toujours correctes. Les modifications de type, les colonnes renommées, les champs supprimés et les ajouts non coordonnés peuvent rompre la compatibilité ou invalider les transformations avant que quiconque ne s'en aperçoive.

Un exemple de commandes et de clients pour la surveillance de l'intégrité

Une ligne de commande avec customer_id = 4821 peut sembler parfaite et être pourtant erronée si le client 4821 a été supprimé du référentiel client au trimestre dernier. Le montant de la commande peut être correct, l'identifiant de la commande unique et le format de l'e-mail valide, alors que l'intégrité a déjà échoué.

Trois vérifications capturent des signaux différents

La Data Validation signale la référence invalide lorsque la commande pointe vers un client qui n'existe plus.
La Data Reconciliation compare les ensembles de données source et cible associés et fait ressortir l'écart entre ce que la table de commande attend et ce que contient le référentiel client.
Le Schema Tracker remarque le changement structurel qui a pu contribuer au problème, comme un champ supprimé ou renommé en amont.

Le pipeline lui-même peut toujours se terminer avec succès. C'est le piège. Un statut de tâche au vert ne signifie pas que la Data Integrity a survécu à l'exécution.

Comment l'incident doit être traité

L'équipe doit regrouper les trois signaux en un seul incident, et non en trois tickets distincts. Cela permet de rester concentré sur la cause profonde, qui peut être une règle de suppression manquante, une synchronisation interrompue ou une modification de schéma qui n'a pas été coordonnée avec les systèmes en aval. La bonne correction se situe généralement en amont, car le simple fait de corriger la ligne orpheline ne restaure pas la relation brisée.

Comment digna peut aider à soutenir la Data Integrity ?

digna Data Validation prend en charge les contrôles explicites de relations et de règles métier, ce qui est l'exigence fondamentale pour détecter les références brisées, les lignes orphelines et les violations de règles. digna Data Reconciliation aide à comparer les ensembles de données source et cible associés lorsque l'intégrité dépend de la cohérence entre les deux systèmes. digna Schema Tracker identifie les modifications structurelles ou de schéma qui peuvent affecter l'intégrité au fil du temps.

Ce que chaque module fait pour l'intégrité

La Data Validation est particulièrement adaptée aux contrôles au niveau des enregistrements. La Reconciliation est idéale lorsque l'intégrité dépend de la cohérence entre les systèmes. Le Schema Tracker constitue la couche d'alerte précoce pour les modifications structurelles susceptibles de rompre les hypothèses en aval.

La surveillance des schémas peut identifier des changements structurels susceptibles d'affecter l'intégrité ; elle ne prouve pas à elle seule que les données sont structurellement ou référentiellement correctes.

Cette distinction est importante car les équipes confondent parfois détection et preuve. Une alerte de schéma vous indique que la forme a changé. Elle ne confirme pas que chaque relation fonctionne toujours ou que chaque règle est toujours respectée.

Si votre équipe cherche à distinguer les données propres des données fiables, plongez dans les règles de relation, les modifications de schéma et les signaux de validation qui se trouvent sous le tableau de bord. Visitez digna pour voir comment ses capacités de validation, de réconciliation et de suivi des schémas peuvent soutenir la surveillance de la Data Integrity dans les systèmes que vous utilisez déjà.