Comment adresser conjointement Data Quality & Data Observability ?

Introduction

Que ce soit dans des articles (spécialisés ou non) ou en contexte professionnel, il n’est pas rare de voir employés à la place de l’autre les concepts de « data observability » et de « data quality ». Si le raccourci peut parfois se comprendre, banaliser cet amalgame peut s’avérer nuisible à la longue : si les deux disciplines sont hautement connectées et complémentaires, il est très important de les distinguer afin qu’elles puissent apporter leurs véritables (et notables) valeurs ajoutées aux entreprises et aux métiers. Cet article se propose donc d’opérer tout d’abord un focus sur chacune des deux matières avant d’illustrer en quoi leur association peut apporter des bénéfices considérables pour toute organisation.

Data Quality : « Business oriented by design »

Au début était la Data Quality

S’il est un thème qui figure immanquablement en tête des problématiques data à adresser au sein d’une organisation, c’est bien la qualité des données. A écouter les équipes projets, les data scientists, les data analysts, tous leurs maux trouvent leur origine dans le manque de fiabilité des données qu’ils sont censés manipuler. Le sujet ici n’est pas de débattre du bien-fondé de ce réflexe pavlovien (spoiler : nombre des causes-racines de ces problèmes remontés ne sont en fait pas liées à la qualité), notre point ici est de mettre en exergue le fait qu’aujourd’hui la qualité des données est LE sujet de préoccupation principal des entreprises « data driven ».

En enfonçant cette porte-ouverte, notre propos vise à rappeler que pour de bonnes ou mauvaises raisons, les acteurs data ont tendance à tout ramener à la Data Quality : côté positif, la sensibilisation a fini par payer et le sujet est maintenant pris au sérieux (« Garbage in, garbage out ») ; côté négatif, la discipline ainsi que ses enjeux et objectifs sont encore trop souvent mal cernés et compris.

La gestion de la qualité des données est façonnée pour servir le besoin métier

Cet article n’étant pas dédié à la seule Data Quality, nous allons donc nous efforcer de proposer une définition simple et claire de celle-ci : le Data Quality Management vise à fournir une donnée fiable et pertinente pour répondre aux besoins clairement identifiés et définis de ses consommateurs.
Cette définition volontairement lapidaire semble sommaire voire lacunaire mais pourtant tous les éléments sont là : le cap guidant en permanence toute initiative de data quality demeure toujours le besoin métier qui doit être analysé et compris systématiquement en premier lieu ; pour servir ces attentes business, il s’agit de définir quel scope data adresser, quelles problématiques/enjeux adresser en priorité quant à la qualité, fixer le niveau d’effort adéquat pour ne tomber ni dans la sur-qualité ni dans une remédiation superficielle et éphémère.

En d’autres termes :

• La démarche de Data Quality Management ne doit jamais être une fin en soi, c’est toujours un enjeu business qui guide et légitime notre démarche
  
• Il est clé de comprendre l’utilisation cible de la donnée pour savoir quelles dimensions de qualité traiter en priorité
  
• La qualité des données étant une démarche d’amélioration continue (et donc jamais achevée), il est capital de doser son effort pour se focaliser sur les initiatives qui aideront le plus le métier, c’est cela avoir une approche « fit for purpose ». Vous ne pourrez jamais traiter tous les problèmes de qualité, il faut savoir choisir ses batailles
• Il est toujours beaucoup plus facile d’identifier un problème de qualité que d’y remédier: pour cette 2° étape, une collaboration entre l’ensemble des acteurs liés à la donnée erronée est indispensable. Ceci inclut à la fois IT & Métier, équipes Data & opérationnels, équipes globales & locales, management & opérateurs de terrain, etc., soit un véritable défi pour parvenir à faire travailler ensemble toutes ces personnes.

