La gestion des métadonnées est une composante importante dans un projet plus global de Data Management, et elle nécessite plus que la simple mise en place d’une solution logicielle de data catalog, aussi connecté soit-il.

Certes le catalogue va permettre d’alléger la charge induite, mais il ne pourra à lui seul garantir le succès.

Inspiré par nos retours d’expérience issus de contextes très variés, cette série d’articles
présente les principaux écueils et idées reçues que vous devez à tout prix éviter lors
de la mise en place d’un catalogue de données à l’échelle de votre entreprise.

Les pièges décrits dans cette série s’articulent autour de quatre thématiques centrales à
la réussite de la démarche :

1. La culture de la donnée dans l’organisation
2. Le sponsorship du projet en interne
3. Le pilotage du projet
4. L’intégration technique du data catalog

—

L’intégration du data catalog dans l’écosystème de l’entreprise favorise des opportunités de création de valeur. Il est primordial de bien considérer cet aspect et d’en comprendre les bénéfices.

Toutes les métadonnées ne doivent être saisies à la main

De plus en plus de systèmes produisent, agrègent et permettent une saisie de métadonnées à valeur locale. Ces informations doivent être récupérées et consolidées dans le catalogue – sans double saisie – pour des raisons évidentes d’économie, de fiabilité et de rapidité de mise à disposition.

Le data catalog est donc une opportunité pour consolider ces informations avec les savoirs portés par les collaborateurs sur leurs périmètres respectifs. Cependant, cette consolidation doit être pensée à travers une intégration technique et non un travail à réaliser manuellement. Même s’il semble évident que la double saisie n’est pas une approche pérenne ou efficace, procéder à des imports / exports entre systèmes reposant sur des actions humaines n’est pas non plus une approche pertinente.

La force d’un data catalog doit être sa capacité à ingérer des métadonnées via des chaînes d’intégration techniques, et d’ainsi permettre une synchronisation robuste entre les systèmes.

Le data catalog n’est pas un outil “automagique”

À l’inverse, penser que le data catalog saura extraire tous types de métadonnées quelle que soit la source ou le format, serait plus que trompeur.

Le catalogue doit certes faciliter la récupération de métadonnées, mais certaines ne pourront pas y être déversées automatiquement. Il reste donc toujours un coût porté par l’intervention de contributeurs.

La première raison à cela réside tout simplement dans l’origine même de certaines métadonnées : des informations ne sont peut-être tout simplement pas encore présentes dans des systèmes car elles sont uniquement issues du savoir d’experts. Le data catalog est donc dans ce cas un candidat potentiel pour devenir le système maître afin de les recevoir.

Au contraire, certaines informations peuvent être présentes dans des systèmes sans qu’il soit possible ou presque de les récupérer de façon automatisée et ce, pour de nombreuses raisons. Nous pourrions par exemple citer l’absence d’une interface permettant d’accéder de façon stable aux informations ou encore la nécessité d’avoir recours à de la rétro-ingénierie pour tenter d’isoler des informations pertinentes. Le risque de produire du bruit sur l’information est donc élevé et ceci conduirait à dégrader la qualité du contenu du catalogue, et in fine, à en détourner les utilisateurs.

Le data catalog ne doit pas être connecté à une source unique de métadonnées

Les métadonnées appartiennent à des couches nombreuses et variées. Les sources sont donc multiples et complémentaires pour une compréhension globale. C’est justement le rapprochement de ces informations dans une solution centrale, le data catalog, qui va apporter les éléments nécessaires aux utilisateurs pour leurs besoins.

Choisir un data catalog connecté est un véritable atout, car la découverte des actifs et la récupération de leurs métadonnées associées sont grandement simplifiées par cette automatisation.

Mais cette connectivité peut aussi très souvent s’étendre à d’autres systèmes complémentaires. Ces systèmes sont potentiellement d‘autres systèmes en amont ou en aval du premier, permettant, si désiré, de matérialiser le data lineage et de documenter ainsi les flux et les transformations entre les systèmes.

Les systèmes peuvent aussi être non liés les uns aux autres et juste permettre, par leur ajout au data catalog, de constituer une cartographie exhaustive du patrimoine de l’entreprise.

Enfin, de par la variété des types d’actifs pouvant être documentés dans le data catalog, les différentes sources connectées peuvent aussi contribuer chacune à l’enrichissement d’un univers spécifique dans le data catalog : couche sémantique pour certaines, couche physique pour d’autres etc.

Toujours fidèle à une approche itérative, les sources multiples qui alimenteront le data catalog seront intégrées progressivement – selon une stratégie influencée par le souci de production de valeur – sous le pilotage global du Data Office.

Depuis le début du 21e siècle, nous vivons une véritable révolution numérique. Le monde est en constante digitalisation et l’activité humaine se structure toujours plus autour de la donnée et des réseaux. L’industrie, les loisirs, les services d’Etats, le secteur tertiaire, le médical, et tant d’autres domaines s’organisent désormais autour de systèmes d’informations complexes et interconnectés. Par conséquent, de plus en plus de données sont continuellement collectées par les appareils et technologies présents dans notre quotidien (Web, Smartphone, IoT) et transitent de systèmes en systèmes. Il est devenu central pour toute entreprise qui fournit des produits ou des services de tout mettre en œuvre pour protéger les données de leurs clients utilisateurs. Pour y arriver, la meilleure approche est celle du Privacy by Design. 

Dans cet article, nous définissons ce qu’est la notion du Privacy by Design, et nous expliquons comment nous l’avons appliquée dans la conception de notre data catalog chez Zeenea. Enfin, nous exposons la manière dont un data catalog peut aider les entreprises à mettre en place le Privacy by Design.

La protection des données : un enjeu capital pour les entreprises

Parmi toutes ces données évoquées précédemment, certaines permettent d’identifier directement ou indirectement des personnes physiques. Ce sont les données personnelles, telles que définies par la CNIL. Elles revêtent une importance capitale dans le monde moderne du fait de leur valeur intrinsèque. 

Quotidiennement, des volumes gigantesques transits entre les individus, les entreprises et les États. Il existe un véritable risque de détournement de leur l’usage, comme l’a montré par exemple le scandale Cambridge Analytica en 2015. Les cybercriminels peuvent également en tirer des gains substantiels, via le piratage de compte, la revente de données à d’autres cybercriminels, l’usurpation d’identité, ou encore l’attaque d’entreprises via phishing ou arnaque au président. C’est par exemple ainsi qu’un promoteur immobilier s’est récemment vu subtiliser plusieurs dizaines de millions d’euros.

Le besoin de protéger ses données n’a jamais été aussi important.

Les États ont rapidement pris conscience de cette problématique pour protéger les individus des dérives liées à l’exploitation de leurs données. En Europe par exemple, le RGPD (le Règlement Général sur la Protection des Données) est en vigueur depuis 2016 et est déjà bien ancré dans les activités quotidiennes des entreprises. Dans le reste du monde, la réglementation évolue constamment et est une préoccupation pour quasiment tous les pays. Récemment, la Californie a voté une loi sur le caractère privé des données des consommateurs, assimilée à un équivalent américain du RGPD. Même la Chine vient de légiférer sur ce sujet.

Privacy by Design : définition d’une notion essentielle pour la protection des données

Si de nombreuses législations s’appuient fortement sur la notion de Privacy by Design, elle a été conceptualisée par Ann Cavoukian à la fin des années 90 alors qu’elle occupait le poste d’Information and Privacy Commissioner de la province de l’Ontario au Canada. L’essence de cette idée est d’inclure la problématique de protection des données personnelles dès la conception d’un système informatique. 

En ce sens, le Privacy by Design liste sept principes fondamentaux :

#1 – La proactivité : toute entreprise doit mettre en place les dispositions nécessaires à la protection des données en amont, et ne doit pas s’appuyer sur une politique réactive ;

#2 – La protection des données personnelles comme paramètre par défaut : tout système doit prendre comme configuration par défaut le plus haut niveau de protection possible pour les données sensibles de ses utilisateurs ;

#3 – La protection des données personnelles intégrée à la conception : la protection des données personnelles doit être un aspect systématiquement étudié et pris en compte lors de la conception et l’implémentation d’une nouvelle fonctionnalité  ;

#4 – La fonctionnalité complète : aucun compromis ne doit être fait avec les protocoles de sécurité ou avec l’expérience utilisateur ;

#5 – La sécurité de bout en bout : le système doit garantir la sécurité des données sur l’ensemble du cycle de vie, depuis leur collecte jusqu’à leur destruction (y compris si lesdites données sont sous-traitées) ;

#6 – La visibilité et la transparence : le système et l’entreprise doivent documenter et communiquer les procédures de protection des données personnelles et les actions réalisées de manière claire, cohérente et transparente ;

#7 – Le respect de la vie privée de l’utilisateur : chaque décision de conception et d’implémentation doit se faire en mettant au centre l’intérêt de l’utilisateur.

L’application du Privacy by Design chez Zeenea

Chez Zeenea, et notamment parce que l’entreprise a été créée en 2017, nous avons bâti notre produit sur les fondements du Privacy by Design.

Le traitement des données personnelles des utilisateurs

Tout d’abord, nous avons ancré la protection des données au cœur de notre architecture. Les données de chaque client sont séparées dans des tenants différents, chiffrés chacun avec leur propre clé. L’authentification des utilisateurs est gérée via un système tiers spécialisé. Nous encourageons la fédération d’identité chez nos clients, ce qui leur permet de garder le contrôle sur les données nécessaires à l’identification et l’authentification des utilisateurs.

Nous avons également inclus le concept de Privacy by Design lors de la conception de notre applicatif. Par exemple, nous ne récoltons que le strict minimum d’information, tous les extrants du système sont anonymisés (traces de log, erreur applicative, APIs).

Le traitement des données métier des clients

