Data owner, data steward, data custodian : clarifier les rôles sans créer une usine à gaz

Cet article aide a clarifier un sujet de decision, de modernisation, de gouvernance ou d'exploitation avant de bouger l'existant.

• Enjeux metier reels
• Risques et dependances
• Arbitrages utiles
• Trajectoire recommandee

Le vrai problème : tout le monde parle de gouvernance, personne ne porte la décision

Dans beaucoup d’organisations, les rôles existent sur un organigramme, mais pas dans les arbitrages du quotidien. Quand une définition métier diverge entre deux directions, quand un indicateur de qualité passe au rouge ou quand une donnée critique change de source, la question n’est pas “qui est concerné ?”, mais “qui décide, qui coordonne et qui exécute ?”. Sans cette clarification, la gouvernance devient un décor : beaucoup de vocabulaire, peu de responsabilité réelle.

Le point de départ d’un bon cadrage n’est donc pas de copier un modèle cible standard. Il faut partir des objets de données qui comptent vraiment, des irritants d’exploitation, des dépendances entre métiers, BI, data et IT, puis construire un dispositif sobre. Dans une intervention directe de freelance senior, l’enjeu est précisément là : couper dans le superflu, nommer les bons rôles et les relier à des décisions observables.

Data owner, data steward, data custodian : qui fait quoi, concrètement ?

Le data owner porte la responsabilité métier d’un domaine ou d’un objet de données. Il arbitre les définitions, valide les règles d’usage, priorise les écarts de qualité selon l’impact métier et tranche en cas de conflit entre parties prenantes. Ce rôle n’est pas opérationnel au quotidien sur chaque anomalie, mais il doit être en capacité de décider.

Le data steward tient le dispositif dans la durée. Il documente, coordonne, prépare les arbitrages, fait remonter les écarts, anime les revues et maintient la cohérence entre glossaire, règles de qualité, usages BI et besoins des équipes. C’est souvent le rôle le plus sous-estimé : sans steward, le owner est sollicité trop tard et la gouvernance retombe.

Le data custodian porte l’exploitation technique de la donnée : stockage, accès, flux, sécurité, transformations, traçabilité, contraintes de plateforme. Il ne décide pas seul du sens métier, mais il garantit que les choix sont exécutables dans le SI et que les contrôles sont effectivement mis en place.

La confusion classique consiste à demander à l’IT de “posséder” la donnée métier, ou à nommer un owner sans lui donner aucun levier de décision. Dans les deux cas, le modèle se bloque rapidement.

Un operating model data utile tient sur peu de rôles et des règles d’escalade claires

Un bon operating model data n’a pas besoin d’être volumineux. Dans la majorité des contextes, il suffit de cadrer quatre éléments : le périmètre de chaque rôle, les décisions attendues, les rituels de gouvernance et les règles d’escalade. L’objectif n’est pas de couvrir tous les cas théoriques, mais de traiter sans ambiguïté les cas récurrents : définition métier, incident de qualité, changement de source, demande d’accès, problème de traçabilité.

Un cadre simple fonctionne souvent mieux qu’une matrice RACI surdimensionnée. Par exemple : le data owner valide la définition de référence et les seuils d’acceptabilité ; le data steward prépare les impacts, coordonne les contributeurs et suit la résolution ; le data custodian met en œuvre les contrôles, le lineage et les ajustements techniques. Si un sujet dépasse le périmètre d’un domaine, une escalade est prévue vers un sponsor ou une instance de décision courte.

Ce type de modèle a un avantage décisif : il résiste mieux à la réalité. En entreprise, les rôles sont rarement portés à 100 % du temps. Il faut donc un dispositif compatible avec des agendas chargés, des priorités mouvantes et des contraintes de delivery.

Les rituels qui servent vraiment : qualité, définitions, incidents et trajectoire

