Pour partage, le support d’une intervention sur la gouvernance des données et le script associé.

Durée 1h avec les questions / réponses.

Dans le même esprit, à suivre la trame d’une intervention sur la stratégie de données.

Sommaire :,

1) Remerciement – introduction
2) Mon parcours
3) La bascule data
4) Je vais commencer par vous raconter quatre histoires où la gouvernance par sa présence ou son absence a joué un rôle centrale
5) Dans beaucoup d’organisations, la gouvernance est vue comme défensive, comme réponse à des crises, des pressions extérieures et on en reste là
6) Il y a un scénario que j’ai vécu n fois, dans n entreprises et même plusieurs fois dans une même entreprise
7) Dans une de mes missions, on m’a demandé de collecter les irritants data. Très vite, j’ai réalisé que je ne collectait pas une liste d’irritants… mais que je faisais une cartographie de fossés
8) Je n’aime pas la data « à côté »
9) Comment briser le plafond de verre : ma vue d’informaticien
10) Une gouvernance qui a émergé par co-construction à toutes les échelles
11) En 15 ans d’immersion data, j’ai souvent l’impression de revivre le même cycle, les mêmes défauts de gouvernance et je me suis demandé pourquoi ?
12) Bienvenue dans la matrice
13) Conclusion
Ressources

1) Remerciement – Introduction

Gouvernance des données en images.

Je veux vous faire un aveux

La gouvernance des données c’est bien le dernier sujet que j’aurais pensé aborder il y a encore quelques années.
Avec une image pas forcément attrayante : de comités, de bureaucratie, de lenteur, de directives hors sol…
Un sujet que je regardais poliment de loin, mais j’avais tort.

Je vais essayer de vous faire vivre ce que j’ai vécu et pourquoi j’avais tort.

2) Mon parcours

Informaticien.

J’ai couvert presque tous les métiers aussi bien côté DSI que côté métier :
MOE, MOA, développeur, business analyst, chef de projet, architecte, urbaniste, directeur de programme…

Avec une première période, les données, c’était simple :
Elles vivaient dans les processus,
Elles étaient vues comme un sous-produit,
On les utilisait sur place,
Les sujets data c’est sous gouvernance IT.

Et puis il y a 15 ans, tout a basculé.
Le Big Data est arrivé.
Les usages des données ont explosé.
Les données sont sur le devant de la scène.

C’est à ce moment-là que j’ai décidé de me spécialiser dans la data.

3) La bascule data

Depuis 2010, c’est une avalanche :
La data explose.
Dans les médias, dans les outils, dans les concepts, dans les architectures, dans les produits de la vie quotidienne.
On parle de data lake, de modern data stack, de data mesh, de data product.
Les data centers poussent comme des champignons.
Les capteurs sont partout.
La liste des solutions logicielles dédiées aux données est passé de quelques dizaines à plusieurs milliers de produits.

Aujourd’hui, les données touchent tout : nos métiers, nos usages, nos comportements, notre vie privée.
On baigne tous dedans.

De mon côté, j’ai plongé dans des projets :
big data, data lake, open data, schémas directeurs data , datalab, réglementaire, data mesh, IA…
Et en ce moment j’accompagne la refonte d’un S.I. dans une logique data centric.

Les données ne sont plus un sous-produit.
Elles sont un produit à part entière.
Elles créent de la valeur.
Elles créent du pouvoir.
Elles bousculent des business models.
Elles sont devenus un marché de plusieurs centaines de milliards de dollars avec des milliers de data broker, et des dizaines voire des centaines de millions de travailleurs de la donnée dans le monde.
Il existe des milliers de règlements sur les données dans tous les secteurs d’activité.

“Les données ne décrivent plus le monde.
Elles le transforment.”
Alors une question s’impose :
Comment les gouverner ?
On ne peut plus faire sans.
Le sujet de la gouvernance est sur le podium des préoccupations data des entreprises.
Pourtant les retours sont : c’est difficile…cela n’imprime pas.

