Dernière modification le 27 février 2025

Sommaire :

1) Introduction

Ces notes font suite à l’article https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/ .

Elles synthétisent les échanges, les retours que j’ai eu suite à sa publication et à diverses présentations que j’ai pu faire (dont celle dans le cadre de DAMA France : https://www.datassence.fr/2024/11/15/retours-dexperience-gouvernance-des-donnees-dama-france-datacamp20/ ).

Ce contenu vient en complément, parfois en recoupement et redondance avec les thèmes abordés dans le 1^er article.

C’est paradoxal, la gouvernance des données est le sujet le moins sexy de la data et pourtant il soulève une attention importante. Je soupçonne qu’une part des personnes sont à la recherche d’une réponse ultime permettant de se débarrasser du sujet. Ok, c’est bien le problème de nos dirigeants, pas le mien. Et réciproquement vu des dirigeants, j’ai fait ce qu’il faut, je suis couvert, si le terrain ne réagit pas…

La gouvernance des données est l’affaire de tous. Et c’est son principale défi, embarquer tout le monde.

Fatalement au cours de ces échanges, le sujet de la définition de ce qu’est la data gouvernance est arrivée sur le tapis.

J’ai pris le parti de ne pas donner une nième définition et plutôt laisser à chacun se faire sa propre idée à la lecture de ces deux articles et bien entendu de son expérience.

Par contre, je n’ai pas pu résister exprimer ce que ne doit pas être la data gouvernance, en réponse à des définitions, des actions qui m’ont choqué et auxquelles j’ai été confrontées sur le terrain.

Pour le reste, à nouveau une vingtaine de thèmes sur le sujet, par ailleurs sans fin, tant les données sont un vaste sujet.

Ces articles ou notes personnelles comme vous voulez, je l’espère a minima doivent permettre d’éviter les principaux pièges, de donner une vue d’ensemble du sujet (surement pas exhaustive), de proposer des messages clés et pratiques à projeter dans son contexte.

Rappel, il n’y a pas de modèle de gouvernance immédiatement applicable, toute gouvernance est forcément personnalisée. Le tout en évitant les discours de généralités sur le sujet, c’est-à-dire en tenant bien compte de la spécificité data.

D’ailleurs pour terminer cette introduction, avant de parler gouvernance de données, assurez-vous que vos interlocuteurs savent ce qu’est une donnée (une data) et ce que sont les données (les data).

Deux questions qui paraissent triviales, mais qui ne le sont pas. Les fondations de la gouvernance des données reposent sur les réponses à ces deux questions (article à venir).

Soyons clairs : une gouvernance des données robuste est absolument essentielle et ne peut pas être contournée.

Et toujours avoir en mémoire que la gouvernance doit au final s’immiscer (parfois sans se nommer) auprès de ceux qui vivent les données sur le terrain. C’est une porte ouverte éternelle, si vous n’êtes pas capable de faire immédiatement le lien entre vos choix et action de gouvernance avec une valeur métier, alors il y a un problème.

1) Ce que ne doit pas être la data gouvernance

Souvent du bon sens, mais des situations hélas rencontrées.

La data gouvernance n’est pas une finalité. J’ai vu plusieurs fois, des initiatives de gouvernance des données pour la gouvernance des données. Pire, des initiatives data gouvernance tour d’ivoire, où chacun acquiesce parce que c’est porté par la direction. Cela n’a aucun sens, sans avoir auparavant une idée minimale d’une stratégie data.

Dans cet esprit, j’ai aussi souvent vu des initiatives de gouvernance des données qui démarraient par une analyse de maturité data de l’organisation (il existe une multitude de cadres de maturité des données pour cela). Cela n’a aucun sens et ne sert à rien tant qu’on ne sait pas ce que l’on veut faire (cf. la stratégie data).

La data gouvernance n’est pas un projet. J’ai aussi vu plusieurs fois des projets de gouvernance des données. Le résultat n’est pas un produit qui une fois délivré résout le problème. Ce n’est pas un big bang (avant, après). C’est une démarche continue, culturelle (état d’esprit), qui doit s’insinuer dans le fonctionnement au quotidien de l’organisation, qui doit répondre aux changements continus et intrinsèques du monde des données.

Dans ce sens, cela ne se résout pas par une solution technique (bien entendu !), avec l’exemple courant du déploiement d’un catalogue de données.

Ce n’est pas non plus centraliser les données en un endroit (une data platform), pour mieux les contrôler. Solution de facilité (la tête sur laquelle taper) souvent mentionnée dans les motivations d’un data lake par exemple.

La data gouvernance n’est pas « à côté ». Ce n’est pas une troisième force entre la gouvernance métier et la gouvernance IT. – voir l’article https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/ . Et cette approche perdure, avec encore récemment l’exemple rencontré d’une entreprise pour qui la gouvernance se déploie et se mesure au travers de la nomination de data owners à temps plein (erreur).

Pire, je rajouterais l’épanchement d’une équipe de 3 personnes à qui on a confié le sujet de la gouvernance des données, fatigués d’être isolés.

Autre point à éviter, confier à un prestataire sa gouvernance des données. Ce n’est pas un service managé de plus à sous-traiter.

La gouvernance des données n’est pas non plus « haut dessus », c’est-à-dire fondée sur la supervision, le contrôle, l’autorité.

La gouvernance des données n’est pas une autorité imposée, elle doit s’insérer, s’intégrer, s’aligner dans l’organisation existante. C’est un élément en plus de fait pour certains métier alors que pour d’autre la gouvernance est historiquement bien en place. Toutefois, au vu de la prise d’importance des données (nouvelles capacités data, IA), aucun métier n’échappe à une réflexion de gouvernance.

La gouvernance des données n’est pas juste une couverture pour se prémunir voire se détourner des questions embarrassantes sur les données. Ce sont des choix et des actions délibérées avec des impacts qui ne restent pas au niveau de vœux pieux exprimés dans des politiques générales (vécu : on a bien une politique des données mais elle n’est pas appliquée de la faute de …).

La data gouvernance ne se décide pas, ne commence pas quand les données sont là.

Leur définition, naissance, environnement de vie sont essentiels dans une bonne gouvernance des données.

La data gouvernance n’est pas (ne doit pas être) de la bureaucratie supplémentaire.

Vœux pieux, qui dit gouvernance, dit règles à respecter. Mais si on maîtrise bien ce que sont les données, il est possible d’inscrire ces règles à la source et non pas sous le contrôle a posteriori d’une bureaucratie.

La gouvernance des données n’a aucune chance d’être viable sans maîtrise des usages, sans comprendre les raisons de la collecte et de l’utilisation des données (les utilisateurs sont plus important que les data owners).

La data gouvernance ce n’est pas un modèle unique/ universel de gouvernance des données à appliquer quelques soient les data. Un modèle souvent centralisé, sous la responsabilité d’un CDO, la facilité de la tête sur laquelle taper et qui finit épuisé en burn out – cf références https://www.datassence.fr/?s=%22burn+out%22 ). On se rendra compte que plusieurs modèles (dont l’absence de gouvernance !) s’appliquent suivant la nature des données (d’où l’importance de connaître ses données) et de la stratégie associée.

La data gouvernance ce ne sont pas des règles édictées dans des chartes / cadres de gouvernance, imposées sans prises sur les données. Il y a besoin à la fois de connaître ce que sont les données (toujours le même point fondamental) et aussi d’être en mesure de les « toucher » (accéder aux données) pour exercer les responsabilités qu’induit la gouvernance.

La gouvernance des données n’est pas se soumettre à la sclérose régulative.

La data gouvernance ce n’est pas résoudre le problème de la qualité des données et c’est terminé. En disant cela, on limite la gouvernance à un seul de ses aspect et on ignore tout de la nature fondamentale du sujet de la qualité des données. La qualité des données n’est pas intrinsèque, indépendante d’usages, de contextes, de conditions. Sur un même jeu de données, un effort de qualité pour un usage, peut être différent voire à refaire pour un autre usage.

Dans cet esprit, la data gouvernance ne se confond pas avec le data management. Il y a une dérive parfois constatée de voir la data gouvernance virer comme uniquement un problème de data management et perdre la dimension choix stratégiques.

2) Quel est le meilleur cadre de gouvernance : le mien … le vôtre !

Suite à l’article précédent, plusieurs personnes m’ont demandé ce que je pensais des cadres de gouvernance et quel était le meilleur.

La réponse n’est pas simple, au vu du nombre de cadre que j’ai découvert en réfléchissant à la réponse.

Pour ma part, je connais quelques cadres (DAMA – DMBOK en particulier), et je vois ces cadres comme sources d’inspiration dans lesquels puiser (idée de boite à outils).

Avec clairement un point critique dans quelle mesure, le cadre de gouvernance n’est pas « à côté » (voir article déjà évoqué : https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/ ), et est aligné, intégré avec les éléments de gouvernance existant (d’entreprise, IT).

Pour les architectes d’entreprise, voir l’exercice de rapprochement entre le cadre de gouvernance du DAMA et TOGAF (Revue datassence d’octobre 2024 https://www.datassence.fr/2024/11/19/revue-data-du-mois-octobre-2024/#_ftn11 et annexe).

Un bon cadre doit aussi permettre d’atteindre le dernier km (des aspects stratégiques à l’implémentation de règles dans des procédures, automatisées ou non).

Il doit être également très clair sur les responsabilités associées, pas de gouvernance sans responsabilités (une banalité !).

Il y a une justesse à trouver entre être intrusif ou non intrusif. Certain propose un cadre non intrusif – voir l’exemple en annexe – le framework « Non invasive Data Governance (NDG) » avec l’objectif d’intégrer de manière transparente les pratiques de gouvernance des données dans les processus existants, sans les perturber. Comme d’habitude, effectivement il faut s’intégrer au maximum avec les pratiques de gouvernance existantes. Mais il faut aussi volontairement les perturber, faire prendre conscience et s’approprier l’apport de la dimension data.

Et comme d’habitude, un cadre de gouvernance n’est jamais déroulé complètement. Il est adapté au contexte. Seule une part va être utilisée.

Avec l’idée également de ne pas surajouter des contraintes bureaucratiques.

Au vu de son expérience, de son contexte, chacun doit construire son propre cadre de gouvernance.

Et je n’y ai pas manqué !

Au fil de temps, je me suis construit ma propre vision sur la base de mes retours d’expérience (voir la conclusion du précédent article et la dernière version proposée ici en annexe).

Sans oublier également la partie mise en œuvre de tels cadres, les fameuses feuilles de route data, par incréments / paliers, en mode agile pourquoi pas, en s’appuyant sur tout l’art de mener à bien un programme de transformation.

Et si vous voulez vous lancer sur le sujet, voir en annexe également un panorama des cadres rencontrés dans la littérature et sur le terrain (en complément de l’annexe du 1^er article).

NB : à noter aussi le recouvrement avec les cadres de gouvernance de l’information, les cadres proposés par certains éditeurs de solutions logicielles de data gouvernance.

3) Les solutions logicielles supports à la gouvernance

Les solutions en appui de la gouvernance des données sont nombreuses.

On peut citer :

Les outils de catalogage des données, intégrés aux data platforms ou externes,
Les solutions de référentiels de métadonnées,
Les outils de master data management,
Les fonctions orientées gouvernance des données dans les data platforms (couche de gouvernance, avec l’introduction de fonctions métier, par domaine, suivant des rôles data, voir l’exemple de Purview Microsoft – https://medium.com/@yashigoyal1927/microsoft-purview-931bb9e67946 ),
Les data platforms orientées traçabilité des données (étiquetage),
Les moteurs de règles,
Toutes les solutions dédiées à la gestion des accès aux données,
Les solutions dédiées à la gestion de la qualité des données,
Les briques supports à des contraintes de gouvernance : anonymisation, cryptage…,
Les solutions d’observabilité des données,
Les solutions de data sharing – data marketplace, avec par exemple la gouvernance des datasets, data products (détection de redondances, contrôle des usages contrôle des dépendances, supervision du niveau de qualité…),
Les fonctions de type FinOps data,
L’intégration de points de gouvernance dans les outils de développement, IDE …
Le tout « copiloté » par les nouvelles capacités offertes par l’IA.

Voir un exemple d’inventaire ici : https://mattturck.com/landscape/mad2024.pdf (voir les blocs « Data governance & catalog », « Data quality & Observability »).

Et aussi dans l’open source : https://thenewstack.io/open-source-redefines-data-platforms/.

En termes d’outils, la criticité est toujours la même, à savoir le niveau d’intégration de ces outils avec les environnement data (S.I., shadow data, données externes) et avec l’organisation data (UX intégrée).

Cette intégration est parfois formalisée sous la forme d’identification de point d’exécution de politiques de données (ou point d’exécution de gouvernance), que les solutions logicielles doivent couvrir. Exemple des règles qualité, des règles d’accès (ABAC), des règles de traçage, de règles de remontée d’alertes, des règles d’obsolescence (exemple prise en compte de dates limites de conservation de données)…

Certains ont poussé assez loin l’intégration avec par exemple des métriques indiquant au travers du catalogue si tel dataset est passé ou non par tels contrôles qualité.

L’autre point critique, ou défi est la couverture des données prise en charge par ces solutions.

Avec sous-jacent la capacité d’accès aux données et de traitement des métadonnées.

Et rappel, une solution technique n’est pas la solution à la gouvernance.

Avec l’erreur classique – cf l’article « Stop Jumping to Solutions and Think About the Problem » – Source https://www.thoughtworks.com/en-us/insights/blog/you-need-understand-problem

Sur les outils de catalogage des données :https://www.actian.com/blog/data-management/why-next-gen-data-catalogs-are-a-must-have/

Un cas d’usage avec Collibra : https://maniksonituts.medium.com/data-governance-in-collibra-for-the-pharmaceutical-sector-d3e26997b1bc

4) Il ne faut pas casser les silos de données

