Dans la gouvernance des données, la technique prend en charge l'outillage : catalogue, lineage, contrôles de qualité, gestion des accès. Elle ne prend pas en charge les décisions : définir les rôles, fixer les règles, désigner les responsables, arbitrer les conflits. Une plateforme data outille la gouvernance, elle ne la remplace pas. La frontière est simple : l'outil exécute, l'organisation décide.
Beaucoup d'organisations entament leur démarche par l'achat d'une plateforme. Un catalogue, un module de qualité, une brique de gestion des accès, et le sentiment d'avoir réglé la question. Quelques mois plus tard, l'outil est en place mais rien n'a vraiment changé : les chiffres se contredisent toujours, personne ne sait qui tranche, et la plateforme se remplit de fiches que personne ne consulte.
L'idée reçue est tenace. On assimile la gouvernance à l'outil qui la supporte, comme si installer une plateforme revenait à instaurer un cadre. Dans les faits, l'outil ne fait qu'appliquer des décisions. Si ces décisions n'existent pas, il n'a rien à appliquer. Une plateforme posée sur une organisation sans règles ni responsables ne produit pas de la gouvernance, elle produit une vitrine.
La vraie question n'est donc pas "quelle plateforme choisir", mais "qu'est-ce que la technique peut faire à ma place, et qu'est-ce qu'elle ne fera jamais". C'est cette ligne de partage, entre ce que l'outil exécute et ce que l'organisation doit décider, qui détermine si une démarche tient debout ou s'effondre au premier désaccord.
Commençons par le périmètre de l'outil, car il est réel et utile. Une plateforme de gouvernance prend en charge tout ce qui peut être automatisé, centralisé et appliqué de façon systématique. C'est sa force : faire vite, à grande échelle, ce qu'un humain ferait lentement et avec des erreurs. Trois domaines relèvent clairement de cette logique.
Le premier service rendu par la technique, c'est la visibilité. Sans outil, personne ne sait précisément quelles données existent, où elles se trouvent et comment elles circulent. Un catalogue de données répond à ce besoin : il recense les jeux de données, leur source, leur structure, leur propriétaire et leur usage. Il transforme un patrimoine flou en inventaire consultable.
Le lineage, ou traçabilité, complète le tableau. Là où le catalogue dit ce qui existe, le lineage dit d'où ça vient et ce que ça devient. Il documente le parcours de la donnée, de sa source à son usage final, en passant par chaque transformation. Quand un chiffre est contesté, c'est lui qui permet de remonter la chaîne et d'identifier où l'erreur s'est glissée. Cette traçabilité des données est typiquement le genre de tâche qu'aucune équipe ne peut tenir à la main de façon fiable, et que l'outil exécute en continu.
Catalogue et lineage ont un point commun : ils rendent visible, ils ne décident de rien. Savoir qu'une donnée existe ne dit pas qui en répond. Savoir d'où elle vient ne dit pas quelle définition fait foi. La technique éclaire le terrain, elle ne trace pas les frontières.
Le deuxième domaine technique, c'est le contrôle automatisé. Une plateforme applique des tests sur les données : valeurs manquantes, doublons, formats incohérents, ruptures de seuil. Elle détecte les anomalies en continu, alerte les équipes et, dans certains cas, bloque une donnée non conforme avant qu'elle ne se propage.
C'est un apport considérable. Vérifier manuellement la qualité d'un flux qui tourne tous les jours est impossible à tenir dans la durée. L'outil ne se fatigue pas, ne se distrait pas et applique la même règle à chaque exécution. Il transforme un contrôle ponctuel et subjectif en surveillance systématique et reproductible.
Mais une nuance change tout : l'outil applique une règle de qualité, il ne la définit pas. Décider qu'un taux de valeurs manquantes supérieur à un certain seuil est inacceptable, choisir quelles données méritent un contrôle strict et lesquelles non, c'est un arbitrage métier. La plateforme exécute le test. Quelqu'un, en amont, a décidé quel test compte.
Le troisième domaine, c'est la sécurité opérationnelle des accès. Une plateforme gère qui peut voir quoi, qui peut modifier quoi, et trace les consultations. Elle applique les politiques d'accès de façon homogène, sur tous les jeux de données, sans oubli ni passe-droit. Elle automatise aussi la conformité, en documentant qui accède à quelles données sensibles.
Là encore, le bénéfice est net. Appliquer manuellement des droits sur des centaines de jeux de données et des dizaines d'équipes est une source d'erreurs permanente. L'outil applique la matrice d'accès à la lettre, et garde une trace exploitable en cas d'audit.
Le mot clé est "appliquer". La plateforme applique des droits, elle ne décide pas qui doit avoir accès à quoi. Trancher qu'un métier peut consulter les données RH mais pas les modifier, c'est une décision de responsabilité et de conformité. L'outil exécute cette décision avec rigueur. Il ne la prend jamais à votre place.
Passons à l'autre camp, celui que l'outil ne couvrira jamais. La gouvernance des données est avant tout un mécanisme organisationnel : un cadre qui définit qui décide, qui arbitre et qui répond. Cette dimension ne s'installe pas, elle se construit. Et elle relève entièrement de l'humain.
Le cœur de la gouvernance, c'est la responsabilité. Sans elle, les règles restent implicites, les décisions se prennent au cas par cas, et dès qu'un désaccord surgit, plus personne ne sait qui doit trancher. La donnée devient "à tout le monde", donc à personne.
Aucun outil ne crée cette responsabilité. Désigner un Data Owner pour un périmètre, clarifier ce qu'attend l'organisation d'un Data Steward, articuler les niveaux de décision : tout cela relève d'un choix d'organisation, pas d'un paramétrage. La répartition des rôles et responsabilités précède l'outil et le conditionne. Le triptyque Data Owner, Data Steward et Data Custodian structure la chaîne de responsabilité, du sens métier à la mise en œuvre technique.
Une plateforme peut afficher le nom d'un propriétaire dans une fiche. Elle ne peut pas le rendre légitime, ni s'assurer qu'il assume réellement la décision quand elle devient inconfortable. La responsabilité s'incarne, elle ne se renseigne pas dans un champ.
La gouvernance sert à fixer des règles communes et à arbitrer les conflits. C'est l'essentiel, et c'est précisément ce que la technique ne touche pas. Définir ce qu'est un "client actif" quand la finance et le marketing ne sont pas d'accord, choisir quelle source fait référence quand deux systèmes se contredisent, décider quelles règles sont réellement utiles et lesquelles alourdissent inutilement : ce sont des arbitrages humains.
Ces décisions supposent de comprendre les enjeux métier, de peser des intérêts contradictoires et d'assumer un choix. Une plateforme peut stocker la définition retenue et la diffuser une fois qu'elle existe. Elle est incapable de la produire. Le travail difficile, celui de mettre des gens autour d'une table pour trancher, reste entier.
Confondre les deux mène à une impasse fréquente. On attend de l'outil qu'il "mette tout le monde d'accord", alors qu'il ne fait qu'appliquer un accord préexistant. Sans décision en amont, la plateforme n'arbitre rien : elle fige le désordre au lieu de le résoudre.
Dernier territoire hors de portée de la technique : l'adhésion. Une gouvernance imposée par la DSI sans implication des métiers est condamnée, même avec la meilleure plateforme. Si les équipes ne comprennent pas pourquoi elles documentent, pourquoi elles respectent une règle, pourquoi elles passent par un circuit, elles contournent ou abandonnent.
Aucun outil ne crée l'adhésion. Elle se gagne par l'explication, l'acculturation, la co-construction des règles avec ceux qui les appliquent. C'est un travail de conviction et de pédagogie, pas de déploiement. C'est aussi l'une des raisons pour lesquelles tant d'initiatives échouent : on a réglé la partie technique en oubliant la partie humaine, qui est la plus déterminante.
Une gouvernance adoptée laisse des traces dans les usages quotidiens. Une gouvernance non adoptée laisse des traces dans les comptes-rendus de comité, et nulle part ailleurs. La plateforme ne fait pas la différence entre les deux. Les équipes, si.
Pour visualiser nettement où passe la ligne, le tableau ci-dessous répartit les principaux éléments d'une gouvernance entre ce que la plateforme exécute et ce que l'organisation décide.
Une fois les deux camps posés, la frontière devient lisible. Elle ne sépare pas des sujets compliqués de sujets simples. Elle sépare l'exécution de la décision. Tout ce qui consiste à appliquer une règle à grande échelle relève de l'outil. Tout ce qui consiste à choisir la règle relève de l'organisation.
La meilleure façon de classer un sujet est de se demander s'il s'agit d'appliquer ou de choisir. Appliquer un contrôle de qualité, diffuser une définition, faire respecter une matrice d'accès : ce sont des exécutions, et l'outil excelle à les industrialiser. Choisir le seuil de qualité, écrire la définition, décider qui accède : ce sont des décisions, et aucune plateforme ne les prend.
Cette distinction explique pourquoi un même sujet apparaît parfois des deux côtés. La qualité des données, par exemple, est en partie technique (les contrôles tournent automatiquement) et en partie organisationnelle (quelqu'un a décidé quoi contrôler et à partir de quel seuil agir). Les outils de qualité ne sont d'ailleurs jamais qu'un support : ils viennent en appui d'une démarche, ils ne la remplacent pas, comme le rappelle tout panorama sérieux des outils de gouvernance des données.
Le piège, c'est de croire qu'en automatisant l'exécution, on a réglé la décision. C'est faux. Automatiser une règle absurde produit une absurdité très efficace. L'outil amplifie la qualité de la décision sous-jacente, dans un sens comme dans l'autre. Sur une bonne règle, il démultiplie la valeur. Sur une mauvaise, il démultiplie le problème.
Pour trancher dans un cas concret, une seule question suffit : la plateforme accélère-t-elle une règle qui existe déjà, ou est-elle censée inventer cette règle à votre place ?
Si la règle existe, l'outil est à sa place. Il l'applique plus vite, plus largement, plus sûrement qu'un humain. C'est exactement à cela qu'il sert, et l'investissement est justifié. Si la règle n'existe pas, l'outil est prématuré. Il va se remplir de contenu sans propriétaire, afficher des responsabilités fictives et donner l'illusion d'une gouvernance là où il n'y a qu'un logiciel installé.
Ce test protège contre l'erreur la plus coûteuse : déployer avant de décider. Une démarche de gouvernance saine commence par un périmètre limité où l'on clarifie les rôles, on fixe quelques règles, on stabilise les arbitrages. L'outil vient ensuite outiller ce qui a déjà été tranché, et non l'inverse.
La question posée par ce sujet appelle une réponse sans ambiguïté. La technique outille la gouvernance, l'organisation la décide. Le catalogue, le lineage, les contrôles de qualité et la gestion des accès relèvent de l'outil. Les rôles, les règles, les arbitrages et l'adhésion relèvent des humains. Aucun des deux camps ne remplace l'autre.
Le danger n'est pas d'investir dans une plateforme. C'est de croire qu'en l'installant, on a fait le travail. Une plateforme posée sur une organisation sans décisions ne gouverne rien : elle automatise l'absence de gouvernance. À l'inverse, des décisions claires sans outil pour les appliquer restent fragiles et difficiles à tenir à grande échelle. Les deux se complètent, dans cet ordre : la décision d'abord, l'outil ensuite.
Pour situer votre propre démarche, quelques questions suffisent. Vos règles existent-elles avant l'outil, ou attendez-vous de l'outil qu'il les invente ? Chaque périmètre de données a-t-il un responsable qui assume vraiment ses arbitrages ? Vos équipes comprennent-elles pourquoi elles appliquent une règle, ou la subissent-elles ? Votre plateforme accélère-t-elle des décisions prises, ou masque-t-elle des décisions jamais tranchées ? Les réponses disent, mieux qu'un comparatif d'outils, si votre gouvernance repose sur un cadre ou sur un logiciel. Cet équilibre s'inscrit dans une réflexion plus large sur la stratégie data de l'organisation.
👉 À lire aussi : Gouvernance des données : à quoi sert-elle vraiment (et à quoi ne sert-elle pas) ?
👉 À lire aussi : Qu'est-ce qu'une Data Platform ?