Les principales causes de la mauvaise qualité des données en entreprise

Dans la plupart des organisations, la mauvaise qualité des données est un problème reconnu mais rarement compris. On en parle dans les comités, on lance des chantiers de nettoyage, on déploie des outils. Quelques mois plus tard, les mêmes anomalies réapparaissent, sur les mêmes périmètres, avec les mêmes effets. Les équipes ressaisissent, recroisent, recroisent encore. Et la confiance dans les tableaux de bord continue de s'éroder.

Le réflexe le plus courant face à une donnée fausse, c'est de la corriger. Une adresse mal orthographiée, un doublon client, un statut de contrat incohérent : on rectifie, on documente, on referme le ticket. Le problème, c'est que cette logique ne traite jamais la raison pour laquelle l'erreur a été produite. Tant qu'on ne remonte pas à la cause, on rejoue indéfiniment le même scénario.

Soyons honnêtes : la qualité des données ne se dégrade pas par hasard. Elle se dégrade parce que des règles métier ne sont pas écrites, parce que personne n'est responsable d'un référentiel, parce que les systèmes ne se parlent pas, parce que les saisies sont libres là où elles devraient être contraintes, et parce que le cycle de vie de la donnée n'est piloté par personne. Ce sont des causes structurelles, pas des accidents isolés.

Cet article passe en revue les cinq causes les plus fréquentes de mauvaise qualité des données en entreprise. Pour chacune, l'objectif est le même : comprendre comment elle se manifeste, pourquoi elle perdure, et ce qu'on peut faire pour la traiter à la racine. Une dernière partie propose quatre leviers concrets pour passer à l'action.

‍

Pourquoi remonter aux causes racines de la mauvaise qualité des données ?

Dans la majorité des organisations, le traitement de la non-qualité reste curatif : on attend que l'erreur soit visible (un dashboard incohérent, une facture rejetée, une alerte régulateur) pour intervenir. Cette approche a un coût caché énorme. Elle mobilise des équipes en pompiers permanents, elle ne produit aucun apprentissage durable, et elle finit par installer l'idée que la donnée est intrinsèquement peu fiable.

Remonter aux causes racines, c'est changer de posture. Ce n'est plus traiter la donnée erronée, c'est traiter le processus qui l'a produite. C'est exactement ce que recouvre une démarche d'audit qualité des données bien menée : ne pas s'arrêter au constat d'anomalie, mais comprendre comment elle est apparue, à quelle étape, et qui en est responsable.

Symptôme ou cause : comment faire la différence

La confusion entre symptôme et cause est probablement le piège le plus fréquent dans les projets qualité. Un doublon client n'est pas une cause, c'est un symptôme. Une date de naissance manquante n'est pas une cause, c'est un symptôme. La cause se situe en amont : dans la manière dont la donnée a été collectée, contrôlée, ou propagée.

Test simple : si on corrige la donnée et que rien d'autre ne change dans le processus, on a traité un symptôme. Si la même anomalie réapparaît dans les semaines qui suivent, c'est la preuve que la cause est encore en place.

Quelques exemples pour clarifier :

• Symptôme : 12 % de nos fiches clients ont des e-mails invalides. Cause possible : le formulaire web n'applique aucune règle de validation au moment de la saisie.
• Symptôme : les chiffres du CRM et de la facturation ne se réconcilient pas. Cause possible : les deux systèmes utilisent deux définitions différentes du statut « client actif », sans règle commune arbitrée.
• Symptôme : personne ne sait quelle base produit fait foi. Cause possible : aucun Data Owner n'a été désigné sur le référentiel produit, donc aucune décision n'est tranchée.

Dans chaque cas, corriger la donnée sans toucher à la cause garantit la récidive. C'est ce qui explique que tant d'organisations aient l'impression de nettoyer en boucle, sans jamais progresser.

Ce qu'on gagne à traiter la cause plutôt que l'erreur

Quand on s'attaque à la cause, plusieurs choses changent en parallèle.

D'abord, la charge de correction baisse mécaniquement. Une règle de validation posée à la source empêche des centaines d'anomalies de se créer chaque mois. Un Data Owner nommé sur un référentiel évite des dizaines d'arbitrages perdus. Une intégration mieux conçue supprime des heures de réconciliation manuelle. Ce qu'on investit dans la cause, on le récupère ailleurs.

