Dernière modification le 3 avril 2025
Comme d’habitude une suite de sujets data en lien avec un ensemble d’articles data du mois de mars.
Avec des sujets de fond sur l’ingénierie data, les métadonnées, la modélisation, le shift left data, la gouvernance des données (dont le sujet de la centralisation).
Sinon dans ce mois de mars le sujet récurrent data et IA.
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
En test le mind map généré via NotebookLM :
Sommaire :
- Considérations sur l’ingénierie data
- Data et IA – Agent IA data scientist / data analyst
- Quand le processus décisionnel peut mal tourner
- Le mythe du ROI de l’équipe data
- Sans métadonnées (métier et technique), pas d’intelligibilité des données
- Des catalogues de données aux jumeaux numériques
- Modélisation des données : incontournable sinon le chaos
- Données personnelles les difficiles équilibres
- Sept leçons sur la création de data products
- Le manifeste Shift Left Data
- Les limites de la centralisation des données
- Données de santé : actualité sur le European Health Data Space
- En vrac (Les données synthétiques : le cas du consommateur synthétique, SQL n’échappe pas aux bases du génie logiciel, Devenir data détective, Equipe de France de Rugby – Quand la data valide l’impact de la stratégie des entraineurs, La data au service du développement d’Etats d’Amérique du Sud, Evocation de la conférence « Data for Black Lives », Translytical database, Data quality management pratique, Quelles données surveiller dans un monde fluctuant, Security Data Engineering)
Considérations sur l’ingénierie data
Les données doivent être contrôlées (qualité, politiques, règles de gouvernance, normes, règles de gestion, droits…). Les contrôles doivent être au centre de l’architecture de données et non « à côté ». Associés aux contrôles doivent être pris en compte : l’exécution de traitements post-contrôle , la gestion des exceptions, les traitements des rejets. Le tout sous surveillance (observabilité). L’auteur propose un cadre d’architecture dans ce sens. Source : https://medium.com/@sutherl99/data-controls-the-backbone-of-data-architecture-part-1-b8251c8fedb9
Pourquoi faire compliqué quand il faut faire simple
Un article intéressant, qui va à l’encontre des architectures data complexes dont on se demande bien pourquoi elles sont construites (voir le sujet des data platforms cathédrale IT et les CV architectures).
NB : vécu personnel sur une plate-forme Big Data, des temps de débogage lourd, des problèmes d’intégration qui tournent en rond, de la redondance fonctionnelle entre outils, de l’instabilité permanente, données illisibles pour les métiers, alors qu’une simple base relationnelle (mode CRUD) suffisait. Source : https://www.edudata.blog/does-your-datas-structure-match-the-question-you-want-to-answer/?
Et un second article excellent à lire absolument surtout si vous vous lancez dans la construction d’une centrale data (data platform et équipe data) et qui reprend tous les affres que peuvent vivre les équipes data avec les conséquences sur les métiers – « The Current Data Stack is Too Complex: 70% Data Leaders & Practitioners Agree » – surabondance, surcharge d’outils, complexité des architectures, problématique d’intégration occultée, pas de rationalisation / vue d’ensemble – des silos techniques au cas par cas. « the Modern Data Stack soon became a double-edged sword. It led to a maze of integration pipelines, only a few star engineers who spent years in the organization understand — implying both a technical as well as cultural centralization of key data assets and solutions. ». Et encore « Switching between tools adds another layer of inefficiency, with users frequently losing context as they jump from one interface to another. This constant toggling not only slows down work but also increases the likelihood of errors. » – « Integration challenges further compound the problem. Teams spend hours troubleshooting integration bugs and patching up connections between tools that were never designed to work seamlessly together. ». « More often than not, to make their lives easier, business users often prefer to simply duplicate the data instead of spending hours or weeks waiting for the integration bridge to get fixed or renewed. ».
L’article cite également tout une liste de couts cachés… très intéressant.
A voir l’initiative citée dans l’article : https://datadeveloperplatform.org/
Data et IA – Agent IA data scientist / data analyst
Agent IA data : ingénierie et data management (catalogage).
L’idée de confier des tâches d’ingénierie et de data management à un agent IA. Attention pas de miracle, les problématiques d’intégration restent à traiter. NB : traduit la logique d’agent comme couche d’automatisation faisant appel à des blocs fonctionnels « classiques » en termes d’architecture. Source : https://ai.gopubby.com/agentic-ai-for-data-engineering-4412d5e70189
Les agents IA prolifèrent.
Ils promettent de vous assister comme data scientist ou data analyst. A voir trois exemples ce mois-ci.
Google – source – https://www.bigdatawire.com/2025/03/06/google-launches-data-science-agent-for-colab/ et « Data Science Agent in Colab: The future of data analysis with Gemini » – Source Google – https://developers.googleblog.com/en/data-science-agent-in-colab-with-gemini/?
Microsoft : https://dataconomy.com/2025/03/26/microsoft-copilot-just-became-your-data-mollycoddler/
Et une nième startup – LlamaIndex – https://www.llamaindex.ai/ (fondée en 2023) – source – https://techcrunch.com/2025/03/04/llamaindex-launches-a-cloud-service-for-building-unstructed-data-agents/
Avec les humains dans la boucle « Humans as Tools? The Surprising Evolution of HITL in Agentic Workflows – how human-AI co-agency is shaping the future of intelligent systems » : https://www.turingpost.com/p/humanaico
Et une conséquence « Thoreau wrote this phrase “men have become the tools of their tools,” in 1845-1847, talking about 19th-century technologies like the railroad, telegraph, and farming equipment. »
Ce qui fait bouger les choses en termes de données et d’IA par le Gartner – https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-identifies-top-trends-in-data-and-analytics-for-2025
La liste du Gartner :
- « Highly Consumable Data Products
- Metadata Management Solutions
- Multimodal Data Fabric
- Synthetic Data
- Agentic Analytics
- AI Agents
- Small Language Models
- Composite AI
- Decision Intelligence Platforms »
Source : https://www.bigdatawire.com/2025/03/05/gartner-giveth-guidance-on-data-analytics-and-we-taketh/
Et aussi un résumé et point de vue complet ici : https://sanjmo.medium.com/data-and-ai-pulse-check-gartner-2025-d-a-summit-reflections-65d7e2d4a98f – Extrait « Apparently, trust in data is a key component. Who knew? “Trust your data” is right up there with “breathe air” on my list of helpful advice. All humor aside, the reality is that building and maintaining data trust is a complex and multifaceted challenge. »
IA et data : les solutions de gouvernance des données étendent leurs fonctionnalités
Immuta (spécialiste data gouvernance – data sécurité – https://www.immuta.com/ ) avec l’appui de l’IA générative propose une aide à la définition des politiques de données (d’accès). Source : https://www.bigdatawire.com/2025/03/03/immuta-brings-ai-to-data-governance-launches-copilot/
Alation (data catalogage – https://www.alation.com/ ) propose l’automatisation de fonctions de data management à l’aide de l’IA (premier processus concerné : la qualité des données). Le tout accompagné par la possibilité de créer ses propres agents IA (avec la mise en œuvre du protocole MCP – voir le sujet sur les métadonnées). Source : https://www.bigdatawire.com/2025/03/03/alation-aims-to-automate-data-management-drudgery-with-ai/
Inversement, des solution base de données comme Weaviate (base de donnée vectorielle open source https://weaviate.io/ ) ajoutent la possibilité d’y développer des agents IA de data management. Source : https://www.bigdatawire.com/2025/03/07/weaviate-introduces-new-agents-to-simplify-complex-data-workflows/
Data (données structurées) et IA : la déconstruction des tableaux de bord, les entrepôts de données comme sources pivots pour l’IA.
Le besoin évolue – déconstruire les tableaux de bord au profit de pouvoir interroger en langage naturel les données via les moteurs d’IA. Disposer de sources de données fiables. Vaincre les hallucinations. Source : https://www.bigdatawire.com/2025/03/11/data-warehousing-for-the-ai-win/
Comment éviter le piège de l’IA dans les système ERP : l’utilisation excessive ou abusive de l’IA dans les systèmes ERP peut comporter des risques – voir le volet données (migration, classification…).Source : https://datanews.levif.be/actualite/innovation/ia/voici-comment-eviter-le-piege-de-lia-dans-les-systeme-erp/
Et un article intelligent de l’impact de l’IA sur les lois du software (dont l’emploi des données).
Exemple : la loi de Postel, également connue sous le nom de principe de robustesse. Elle stipule traditionnellement : « Soyez conservateur dans ce que vous envoyez et libéral dans ce que vous acceptez.» Pour les données Limiter le caractère aléatoire des données envoyée (être fiable), mais accepter en réception divers types de données (être ouvert). Avec l’IA qui inverse cela.
Voir aussi ce qui est dit pour la loi de Conway.
Source : https://thebootstrappedfounder.com/how-ai-changes-famous-laws-in-software-and-entrepreneurship/
Quand le processus décisionnel peut mal tourner
Soit par la faute des données, soit par une mauvaise interprétation.
Les questions clés : quelles données adaptées à la problématique traitée, d’où elles viennent (contexte), quelles sont leurs limites, peuvent-elles être généralisées (répétées) ?
Attention aux données externes à transposer dans son contexte (effort de transposition impératif – contextualisation + combinaison avec les données internes).
La combinaison de mesures est nécessaire mais est un point complexe à maîtriser (à ce sujet voir les arbres de métriques ou de performance – https://www.datassence.fr/2024/01/18/revue-data-du-mois-decembre-2023/?highlight=arbre%20de%20performance#_ftn5).
Contrôler les résultats demande du temps (choix de l’échantillon, hypothèses, mesures, combinaisons, analyses, vérifications du résultat, élimination des biais, décision potentielle, analyses sous-jacentes, incertitudes à prendre en compte…le tout en itérations / feedbacks).
Préparer la décision est un sport d’équipe (métier, data analyste, data scientist, décideur).
Source : https://hbr.org/podcast/2025/03/the-right-way-to-make-data-driven-decisions
Le mythe du ROI de l’équipe data
« Measuring the impact of most data work is just really, really hard. » … voire impossible ou démesuré !
Une proposition utiliser le : « “Net promoter score” is a simple concept – basically asking customers “how likely are you to recommend this product/service to someone else?” »
Source : https://hex.tech/blog/myth-of-data-team-roi/?ref=blef.fr
Sans métadonnées (métier et technique), pas d’intelligibilité des données
Un système de données est vivant. Il évolue constamment (définition, data shift, nouveaux traitements, nouvelles règles de gestion, maintenance…). Comprendre l’évolution des données dans le temps est aussi important que de comprendre leur état à un instant T. Extrait « When did access policies change and who modified them? How have data contracts evolved over time and between environments? Which semantic definitions have drifted from their original meaning? What composition rules have been added, modified, or deprecated? Without temporal tracking, you’re flying blind through your data architecture’s history, unable to understand how you arrived at your current state or effectively plan for future changes… “What schema changes preceded our recent data quality issues?” ».
Source : https://medium.com/data-mess/data-architecture-power-of-temporal-metadata-in-hasura-ddn-e6c0025334bf
Zoom sur l’idée d’étiquetage des données (à l’image de ce qu’il se fait en supply chain). NB : sur cette idée d’étiquette voir la data platform Orkestra data – https://orkestra-data.com/ où cette idée est native. Extrait : « While data is the shippable product, everything surrounding it — ensuring it reaches the right consumer in the right condition — is metadata. Just as a physical product needs packaging, tracking labels, storage, customs clearance, and optimized transportation routes before it reaches its destination, data relies on metadata to be discoverable, accessible, secure, and compliant. Without metadata, data would be like a package without a label — unidentifiable, misrouted, or stuck in transit. »
De fait à appliquer à tout processus data à risques, à valeur, critique…
Voir aussi page 32 « L’étiquetage des données au coeur des data platforms » du guide Dynamique des data platforms – https://www.datassence.fr/2024/04/23/dynamique-et-panorama-des-data-platforms/ .
Citation de fin de l’article : « Metadata isn’t just documentation — it’s the foundation of the data economy. »
Un article plus technique sur l’intérêt d’avoir des métadonnées bien structurées pour optimiser les accès aux données (requêtage SQL entre autre) et économiser des millions de $ de couts de calculs. Le tout en environnement Iceberg. Extrait : « When faced with a massive 90-petabyte data lake that was getting slower by the day while costing more and more to operate, I discovered that sometimes the most impactful optimizations aren’t about processing data itself but about how we access it. This is the story of how a deep dive into Apache Iceberg’s metadata architecture led to a solution that saved my team within Advertising millions of dollars in compute costs. ».
L’idée de data lake d’observabilité, c’est-à-dire de regroupement des logs, traces, métadonnées pour offrir des fonctions d’observabilité des données.
NB : attention à la diversité des sources de métadonnées, à une majorité d’absence de métadonnées disponibles et à construire un nième système de gouvernance data (qui veut dire des problématique d’intégration). Source : https://thenewstack.io/observability-without-a-data-lake-might-no-longer-work/
Et la formalisation des métadonnées pour l’IA via l’initiative MCP Model Context Protocol d’Anthropic (https://www.anthropic.com/news/model-context-protocol ).
(Rappel sans contexte les données n’ont pas de sens et les évolutions autour des moteurs d’IA l’ont bien compris. NB : ici on est plutôt sur la part contexte technique).
« “Even the most sophisticated models are constrained by their isolation from data – trapped behind information silos and legacy systems.» – Anthropic, on why context integration matters. Un article sur tout ce que vous avez voulu savoir sur MCP. Un développement en logique Open Source. L’idée de créer une toile MCP avec des serveurs standardisés au niveau des sources que les agents IA peuvent interroger. La principale ambition de MCP est de réduire les couts d’intégration des sources de données (éternel problème … que le buzz IA va peut-être réduire ? … initiative de standardisation, ouverte, poids de l’IA … on en est au début et cela va forcément évoluer).
Source : #14: What Is MCP, and Why Is Everyone – Suddenly!– Talking About It? https://huggingface.co/blog/Kseniase/mcp#:~:text=MCP%20is%20all%20about%20the,in%20a%20secure%2C%20structured%20manner et https://towardsdatascience.com/600112-2/ Et aussi https://www.bigdatawire.com/2025/03/31/will-model-context-protocol-mcp-become-the-standard-for-agentic-ai/
Des catalogues de données aux jumeaux numériques
Des catalogues de données aux jumeaux numériques pour le contrôle de conformité des données … et pour la confiance dans les données.
Présentation de l’offre Solidatus https://www.solidatus.com/ qui propose un jumeau numérique comme réplique virtuelle des données et des processus connectés aux systèmes en cours d’exécution. Permettant de cataloguer les données, de les visualiser dans le temps et dans les systèmes, de simuler l’impact de changements (exemple une migration cloud). A voir aussi le positionnement par rapport aux solutions de data observabilité.
Source : https://diginomica.com/how-solidatus-building-digital-twins-data-compliance-meet-regulatory-demand
Modélisation des données : incontournable sinon le chaos
Fondamental, mais négligé voire oublié dans certains cas avec des dégâts gigantesques.
Un savoir-faire incontournable dans le monde des données.
Au début de ma carrière, les modèles de données étaient une évidence. On apprenait également à parler métier autour de ces modèles. Puis il a fallu de plus en plus les imposer. La CV ingénierie – parler NoSQL, base vectorielle, delta lake… les a rendu moins attrayant. Jusqu’à ma grande surprise de les voir disparaître dans certains projets remplacés par la définition de tables au moment du coding … avec les catastrophes associées (explosion des couts, non évolutivité, non maintenabilité, illisibilité, non portabilité, dépendance …).
Que sont devenu les modèles de données des sources … disparus ?
Le premier article revient sur ce phénomène.
Avec l’IA comme sauveur d’une bonne modélisation !
Extrait « Luckily, with the advent of AI and its tendency to expose poorly designed and curated data, data modeling is coming back into vogue. Now, it seems that 50 to 60% of AI articles are either entirely or partially about the need for better data quality from the source systems feeding the hungry AI/ML models. »
Et aussi un constat partagé : « Another factor in the resurgence of data modeling is the growing discontent with NoSQL databases. Document and key-value databases have their place, but many who tried to move their systems to NoSQL discovered, to the chagrin of their budget and decision-making reputation, that they caused far more problems than they solved. ».
Sources : https://datasherpa.blog/p/the-lost-art-and-science-of-data-modeling?
Un article pédagogique sur le modèle conceptuel (la première passerelle entre le métier et l’IT/MOA). Source : https://medium.com/itversity/conceptual-data-modeling-laying-the-foundation-for-business-alignment-53c485d3b120
Et la déclinaison au niveau data ingénierie vers les modèles logiques et physiques. Source : https://blog.det.life/logical-vs-physical-data-models-a-must-know-for-data-engineers-7848e2024d91
Autres sujets liés.
Modélisation data vault, une explication pour mieux comprendre sa structure.
Source : Patrick Cuba
Référence : https://medium.com/the-modern-scientist/data-vault-is-information-mapping-79f186e2b5b5
Le versionning de schémas de données – une problématique pas si simple. Source : https://tdan.com/the-data-centric-revolution-abox-versioning/32514
Détecter les modèles de données qui ne « sentent pas bon » !
N fois vécu, on a tout de suite l’idée de la qualité d’un modèle de données (conceptuel, logique ou physique) dès sa première lecture.
L’auteur développe cette idée :
- Des règles de nommage illisibles pour les métiers voire pour ses collègues,
- La normalisation (au sens formes normales) minimale non respectée (même si la dénormalisation est nécessaire),
- Des données techniques mélangées avec des données métiers
- Du câblage en dur créant des dépendances avec des systèmes sources,
- Usage excessif de JSON, BLOB…
- Et je rajouterai l’absence de structuration par modules logiques, un plat de spaghetti (relations), l’historisation absente
- …
Source : https://practicaldatamodeling.substack.com/p/data-model-smells
Données personnelles les difficiles équilibres
Données personnelles les difficiles équilibres entre : gratuité / publicité / personnalisation / traçabilité / privé-public / protection / … suppression
Les données d’identification sont naturellement clé (identité, mais aussi traits d’identité, adresses techniques – IP-Mac, identifiants publicitaires…) et elles forment un business avec des acteurs majeurs (exemple Publicis), elles se vendent (courtiers) et elles font l’objets de trafics (Initial Access Brokers – IAB).
Les données personnelles ne sont pas à l’abris d’être détruites, vendues unilatéralement (Google qui par erreur supprime les Google Maps Timelines ou 23andme en faillite avec les données ADN de plusieurs millions de personnes dont on ne connait pas le devenir).
Difficile de maîtriser voire s’opposer à cela…
Sources :
- https://www.lemondeinformatique.fr/publi_info/lire-comment-les-courtiers-en-acces-initial-iab-vendent-les-informations-d-identification-de-vos-utilisateurs-1184.html
- https://www.commentcamarche.net/securite/confidentialite/34071-publicis-data
- https://lifehacker.com/tech/how-to-delete-your-23andme-data
- https://www.presse-citron.net/23andme-qui-detient-ladn-de-15-millions-de-personnes-fait-faillite
- https://www.clubic.com/actualite-558447-faillite-d-une-biotech-specialisee-dans-les-tests-adn-qu-adviendra-t-il-des-precieuses-donnees-genetiques.html
- https://www.forbes.com/sites/daveywinder/2025/03/24/google-confirms-user-data-deletion-error-who-is-impacted-what-to-do
- https://www.journaldunet.com/cybersecurite/1539991-proteger-ses-donnees-sans-renoncer-aux-services-numeriques-un-equilibre-possible
Sept leçons sur la création de data products
- Collecter autant de données que possible (la valeur accumulée au fil du temps peut être un différentiateur),
- Créer des boucles de rétroaction sur l’usage des data products,
- Ne pas attendre les données parfaites ni un support parfait (NB : vécu le cas de données de référence où tout a commencé par un simple xls),
- Exploiter les asymétries de données – le data product vient combler l’asymétrie,
- Donner pour recevoir – inciter pour recevoir les données (exemple Glassdoor en échange de fournir des données salariale vous avez accès à la plate-forme),
- Être attentif aux changements de comportement, de contexte (exemple emblématique la période COVID).
NB : l’auteur parle de 7 leçons et en présente 6 ?!
Source : https://svenbalnojan.medium.com/6-essential-lessons-for-building-great-data-products-395ec86ec7f0
Le manifeste Shift Left Data
Une réflexion terrain qu’on ne peut qu’approuver.
La gestion de données marche si on est face à des environnements centralisés
La décentralisation, fédération d’équipes data est incontournable.
Les stratégies data échouent pour mal prendre en compte ces deux points.
L’auteur propose un manifeste … poser la gestion / responsabilité des données à leur racine ou plus proche de leur origine (systèmes et acteurs).
« Simply put: Shifting Left means moving ownership, accountability, quality and governance from reactive downstream teams, to proactive upstream teams. »
L’origine du problème : la loi de Conway qui aboutit à un morcellement des systèmes de données et la loi « Unintended Consequences Systems, or to summarize – « The purpose of a system is what it does » (POSIWID) – coined by Stafford Beer » bien connue au quotidien de la vie des Systèmes d’Information et qui se traduit par le mode crise quasi permanent quand on optimise la rapidité pour régler les dysfonctionnements (systèmes, flux, data qualité…) … la classique absence d’une réunion de fond justifiée pour régler un problème de production data. La solution / réparation court terme plutôt que la solution long terme.
« If Conway’s Law helps explain how data got into such a sorry state, POSIWID explains why – the broader organization optimizes for manual effort over proactive, automated, comprehensive solutions. ».
Et le mode agile mal appliqué n’a fait qu’augmenter le problème en favorisant par équipe des décisions locales de conception (modèle de données, format de stockage, convention de nommage, conception des pipelines, accostage spécifique à des sources de données…) mettant à mal une cohérence d’ensemble des données.
« Without centralized oversight, engineering teams optimized for their immediate needs rather than long-term data quality. ».
« This led to massive data silos and duplicated effort. »
La réponse classique : le socle / lac de données.
« Instead of trying to force governance onto hundreds of independent teams, companies adopted a « dump now, analyze later » approach, instructing engineering teams to send all their raw data into a centralized cold storage repository. This led to the rise of data engineering, a discipline that emerged to turn the messy unstructured data into something usable. »
Avec les limites connues de la centralisation face à l’explosion des données (limites : obésité, perte de sens, perte de responsabilité, goulet…).
Une ingénierie des données centralisée est insoutenable.
Face à ces constats, la solution fédérée « shifting left » est la solution (NB : il y a beaucoup à dire sur cela en particulier sur le rôle difficile voire l’absence des urbanistes / architectes S.I. / architectes data face à ces problématiques … normalement gardiens du long terme, de la cohérence d’ensemble).
« the next era of data engineering must be deeply integrated into the software development lifecycle. Federation ate the world. But now we must decide how to rebuild it—this time, with accountability and resilience at its core. »
« The concept of Shifting Left emerged as a mechanism of driving ownership across a decoupled engineering organization and ultimately became the go-to solution for developers. »
« A Shift Left approach to data requires embedding data management best practices at the source, not just patching issues downstream. »
« A core idea behind shifting Data Left is simple but often overlooked: data is code. Or more accurately—data is produced by code. It’s not just some downstream artifact that lives in tables and gets piped into dashboards and spreadsheets. Every record, event, or log starts somewhere—created, updated, or deleted by a line of code. »
Avec l’idée de Dataops à l’image du DevOps et du DevSecOps (je dirais même fusionné si c’est possible).
Bref revenir aux fondamentaux du génie logiciel y compris pour les données.
Et l’auteur propose de mettre cela en place en commençant pas les contrats de données en parallèle de règle de codage (data in the code – par exemple l’implémentation de règles de gestion extraites des politiques versus a posteriori, sur un stock, manuellement). Source : https://dataproducts.substack.com/p/the-shift-left-data-manifesto
Voir le point suivant sur le sujet de la centralisation des données
Les limites de la centralisation des données
Après le Big Data, sa déclinaison data lake, l’IA pousse à la mise en place d’une gestion centralisée des données (copier toutes les données à un même endroit).
Le discours data « soyez data », soyez data centric, les REX d’acteurs (digital native) qui montrent l’atout de leur stack data poussent aussi à cela.
Mais cette centralisation a des limites.
Les ignorer c’est s’exposer à des frustrations, des échecs (dont on parle moins).
L’article « Why Centralized AI Fails in Enterprise: The Case for a Federated Architecture » paru ce mois-ci a le mérite de s’attarder sur ce sujet.
Je ne peux aller que dans son sens. Et même compléter cette vision.
J’ai vécu plusieurs mission d’audit d’équipes et systèmes de données centralisés. Avec à chaque fois la même conclusion … il faut « alléger » le dispositif (voir sur Datassence le sujet maintes fois abordé – par exemple ici https://www.datassence.fr/2024/07/11/notes-linkedin-live-cathedrales-data-it-vs-chapelles-data-metiers/?highlight=ob%C3%A9sit%C3%A9 et ici https://www.datassence.fr/2023/10/02/je-naime-pas-la-data-a-cote/?highlight=ob%C3%A9sit%C3%A9).
Les limites sont intrinsèques aux fondamentaux des données. Avec le premier : sans contexte les données n’ont pas de sens (par contexte on entend à la fois la définition des données, leur cycle de vie, leur lineage – statique et dynamique, leur environnement de production et d’utilisation, l’univers de connaissance mobilisé…). Avec toute la difficulté de définir la portée de ce contexte (voir l’exemple emblématique du COVID qui a remis en cause un bon nombre d’interprétations d’indicateurs dans les entreprises).
En centralisant les données se pose la question du devenir et de représentation de ce contexte ?
L’IA a un mérite dans le monde des données, ses réponses sont sans commune mesure meilleures lorsqu’on associe un contexte aux données mobilisées (voir les développements autour des moteurs d’IA – rôle des métadonnées, vision graphe, le retour du knowledge management – exemple https://bloomfire.com/, la partie sidecar des data products, l’initiative MCP citée dans cette revue…).
Dans les efforts de centralisation des données, cette dimension est négligée.
Cela va marcher lorsqu’il y a une communauté d’intérêt autour des données centralisées (un métier, un processus), lorsque le résultat est aligné avec des besoins d’entreprise (exemple des indicateurs d’entreprise sur lesquels on s’est mis d’accord avec les bonnes personnes sachant les interpréter contextuellement), ou encore dans le cadre d’une startup qui a conçu son organisation, son business et son système en exploitant une logique data centric.
Cela ne marche pas lorsque les données sont détachées de leur contexte (voir dans les fondamentaux data le concept de contextualisation / décontextualisation, de détachement / rattachement ou encore XXX bien connu dans l’univers de partage des données).
Lorsqu’on centralise des données on rentre dans cette logique malheureusement oubliée.
Les acteurs centraux se retrouvent alors avec des données dont ils ignorent les subtilités locales et au vu de la diversité des données, de leur volume prendre en compte ces subtilité est rédhibitoire. Les équipes centrales explosent (data swamp, perte de sens, goulet, obésité…). La responsabilité vis-à-vis des données est détruite : pour les acteurs locaux, les acteurs centraux en récupérant les données en prennent la responsabilité et les acteurs centraux ne sont pas en mesure d’assumer la responsabilité.
Pour revenir à l’article, celui-ci met en avant :
- Les données sont forcément réparties, du fait de la conception des systèmes (loi de Conway), des opportunités techniques (multi-cloud), des contraintes de gouvernance…
- Copier les données sources dans un système central est un défi : obsolescence des copies, cout de gouvernance – la compliance s’applique sur les copies, exemple des règles de gestion à appliquer (illustration droit à l’oubli), vulnérabilité (SPOF single point of failure), gestion des accès à dupliquer, contraintes réglementaires de localisation des données..
- L’idée d’architecture fédérée répond mieux à tout cela (arguments de la logique data mesh).
- La délégation de tâches aux agents IA (consommateurs des données) doit se faire au plus près de l’expertise, du contexte des données d’exécution.
Source : https://thenewstack.io/why-centralized-ai-fails-in-enterprise-the-case-for-a-federated-architecture/
Dans cet esprit – voir aussi l’article « Platform-Mesh, Hub and Spoke, and Centralised | 3 Types of data team – Why understanding Team Structure is critical for Data and AI » – https://medium.com/@hugolu87/platform-mesh-hub-and-spoke-and-centralised-3-types-of-data-team-9dd94b37e334
Données de santé : actualité sur le European Health Data Space
« L’espace européen des données de santé (EHDS – European Health Data Space) est un pilier de l’union européenne de la santé et le premier espace de données commun de l’UE consacré à un domaine spécifique dans le cadre de la stratégie européenne pour les données. ».
Avec la publication du Règlement relatif à l’espace européen des données de santé le 05 mars pour une entrée en vigueur le 26 mars – source : https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_fr
La publication d’un FAQ https://health.ec.europa.eu/document/download/4dd47ec2-71dd-49fc-b036-ad7c14f6ed68_en?filename=ehealth_ehds_qa_en.pdf
A suivre le format de données pivot – https://ehr-exchange-format.eu/ (à voir par rapport à HL7).
Voir aussi : « L’accès aux données de santé facilité par le Health Data Hub » – https://acteurspublics.fr/articles/lacces-aux-donnees-de-sante-enfin-facilitee-par-le-health-data-hub/
Et une analyse « The politics of constructing health data spaces: Border work and the stickiness of fragmentation » – Source : https://journals.sagepub.com/doi/full/10.1177/20539517251320012?mi=ehikzz
Sur le sujet des données de santé à voir aussi un livre blanc intéressant du cabinet Doshas consulting – https://doshas-consulting.com/actualites/281-livre-blanc-donnees-de-sante-et-intelligence-artificielle
En vrac (Les données synthétiques : le cas du consommateur synthétique, SQL n’échappe pas aux bases du génie logiciel, Devenir data détective, Equipe de France de Rugby – Quand la data valide l’impact de la stratégie des entraineurs, La data au service du développement d’Etats d’Amérique du Sud, Evocation de la conférence « Data for Black Lives », Translytical database, Data quality management pratique, Quelles données surveiller dans un monde fluctuant, Security Data Engineering)
1) Les données synthétiques : le cas du consommateur synthétique
Un sujet d’équilibre de représentativité entre des données réelles sensibles et ouvertes et des données synthétiques et fermées. Un livre blanc par https://www.pymc-labs.com/ sur le sujet : https://www.pymc-labs.com/blog-posts/synthetic-consumers/?
2) SQL n’échappe pas aux bases du génie logiciel
Les règles du génie logiciel : non accès direct au tables mais passage a minima par des vues voir pousser la logique jusqu’à l’idée de ½ interface, non duplication des règles de filtrage versus copier / coller les requêtes SQL à différents endroits et se retrouver à devoir changer à N endroits une règle … avec les oublis et la conséquence d’écart de résultat de filtrage suivant la version de la commande SQL invoquée + le cout de maintenance, zéro documentation ou obsolète et toujours le cout de maintenance….
« Things change. There’s no getting around change in your data environment. Tables are deprecated, fields are renamed, and code is changed. »
3) Devenir data détective : pour inspirer / attirer les jeunes
« A mission to build young data storytellers ». A suivre l’initiative ici – source : https://www.storytellingwithdata.com/blog/data-detectives-a-new-way-to-inspire-young-learners
Le défi du « self-service data and analytics ».
Une belle idée, mais attention à sa mise en œuvre. Le défi n’est pas technique mais culturel : comment aligner / penser data et business ?
Avec comme préalables : pouvoir se saisir des données (accès, traçabilité, lisibilité, intelligibilité), sous gouvernance, avec une stratégie de métadonnées,
4) Equipe de France de Rugby – Quand la data valide l’impact de la stratégie 7-1 de gestion des remplaçants … « La data est importante, mais l’humain supplante tout », entretien avec William Servat – https://www.rugbyrama.fr/2025/03/24/xv-de-france-entretien-la-data-est-importante-mais-lhumain-supplante-tout-william-servat-se-confie-longuement-apres-la-victoire-dans-le-6-nations-2025-12589389.php
5) La data au service du développement d’Etats d’Amérique du Sud avec l’appui de la banque mondiale (https://www.worldbank.org/en/publication/government-analytics ).
« Guatemala’s Ministry of Education has reduced the dropout rate for students entering lower secondary school by 9% by identifying and supporting those who are most at risk of leaving school. » avec les défis associés (collecte, data platform, data qualité, gouvernance…).
Source : https://www.weforum.org/stories/2025/03/latin-america-caribbean-data-government-transform/ et https://www.worldbank.org/en/region/lac/publication/data-for-better-governance-building-government-analytics-ecosystems-in-latin-america-and-the-caribbean
6) Evocation de la conférence « Data for Black Lives » – https://d4bl.org/ par H. Guillaud.
Et des extraits forts, comme « Comme l’a expliqué Katya Abazajian, fondatrice de la Local Data Futures Initiative, lors d’un panel sur le logement, « toutes les données sont biaisées. Il n’y a pas de données sans biais, il n’y a que des données sans contexte ». ».
« Soulignant les injustices historiques et systémiques qui affectent la représentation des données, la criminologue et professeure de science des données Renee Cummings a rappelé le risque d’utiliser les nouvelles technologies pour moderniser les anciennes typologies raciales. « Les ensembles de données n’oublient pas », a-t-elle insisté. »
Source : https://danslesalgorithmes.net/stream/data-for-black-lives/
7) Translytical database : fusion du transactionnel et de l’analytique pour le « temps réel » analytique, ne pas perdre le contexte actualisé …dont a besoin les systèmes d’IA
Source : https://www.forrester.com/blogs/translytical-databases-are-fueling-modern-ai-apps/
8) Data quality management. Un article tour d’horizon intéressant.
« This article shares the lessons I’ve learned from tackling data quality challenges across different environments, offering concrete strategies for improving data quality at various levels of maturity. The goal is not to provide a rigid, step-by-step blueprint — because no universal fix exists — but rather to inspire you with practical approaches that can be adapted to your organization’s specific context. »
9) Quelles données surveiller dans un monde fluctuant, volatile, incertain en permanence… Trump / Musk / DOGE.
Source : https://hbr.org/2025/03/the-economic-data-you-need-to-make-decisions-through-volatility
« When world events are moving this quickly, it is hard to keep track of what is actually happening, and what it means for the economy and your business. That’s why it is more important than ever to remain flexible, careful, and watch objective data rather than the headlines. »
10) Security Data Engineering, ou la complexité d’un système data dédié à l’observabilité IT
L’observabilité se trouvent confrontée à des volumes de données de plus en plus important, à une croissance continue des sources de données, à une multiplication des natures de données (structurées, semi-structurées, non structurées), à des natures de sources différentes (logs entre autre mais aussi rapports d’utilisateurs), à des formats hétérogènes avec en réponse un marché morcelé.
Le tout rendant difficile l’interprétation de l’ensemble des données.
L’article propose un tour d’horizon du sujet, avec l’idée d’utiliser les LLM pour faciliter cette interprétation : extraire des informations du volume de données, détecter des patterns d’anomalies, générer des synthèse des données de journaux, catégoriser les données, établir des corrélations…
Source : https://www.datagravity.dev/p/security-data-engineering-and-etl
RDV maintenant en mai pour la revue et les actualités d‘avril.
Les commentaires sont fermés.