Ma confrontation avec la gouvernance !

4) Je vais commencer par vous raconter quatre histoires où la gouvernance par sa présence ou son absence a joué un rôle central

La première histoire – un classique – Le crash test de la conférence de presse.
A l’époque je faisais partie du pool d’architecte data d’une Banque.
Cela se passe un samedi matin, le directeur de l’entité d’Asset Management présente ses résultats dans une conférence de presse.
A un moment donné un journaliste lève la main :
— “Vous annoncez 70 M€ de frais de gestion. Votre site affiche 25 M€. Expliquez-nous.”
Gêne. Le Directeur s’en tire par une pirouette.
Et le lundi matin, réunion d’urgence avec le Dir de la communication, le Dir. Financier qui ont invité le Dir. Commercial et le DSI qui a invité son cabinet d’architecte (j’étais là).
Reconstruction du lineage.
Verdict deux semaines après : aucun des deux chiffres n’était correct.
Pourquoi ?
Sources différentes.
Règles de filtrage différentes.
Versions différentes.
Agrégations différentes.
Conflits de vision, de définition.

“Sans gouvernance, une donnée est pernicieuse.” – « Sans gouvernance on ne sait pas quelle donnée on a entre les mains ».

La deuxième histoire – Ma mission de négociateur au sein GID du groupe d’intervention data – c’était notre surnom.
Pour valoriser les données il faut les libérer et les faire circuler,
Et pour cela il faut négocier avec les sources de données, les silos.
Et … ce n’est pas un long fleuve tranquille.
J’ai vécu :
Le DW finance qui ne veut pas partager ses données de peur d’en être dépossédé où que l’on ne sache pas correctement les interpréter.
Le projet du nouvel ERP “trop tendu” pour être intégré à la roadmap data.
Le marketing qui veut récolter un champ client en plus, mais la maintenance industrielle ne veut surtout pas toucher à son compte-rendu d’intervention client.
Des données commerciales erronées depuis 10 ans qu’il ne faut pas corriger et dont la publication pourrait mettre à mal une règle tacite de rémunération des commerciaux.

J’entends souvent dans les discours sur la gouvernance : “il faut casser les silos”.
Faux.
C’est même dangereux.
Certains silos sont effectivement toxiques et doivent tomber.
Mais beaucoup sont légitimes avec un savoir-faire local, une valeur contextuelle, des responsabilités assumées qu’il faut préserver.
“Un silo n’est pas un ennemi. C’est une frontière avec qu’il faut apprendre à négocier et c’est ce qu’on attend de la gouvernance.”

La troisième histoire – quand vos propres données se retournent contre vous
Le contexte : une entreprise industrielle X (je vais l’appeler comme cela dans la suite) transmet plein de données à ses clients, contractuellement mais aussi par bonne volonté des chargés de clientèles, des fonctions support, des commerciaux.
Sans contrôle.
Sans vision.
Avec une dispersion totale.
Un acteur tiers s’immisce dans la relation client, regroupe les données de différents clients et leur propose :
“Nous allons négocier à votre place vos contrats avec l’entreprise X.
Nous allons comparer vos couts, les optimiser… et prendre la main.” : par exemple nous allons pouvoir inverser les décisions de maintenance – passer d’une maintenance contrôlée par l’entreprise X à une maintenance contrôlée par vous les clients.
Conséquence : la politique industrielle de l’entreprise X est menacée, son business model, son organisation sont remis en cause.

Heureusement, en urgence, une politique de publication des données a été définie et mise en place. Le robinet data a été fermé juste à temps.
Avec une prise de conscience du rôle des données qui a amené l’entreprise à édifier une charte des données gagnante gagnante avec ses clients.

La quatrième histoire – Plongeons dans le code de la santé pour concevoir l’architecture d’un système
J’ai participé au cadrage de la refonte d’un référentiel socle du domaine de la santé.

