Cette revue est basée sur un ensemble de publications du mois de mars 2024, issues de sources en lien avec le sujet Data. A piocher suivant vos centres d’intérêts.
Pour ce mois de mars des sujets récurrents (Data platforms, Data et IA, Data mesh, Data stratégie), un zoom sur la technique RAG – Retrieval Augmented Generation qui permet de contextualiser les grands modèles LLM à partir de données d’entreprise, le sujet pas forcément attirant de la data gouvernance, le CR d’une table ronde sur l’open data suite à la parution de l’ouvrage de S. Goëta – « Les données de la démocratie ».
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
Sommaire :
- Le sujet le moins sexy de la data : la data gouvernance
- Zoom sur la RAG (retrieval augmented generation)
- Data et IA
- Data platforms
- Data mesh
- Data stratégie
- Comment le management vit les données ?
- Prolog … Datalog
- Open data, pouvoir & contre-pouvoirs
- En vrac (Hiver data suite, Le data act fait faire des économies, data and analytics (D&A) summit du Gartner, Nos voitures livrent à tout vent des masses de données, Rendre les données tangibles via la réalité virtuelle)
Le sujet le moins sexy de la data : la data gouvernance
1) Le rôle incontournable de la data gouvernance pour la sécurité des données. L’idée es bonne de relever le rôle de la data gouvernance en fonction des 7 couches de data sécurité pour la cybersécurité (inspiré des 7 niveaux de l’OSI) – source https://www.researchgate.net/figure/Seven-Layers-Data-Security-of-Cybersecurity_tbl1_355420255.
L’article présente l’idée, mais ne développe pas assez selon moi l’angle data gouvernance.
Quelques éléments par couche :
- Couche humaine : data sensibilisation, politique d’accès, défense contre le phishing (sans préciser le rôle des données – mais il y a sûrement à faire des choses de ce côté), data responsabilisation (non précisé – mais la logique data domaine – data product du data mesh peut jouer un rôle)
- Couche de sécurité périmétrique : classification des données pour leur ouverture ou fermeture
- Couche réseau : règles de circulation des données inter-réseaux, choix de chiffrement, contrôle / surveillance des pipelines de données (mouvements de données)
- Couche des périphériques : politique de cryptage, de stockage sur les terminaux…
- Couche applicative : tests de vulnérabilité des applications par rapport à l’accès aux données
- Couche data : classification et étiquetage des données, cryptage en base… (je rajouterais aussi les principes de séparation des modes de stockage des données en fonction de leur sensibilité … pas tout et de la même façon dans la même base de données, voir aussi la sécurité au niveau attribut – ABAC – Attribute-Based Access Control…),
- Couche des données critiques : politique de backup, surveillance active
Je rajouterais, d’une façon plus globale, cela milite pour l’importance de la data observabilité au service de la data gouvernance … au service de la sécurité et tout cela ne peut se faire sans une bonne stratégie de gestion des métadonnées !
2) Vu sur Linkedin, l’initiative de la Data Governance Alliance for Smarter Citizens (https://www.datagovernancealliance.org/ ) et qui pose la question de qui doit gouverner les données ?
« La gouvernance des données n’est pas seulement essentielle pour nous en tant qu’individus, mais elle l’est aussi pour la société dans son ensemble. C’est pourquoi nous adhérons pleinement à la Charte DG4U de la DG4SC. Elle reconnaît l’importance de mettre l’humain au cœur de la gouvernance des données et de garantir que nos droits sont respectés. » – https://www.datagovernancealliance.org/data4u – voir la charte associée à l’initiative
Initiative intéressante, à voir comment cela peut se décliner dans une gouvernance des données interne aux organisations (exemples, du consentement – voir ce qui est fait par rapport au RGPD, de la traçabilité – étiquetage des données, de la mutualisation – avec les règles d’interopérabilité…).
Source :
3) Comment la data gouvernance contribue à la valeur de l’entreprise ?
A partir d’une grille proposée par Deron Hook, Director of Data Governance and Management at American Express. :
A ces quatre axes, Deron Hook ajoute :
- La portée d’audience des données dans l’organisation (du COMEX à l’opérationnel)
- Le niveau de maturité vis-à-vis des données (il existe plusieurs grilles de maturité sur ce sujet)
- La facilité à obtenir la preuve des données (rôle de la traçabilité, de l’étiquetage) – Problématique classique de conflit, débat, charge de travail pour retracer le parcours de données, d’indicateurs.
- Le niveau et la qualité de communication sur la data gouvernance (communication sur la gouvernance par le succès, par la peur – réglementaire, par la comparaison avec la concurrence mise en risque par défaut de gouvernance…)
Mais avec la difficulté d’exprimer un ROI tangible (économique) de la data gouvernance : aller chercher des cas d’usage exemplaire, des exemples de gains indirects, intangibles, d’économies…
Source : https://www.dataversity.net/demonstrating-the-value-of-data-governance/
4) La data gouvernance n’est pas qu’un ensemble de principes, c’est aussi quelque chose de très opérationnel. Je vous conseille de revivre le webinaire d’Orkestra data (https://orkestra-data.com/ ) sur ce sujet. Avec une mise en lumière de toute l’importance de savoir by design intégrer la gouvernance dans le quotidien data.
Source : https://www.youtube.com/watch?v=T9nHKfJoy0k
5) Le problème avec la data gouvernance (traduction du titre de l’article source)
Comment se motiver pour un tel sujet lorsqu’on a cela en charge dans une organisation ?
Le champ d’application de la gouvernance des données s’est tellement étendu que cela n’a plus de sens.
Le mot gouvernance évoque, des politiques, de la conformité … des risques. Mais quels sont les risques liés aux données ? Tout se rejoindrait à traiter des problèmes de qualité de données ! Mais les personnes qui pratiquent la gouvernance ne maîtrise pas les données, leur cycle de vie, leurs usages … et les principes structurant de la qualité des données (exemples : différence entre exactitude et validité, les données ne sont pas immuables…).
Le terme gouvernance est un abus de langage. On devrait parler de gestion des données. On ne gouverne pas un actif, on le gère. Extrait :
« Data instrumentation & curation → address supply side of asset.
Data enhancement & enrichment → address enhancement side of asset.
Data distribution & utilisation → address monetisation side of asset. »
Source : https://eric-sandosham.medium.com/the-problem-with-data-governance-2570f0573f3a
Et voir les commentaires sur Linkedin : https://www.linkedin.com/posts/charlotte-ledoux-53b43253_the-problem-with-data-governance-activity-7175060801240645633-Iw0q
J’aime bien celui-ci « Imagine a country that will be « managed » by the people, and not « governed »… No law, no rules, no law enforcement… that’s is called the Far West… not sure about the created value for the company… » – https://fr.linkedin.com/in/pnieuwbourg/fr?trk=public_post_comment_actor-name
Et cela aux sources : « According to the Oxford Dictionary governance is « The process of collective decision‐making and policy implementation », whilst management is « the activity of running and controlling a business or similar organization ». One is defining (strategy) / one is applying (execution). » – https://uk.linkedin.com/company/marketdata-md?trk=public_post_comment_actor-name
6) Et dans le même esprit – un article : « Is Data Governance a Service or an Enabler? »
La data gouvernance vue comme service dans sa capacité à fournir des moyens.
La data gouvernance vue comme « enabler » dans son rôle d’appui à atteindre les objectifs de l’entreprise.
Source : https://www.nicolaaskham.com/blog/2024/3/28/is-data-governance-a-service-or-an-enabler
NB : sujet déjà évoqué dans des revues data précédentes – https://www.datassence.fr/2024/01/18/revue-data-du-mois-decembre-2023/#_ftn8
Zoom sur la RAG (retrieval augmented generation)
Pourquoi ce zoom ?
Parce que cela tire le sujet de personnalisation / contextualisation des grands modèles LLM à partir de données d’entreprise. C’est-à-dire la capacité à invoquer des données contextuelles (documents d’entreprise par exemple) dans les réponses des moteurs d’IA (jusqu’à y faire référence).
Comment cela marche : les questions (prompts) sont projetées dans l’univers des données d’entreprise (datasets à créer) pour récupérer les données pertinentes (extraits de documents par exemple) en fonction d’une distance par rapport à la question. Ensuite le LLM exploite cela pour construire (générer) la réponse.
Le tout devant bien entendu être entraîné (datasets de Q/R) et évaluation de la pertinence des réponses – part manuelle qui peut être assistée – exemple module UMAP décrit ici https://towardsdatascience.com/visualize-your-rag-data-evaluate-your-retrieval-augmented-generation-system-with-ragas-fc2486308557
– utilisation de métriques de type exactitude de la réponse, précision par rapport au contexte, degré de similarité sémantique entre la question et la réponse, ou encore criticité de la réponse par rapport à une politique, filtrage des réponses).
Un tour d’horizon d’articles, à retenir :
1) Un article qui trace pas à pas la démarche RAG : construction de la base documentaire contextuelle, calcul de similarité (distance) avec la question posée, récupération de la question enrichie de son contexte (filtrage possible en fonction de règles – application de politiques), transmission au moteur de LLM pour construction de la réponse. Source : https://towardsdatascience.com/a-beginners-guide-to-building-a-retrieval-augmented-generation-rag-application-from-scratch-e52921953a5d?source=rss—-7f60cf5620c9—4
2) Avec la RAG, se pose la question de la qualité documentaire – de la base de connaissance, des textes contextuels qui vont être utilisés pour répondre aux questions (exemple contenu manquant, documents plus important que d’autres, documents hors contexte, niveau de détail ou de spécificité non satisfaisant, contenus sensibles…),
Points d’amélioration possible : choix et multiplication des calculs de similarité (il en existe de nombreux et historiques – comme par exemple basée sur la fréquence des mots – TF-IDF), enrichissement du contexte par l’ajout par génération de questions similaires à la question posée (en quelque sorte le LLM va se poser à lui-même des questions), traitement des documents pour ne récupérer dans le contexte que les informations pertinentes. Source : https://www.datasciencecentral.com/decoding-rag-exploring-its-significance-in-the-realm-of-generative-ai
3) Un exemple RAG pour effectuer des recherches en langage naturel dans sa base d’archive de mails (difficile parfois de retrouver un ancien message par les critères classiques de recherche, l’idée est de poser cela sous forme de question – exemple de l’auteur : « « À quel cours technique me suis-je inscrit au cours de ma deuxième année à NTNU ? ». La base de connaissance : sa base d’emails (NB : les pièces jointes peuvent aussi être exploitées). Formatage de la base de connaissance : récupération des métadonnées et du contenu des emails dans une base de données qui le système RAG va exploiter (vecteurs de données). Vectorisation de la question. Calculs de similarité entre la question et le contenu de la base de connaissance (les emails). Sélection des contenus à plus forte similarité. Construction de l’entrée au LLM (question + contenus sélectionnés). Appel au LLM. Récupération de la réponse fournie par le LLM. Test-évaluation du processus pour tuning (plus de métadonnées, amélioration du calcul de similarité, amélioration de la sélection – fenêtre contextuelle plus grande…). Source : https://towardsdatascience.com/how-to-make-a-rag-system-to-gain-powerful-access-to-your-data-caf4bb9186ea
4) Une autre présentation plus avancée, avec : la mise en évidence de la segmentation de la base de connaissance (découpage des documents en unités de récupération), l’utilisation de l’IA traditionnelle pour les calculs de similarité – classement des documents par rapport aux questions, enrichir le contexte documentaires (les unités de récupération) par une mise en graphe (voir aussi sur ce sujet – https://towardsdatascience.com/using-causal-graphs-to-answer-causal-questions-5fd1dd82fa90?source=rss—-7f60cf5620c9—4), par un travail sur la diversité (ouvrir le contexte à un maximum de cas), fourniture de références avec la réponse pour vérification par l’utilisateur, l’enrichissement par RAG en continu du LLM (« mis à jour ») – voir l’exemple de la souche LLM Gorilla qui exploite en dynamique 1600 API d’appel à des moteurs spécialisés en fonction de la question posée pour enrichir son contexte (à noter que l’IA sait adapter son appel à l’API dès que la documentation de celle-ci est modifiée … pour ceux qui ont trempé dans l’API management…), utilisation de métriques automatisées pour évaluer la pertinence des réponses contextualisées (voir RAGAS)… et en conclusion à retenir « any AI/ML practitioner knows that 90% of time building an application will be spent observing and working with data. ».
-Et pour aller encore plus, voir l’article ci-après pour tirer des données structurées des documents et exploitables dans une personnalisation RAG :
Source : https://ai.plainenglish.io/advanced-rag-07-exploring-rag-for-tables-5c3fc0de7af6
… et aussi tenir compte de l’enchainement de questions comme contexte plus large (chaînes de prompts- Chain-of-thought prompting).
Data et IA
Actualités :
1) J’ai bien aimé le constat sans tabou, de la bascule sur les données en linguistique, entre l’approche historique d’analyse structurelle du langage (syntaxe, grammaire…) et l’approche LLM (tokenisation). Avec les conséquences pour les chercheurs en linguistique … Source : https://www.pauljorion.com/blog/2024/03/08/grands-modeles-de-langage-pourquoi-les-reseaux-neuronaux-ont-ils-reussi-la-ou-la-linguistique-echouait-par-claude-roux
2) Est-ce que vos données d’entreprise sont prêtes pour l’IA générative ? Vu par la revue HBR (Harvard Business Review – www.hbr.org )
L’enthousiasme est là … mais la préparation des données nécessaires pas tout à fait !
Parce que c’est une charge nouvelle, cela implique de nouvelles données (les données non structurées … et le retour de vieux sujets comme la gestion de la connaissance – le knowledge management ! Avec aussi des problématiques de qualité et de métadonnées différentes des données structurées), qu’identifier tout de suite les cas d’utilisation à valeur économique n’est pas si évident, qu’il y a des risques (jusqu’à interdire l’usage de l’IA générative dans certaines entreprises), qu’il faut investir dans une architecture de pipelines de préparation de données pour nourrir les IA avec des données de qualité…
Autre constat « amusant » : « In addition, there is contention for who leads generative AI within their companies; CDOs are competing with CIOs, CTOs, and chief digital officers for leadership of the hot new technology. ».
Et pour conclure : « The job to make a large organization’s important data ready for AI could easily take several years. The time to start is now. »
Source : https://hbr.org/2024/03/is-your-companys-data-ready-for-generative-ai
3) Pas d’IA sans data de qualité et pas de data de qualité sans interventions humaines.
Antonio A Casilli est le porte-parole de tous ces travailleurs de la data pour l’IA, souvent cachés. A suivre tous ses travaux remarquables sur le sujet – https://www.casilli.fr/ .
Avec dans l’actualité une étude importante sur la part humaine dans les pipelines de traitements / préparation de données, qui fait quoi, sous quelles formes, dans quels contextes, où… publiée ici – source : https://journals.sagepub.com/doi/abs/10.1177/20539517241232632?ai=2b4&mi=ehikzz&af=R
Extraits :
« Assignments of AI data workers consist of a variety of tasks, from categorising and assembling datasets, to annotating different types of data and interpreting and correcting the results of machine learning algorithms » avec les impacts éthiques associés
« They focus on the functions performed by microworkers recruited through digital platforms in three distinct forms of work: ‘artificial intelligence preparation” “artificial intelligence verification” and “artificial intelligence impersonation »
Sur le niveau d’expertise attendu, parfois élevé : « AI data platforms may require annotators to complete training courses before being allowed to access specific kinds of more skilled tasks such as Light Detection and Ranging (hereafter LiDAR) a method for determining ranges through laser imaging which is a form of 3D laser scanning that is used for 3D moving objects. This drives clients to seek more expensive and specialised services that emphasise a higher degree of workforce management and quality control. »
« Data verification on the other hand refers to reviewing and correcting model predictions, or labels in the training data. This might involve identifying errors related to objects that are underrepresented in the training data in diversity and quantity. This process is difficult to measure in aggregate as human judgement is often required for complex or subtle nuances in data. For example, annotating the perceived fatigue of a driver for an AV ‘In-cabin Behaviour Monitoring »
Sujet aussi évoqué dans des revues précédentes : https://www.datassence.fr/2023/12/05/revue-data-du-mois-novembre-2023/#_ftn5
Et sur ce sujet, un clin d’œil, jusqu’à ce que même l’IA n’existe pas en réalité et ce sont les travailleurs de la data qui font tout – « Amazon vante son IA de détection d’objet… mais c’est en fait un employé indien » – https://www.lebigdata.fr/amazon-vante-son-ia-de-detection-dobjet
4) Deux natures de risques liées aux données connues des moteurs d’IA
- Des risques juridiques (secret des affaires), d’utilisation abusive et de divulgation de données faisant l’objet de contrats de confidentialité (avec un partenaire commercial, un sous-traitant par exemple)
- Des risques liées aux données personnelles (avec le problème de la multiplication des lois dans le monde entier … comment s’assurer de couvrir tous les cas ?)
5) Traitement de la qualité des données par l’IA LLM
- Identifier et cataloguer les défauts de qualité de données,
- Comment se passer d’un travail humain pour faire cela (travail fastidieux)
- Faire appel à l’IA LLM
- Pour cela il faut mettre les données structurées sous forme de texte et se reposer sur le vaste ensemble de données d’apprentissage des moteurs de LLM pour y détecter des anomalies (et y associer un score de confiance)
- Si besoin compléter la connaissance des données via une approche RAG (voir dans cette revue le point RAG)
- Une fois encore les métadonnées vont jouer un rôle clé (par types d’anomalies possibles – exemple domaine de valeur à considérer pour la détection de valeurs incorrectes)
Et interroger l’IA :
« Below are common data quality issues to guide your analysis. However, you may also identify other relevant issues :
Ingestion errors
Typecasting issues
Duplicates
Date parsing issues
Character encoding problems
Missing values
Typos/spelling mistakes
Anomalies/outliers
Conversion errors and inconsistent units
Privacy concerns (e.g., exposed PII)
Domain-specific errors (e.g., invalid formats for addresses, phone numbers, emails) »
Et une suite possible, la génération de réparations possibles en appui pour les data stewards.
6) Et pour finir dans cet actualité, un article technique sur la dérive conceptuelle de données. Sujet sensible pour les moteurs d’IA (modifie la façon d’interpréter les données suite à des changements dans le temps, de représentativité des données … pouvant aller jusqu’à leur définition). L’article présente une méthode pour détecter les changements (à partir d’une fenêtre de référence).
Data platforms
– L’idée (pas nouvelle) de renverser la logique de création des applications, avant définir l’application puis façonner les données nécessaires, après partir des données disponibles, y compris les données non structurées (données dans le Data cloud Salesforce – https://www.salesforce.com/fr/blog/what-is-salesforce-genie/ ) puis façonner les applications à partir de ces données (data first) … et l’IA vous bâti cela automatiquement à partir d’une intention -> conférence Salesforce
Source : https://diginomica.com/trailblazerdx-2024-data-cloud-datablazers-data-first-apps
– Le rôle clé de l’orchestration des traitements de données (voir par exemple les outils open source – Prefect, Dagster, Mage, Kestra ou encore Orchestra), avec les fonctions de construction de graphes d’enchaînements de traitements, de gestion d’événements, de planification et le tout sous surveillance. Avec le rôle clé des métadonnées et tout l’intérêt de l’approche déclarative de l’orchestration (versus câblée dans le code). Voir l’article qui présente la solution Orchestra – https://www.getorchestra.io/ (NB à ne pas confondre avec Orkestra data – https://orkestra-data.com/ ! – mais à noter qu’aussi bien Orchestra que Orkestra data sont toutes les deux des solutions métadonnées centriques … une force) :
– Quand l’agile s’exprime mieux au travers d’une data platform versus lorsqu’il est nécessaire de faire appel à une combinaison de N outils pour « gérer/traiter » les données. L’approche fragmentée est lourde, complexe à mettre en œuvre, avec une problématique d’interfaces entre outils qui ne permettent pas à la démarche agile d’être performante. Source : https://insidebigdata.com/2024/03/13/embracing-the-agile-data-platform-a-key-to-business-survival-today
Data mesh
1) Un REX de Thoughtworks (https://www.thoughtworks.com/en-de/insights/articles/data-mesh-in-practice-getting-off-to-the-right-start ) chez Roche (https://www.roche.fr/ ) :
- (porte ouverte) Le data mesh ce n’est pas on / off, cela se met en place progressivement – équilibre à trouver entre apprentissage et déploiement à l’échelle,
- Les domaines métier ne sont pas à inventer. S’appuyer sur l’existant tout en éclairant au maximum où se situe leur responsabilité métier (lien entre la stratégie d’entreprise et leur rôle/valeur … qui permettra d’identifier leur responsabilité sur quelles données). Être conscient de la difficulté de prise en compte des limites / frontières entre domaine pas toujours claires (jouer sur les rôles avec des responsabilités claires au sein des domaines),
- S’inspirer de « Design Council’s double diamond » pour la mise en oeuvre – https://www.designcouncil.org.uk/our-resources/archive/articles/double-diamond-universally-accepted-depiction-design-process ,
- (de base) La mise en œuvre concerne les 4 piliers en même temps (y compris et surtout la gouvernance), et s’adapte en continu en fonction de la mesure de progression de la qualité du maillage,
- Intégrer les changements nécessaires dans l’organisation existante, en partant toujours des valeurs métier,
- (porte ouverte) … Toujours être aligné sur le objectifs / la stratégie d’entreprise. Avec le défi d’être en face d’objectifs, de stratégies, de modèles organisationnels, de priorités, décousus, peu clairs !
- Disposer d’une vue continue du maillage : produits de données, interconnections entre produits, production / consommations, niveaux de services observés (des produits de données), indicateurs de valeurs (alignement sur la stratégie d’entreprise),
- En termes d’implémentation technique, la vue data mesh est une vue logique qui est à décliner sur l’existant et de nouvelles briques. Les produits de données en étant les briques élémentaires. Avec les métadonnées comme ressources essentielles pour assurer la cohérence (dont l’aspect normatif) et fluidité (dont l’interopérabilité) d’ensemble. Avoir en continu une vue de l’implémentation du maillage et de ses axes de progrès,
- Les produits de données comme briques élémentaires doivent avoir toute l’attention nécessaire quant à leur qualité (au sens développement – génie logiciel – exemple de la modularité, de la gestion des dépendances, de l’automatisation des tests…),
- Investir dans l’automatisation des politiques (à la main cela finira par être rédhibitoire) – voir par exemple https://www.thoughtworks.com/en-us/radar/tools/open-policy-agent-opa
- Investir dans le data sharing.
Source :
2) « When a Data Mesh Doesn’t Make Sense for Your Organization »
– Toutes les organisations ne peuvent pas prendre en charge ce modèle,
– « In real world deployments, this often translates into a small central platform team providing a shared infrastructure and baseline standards, that embedded data teams within each domain can build upon and customize for their needs. »
– « But as the data mesh theory has peddled its way through the hype cycle, it’s become clear that the use case for a data mesh is far narrower than the concept initially suggested. And a lot more difficult. »
– Frein numéro 1 (la numérotation est de ma lecture) : le manque de compétences data et la maturité / expérience data qu’impliquent les composants du data mesh et la difficulté de trouver cela dans les domaines métier avec le risque de se retrouver avec des produits de données de mauvaise facture (qualité, SLA, définition, maintenance, cohérence). Avant tout, il est nécessaire de commencer par un bilan de compétence data au sein des métiers ! NB : et sans oublier à avoir une charge suffisante data au sein du domaine pour mobiliser des ressources.
– Frein numéro 2 : les conflits, les frontières floues des produits de données qui chevauchent plusieurs domaines métier … comment décider du propriétaire (sans qu’un métier s’arroge la propriété au détriment des autres). Il faut savoir traiter cela … sinon c’est voué à l’échec (cela me rappelle les premiers essais et échecs Big data avec un métier testeur volontaire qui s’arroge de la plate-forme et amenant les autres métiers à en s’éloigner). Pistes de solutions : un domaine métier transverse, central …
– Frein numéro 3 : le data mesh cela a un coût (investissement, changement). Il faut être en mesure de l’assumer face aux priorités à court termes d’une équipe data par exemple. Comment trouver de la valeur dès le départ ?
– Frein numéro 4 : la taille de l’organisation… si celle-ci est petite, le domaine métier EST l’organisation (l’approche centralisée est une cible, plus facile à prendre en compte).
– Frein numéro 5 : il existe N data platforms ou solutions supports aux données (tel ETL ici et tel autre ici, idem pour le reporting…) rendant difficile la mise en place des produits de données partageables par les domaines métier, interopérables, en conformité (politiques partagées). La gestion des produits de données doit être vue comme un processus de bout en bout d’un producteur vers N consommateurs et dans un cadre gouverné. Tester ce processus sur votre existant (IT mais aussi organisationnel) et identifier les frictions … à lever (et les moyens nécessaires). Si impossible alors abandonnez !
– Frein numéro 6 : l’incapacité à fournir en mode self-service des données de qualité (pipelines maîtrisés) avec le bon SLA et sous surveillance (observabilité). La centralisation d’une part du processus peut être une approche avec seulement le routage d’indicateurs (d’observabilité) et d’alertes aux domaines responsables des données.
Source : https://barrmoses.medium.com/when-a-data-mesh-doesnt-make-sense-for-your-organization-20de8f3f48bd
Data stratégie
Un tour d’horizon d’une suite d’articles sur la stratégie data :
- A distinguer et aligner : la stratégie data (quelles valeurs ?) et la stratégie data management (gestion pour en tirer de la valeur) – citation « it’s impossible to manage data effectively without knowing its worth, and it’s impossible to know its worth without knowing its purpose »
- Deux cadres de référence de définition d’une stratégie data : DAMA-DMBOK2 et Gartner (« Data and Analytics Strategy and Operating Model »)
- A distinguer en termes de stratégie : les données comme produit monnayable ou comme ressource
- A distinguer la stratégie de données et la stratégie d’analyse de données (les données ne se limitent pas à des besoins d’analyse)
- La stratégie data n’est pas une affaire IT (même comme sous ensemble de la stratégie IT), mais bien une affaire de niveau entreprise (métiers)
- Le cadre de référence en termes de stratégie data management proposé par un des auteurs. Source : https://datacrossroads.nl/product/the-orange-data-management-framework/
- Tout se base sur une stratégie des métadonnées – citation « Effective use of metadata is one of the most fundamental steps in enabling such a strategy. For data to be effectively segregated and categorized, organizations must ensure metadata is consistent, detailed and robust to ensure coherence across applications and that a data’s purpose or business use case can be identified quickly and accurately. »
- Conserver vos données, même les plus anciennes, elles peuvent servir après coup pour l’IA !
- (porte ouverte) Pas de stratégie data sans trajectoire réalisable -> d’où l’idée de franchir des paliers de maturité / stratégiques en s’appuyant sur une grille de maturité (voir celle du DAMA – DMBOK présentée ici – https://blog.det.life/a-data-strategy-comprehensive-guide-for-a-step-by-step-data-maturity-assessment-b9ff23de7cd7
Sources :
https://datacrossroads.nl/2024/03/04/data-strategy-theory-practice-part1https://datacrossroads.nl/2024/03/18/a-data-strategy-theory-vs-practice-part-2https://thenewstack.io/strategies-for-navigating-data-delugehttps://blog.masterdata.co.za/2024/03/19/data-strategy-more-than-just-numbers
Comment le management vit les données ?
- Les données sont importantes pour manager.
- Mais – Extraits : « Too many people complain that they don’t have the data they really need and don’t trust what they have. »
- Comprendre l’univers des données n’est pas simple (il suffit de compter les termes en data X, data gouvernance, data management, data lake, metadata, master data, data visualisation…)
- Et si on revient à la base comment extraite de la valeur des données ?
- Face à cela, ce que propose l’article de la revue HBR :
- Déjà ne pas confier le problème des données à l’IT ! Mais trouver les bonnes personnes métier. L’usage des données ne peut pas être délégué. Il faut les manipuler dans son quotidien, pour ses besoins (pas « à côté » – https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/ )
- Eviter de se noyer dans la portée des problèmes à traiter. Les données sont partout. Et vouloir traiter un problème data (exemple d’accès aux données) c’est nécessairement s’attaquer à un problème d’envergure (modéliser, standardiser, mettre à disposition, contrôler)… et s’y noyer ou de se trouver devant un fossé infranchissable. Il faut donc faire simple, par petit pas pour aussi renforcer les compétences progressivement.
- Le sujet de la confiance dans les données est clé. « A Harvard Business Services estimates that only one in six managers trust the data they use everyday ». Cela passe par un travail important sur la qualité des données. Qui doit être rendu visible, partagé, collectif et mettant en valeur les acteurs qui s’y attaquent. Avec une approche root cause analysis autrement dit s’y intéresser dès la naissance des données… versus corriger a posteriori.
- Passer par l’apprentissage de techniques simples de data science.
Source : https://hbr.org/2024/03/getting-your-companys-data-program-back-on-track
Prolog … Datalog
Un petit plaisir personnel pour avoir codé quelques milliers de lignes en Prolog à la fin des années 80 (si si c’est possible – plus d’un an d’effort pour écrire un moteur de simulation instancié en wargame dans ce sympathique langage 😊) – juste avant l’hiver de l’IA ( ☹).
Un article vu en mars sur Datalog, un sous-ensemble de Prolog pour les données, dont j’ignorais l’existence. Mais fondamentalement fan ! Source : https://www.lebigdata.fr/tout-savoir-sur-loutil-de-gestion-de-base-de-donnees-datalog
Open data, pouvoir & contre-pouvoirs
Le 13 mars, j’ai assisté à la table ronde » Open data, pouvoir & contre-pouvoirs » organisée suite à la publication du livre de Samuel Goëta « Les données de la démocratie » – https://cfeditions.com/donnees-democratie/
Pour revoir l’événement : https://medialab.sciencespo.fr/actu/open-data-pouvoir-and-contre-pouvoirs/
Quelques notes :
- Retour sur la loi de 2016 d’ouverture des données : re questionnement , repose beaucoup sur des individus volontaires avec des moyens fragiles, plafond de verre (15% des collectivités répondent à l’obligation de la loi) presque 10 ans après ? Besoin de revenir à pourquoi on fait cela (valeur de pourquoi on fait cela pas toujours perçue – en particulier par les élus), de prendre mieux en compte le travail nécessaire (l’exécution). Mais avec de la valeur produite et un rôle important, sans open data de nombreux services impossibles ou de moins bonne qualité (exemple vivre dans ma ville), l’open data comme ilot de sources fiables face aux fake news et une perspective pas d’IA sans open data. En synthèse LA DIFFICULTE c’est la mise en oeuvre
- Besoin de mieux connaître les consommateurs de l’open data (ses usages). Mais cela ne suffit pas (cité par C. Nebbula – 5 demandes d’ouvertures des données en 10ans et par des entreprises). Il faut aller plus loin et provoquer les cas d’usage – aller les chercher – les accompagner (dans l’acculturation à tous les niveaux – et REX à faire sur comment la pandémie COVID à provoquer un bouillonnement autour des données ouvertes, dépasser le paradoxe de l’open data non utilisé par les collectivités elles-mêmes pour leur besoin – voir l’exemple des données DGFIP sur la taxe d’habitation et utilisées par les collectivités pour se comparer, décider de leur taxe)
- Une vue plus haute : l’open data dans la mouvance de l’idée de communs numériques (données d’intérêt général). Aller plus loin que l’open data par défaut. Introduire une dimension stratégique (que veut-on faire avec les données, versus attendre les demandes, anticiper des situations favorables pousser par la réglementation – exemple des données CRSD et leur croisement avec des données open data, autour du climat…). En synthèse BESOIN D’EMMENER, D’ACCOMPAGNER++ LES USAGES et penser plus largement stratégie data.
Commentaire personnel : il manque un point de vue informatique / génie logiciel / data management* – data literacy du sujet – quand les intervenants parlent de fragilité parce qu’un nom de colonne a changé, ou de connaître les usages, ou de qualité, de processus de diffusion, de standardisation, de maintenabilité, de fichiers xls comme support … il faut mettre de la méthode et des principes de base dans la démarche (et comme d’habitude trouver le bon équilibre). Ce qu’il se passe par exemple dans les approches de type data product (logique produit), data mesh, data sharing, gouvernance des données fédérée… serait intéressant à exploiter pour l’open data.
Et pour l’avoir vécu de l’intérieur dans deux grandes entreprises amenées à publier des données en open data, il y a un REX à faire vers le secteur public de ces cas en termes de processus de production. Je pense par exemple à l’étiquetage automatique des jeux de données (preuve et traçabilité), au traitement de la qualité à la source, de processus de publication, de traitement du cycle de vie des données (versions, variantes, jusqu’à l’archivage), de lien avec les référentiels de données, de principes de comparabilité dans le temps, d’agrégation, mais aussi aux moyens techniques (infrastructure, data platforms)… (bon tout cela avec des moyens à acquérir).
* Voir par exemple un ouvrage de référence : « Informatique : normes et temps » – février 2000 de I. Boydens.
Après, le monde de l’open data est très large et très riche. Dans cet esprit toujours à suivre l’actualité open data par : https://opendatafrance.fr/lactualite-opendata-du-mois-18
En vrac (Hiver data suite, Le data act fait faire des économies, data and analytics (D&A) summit du Gartner, Nos voitures livrent à tout vent des masses de données, Rendre les données tangibles via la réalité virtuelle)
1) Hiver data : dans la suite du sujet présenté dans la revue du mois de février (https://www.datassence.fr/2024/03/09/revue-data-du-mois-fevrier-2024/#_ftn7 )
Meta a décommissionné l’API qui permettait aux chercheurs d’accéder aux contenus de Facebook et Instagram. Source : https://qz.com/meta-replacing-crowdtangle-monitor-content-us-election-1851334958
2) Le data act fait faire des économies
Google, Azure, AWS, abandonnent les frais de sortie de leur environnement (migration de données vers une autre plate-forme). Avec pour Microsoft quelques limites, cela ne s’adresse qu’aux clients qui sortent complètement de Microsoft Azure (la contrainte des frais de sortie reste si vous êtes en environnement multi-cloud) !
Source : https://techcrunch.com/2024/03/14/after-aws-and–google-microsoft-says-its-removing-azure-egress-data-transfer-fees-but-with-caveats/
3) Un CR du data and analytics (D&A) summit du Gartner
Extrait :
« The summit highlighted that the key challenges faced by D&A leaders include difficulty sourcing talent, lack of data-driven innovation, incorrect use of data for decision-making, and the higher total cost of ownership (TCO) for D&A projects. » et « Gartner predicts that 75 percent of new analytics content will be contextualized for intelligence application… ». Source : https://www.datanami.com/2024/03/14/highlights-from-the-gartner-data-and-analytics-summit-in-orlando-fl
4) Nos voitures livrent à tout vent des masses de données nous concernant
Et les assureurs en sont friands. Source :
5) Rendre les données tangibles via la réalité virtuelle
Extrait : « If implemented as a VR solution, it would allow for an upper-level manager to review the state of a warehouse without having to necessarily step foot there, perhaps uncovering and visualizing that state in terms of tangible things. ». Source : https://tdan.com/creative-ways-to-surf-your-data-using-vr-and-ar/31655
RDV maintenant en mai pour la revue et les actualités d’avril
Comments are closed.