Lorsqu’on parle gouvernance des données, rapidement le sujet des silos de données arrive sur le tapis. Avec majoritairement, l’idée de casser les silos (à tout point de vue : accès, disparition, mise sous contrôle, absorption dans une vue unifiée des données).

Attention, les silos ne sont pas tous à casser loin de là.

Il existe de fait des silos où les données sont redondantes avec d’autres environnements et ceux-là sont à casser (aux architectes de données de travailler – avoir plusieurs responsables de mêmes données n’est pas bon, ainsi que l’inverse, c’est-à-dire des données sans responsables).

Il existe des silos où les données sont enfermées et ceux-là sont à ouvrir (casser le problème d’accès).

Et il existe des bons silos de données, à conserver, parce qu’ils couvrent des spécificités locales à ne pas perdre (données, modèles de données et contexte de production des données). Avec en termes de gouvernance, le sujet clé de la responsabilité. Dans ces silos, on a souvent des acteurs en responsabilité, attachés à leur savoir-faire, environnement.

Il ne s’agit surtout pas de les « casser » mais au contraire de les embarquer.

La gouvernance doit être au plus près de ceux qui vivent les données, qui en ont l’expertise et en assument la responsabilité (bien précieux, à valoriser). Elle ne doit pas prendre la place de ce qui existe dans le silos.

Elle doit transcender le silo, dans le sens, lui apporter un cadre plus large, commun (pour porter des processus transverses, le besoin en interopérabilité, la nécessité de respecter des enjeux plus large que la valeur portée par le silo, identifier ce qui peut être mutualisable…).

Casser de tels silos, c’est une erreur et une perte en termes de données.

Cette logique de silos est à analyser également en termes de domaines métier (domain driven design) et de modularité d’architecture de données.

Les concepts de data product et de data contract sont utiles pour faire progresser la gouvernance des silos de données.

En termes de gouvernance, faire attention aux injonctions auprès des silos, injonctions hélas fréquemment rencontrées : mettez vos données dans cet « espace » centralisé et on s’en occupe, répondez aux demandes de l’équipe centrale de gouvernance qui va contrôler vos données.

Pour avoir été architecte data de processus transverses, inter organisationnels, je me suis retrouvé en face de silos de données, de chapelles de données. Indubitablement le discours de faire rentrer leurs données dans une vue unifiée ne passe pas.

Les données de base sont utilisées dans chaque transaction, tout au long de ces processus, mais de différentes manières et à des fins différentes. Et ces différences sont une force. Il faut les fédérer, les faire collaborer mais ne les casser pas.

Exemple rencontré : le processus transverse d’une demande d’intervention, jusqu’à son exécution auprès d’un client. Avec comme silos : les données de la relation client (demandes à l’initiative du client ou de l’entreprise), les données marketing, les données contractuelles, les données d’infrastructure (là où l’intervention doit être faite), les données logistiques et d’intervention (pilotage et suivi des interventions), les données RH (intervenants, sous-traitants), les données achats, les données d’exploitation (de l’infrastructure), les données financières (coûts des interventions, ROI)…

Allez trouver une personne responsable de la gestion de bout en bout de l’actif de données d’un tel processus… ! La responsabilité est répartie. Vécu, l’exercice d’interface entre silos (au sens qui est responsable de ce qui entre et qui sort en termes de données), comme une révélation auprès des métiers concernés en termes de leur responsabilité.

Ce choix de ne pas casser les silos, pose la question de jusqu’où sont-ils autonomes ?

La réponse est une logique d’enchâssement (voir ce que propose l’approche data mesh – point n°14 sur centralisation / décentralisation).

La matrice suivante permet de cibler cette autonomie par rapport à l’idée de règles d’alignement issues de la gouvernance (définies dans les politiques : d’accès, de sécurité, réglementaire, d’interopérabilité …).

Pas d’alignement et Forte autonomie : anarchie – ECHEC	Alignement et Forte autonomie : Confiance – SUCCES
Pas d’alignement et Pas d’autonomie : micro management central – ECHEC	Alignement et Pas d’autonomie : Tyrannie centrale – ECHEC

Voir aussi sur Datassence ce sujet souvent évoqué : https://www.datassence.fr/?s=silos

Voir aussi une vision plus large, stratégique sur les silos organisationnels : https://frankdiana.net/2024/03/08/beyond-the-silo-how-exploding-possibilities-are-fueling-the-rise-of-horizontal-ecosystems/#more-14481 et imaginer la réponse en termes de données.

5) De la théorie à la pratique, le portefeuille d’initiatives data comme outil pivot

NB : fait suite à la partie « 4) Cas d’usage et gardiens data un couple efficace de mise en place de la data gouvernance » – rôle du portefeuille data – https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/#_ftn4

Il existe un certain nombre de concepts théoriques autour de la gouvernance de données.

Ces concepts permettent d’appréhender dans son ensemble le sujet.

La difficulté est ensuite de passer à la pratique.

Pour cela, il existe un outil pivot : le portefeuille d’initiative data (voir article précédent).

Par expérience, ce portefeuille est l’outil pratique par excellence. J’ai pu l’expérimenter à deux occasions, comme support de dialogue direct avec une Directrice des Systèmes d’Information et comme support auprès de membres du COMEX dans le cadre de l’accompagnement du développement d’un nouveau métier.

Ce portefeuille a le mérite de proposer une vue d’ensemble des initiatives data (idées, cas d’usage, projets et volets data, programmes data, irritants, démonstrateurs, expérimentations d’un datalab, initiatives d’acteurs locaux, industrialisation de ces initiatives…).

C’est un pont relationnel entre toutes les parties prenantes autour de la gouvernance.

C’est le moyen d’identifier les « moments de gouvernance » où les questions et besoins de gouvernance apparaissent « naturellement » (par exemple l’évolution d’un service), versus lancer une initiative de gouvernance à l’aveugle.

C’est un outil extrêmement vivant (j’ai eu l’occasion d’en gérer un sur plusieurs années).

Il concrétise les concepts théoriques invoqués lorsqu’on parle de gouvernance :

Le besoin d’une vue holistique des données et de leur environnement : le portefeuille apporte la vision d’ensemble des usages des données,
Avec la capacité de suivre ces usages et donc le besoin de rétroaction nécessaire à la gouvernance,
Dans cet esprit Il s’inscrit dans l’idée du vue systémique et de lean gouvernance (ajustement de la gouvernance en fonction des feedbacks tout en s’inscrivant dans la racine des systèmes),
Il permet de s’assurer du passage à l’échelle en permettant d’appréhender la couverture des initiatives data au sein de l’organisation, ainsi que l’industrialisation d’initiatives locales,
Il est un outil de pilotage permettant de qualifier les paliers de gouvernance (palier au sens – niveaux acquis et à valeur obtenue, sans attendre que la cible finale soit atteinte), mais aussi les fameux quick win,
Il centralise les demandes, dont les demandes opérationnelles, et même le lot de demandes ad hoc (nombreuses, résolues parfois à la marge des projets parce que se limitant à une requête dans une base de données, mais qui sont riches en enseignements et que les outils de ticketing peuvent aider à suivre),
Et le graal, il permet de suivre comment la stratégie data se décline (de l’initiative data à sa contribution à la stratégie).

La gestion de ce portefeuille peut se retrouver : sous la responsabilité d’un acteur central (le CDO, l’architecte data d’entreprise), sous la responsabilité d’un collectif, alimenté via un processus de gestion des demandes data (stratégiques, opérationnelles, fonctionnelles), inscrit dans l’élaboration pluriannuelle du schéma directeur d’entreprise…

Attention, on parle bien d’un portefeuille d’initiatives data. Le terme initiative n’est pas neutre.

Le portefeuille n’est pas uniquement un inventaire de cas d’usage modélisés du quotidien métier. C’est aussi l’occasion de penser data (voir point n°17), jusqu’à revoir la façon de travailler par le levier des données. L’idée est que chacun de façon autonome, responsable puisse faire part d’initiatives data qui pourront devenir ou non des cas d’usage bien modélisés.

Pour finir, j’ai vu des bons communicants (indispensables) produire des visuels à partir d’un portefeuille data (des cartes de son contenu), mettant en relief, les valeurs produites par les données, les moyens consacrées, par domaine, pour le bien commun, transverse, la projection dans une feuille de route pluri annuelle.

6) Interopérabilité et gouvernance

Il y a un sujet parfois évoqué mais rarement développé dans le périmètre de la gouvernance de données. Ce sujet c’est l’interopérabilité dans le monde des données.

Le terme a une connotation technique, de tuyaux qu’on ne peut pas brancher ensemble, faute d’avoir le même diamètre (cf. l’exemple de l’écartement des rails de chemin de fer entre la France et l’Espagne).

Pourtant ce sujet est au cœur de la gouvernance des données.

Un des principes forts que la gouvernance des données doit édicter, c’est le respect des règles d’interopérabilité. Ces règles doivent figurer dans les politiques de données et être implémentées dans le S.I. (dans le code et dans les procédures / processus).

L’interopérabilité se situe à différents niveaux : au niveau technique, au niveau fonctionnel et au niveau métier.

Le niveau technique et fonctionnel sont l’affaire de l’IT et de sa gouvernance (par exemple limiter la disparité de formats de données, de moyens d’exposition des données à gérer par le S.I.).

Le niveau métier est l’affaire de l’organisation dans son ensemble.

L’interopérabilité concerne :

Le choix de standards, de normes comme le partage d’une définition commune pour des données de même nature (exemple de la définition / standardisation des adresses – très vieux sujet !),
La définition et la mise en circulation des identifiants des objets métier dans les processus et systèmes associés,
Le respect des référentiels de données en termes d’accostage par les différentes briques du S.I.,
Le respect de nomenclatures partagées (et limiter les transcodifications),
Et souvent oublié, l’interopérabilité des systèmes supports aux métadonnées (essayez d’obtenir une image complète du lineage de données, entre les développeurs qui ne font pas l’effort et ceux qui doivent jongler entre N briques techniques d’enregistrement de métadonnées).

La gouvernance des données doit s’assurer que telle définition est bien partagée, que les identifiants circulent bien entre les systèmes, que les référentiels sont respectés, que les formats de représentation des métadonnées sont communs (voir à ce titre l’intérêt de ce qu’il se passe au niveau des data products).

L’idée ici est de limiter les couts liés aux frictions résultantes de l’absence d’interopérabilité : transcodifications, mise en place de passerelles de traductions de données entre systèmes, efforts supplémentaires lorsque des échanges de données doivent être mis en place, ruptures ne permettant pas d’avoir une vision bout à bout d’un processus, portabilité des données impossible, etc.

Le tout se répercutant au niveau sémantique et donc usages des données (incompréhension sur un même terme utilisé avec deux définitions différentes, difficulté à obtenir une vue 360° des données d’un client faute d’identifiant commun entre plusieurs dimension – données contractuelles, données de contact client, données opérationnelles, dans la même idée, difficulté à croiser des données entre-elles…).