De fait, on a intégré la gouvernance dès la conception du système cible (respect du code de la santé, des décrets d’application, des instructions ministérielles).
Jusqu’à amener à publier un nouveau décret pour tenir compte des choix de conception.

La gouvernance a cadré l’architecture.
Et l’architecture a fait évoluer la gouvernance.
Les deux ont avancé ensemble.

Pour terminer je ne peux pas m’empêcher de vous partager une actualité récente, un industriel vient de me poser une question de gouvernance qui aurait pu passer pour de la science-fiction il y a encore peu de temps. La question :
Quelle gouvernance des données et qui est propriétaire des données dans le cadre d’une offre de service autour de jumeaux numériques et d’IA générative.
Si je transpose de façon simpliste cela au monde de l’assurance, ça serait l’équivalent de disposer d’un jumeau numérique de tout assuré, interrogeable via une IA générative et support au pilotage de services d’assurances à partir d’agents. Quelle gouvernance des données … vous avez quatre heures ?

Je vous propose maintenant de prendre un peu de recul.

5) Dans beaucoup d’organisations, la gouvernance est vue comme défensive, comme réponse à des crises, des pressions extérieures et on en reste là

Mais il y a une autre façon de la voir, elle peut être proactive, créatrice de valeur.

La gouvernance défensive, c’est simple :
Les règles viennent de l’extérieur.
On traduit.
On applique.
On coche les cases.
On réagit.
On subit.
On fait le “bon soldat”.
Constat “La gouvernance imposée, ça ne motive personne — ça ne mobilise pas.”

La gouvernance offensive, c’est tout l’inverse :
Les choix viennent de l’intérieur.
On passe en mode action.
On touche à l’identité de l’entreprise.
On fait évoluer les métiers.
On crée de nouveaux services.
On construit du pouvoir.
“La gouvernance offensive, ce n’est pas se protéger des données — c’est créer de la valeur avec elles. C’est penser data et là c’est passionnant.”

6) Il y a un scénario que j’ai vécu n fois, dans n entreprises et même plusieurs fois dans une même entreprise. Je l’appelle : le scénario rouleau compresseur

Tout commence par le même schéma.
Tout le monde parle de données : les concurrents, les fournisseurs, les cabinets de conseil…
Et là, branle-bas de combat : « Il faut faire quelque chose ! »
Alors on lance la grande mission data.
On commence par une « évaluation de maturité data ».
On réunit les foules.
On lance des incantations : « Soyez data ! »
On crée des rôles data, une politique data, une équipe data centrale…
Et bien sûr : le grand projet.
La data platform d’entreprise.
La cathédrale.

J’ai subis des évaluation de maturité data…j’ai trouvé cela dénigrant et hors sol.
J’ai entendu “il faut gagner 2 niveaux de maturité ! »
On commence par-là alors qu’on n’a même pas défini la stratégie data.
C’est comme fixer la hauteur d’un escalier avant de savoir où il va.
La maturité est un effet et pas un objectif.

Pendant ce temps, le rouleau compresseur, lui, avance.
Et en avançant, il laisse de côté voire écrase ce qui existait déjà.
Des rôles data non officiel, des équipes métier dédiées au pilotage de domaines métier, des responsables BI, des personnes sans qui les processus data ne peuvent pas fonctionner
Des personnes, qui voient arriver une équipe centrale « sponsorisée top management », parfois un Chief Data Officer flambant neuf…
Sans qu’on leur dise où est leur place, ce qu’on attend d’eux, et surtout : ce qu’on fait de leurs pratiques.

Et puis le rouleau compresseur fixe LE chemin.
Un seul, uniforme.
Direction la plateforme data – taille unique.
Et évidemment dans laquelle on va trouver la fameuse vue unifiée des données d’entreprise.
La vue magique qui va tout résoudre mais qui en réalité est un mythe. Par exemple ce n’est pas anormal d’avoir plusieurs définition différentes de ce qu’est un client.