Ensuite, la qualité devient mesurable dans la durée. Tant qu'on corrige au coup par coup, on n'a pas de baseline : on ne sait pas si on progresse. Quand on traite les causes, on peut suivre l'évolution des indicateurs (taux de complétude, taux d'unicité, taux de conformité aux règles métier) et observer un effet réel sur le temps long.

Enfin, la confiance se reconstruit. Les utilisateurs métier cessent de doubler chaque chiffre par un fichier Excel personnel. Les comités arrêtent de débattre des chiffres et débattent enfin des décisions. C'est moins spectaculaire qu'un grand chantier de nettoyage, mais c'est ce qui change réellement le quotidien.

Cause n°1 : les erreurs de saisie à l'origine de la mauvaise qualité des données

C'est la cause la plus universellement citée, et celle qui est la plus mal traitée. Quand on évoque la mauvaise qualité des données, l'image qui vient en premier est celle d'un opérateur qui se trompe en remplissant un formulaire. C'est vrai, mais c'est très réducteur. La réalité, c'est que l'erreur de saisie est presque toujours le symptôme d'un défaut de conception en amont.

Une saisie produit une erreur quand le système ne l'empêche pas. Si un champ d'adresse e-mail accepte n'importe quelle chaîne de caractères, on aura des e-mails sans @. Si une date de naissance peut être saisie au format libre, on aura des dates en JJ/MM/AAAA, AAAA-MM-JJ, et parfois en texte. Si un champ « pays » est une zone de texte ouverte, on aura quinze orthographes différentes pour « France » dans la même base. Ce n'est pas l'opérateur qui produit l'erreur, c'est l'absence de contrôle qui la laisse passer.

Les facteurs qui aggravent la fréquence des erreurs de saisie sont presque toujours les mêmes :

• Absence de contrainte technique : champs libres là où ils devraient être contraints (listes déroulantes, formats imposés, validations bloquantes sur les e-mails et téléphones).
• Pression sur le temps de traitement : quand une équipe est mesurée sur le nombre de fiches saisies par heure, la qualité passe systématiquement après.
• Absence de retour sur erreur : quand un opérateur ne voit jamais les conséquences d'une donnée mal saisie, il n'a aucune raison d'y prêter attention.
• Manque de documentation : un champ dont personne ne connaît la définition exacte sera rempli différemment par chaque utilisateur.
• Duplication de saisie : quand la même information doit être saisie dans trois systèmes différents, les écarts entre les trois sont garantis.

Traiter cette cause ne se résume pas à former les équipes. La formation aide, mais elle ne tient pas dans la durée si l'environnement de saisie ne change pas. La vraie réponse est technique et organisationnelle : contraindre la saisie par construction (formats, listes fermées, validations bloquantes), réduire le nombre de points de saisie (un seul système source par information), et organiser un retour rapide sur les erreurs détectées en aval.

Cause n°2 : l'absence de règles métier qui dégrade la qualité des données

Si la première cause concerne le « comment » de la saisie, la deuxième concerne le « quoi ». Une donnée peut être techniquement bien formée et fausse dans son contenu, parce que personne n'a défini ce qu'elle doit représenter. La règle métier, c'est ce qui transforme un champ rempli en information fiable.

Prenons un exemple : le champ « date de fin de contrat client ». Techniquement, c'est une date, donc le format est contraint. Mais que veut-elle dire exactement ? La date de fin contractuelle initiale ? La date de fin effective après renouvellement ? La date à laquelle le client peut résilier ? La date à laquelle la facturation s'arrête ? Si quatre équipes utilisent le même champ avec quatre interprétations différentes, la donnée est parfaitement valide d'un point de vue technique, et totalement inutilisable d'un point de vue métier.

L'absence de règles métier prend plusieurs formes :