Si vous écoutez bien au cours des réunions liées à des problématiques data, une large part est consacrée à comprendre par où passent les données et comment. Pour ensuite construire des passerelles et des briques d’intégration de données. Tout cela est une charge et certains parlent même de charge cognitive d’intégration ! Et cela concerne aussi bien les acteurs métiers que les développeurs qui doivent jongler avec un nombre important de systèmes différents. C’est un des apports moins connu de l’interopérabilité, elle réduit la charge cognitive (a minima le nombre et la durée des réunions).

Plus des données ont de la valeur dans leur partage, plus le sujet de leur interopérabilité est important (voir l’exemple du partage et de la collaboration autour de données de santé).

Dans ce périmètre, est inclus la gouvernance des nomenclatures. Vaste sujet qui mériterait un développement complet (voir quelques notes sur je sujet – https://www.datassence.fr/?s=nomenclature ). Quelle définition des catégories présentes dans une nomenclature ? Suivant quelle granularité ? Comment faire évoluer une nomenclature sans bousculer l’historique ?

Et pour rappel, les nomenclatures portant sur la catégorisation, sont une forme de pouvoir (comment on classe tel objet) … normalement une préoccupation première en termes de gouvernance (par exemple sur les aspects éthiques, catégories interdites, mises à l’index de populations…).

7) Sans prise sur les données difficile d’en assurer la gouvernance

L’accessibilité aux données est souvent cité comme le 1^er problème des données.

Pour gouverner, au-delà de pouvoir accéder aux données, il faut avoir de la prise sur les données.

C’est-à-dire, être en mesure d’y appliquer les règles de gouvernance.

Et cela n’est pas toujours facile, entre les données enfouies dans des vieux systèmes, isolées dans des silos, dupliquées de multiples fois, mélangées au sein de supports de stockage multiples et présentes dans différentes formes de shadow data.

Le défi peut être immense et « désole » les CDO et data owners. Dans le sens, où il leur est difficile d’exercer leurs prérogatives. Comment assumer ses responsabilité vis-à-vis de données inaccessibles, sur lesquelles les prises sont difficiles.

La solution du catalogue de données a ses limites (gestion manuelle, automatisation demandant une maîtrise des métadonnées, couverture totale difficile).

La gestion d’un graphe de données est également un apport (il permet d’aller plus loin qu’un simple inventaire en permettant de visualiser les dépendances entre données).

Ces solutions aident mais ne permettent pas une prise sur les données lorsqu’elles sont là. Toute la partie amont (naissance et cycle de vie) n’est pas dans leur périmètre.

Les concepts de data products et de data contracts sont des bonnes prises sur les données. Mais ils ne peuvent pas s’appliquer à toutes les données. Et leur intégration dans les S.I. n’est pas immédiate (NB : dans les S.I. bien architecturés, l’idée de data contract ou de contrat d’interface n’est pas nouvelle. Dans certain S.I. cela perdure, dans d’autres cela s’arrête à des descriptions techniques et pour d’autres cela a été malheureusement oublié).

L’idée de gestion centralisée des données est aussi vu comme une solution. En centralisant toutes les données dans un seul endroit (data platform, data stack), on peut estimer avoir une meilleure prise sur les données. Mais cette idée de vue centralisatrice (unifiée) des données est pour partie un mythe (REX ateliers sur ce sujet à venir …).

Enfin les dispositifs de data sharing (partage de données, data marketplace) sont aussi des prises sur les données.

Derrière cette idée de prise sur les données, se trouve une part de la stratégie vis-à-vis des métadonnées (l’autre part concerne la maîtrise du contexte des données).

Cette stratégie peut être plus ou moins sophistiquée, jusqu’à l’idée de gérer des étiquettes attachées aux données (sur le sujet voir les pages 9,10 puis 32 et 33 du guide « Dynamique

des Data Platforms » – https://www.datassence.fr/2024/04/23/dynamique-et-panorama-des-data-platforms/ – téléchargeable ici https://orkestra-data.com/orkestra-ressources/ ).

A eux seuls les acteurs data (CDO, data owners, data stewards) n’arriveront pas avoir une prise sur toutes les données sous leur responsabilité.

La gouvernance est l’affaire de tous. Tout le monde peut être amené à proposer des prises sur certaines données et a besoin de prises sur d’autres données.

D’abord pour découvrir les données puis y accéder (NB : un sujet prioritaire de la gouvernance des données – rendre visible les données).

Et vu une initiative intéressante d’une équipe décisionnel qui à chaque tableau de bord associe et affiche tout un ensemble de métadonnées permettant d’appréhender les données mobilisées (sources, processus de collecte, définitions, niveau de qualité, règles embarquées, niveau de sensibilité, éléments de contexte connus, consommateurs actifs du tableau de bord). Leur idée : rendre visible la gouvernance des données dans les tableaux de bord, outre pour mieux donner du sens à ce qu’expose le tableau de bord, mais aussi pour adapter la gouvernance (NB : avec par exemple, le pire, éviter de produire des tableaux de bord que personne ne consulte !).

8) Le 8ème frein de la gouvernance des données : le problème du rythme

Dans l’article précédent, j’ai cité 7 freins à la gouvernance des données.

Je vais en rajouter deux, ce 8^ème frein et un 9^ème à la suite.

Ce frein concerne le décalage entre le rythme de la gouvernance et le rythme business / métier.

Face au rythme effréné des affaires, du développement de nouveaux produits et tout simplement des organisations, le rythme de la gouvernance apparait comme un frein.

La gouvernance reposant sur des structures rigides veut imposer son rythme, imposer des actions, obliger à des réactions qui épuisent tout le monde (collaboration difficile, résistance à lever).

Le défi : la gouvernance doit suivre le rythme.

Certains parlent de gouvernance agile (à la mode). On parle même de GouvOps en analogie au DevOps.

Mais quand le besoin en gouvernance apparait, il est parfois déjà trop tard.

Si la gouvernance est directement intégrée à l’activité, de fait la réactivité sera meilleure.

La dynamique métier n’attendra jamais que la gouvernance soit en place.

Et souvent vient se rajouter à cela le prétexte du temps. Le projet métier ou IT n’a pas de temps à consacrer à la gouvernance.

En général deux rythmes cohabitent en termes de gouvernance.

Un rythme de fond, avec la mise en place par incréments des moyens de gouvernance à combler (cf. l’idée de palier versus étape).

Et un rythme qui colle au métier.

Le tout en essayant au mieux d’anticiper les moments de gouvernance avant qu’ils surviennent (plus facile par exemple avec les échéances réglementaires). Un travail sur les irritants permet de présenter des solutions prêtes à l’emploi (type prévention des risques).

Retour d’expérience, en tant qu’architecte de données, j’ai été amené à suivre des revues de processus d’entreprise. Ces revues biannuelles étaient une source incontournable d’identification de sujets / moments potentiels de gouvernance à anticiper (défaut de qualité de données, indicateurs non alignés, risques de collecte sur de nouvelles données, recommandations de conformité à préparer, normalisation de données…).

Dans le même temps, on m’a demandé d’accompagner un programme massif de mise en conformité de durée de conservation de données personnelles qui venait s’ajouter à un second programme de mise sous contrôle des accès à certaines données. Autant le dire tout de suite, les acteurs sollicités se sont retrouvés submergés face à ces initiatives, jusqu’à freiner les actions liées puis les rejeter (avec le classique « ghosting » vis-à-vis des acteurs transverses en charge de ces programmes).

En tout état de cause la mise en place d’une gouvernance de type big bang n’est pas la bonne approche. En faisant cela on veut imposer le rythme de la gouvernance aux acteurs de l’organisation alors que c’est la posture inverse qui doit être adoptée.

Un dernier retour d’expérience sur ce thème, comment maintenir la dynamique de gouvernance (accompagner le métier, anticiper) sans que cela soit un fardeau ? La réponse vécue reposait sur une cellule de data stewards organisée en mode commando et non pas en mode exécutants / contrôleurs bureaucratiques de procédures de gouvernance.

9) Le 9ème frein : la gestion des conflits

La gouvernance a pour mission de fluidifier l’accès aux données, d’éliminer les frictions.

Et ces frictions sont parfois conflictuelles.

Chaque source de données a souvent sa propre gouvernance (politiques d’accès et autres SLA) pour ses propres besoins.

Et les données concernées peuvent intéresser d’autres utilisateurs qui ont leurs propres exigences.

Chaque domaine métier a naturellement ses propres priorités et exigences sur des données partagées, circulantes. Par exemple, la direction marketing a besoin que les données des interventions clients soient mises à jour quotidiennement, tandis que la direction industrielle qui gère les interventions ne consolident ses données qu’à une fréquence mensuelles.

Chaque domaine métier protège ses données (voir aussi le point n°4 sur les silos). Et c’est naturel. Quels sont les usages qui vont en être fait par des tiers ? Avec la crainte qu’une part de son travail (et responsabilité) s’échappe. Et également la crainte de se mettre en dépendance d’autres acteurs (NB : on aime bien récupérer facilement les données des autres et moins partager les siennes, avec l’excuse de la sécurité souvent utilisée pour ne pas partager).

La gouvernance doit résoudre les conflits (dont qui paie les évolutions nécessaires attendues par des utilisateurs externes à ses données. Ouvrir, partager des données a un coût).

Pas en imposant une vue unifiée, mais en ménageant chaque domaine tout en les amenant à collaborer / coopérer.

Par exemple l’idée de data product aide à résoudre les conflits. Un data product matérialise la responsabilité d’un producteur auprès de consommateurs (la qualité de son produit, de ses livraisons). L’idée à elle seule ne suffit pas. La gouvernance doit maîtriser les dépendances qui se crée entre le producteur et les consommateurs.

Lorsque des conflits surviennent (par exemple, des problèmes d’accès ou de qualité des données divergent), leur résolution doit être au plus proche du point de production. Mais cette résolution n’est pas forcément dans le bon timing pour les consommateurs et le producteur peut y voir un impact important sur sa source de données non forcément pour son bénéfice immédiat.

La gouvernance doit alors décider.

10) Sans gouvernance des métadonnées pas de gouvernance

D’où viennent les données ?
Qui a collecté les données ?
Pourquoi ont-ils collecté les données ?
Quelles sont les méthodes et les paramètres utilisés pour
collecter les données ?
Les données ont-elles été traitées d’une manière ou d’une autre ? Si oui,
comment, pourquoi et par qui ?
Quelles pratiques d’hygiène des données les données ont-elles
été appliquées ? Par qui et comment ?
Comment les données ont-elles été stockées ?

…

Les réponses à ces questions sont des métadonnées.
Et ces métadonnées sont un ingrédient important dans l’intelligibilité et la confiance aux données.

Mais elles sont aussi clé pour la gouvernance.
Pour gouverner il faut faire des choix, décider et pour cela il faut s’appuyer sur des données.
Ces données sur les données (métadonnées) forment un système à part entière.
La difficulté va être jusqu’où investir dans un tel système ? Entre prendre ce qui existe et construire un système de système. Parce que ces données (métadonnées) sont de fait étroitement dépendantes des environnements – systèmes de données (les S.I. principalement).

Les bonnes pratiques de développement doivent normalement apporter une large part de ces métadonnées : documentation, logs, sondes – mesures.
Malheureusement ce n’est pas le cas.
Et quand cela existe, l’hétérogénéité est de mise.

Face à cela, la facilité est de rassembler les données et les métadonnées en un seul endroit : un data lake (ou encore un data lakehouse) et un catalogue de données.

De toute façon, s’attaquer au S.I. existant pour qu’il fournisse les bonnes métadonnées est trop lourd. Donc, on va s’attacher à les produire dans ces visions centralisées, par un effort au moment de l’alimentation ou en management du data lake (et pour contrôler le phénomène de data swamp) et par un effort manuel via un data steward en charge de l’alimentation du data catalog (on inclus ici aussi l’idée de data marketplace, de data sharing).

On le sait une telle vue unifiée a ses limites et est un mythe.
Sauf pour des métiers qui partent d’une page blanche et adopte un système data centric dès le départ.

Le data mesh au travers les métadonnées associées aux data products apporte une solution. La vue unifiée est formée du maillage des data products.

La stratégie vis-à-vis des métadonnées est essentielle (quelles métadonnées, via quels moyens, à quels couts, pour quels cas d’usage, pour quels services de gouvernance…).
La gouvernance des données doit s’interroger sur la gouvernance des métadonnées pour ses besoins.
Sans gouvernance des métadonnées pas de gouvernance des données.

