Identifiez et nommez vos data owners : enfin des réponses claires à vos questions

1. Qu’est-ce qu’un data owner

Le terme data owner, propriétaire de données, crée dès le départ une confusion. Et peut générer un rejet de la part de certains data owners potentiels qui y voient l’apparition de responsabilités qu’ils ne souhaitent pas. Soyons clairs dès le départ, le data owner n’est propriétaire de rien ! Les données appartiennent toutes à une seule et même entité, votre organisation. C’est donc un abus de langage de parler de propriétaire de données.

Si l’on devait trouver à ce terme une adaptation en français, le terme de « référent donnée » serait sans doute un des meilleurs. Un référent est une personne à qui l’on peut se référer. Le Larousse nous indique qu’un référent « se dit d’une personne, ou d’un service, compétent pour exercer une mission spécifique auprès d’un groupe ». Exactement ce que je souhaite confier à nos data owners !
Mais comme les Américains parlent de data owner, et que nous avons l’habitude de croire en leur bonne parole, nous utiliserons alternativement le terme de data owner, et de référent donnée, en évitant soigneusement celui de propriétaire, contrairement à l’Office québécois de la langue française qui le recommande.

Être data owner n’est pas un métier ! On n’est pas référent donnée professionnel ! C’est un rôle que l’on attribue, suivant les règles que nous verrons plus loin. Et la plupart du temps, le référent donnée l’est déjà ! Parfois, il ne le sait pas, ou cela n’a pas été formalisé. Mais il assure déjà plus ou moins ce rôle. C’est d’ailleurs le meilleur argument à mettre en avant face à ceux qui rejettent cette éventuelle responsabilité : elle n’est que la formalisation d’une situation déjà existante.

On n’est donc pas data owner professionnel. C’est un rôle qui fait partie de notre métier quotidien. Car aujourd’hui en entreprise, tout le monde manipule des données.

2. Qui sont les data owners

Qui sont alors ces référents données ? La réponse est simple : le référent d’une donnée devrait toujours être la personne qui connait le mieux la donnée. Les référents données sont donc à identifier dans les départements métier. Profitons de l’occasion pour parler de domaine métier. Un département correspond à l’organisation de l’entreprise, il représente le plus souvent un groupe de personnes. Un domaine en est plutôt une subdivision. Mais il n’y a pas forcément de hiérarchie claire, et un domaine métier peut regrouper des utilisateurs en provenance de plusieurs services. Mais gardez cette définition en tête et transformez-la en question : mon référent donnée choisi est-elle bien la personne qui connait le mieux la donnée ?

Alors, maintenant quelques questions, que tout le monde se pose :

Un data owner doit-il être une personne physique ? Oui, mais cela peut-être un groupe de personnes physiques, désignées par leur entité, par exemple l’assistance commerciale. Mais la communication autour du ou des noms des data owners doit permettre de les contacter. Il faut donc un email et un numéro de téléphone. Si le référent donnée est le « département finance », c’est trop imprécis. On ne saura pas qui contacter. L’objectif est de permettre à toute personne qui a une question sur la donnée, de contacter le bon interlocuteur, le référent.

Le data owner est-il le chef de service ? Non, surtout pas ! J’ai rencontré ce cas dans certaines collectivités locales, qui — sans doute pour brosser le chef dans le sens du poil — avaient décidé de nommer les directeurs comme data owners de l’ensemble de leurs données. Ça n’a pas raté, six mois après, ils nommaient des sous data owners. Car le chef de service en question, incapable de répondre aux questions concernant les données dont il était soi-disant référent, renvoyait systématiquement vers le vrai data owner. Donc, non, pas de brochette de médailles de data owner sur la poitrine des chefs.

Peut-on être data owner de plusieurs données ? Oui, bien sûr. Mais dans la limite du raisonnable. Je ne peux pas tout savoir sur plusieurs milliers de données. Mais si je suis réellement référent de plusieurs données, et capable de renseigner mes interlocuteurs, aucun problème.

Une même donnée peut-elle avoir plusieurs data owners ? Oui… si vous aimez les réunions de copropriétés ! En effet, comme dans un immeuble, si toute décision doit être prise par un ensemble de personnes, cela ajoute une complexité évidente. Les co-data owners doivent se réunir et décider avant toute action concernant la donnée. Donc ce n’est pas impossible, mais c’est fortement déconseillé d’affecter plusieurs référents à la même donnée.

Doit-on forcer quelqu’un à être data owner ? C’est fortement déconseillé, car cela ne fonctionne pas. Et cette personne, si elle n’a pas conscience de son rôle, ne répondra pas correctement aux questions qui lui seront posées. Les retours d’expérience montrent qu’un data owner volontaire et convaincu vaut mille fois mieux qu’un data owner contraint. Alors que faire si un data owner ne veut pas l’être ? Eh bien, passez au suivant. Une fois que vous aurez identifié tous les data owners volontaires, vous reviendrez aux récalcitrants. Et avec un peu de diplomatie, soit ils auront évolué et compris, soit ils seront remplacés.

Être data owner c’est du travail en plus et ça n’apporte rien ? Objection classique. Mais comme indiqué précédemment, le data owner, la plupart du temps, l’est déjà. Même si ce n’est pas formalisé. Il n’y a donc quasiment pas de tâches supplémentaires. À part peut-être la mise à jour du catalogue de données… mais cela aurait dû être fait par le data owner depuis longtemps. Quant à la reconnaissance du rôle de data owner, elle est importante. En étant affiché comme data owner, la personne en question aura accès aux usages de ses données. Elle comprendra que les données sont importantes, tout comme leur qualité, et leur partage. Et que cela sera possible grâce à lui et à son rôle de référent donnée.

Vous avez d’autres questions pièges, d’autres préoccupations concernant l’identification des data owners, posez-les dans les commentaires, et je serai heureux d’y répondre. Et la semaine prochaine, nous continuons avec la seconde partie où je vous apprendrai à identifier les data owners dans le catalogue de données.