Notre principale mission étant de documenter la donnée, notre solution contient par essence majoritairement des métadonnées. Par conception, Zeenea n’extrait aucune donnée des systèmes de nos clients. En effet, le risque est intrinsèquement moindre sur la métadonnée que sur la donnée. 

Nous proposons néanmoins au sein de l’application Zeenea plusieurs fonctionnalités permettant de fournir de l’information sur la donnée présente dans les systèmes clients (des statistiques, du sampling, etc.). Du fait de notre architecture, les calculs se font toujours sur l’infrastructure du client, au plus près des données et de leur sécurisation. Et dans le respect du principe #2 du Privacy by Design, nous avons placé la protection des données personnelles comme paramètre par défaut. Ainsi, toutes ces fonctionnalités sont désactivées par défaut et ne peuvent être activées que sur décision du client.

Comment notre catalogue de données aide les entreprises à mettre en place le Privacy by Design

Le data catalog peut aider votre entreprise à mettre en place le Privacy by Design, surtout sur les aspects de contrôle et de vérification. Si l’on reprend les 7 principes décrits plus tôt, le data catalog peut participer efficacement à deux d’entre eux : le principe de visibilité et de transparence, et celui de sécurité de bout en bout. Le catalogue de données permet aussi l’automatisation de l’identification des données sensibles.

La visibilité et la transparence via le data catalog

L’objectif du data catalog est de centraliser le patrimoine de données de l’entreprise, de le documenter, et de le partager au plus grand nombre afin d’en permettre l’usage éclairé. Par exemple, cette centralisation permet à chaque employé de savoir quelles sont les données collectées par le CRM, et aux équipes marketing et Customer Success de traiter cette information dans des rapports de suivi des acquisitions et de churn.

Une fois cet inventaire établi, le catalogue permet d’envisager de documenter certaines informations supplémentaires et nécessaires au bon fonctionnement de l’entreprise. C’est notamment le cas du caractère sensible ou non d’une information documentée, des règles de gouvernances, des traitements, ou encore les procédures d’accès qui doivent s’appliquer. 

Dans le contexte d’une démarche Privacy by Design, le data catalog permet par exemple d’ajouter un terme métier correspondant à une donnée sensible (un numéro de sécurité sociale, un numéro de téléphone etc.). Ce terme métier peut alors facilement être associé aux tables ou aux champs physiques qui contiennent la donnée, permettant ainsi son identification aisée. Cette initiative contribue ainsi au principe de visibilité et de transparence du Privacy by Design.

La sécurité de bout en bout via le data catalog

Le data catalog offre également des fonctionnalités de lignage des données (ou data lineage). Le lignage automatique permet de s’assurer que les traitements qui sont appliqués aux données identifiées comme sensibles sont bien conformes à ce qui est défini par la gouvernance des données dans l’entreprise. Il est alors simple avec le catalogue de données de renseigner les règles de gouvernances à appliquer aux données sensibles. 

De plus, le lignage permet de suivre l’ensemble du cycle de vie de la donnée, de sa création à son utilisation finale, en passant par ses transformations. Ainsi il est aisé de contrôler que toutes les étapes de ce cycle de vie sont conformes aux règles et de corriger les éventuelles erreurs. 

Le data catalog, via le data lineage, contribue ainsi au principe de sécurité de bout en bout du Privacy by Design.

Attention : chez Zeenea nous restons convaincus que le data catalog n’est pas une solution de compliance, mais bien un outil d’acculturation des équipes à la donnée sensible et à ses particularités d’usage.

L’identification des données sensibles via le data catalog

Dans un environnement data qui évolue extrêmement rapidement, le catalogue de données doit être le plus possible un reflet de la réalité pour conserver la confiance de ses utilisateurs. Sans cela, c’est l’adoption toute entière du projet de data catalog qui est mise en question. 

Chez Zeenea, nous sommes intimement convaincus que le data catalog doit être automatisé un maximum pour être scalable et efficace. Cela commence par l’inventaire des données disponibles. En ce sens, notre inventaire est automatisé et se charge de répercuter toutes les modifications du système d’origine (source) des données directement dans le catalogue. Ainsi, à tout moment, le client dispose d’une liste exhaustive des données présentes dans ses systèmes. 

Et pour aider nos clients à identifier dans ces données inventoriées celles qui méritent un traitement particulier du fait de leur statut de données sensible, l’automatisation ne s’arrête pas à l’inventaire. Nous proposons aujourd’hui un système qui suggère le taggage des nouvelles données inventoriées présentant un profil de données sensible. Ainsi, le travail de mise en avant de ces données est facilité et l’information se propage plus vite et plus facilement dans l’entreprise.

Pour plus d’information sur la technologie utilisée chez Zeenea, téléchargez notre eBook “Les 5 ruptures technologiques d’un Data Catalog”

Conclusion

La donnée personnelle est devenue en quelques années un vrai sujet de préoccupation pour la plupart des consommateurs. De plus en plus de pays mettent en place des réglementations pour garantir à leur concitoyens une protection à la hauteur des enjeux. L’un des principes majeurs régissant toutes ces réglementation est le Privacy by Design.

Chez Zeenea, nous avons dès le départ inclus la réflexion autour de la donnée personnelle au cœur de notre produit. Aussi bien dans notre technique de développement et de traitement des données de nos utilisateurs directs, que dans notre réflexion sur les données que nos clients traitent via notre catalogue. 

Nous pensons que le catalogue de données peut être un atout non négligeable dans la mise en place et le suivi des politiques induites par le Privacy by Design. Nous misons également beaucoup sur l’automatisation et l’IA pour y apporter encore de nombreuses améliorations dans les mois à venir : construction automatique du lignage technique des données, amélioration de la détection des données sensibles dans les objets du catalogue pour mieux les documenter, contrôle de qualité des processus appliqués aux données sensibles etc. Les possibilités sont nombreuses. 

Pour en savoir plus sur les avantages du catalogue dans la gestion de vos données sensibles et personnelles, n’hésitez pas à nous contacter !

Il s’agit pourtant d’une mission essentielle pour amener un produit au succès, et d’un prérequis évident à la motivation des équipes qui ont besoin de savoir pourquoi elles se lèvent tous les matins pour aller au bureau.

Les bases d’une vision produit partagée dans l’entreprise

Différents “frameworks” (NorthStar, OKR, etc.) ont été développés depuis quelques années pour permettre aux entreprises et à leurs équipes produit de poser ces bases, les diffuser au sein de l’organisation et construire une roadmap qui crée l’adhésion. Ces frameworks permettent généralement de définir quelques artefacts clés et ont déjà donné lieu à une importante littérature. Si les versions peuvent différer d’un framework à l’autre, on retrouve tout de même généralement les concepts suivants : 

• La vision : le rêve, le véritable Nord d’une équipe. La vision doit être inspirante et créer un sens commun de l’objectif dans toute l’entreprise.
• La mission : elle représente l’objectif primordial de l’organisation et doit être mesurable, réalisable.
• Les objectifs : déclinaisons de la mission, les objectifs définissent des jalons mesurables à court ou moyen termes pour accomplir la mission.
• La roadmap : une source de vérité partagée – elle décrit la vision, la direction, les priorités et les progrès d’un produit au fil du temps.

Grâce à une définition claire et partagée de ces concepts au sein de l’entreprise, les équipes produits ont une base solide pour identifier les problèmes à résoudre en priorité et ordonner efficacement les backlogs produits.

Les valeurs produit : clé de l’adhésion et de l’alignement des équipes dans le temps

Bien définis au départ, ces concepts décrits précédemment peuvent malgré tout tomber dans l’oubli au bout de quelque temps ou devenir obsolètes ! En effet, l’entreprise et le produit évoluent, les équipes changent, et par conséquent le produit peut perdre le cap… Un travail de remise en cause et d’acculturation doit donc être effectué en continu par les équipes produit pour tenir dans la durée.

En effet, le développement produit est à la fois un sprint et un marathon ! Une des difficultés principales des équipes produit est de conserver cet alignement dans le temps. À ce titre, on retrouve un autre concept dans ces frameworks est souvent sous-exploité quand il n’est pas complètement oublié par les organisations : il s’agit des valeurs du produit. 

Jeff Steiner de LinkedIn a particulièrement mis en avant l’importance de définir les valeurs de l’entreprise grâce au framework Vision to values. LinkedIn définit ainsi la notion de valeurs comme “Les principes qui guident les décisions quotidiennes de l’organisation ; un élément déterminant de votre culture”. Par exemple “être honnête et constructif”, “exiger l’excellence”, etc.

Définir les valeurs du produit en complément de celles de l’entreprise peut être un excellent moyen pour les équipes produit de créer cet alignement dans le temps et c’est ce que l’on fait chez Zeenea.

De la vision d’entreprise aux valeurs produit : focus sur Zeenea Data Catalog

Organisation & cohérence produit chez Zeenea

Chez Zeenea, nous avons une vision partagée – ”Be the first step of any data journey” – et une mission claire – “To help data teams accelerate their initiatives by creating a smart & reliable data asset landscape at the enterprise level”.  

Nous nous positionnons comme un pure-player du Data Catalog et nous partageons la responsabilité d’un seul produit entre plusieurs Product Managers. C’est pourquoi nous nous sommes organisés en feature teams. Ainsi chaque équipe de développement peut prendre en charge n’importe quelle nouvelle fonctionnalité ou évolution en fonction des priorités de l’entreprise, et les mener à bien de bout-en-bout.

Si nous priorisons le backlog et le delivery en définissant et en adaptant notre stratégie et notre organisation en fonction des objectifs, trois problématiques subsistent : 

• Comment nous assurer que le produit reste cohérent dans le temps quand il y a plusieurs pilotes dans l’avion ? 
• Comment favoriser une approche plutôt qu’une autre ? 
• Comment s’assurer que toute nouvelle fonctionnalité soit cohérente avec le reste de l’application ? 