C’est un peu exagéré, la cible idéale serait une couverture complète en métadonnées de toutes les données à gouverner. Avec dans le rôle du gardien, un référentiel central des métadonnées*. Cette cible idéale n’est pas atteignable (jusqu’où aller en termes de métadonnées !) et relève du fantasme d’éliminer toute part humaine de la vie des données.

Mais cela aide !

* Si vous voulez vous lancer dans cet exercice, un tel référentiel existe par exemple à l’Insee, indispensable de par leur métier de professionnel des données – source https://www.insee.fr/fr/information/4168396?sommaire=4168411. Et la fonction (référentiel de métadonnées) apparait dans certaines data platforms.

Et rappel, les gérer entièrement à la main est trop lourd. C’est impossible de suivre tous les changements – NB : je n’ai jamais rencontré un document descriptif sur des données à jour … pas de chance ?! (voir aussi ce sujet dans l’article précédent).

Il faut faire appel à toute la chaîne de gestion du cycle de vie des données (MOA, développeurs, data stewards, utilisateurs…) et automatiser au maximum pour les produire… tout le monde est bien concerné par la gouvernance même au niveau des métadonnées.

Rappel de quelques services de gouvernance qui font appel aux métadonnées :

Cartographie des données,
Partage de données (donner les bonnes informations aux consommateurs des données),
Observabilité des données (dont la consistance entre usages de même données)
Sécurité (dont gestion des accès),
Traçabilité du cycle de vie des données pour preuve dans des cadres réglementaires (BCBS, SOC…) – lineage statique et dynamique[1],
…

Pour finir, gouverner les métadonnées est incontournable par rapport à leur valeur et leur rôle en termes d’accès aux données … avec l’équilibre à trouver de leur protection comme source potentielle de problématique de sécurité.

C’est un peu une mise en abîme, les métadonnées contrôle les données. Les métadonnées sont des données … et donc doivent être contrôlées. D’où le rôle d’autorité de la gouvernance des données vis-à-vis des métadonnées 🤯… mal à la tête ?!

[1] A avoir en tête que la traçabilité est un enjeu majeur dans l’usage des données. Et cela à tous les niveaux, du développeurs qui ne fait pas confiance aux données qu’il manipule*, jusqu’à une autorité réglementaire qui a besoin qu’on lui fournisse l’origine des données qu’on lui transmet.

Lorsqu’il n’y a pas de métadonnées ou que celles-ci sont inexactes difficile de se fier aux données.

Le paradoxe, la part de développeurs qui font l’effort de mettre à jour correctement les métadonnées les concernant reste très faible (hélas hors scope des critères de vélocité par exemple).

* https://thenewstack.io/50-of-engineers-lack-trust-in-the-data-they-rely-on-most/

Voir aussi l’idée de méta-grille – https://metagrid.ch/ – qui fait le lien entre la gestion des métadonnées et la vision développeur pour disposer d’une vue système des données.

NB : les discours sur les métadonnées sont souvent difficile à comprendre … c’est technique, c’est métaphysique !

Mais derrière cela se cache une réalité matérielle. Par exemple dans le domaine de la traçabilité des produits (retail, monde de la santé – médicament), Il y a de nouvelles exigences par les autorités (normes, reporting, standards) avec des enjeux de société (exemple EU le Digital Product Passport (DPP)). Et tout cela passe par les données et métadonnées. Les manufacturiers doivent apporter la trace / la preuve de comment ils ont produits les étiquettes de leur produit, qui elles-mêmes garantissent les produits ! Et les consommateurs (et aussi associations / états) sont de plus en plus attentif à cela (exemple dans le retail avec des QR code qui permettent de lire les étiquettes d’un produit … avec toute la problématique de comment est construit cette étiquette … élément de confiance. Voir par exemple ce qu’il se passe sur le nutriscore ou encore les tensions sur les données de l’application Yuka https://yuka.io/ ).

11) La gouvernance des données au service de l’IA et l’IA au service de la gouvernance des données

Impossible de ne pas parler de l’IA à propos de la gouvernance des données.

A double titre :

La gouvernance des données nécessaire aux besoins des moteurs d’IA,
Et l’IA au service de la gouvernance des données.

Avec en perspective également, les régulations possibles autour de l’IA, comme la dernière loi Européenne qui embarque des contraintes en termes de pratique de gouvernance des données (traçabilité, classification des données…).

Il ne s’agit pas ici de détailler tout ce que ce sujet IA tire (voir pour cela https://www.datassence.fr/2024/04/08/lia-pour-et-par-les-data-platforms/ – mise à jour en cours).

A titre d’exemple avec l’IA générative, les attentes en termes de gouvernance sont grandes (même si la pression du couple Trump / Munsk élimine certains contraintes).

Mais a minima, la bataille est intense entre tous les modèles et moteurs d’IA (avec en filigrane tous ceux qui s’amusent à défier les moteurs d’IA en leur faisant produire des résultats non à propos).

La gouvernance joue un rôle clé dans cette bataille au travers des points suivants qui reposent tous sur des données et métadonnées :

De base la qualité des données selon la logique garbage in garbage out).
Partout il est dit que les projets d’IA consacrent plus de 80% de leur temps dans la collecte, nettoyage et préparation des données (temps où la course aux métadonnées, à la gestion des métadonnées sont essentielles).
La qualité de contextualisation des données (voir le sujet des métadonnées), dont la partie difficile d’explicabilité (par exemple l’association de sources référentes) et de réduction des « hallucinations » (plus le contexte est riche – dont décrit par des métadonnées, mieux les « hallucinations » peuvent être traitées. D’une façon générale sans contexte difficile d’interpréter correctement n’importe quelle donnée).
Le suivi en continu, pseudo temps réel des changements sur les données. Avec le cas du data drift (changement de définition, de sens de données).
La prévention du data poisoning, du data leakage et autre jailbreak (et attaques par prompting).
La mise en place de règles de contrôle éthique, de politiques (de quoi a-t-on le droit de parler avec l’IA…).

Et réciproquement, l’IA peut être un allier pour la gouvernance : appui à la génération de la documentation, des métadonnées, à la supervision (data observabilité)…

Zoom sur le cas des données non structurées

En complément de : https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/#_ftn17

Les données non structurées (sons, vidéos, textes) sont sur le devant de la scène au travers de la nouvelle vague IA.

Ce sont les nouvelles stars des données (les moteurs d’IA générative ont paradoxalement plus de mal avec les données structurées jusqu’à l’idée de les considérer comme des données non structurées …. mais c’est un autre sujet).

Leur gouvernance devient essentielle :

Comme source « conforme » pour les moteurs d’IA,
Comme source permettant d’extraire des données structurées par les moteurs d’IA (et la promesse des Agents IA capable de naviguer dans l’ensemble de ces données pour vous soulager de tâches administratives – remplir tel formulaire, extraire telle donnée de tel pdf…).

La gouvernance de ces données diffère pour partie de celle des données structurées.

Elle rejoint les historiques gestion documentaire, gestion de la connaissance, gestion de l’information et gestion de la bureautique.

Ces données introduisent une complexité supplémentaire en termes de support, format, métadonnées, structuration possible à la lecture, éparpillement (file system, cloud, supports personnels de stockage, boîtes aux lettres…), décentralisation jusqu’aux individus et leurs fichiers et avec une forte présence hors maîtrise IT (contenus d’emails, fichiers bureautiques, documentations, supports de communication, pièces jointes de chat, visio…).

La question de la qualité de ces données se pose différemment (comme qualifier une source texte pour un moteur d’IA).

Elles sont facilement redondantes (des fichiers un peu partout). Elles sont hétérogènes et une lecture de leur obsolescence n’est pas immédiate (évidente). Sans compter l’aspect fake difficile à maîtriser.

A voir par exemple la proposition de Daniel Sonntag, dans son article « Évaluation de la qualité des données textuelles en langage naturel », qui décrit quatre « dimensions de qualité du texte (avant l’arrivée de l’IA générative) – source https://tdan.com/through-the-looking-glass-what-does-data-quality-mean-for-unstructured-data/32254.

Auteur et source D. Sonntag – https://www.dfki.de/~sonntag/text_quality_short.pdf

En termes de gouvernance, il existe depuis longtemps des normes ISO, tel que pour la gestion des documents, l’ISO 19475:2021.

Il faut se souvenir aussi des acquis en gouvernance en lien avec les sujets de GED (gestion électronique de documents) et de KM (knowledge management).

L’autre particularité des données non structurées est leur lien avec le langage naturel (texte, voix, sous-titrage de vidéo, labélisation).

Et ce lien induit tout un ensemble de biais, de problématique de terminologie (terme employé dans un domaine avec une définition différente pour un autre domaine – voir des exemples dans le secteur bancaire), de langues, de place par rapport à un contexte historique, sociologique, de qualification par rapport aux auteurs, d’informations sensibles présentes au détour d’un texte (par exemple des données personnelles dans le fil d’une conversation), de maîtrise de l’étiquetage textuel de contenus médias par les data workers (voir le point n°18 – gros plan sur les rôles data), etc.

Tout cela est difficile à maîtriser et pourtant c’est la base de la matière première des chats ou agents des IA génératives.

Et c’est un gros changement en termes de gouvernance. On passe d’une matière dédiée à la communication humaine à une matière alimentant des moteurs d’IA, une machine avec des exigences différentes.

12) Quand la gouvernance des données au niveau d’une organisation doit prendre en compte la gouvernance des données à l’échelle des gouvernements / états

L’intersection entre la gouvernance des données à l’échelle des entreprises et la gouvernance des données à l’échelle des gouvernements / états prend une place de plus en plus importante.

La localisation des données imposées (souveraineté), l’ouverture réglementée de données (interopérabilité, portabilité), le data governance act européen, les règles de gouvernance imposées par exemple par l’IA Act, sont des exemples qui font que la gouvernance des données à l’échelle des entreprises doit elle-même se conformer à des exigences plus larges.

Ces exigences forment un cahier des charges qui va nécessiter de mettre en place une gouvernance des données adaptées. Exemple les datasets supports aux moteurs d’IA, doivent faire l’objet d’une gouvernance spécifique, en termes de risques, de représentativité, de surveillance, de traçabilité, de suivi des évolutions.

La gouvernance de données s’impose aux entreprises.

Avec un effet récursif, la gouvernance de données pour la gouvernance des données. Par exemple pour une gouvernance correcte de la représentativité de jeux de données personnelles (s’assurer que telles et telles populations ne sont pas « oubliées »), il y a besoin de gérer des données (métadonnées) représentatives de ces jeux de données, métadonnées elles-mêmes sujettes à une gouvernance.

Zoom sur la souveraineté – maîtrise de la résidence de ses données

La souveraineté vis-à-vis de ses données est un point de gouvernance important.

A la fois dans le cadre de réglementation (obligation réglementaire des lieux de stockage de certaines données -exemple RH – voir le cas de la Suisse) et à la fois dans la maîtrise de ses données.

Localiser ses données n’est pas toujours facile surtout à l’heure du cloud et des échanges inter-entreprises.

La gouvernance doit définir les règles et moyens en termes de cartographie et de suivi de la résidence des données jusqu’au contrôle des transferts transfrontaliers (le suivi de la localisation des données dans les lineage est une nouvelle dimension à prendre en compte).

Le tout dans le respect de conformités régionales.

13) Il faut choisir les données à mettre sous gouvernance

Toutes les données ne peuvent pas être mises sous gouvernance.

Mettre toutes les données d’une organisation sous gouvernance est illusoire.

C’est trop lourd, trop couteux de mettre en place une gouvernance sur toutes les données.

De plus si on étend le sujet aux données non structurées.

C’est illusoire a posteriori, lorsque les données sont là.

Et mieux contrôlable a priori, lorsque les données sont à produire (voir le thème gouvernance by design déjà abordé dans l’article précédent).

C’est illusoire au vu de l’effort de mise sous contrôle des données : cartographie, étiquetage – construction du plan de métadonnées, mise sous observation de leur cycle de vie, mises sous politiques des stocks de données, contrôle des accès, mise en place des procédures de traitement des défauts de gouvernance, etc.

C’est inutile pour une part des données, lorsque celle-ci sont sous le contrôle de processus.

Le processus fixe le cadre de gouvernance (NB : s’il y a une action à mener de gouvernance, c’est dans le design et le fonctionnement du processus avant tout).

