Comme d’habitude une suite de sujets data en lien avec un ensemble d’articles data du mois de septembre.
A noter la publication d’un guide de référence sur les données et jeux de données. A lire, conserver dans un coin et à ressortir dès que l’on parle données (sous l’égide de Kate Crawford) : « A critical field guide for working with machine learning datasets » – https://arxiv.org/pdf/2501.15491
Les sujets récurrents sur le data mesh et les data products, la data analysis, les métadonnées, la gouvernance des données (dont un REX de déploiement d’un catalogue de données chez Doctolib), la modélisation des données, data et IA, les données personnelles et la souveraineté des données.
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
Sommaire :
- Data mesh et data products : implémentations Databricks et Snowflake
- Data analysis : se frotter aux imperfections, apport limité des agents IA, causes d’échec
- Data et IA : un guide de référence sur les fondamentaux data / datasets, comment assurer la confidentialité des données, Github de datasets
- Données personnelles : Palantir, La banque de mes données
- Modélisation des données : les données sont politiques, le modèle en étoile reste un excellent pont entre la modélisation et la lecture métier
- La gouvernance des données à la source
- REX Doctolib sur le déploiement d’un nouveau catalogue de données
- Métadonnées : rôle, implémentation dans le code, system design by metadata
- Souveraineté des données
- En vrac (Datacommons Google et MCP, Hallucinations, ARTE – travailleurs de la donnée, intégration des données des systèmes historiques, ouvrage sur l’interopérabilité des données)
Data mesh et data products : implémentations Databricks et Snowflake
1) Comment déployer le Data Mesh et les Data Products à grande échelle dans une organisation réelle avec Databricks ?
Chaque Domaine métier de données possède son propre espace de travail Databricks (sources, pipelines, datasets, agents…).
Un hub central assure la cohésion de l’ensemble (via les politiques).
Avec le maillage sous la responsabilité du hub qui gère les liens entre produits de données (publication par les domaines, dépendances, partage). NB : le hub peut être vu comme un domaine particulier avec ses propres produits (transverses, multi-domaines).
Le partage peut être centralisé via le hub, ou géré localement au niveau de chaque domaine.
L’architecture Medallion (Bronze → Argent → Or) est le moteur de création de produits de données au sein de chaque domaine.
Les data contracts sont définis et supports de la fonction de partage. Le partage peut être privé ou public.
Une extension IA des data products peut être gérée (déploiement d’agents IA à partir d’un data products) – idée de AI Data Product – interrogation en langage naturel des données, aide à l’analyse, à la data visualisation.
Chaque domaine crée ses propres AI Data Products.
Des « super » agents peuvent orchestrer, superviser d’autres agents.
Moyens Databricks mobilisés : Databricks marketplace, Unity catalog, Delta sharing, Genie (AI agent) et Genie Mesh orchestration multi-agents.
2) Pourquoi les marécages de données (data lake) peuvent être sauvés par les data contracts
La base : tout data lake devrait être gouverné à la source via des data contracts (gestion des métadonnées – contextualisation, prévention des changements – preventing breaking changes, gestion des versions, Shifting responsibility “left” to producers, defining clear data ownership and SLAs (logique maillage de données), embedding data quality checks and business logic (points d’application des règles métiers), shaping organizational alignment (support du dialogue – feedback producteur – consommateur)
Un exemple d’implémentation dans Snowflake.
Data analysis : se frotter aux imperfections, apport limité des agents IA, causes d’échec
1) Préparer les data analysts / data scientists aux imperfections du monde des données
Ce qu’ils n’apprennent pas à l’école : incohérences, interfaces rompues, données absentes, codages erronés, nomenclatures non stables, identifiants faux ou dupliqués… ce qui est la norme et pas l’exception.
L’idée appel à un moteur de génération de données synthétiques qui reproduits des incohérences, comme datasets d’exercice.
Le portefeuille data : outil pivot – les 5 erreurs à ne pas faire
Le portefeuille d’initiatives data est central dans toute démarche de gouvernance.
L’article décrit les 5 erreurs à ne pas faire (vision data scientists).
- 2 Se méfier des cas où les données sont prêtes et propres. Ce n’est pas la réalité.
- 3 Traiter les projets comme des concours Kaggle. En entreprise des solutions simples moins performantes sont meilleures.
- 4 Afficher uniquement le résultat. Le processus de production est aussi important.
- 5 Terminer par un modèle et ne pas pousser jusqu’à l’action.
La première erreur citée est hors scope pour moi (Créer des projets qui ne vous intéressent pas).
Source : https://www.kdnuggets.com/5-portfolio-mistakes-that-keep-data-scientists-from-getting-hired
2) Retour d’expérience agents AI et data analysis
Text to SQL ne suffit pas.
Il y a besoin d’instruire un contexte (sémantique), de savoir décomposer la problématique en briques de requêtage à enchainer, de vérifier des hypothèses, de tester…
Source : https://www.pedronasc.com/articles/lessons-building-ai-data-analyst
3) Pourquoi tant de projets de données échouent-ils ?
Eternel sujet !
En quoi ces indicateurs, ce tableau de bord va influencer mes décisions demain ? … Personne n’avait de réponse claire.
Les erreurs citées par l’auteur :
- Evaluer l’adoption par des mesures de déploiement (tableau de bord livré) et non pas en impacts mesurables pour l’entreprise,
- Un ensemble de KPI, un tableau de bord n’est pas un projet à mener mais un produit à faire vivre et évoluer dans le contexte de l’entreprise
- S’occuper de la gouvernance plus tard (problème de dette, de conformité, d’absence de réel propriétaire des données ou alors de multi-propriété ce qui est la même chose … qui érode la confiance)
Source : https://medium.com/@ruifariapereira/why-do-so-many-data-projects-fail-433dfd8bdff0
Data et IA : un guide de référence sur les fondamentaux data / datasets, comment assurer la confidentialité des données, Github de datasets
1) A critical field guide for working with machine learning datasets
Une référence !
Une formalisation et production sur la connaissance des données à lire, à conserver et à ressortir dès que l’on parle données.
Un effort de synthèse remarquable sur ce que sont les données et les datasets.
NB : pertinent bien au-delà de l’usage pour l’IA.
« Written by Sarah Ciston. Editors: Mike Ananny and Kate Crawford. Part of the Knowing Machines research project – https://knowingmachines.org/ ).
Et en lien un second article sur comment décrire un datasets – les questions à poser à propos d’un datasets (template de recueil de métadonnées) : Datasheets for Datasets
Et la couverture du cycle de vie d’un dataset : motivation, composition, collection process, preprocessing/cleaning/labeling, uses, distribution, maintenance.
Auteurs : TIMNIT GEBRU, Black in AI
JAMIE MORGENSTERN, University of Washington
BRIANA VECCHIONE, Cornell University
JENNIFER WORTMAN VAUGHAN, Microsoft Research
HANNA WALLACH, Microsoft Research
HAL DAUMÉ III, Microsoft Research; University of Maryland
KATE CRAWFORD, Microsoft Research
Sources : https://arxiv.org/pdf/2501.15491 et https://arxiv.org/pdf/1803.09010
2) Comment assurer la confidentialité de ses données
L’IA n’existe pas sans données et de qualité.
Comment alors lui partager des données sensibles sans danger dès son apprentissage ?
Le point d’équilibre difficile à trouver entre on partage tout (risque complet) et on ne partage rien (pas de service).
Il existe des solutions techniques de partage (privacy enhancing technologies – PET) – voir https://www.datassence.fr/2025/09/23/revue-data-du-mois-juillet-et-aout-2025/#_ftn25 .
Google propose un modèle expérimental en jouant sur la capacité d’obfuscation des données sensibles tout en préservant la qualité du moteur d’IA : « Differential privacy involves injecting a small amount of noise, or random data, during the AI training process. ».
3) Référentiel de datasets pour LLM : quand les données pour l’IA s’attaquent à représenter des domaines de plus en plus étendus.
« Github Repository for Top LLM Datasets ».
Avec des jeux de données adaptés aux différents types de LLM : exemples pairs question / réponse, production de code, raisonnement mathématique, suivi d’instructions, conversations (schémas de communication humaine), respect des valeurs humaines, reconnaissance de connaissances à partir de données pédagogiques, alignement sur les préférences utilisateurs,
Constats de lecture de l’article :
- Les jeux de données s’attaquent à des domaines qualitatifs comme les valeurs humaines et cognitifs comme la représentation de schémas de comportements humain,
- Les jeux de données visent à représenter des techniques de raisonnement de plus en plus complexes
Le rythme des progrès de l’IA s’accélère et cela repose sur la portée de plus en plus large des datasets dans la représentation des pensées (cognition), comportements (actions), schéma de langage – conversation (communication) humains.
Source : https://www.analyticsvidhya.com/blog/2025/09/github-repository-for-top-llm-datasets/
Données personnelles : Palantir, La banque de mes données
1) Palantir : la cartographie de la population comme priorité
Le pouvoir de relier une multitude de fragments de données pour établir un réseau unifié de nœuds de profils.
Avec : la capacité de fournir à un enquêteur un dossier intégrant tout ce qu’il est possible de récolter en données pour un profil donné … les historiques de voyage, les dossiers de visas, les données biométriques, les données des réseaux sociaux…
Et l’utilisation par le gouvernement Américain dans le cadre de sa politique. Avec le sujet du transfert de contrôle (définition des données, de la façon de les lier et de les traiter : filtres – algorithmes…) et la dépendance à un prestataire privé (Palantir)… le profilage de masse et sa capacité à contrôler notre vie / survie.
La structure de gouvernance évolue en intégrant un acteur privé qui influence les décisions.
« Le partenariat entre Palantir et le gouvernement fédéral soulève des questions fondamentales quant à la responsabilité dans un État axé sur les données. Qui décide de l’utilisation de ces outils ? Qui peut contester une décision prise par un logiciel, surtout si ce logiciel est propriétaire ? »
Ce que résout Palantir et dont il sera difficile de s’en séparer … Le chaos des données (multitude, cloisonnement, accès lent) en une vue unifiée
Le deuxième article présentent plusieurs cas d’utilisation (Fujitsu, Andretti Global – RaceOS, coopérative de Subway, hôpitaux, American Airlines…).
La couche Palantir comme couche d’OS intermédiaire pour les traitements (Data centrisme vers DataOS).
Source : https://www.techdirt.com/2025/09/11/how-palantir-is-mapping-everyones-data-for-the-government/ et
https://medium.com/@sainathde/every-industry-faces-the-same-data-problems-my-take-on-palantirs-approach-at-aipcon-8-8209377a702a
2) A quand MA banque de mes données ?
Un échange entre la PDG (Irène Ng) de Dataswyft (https://dataswyft.com/ ) sur la propriété de ses données et le contrôle qu’on peut en avoir face aux entreprises qui tirent des revenus de nos données.
Les données sont un actif, ont de la valeur.
Actuellement le dissymétrie est quasi-totale entre ceux qui portent les données (nous producteurs) et ceux qui les consomment (réseaux sociaux, IA, e-commerce, moteurs de recherche, fournisseur de services…). Nos données comportementales sont un trésor que ces entreprises consommatrices savent transformer en revenus.
Si les données ont une telle valeur, pourquoi il n’existe pas une sorte de banque de ses données pour mieux en maîtriser leur contrôle ?
C’est en quelque sorte ce que propose Dataswyft ou encore l’idée de Solid POD d’Inrupt Tim Berners Lee https://www.inrupt.com/ .
Avec en prime, l’accent mis sur la portabilité et l’interopérabilité des données afin de se défaire de la dépendance aux consommateurs (changer de fournisseurs de services).
Le problème : « Si vous allez voir quelqu’un et lui dites : « Tiens, tu aimerais posséder tes données ? », il vous répondra : « Oui, c’est plutôt sympa. » Mais en trois secondes, généralement, si vous lui offrez quelque chose en échange, il les donne. »
Ce n’est pas une faute. Peu de personnes en réalité savent ce qu’elles donnent, mesurent la valeur qui est transmise.
L’idée est de confier ses données à un service (mon compte et portefeuille de données – wallet) qui va vous permettre d’en contrôler la conservation, la représentation et les usages. En quelque sorte les confier à une sorte de banque qui vous permettra de les gérer (attention les données ne sont pas actif comme les autres : obsolescence, non rivalité, valeur par l’usage…).
NB : la dissymétrie n’est pas que dans la relation 1-1 (producteur – consommateur) mais aussi dans la masse – relation 1-N (voir l’idée de data gravity). Quel pouvoir de ses solutions (Dataswyft) face à cela ?
A lire l’entretien
Source : https://diginomica.com/ai-age-hype-why-we-must-seize-back-control-our-data-says-dataswyft-ceo
Modélisation des données : les données sont politiques, le modèle en étoile reste un excellent pont entre la modélisation et la lecture métier
1) Les données sont politiques
La modélisation de données est le lieu de négociations : entités représentées, définitions (qu’est-ce qu’un client entre un commercial et agent d’intervention), niveau d’abstraction, évolutivité, transparence des sources…
Les données sont manipulées sous la pression d’influences politiques (intérêts, règles non écrites…).
Source : https://practicaldatamodeling.substack.com/p/data-is-political
Et dans la suite la préconisation : avant de modéliser, cartographier le terrain politique -> identifier et animer un réseau de parties prenantes internes et externes.
Les modélisateurs de données ne travaillent pas en vase clos.
Les parties prenantes internes : pour les cas d’usage en lien avec le fonctionnement de l’organisation.
Les parties prenantes externes : pour les cas d’usage en lien avec les partenaires (clients, fournisseurs, régulateurs…) affectés par l’activité de l’organisation.
Le modèle de données n’est pas le même si la finalité est une traçabilité réglementaires versus un accompagnement client.
« Par exemple, des réglementations comme le RGPD stipulent clairement que vous devez supprimer les données d’un utilisateur sur demande. Comment procéder ? Il est incroyable de constater le nombre de modèles de données qui ne permettent pas une suppression simple et en cascade des données, imposant une suppression manuelle. »
Pour chaque partie prenante, identifier son pouvoir (influence) par rapport à la modélisation (vécu : un facteur important dans la démarche délicate de validation d’un modèle de données).
Source : https://practicaldatamodeling.substack.com/p/stakeholders-dynamics-in-data-modeling
2) Le modèle en étoile (Kimball – faits – dimensions) reste un excellent pont entre la modélisation et une lecture métier. Il demande à être accompagné pour les architectures de données modernes (gestion de l’historisation, automatisation des évolutions par des métadonnées actives). Source : https://medium.com/towards-data-engineering/from-kimball-to-metadata-how-dimensional-thinking-still-shapes-modern-data-architecture-8e04a6f976b3
La gouvernance des données à la source
Ou l’idée de « shift left » repris du DevOps (déplacer les tests et l’assurance qualité plus tôt dans le cycle de développement … précepte de base du génie logiciel).
Pour les données : « Au lieu de politiques, d’audits et d’approbations a posteriori, la gouvernance est intégrée directement aux flux de travail, aux pipelines et à la conception des produits. ».
Avec un problème bien connu : quand seuls des spécialistes de la source savent réellement exploiter les données. Et l’erreur de vouloir imposer un contrôle descendant.
Les exemples Airbnb et Uber sont cités en exemple (attention deux entreprises data).
Avec des messages clés : « recentrer la gouvernance sur les compétences des employés » … » Les règles étaient trop diverses, évoluaient trop vite, et les équipes locales ne pouvaient pas attendre des semaines pour obtenir des approbations. »… « Les ingénieurs et les analystes ont appris les règles en amont, et non après coup. ».
Avec le portefeuille de produits de données comme unité de convergence entre stratégie métier, gouvernance de données et delivry.
REX Doctolib sur le déploiement d’un nouveau catalogue de données
La difficulté de trouver les bonnes données est un problème récurrent (de recherche, d’exploitation, de management ,de gouvernance des données). Avec les frustrations, le temps perdu à retrouver des données et leur contexte.
Le catalogue existant n’était plus adapté : trop technique (réservé aux techniciens), traçabilité (lineage) incomplète, affichage en lien avec l’utilisation des données (provenance des données dans un tableau de bord par exemple) impossible, évaluation des politiques de données limitée. Avec au résultat, une faible utilisation pour un coût élevé.
Le choix d’une nouvelle solution : POC, UX – cas d’utilisation – personae (intégration dans la quotidien), fonctionnalités (exemples taxonomie des données, lineage, assistant d’interrogation – IA, gestion des droits). A noter la partie intégration progressivement évoquée (automatisation de la récupération des métadonnées). On parle d’une connexion quotidienne au stack data (seul système data ?). On parle d’un processus précédent extrêmement fastidieux et chronophage pour des ingénieurs hautement qualifiés qui devaient modifier manuellement des centaines de pages du catalogue de données. Et un renversement avec par exemple la taxonomie en bout de chaîne dans le catalogue rebasculée à la source directement dans le code. Evoqué également le partenariat fort avec les responsables de data products.
Commentaires : un effort remarquable sur la partie adoption du futur catalogue et valorisation de ses fonctions (démarche UX, communication, conduite du changement, lobby), mais un socle d’infrastructure d’intégration des métadonnées peu mis en avant – dans les deux sens entre systèmes data et le catalogue (hormis la classification à la source) ?!
Et six mois après – https://medium.com/doctolib/changing-our-data-catalog-28-weeks-later-of-product-mode-6-6-61f81d9c15aa process continu (feedback, évolution du catalogue) et passerelle avec la plate-forme d’agents IA et la question d’ajouter une couche sémantique.
Source : voir la série d’articles à partir de https://medium.com/doctolib/changing-our-data-catalog-why-healthtech-company-doctolib-decided-it-was-time-for-an-overhaul-20e452b5991a
Métadonnées : rôle, implémentation dans le code, system design by metadata
1) Le cas inconnu – connu (matrice kown-unknown) : un risque, une problématique inconnue, qui se cachent dans des données d’entreprise mais qu’on ne sait pas clairement identifier (silos, documents oubliés, archives…).
Avec les métadonnées pour lever le problème de l’identification de ces données et de leur contextualisation. Source : https://blog.masterdata.co.za/2025/09/19/taming-the-unknown-known-how-metadata-management-uncovers-your-organizations-hidden-risks/
2) Un guide étape par étape pour implémenter les métadonnées en tant que code en production – qualité des données, détection de changement de schémas, construction de lineage, classification – étiquetage des données, protection des données (accès – droits), gestion des interfaces (via les contrats de données), règles de conformité (réglementaire), automatisation des tests, alimentation du catalogage, observabilité – auditabilité … automatisation de la gouvernance. source :
https://medium.com/@arrufus/metadata-as-code-why-your-data-platform-needs-it-now-part-3-fee7d7fc1c8c
NB :cet exemple illustre que la mise en place d’une telle implémentation a un cout important, d’autant plus élevé que l’on part d’un système historique non prévu pour cela (données comme sous-produit).
3) Pousser les métadonnées au centre de la conception des systèmes : pas uniquement comme éléments de description à produire par les systèmes (des étiquettes), mais aussi comme pilotes de fonctionnement de ces systèmes (contrôles, choix, ordonnancement de processus, interopérabilité, gestion des variations).
Un article sur « La déconnexion entre gouvernance et sémantique : un problème systémique ».
Et l’exemple des systèmes de métadonnées des bibliothèques, où gouvernance et sémantique sont indissociable. Les métadonnées pilotent le catalogage, la qualité attendue et surtout la modélisation des données (normalisation, interopérabilité).
L’article met en lumière l’importance de l’architecture sémantique (vocabulaire, concepts, relations) représentée par les métadonnées dans le conception des systèmes.
NB : nième rappel l’intégration est le problème n°1 des S.I. Une conception des modèles de données par métadonnées doit permettre de réduire « l’exercice interminable (d’intégration) de mise en correspondance entre des visions du monde incompatibles lorsque les organisations ne disposent pas de modèles de données partagés… ET cela ne signifie pas qu’un seul modèle de données régisse tous les autres. »
Source : https://jessicatalisman.substack.com/p/metadata-as-a-data-model-b68
Souveraineté des données
Le règlement FiDA – « Nous sommes pour l’exclusion des Big Tech qui n’hébergent pas leurs données en Europe ». Source : https://www.journaldunet.com/fintech/1544589-fanny-rodriguez-afepame/
La souveraineté des données est devenue un sujet brûlant . Les facteurs déclenchants : la sensibilité des données (perte, fuite, contrôle de données), la dépendance à des acteurs technologiques extérieurs et dominants dans le traitement et le stockage de données, dont le risque commercial (verrouillage de services), le risque géopolitique. Avec les tensions que cela crée entre construire et disposer immédiatement de ressources. Source : https://diginomica.com/data-sovereignty-emerges-universal-business-risk-just-billions-flow-us-clouds
Le data act est entré en vigueur le 12 septembre.
« Les données générées par un produit ou un service connecté devront désormais être accessibles à l’utilisateur et transmissibles au tiers de son choix. »
Le droit comme arme pour les données en Europe.
Et quand l’idée de propriétaire des données n’est pas le plus important :
Extrait : « ‘Prenons l’exemple d’une voiture ‘intelligente’’, explique Claude Rapoport. ‘Il s’agit fondamentalement d’un produit en réseau qui envoie des données au constructeur automobile. Mais si vous êtes un bon conducteur, vous pourriez vouloir transmettre certaines de ces données à votre assureur pour le prouver et obtenir ainsi une police moins chère. À qui appartiennent ces données ? Aux yeux du règlement sur les données, cela n’a aucune importance. La seule question qui compte est de savoir qui détient les données. Dans ce cas-ci, il s’agit du constructeur automobile, qui aura l’obligation de les transmettre ces données à votre assureur si vous le lui demandez.’
… A suivre dans le temps les changements que cela va apporter (par exemple par rapport aux offreurs cloud).
Sources :
https://www.latribune.fr/idees/tribunes/data-act-quand-l-europe-transforme-la-donnee-en-arme-de-souverainete-1032333.html et https://datanews.levif.be/analyse/arriere-plan/reglement-sur-les-donnees-quel-impact/
Comment faciliter le partage des données, la réponse de l’initiative européenne International Data Spaces (IDS) et son offre de cadre pour un partage de données fiable entre les secteurs et les frontières.
Avec l’interopérabilité au centre.
A suivre les efforts de normalisation lancés par l’Europe : CEN/CENELEC JTC 25, ETSI TC Data et le lien avec la norme ISO/CEI 20151, ou encore les spécifications techniques comme le protocole Dataspace (IDS).
Source : https://internationaldataspaces.org/how-the-eu-data-act-will-shape-data-spaces/
En vrac (Datacommons Google et MCP, Hallucinations, ARTE – travailleurs de la donnée, intégration des données des systèmes historiques, ouvrage sur l’interopérabilité des données)
1) Google ouvre son réservoir de données Data commons aux agents IA via MCP
Data commons : https://datacommons.org/
2) C’est dit les hallucinations des moteurs d’IA (générative) sont intrinsèques.
On devrait leur permettre d’exprimer leur niveau d’incertitude. Mais cela va à l’encontre des attentes des utilisateurs qui veulent des réponses.
NB : un moteur d’IA générative est conçu pour halluciner avec un % de résultats que l’utilisateur prendra pour correct (on a simplement «énormément amélioré la capacité du chimpanzé à produire une œuvre de Shakespeare).
Sources : https://arxiv.org/pdf/2509.04664 et https://singularityhub.com/2025/09/18/why-openais-solution-to-ai-hallucinations-would-kill-chatgpt-tomorrow/
3) Les travailleurs de la donnée – un reportage à regarder sur Arte
D’où viennent les données qui alimentent les moteurs d’IA ?
La façon de faire n’est pas récente, mais est toujours d’actualité … et encore plus.
4) Quand une start up française s’attaque à l’intégration des données des systèmes / BD historiques
Non pas en extrayant les données, mais en reproduisant les événements en temps réel sur les données captés par les logs des systèmes / BD historiques (AS400, DB2, Oracle, SAP. NB : logique de change data capture (CDC).
Outil de « libération » des données historiques et de migration.
5) Parution d’un ouvrage de synthèse sur l’interopérabilité des données.
Data Interoperability: Unified Architecture Connecting All of Your Data – 4 septembre 2025
de Dave Wells (Auteur)
Source : https://tdan.com/the-book-look-data-interoperability/32989
RDV maintenant en novembre pour la revue et les actualités d’octobre.
Les commentaires sont fermés.