En effet, chaque Product Manager a sa propre sensibilité, son propre background. Et si les problèmes sont clairement identifiés, il existe généralement plusieurs façon de les résoudre. C’est là où entrent en jeu les valeurs produit…

Les valeurs produit Zeenea

Si la vision et la mission nous aident à répondre au “pourquoi ?”, les valeurs du produit nous permettent de rester aligner sur la question “comment ?”. Il s’agit d’un outil précieux pour challenger les différentes approches possibles pour répondre à un besoin client. Et chaque Product Manager peut se référer à ces valeurs communes pour faire des choix, prioriser une fonctionnalité ou la rejeter, et assurer une expérience utilisateur unifiée dans toute l’application et différenciée face à la concurrence.

Ainsi, chaque nouvelle fonctionnalité est réalisée avec pour guides les 5 valeurs produit suivantes :

La simplicité (simple) 

Cette valeur est au cœur de nos convictions. L’objectif d’un Data Catalog est de démocratiser l’accès à la donnée. Pour cela, faciliter l’adoption du produit par les utilisateurs finaux est un élément primordial. La simplicité se traduit clairement dans la façon dont chaque fonctionnalité est proposée. Beaucoup d’applications finissent par ressembler à des sapins de Noël avec des boutons dans tous les sens que personne ne sait utiliser ; d’autres demandent des semaines de formation avant de pouvoir cliquer sur le premier bouton. L’utilisation du Data Catalog ne doit pas être réservée à des experts et doit donc être évidente et fluide quel que soit l’objectif de l’utilisateur. Cette valeur se retranscrit notamment dans notre choix d’avoir créé deux interfaces pour notre Data Catalog : une dédiée à la recherche et l’exploration, et une autre pour la gestion et le monitoring du contenu du catalogue. 

L’autonomie (empowering)  

Les tâches de documentation sont souvent ingrates et il peut être difficile de motiver les sachants à partager et formaliser leurs connaissances. De la même façon, le produit doit encourager le plus possible les consommateurs de données à être autonomes dans leurs usages de la donnée. C’est pourquoi nous avons fait le choix de ne pas proposer de workflows de validation rigides pour leur préférer un système de responsabilisation. Celui-ci permet aux Data Stewards de prendre conscience des impacts de leurs modifications. Couplé à un système d’alerting et d’audit a posteriori, il assure une meilleure autonomie tout en gardant une bonne traçabilité en cas de problème. 

La confiance (reassuring) 

Il est essentiel de permettre aux utilisateurs finaux d’avoir confiance dans la donnée qu’ils consomment. Le produit doit donc rassurer l’utilisateur de part sa façon de présenter l’information. De la même manière, les Data Stewards qui maintiennent une grande quantité de données ont besoin d’être rassurés vis-à-vis des opérations dont ils sont responsables : ai-je bien tout traité ? comment m’assurer qu’il n’y a pas d’incohérence dans la documentation ? Que va-t-il vraiment se passer si je clique sur ce bouton ? Et si ça plante ? Le produit doit créer un environnement où l’utilisateur se sent en confiance vis-à-vis de l’outil et de son contenu. Cette valeur se traduit par des messages préventifs plutôt que des rapports d’erreurs, un type de langage, le caractère idempotent des opérations d’imports, etc.

La flexibilité (flexible)  

Chaque client a son propre contexte métier, son historique, ses règles de gouvernance, ses besoins, etc. Le Data Catalog doit pouvoir s’adapter à ce contexte là encore pour faciliter son adoption. Mais la flexibilité est aussi une valeur essentielle pour permettre au catalogue de s’adapter à tous les contextes technologiques actuels et être réellement le référentiel de la donnée à l’échelle de l’entreprise. Le produit doit donc s’adapter au contexte de l’utilisateur et être aussi proche que possible de ses usages. Notre modélisation à plat et incrémentale s’appuie sur cette valeur, face à des modèles hiérarchiques plus rigides proposés sur le marché.

La Deep Tech 

Cette valeur est également très importante dans nos choix de développement. La technologie est au cœur de notre produit et doit servir les autres valeurs (notamment de simplicité et de flexibilité). Documenter, maintenir et exploiter la valeur d’un patrimoine de données à l’échelle de l’entreprise ne peut se faire sans l’aide de technologies intelligentes (automatisation, intelligence artificielle, etc.). Le choix de baser notre moteur de recherche sur un graphe de connaissance ou notre positionnement en termes de connectivité sont des illustrations de l’application de cette valeur “deep tech” chez Zeenea.

Take away

Créer l’alignement autour d’un produit est un travail de longue haleine. Il  demande aux Product Managers – en synergie avec toutes les parties prenantes – de bien définir au départ : la vision, la mission et les objectifs de l’entreprise pour pouvoir prioriser efficacement le travail des équipes. Mais pour assurer la cohérence d’un produit dans le temps, l’utilisation des valeurs du produit est un outil précieux. Chez Zeenea, nos valeurs produit sont la simplicité, l’autonomie, la confiance, la flexibilité et la technologie. Elles se reflètent dans la façon dont nous concevons et faisons évoluer notre Data Catalog et nous permettent d’assurer une meilleure expérience client dans le temps. 

Si vous souhaitez en savoir davantage sur notre produit, ou pour obtenir plus d’informations au sujet de  Data Catalog :

Un data catalog doit être smart dans l’expérience qu’il propose aux différentes populations d’utilisateurs qui seront amenées à le consommer. En effet, l’un des principaux enjeux du déploiement d’un catalogue de données est son adoption par ceux à qui il est destiné in fine – les consommateurs de datas. Et l’expérience utilisateur joue bien sûr un rôle majeur dans cette adoption.

La notion d’expérience utilisateur dans le domaine du data catalog

La notion d’expérience utilisateur se repose principalement sur l’identification de persona dont on cherche à modéliser le comportement et les objectifs, afin de leur fournir une interface graphique aussi performante et ergonomique que possible. Dans le domaine du data catalog, la caractérisation des personas est problématique, car il n’existe pas d’organisation canonique – il s’agit d’un outil universel, précieux pour des entreprises de toutes tailles, opérant sur virtuellement tous les secteurs d’activité et dans toutes les géographies.

Plutôt que modéliser d’insaisissables personas, il est possible d’aborder le sujet en étudiant l’adoption. Pour cela, on peut distinguer deux grandes populations d’utilisateurs 

• Les producteurs de métadonnées, qui vont alimenter le catalogue et monitorer la qualité de son contenu – nous les appellerons de façon générique les Data Stewards ;

• Les consommateurs de métadonnées, qui vont utiliser le catalogue dans le cadre d’un objectif opérationnel lié à leur fonction – nous les appellerons simplement Utilisateurs.

Ces deux populations ne sont bien sûr pas totalement disjointes : certains Data Stewards, polyvalents, sont aussi Utilisateurs.

Les freins à l’adoption du catalogue dans l’entreprise

La vraie valeur d’un data catalog réside dans sa capacité à être adopté largement non par les spécialistes du Data Management, mais par la population beaucoup plus vaste des consommateurs de données (ou de métadonnées).

Cette population est très diversifiée. On y retrouve des experts de la donnée (ingénieurs, architectes, data analysts, data scientists, etc.), des profils métiers (chefs de projets, responsables de domaines, responsables produits, etc.), des spécialistes de la conformité ou du risque. Et plus généralement – dans les organisations les plus matures – tous les responsables opérationnels qui sont amenés à consommer des données pour améliorer leurs performances.

L’adoption du data catalog par ces populations d’Utilisateurs est typiquement freinée par les aspects suivants :

• Pour ces Utilisateurs, l’usage du data catalog est sporadique : ils l’utilisent ponctuellement pour répondre à une question précise, puis utilisent la réponse à leur question dans leur activité opérationnelle. Ils n’ont généralement ni le temps ni l’envie de supporter une courbe d’apprentissage longue sur un outil qu’ils n’utilisent que de façon ponctuelle – il peut s’écouler des semaines entre deux utilisations

• Tous n’ont pas le même prisme sur les métadonnées. Certains seront davantage concernés par les métadonnées techniques, d’autres auront un prisme beaucoup plus sémantique, d’autres encore seront focalisés sur les aspects organisationnels ou de gouvernance.

• Tous ne maîtrisent pas le métamodèle ni l’organisation interne de l’information dans le catalogue. Ils peuvent rapidement se sentir intimidés par une avalanche de concepts potentiellement abscons à leurs yeux.

Le Smart Data Catalog va chercher à adresser ces différents freins pour accélérer l’adoption du catalogue. 

Les solutions mises en place par Zeenea pour favoriser l’adoption du catalogue

Le premier élément de réponse tient à l’interface graphique. Nous estimons que les Utilisateurs doivent avoir une courbe d’apprentissage la plus faible possible pour utiliser le catalogue – en pratique, cela signifie qu’ils devraient être en mesure de l’utiliser de façon efficace sans formation préalable. Pour cela, nous avons pris plusieurs décisions.

La première consiste à ne pas proposer la même interface graphique aux Data Stewards et aux Utilisateurs. La solution Zeenea propose deux interfaces :

Zeenea Studio : l’outil de gestion et de monitoring du contenu du catalogue – un outil expert destiné aux Data Stewards.

Zeenea Explorer : qui est destiné aux Utilisateurs – leur propose une expérience de recherche et d’exploration du catalogue la plus simple possible.

Cette approche reprend les principes ergonomiques des solutions de marketplace – qui restent les grands spécialistes de la gestion de catalogue au sens large. Ces solutions proposent typiquement au moins deux applications. L’une, que l’on pourrait qualifier de back-office, permet au personnel de la marketplace (ou à ses partenaires) d’alimenter le catalogue de la façon la plus automatisée possible et de contrôler son contenu pour monitorer sa qualité. L’autre, destinée aux consommateurs, est le plus souvent matérialisée par un site de commerce électronique, et permet aux utilisateurs finaux de rechercher des articles ou d’explorer thématiquement le catalogue. Zeenea Studio et Zeenea Explorer tiennent respectivement ces deux rôles.

