Dernière modification le 22 juin 2023

Cette revue est basée sur un ensemble de publications du mois de mai 2023, issues de sources en lien avec le sujet Data. A piocher suivant vos centres d’intérêts.

Pour ce mois de mai, une actualité toujours importante, deux thématiques qui ressortent : 1) Les tableaux de bord sont-ils des objets du passé ? 2) Le data management a un double problème : de connaissance des données et d’être à côté versus dans les données.

Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.

Sommaire :

Les tableaux de bords objets du passé ?
Les trois sphères du data management et le rôle clé des métadonnées – de l’étiquetage des données
L’actualité open data du mois
Utilisation des données de santé – la tension entre des données vitales et des données personnelles
La qualité des données revisitée : moderne ( ?), temps réel
Data literacy : quelles compétences à mobiliser, développer ?
L’IA s’invite sur tous les sujet data
Dans la suite de l’idée de burn out data … le problème de la data entropy
En vrac (régulation data – transferts de données, data et stockage quantique, open source outils BI, data ops, data temps réel, data citizen, EDA – Exploratory Data Analysis sur les données non structurées, interopérabilité des données)

Les tableaux de bords objets du passé ?

Source : https://www.dataversity.net/automated-remediation-can-make-dashboards-a-thing-of-the-past/

L’idée : avant les tableaux de bord (vue de haut niveau), définir quelles données mettre sous surveillance (et sous alertes), en temps réel et définir qui est capable de réaliser cette surveillance (connaissance et compétence) … avec sous-entendu la possibilité d’automatiser les problèmes détecter au travers de cette surveillance et de libérer.

Source : https://towardsdatascience.com/build-more-analyses-build-less-dashboards-a4789052e35d?source=rss—-7f60cf5620c9—4

Les idées :

Des décennies d’accumulation de tableaux de bord, en ont fait une primauté. Mais mesure-t-on bien leur efficacité ? Et en se rappelant aussi du passé et les dizaines de rapports imprimés et diffusés, qui finissaient directement au pilon !
Multiplier les tableaux de bord peut être confusant (voire un paramètre de plus dans l’infobésité, tous les tableaux de bord n’ont pas le même poids mais l’avalanche de tableaux de bord ne permet plus de les distinguer).
Un tableau de bord c’est bien, mais ce qui compte c’est l’interprétation qu’il en est fait. Il faut inverser l’effort mettre plus de moyens sur l’interprétation et moins sur la réalisation des tableaux de bord qui actuellement prennent toute la charge (avec l’éternel sujet de la charge de préparation des données qui accapare tout et en particulier la vraie valeur à savoir l’analyse/l’interprétation).
Les tableaux de bord, tels qu’ils sont majoritairement imaginés sont issus d’une construction bien définie et figée (choix des données, des indicateurs, des formes de représentation – data visualisation, de la fréquence de publication…). Cette logique ne peut pas tout couvrir en termes de besoin d’analyse (l’instabilité prend de plus en plus de place, de plus en plus de données sont potentiellement exploitables mais non sous contrôle IT, quand les tableaux de bord disent tout va bien – il peut se cacher une incertitude, une alerte non visible).
Il faut basculer la façon de travailler : penser l’analyse avant le tableau de bord, penser en parallèle des demandes ad hoc sur les données fréquentes (et réponse via le réflexe SQL), quelle interprétation est recherchée.
Une démarche structurée d’analyse basée sur la narration et en empruntant les réflexes agiles peut être une bonne attitude
L’optimisation au maximum des phases de préparations des données et de construction des tableaux de bord doivent également aider dans cette logique d’inversion de l’effort (basculer votre valeur, de la prouesse technique de traitement des données à la prouesse d’analyse) et d’agilité (et des nouveaux moyens – souvent self data – permettent cela).

Source : https://towardsdatascience.com/build-more-analyses-build-less-dashboards-a4789052e35d?source=rss—-7f60cf5620c9—4

