Dernière modification le 2 octobre 2024

La gouvernance des données n’est pas le sujet le plus sexy de la data. Mais elle est indispensable.

Je vous propose un tour d’horizon de 10 ans de situations rencontrées et vécues au sein de différentes organisations.

Pour une meilleure digestion, ce tour d’horizon a été découpé en 17 tranches autonomes et qui se recoupent.

En prenant un peu de chacun de ces retours d’expérience, peut-être trouverez-vous votre chemin (voir celui que j’ai trouvé en conclusion de cet article).

Ces retours d’expérience resteront anonymes et n’engagent que l’auteur !

Les secteurs à l’origine de ces des retours d’expérience : énergie, banque, monétique, ingénierie, secteur public.

En complément à cet article, à suivre le sujet de la data gouvernance sur datassence.fr : https://www.datassence.fr/category/data_gouvernance/ – exemples dans les revues du mois data – Le sujet le moins sexy de la data : la data gouvernance et encore Gouvernance des données : où la situer, dépasser les poncifs, Data gouvernance offensive et défensive + l’argument IA.

Avertissement : dans ces retours d’expérience on parle de data gouvernance parfois confondue avec sa déclinaison en termes de data management. Les deux sujets sont naturellement liés. La gouvernance c’est à la fois la définition d’un périmètre (quelles données, quelles catégories de données, quels domaines métier, quelles politiques) et des mécanismes de gouvernance (organisation, processus, actions de data management).

Second avertissement, n’est pas abordé ici la data gouvernance en termes géopolitiques, contrôles des échanges de données entre nations, normes et règles internationales – exemple DGA – data governance act en Europe, cadres de gouvernance au niveau d’un état, marché des données, souveraineté dans la gestion des données, ouverture des données (open data).

Sommaire :

1) Quand les grands cadres de data gouvernance et les grandes messes data s’arrêtent aux incantations

Cela commence toujours de la même façon. L’idée d’insuffler une dynamique data à l’échelle de l’entreprise est née. Des acteurs, souvent centraux et accompagnés d’un cabinet sont chargés de cette dynamique. Une feuille de route est construite incluant un plan de communication (diffusion de l’esprit data). Dans cette feuille de route on va trouver la construction d’un cadre de gouvernance des données et tout un ensemble de messes data (semaine de la data, datathon – data camp – data game, e-learning data, RDV de cercles ou de groupe de travail data…). Le cadre de gouvernance définit les rôles data – data owner en premier, le classement des données, les politiques de données… Des slogans sont créés : « Soyez Data », « Tous acteurs data »…

Et c’est parti. Par le buzz data et l’énergie des acteurs en charge de la feuille de route, l’intérêt est manifeste. Localement des succès data apparaissent. Mais au bout d’un an et de quelques mois, le soufflet retombe. Le cadre de gouvernance défini est vu comme un livrable ponctuel … le sujet est clôt, on ne s’y investit plus, alors qu’il devrait évoluer de façon continue. Les activités de data gouvernance se réduisent. La feuille de route devient de moins en moins prégnante (d’autres sujets plus directs et opérationnels sont sur le devant de la scène – NB : une contrainte à tenir compte, il n’y aura jamais une période calme laissant du temps pour mettre en place la gouvernance des données). Les efforts prolongés sans résultat clair finissent même par la rendre fantomatique.

Un ou deux ans après, le bilan est faible. Des rôles data difficile à porter. Pas de passage à l’échelle (peu d’accrochage local, peu d’extension de la pensée data hormis la peur réglementaire). Les acteurs porteurs de la dynamique data s’essoufflent et partent. Les produits (charte, fiches de poste, politiques) du cadre de gouvernance sont dans des placards. Le peu qu’il en reste est vu comme une contrainte en plus. Certains s’acharnent avec le suivi de KPI de data maturité, mais cela ne change pas grand-chose sur le terrain.

Et le pire, plusieurs années après, ce cycle d’ardeur data repart avec de nouveaux acteurs, qui réinventent ce qu’on fait leur prédécesseurs avec les mêmes conséquences.

La gouvernance débarque comme un précepte, un vœu pieux. Elle est mal déclinée, elle n’est pas ancrée, elle n’est pas alignée, elle est trop loin du business quotidien.

Le constat est un peu cru. L’éducation à la donnée est nécessaire. J’ai connu deux exemples de datathon intelligemment préparés et menés :

Le premier a visé à mettre entre les mains les données du contexte quotidien des participants. Cela a demandé un important travail préparatoire, de recrutement des participants et de récolte des jeux de données en lien avec leur contexte (des données qui parlent dans les mains).
Le deuxième a visé un cas d’usage fédérateur, que seul un collectif d’acteurs de différents domaines pouvait résoudre (exemple : le développement d’une relation avec un nouveau type de partenaire). Avec l’idée de montrer que la donnée est une affaire collective.

Les données sont dans un mouvement continu croissant (et les perspectives sont énormes), la gouvernance doit suivre ce mouvement. Ce n’est surtout pas un projet mais quelque chose à incruster dans les fondations de l’organisation et en mesure de fonctionner en changement continu.

2) La data gouvernance « à côté » ajoute de la complexité et ne marche pas

J’ai déjà écrit sur le sujet – voir : https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/ avec cette partie en particulier – Pourquoi il ne faut pas être « à côté » ? L’argument de la gouvernance – https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/#_ftn4

Extrait d’un entretien avec un responsable data spécialement recruté qui a fini par jeter l’éponge au bout de six mois : « J’étais comme un nouveau pion à éliminer. Non pris au sérieux dès que je proposais de modifier un processus pour intégrer des contraintes data. Non invité quand des problèmes opérationnels liés aux données était traités, j’apprenais leur existence après. Si je demandais à accéder aux données, plusieurs semaines pouvaient se passer avant qu’on traite ma demande. J’avais le double tort d’être étiqueté extérieur et « à côté » ».

Autre remarque vécue : « La gouvernance des données c’est un sous ensemble de la gouvernance IT et donc de sa responsabilité » … tout faux. La gouvernance des données est de la responsabilité de tous métier et IT, terrain et management.

Et attention aux détails. La gouvernance c’est aussi faire la chasse aux points de friction. On parle de « data friction » – tout obstacle, frein qui entrave la fluidité de traitement, lecture, gestion des données. Les points de frictions peuvent être nombreux et mettre à mal le déploiement des principes définit par la gouvernance : une gestion des demandes d’accès aux données bloquante, un choix de modélisation des données les rendant illisibles aux métiers (exemple vécu d’un essai data vault)…

Et dans la logique « à côté » à éviter : faire appel à un cabinet extérieur qui va gérer / manager la gouvernance pour vous (j’ai croisé des interventions externes de service managé de la gouvernance). Vous resterez en dehors de la data.

Sans que cela soit un exemple que j’ai vécu, j’ai trouvé le témoignage suivant inspirant Sources – https://www.youtube.com/watch?v=C7vP1ab1blI&t=3s et https://www.artefact.com/fr/news/comment-peut-on-reinventer-lacculturation-des-projets-de-data-governance/. Il s’agit de l’exemple de Carrefour – avec la création d’un écosystème d’accès aux données – type marketplace interne (classement par famille, étiquetage – composition, qualité, propriétés métier – exemple « contactabilité » client d’un data product, normalisation). Avec une équipe de gestion dédiée et des séances d’adoption de type datathon – et l’idée de fond d’analogie et d’esprit du supermarché data … aligné sur la culture d’entreprise, chacun se sert (data shopping) et est capable d’exploiter les données (en self dans son quotidien à partir de données de base, de données semi-transformées – des indicateurs, de produits finis – un tableau de bord et d’outils de cuisine – des briques de codes, des requêtes SQL). Comme dans un supermarché, on peut tout voir mais la gestion du panier (des demandes en données) est sous contrôle (pas de paiement, mais des droit d’accès).

NB : choix technologique, fonctionnel et ergonomique (UX) – data supermarketplace en développement interne via Google Dataplex.

3) Coconstruire la gouvernance data a été une des meilleures expériences vécues

La mission

La mission : une entreprise historique (plus de 50 ans d’activité) équipée d’un S.I. traditionnel (ERP finance, RH, support logistique), avec un cœur de métier bénéficiant d’un outillage dédié. Le tout sans gouvernance des données d’entreprise. L’ambition : maîtriser et valoriser ses données à la lumière des réglementations, des innovations data (data science, IA) avec le sentiment d’être assis sur un patrimoine data de 50 ans (du cœur de métier) non exploité.