Et cela peut amener à un risque d’effet tunnel, d’attente trop longue, avant de se mettre en action. Vécu plusieurs fois des consultants lancés pendant plusieurs mois pour réaliser une cartographie approfondie des données (recensement, définition, sensibilité, classement … le tout dans un fichier xls sophistiqué) mais dont à la fin personne s’en intéresse (pas dans le temps métier, les gens sont passés à autre chose, le manager en charge du suivi de la mission a changé de poste, on a coché la case action suivie en COMEX – on peut clôturer le sujet).

Choisir les données à mettre sous gouvernance.

On ne peut pas tout gouverner. Il faut hiérarchiser les efforts.

Quelles données mettre sous gouvernance ? Quelle couverture du cycle de vie des données à mettre sous gouvernance ? Quelle granularité des données choisir pour la gouvernance (par exemple sous forme de datasets, data products) ?

Les réponses à ces questions se trouvent dans la stratégie data (voir le point n°17), le portefeuille data associé et les choix d’architecture de données (environnements de données, data products, données supports des besoins en interopérabilité…).

C’est suivant les cas d’usage que l’on va déterminer les données à mettre sous gouvernance, parce que le cas d’usage est à valeur, à risque, concerne des données très sollicitées.

Et ces questions se posent hiérarchiquement.

Certaines données n’ont pas besoin de faire l’objet d’une gouvernance globale. Une gouvernance locale peut suffire.

Et pour certaines données, couvrir tout le cycle de vie n’est pas nécessaire. Par exemple, la gouvernance s’applique uniquement au moment de l’accès aux données (cas fréquent).

NB : ne pas négliger également la gouvernance sur l’historisation des données.

Et bien entendu, le périmètre des données sous gouvernance va évoluer constamment.

Les données expérimentales, temporaires – intermédiaires, non productives ou à portée limitée créées dans des environnements de type «bac à sable » peuvent être considérées comme non gouvernées, puis gouvernées lorsqu’une industrialisation est décidée.

NB : si on décline cela jusqu’au dernier km, cela signifie, soutenir cette distinction (données gouvernées et non gouvernées) en gérant par exemple des environnements distincts (voir à l’extrême le principe de séparation des données sensibles – exemple des identifiants bancaires). Et encore en gérant la distinction au sein du catalogue de données.

NB bis : deux retours d’expérience pour suivre ce périmètre, dans le 1^er cas seules les données sous gouvernance figurent au catalogue de données, dans le 2^ème cas, le catalogue de données gère un flag indiquant les données sous gouvernance et celles non sous gouvernance (flag données régies).

14) Le faux débat entre la centralisation et la décentralisation de la gouvernance

Attention au débat simpliste du choix entre une gouvernance centralisée et décentralisée.

L’histoire dans les organisations montre souvent une dynamique de flux et un reflux entre centraliser et décentraliser. Voir par exemple l’analyse sur ce sujet à l’échelle de plusieurs décennies sous l’angle solutions – source : https://www.linkedin.com/posts/kevinpetrietech_data-datamesh-analytics-activity-7260411216454406144-TboG/

Le choix dépend d’abord de la nature des données concernées et des ambitions associées

Pour certaines données une gouvernance centralisée n’a pas de sens, alors que pour d’autres c’est la gouvernance décentralisée.

Pour certains sujets de gouvernance, idem. Par exemple pour la sécurité, l’interopérabilité, certaines réglementations, l’organisation de la gouvernance peut être différente.

Ensuite, il existe d’autres formes de gouvernance : fiducies des données, gouvernance via le support de communautés de pratiques, gouvernance participative, gouvernance autonome locale.

La centralisation est une solution de facilité (l’endroit ou taper), c’est clair – voir aussi l’introduction « Ce que n’est pas la data gouvernance… », une data patform centralisatrice, un CDO, une équipe data et le tour est joué. Mais cette solution unique a ses limites. Souvent la gouvernance des données se concentre sur les « grandes » données (données clients par exemple).

Alors que la décentralisation amène forcément moins de clarté (plus de monde impliqué, plus d’environnement et de situation différente). NB : à noter l’effort du data mesh, via l’idée de maillage de donnée d’apporter de la clarté dans une logique de décentralisation / fédération (à suivre par exemple l’effort d’une entreprise dans le domaine de l’énergie de contrôle du maillage via l’idée de contrats de maillage).

Mais la production de données est profondément décentralisée. Comment y appliquer une gouvernance centralisée ?

Et pour rappel des nombreux retours d’expérience de l’effondrement sur elles-mêmes des gouvernances centralisées faute de pouvoir répondre à toutes les attentes, de maîtriser toutes les données et leurs différents contextes locaux … même (symptôme connu) avec des équipes de plus en plus importantes (vécu dans une mission « light data », une équipe centrale data qui finit en stress tout en étant passée de 10 personnes à plus de 70 personnes en l’espace de quelques années).

On le sait aussi, la centralisation amène la déresponsabilisation des acteurs locaux, voire pire le sentiment d’être dépossédés d’une part de leur pouvoir et d’autonomie (ils s’exposent via leurs données), le tout en leur demandant des efforts de centralisation. Ils deviennent de simples utilisateurs.

Mais tout n’est pas rose non plus côté gouvernance décentralisée. Elle apporte d’autres complexités (redondances, dépendances, duplicité des data products … forks sans contrôles de versions et variantes).

Décentralisé ne veut pas non plus dire que chaque domaine est censé héberger sa propre infrastructure et architecture data, son personnel qualifié.

Décentralisé ne veut pas dire isolement. Chaque domaine est indépendant mais non isolé au sein d’un environnement commun (de moyens, de personnes, de règles).

Décentralisé veut dire solidarité entre domaines. Si on s’appuie sur la brique data product, cela veut dire penser le data product pour soi et pour les autres (pas toujours simple).

Quelques difficultés rencontrées au regard de la centralisation ou décentralisation de la gouvernance :

La difficulté de passage à l’échelle pour certaines données, maîtriser leur gouvernance sur l’ensemble de l’organisation,
Les conflits de gouvernance possible en cas de décentralisation … dont le règlement dépend d’une responsabilité centrale,
La maîtrise des coûts en cas de forte décentralisation.

Dans les solutions, pour rappel voir ce que propose le data mesh avec la notion d’enchâssement de la gouvernance (https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/#_ftn10 ).

Voir aussi, une excellente proposition ici : https://management-datascience.org/articles/37176/

Extrait : «

Les initiatives stratégiques s’inscrivent dans une vision à long terme et sont souvent impulsées par la direction générale. Elles posent les bases d’une politique de gouvernance unifiée pour assurer la qualité, la sécurité et la conformité des données. Elles structurent la gouvernance autour de normes communes, alignées aux objectifs globaux.
Les initiatives tactiques autonomes répondent à des besoins métiers spécifiques ou à des projets ponctuels. Elles apportent des solutions rapides et ciblées, sans attendre une validation stratégique. Leur autonomie leur permet d’ajuster les pratiques en fonction des besoins immédiats. Cette approche peut contribuer à enrichir la stratégie de gouvernance.
Les initiatives opérationnelles autonomes assurent la gestion du cycle de vie des données. Elles répondent aux besoins immédiats des unités métiers et posent des standards opérationnels, qui peuvent inspirer une gouvernance plus large. »

On en revient toujours au même point d’attention. Le meilleur modèle de gouvernance est celui, intégré, aligné à la gouvernance existante.

La gouvernance des données est forcément hybride.

15) Le dernier km de la data gouvernance : sa matérialisation dans le code

Les équipes projets, MOA, architectes, MOE dont les développeurs sont souvent les grands oubliés de la gouvernance des données.

On désigne ici, les équipes classiques de maîtrise d’œuvre de projets S.I., comme les membres de data fabrics ou encore des data scientists.

La matérialisation de la gouvernance auprès de ces équipes est clé.

Elle fait partie de la problématique du dernier km, comment traiter le grand écart entre la gouvernance stratégique et sa déclinaison comme règles de gouvernance dans le code.

La liste est longue des points où la gouvernance intersecte avec le travail des MOA et des développeurs, en vrac :

Quelle règles de gestion des données d’historisation ?
Auprès de quels référentiels de données s’accoster ?
Quelles nomenclatures sont officiellement valides ?
Quelles conventions de dénomination des données respecter ?
Quelles règles de gouvernance (déclinaison des politiques) doivent être intégrées (sécurité, réglementaire – exemple de type PCI-DSS) dans les pipelines de données ?
Quelles métadonnées sont à prendre en compte ?
Quelles métadonnées sont à produire au cours du développement d’un pipelines de traitement de données (par exemple pour alimenter la fonction d’observabilité, versus des logs absurdes) ?
Quels standards de format, de description des données à respecter (exemple dans la santé HL7) ?
Quels principes doivent être respecter pour la bonne circulation des IDs (exemple dans les signatures d’API) ?
A partir de quelles règles peut-on qualifier ce datasets (représentativité, confidentialité…) ?
Quels emplacements de stockage à respecter (sujet qui peut être exacerbé par la problématique de souveraineté des données) ?
Quelle source est valide pour ces données ?
Quels besoins en données pour satisfaire les besoins en accessibilité (UX – RGAA) ?
Etc.

Avant d’arriver au développeur, le dernier maillon, toute une chaîne d’acteurs va jouer un rôle dans la définition des contraintes data à prendre en compte.

En partant des choix de gouvernance (dont la vision stratégique, puis les politiques), le défi va être d’identifier ce que dans certaines méthodes de projet (agile on non) on désigne par des points d’exécution de gouvernance. Points qui au final seront soit implémentés dans du code, soit opérés dans des procédures.

Les urbanistes, architectes S.I. (applicatifs), architectes logiciels, MOA, vont permettre de produire les spécifications de ces points de gouvernance à destination des développeurs.

Les architectes vont par exemple définir les emplacements des points d’exécution de gouvernance*, au niveau d’une source, au sein d’une plate-forme de master data management, dans les interfaces gérées par un hub data, au niveau des pipelines d’alimentation en données… en s’assurant de leur non duplication, redondance, le tout en définissant les métadonnées associées et comment elles sont intégrées dans l’infrastructure data (on parle de métadonnées actives).

* On trouve aussi la formalisation de PEP – point d’exécution de politique, c’est-à-dire l’endroit où les politiques de données sont mises en œuvre.

La MOA va faire le lien entre des exigences et les contraintes data issues des choix de gouvernance.

Tout cela va s’exprimer dans un cahier des charges, dans un backlog.

A noter que cela ne concerne pas que les projets data, mais tout projet digital qui fondamentalement a forcément un volet data.

Savoir rédiger les spécifications de ce volet data est important. Elles couvrent tout un ensemble de points que les développeurs devront intégrer dans leur code.

Pour illustration, j’ai animé un atelier data sur le sujet de l’idée (du mythe) de vue unifiée des données (le graal dans les S.I. hétéroclites pour l’usage et la gouvernance des données). Dans cet atelier, nous avons fait appel à un jeu de rôle autour de personae, dont le rôle de développeur. Ci-après les exigences vis-à-vis de cette vue unifiée des données en vision développeur. Exigences qui prennent pour partie leur racine de la gouvernance des données.

Une façon de voir cette problématique de gouvernance dans le code est de penser « by design ». C’est une façon de voir (de bon sens) que l’on entend un peu pour tout (security by design privacy by design…). L’idée de gouvernance by design est de la même nature.

Il s’agit ni plus ni moins de ce qui a été dit plus haut. A savoir l’intégration de la gouvernance des données dès les premières étapes de conception et de développement et cela tout au long du cycle de vie des données.

On parle de gouvernance proactive à la source versus l’application de la gouvernance en mode réactif, quand les données sont là (en stock), ou encore par l’intermédiaire de workflows de compliance, de contrôle et de correction a posteriori (vécu la découverte d’une centaine de ces workflows … pour ne pas « déranger » la source !).

Et rappel « by design » ne signifie pas uniquement dans le code, mais aussi dans l’expression des besoins, dans la mise en production, jusqu’à la conduite du changement.

Les développeurs en bout de chaîne sont souvent frustrés par rapport à la formalisation des éléments de gouvernance. Ils sont rarement exprimés et plus souvent découverts au fil des problèmes (par exemple la source n’est pas de bonne qualité, ce n’est pas le bon champs de telle table qu’il fallait utiliser, l’accostage à tel référentiel n’est pas bon, telle version de nomenclature est obsolète, la log produite nécessaire à l’observabilité est inexploitable, on corrige des données lorsqu’on les reçoit sans revenir à la source, on fait fi de la lisibilité des données en générant des ruptures sémantiques – par exemple en passant d’un modèle relationnel à un modèle vecteur … au grand dam des MOA et des métiers). Plusieurs entretiens avec des développeurs, concepteurs de pipelines et même data scientists confirment cette situation. Certains retours sont édifiants. Les sujets de gouvernance sont carrément écartés (jugés comme non prioritaires car non au cœur du fonctionnel attendu … et pénalisant pour la vélocité – cf. agile).