La gouvernance échoue souvent non par manque de rôles, mais par manque de rythme. Sans rituels, les décisions restent implicites, les écarts s’empilent et les équipes recréent des contournements. Trois rituels suffisent généralement à créer de la traction.

D’abord, une revue courte des objets critiques : définitions, points de friction, responsabilités ouvertes. Ensuite, une revue qualité ciblée sur quelques règles utiles, avec analyse des écarts, impacts métier et plan d’action. Enfin, une revue de trajectoire pour arbitrer les dépendances entre backlog data, exigences réglementaires, usages BI et dette technique.

Le point clé est d’éviter les comités génériques. Si aucune décision n’est prise, le rituel devient un coût de plus. À l’inverse, quand chaque réunion est reliée à un périmètre clair, à un owner identifié et à des actions suivies, la gouvernance cesse d’être un sujet abstrait. Elle devient un mode d’exploitation maîtrisé.

Les erreurs d’organisation qui créent l’usine à gaz

Première erreur : nommer des rôles sans vérifier la capacité réelle à les tenir. Un directeur métier affiché data owner, mais absent des arbitrages, crée plus de confusion qu’il n’en résout. Deuxième erreur : confondre documentation et gouvernance. Un catalogue bien rempli ne remplace ni la décision, ni la qualité, ni la traçabilité opérationnelle.

Troisième erreur : vouloir industrialiser trop tôt. Certaines organisations lancent un glossaire global, un outillage complet, des workflows complexes et plusieurs comités avant même d’avoir stabilisé dix objets de données prioritaires. Le résultat est prévisible : faible adoption, charge administrative, rejet côté métiers.

Quatrième erreur : laisser chaque domaine inventer ses propres règles sans cadre commun. À court terme, cela semble pragmatique. À moyen terme, les définitions dérivent, les responsabilités se contredisent et les usages transverses deviennent coûteux. Un minimum de standardisation est nécessaire, mais au bon niveau : vocabulaire commun, règles d’escalade, format de décision, critères de qualité et principes de traçabilité.

Par où commencer sans bloquer l’exploitation

Le bon point d’entrée n’est pas un programme trop large. Il vaut mieux cadrer un périmètre resserré : un domaine de données critique, quelques objets à fort impact, les rôles réellement mobilisables et deux ou trois irritants concrets à traiter. Cela permet de tester l’organisation sur des cas réels : un KPI contesté, une donnée client incohérente, un flux mal tracé, un accès mal gouverné.

Dans cette approche, l’intervention directe d’un freelance senior apporte surtout de la netteté : audit rapide des rôles existants, clarification des responsabilités, définition d’un operating model data proportionné et mise en place de premiers rituels tenables. Pas de couche agence, pas de complexité artificielle, pas de gouvernance conçue hors sol. L’objectif est simple : rendre les décisions plus fiables, les responsabilités plus lisibles et l’exploitation plus robuste.

FAQ

Quelle différence entre data owner et data steward ?

Le data owner porte la décision métier sur la donnée : définition de référence, niveau d’exigence, arbitrages de priorité. Le data steward anime le dispositif au quotidien : documentation, coordination, suivi des écarts, préparation des décisions et maintien de la cohérence entre acteurs.

Le data custodian est-il toujours un rôle IT ?

Dans la plupart des cas, oui, car il concerne l’exploitation technique, les flux, les accès, la sécurité et la traçabilité. Selon l’organisation, ce rôle peut être porté par une équipe plateforme, BI, data engineering ou production applicative. L’important est de ne pas lui attribuer à tort la responsabilité métier de la donnée.

Combien de rôles faut-il formaliser pour démarrer une gouvernance data ?

Le minimum utile est souvent de formaliser un data owner, un data steward et un data custodian sur un périmètre prioritaire. Mieux vaut trois rôles clairs, tenus dans la durée, qu’un modèle complet mais inopérant. La maturité vient ensuite, à partir des premiers arbitrages et des irritants réellement rencontrés.