Au risque d’énoncer une nouvelle évidence, une initiative de Data Quality réussie nécessite une compréhension claire et totale de l’utilisation des données par ses consommateurs : les praticiens DQ ont donc l’obligation d’échanger et collaborer étroitement avec les utilisateurs de la donnée afin de savoir quels éléments data superviser, afin de définir des métriques et KQIs (Key Quality Indicators) pertinents, afin de définir des process efficaces pour monitorer/alerter/comprendre/solutionner les problématiques de data quality.

C’est donc pour répondre à ces enjeux de façon rapide et efficace que le Data Quality Management est « business oriented by design ».

Mais si les projets de Data Quality Management monopolisent aujourd’hui encore une part substantielle des efforts pour améliorer la fiabilité et donc l’utilisation des données, des disciplines connexes et plus récentes prennent un réel essor depuis quelques années, à l’instar de la Data Observability.

Data Observability : agnostique quant à la valeur métier de la donnée

Pourquoi la Data Observability ?

Les raisons de l’émergence rapide de la Data Observability sont multiples. Tout d’abord, la multiplication des sources de données et la complexité croissante des architectures informatiques rendent la surveillance constante des flux de données cruciale. Du fait des interactions innombrables entre des briques data tout aussi nombreuses, il n’est plus possible d’opérer une supervision artisanale, soit non industrialisée et automatisée, sous peine d’être en perpétuelle réaction face aux avaries pouvant affecter les data pipelines. L’observability vise à passer d’une posture passive, subissant les événements, à une approche proactive et détectant au plus tôt et au plus près les anomalies de flux.

Plutôt que de se concentrer uniquement sur la qualité statique des données, cette discipline adopte une approche axée sur le monitoring en temps réel de la performance des flux de données et de la santé des données tout au long de leur cycle de vie, par exemple depuis la saisie d’une transaction dans un système de caisse jusqu’à sa consommation finale dans un reporting financier.

Elle agit donc comme un moyen de détection de toute dégradation au cours du transit des données via un ou plusieurs de ses piliers : Freshness, Volume, Schema, Lineage, Distribution, Availability, etc., (un focus sur ces dimensions fera l’objet d’un futur article dédié).

Comment instaurer et maintenir un dispositif d’Observability efficace ?

• Il va de soi que la première étape serait de définir les piliers d’observability prioritaires en fonction des besoins spécifiques des utilisateurs finaux. Il faudra donc commencer par l’analyse des incidents survenus afin d’identifier les problèmes les plus fréquents. Ensuite, consulter les parties prenantes pour connaître les dimensions les plus critiques pour l’usage qu’ils auront de la donnée. Enfin, en fonction des piliers prioritaires (Freshness, Volume, etc.), définir les métriques spécifiques à surveiller en priorité.
• Un outil de monitoring en temps réel est crucial pour avoir une analyse rapide et approfondie de la performance des ingestions des données : de nombreuses solutions d’observability existent aujourd’hui (Sifflet, MonteCarlo, etc.), de plus en plus puissantes et complètes.
  Cependant, il est nécessaire de renforcer ce monitoring par un système d’alertes automatiques et personnalisées. Ces alertes permettront la détection immédiate des problèmes et l’intervention rapide des équipes opérationnelles. Elles doivent être configurées pour différents niveaux de criticité afin d’assurer une réactivité proportionnée aux incidents.
  
• La mise en place d’un système d’observability implique la définition claire du processus à suivre et des rôles et responsabilités pour chaque étape du processus. Notamment, qui assurera la surveillance quotidienne des métriques définies, qui recevra les alertes en cas d’incident, quelles seront les actions à engager et les acteurs à solliciter selon la criticité du problème, etc. Il est primordial de co–définir ce processus avec toutes les parties prenantes pour garantir une mise en œuvre réussie et une adhésion généralisée.
• Il faut tenir compte de l’importance de la conduite du changement des utilisateurs finaux (que ce soient les équipes opérationnelles ou métier). Expliquer les outils et processus disponibles, les mettre en miroir vis-à-vis des attentes des métiers en termes d’observability, et mettre en avant l’importance, dans ce cadre, des tâches qu’ils doivent accomplir, etc.
  Toute cette démarche d’accompagnement et d’acculturation contribuera à une meilleure collaboration et réactivité.