Une information hiérarchisée en fonction du rôle de l’utilisateur dans l’organisation

Le second dispositif imaginé par Zeenea est encore au stade expérimental. Il consiste à adapter dynamiquement la hiérarchie de l’information dans la catalogue selon le profil de l’Utilisateur.

En effet, pour un catalogue de données, la hiérarchie de l’information est tributaire du rôle opérationnel de l’Utilisateur. Pour certains, l’information la plus importante sur un jeu de données va être ses caractéristiques techniques : emplacement, sécurité, formats, types, etc. D’autres voudront avant tout connaître la sémantique des données et leur lineage métier. D’autres encore sauront connaître les processus et contrôles qui pilotent la production des données – à des fins réglementaires ou plus opérationnelles.

Le Smart Data Catalog devrait ajuster dynamiquement la structure de l’information pour s’adapter à ces différents prismes.

Enfin, le dernier frein concerne l’organisation de l’information dans le catalogue, qui se matérialise par des axes d’exploration thématiques (un peu comme les rayonnages d’une marketplace). Là aussi, difficile de trouver une structure qui satisfasse toutes les populations d’utilisateurs. Certains chercheront plutôt à explorer le catalogue selon des axes techniques (systèmes, applications, technologies, etc.). D’autres voudront l’explorer selon une classification fonctionnelle – domaines et sous-domaines métier, d’autres encore sous un angle plutôt sémantique à travers un glossaire métier, etc.

La difficulté d’accorder tout le monde sur une classification universelle nous semble insurmontable, et là aussi, le Smart Data Catalog devrait s’adapter à ces différents prismes plutôt que demander aux Utilisateurs de maîtriser une classification qui n’a peut-être pas de sens pour eux. L’expérience utilisateur est donc l’un des facteurs de succès les plus importants pour un catalogue de données. 

Pour comprendre comment une expérience utilisateur “smart” (maligne) renforce les capacités d’un data catalog, téléchargez notre eBook : “Qu’est-ce qu’un Smart Data Catalog ?” dès maintenant!

Un moteur de recherche puissant pour une exploration efficace

Selon nous, dans un univers d’information très volumineux, comme c’est le cas d’un catalogue de données d’entreprise, la recherche n’est pas une fonction annexe mais le principal mécanisme par lequel les utilisateurs vont pouvoir exploiter le catalogue. Elle doit donc être simple, puissante, et surtout efficace – les résultats doivent satisfaire les utilisateurs. Google ou Amazon.com fixent en la matière la barre très haut, et l’expérience de recherche qu’ils proposent est devenue une sorte de référence dans le domaine. 

Ils fixent le la de l’expérience de recherche, que l’on pourrait résumer de la sorte :

• Je saisis quelques mots clés dans la barre de recherche – souvent assisté par un système de suggestion me proposant des associations fréquentes de termes permettant de mieux qualifier ma recherche.

• La réponse, quasi instantanée, m’affiche les résultats dans un ordre précis, et je m’attends à trouver celui ou ceux qui m’intéressent sur la première page de résultats.

• À défaut, je vais soit ajouter un terme à ma recherche pour mieux la circonscrire, soit utiliser un système plus ou moins poussé de filtrage permettant d’éliminer les résultats non pertinents.

Or dans le monde du data catalog, en matière de capacités de recherche, les solutions du marché proposent au mieux un bon système d’indexation. Cette approche donne des résultats satisfaisants quand l’utilisateur a une idée précise de ce qu’il cherche (high intent search), mais est décevante pour ceux dont la démarche est plus exploratoire (low intent search) ou quand il s’agit de suggérer spontanément certains résultats pertinents à un utilisateur (no intent).

En somme, la simple indexation permet au mieux de retrouver les éléments dont on connaît les caractéristiques précises, mais n’est pas suffisante lorsque la recherche est plus évasive. Les résultats sont alors trop souvent pollués par de nombreux faux positifs, et l’ordre des résultats est surdéterminé par les correspondances exactes.

Une approche multidimensionnelle de la recherche

Nous avons décidé quant à nous, dès le départ, qu’un simple système d’indexation serait trop limitatif pour répondre de façon pertinente aux questions des utilisateurs. Nous avons donc pris le parti d’isoler le moteur de recherche dans un module dédié de la plateforme, et d’en faire une zone d’innovation (et d’investissement) forte.

Nous ne disposons bien sûr pas des moyens de Google, ni de sa connaissance en matière d’optimisation des résultats de recherche. Mais nous avons néanmoins intégré dans notre moteur de recherche plusieurs features qui permettent d’ores et déjà une très bonne pertinence, et qui sont en amélioration continue – tester et valider la performance d’un moteur de recherche est en soit une gageure.

Nous nous sommes donc naturellement intéressés aux travaux des fondateurs de Google sur leur algorithme Page Rank. Celui-ci prend en compte plusieurs dizaines d’aspects (appelées features), parmi lesquels on retrouve la densité des relations entre les différents objets du graphe (liens hypertextes dans le cas de pages Internet), le traitement linguistique des termes de la recherche ou encore l’analyse sémantique du knowledge graph.

Les principales features que nous avons intégré sont les suivantes :

• L’indexation classique, à plat, de tous les attributs d’un objet (son nom, sa description et toutes ses propriétés) avec une pondération en fonction du type de propriété.

• Une couche de NLP (Natural Language Processing) permettant de prendre en compte les approchants (fautes de frappe ou d’orthographe).

• Une couche d’analyse sémantique, reposant sur le traitement du knowledge graph.

• Une couche de personnalisation, reposant actuellement sur une classification simple des utilisateurs selon leurs cas d’usage, mais qui sera dans le future enrichie de données de profilage individuel.

Le smart filtering pour contextualiser et limiter les résultats de recherche

Pour compléter le moteur de recherche, nous proposons également un système de smart filtering. Il s’agit d’une capacité que l’on trouve fréquemment dans les sites e-commerce (typiquement Amazon.com ou Booking.com), et qui consiste à proposer des filtres contextualisés pour réduire le résultat d’une recherche.

Ces filtres fonctionnent de la façon suivante :

• Seules les propriétés qui permettent effectivement de réduire la liste des résultats sont proposées dans la liste des filtres – les propriétés non discriminantes n’apparaissent pas.
• Chaque filtre indique son impact – c’est-à-dire le nombre de résultats résiduels une fois le filtre appliqué.
• L’application d’un filtre rafraîchit instantanément la liste des résultats.

En combinant la recherche multidimensionnelle et le smart filtering, nous estimons aujourd’hui offrir une expérience de recherche véritablement smart. Et notre architecture découplée nous permet d’expérimenter de façon continue de nouvelles approches, tout en intégrant très rapidement celles qui nous semblent efficaces.

Pour comprendre comment un moteur de recherche “smart” (malin) renforce les capacités d’un data catalog, téléchargez notre eBook : “Qu’est-ce qu’un Smart Data Catalog ?” dès maintenant!

Le second domaine sur lequel un data catalog peut être smart, c’est l’inventaire. Rappelons-le : un data catalog est fondamentalement un inventaire aussi exhaustif que possible des actifs informationnels, complété d’un ensemble de métadonnées permettant d’exploiter de façon optimale les actifs en question. Tout effort de mise en place d’un catalogue de données repose donc en premier lieu sur un inventaire des actifs présents dans les différents systèmes.

Le défi de l’automatisation de l’inventaire

Aussi bien pensée soit-elle, l’approche déclarative pour la construction de l’inventaire ne nous semble pas spécialement smart. Elle requiert une charge de travail conséquente pour initialiser le catalogue, et oblige à un travail constant et passablement rébarbatif pour le maintenir à jour – dans un univers digital en perpétuelle évolution, l’inventaire initial est rapidement frappé d’obsolescence.

Le premier moyen pour réaliser un inventaire de façon maline, c’est bien sûr de l’automatiser. À de rares exceptions près, les jeux de données d’une entreprise sont gérés par des systèmes spécialisés, qui vont du système de fichiers distribué aux ERPs en passant par des bases de données relationnelles ou non, des progiciels, des dataware houses, etc. Tous ces systèmes maintiennent, d’une façon ou d’une autre, un registre des données qu’ils gèrent, et un ensemble de métadonnées nécessaires à leur bon fonctionnement.

Inutile donc de recréer manuellement ces informations : il suffit de se connecter aux différents registres, et de synchroniser le contenu du catalogue avec celui des systèmes source. Le principe est simple, la réalisation nettement plus délicate. En effet, il n’existe aucun standard auquel se conformeraient les différentes technologies pour offrir une méthode universelle d’accès à leur métadonnées.

Le rôle essentiel de la connectivité aux systèmes sources

Une couche de connectivité maline est donc constitutive du Smart Data Catalog. Pour une description plus poussée de la technologie de Zeenea en matière de connectivité, je vous renvoie de nouveau à notre précédent livre blanc, les 5 ruptures technologiques d’un data catalog de nouvelle génération. Rappelons simplement ici ses principales caractéristiques, elle est :

• Propriétaire – nous ne nous reposons pas sur une solution tierce, pour conserver son ultra-spécialisation sur la récupération de métadonnées.
• Distribuée – pour ne pas limiter la portée du catalogue.
• Ouverte – quiconque voulant l’enrichir peut développer simplement ses propres connecteurs.
• Universelle – elle permet de synchroniser n’importe quelle source de métadonnées

Cette production de métadonnées nécessite non plus simplement l’accès aux registres des systèmes sources, mais aux données elles-mêmes, qui vont être analysées par nos scanners pour enrichir automatiquement le catalogue.

À ce jour, nous produisons deux types de métadonnées :

• De l’analyse statistique qui permet de construire le profil des données – distribution des valeurs, taux de valeurs nulles, top valeurs, etc. (la nature de ces métadonnées dépend bien sûr du type natif des données analysées) ;