Une des premières actions à faire lorsqu’on déploie une gouvernance des données est d’interroger les développeurs et analystes (MOA) projet.

Et en poussant l’exercice jusqu’au bout, j’aurais envie aussi de dire que la gouvernance devrait se préoccuper des pratiques de développements des volets data.

Petite parenthèse : le fossé entre développeurs data (de pipelines en particulier) et développeurs logiciels est ridicule. Les bonnes pratique de développement logiciel s’applique au développement data. Mon pire cauchemar, m’être retrouvé devant des requêtes SQL de plusieurs centaines de lignes … (un conseil imposer la lecture de l’ouvrage SQL Antipatterns à tous les DEV data).

Last but not least, toute ces remarques s’appliquent aussi bien au moment de traitements de données (quand les données sont là) mais aussi au moment où les données sont produites (quand les données naissent). Et la gouvernance devrait systématiquement commencer par la, à la racine.

Et une citation à avoir toujours en tête : « Les mauvais programmeurs s’inquiètent du code. Les bons programmeurs s’inquiètent des structures de données et de leurs relations. » – Linus Torvalds (LINUX father).

La DSI doit mobiliser ses architectes S.I., urbanistes sur la gouvernance des données.

Au cours de plus d’une dizaine d’année comme architecte S.I. ou urbaniste, j’ai rarement vu le sujet de la gouvernance des données apparaître dans les dossiers d’architecture.

Pourtant cela devrait être une réflexion de base : comment intégrer les règles de gouvernance dans la structure même de l’infrastructure et de l’architecture du S.I. (gestion des métadonnées, gestion des politiques de données…).

A la fois dans le S.I. existant (cela peut être vu comme une dette à gérer) et à la fois dans les nouveaux projets.

A minima, ce sujet de la gouvernance des données doit apparaître dans les processus de pilotage de la DSI : schéma directeur, agilité à l’échelle, programmes de transformation, supervision (ITIL), gestion budgétaire… (à nouveau l’important est que la gouvernance des données soit intégrée et alignée avec la gouvernance existante, dont celle de l’IT).

Voir en annexe, une tentative plus large de rapprochement entre la gouvernance des données (vue DAMA-DMBOK) et l’architecture d’entreprise (vue TOGAF).

Références complémentaires :

https://www.kdnuggets.com/implementing-data-governance-in-data-science-pipelines-techniques-and-best-practices

https://blog.det.life/how-to-build-without-burnout-the-seven-deadly-sins-of-data-engineering-5a913ffca083

https://medium.com/@wandrews_36445/proactive-data-governance-embedding-compliance-in-the-design-phase-to-increase-governance-adoption-7a6d485b7bff

Et un souvenir toujours d’actualité, dans la formation d’analyste programmeur (années 80), le cahier des charges (développement en V) comportait un volet data (glossaire, définitions, règles de gestion, structure des logs … en non pas un gros BLOB JSON, gestion des codes – nomenclatures, métriques de pilotage des entités et traitements…).

16) Récriminations et causes d’échec de la data gouvernance

Cela ne marche pas ! Où est la vraie gouvernance des données ? Poncifs, et concrètement on fait comment ? Bullshit ! Les récriminations arrivent vite lorsque on évoque le sujet de la gouvernance des données.

Ces récriminations ne valent bien entendu que par le point de vue de leur auteur, dans un contexte donné, mais dont la fréquence me fait dire que cela concerne plus d’un contexte.

Ces récriminations prolongent la partie « ce que n’est pas la gouvernance des données » après l’introduction.

Numéro 1 : La gouvernance vue comme un projet IT, et où les acteurs IT directement concernés (équipes data) courent après les acteurs métier. Et les acteurs métiers se demandent ce que font les acteurs IT.

Avec les récriminations des acteurs IT ou des équipes data vis-à-vis des acteurs métier, besoins en termes de gouvernance non formalisés voire absence d’interlocuteurs, de décideurs pour répondre aux interrogations (choix des données de références, maîtrise des nomenclatures…). Jusqu’à parfois pousser les équipes IT / data à se demander à quoi ils servent.

Et le vieil exemple du projet qualité des données confié à l’IT, parce que le métier a autre choses à faire.

La gouvernance des données ne fait qu’exacerber les frictions de la relation IT – métier.

Numéro 2 : La gouvernance des données absente des réflexions de fond et qui apparait uniquement en mode réactif à l’arrivée d’un problème data (violation de données, défaut de qualité, échéance réglementaire négligée, audit, question du COMEX sur des indicateurs…).

Numéro 3 : Le mur du dernier km (voir le point n°15 précédent).

Numéro 4 : les renvois de balles, les retards pour ne pas savoir gérer le débat entre ouvrir les données, faciliter leur accès et restreindre les accès, contrôler strictement leur diffusion, les protéger, les sécuriser, limiter les risques.

NB : il faut ramener le débat à la maîtrise des usages et non pas directement au niveau des données. Des données sans usage n’ont pas de valeur (j’enfonce une porte ouverte !). Maintenant il y a les bons et mauvais usages ! Voir sur ce point le rôle du portefeuille data (point n° 5).

Numéro 5 : l’absence de responsabilité (au sens décision forte) jusqu’à laisser tomber le sujet de la gouvernance face à « on a déjà assez de problèmes comme ça à traiter ». « N’en rajoutez pas ou oh non on n’a pas besoin de bureaucratie en plus ! ».

Avec aussi la situation connue où tout le monde attend tout le monde pour traiter tel problème data (qualité souvent) faute de responsabilités bien identifiées.

Conclusion pour moi la principale cause d’échec avec les récriminations liées et ne pas savoir ce que sont fondamentalement les – vos données et pour savoir bien penser data (voir le point suivant).

Autres points de vue sur le sujet :

https://medium.com/@Keith_Coe/why-data-governance-fails-so-often-ce71ec31869c https://www.dataversity.net/how-not-to-put-data-governance-into-practice-four-common-mistakes/https://tdan.com/data-governance-defying-gravitas/32249 https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/designing-data-governance-that-delivers-value

17) La stratégie data c’est d’abord savoir « penser data »

La stratégie de données est forcément le point de départ de la gouvernance de données.

Elle n’est pas un complément à la stratégie d’entreprise, mais intégrée, alignée avec celle-ci (elle y colle, elle n’est pas isolée),

Elle est une vision qui se décline à tous les niveaux de l’entreprise (globalement et localement, par domaine métier).

Ce n’est pas un plan de développement de capacités en matière de données (capacités techniques et humaines, livrables, budget, responsabilités), avec comme exemple, le plan de data management (cela soutien la stratégie).

Ce n’est pas non plus, décliner un plan d’action à partir d’une analyse de maturité data pour viser tel degré de maturité. L’analyse de maturité data arrive après et non pas avant la stratégie.

Les plans sont une question d’exécution, de certitude. La stratégie est une question d’incertitude, de décision.

Elle implique de savoir penser data, être inspiré par les données, en termes :

De pouvoirs des données projetés sur les métiers de l’entreprise,
De portée, apports et impacts visés par les données (datafication), au niveau unitaire (un objet, un individu – exemple le client), à l’échelle d’une population (quels objets – exemple les clients), jusqu’à l’idée de données du future,
De valorisation des données et par les données,
D’innovation par les données (la matrice know-unknown appliquée aux données est un bel outil pour cet exercice),
De voir les données comme un actif d’entreprise,
Des demandes autour des données (besoins, irritants),
De contraintes, risques : exemple réglementations à respecter,
D’éthique (lucidité sur les biais, inclusion, valeurs axiologiques).

C’est une logique de résolution de problèmes, qui va amener à un ensemble de choix, qui forment le résultat souhaité.

NB : choix où l’équilibre entre usage sans limite des données et protection (des données mais aussi des personnes) est à arbitrer.

Chacune de ces façons de penser data mérite à elle seule un développement complet (articles à venir).

Il faut avoir en tête les différentes façon de penser data avant de parler stratégie de données. C’est un point clé (c’est un volet de la data literacy).

Cela souligne que les dirigeants, managers de tous types et de tous niveaux doivent adopter une culture des données, s’assurer qu’ils comprennent, sont disposés à, sont compétents et sont tenus d’exploiter les possibilités d’utiliser les données comme leviers stratégiques. Ils doivent intégrer la pensée data.

La stratégie data est produite en continu (et non une fois pour toute), au travers d’une démarche top down / bottum up.

Le portefeuille d’initiative data est le reflet opérationnel de la stratégie.

Elle s’accompagne d’une stratégie pour les métadonnées. Elle s’applique sur les différents plans du S.I. : métier en premier lieu, fonctionnel et technique. Elle se décline en politiques … et doit se répandre jusqu’au dernier km. Elle fonctionne par paliers, incréments et par boucles de rétroaction.

Les difficultés :

Paradoxalement, la première difficulté est l’accès à la stratégie d’entreprise (voire sa vision), ou de certains domaine métier (j’ai cherché pendant 6 mois une stratégie commerciale à décliner en vision données … sans la trouver),
L’envie d’aller directement à la solution, aux problèmes de data management. Et Il ne s’agit pas d’acheter une solution technologique prête à l’emploi comme le promettent de nombreux éditeurs,
La faiblesse de la pensée data (et de ne pas prendre le temps de s’approprier cette pensée),
L’éternelle implication de sponsors légitimes. Par expérience c’est rédhibitoire,
C’est limité la pensée data, à des problématiques d’indicateurs et de tableaux de bord,
Ou au contraire, parler de devenir une entreprise data centric alors que cela ne tient pas compte de la réalité de l’entreprise et impliquerait une transformation gigantesque,
Adopter et décliner une stratégie de données n’est pas qu’une question d’expertise data, négligeant les changements culturels et organisationnels que cela exige (par expérience, il faut être accompagné de spécialistes, coachs sur cette dimension … ne pas la laisser entre les mains des experts data. Mon erreur).

NB : ces réflexions sont inspirées de différents retours d’expérience. L’accompagnement de CDO dans la définition de leur feuille de route face au COMEX. Le choc d’une tentative de désintermédiation par les données avec la défense puis la contre-attaque décidée. L’initiative data d’un domaine métier en charge de la relation partenaires, au cours de laquelle la stratégie de données a été coconstruite avec l’ensemble des parties prenantes (dont en premier lieu les partenaires). La définition d’une stratégie data au travers d’un portefeuille de cas d’usage visant à l’ouverture d’un nouveau marché, d’un nouveau métier. La vue data dans le cycle annuel de définition et revue du schéma directeur S.I. Et enfin l’alignement de la stratégie data sur la stratégie RH d’une grande banque, appuyé sur l’analyse en vision data des politiques RH (présentes et ambitionnées).

Autres points de vue : https://towardsdatascience.com/how-most-organizations-get-data-strategy-wrong-and-how-to-fix-it-b8afa59f1533

Articles inventaires généralistes https://medium.com/@sruhee98/implementing-a-data-governance-strategy-e4091f797d05

https://www.dataversity.net/driving-data-governance-the-role-of-data-strategy-and-data-literacy-programs/

https://www.dataversity.net/book-of-the-month-insights-from-humanizing-data-strategy/

NB : voir aussi les notes sur ce sujet régulièrement abordé dans les revues mensuelles data – https://www.datassence.fr/category/data-strategy/

18) Gros plan sur les rôles data

Qui dit gouvernance, dit tout un ensemble de rôles à identifier et à endosser.

Ces rôles sont définis par des responsabilités.

La gouvernance des données doit soutenir ces responsabilités.

Le DMBOK du DAMA identifie de nombreux rôles.

Parmi ces rôles, ma sélection, au fil de mes rencontres, et quelques commentaires :

Le rôle indispensable : data steward (ou d’administration des données, à ne pas confondre avec les DBA – database administrator). J’ai eu l’expérience de manager une cellule de data stewards, sans eux le plan data de l’organisation, les processus data ne fonctionnent pas (vie des référentiels de données, suivi des échanges / alimentations de données, supervision des contrôles qualité, application des politiques de données, supervision des cycles de vie des données, traitement des rejets résultats de l’application des règles des politiques),
Le rôle difficile de data owner, pour lequel je n’ai vu que des échecs lorsqu’il était défini comme un rôle dédié, temps plein au sein d’organisations « traditionnelles ». Un rôle transverse, souvent sans prise sur les données, malheureusement avec une dérive « à côté ». NB : par contre j’ai vu des personnes jouer avec succès de fait se rôle sans en avoir le titre, toujours des personnes pivots dans une sphère métier. Ce rôle est plutôt fait pour des entreprises au business data centric.
Le pire rôle : data owner délégué. Voir point précédent, aggravé par : la responsabilité ne se délègue pas.