La shadow data, excel sont à éliminer.
A remplacer par une offre self data proposée par la data plateforme alors qu’excel est bien le seul outil de self data qui ait fait ses preuves.

Résultat ?
On crée des tensions.
L’équipe centrale ne peut pas répondre à toutes les demandes, ignore les contextes locaux et ne peut pas comprendre toutes les données.
Pour moi la gouvernance des données ce n’est pas décréter une « entreprise data unique »

7) Dans une de mes missions, on m’a demandé de collecter les irritants data. Très vite, j’ai réalisé que je ne collectait pas une liste d’irritants… mais que je faisais une cartographie de fossés

Le premier fossé est frustrant, entre une ambition data incarnée par une belle vision, une organisation et des feuilles de routes.

Et des acteurs terrain qui ne voient pas toujours le lien avec leur quotidien et qui vivent des problèmes de données sans cesse reproduit (le mythe de Sisyphe toujours faire et refaire)
Un manager qui tous les matins avant l’arrivée de son équipe consolide sur des post-it toutes les données utiles à sa journée, collectées dans une dizaine de systèmes différents à croiser avec un tas d’excels de sa hiérarchie.
Des pipelines de données qui obligent systématiquement en fin de mois à arriver à 6h du matin pour s’assurer de leur bon fonctionnement.

Deuxième fossé le classique : entre le métier et la DSI.
Côté DSI : « On va faire un super conteneur – un data lake et l’alimenter en définissant des contrats de données ! »
Mais sans les métiers
Une image vécue, quand j’ai récupéré la documentation du data lake : 90 % de la documentation était dédiée à son architecture … brillante, et 10 % à son contenu, les données. J’aurais préféré l’inverse.

Côté métier, c’est le mode survie.
Des crises data.
Les classiques :
une crise réglementaire déclenchées par l’arrivée imprévue d’un audit,
des crises liée à des défauts de qualité de données
mais aussi des crises structurelles à l’exemple d’un référentiel organisation dont l’abandon faute de gouvernance a couté plusieurs millions d’euros.

Du shadow data partout.
On s’échange des données par tous les moyens — parfois j’avais l’impression d’observer le dark data de l’entreprise.
On recrute des profils data dans les équipes métiers… et on réinvente la roue voire des systèmes complets de données sur des PC scientifiques détournés.
Avec des exploits, des frustrations, des échecs et des dangers faute de gouvernance.

Et toujours des tensions : Une initiative qualité de données financée par la DSI mais bloquée par la Direction commerciale qui ne souhaitait pas que ses collaborateurs en charge de l’intégration des données clients soient distraits.

La bonne gouvernance, c’est celle qui reconnecte les mondes.
Celle qui aligne les initiatives, élimine les frictions, met en valeur le travail sur les données
Celle qui part du terrain.
Celle qui va jusqu’au dernier kilomètre

Souvent pour régler cela, la première décision de gouvernance est de créer une filière data avec un CDO, une équipe data centrale, la mise en place de rôles data (des data owner) et de l’outillage comme un catalogue de données et la fameuse data platform d’entreprise.
Comme architecte data j’ai fait partie de ce type de dispositif.
Avec des interlocuteurs métiers et IT en face de moi … qui soupiraient, encore un truc organisationnel en plus.

J’ai aimé au début et moins au bout d’un moment

8) Je n’aime pas la data « à côté »

Déjà que le dialogue métier–IT est compliqué… quand on ajoute un troisième acteur, la filière data, ça devient vite ingérable.
Surtout quand cette filière n’a ni vraiment la main sur les systèmes de données, ni vraiment la main sur les données en contexte métiers.