• De l’analyse structurelle pour déterminer le type fonctionnel de certaines données textuelles (email, adresse postale, numéro de sécurité sociale, code client, etc. – le système est extensible et personnalisable).

Le mécanisme d’inventaire doit lui aussi être malin

Outre la connectivité, qui permet d’alimenter automatiquement le catalogue avec les actifs contenus dans les différents systèmes, notre mécanisme d’inventaire est lui-même smart en plusieurs points :

• La détection des jeux de données s’appuie sur une grande connaissance des structures de stockage, notamment dans des contextes Big Data. Par exemple, un jeu de données IoT constitué de milliers de fichiers de mesures time series sera bel et bien identifié comme un jeu de données unique ;

• L’inventaire n’est pas par défaut directement intégré dans le catalogue, pour éviter d’importer des jeux de données techniques ou temporaires, dont la présence dans le catalogue est généralement inutile (soit parce-que les données ne sont pas exploitables, soit parce qu’elles sont redondantes) ;

• La sélection des actifs à importer dans le catalogue est elle- même assistée – nous nous efforçons d’identifier les objets les plus susceptibles d’intégrer le catalogue, en utilisant plusieurs approches complémentaires pour réaliser cette sélection.

Pour comprendre comment un inventaire de données “smart” (malin) renforce les capacités d’un data catalog, téléchargez notre eBook :

“Qu’est-ce qu’un Smart Data Catalog ?” dès maintenant!

Un métamodèle universel et statique ne peut être smart

Le nombre de métadonnées nécessaire pour exploiter efficacement les actifs informationnels peut être considérable. Et ces métadonnées seront spécifiques à chaque organisation, voire à des populations distinctes dans une même organisation. Par exemple, un business analyst ne cherchera pas nécessairement les mêmes informations qu’un ingénieur ou un responsable produit.

Partant de là, chercher à définir un métamodèle universel ne nous semble pas spécialement malin. En effet, un tel métamodèle devrait s’adapter à tous les contextes imaginables, tombant fatalement dans l’un des trois écueils classiques de l’universalisme :

• Un simplisme excessif, qui ne permettra pas à terme de couvrir tous les cas d’usage ;

• Un niveau d’abstraction excessif, potentiellement capable de s’adapter à de nombreux contextes mais au prix d’un apprentissage long et difficile des concepts – difficilement compatible avec le déploiement à grande échelle du catalogue ;

• Un niveau d’abstraction trop faible, qui oblige à multiplier les concepts concrets en combinant les notions issues d’un grand nombre de contextes différents – mais qui pour beaucoup seront inutiles dans un contexte particulier, compliquant inutilement le métamodèle, potentiellement au point de le rendre incompréhensible.

La métamodélisation Smart, selon nous, doit permettre d’adapter le métamodèle à chaque contexte, et de l’enrichir à mesure que les cas d’usage, ou le niveau de maturité de l’organisation se développent.

L’approche organique du métamodèle

Un métamodèle est un domaine de connaissance, et la structure formelle d’un modèle de connaissance porte le nom d’ontologie.

Une ontologie définit un ensemble de classes d’objets, leurs attributs et les relations qu’elles peuvent avoir entre elles. Dans un modèle universel, l’ontologie est statique – les classes, les attributs et les relations sont prédéfinis, avec un niveau d’abstraction et de complexité variable.

Chez Zeenea, nous avons choisi de ne pas nous appuyer sur une ontologie statique, mais plutôt de nous reposer sur un graphe de connaissance complètement évolutif.

Au démarrage, le métamodèle est donc volontairement très simple – il ne comprend qu’une poignée de types, représentant les différentes classes d’actifs informationnels (sources de données, jeux de données, champs, tableaux de bords), chacun doté de quelques attributs que nous jugeons universels (nom, description, contacts).

Ce métamodèle de base est complété automatiquement par les métadonnées techniques extraites des sources de données, qui varient en fonction de la technologie sous- jacente (les métadonnées techniques d’une table dans un data warehouse ne sont pas strictement les mêmes que celles d’un fichier parquet dans un data lake).

Cette métamodélisation que l’on pourrait qualifier d’organique, est selon nous la façon la plus smart d’aborder la problématique de l’ontologie dans un data catalog. Elle présente en effet plusieurs intérêts majeurs :

• Le métamodèle peut être complètement adapté à chaque contexte, s’appuyant sur une modélisation souvent pré- existante, intégrant la nomenclature et la terminologie maison sans nécessiter un cycle d’apprentissage long et coûteux ;

• Le métamodèle n’a pas besoin d’être intégralement défini pour démarrer l’exploitation du catalogue – il suffira de se focaliser sur les quelques classes d’objets et les quelques attributs nécessaires pour couvrir les premiers cas d’utilisation, puis d’augmenter ce modèle à mesure que la portée du catalogue se développe ;

• Les feedbacks utilisateurs pourront être intégrés progressivement, améliorant l’adoption du catalogue, et par conséquent le retour sur investissement de la gestion de métadonnées.

L’ajout d’attributs fonctionnels au métamodèle pour faciliter la recherche

Cette approche de la métamodélisation présente des avantages massifs, mais également un inconvénient majeur : le métamodèle étant complètement dynamique, il est difficile pour le moteur d’en comprendre la structure, et par conséquent d’assister efficacement les utilisateurs pour l’alimenter et le consommer (ces deux sujets étant au cœur du Smart Data Catalog).

Une partie de la solution concerne le métamodèle, et notamment les attributs de l’ontologie. Classiquement, les attributs d’un métamodèle sont définis par leur type technique (une date, un chiffre, une chaîne de caractères, une liste de valeurs, etc.). Chez Zeenea, la bibliothèque de types contient bien sûr ces types techniques, mais également des types fonctionnels – un niveau de qualité, un niveau de confidentialité, un caractère personnel, etc.

Utiliser ces types fonctionnels permet au moteur Zeenea de mieux comprendre l’ontologie pour affiner ses algorithmes et adapter la représentation de l’information.

Pour comprendre comment un métamodèle “smart” (malin) renforce les capacités d’un data catalog, téléchargez notre eBook :

“Qu’est-ce qu’un Smart Data Catalog ?” dès maintenant!

Le Data Catalog d’une organisation permet de valoriser l’ensemble de son patrimoine de données en s’appuyant notamment sur deux types d’informations – d’une part les informations purement techniques synchronisées automatiquement depuis les sources ; et d’autre part les informations métier qui sont issues du travail des Data Stewards. Ces dernières sont mises à jour manuellement et apportent ainsi leur lot de risques à l’échelle de l’organisation.

Un système de permissions est alors essentiel afin de définir et hiérarchiser les droits d’accès des utilisateurs du catalogue. Dans cet article, nous détaillons les caractéristiques fondamentales et les approches possibles pour bâtir un système de permissions efficace, ainsi que la solution mise en place dans le Data Catalog Zeenea.

Le système de permissions : un outil indispensable à l’échelle de l’organisation

Pour que l’utilisateur du Data Catalog ait confiance dans les informations qu’il consulte, il est essentiel que la documentation des objets catalogués soit pertinente, de qualité et surtout fiable. Vos utilisateurs doivent facilement trouver, comprendre et exploiter le patrimoine de données à leur disposition. 

Origine des informations du catalogue et automatisation 

Un catalogue de données intègre généralement deux types d’informations. D’une part, on trouve des informations purement techniques qui proviennent directement de la source de données. Chez Zeenea, ces informations sont synchronisées de façon complètement automatisée et continue entre le Data Catalog et chaque source de données, pour en garantir la véracité et la fraîcheur. D’autre part, le catalogue contient toute la documentation métier ou organisationnelle (majoritaire), qui est quant à elle issue du travail des Data Stewards. Ces informations ne peuvent pas être automatisées, elles sont mises à jour manuellement par les équipes de data management de l’entreprise.

Le système de permissions comme prérequis à l’utilisation du catalogue

C’est pour gérer cette deuxième catégorie d’informations que le catalogue doit comporter des mécanismes de contrôle de la saisie. En effet, il n’est pas souhaitable que n’importe quel utilisateur du Data Catalog de votre organisation puisse créer, éditer, importer, exporter ou même supprimer des informations sans avoir été crédité des autorisations préalables. Un système de gestion des permissions des utilisateurs est alors un prérequis, c’est lui qui joue ce rôle de garde fou. Il définit les droits d’accès des utilisateurs.

Les 3 caractéristiques fondamentales du système de permissions d’un Data Catalog

La mise en place d’un système de permissions à l’échelle de l’entreprise est soumise à de nombreuses attentes qui vont devoir être prises en compte pour sa conception même. Parmi elles, nous avons choisi dans cet article de nous concentrer sur trois grandes caractéristiques fondamentales d’un système de permissions : son niveau de granularité et de flexibilité, sa lisibilité et son auditabilité, ainsi que sa simplicité d’administration.

Granularité et flexibilité

Tout d’abord, un système de permissions doit avoir le bon niveau de granularité et de flexibilité. Certaines actions doivent être disponibles sur l’ensemble du catalogue afin d’en faciliter l’usage. D’autres actions doivent être restreintes à certaines parties du catalogue uniquement. Certains utilisateurs auront des droits globaux liés à tous les objets du catalogue, d’autres seront limités à ne pouvoir éditer que le périmètre qui leur aura été attribué. Le système de permissions doit donc permettre cet éventail de possibilités allant de la permission globale à la finesse d’un objet dans le catalogue. 

Chez Zeenea par exemple, les clients sont de toutes tailles, avec des niveaux de maturité sur les sujets de la gouvernance data très hétérogènes. Certains sont des Start-ups, d’autres de grandes entreprises. Certains ont une culture data déjà bien intégrée dans leur processus, d’autres au contraire n’en sont qu’au début de leur démarche d’acculturation data. Le système de permissions doit donc être suffisamment flexible pour s’adapter à toutes les typologies d’organisations.

