Cette revue est basée sur un ensemble de publications du mois de juin 2024, issues de sources en lien avec le sujet Data. A piocher suivant vos centres d’intérêts.
Pour ce mois de juin les sujets récurrents (Data platforms, Data et IA, Data mesh, Data product, Data contract, Data stratégie, Data integration). Un zoom sur des REX de data scientists.
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
Sommaire :
- Data stratégie et data décision
- La journée d’un data scientist
- Data project
- Le mur des données
- Data platforms
- Data mesh – data contract – data product
- Data integration
- IA et data
- Réglementaire flux de données
- En vrac (Architecture data, Données manquantes, Partage de données, Comment concilier confidentialité des données et tracking des comportements malsains, Collecte data)
Data stratégie et data décision
Mise en regard de décisions par le système 2 (démarche analytique) et le système 1 (démarche intuitive) – en référence à l’ouvrage de D. Kahneman – « Système 1, système 2 : Les deux vitesses de la pensée » avec la question de la place des données.
Des constats :
1) « …according to a global survey by BARC, 58% of companies base at least half of their regular business decisions on gut feel or experience rather than being driven by data and information.
It is not a lack of data that is the problem — in fact, leaders are buried under data. The problem is that the data doesn’t tell them what they should do, which is why they rely on intuition again. »
2) « The point that is made is that even in a case where there is plenty of data, talent, and resourcing, and a highly deliberate effort to make data-driven decisions, you still can get it monumentally wrong. Not in spite of the data, but because of the data. »
Et implication pour les données :
1) « Thus, this data gathering work is influenced by the preparer’s logic, not the executive leadership team’s.
Therefore, Martin stresses starting with the data in the heads of the executives, acknowledging it’s imperfect and incomplete. Perfect data doesn’t exist, and while pertinent data is helpful, he argues that “less is better” for making strategic decisions. On the surface, this seems to challenge the dogma of data-driven decision-making. »
De façon évidente, choisir les bonnes données qui parlent à ceux qui vont prendre les décisions. Et non pas un maximum de données choisies par une équipe data.
2) Faire la distinction entre décision opérationnelle (fréquente et répétée dans le contexte de processus qui peut donc être standardisée) et décision stratégique (unique et complexe à impact élevé)
3) Comment prendre cela en compte dans une stratégie data ?
– Les cas d’utilisation passerelle entre la stratégie d’entreprise et la stratégie data
– Problème les cas d’utilisation concernent principalement les décisions opérationnelles
– Hormis l’éclairage de contextes par les données, la stratégie data ne couvre pas les décisions stratégiques.
On met l’accent sur la collecte et la gestion des données en espérant que la valeur va suivre. On ne s’intéresse pas au processus de décision en tant que tel.
« There is no attention to the second part of the equation: the decision-making process itself. What do people do with the data when it is available to them? Are they trained to interpret it, understand biases, and make decisions? Are they taught how to develop hypotheses and confirm them by gathering highly specific data points? In no data strategy of any importance that I’ve seen is there any explicit attention given to this… »
En clair, mais pas si simple, analyser le processus de décision stratégique (si on peut parler de processus) et identifier l’apport des données… Bref un travail de data analyst expert en stratégie d’entreprise.
Et un article sur les stratégies data pour les données en elles-mêmes (qualité, infrastructure, culture), sans le volet pour qui et quoi.
Source : https://www.cio-online.com/actualites/lire-7-tendances-en-matiere-de-strategie-data-15695.html
La journée d’un data scientist
L’exercice des tests des modèles mis en œuvre et dans le temps (comportement des modèles) par les data scientists. Et se protéger de la dégradation des modèles (exemple du phénomène de drift ou du processus de collecte non stable). Et plus globalement le REX d’un data scientist sur ses journées. Source :
Un autre article REX d’un data scientist, qui met en avant : le savoir-faire en communication, la compréhension du métier (l’éternel évidence), la recherche de la neutralité des données (éliminer les biais), ne pas négliger les données « anecdotiques » face aux données de masse, attention aux changements de mesures de collectes, savoir changer d’avis – vos recommandations (les modèles bougent, les données bougent, le métier bouge, attention au flot de demandes ponctuelles sur les données (risque de saturation et de négliger le fond), avoir des métriques parfaitement standardisées dans toute l’entreprise (partagées) est irréaliste, il faut trouver l’équilibre entre rigueur et désordre des données.
Dans la même idée, le REX d’un data scientist qui a exercé chez Uber, META … quelles métriques suivre et comment elles s’articulent entres-elles (cf arbre de métriques – voir aussi cl’arbre de performance proposé par G. Garibian – https://www.datassence.fr/2024/01/18/revue-data-du-mois-decembre-2023/#_ftn5), mettre en repère les métriques et faire le lien avec le contexte métier, attention aux effets de la saisonnalité… et toujours avoir en tête « Remember, data in itself does not have value. It becomes valuable once you use it to generate insights or recommendations for users or internal stakeholders. »
Source : https://towardsdatascience.com/the-ultimate-guide-to-making-sense-of-data-aaa121db1119 et aussi du même auteur https://towardsdatascience.com/how-to-design-better-metrics-9bad7bc8c875
Attentions aux articles sans connaissance de la réalité des pratiques et des compétences en data science, avec une critique d’un article de HBR – https://hbr.org/2018/10/prioritize-which-data-skills-your-company-needs-with-this-2×2-matrix .
Source : https://keith-mcnulty.medium.com/a-very-dangerous-data-science-article-f5e3db86d52a
Et une suite d’articles dans la tête de data scientists, de trucs et astuces :
– comment ChatGPT assiste les data scientist – https://www.youtube.com/watch?v=CG1NNrUAmX8 et aussi https://towardsdatascience.com/how-llms-will-democratize-exploratory-data-analysis-70e526e1cf1c. Et attention https://techcrunch.com/2024/06/29/geminis-data-analyzing-abilities-arent-as-good-as-google-claims/
– savoir expliquer les modèles utilisés – exemple sur les fraudes à la carte bancaire – https://towardsdatascience.com/model-interpretability-using-credit-card-fraud-data-f219ff7ec89d
Data project
Des rappels de bon sens :
– La construction d’un stack data est un moyen et non pas une fin en soi !
– Les projets échouent parce que la technologie n’est pas à elle seule une solution magique
– Comment meubler le « slow time to delivery » (le temps projet) sans tomber dans le shadow data (exports à la main, excel) – quelle approche tactique ?
– La connaissance data doit être documentée et gérées (définitions, contexte métier, lineage, accès) et ne pas rester dans la tête de quelques sachants goulot d’étranglement
– La loi de Conway – https://www.melconway.com/Home/pdf/committees.pdf -s’applique, le projet data reflètent les personnes, le fonctionnement et l’organisation en place … l’idée est d’abord de revoir cela (loi de Conway inversée – https://itrevolution.com/product/team-topologies/ ) avant d’attaquer le projet technologique
– Autrement dit revoir l’intégration de la data dans le quotidien, dans les processus, dans les compétences des acteurs métier et même IT (exemple : former les métiers aux gestes data – gestion des flux, self analysis, prise en compte des règles de gestion data, des politiques data, contribuer à des process data comme l’alimentation d’un catalogue – voir aussi ce que propose le DAMA avec son DMBOK – https://www.dama.org/cpages/body-of-knowledge )
Source : https://medium.com/@meskensjan/scoping-data-projects-why-technology-alone-isnt-enough-2f2dafdd1c1c
Le mur des données
Le manque de données pour IA (déjà abordé dans des précédentes revues : https://www.datassence.fr/2023/12/05/revue-data-du-mois-novembre-2023/#_ftn3 )
Il existerait (rumeur) un risque de mur des données pour les moteurs d’IA (plus assez de données pour alimenter leur grands modèles). Une des idées est de passer par des données synthétiques (les IA génèrent les données qui leurs sont nécessaires !). Est-ce une frontière ?
Personnellement, ce débat a peu de sens, 1) un modèle IA ne peut pas être figé au risque d’être rapidement obsolète, 2) on commence seulement à exploiter les données non structurées (voir l’exemple GDELT https://www.gdeltproject.org/ ), 3) les projets mettant en œuvre une part de collecte data n’ont jamais été aussi nombreux, 4) la première vague de moteurs d’IA s’appuie sur des données « peu » qualifiée (garbage in garbage out), les données de qualité vont arriver (il faut l’espérer)…
Le risque sur les données n’est pas là, mais plutôt sur le mur des fake data.
Source et discussion : https://www.lesswrong.com/posts/axjb7tN9X2Mx4HzPz/the-data-wall-is-important
Data platforms
Beaucoup d’actualité avec en particulier le combat à coup d’annonces entre Databricks et Snowflake (sur l’IA bien entendu, la fonction de catalogage, la prise en compte de format de données – autour de tables Apache Iceberg, les fonctions de construction de pipelines…).
Mais aussi de plus en plus d’initiative open source, en provenance des grands éditeurs (exemple Unity Catalog de Databricks) mais aussi d’autres acteurs.
Sources :
– https://thenewstack.io/snowflake-databricks-and-the-fight-for-apache-iceberg-tables/
– https://www.datanami.com/2024/06/10/its-go-time-for-open-data-lakehouses/
– https://www.datanami.com/2024/06/12/databricks-to-open-source-unity-catalog/
– https://techcrunch.com/2024/06/12/databricks-launches-lakeflow-for-building-data-pipelines/
Dans la mouvance des data platforms voir aussi le sujet des librairies de connecteurs aux sources de données.
La chasse aux données et à l’optimisation des accès aux sources de données est ouverte, Cdata (https://www.cdata.com/ ) fournisseurs de data connecteurs obtient un financement de 350 M$. Source : https://techcrunch.com/2024/06/26/cdata-which-helps-orgs-use-data-across-apps-and-to-build-ai-models-snaps-up-350m/
Voir aussi ce que propose OpenDataSoft : https://www.opendatasoft.com/fr/blog/centraliser-tous-ses-actifs-de-donnees-grace-a-la-connectivite-illimitee-dopendatasoft/
Data mesh – data contract – data product
Les data contracts associés aux data products sont des piliers fondamentaux pour la bonne mise en œuvre du cadre de vie des données (à l’exemple du data mesh).
Il y a 20 ans on parlait de contrat d’interface IT/métier dans la mise en place de flux de données pris en charge par les EAI, avec l’essors des données, on parle maintenant de data contract à associer aux data products.
1) Des propositions de standardisation apparaissent (voir dans les revues précédentes – opendataproduct y https://opendataproducts.org/ , opendatacontract – https://opendatacontract.com/ ), des solutions logiciels dédiés émergent (exemples de Glabe – https://www.gable.ai/ et aussi Bitol – https://bitol.io/ ).
Dans un data contract et dans un data product on va trouver les métadonnées actives qui vont permettre d’exprimer le contexte lié aux données et de les réguler (application des politiques).
En ce mois de juin, une revue de quelques articles sur ces sujets :
2) « Data products — Where theory meets practice » : Une discussion sur les data products et les data contracts. Avec les data products vus comme un assemblage de data contracts.
« Data contracts are resolving most elements addressed in FAIR principles — Findable, Accessible, Interoperable anr Reusable — or the DATSIS principles, which were introduced by Zhamak Dhegani when first describing data mesh: Discoverable, Addressable, Trustworthy, Self-Describing, Interoperable, and Secure. »
Avec un point d’attention, la définition de data products et de data contracts vus comme une charge supplémentaire de formalisation « The hardest part is defining the why of every single data product and incentivizing teams, certainly those that do not see the value within there own domain. »… l’éternel sujet de voir plus loin que l’horizon de son domaine.
Source : https://medium.com/data-mesh-learning/data-products-where-theory-meets-practice-2cec3ebb2460
3) « A Technical Guide to Data Contract from conceptualisation to implementation » – un tour d’horizon complet de l’idée de data contract (à noter l’introduction de l’idée de moteur de politiques qui s’exécute à partir des métadonnées contenues dans les data contracts – exemple droits, qualité…).
4) « Data consumption can be regulated through data contracts by embedding all the necessary information to guarantee a data consumer a good data experience and at the same time to let a data producer control the right usage of the exposed data.
Data contracts have a big potential from a data governance perspective because they aim to regulate producers and consumers of data through a supplier vs customer relationship. »
« Alchemesh: Data mesh framework — The genesis » – la mise en œuvre d’une approche data mesh, va bien entendu solliciter l’idée de data product, mais aussi de data contract
« Data Contracts: These become crucial for formalizing dependencies between teams and their products. Data contracts clarify expectations and responsibilities, ensuring effective communication and collaboration. ». L’article présente l’initiative d’un framework support au data mesh, en trois couches : 1- une console/portail pour naviguer dans le maillage (recouvre l’idée de datashop d’exposition des data products), 2- une couche de contrôle du maillage à partir des différentes métadonnées, 3- une couche de composants data (d’infrastructure jusqu’à des moteurs de traitements).
Source : https://medium.com/alchemesh/alchemesh-data-mesh-framework-the-genesis-aaa9aba2f7bd
5) « Data mesh roundtable — Data Product Design » – comment concevoir un produit de données, avec la partir codage des traitements (dont la logique métier – règles de gestion) incluse dans le produit de données (NB : sujet à débat voir https://towardsdatascience.com/data-engineering-redefined-643249cbbadd « To be very clear, data engineering should not implement business logic. » – selon le principe de « separation of concerns »), la mise en lumière de la gestion de versions (NB : pour mieux maîtriser les changements et la dépendance créée entre producteurs et consommateurs, avec l’idée de poser parfois des solutions tactiques temporaires – exemple en support de migrations de sources de données).
Source : https://medium.com/data-mesh-learning/data-mesh-roundtable-data-product-design-d556d4c54dc1
6) « Enabling FinOps for Data Mesh » – et pour finir un article sur la maîtrise de la dimension financière – contrôle des coûts liés aux principes du data mesh (dont associés aux data products) – principalement par rapport aux dépenses cloud. Avec la définition d’un certain nombre de mesures de couts (couts de production d’un data product, couts de consommation et leurs liens avec la consommation de ressources cloud).
Extrait : « Observability and monitoring of resource consumption metrics
The monitoring architecture must be integrated with a cost management tool. In the context of FinOps this is called Data Ingestion (see for instance Apptio Cloudability Total Cost and Datadog): »
Avec l’idée de rétro facturation de charges aux consommateurs : « Charging back triggers a mechanism of cost optimization and negotiation that improve the data value chain. In fact, consumers will fight to spend less, forcing producers to design cost effective architectures. »
Source : https://medium.com/agile-lab-engineering/enabling-finops-for-data-mesh-4b09b44b5e22
Data integration
Dans la famille des ETL pour intégrer les données, l’idée d’évolution vers les EtTL – pour Extract transform ou tweak Load Transform – https://glossary.airbyte.com/term/etlt/ , plus une dimension temps réel « EtLT architecture enhances ELT by adding real-time data extraction from sources » pour
Avec comme représentants : FiveTran, Airbyte, Matillion
Source : https://thenewstack.io/how-data-integration-is-evolving-beyond-etl/ et voir aussi une mise en perspective historique des solutions ETL – https://blog.devgenius.io/elt-is-dead-and-etlt-will-be-the-end-of-modern-data-processing-architecture-154b87c1cce0? avec la référence à l’initiative open source Apache SeaTunnel https://seatunnel.apache.org/
IA et data
Déjà dit, mais à redire, l’importance d’avoir un maximum de contexte lié aux données : data annotation (voir article exemple sur la supply chain), rôle et stratégie vis-à-vis des métadonnées actives : https://dataconomy.com/2024/06/05/data-annotations-role-in-streamlining-supply-chain-operations et aussi – https://medium.com/@davidsweenor/for-generative-ai-metadata-is-all-you-need-36ca088651b6
Et l’usage de l’IA pour exploiter les données immergées dans les flux « non structurés » : mails, slacks, appels téléphoniques, documents commerciaux… Avec l’offre d’OmniAI – https://getomni.ai/
Source : https://techcrunch.com/2024/06/22/omniai-transforms-business-data-for-ai/
Data qualité et IA – REX « The Sequence Pulse: The Architecture Powering Data Drift Detection at Uber »
NB : attention aux REX des grands acteurs data, leur problématique n’est pas forcément la problématique de tout le monde (cf. échec des projets big data).
La brique D3 Dataset Drift Detector d’Uber – surveillance des données selon plusieurs dimensions (anomalies, écarts par rapport aux données utilisées pour le modèle d’IA d’origine – appel à des moyens statistiques, de profilage des données).
Et toujours l’importance des métadonnées « Metadata: Each dataset within D3 is associated with specific metadata, including dimensions, aggregators, supported monitor types, excluded columns, and partition-related information. This metadata determines the types of monitors that can be defined on the dataset. Additionally, it enables streamlined automated onboarding of datasets, simplifying the process with just a single click. ».
Source : https://thesequence.substack.com/p/the-sequence-pulse-the-architecture
Réglementaire flux de données
Les réglementations sur les données et par les données s’accumulent et cela ne fera que continuer.
Sans une vue globale de ses données, il va vite être impossible de mener des projets spécifiques à chaque nouvelle réglementation. Par exemple l’anticipation par de la gouvernance automatisée doit être envisagée.
Exemple de nouvelles contraintes (sans oublier CSRD, Data act…) – Source : https://www.journaldunet.com/cybersecurite/1530593-comment-les-entreprises-peuvent-tirer-des-lecons-du-rgpd-pour-se-conformer-aux-nouvelles-exigences-telles-que-dora-et-nis-2/
En vrac (Architecture data, Données manquantes, Partage de données, Comment concilier confidentialité des données et tracking des comportements malsains, Collecte data)
1) Architecture data
Un article en contraposée, « Comment produire des données de mauvaises qualité » créez des silos, favorisez l’hétérogénéité, personnalisez l’intégration entre briques data, oubliez le lineage…
Data crime : l’exemple de confusion d’identité, si vous vous appelez Bob Smith aux U.S. alors vous n’êtes pas seul ! Avec les risques d’avoir son nom dans une black list et les conséquences associées. Source : https://tdan.com/data-crime-bob-smith/31880
Autre exemple de data crime – les faux hôtels sur Booking (et le data crime amplifié par l’IA générative). Source : https://www.lebigdata.fr/booking-faux-hotels-chatgpt
2) Données manquantes
Une analyse rétrospective des données manquantes relatives aux analyses de la pandémie de COVID. Un travail en profondeur qui décrit trois types de données manquantes : « Through our analysis, we surfaced three types of epistemological ambiguities COVID data builders encountered within their datasets: disappearing and ephemeral data, obscuring data, and disregarded data. ». Avec l’idée d’affiner le vocabulaire lié aux données manquantes pour mieux les maîtriser par tous les acteurs, y compris en communication. Source : https://journals.sagepub.com/doi/abs/10.1177/20539517241259666?ai=2b4&mi=ehikzz&af=R
3) « L’Europe dans l’économie mondiale des données : vers un paradigme du partage »
Les données à l’échelle de l’Europe, et le partage de données mis en avant – avec la citation : « Le partage de données est au cœur de ce que les économistes appellent les marchés multifaces. Un bon exemple est Skywise. Airbus fournit à ses clients (comme EasyJet par exemple) des données industrielles sur les avions (« tels que conçus » et « tels que fabriqués »). EasyJet partage en retour les données d’exploitation et de vol (« tel qu’exploité »). La combinaison et l’analyse de ces ressources de données partagées permettent ensuite des scénarios de maintenance intelligents qui conduisent à une utilisation plus élevée des actifs, à de nouveaux modèles de services, en bref : un bénéfice pour les deux parties. ». Source : https://legrandcontinent.eu/fr/2024/06/21/leurope-dans-leconomie-mondiale-des-donnees-vers-un-paradigme-du-partage/
4) Sujet difficile, comment concilier confidentialité des données et tracking des comportements malsains – Source : https://www.techdirt.com/2024/06/26/eus-going-dark-expert-group-publishes-42-point-surveillance-plan-for-access-to-all-devices-and-data-at-all-times/
5) Collecte data
Utiliser les objets connectés pour collecter des données tiers. Exemple de TomTom qui profite des données des véhicules pour concevoir ses cartes. Mais aussi les essuie-glaces connectes pour informer de la météo en temps réel aux autres conducteurs.
Et la collecte de données à son profit Source : https://www.lebigdata.fr/vos-donnees-de-sante-vont-etre-collectees-par-letat-pour-vous-envoyer-des-conseils
RDV maintenant en septembre pour la revue et les actualités de juillet et août.
Les commentaires sont fermés.