data quality

Les 7 mensonges des fournisseurs de Data Catalog – n°2- Un Data Catalog n’est pas une solution de DQM (Data Quality Management)

juin 21, 2021

Le marché du Data Catalog a beaucoup évolué depuis ses débuts, et ce composant est désormais identifié comme une brique essentielle dans le déploiement d’une stratégie data-centric.

Victime de son succès, ce marché a attiré un grand nombre d’acteurs opérant sur des marchés adjacents et qui ont revu leur positionnement marketing pour se présenter comme solution de Data Catalog.

En réalité, faibles sur les promesses du Data Catalog, ils cherchent à convaincre, avec un succès proportionnel à leurs moyens marketing, qu’un Data Catalog n’est pas simplement un outil de recherche ultra-performant destiné aux équipes data, mais une solution intégrée susceptible d’adresser tout un tas d’autres sujets.

C’est le discours de ces vendeurs de Data Catalog de la dernière heure que l’on souhaite déconstruire dans cette série d’articles.

Voici selon nous, les 7 principaux mensonges des vendeurs de Data Catalog :

  1. un Data Catalog est une plateforme de gouvernance des données,
  2. un Data Catalog permet de mesurer et piloter la qualité des données,
  3. un Data Catalog permet de gérer la conformité réglementaire,
  4. un Data Catalog permet de requêter directement les données,
  5. un Data Catalog permet de modéliser l’architecture logique et les processus métiers autour de la data,
  6. un Data Catalog est un outil collaboratif de cartographie et de gestion de métadonnées impossible à automatiser,
  7. un Data Catalog est un projet long, complex et très couteux.

Un Data Catalog n’est pas une solution de DQM (Data Quality Management)

 

Soyons une nouvelle fois clairs: chez Zeenea, nous ne sous-estimons pas l’importance de la qualité des données pour le succès des projets data, bien au contraire. Il est juste absurde de confier ce sujet à une solution qui, par nature, ne sera pas en mesure de réaliser les contrôles au bon moment.

Il existe une règle élémentaire en matière de contrôle qualité, une règle que l’on peut appliquer virtuellement dans tous les domaines où la qualité est un enjeu, que ce soit une chaîne de production industrielle, une organisation de développement logiciel ou la cuisine d’un grand restaurant: plus un défaut est détecté tôt, moins il est coûteux à corriger.

On imagine mal un constructeur automobile se contenter d’une batterie de tests une fois le véhicule achevé, quand tout le coût de production a été engagé, quand l’occurrence d’un défaut a le prix le plus élevé. Non. Chaque pièce fait l’objet de contrôles poussés, chaque étape de la production est testée, les pièces défectueuses sont écartées avant même d’être intégrées dans le circuit de production, et la chaîne complète peut être stoppée si des problèmes de qualité sont détectés à l’une quelconque de ses étapes. Quant aux problèmes de qualité à proprement parler, ils sont corrigés le plus en amont possible du processus de production – car c’est aussi en amont que les corrections sont les moins coûteuses et les plus durables.

 

« Dans une organisation data moderne, la production de données repose sur les mêmes principes. Il s’agit d’une chaîne d’assemblage destinée à alimenter des usages à haute valeur ajoutée. Le contrôle de la qualité doit être fait à chacune des étapes, et les corrections réalisées le plus en amont possible. La nature et le niveau des contrôles sont au demeurant très dépendants des usages (ou, pour être précis, du coût de la non qualité, qui est lui dépendant des usages). »

 

Si vous traitez de la donnée, vous disposez nécessairement de pipelines destinés à alimenter vos usages. Ces pipelines comprennent potentiellement des dizaines d’étapes – acquisition des données, nettoyage, transformations diverses, combinaison avec d’autres sources, etc. Pour développer ces pipelines, vous utilisez probablement une batterie de technologies, allant de scripts maisons à de coûteux ETL, en passant par d’autres middlewares plus 10 ou moins exotiques.

C’est dans ces pipelines que vous devez insérer et piloter vos mesures qualité, le plus tôt possible, en les adaptant aux enjeux du produit fini. Mesurer uniquement le niveau de qualité des données finales est non seulement absurde, c’est également fondamentalement inefficace.

Partant de ce constat, il est difficile de déterminer comment un Data Catalog (dont le rôle est d’inventorier et documenter tous les jeux de données potentiellement exploitables afin d’en faciliter la découverte et la consommation) pourrait se révéler un outil efficace de mesure et de pilotage de la qualité.

Un Data Catalog travaille sur le stock (les jeux de données disponibles), vise l’exhaustivité (tous les systèmes contenant des données) et devrait être aussi peu intrusif que possible afin de se déployer rapidement dans toute l’organisation.

Une solution de DQM travaille sur les flux (les pipelines), se focalise sur les données de production (celles effectivement utilisées dans des usages) et est par construction intrusive et longue à déployer. Et je ne vois pas d’architecture logicielle permettant de combiner efficacement les deux problématiques sans dégrader radicalement l’une ou l’autre de ses promesses.

Les vendeurs de Data Catalogs qui promettent de résoudre au passage vos problèmes de qualité sont à notre sens dans une impasse – il est peu probable qu’ils aillent au-delà d’une démo alléchante. Quant aux vendeurs de DQM (qui vendent également souvent des ETLs), leurs solutions sont trop complexes et coûteuses à déployer pour se transformer en catalogues crédibles.

La bonne nouvelle, c’est que l’orthogonalité entre les problématiques de catalogage et celles de contrôle qualité permet de faire cohabiter facilement des solutions spécialisées dans chaque domaine, sans chevauchement de responsabilités.

 

En effet, si un Data Catalog n’a pas vocation à réaliser les contrôles qualité, il peut en revanche exploiter avec beaucoup de bénéfices les informations sur la qualité des jeux de données qu’il contient.

 

Le Data Catalog exploite cette métadonnée en premier lieu pour diffuser l’information (et les éventuelles alertes qui l’accompagnent) auprès de consommateurs avérés ou potentiels de ces jeux de données; il peut également tirer bénéfice de ces informations pour ajuster son moteur de recherche et de recommandation et orienter les utilisateurs vers les jeux de données les plus qualitatifs.

Et il suffit de quelques APIs pour intégrer à peu de frais les deux solutions…

 

Take Away

La qualité des données s’évalue le plus tôt possible dans les pipelines d’alimentation de vos usages.

Le rôle d’un Data Catalog n’est pas de réaliser les contrôles qualité, juste de diffuser le plus largement possible le résultat de ces contrôles. Par nature, un Data Catalog est une mauvaise solution de DQM, et les solutions de DQM sont des Data Catalog médiocres ou trop complexes. L’intégration entre une solution de DQM (ou un système ad hoc) et un Data Catalog devrait être très simple, et constitue l’approche la plus pragmatique.

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

zeenea logo

At Zeenea, we work hard to create a data fluent world by providing our customers with the tools and services that allow enterprises to be data driven.

zeenea logo

Chez Zeenea, notre objectif est de créer un monde “data fluent” en proposant à nos clients une plateforme et des services permettant aux entreprises de devenir data-driven.

Be(come) Data Fluent

Read the latest trends on big data, data cataloging, data governance and more on Zeenea’s data blog.

Join our community by signing up to our newsletter!

Devenez Data Fluent

Découvrez les dernières tendances en matière de big data, data management, de gouvernance des données et plus encore sur le blog de Zeenea.

Rejoignez notre communauté en vous inscrivant à notre newsletter !

LET’S GET STARTED

Make data meaningful & discoverable for your teams

Démarrer MAINTeNaNT

Donnez du sens à votre patrimoine de données