Les trois sphères du data management et le rôle clé des métadonnées – de l’étiquetage des donnée

Source : https://www.dataversity.net/connecting-the-three-spheres-of-data-management-to-unlock-value/

Pour ses enjeux le data management a besoin de réconcilier les connaissances sur les données issues de trois sphères : la sphère des systèmes physiques supports aux données (schémas de données, flux, lineages, logs), la sphère modélisation des données (définition, terminologie – glossaire métier, modèles conceptuels de données, dictionnaire) et la sphère des processus et cas d’usage (utilisation des données).

Image by author : Willem Koenders
Figure 1: Three spheres driving insights and value creation in (meta-)data management.

Avec le constat habituel d’effort systématique de « retro engineering » de l’existant avant de s’attaquer au problème à traiter : d’où viennent les données, de quels systèmes, selon quelles définitions, avec quelle fiabilité, au sein de tel processus…

En s’appuyant sur des descriptions disparates, non toujours (rarement) à jour, via des sachants novices du fait de changements d’interlocuteurs…

L’article cite trois écueils à cette connaissance issues des trois sphères :

1) Absence de lien entre la vue physique (circulation des données par exemple) et la vue cas d’utilisation – processus (difficile d’identifier par exemple les répercussions d’un changement de part et d’autre – si je modifie telle données … quel impact ?)

2) Ignorer la modélisation des données : se tromper dans la lecture des données en n’employant pas la bonne définition, recréer des données pourtant déjà existantes mais mal connues, mal classées

3) Rester théorique : parler de domaines de données métier, d’objets métier sans être capable de faire le lien avec les systèmes physiques.

Comment connecter les trois sphères ? Le rôle clé des métadonnées (étiquettes)

Formaliser les métadonnées de la vue métier : sources de données qui alimentent les cas usages – processus, propriétaires des données, domaines métier concernés,
A partir des sources faire le lien avec les définitions, modèles des données
Etc.

Cela nécessite de se pencher sur la disponibilité d’un référentiel des métadonnées et comment alimenter ce référentiel (par description – exemple catalogage des données, par automatisation – traitements de logs de flux de données).

L’auteur met en avant les rôles nécessaires à cette gestion des métadonnées.

Image by author : Willem Koenders
Figure 4: Key data roles across the three spheres.

NB : ce qui saute aux yeux, c’est toute la complexité et l’énergie pour gérer cela ! … Rédhibitoire ?

D’où l’importance de penser au maximum la gestion des données (métadonnées – étiquettes sur les données) de façon intégrée (automatisée) et non pas « à côté » (c’est-à-dire via du déclaratif – des description apportées par des acteurs … avec tous les défauts connus : reflet exact de la réalité des traitements dans les systèmes, fraîcheur, perte de connaissance si absence – départ, décalage par rapport à des changements instruits dans les systèmes sans forcément mise à jour des descriptions…exemple changement d’une règle de gestion qui va influer la qualité des données).

Et d’où … la difficulté de rôle transverse – voir revue précédente d’avril sur le burn out des CDO (https://www.datassence.fr/2023/05/11/revue-data-du-mois-avril-2023/#_ftn1)

Et d’où l’intérêt d’une approche data mesh qui au-delà de la technique se positionne comme vue logique avec le rôle de la notion de domaine métier, de data product (qui va centraliser les métadonnées de description)…

En lien aussi avec ce sujet – voir cette source – tour d’horizon de solutions de data management : https://datacrossroads.nl/2023/05/30/data-management-it-tools-data-management-solutions/

Voir aussi l’idée d’encore d’un nouvel acteur data (en plus !) : https://www.journaldunet.com/solutions/analytics/1521141-analytics-engineer/

A suivre sur datassence.fr, l’idée contreproductive de la multiplication des rôles data, comme 3^ème organisation sur les données en plus de l’IT et des métiers et plus largement de gérer une vue (au sens large) sur les données « à côté » inefficace versus intégrée (au métier).

Voir aussi sur le problème d’une gestion par déclaration (« à côté ») des méta données : « In many organisations I have worked with, the metadata management tool is implemented as part of a project and then not maintained, hence becoming stale and unusable. » – Source https://towardsdatascience.com/3-simple-and-powerful-ways-this-ai-technique-will-transform-data-management-fe2b66fb9a03

Autres sujets du mois :

1) L’actualité open data du mois – toujours intéressante

