Ce mois de décembre, des articles éclairants quant à la montée en maturité de la compréhension des données, de leur production à leurs usages.
Avec l’importance du contexte de compréhension et d’utilisation.
Le recherche du graal contextuel, couche sémantique, ontologie… et le passage de métadonnées passives à actives.
Rappel une donnée sans contexte n’a pas de sens.
Des articles REX : data mesh, data analysis – BI, data gouvernance, data architecture.
La bataille de l’accès aux données entre plates-formes privées et le monde de la recherche, le besoin de régulation.
Toujours une liste de pas mal de notes de lectures au fil de l’eau.
A piocher en fonction de vos centres d’intérêt.
Sommaire :
- Valeur BI-Data science / BI zombie / Self data la réalité et l’avenir / Nettoyeurs des données
- REX Data mesh – comment une mauvaise lecture de ses principes a abouti à un désastre
- Observabilité … des changements dans les données
- Le temps des données, exemple du temps statistique
- Data product : gouvernance certification, carte d’identification (étiquette)
- Data architecture (tendances, du traitement par lot au streaming de données, l’avenir des bases de données, un pipeline remplacé par un agent IA : avant / après, le mythe de la vue unifiée, de l’unique source de vérité, des métadonnées dans les connecteurs, redéfinition des moteurs SQL multi sources par l’IA)
- La gouvernance des données ne cesse de se construire (continuité, burn out CDO, du théâtre à l’opérationnel, l’orchestration apprenante, fenêtres data Amazon, à qui appartiennent les données, monétisation des données : l’exemple Uber, la fin des data catalogue passif)
- Couche sémantique, ontologie, knowledge graphe, réseau / modèle d’objets métier, modèles d’architecture d’entreprise, taxonomie, ou plus simplement dictionnaire de données … même chose, même combat – la contextualisation des données, la vérité des données ?
- La bataille d’accès aux données (des capteurs partout, sur tout et en masse, constitution d’un écosystème de traces, les données d’interactions professionnelles comme source d’apprentissage pour l’IA – le cas Linkedin, les vœux du monde de la science et des médias pour accéder aux données des plates-formes)
- Vrac (règles juridiques des données dans l’espace, revue sciences humaines dédiée aux données, data value manifesto, data ethic framework, data et cybersécurité, données non structurées, la guerre des données, décrire le monde)
Valeur BI-Data science / BI zombie / Self data la réalité et l’avenir / Nettoyeurs des données
1) Un classique « We Spent $8M on “Self-Service Analytics.” 92% of Our Dashboards Had Zero Views in 6 Months. Here’s the Dirty Secret of Every BI Program. »
NB : vécu de supprimer des chaînes de production publication de tableau de bord et d’attendre les réactions … et le constat d’une bonne part sans réaction.
Le REX : les tableaux de bord zombie (sans lecteur) parce que conçu pour des utilisateurs imaginaires (non ancrés dans le quotidien, dans les cycles de décisions mais demandés comme on pose une question à un moment donné), avec la confusion entre le besoin d’un tableau de bord et le besoin de données, des tableaux de bord reposant sur des mauvaises définitions non alignées sur les lecteurs (exemple du CA qui n’inclut pas les transactions en cours alors que c’est cela que le dirigeant souhaite voir), des tableaux de bord trop complexes, trop nombreux sur un même sujet (noyade dans les chiffres).
Le self BI n’atteint que 1% des utilisateurs pour le reste c’est toujours le même schéma « Les utilisateurs consultent leurs e-mails, Quelqu’un leur signale un problème, Ils demandent à un analyste d’enquêter, L’analyste envoie une capture d’écran d’Excel ».
L’action : nettoyage des tableaux de bord non utilisés, passer autant de temps à intégrer la communication des données et des tableaux de bord dans le quotidien opérationnel que à les concevoir, penser le besoin non en termes de tableaux de bord à produire mais de résultat pour telle décision.
« Truth #2 : Nobody Wants to Be Their Own Analyst
As research shows, department heads and decision-makers struggle with complex data models and need insights delivered, not tools to find them.
We trained 500 people on “self-service analytics.” Number who successfully self-served : 3. Number who just wanted the answer : 497. »
Et le futur : « The Future of Analytics (Hint : It’s Not Dashboards)
The research is clear : AI-powered analytics will deliver insights before users even ask, with dashboards becoming obsolete for most use cases.
The future :
AI that pushes insights : “Sales are unusual in Boston today”
Natural language questions : “Why are sales down ?” (get an answer, not a dashboard) »
Source : https://medium.com/@aminsiddique95/i-deleted-1-200-dashboards-no-one-noticed-c559ff5d3d85
2) REX : self data vers les agents IA – solution ThoughtSpot https ://www.thoughtspot.com/fr
« How Huel leveraged self-service analytics to upskill its business users — and free its data team from dashboard hell »
Formation d’utilisateurs métier aux données et à leur analyse.
Passage de demande de tableau de bord à demande de données pour se débrouiller par soi-même.
Utilisation d’agents IA assistance à l’interprétation des données.
La mise en place d’une source unique de vérité des données (choix Snowflake et une couche d’unification des données via dbt).
3) REX équipe data : à la recherche des responsables, trop d’outils, la modélisation parent pauvre
L’absence de responsabilité (tableau de bord, KPI, pipelines, référentiel…). Et en l’absence de responsabilité, le mode de travail est réactif et non proactif (gestion des changements, résolution de problèmes…).
Pas de trou dans la raquette :
« every dataset has an owner
every metric has a definition
every transformation has a domain
every pipeline has SLAs
every model has documentation »
Trop d’outils nuit : fragmentation, multi interfaces, charges d’intégration, trop de configurations, charge de maintenabilité = trop de temps passé sur les outils plutôt que les données.
Manque d’investissement sur la modélisation des données en pensant qu’il suffit d’intégrer les données tel que et de les préparer ensuite.
Le résultat un chaos (duplications, double sens, contradictions, incohérences, illisibilité) chronophage, à grosse charge d’investigation – de transformation.
Les modèles sont des produits à gérer en tant que tel.
4) We Hired 10 Data Scientists. They Spent 3 Years Cleaning CSVs.
« he $200K Excel Specialist
Meet Sarah. MIT graduate. Published researcher. Kaggle grandmaster.
Her Monday :
9 AM : Remove duplicates from customer data
10 AM : Figure out why dates are in 7 different formats
11 AM : Discover “revenue” means 12 different things
12 PM : Lunch (googling “data science jobs that actually do data science”)
1 PM : Explain why the data is wrong (it’s always wrong)
2 PM : Clean more data
3 PM : Meeting about “AI strategy” (while cleaning data)
4 PM : Realize yesterday’s cleaning was wrong, start over
5 PM : Update resume
Sarah’s salary : $180,000 Sarah’s actual job : VLOOKUP specialist Sarah’s job title : Senior Data Scientist Sarah’s soul : Crushed »
Et pas de chance le nettoyage est sans fin.
Il faut revenir à la source et embaucher des nettoyeurs de données et non pas des data scientists pour faire cela :
« The Sources of Garbage :
Sales enters data while drunk (only explanation for some entries)
Marketing uses creative spelling (“Kalifornia” is not a state)
Finance has their own reality (revenue includes “potential maybe revenue”)
IT doesn’t talk to anyone (built 5 customer databases, none match)
Legacy systems from 1987 (stores phone numbers as scientific notation) »
REX Data mesh – comment une mauvaise lecture de ses principes a abouti à un désastre
Suite de la revue de novembre : https://www.datassence.fr/2025/12/18/revue-data-du-mois-novembre-2025/#_ftn14
1) We Spent 2 Years Building a Data Mesh. It Was a $4M Disaster.
REX d’un bilan désastreux … de mon avis faute d’avoir correctement instancié la logique data mesh et faute de ne pas maîtriser les fondamentaux des données.
Avec la décentralisation totale sans centralisation (a minima un domaine data métier entreprise). L’oubli qu’un domaine data métier peut être aussi un processus transverse (exemple le parcours client).
Le data mesh solution à la confiance des données … mais non, c’est un cadre. La confiance c’est plus que cela.
L’erreur du libre-service (je reconnais j’ai donné … à modérer l’enthousiasme de départ – et les agents IA peuvent aider).
Le problème des compétences data par domaine. Trop lourd pas de mutualisation, sous employés – pas d’économie d’échelle.
Pas de contrôle du maillage. Chacun défini ses data products. Quid du maillage en tant que tel (lien entre data products, cohérence des définitions, possibilités de mapping, nomenclatures partagées…).
Une gouvernance fédérée inefficace. Exemple une réunion pour s’accorder sur un définition du client qui n’aboutit pas. Erreur fatale, il y a n définitions (ventes, marketing, comptabilité, support…) et c’est normal (principe de base de modélisation). Juste savoir comment accorder cela.
Chaque domaine libre de choisir ses outils : le grand n’importe quoi ! Pas d’architecte dans cette entreprises ?!
Des guerres d’irresponsabilité ! … pas de gouvernance.
… quel gâchis !!!
Et pour finir retour à la centralisation … intelligente : une infrastructure centrale mutualisée, les bonnes compétences au bon endroit (pas besoin d’un expert technique data dans les domaines), remettre de la gouvernance (favoriser l’accès plutôt que la propriété des données*).
* L’expression data owner fausse ce qu’on en comprend, la responsabilité d’accès aux données est le plus important versus être responsable / propriétaire de données qui laisse plus penser à être le gardien d’un produit bien poli (qualité de données) dans une sorte d’espace sous contrôle. Le but est de faire circuler les données pas de les posséder, les polir.
2) Le data mesh a échoué – Le mythe de la décentralisation
Problème n°1 : assumer la responsabilité au niveau des domaines métier n’est pas évident. Passer d’une logique d’exploitation des données par bricolage, au fil des besoins (pipelines à l’arrache et vite jeté, extractions ponctuelles puis excel), turn over des acteurs et perte de leurs bricolages data, à une logique de produit de données (avec toute la logique produit : rigueur, industrialisation, SLA, méta documenté…). La charge n’est pas du tout la même (et conflit mental entre le quotidien opérationnel et la livraison d’un produit data).
Problème n°2 : la décentralisation a besoin de discipline (locale et commune)
Il faut simplifier le data mesh.
Il faut toujours une équipe centrale : qui fixe les principes partagés, maintien une infrastructure commune (NB : si on lit bien, le data mesh parle de domaines de données centraux avec cette vocation).
Faire que les domaines ne se préoccupent que de la logique métier des données alignée sur une couche sémantique partagée.
Revoir la gouvernance que personne ne lira : l’automatiser, la mettre sous contrôle central (ne pas avoir une confiance aveugle dans les domaines).
NB pour moi : le data mesh a échoué par une mauvaise lecture de ses principes et par l’ignorance de la réalité des données dans les entreprises (surtout dans les domaines métier).
Source : https://cloudshark.medium.com/data-mesh-architecture-problems-alternatives-1adcb75a0c44
Observabilité … des changements dans les données
1) Quand l’observabilité des données n’est pas uniquement surveiller le fonctionnement des flux, des pipelines, des tableaux de bord, surveiller les données (défauts valeurs aberrantes, répartition…), lever des alertes techniques et métier, … mais aussi surveiller les changements (la fameuse gestion des changements en génie logiciel).
Avec l’exemple d’une requête SQL modifiée par erreur qui a caché une baisse d’activité.
« Turns out, someone changed a WHERE clause three weeks ago. Instead of counting active customers, we were counting customer records. Including test accounts. Including deleted accounts. Including duplicates from that migration we did in 2019. »
Sans que l’infrastructure (couteuse) d’observabilité (MonteCarlo, Datadog, Metaplane, GreatExpectations, Soda, CloudWatch…) n’est vu quelque chose.
Triple leçon :
- Revenir au basique du génie logiciel : gestion des changements.
- On ne surveille pas tout et au même niveau (alignement sur la stratégie, le business model, les cas d’usage).
- L’observabilité est contextuelle / locale par domaine – c’est normal que le lendemain de Noël il y ait une chute de X% des accès ou que le lundi il y ait un surplus de X%, le CA a bondi de 100% conclusion d’un deal avec un de nos clients les plus important. On ne peut pas surveiller ce que l’on ne comprend pas (toujours l’importance du contexte – exemple le contexte commercial, marketing…).
L’observabilité : système de système est complexe, et surcomplexe du fait d’être au-dessus de systèmes déjà complexes (je dirais compliqués ?) et où le contexte joue un rôle clé.
Conclusion : l’observabilité et ses outils vus comme une assurance au cas où … poussée par le buzz éditeur / conseil.
Et en fond toujours le sujet de la confiance dans les données.
Source : https://medium.com/@aminsiddique95/our-500k-data-observability-stack-caught-0-of-our-actual-problems-8fe37303a272
2) Why Most Data Projects Fail After Go-Live—And How to Prevent It
Dans la suite de l’article précédent : l’érosion de la confiance dans les données fournies.
Le symptôme et schéma courant : l’érosion progressive de la confiance quant aux données fournies (erreurs signalées, nécessité de retraitement à la main).
Parce qu’un tableau de bord, un produit de données n’est jamais figé, ne se gère pas comme un projet mais bien comme un produit.
L’environnement des données est continuellement mouvant : sources, règles, logique métier, nouveaux cas particuliers, besoins, conditions d’exécution… tout bouge.
Lorsqu’on pense produits de données, ce n’est pas en mode projet avec le produit en résultat. C’est un mode produit, qui concerne aussi l’organisation autour du produit, sa documentation – cf. rôle des métadonnées (pas comme un mode projet qui après la livraison amène à dissoudre l’environnement de projet même si une TMA est mise en place) et cela tout au long du cycle de vie du produit.
Source : https://medium.com/h7w/why-most-data-projects-fail-after-go-live-and-how-to-prevent-it-53b340439b7d
Le temps des données, exemple du temps statistique
Publication du n°14 du courrier des statistiques (https://www.insee.fr/fr/information/3622502).
Une revue de référence. A prendre le temps pour lire des articles de fond.
Dans ce numéro : un article sur le temps des statistiques … à l’opposé de la pression temps réel qui passe à côté du fond des données, la qualité de leur sens.
Titre : « À propos du temps de production des statistiques publiques ».
Auteurs : Pierre Lamarche, chef de l’unité Innovation et stratégie du système d’information, Pascal Rivière, chef de l’Inspection générale.
L’article présente :
- Les types de processus de recueil des données : enquêtes, récupération de données administratives, récupération de données du secteur privé
- Le processus de production des statistiques
- Les temporalités associées : période de préparation, dates et temps de collectes, dates de références statistiques, période de vérification des données – data editing, dates de publication
- Le travail de préparation : la définition du besoin, son alignement avec des enjeux de sociétés, politiques, les choix de conceptualisation, les négociations à mener sur le dispositif de collecte et les sources de données, dont le travail de détachement / rattachement des données issues de contextes externes (données administratives, données du secteur privé) – avec le rôle clé des métadonnées.
- Le travail de traitement statistique : redressement de données, données manquantes, pondérations, exigences de cohérence
- Le tout pour alimenter le travail central d’interprétation, afin de maîtriser la définition des données, leur environnement de vie, leurs limites, le tout dans l’idée de convergence du sens et tout cela demande du temps, du feedback … incompressibles.
Source : https://www.insee.fr/fr/information/8675585?sommaire=8667496
Et dans le temps à tenir compte aussi de la loi de Twyman
« Tout chiffre qui paraît intéressant ou différent est généralement faux.»
Leçon : prendre le temps de vérifier, revérifier les données.
Source : https://www.storytellingwithdata.com/blog/interesting-data-is-probably-wrong
Data product : gouvernance certification, carte d’identification (étiquette)
1) Des efforts gigantesques sont fait pour définir des data products, leur associer les bonnes métadonnées, établir des liens entre eux, mettre en place la gouvernance – owner, niveau de qualité, traçabilité, documentation).
Mais les managers sollicitent toujours les équipes data pour des extractions ponctuelles alors que les data products sont là !
Pourquoi : “Because he can’t verify it’s current and trustworthy for his decision. And I don’t blame him.”
Et c’est systématique on ne fait pas confiance aux data products. On a besoin de vérifier (manuellement) les données.
Les data products ont besoin d’un cycle de certification (NB : depuis longtemps dans la BI on parle d’indicateurs labélisés).
Les besoins : « …validates quality before every use, monitors anomalies continuously, states associated business rules, self-certifies trustworthiness in real time, clearly tells users: “safe to use now”, “use with caution”, or “don’t use this yet”/ Most data products today are like food without an expiration label. » …« Most data products today are like food without an expiration label. They might be fresh. They might be spoiled. Users only find out after they consume them. » …
Le problème : « But here’s the gap: You optimized for creation, not consumption confidence. »
Voir les exemples classiques cités dans l’article de ce qu’il se passe dans le contexte terrain d’un process data (exemple vécu N fois pour ma part, une filiale qui n’a pas remis ses données à temps, pas avec le bon filtre, pas au bon niveau de granularité, sans le dernier deal arrivé après la fourniture des données). Avec les questions associées : de quand date ces données – dernière actualisation / synchronisation, quels traitements ont-elles subit, quels risques de dérives (definition drift)…
Et on en arrive au besoin de formaliser le contexte d’utilisation en plus du contexte de production.
NB : sujet connu dans le monde de l’open data avec l’idée de détachement (des données de leur environnement de création) / rattachement (des données dans un nouvel environnement).
« “Is this data good enough right now for this type of decision?”
Example:
82% completeness → fine for exploration
82% completeness → not acceptable for executive reporting
Same data product. Different usage context. Different certification outcome. »
NB : sujet aussi bien connu, la qualité des données est toujours contextuelle et dépend de l’usage.
L’importance de la confiance et du rôle du contexte associé aux données : « Because trust isn’t a metric. Trust is a decision. And decisions need context. »
Contexte = métadonnées structurelle, dynamique (exécution), de changement et le passage de métadonnées passives au métadonnées actives.
2) Carte d’identification d’un data product
Le sujet commence à se formaliser un peu partout au travers : de spécifications ouvertes (ODPS – https://opendataproducts.org/ – https://github.com/agile-lab-dev/Data-Product-Specification ), de l’idée d’étiquette (Orkestra data de l’éditeur Krialys), voir aussi dans la revue du mois de novembre – https://www.datassence.fr/2025/12/18/revue-data-du-mois-novembre-2025/#_ftn9. Ou quand il y a besoin d’une structuration des métadonnées (associées aux données et entres elles).
Le tout poussé par les besoins des agents IA.
L’article décrit :
- Le besoin de construire une couche sémantique à base de cartes d’identification des data products
- La formalisation d’un descripteur (technique et métier) de data products
- Une dynamique d’exposition et de consommation de ce descripteur (pour découvrir, évaluer et utiliser les data products de façon autonome)
- La fiche d’identification du data product est un sous ensemble du descripteur
Figure 1. The Data Product Descriptor contains both the ID Card and the Context Pyramid.
Source l’autrice : Irene Donato
Avec une logique de divulgation progressive du contexte en partant du haut de la pyramide au fur et à mesure du besoin de l’agent, pour la découverte (recherche de données – vue business domain), pour l’évaluation (choix de la meilleure façon de répondre à une requête à laquelle doit répondre l’agent), préparation de la requête (passage du contexte métier au code – jointures, calcul d’indicateur…), levée des ambiguïtés (passage du résultat à un tamis de contexte plus approfondis de compréhension du processus métier – Exemple : les transferts de stock internes sont marqués par customer_id = 0 et doivent être exclus du calcul du chiffre d’affaires, positionnement dans le contexte plus large d’entreprise (place et finalité officielle des données, liens ontologiques – éléments de gouvernance – exemple sensibilité, durée de conservation des données).
Le tout ouvert via des services MCP permettant d’établir un dialogue entres les data products et les agents IA via l’idée de protocole Agent-to-Data-Product (A2DP).
Et toujours le défi organisationnel avec l’importance des propriétaires des données responsables de la publication des données et des métadonnées correspondantes, y compris la fiche d’identification.
Discuter avec les données ce n’est pas une simple requêtes SQL, mais bien la compréhension de tout le contexte lié à leur environnement de vie … et les agents IA doivent arriver à cela.
Un dernier point, l’autrice est consciente de l’effort considérable pour construire et maintenir une telle couche contextuelle et propose l’idée d’agents spécifiques en charge de la création de cette couche dans un cercle vertueux.
Source : https://medium.com/agile-lab-engineering/data-product-id-card-is-all-you-need-8d8e197bde78
Data architecture (tendances, du traitement par lot au streaming de données, l’avenir des bases de données, un pipeline remplacé par un agent IA : avant / après, le mythe de la vue unifiée, de l’unique source de vérité, des métadonnées dans les connecteurs, redéfinition des moteurs SQL multi sources par l’IA)
1) Tendances
La donnée immédiatement disponible est maintenant la base des architectures : pour l’IA, pour les analystes, pour les tableaux de bord, pour les traitements temps réel (fraude, recommandation). Le traitement par lots n’est plus opérant. Passage en flux continu – streaming des données. Kappa s’impose, capable de traiter en même temps des lots et du streaming pour les mêmes données.
Apache Iceberg le vainqueur : indépendance vis-à-vis du moteur de traitement (versus delta lake open source mais conçu pour Databricks), fonctionnement par métadonnées (évolution des schémas, versionning dans le temps, partitionning, catalogage).
L’IA a besoin de fonctions avancées sur les données sur de gros volumes (indexation).
Comment gérer de façon cohérente : l’historique (stockage en base relationnelle, ou mode DW/DM), un data lake et du stockage dédié à l’IA.
L’observabilité de bout en bout est incontournable.
Les contrats de données sont également incontournables (et va de pair avec l’observabilité).
On évite de déplacer les données avec l’idée de zéro ETL : consulter les données sur place.
Les métadonnées sont actives.
NB : et à rajouter la nécessité de maîtriser une couche de contexte aux données.
2) Du traitement par lot au streaming de données
Pourquoi c’est un faux débat ?
Parce que c’est un débat de technicien.
Il faut revenir aux besoins de l’entreprise (on enfonce une porte ouverte).
La frontière s’est estompée : le traitement par lot intègre des événements, le traitement temps réel passe par des phases de retraitement batch.
Le vrai problème n’est pas la vitesse, mais la confiance dans les données, de garantir une exactitude continue (NB : ou plutôt une transparence continue – l’exactitude n’est qu’une facette des données. On peut parler de reproductibilité, de traçabilité aussi), tout au long du cycle de vie des données (intégration, réconciliation, calculs, historisation, usages avec les événements qui font avancer le cycle de vie).
Plus que la vitesse, il faut savoir répondre à la question : quel événement a modifié l’état des données ? NB : rappel un processus, se reflète au travers de la succession des activités amenant au changement d’état de données.
Les événements sont une référence.
Le tout sous pression de l’IA qui révèle les limites des systèmes actuels par lot ou temps réel. L’IA a besoin d’une approche hybride qui embarque un contexte.
Le travail d’architecte data doit évoluer :
« Today, strong data engineers :
Design stateful data models
Think in timelines, not runs
Anticipate late data
Build systems that heal themselves
Explain trade-offs clearly to the business »
…
« Speed without trust is noise
Freshness without context is misleading
Complexity without clarity is unsustainable
And that realization changes how systems are designed. »
NB – L’architecture data doit faire avec : des données partout, différentes, changeantes, qui vivent dans des environnements non stables, le besoin de contextualisation, de transparence, intégrant de nouvelle primitives via l’IA (évaluation, décision, validation) … le tout délivré de façon continue.
Source : https://medium.com/towards-data-engineering/the-end-of-batch-vs-streaming-in-data-engineering-6b528817e632
3) L’avenir des bases de données
Quel cadre conceptuel dans les années à venir.
SGBD, Data Stack et Modern Data Stack, la suite ?
Le constat les couches pour exploiter les données s’empilent : ETL, Data lake, Transformation (ex Dbt), Couche sémantique, Data viz, ETL inversé, où les données sont copiées et recopiées, avec des délai incompressibles de passage à l’analytique.
Prédictions de l’auteur :
a) Le classique (répété tous les ans depuis 30 ans), la fusion du transactionnel et de l’analytique (à suivre Singlestore, DuckDB, Clickhouse, TiDB…) avec pas de recopie, pas de délai entre le transactionnel et l’analytique.
b) Fin des pipelines au profit d’agent IA
Ce que prend en charge l’agent et non le pipeline :
« Discovers the schema automatically
Infers relationships between objects
Suggests transformations based on similar pipelines
Generates quality checks from data patterns
Handles errors autonomously
Evolves as the source changes »
Et boucle de feedback
Avant : Source → ETL → Warehouse → Transform → BI
Après : Source → AI Agent → Query Result
Bilan des points 1 et 2 : réduction salvatrice de la forêt de pipelines : moins de copies des données, moins de chaîne orientées préparation – transformation des données.
c) Rôle clé de la couche sémantique (voir aussi plus loin)
Ce qui est précieux c’est le sens que l’on donne aux données ?
Et cela passe par leur contextualisation – leur place dans un univers sémantique (à suivre Malloy de Google).
La couche sémantique est la source de vérité (à suivre Cube, Transform, dbt metrics
d) L’edge computing décentralise les données (à nouveau)
Avant : Objet connecté – Source → Cloud → Traitement → Stockage → Analyse
Après : Objet connecté – Source -> Analyse locale -> Synchronisation Cloud
Bouleversement de l’approche Cloud first.
L’edge devient la couche de calcul principale
Le cloud devient sauvegarde et coordination
e) SQL survivra toujours
SQL a plus de 50 ans et il a survécu.
NB : et c’est dans ses fondamentaux en termes de structure déclarative d’interrogation des données, de lisibilité.
Et il va intégrer des primitives héritées de l’IA.
f) Trop de décentralisation tue la décentralisation : retour intelligent à la centralisation
Appliquer une lecture intelligente du data mesh : décentraliser la prise en compte des données (au plus près de leur contexte – les domaines métier, sous forme de produits de données inscrit dans une couche contextuelle – sémantique), centraliser l’infrastructure, les principes d’interopérabilité – gestion des ID, des référentiels, normes, une gouvernance automatisable… (mutualisation, cohérence, efficacité, observabilité).
Et encore le traitement par lot vers le temps réel (à suivre Materialize), le besoin d’un orchestrateur d’agents en contexte métier (voir ce qu’on disait il y a 40 ans sur les systèmes multi-agents – J. Ferber).
4) Un pipeline remplacé par un agent IA : avant / après – critiques
I) Avant : un pipeline de données classique, agrégateur de N sources de données, sources avec des défauts (format mouvant, gestion des dates variable, nouvelle catégorie non déclarée, texte libre avec des caractères spéciaux…), qui font planter régulièrement le pipeline malgré une gestion prédéfinie des erreurs non toutes prévisibles (les environnements des N sources sont fluctuants et parfois pas de gestion des changements côté de ces sources). Une chaîne industrielle mais rigide : extraction, transformation, validation, chargement. Un enregistrement en erreur et la chaîne s’arrête. Des centaines de règles de transformation (à chaque nouveau cas un nouvel if).
Bilan : le pipeline ne sait pas s’adapter automatiquement aux fluctuations (plantage et passage par un œil humain puis par une adaptation qui peut être remise en cause le lendemain).
II) Après : développement d’un agent IA, lui confier la qualification des sources et l’adaptation automatique du code à ce qu’il reçoit (format, nouveau champ…). Puis conception d’une architecture à trois agents (un de routage, un de transformation, un de validation). L’agent de routage détermine automatiquement le chemin à suivre (exemple choix de traitements en fonction de ce qui est reçu). L’agent de transformation génère le code de mapping et l’adapte automatiquement. L’agent valideur s’assure que le résultat est correct (règles et tests). Et ajout de gardes fous – alerting d’un humain pour approbation d’une décision de l’agent.
Résultat : quasi suppression des interventions humaines en cas d’erreur, d’évolution des sources (maintenance fortement réduite).
Bilan : les agents sont forts en tactique et la stratégie (l’architecture) reste à l’humain. L’observabilité des agents est primordiale (transparence des transformations, des validations, des décisions). Les agents sont intéressant dans un contexte mouvant moins lorsque les sources sont fiables industrielles.
Points à surveiller : le débogage est (beaucoup) plus complexe (voir article suivant).
Evolution en cours : un agent dédié à la surveillance de la qualité des données
III) Critiques
Le code généré par les agents entraîne un fort risque d’accumulation de dette technique et une charge de deboggage élevée.
Le problème des hallucinations reste persistant (rappel : de base une IA LLM hallucine 100% du temps et dans ces 100% il se trouve qu’un taux +/- élevé correspond à une « bonne » réponse).
La définition de l’architecture d’intégration est hors de portée pour le moment des agents (même avec MCP). De plus souvent il est nécessaire de définir et enchaîner plusieurs étapes pour résoudre un problème et là les agents sont encore trop limités (choix des étapes et risque d’effet domino en cas d’erreur). Et ne pas oublier que les agents doivent s’appuyer sur des systèmes historiques loin d’avoir la qualité d’architecture nécessaires (paramètres limitants, documentation hors système et non à jour – métadonnées, défauts contournés par des verrues, codes erreurs difficile à interpréter automatiquement). Avec le risque de corrompre « en silence » ces systèmes historiques (CRM, ERP, SGBD) avec des données en erreur.
La fragilité des agents face aux cyberattaques (par exemple via des requêtes d’attaque).
Les cas particuliers propres à de nombreux processus sont mal pris en charge (et souvent ces cas sont critiques pour des clients).
D’une façon générale, l’autonome n’est pas possible. L’agent ne comprend pas ses erreurs (rappel de base pas de notion de compréhension pour les LLM – exemple supprimer une données ou une base de données n’a pas de différence), ne peut pas s’adapter aussi automatiquement que l’on veut aux évolutions de contexte métier et technique (rappel : l’instabilité est la règle).
En bref : difficile d’obtenir une architecture robuste, fiable … de confiance.
Le gap entre démonstrateurs et industrialisation est parmi les plus grands à franchir.
Pour le moment les agents à réserver pour les tâches simples. Des »bouts » d’agent en appui des processus. Mais pas la totalité.
La supervision humaine est indispensable.
Et attention au buzz médiatique, avec la pratique d’apposer l’étiquette « agent » sur des chatbots, des scripts RPA et des moteurs de règles.
Sources : https://medium.com/analysts-corner/six-weeks-after-writing-about-ai-agents-im-watching-them-fail-everywhere-fb6636a4568e et https://garymarcus.substack.com/p/ai-agents-have-so-far-mostly-been
5) Le mythe de la vue unifiée, de l’unique source de vérité
REX : Our $5M “Single Source of Truth” Became 17 Sources of Lies
Ce que couvre les 5M$ :
1) La construction d’un entrepôt Snowflake (mais avec un problème de gouvernance – le classique du domaine testeur, premier et qui fait fuir les autres domaines)
2) La construction d’un data lake avec les données brutes (mais avec le problème du data swamp).
3) La construction du compromis entre l’entrepôt et le data lake avec Databricks lakehouse (résultat une 3ème vue des données)
4) La mise en place d’un MDM (Master Data Management) – Informatica MDM, les données de référence vont tout sauver… gouverner les autres vues)
Bilan un enfer data.
L’Excel de Steve au service financier est plus fiable !
La réalité : « Sales counts a customer when they sign. Finance counts when they pay. Product counts when they activate. Legal counts when contracts execute. Marketing counts when they provide an email.
Who’s right? Everyone. And no one.
… Truth Changes Over Time
Monday: “Customer X is active” Tuesday: “Customer X churned” Wednesday: “Customer X reactivated” Thursday: “Actually, they never left, it was a billing error” Friday: “No wait, they did leave, but came back”
… Technical Truth ≠ Business Truth
In the database: customer_status = 1 What it means:
To Engineering: Boolean for active
To Finance: Paying customer
To Product: Logged in recently
To Sales: Still in contract
To Marketing: Opted into emails
One field. Five truths. Zero agreement. »
Ou se cache la vérité ? Dans l’ERP, dans le tableau de bord, dans l’entrepôt, dans le data lake, dans le MDM, dans les excel extraits et ajustés à la main, dans le pipeline…
NB : toujours savoir de quoi on part (la source des données), de quoi on parle (la définition des données en contexte – déjà dit, il y a N définitions de ce qu’est un client, c’est normal et cela se modélise très bien par l’utilisation de facettes, rôles sur un objet pivot), ce qu’on veut faire avec quelles sources et définitions.
Et si vous voulez vous plongez dans l’histoire de l’idée de vue unifiée des données – à lire la naissance et l’évolution du modèle de Kimball DW/DM – faits-dimensions
https://williaminmon.substack.com/p/a-tale-of-two-architectures-kimball
6) Precisely introduit des métadonnées dans ses connecteurs
« Technical metadata : chémas, fields, relationships, data types
Operational metadata : usage patterns, pipeline activity, change frequency, volumes
Statistical metadata : data distributions, anomalies, PII detection
Physical data : source data needed for replication, quality checks, or enrichment workflows »
7) Redéfinition des moteurs SQL multi sources par l’IA
Génération automatique d’agents connecteurs aux sources (requêtage SQL).
Construction d’une couche de traduction du langage naturel to SQL entre les data analystes et les sources.
Editeur : https://textql.com/
Source : https://datanews.levif.be/analyse/arriere-plan/lagent-ia-ana-souhaite-exploiter-des-donnees-complexes-a-laide-du-langage-naturel/
La gouvernance des données ne cesse de se construire (continuité, burn out CDO, du théâtre à l’opérationnel, l’orchestration apprenante, fenêtres data Amazon, à qui appartiennent les données, monétisation des données : l’exemple Uber, la fin des data catalogue passif)
1) How Data Governance Evolved Without Ever Defining Itself
Donner une définition c’est quelque part figer un concept. Figer l’idée de gouvernance des données n’est pas facile tant elle évolue et continue à évoluer.
NB : il est vrai que dans mes interventions sur le sujet, je ne cherche pas à donner une définition, mais à ce que chacun se fasse son idée. Et cela parce que le monde des données a complètement changé et continue à changer.
La gouvernance des données ne cesse de se construire.
L’article revient sur cette construction, son histoire, sous les pressions autour des données au fil du temps (des années 60-70 à nos jours).
Et explique la difficulté de la définition parce que les données sont des choses complexes :
« My close friend and mentor, Daragh O Brien, wrote an excellent piece describing data management as a “Wicked Problem” — it’s a perfect characterization. Read it.
Many data governance problems behave like classic wicked problems:
Recursive, cross-functional, stubborn, and resistant to permanent resolution.
Data is socially constructed.
People interpret it differently.
Systems encode imperfect representations of the world. »
« Governance requires legal literacy, technical fluency, risk awareness, organizational design, and information architecture. No single team holds all of this, and no single leader owns all the incentives. »
La gouvernance des données prend quatre formes :
Form 1: Governance for Quality (Data as an Asset Whose Value Depends on Its Condition)
Form 2: Governance for Risk and Compliance (Data as an Asset That Carries Exposure)
Form 3: Governance for Strategic Value (Data as an Asset That Produces Return)
Form 4: Governance Embedded in Operations (Data as an Asset Managed Through Design and Performance)
…
Form 1: quality → maintain the asset
Form 2: risk → protect the asset
Form 3: strategy → invest in the asset
Form 4: operations → operate the asset effectively
2) REX CDO – turn over, burn out
(sujet mainte fois abordé et mainte fois rencontré)
Un rôle de théâtre mais non opérationnel !?
Classique ni IT, ni métier alors que les données sont de ces deux côtés (vues en termes de conteneur et de contenu).
Le REX est impitoyable d’une réalité mainte fois rencontrée.
La leçon : l’ancrage dans les systèmes (organisationnels, S.I.) et accepter de prendre à bras le corps le sujet data de chaque côté IT et métier sans avoir besoin d’un CDO.
Source : https://medium.com/@aminsiddique95/we-hired-a-chief-data-officer-for-400k-they-havent-fixed-a-single-data-problem-092f66ee305d
3) REX du théâtre à l’opérationnel
« Our $8M Data Governance Program Protected Nothing and Governed Nobody
We Had 47 Policies, 23 Committees, and 186 Standards. Our Data Was Still a Dumpster Fire. »
De la documentation (politiques, normes, catalogue…), des rôles, des scènes (comités), du théâtre, des effets de bord (contournement par excel).
Mais pas de réelle gouvernance. Au plus près des données, dans l’opérationnel (l’action), aller à la source des données, dans leur fondamentaux (définition, environnements de vie), éliminer les frictions qui empêchent les données de circuler.
Article à lire sur la réalité de la gouvernance.
Source : https://medium.com/@aminsiddique95/our-8m-data-governance-program-protected-nothing-and-governed-nobody-108635e78df1
4) Le défi de la gouvernance des données : l’orchestration apprenante
Comment gouverner les données, alors qu’intrinsèquement elles forment un univers, mouvant, de qualité inégale, soumis à pression (exemple nouvelle réglementation), à perturbation, transverses – interfonctionnelles – transformationnelles, avec une omniprésence, une valorisation des données qu’au moment des usages qu’on ne connait pas tous à l’avance… ?
Comment gouverner sans ne plus faire que de la gouvernance réactive (problème après problème – ou plutôt multi-problèmes qui arrivent simultanément) ?
L’article est issu de la thèse de l’auteur sur « Towards Resilient Data Governance ». Avec une enquête auprès de 348 praticiens dans 46 pays.
« The most frequently endorsed goals included: Managing data quality (62%), Managing risk and compliance (57%), Supporting data strategy and transformation (52%), Building data culture and literacy (59%), and Defining and managing metadata (56%). »
Certain objectif s’alignent naturellement. D’autres non.
Le défi est comment coordonner les efforts tout en apprenant globalement (versus résoudre localement le problème – qualité de données sans lien en amont ou en aval).
Pour être résiliente la gouvernance doit s’apprendre de façon continue, partagée (et non vue comme un contrôle statique).
Pour être résiliente la gouvernance doit être pensée structurellement comme étant sous pression, à résoudre les problèmes constamment. Pour cela il faut répartir la pression (le partage) et apprendre en retour (le feedback – la capacité de faire évoluer dynamiquement la gouvernance). Il faut aller plus loin que le cycle PDCA (Planifier-Développer-Contrôler-Agir) et faire qu’il enrichisse les métadonnées.
Source : https://medium.com/my-column-has-nulls/designing-data-governance-to-learn-what-practitioner-reported-goals-reveal-about-value-d8029049fc05
5) Stratégie data chez Amazon : les fenêtres data
« Amazon’s Moat Isn’t Their Data. It’s Their Ability to Find New Data. »
Savoir trouver de nouvelles données et dépasser ses propres données : construire de façon continue sa fenêtre d’observation (différentes de celles des concurrents).
« But here’s what most people miss about Amazon and Netflix — the companies that actually built lasting data moats. They didn’t win by finding one proprietary dataset and defending it forever. They won by building the capability to continuously reposition for NEW observation advantages as old ones eroded. »
A la recherche de données pour dépasser la concurrence.
« Three dimensions identify real advantages : exclusive population access, unique behavioral context, temporal head start ».
Les données d’abord (quoi observer) avant la cathédrale technologique (le téléscope).
Exemples de changement de sa fenêtre d’observation : « Amazon in 1997 wasn’t special because they tracked purchases. Every retailer tracked purchases. They were special because they observed what happened when you removed inventory constraints from shopping behavior…Amazon saw behavioral loyalty driven by shipping psychology. ».
Le défi : « It’s knowing how to find your next observation window. ».
L’article propose des axes de construction : la population observée et les concurrents ont-ils accès à cette population, le comportement observé vous est-il exclusif, avantage temporel — observez-vous avant que cela ne se généralise ?
« The real moat isn’t having observed unique behavior once. It’s being positioned to keep observing NEW unique behaviors as »
Source : https://infusedata.io/amazons-moat-isn-t-their-data-it-s-their-ability-to-find-new-data-402ee05923ec
6) À qui appartiennent les données ?
« No one wants the crown. »
…
« Most people in these meetings aren’t resisting out of malice. They’re protecting themselves from risk — political, reputational, operational.
Data crosses silos. No one wants to be blamed for decisions made upstream. Owning data means owning its problems.»
Être responsable de données implique : d’approuver des définitions, des cycles de vie (des données), des usages, des évolutions, des équilibres cout / qualité, des risques…
Ce n’est pas un rôle administratif de la gouvernance. C’est un rôle visible opérationnel
Source : https://tdan.com/who-owns-the-data/33231
7) Monétisation des données : l’exemple Uber
Historiquement Uber vend ses données de géolocalisation aux annonceurs.
Avec son nouveau programme Uber Intelligence, Uber va monétiser les données comportementales de ses utilisateurs. Toujours à destination d’opérateur marketing (Uber ambitionne un CA publicitaire d1,5 Md$).
« In the case of Uber, this means advertisers who access this data will not just know where a person has been, but insights like what they eat, and how often they move through, say, a given neighborhood or district in a city… With access to Uber users’ data at such granular levels, a hotel company could identify key businesses like restaurants or nearby venues that could be roped into a loyalty program. »
Source : https://gizmodo.com/uber-targeting-for-ads-2000697042
« Get dropped off at the gym ? Someone wants to sell you keto freezer meals and running shoes. More ominously, ICE could use the information to identify hotspots where people from majority-minority neighborhoods congregate, making it simple to target specific churches, community centers, or restaurants. »
Et aussi https://boingboing.net/2025/12/26/uber-wants-to-sell-your-data-to-the-highest-bidders.html
8) La fin des data catalogues documentaires
Data Catalog Is Dead: Long live the metadata
Du catalogue documentaire, passif, non orienté besoin (dans l’opérationnel), non en lien avec le cycle de vie des données.
Au métadonnées boostées par les agents IA et les couches sémantiques.
Les agents IA s’intègrent au quotidien et exploitent les métadonnées dans un contexte étendu (sémantique).
« In the future enterprise, the process would begin not by browsing a list of tables on a data catalog UI, but by asking questions . ».
On ne parle plus de catalogue, mais de questions / réponses – dialogues sur les données dans un cadre opérationnel – au moment où on en a besoin. Et les métadonnées sont actives (porteuses de la gouvernance).
Les catalogues passifs sont morts.
Maintenant tout dépend de la qualité des métadonnées …
Source : https://medium.com/@harmeet.sokhi/data-catalog-is-dead-long-live-the-metadata-52ae7fa66f79
Couche sémantique, ontologie, knowledge graphe, réseau / modèle d’objets métier, modèles d’architecture d’entreprise, taxonomie, ou plus simplement dictionnaire de données … même chose, même combat – la contextualisation des données, la vérité des données ?
Dans la suite de la revue de novembre : https://www.datassence.fr/2025/12/18/revue-data-du-mois-novembre-2025/#_ftn3
1) Une série d’articles sur novembre / décembre
NB : tous ces concepts visent à exprimer une vue unifiée d’un univers. Leur différence tient dans leur capacité à fournir plus ou moins de sens. L’ontologie a intrinsèquement – formellement l’ambition de capter la structure essentielle (porteuse de sens – comme les concepts métier, leurs relations mais aussi les intentions, les états et actions possibles, les règles…). Quant aux dictionnaires, ils s’arrêtent à l’idée de définition statique (des données).
NB bis : tous ces concepts sont en quelque sorte une grammaire d’expression de connaissances. Et cette expression de connaissance ne se révèlent pas d’un coup. Elle se construit culturellement au fil du temps, contextuellement à l’entreprise, collectivement, en embarquant N points de vue (métier, sécurité, réglementaire…). Dans l’exercice de représentation, il est essentielle de prendre en compte ces dimensions (dans le temps, dans la culture) – certains parlent d’appréhender la dimension épistémologique. J’ai connu dans le milieu des année 90 les marchands de modèles « ontologiques » métier d’entreprise (exemple IBM dans le monde bancaire). Avec l’échec associé parce qu’externe à cette dimension épistémologique (sauf à avoir la volonté de l’imposer … le grand classique des ERP qui imposent leur concepts – voir l’exemple SAP). Le seul intérêt que l’on en a eu à l’époque est comme check list des concepts métier.
NB ter : le problème clé, pour représenter tout cela … c’est le temps ! On n’a pas ce temps. Comment faire ? (toujours la même réponse : l’IA le fera pour nous 😉 A minima c’est un excellent facteur d’accélération et permettant d’éviter le syndrome de la page blanche en partant sur une première proposition générée par l’IA)
NB quater : les métadonnées sont le moyens techniques de représentation de ces structures (couches, ontologie, graphes, dictionnaire…). Donc avant de parler de métadonnées, les catégoriser, il faut comme pour toute donnée, savoir ce qu’elles représentent !
Les acteurs data platforms parlent de plus en plus de couches sémantiques – d’ontologie (pour l’interopérabilité, l’IA, le besoin en intelligence contextuelle).
Le web sémantique existe depuis plus de 20 ans mais n’a pas séduit les entreprises (en raison d’une technicité conceptuelle élevée – voir les concepts liés à OWL et en raison de limites de représentativité. A réserver à l’approche scientifique).
Palantir vend en premier son approche ontologique (à base d’objets, de relations, de contraintes – support à la construction du sens, de l’assise contextuelle des données. Sans cela l’IA n’a pas d’appui fiable pour lier les données entre elles).
Se limiter aux données brutes est un échec pour les IA. Elles ont besoin de contexte … sous différentes formes dont ontologique, sémantique pour structurer leur base d’apprentissage mais aussi comme garde-fou / contrôle de leurs résultats.
« When leaders invest in this kind of structured intelligence, they’re not just building better models, they’re institutionalizing trust. That’s the next frontier of AI maturity: where governance, engineering, and meaning converge. »
…
« The Future: Neuro-Symbolic AI
We’re entering a new era of neuro-symbolic AI, where the neural (data-driven) and symbolic (knowledge-driven) worlds converge. Generative AI provides creativity, generalization, and natural interaction, while ontologies provide grounding, structure, and explainability. »
Sources :
https://medium.com/knowledge-driven-business/on-the-limitations-of-ontologies-contributing-to-a-public-discussion-643a30b939b0
https://medium.com/@nc_mike/why-ontologies-are-more-critical-than-ever-93ef40779d5b
https://medium.com/@nfigay/semantic-graphs-going-beyond-the-semantic-conflation-of-metadata-and-graph-labels-c2c0b5d3b5b6
(tutoriel pour construire une ontologie – approche web sémantique) https://medium.com/@cloudpankaj/building-your-first-ontology-a-hands-on-tutorial-2cdd08bc2e02
https://medium.com/timbr-ai/ontology-modeling-for-data-teams-who-dont-want-the-complexity-74145b7d549b
https://medium.datadriveninvestor.com/the-context-advantage-how-palantir-aip-operates-the-modern-enterprise-210c4af39727
2) Le nécessaire temps de constitution d’un socle de sens des données
« AI doesn’t fix broken data. AI amplifies it. »
Le go to market accentue le phénomène.
Le problème de la taxonomie empirique sans réflexion pour répondre à la pression de l’IA (médiatique, éditeur, marché, CV voire politique). Alors que pour certaines données, certains domaines cette taxonomie est normée (comptabilité, supply chain…).
« AI systems depend on consistent labels, clean hierarchies, and unified semantics. GTM data today is typically the opposite: duplicated, manually edited, and governed by exception. »
Le classique : « A growth-stage B2B company implemented AI forecasting across its sales organization. Within two quarters, they discovered their model was consistently 30% less accurate than their veteran commercial Account Executive’s manual forecasts. The culprit? “Stage 3: Qualified Opportunity” meant different things across three regional teams. One required legal review, another required budget confirmation, and the third required neither. The AI faithfully learned all three definitions simultaneously, producing confident predictions based on incoherent inputs. »
Et la gouvernance est clé : assurer le lien entre les N vues, normaliser quand c’est nécessaire (interopérabilité), contextualiser…
Source : https://dataconomy.com/2025/12/30/gtm-data-standard-the-missing-infrastructure-layer/
3) L’intégration sémantique
L’intégration logiciel est le point dur numéro un en génie logiciel.
Dans son périmètre on peut y inclure l’intégration sémantique : comment différents systèmes de données peuvent communiquer, se rapprocher. Comment telles données se rapportent à telles autres données.
Cette intégration est source de sens.
Quelques principes : le DDD (Domain Driven Design) – le contexte local des données – dialecte – sources et environnement de vie, l’interopérabilité et l’idée de Composable Functional Data Fabric (CFDF) – briques de la couche d’intégration sémantique – voir l’article https://blog.dataengineerthings.org/universal-data-supply-a-composable-functional-data-fabric-cfdf-890cea1e9ad7
Et contre principe, avec principalement le web sémantique non adapté aux entreprises – trop lourd en technicité de modélisation, trop axé sur la construction de modèles face à la fragmentation des données. NB : à suivre l’idée d’ontologie native SQL.
Source : https://blog.dataengineerthings.org/its-the-semantics-stupid-c23b0c8fa0bf
4) Contextualisation
La fenêtre de contexte remplace le schéma – nouvelle forme de schéma on read sur les données brutes
L’argument de la « Table Unique » (TO) – SQL plus simple à générer (moins d’hallucinations)
L’argument de la modélisation « juste-à-temps » (JIT) – couche sémantique générée par un agent IA
La boucle des « données synthétiques » langage inter IA sans besoin d’une compréhension (modèle) humaine
L’argument « Les données tabulaires sont mortes » – exploiter la masse principale des données non structurées
L’argument « Pas besoin d’apprendre quoi que ce soit… grâce à l’IA » – pas besoin d’apprendre à coder, à modéliser, SQL puisque l’IA prend cela en main
A suivre dans le prochain article de l’auteur, le démontage de ces arguments.
Source : https://practicaldatamodeling.substack.com/p/data-modeling-is-dead-again-2026
5) Les données ne sont pas la vérité
1) Failles de collectes, failles d’enregistrement, failles de stockage, failles de maintenance, failles humaines (« tromper » les données pour une « réalité » moins préjudiciable).
Les défaillances de l’IA sont d’abord une défaillance dans la gestion des données.
« And if the production of bad data is incentivized, then good machine learning isn’t just hard — it’s mathematically impossible. ».
Que faire : investir dans la connaissance a priori (la « vérité » structurelle (modèles, graphes, règles) plutôt que la « vérité » enregistrée. « Vérité » structurelle qui doit permettre de contrôler la « vérité » enregistrée plausible.
Source : https://frankcorrigan.substack.com/p/bad-data-is-a-feature
2) Le mur du contexte, de la vérité opérationnelle.
En ne tenant compte que de la vérité structurelle (les données, les schémas) l’IA sera en échec.
Les métadonnées opérationnelles, logs de pipelines, des data platforms, traces de l’orchestrateur, historique des connecteurs, données d’observabilité… doivent enrichir le contexte de données.
Source : https://thenewstack.io/the-real-bottleneck-in-enterprise-ai-isnt-the-model-its-context/
L’ambition de donner du sens de bout en bout entre les différentes représentations des contextes des données : modèles de données, schémas d’architecture, de flux, descriptions physiques, taxonomies, lineages, documents applicatifs, production des démarches d’urbanisme…
L’idée produire une cartographie sémantique pour aligner, maintenir la continuité de tout cela (NB : sujet non nouveau historiquement l’ambition de l’architecture d’entreprise).
Et le vécu des nombreuses séances d’archéologies des systèmes pour reconstituer tout un contexte (technique mais aussi métier).
Pourquoi cela revient ?
L’accroissement de la complexité des systèmes (l’empilement du temps).
Avec le problème n°1 qui n’est plus le big data mais le multi data (la fragmentation des environnements de données).
L’ambition de produire le contexte attendu par l’IA.
NB : le défi en faire des métadonnées actives.
Sources : https://medium.com/@nfigay/semantic-cartography-a-new-way-to-maintain-enterprise-continuity-across-domains-and-time-ee4efa8a3770 et https://medium.com/timbr-ai/how-ontologies-turn-data-chaos-into-clarity-5cfea9b2fc1d
La bataille d’accès aux données (des capteurs partout, sur tout et en masse, constitution d’un écosystème de traces, les données d’interactions professionnelles comme source d’apprentissage pour l’IA – le cas Linkedin, les vœux du monde de la science et des médias pour accéder aux données des plates-formes)
1) Des capteurs partout, sur tout et en masse
a) Le dernier né des géants
“Le bateau est équipé de cinq cents capteurs faisant remonter plus de un milliard et demi de données par jour. Charles Caudrelier »
b) Et dans un autre registre : les capteurs dans vos toilettes.
Sources : https://www.lebigdata.fr/withings-pee-scanner-votre-analyseur-durine-connecte-a-domicile et https://www.techdirt.com/2025/12/15/literal-enshittification-smart-toilets-play-fast-and-loose-with-your-pooping-data/
c) Capture de l’intime pour sa santé, mais détourné pour des considérations marketing et pour entraîner des IA. Tout y est du schéma classique d’usage de nos données et de leur valorisation : capture de données -> revenus publicitaire -> entraînement IA (capture connaissance -> valorisation), rebouclage.
d) Tout peut-il être sous forme de données – suite ?
Source : https://link.springer.com/article/10.1007/s41060-025-00997-4 – technique de détection des sarcasmes … (suite revue novembre – Tout peut-il être sous forme de données ?)
Avec la question habituelle, qui a l’autorité pour formaliser ce qu’est un sarcasme. Avec quels choix, restrictions. Un sarcasme est un concept ouvert. On va fermer sa définition !?
2) Constitution d’un écosystème de traces
Quand vous devez déclarer votre activité en ligne lorsque vous voulez vous rendre aux US.
Quand le Service américain de l’immigration et des douanes (ICE) a publié un appel d’offres destiné aux entreprises privées pour la mise en place d’un programme de surveillance des réseaux sociaux 24h/24 et 7j/7.
Le tout pour alimenter le backbone mis en place avec la technologie de Palantir (regroupement et agrégation de données, reconstruction de réseaux de relations – votre famille, vos amis, vos rencontres..).
L’écosystème en construction : « ICE quietly revived a contract with Paragon’s Graphite tool, software reportedly capable of infiltrating encrypted apps such as WhatsApp and Signal.
Meanwhile, ICE’s vendor ecosystem keeps expanding : Clearview AI for face matching, ShadowDragon’s SocialNet for mapping networks, Babel Street’s location history service Locate X, and LexisNexis for looking up people. ICE is also purchasing tools from surveillance firm PenLink that combine location data with social media data. »
Auquel il faut rajouter l’achat de données aux brokers, le croisement sans frein des données de différentes sources — agences gouvernementale (santé, police, fiscal, juridique, électoral, prestations sociales…).
La prochaine étape, l’identité numérique biométrique pivot des traces.
Avec les drames des faux positifs incontournables.
Et aussi : https ://www.wired.com/story/dhs-data-grab-putting-us-citizens-at-risk/
3) Les données d’interactions professionnelles comme source d’apprentissage pour l’IA – le cas Linkedin.
La valeur des données Linkedin est immense, difficile à reproduire.
Et cela se fait avec nos données contre plus de service (on paye avec nos données).
Avec l’effet du serpent qui se mord la queue : une partie de ces données sont / seront générées via l’IA (a minima proposée par Linkedin)… avec quels effets ? (fausser le marché de l’emploi ?).
Et pas de retour arrière possible, les données existantes ont déjà servi à entraîner les moteurs d’IA.
Avec en fond, la question de la protection de nos identités (professionnelle, civile…).
Source : https ://www.lebigdata.fr/linkedin-entraine-son-ia-sur-vos-donnees-2-experts-devoilent-les-risques
4) Données réfractives la solution au verrouillage des données des plates-formes
Les grandes plateformes numériques (X/Twitter, Meta, TikTok, Reddit…) restreignent de plus en plus l’accès à leurs données. Ce qui fragilise la recherche en sciences sociales, la capacité d’audit.
Face à ce verrouillage, les auteurs proposent une méthodologie alternative : l’analyse de jeux de données réfractifs (refractive datasets).
Le concept : partir des données de plates-formes ouvertes pour comprendre les dynamiques qui se déroulent dans les plates-formes fermées.
L’analyse du reflet des plates-formes fermées dans les plates-formes « ouvertes » (l’article en mobilise deux : Wikipédia, moteurs de recherche – Google trends).
Exemple : réfraction du sujet de l’hydroxychloroquine pendant le COVID-19 dans Wikipédia (pics de consultation, localisation, historique des éditions, mises en garde…
Wikipédia agit ici comme un point de consolidation de discours dispersés sur de multiples plateformes inaccessibles.
Autre exemple du sujet de l’usage détourné du protoxyde d’azote et des contenus associés (diffusés dans Tiktok avant d’être supprimés).
Pas d’analyse direct possible (pas d’accès, effacement), mais via Google trends essai de reconstitution de la chronologie (premières publications, influenceurs, vidéo virales, amplification par les médias traditionnels).
Et aussi visé l’analyse des pratiques de désinformation, des paniques morales, des rumeurs, des comportements à risque propagés par les plates-formes fermées mais non accessibles. Jusqu’à l’idée d’instruire une gouvernance par proxy (via la réfraction).
En santé publique, cela correspond à une logique de surveillance direct des pathologies, mais des récits, croyances et paniques qui influencent les comportements de santé.
Les auteurs donnent les limites de l’exercice, non accès direct aux contenus des plates-formes fermées, et biais des plates-formes ouvertes utilisées comme lentille (politique éditoriale de Wikipédia, manque de transparence de Google trends).
L’article présente également les attaques contre les infrastructures de connaissance (cas de dérèglement climatique), via la production par LLM d’articles, de résumés faussés et le tout repris et diffusé sur Tiktok
Les données réfractives parlent autant par ce qu’elles montrent que par ce qu’elles laissent deviner.
Et pour la gouvernance des données, le sujet du contrôle des accès (par qui, pour quoi) reste premier. Et tout cela pour une gouvernance plus profonde : le contrôle des effets sociaux.
Source :https:/ /journals.sagepub.com/doi/abs/10.1177/20539517251406193?a i=2b4&mi=ehikzz&af=R
Et dans cette logique l’article suivant.
5) Les vœux du monde de la science et des médias pour accéder aux données des plates-formes
Proposition d’une feuille de route pour élargir l’accès aux données influentes des plateformes en lignes. Feuille de route élaborée par des journalistes, chercheurs, acteurs de la société civile.
Cité par https://danslesalgorithmes.net/stream/ameliorer-lacces-aux-donnees-des-plateformes/
Les données pour le bien commun ont besoin de moyens d’accès.
Les plates-formes restreignent les accès (fermeture d’API, menace de poursuite) et poussent à la monétisation de leurs données.
Les chercheurs ont de plus en plus de difficulté à accéder aux données de ces plates-formes.
Ils proposent un cadre « Better Access » pour les données à fortes influences sur le discours public.
Quatre catégories de données à forte influence :
« Contenus à forte diffusion : Publications ou vidéos atteignant une portée ou un niveau d’engagement exceptionnels, et contribuant à façonner l’agenda public.
Comptes gouvernementaux et politiques : Publications provenant de comptes appartenant à des élus, des candidats, des partis politiques et des institutions, qui influencent directement la gouvernance.
Comptes publics influents : Contenus provenant de comptes appartenant à des célébrités, des journalistes, des responsables civiques ou d’autres personnalités publiques dont la portée leur confère une influence considérable.
Comptes commerciaux et contenus sponsorisés : Publicités et messages commerciaux susceptibles d’influencer le comportement des consommateurs, la santé publique ou la confiance du public. »
Et influence variable suivant le contexte : couverture en termes de populations (global, local), géographique, linguistique.
Le cadre définit trois mécanismes complémentaires que les plateformes doivent mettre en œuvre : une interface de données proactive (API ou autre moyen), capacité de répondre à des demandes de données personnalisées de la part des chercheurs et autorisation de collecte automatisée indépendante de données.
La table des matières
Les données attendues
NB : à quand une norme sur les données des réseaux sociaux à l’image des normes comptables, bâloise, solvency … ?!
Source : https://kgi.georgetown.edu/research-and-commentary/better-access/ et le rapport https://kgi.georgetown.edu/wp-content/uploads/2025/11/Better-Access_Data-for-the-Common-Good_Knight-Georgetown-Institute_November2025.pdf
Vrac (règles juridiques des données dans l’espace, revue sciences humaines dédiée aux données, data value manifesto, data ethic framework, data et cybersécurité, données non structurées, la guerre des données, décrire le monde)
1) Quelles règles juridiques pour les données stockées dans l’espace
« Artificial intelligence companies are exploring locating their data centers on satellites. »
Comment considérer les données « hors Terre » !
Source : https://tdan.com/legal-issues-for-data-professionals-data-centers-in-space/33289
2) Naissance d’une revue dédiée aux données en SHS sciences humaines et sociales
https://dc.episciences.org/volumes/1042 espace éditorial entièrement dédié aux articles de données (data papers) en SHS
Source : https://hal.science/hal-05398681v2/document
3) Data value manifesto
« This free online course is designed to help you explore the Data Values Manifesto and learn how you can help make data fair, inclusive, and beneficial for everyone. ». Source : https://www.data4sdgs.org/resources/data-values-e-learning-course
4) Data ethic framework
https://www.gov.uk/government/publications/data-ethics-framework
Evolution avec l’IA.
Un outil d’auto évaluation du gouvernement UK.
Sources : https://dataingovernment.blog.gov.uk/2025/12/18/building-trust-in-data-and-ai-the-new-data-and-ai-ethics-framework-and-self-assessment-tool/ et https://www.ukauthority.com/articles/gds-updates-data-ethics-framework-for-public-sector
5) Data et cybersécurité
https://diginomica.com/what-if-your-security-problem-really-your-data-problem-heres-why-databricks-shifting-blame-it
6) Données non structurées
Prolifération, exploitation par l’IA … le mal de crâne de la gouvernance pour maîtriser cela.
Comment les classer, le premier pas.
Source : https://www.hpcwire.com/bigdatawire/2025/12/18/untamed-data-is-undermining-the-ai-revolution/
7) La guerre de l’information … la guerre des données
Des témoignages (en Hongrie, aux US, en Ukraine).
Source : https://dataculturegroup.org/2025/12/14/cpluj-2025.html
8) Décrire le monde
Pour les besoins de l’IA, de la robotique.
RDV maintenant en février pour la revue et les actualités de janvier.
Les commentaires sont fermés.