• Pas de définition partagée : chaque équipe a sa propre notion de ce qu'est un « client actif », un « projet en cours », un « produit lancé ». Les chiffres ne se réconcilient jamais parce qu'ils ne mesurent pas la même chose.
• Pas de règles de calcul documentées : un même indicateur (chiffre d'affaires, marge, taux de conversion) peut être calculé de cinq manières dans cinq outils, sans que personne ne sache laquelle fait foi.
• Pas de règles de cohérence inter-champs : rien n'empêche techniquement qu'un contrat ait une date de fin antérieure à sa date de début, qu'un employé soit rattaché à un département qui n'existe plus, qu'un produit ait un prix négatif.
• Pas de gestion des cas particuliers : que faire d'une donnée incomplète mais utilisable ? Que faire d'un doublon partiel ? Sans règle, chaque utilisateur décide pour lui, et les divergences s'accumulent.

Cette absence de règles métier explique pourquoi tant d'organisations ont l'impression que leur qualité ne s'améliore pas, malgré les investissements outils. Un outil de Data Quality ne peut contrôler que ce qu'on lui demande de contrôler. Si les règles ne sont pas écrites, l'outil ne fait rien d'autre que détecter des doublons triviaux et des champs vides. Il ne détecte pas les incohérences métier, parce que personne ne lui a appris à les reconnaître.

Une règle écrite est une règle qu'on peut automatiser. Une règle non écrite est une règle qu'on rejouera à l'oral dans chaque comité, sans jamais converger.

Cause n°3 : les silos de données entre systèmes et les défauts d'intégration

La troisième cause concerne ce qui se passe quand la donnée doit circuler entre systèmes. C'est probablement la plus sous-estimée dans les analyses de qualité, parce qu'elle est invisible côté utilisateur : la donnée a l'air correcte à l'écran, mais elle ne correspond plus à la réalité de l'autre côté du pipeline.

Une organisation moyenne fait coexister une quinzaine de systèmes qui stockent ou produisent des données : CRM, ERP, RH, outils marketing, facturation, e-commerce, BI, et ainsi de suite. Chacun a été choisi pour répondre à un besoin métier précis, à un moment donné, par une équipe donnée. La logique d'intégration entre les systèmes vient toujours après, et souvent jamais.

Le résultat : la même information existe dans plusieurs systèmes, sous des formats différents, mise à jour à des rythmes différents, avec des règles de calcul différentes. Quand on demande « combien de clients avons-nous ? », chaque système a sa propre réponse. Et aucune n'est totalement fausse.

Les manifestations concrètes sont nombreuses : doublons inter-systèmes (le même client créé trois fois avec trois identifiants), décalages temporels (une donnée modifiée dans le système A met 48 heures à arriver dans B), transformations silencieuses lors des transferts ETL non documentés, données orphelines (commandes référençant un produit supprimé), référentiels concurrents (plusieurs versions du catalogue produit sans arbitrage).

Le piège classique, c'est de croire qu'on va résoudre tout cela par un outil unique. « On va déployer un MDM et tout sera réglé. » C'est rarement vrai. Un outil MDM est un excellent moyen de structurer la gestion des référentiels maîtres, mais il ne résout rien tant que les règles de qualité, les responsabilités et les processus de mise à jour ne sont pas définis en amont. L'outil ne crée pas la gouvernance, il l'instrumente.

Une approche plus réaliste consiste à attaquer les silos par leurs points de douleur réels. Quel référentiel coûte le plus à l'entreprise quand il diverge ? Quelle intégration produit le plus de tickets de support ? Quel processus métier souffre le plus des écarts ? On part de ces points-là, on identifie le système source légitime, on pose les règles de propagation, et on met en place les contrôles qui détectent les divergences avant qu'elles n'arrivent chez l'utilisateur.

Cause n°4 : l'absence de Data Owner, cause structurelle de mauvaise qualité des données

Les trois premières causes sont avant tout techniques et méthodologiques. La quatrième est organisationnelle, et c'est probablement celle qui pèse le plus lourd dans la durée. Tant qu'une donnée n'a pas de propriétaire métier identifié, sa qualité ne s'améliorera pas durablement. Quels que soient les outils, quels que soient les chantiers, quelle que soit la pression de la direction.

La raison est simple : sans propriétaire, personne n'arbitre. Les ateliers qualité produisent des recommandations qui ne sont jamais tranchées. Les contrôles automatisés détectent des anomalies que personne ne traite. Les définitions métier restent floues parce que personne n'est légitime pour les figer. Une donnée sans propriétaire est une donnée sans destin.

Le rôle de Data Owner répond précisément à cette lacune. C'est un responsable métier, pas un profil IT, qui porte la responsabilité fonctionnelle d'un périmètre de données : il décide de ce que la donnée doit représenter, il arbitre les conflits d'usage, il valide les règles, il priorise les actions d'amélioration. Le trio Data Owner, Data Steward, Data Custodian structure cette chaîne de responsabilité, du « pourquoi » métier au « comment » technique.

Pourquoi ce rôle est-il si souvent absent ou mal incarné ? Plusieurs raisons s'accumulent :

• Rôle confondu avec un rôle technique : les organisations le confient à la DSI ou à un Data Steward, qui n'a pas la légitimité métier pour arbitrer. Le Data Owner doit être un manager opérationnel d'un domaine (commercial, RH, finance, supply chain), pas un expert technique.
• Rôle jamais formalisé : on parle de « propriétaire de la donnée » dans les comités, sans jamais nommer la personne, sans jamais inscrire la responsabilité dans la fiche de poste. Résultat, personne ne se sent comptable.
• Charge sous-estimée : être Data Owner, ce n'est pas un titre honorifique, c'est un temps de travail réel (10 à 20 % d'un ETP selon les périmètres). Sans temps dédié, la fonction ne s'exerce pas.
• Data Owner isolé : sans relais opérationnel (typiquement un Data Steward), il ne peut pas exécuter ce qu'il décide. Le binôme Owner / Steward est la combinaison qui fonctionne, pas l'Owner seul.

L'absence de Data Owner produit un cercle vicieux particulièrement difficile à briser. Sans Owner, les règles ne sont pas écrites. Sans règles, les contrôles ne peuvent pas être posés. Sans contrôles, les erreurs s'accumulent. Une fois que les erreurs sont massives, il faut un effort énorme pour les corriger, et personne n'est légitime pour piloter l'effort. L'organisation s'installe dans une médiocrité durable, qu'elle finit par accepter comme une fatalité.

À l'inverse, nommer un Data Owner crédible sur un périmètre critique change rapidement la dynamique. En quelques mois, le périmètre est documenté, les règles sont posées, les écarts diminuent. Pas parce que l'Owner fait tout le travail seul, mais parce qu'il rend possibles toutes les actions qui étaient bloquées par l'absence d'arbitre.

👉 À lire aussi : Qui sont les garants de la qualité des données ?

Cause n°5 : un cycle de vie de la donnée non maîtrisé

La cinquième cause est la plus systémique, et celle qui apparaît quand on prend de la hauteur. La donnée n'est pas une entité figée : elle naît, elle est utilisée, elle est transformée, elle vieillit, elle devient obsolète, et idéalement elle est archivée ou supprimée. Ce parcours, c'est le cycle de vie de la donnée, et il est presque toujours sous-piloté dans les organisations.

Le symptôme le plus visible, c'est l'accumulation. Les bases enflent indéfiniment, parce qu'on ne supprime jamais rien. Les contacts inactifs depuis dix ans cohabitent avec les prospects de la semaine. Les produits référencés en 2008 et plus jamais commercialisés restent dans le catalogue. Les comptes utilisateurs d'anciens collaborateurs restent ouverts. Cette accumulation produit deux effets : elle dégrade la qualité (chaque donnée morte est une donnée potentiellement fausse), et elle augmente le coût de tous les traitements en aval.

L'absence de pilotage du cycle de vie concerne chaque étape du parcours :

• Création : qui décide qu'une donnée nouvelle peut exister ? Sur quels critères ? Combien de bases parallèles ont été créées « pour dépanner » et n'ont jamais été supprimées ?
• Mise à jour : à quelle fréquence la donnée doit-elle être rafraîchie ? Qui est responsable de la mise à jour ? Quel délai est acceptable entre la réalité et le système ?
• Usage : qui peut consulter la donnée, la modifier, l'exporter ? Sans règle d'usage claire, les exports sauvages se multiplient et créent des copies parallèles qui divergent.
• Archivage : à quel moment une donnée passe-t-elle d'un état actif à un état archivé ? Sans cette transition formalisée, tout reste dans le même bac.
• Suppression : quand et comment la donnée est-elle supprimée définitivement ? Cette étape est cruciale pour le RGPD, et pourtant elle est rarement industrialisée.

Sans pilotage du cycle de vie, la qualité se dégrade mécaniquement avec le temps. Une donnée correcte à sa création ne le reste pas si personne ne pilote son vieillissement. C'est une cause silencieuse, qui ne produit pas de crise visible mais qui érode lentement la fiabilité de l'ensemble du patrimoine informationnel.

4 leviers pour corriger les causes de la mauvaise qualité des données

Identifier les causes, c'est la moitié du chemin. Encore faut-il pouvoir agir dessus, dans un contexte où les ressources sont contraintes et les priorités multiples. Voici quatre leviers concrets, dans l'ordre où il est généralement le plus efficace de les actionner.

Auditer pour identifier les causes par domaine de données

Avant de lancer des chantiers, il faut savoir où on en est. L'audit qualité des données n'est pas un exercice théorique : c'est ce qui transforme une intuition (« nos données ne sont pas fiables ») en faits objectivés, par domaine, par dimension, et par cause.

Un bon audit ne se contente pas de mesurer des taux de complétude ou d'unicité. Il identifie, pour chaque anomalie significative, le mécanisme qui l'a produite : saisie libre, absence de règle, défaut d'intégration, donnée orpheline. C'est cette analyse causale qui permet ensuite de prioriser les actions et d'éviter les chantiers cosmétiques.

L'audit doit être conduit domaine par domaine (clients, produits, contrats, RH, finance), pas en bloc. Chaque domaine a ses propres causes dominantes, ses propres responsables, ses propres règles. Un rapport unique qui mélange tous les périmètres est presque toujours illisible et inactionnable.

👉 À lire aussi : Audit de qualité des données : 5 KPI à suivre absolument

Nommer un propriétaire métier par périmètre critique

Si une seule action devait être priorisée, ce serait celle-là. Nommer un Data Owner sur les périmètres les plus critiques est le levier qui débloque tous les autres. Sans Owner, l'audit produit des recommandations sans suite. Sans Owner, les règles ne sont pas arbitrées. Sans Owner, les contrôles automatisés tournent dans le vide.

Le critère de choix d'un bon Data Owner est simple : c'est la personne qui, dans l'organisation actuelle, a déjà la légitimité pour trancher quand deux équipes ne sont pas d'accord sur la définition d'une donnée. Si ce nom n'émerge pas spontanément, c'est qu'il y a un problème de gouvernance plus large à résoudre avant.

Mettre en place des contrôles automatisés à la source

Une fois les Owners en place et les règles métier écrites, ces règles doivent être instrumentées. C'est le rôle des contrôles automatisés : transformer une règle métier en test qui s'exécute à chaque saisie, à chaque mise à jour, à chaque transfert entre systèmes.

Les contrôles à la source ont un effet incomparable aux contrôles a posteriori. Un contrôle qui bloque une saisie erronée empêche la création de la donnée fausse. Un contrôle qui détecte la même erreur trois mois plus tard mobilise des équipes pour la corriger, alors qu'elle a déjà produit ses effets dans une dizaine de processus en aval. Plus le contrôle est proche du point de création de la donnée, plus son retour sur investissement est élevé.

Les contrôles les plus utiles sont rarement les plus sophistiqués. Les validations de format (e-mail, téléphone, code postal), les contraintes de cohérence inter-champs (date de fin > date de début), les contrôles d'unicité sur les identifiants métier, les vérifications de complétude sur les champs obligatoires : ce sont des règles simples qui, déployées systématiquement, suppriment la majorité des anomalies récurrentes. Ces contrôles s'inscrivent dans une démarche plus large de dispositifs pour maintenir la qualité des données dans le temps.

Acculturer les équipes productrices de données

Les trois leviers précédents sont structurels. Ce quatrième est culturel, et c'est sans doute celui qui inscrit la transformation dans la durée. Tant que les équipes qui produisent la donnée ne comprennent pas ce qu'on en fait en aval, elles ne peuvent pas en prendre soin.

L'acculturation data ne consiste pas à former tout le monde à SQL ou à Power BI. Il s'agit de faire comprendre, à chaque équipe productrice (commerciaux qui saisissent dans le CRM, gestionnaires qui mettent à jour l'ERP, RH qui maintiennent les référentiels), pourquoi leur saisie compte, à quoi sert la donnée qu'ils produisent, et quels sont les effets concrets d'une donnée mal saisie sur le reste de l'organisation.

Cette pédagogie change la posture des équipes : la qualité cesse d'être perçue comme une contrainte IT pour devenir une responsabilité métier. C'est précisément ce qui permet aux contrôles automatisés d'être acceptés et non contournés, aux règles métier d'être respectées et non détournées, aux Data Owners d'être écoutés et non snobés. Sans acculturation, les trois autres leviers s'essoufflent. Avec acculturation, ils s'auto-renforcent.