https://www.opendatafrance.net/2023/05/02/lactualite-opendata-du-mois-12/

Avec l’initiative : « Données & Territoires :

Cartographie des enjeux de la donnée pour les collectivités et espace de ressources pour l’intégrer comme une composante essentielle dans la mise en oeuvre de l’action publique territoriale ».

https://programme-tnt.gitbook.io/donnees-territoires/ et de nombreuses ressources (guides, vidéos) en lien avec le cycle de vie des données (acquisition, circulation, exploitation, archivage).

2) Utilisation des données de santé – la tension entre des données vitales et des données personnelles

Voir le programme d’un débat qui a eu lieu le 22 mai https://calenda.org/1071831 (infrastructures de partage de données, les données synthétique comme solution ?)

Et avec les supports et vidéos ici : https://files.inria.fr/ipop/donnees-de-sante/programme/

Voir aussi en lien avec le sujet des données personnelles : comment contrôler ses données personnelles et la capture qu’en font les courtiers en données (data brokers) – l’offre d’Optery https://www.optery.com/ qui permet d’identifier où sont ses données personnelles chez quels opérateurs de données et comment les supprimer (rejoint des offres de types Deleteme et Privacybee) – et https://www.techcrunch.com/2023/05/08/optery-using-its-new-funding-to-evolve-from-data-broker-opt-outs-to-personal-info-platform/

3) La qualité des données revisitée : moderne ( ?), temps réel

Une sérier d’article de Datasciencecentral :

https://www.datasciencecentral.com/4-pillars-of-modern-data-quality/
https://www.datasciencecentral.com/top-4-benefits-of-modern-data-quality/
https://www.datasciencecentral.com/modern-data-quality-approach/

Quelques extraits :

1) Passer d’une vision technique (dédoublonner, traiter les valeurs manquantes, les défauts de formats) à une vision contextuelle – s’assurer que les données respectent le contexte d’interprétation (métier mais aussi de formalisation). On revient au principe de base, la qualité dépend de l’usage, et cet usage fait partie du contexte des données (qui les utilisent, pourquoi, avec quelle gouvernance, sous quelle définition, quelles nomenclatures sont mobilisées…).

2) Penser data products de la discipline qualité d’un produit à la qualité d’un produit data

(dans la logique data mesh et de l’idée de responsabilité des domaines métier par rapport à leurs data products).

Voir aussi l’article suivant qui met en avant le rôle de la gestion de versions (idée d’une étiquette version associée au cycle de vie des données et produits de données)

https://towardsdatascience.com/how-to-keep-track-of-data-versions-using-versatile-data-kit-f1916f18737e?source=rss—-7f60cf5620c9—4

3) Exploiter la capacité d’observation des données (data observability) – vue holistique sur les données dans le systèmes et capture des alertes à tous les endroits en termes de qualité (et appel à l’IA pour détecter ces alertes).

Image by https://www.datasciencecentral.com

4) Le rôle clé des métadonnées

5) Penser la qualité en continu (et de plus en plus nécessaire avec les besoins temps réel sur les données) – « continuous quality »

Voir aussi sur ce sujet l’article intéressant suivant :

https://hevodata.com/blog/real-time-anomaly-detection/ (rôle de l’IA, de la data observability…)

6) Basculer vers de nouveaux moyens self data et d’automatisation des traitements de données versus les limites de traitements de qualité de données par Excel (les solutions de fortune pour les problème de qualité de données fonctionnent très mal).

