Dernière modification le 10 décembre 2024
Comme d’habitude une suite de revues commentées de sujets data en lien avec un ensemble d’articles du mois de novembre.
Ce mois, une revue organisée autour de deux thèmes centraux : la gouvernance des données et l’architecture de données.
Sinon, les sujets récurrents (Data platforms, Data product, BI/ data analytics, Data et IA…).
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
Sommaire :
- Gouvernance des données
- Data architecture : bonnes et mauvaises pratiques
- Data platforms
- L’idée de data product gagne du terrain
- BI / Analytique
- Data et IA
- En vrac (Open Data, Vast Date – OSData, Data physicalisation, Souveraineté data, Data colonisation, Démocraties et data, Data et santé, Sport et données qualitatives)
Gouvernance des données
1) Centralisation / Décentralisation – Stratégique / Tactique / Opérationnel : comment positionner la gouvernance.
Souvent dès que l’on parle gouvernance des données, une des premières question est le modèle de gouvernance à retenir : centralisé ou décentralisé. C’est pour moi un faux débat. On peut très bien avoir pour une famille de données une gouvernance centralisée et pour une autre une gouvernance décentralisée. Ensuite on connait les limites de chacun des deux modèles. S’il y a une règle à retenir, c’est de choisir un modèle aligné sur la gouvernance d’entreprise et pas « à côté », c’est-à-dire spécifique aux données.
L’article suivant est intéressant, il introduit une autre dimension pour un modèle de gouvernance au travers de trois types d’initiatives : stratégique, tactique autonome et opérationnelle autonome.
Extrait « Les initiatives stratégiques s’inscrivent dans une vision à long terme et sont souvent impulsées par la direction générale. Elles posent les bases d’une politique de gouvernance unifiée pour assurer la qualité, la sécurité et la conformité des données. Elles structurent la gouvernance autour de normes communes, alignées aux objectifs globaux.
Les initiatives tactiques autonomes répondent à des besoins métiers spécifiques ou à des projets ponctuels. Elles apportent des solutions rapides et ciblées, sans attendre une validation stratégique. Leur autonomie leur permet d’ajuster les pratiques en fonction des besoins immédiats. Cette approche peut contribuer à enrichir la stratégie de gouvernance.
Les initiatives opérationnelles autonomes assurent la gestion du cycle de vie des données. Elles répondent aux besoins immédiats des unités métiers et posent des standards opérationnels, qui peuvent inspirer une gouvernance plus large. ». En croisant cela avec l’aspect centralisé / décentralisé on obtient une matrice de positionnement riche. Je vous laisse lire la suite. Source : « Modèle et initiative de gouvernance des données : quels assortiments ? » auteur Charles Ngando Black – https://management-datascience.org/articles/37176/
2) Pourquoi la gouvernance des données échoue si souvent ?
- Classique : parce qu’on choisit d’abord un outil et on pense que c’est réglé (le défaut du solutionnisme technique). Le défi n’est pas là, il est dans l’organisation et l’esprit (culture et politiques).
- Traiter la gouvernance comme un projet informatique ! Erreur fatale, c’est un sujet d’entreprise métier et informatique.
- Les données sont de la responsabilité de tous. Ce type fréquent d’incantation est à prendre avec précaution. La donnée est partout, cela ne veut pas dire que la responsabilité est partout. Il faut une responsabilité claire et identifiée des données et non pas diluée (inefficace).
- Vouloir traiter toutes les données … pareto est utile ici. Se concentrer d’abord sur les données critiques (identifiées par une analyse de risques, de la valeur, en interface entre domaines et avec l’extérieur, référentielles).
- Faire de la gouvernance en mode réactif : données hackées, défaut de qualité impactant, audit, échéance réglementaire que l’on n’avait pas vu venir…La gouvernance est une structure qui doit être en place (proactive), qui encadre les activités IT et métier, constituées de points de gouvernance positionnés aux bons endroits (voir ce que l’article liste comme points, jusqu’à l’idée de plan des risques – NB : j’ai participé à des systèmes où ce type de plans était prévus, répétés … vitaux).
- La statistique choquante que l’on voit souvent circuler : « Misalignment with Business Objectives- Here’s a shocking stat that keeps me up at night: 85% of data initiatives fail to deliver business value. ». L’éternel sujet de l’alignement business (besoins, stratégies, règles…). La gouvernance en dehors de cet alignement ne marche pas voire peut être une entrave (c’est du bon sens).
- Négliger voire oublier les données non structurées alors qu’elles portent une grande richesses en données et cela d’autant plus avec l’arrivée de l’IA capable d’exploiter ce type de données.
L’article est riche, il rejoint et complète pas mal de points évoqués ici : https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/
Source : https://medium.com/@Keith_Coe/why-data-governance-fails-so-often-ce71ec31869c
3) Le défi de la sécurité des données vu de la gouvernance des données, dont la gouvernance des données dans le cloud. Source : https://3liud.medium.com/data-governance-challenges-and-solutions-2c152a54b2cf
Le lean et l’approche systémique appliqués à la gouvernance des données : lean et qualité de données (décalage vers la gauche – au plus près de la source de données), boucles de feedback / rétroaction à prévoir. La gouvernance des données n’est pas un processus linéaire. C’est une structure – un système (où les métadonnées sont importantes) dans le système. L’article prend l’exemple de la qualité des données.
Source : https://tdan.com/the-art-of-lean-governance-a-systems-thinking-approach-to-data-governance/32239
4) La gouvernance des données peut être fun
La gouvernance des données … c’est ennuyeux, cela peut faire peur. L’article suivant propose des pistes pour en faire quelque chose de fun ! L’idée passe par des métaphores. Imaginez-vous dans une jungle de données, comment s’y retrouver. Imaginez un produit de données comme un plat où la qualité des ingrédients (des données) est essentielle. Imaginez de coller des étiquettes sur vos données pour les classer. Imaginez de mettre sous clé les données sensibles. Jouez les détectives sur les données (qui les a utilisé et pourquoi, d’où elles viennent, quelles traces ont-elles laissé ?). Avant tout projet, faite une chasse au trésor – aux données. Pensez aux salles blanches de partage de données. Article sympathique, à s’inspirer et à élargir à d’autres thèmes de la data gouvernance. Source :
5) Gouvernance des données et graphes de connaissance
Depuis un moment on voit le retour en grâce des graphes de connaissance (pour ceux qui ont vécu l’époque du knowledge management). Un graphe de connaissance appliqué aux données est naturellement un bon support pour la gouvernance. C’est une façon de voir les données qui montre les liens (et natures de liens) / les dépendances entre données, les données centrales (avec beaucoup de liens), les groupes de données … Et cette façon de voir permet de mieux visualiser les données. C’est une bonne « prise » sur les données pour les personnes et les systèmes en charge de leur gouvernance. Mais attention, maintenir un graphe de connaissance des données, demande une gouvernance des métadonnées. Source :
https://www.nicolaaskham.com/blog/2024/11/21/knowledge-graphs-and-data-governance
https://nicola-76063.medium.com/knowledge-graphs-and-data-governance-4798f85e8b8c
6) Du data lake au data swamp : le rôle clé de la gouvernance des données et de la stratégie de gestion des métadonnées. Point souvent négligé. Source :
7) Comment a évolué et doit s’exprimer le leadership sur les données : de la gouvernance défensive (réglementaire) à la gouvernance offensive (couvrant toute les chaîne de valeur des données). L’article répond à la question « Qu’est-ce que le leadership en matière de données ? ». Le leadership n’est pas réservé au CDO. Il existe d’autres leaders sur les données non forcément désignés comme tel (gardien du DW historique, spécialiste de telle réglementation, un responsable marketing afficionados des données clients, un IT human middleware hub data incontournable pour des processus…)… « These are typically not people who will ever have enterprise responsibility, but they own critical use cases for data in their areas and, therefore, need to pay close attention to it. ». Cela pour dire que si la gouvernance se réduit autour de quelques spécialistes des données c’est un échec. Elle doit être communautaire (après le retour du knowledge management, le retour des CoP – communautés de pratique !?). Avec le problème de comment faciliter le leadership sur les données ? La réponse via la « productisation » des données (toujours le problème n°1 des données : leur accessibilité). Un autre outil est mentionné dans l’article l’arbre des métriques / KPI permettant d’avoir une vue d’ensemble et articulée des KPI entres-elles (déjà évoqué dans plusieurs revues – avec en particulier, l’idée d’arbres de performance : https://www.datassence.fr/2024/01/18/revue-data-du-mois-decembre-2023/#_ftn5 – voir aussi dans l’actualité de ce mois l’article « Lessons Learned Implementing Metric Trees » – https://sqlpatterns.com/p/lessons-learned-implementing-metric – qui parle aussi d’arbre des métriques, à associer avec l’idée d’arbre des hypothèses présenté ici – https://towardsdatascience.com/how-to-answer-business-questions-with-data-26f6f067de71 ). Le rôle d’une data platform est aussi mentionné (idée de disposer d’une infrastructure unifiée – de vue des données). Le tout avec une communication de la vision des données et de comment cette vision est portée (communication dont la gouvernance des données est responsable).
Source :
8) Le sujet de la confiance dans les données … le but ultime de la gouvernance des données.
Les deux premiers articles parlent de 7 facteurs pour la confiance dans les données : 1- la qualité automatisée des données, 2- la gestion de politiques des données, 3- le support du cadre ABC – Audit, Balance and Controls – garantie de l’intégrité des données, de l’absence de perte, tout au long du cycle de vie des données en commençant par l’intégration de données (avec la reprise des bons principes d’en-tête de flux, des EAI…), 4- l’observabilité des données, 5- la maîtrise de la gestion des changements (bien connus dans l’exploitation IT), 6- les contrats de données- permet de contrôler les données (production / consommation), d’appliquer les règles de gouvernance (le contrat est un point de gouvernance) … idem reprend les bons principes de gestion des hub data, EAI…., 7- l’optimisation des couts (en particulier dans les environnements cloud).
Le troisième article : tout commence par la phrase redoutée « Ces chiffres ne sont pas exacts. ». L’article présente l’équation de la confiance (https://trustedadvisor.com/why-trust-matters/understanding-trust/understanding-the-trust-equation ) appliquée aux données.
Cela donne : la confiance passe principalement par les personnes … ici tout acteur impliqué dans la gouvernance des données (soyez digne de confiance), les données demandent de la rigueur (soyez précis), racontez vos histoires de données aux acteurs métier (soyez ouvert, transparent), (bien entendu – toujours cette porte ouverte éternelle…) montrez votre curiosité au business, guidez les métiers sur les données (soyez data business), sécurisez les acteurs métier en cas de questions, d’irritants (soyez là, présent, accessible au quotidien).
Sources : (rattrapage d’octobre) https://medium.com/@sutherl99/data-trust-the-cornerstone-of-data-control-part-1-2c76da9d904e et https://taylor-count.medium.com/the-data-trust-equation-faa550d7fbb9.
9) Et toujours le sujet de la qualité des données
Elle est ajustable à la valeur défendue, elle dépend de l’utilisation des données, des données en défaut de qualité peuvent être laissées telles quelles, la surveillance des sources manuelles est naturellement à privilégier (exemple des saisies front dans un outils de CRM), traiter le récurrent plutôt que le ponctuel, ne négligez pas les rejets (un sujet de gouvernance classique, qui s’occupe des rejets ? J’ai souvent vu les voir tomber dans des oubliettes…). Source :
https://towardsdatascience.com/your-data-quality-checks-are-worth-less-than-you-think-c8bd181a1327
Attention à distinguer l’exactitude des données versus la validation des données. Il s’agit de deux choses différentes. Comment s’assurer que la donnée est exact, à partir de quoi (NB à noter un sujet clé pour les référentiels) ? Et un rappel la qualité des données c’est comme les bugs en logiciel (règle des defects connue en génie logiciel), les problème de qualité non détecté sont proportionnels aux problèmes détectés. Pour éclairer cela, à adopter, l’échantillon du vendredi pour se faire une idée des défauts de qualité non détectés. Un article avec pas mal de ressources de référence sur la qualité des données et écrit par un expert – Dr. John Talburt is Professor of Information Science and Acxiom Chair of Information Quality at the University of Arkansas at Little Rock
Source : https://tdan.com/data-speaks-for-itself-data-validation-data-accuracy-imposter-or-assistant/32237.
Un beau travail de DAMA France et de l’ISACA-AFAI sur la qualité des données publié en novembre. A lire, c’est téléchargeable ici : https://dama-france.org/ . Avec des témoignages, des études de cas et des bonnes pratiques décrits dans deux cahiers : cahier n°1 – « Approches tactiques et stratégiques sur la qualité des données » et cahier n°2 – points de repère clés pour mesurer la qualité des données. ».
10) Pour être complet, pas de gouvernance des données sans métadonnées.
Définir sa stratégie des métadonnées est indispensables (une bonne capacité de pédagogie est nécessaire, tant le terme métadonnée peut faire peur … technique).
Il faut tenir compte de différents types de métadonnées : métadonnées techniques, les métadonnées comportementales et les métadonnées métiers.
Elles peuvent être passives ou actives (de préférence).
C’est un défi si ce n’est pas pris à un stade précoce de construction du S.I.
Toujours rechercher le décalage vers la gauche (« shifting left »), capter les métadonnées à la source.
C’est un sujet permanent à faire avancer pas par pas.
Source : https://blog.datahubproject.io/metadata-in-action-tips-and-tricks-from-the-field-bc85fd1604d7
11) Et le retour d’expérience : « Afflelou déploie une gouvernance data pour y voir plus clair ». Source : https://www.cio-online.com/actualites/lire-afflelou-deploie-une-gouvernance-data-pour-y-voir-plus-clair-16005.html
Data architecture : bonnes et mauvaises pratiques
Extraits et commentaires :
1) Aussi incroyable que cela paraisse, il faut rappeler que les deux mondes de l’ingénierie logicielle et l’ingénierie des données doivent se rapprocher. NB : l’ingénierie logicielle devrait être la base de l’ingénierie des données, avec des spécificités :
- Des métriques adaptées en complément des métriques DORA (https://dora.dev/guides/dora-metrics-four-keys/ ), par exemple la surveillance de taux de panne des pipelines (en particulier sur des périodes critiques), « Software engineers can spend anywhere from 25% to 70% of their time writing tests — it is a broad brush statement, but most data engineers do not do this who are serving BI use-cases. ».
- Un process de développement qui doit tenir compte de la différence entre un produit logiciel et un produit de données. Pour ce dernier, les prévisions de charges de qualification, curation des données, d’itérations de modèles (data science – démarche scientifique) sont différentes de celles d’un codage classique (l’incertitude n’est pas de même nature et est plus prégnante avec les données). La capacité à montrer des résultats intermédiaire est différente. Ce qui perturbe les démarches agiles. Source : https://substack.com/home/post/p-150467085
Sujet déjà abordé en octobre : https://www.datassence.fr/2024/11/19/revue-data-du-mois-octobre-2024/#_ftn6
2) L’ingénierie des données à un problème d’architecture en misant tout sur le traitement de pipelines de données au coup par coup qui s’empilent au fur et à mesure des besoins pour finir entrelacés, interdépendants, forkés en N versions pour répondre à des besoins quasi similaires, avec des correctifs « à l’arrache »… (le plat de spaghetti bien connu inmaintenable). Pourquoi les principes de modularité, de réutilisabilité, de hub data (exemple hub and spoke data), de ½ interface, de traçabilité (log, monitoring), de patterns de conception (sans oublier de tracer les choix), de versionning, de tests automatisé, une bonne documentation (incroyable de rappeler cela)…, sans oublier les spécificités data (vues SQL, formes normales, indexations), n’y sont pas appliqués ?
3) On a fait faire (et cela continue) au data scientists tout et n’importe quoi, de l’ingénierie logicielle / de développement qu’ils ne maîtrisent pas, de l’architecture de systèmes logiciels / de S.I. qu’ils ne maîtrisent pas, de la gouvernance des données appliquée qu’ils ne maîtrisent pas et de la modélisation sémantique unifiée qu’ils pourraient maîtriser… il faut les remettre à leur place dans la data science et les intégrer dans un écosystèmes de data architectes, data ingénieurs, de data modélisateurs / analystes … le tout aidé par des approches de types data products, data contracts (NB : une part des échecs des projets big data est d’avoir laissé les clés du camion aux data scientists).
4) L’architecture pour l’architecture, ou autrement dit l’architecture pour se faire plaisir technologiquement, pour son CV (voir sur ce sujet le bon article : https://www.urbanisation-si.com/les-architectures-catholiques-du-si ). En faisant cela on arrive à de magnifiques cathédrales technologiques … en oubliant que les données restent le sujet principal. On prend les 12 technologies à la mode, on les assemblent et cela roule. Rappel l’intégration logicielle va être votre pire cauchemar. Quand mettre en place un pipeline de donnée demande de jongler avec trop de technologies différentes alors il y a un problème. L’architecture ne doit pas être un fardeau (et pire un stress, pour avoir vu une équipe ayant composé sa propre data platform se relayer à partir de 7h du matin tous les jours afin de s’assurer que leur architecture fonctionne bien pour produire les tableaux de bord attendus avant le début de la journée). Rappel : chaque couche technologique que vous ajoutez pour faire fonctionner vos pipelines est un point de défaillance potentiel. NB : une part des échecs des projets big data, a été le trop de charges qui s’accumule progressivement au cours du temps à faire fonctionner la plate-forme au détriment des nouveaux projets. Avec l’impression d’être enfermé dans la complexité de la plate-forme (dans un audit posez des questions pour évaluer sa stabilité). Exemple rencontré : un projet big data avec le choix de développer son propre orchestrateur et de la maintenir alors qu’un bon cron aurait suffi.
5) La règles des 80 /20 (Pareto) est toujours un bon guide. Toute une liste de 80/20 data dans cet article : « 20 % des pipelines de données traiteraient 80 % de votre volume de données ou de vos processus métier critiques, concentrez-vous sur l’optimisation de ces 20 %… 80 % des problèmes de qualité de données sont causés par 20 % des données…Concevez des modèles de données autour des 20 % d’entités et de relations qui génèrent 80 % de la valeur business… ». Source : https://medium.com/@jagadeshjamjalanarayanan/80-20-rule-for-data-engineers-b6484a9b36c7 ).
6) L’architecture copiée de retours d’expérience et de concepts de grandes entreprises technologiques, où la data est au cœur de leur business … et non adaptée à votre contexte (historique S.I., business model, cas d’utilisation). NB : c’est une part également des échecs des projets big data, en copiant des infrastructures non adaptées à son contexte alors qu’une simple base de données bien paramétrée aurait suffi (pourquoi faire simple quand on peut faire compliqué !). Et je rajouterais, se méfier des POC, se méfier de la fin d’année avec les fameuses tendances pour l’année suivantes qu’il ne faut pas louper (source : https://medium.com/towards-data-engineering/data-engineering-2-0-trends-that-are-shaping-the-industrys-future-8d9415ddaa1d ) et se méfier de l’IA qui va monopoliser les besoins en données selon sa propre vision (ingestion, base vectorielle…) et balayer le reste .. à nouveau (bis repetita du phénomène big data).
7) La modélisation des données pilotée par le pipeline en cours de développement … c’est tellement facile avec les outils actuels et dangereux. Chacun (pipeline) ses tables de données, c’est plus simple, plus rapide, moins contraignant. Pourquoi s’embêter avec une modélisation d’ensemble voire même conceptuelle. Mais bon courage ensuite pour la maintenance, la lisibilité des données, l’application de la gouvernance, la transmission à une autre équipe (attention à la dépendance de concepteurs clés)… en plein dans le sujet de la dette technologique. Et pour en rajouter, entre travailler sur le premier projet LLM et réduire cette dette, devinez qui a gagné !
La modélisation des données est morte tuée par le poids des outils, le comment (One Big Table, JSON, Tabulaire, Data vault, modèle Dbt…) où le quoi a disparu. L’agile qui ne laisse pas le temps à la modélisation (pour l’action, le code à tout prix). Et avec comme conséquence : « le bordel ». Un cri du cœur, revenez à la modélisation conceptuelle et logique à la place d’attaquer directement le physique. Source : https://medium.com/@edmund.tongly/data-modeling-is-dead-b7889639f14a … mais ce n’est pas gagné : https://medium.com/@dilukshashamal2001/data-modeling-296029d74d7c
Et la compétence en modélisation régresse « data modeling should be central to a data practitioner’s skill set. The number of practitioners I meet who truly understand data modeling from first principles is shockingly low. » et quand il y a une lueur d’espoir, la modélisation dont on parle est en réalité technique (voir § précédent). Les principes de normalisation des données (Codd – modèle relationnel) ont disparu … au profit de la dénormalisation non justifiée. Remarque personnelle : la prolifération de technologies data va-t-elle tuer les fondations des données ? Et ne vont-elles pas se tuer elles-mêmes sans fondation … au profil de la nouvelle technologie qui arrive déjà pour les remplacer ? Un bel article – source https://joereis.substack.com/p/one-of-the-biggest-challenges-in .
8) « The Future of Data Is Composable, Portable, Programmable » (modularité, portabilité, « programmabilité » as a code) une bon résumé d’une bonne cible par Stéphane Heckel. Source : https://medium.com/@stephane.heckel/the-future-of-data-is-composable-portable-programmable-9d7088f8d3a9
9) Les besoins des IA en données non structurées nécessite de nouvelles architectures différentes des architectures pour les données structurées : indexation, volume, gestion de la qualité, formats, stockage, pré-traitements spécifiques, métadonnées – contextualisation différente … en attendant une standardisation des besoins des moteurs d’IA. Source : https://diginomica.com/new-world-unstructured-data-and-ai-how-build-unstructured-data-pipeline-gen-ai .
10) Un ouvrage utile « Deciphering Data Architectures (Serra 2024) » – revue ici : https://medium.com/@andreashrlund/deciphering-data-architectures-serra-2024-my-main-takeaways-and-review-b016609e35dc .
Sources :
https://medium.com/everestengineering/learning-socio-technical-data-architecture-ab2b61bfb84d
https://seattledataguy.substack.com/p/7-lessons-i-learned-the-hard-way
Et sur ce thème de la data architecture quelques articles dédiés à des styles d’architecture.
Data lakehouse la combinaison des bénéfices des data lake et des data warehouse sans les inconvénients ?). Source : https://medium.com/@vipin.kataria2209/why-i-think-data-lakehouse-is-the-future-my-journey-through-data-architectures-da113fd3c90c .
Le data mesh (NB qui n’est pas qu’un sujet d’architecture) : une architecture via Databricks dans le domaine des aéroports multi-domaines métier, où le data mesh semble bien adapté. Source : https://medium.com/dbsql-sme-engineering/lifting-off-with-data-mesh-exploring-data-mesh-with-uc-and-dbsql-for-airport-management-7b5103bb06c4 .
ETL versus pipelines de données …fusion des concepts dans les data platforms. Source : https://blog.det.life/data-pipeline-vs-etl-understanding-the-key-differences-f71bde598387 .
L’écosystème particulier de l’initiative EU des data spaces https://internationaldataspaces.org/ – avec en novembre la publication d’un position paper « Data Spaces Business Models ». « It is important to distinguish between business models for the data space infrastructure (which would be based on cooperation, or at least coopetition) and business models for the participants, which act mostly on individualistic and competitive behaviours ». NB : à rajouter au onboarding de ce concept, déjà pas simple – Source : https://internationaldataspaces.org/wp-content/uploads/dlm_uploads/IDSA-Position-Paper-Data-Spaces-Business-Models.pdf
L’idée de clean data rooms pour le partage sécurisé de données se diffuse, se décline – exemple des data rooms virtuelles. Source : https://www.lebigdata.fr/data-rooms-virtuelles-lavenir-securise-des-fichiers-professionnels .
L’idée de zero-ETL à prendre avec précaution. Source : https://medium.com/@simon.thelin90/zero-etl-revolutionary-or-a-recipe-for-trouble-6405f817a235.
Et pour finir un pot-pourri de réflexions data à prendre ou à laisser dont sur les architectures et leurs composants… quelques extraits : chargement incrémentiel versus par lot (le célèbre j’annule et remplace), a-t-on vraiment besoin du temps réel, j’aime bien mais comment résister « Mastery of foundational skills should take priority over adopting new technologies… », surveiller l’alignement entre les besoins business (un portefeuille data) avec les capacités de la pile technologique data (data platform) … sur/sous dimensionnement … une sandbox est toujours utile, maîtriser les coûts « “The Future of Cost Savings is in Spending.” Investing in data roles will unlock significant improvements in revenue-to-cost ratios by reducing hidden costs like rework, manual fixes, and inefficient processes. », les produits de données sont une bonne piste, mais à ne pas se précipiter sans une large réflexion (métier, qualité, technologique, gouvernance…). Source :
Data platforms
L’actualité a été riche sur ce mois de novembre, avec énormément d’annonces, de rachats, de nouvelles fonctionnalités, d’événement dont toujours la bataille Snowflake – Databricks.
Impossible de tout détailler. Quelques éléments clés quand même en attendant la version 2025 des guides data platforms (https://www.datassence.fr/2024/04/23/dynamique-et-panorama-des-data-platforms/ ).
Cloudera reste dans la course avec le rachat d’Octopais : https://insideainews.com/2024/11/14/cloudera-to-acquire-octopais-platform-to-deliver-trusted-data-across-the-entire-hybrid-cloud-data-estate/ et https://www.bigdatawire.com/2024/11/18/cloudera-enhances-data-catalog-and-metadata-management-with-octopai-acquisition/
Purview toujours plus riche en fonctionnalités dont orientées métier : https://medium.com/@yashigoyal1927/microsoft-purview-931bb9e67946 et https://medium.com/@yashigoyal1927/microsoft-purview-data-map-b7a2b012ae60
Et plus largement chez Microsoft : https://www.lemondeinformatique.fr/actualites/lire-la-plateforme-d-analyse-de-donnees-fabric-de-microsoft-s-etoffe-95321.html
https://www.lebigdata.fr/microsoft-lance-drasi-lavenir-du-traitement-des-donnees
A noter un nouvel outil DRASI : reprise des architectures orientées événements pour l’usage des données de façon à ingérer les données par changement – et de conserver les traces des changements sous forme d’événements (à voir comment cela va se positionner avec le reste de l’offre Microsoft).
Une longue liste d’annonces Snowflake : https://blog.augustorosa.com/the-unofficial-snowflake-monthly-release-notes-october-2024-6a4aee8e4625, et le rachat de Datavolo https://techcrunch.com/2024/11/20/snowflake-snaps-up-data-management-company-datavolo/ et dans le domaine des agents IA https://insideainews.com/2024/11/16/snowflake-unveils-snowflake-intelligence-the-future-of-data-agents-for-enterprise-ai/ – https://siliconangle.com/2024/11/20/snowflakes-shares-surge-higher-blowout-earnings-promising-acquisition-new-ai-partnership/ et partenariat avec Microsoft sur l’accès aux données de la suite Dynamics – https://siliconangle.com/2024/11/19/snowflake-broaden-interoperability-microsoft-dataverse-dynamics/
Et la réponse côté Databricks : https://medium.com/@NextGenLakehouse/databricks-data-engineering-governance-and-warehousing-announcements-october-2024-055f0e159ab3 et https://www.bigdatawire.com/2024/11/27/databricks-to-raise-5b-at-55b-valuation-report/ – https://medium.com/@matt_weingarten/databricks-q4-roadmap-w2w4-4fa9e26c2d9c
https://medium.com/@24chynoweth/databricks-and-the-shift-left-architecture-4c6b697039e8
Avec forcément des comparaisons Snowflake – Databricks : https://factspan.medium.com/databricks-vs-snowflake-2024-098c25cdf459
Et des annonces d’autres éditeurs :
Alteryx https://siliconangle.com/2024/11/12/alteryx-simplifies-analytics-hybrid-data-infrastructures/
Avec la nécessité de montée en puissance sur les données non structurées : https://www.bigdatawire.com/2024/11/25/anomalo-expands-data-quality-platform-for-enhanced-unstructured-data-monitoring/
Et pour finir l’idée de data platform sous le terme de data platform gravity – https://medium.com/@mustafaisonline/data-platform-gravity-fd639ca6e656
L’idée de data product gagne du terrain
Quelques idées :
1) Les trois types de data product : fondamentaux, intégrés, analytiques
Idée de mesures de leur efficacité et de leur santé – fiabilité (voir un article du mois de mars avec à nouveau l’utilisation d’un arbre de mesures – https://moderndata101.substack.com/p/model-first-data-products ).
Source : https://medium.com/@community_md101/so-i-have-a-data-product-now-what-3638de29027a
2) Toutes les organisations ne sont pas forcément matures pour une logique data product / data product management (dans la logique d’un chef de produit classique).
Le danger des data products, c’est leur duplication (risques)
Source : https://medium.com/@yuliia.tkachova/data-products-and-all-the-fluff-around-it-fdfe71f85635
3) L’introduction d’une dimension couts dans les métadonnées qui accompagnent un data product. Après, “Data Quality as Code” et “SLA as Code”, idée de “Pricing Plans as Code”.
4) Par l’auteur Andrea Gioia de l’ouvrage « Managing Data As A Product »
Un produit de données est une application logicielle pilotée par des données et développée selon les principes de gestion de produits.
« For an application to be considered a data product, it needs two key traits: it must be a product and offer functionalities directly driven by the data it manages. ».
Les produits de données rationalisent (concentrent) le travail d’intégration (la difficulté n°1), pour faciliter leur disponibilité et leur prise en charge par plusieurs cas d’utilisation.
(porte ouverte) Pour être considérée comme un produit, une application de données a besoin d’utilisateurs qui reconnaissent sa valeur et qui peuvent être prêts à payer pour l’utiliser.
Source : https://medium.com/@andrea_gioia/what-i-talk-about-when-i-talk-about-data-product-19faa223f91b et l’ouvrage https://www.packtpub.com/en-au/product/managing-data-as-a-product-9781835469378 – et les illustrations sous Github https://github.com/PacktPublishing/Managing-Data-as-a-Product/tree/main
BI / Analytique
Consulter la météo de votre cadre d’activité
Leçon 1 : Les données sont là pour fournir des options, élargir votre horizon et jamais pour « vous aider à prendre une décision ».
Leçon 2 : La vitesse de prise de décision est importante « Too much information means lost time, so Amazon aims to make most decisions with 70% of the data you wish you had. ».
Se concentrer sur la bonne collecte des bonnes données (soyez espion. vous n’êtes pas une machine, vous ne voulez pas être guidé par les données, vous voulez juste plus d’idées.
Source : https://svenbalnojan.medium.com/how-to-escape-data-flatland-a8b11eff8bd8
Et toujours, tout commence par la meilleure définition des demandes / besoins. Trop de demandes sont vagues, floues qui font perdre du temps aux data analystes, data scientists (Exemple : « Quels sont les facteurs de désabonnement ? »). L’arbre des hypothèse est une forme pour challenger / investiguer les demandes / besoins. Source : https://towardsdatascience.com/how-to-answer-business-questions-with-data-26f6f067de71
Data et IA
Les IA reflètent les positions idéologiques de leurs créateurs : origine culturelle et linguistique des données (dont le reflet des politiques d’accès aux données), choix d’annotations, choix de sélection et curation des données, choix liés au renforcement par retour humain (Reinforcement Learning from Human Feedback, RLHF). Source : https://danslesalgorithmes.net/stream/impartiale-lia/ et https://arxiv.org/pdf/2410.18417
Pas de sens des données sans contexte. A distinguer le contexte de formation des données et le contexte de représentation des données (renforcement du sens). Un exemple ici avec les données de proximité géographiques comme contexte des transactions immobilières. Source : https://www.datanami.com/2024/11/19/without-data-context-there-is-no-ai.
En vrac (Open Data, Vast Date – OSData, Data physicalisation, Souveraineté data, Data colonisation, Démocraties et data, Data et santé, Sport et données qualitatives)
1) Open data – l’actualité du mois https://opendatafrance.fr/lactualite-opendata-du-mois-23/
2) Vast data – l’OS data https://tdan.com/a-step-ahead-iot-communication-how-vast-data-is-moved/32202 et aussi d’octobre – https://siliconangle.com/2024/10/01/insightengine-vast-data-aims-operating-system-ai/
3) Data physicalisation – où comment rendre physique les données https://dataculturegroup.org/2024/11/19/clay-data-sculptures.html
4) Souveraineté data
5) Data colonisation : Amérique latine, décoloniser la datafication, trop marquée par des données « occidentales » – non locales. https://journals.sagepub.com/doi/full/10.1177/20539517241270694
6) Démocraties et data – https://www.project-syndicate.org/commentary/leveraging-data-to-protect-democracy-by-claire-melamed-2024-11
7) Suite data et santé (voir revue datassence https://www.datassence.fr/2024/11/19/revue-data-du-mois-octobre-2024/#_ftn4 ).
https://journals.sagepub.com/doi/full/10.1177/20539517241296056
8) Sports et données qualitatives
Quand les données quantitatives ne suffisent plus, comment prendre en compte les données qualitatives, mesures du ressenti, des émotions des sportifs et mesures du collectif.
Pour les abonnés : https://www.lequipe.fr/Tous-sports/Article/Team-sports-l-innovant-projet-sur-la-preparation-mentale-lance-par-les-federations-de-sports-collectifs-francais/1521590
Un hommage souvenirs (madeleine de Proust) et clin d’œil pour finir à Thomas E. Kurtz cocréateur du Basic.
https://next.ink/brief_article/thomas-e-kurtz-co-createur-du-basic-est-mort-a-96-ans
RDV maintenant en janvier 2025 pour la revue et les actualités de décembre.
Les commentaires sont fermés.