DATA QUALITY

Qui est réellement responsable de la qualité des données ?

Assia El Omari
Chef de projet Marketing
26/5/2026
Sommaire

Posez la question dans un comité de direction : « Qui est responsable de la qualité de nos données ? » Les regards convergent vers la DSI, parfois vers le CDO si l'entreprise en a un, plus rarement vers un métier précis. Posez la même question à la DSI : elle répondra que la donnée appartient au métier qui la produit. Posez-la au métier : il vous dira que c'est à la DSI de garantir la qualité des systèmes qui stockent ces données. Personne ne ment. Mais personne ne porte vraiment la responsabilité.

C'est ce flou qui explique pourquoi tant d'entreprises ont des programmes qualité qui s'enlisent. Les ateliers identifient des problèmes, formulent des recommandations, et ces recommandations se perdent parce qu'aucune ligne ne s'estime légitime pour les arbitrer. Les outils détectent des anomalies, et ces anomalies restent en l'état parce qu'aucune équipe n'a la responsabilité explicite de les traiter. La qualité des données n'est pas un sujet sans propriétaire. C'est un sujet à trop de propriétaires partiels et aucun comptable final.

Cet article remet à plat la chaîne réelle de responsabilité. Pas l'organigramme idéal des bonnes pratiques, mais ce qui fonctionne quand on regarde les organisations qui progressent vraiment : qui décide, qui exécute, qui contrôle, et surtout comment cette répartition est rendue traçable au quotidien.

Qualité des données : pourquoi la question de la responsabilité est mal posée ?

La formulation « qui est responsable de la qualité des données » suppose qu'il existe une seule réponse, une fonction unique à qui l'on confie le sujet en bloc. C'est précisément cette hypothèse qui bloque toutes les organisations qui s'y prennent ainsi. La qualité des données n'est pas une tâche qu'on confie, c'est une responsabilité qui se répartit le long d'une chaîne, depuis la décision métier jusqu'au contrôle technique.

Trois confusions reviennent systématiquement dans les organisations qui n'avancent pas sur le sujet.

  • Première confusion : penser que la qualité est un sujet IT. C'est l'erreur la plus courante. Les données vivent dans des systèmes informatiques, donc on imagine que la qualité est un sujet de la DSI. Sauf que la qualité d'une donnée ne se mesure pas à la performance du système qui la stocke, mais à sa capacité à représenter fidèlement la réalité métier. Si le champ « statut client » est techniquement bien formé mais mal utilisé par les commerciaux, ce n'est pas un problème IT, c'est un problème métier. La DSI est responsable du contenant. Le contenu, c'est le métier.
  • Deuxième confusion : déléguer en bloc au CDO. Quand une entreprise nomme un Chief Data Officer, la tentation est forte de lui attribuer la responsabilité globale de la qualité des données. C'est un piège. Le CDO porte la stratégie data, le cadre, les normes, mais il ne peut pas être comptable de la qualité de chaque donnée dans chaque système. Lui transférer cette responsabilité, c'est lui donner un mandat impossible à tenir, et déresponsabiliser tous les autres.
  • Troisième confusion : croire que c'est l'affaire de tous. Le slogan « la qualité des données est l'affaire de tous » a l'avantage d'être inclusif. Il a l'inconvénient d'être inopérant. Quand tout le monde est responsable, personne ne l'est. Si l'on veut que la qualité s'améliore, il faut nommer des responsables identifiés sur des périmètres définis, et organiser leur coopération.

La bonne question n'est donc pas « qui est responsable de la qualité des données ? » mais « qui est responsable de quoi, sur quel périmètre, à quel niveau de la chaîne ? » C'est cette répartition qui permet d'identifier les véritables garants de la qualité des données dans l'organisation.

Les trois confusions qui paralysent la responsabilité qualité des données

La vraie chaîne de responsabilité de la qualité des données : qui décide, qui exécute, qui contrôle

Plutôt que de chercher un responsable unique, il faut comprendre que la qualité des données suit une chaîne à quatre niveaux, chacun avec un rôle précis. Ces niveaux ne se substituent pas l'un à l'autre, ils s'articulent. C'est leur cohérence qui produit la qualité, et c'est leur découplage qui la dégrade.

Le Data Owner : le responsable qui décide et arbitre la qualité des données

Au sommet de la chaîne opérationnelle, le Data Owner est le responsable métier d'un périmètre de données. Son rôle n'est pas technique : il décide de ce que la donnée doit représenter, il arbitre les conflits d'usage entre équipes, il valide les règles métier, il priorise les actions d'amélioration sur son périmètre.

