Cette revue est basée sur un ensemble de publications du mois d’avril 2024, issues de sources en lien avec le sujet Data. A piocher suivant vos centres d’intérêts.
Pour ce mois d’avril des sujets récurrents (Data platforms, Data et IA, Data management et data gouvernance, Data stratégie, Data qualité), des sujets aussi que l’on retrouve souvent (la data sauve le monde, les entreprises ne contrôlent pas leurs données).
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
Sommaire :
- Data platforms
- Data et IA
- Data stratégie
- Data gouvernance et data management
- Data qualité
- Quand les entreprises perdent le contrôle de leurs données
- Où va notre planète vu par la data
- En vrac (données des véhicules et assurance, données et blockchain, data citizen scientist, les 100 premiers jours du CDO par le Gartner, les données d’adresse, le burn out des acteurs data, neurodonnées, collecte des données, accidents routiers et données, interopérabilité, les données filent dans l’espace)
Data platforms
1) Autopromotion, notre travail avec Orkestra Data – https://www.orkestra-data.com/ est disponible. Au travers de la publication de deux guides : la Dynamique des data platforms et le Panorama des data platforms.
C’est téléchargeable sur le site d’Orkestra Data.
Un court aperçu ici (sommaires) : https://www.datassence.fr/2024/04/23/dynamique-et-panorama-des-data-platforms/.
2) Un article anodin au départ, mais en avançant dans sa lecture, excellent qui met le doigts sur des difficultés dans le déploiement d’une data platform et qui a réveillé en moi des situations d’échec vécues dans le passé (data hub, big data, data lake) et qui se répètent avec les data platforms. L’article propose des principes, de bon sens, mais à répéter, répéter…Je m’y suis attardé et fait un commentaire approfondi avec de nombreux vécus en tête. A surveiller dans votre environnement. Article de synthèse à partager.
a) Quand le développement data (pipelines and co) est rattrapé par la maîtrise des règles de développement logiciel … mais avec ses spécificités. La principale : savoir gérer l’intégration et l’évolution de sources de données de plus en plus nombreuses (avec pour moi le rôle clé de la maîtrise du découplage par exemple via les demi-interfaces paramétrées par les data contracts et dans lequel des règles d’appariement, d’interopérabilité, de policy sont positionnées : automatiser le cadre de vie des données).
b) Eternel et déjà vécu au moment du phénomène big data, les équipes data se concentrent sur la cathédrale technique, c’est-à-dire la construction de la data platform, du stack data … tout en vendant une perspective de maîtrise/valorisation des données. Malheureusement cela prend du temps, c’est difficile (rappel l’intégration est LE SUJET le plus difficile en data engineering) …pendant ce temps, peu de données disponibles, les cas d’usage attendent. L’échec de nombre de projets big data à cause de cela doit revenir en mémoire de nombreuses personnes (vécu, 18 mois de construction d’une plate-forme big data, pour finir de façon cachée par prendre en compte les premiers cas d’usage via une base MySQL discrètement glissée dans la plate-forme). Rappel des priorités : les données, les données, les données et savoir construire par les cas d’usage… à valeur qu’il faut répondre (demandes), chercher, imaginer, aligner avec la stratégie métier (bref la « porte ouverte » habituelle).
c) Autre phénomène qui se répète, l’équipe data (data platform) comme goulot d’étranglement (vécu N fois et depuis longtemps, déjà à l’époque des EAI, data hub, data lake, ce phénomène, avec des équipes qui grossissent et finissent par s’effondrer sur elles-mêmes sous le poids impossible à tenir de la connaissance métier et des responsabilités intenables). Cette équipe data est là pour lancer la dynamique. Mais elle doit savoir se délester progressivement de la responsabilité des cas d’usage et rester la gardienne de la qualité d’ensemble de la plate-forme et de son contenu.
d) Le self data est là pour faire avancer cette situation (délester l’équipe data platform vers les domaines métier). Mais attention, mener des projets data n’est pas inné ! Cela demande de maîtriser des principes de développement (retour au point n°1), de maîtriser l’architecture data d’ensemble (le maillage en data mesh) avec l’application de règles et normes … sinon un self chaos data arrive vite !
e) Le passage à l’échelle. Entre quelques cas d’usage et une vue des données à tous les niveaux de l’organisation (pas uniquement pour le management), touchant tous les domaines métier (et pas uniquement les data fluent), intégrant des natures de données de plus en plus large et en capacité d’appliquer des politiques globales, il y a des caps à franchir. A chaque cas d’usage, il faut s’arrêter au moins une fois pour se positionner dans cette vue plus large et faire évoluer sa data platform pour la préparer progressivement aux changements d’échelle (avoir un plan d’évolution). Sujet pas simple. Le habilitations sont un bon exemple (inexistant voire très simple sur les premiers cas d’usage puis devant être de plus en plus pris en compte et dans une perspective plus large ensuite).
Source l’auteur : Mahdi Karabiben – https://towardsdatascience.com/navigating-your-data-platforms-growing-pains-a-path-from-data-mess-to-data-mesh-c16df72f5463.
f) Surveiller les couts. Et pas uniquement les couts en cas d’une infrastructure cloud. Retour au point 2. Les couts les plus important se cachent souvent dans l’intégration, la maintenance en service de la data platform (quand on choisit de créer sa data platform). Vécu deux situations clients en parallèle. Le premier client choisi de développer sa data platform – à l’époque un data lake, avec une équipe réduite et motivée : couts de départ peu élevé, choix de composants open source… Le deuxième client choisi une data platform prête à l’emploi, un Teradata : couts de départ élevé. Bilan au bout de 2 ans, la courbe de rentabilité couts / projets data portés s’est inversée. Le 1er client a vu ses couts exploser en intégration, en maintenance – stabilisation de la plate-forme avec peu de cas d’usage délivré quand le 2ème a pu produire rapidement de nombreux cas d’usage avec un cout de maintenance de la plate-forme faible (logique progiciel). La recommandation : suivez le cout de votre data platform (logiciel, intégration, maintenance, debuggage des traitements associés aux cas d’usage) au jour le jour !
g) Déjà évoqué dans une revue précédente – voir par exemple dans les tendances data platforms – https://www.datassence.fr/2024/02/10/revue-data-du-mois-janvier-2024/#_ftnref1 ), et encore un retour au point 1, les développements data n’échappent pas aux principes de génie logiciel (gestion des tests par exemple, gestion des environnements). Sur ce sujet voir l’évolution de l’offre Dbt. Et dans la même idée, le monde de la données doit disposer de moyens de supervision, de monitoring (responsabilité de l’exploitation), avec la data observability qui doit entrer en jeu.
Et la dernière recommandation qui rejoint le point 2 et le point 5 (plan d’évolution), (éternel aussi) savoir maîtriser la pression de la course technologique où la dernière fonctionnalité annoncée par les éditeurs de data platform est forcément indispensable (Vécu pendant le phénomène big data, de briques techniques déployées par des clients alors qu’une simple base relationnelle suffisait).
Voir aussi https://insidebigdata.com/2024/04/22/the-solution-to-data-in-motion-is-to-just-stop/.
Avec l’accent mis sur le sujet du cout d’intégration des sources de données (d’ingestion des données) et l’idée de limiter au maximum les mouvements de données (requêtage fédéré, cache, virtualisation…voir aussi l’idée de zéro ETL)… le data lakehouse devient uniquement un moteur de calcul, de traitement des données centralisé (toujours le débat cyclique sur les données, gestion centralisée <-> gestion décentralisée).
3) Datavolo (https://datavolo.io/ ) propose un nouveau modèle de pipelines de données, conçu pour l’IA et basé sur Apache Nifi. L’apport de Datavolo, traitement multimodale de données non structurées fondamentales pour les IA génératives. Idée de hub de données non structurées versus une logique point à point. En synthèse Datavolo propose une brique de développement de pipelines de données spécialisée dans les données non structurées.
Extrait « According to Clark, the existing relational data model that serves as the foundation of the modern economy will be joined by an entirely new data model that’s designed to meet the specific needs of AI. ». Source : https://siliconangle.com/2024/04/02/startup-datavolo-raises-21m-transform-generative-ai-models-access-unstructured-data/.
4) Dell et Starburst s’associent pour promouvoir une offre dell data lakehouse.
La réponse à « The proliferation of data presents a dual challenge: the need for a modern data platform that simplifies data management while offering flexibility and scalability. However, the prevailing options — cloud migration or on-premises DIY solutions — fall short, underscoring the urgent demand for a more viable alternative, according to Jain ». Source : https://siliconangle.com/2024/03/18/dell-data-lakehouse-cubeconversations.
5) Un tour d’horizon des KPI à prendre en compte pour surveiller la qualité d’ensemble des données au sein d’une data platform (« This article explores key performance indicators (KPIs) across various aspects, including data quality, monitoring, observability, cost optimization (FinOps), and sustainable practices (GreenOps) »).
Exemples de KPI : Taux d’exactitude des données, Cohérence des données, Taux d’actualisation des données, Couts par traitement de données…
A compléter par des KPI de maillage. Source https://medium.com/dcsfamily/build-trust-and-reliability-data-platforms-5ce79319495f.
6) Quand le monde des données découvre le mode déclaratif… code as data ou encore le code remplacé par des métadonnées (exemple policy as code). Intérêt CI/CD. Dbt cité avec l’utilisation de YAML (Yet Another Markup Language) pour la déclaration de tables incluant la structure, la documentation et les tests. Voir aussi SQLMesh. Concerne aussi, les pipelines de données, les data contracts, les couches sémantiques, les data products jusqu’au data visualisation en mode déclaratif. NB : attention demande une autre forme de pensée (par état), pas de standardisation de fait, chacun au niveau de sa data platform doit définir son niveau d’abstraction (YAML) … non forcément commun. Et à ce jour peu de data platform ont cette capacité à traiter cette logique et exploiter des fichiers YAML. Source : https://blog.picnic.nl/yaml-developers-and-the-declarative-data-platforms-4719b7a1311c.
7) L’accès aux données est le premier sujet à traiter par les data platforms. Et c’est un sujet qui reste très attendu et un défi malgré l’effort des MDS (Modern Stack Data). Pour les acteurs data, métier, IT, la principale difficulté est de « se saisir » des données, les trouver, les « toucher ». Les données vues comme produit sont une façon de « se saisir » des données. Il existe d’autres façons de « se saisir » des données, par exemple la classification des données. Savoir classifier les données devrait être une fonction première d’une data platform. Classer c’est comprendre (« se saisir ») par ensembles les données (par sensibilité, par type, par risque, par nature métier, par usage…). Et rappel classer c’est aussi un pouvoir … utile à la data gouvernance. Un tour d’horizon du sujet ici : https://www.dataversity.net/fundamentals-of-data-classification/.
Voir aussi tiré par le domaine de la sécurité , une revue (par Varonis) de moyens de classification des données : https://www.varonis.com/blog/data-classification-buyers-guide.
Data et IA
1) Quand l’IA tire le besoin d’une vue unifiée des données – commentaire d’une étude de Cloudera :
– « One of the key requirements of modern data architecture is to have a single data platform that works seamlessly across public cloud and on-premises infrastructure. ». Personnellement je pense que c’est une utopie …une seule data platform (mais l’étude est poussée par Cloudera !). Une vue unifiée non réaliste, une vue organisée oui,
– Mais la vue unifiée serait essentielle pour l’IA,
– Et les stratégies hybrides et multi cloud complexifie la chose.
2) Le contexte, le contexte, le contexte des données est essentiel. C’est vrai partout dès lors qu’il faut interpréter des données. C’est donc vrais aussi pour l’IA en entrée comme en sortie : Extrait – « Why is truly, explicitly contextualized data so important to the success of LLMs? We don’t want machines to have to guess more than they have to. In the current piles of scraped, labeled, compressed and tensored data that are used as LLM inputs, machines have to guess which context is meant (from the input) and which context is needed (for the output). ».
Et ce contexte, c’est la vue unifiée du point 1, des métadonnées, de l’étiquetage ou encore des « smart data fingerprinting » promus par Infosys sur les données non structurées (https://www.infosys.com/services/data-analytics/documents/smart-data-fingerprinting.pdf ).
Déjà n fois dit, la stratégie des métadonnées est clé (voir l’exemple dans l’article d’utilisation d’un jumeau numérique).
Source : https://www.datasciencecentral.com/data-fitness-and-its-impact-potential-on-enterprise-agility/.
3) Quand les LLM permettraient de labéliser automatiquement les données … et remplacer les travailleurs humains (et pour les protéger des contenus dangereux) et accélérer le processus de labélisation :
– L’opinion est partagée quant à la possibilité des LLM de réaliser cela,
– La performance de classification des données varie entre LLM et il y a des tâches pour lesquelles les LLM ne fonctionnent pas bien (la labélisation n’est pas binaire, elle peut être un compromis, le résultat d’un vote d’opinion). De plus les LLM censurent certains contenus … qu’il ne devient plus possible de traiter. Ne risque-t-on pas de retrouver les biais des LLM dans la labélisation. La « créativité » – génération (« hallucinations » des IA) peut faire dévier la labélisation. L’anglais reste à la langue de ressource, attention si la labélisation concerne d’autres langues,
– En synthèse : prudence.
Et il y a toujours le recourt à des sociétés spécialisées de labélisation – un tour d’horizon ici :
https://www.datanami.com/2024/04/23/the-top-five-data-labeling-firms-according-to-everest-group/. Exemples Appen aurait labélisé 100 millions de données, avec un CA de 273 Millions de $ en 2023, Taskus est capable de mobiliser 100 000 experts dans le monde…
4) Quand l’IA générative Claude 3, se montre performante dans l’extraction de données structurées à partir de documents (excel inclus)… mais cela a un prix.
Sources : https://python.plainenglish.io/claude-3-the-king-of-data-extraction-f06ad161aabf et https://www.lebigdata.fr/ia-generative-commerce-detail-strategies-gestion-donnee-strategie.
5) La course aux données par les fournisseurs de LLM :
Les moteurs de LLM cherchent toutes les données possibles après avoir épuisé celles directement disponibles sur le web.
– OpenAI en guerre avec Youtube après avoir récupéré sous forme de texte une part des paroles capturées dans les vidéos publiées (un million d’heures de vidéos transcrites),
– Meta discute avec des éditeurs pour récupérer les ouvrages publiés (textes long),
– La solution des données synthétiques ?
Sources : https://www.nytimes.com/2024/04/06/technology/tech-giants-harvest-data-artificial-intelligence.html et https://www.nytimes.com/2024/04/06/technology/ai-data-tech-takeaways.html.
Et repris par : https://www.lebigdata.fr/donees-entrainement-ia.
Avec la contre-offensive – protéger ses données des moteurs de LLM : Un tour d’horizon des techniques pour le faire – se désinscrire (interdire le partage de ses données comme dans Substack, Slack, Tumblr…) et au-delà ne pas faire que les données que l’on utilise avec les moteurs LLM soient utilisées à leur tour. Source : https://www.wired.com/story/how-to-stop-your-data-from-being-used-to-train-ai/.
Mais aussi des accords comme avec le Financial Times : https://www.lebigdata.fr/nouvelle-victoire-de-lia-contre-le-journalisme-financial-times-se-vend-a-openai.
6) Les IA peuvent être empoisonnées par les données … sujet exacerbé en temps de guerre quand l’IA intervient sur le champ de bataille. J’en parle aussi ici : https://www.datassence.fr/2024/02/01/la-fausse-innocence-des-donnees/ Source : https://www.lebigdata.fr/empoisonnement-de-lia-ce-grave-danger-neglige-en-cas-de-guerre.
Data stratégie
Un article qui bâtit la stratégie sur un classement des problématiques data en :
« Data Availability and Structure, Analytics Strategy and Planning, Data Value and Direction, Careers and Talent Acquisition (People). »
Et croisées avec des objectifs de maturité / maîtrise.
Un tableau résume les questions à traiter.
A comparer avec un autre article (qui date d’octobre 2022), pour parler data stratégie pendre 3 points de vue et pas plus (faire simple) : « with just three dimensions: data, technology and people (“3D data story”) ».
Et croisés avec des objectifs de maturité / maîtrise (inspiré du Dell Data Maturity Model).
Un tableau résume les questions (feuille de route) à traiter comme pour l’article précédent. Source : https://towardsdatascience.com/pitching-your-data-strategy-translating-tech-talk-for-management-and-users-bbd044872ee4.
Data gouvernance et data management
A retenir :
1) Déjà souvent dit : les métadonnées sont clés et indispensables pour un bon data management et bonne data gouvernance. Extrait : « Metadata can be thought of as data about data. It provides context, structure, and meaning to raw data, facilitating its interpretation, management, and usability. ». Elles concernent, la cartographie des données, le lineage, le mapping (avec une source, avec un data product, avec l’identification de données sensibles). « Metadata repositories serve as the backbone of metadata management, providing a centralized location for storing and accessing metadata information, including data mappings. ». Source : https://www.datasciencecentral.com/how-data-mapping-enhances-data-governance-and-lineage/.
2) Le levier (bâton) de la réglementation et des risques pour la gouvernance des données (défensive). Evénement récent dans ce sens, la SEC met en garde les entreprises sur leur sécurité des données face à la cybermenace et la perte de confiance conséquente. Et introduit une obligation de déclaration sous 4 jours des accidents de sécurité. Extrait : « Why Data Governance Is Now on the Board’s Agenda. In the current landscape, where the detection and impact of data breaches can go undetermined for months, data governance should ascend to the forefront of boardroom agendas, especially with audit committees. The urgency stems from the need to swiftly discern the scope of data compromised during a cybersecurity incident. » … « CIOs must pivot to data security posture management (DSPM) solutions that offer a panoramic view of data, assessing risks and materiality through automated discovery and classification. ». Source : https://tdan.com/data-governance-gets-a-new-impetus/31692.
3) Un article sur la gouvernance des données vue au travers de l’offre Microsoft Purview (version du 08 avril 24) :
– Evolution du data catalog, évolution d’une vue technique à une vue fonctionnelle (gestion des domaines métier, produits de données, qualité de données, OKR – Objectives and Key Results, politique d’accès aux données, santé du patrimoine de données, fusion avec les aspects sécurité, étiquettes de sensibilité des données, historique d’évolution des actifs au catalogue…),
– Attention à ce stade de la roadmap Microsoft, la portée des données couvertes comprend suivant la fonction : Azure SQL, Blog Storage, and ADLS gen2, ADLS (Delta only),
– A venir la recherche dans le catalogue appuyée par le Copilote. A noter pas encore de vues de type lineage.
– Reste à Microsoft d’aligner ses différents composants sur cette vue, par exemple entre les domaines vus de Microsoft Fabric et les domaines vus de Purview ou encore la prise en compte des règles qualité dans les pipelines de données.
Exemple d’apport à la data gouvernance :
« Preconfigured reporting that displays the quality of metadata across various dimensions ».
Commentaire personnel : l’évolution Purview va complètement dans la tendance métier des data platform.
Purview passe d’une vision technique des données (vue physique) à une vue logique orientée métier sur les données. Ce qui naturellement favorise la gouvernance des données et lève le frein majeur au rôle des acteurs en charge de cette gouvernance (CDO) à savoir la capacité de « se saisir » des données (les comprendre dans une logique métier, parler produit de données et non pas tables physiques, maîtriser le lien avec les domaines métier, être en capacité d’agir sur les données via des politiques, contrôler la qualité des données, mesurer l’apport des données via les OKR, supervision globale de santé du patrimoine de données et de son historique, etc).
La boîte à outil data de Microsoft est riche … reste à qu’elle soit bien intégrée.
Source : https://piethein.medium.com/microsoft-purviews-reimagined-data-governance-experience-9af0dd0cdebd.
En synthèse, la gouvernance des données ne doit pas être « à côté » mais intégrée à la gouvernance d’entreprise. Voir pour cela comment aligner les deux gouvernance : https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/#_ftn4.
4) Vu dans le fil d’actualité Linkedin, un tableau de synthèse intéressant de définitions et de complémentarité entre data management et data gouvernance. Source :
5) A lire un article qui remet les choses à leur place, ne pas confondre data gouvernance et data management, comment articuler/aligner la gouvernance à différentes échelles (des domaines métier à l’entreprise voire son écosystème), comment gouvernance par le haut et par le bas se rencontrent.
Figure tirée de l’article et inspirée du DMBOK (Data Management Body of Knowledge) du DAMA.
Source : https://tdan.com/data-governance-made-simple/31732.
NB : je vous invite à suivre toutes les productions de DAMA France sur ce sujet du data management et de la data gouvernance. C’est ici : https://dama-france.org/ et https://www.linkedin.com/company/dama-france/.
Data qualité
Nouveautés (mais problèmes connus !) :
1) Foundational (https://www.foundational.io/ ) traque les défauts de qualités de données en permettant aux développeurs de faire le lien avec les changements de configuration de leurs traitements de données (pipelines). Rejoint l’idée de la data qui redécouvre les bonnes pratiques du génie logiciel. Source : https://siliconangle.com/2024/03/25/foundational-nabs-8m-help-developers-fix-data-quality-issues-faster/.
Et dans le même esprit par Dbt (https://www.getdbt.com/ ), une étude relève que le combat de la qualité des données est le combat premier et le plus difficile. Et la bataille est rude, la qualité se détériore. Vu aussi dans d’autres études (Monte Carlo il y a un an, Bigeye…).
2) « The reason that data quality will never be a “solved problem,” Patel said, is partly because data will always be collected from various sources in various ways, and partly because or data quality lies in the eye of the beholder. »
‘“You’re always collecting more and more data,” Patel told Datanami recently. “If you can find a way to get more data, and no one says no to it, it’s always going to be messy. It’s always going to be dirty.”
… ce n’est pas faux ! Rappel, la qualité des données dépend de l’usage que l’on fait des données. Il n’y a pas de qualité intrinsèque.
Source : https://www.datanami.com/2024/04/05/data-quality-getting-worse-report-says/.
Et exemple (date de mars) : l’idée de score de « saleté » des données pour les moteurs d’IA – https://towardsdatascience.com/data-dirtiness-score-fe2ca5678d40.
Voir aussi l’enquête de Precisely et ce que dit le Forum Economique Mondial… cités ici : https://www.dataversity.net/what-is-data-reliability-and-why-do-you-need-it/.
3) Un rappel (évidence), les règles de contrôle qualité sont des règles métier. Source : https://blog.masterdata.co.za/2024/04/30/beyond-validation-how-the-best-data-quality-rules-are-actually-business-rules/.
Quand les entreprises perdent le contrôle de leurs données
Les entreprises perdent le contrôle de leurs données pourtant dans leurs systèmes, jusqu’à ne plus être capable de les retraiter. Cela me rappelle un des premiers articles de ce site avec le cas Facebook qui avait perdu ses données : https://www.datassence.fr/2022/09/12/maman-jai-perdu-les-donnees-data-lineage-et-data-observability-episode-1/ .
Le premier article mais le doigt sur un certain nombre de vérités historiques qui me font remonter le souvenir de situations ubuesques où par exemple, une entreprise n’avait pas d’accès direct aux données d’un logiciel qu’elle utilisait, ni à leur modèle par la faute d’un contrat de licensing mal négocié.
Et j’aime bien cette idée de taxe d’intégration – extrait « The implication here is that for established organizations, in 2024, what dataware company Cinchy calls an “integration tax” could be growing at 15 percent or more every year… ». Sources : https://www.datasciencecentral.com/losing-control-of-your-companys-data-youre-not-alone/.
Et aussi quand l’IA déraille et fourni de mauvaises données sur une personne … avec l’impossibilité de corriger – Extrait « « OpenAI admet ouvertement qu’elle n’est pas en mesure de corriger les informations incorrectes sur ChatGPT », pointe l’association. Elle l’accuse également de ne pas pouvoir ou savoir dire « d’où proviennent les données ni quelles données ChatGPT stocke sur des personnes individuelles. »- Source : https://www.numerama.com/tech/1734602-chatgpt-dit-nimporte-quoi-sur-les-internautes-et-se-fait-attaquer.html.
Où va notre planète vu par la data
Yves Caseau en parle ici : http://organisationarchitecture.blogspot.com/2024/04/un-regard-alternatif-sur-le.html. Avec une excellente revue du livre de de Hannah Ritchie. Le titre : « Not the End of the World: How We Can Be the First Generation to Build a Sustainable Planet ». J’aime beaucoup ce livre. Une vision constructive, étayée. La data ne fera pas tout (et de loin), mais il y a des gens intelligents qui savent l’exploiter. Hannah Ritchie est membre de « Our World in Data » – https://ourworldindata.org/ .
Et aussi dans le même esprit, quand j’étais plus jeune (beaucoup), j’étais fan de Auguste Piccard et de son fils qui ont inventé le bathyscaphe. Ils sont le grand père et le père de Bertrand Piccard (l’avion solaire) qui est dans le même esprit que Hannah Ritchie. Voir le site de B. Piccard – https://bertrandpiccard.com/.
A consommer sans modération après avoir fermé les infos du jour !
En vrac (données des véhicules et assurance, données et blockchain, data citizen scientist, 100 premiers jours du CDO par le Gartner, les données d’adresse, le burn out des acteurs data, neurodonnées, collecte des données, accidents routiers et données, interopérabilité, les données filent dans l’espace)
1) L’accointance données de conduite et assureurs : https://siliconangle.com/2024/03/11/report-automakers-might-secretly-selling-driving-data-insurance-companies/ et https://www.nytimes.com/2024/03/11/technology/carmakers-driver-tracking-insurance.html.
2) La blockchain comme support garantissant l’intégrité des données mais pas comme garantie de données de meilleure qualité contrairement à ce que dit cet article. Source : https://www.smartdatacollective.com/implications-of-blockchain-technology-on-big-data/.
Et aussi, le traitement de l’intégrité des données financières (cadre Defi Decentralized Finance) par le couplage de sources de données avec une blockchain via FTSOV2. Source : https://dataconomy.com/2024/04/17/decentralizing-data-how-ftsov2-is-revolutionizing-oracle-services-in-defi.
Et les données de la blockchain dans le cadre des cryptomonnaies qui servent de données d’entraînement pour repérer les formes de blanchiment d’argent. Source : https://www.wired.com/story/ai-crypto-tracing-model-money-laundering/.
3) La remise en cause ou le mythe du citizen data scientist dans les entreprises. Outre l’aspect compétence, sa place (responsabilité) dans l’organisation est clé. Reconnu cela marche, « à côté » cela ne marche pas. Cela ne s’improvise pas sur un coin de table. J’adhère à ce qui est dit dans l’article. Et de mon côté, vécu une situation où le rôle était officiel intégré dans des équipes métier d’appui avec succès et une situation au bon vouloir sans un véritable positionnement avec peu de succès et surtout le classique démarrage en trombe et soufflet qui retombe. Source : https://tdan.com/do-citizen-data-scientists-add-value-or-is-the-concept-mere-buzz/31716.
4) Le Gartner publie un guide pour accompagner les 100 premiers jour d’un CDO.
Source : https://www.gartner.com/en/data-analytics/insights/new-to-role-cdao.
5) Dans le jeu des données, qui n’a pas traité les données d’adresse … ? Le standard de représentation des adresses en France a été publié pour revue. Un rôle clé pour « Ce standard se place dans un contexte de l’adresse encore en évolution -notamment celles prévues dans la feuille de route BAN, les travaux en cours du RIAL (référentiel inter administratif des locaux, du GT bâti (futur RNB – Référentiel national des bâtiments) et du GT Routes. ». Et cela « en cohérence avec les spécifications Adresse de la directive INSPIRE et la norme internationale ISO 19160 ». A prévoir un nième chantier au sein des S.I. de normalisation des adresses ! Source : https://cnig.gouv.fr/IMG/pdf/prj_standard_adresse_pour_revue.pdf.
En regard du sujet des adresses… le business des données de géopositionnement / localisation des entreprises, commerces… Dataplor (https://www.dataplor.com/ ) constitue une base de données mondiale avec l’appui des technologies data, de l’IA et d’un réseau de 100 000 valideurs. A ce jour 250 millions de référence sur plus de 200 pays/territoires. Source : https://techcrunch.com/2024/04/18/dataplor-data-intelligence-location/?guccounter=1.
6) Et toujours le burn out des acteurs et équipes data (déjà évoqué dans les précédentes revues … j’aurais dû créer un tag spécifique … je vais le faire !). « Data teams are burned out – here’s how leaders can fix it. Commentary by Drew Banin, Co-Founder of dbt Labs. Rendre visible le travail de ces acteurs. Source : https://insidebigdata.com/2024/04/04/heard-on-the-street-4-4-2024/.
Voir aussi : https://www.datassence.fr/2023/07/17/revue-data-du-mois-juin-2023/#_ftn3 et https://www.datassence.fr/2023/06/23/lequation-des-donnees-dans-les-systemes-dinformation/.
7) On y arrive, il va falloir protéger les données capturées de son cerveau (les neurodonnées) ! L’Etat du Colorado a signé une loi dans ce sens. Source : https://www.nytimes.com/2024/04/17/science/colorado-brain-data-privacy.html.
8) La stratégie et la maîtrise de la collecte des données devrait être le sujet de départ de toute démarche data (maîtriser la « naissance » des données, c’est la racine de tout). Un exemple chez L’Oréal. Source : https://www.journaldunet.com/martech/1529817-reinventer-la-collecte-de-donnees-le-cas-pratique-de-l-oreal-avec-qualifio/.
9) Un cas d’usage représentatif de mise sous data d’un écosystème : flotte de transport, conducteurs, assureurs pour plus de sécurité (prévenir les accidents).
Source : https://diginomica.com/fleet-management-safety-good-business-why-connected-data-platform-key.
10) Et toujours le sujet de l’interopérabilité des données, qui passe par des standards à prendre en compte. Avec l’exemple de l’initiative IDS International Data Spaces. Source :https://internationaldataspaces.org/advancing-global-interoperability-the-role-of-standardization-in-data-spaces/.
11) Clin d’œil pour finir … les données filent dans l’espace.
La NASA a réussi à transmettre des données à plus de 140 millions de kms à l’aide de lasers spatiaux. Source : https://www.nasa.gov/missions/psyche-mission/nasas-optical-comms-demo-transmits-data-over-140-million-miles/.
Source NASA : This visualization shows the Psyche spacecraft’s position on April 8 when the DSOC flight laser transceiver transmitted data at a rate of 25 Mbps over 140 million miles to a downlink station on Earth. NASA/JPL-Caltech.
Quand certains pensent que l’on va tous finir sous forme de données … cela laisse de l’espoir pour voyager dans l’espace !
RDV maintenant en juin pour la revue et les actualités de mai
Comments are closed.