Lisibilité et auditabilité

Ensuite, un système de permissions doit être lisible et facile à suivre. Lors d’un audit, ou d’une revue des permissions du système, un administrateur qui explore un objet doit être en mesure de rapidement savoir qui est en capacité de le modifier. Inversement quand un administrateur regarde le détail des droits d’un utilisateur, il doit rapidement être capable de déterminer le périmètre qui lui est attribué et ses actions autorisées sur celui-ci. 

Cela permet de s’assurer simplement que les bonnes personnes ont accès aux bons périmètres, et ont le bon niveau de permission par rapport à leur rôle dans l’entreprise. 

Ne vous-êtes vous jamais retrouvé face à un système de permissions et d’autorisations tellement complexe qu’il était impossible de comprendre pourquoi un utilisateur avait le droit de consulter une information ? Ou au contraire en était incapable ?

Simplicité d’administration

Enfin, un système de permissions doit être résilient face à l’augmentation du volume du catalogue. On sait aujourd’hui que nous vivons dans un monde de données : 2,5 exaoctet de données étaient générées par jour en 2020 et on estime à 463 exaoctet le volume de données générées par jour en 2025. Nouveaux projets, nouveaux produits, nouveaux usages : les entreprises doivent faire face quotidiennement à l’explosion de leur patrimoine data.

Pour rester pertinent, un Data Catalog doit évoluer avec la data de l’entreprise. Le système de permissions doit alors absolument être résilient face à la modification de son contenu ou même suite aux mouvements de collaborateurs dans l’organisation.

Les différentes approches pour la conception d’un système de permissions d’un catalogue de données

Il existe différentes approches pour la conception du système de permissions d’un Data Catalog, qui répondent plus ou moins bien aux caractéristiques principales attendues et évoquées ci-dessus. Nous avons choisi d’en détailler trois dans cet article.

Le Crowdsourcing

Premièrement, l’approche crowd sourcing – on fait confiance au collectif pour s’auto-corriger. Une poignée d’administrateurs peuvent modérer le contenu et l’ensemble des utilisateurs peut contribuer à la documentation. Un système d’audit vient généralement compléter le dispositif pour s’assurer de ne pas perdre d’information par erreur ou malveillance. Dans ce cas, aucun contrôle a priori, mais une correction collective a posteriori. C’est typiquement le système choisi par des encyclopédies en ligne telles que Wikipedia. Ces systèmes sont dépendants du nombre de contributeurs et de leurs connaissances propres pour bien fonctionner, l’auto-correction ne pouvant être efficace que grâce au collectif. 

Ce système répond parfaitement au besoin de lisibilité – tous les utilisateurs ayant le même niveau de droit, il n’y a pas de question à se poser sur les droits d’accès de chacun. Il est également simple à administrer – tout nouvel utilisateur possède le niveau de droit commun à tous, et tout nouvel objet dans le Data Catalog est accessible par tous. En revanche, il n’existe pas de possibilité de gérer la granularité des droits. Tout le monde peut tout faire et tout voir.

La permission rattachée à l’utilisateur 

Seconde approche pour la conception du système de permissions : les solutions où le périmètre est attaché au profil de l’utilisateur. Lors de la création d’un utilisateur dans le Data Catalog, les administrateurs lui assignent un périmètre qui définit les ressources que celui-ci aura la possibilité de voir et de modifier. Dans ce cas, tous les contrôles sont faits en amont et un utilisateur ne peut pas avoir accès à une ressource par inadvertance. C’est le type de système d’un OS type Windows par exemple.

Ce système a l’avantage d’être très sûr, il n’y a aucun risque qu’une nouvelle ressource soit visible ou modifiable pour les personnes qui n’en auraient pas le droit. Ce système répond également au besoin de lisibilité : pour chaque utilisateur, toutes les ressources qui lui sont accessibles sont simples à retrouver. Le niveau de granularité attendu est également bon, puisqu’il est possible d’attribuer ressource par ressource les données du système. 

En revanche, l’administration en est plus complexe – à chaque nouvelle ressource ajoutée au catalogue, il faut l’ajouter aux périmètres des utilisateurs concernés. Il est possible de pallier cette limitation en créant des périmètres dynamiques. Pour ce faire on peut définir des règles qui attribuent les ressources aux utilisateurs, par exemple tous les fichiers de type PDF lui seront accessibles. Mais des règles contradictoires peuvent facilement apparaître, compliquant alors la lisibilité du système.

La permission rattachée à la ressource 

Dernière grande approche pour concevoir le système de permissions d’un Data Catalog : les solutions où les actions autorisées sont attachées à la ressource à modifier. Pour chaque ressource, les permissions possibles sont définies utilisateur par utilisateur. Ainsi c’est elle qui porte sa propre liste de permissions. En regardant la ressource, il est alors possible de savoir tout de suite qui peut la consulter ou l’éditer. C’est par exemple le type de système d’un OS de type UNIX.

Le besoin en lisibilité est parfaitement comblé – un administrateur voit immédiatement les droits des différents utilisateurs en consultant la ressource. Idem pour le besoin en granularité – cette approche permet de donner des droits au niveau le plus macro par un système d’héritage, ou au niveau le plus micro directement sur la ressource. Enfin, côté facilité d’administration, il est nécessaire de rattacher chaque nouvel utilisateur aux différentes ressources ce qui est potentiellement fastidieux. Il existe cependant des systèmes de groupe qui permettent de mitiger cette complexité.

Le modèle de permissions du Data Catalog Zeenea : simple, lisible et flexible

Parmi ces approches, détaillons celle qui a été choisie par Zeenea et comment elle est appliquée.

L’approche au niveau de la ressource privilégiée

Récapitulons les différents avantages et inconvénients de chacune des approches abordées précédemment. Dans les deux systèmes de permissions rattachées à la ressource ou à l’utilisateur, le besoin en granularité est correctement appréhendé – ces systèmes permettent d’assigner des droits ressource par ressource. En revanche, dans le cas du crowdsourcing, la philosophie de base est que tout le monde peut accéder à tout.

La lisibilité ensuite est clairement plus simple à suivre dans les systèmes de type crowdsourcing ou pour ceux dans lesquels les permissions sont rattachées à la ressource. Elle reste convenable dans les systèmes où les permissions sont rattachées à l’utilisateur mais souvent au détriment de la simplicité d’administration.

Enfin, la simplicité d’administration est très optimisée pour l’approche crowdsourcing et dépend alors de ce qu’on va le plus modifier – la ressource ou bien les utilisateurs.

 Le besoin de granularité n’étant pas respecté dans l’approche crowdsourcing, nous l’avons éliminée. Il nous restait alors deux solutions : la permission rattachée à la ressource ou la permission rattachée à l’utilisateur. La lisibilité étant un peu meilleure sur les permissions rattachées à la ressource, et étant donné que le contenu du catalogue va évoluer plus vite que le nombre d’utilisateurs, l’option des permissions attachées à l’utilisateur nous semblait la moins pertinente.

L’option que nous avons privilégiée chez Zeenea est donc la troisième : les permissions sont rattachées aux ressources.

Le fonctionnement du système de permissions du Data Catalog Zeenea

Dans le catalogue de données Zeenea, il est possible de définir pour chaque utilisateur s’il aura le droit de manipuler les objets de l’ensemble du catalogue, un ou plusieurs types d’objets, ou uniquement ceux de son périmètre. Ainsi la granularité la plus fine est permise, mais également des rôles plus globaux. Par exemple, des “super-stewards” pourraient avoir la permission d’agir sur des parties entières du catalogue, comme le glossaire.

On associe ensuite une liste de dépositaires à chaque objet du catalogue, c’est-à-dire les responsables de la documentation de cet objet. Ainsi, simplement en explorant les détails de l’objet, on peut immédiatement savoir à qui s’adresser pour corriger, compléter la documentation, ou encore répondre à une question sur celle-ci. Le système est donc lisible et simple à comprendre. Les périmètres d’actions des utilisateurs sont déterminés avec précision grâce à un système granulaire, jusqu’à l’objet du catalogue.

Lorsqu’un nouvel utilisateur est ajouté au catalogue, il faut alors lui définir son périmètre d’actions. Pour le moment, cette configuration se fait en passant par une édition en masse des objets. Afin de simplifier encore la gestion, il sera bientôt possible de définir des groupes d’utilisateurs responsables, pour qu’à l’arrivée d’un nouveau collaborateur il n’y ait plus besoin de l’ajouter nominativement sur chaque objet dans son périmètre. Il suffira alors de l’ajouter au groupe responsable, et son périmètre lui sera automatiquement attribué.

Enfin, nous avons volontairement fait le choix de ne pas implémenter de workflow de validation de la documentation dans le catalogue. Nous pensons en effet que la responsabilisation des équipes est une des clés de la réussite d’une démarche de mise en place d’un Data Catalog. C’est pourquoi le seul contrôle que nous mettons en place est celui qui détermine les droits de l’utilisateur et son périmètre. Une fois ces deux éléments déterminés, les responsables de la documentation sont libres de leurs actions ! Un journal d’événements sur les modifications afin de permettre une auditabilité complète, ainsi qu’un système de discussion sur les objets, permettant à tous de proposer des évolutions ou de signaler des erreurs sur la documentation, viennent compléter le dispositif.

Si vous souhaitez en savoir davantage sur notre modèle de permissions, ou pour obtenir plus d’informations au sujet de  Data Catalog :

Posséder d’importants volumes de données, c’est bien. Les exploiter au quotidien avec pragmatisme, intelligence et finesse, c’est mieux ! Pour y parvenir, il faut distiller une véritable culture data au sein de votre entreprise. Le socle de cette culture, c’est la data curation.

90% des données mondiales ont été créées au cours des deux dernières années. Avec la croissance exponentielle des appareils connectés, les entreprises seront confrontées à une funeste réalité : notre capacité à créer des données surpassera de très loin notre capacité à les gérer et à les exploiter. 