Concrètement, le Data Owner est le seul à pouvoir trancher quand deux équipes ont une définition différente d'un même indicateur. Quand le commerce dit « un client actif est un client ayant acheté dans les 12 derniers mois » et que la finance dit « un client actif est un client dont la dernière facture date de moins de 6 mois », c'est le Data Owner du domaine clients qui décide. Sans cette décision, les deux définitions cohabitent et les chiffres ne se réconcilient jamais.

Le Data Owner doit être un manager opérationnel du domaine concerné. Le Data Owner des données RH est le DRH ou un de ses adjoints. Le Data Owner des données clients est le directeur commercial ou le directeur marketing. Le Data Owner des données financières est un responsable de la direction financière. Ce ne peut pas être un profil IT, ni le CDO, ni un consultant externe. La légitimité du rôle vient de son ancrage métier.

Le Data Steward : le responsable qui opère et contrôle la qualité des données

Si le Data Owner décide, le Data Steward exécute. C'est le bras opérationnel de la fonction qualité sur un périmètre. Il documente les règles décidées par l'Owner, il pilote les contrôles automatisés, il analyse les anomalies détectées, il anime les actions correctives avec les équipes productrices.

Le Data Steward est typiquement un profil hybride : suffisamment proche du métier pour comprendre la sémantique des données, suffisamment à l'aise techniquement pour dialoguer avec la DSI et exploiter les outils qualité. C'est souvent un analyste métier confirmé, un référent fonctionnel, ou un data analyst rattaché au domaine.

Le binôme Owner / Steward est la combinaison qui fonctionne. L'Owner sans Steward décide mais n'exécute pas. Le Steward sans Owner exécute mais sans légitimité pour arbitrer. Cette articulation est ce que décrit la triade Data Owner, Data Steward, Data Custodian, où le Custodian représente le rôle technique de gardien du système (typiquement à la DSI).

Le CDO et le Data Office : les responsables du cadre de qualité des données

Au-dessus de chaque couple Owner / Steward, le Chief Data Officer et son équipe (le Data Office) portent une responsabilité différente : celle du cadre. Ils ne sont pas responsables de la qualité de chaque donnée prise individuellement, mais des conditions qui permettent à cette qualité d'exister.

Concrètement, le Data Office :

  • Définit la politique de qualité des données : critères, niveaux de service attendus, seuils d'alerte, instances d'arbitrage.
  • Met à disposition les outils communs : plateforme de Data Quality, dictionnaires de données, outils de gouvernance et catalogues.
  • Anime la communauté des Data Owners et des Data Stewards : partage de pratiques, retours d'expérience, montée en compétence.
  • Pilote la stratégie globale : priorisation des domaines, choix des chantiers structurants, sponsoring des transformations.
  • Rend compte à la direction générale de l'état du patrimoine de données, avec des indicateurs consolidés.

Le CDO est responsable du fait que la chaîne fonctionne. Il n'est pas responsable du fait que chaque donnée soit juste. Cette nuance change tout dans la manière dont son mandat est rédigé et évalué. Un CDO à qui l'on demande de garantir la qualité de toutes les données de l'entreprise échouera systématiquement. Un CDO à qui l'on demande de garantir que le dispositif fonctionne (Owners nommés, règles écrites, contrôles déployés, indicateurs suivis) a une mission réaliste et mesurable.

Qualité des données et métiers : contributeurs, pas spectateurs

Le dernier maillon, et le plus large, ce sont les équipes métier qui produisent et consomment la donnée au quotidien. Un commercial qui saisit une fiche prospect, un gestionnaire qui met à jour un contrat, un opérateur qui valide une commande : chacun est producteur de données. Et donc co-responsable de leur qualité.

Cette responsabilité diffuse n'est pas comparable à celle du Data Owner ou du Steward. Les équipes métier ne décident pas des règles, ne pilotent pas les contrôles. Mais elles peuvent détruire la qualité à grande échelle si elles ne respectent pas les règles posées, ou la construire à grande échelle si elles les intègrent dans leurs pratiques.

C'est pour cela qu'on parle de contributeurs plutôt que de spectateurs. Les équipes métier ne sont pas le public d'une démarche qualité pilotée à leur place. Elles en sont l'un des leviers principaux. Et c'est précisément ce qui justifie l'investissement dans un programme d'acculturation data : pour qu'une équipe respecte une règle, encore faut-il qu'elle en comprenne le sens.