La mission est partie dans l’idée d’instaurer l’esprit de communauté de pratique de la gouvernance des données (favoriser les interactions, créer un réseau d’acteurs et de partage de connaissance sur les données, intégrer des principes agiles dans la gouvernance…).

Avec des choix et des définitions de gouvernance co-définis (idée de bon sens : garantir que les parties prenantes sont intégrées dans la définition de la gouvernance et impliquer un maximum de personnes).

Le résultat

Le résultat au final a été produit et signé des acteurs ayant un rôle par rapport à la gouvernance. Celui qui applique, qui endosse la responsabilité de gouvernance est à l’origine de la définition des processus, politiques – règles, moyens de gouvernance.

Et cela sous la validation explicite du sponsoring CoDir (De fait le CoDir est le premier acteur clé de la gouvernance des données et a produit comme tout autre acteur les règles le concernant).

Pour la mission, cela a signifié une attention particulière à l’idée de co-définition. Notre rôle n’a pas été de produire une cible de gouvernance en chambre mais d’accompagner sa définition.

A l’opposé de la démarche de certains cabinets qui déroulent leur modèle, jusqu’à prendre en charge certains rôles data.

Le succès final de la mission est un résultat opérationnel : des acteurs (QUI) qui savent quoi faire (QUOI et POURQUOI), avec quels moyens (COMMENT – la charge est acceptée), dans quel cadre (OU – le travail au quotidien) et à quels moments (QUAND).

NB : il existe des guides sur lesquels on peut s’appuyer pour cette co-définition. Exemple du procédé de la méthode d’architecture d’entreprise Praxeme (www.praxeme.org) pour rédiger une politique de la donnée de l’entreprise X https://www.praxeme.org/download/data-policy-form/?lang=en et https://www.praxeme.org/download/data-policy/.

Avec qui coconstruire ?

Identifier le premier noyau d’acteurs a pris du temps, mais a été considéré comme un prérequis incontournable. En sachant que ce noyau a évolué au fil de la mission.

Le succès de la mission a été de s’assurer que les conditions de mise en place de la gouvernance étaient atteintes (avec un focus sur les moyens humains). Point d’attention, la mise en place d’une gouvernance des données n’est pas l’affaire d’un instant (l’instant de la mission ici). C’est un effort continu, de progrès, de résilience et d’endurance dans le temps. L’expérience montre qu’il existe des phases d’essoufflement qu’il est nécessaire de prévenir.

J’ai vu attendre le milieu de la mission pour qu’une définition formelle de la data gouvernance soit posée par les acteurs internes eux-mêmes (signe qu’on allait dans le bon sens).

Avec cette approche la gouvernance n’est pas introduite d’un seul coup (ce qui ne marche pas), mais au fil du temps de construction.

Un autre constat, on ne part jamais d’une feuille blanche. Dans toutes les organisations que j’ai côtoyées, il existe déjà des acteurs et des équipes data qui n’en porte pas forcément le nom et jusqu’à parfois ne pas être visibles (équipe d’expertise, IT human middleware … maillon data dans un processus). Ces acteurs sont incontournables dans une telle démarche. Les ignorer c’est l’échec assuré.

J’ai vu aussi l’inverse, des personnes identifiées comme champions, cracks de la data. Là aussi, il faut naturellement les prendre en compte, tout en évitant pour les autres acteurs, le syndrome de décharge « comme il y a des champions, à eux de jouer ».

Dans le même esprit, il a fallu faire prendre conscience de ses limites à l’équipe data centrale et donc transmettre à d’autres équipes (plus proche du terrain) des cas d’usage, accompagner versus faire pour le compte de. L’un des défis de la conception d’une gouvernance des données est de déterminer ce qui doit être centralisé par rapport à ce qui doit être alloué aux domaines données / métiers.

Co-construction avec les acteurs de la shadow data

Enfin, l’exercice met en lumière les acteurs de la shadow data, que l’on ne doit plus ignorer (et parfois soulager – exemple vécu, d’un acteur métier, passionné par la data, qui a mis en place « sous son bureau » des bases MySQL consolidatrices de données de son domaine, devenu un héros incontournable mais sous pression face au bébé qu’il avait construit … système que la gouvernance a du intégrer).

Co-construction avec les « développeurs » data

Cette co-construction doit adresser également les acteurs « développeurs » data (côté IT, comme côté métier – en self data, développeurs de traitements – pipelines de données, en incluant également les data analysts et data scientists) et leur structure d’appartenance (un équipe data platform, une équipe data fabric, une équipe data analysis…).

La gouvernance doit se retrouver dans le code. Et la façon de le faire est à définir avec les « développeurs ».

Exemples de besoins collectées en interview :

Faciliter la recherche des bonnes données (sources de référence) et avoir la possibilité de disposer immédiatement des connecteurs et des données de test (processus de gestion des demandes – droits auprès des data owners à définir par la gouvernance),
Disposer de templates et de modules de tests prédéfinis dans lesquels je dois configurer les métadonnées liées à mes développements (data product configuration, lineage, règles qualité ou de politique embarquées, data contract automatisé – exemple gestion de version : LakeFS – pour le change management, gestion des droits – politique : ODRL – Open Digital Rights Language, contrôles qualité : exemple Great Expectation, déclaration des sources de données dans Dataform – Google)
Accompagnement dans le production du code du respect des standards de mon domaine (exemple en santé FHIR Fast Health Interoperability Resources)
S’intégrer aux besoins d’alimenter l’observabilité des données (logs, connexion des sondes, levées d’alertes) …mais aussi récupérer et réagir à ce qui dit l’observabilité des données (récupérer les alertes, suivre le comportement des pipelines développés et des systèmes invoqués … résoudre les problèmes – exemple de qualité de données : valeurs manquantes, valeurs aberrantes, incohérences référentielles, respect des politiques…, avant l’impact utilisateur / métier. NB : idée de l’observabilité data comme support des tests d’intégration, de bout en bout. Versus la tentation d’un petit code bien placé (à la mode test circuit breaking) qui reproduit une observabilité par et uniquement pour soi… avec les risques d’architecture et de sécurité.

L’impact sur l’organisation des équipes data

La co-construction n’est pas qu’une affaire de définition des impacts de la gouvernance dans les activités d’un acteur (les rôles data à porter).

Elle touche aussi l’organisation des équipes data (développement, data management, data gouvernance). Doit-on mettre en place une équipe centrale, une direction data groupe, des équipes locales, pas d’équipe dédiée mais des rôles au sein d’équipes existantes ? Quelle couverture peuvent avoir ces équipes locales, un seul domaine métier, plusieurs domaine, par data product, sont-elles en mesure de prendre en compte toutes les politiques… ? Comment optimiser leur charge de travail, les capacités ? Comment répartir les compétences ? Recruter des ressources dédiées data (des data stewards) ou s’assurer que tel rôle data fait partie du travail de tel acteur métier ou tel data analyst ?

Majoritairement, l’idée d’une équipe centrale est immédiate. Mais elle a des limites. Du côté des domaines métier, disposer de son équipe (la conserver) est la première demande. Comme souvent il n’y a pas de règle unique sur ce sujet. Il faut juste ne pas occulter le sujet (de toute façon il arrive vite sur la table).

Tous les retours d’expérience montrent, comme pour beaucoup de sujets, que l’esprit collaboratif, coopératif est indispensable. Une équipe de champions data ne peut pas tout maîtriser. Une responsabilité data locale isolée va rencontrer des difficultés de savoir-faire et de pratiques. Au début des années 2000, l’idée de communautés de pratiques faisait son chemin dans les organisation. Dans mes rencontres data, cette idée à tout son sens (voir les travaux d’Eddie Soulier sur ce sujet).

4) Cas d’usage et gardiens data un couple efficace de mise en place de la data gouvernance

Le contexte et l’ambition

Une entreprise dans la domaine de la monétique (avec de fait les données des transactions monétiques dans son cœur de métier … un atout pour la culture data mais sans pour autant éliminer certains silos !), avec l’idée de s’appuyer sur ce cœur de métier et les données associées pour étendre son activité en y incluant une offre de service bancaire (établissement de paiement) et en développant des pistes de valorisation des données.

Le portefeuille de cas d’usage pour aborder la problématique

L’axe central de la mission a été l’identification d’une portefeuille de cas d’usage qui vont tirer les besoins en gouvernance et en moyens techniques.

Avec l’idée d’une gouvernance par cas d’usage enchâssée dans une gouvernance par domaine métier puis de façon globale à l’échelle de l’entreprise.