Et cela ne risque pas de s’arranger ! Selon les estimations publiées dans le Digital Economy Compass 2020 de Statista, le volume annuel de données numériques créées à l’échelle mondiale a été multiplié par plus de vingt au cours de la dernière décennie et dépassera le seuil des 50 zettaoctets en 2021 !

Dans ce contexte, rien d’étonnant à ce que la plupart des entreprises ne soient actuellement en mesure d’analyser que 12 % des données dont elles disposent ! Car, derrière la collecte, le stockage et la sécurisation de la donnée, il y a surtout la valeur business que l’on est susceptible d’en tirer.

C’est tout l’enjeu auquel répond le concept de Data Curation (curation des données en français) : l’étape essentielle pour exploiter le potentiel d’un patrimoine de données abondant d’une organisation. 

Data Curation : une tentative de définition

Si l’on s’en réfère à la définition qu’en donne l’INIST (Institut de l’Information Scientifique et Technique) qui est rattaché au CNRS, 

« On désigne par curation l’ensemble des activités et opérations nécessaires à une gestion active des données de recherche numérique, tout au long de leur cycle de vie. L’objectif est de les rendre accessibles, partageables et réutilisables de façon pérenne. Trois intervenants peuvent être identifiés dans le cycle de vie de données : les créateurs, le plus souvent les chercheurs, les « curateurs » et les utilisateurs ». 

En d’autres termes, la curation de données est une tâche qui consiste à identifier dans un catalogue de données celles qui peuvent être valorisées, exploitées et dans un deuxième temps, les mettre à la disposition des utilisateurs susceptibles d’en tirer les meilleurs enseignements.

Pour mettre en place une Data Curation efficace et pertinente, il faut commencer par s’adosser sur une cartographie précise de la donnée disponible. Cette cartographie initiale, constitue le socle d’une gouvernance des données pragmatique et opérationnelle. 

Une fois les règles de gouvernance établies, c’est vers l’utilisateur des données qu’il faut concentrer toutes les attentions. La Data est un minerai qui ne vaut que s’il est convenablement valorisé. Or, cette valorisation doit être pensée comme une réponse à des besoins de l’utilisateur.

C’est ce dernier qui est à l’origine du projet de curation des données. 

Un processus itératif et continu au service de l’exploitation de la data, distinct de toutes les tâches essentielles à la gouvernance des données (de la gestion de la qualité en passant par leur protection et jusqu’à la gestion du cycle de vie des données).

Data Curation : des prérequis indispensables, des bénéfices indéniables

La Data Curation est une perspective de développement rapide et massif de la culture data au sein de votre organisation. La constitution d’un plan de gestion et de curation des données permet tout d’abord de recenser les données produites. Il est alors possible de sélectionner les plus pertinentes et de les enrichir des métadonnées nécessaires à leur compréhension et à leur réutilisation, y compris par des utilisateurs métier.

Chacun dans l’entreprise peut alors, fonder ses choix, ses décisions, ses stratégies et méthodes sur la base d’un recours systématique à la donnée, sans avoir à disposer de compétences spécifiques.

L’objectif : créer les conditions d’un recours systématique à la data pour fonder tout projet, toute démarche, et ne pas limiter son exploitation aux seules équipes Data Science ou expertes en matière de données.

Pour déployer efficacement votre stratégie de curation des données, vous devrez donc, vous appuyer sur des éléments essentiels à la bonne gestion de vos actifs data. Le cœur du réacteur ne se cantonne pas aux data catalogs ! 

S’ils sont indispensables et découlent directement de votre travail de cartographie de la data, la gouvernance des métadonnées joue de son côté, un rôle encore plus crucial. Grâce à ces métadonnées, les utilisateurs peuvent plus facilement interagir avec les portefeuilles de données et ce, en langage naturel. 

Grâce à la curation des données, inscrivez pour de bon dans une dynamique data-driven !

Un Data Catalog est complexe mais pas compliqué

Cette dernière proposition découle assez logiquement des précédentes, et servira de conclusion à ce document.

Nous voyons trop de projets de Data Catalog qui tournent au projet interminable de gouvernance des données, et cherchent à régler trop de problèmes d’un seul coup – au détriment de ceux qu’un Data Catalog peut régler très rapidement. Une fois débarrassé de tout ce qui l’alourdit,

le déploiement d’un Data Catalog est l’affaire de quelques jours, et non de quelques mois, pour commencer à produire de la valeur.

Le service rendu par un Data Catalog n’est pas compliqué. Dans sa version la plus épurée, un Data Catalog se présente comme une simple barre de recherche, dans laquelle n’importe quel utilisateur peut saisir quelques mots clé (voire une question en langage naturel), et obtenir une liste de résultats dont les 5 premiers éléments contiennent l’objet le plus pertinent correspondant
à sa recherche, puis disposer de toute l’information dont il a besoin pour consommer les données (pensez à un moteur de recherche web, ou à un site de vente en ligne).

Cette simplicité est fondamentale pour assurer l’adoption du catalogue par les équipes data.

Facialement, le Data Catalog doit être une solution très simple, à l’ergonomie très épurée. Il n’en reste pas moins, qu’à l’instar de n’importe quel moteur de recherche ou de recommandation, la complexité sous-jacente est très forte.

La bonne nouvelle, c’est que traiter cette complexité n’est pas à votre charge, mais précisément à celle du vendeur de la solution.

Chez Zeenea, nous investissons beaucoup sur la structure de l’information (pour construire un graphe de connaissance sémantique), sur l’automatisation et sur le moteur de recherche et de recommandation. Cette complexité n’est pas visible, et constitue la vraie valeur d’un Data Catalog.

L’obsession pour la simplicité est au cœur des valeurs de Zeenea. Chaque fonctionnalité que nous décidons d’ajouter au produit doit répondre affirmativement à l’une des deux questions suivantes :

• La fonctionnalité permet-elle de déployer plus rapidement le catalogue dans l’organisation?
• La fonctionnalité permet-elle aux équipes data de trouver plus rapidement l’information dont elles ont besoin pour mener à bien leurs projets?

A défaut de satisfaire fortement à l’une ou l’autre de ces exigences, les fonctionnalités sont écartées.

Le résultat est que vous pouvez bel et bien connecter Zeenea à vos systèmes opérationnels, configurer et alimenter un premier métamodèle, puis ouvrir le système aux utilisateurs finaux en quelques jours.

Il faudra bien sûr ensuite itérer, étendre, compléter le métamodèle, intégrer d’autres systèmes, etc. Mais la création de valeur est immédiate.

Take Away

 Corollaire de la recherche de simplicité, le Data Catalog n’a pas à être une solution hors de prix.

C’est vrai pour le coût d’implémentation – déployer un catalogue connecté ne nécessite pas des milliers d’heures de travail. Nous vous proposons un programme de déploiement sur 3 à 6 semaines, couvrant la formation, l’intégration à vos systèmes et la mise au point d’un premier métamodèle pour 3000 euros.

C’est vrai également pour les coûts logiciels – oubliez les factures à 6 chiffres, Zeenea démarre à 18000 euros annuels, pour 5 data stewards, 50 consommateurs de données et 3 types de connecteurs.

Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !

Un Data Catalog doit s’appuyer sur l’automatisation

Certains vendeurs de Data Catalogs, dont la culture vient plutôt du monde de la cartographie, développent une rhétorique selon laquelle l’automatisation est un sujet secondaire, qui peut être adressé dans un second temps.

Ils vous expliqueront qu’il suffit de quelques imports de fichiers manuels, d’un peu d’huile coude et d’une communauté d’utilisateurs collaborant sur leur outil pour alimenter et utiliser le catalogue.

Un peu d’arithmétique permet de bien comprendre pourquoi cette approche est vouée à l’échec dans une organisation data-centric.

Un data lake actif, même de taille modeste, contient rapidement, sur ses différentes couches, plusieurs centaines voire milliers de jeux de données. A ces jeux de données viennent s’ajouter ceux des autres systèmes (bases de données applicatives, API diverses, CRMs, ERPs, no-SQL, etc.) que l’on souhaite généralement intégrer dans le catalogue.

Les ordres de grandeur dépassent rapidement plusieurs milliers voire dizaines de milliers de jeux de données. Chaque jeu de données contient à son tour plusieurs dizaines de champs (ou colonnes, si vous préférez). Jeux de données et champs représentent donc à eux seuls plusieurs centaines de milliers d’objets (on pourrait également comptabiliser les autres actifs: modèles ML, tableaux de bord, rapports, etc.).

Pour que le catalogue soit utile, il ne suffit pas d’inventorier tous ces objets.

Il faut également leur associer toutes les propriétés (métadonnées) qui permettront aux utilisateurs finaux de trouver, comprendre et savoir exploiter ces actifs. Les métadonnées sont de plusieurs natures: informations techniques, classification métier, sémantique, sécurité, sensibilité, qualité, normes, usages, popularité, contacts, etc.

On parle donc là aussi, pour chaque actif, de plusieurs dizaines de propriétés. Faites le calcul: au final, il s’agit de millions d’attributs à définir, puis maintenir.

Une telle volumétrie à elle seule devrait disqualifier irrévocablement l’approche manuelle.

Mais ce n’est pas tout. Le stock d’actifs informationnels n’est pas statique. Il grossit en permanence. Dans une organisation data-centric, chaque jour, des jeux de données sont créés, d’autres sont modifiés ou déplacés.

Le catalogue doit refléter ces changements. A défaut, son contenu sera en permanence obsolète, et les utilisateurs finaux ne l’adopteront pas (qui ferait confiance à un catalogue dont le contenu est structurellement incomplet et faux?).

Si vous pensez que votre organisation est en mesure d’absorber la charge nécessaire pour maintenir le catalogue à jour, très bien. Sinon, nous vous invitons vivement à vérifier très tôt le niveau d’automatisation proposé par les différentes solutions que vous évaluez.