👉 À lire aussi : Audit de qualité des données : méthode et indicateurs clés

Les trois angles morts qui font dérailler la responsabilité de la qualité des données

Même dans les organisations qui ont mis en place une chaîne théoriquement claire, trois angles morts reviennent systématiquement et finissent par éroder le dispositif. Les identifier, c'est se donner les moyens de les anticiper.

  • Premier angle mort : les données transverses sans Owner désigné. Certaines données ne s'attachent pas naturellement à un domaine. Un identifiant client unique est partagé entre commerce, marketing, finance, juridique. Une nomenclature produit traverse achats, logistique, vente, comptabilité. Sans arbitrage volontariste, ces données restent orphelines : chaque domaine y touche, aucun n'en assume la cohérence globale. La règle pratique : pour chaque donnée transverse critique, désigner un Owner principal et formaliser les co-décideurs sur les usages.
  • Deuxième angle mort : la donnée qui change de mains pendant son cycle de vie. Une donnée client est créée par le marketing au moment de la prospection, enrichie par le commerce au moment du closing, mise à jour par le service client après la vente, archivée par la conformité après la fin de relation. Qui en est responsable à chaque étape ? Si la réponse n'est pas formalisée, la qualité se dégrade à chaque transition. Comprendre le cycle de vie de la donnée est donc indissociable de la définition des responsabilités : on est responsable d'un périmètre à un moment du cycle, pas d'une donnée en abstrait.
  • Troisième angle mort : les flux entre systèmes. Une donnée correcte dans le système A peut arriver dégradée dans le système B après transformation par un ETL. Qui est responsable de cette dégradation ? Le Data Owner du système A, qui considère que sa donnée est correcte au départ ? Celui du système B, qui reçoit une donnée déjà altérée ? La DSI qui exploite le pipeline ? Sans règle explicite, chacun renvoie la responsabilité au suivant et personne ne corrige. La pratique qui fonctionne consiste à désigner un responsable de flux pour chaque pipeline critique, distinct des Owners de chaque système.

Comment rendre la responsabilité de la qualité des données partagée et traçable

Identifier les bons rôles ne suffit pas. Tant que la répartition reste implicite ou orale, elle ne tient pas dans la durée : un changement d'organisation, un départ, un nouvel arrivant suffisent à la faire disparaître. Trois leviers complémentaires permettent de l'ancrer durablement.

Formaliser la responsabilité qualité des données dans une matrice RACI