Exemples de cas d’usage : du réglementaire (blanchiment – lutte antiterroriste), du service client (évolution des reporting commerçants), de la sécurité (conformité PCI-DSS), du pilotage financier prédictif, du monitoring analytique temps réel, de la simulation (sur changement de règles métier), des vues 360° historisées (commerçant, comptes, canaux), de la valorisation (exemple mise à disposition de l’origine des porteurs de cartes de paiement aux responsables de développement de zones touristiques).

Par cas d’usage, identification des points de gouvernance – exemples : alimentation du dictionnaire de données et des points de lineage, définition du dispositif de maîtrise / contrôle des sources de données, définition des rôles data dans la maitrise de la collecte des données et de leurs usages (data owner, data steward – besoins en administration de données), avec l’organisation dédiée à la qualité des données, maîtrise de la circulation des données (dans le domaine métier et entre domaines), classification de la sensibilité des données en regard des politiques…

Le tout se retranscrivant dans des outils de gouvernance à mettre en place (catalogage des données et gestion des métadonnées par exemple) et dans des politiques de données contrôlées au niveau des domaines métier (interopérabilité sémantique par exemple) et d’entreprise (avec en CoDir la présence des gardiens data de niveau entreprise en charge des politiques de données).

Extrait du retour d’expérience complet : « De façon transverse un élément clé de succès a été le support et l’animation d’un portefeuille des cas d’usage data. A la fois comme outil de pilotage de déploiement de la gouvernance et comme outil permettant d’avoir une vision d’ensemble des cas d’usages data support aux réflexions métier sur les potentialités d’exploitation des données (tel cas d’usage et les données associées de tel domaine peuvent intéresser tel autre domaine). »

La représentativité du portefeuille

Un attention particulière est à avoir sur la représentativité du portefeuille.

Extrait du contrôle qualitatif du portefeuille de cas d’usage :

Quelle couverture des domaines métier (pas de domaine orphelin) ?
Est-ce que des cas d’usage sont bien intégrés aux grands projets de transformation (nouvel ERP, refonte digitale…) … qui ne manquent pas et pour qui la gouvernance des données n’est pas la priorité (par expérience, il faudra se battre pour y imposer le volet gouvernance)
A-t-on des cas d’usage qui parlent à tous les niveaux de l’organisation (du local, au COMEX en passant par le middle management) ?
A-t-on des cas d’usage qui tirent la coopération de plusieurs domaines, processus ?
A-t-on des cas d’usage qui touchent notre écosystème de partenaires, de tiers externes, d’initiatives open data ?

Les cas d’usage comme support d’apprentissage

L’expérience des cas d’usage, montre aussi leur intérêt comme forme d’apprentissage de la gouvernance (par l’exemple), comme source de transmission pédagogique (par ses collègues), comme support de communication sur la gouvernance, d’autant plus que le cas d’usage nécessite le croisement de données de plusieurs domaines fonctionnels.

5) La gouvernance est vue uniquement comme défensive et c’est dommage

Gestion et contrôle des accès aux données (sensibilité, sécurité), gestion de la qualité des données et compliance réglementaire vis-à-vis des données, sont les trois premiers sujets traités par la gouvernance. Et souvent l’effort s’arrête là.

Passer à une gouvernance offensive demande un autre état d’esprit vis-à-vis des données.

Et ce ne sont pas les mêmes actions à déployer, ni forcément les mêmes acteurs à solliciter.

Beaucoup d’organisations, n’effectuent pas ce passage et restent dans une attitude défensive.

L’approche défensive est souvent réactive, la gouvernance sera mise en place que si vraiment elle est nécessaire. Alors qu’une approche proactive est le signe d’innovation, de tirer des avantages de la gouvernance des données.

Au crédit de l’approche défensive, il est plus facile de la justifier, de trouver les leviers (risques) la légitimant (pénalités, amendes en cas de non-conformité, couts liés à la non qualité de données, manageurs mis en difficultés par de mauvaises données).

A contrario, l’approche offensive demande plus d’effort, d’imagination, de connaissance profonde du métier (voir par exemple les outils de stratégie data : https://www.datassence.fr/2022/10/27/revue-data-du-mois-octobre-2022/#_ftn8 et https://www.datassence.fr/category/data-strategy/ ). C’est ici que l’on va mener l’exercice de valorisation des données : enrichissement et performance métier, nouveau revenu (valeur économique), alignement axiologique (dont éthique).

6) Pour les cas d’usage à forte valeur métier, il est intéressant de s’inspirer des pratiques des professionnels des données (exemple des statisticiens)

Toutes les données ne méritent pas le même niveau de gouvernance.

Pour certaines données, la gouvernance peut être minime, mais pour d’autres elle doit être exemplaire.

Pour définir une gouvernance des données exemplaire, on peut s’inspirer de celle appliquée par les statisticiens avec le déploiement d’outils méthodologiques et de data management (exemple : Generic Statistical Business Process Model (GSBPM) – https://www.insee.fr/fr/information/4137701 et aussi un ensemble de retours d’expérience et de pratiques à retrouver dans le courrier des statistiques de l’Insee – exemple – https://www.insee.fr/fr/information/8203036 Faciliter l’accès aux données de l’Insee).

D’autres cadre de gouvernance peuvent être appliqués à l’exemple de ceux appliqués pour le RGPD, SOX ou encore BCBS 239 et aussi pour répondre à la directive CSRD.

Attention, il y a un danger de créer des silos de gouvernance en fonction des données traitées et des enjeux. Par exemple de nombreuses banques ont mis en place des systèmes et des équipes dédiées au traitement des données dans le cadre de BCBS 239. Le réflexe est classique, un problème, une équipe, un système. Alors que les données concernées ont une emprise plus large que le seul sujet adressé (BCBS dans notre exemple).

7) Les composants data socles (quantum data) de la data gouvernance : data sources, data contracts, data products

Quantum data : data sources, data contracts et data products

Les données ne sont pas données* ! La data gouvernance n’est pas juste poser des règles sur des données qui sont là.

L’idée est de partir des racines de l’univers des données pour poser les règles de data gouvernance (idée de bon sens : se focaliser sur l’origine, être au plus près du contexte de naissance).

NB : dans la même idée qu’en génie logiciel, où on apprend qu’un bug traité au moment du développement coute X fois moins cher que s’il est détecté en production (d’où l’importance de la stratégie de test), le coût de la gouvernance va coûter X fois moins cher lorsqu’elle traitée dès le départ versus un traitement a posteriori une fois les données déployées, dupliquées (voir l’exemple du cout des nombreux projets de conformité RGPD mobilisant des pèlerins qui vont parcourir l’entreprise à la recherche de données concernées puis des évangélistes qui doivent convaincre une multitude d’acteurs de mener les actions de mise en conformité).

* Repris de l’excellent article de Pascal Rivière de l’Insee – « Qu’est-ce qu’une donnée » – https://www.insee.fr/fr/statistiques/fichier/5008707/courstat-5-8.pdf

Ces racines sont de trois natures :

1) Des sources de données (producteurs de données), ou autrement dit les lieux et les cycles de naissance des données. Stratégie de collecte, maîtrise de la naissance des données et du contexte associé sont clés et doivent être visibles, au premier plan. On ne doit pas s’intéresser aux données seulement quand elles sont là.

2) Des data contracts, c’est-à-dire la formalisation contractuelle de mise à disposition des données entre producteurs de données et consommateurs (support des cas d’usage),

3) Et des data products, c’est-à-dire la forme permettant de gérer les données, leurs circulations, leurs compréhensions, leurs interconnexions (exemple du maillage dans le data mesh).

L’enjeu des métadonnées

Ces trois éléments sont décrits à l’aide de métadonnées.

Dans ces métadonnées on va retrouver les éléments supports à la gouvernance des données (classement en termes de sensibilité, de niveau de qualité, de niveau de service – SLA, de niveau de standardisation… plus largement la couverture et la traduction en métadonnées des politiques en jeu, gestion des droits, règles d’interopérabilité technique et sémantique – conformité à dictionnaire métier, liens contextuels nécessaires à l’interprétation des données – place dans un modèle, lineage).

Ensuite, il s’agit d’appliquer l’idée de métadonnées actives. Autrement dit, les outils data, les infrastructures data, l’organisation data vont exploiter les métadonnées de gouvernance pour l’automatiser, la monitorer, la gérer (data management) le tout sous l’œil de la data observability (suivre le parcours des données).

Gouvernance by design

J’ai croisé une fois, l’idée de gouvernance by design d’un data product. C’est-à-dire dès sa conception, penser aux besoins de gouvernance : règles de contrôle embarquée, contexte embarqué pour comprendre les données (métadonnées, liens sémantiques), classification, gestion de son cycle de vie, statut de ses consommations…