La filière data se retrouve dans une position impossible :
ni assez proche des métiers, ni assez proche de l’IT.
Alors elle s’épuise.
Elle court après ceux qui peuvent faire. Elle porte des préconisations à valider par N comités (métier et IT) que d’autres devront appliquer…
Elle finit par porter seule la gouvernance.
Pire : elle est un bon alibi pour se déresponsabiliser.
Côté IT comme côté métier, on se dit : « c’est maintenant à l’équipe data de gérer ça ».

Elle est challengée par les autres gouvernance (IT, sécurité), on lui reproche les problèmes de data management, on lui demande de justifier son ROI alors que la valorisation finale des données ne passe pas par elle.

J’ai vu des CDO partir en burn-out, des data owners brasser du vide, des data custodians perçus comme des intrus dans les comités d’architecture.
On réinvente des rôles qui existaient déjà, on crée de la friction, on perd du temps.

Le “à côté”, c’est le catalogue de données mis à jour à la main, toujours en retard sur la réalité, incapable de suivre le rythme d’évolution des données aussi bien côté métier qu’IT (je connais une grande banque qui y a renoncé et préférer mettre en place un annuaire des données – c’est-à-dire qui connait telles données).

Le “à côté”, ce sont des projets de qualité de données curatifs au lieu d’agir sur la source (toujours le mythe de Sysiphe).
Le pire que j’ai vu, une gouvernance confiée comme service managé à un prestataire (un cabinet de conseil)… ce qui n’a aucun sens.

La réalité, c’est que la data ne doit pas être à côté.
Elle doit être au cœur des systèmes, des processus métier, des décisions.
Et pour y arriver, il faut résoudre le fameux problème du dernier kilomètre.
Celui qui demande de briser un plafond de verre organisationnel mais aussi technique.
Et comme tout bon informaticien, on va chercher la solution dans la technique, dans le code.

9) Comment briser le plafond de verre : ma vue d’informaticien

Aujourd’hui, les données sont devenues de vrais produits, avec un cycle de vie.
Si on veut les gouverner, il faut les connaître : leur origine, leurs règles, leurs défauts, leurs relations, leurs usages.
Une donnée sans tout ce contexte, n’a pas de sens.
Et comme les données vivent au cœur des systèmes, leur gouvernance doit vivre au cœur du SI.
Pas à côté.
Pas dans un catalogue jamais à jour.
Pas uniquement dans une plateforme centrale qui ne voit que X % du paysage data.

La voie, c’est la gouvernance by design :
intégrée nativement dans l’architecture, le code, les services, les IHM.
Et cela passe par des métadonnées actives qui représentent les définitions des données, leurs traces, leur niveau de qualité, leur sensibilité réglementaire, les droits associés, etc
J’ai vu une équipe DEV intégrer cela directement dans le code en faisant appel à ODRL – Open Digital Rights Language – pour les droits et Great Expectations pour la qualité, utiliser l’Open Data Product Specification ou encore tester la pseudo colonne _metadata de Databricks.
On passe d’une logique documentaire à une logique d’action.

“Si la gouvernance n’est pas dans le code, elle n’existe pas.”

Les métadonnées deviennent des fondations.
Qui parlent à ceux qui modélisent, qui parlent aux architectes, qui parlent à l’infrastructure, qui parlent aux métiers.

Mais ce n’est pas facile, le legacy n’a pas été conçu pour cela. On parle quand même de construire un système de système – un métasystème … à quel cout ?
Mais le marché avance : Databricks, Snowflake, Denodo, ServiceNow…intègrent nativement de plus en plus de fonctions de gouvernance des données et s’intéressent à comment moderniser l’existant (je viens de voir passer une liste d’offres dans ce sens par l’éditeur Dremio).

Et l’IA arrive en mode bulldozer en imposant des données contextualisées, tracées, disponibles en temps réel. Un rappel, l’IA c’est 10% d’ingénierie de haute volée mathématique avec du bricolage et 90% de transpiration sur la production de données.