Que peut-on automatiser dans un Data Catalog?

En matière d’automatisation, la capacité la plus fondamentale, c’est l’inventaire. Un Data Catalog doit pouvoir scanner en permanence toutes vos sources de données, et mettre à jour automatiquement l’inventaire des actifs (jeux de données, structures et métadonnées techniques à minima) pour refléter la réalité opérationnelle des systèmes qui les hébergent.

Croyez-nous: un Data Catalog qui ne sait pas se connecter à vos sources de données deviendra vite inutile, car son contenu sera toujours douteux.

Une fois l’inventaire traité, la question suivante est de savoir comment automatiser l’alimentation du métamodèle. Sur ce plan, et au-delà des métadonnées techniques, une automatisation intégrale est difficilement imaginable.

Mais il reste possible de réduire de façon significative la charge de travail nécessaire à la maintenance du métamodèle.

La valeur de certaines propriétés (ou attributs) peut ainsi être déterminée en appliquant simplement des règles au moment de l’intégration des objets dans le catalogue (on sait par exemple que les jeux de données provenant de tel système appartiennent à telle classification métier, sont destinés à tel type d’usage, ou sont sous la responsabilité de tel individu).

Il est également possible de suggérer des valeurs de propriétés en utilisant des algorithmes plus ou moins sophistiqués (détection de types logiques, analyse sémantique, pattern matching sur le contenu du catalogue, etc.).

Enfin, il est souvent possible d’alimenter une partie du catalogue en s’intégrant aux systèmes produisant ou contenant de la métadonnées. Ce peut être le cas par exemple pour les mesures de qualité (qui peuvent être intégrées dans le catalogue au moment où elles sont réalisées), pour les informations de lineage (connues par votre pipeline ou votre ETL), pour votre ontologie métier (qui peut être gérée dans un autre logiciel spécialisé), etc. Pour que cette approche soit possible, le Data Catalog doit être ouvert, et proposer un jeu d’APIs complet permettant de mettre à jour les métadonnées depuis d’autres systèmes.

Take Away

Un Data Catalog recense des millions d’informations sur un patrimoine en mutation permanente.

Maintenir ces informations manuellement est virtuellement impossible, ou extrêmement coûteux. Sans automatisation au moins de l’inventaire, le contenu du catalogue sera en permanence douteux, et les équipes data ne l’adopteront pas.

Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !

Un Data Catalog n’est pas une solution de Modélisation Business 

Certaines organisations, souvent de grande taille, ont investi durant des années dans la modélisation de leurs processus métier et de leur architecture de l’information. Elles ont développé plusieurs couches de modèle (conceptuel, logique, physique) et mis en place une organisation permettant de maintenir et diffuser ces modèles à certaines populations (experts métier et IT principalement).

Je ne doute absolument pas de la valeur de ces modèles.

Ils jouent un rôle clé dans l’urbanisation, la définition de schémas directeurs, le pilotage du SI et la conformité réglementaire. Mais on doute radicalement de la capacité des outils de modélisation à fournir un Data Catalog décent.

Il y a là aussi un phénomène de marché: certains acteurs historiques de la modélisation métier cherchent à élargir leur offre en se positionnant sur le marché du Data Catalog. Après tout, ils gèrent déjà un grand nombre d’informations sur l’architecture physique, les classifications métier, les taxonomies d’actifs, les glossaires et ontologies, le lignage des informations, les processus et rôles, etc.

Mais je leur vois deux défauts à mon sens rédhibitoires.

Le premier est organique. Par nature, les outils de modélisation définissent des modèles, qui sont conçus par le haut (approche top- down) pour décrire l’organisation de l’information dans un SI. Aussi précis soit-il, un modèle reste un modèle: une représentation simplifiée de la réalité.

Ce sont des outils de communication très précieux dans beaucoup de domaines, mais il leur manque l’ancrage dans la réalité opérationnelle qui me semble indispensable pour tenir les promesses d’un Data Catalog (permettre aux équipes data de trouver, localiser, comprendre et savoir exploiter les jeux de données présents dans leur organisation).

Le second défaut est ergonomique.

Un outil de modélisation est un outil complexe, manipulant un nombre important de concepts abstraits, et qui demande une courbe d’apprentissage importante. C’est un outil d’expert.

On peut bien sûr imaginer des simplifications ergonomiques permettant de l’ouvrir à un public plus large. Mais la complexité intrinsèque de l’information ne disparaîtra pas. Comprendre l’information fournie par ces outils demande une maîtrise préalable des principes du modèle (classes d’objets, niveaux logiques, nomenclatures, plan d’urbanisation, etc.). C’est un effort conséquent pour les équipes data – et un effort dont l’intérêt est difficile à justifier sur le plan opérationnel.

La vérité, c’est que convertis en Data Catalog, les outils de modélisation souffrent d’un énorme problème d’adoption par les équipes opérationnelles (elles doivent faire des efforts conséquents pour apprendre à l’utiliser, pour finalement ne pas y trouver ce qu’elles cherchent).

Un prospect nous a récemment présenté le métamodèle qu’il avait conçu, en nous demandant s’il était possible de l’implémenter dans Zeenea. Dérivé de ses modèles métier, le métamodèle comprenait plusieurs dizaines de classes d’objets, et des milliers d’attributs. A la question, la réponse formelle était plutôt oui (le métamodèle de Zeenea est très souple).

Mais nous avons surtout passé du temps à le dissuader de se lancer sur cette voie: un métamodèle aussi sophistiqué risque selon moi de dérouter les utilisateurs finaux, et de faire échouer le projet de Data Catalog…

Faut-il pour autant oublier les modèles métier pour la mise en place d’un Data Catalog? Absolument pas.

Mais il faut se rappeler que les modèles métier existent pour répondre à certaines problématiques, et le Data Catalog à d’autres.

Certaines informations contenues dans les modèles permettent de structurer le catalogue et d’enrichir son contenu de façon très précieuse (je pense en particulier aux responsabilités, aux classifications et bien sûr aux glossaires métier). La bonne approche est donc de concevoir le métamodèle du catalogue en se focalisant exclusivement sur la valeur ajoutée aux équipes data (en se posant systématiquement la question suivante: cette information permet-elle de trouver, localiser, comprendre et exploiter correctement les données?), puis d’intégrer l’outil de modélisation et le catalogue afin d’automatiser l’alimentation de certains éléments du métamodèle déjà présents dans les modèles métier.

Take Away

 Aussi utiles et complets soient-ils, les modèles métier restent des modèles: ils reflètent imparfaitement la réalité opérationnelle des systèmes, et peinent à fournir un catalogue de données efficace.

Les outils de modélisation, ainsi que les modèles métier, sont trop complexes et trop abstraits pour être adoptés par des équipes data. Définissez le métamodèle de votre catalogue pour répondre aux questions des équipes data, et alimentez certains aspects du métamodèle en vous intégrant à vos modèles métier.

Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !

Un Data Catalog n’est pas une solution de Requêtage 

C’est une autre bizarrerie du marché du Data Catalog.

Plusieurs vendeurs, dont l’ambition initiale était de permettre leurs utilisateurs de requêter simultanément plusieurs sources de données, ont “pivoté” vers un positionnement de Data Catalog. S’ils ont pivoté, ce n’est pas pour rien.

L’émergence des Data Lakes et du Big Data les a menés dans une impasse technologique qui a anémié leur marché d’origine.

Un Data Lake est typiquement segment en plusieurs couches. La couche “raw” intègre les données sans transformation, dans des formats plus ou moins structurés, et des volumétries  normes (c’est le principe). Une seconde couche, que l’on va appeler “clean” va contenir plus ou moins les mêmes données, mais dans des formats normalisés, et après un peu de nettoyage.

Ensuite, il peut y avoir une ou plusieurs couches “business” dédiées aux usages: un data warehouse et un outil de visualisation pour l’analytique, un cluster Spark pour la data science, un système de stockage pour la distribution commerciale, etc. Dans ces couches, les données sont transformées, agrégées et optimisées pour les usages, et les outils qui supportent ces usages (outils de dataviz, notebooks, massive processing, etc.).

Dans ce paysage, un outil de requêtage universel en self-service n’est pas souhaitable. Il est bien sûr possible de monter une couche d’interprétation SQL au-dessus de la couche “clean” (style Hive), mais exécuter les requêtes reste une affaire de spécialistes. Les données sont très volumineuses et peu ou pas du tout indexées.

Laisser des utilisateurs définir leurs propres requêtes est très risqué : sur des systèmes on-prem, ils risquent d’écrouler le cluster en lançant une requête très coûteuse. Et sur le Cloud, ils risquent de faire exploser la facture. Sans compter les problématiques de sécurité et de sensibilité des données…

Quant aux couches “business”, elles sont généralement couplées des solutions spécialisées (par exemple, une combinaison Snowflake + Tableau pour l’analytique) qui proposent un outillage sécurisé très complet et très performant pour le requêtage self-service. Et qui sont déjà maîtrisés par les utilisateurs.

Leur marché se réduisant comme peau de chagrin, certains vendeurs de requêteurs multi-sources ont donc pivoté vers le Data Catalog; ils cherchent maintenant à convaincre que la capacité à  exécuter des requêtes fait de leur solution la Rolls du Data Catalog (et justifie leurs tarifs à 6 chiffres). Je vous invite vraiment à y réfléchir à deux fois…

Take Away

 Sur une architecture data moderne, la capacité à exécuter des requêtes depuis le Data Catalog est non seulement inutile, mais aussi très risquée (performance, coût, sécurité).

Les équipes data disposent déjà de leurs propres outils pour exécuter des requêtes sur les données qui leur sont destinées – et si ce n’est pas le cas, il faut songer à les équiper. Intégrer les problématiques d’accès aux données dans le déploiement du catalogue est le meilleur moyen d’en faire un projet long, coûteux, et décevant.

Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !