Demandez à dix dirigeants ce qu’est la gouvernance de la donnée. Vous obtiendrez dix réponses : un catalogue, une politique de conformité, une équipe, un tableau de bord de qualité, un projet RGPD. Cette dispersion est révélatrice. Elle explique pourquoi tant d’organisations investissent dans la gouvernance sans jamais en récolter les bénéfices : elles traitent un problème d’architecture et de responsabilité comme un problème d’outillage.

Le symptôme est universel. Deux directions produisent deux chiffres de « chiffre d’affaires » qui ne se recoupent pas. Un même client existe sous quatre identifiants dans quatre systèmes. Un rapport réglementaire mobilise trois semaines de réconciliation manuelle parce que personne ne sait quelle source fait foi. On achète alors un catalogue de données, on nomme un responsable, on lance un programme — et dix-huit mois plus tard, les deux chiffres ne se recoupent toujours pas.

La raison est simple : la gouvernance ne répond pas d’abord à la question « quel outil ? », mais à trois questions structurantes que seule l’architecture peut trancher — qui possède la donnée, que signifie-t-elle, et quel est son cycle de vie ? Cet article pose ces trois questions, le modèle qui les résout, et les modes d’échec à éviter.

Pourquoi le sujet devient urgent

La gouvernance de la donnée n’est pas neuve. Ce qui a changé, c’est le coût de son absence.

La donnée s’est répandue. Le cloud, les services managés et la multiplication des SaaS ont fait exploser le nombre d’endroits où vit une même information. Le périmètre bien délimité de l’entrepôt central a laissé place à un paysage éclaté, où la donnée se duplique plus vite qu’on ne la gouverne.

Les décisions se sont automatisées. À mesure que les organisations industrialisent l’analyse et l’aide à la décision, la qualité de la donnée cesse d’être un confort de reporting : elle devient la matière première de choix opérationnels. Une donnée fausse ne produit plus un rapport erroné — elle produit une décision erronée, à grande échelle et sans supervision humaine.

La réglementation s’est durcie. Protection des données personnelles, exigences sectorielles, traçabilité des traitements : le régulateur ne demande plus seulement « protégez-vous les données ? » mais « savez-vous où elles sont, d’où elles viennent, et qui y accède ? ». Ce sont des questions de lignage et de propriété — des questions de gouvernance.

Le point commun de ces trois forces : aucune ne se résout par un achat de logiciel. Toutes exigent que l’on ait d’abord répondu à qui décide de quoi sur la donnée.

Les trois questions que la gouvernance doit trancher

1. Qui possède la donnée ?

C’est la question fondatrice, et la plus esquivée. « Propriété » ne signifie pas propriété juridique ni possession technique du serveur. Elle désigne une responsabilité : qui a autorité pour décider de la définition d’une donnée, de sa qualité attendue, des règles d’accès et de son cycle de vie ?

L’erreur classique est de confier la donnée à la DSI. La DSI héberge et opère la donnée ; elle n’est pas légitime pour décider ce qu’est un « client actif » ou un « contrat résilié » — ces définitions appartiennent au métier. D’où une distinction que toute organisation mature finit par formaliser :

  • Le propriétaire (data owner) est un responsable métier. Il répond de la définition, de la qualité et des règles d’usage d’un domaine de données. C’est un rôle d’autorité, pas d’exécution.
  • L’intendant (data steward) opère cette responsabilité au quotidien : il maintient les définitions, surveille la qualité, arbitre les anomalies. C’est le bras armé du propriétaire.
  • Le dépositaire (data custodian), côté IT, assure le stockage, la sécurité et la disponibilité technique.

Tant que ces rôles ne sont pas nommés — nominativement, pas « l’équipe X » — la gouvernance reste une intention. La donnée sans propriétaire est une donnée que personne n’a mandat pour corriger.

2. Que signifie la donnée ?

Deux systèmes qui stockent un champ « client » ne stockent presque jamais la même chose. L’un compte les prospects, l’autre non ; l’un inclut les comptes clôturés, l’autre les exclut. Aucune plateforme ne résout cette divergence : elle est sémantique, pas technique.