• Évoluer avec les besoins business : l’observability est un chantier en amélioration continue. Il n’est pas rare de devoir itérer constamment sur les pratiques d’observability pour répondre aux évolutions des exigences métier et du SI.

Il est préférable que certaines de ces activités soient menées en parallèle, afin par exemple de ne pas définir des métriques incompatibles avec un processus d’alerting et de remédiation. Soyons agiles !

Deux disciplines indépendantes mais que les entreprises ont grand intérêt à associer

La Data Observability et la Data Quality sont bien deux disciplines distinctes, mais leur association peut grandement bénéficier aux entreprises en renforçant la fiabilité et la valeur de leurs données.

Au-delà de leurs dissemblances, examinons de plus près la complémentarité de ces deux démarches :

• Temporalités d’intervention différentes : la Data Quality se concentre sur l’assurance de la valeur métier de la donnée et implique des interventions sur le temps long du fait de la sollicitation d’acteurs nombreux et variés (acteurs orientés métier, Data Owner, Application Owner, etc.) tandis que la Data Observability permet une résolution plus rapide par des acteurs moins nombreux et bien identifiés (équipes techniques en charge des pipelines, Data Lake, APIs, etc.)
• Périmètre de remédiation différents sur le data lineage: alors que la Data Quality vise principalement à agir au niveau de la source de la donnée (la donnée pourra être corrigée en bout de chaine mais le problème demeurera), l’Observability focalise son champ d’action précisément entre le début et la fin du cycle de vie de la donnée.
  En d’autres termes, l’Observability adresse les flux de données entre source et cible, tandis que la Data Quality peut intervenir au niveau de la cible (exemple : datalake), en mode pompier, mais de façon plus souhaitable au niveau de la source (exemple : système transactionnel déployé dans un pays).
• Focalisation des data analysts sur les taches réellement prioritaires: en libérant les ressources existantes des tâches de monitoring constant des flux (grâce à l’automatisation de la supervision et de l’alerting), en facilitant de ce fait la résolution des problématiques de flux,  il devient plus aisé de consacrer davantage de temps à la remédiation des problématiques de qualité qui, elles, nécessitent un temps conséquent (pour comprendre la cause de chaque problème, pour définir et prioriser les solutions potentielles et enfin pour mettre en place les correctifs appropriés). Le tout avec des acteurs nombreux et variés, ce qui est moins fréquent pour les problématiques relatives aux data pipelines.

• Surveillance dynamique vs statique : nous le répétons, la Data Observability surveille la dynamique des flux de données, tandis que la Data Quality se concentre sur la qualité statique des données. En associant ces deux disciplines, les entreprises minimisent les risques liés à la fiabilité des données à la fois statiques et dynamiques, assurant ainsi une excellence globale de leur création à leur utilisation en temps réel.

Conclusion

Nos lecteurs auront deviné dès l’introduction de l’article que Data Observability et Data Quality sont hautement complémentaires et indissociables, cela ne surprendra personne : il est aujourd’hui patent que ces deux approches sont faites pour s’entrelacer afin de garantir à toute organisation des données maitrisées, fiables et utiles aux métiers.
En revanche, pour dépasser des lieux communs, il semble utile et salutaire d’adresser un avertissement aux entreprises souhaitant se lancer à bride abattue sur ces deux démarches : il est indispensable de toujours s’interroger sur les besoins de l’organisation et des métiers quant aux données qu’ils consomment avant de se lancer sur une de ces disciplines, à fortiori si l’on envisage de déployer de front les deux. Il est trop fréquent de voir échouer des initiatives DQ et/ou Observability faute de s’être posé les bonnes questions : aucune de ces deux approches n’est une fin en soi, c’est toujours le business que l’on doit servir in fine. Il est impératif de bien jauger la maturité data de l’organisation, de bien mesurer les coûts et les bénéfices attendus, etc., avant de lancer ce genre de chantier. Cela aussi participe de la Stratégie Data de l’organisation.