Les data contracts quant à eux sont plus vieux dans la construction d’architectures de données (on parlait de contrat d’interface du temps des EAI -Enterprise Appplication Integration, data hub). Ils sont encore plus d’actualité. En termes de gouvernance, ils doivent permettre de contrôler les relations producteurs / consommateurs de données, maîtriser les dépendances – couplages / découplages, la bonne prise en compte de l’autorité des sources de référence (référentiels de données, circulation des identifiants), le respect des normes – ajustements / mapping à un langage commun…

L’infrastructure capable d’exploiter nativement les quantum data est en devenir

En termes de retours d’expérience, on en est au début.

Ceux qui possèdent une expérience en Master Data Management (MDM) sont avantagés (certains outils de MDM proposent depuis longtemps la gestion automatique de politiques de données au travers de règles et de métadonnées).

Une difficulté est de disposer de l’infrastructure (la structure d’accueil) qui sera capable d’exploiter ces trois composants architecturaux (interpréter les métadonnées). Une telle infrastructure globale n’existe pas. Les opérateurs cloud data avancent sur ce sujet, les éditeurs de data platform également. C’est un des points critiques dans le développement du data mesh (voir dans cet esprit l’initiative Next Data – créer un OS data – https://www.nextdata.com/ de Zhamak Dehghani à l’origine du concept de data mesh).

Normalisation des quantum data

Il y a une deuxième dimension de la gouvernance au travers de ces composants.

Ces composants doivent eux-mêmes être gouvernés en termes de : couverture, cohérence, redondance, dépendance, usages, normalisation.

Sur ce dernier point des initiatives de standardisation et open source se développent (voir https://opendataproducts.org/ , https://github.com/Open-Data-Product-Initiative/v1.0 et https://opendatacontract.com/ ).

La formalisation au niveau des sources de données (naissance des données) est moins forte.

En lien également les travaux autour de l’open lineage – https://openlineage.io/ et https://github.com/OpenLineage/OpenLineage

Les data platforms commencent également à adopter ces éléments.

Des nouveaux processus de gestion de ces composants sont à définir et mettre en place par la gouvernance (quand créer un data product, selon quelle démarche, comment traiter les demandes d’usage ? …).

A suivre aussi, l’initiative d’un acteur de l’énergie en France qui s’est lancé dans ce type d’approche (data product, contrat de maillage…gestion des dépendances, gestion de la demande).

Et pour finir voir dans cet esprit l’idée de Shift-Left Data Democracy (SLDD) – la gouvernance au plus près de la source de données (passage d’une gouvernance réactive à proactive) – https://dlthub.com/blog/governance-democracy-mesh et aussi https://medium.com/@dlthub.com/shift-left-data-democracy-the-link-between-democracy-governance-data-contracts-and-data-mesh-4dbd976e8817.

8) Une gouvernance des données qui propose une gestion des données « à la main » non pour partie automatisée est très limitée

Appliquer la gouvernance « à la main » est fastidieux

J’ai vu majoritairement des efforts de gouvernance peu automatisés, « à la main ». Soit au travers d’opérateurs (data administrateur) dans un poste récurent, soit au travers du mode projet.

Avec aussi une charge systématique de questionnement des acteurs convoqués sur l’état des données et de la gouvernance associée dès qu’une problématique intersecte avec les données (ce qui est fréquent !).

En 10 ans de recul, la situation est délicate. Les données sont partout et l’automatisation de leur gouvernance n’a pas suivi.

Concrètement, cela se traduit par (exemples) :

– la gestion du patrimoine data (recensement, classification, catalogage) à la main (à l’aide d’un outil a minima mais purement descriptif – les premiers data catalog).

Retour d’expérience vécu N fois, le grand classique de la fenêtre de connaissance du mode projet, moment où l’effort de documentation, de recensement des données par l’équipe projet est au maximum et qui va s’étioler une fois le projet terminé. Et à reconstituer dès qu’un problème se pose. L’effort doit être continu (embarquement de la maintenance dans la gouvernance a minima … avec une attention particulière aux migrations dans le cloud),

– la gestion de process qualité, avec un ensemble de moyens adossés aux chaînes de production et gérés par des personnes dédiées (rapport de contrôles, alerting, traitement de rejet, mise en qualité de stocks de données),

– le traitement réglementaire via un projet et une équipe dédiée (exemple traitement des limites de conservation de données personnelles), qui va prendre son bâton de pèlerin, pour recenser les données concernées, définir les actions dans les différents systèmes, faire exécuter ces actions…

– et d’une manière générale, un état systématique, une archéologie data à la main (usante) de la situation de telle famille de données, dès lors qu’un sujet les concerne (qui a les accès ? quels systèmes les portent, quelles sont les copies connues ? quelles règles appliquées par tels scripts, qu’est ce qui est diffusé et à qui ?).

Tout cela est lourd et pas toujours gratifiant (peu visible), avec de nombreuses limites (problème d’actualisation, charge manuelle, incapacité à traiter toutes les situations – dont la prolifération des règles de compliance).

Cette situation est anormale lorsque l’on sait que les données n’ont majoritairement* d’existence qu’au travers des systèmes d’information (officiels et shadow). Et lorsqu’on affronte le volume et la complexité croissante des données.

* voir aussi le thème n°17 !

L’automatisation est indispensable

La tendance de fond est une automatisation des principes de gestion de données définis par la gouvernance (une gouvernance des données active versus rétroactive).

Le sujet n’est pas simple*. Mettre en place une telle automatisation quand cela n’a pas été prévu dès le départ est coûteux (récupérer et intégrer des métadonnées, mettre en place les traitements automatiques de gouvernance …). C’est quasiment un système de système à mettre en place (ce qui serait une erreur d’ailleurs – l’automatisation doit être intégrée nativement dans les S.I.).

Les data platforms de type stack data centralisé l’ont bien compris. En regroupant les données, elles permettent l’automatisation de la gouvernance (mais seulement sous leur toit).

*NB : la data gouvernance ce n’est pas se cacher derrière la mise en place d’un data catalogue qui doit tout régler avec la caricature le projet de data gouvernance = le projet data catalogue d’entreprise.

Autre approche intéressante, certaines data platforms métier proposent nativement le support de la gouvernance en l’intégrant et l’automatisant dans les processus data.

Pour des retours d’expérience et une présentation voir l’offre d’Orkestra Data (https://orkestra-data.com/ ).

Leur webinaire vous donnera de belles pistes par rapport à cette problématique : https://www.youtube.com/watch?v=T9nHKfJoy0k

Derrière cette automatisation se cache la stratégie vis-à-vis des métadonnées. Avec le défi de leur collecte et intégration dans les systèmes qui vont porter des fonctions de gouvernance. Sans ces métadonnées inutile de parler de gouvernance et encore plus inutile de penser son automatisation.

Le défi est plus ou moins grand. Soit il est relevé à la naissance des systèmes (à l’exemple de ce que propose la data platform métier Orkestra citée plus haut), soit il doit être relevé a posteriori, sur des systèmes existants (la grande majorité des situations).

Et ce défi doit s’intéresser à la collecte des métadonnées tout au long du cycle du de vie des données, de leur naissance, à leur traitements, en passant par leur stockage, jusqu’à leur diffusion dans des différents supports (reporting, documents, datasets…) et à leur extinction progressive dans des systèmes d’archivage.

Le rôle clé des métadonnées

Une image, si vous voulez automatiser votre relation client, vous avez besoin des données client. Si vous voulez automatiser votre relation aux données (la gouvernance), vous avez besoins des données sur les données. Et comme pour des données client, ces données sur les données doivent pouvoir évoluer dans le temps, s’adapter aux besoins de gouvernance (exemple une nouvelle réglementation, une nouvelle étape dans le cycle de vie de la donnée).

En termes de retour d’expérience, le chemin peut être long. D’abord faire comprendre à tous les niveaux des acteurs de gouvernance, ce que sont ces métadonnées et leur rôles. Les sponsors comme les autres doivent comprendre cela. Mais, dès que vous prononcez les termes gouvernance des données puis immédiatement après métadonnées, vous pouvez être sûre de perdre 90% de votre audience, qui va y voir un sujet d’expert et technique (ce qui n’est pas le cas). Pourtant la stratégie vis-à-vis des métadonnées est centrale lorsqu’on définit une gouvernance des données. Un premier acte de gouvernance est une bonne pédagogie sur ce sujet.

9) Data gouvernance as a code

Une faiblesse à corriger

On constate, une grande faiblesse de la prise en compte des règles de gouvernance dans les développements data (pipelines, stockage). Les règles sont majoritairement vues a posteriori – gouvernance par inspection – rétroactive (une fois les données traitées, sorties des chaînes de traitement). Et quand elles sont prises en compte a priori (dans le code – gouvernance par règles), c’est rarement de façon coordonnée (exemples : telle règle de mise en qualité va être dupliquée N fois dans différents pipelines et lorsqu’elle doit être modifiée, elle doit l’être N fois, ou encore pour telle donnée – sensible – les règles d’alimentation d’un dispositif d’observabilité ne sont pas prises en compte par tous les traitements … et donc des trous dans la raquette subsistent*).

Pire, parfois des duplications de données, des dépendances entre données, data products sont créées et mettent à mal les règles de gouvernance.

* Des efforts émergent avec des acteurs data (fournisseurs d’IDE, d’ETL) qui ont pris conscience de la nécessité d’appliquer aux développements data les bonnes pratiques du développement logiciel (génie logiciel) – voir l’exemple de ce que propose Dbt – https://www.getdbt.com/.

A cela vient s’ajouter les solutions self data / self BI qui doivent également intégrer les règles de gouvernance. Certaines solutions l’ont bien compris et proposent des fonctions dédiées à la gouvernance et directement intégrées dans les traitements low / no code data.

Automatisation et qualité logiciel au service de la gouvernance

L’approche policy-as-code a un double intérêt. Elle permet d’automatiser, mais également d’appliquer les bonnes pratiques du génie logiciel au service de la gouvernance (gestion de version des politiques, instanciation des stratégies de test de contrôle du respect des règles de gouvernance, déploiement automatisé DataGouvOps, alerting – monitoring en cas d’anomalie).

La déclinaison de la gouvernance dans le code est un défi. Comme pour le thème n° 7 (les composants data socles), il y a besoin d’une infrastructure, une structure d’accueil capable d’interpréter les codes de la gouvernance (règles exprimant les politiques, exemple des droits d’accès ou encore sur l’interopérabilité).

La gouvernance as a code de bout en bout reste un graal.

10) Le data mesh est une bonne source d’inspiration au travers de l’idée de data gouvernance fédérée

