En bref
Des données fausses ne sont presque jamais un problème de saisie ni d’outil : c’est un problème de propriété. On achète des applications, on hérite des flux — et ce qui n’a jamais été décidé n’a jamais eu de responsable. Trente ans que le sujet traîne ; l’IA est en train de lui donner, enfin, un sponsor.
Le commercial ouvre le CRM, le comptable ouvre l’ERP, et le même client n’y porte ni la même adresse, ni le même nom, ni parfois le même identifiant. Chacun est convaincu de détenir la bonne version. Personne n’a tort — et c’est exactement le problème.
Ce constat n’a rien de neuf. On l’écrit depuis trente ans. La vraie question n’est donc pas de le décrire une fois de plus : c’est de comprendre pourquoi, en 2026, il est toujours là.
On achète des applications, on hérite des flux
Dans « système d’information », le mot qui compte n’est pas « système ». On a passé trois décennies à parler de contenants — applications, serveurs, cloud, licences — alors que le nom même du métier désigne le contenu. Un SI n’est pas une collection d’applications : c’est un ensemble où l’infrastructure, les données et la gouvernance sont indissociables. Et la partie qui décide de la valeur, c’est la donnée.
Voilà pourquoi le sujet échappe : les applications se décident, les flux se subissent. Personne n’a jamais signé un bon de commande pour une interface. On choisit un CRM, on choisit un ERP — chacun avec son comité, son budget, son sponsor. Puis il faut bien qu’ils se parlent, et l’on construit un flux : sans arbitrage, sans propriétaire, souvent dans les dernières semaines d’un projet. Les applications sont des nœuds que l’on décide ; les flux sont des arêtes que l’on hérite. Ce qui n’a jamais été décidé n’a jamais eu de responsable.
Une cartographie du SI rend ces flux visibles, et c’est déjà beaucoup. Mais il faut être lucide sur ce qu’elle fait : elle révèle les flux, elle ne les gouverne pas. Elle vous dit qui parle à qui. Elle ne dit pas qui a raison.
La seule question qui compte : qui est maître ?
Être maître d’une donnée, c’est faire autorité sur elle : c’est le système où elle est créée, modifiée, et depuis lequel elle se diffuse. Les autres la consomment, l’affichent, s’en servent — mais ne la redéfinissent pas. Cette règle ne se pose pas au niveau du SI en bloc, elle se pose donnée par donnée. Le CRM peut très bien faire autorité sur la donnée client tandis que l’ERP fait autorité sur la donnée produit, avec des flux cohérents entre les deux.
Ce travail n’a rien de technique, et c’est ce qui déroute. Il consiste à désigner, pour chaque donnée structurante, un système maître et un responsable métier — un humain, pas une application — qui répond de sa définition et de sa qualité. Sans cela, aucun outil ne sauvera la situation : le nettoyage traite le symptôme, et six mois plus tard les écarts reviennent au même endroit. Tant que deux systèmes peuvent créer la même donnée sans qu’aucun ne fasse autorité, la divergence n’est pas un accident — c’est le fonctionnement normal de l’organisation.
| Le symptôme visible | La cause réelle |
|---|---|
| Des doublons qui reviennent après chaque nettoyage | Deux systèmes créent la même donnée, aucun ne fait autorité |
| Des chiffres qui divergent selon le rapport consulté | La donnée n’a pas la même définition d’un service à l’autre |
| Des interfaces qui « perdent » des informations | Les flux ont été construits sans règle de préséance |
| Personne ne sait quelle version est la bonne | Aucun responsable métier n’a été désigné |
| Le projet décisionnel n’aboutit jamais | On consolide des données dont la sémantique diffère |
Pourquoi ce n’est toujours pas réglé en 2026
Si tout le monde connaît le problème et que personne ne le résout, ce n’est pas par négligence. C’est qu’une mécanique très efficace le maintient en vie. Elle tient en quatre ressorts.
Il n’a jamais eu de sponsor
La qualité des données est le problème de tout le monde, donc de personne. Chaque direction en souffre un peu ; aucune n’en meurt. Le commercial refait son devis, le comptable recorrige son adresse, le contrôleur de gestion retraite son fichier — chacun a développé ses contournements, et ces contournements sont précisément ce qui empêche la crise salutaire.
Le coût est diffus
C’est le point décisif. Une donnée fausse ne provoque pas de panne : elle provoque un devis à refaire, un client agacé, un rapport contesté en comité, une livraison à la mauvaise adresse. Des micro-coûts absorbés par les équipes, qui n’apparaissent sur aucune ligne budgétaire et ne déclenchent aucune alarme. Un sujet sans sponsor et sans coût visible ne se règle pas. Il attend.
Les projets s’arrêtent à la mise en service
Le budget d’un projet couvre la migration, rarement la reprise. On charge l’existant tel quel, on garde les doublons « pour l’historique », on nettoiera « après ». Il n’y a pas d’après : l’équipe projet est dissoute, le sponsor est passé au chantier suivant, et la dette de données est transférée à l’exploitation, qui n’a ni mandat ni budget pour la traiter. Chaque projet réussi techniquement peut ainsi aggraver la situation.
Chaque nouveau chantier ajoute un prétendant
CRM, outil marketing, portail client, décisionnel, et maintenant les assistants : chacun a besoin de « la » donnée client — et chacun finit par s’en recréer une version. Le nombre de prétendants au titre de maître croît à chaque projet, alors que le nombre d’arbitrages, lui, reste à zéro.
Ce que l’IA change vraiment
On entend partout que l’IA échouera sur de mauvaises données. C’est à la fois banal et imprécis : beaucoup d’usages de l’IA générative ne touchent pas à vos données et fonctionnent très bien. Le sujet ne concerne que les usages branchés sur votre patrimoine — assistants sur vos documents, agents sur vos applications, analyses sur vos bases. Mais pour ceux-là, l’IA fait quelque chose que les outils précédents ne faisaient pas.
Elle rend les mauvaises données indiscutables
Un tableau de bord faux, on le conteste : le chiffre paraît bizarre, quelqu’un lève la main, on remonte à la source. Une réponse d’IA fausse, elle, est fluide, assurée, argumentée — et sans traçabilité. Elle ne dit pas « je me base sur la table client de 2019 » ni « j’ai trouvé deux tarifs contradictoires et j’ai choisi le premier ». Elle affirme. La donnée douteuse cesse d’être visiblement douteuse : elle ressort blanchie, avec l’autorité de la machine. Un assistant branché sur un espace documentaire ne distingue pas la version validée du brouillon, ni le tarif en vigueur de celui d’il y a trois ans — sauf si quelqu’un, un jour, a décidé lequel fait foi.
Pour la première fois, le sujet a un sponsor
Et c’est là que se produit le renversement. Trente ans de discours sur la qualité des données n’ont donné à ce sujet ni budget, ni urgence, ni patron. L’IA vient de lui apporter les trois d’un coup. Pour la première fois, il existe un projet que la direction veut, qui échoue visiblement quand les données sont douteuses, et dont l’échec, lui, ne passe pas inaperçu. Autrement dit : l’IA n’est pas menacée par vos données — elle est le premier prétexte crédible pour enfin traiter un sujet que personne n’a jamais voulu porter. C’est une opportunité politique bien plus qu’un risque technique. Les entreprises qui l’ont compris ne font pas « un projet IA » : elles profitent de l’IA pour poser les arbitrages qu’elles repoussaient depuis dix ans.
Le phénomène a d’ailleurs un cousin : quand les usages d’IA s’installent hors de tout cadre, ils exposent au grand jour ce que l’entreprise ne maîtrisait pas de ses données. Le Shadow IA et la qualité des données racontent la même histoire vue de deux côtés.
Faut-il un MDM ?
Le MDM — Master Data Management — désigne la discipline qui consiste à gouverner les données de référence : celles que plusieurs applications partagent et qui structurent l’activité (clients, produits, fournisseurs, sites). C’est d’abord une discipline, et seulement ensuite, parfois, un logiciel.
La confusion coûte cher. Beaucoup d’entreprises achètent un outil de MDM en espérant qu’il tranchera à leur place les questions qu’elles n’ont pas voulu trancher. Il ne le fera pas : un MDM outille des règles, il ne les invente pas. Déployé sans gouvernance préalable, il devient un système de plus — avec ses propres divergences, et un prétendant supplémentaire au titre de maître. En PME et ETI, la gouvernance seule, formalisée dans les règles des flux d’intégration, suffit très souvent, sans acheter le moindre produit dédié.
★ Mon retour d’expérience
Sur une mission dans une PME industrielle, deux applications géraient la donnée client, chacune capable de la créer et de la modifier. Le débat durait depuis des années — sous une forme technique : quelle interface corriger, quel sens de synchronisation retenir. En réalité, la question n’avait jamais été posée à ceux qui pouvaient y répondre : la direction commerciale et la direction financière. Il a fallu une heure de réunion pour désigner un maître par donnée. La partie technique a pris quelques jours. L’arbitrage manquant, lui, coûtait des années — et personne ne l’avait jamais chiffré, parce que ce coût-là ne figure sur aucune facture.
💡 Le piège : croire que c’est un sujet IT
La DSI peut décrire les flux, mesurer les écarts, outiller les règles. Elle ne peut pas décider que le CRM fait autorité sur la donnée client — c’est un arbitrage métier, qui engage la façon de travailler des équipes. Une gouvernance de données portée par la seule IT ne tiendra pas : les métiers continueront de saisir là où ça les arrange. Si le sujet n’a pas de sponsor au comité de direction, il n’a pas commencé.
Par où commencer
Pas par l’exhaustivité. On identifie les quelques données réellement structurantes — souvent moins d’une dizaine — puis, pour chacune, on désigne un système maître et un responsable métier, on écrit la définition en une phrase, et on rend les flux cohérents avec cette règle. Rien de technologique là-dedans : quatre colonnes dans un tableur et une série d’arbitrages assumés.
Le vrai conseil est ailleurs, et il est politique : ne lancez pas un « chantier qualité des données ». Il n’aura ni sponsor ni urgence, comme les précédents. Accrochez-le à un projet que la direction veut — un décisionnel, un CRM, un usage d’IA — et faites des arbitrages de propriété un prérequis explicite de ce projet, pas une tâche annexe. C’est le rôle d’un schéma directeur que de rendre ces dépendances visibles avant qu’elles ne se transforment en dette.
Questions fréquentes
Qu’est-ce qu’une donnée maître ?
Une donnée de référence partagée par plusieurs applications et structurante pour l’activité : client, produit, fournisseur, site. Son système « maître » est celui qui fait autorité — où elle est créée et modifiée — les autres ne faisant que la consommer.
Faut-il acheter un outil de MDM ?
Rarement d’emblée. Le MDM est d’abord une discipline de gouvernance : désigner un système maître et un responsable métier par donnée. En PME et ETI, ces règles portées par les flux d’intégration suffisent souvent. Un outil déployé sans gouvernance ajoute un système de plus, et un prétendant supplémentaire au titre de maître.
Qui doit être responsable de la qualité des données ?
Un responsable métier, pas la DSI. La DSI outille, mesure et fait respecter les règles ; elle ne peut pas décider seule quelle application fait autorité, car cet arbitrage engage la façon de travailler des équipes.
Pourquoi la qualité des données n’est-elle toujours pas réglée ?
Parce qu’elle n’a jamais eu de sponsor et que son coût est diffus : une donnée fausse ne provoque pas de panne mais un devis refait, un rapport contesté — des micro-coûts absorbés par les équipes, invisibles au budget. S’y ajoute le fait que les projets s’arrêtent à la mise en service, laissant la reprise des données à une exploitation sans mandat.
Faut-il des données propres avant de se lancer dans l’IA ?
Pour les usages branchés sur vos propres données, oui : l’IA ne se contente pas d’hériter des erreurs, elle les rend indiscutables en répondant avec assurance et sans traçabilité. Mais le bon raisonnement est inverse : l’IA est le premier projet capable de donner à la qualité des données le sponsor, le budget et l’urgence qui lui ont toujours manqué.
Des données qui divergent d’un système à l’autre ?
Arnaud Benistant
Fondateur et président d’Askee, cabinet de conseil en management des systèmes d’information en Auvergne-Rhône-Alpes. Fort de 20 ans d’expérience en SI, il a notamment été DSI de l’Entrepôt du Bricolage (Groupe SAMSE) avant d’accompagner dirigeants et directions comme DSI de transition. Sa conviction : derrière chaque projet IT, c’est presque toujours une question d’humain.
