Points clés
- La gouvernance de la qualité des données n'est pas un projet ponctuel. C'est une discipline opérationnelle continue.
- La propriété, les normes et l'application doivent exister au niveau des données, pas seulement dans les documents politiques.
- La plupart des défaillances proviennent d'une modélisation faible des données à la source, non d'un manque d'outils de surveillance.
- Intégrer les règles de qualité dans les pipelines de données prévient les problèmes au lieu de les signaler.
La plupart des organisations savent que leurs données posent des problèmes de qualité. Doublons dans les enregistrements de fournisseurs, attributs produits qui signifient des choses différentes selon les systèmes, valeurs manquantes qui ne remontent à la surface que lorsque quelqu'un essaie de générer un rapport. Ce qui est moins clair, c'est qui est responsable de ces problèmes et ce qu'il faudrait vraiment faire.
C'est ce fossé que la gouvernance de la qualité des données est censée combler.
Ce que la gouvernance de la qualité des données signifie vraiment
La gouvernance des données et la qualité des données sont liées mais ne sont pas la même chose. La gouvernance définit les règles : qui possède les données, comment elles sont classifiées, quelles normes s'appliquent, qui a accès. La qualité des données est le résultat opérationnel : si les données répondent réellement à ces normes à un moment donné.
La gouvernance de la qualité des données est le point de connexion entre les deux. C'est l'ensemble des processus, rôles et contrôles qui traduisent un cadre de gouvernance des données en résultats mesurables. La gestion de la qualité des données est l'exécution quotidienne de ce travail. Le résultat, quand les deux fonctionnent correctement, est l'intégrité des données : des enregistrements qui sont exacts, cohérents et fiables dans tous les systèmes qui les utilisent.
Un rapport 2025 de l'Institut IBM pour la valeur commerciale a révélé que 43 % des directeurs des opérations identifient les problèmes de qualité des données comme leur priorité principale en matière de données. Plus d'un quart des organisations estiment qu'elles perdent plus de 5 millions USD par an en raison d'une mauvaise qualité des données.
Ces pertes ne résultent rarement d'une seule mauvaise décision. Elles s'accumulent à partir de petites défaillances systémiques : pas de définition convenue de ce que « complet » signifie pour un enregistrement produit, pas de processus pour détecter les doublons avant qu'ils atteignent les systèmes en aval, personne responsable quand les données sortent des spécifications.
Le vrai mode de défaillance
Les entreprises ont tendance à traiter la qualité des données comme une tâche de nettoyage. Quelque chose ne va pas, une équipe exécute un script de correction, et le problème est fermé. Trois mois plus tard, le même problème est de retour.
La raison est structurelle. Si le modèle de données permet aux mauvaises données de passer à l'ingestion, et qu'aucune règle n'est appliquée à ce stade, le nettoyage des données est toujours réactif. Vous supprimez des problèmes après qu'ils se soient déjà propagés dans les rapports, les moteurs de tarification, les transactions ERP et les sorties orientées client.
Le plus grand prédicteur unique de la mauvaise qualité des données est un modèle de données jamais conçu en pensant à la qualité.
Dans les projets que nous avons implémentés pour les fabricants d'équipements industriels, la cause première était presque toujours la même : champs d'attributs définis en tant que texte libre, aucun vocabulaire contrôlé, aucun champ obligatoire au niveau du produit. Chaque équipe entrait les données différemment. Au moment où le catalogue atteignait la plateforme e-commerce, l'appariement et la déduplication exigeaient des semaines de travail manuel avant chaque cycle de lancement de produit.
Les cadres de gouvernance qui se concentrent uniquement sur la propriété et les politiques d'accès sans toucher au modèle de données sous-jacent ne régleront pas ce problème. La gouvernance de la qualité des données commence en amont, au point où les données sont définies et entrées, pas où elles sont rapportées.
À quoi ressemble un cadre qui fonctionne
La gouvernance de la qualité des données qui tient réellement en production nécessite cinq composants. Leur importance n'est pas égale, et l'ordre de mise en œuvre compte.
Dimensions de qualité définies avec des objectifs mesurables
L'exactitude, l'exhaustivité, la cohérence, la ponctualité, l'unicité, la validité et la conformité sont les dimensions fondamentales de la qualité des données. L'utilisabilité couvre si les données sont structurées de manière que les équipes en aval puissent réellement les utiliser, et vaut la peine d'être ajoutée quand les données traversent les limites des systèmes. Les définitions doivent être spécifiques. « L'exhaustivité » d'un enregistrement produit chez un distributeur de matériaux de construction pourrait signifier que les 14 attributs obligatoires sont remplis, y compris l'unité de mesure, la classification des risques et les dimensions d'emballage. Chaque dimension a également besoin d'un objectif, d'une méthode de mesure et d'une cadence d'examen. Sans ces trois choses, une dimension de qualité n'est qu'une étiquette.
Propriété des données au niveau des attributs
Assigner un propriétaire de données à une table ou un domaine est trop vague. La responsabilité de la qualité fonctionne quand elle se situe au niveau des attributs. Quelqu'un est responsable de l'exactitude du numéro de matériel. Quelqu'un d'autre possède les champs de description du produit. Quand un champ se dégrade, vous savez immédiatement à qui incombe le travail de le corriger. La plupart des organisations évitent ce niveau de spécificité jusqu'à ce qu'un audit réglementaire les y force. Des rôles de gouvernance des données clairs, définissant qui possède quoi et à quel niveau de granularité, sont ce qui prévient cela.
Règles de validation intégrées à l'ingestion
C'est là que la plupart des programmes de gouvernance de la qualité des données fonctionnent ou échouent. Les règles de qualité doivent s'activer au point où les données entrent dans un système. Un champ obligatoire laissé vide doit faire échouer l'enregistrement catégoriquement, pas le laisser passer et le signaler dans un rapport de qualité des données hebdomadaire trois jours plus tard. Une valeur en dehors d'un ensemble autorisé doit être rejetée lors de l'ingestion des données, avec un message d'erreur spécifique.
Nos clients dans l'espace de distribution d'équipements de sécurité viennent souvent nous voir après des années d'exécution de vérifications de qualité post-ingestion. Les vérifications existaient. Les problèmes de qualité des données n'ont pas disparu. La différence, une fois que la validation automatisée s'est déplacée en amont vers le pipeline d'ingestion des données lui-même, a été immédiate : les taux d'erreurs ont chuté, les cycles de reprise raccourcis, et les systèmes en aval ont cessé de recevoir des enregistrements corrompus. La normalisation des données, en appliquant les formats cohérents, les unités et les valeurs contrôlées à l'entrée, a fait que les métriques de qualité des données reflètent réellement la réalité plutôt que de mesurer la sortie d'un script de nettoyage.
Le profilage des données avant de construire les règles de validation compte ici. Si vous ne connaissez pas la distribution des valeurs dans un champ, l'éventail des formats utilisés ou où les valeurs nulles se regroupent, les règles que vous écrivez seront soit trop lâches soit trop strictes. Le profilage transforme les hypothèses en spécifications.
Pistes d'audit et lignage des données
Vous ne pouvez pas gouverner ce que vous ne pouvez pas tracer. Quand une spécification produit change, le système devrait enregistrer qui l'a changée, quand et à partir de quelle valeur. Quand un enregistrement échoue une vérification de qualité, il devrait y avoir un journal de la règle qui a échoué et de ce qui s'est passé ensuite.
Dans les environnements multi-systèmes, le lignage compte autant que la piste d'audit elle-même. Un enregistrement produit qui provient d'un ERP, passe par un PIM et publie sur trois canaux de vente peut se dégrader à n'importe quel point de cette chaîne. La gestion des métadonnées, en capturant d'où provient chaque champ et quelles transformations il a traversées, est ce qui rend possible de pointer le point d'entrée d'une défaillance. Un catalogue de données qui indexe ces métadonnées donne aux équipes un seul endroit pour tracer les problèmes sans interroger chaque système individuellement.
Approbations de flux de travail pour les modifications critiques des données
Les modifications apportées aux niveaux de tarification, aux classifications de produits ou aux attributs réglementaires nécessitent généralement un second examen avant d'être publiées. Dans les secteurs ayant des exigences strictes de conformité réglementaire, comme les produits chimiques, les dispositifs médicaux et les matières dangereuses, un flux de travail d'approbation n'est pas optionnel. C'est le mécanisme qui empêche les données gouvernées d'être écrasées sans enregistrement. L'étape d'approbation ne doit pas couvrir chaque modification, seulement celles où une erreur est coûteuse à annuler.
Ces cinq composants se renforcent mutuellement. La propriété sans règles de validation signifie que les gens responsables reçoivent toujours de mauvaises données. La validation sans lignage signifie que vous attrapez les erreurs mais que vous ne pouvez pas expliquer d'où elles viennent. Un programme de gouvernance de la qualité des données avec les cinq composants en place à un niveau basique surpassera celui qui construit un composant unique bien tout en laissant les autres sans adresse.
Le côté organisationnel est plus difficile que le côté technique
Les composants techniques de la gouvernance de la qualité des données sont bien compris. La partie la plus difficile est organisationnelle.
La plupart des entreprises ont plusieurs équipes qui touchent les mêmes données. L'équipe ERP possède le fichier article. L'équipe marketing gère le contenu produit. L'équipe logistique met à jour les données dimensionnelles. Aucune d'entre elles ne rapporte à l'autre, et leurs incitations pour la qualité des données sont différentes. Une équipe de gouvernance des données, ou du moins un groupe de gouvernance interfonctionnel, est ce qui donne aux organisations un moyen de résoudre ces conflits sans escalader chaque différend de données à la direction générale.
Sans une fonction de gouvernance des données qui traverse les limites organisationnelles, les politiques de gouvernance ont tendance à être suivies par ceux qui les ont écrites et ignorées par tous les autres.
Un rôle de gestionnaire des données n'a pas besoin d'être un poste à temps plein. Dans les petites opérations, cela peut être une responsabilité désignée pour quelqu'un déjà proche des données. Ce qui compte, c'est que quelqu'un soit responsable des résultats de qualité, ait l'autorité d'appliquer les normes et ait une visibilité sur les systèmes où les données vivent.
Les examens réguliers de la qualité des données, avec des métriques convenues et la participation des parties intéressées, sont ce qui empêche un programme de gouvernance de la qualité des données de devenir un document que personne ne lit après le lancement initial.
Les outils soutiennent la gouvernance. Ils ne la remplacent pas.
Il existe une catégorie de logiciels commercialisés comme des plateformes « de qualité des données » ou « de gouvernance des données ». Certains font du vrai travail. Mais sans structures de propriété, normes définies et logique de validation en place, les outils ajoutent des tableaux de bord à un problème qui n'a pas encore de propriétaire.
Un outil de surveillance de la qualité des données montre où la qualité se dégrade. C'est une information utile. Mais s'il n'y a pas de normes définies pour mesurer, le tableau de bord affiche des nombres sans contexte. S'il n'y a pas de structure de propriété, il montre des problèmes dont personne n'est responsable de résoudre. L'outil devient la preuve d'une lacune en gouvernance de la qualité des données, pas une solution à celle-ci.
AtroCore adopte la position que la gouvernance de la qualité des données doit être appliquée au niveau du modèle de données. Sa plateforme de gestion des données maitresses utilise un modèle de données basé sur EAV qui permet aux organisations de définir quels attributs sont obligatoires, quelles valeurs sont valides et quelles modifications nécessitent une approbation avant d'être appliquées. Le résultat est une source unique de vérité pour le produit, le fournisseur et les autres données maitresses : des données fiables qui restent cohérentes dans tous les systèmes connectés. Les pistes d'audit et la synchronisation bidirectionnelle avec les ERP et les plateformes e-commerce signifient que les contrôles de qualité des données suivent l'enregistrement sur tout le cycle de vie, couvrant chaque système auquel les données accèdent.
Par où commencer
Commencez par les entités de données causant les dégâts les plus importants en aval. Pour les fabricants et les distributeurs, c'est généralement le fichier produit ou l'enregistrement du fournisseur. Cartographiez quels attributs existent, qui les remplit, et à quoi ressemblent actuellement les taux de remplissage et les taux d'exactitude. Cet audit révélera les trois à cinq défaillances dignes d'être adressées en premier dans votre effort de gouvernance de la qualité des données.
Établissez la propriété pour ces attributs spécifiques avant d'acheter un quelconque outil. Écrivez des règles de qualité qui sont spécifiques suffisamment pour être testables. « Les descriptions de produits doivent être exactes » n'est pas une règle. « Les descriptions de produits doivent être entre 100 et 500 caractères, ne contenir aucune balise HTML et être remplies pour tous les SKU actifs » est une règle. Des données fiables découlent de ce type de spécificité. Rien d'autre ne la produit.
La gouvernance de la qualité des données échoue quand les organisations la traitent comme un projet avec une date limite. Les entreprises qui s'en tirent bien la traitent comme une propriété opérationnelle de leur infrastructure de données, construite dans la manière dont les données sont créées, déplacées et modifiées, puis soutenue en tant que discipline continue.