Avertissement : je n’ai pas de retour d’expérience direct sur une telle mise en place. Par contre, j’ai participé à plusieurs échanges sur la définition de domaines de données – voir dans le guide « Dynamique des data platforms » page 19 ce qu’on en dit – https://www.datassence.fr/2024/04/23/dynamique-et-panorama-des-data-platforms/ .

Par ailleurs, on trouve quelques premiers retours d’expérience et leçons sur Internet (voir en fin de cette rubrique).

Le pilier gouvernance fédérée du data mesh

Après un important buzz, le data mesh s’établit progressivement comme référence dans la gestion des données. Parmi ses 4 piliers, le pilier de data gouvernance fédérée n’est pas forcément le plus mis en avant. Mais les quatre piliers du data mesh sont interdépendants.

Rappel des principes clés de ce pilier :

Sur quoi porte la gouvernance (quel est l’actif) ? ->

Les données et les data products
Le maillage (et c’est un défi d’insuffler l’état d’esprit de la gouvernance à cette échelle)

Que vise la gouvernance ? -> Le développement de la valeur de l’actif qui passe par sa qualité

Comment la gouvernance s’applique ? -> Par la définition des bons moyens-investissements (organisationnels, systèmes, règles-politiques, pratiques, projets) pour développer la valeur de l’actif.

Via quel style de gouvernance ? -> Fédérée : avec comme entités de base les domaines métier

L’idée de fédération, à quoi cela s’oppose :

A la centralisation, au monolithique unique (les 4 piliers dans un grand tout) – qui est un goulet d’étranglement, un facteur de rigidité (NB : on parle de distribuer et de fédérer la gouvernance)
A la data « à côté » (voir REX précédent – thème n°2) – facteur de complexité, d’inefficacité et de déresponsabilisation
A tout ce qui peut conduire à des frictions dans la circulation et l’usage des données – data products (les données comme produit – pilier data mesh)

Pour privilégier l’autonomie versus un contrôle central, via la dimension self (les données en self-service – pilier data mesh) exercée par les domaines métier (les données au plus près des domaine métier – pilier data mesh). Au plus près de de la connaissance, des responsabilités et de l’échelle de temps locale.

L’idée de fédération : comment cela se définit ?

1) Idée d’enchâssement des règles de gouvernance suivant la portée d’usage / d’influence du data product :

Portée locale : règles locales (définition par le domaine métier)
Portée interfonctionnelle (exemple dans le cadre d’un processus inter-domaines, d’un suivi de bout en bout, d’une vue 360°) : règles interfonctionnelles (définition par le cadre interfonctionnel – coopération des domaines concernés, responsable de processus…)
Portée globale : règles globales (définition de niveau entreprise – stratégique, d’agrégation – exemple historique pour les systèmes de comptabilité-gestion, suivant des expertises transverses – juridique – sécurité – risques – compliance…)

2) Responsabilisation des domaines métier dans leurs relations : SLA – contrats – règles entre domaines producteurs des data products et domaines consommateurs

L’IT a en charge d’automatiser au maximum les règles de gouvernance dans les plates-formes data (stockage, échanges…). La fédération s’applique aussi à la gouvernance IT des différentes plates-formes (qui doivent supporter le maillage).

La gouvernance doit suivre le changement continu qui entoure les données. Le changement est intrinsèque aux données. Il n’est pas une exception. La gouvernance doit être bâtie sur cette base : réduire toutes les frictions qui impliquent du délai, des efforts dans la circulation et manipulation des données.

Référence : l’ouvrage de Dehghani, Zhamak. Data Mesh. Chez O’Reilly – https://www.oreilly.com/library/view/data-mesh/9781492092384/

Exemples emblématiques où la gouvernance fédérée est absolument nécessaire

J’ai participé à des projets vue 360 client, vue 360° intervention, parcours client de bout en bout, recherche de signaux faibles (exemple dans la fraude).

Projets, qui sollicitent de fait N métiers, N contextes. Où chacun a un bout, un aspect de l’objet (le client, un produit, un processus, un écosystème) traduit en termes de données (on parle de multimodalité – https://fr.wikipedia.org/wiki/Multimodalit%C3%A9 ).

La gouvernance fédérée est la solution pour croiser, rapprocher les contextes, en alliant gouvernance locale (indépendance et au plus près de l’expertise métier) et gouvernance globale (soutien en termes d’intégration pour la vision d’ensemble).

Des retours d’expérience collectés sur Internet

Articles retours d’expérience :

11) Les data platforms dans la limite de leur portée (sous leur toit) offrent de plus en plus de fonctions supports à la data gouvernance

La montée en puissance des fonctions de data gouvernance dans les data platforms

Le monde des solutions de data platforms évolue. J’ai eu le plaisir de participer à deux guides sur cette évolution – voir : https://www.datassence.fr/2024/04/23/dynamique-et-panorama-des-data-platforms/

Dans cette évolution la prise en compte de la data gouvernance est de plus en plus forte.

Avec une bascule du technique vers le fonctionnel. C’est-à-dire de la gestion technique des données (champs, tables) à une gestion fonctionnelle (gestion patrimoniale des données, gestion du cycle de vie des données, support des politiques de données, support des fonctions pour les rôles data, data observabilité…).

Dans le guide de Panorama des data platforms, un point de synthèse sur la capacité d’accompagnement de la data gouvernance est fait par éditeur. Et dans les tendances du marché, un point d’évolution sur le support de la data gouvernance par les data platforms est fait (page 52 – Guide Panorama).

L’actualité confirme cette tendance. Avec par exemple l’évolution de Purview de Microsoft au 1^er semestre 2024. Voir les revues mensuelles data sur ce sujet https://www.datassence.fr/2024/05/02/revue-data-du-mois-avril-2024/#_ftn4 et (https://www.datassence.fr/tag/revues-data-mensuelles/ ).

Voir aussi l’apparition d’une nouvelle génération de solutions dédiées à la gouvernance en modèle self service data comme l’offre de Data Dynamics – https://www.datadynamicsinc.com/data-governance-and-compliance/ (« Policy-based Data Governance
Framework and Insight », « Data Observability and Root Cause Analysis (RCA) », « RBAC Driven Process and Controls », « Data Usage & Traceability », « Policy-driven Data Migration », « Data Lifecycle Management »…).

12) Passer à l’échelle est un palier critique

Appliquer localement ou sur un cas d’usage particulier des principes de gouvernance ne pose pas de problème. Les données sont directement entre les mains des acteurs métiers et IT (responsable de processus, analyste, développeur, responsable applicatif, équipe projet). Il suffit de ne pas oublier leur gouvernance.

Passer à l’échelle d’un domaine métier, demande un peu plus d’effort mais n’est pas rédhibitoire. La communauté d’action, de connaissance et d’intérêt que forme un domaine métier facilite la prise en compte d’une gouvernance des données à cette échelle.

Où cela devient plus difficile c’est le passage à l’échelle d’une organisation entière, multi processus, multi domaines, multi métiers, multi-entités / sites…

Comment mettre en place une gouvernance des données à cette échelle ?

La difficulté porte sur la prise en compte de règles de gouvernance au sein d’entités locales qui dépassent leur périmètre de responsabilité.

En termes de retours d’expérience, on rencontre :

13) La data gouvernance doit composer face au mythe de la vue data unifiée d’entreprise

Le mythe de la vue data unifiée

Le marché de la data, concepts et solutions, pousse la vision d’une couche data « encapsulante » d’entreprise et sur laquelle toute utilisation des données doit se référer et donc vu comme lieu idéal pour la data gouvernance.

L’idée n’est pas récente.

Le besoin de pouvoir accéder de manière unifiée à différentes bases de données a émergé dès leur naissance.

Des solutions sont rapidement apparues et restent au cœur des solutions actuelles :

L’entrepôt de données : on centralise les données, les données sont déplacées,
La virtualisation de données : on médiatise via une vue virtuelle des données, les données restent à leur place,
Le moteur SQL multi-bases : on interroge les données directement à leur place.

Cette idée de « super » vue data d’entreprise vise plusieurs ambitions :

La gestion patrimoniale d’ensemble des données (respect des politiques data d’entreprise – contrôle / application – gouvernance de bout en bout),
Gestion de la connaissance (données -> information -> connaissance), recensement – catalogage des données, contextualisation sémantique (enrôlement dans des modèles, classements, labélisation, autorité référentielle), contextualisation opérationnelle (lineages statiques et dynamiques), connaissance et partage des usages,
Observabilité d’ensemble – événements data – surveillance – tests – suivi de bout en bout (cycle de vie des données),
Support au delivry pour des usages transverses, de consolidation, de réutilisation : vue 360°, 2^nd vie des données, consolidations, croisements, alimentation d’usines à calculs (data science, IA),
S’organiser autour des données : avec en central le support de la gouvernance.

Tout serait plus facile avec une vue unifiée des données.

Malheureusement cette idée est un défi et elle se heurte à plusieurs limites et freins.

Quelques exemples :

Des données sans contexte n’ont pas de sens, comment traduire ce contexte dans la vue unifiée ?
Les données bougent tout le temps (en termes de contenu, de définition, d’usage, de règle…), comment aligner la vue unifiée sur un tel mouvement continu ?
La vue unifiée ne sera jamais complète, tout centraliser, tout virtualiser n’a pas de sens.
La construire est une charge importante, qui se heurte à des situations où l’automatisation n’est pas toujours présente / possible ou coute trop cher… et nécessite une vue unifiée des métadonnées !
Dans cette même logique, le défi de créer une vue unifiée sur la base de l’héritage laissé dans le patchwork de systèmes qui composent un S.I. (au-dessus ou par reconstruction).
Etc.

Il faut aussi résister aux sirènes des éditeurs de solutions data … qui de façon magique (plug and play) en vendant / imposant leur vue data vont tout résoudre … « être le point unique de vos données… on s’occupe de tout ».

« Une plate-forme unique de vos données. Mobiliser les données de toute l’entreprise voire du monde entier – Snowflake. Unifiez vos données et l’IA – Databricks ». Et le tout accompagné d’un ensemble de concepts, de termes qui s’intègrent dans cette idée de vue data : unified data, maillage de données, data sharing, data marketplace, data hub, couche sémantique…(à perdre tout interlocuteur à qui on expose le sujet de la gouvernance des données !).

Comment gouverner sans une vue complète des données ?

Face à tout cela, la data gouvernance doit composer.

Il existe des solutions, des approches.

J’ai eu la chance d’animer un atelier sur ce sujet avec des acteurs data de différentes entreprises.

Avec les participants nous avons partagé plusieurs retours d’expérience et des pistes de solutions (exemple définir des vues data partielles logiques, se concentrer sur l’interopérabilité technique – fonctionnelle – sémantique – de gestion des données).

Je vous proposerai une restitution dans un futur article.

Détour par les silos de données : les bons et les mauvais

Pour terminer sur ce thème, un petit mot sur les silos de données. J’ai rencontré des silos de données, des vrais, avec une forme d’épuisement à vouloir les ouvrir (souvent par crainte de perte d’autonomie, de perte de pouvoir sur les données concernées). J’ai aussi rencontré des silos de données, des vrais encore, avec une expertise locale élevée, ses propres concepts et règles, bâtie au fil du temps, avec une bonne volonté d’exposé les données concernées. J’ai entendu au cours de réunion gouvernance des données, l’idée « il faut tuer les silos de données ». Tout faux, certains silos doivent être embarqués mais préservés parce que à forte valeur locale avec un risque de perte de savoir si alignés sur une politique globale. Tout faux, ceux qui protègent leur silo, font preuve de responsabilité et c’est précieux. Bon, il existe quand même des silos inutiles voire cauchemardesques (souvent sur la base de copies, ou de redondances de données), qu’une bonne démarche d’architecture d’entreprise doit traiter.

Une dernière remarque sur ce point, j’ai vécu un data lake visant à casser les silos qui s’est fini en data swamp. Et j’ai vécu un data lake vu comme structure d’accueil de silos qui a très bien réussi.

14) Un détour par une forme de data gouvernance qui nous vient de nos cousins Québécois : la fiducie des données

Il existe pour certaines données, une problématique particulière de gouvernance : les données sur des tiers qu’une entreprise va récolter et utiliser. Dans cette catégorie on reconnait plus particulièrement les données personnelles (mais cela peut aussi concerner des données de partenaires).

La fiducie des données

Dans ce cas la gouvernance doit inclure d’une façon ou d’une autre le tiers concerné et ses droits.

Issus du monde anglo-saxon et plus particulièrement du Canada/Québec, il existe un modèle de gouvernance, appelé fiducie des données.

Ce modèle s’inspire du modèle juridique de la fiducie.

L’idée est d’une délégation du contrôle de l’usage des données d’un tiers par une organisation indépendante, qui agira au nom du tiers et en tenant compte d’un intérêt général, avec en retour une valeur ajoutée (du fait du partage des données).

Appliqué aux données cela donne :

Des tiers bénéficiaires mettent à disposition des données les concernant auprès d’un acteur, le fiduciaire,
Cette mise à disposition est régulée par un contrat de délégation (transfert de responsabilité) en lien avec des finalités, entre les bénéficiaires et le fiduciaire,
Les finalités sont sous définition et contrôle d’une autorité appelé le constituant,
Cette autorité défini le fiduciaire, établi avec lui un contrat de fiducie (qui fixe les finalités, par exemple en fonction d’une stratégie) et le contrôle,
Le fiduciaire à partir des données mises à disposition, constitue et gère (création, administration, localisation, sécurisation), un patrimoine pour la réalisation des finalités,
Enfin des consommateurs vont faire usage des données, régulé par un contrat d’usage en lien avec les finalités (à nouveau transfert de responsabilité).

Les idées portées par la fiducie des données :

Valeur collective et inclusive de la chaîne d’acteur en lien avec les données : des tiers et les données les concernant aux consommateurs de ces données en passant par un fiduciaire et le tout sous contrôle d’une autorité,
Constitution d’un patrimoine de données (à valeur individuelle pour le tiers bénéficiaire et d’ensemble pour les consommateurs), bien commun pour répondre à des finalités (réponse à une stratégie)
La gouvernance vise le respect et le développement du patrimoine et des finalités associées (respect exclusif, on ne fait pas ce qu’on veut avec les données, usage éclairé des données)
Palie la faiblesse des modèles de gouvernance des données fondés sur le consentement. Modèles, où c’est le tiers qui a la responsabilité de déterminer si les finalités d’une entreprise en matière de collecte et d’utilisation de ses données respectent ses préférences et sont équitables (ce qui dans le cas d’une personne est quasi impossible et de plus s’inscrit dans une asymétrie et un déséquilibre en sa défaveur*)
L’idée est d’établir une relation de confiance gagnante-gagnante et se traduisant dans la qualité des données :
- Des tiers bénéficiaires sur l’usage de leurs données (« consentement » délégué et éclairé -> intérêt par rapport aux finalités, préservation de leurs données) -> pousse à un partage des données de qualité,
- Des consommateurs dans l’usage des données (valeur du patrimoine mis à disposition, qualité des données en adhérence avec les finalités).