NB : retour d’expérience, vu dans une organisation, une mesure de déploiement de la gouvernance des données au travers du nombre de data owners nommés. Erreur d’indicateur (la gouvernance pour la gouvernance). Et le temps le montre, avec au bout d’un an une majorité de data owners « A nommer ».

Tous ces rôles portent des responsabilités, et ces responsabilités ne vont pas sans moyens et sans reconnaissance (bon sens).

La responsabilité s’exerce au plus près des données (de leur cycle de vie).

Les données sont partout, sont l’affaire de tous, impossible de répondre à toutes les demandes de données de façon centralisée dans une organisation, cela veut donc dire aussi une exigence en termes d’autonomie (attention le self data n’est que l’élément visible lorsqu’on pense à produire par soi-même des tableaux de bord, le self data c’est aussi maîtriser et challenger les données, contribuer aux politiques, partager le contexte des données, s’inscrire dans un collectif dès lors que les données sont partagées…).

Mais dans tout ce parcours de rôles, il y a un rôle particulier à ne surtout pas oublier : les data workers.

Ce rôle ne concerne pas l’environnement des données (principalement la construction et le fonctionnement du S.I.) mais les données elles-mêmes.

Avec l’arrivée de l’IA et plus particulièrement des IA génératives, ce rôle de l’ombre est de plus en plus mis en lumière avec les dérives associées et donc des principes éthiques qui relèvent de la gouvernance.

Il existe beaucoup d’écrits sur ces data workers. Avec des spécialistes comme Antonio A. Casilli (voir sur Datassence – https://www.datassence.fr/?s=casilli).

La prise en compte de ces acteurs (officiels et non officiels, sous-traitants, « clients » qui produisent des données…) est un incontournable dans toute bonne gouvernance des données.

Pour aller plus loin sur ce thème :

Voir dans Datassence, les notes sur les acteurs data et en particulier les CDO https://www.datassence.fr/?s=CDO et https://www.datassence.fr/?s=%22acteurs+data%22
Sur les data workers : https://www.france.tv/documentaires/documentaires-societe/6888928-les-sacrifies-de-l-ia.html

Références utiles et complémentaires :

https://dr-alvin-ang.medium.com/data-governance-roles-part-3-raci-model-6648312a9a22

https://diginomica.com/heres-what-it-takes-be-successful-chief-data-officer

19) L’histoire MERCADO Libre (MELI)

J’ai trouvé intéressant ce retour d’expérience sur Medium : https://medium.com/mercadolibre-tech.

L’équipe data y décrit comment la gouvernance des données s’applique dans leur environnement.

Mercado Libre (https://www.mercadolibre.com/ ) est une des plus grandes place de marché d’Amérique Latine (plus de 54 millions d’acheteurs et 371 transactions par secondes)… l’Amazon du continent Sud-Américain.

ATTENTION c’est une entreprise native du numérique. Ce qui signifie qu’ils sont fortement moins contraint par un S.I. historique et qu’ils ont pu appliquer une logique data centric dès le départ (et de fait naturelle vis-à-vis de leur business model). Avec comme contexte une nature décentralisée de la production de données. Ils citent 10 000 producteurs de données répartis dans un vaste écosystème (250 équipes, 30 000 personnes).

Ce qui suit en termes de retour d’expérience est à bien relativiser par rapport à ce contexte.

Les idées clés implémentées en support de la gouvernance des données

1) Le passage à une architecture de données décentralisée (l’option équipe centralisée ayant montré ses limites). Tout en équilibrant la décentralisation avec une gouvernance à l’échelle de l’entreprise.

2) Le choix stratégique de séparer explicitement données gouvernées et données non gouvernées (à partir de critères métiers – exemple les données utilisées pour la prise de décision sont gouvernées, les données qui entrent dans des processus exploratoires ou à faible portée sont non gouvernées) – « nous reconnaissons que nous ne pouvons pas tout gouverner ».

3) Les données sous gouvernance sont en continu inventoriées et mises sous surveillance automatique. Avec le déclenchement de workflows de gestion de données (actions à mener suite au déclenchement de seuils d’alerte, pour le traitement de rejets suite à des contrôles qualité – de données – de respect de normes dans la production de tableaux de bord, jusqu’à l’inventoriage normalisé dans le catalogue de données – sous 40 points de contrôle et un circuit d’approbation).

4) Une forte orientation data products (dans la logique data mesh), avec des propriétaires techniques qui sont les gardiens des métadonnées (avec le moyens d’en juger la qualité – complétude des métadonnées par exemple). Le tout par domaines d’activité.

Avec également le suivi du périmètre d’utilisation et des accès du produit de données (avec aussi en cas de non utilisation le déclenchement de pipelines de nettoyage).

5) Un data catalog d’entreprise pour la découverte et compréhension des produits de données (dont les tableaux de bord). Qui comprend un classement des données en fonction de leur criticité (avec le niveau de SLA associé). Ce classement est le résultat de tout un environnement « Data Artifacts Criticality » : mesures de l’utilisation et de la pertinence des data products, de leur niveau de service, de leur dépendances.

6) Dont l’utilisation de l’IA générative comme assistante : en appui de l’inventoriage des produits de données dans le catalogue (description dont le lineage, détection de redondances via la mesure de distance entre data products – score d’unicité) et en retour en appui à la recherche de données dans le catalogue.

7) Les règles de gouvernance sur la base des métadonnées sont intégrées nativement dans la data platform d’entreprise (comprenant un environnement de développement Data Suite fait maison) et dans les fonctions de data sharing (API des data products). Avec un système de « garde-fous intelligents » au sein de la Data Suite, guidant activement les équipes dans les différentes étapes du développement de produits de données tout en garantissant la gouvernance à chaque étape.

Extrait de https://medium.com/mercadolibre-tech/accelerating-the-ai-driven-future-with-data-governance-at-the-wheel-a1d90b6b4b0b – Google traduction « En incluant les conventions de dénomination des tables et des colonnes, les meilleures pratiques d’architecture de pipeline, le processus de publication et la gestion des données historiques, ces contrôles ne sont pas de simples cases à cocher ; ils sont intégrés aux flux de travail de nos équipes, rejetant actuellement environ 10 % des déploiements avant qu’ils n’atteignent la production. Cette approche proactive réduit les erreurs et garantit que la gouvernance n’est pas une réflexion après coup mais une partie naturelle du processus de développement au sein de notre écosystème ».

8) Une gestion de l’observabilité des données de bout en bout (de la production à l’utilisation) via la mise en œuvre de la solution MonteCarlo (vu comme le capteur de la gouvernance des données – avec par exemple la mise sous surveillance de plusieurs milliers point de données avec des alertes plus ou moins élevées suivant la criticité des produits de données). Et en incluant une dimension économique (surveillance des couts de maintenance des data products – développements Data suite et rapprochement avec leur utilisation -> première idée de retour sur investissement).

9) Une volonté d’embarquer un maximum de personnes. Dont des utilisateurs métier moins expérimentés technologiquement, mais en mesure de produire leurs propres pipelines de données jusqu’à assurer leur fonctionnement, le tout dans le respect de la gouvernance.

Avec l’idée de priorité à la valeur commerciale – extrait Google traduction : « Laissez de côté le fardeau de la conformité, des réglementations et des politiques, qui semblent très éloignées de la création de valeur commerciale, et créez des forums où les gens peuvent partager des exemples concrets dans lesquels la gouvernance des données a fait la différence au sein de leurs unités commerciales. Cette approche non seulement crée une dynamique, mais démontre également la valeur d’une bonne gouvernance d’une manière qui trouve un écho auprès des parties prenantes. »

10) Un volet data literacy définit par la gouvernance : https://medium.com/mercadolibre-tech/data-culture-strategy-at-mercado-libre-857b33bd36f7

Articles exploités :

https://medium.com/mercadolibre-tech/data-mesh-meli-empowering-data-owners-9aa5db264ff3

https://medium.com/mercadolibre-tech/data-mesh-meli-building-highways-for-thousands-of-data-producers-0f41d8e08610

https://medium.com/mercadolibre-tech/how-data-artifacts-criticality-is-enhancing-data-governance-at-meli-64e98067ea76

https://medium.com/mercadolibre-tech/accelerating-the-ai-driven-future-with-data-governance-at-the-wheel-a1d90b6b4b0b

https://medium.com/mercadolibre-tech/an-ai-ready-framework-for-data-governance-at-mercado-libre-17916136aa4c

https://medium.com/mercadolibre-tech/data-culture-strategy-at-mercado-libre-857b33bd36f7

https://medium.com/mercadolibre-tech/in-the-age-of-data-the-new-number-you-need-to-grow-2ee6f6de40c3

20) Pratiques et thèmes additionnels

En lien avec la gouvernance des données, les sujets sont sans fin.

Juste pour mémo, ci-après quelques thèmes additionnels … à développer largement.

Qualité

C’est souvent le 1^er sujet évoqué lorsque l’on parle gouvernance des données.

Le sujet est bien connu et maîtrisé entre la qualité préventive (root cause analysis) et la qualité curative (sur stock quand les données sont là).

Pour rappel la qualité dépend de l’usage (voir à ce titre le lien avec portefeuille d’initiative data – point n°5).

Et aussi pour rappel, dans l’esprit du temps (IA et autres moteurs data), qualité ne veut pas dire justesse ou vérité des données.

La qualité des données abandonnée par la gouvernance, fait transpirer tout le monde, les data scientist / data analyst qui souffrent de données de mauvaises qualité et dépensent la majorité de leur temps à leur mise en qualité, les moteurs d’IA au titre du garbage in garbage out, les data stewards qui courent après les rejets suite à des contrôles qualité, les acteurs de processus métier qui comblent les déficits de qualité via des moyens shadow, etc.

Le tout avec le syndrome du mythe de Sysiphe.

La qualité des données semblent être un problème éternel malgré tout l’outillage que l’on peut mettre (et même en tenant compte des promesses de l’IA sur ce sujet). Les partisans des solutions outils passent à côté d’une vérité fondamentale : la qualité des données dépend d’une chaîne humaine (de la conception à l’exécution, dont la collecte en passant par la supervision).

Il existe de nombreux ouvrages de référence sur le sujet :

La qualité et la gouvernance des données – Au service de la performance des entreprises – https://www.eyrolles.com/Informatique/Livre/la-qualite-et-la-gouvernance-des-donnees-9782746225107/ sous la direction de Laure Berti-Equille