La gouvernance à base de comités, de powerpoint et de fichiers Excel ne peut plus suivre.
C’est pour ça que l’on parle de gouvernance a priori et non a posteriori, à la source, injectée dans les pipelines, automatisée dès le départ… pour atteindre le dernier km.

Attention comme d’habitude la technologie ne fait pas tout …sans stratégie sur les métadonnées le chaos est vite arrivé. Et on ne peut pas tout couvrir. La gouvernance doit faire des choix.

Par exemple axer les efforts sur la consommation des données avec leurs contextes (les métadonnées). Mettre à disposition une infrastructure mutualisée avec une offre de gouvernance basée sur les métadonnées.

Et ce n’est pas de la théorie.
J’ai eu la chance d’explorer les entrailles d’une data platform où tout est tracé, étiqueté, piloté par la gouvernance via des métadonnées et le tout à la main des métiers.
Et le résultat est bluffant en termes d’efficacité, de ROI, de confiance dans les données.

A ce stade de ma présentation, j’ai émis des critiques :
S’arrêter à la gouvernance défensive.
Le mode rouleau compresseur.
Les fossés.
La data à côté.

J’ai aussi dévoilé des challenges :
La gouvernance offensive.
Comblé les fossés et atteindre le dernier km.
La gouvernance by design et dans les métadonnées.

Je voudrais maintenant vous parler de ma meilleure expérience de gouvernance des données.

10) Une gouvernance qui a émergé par co-construction à toutes les échelles

Une entreprise de 1000 personnes.
Culture digitale et cœur de métier du processing data.
Deux principes forts :

Ceux qui vont appliquer dans l’entreprise les règles de gouvernance … contribuent à les définir et les signent (direction, responsable de processus, développeur, data steward).
Le tout arbitré au travers de cas d’usage qui vont fédérer les acteurs métier et IT dans l’exercice de définition de la gouvernance. La question de la gouvernance arrive dès l’analyse des cas d’usage. Cas d’usage que l’on va collecter et piloter au travers d’un portefeuille pour produire une feuille de route data.

Des groupes de travail ont été constitué à toutes les échelles, horizontaux, verticaux y compris avec des membres du COMEX.
Des DEV avec plein d’idées, comme de rendre visible la gouvernance dans les tableaux de bord par l’affichage des sources, des règles, des définitions des données, du lineage, de la sensibilité des données dans le tableau de bord. Mais aussi des obstacles à franchir comme l’interopérabilité des métadonnées (vaste sujet).

Un effet boule de neige par embarquement de plus en plus de personnes par rebond sans frontière fonctionnelle ou organisationnelle.
Exemple les responsables techniques en charge des pipelines de données ont pu mobiliser toutes les personnes à impliquer pour une meilleure qualité des données en amont – a minima des données mieux connues, négocier avec les sources, des contrats de données, et des produits de données correctement étiquetés.

Le résultat : on a définis des dizaines de points de gouvernance avec les moyens humain et technique associés –
Le responsable de la politique sur les données personnelles supervise les résultats de la déclinaison de sa politique dans le code versus tout un travail d’enquête, de contrôle, a posteriori,
Le service d’observabilité des données est configuré pour alerter les bonnes personnes.

L’autre atout de la démarche, elle nous a permis un pilotage à l’échelle – à partir de la vue d’ensemble des cas d’usage et des points de gouvernance :

Quelle cohérence et mutualisation possible?
Exemple : limiter l’éparpillement des règles sur les données et éviter le fameux effet domino non maîtrisé au moindre changement.
A-t-on des cas d’usage avec les bonnes priorités qui parlent à tous les niveaux de l’organisation (du local, au COMEX en passant par le middle management), des cas d’usage intégrés aux grands programmes de transformation, qui tirent de la valeur de la coopération inter-domaines, jusqu’à l’écosystèmes de nos partenaires ?