Peu de retours d’expérience complets mais des principes que l’on retrouve dans d’autres cadres

Le modèle est séduisant mais à notre connaissance, il n’existe pas d’application complète (voir peut être https://www.culturepedia.ca/ ). Par contre, il met le doigt sur un sujet que des acteurs de gouvernance peuvent tirer à leur profit et en faire un différentiateur.

Approches voisines data altruism

A voir également dans cet esprit (mais à ne pas confondre), la gouvernance de données dans la logique data altruism (https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022R0868#d1e2123-1-1 ), évoquée dans le Data Governance Act (DGA) – https://digital-strategy.ec.europa.eu/en/policies/data-governance-act et le texte complet en version FR https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022R0868

* Voir McDonald, A. M. et Lorrie, F. C. (2008). The Cost of Reading Privacy Policies. Journal of Law and Policy for the Information Society, volume 4,3.

15) Les sept freins systématiquement rencontrés par les acteurs en charge de la mise en place de la data gouvernance

Au cours de mes rencontres d’acteurs en charge de la mise en place de la data gouvernance, sept freins sont systématiquement cités (freins qui se recouvrent).

Frein n°1 : data gouvernance = menace

La data gouvernance est vécue comme une nouvelle contrainte en plus, une menace sur son quotidien, imposée de l’extérieur avec parfois un sentiment d’ingérence.

Frein n°2 : data gouvernance éloignée du business

La data gouvernance est trop éloignée du business, en termes de ROI, de pratiques (on parle données avant de parler business, c’est bureaucratique), de coopération à avoir avec des acteurs non impliqués directement dans le business (exemple de l’IT avec qui on doit encore composer ou une équipe data centrale éloignée !).

Frein n°3 : data gouvernance = charge supplémentaire

La data c’est bien, la data gouvernance est nécessaire, mais c’est une charge en plus, une complexité en plus (un sujet en plus à considérer) qu’il est impossible d’intégrer dans son quotidien (exemple vu dans une Mutuelle, 6 mois de négociation auprès des domaines métier, pour arriver à faire dégager 2h par mois par un unique domaine pour traiter des sujets de data gouvernance – mettre son activité quotidienne en suspens pour de la data gouvernance, c’est plutôt rare).

Frein n°4 : le manque de moyens

Dans le même esprit, la faiblesse des moyens à destination des acteurs qui doivent traiter la gouvernance vient renforcer le sentiment de charge.

Frein n°5 : la fuite devant les responsabilités

Peu de personnes veulent endosser les responsabilités associées à la data gouvernance.

Ou alors, lorsqu’un responsable fini par être identifié (un data owner par exemple), il n’a pas la main direct sur les données, il est by passé par les acteurs terrain qui continue à traiter les données sans l’impliquer. Les rôles défini par la gouvernance ne sont pas réellement occupés / adoptés. Et quand c’est assumé, une forme de découragement arrive vite, aussi bien par l’acteur en charge du rôle que par les autres acteurs en contact avec les données.

NB : data owner est le rôle le plus difficile, comment être propriétaire de données (données client par exemple), quand ces données sont manipulées quotidiennement par des dizaines d’autres acteurs. Attribuer la propriété de données n’est pas une chose facile. Une piste : remplacez-les data owners par des data product owners.

En termes de retour d’expérience, je fais souvent le constat, que les rôles et responsabilités data (owners et stewards) sont soit pas encore (et cela dure) attribués, soit ils sont attribués mais l’engagement des personnes en charge est très partiel voire éteint.

La responsabilité est mal définie, elle fait peur, elle manque de moyens… et sans responsables cela ne marche pas.

Et quand elle est assumée par un acteur à temps plein, celui-ci prend le risque de déclassement (à la première coupe budgétaire, vous êtes une ETP à risque), d’être en dehors du flow business (vous n’êtes plus directement impliqué dans la création de revenu), de se retrouver à accomplir des tâches de data steward qu’il n’est pas (cataloguer les données, mettre à jour les métadonnées, surveiller la qualité, gérer les accès…). NB : data owner et data steward forment un couple qui peut reposer sur une même tête ou plusieurs. Mais j’ai vu aussi des propriétaires de données consacrer habilement la majorité de leur temps à résoudre des problèmes multi-domaines que personne ne porte avec un fort retour en termes de revenus.

Frein n°6 : la croix de la transversalité

La data gouvernance est un sujet transverse, un axe matriciel en plus et son animation souffre comme tous les sujets transverses d’être pris entre une volonté d’entreprise et les contraintes locales. Avec la difficulté de faire agir et de synchroniser sur des sujets data, des acteurs et des équipes qui ne se rencontrent pas toujours.

Les porteurs des initiatives de data gouvernance s’épuisent à convaincre et sont peu suivi localement. Et cela d’autant plus dans les organisation de taille importante avec des sites déportés ou des filiales. La conscience que ses données ont une portée plus large que son domaine d’action est difficile à faire évoluer. Être pro actif sur un sujet comme la gouvernance de données est rare voire inexistant.

Frein 7 : Combien cela coute ? Et combien de temps cela prend ?

Les deux questions arrivent vite dès qu’une initiative gouvernance des données arrive.

Et il est difficile de répondre à ces questions.

Combien de temps cela prend, la réponse est que la gouvernance des données n’est pas un projet, mais un effort continu ancré au cœur de l’activité. Les premiers résultats tangibles vont prendre du temps à être démontrés (d’où l’exercice complémentaire d’identifier les bonnes métriques pour prouver les résultats de la data gouvernance – faire le lien entre des indicateurs métier et des actions data).

Pour le coût, il existe plein de réponses, de modèles en termes de gains directs, de gains indirects, de couts évités (liés à la non qualité des données, à des pénalités évitées), de gains non mesurables (d’image par exemple), de valeur débloquée … mais arriver à poser des chiffres réalistes est difficile (pour cela voir l’expérience des projets IT avec le volet business case).

J’ai vu dans des comités de gouvernance suivre des indicateurs du type : nombre de familles de données couvertes, nombre de data owners, nombre de data products… Ce ne sont pas les bons indicateurs. Il faut des indicateurs métier … mais ce n’est pas facile de les lier à des choix ou des actions de gouvernance (comme une politique d’accès aux données : un exemple dans le monde de l’énergie, une métrique d’économie moyenne engendrée par la mise à disposition de données de consommation énergétique).

Illustration :

Source : https://www.ecojoko.com/ voir aussi son concurrent nrLINK – https://pro.myem.fr/nrlink-pros/

16) La gouvernance des données de référence a quelque chose en plus

Les données de référence ont quelque chose en plus.

Elles doivent tenir compte de qualités particulières (centralité, autorité, unicité, interopérabilité, stabilité…) que leur gouvernance doit prendre en compte.

J’ai beaucoup pratiqué ce sujet avant et après la publication d’un ouvrage sur les référentiels de données auquel j’ai eu la chance de participer – voir https://www.datassence.fr/referentiels-de-donnees/ ).

Voir aussi un bel exemple auquel j’ai participé dans le domaine de la santé, avec le référentiel FINESS des établissements de santé et sa gouvernance associée : https://www.datassence.fr/2023/12/11/finess-un-referentiel-de-donnees-de-plus-de-40-ans/ .

A l’échelle d’une organisation, les référentiels de données sont un des piliers de la gouvernance des données. Données de référence et gouvernance des données se soutiennent mutuellement. Une des premières actions de gouvernance est de les identifier, puis de définir et attribuer les rôles liés à leur gestion et enfin s’assurer que dans toute initiative-projet data, ils ont bien été pris en compte.

A titre d’exemple, j’ai participé à la mise en place de cela dans une organisation avec :

L’identification des référentiels dits stratégiques via une équipe Métier et IT,
La rédaction d’une note de politique de gestion des données de référence (incluant la gouvernance – sa définition et sa mise en place, ainsi que les règles d’accostage aux référentiels),
Un volet référentiels de données dans l’animation de la roadmap d’évolution / projets du S.I. (type schéma directeur), avec par projet au portefeuille, l’identification des projets référentiels en tant que tel et la bonne prise en compte des référentiels de données par l’ensemble des projets (roadmaps d’accostage),
Et enfin par projet, l’instruction d’une revue données référence à la définition du projet, au cours du projet jusqu’à son déploiement.

