Les données ne restent pas fiables d'elles-mêmes. Elles proviennent de plusieurs sources, sont transformées par différents systèmes, et arrivent dans les rapports, tableaux de bord ou catalogues de produits sur lesquels les gens s'appuient pour prendre des décisions. À chaque étape, quelque chose peut mal tourner : un champ disparaît, un format se casse, une valeur se duplique. La surveillance de la qualité des données, c'est la façon de détecter ces problèmes avant qu'ils ne causent de vrais dégâts.
Gartner estime que la mauvaise qualité des données coûte aux organisations en moyenne 12,9 millions de dollars par an. Un rapport 2025 de l'IBM Institute for Business Value a révélé que 43 % des directeurs des opérations ont identifié les problèmes de qualité des données comme leur défi majeur en matière de gestion des données. Le problème est répandu, le coût est mesurable, et il se corrige rarement sans un processus de surveillance délibéré.
Ce qu'est réellement la surveillance de la qualité des données
La surveillance de la qualité des données est la pratique consistant à mesurer continuellement si vos données répondent à des normes définies, et à vous alerter quand ce n'est pas le cas. Le mot clé est continuellement. Un audit unique détecte les problèmes qui existaient à un moment donné. La surveillance détecte les problèmes de qualité des données dès qu'ils apparaissent, ce qui est la seule façon d'agir avant qu'ils ne se propagent en aval.
Elle diffère des tests de données, qui vérifient des problèmes connus et spécifiques. La surveillance est plus large. Elle suit les changements dans la qualité des données au fil du temps, signale les anomalies, et vous donne une ligne de base pour la comparaison. Quand un champ d'attribut de produit qui est normalement complet à 98 % chute soudainement à 60 %, la surveillance le détecte. Un test ponctuel ne le ferait pas.
Certaines équipes rencontrent également le terme observabilité des données, qui fait référence à la visibilité complète de la santé des pipelines de données : si les données sont arrivées à l'heure, si le schéma a changé de manière inattendue, si le volume semble normal. La surveillance de la qualité des données et l'observabilité des données se chevauchent considérablement. L'observabilité tend à se concentrer sur le comportement du pipeline. La surveillance de la qualité se concentre sur les données elles-mêmes. En pratique, les deux sont nécessaires. Ensemble, ils forment la colonne vertébrale opérationnelle de tout programme sérieux de gestion de la qualité des données.
Les dimensions que vous surveillez réellement
Tout programme de surveillance de la qualité des données fonctionne en mesurant les données par rapport à un ensemble de dimensions définies. Les plus suivies sont :
- Complétude. Tous les champs obligatoires sont remplis. Pour un fabricant gérant des milliers de SKU, une absence de poids ou de classification de danger peut empêcher un produit d'être mis en ligne sur un canal. Les taux de valeurs nulles et les valeurs manquantes sont les métriques standards ici.
- Exactitude. Les données reflètent la réalité. C'est plus difficile à automatiser car cela nécessite souvent une source de référence ou une source unique de vérité.
- Cohérence. Les mêmes données ressemblent à la même chose dans tous les systèmes. Un produit décrit différemment dans l'ERP par rapport au PIM par rapport au webshop crée des frictions au minimum, des erreurs au pire.
- Actualité. Les données sont suffisamment actuelles pour être utiles. Les défaillances de fraîcheur des données sont courantes dans les flux de fournisseurs et dans tout pipeline avec un délai d'ingestion long.
- Validité. Les données respectent les formats et règles définies. La validation du schéma détecte cela lors de l'ingestion. Une adresse e-mail sans @, ou une date au mauvais format, est techniquement présente mais fonctionnellement inutile.
- Unicité. Aucun enregistrement en double ne crée de bruit ou d'incohérence dans les systèmes en aval.
En pratique, vous ne surveillerez pas toutes les dimensions de la même façon pour tous les ensembles de données. Identifiez les dimensions les plus importantes pour chaque domaine de données et définissez les seuils en conséquence. Un score de qualité des données ou une fiche de score qui regroupe ces dimensions dans une vue unique par domaine donne aux équipes et aux responsables des données un moyen pratique de suivre les progrès au fil du temps et de rapporter les KPI de qualité des données.
Ce à surveiller et où
Commencez par les données qui alimentent vos processus les plus critiques. Pour les fabricants, cela signifie généralement les données maîtres de produits : les attributs, spécifications et classifications qui s'écoulent dans tous les systèmes en aval. Pour les équipes opérationnelles, il peut s'agir de données transactionnelles ou d'enregistrements clients.
Les points de surveillance doivent correspondre aux endroits où les données peuvent se dégrader.
À l'ingestion.
Quand les données arrivent d'une source externe (un fournisseur, un ERP, un flux tiers), c'est là que les problèmes de format, les valeurs manquantes et les changements de schéma ont tendance à apparaître en premier. Les détecter ici empêche les mauvaises données d'entrer dans votre environnement. Les vérifications de qualité des données lors de l'ingestion sont le correctif le moins cher du pipeline. Le coût de la correction augmente à chaque étape suivante.
Dans la transformation.
Les pipelines ETL qui déplacent et remodèlent les données peuvent introduire des erreurs : champs supprimés, valeurs mal mappées, problèmes d'encodage. La surveillance des résultats de transformation par rapport aux schémas attendus et aux plages de valeurs détecte cette catégorie de problèmes. La dérive des données (changements graduels dans les distributions de valeurs au fil du temps) est un risque spécifique ici que le profilage statistique détecte.
Dans l'enregistrement maître.
L'enregistrement central dans un PIM, MDM ou système de gestion des données maîtres doit être vérifié par rapport aux règles de complétude et à la logique métier avant toute publication. Un enregistrement de produit sans images et sans description ne devrait pas atteindre un canal de vente indépendamment de ce qui d'autre semble correct.
À la distribution.
Quand les données sont poussées vers un canal, une place de marché ou un système en aval, une validation des données finale confirme que ce qui est arrivé correspond à ce qui a été envoyé.
Techniques clés
La validation basée sur les règles définit des contraintes explicites (plages de valeurs, champs obligatoires, modèles de format, vérifications de référence) et signale tout enregistrement qui les viole. C'est déterministe et rapide. La limitation est qu'elle ne détecte que ce à quoi vous avez déjà pensé à vérifier. Un glossaire métier partagé aide ici : quand les règles sont liées à des définitions convenues, elles sont plus faciles à maintenir et plus difficiles à ignorer.
Le profilage statistique établit des lignes de base et surveille la dérive. Si la longueur moyenne des descriptions de produits est généralement de 180 caractères et chute soudainement à 40, c'est un signal qui mérite une investigation même si aucune règle spécifique n'a été enfreinte. Le profilage détecte les anomalies que la validation basée sur les règles manque.
La détection des doublons compare les enregistrements pour identifier les quasi-correspondances, pas seulement les doublons exacts. Les enregistrements de produits avec des noms légèrement différents mais le même EAN, ou les enregistrements clients avec des caractères transposés dans un nom, nécessitent une logique de correspondance floue pour être détectés.
Les vérifications d'intégrité référentielle vérifient que les relations entre les ensembles de données sont maintenues. Un produit assigné à une catégorie qui n'existe plus, ou une commande liée à un enregistrement client qui a été supprimé, est une violation d'intégrité qui crée des problèmes en aval.
Le suivi de la lignée des données documente d'où viennent les données et comment elles ont été transformées. Quand un problème de qualité des données apparaît dans un rapport, la lignée vous permet de le retracer jusqu'à la source plutôt que de deviner. Elle soutient aussi l'analyse des causes profondes : quel système en amont a introduit le problème, et quels systèmes en aval sont affectés. Un catalogue de données qui capture cette lignée rend le suivi opérationnellement utile plutôt que simplement théorique.
La surveillance en temps réel étend ces vérifications aux environnements de données en continu. Là où la surveillance par lot détecte les problèmes à intervalles réguliers, la surveillance en temps réel signale les problèmes dès que les données entrent ou se déplacent dans le pipeline. Pour les environnements de données à haute vélocité, l'écart entre la détection et l'impact peut être très court. Les vérifications en temps réel réduisent considérablement cette fenêtre.
Construire un processus de surveillance
Les outils ne résolvent pas le problème par eux-mêmes. Quelques éléments doivent être en place avant que les vérifications automatisées de qualité des données apportent une vraie valeur.
Responsabilité définie.
Quelqu'un doit être responsable de la qualité des données dans chaque domaine. Sans responsabilité, les alertes sont ignorées et rien ne s'améliore. Dans les plus grandes organisations, cela correspond à des rôles de responsable des données. Dans les plus petites, c'est généralement la personne qui possède le système.
Seuils convenus.
Un taux de complétude de 95 % peut être acceptable pour un champ d'attribut supplémentaire et complètement inacceptable pour un attribut réglementaire obligatoire. Les seuils doivent refléter l'impact métier, pas seulement les valeurs par défaut techniques. Liez-les aux KPI de qualité des données qui ont du sens pour l'entreprise.
Règles documentées.
Chaque règle de validation devrait avoir une justification métier attachée. Les règles que personne ne peut expliquer ont tendance à être ignorées ou supprimées quand elles déclenchent des alertes gênantes. La documentation force la clarté sur ce qui est bon, et lie les normes de qualité des données à la politique de gouvernance des données.
Un processus pour gérer les problèmes.
La surveillance crée des alertes. Les alertes doivent aller quelque part d'utile : un tableau de bord de qualité des données que quelqu'un consulte, un flux de tickets, une notification à la bonne personne. La surveillance sans un chemin de correction clair, incluant les flux de nettoyage des données et de validation des données, ne crée que du bruit.
Dans les projets que nous avons soutenus, un modèle récurrent est les organisations qui investissent dans les outils de surveillance mais n'ont pas résolu la question de la responsabilité. Le système détecte les problèmes mais rien ne s'améliore, car il est peu clair de qui est la responsabilité d'agir. Le problème est organisationnel, pas technique.
Les données de produits comme domaine intensif en surveillance
Les données de produits méritent une attention particulière car le volume et la vélocité des changements sont élevés, et les problèmes de qualité des données sont directement visibles. Une dimension incorrecte sur une fiche technique, une classification de sécurité manquante, une unité incorrecte : ces éléments sont vus par les clients, les revendeurs et les autorités réglementaires.
Les fabricants avec de grands catalogues gèrent des enregistrements qui évoluent constamment : nouvelles variantes, spécifications mises à jour, additions d'attributs réglementaires, adaptations spécifiques au canal. Chaque changement est un événement de qualité potentiel. Et contrairement à un tableau de bord interne cassé, un mauvais enregistrement de produit est vu par des personnes en dehors de l'organisation.
Un PIM ou MDM avec des règles de qualité des données intégrées couvre une grande partie de la surveillance basée sur les règles. Mais le score de complétude, l'alerte de seuil et les vérifications de cohérence entre systèmes nécessitent une configuration qui reflète le modèle d'attribut spécifique et les exigences de canal de l'entreprise. Les règles génériques prêtes à l'emploi s'alignent rarement avec ce qu'un fabricant spécifique a réellement besoin.
Pour les équipes qui ont besoin de ce niveau de contrôle, AtroCore supporte les règles de validation configurables et le score de complétude au niveau de l'attribut et de l'entité. Parce qu'il est open-source et modulaire, les vérifications de qualité des données peuvent s'intégrer dans des pipelines de données plus larges et se connecter à des systèmes externes plutôt que de rester isolées dans la plateforme de données maîtres.
Modes de défaillance courants
Quelques modèles apparaissent régulièrement quand la surveillance ne fonctionne pas.
La surveillance uniquement des ensembles de données que vous considérez comme « importants » crée des zones d'ombre. Les problèmes de qualité des données se propagent d'où qu'ils proviennent. Définir les seuils une fois et ne jamais les revoir conduit à la fatigue d'alerte ou à des problèmes manqués. Les deux causent le même résultat : la surveillance est ignorée.
Une troisième défaillance est purement opérationnelle : acheter et déployer un outil sans le configurer au modèle de données réel. Les règles par défaut détectent les problèmes évidents dans les ensembles de données génériques. Elles manquent les contraintes spécifiques au domaine qui importent le plus, comme un champ de certification obligatoire pour les produits réglementés ou un attribut d'image obligatoire avant qu'un enregistrement ne soit en ligne. Un programme de surveillance construit sur des valeurs par défaut est mieux que rien, mais pas beaucoup.
La défaillance la plus courante, cependant, est de traiter la surveillance de la qualité des données comme un projet technique plutôt que comme une discipline de gestion des données. Si les personnes qui agissent sur les alertes ne comprennent pas ce qu'elles signifient ou pourquoi elles importent, l'infrastructure de surveillance génère simplement des rapports que personne ne lit. L'assurance de la qualité des données fonctionne uniquement quand les résultats techniques se connectent à la responsabilité métier.
Où l'automatisation s'intègre
L'automatisation gère le volume. Un catalogue de produits avec 50 000 SKU ne peut pas être validé manuellement au niveau de l'attribut. Il en va de même pour tout environnement de données à haut volume. Les vérifications automatisées de qualité des données s'exécutant continuellement à travers les pipelines sont la seule façon pratique de maintenir la fiabilité des données à l'échelle.
Ce que l'automatisation ne fait pas bien, c'est le jugement. Quand une alerte se déclenche, une personne doit évaluer si c'est un vrai problème, un faux positif, ou un signal que la règle elle-même a besoin de mise à jour. L'automatisation réduit l'ensemble des choses nécessitant l'attention humaine. Elle n'élimine pas ce besoin.
La détection d'anomalies assistée par l'IA étend la couverture en révélant des modèles inattendus sans règles prédéfinies. Elle fonctionne mieux comme complément de la surveillance basée sur les règles, puisque les faux positifs sont courants et la logique n'est pas toujours transparente. La plupart des équipes bénéficient de la combinaison des deux : les vérifications basées sur les règles pour les contraintes connues, la surveillance basée sur les statistiques ou l'apprentissage automatique pour la dérive et les dégradations inconnues.
Commencer
Le point de départ pratique est plus étroit que ce que la plupart des équipes s'attendent. Plutôt que de tenter de surveiller tout à la fois, choisissez un domaine de données et suivez cette séquence :
- Définissez ce qu'est bon. Identifiez les champs obligatoires, les plages de valeurs acceptables, les normes de format et toute règle de cohérence entre systèmes qui s'applique. Ceci est la fondation de votre cadre de qualité des données pour ce domaine.
- Définissez des seuils mesurables pour chaque dimension de qualité. Liez-les aux conséquences métier, pas aux préférences techniques.
- Assignez la propriété. Un responsable des données ou une équipe par domaine, avec un mandat clair d'agir sur les alertes.
- Instrumentez les vérifications de qualité des données. La validation basée sur les règles et la validation de schéma en premier, le profilage statistique une fois que les lignes de base existent.
- Construisez le processus de correction. Décidez où vont les alertes, qui les révise, et comment le nettoyage des données et les corrections sont suivis.
- Révisez et ajustez. Après le premier mois, revisitez les paramètres de seuil. Certains seront trop sensibles ; d'autres trop lâches.
Élargissez à des domaines supplémentaires une fois que le processus fonctionne à petite échelle. Un programme de surveillance de la qualité des données qui couvre bien un domaine est plus utile que celui qui couvre tout mal.