La gouvernance devient plus intégrée, transparente, vivante, collective et pas un diktat descendant.
Elle est définie en fonction d’où on veut aller et non posée à l’avance.
La co-création est essentielle. Une vision hiérarchique, centralisée ne peut pas avoir conscience de toutes les possibilités data qui s’offrent au sein de l’entreprise.

11) En 15 ans d’immersion data, j’ai souvent l’impression de revivre le même cycle, les mêmes défauts de gouvernance et je me suis demandé pourquoi ?

On lance une dynamique.
Puis l’énergie retombe.
Les data owners s’envolent au premier prétexte de changement.
Les comités se vident.
Les CDO défilent.
Et les cadres de gouvernance de données…
finissent dans des placards.

La gouvernance n’est pas résiliente
lorsqu’elle reste isolée,
à côté du SI,
à côté des métiers,
à côté des autres gouvernances.

Le rouleau compresseur,
les fossés,
la data “à côté”,
le dernier kilomètre non atteint…
Ce sont les symptômes d’une gouvernance qui n’est pas fusionnée avec le reste de l’entreprise.

“La gouvernance des données, ce n’est pas un projet qu’on lance et qui va tout résoudre. C’est une attitude continue.”

De toutes ces expériences et des échanges avec d’autres architectes data ait né un outil simple,
que j’utilise comme fil de pensée dans chacune de mes missions.

12) Bienvenue dans la matrice

Comment cela marche ?

Il existe déjà des formes de gouvernance dans l’entreprise : la gouvernance d’entreprise en tant que tel et la gouvernance IT (avec COBIT par exemple).
La data comme entité à la fois numérique et métier est donc fortement dépendante de ces deux gouvernances.

L’ambition est simple comment aligner tout cela verticalement et horizontalement, à tous les niveaux de la stratégie à l’opérationnel et réciproquement en passant par la construction. Commet faire que la gouvernance ne soit pas quelque chose d’isolé, « à côté ».

La matrice se lit de la façon suivante de chaque côté la gouvernance d’entreprise et la gouvernance IT et au milieu la gouvernance des données alignée voire fusionnée.

Exemple trivial, la stratégie data doit être alignée avec la stratégie d’entreprise, déclinée dans un schéma directeur data, lui-même aligné avec le schéma directeur IT.

On va chercher à enrichir des supports de gouvernances existants – comme :
• Un volet data dans les dossiers projets, d’urbanisation S.I.et des revues des processus métier,
• Des rôles data décrits dans les fiches de poste RH,
• Des moyens de lineage, d’observabilité des données intégrés nativement dans les infrastructures IT,

J’entends souvent le débat entre gouvernance centralisée ou décentralisée.
Cela n’a pas de sens, les points de gouvernance doivent être intégrés parfois dans une logique centralisée parfois dans une logique décentralisée, dans des domaines métier, auprès du bon expert voire dans des silos.
On peut avoir une gouvernance centralisée de publication de certaines données
et des gouvernances décentralisées sur la qualité de ces mêmes données.
Ce qui compte c’est l’alignement, l’intégration.

J’en arrive à ma conclusion.

13) Conclusion

Il n’existe pas de modèle de gouvernance prêt à l’emploi.
Il n’existe pas de cadre magique.
La gouvernance des données est une performance collective.
La meilleure gouvernance, c’est celle qu’on ne remarque même plus.
Elle reste un moyen et non une finalité.
Moyen au service de « savoir penser data »

Le jour où chacun, dans son métier, sait penser data
-> produire et analyser des données
→ enrichir un processus à partir du cycle de vie de ses données,
→ utiliser le pouvoir des données.
→ comprendre les limites des données
→ ne pas les gâcher.
Le tout dirigé par une bonne gouvernance.
Alors c’est gagné.

J’espère vous avoir convaincu que la gouvernance des données nous concerne tous, DEV, chef de projet, manager, MOA, architecte, exploitant.

Et si je dois vous laisser avec une seule idée :
“Chacun de nous dans son métier peut devenir un maître des données.”

Merci.