Il y a quelques mois, j’ai travaillé pour une grande entreprise sur la formalisation des caractéristiques du catalogue de données idéal. « Social et orienté vers ses utilisateurs » sont ressorties comme les caractéristiques essentielles d’un catalogue efficace en 2026… ou 2027.
Un catalogue social, c’est-à-dire conçu comme tous les outils que nous utilisons au quotidien, qui favorisent l’interaction, la création de contenu par l’utilisateur, la simplicité d’utilisation, et l’intégration aux applications existantes. Mais surtout conçu pour ceux qui l’utiliseront et non pour ceux qui le mettront en service. Un catalogue entièrement pensé en faveur de l’expérience utilisateur.
Social : au croisement de Google Maps, LinkedIn et Tinder
Pensez à votre journée, aux interactions que vous menez avec l’information, à titre personnel. Et si vous n’y croyez pas, regardez ceux qui nous remplaceront dans quelques années, les fameux millénaux. Commander un Uber et lui donner une note, réserver un Airbnb pour le week-end et laisser un commentaire, sélectionner un restaurant sur Google Maps et lui attribuer des étoiles en publiant des photos, laisser un message à un collègue sur LinkedIn pour sa nomination, glisser vers la droite ou vers la gauche les profils qui apparaissent sur votre fil Tinder… et la litanie pourrait continuer longtemps. Notre vie numérique est devenue sociale. Cela a pris vingt ans, mais ces interactions sont maintenant au cœur de notre vie quotidienne.
Et une fois arrivé au bureau, après avoir allumé votre PC, la consultation de votre catalogue de données ressemble à un vieux Minitel : une dizaine d’onglets, des dizaines de champs, et presque aucune interaction. Et vous vous demandez encore pourquoi vos utilisateurs ne l’adoptent pas !
Demain, votre catalogue de données, si vous souhaitez qu’il soit utilisé, devra :
- Permettre de noter chaque donnée et de consulter les notes attribuées par les autres utilisateurs ; des notes et de commentaires sur l’expérience des autres : qualité, conformité, fréquence de mise à jour, intérêt…
- Dialoguer avec le référent de chaque donnée, et avec ses autres utilisateurs, au travers d’un « chat » propre à chaque donnée.
- Signifier votre intérêt pour cette donnée par un simple « swipe » comme dans Tinder. Nous verrons si vous « matchez » avec le data owner !
Le catalogue de données de demain sera social ou… ne sera toujours pas utilisé par les métiers ! Éditeurs de logiciels, à vous de faire en sorte qu’il soit l’application que tout data worker ouvre chaque matin et garde toute la journée sur un coin de son bureau.
Choisi pour ceux qui l’utilisent, pas pour ceux qui le construisent
Récemment, une grande organisation me contait son processus de choix d’un catalogue de données centralisé. Processus piloté par la direction informatique (ce qui est compréhensible), mais qui semble oublier ou minimiser les perceptions de ses futurs utilisateurs.
Un catalogue de données est en effet destiné à être utilisé ! Plus les utilisateurs métiers prendront l’habitude de le consulter pour y rechercher l’information dont ils ont besoin, plus le succès sera au rendez-vous. Même si le projet est mené par la direction informatique, ce n’est pas la satisfaction des utilisateurs-informaticiens qui en sera l’indicateur principal, mais celle des utilisateurs métiers. Dans mon exemple, la direction informatique compare plusieurs solutions et sa préférence va à un outil technique, un catalogue de données en open source, mais dont l’interface utilisateur est loin d’être intuitive pour des non-informaticiens. Les départements métier, également consultés, ont eu choisi un catalogue simple, efficace, à l’interface utilisateur beaucoup plus accessible. Qui va l’emporter ? Je crains de connaître le vainqueur par avance… ainsi que la suite de l’histoire lorsqu’une année après, on reprochera au catalogue, et au responsable de la gouvernance, de ne pas être entré dans les habitudes des utilisateurs métier.
Mon conseil, comparez les solutions, établissez des impératifs techniques à respecter, mais in fine, laissez ceux qui l’utiliseront au quotidien établir leur préférence. L’équipe de mise en place passera quelques mois à l’installer et le paramétrer ? Des centaines d’utilisateurs passeront des années à le consulter ! Devinez qui devrait choisir l’interface utilisateur qui lui plait le plus…
Deux critères clefs pour eux :
- Une interface de mise à jour simple : si vous souhaitez que l’utilisateur métier mette à jour les métadonnées dont il est le référent, il faut que cette mise à jour soit ludique !
- Proposez une recherche en langage naturel comme « quelle donnée est disponible pour évaluer le chiffre d’affaires par client ? ». Vous voulez mettre de l’IA ? C’est ici qu’elle se justifie
Ni centralisé, ni décentralisé, mais fédéré.
Depuis longtemps, le catalogue des métadonnées est pensé centralisé. Est-ce la bonne méthode ? S’il est si compliqué d’en faire adopter l’usage par les utilisateurs métier, c’est peut-être qu’ils s’en sentent éloignés ; qu’ils le perçoivent comme un outil de plus géré par la direction, plutôt que comme un outil destiné à leur faciliter l’accès aux données.
Par ailleurs, est-il logique que les métadonnées soient centralisées, alors que les données sont de plus en plus gérées dans les départements métier ? Les métadonnées ne devraient-elles pas rester au plus proche des données ?
Mais alors, si les métadonnées sont décentralisées, comment s’assurer que les différents métiers les gèrent de manière cohérente, dans un objectif de partage à travers l’ensemble de l’organisation ? Pour cela il ne faut pas passer de la centralisation à la décentralisation, mais à la fédéralisation : des métadonnées décentralisées, mais qui respectent une gouvernance centralisée. Comme dans un État fédéral, certaines compétences sont déléguées aux métiers, d’autres relèvent de décisions centralisées (prises par exemple par le comité de gouvernance des données).
Pour creuser cette idée de maille de métadonnées, lisez ce qu’a publié Ole Olesen-Bagneux sur le thème du Meta Grid : https://olesenbagneux.medium.com/the-meta-grid-is-the-third-wave-of-data-decentralization-b18827711cec et son livre Fundamentals of metadata management (https://www.actian.com/fr/lp/fundamentals-of-metadata-management-ebook/.
Interopéré par des contrats de données
Aimez-vous faire plusieurs fois la même chose ? Non, et c’est normal. Alors, pourquoi ne pas essayer de profiter d’un travail pour en réaliser plusieurs ?
Vous réalisez des interfaces entre applications, entre utilisateurs de données. Ces interfaces incluent un schéma de données. Vous pourriez utiliser cette description d’interface pour alimenter partiellement, mais automatiquement votre catalogue de données. C’est toujours cela de pris, et cela avance le travail du référent données.
Pour cela, vous devez formaliser vos contrats d’interface, en utilisant des contrats de données (data contracts), et vous avez de la chance. Jean-Georges Perrin et l’équipe de volontaires de Bitol (membre de la fondation Linux) ont travaillé pour vous. Ils ont conçu ODCS (Open Data Contract Standard) qui permet l’interopérabilité entre les outils qui y adhérent, grâce à un standard open source. En l’adoptant, vous disposerez de contrats de données qui pourront alimenter un ETL, mais aussi votre catalogue de métadonnées, ou encore l’outil d’observabilité du data steward.
I had a dream…
Alors non, malheureusement, ce catalogue social, compatible ODCS/OPDS, et fédéralisé des informations n’existe pas encore ! Mais ses bases sont claires. Visionnaire, certainement. Réaliste, pas encore ? Mais face aux nombreuses difficultés liées à l’implémentation des catalogues existants, il faut un « reset ». Je rêve d’un catalogue imaginé comme un produit Apple, que l’on soit fier de montrer, et non comme un produit Microsoft où il faut aller dans le menu Démarrer pour Éteindre…
Pour que l’alchimie fonctionne, il faudrait que les utilisateurs manifestent de l’intérêt pour un catalogue conçu en fonction de leurs besoins ; que les informaticiens conçoivent qu’un catalogue de données est destiné à être utilisé et pas simplement construit ; et que les responsables de la gouvernance mettent en avant l’indicateur du taux d’usage et non de la complétude théorique. Quel éditeur est prêt à relever le défi ?
Si vous voulez en savoir plus et expérimenter tout cela, participez aux formations sur la gouvernance des données que je donne tout au long de l’année.
Un catalogue social, c’est-à-dire conçu comme tous les outils que nous utilisons au quotidien, qui favorisent l’interaction, la création de contenu par l’utilisateur, la simplicité d’utilisation, et l’intégration aux applications existantes. Mais surtout conçu pour ceux qui l’utiliseront et non pour ceux qui le mettront en service. Un catalogue entièrement pensé en faveur de l’expérience utilisateur.
Social : au croisement de Google Maps, LinkedIn et Tinder
Pensez à votre journée, aux interactions que vous menez avec l’information, à titre personnel. Et si vous n’y croyez pas, regardez ceux qui nous remplaceront dans quelques années, les fameux millénaux. Commander un Uber et lui donner une note, réserver un Airbnb pour le week-end et laisser un commentaire, sélectionner un restaurant sur Google Maps et lui attribuer des étoiles en publiant des photos, laisser un message à un collègue sur LinkedIn pour sa nomination, glisser vers la droite ou vers la gauche les profils qui apparaissent sur votre fil Tinder… et la litanie pourrait continuer longtemps. Notre vie numérique est devenue sociale. Cela a pris vingt ans, mais ces interactions sont maintenant au cœur de notre vie quotidienne.
Et une fois arrivé au bureau, après avoir allumé votre PC, la consultation de votre catalogue de données ressemble à un vieux Minitel : une dizaine d’onglets, des dizaines de champs, et presque aucune interaction. Et vous vous demandez encore pourquoi vos utilisateurs ne l’adoptent pas !
Demain, votre catalogue de données, si vous souhaitez qu’il soit utilisé, devra :
- Permettre de noter chaque donnée et de consulter les notes attribuées par les autres utilisateurs ; des notes et de commentaires sur l’expérience des autres : qualité, conformité, fréquence de mise à jour, intérêt…
- Dialoguer avec le référent de chaque donnée, et avec ses autres utilisateurs, au travers d’un « chat » propre à chaque donnée.
- Signifier votre intérêt pour cette donnée par un simple « swipe » comme dans Tinder. Nous verrons si vous « matchez » avec le data owner !
Le catalogue de données de demain sera social ou… ne sera toujours pas utilisé par les métiers ! Éditeurs de logiciels, à vous de faire en sorte qu’il soit l’application que tout data worker ouvre chaque matin et garde toute la journée sur un coin de son bureau.
Choisi pour ceux qui l’utilisent, pas pour ceux qui le construisent
Récemment, une grande organisation me contait son processus de choix d’un catalogue de données centralisé. Processus piloté par la direction informatique (ce qui est compréhensible), mais qui semble oublier ou minimiser les perceptions de ses futurs utilisateurs.
Un catalogue de données est en effet destiné à être utilisé ! Plus les utilisateurs métiers prendront l’habitude de le consulter pour y rechercher l’information dont ils ont besoin, plus le succès sera au rendez-vous. Même si le projet est mené par la direction informatique, ce n’est pas la satisfaction des utilisateurs-informaticiens qui en sera l’indicateur principal, mais celle des utilisateurs métiers. Dans mon exemple, la direction informatique compare plusieurs solutions et sa préférence va à un outil technique, un catalogue de données en open source, mais dont l’interface utilisateur est loin d’être intuitive pour des non-informaticiens. Les départements métier, également consultés, ont eu choisi un catalogue simple, efficace, à l’interface utilisateur beaucoup plus accessible. Qui va l’emporter ? Je crains de connaître le vainqueur par avance… ainsi que la suite de l’histoire lorsqu’une année après, on reprochera au catalogue, et au responsable de la gouvernance, de ne pas être entré dans les habitudes des utilisateurs métier.
Mon conseil, comparez les solutions, établissez des impératifs techniques à respecter, mais in fine, laissez ceux qui l’utiliseront au quotidien établir leur préférence. L’équipe de mise en place passera quelques mois à l’installer et le paramétrer ? Des centaines d’utilisateurs passeront des années à le consulter ! Devinez qui devrait choisir l’interface utilisateur qui lui plait le plus…
Deux critères clefs pour eux :
- Une interface de mise à jour simple : si vous souhaitez que l’utilisateur métier mette à jour les métadonnées dont il est le référent, il faut que cette mise à jour soit ludique !
- Proposez une recherche en langage naturel comme « quelle donnée est disponible pour évaluer le chiffre d’affaires par client ? ». Vous voulez mettre de l’IA ? C’est ici qu’elle se justifie
Ni centralisé, ni décentralisé, mais fédéré.
Depuis longtemps, le catalogue des métadonnées est pensé centralisé. Est-ce la bonne méthode ? S’il est si compliqué d’en faire adopter l’usage par les utilisateurs métier, c’est peut-être qu’ils s’en sentent éloignés ; qu’ils le perçoivent comme un outil de plus géré par la direction, plutôt que comme un outil destiné à leur faciliter l’accès aux données.
Par ailleurs, est-il logique que les métadonnées soient centralisées, alors que les données sont de plus en plus gérées dans les départements métier ? Les métadonnées ne devraient-elles pas rester au plus proche des données ?
Mais alors, si les métadonnées sont décentralisées, comment s’assurer que les différents métiers les gèrent de manière cohérente, dans un objectif de partage à travers l’ensemble de l’organisation ? Pour cela il ne faut pas passer de la centralisation à la décentralisation, mais à la fédéralisation : des métadonnées décentralisées, mais qui respectent une gouvernance centralisée. Comme dans un État fédéral, certaines compétences sont déléguées aux métiers, d’autres relèvent de décisions centralisées (prises par exemple par le comité de gouvernance des données).
Pour creuser cette idée de maille de métadonnées, lisez ce qu’a publié Ole Olesen-Bagneux sur le thème du Meta Grid : https://olesenbagneux.medium.com/the-meta-grid-is-the-third-wave-of-data-decentralization-b18827711cec et son livre Fundamentals of metadata management (https://www.actian.com/fr/lp/fundamentals-of-metadata-management-ebook/.
Interopéré par des contrats de données
Aimez-vous faire plusieurs fois la même chose ? Non, et c’est normal. Alors, pourquoi ne pas essayer de profiter d’un travail pour en réaliser plusieurs ?
Vous réalisez des interfaces entre applications, entre utilisateurs de données. Ces interfaces incluent un schéma de données. Vous pourriez utiliser cette description d’interface pour alimenter partiellement, mais automatiquement votre catalogue de données. C’est toujours cela de pris, et cela avance le travail du référent données.
Pour cela, vous devez formaliser vos contrats d’interface, en utilisant des contrats de données (data contracts), et vous avez de la chance. Jean-Georges Perrin et l’équipe de volontaires de Bitol (membre de la fondation Linux) ont travaillé pour vous. Ils ont conçu ODCS (Open Data Contract Standard) qui permet l’interopérabilité entre les outils qui y adhérent, grâce à un standard open source. En l’adoptant, vous disposerez de contrats de données qui pourront alimenter un ETL, mais aussi votre catalogue de métadonnées, ou encore l’outil d’observabilité du data steward.
I had a dream…
Alors non, malheureusement, ce catalogue social, compatible ODCS/OPDS, et fédéralisé des informations n’existe pas encore ! Mais ses bases sont claires. Visionnaire, certainement. Réaliste, pas encore ? Mais face aux nombreuses difficultés liées à l’implémentation des catalogues existants, il faut un « reset ». Je rêve d’un catalogue imaginé comme un produit Apple, que l’on soit fier de montrer, et non comme un produit Microsoft où il faut aller dans le menu Démarrer pour Éteindre…
Pour que l’alchimie fonctionne, il faudrait que les utilisateurs manifestent de l’intérêt pour un catalogue conçu en fonction de leurs besoins ; que les informaticiens conçoivent qu’un catalogue de données est destiné à être utilisé et pas simplement construit ; et que les responsables de la gouvernance mettent en avant l’indicateur du taux d’usage et non de la complétude théorique. Quel éditeur est prêt à relever le défi ?
Si vous voulez en savoir plus et expérimenter tout cela, participez aux formations sur la gouvernance des données que je donne tout au long de l’année.
Abonnez-vous pour ne manquer aucun épisode du Podcast Decideo
Pour ne manquer aucun épisode du podcast Decideo, abonnez-vous, c'est gratuit !
- Sur Apple Podcast : https://podcasts.apple.com/es/podcast/decideo-data-science-big-data-intelligence-augment%C3%A9e/id1505073603
- Sur Podcast Addict : https://podcastaddict.com/podcast/decideo-data-science-big-data-intelligence-augmentee/4102946
- Sur Spotify : https://open.spotify.com/show/1Cs8jBS1PB7ehZU4s4EiyB?si=ec6b704dd15d4454
Ou sur votre plateforme de podcast préférée, cherchez "Decideo" !
- Sur Apple Podcast : https://podcasts.apple.com/es/podcast/decideo-data-science-big-data-intelligence-augment%C3%A9e/id1505073603
- Sur Podcast Addict : https://podcastaddict.com/podcast/decideo-data-science-big-data-intelligence-augmentee/4102946
- Sur Spotify : https://open.spotify.com/show/1Cs8jBS1PB7ehZU4s4EiyB?si=ec6b704dd15d4454
Ou sur votre plateforme de podcast préférée, cherchez "Decideo" !
Autres articles
-
Podcast : IA, RH et données, avec José Rodriguez, Cornerstone
-
Podcast : Les agriculteurs dépossédés de leurs données, avec Caroline Gans Combe
-
Podcast : Alain Garnier, Jamespot, défend une diversité souveraine
-
Podcast : L’observabilité, attitude et outil du data steward
-
Podcast : Automatisation des services comptables, avec Geoffrey Nozerand, Dext