La réponse est un glossaire métier — un référentiel partagé des définitions, arbitré par les propriétaires, qui fait autorité dans toute l’organisation. Ce n’est pas un dictionnaire technique de colonnes ; c’est le contrat de sens sur lequel s’accordent la finance, le commerce et les opérations. Sans lui, chaque rapprochement de données rejoue la même dispute sur ce que « chiffre d’affaires » veut dire.

À ce glossaire s’ajoutent deux référentiels que l’architecture doit expliciter : les données de référence (les nomenclatures partagées — pays, devises, codes produits) et les données maîtres (les entités pivots — client, produit, fournisseur — dont il ne doit exister qu’une version faisant foi). La gestion des données maîtres (Master Data Management) n’est pas un projet parallèle : c’est le socle qui garantit qu’un « client » est le même client partout.

3. Quel est le cycle de vie de la donnée ?

Une donnée naît, circule, se transforme, se périme et, un jour, doit disparaître. Gouverner, c’est maîtriser cette trajectoire : d’où vient la donnée (le lignage), par quelles transformations elle passe, combien de temps elle est conservée, et quand elle doit être purgée.

Cette dimension est devenue non négociable pour deux raisons. La conformité, d’abord : prouver qu’une donnée personnelle est supprimée au bon moment suppose de connaître tous les endroits où elle a essaimé. La confiance, ensuite : un décideur qui ne peut pas remonter une donnée à sa source ne s’y fiera pas — et une donnée en laquelle personne n’a confiance ne vaut rien, quelle que soit sa qualité réelle.

Le modèle : fédérer, pas centraliser

Face à ce constat, la tentation naturelle est la centralisation : une équipe unique, une plateforme unique, un contrôle unique. C’est l’approche qui échoue le plus régulièrement. Une équipe centrale ne connaîtra jamais assez finement chaque domaine métier pour en arbitrer les définitions ; elle devient un goulot d’étranglement, puis un service que le reste de l’organisation contourne.

Le modèle qui tient est fédéré. Il repose sur un principe simple : la responsabilité de la donnée appartient à ceux qui la produisent et la connaissent — les domaines métier — tandis qu’une instance centrale légère fixe les règles communes et garantit l’interopérabilité. C’est la logique qui sous-tend les approches modernes dites de data mesh : traiter la donnée comme un produit, dont chaque domaine est responsable, avec des standards partagés qui rendent ces produits interopérables.

Trois piliers structurent ce modèle fédéré :

  • Des domaines responsables. Chaque domaine métier possède ses données, les expose proprement aux autres, et répond de leur qualité. La propriété est distribuée, pas diluée.
  • Des standards communs. Une gouvernance centrale minimale définit ce qui doit être partagé : le glossaire, les formats d’échange, les règles de sécurité et de classification, les exigences de lignage. Elle arbitre l’interopérabilité, pas le contenu de chaque domaine.
  • Des contrats de données. À la frontière entre domaines, un contrat explicite la structure, la sémantique et les garanties de qualité de ce qui est échangé. C’est l’équivalent, pour la donnée, du contrat d’interface entre services : il permet à un domaine d’évoluer sans casser ceux qui dépendent de lui.

Ce modèle n’est pas un choix d’outil. C’est un choix d’architecture organisationnelle et technique — la répartition des responsabilités et des frontières — que l’architecte d’entreprise est le mieux placé pour dessiner, parce qu’il voit à la fois les domaines métier et les flux qui les relient.

Pourquoi le catalogue ne suffit jamais

Une organisation sur deux confond « acheter un catalogue de données » avec « gouverner ses données ». Le catalogue est utile — il rend la donnée trouvable et documente le lignage. Mais il ne fait que refléter une gouvernance ; il ne la crée pas.

Un catalogue déployé sans propriétaires nommés se remplit de fiches orphelines que personne ne maintient. Un catalogue sans glossaire arbitré documente la confusion existante au lieu de la résoudre. Un catalogue sans modèle de responsabilité devient un cimetière de métadonnées : exhaustif, à jour le premier mois, obsolète le sixième.