Attention, comme d’habitude le monde parfait n’existe pas. Pour certaines données de référence, il n’y a pas de système référentiel existant, pour d’autres données de références plusieurs systèmes référentiels se recouvrent voire sont en concurrence, ou encore un projet de construction d’un système référentiel vient d’être lancé et la transition doit être gérée.

L’exercice est naturellement évolutif.

En termes de gouvernance, il est parfois difficile de trouver le bon propriétaire ou le bon steward.

Et à cette échelle, l’implication au niveau COMEX est nécessaire. Dans ce cas, la Directrice de la Stratégie s’est impliquée, avec l’inscription des référentiels stratégique dans une note de politique dédiée et une co-diffusion pour application par le DSI et la Directrice de la Stratégie.

A noter de ne pas oublier les nomenclatures partagées qui sont partie intégrante du sujet des référentiels stratégiques (ce point est souvent négligé voire oublié). Avec une subtilité, les nomenclatures sont le reflet de choix politiques, de façons de classer, de catégoriser, de hiérarchiser. A ce titre, elles « cachent » un pouvoir, la gouvernance « mère », plus large, métier, d’entreprise et même d’état, rarement explicite mais sensible.

Illustration – exemple de vision globale d’identification de référentiels stratégiques

17) Quand les données non structurées sont à inclure dans la gouvernance des données

Un dernier sujet qui explose en termes de gouvernance data : le sujet des sources de données non structurées (documents, photo, vidéo, sons) en mesure de produire des données structurées à partir des nouvelles capacités d’Intelligence Artificielle.

Les organisations produisent beaucoup de documents, de vidéos, d’enregistrements – podcast par exemple, de mails, interagissent via des canaux multi modaux, le tout embarquant de fait de nombreuses données.

Ces données auparavant enfermées dans ces supports sont maintenant de plus en plus facilement interrogeables et en mesure d’être extraites (récupérer des données financières citées) ou calculées (exemple de l’analyse de sentiments).

La question de la gouvernance de ces sources / supports et des données contenus devient un enjeu.

Ces sources / supports ne sont pas nouveaux.

Les systèmes de GED, d’archivage existent depuis longtemps.

A une époque les systèmes de Knowledge Management ont tenté une percée en termes de gestion.

Mais la dimension données embarquées n’y est pas considérée (ou rarement).

Avec l’arrivée des nouveaux modèle d’IA, la question se pose à double titre :

Comment protéger ses données, traiter leur sensibilité, les aspects éthiques quand elles servent de support aux moteurs d’IA que l’organisation déploie (modèles LLM et RAG – cf. https://www.datassence.fr/2024/04/10/revue-data-du-mois-mars-2024/#_ftn2 utilisés par exemple dans un chat client, ou d’un système automatique de traitement des mails) ?
Comment maîtriser les données structurées embarquées dans les données non structurées et rendues facilement accessible via les moteurs d’IA (de concurrents, de hackers…) ?

Comment assurer la gouvernance des données embarquées dans ces supports (modèles IA, documents, enregistrements) ?

Vaste sujet… où l’IA va également intervenir en facilitant le classement de ces sources.

A suivre une recherche de retours d’expérience…

Conclusion : un outil pratique, la matrice d’alignement métier – data – IT

Au travers de ces expériences, je me suis construit une vision de la gouvernance … de bon sens : intégrée et non « à côté », top down et bottom up, collaborative, continue, par palier et où tout est question d’équilibre.

Matrice d’alignement et d’intégration de la data gouvernance dans l’architecture d’entreprise

Les données sont maintenant dans les fondations des organisations. Leur gouvernance ne peut plus être l’affaire d’une organisation data tour d’ivoire. L’ensemble de l’organisation doit être embarquée.

La matrice suivante est une synthèse de cette vision (déjà en partie présentée dans l’article : https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/#_ftnref4 ).

Cette matrice est un outil qui vise à s’assurer du bon alignement entre la gouvernance des données et ses moyens associés, avec le reste de l’entreprise.

Et d’éviter ainsi une démarche non intégrée, isolée ou trop éloignée des enjeux et du quotidien de chacun (métier, IT et spécialistes data).

Elle permet :

De positionner les points de gouvernance aux bons endroits (intégration et alignement attendus, au plus près des acteurs légitimes – dans l’action, experts),
De « ratisser » ces points,
De faire que l’ensemble des points de gouvernance forme un tout cohérent, ne soient pas isolés – non reliés (exemple clé – le cas du volet RH visant à embarquer tout le monde et des compétences à décliner, ou exemple plus léger d’un glossaire métier « en l’air » et qui finit au placard),
De réduire les frictions, les recouvrements avec les pratiques existantes.

Elle aborde le positionnement des points de gouvernance de façon descendante et ascendante :

Déclinaison de la stratégie, à la tactique – cadres-règles à appliquer, jusqu’à l’opérationnel (au quotidien, au sein des projets IT comme métier).
Remontée de l’opérationnel, des cas d’usage, des initiatives locales en réponse à un besoin, vers le tactique (partage avec d’autres domaines) puis le stratégique (promotion à l’échelle de l’entreprise).

Le tout sous forme de co-construction, avec des boucles de feedback, de l’agilité et de façon continue (la gouvernance des données est un processus dynamique dans un environnement dynamique).

Avec l’ultime rappel : des données sans contexte (décrit par des métadonnées) n’ont pas de sens et ne sont pas gouvernables.

17 thèmes c’est beaucoup pour un sujet pas forcément le plus facile.

Et ce n’est pas clôt.

Je vois trois autres thèmes qui pourraient être abordés :

Le lien, l’alignement entre gouvernance des données et la cybersécurité (a minima, il existe des experts sur le sujet – voir par exemple Sylvain Conchon – https://fr.linkedin.com/in/sylvain-conchon),
L’alignement de la data gouvernance s’applique aussi avec les politiques métier (a priori traduite dans les processus mais pas toujours – NB : il s’agit de documents précieux pour une analyse prospective de stratégie data – exemple vécu d’exploitation de politiques RH pour définir une stratégie data). Cela concerne également l’alignement avec des contrats d’échanges avec des partenaires extérieurs et plus particulièrement les « Data Sharing Agreements »,
L’inévitable apport de l’IA pour la gouvernance des données (un bot / copilote IA data gouvernance !?).

NB : cette compilation a été réalisée au fil de ma remémoration d’expériences, le résultat est plus long que je ne le pensais, les sujets se recoupent et c’est normal, avec le recul … une synthèse est possible. A suivre.

Et si vous êtes arrivés jusque-là … bravo !

Annexe 1 – Les cadres de références sur la data gouvernance

A cette vision, il faut y associer aussi les références connues sur lesquelles on peut s’appuyer :

Extrait :

Le framework proposé repose sur trois types de mécanismes : 1) mécanismes structuraux (instances de gouvernance, rôles), 2) mécanismes relationnels (synergie entre acteurs, data literacy), 3) mécanismes procéduraux (standards, règles, politiques, procédures de data management à respecter). Avec différents points de vue sur les données : 1) point de vue patrimonial, 2) point de vue décisionnel (au sens connaissance des données : métadonnées, linage, qualité), 3) point de vue organisationnel (gouvernance niveau projet, entre entités, externe).

Annexe 2 – Autres ressources – exemples dans des entreprises

– Data Governance Examples: How Top Companies Manage Their Data – https://medium.com/@kanerika/data-governance-examples-how-top-companies-manage-their-data-c56ac9ac8e12

– : Data Governance to Support Business Needs A Study with GKN Aerospace Engines –

https://odr.chalmers.se/server/api/core/bitstreams/15c96bb4-ee90-4871-ae65-e7f855fe7f92/content

Extrait

– GKN Aerospace Engines – « Data Governance to Support Business Needs – A Study with GKN Aerospace Engines https://odr.chalmers.se/server/api/core/bitstreams/15c96bb4-ee90-4871-ae65-e7f855fe7f92/content

– Ariane Groupe avec un bel exemple de gestion des cas d’usage en logique prototypage initial en mode task force (sur 3 semaines) avant de basculer en industrialisation (sur 3 mois). Avec un travail de cadrage initial reposant sur 5 piliers : 1- Les besoins fonctionnels et business, 2- Les sources de données, 3- L’architecture d’intégration, 4- La proposition de valeur, 5- Les coûts. Source : https://www.lemagit.fr/actualites/366593494/Les-secrets-dArianeGroup-pour-decoller-vers-le-Data-Centric

Retours d’expérience gouvernance des données