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.
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.
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.
.jpg)
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.
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.
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).
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 :
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.
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
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.
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.
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.
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.
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é.
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 ?
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.
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.
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.