La règle est constante : l’outil vient après le modèle. On ne cataloguera utilement que ce dont on a d’abord décidé la propriété, la définition et le cycle de vie. Inverser l’ordre — l’outil d’abord, la gouvernance ensuite — est le raccourci qui coûte le plus cher, parce qu’il donne l’illusion du progrès tout en laissant intact le problème de fond.

Les modes d’échec à connaître

Les programmes de gouvernance échouent de façons prévisibles. Les nommer, c’est déjà les éviter.

La gouvernance de comité. Un programme qui produit des politiques, des chartes et des réunions, mais aucun changement dans les systèmes ni dans les responsabilités réelles. La gouvernance existe sur le papier ; la donnée reste ingouvernée.

Le grand inventaire. Vouloir cataloguer et documenter toutes les données avant de gouverner quoi que ce soit. L’effort s’épuise avant d’atteindre la donnée qui comptait, et le programme meurt de son ambition.

La propriété fantôme. Des propriétaires nommés sur un organigramme mais sans autorité, sans temps alloué, sans conséquence en cas d’inaction. Un propriétaire qui ne peut rien décider n’est pas un propriétaire.

La qualité sans finalité. Mesurer la qualité de la donnée pour elle-même, sans la relier à une décision ou à un risque concret. On produit des indicateurs que personne n’utilise, au lieu de fiabiliser les données dont dépend une décision précise.

Le tout-ou-rien. Attendre la plateforme parfaite et le modèle complet avant de commencer. La gouvernance utile se construit domaine par domaine, en commençant par ceux où le coût de l’incertitude est le plus élevé.

Une trajectoire, pas un programme

La gouvernance ne se déploie pas d’un bloc ; elle se construit par paliers, en partant de là où la douleur est réelle.

Commencer par un domaine à fort enjeu. Choisir un périmètre où l’incertitude sur la donnée coûte visiblement cher — un rapport réglementaire, une vue client, un chiffre de pilotage contesté. Y nommer un propriétaire, arbitrer les définitions, tracer le lignage. Faire la preuve sur ce domaine avant d’étendre.

Institutionnaliser les rôles. Formaliser les fonctions de propriétaire et d’intendant, leur donner un mandat et du temps. La gouvernance vit ou meurt par la réalité de ces rôles, pas par la sophistication de la plateforme.

Fixer le minimum commun. Établir le glossaire, les règles de classification et de sécurité, les standards d’échange. Le moins possible, mais respecté partout.

Outiller ce qui est déjà gouverné. Déployer le catalogue, les contrôles de qualité, le lignage automatisé — sur des domaines déjà dotés d’un propriétaire et de définitions. L’outil amplifie alors une gouvernance réelle, au lieu de simuler une gouvernance absente.

Étendre par contrats. Domaine après domaine, relier les périmètres par des contrats de données explicites. La gouvernance croît comme un maillage, pas comme une tour de contrôle.

Ce que la direction doit décider

La gouvernance de la donnée est souvent présentée comme un sujet technique. C’est une erreur de niveau. Les décisions qui la font réussir ou échouer sont des décisions de direction : accepter que la donnée appartienne au métier et non à l’IT ; donner aux propriétaires une autorité réelle et du temps ; accepter de commencer petit plutôt que d’attendre le programme parfait ; et traiter la donnée comme un actif dont on répond, non comme un sous-produit des applications.

Aucun de ces arbitrages n’est technique. Tous sont architecturaux, au sens fort : ils portent sur la répartition des responsabilités, les frontières entre domaines et les contrats qui les relient. C’est précisément ce que l’architecture d’entreprise rend visible et décidable — avant qu’un premier outil ne soit choisi. La question n’est jamais « quel catalogue acheter ? ». Elle est : qui possède quoi, que veulent dire nos données, et où vont-elles ? Tant que ces réponses n’existent pas, aucun outil ne les inventera.