L'outil le plus simple, et le plus souvent négligé, c'est la matrice RACI appliquée à la qualité des données. Pour chaque grande activité (définition des règles, pilotage des contrôles, traitement des anomalies, validation des indicateurs, arbitrages d'usage), on identifie qui est Responsible (qui exécute), Accountable (qui répond du résultat), Consulted (qui est consulté), Informed (qui est informé).

L'exercice est éclairant. Sur les périmètres où la qualité progresse, le RACI est clair et tenu. Sur les périmètres où elle stagne, le RACI est soit absent, soit comporte plusieurs Accountable sur la même activité, ce qui revient à ne pas en avoir.

Activité Data Owner Data Steward CDO / Data Office DSI Métier producteur
Définir les règles métier A R C C C
Documenter les règles A R I I C
Mettre en place les contrôles A R C R I
Traiter les anomalies A R I C R
Arbitrer les conflits d'usage A C C I C
Valider les indicateurs qualité A R I I I
RResponsible — réalise l'activité AAccountable — rend des comptes, décide CConsulted — consulté avant l'action IInformed — informé du résultat

Cette matrice n'est qu'un exemple générique. Chaque organisation doit la décliner sur ses propres périmètres et ses propres processus. Mais l'esprit reste le même : un seul A par ligne, des R clairement identifiés, et une revue annuelle pour vérifier que la répartition tient toujours.

Ancrer la responsabilité qualité des données dans les processus, pas les organigrammes

Une responsabilité écrite dans un organigramme ne vit que tant que l'organigramme ne bouge pas. Une responsabilité ancrée dans les processus survit aux réorganisations. C'est une différence majeure.

Ancrer la responsabilité dans les processus, c'est rendre la qualité indissociable des actes quotidiens. Quand un commercial crée une fiche prospect, le système exige les champs critiques et bloque la création si une règle n'est pas respectée. Quand un gestionnaire valide un contrat, un contrôle automatique vérifie la cohérence avec les données existantes. Quand une équipe lance un nouveau projet data, une checklist qualité est intégrée dans le passage de jalon. La responsabilité n'est plus une fonction qu'on exerce à part, c'est une exigence intégrée au geste métier.

Cette approche change la posture des équipes. Tant que la qualité est portée par une cellule centrale, elle est perçue comme une contrainte externe. Quand elle est intégrée aux processus métiers, elle devient un attribut du métier lui-même. Les outils pour maintenir la qualité des données (contrôles à la source, validations bloquantes, dashboards intégrés aux outils métier) jouent ici un rôle clé.

Rendre la responsabilité qualité des données visible par des indicateurs partagés

Le troisième levier, c'est la transparence. Une responsabilité qui n'est pas mesurée publiquement est une responsabilité qui se dilue. À l'inverse, dès qu'on rend visible l'état de la qualité par périmètre, avec un Owner identifié, le mécanisme social fait son œuvre : personne n'a envie d'être le Data Owner d'un périmètre qui clignote en rouge sur un dashboard partagé.

Concrètement, cela se traduit par un dashboard qualité par domaine, mis à jour automatiquement, accessible à un cercle de décideurs (direction générale, CDO, Data Owners, comité data). Les indicateurs sont classiques : taux de complétude, taux d'unicité, taux de conformité aux règles métier, délai de traitement des anomalies. Ce qui compte, ce n'est pas la sophistication des indicateurs, c'est qu'ils soient les mêmes pour tous, et que chaque Owner soit identifié à côté de son périmètre.

Cette visibilité produit deux effets puissants. D'abord, elle objective les progrès : on cesse de débattre des chiffres et on observe les tendances. Ensuite, elle responsabilise par construction : un Data Owner qui voit son indicateur stagner pendant trois trimestres ne peut plus prétendre qu'il fait son maximum.

👉 À lire aussi : Quels KPI pour suivre la qualité des données ?

Conclusion : la responsabilité, premier levier d'une démarche qualité des données durable

Tant que la responsabilité de la qualité des données reste floue, aucun outil, aucun investissement, aucun plan d'action ne produit de résultat durable. C'est le premier levier à activer, avant la technologie, avant la méthode, avant les KPI. Une organisation qui ne sait pas qui décide de la qualité de ses données ne peut pas, par construction, l'améliorer.

La bonne nouvelle, c'est que ce levier coûte peu en investissement. Nommer trois à cinq Data Owners sur les périmètres critiques, leur adjoindre un Data Steward, formaliser un RACI, mettre en place un dashboard partagé : aucune de ces actions ne demande de grand chantier IT. Elles demandent du courage organisationnel et de la constance dans la durée. Ce n'est pas un projet, c'est un changement de mode de fonctionnement.

Les organisations qui réussissent leur démarche qualité ne sont pas celles qui ont les meilleurs outils ou les plus gros budgets. Ce sont celles qui ont accepté de répondre clairement à la question initiale : qui décide, qui exécute, qui contrôle, qui contribue. Et qui ont rendu cette répartition vivante, tracée, mesurée. La qualité suit, presque mécaniquement.

FAQ

Les questions fréquentes

Qui est responsable de la qualité des données dans une entreprise ? +

Il n'existe pas un responsable unique de la qualité des données. La responsabilité se répartit le long d'une chaîne à quatre niveaux, depuis la décision métier jusqu'au contrôle technique. La bonne question n'est pas qui est responsable, mais qui est responsable de quoi, sur quel périmètre et à quel niveau de la chaîne.

  • Le Data Owner décide de ce que la donnée doit représenter et arbitre les conflits d'usage.
  • Le Data Steward exécute : il documente les règles, pilote les contrôles et traite les anomalies.
  • Le CDO et le Data Office portent le cadre : politique qualité, outils communs, animation des Owners.
  • Les équipes métier sont contributrices, parce qu'elles produisent la donnée au quotidien.
  • C'est la cohérence entre ces quatre niveaux qui produit la qualité, leur découplage qui la dégrade.
La qualité des données est-elle un sujet pour la DSI ? +

Non, ou plutôt pas seulement. C'est la confusion la plus répandue : comme les données vivent dans des systèmes informatiques, on imagine que leur qualité relève de la DSI. La qualité d'une donnée se mesure pourtant à sa capacité à représenter fidèlement la réalité métier, pas à la performance du système qui la stocke.

  • La DSI est responsable du contenant, c'est à dire des systèmes qui hébergent la donnée.
  • Le contenu, lui, relève du métier qui produit et utilise la donnée.
  • Un champe statut client bien formé techniquement mais mal utilisé reste un problème métier.
  • Confier le sujet en bloc à la DSI revient à traiter un problème métier avec un mandat technique.
Le CDO est-il responsable de la qualité de toutes les données ? +

Non. Confier au Chief Data Officer la responsabilité globale de la qualité de chaque donnée est un piège qui le condamne à l'échec. Le CDO est responsable du fait que la chaîne fonctionne, pas du fait que chaque donnée soit juste. Cette nuance change la manière dont son mandat est rédigé et évalué.

  • Le CDO et le Data Office définissent la politique de qualité : critères, seuils d'alerte, instances d'arbitrage.
  • Ils mettent à disposition les outils communs : plateforme de Data Quality, dictionnaires, catalogues.
  • Ils animent la communauté des Data Owners et des Data Stewards.
  • Ils rendent compte à la direction générale de l'état du patrimoine de données.
  • Un mandat réaliste : garantir que les Owners sont nommés, les règles écrites et les contrôles déployés.
Quelle est la différence entre un Data Owner et un Data Steward ? +

Le Data Owner décide, le Data Steward exécute. L'Owner est un responsable métier qui arbitre et valide les règles sur son périmètre. Le Steward est le bras opérationnel qui les met en oeuvre. Le binôme est la combinaison qui fonctionne : l'Owner sans Steward décide sans exécuter, le Steward sans Owner exécute sans légitimité pour arbitrer.

  • Le Data Owner est un manager opérationnel du domaine : DRH pour les données RH, directeur commercial pour les données clients.
  • Il ne peut être ni un profil IT, ni le CDO, ni un consultant externe : sa légitimité vient de l'ancrage métier.
  • Le Data Steward est un profil hybride, proche du métier et à l'aise avec les outils techniques.
  • C'est souvent un analyste métier confirmé, un référent fonctionnel ou un data analyst rattaché au domaine.
  • La triade se complète avec le Data Custodian, gardien technique du système, typiquement à la DSI.
Combien de temps faut-il consacrer au rôle de Data Owner ? +

Être Data Owner représente 10 à 20 % d'un ETP selon la criticité du périmètre. Nommer un Owner sans lui donner ce temps formel est l'erreur classique : le rôle reste théorique et le dispositif ne produit rien. Le temps doit être alloué, formalisé dans la fiche de poste et intégré aux objectifs annuels.

  • Sans temps dédié, l'Owner ne participe pas aux ateliers et n'arbitre pas les conflits.
  • Le rôle ne se résume pas à un titre : c'est une charge de travail réelle et récurrente.
  • Dans une mutuelle citée en exemple, l'Owner décidait une heure par semaine, le Steward exécutait trois jours sur cinq.
  • Ce périmètre a vu son taux de complétude passer de 78 % à 94 % en huit mois, sans nouvel outil.
Quels sont les angles morts qui font dérailler la responsabilité qualité ? +

Même avec une chaîne de responsabilité claire, trois angles morts reviennent systématiquement et finissent par éroder le dispositif. Ils concernent les données qui n'appartiennent à aucun domaine, celles qui changent de mains et celles qui transitent entre systèmes.

  • Les données transverses sans Owner désigné : un identifiant client partagé entre commerce, marketing, finance et juridique reste orphelin.
  • La donnée qui change de mains pendant son cycle de vie : créée par le marketing, enrichie par le commerce, mise à jour par le service client.
  • Les flux entre systèmes : une donnée correcte dans le système A peut arriver dégradée dans le système B après transformation par un ETL.
  • La parade : désigner un Owner principal pour chaque donnée transverse et un responsable de flux pour chaque pipeline critique.
Comment rendre la responsabilité de la qualité des données traçable ? +

Identifier les bons rôles ne suffit pas. Tant que la répartition reste orale, un départ ou une réorganisation suffit à la faire disparaître. Trois leviers permettent de l'ancrer durablement, et aucun ne demande de grand chantier IT.

  • Formaliser une matrice RACI par activité, avec un seul Accountable par ligne et des Responsible clairement identifiés.
  • Ancrer la responsabilité dans les processus métier plutôt que dans l'organigramme, pour qu'elle survive aux réorganisations.
  • Rendre la qualité visible par un dashboard partagé par domaine, avec le nom de l'Owner affiché à côté de son périmètre.
  • Suivre des indicateurs simples et communs à tous : complétude, unicité, conformité aux règles, délai de traitement des anomalies.
  • Prévoir une revue annuelle pour vérifier que la répartition tient toujours.