4) Data literacy : quelles compétences à mobiliser, développer ?

Les data peuvent aller de pair avec la pensée intuitive :

https://dataliteracy.com/an-illustrated-guide-to-data-literacy-use-your-intuition/

Le CR des ateliers culture données par Open Data France : compétences data mobilisées, à développer (comprendre les données et leur environnement …)

https://www.opendatafrance.net/2023/05/24/atelier-culture-d-metiers-donnees-la-synthese-des-echanges/

Et aussi la publication du support de la présentation publique qui s’est tenue le 18 avril 2023 sur la sensibilisation des collectivités de taille intermédiaire aux enjeux de la donnée : https://www.opendatafrance.net/2023/04/25/sensibilisation-des-collectivites-de-taille-intermediaire-aux-enjeux-de-la-donnee/ – lien vers le support https://www.opendatafrance.net/wp-content/uploads/2023/05/TNT-GP6-Reunion-n4-vF.pdf

5) L’IA s’invite sur tous les sujet data

De fait les données sont le carburant des IA.

En retour, l’IA s’invite dans les plates-formes data pour « augmenter » leur fonctionnalité :

Data – data science et IA (exploitation en langage naturel des données) : https://www.lebigdata.fr/salesforce-tableau-big-data-ia

Pilotage par les données : combinaison gagnante du formel (processus industriel) et de l’IA (traitements des aléas)

https://www.journaldunet.com/solutions/analytics/1522113-l-ingenierie-des-donnees-et-l-analytique-avancee-peuvent-elles-dompter-l-incertitude-de-la-chaine-logistique/

L’IA au service de la data gouvernance : le volume des données comme actifs (asset) augmente – change continuellement, impossible par les approches traditionnelles de tout embrasser, besoin d’automatiser l’étiquetage (découverte des données sensible en lien avec des politiques de données -> métadonnées) -> cible donnée à l’IA https://www.okera.com/product/ et https://techcrunch.com/2023/05/03/databricks-acquires-ai-centric-data-governance-platform-okera/

De fait les données sont le carburant des moteurs d’IA. Et ce carburant ou plutôt cette multitude de carburants est clé (voir déjà dans la revue de mars https://www.datassence.fr/2023/04/12/revue-data-du-mois-mars-2023/#_ftn10).

Les idées dans l’article suivant :

« L’utilisation de dictionnaires de données et de glossaires est manuelle, chronophage et sujette aux erreurs. »
Se passer des outils de classement manuel (dictionnaire, catalogue) pour utiliser les capacités de l’IA à classifier les données (identification des données de référence par similarités)
Utiliser l’IA pour détecter les patterns de défaut de qualité des données par rapport aux données de référence (seuils de similitudes)

Source : https://towardsdatascience.com/3-simple-and-powerful-ways-this-ai-technique-will-transform-data-management-fe2b66fb9a03

6) Dans la suite de l’idée de burn out data … le problème de la data entropy

Rappel de l’histoire : le stress data voire le burn out des acteurs data devient un sujet de préoccupation – voir la revue data du mois d’avril – https://www.datassence.fr/2 0 23/05/11/revue-data-du-mois-avril-2023/#_ftn1

Dans ce sens, l’idée de data entropie est évoquée : tendance à la désorganisation, augmentation du désordre avec comme conséquence l’incertitude.

Des exemples d’accumulation :

Où trouver les bonnes données au bon moment avec la bonne qualité et avec les bon outils,
Remise en question systématique des chiffres que chacun reconstitue de son côté,
Charge systématique de rétro-ingénierie sur les données avant toute action : qualifier les traitements – pipelines, stockages, usages …,
Quels ROI pour toutes les plates-formes data (dont big) mises en place ?
Voir aussi le sujet numéro 2 sur la data management de cette revue data et la prolifération des profils data

Source :

https://towardsdatascience.com/data-entropy-more-data-more-problems-fa889a9dd0ec?source=rss—-7f60cf5620c9—4