Voir aussi le récent résultat des travaux du DAMA (https://dama-france.org/ ) et la publication de deux cahiers techniques – Approches tactiques et stratégiques sur la qualité des données – https://dama-france.org/wp-content/uploads/2021/09/GT-DQ-DAMA-FRANCE-ISACA-AFAI-Cahier-pratique-1-2021.pdf et points de repère clés pour mesurer la qualité des données – https://dama-france.org/wp-content/uploads/2023/02/Groupe-de-travail-02-ISACA-AFAI-et-DAMA-France_Page-a-page.pdf .

Voir le chapitre dédié ici dans le cadre des données de référence : https://www.dunod.com/sciences-techniques/referentiels-du-systeme-d-information-donnees-reference-et-architectures-d – Les référentiels du système d’information. Données de référence et architectures d’entreprise – chapitre 6 – De la qualité des référentiels.

Processus de gouvernance

Voir l’inventaire et la classification proposée dans le DMBOK du DAMA.

Ecrire une politique de données

Il y a plus de 10 ans nous avons rédigé à plusieurs un guide de rédaction d’une politique de données. Production réalisée dans le cadre de l’initiative Praxeme (architecture d’entreprise – www.praxeme.org).

Ce guide est une première base et de mémoire faisait suite à la rédaction d’un guide au sein d’une entreprise avec l’historique suivant (plusieurs fois rencontré) :

On a publié des données : sans le savoir et sans connaître les risques.
Puis on a publié des données : en le sachant mais toujours sans connaître les risques.
Puis on a publié les données : en le sachant et en se rendant compte des risques … mais tout en continuant à publier.
Et enfin on publie les données dans le respect d’une politique… qu’il a fallu rédiger.

Pour avoir contribué depuis à d’autres politiques, je dirais que la difficulté est la déclinabilité jusqu’au dernier km. Attention, ce n’est pas forcément du ressort de la politique qui ne peut pas être au fait de tous les contextes. Dans ce cas la diffusion et l’appropriation de la politique est clé. Sinon elle reste dans un placard.

Source : https://www.praxeme.org/download/data-policy-form/ et https://www.praxeme.org/download/data-policy/

Autre source : https://medium.datadriveninvestor.com/how-to-write-your-first-data-governance-policy-e831a4ff0e54

Sécurité

C’est un sujet majeur dans la gouvernance des données (et exacerbé dans des situations de décentralisation). Avec en tête le phénomène data breach (violations de données).

Souvent cela se traduit par une politique de sécurité des données.

Il existe des cadres spécifiques dédiés à la cybersécurité des données, des protocoles, des normes (exemple PCI DSS) et des solutions techniques (voir par exemple Immuta – https://www.immuta.com/ , Dateligens – https://dateligens.com/ et Varonis https://www.varonis.com/ ).

Il existe par ailleurs des modèles de descriptions des risques, menaces sur lesquels la gouvernance des données peut s’appuyer – voir par exemple https://cyber.gouv.fr/la-methode-ebios-risk-manager

Autre exemple le modèle de cybersécurité Zero Trust.

Voir aussi le croisement entre la gouvernance des données et la mise en œuvre de la norme ISO 27001 pour les systèmes de gestion de la sécurité de l’information (SMSI).

Source : https://medium.com/data-view-house/what-are-the-data-governance-deliverables-for-iso-27001-standard-51fa169b4975

Autre source : https://tdan.com/data-governance-best-practices-lessons-from-anthems-massive-data-breach/32261

Données personnelles – une gouvernance particulière

Juste pour mémo, le RGPD a été l’un des fers de lance de la gouvernance des données.

Les données personnelles sont des données à la gouvernance particulière.

Voir aussi : https://medium.com/data-view-house/how-to-balance-data-conformance-and-performance-for-pii-protection-in-internal-reporting-8cc0f56f3078

Inclusion

Les données ne sont pas absentes du sujet de l’inclusivité (inclusive data practice).

De par le phénomène de biais dans les jeux de données.

Exemple UK – La norme data SAVVI (Scalable Approach to Vulnerability Via Interoperability – pour les données des personnes vulnérables).

Et de par le sujet de l’accessibilité (au sens par exemple du RGAA – Référentiel général d’amélioration de l’accessibilité).

Dans ce cas, des données vont venir compléter des images, des tableaux de bord afin de les rendre accessibles à des personnes mal voyantes.

Voir aussi ce qu’il est nécessaire de mettre en place pour faciliter la saisie de données et donc leur qualité.

Autre exemple, la restitution de données extraites d’enregistrements audio pour les mal entendants.

Jusqu’à l’utilisation de données pour détecter des problèmes d’accessibilité.

La gouvernance de données dans ce cas doit se pencher sur les règles de gouvernance en fonction de populations explicitement identifiées.

Cas de l’open data

Les données qui rentrent dans un périmètre open data font l’objet d’une gouvernance particulière.

J’ai été en charge d’un projet de ce type.

Une des particularité est la sortie de données hors de leur environnement habituel.

Il existe beaucoup de matière sur le sujet.

Avec aussi des retours d’expérience traduits dans le cadre d’étude de sociologues.

Voir par exemple Antoine Courmont – https://www.pug.fr/produit/1897/9782706147357/quand-la-donnee-arrive-en-ville – Quand la donnée arrive en ville – Open data et gouvernance urbaine,

Ou encore Samuel Goëta Les données de la démocratie – Open data, pouvoirs et contre-pouvoirs – https://cfeditions.com/donnees-democratie/ .

Et aussi https://shs.cairn.info/article/FLUX1_127_0065/pdf?lang=fr

Observabilité

Sans observabilité des données difficile de mener à bien leur gouvernance.

Juste sur ce point ne pas tomber dans l’idée que l’observabilité des données est un sujet technique.

C’est aussi (et en premier) un sujet métier.

Voir par exemple : https://medium.com/@gregorysnelson/data-observability-what-every-executive-should-know-196d39ae87d4

Cloud

De fait, le cloud tient une place importante dans la gestion des données.

Les AWS, Azure, GCP… offrent des moyens de gouvernance dédiés : cloud native data governance.

Le challenge est d’adresser cette gouvernance au travers d’environnements cloud distribués, multi-fournisseurs.

Le sujet de la standardisation de la gouvernance se pose (pour la réversibilité, l’interopérabilité, la scalabilité des moyens…).

Et le sujet financier (cloud cost optimization) y est prégnant.

Normes ISO et gouvernance des données

Sources :

https://medium.com/data-view-house/what-are-the-data-governance-deliverables-for-iso-27001-standard-51fa169b4975

https://medium.com/data-view-house/why-we-need-iso-standards-for-data-management-f2418898711d

Cadre de gouvernance du monde scientifique

Le monde scientifique est de fait un gros producteur et consommateur de données.

Des réflexions sur la gouvernance des données sont de fait associées aux pratiques des scientifiques.

Deux auteurs sont des références sur le sujet : Christine L. Borgman (https://christineborgman.info) et Rob Kitchin (https://www.kitchin.org/ ).

Voir leurs ouvrages respectifs.

Kitchin, R. (2022) The Data Revolution: A Critical Approach to Big Data, Open Data, and Data Infrastructures. 2nd edition. Sage, London.

C. Borgman (2016) MIT Press – Big Data, Little Data, No Data: Scholarship in the Networked World

La gouvernance des données est ici très liée à la connaissance.

La notion d’infrastructure de connaissance y est centrale dans laquelle on retrouve l’idée d’infrastructure de données.

A retenir à la fois des particularités propres au monde scientifique et des enseignements qui concernent aussi le monde des entreprises.

Exemples :

Réutilisation des données,
Communautés de pratiques autour des données,
Multimodalité des données (N points de vue en termes de données d’un même objet),
Suivi du cycle de vie des données,
Durabilité longue des données dans le temps de la science,
Obsolescence des ressources (outils) d’accès aux données jusqu’à la perte du contexte de connaissance lié aux données,
Reproductibilité, réplicabilité de résultats à partir de données partagées…

Mot de la fin : les défis de la data gouvernance et un clin d’œil historique

Pour conclure cette suite de notes sur ce thème sans fin, une réponse à la question qui m’a été posée fin janvier : quels sont pour vous les principaux défis de la gouvernance des données ?

A chaud et en vrac :

NB : certains voient aussi la gouvernance des données comme un défi culturel, de data literacy, de conduite du changement. Ils ont raison et il faut savoir s’entourer des personnes dont c’est la spécialité (ce qui n’est pas mon cas), des bons communicants, des bons facilitateurs et qui ont compris le fond de ce que sont les données.

Ultime conclusion : finalement la réponse à ce qu’est la gouvernance des données, c’est la traduction au sein de votre contexte, de tous ces différents points évoqués au fil de ces deux condensés de notes.

Et certains l’avaient déjà abordé dans le passé, un clin d’œil historique … sur un ouvrage paru en 1981 – tout y est ! – source https://archive.org/details/designstrategyfo00mart – « Design and strategy for distributed data processing » de James Martin.

Annexe 1 Matrice d’alignement et d’intégration de la gouvernance des données

Version courante – datassence.fr

Voir : https://www.datassence.fr/2024/11/15/retours-dexperience-gouvernance-des-donnees-dama-france-datacamp20/

Annexe 2 – Lien architecture d’entreprise – data gouvernance

La vision architecture d’entreprise est utile dans la réflexion sur la gouvernance des données.

Et c’est normal, elles se situent toutes les deux dans une vue entreprise (certains parlent de vue holistique).

Leur rapprochement est donc naturel.

Source à explorer : https://medium.com/@arindamsg/from-data-strategy-to-implementation-navigating-the-path-with-dmbok-and-togaf-62a8deeec359

Voir un rapide tour ici :https://www.datassence.fr/2024/11/19/revue-data-du-mois-octobre-2024/?highlight=TOGAF#_ftn11

Annexe 3 – Inventaire de cadres de gouvernance

Suite point n°2.

Voir aussi l’annexe de l’article précédent : https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/#_ftn19

Source : https://dr-alvin-ang.medium.com/various-types-of-data-governance-frameworks-82da7b37eed2

Deux cadres souvent cités en complément de celui du DAMA :

L’Enterprise Data Management (EDM) Council – DCAM
O.R.A.N.G.E. Data Management Framework (DMF).

Avec une comparaison ici : https://datacrossroads.nl/2025/01/06/data-management-across-contexts-a-unified-perspective/

« The approach described below is derived from the O.R.A.N.G.E. Data Management Framework, which I utilize in my practice. Unlike DAMA-DMBOK2 and DCAM®, this framework explicitly leverages the relationship between data management capabilities and the data lifecycle model. Moreover, DAMA-DMBOK2 and DCAM® present significantly different perspectives on data management capabilities. To address these gaps, the analysis below details the artifacts these capabilities should deliver, providing a more transparent framework for their application in practice. »

L’ISO offre également plusieurs cadres.

Source : https://medium.com/data-view-house/why-we-need-iso-standards-for-data-management-f2418898711d

Autour du concept de data mesh, il existe différentes formulation de cadres de gouvernance. Exemple l’idée de Cadre technique commun DME Data Mesh Environment – Source : https://medium.com/mercadolibre-tech/data-mesh-meli-building-highways-for-thousands-of-data-producers-0f41d8e08610

Auteur Ignacio Weinberg – in Mercado Libre Tech

Une synthèse intéressante des différentes facettes de la data gouvernance – ici : https://hal.science/hal-04551264/document

Ugo Verdi, Nathalie Pinède, Guy Melançon. La gouvernance des données en contexte universitaire : proposition d’un modèle de maturité. 2024. ffhal-04551264f

Extraits :

En lien avec la gouvernance de l’information :

Avec l’idée de continuité entre les données et la notion d’information. Du S.I. aux données (production, support du cycle de vie), des données (interprétation, en contexte) aux informations.

Voir aussi ce lien au travers de la pyramide DICS (Donnée, Information, Connaissance, Sagesse).

Source : https://www.sibenco.com/wp-content/uploads/2017/09/Information_governance_data_governance_September_2017.pdf

Autres sources :

https://datacrossroads.nl/2024/12/31/governance-vs-management-clarifying-the-divide

https://medium.com/castor-app/how-to-build-a-data-governance-framework-d0e156739e07

Pour terminer une approche intéressante Non-Invasive Data Governance de Robert S. Seiner et KIK Consulting & Educational Services.

Vu ici https://www.linkedin.com/pulse/non-invasive-data-governance-most-practical-pragmatic-seiner-kuc4e/ et https://kikconsulting.company.site/

Va dans le sens de l’intégration, de l’alignement avec l’existant (ressources, procédures, processus établis sources des données, autres gouvernances), non « à côté », non basée sur des investissements lourds (dont nouveau processus, nouveaux acteurs…). Avec l’idée de réduire la résistance en intégrant dans les pratiques actuelles des mesures progressives de gouvernance et dans la continuité des responsabilités existantes.

Références : https://tdan.com/what-is-non-invasive-data-governance/7354

Et l’ouvrage : Non-Invasive Data Governance Strikes Again: Gaining Experience and Perspective

https://technicspub.com/non-invasive-data-governance-strikes-again/ – voir la table des matières.

Annexe 4 – Ressources et ouvrages utiles

Holistic Data Governance de David Kowalski – https://technicspub.com/holistic-data-governance-vol-1/

Gouvernance des données pour les administrations fiscales. Un guide pratique – https://www.ciat.org/Biblioteca/DocumentosTecnicos/Frances/2024_gouvernance_donnees.pdf (qui donne une bonne vue d’ensemble du sujet de la gouvernance des données avant d’aborder la cas de l’administration fiscale)

Jonathan Reichental, ancien DSI et auteur de « Data Governance for Dummies » https://www.dummies.com/article/business-careers-money/business/data-management/what-is-data-governance-296085/

Madsen, Laura (2019). Disrupting Data Governance: A Call to Action. Technics Publications – https://technicspub.com/disrupting-dg/

Metadata Management Selected Strategies for Data Governance and Business Insight

Green, Sam (2024)

Et aussi https://www.secoda.co/blog/best-books-on-data-governance

Notes sur la gouvernance des données – suite