Cet été un ensemble d’articles plutôt orientés retours d’expérience et qui montre une montée en maturité et une prise en compte des fondamentaux sur les données.

Je vous livre une liste de pas mal de lectures au fil de l’eau.

A piocher en fonction de vos centres d’intérêt.

Sommaire :

• Les données ombres de la caverne de Platon
• Sans contexte les données ont peu de valeur
• Les data platforms ne peuvent pas tout faire
• Data team : centre de coût ou centre de profit quand cela dépend de la façon de modéliser les données
• Le tournant du partage des données
• La représentation du temps dans la modélisation des données
• Attention à la vision idéalisée de l’IoT
• La croissance des données par les besoins des agents IA et par leur production en données
• Les données ne font pas tout … exemple d’un centre d’appel
• Pourquoi votre stratégie d’IA passe à côté de la moitié des données importantes. Le fossé d’interprétation
• Souveraineté des données à tous les niveaux. Qui possède et contrôle vos données ?
• Et pourtant la société Palantir et son offre de service et logiciel (data platform) s’étend à vitesse grand V
• A lire aussi en lien – data gouvernance et données personnelles
• Le rôle vital des métadonnées commence à être largement reconnu
• Graphe de connaissances fédéré : le chaînon manquant de votre stratégie de données
• La dépendance entre documents et données devient un sujet avec l’IA
• Quatre façons de comprendre la stratégie de données et d’IA de toute organisation au travers de l’idée de produits de données
• Les contrats de données ne fonctionnent pas. Voici comment y remédier
• Leçons du Big Data à l’IA
• Loi de Conway, silos, cloud et modélisation des données … théorie et réalité
• Quand les agents IA s’invitent dans les tâches de traitement des données
• Les vérités dérangeantes de l’analyse en libre-service
• Le problème des trois corps des données : pourquoi l’analytique, les décisions et les opérations ne s’alignent jamais
• Data Mesh : Réalités des premiers utilisateurs
• Les données écartelées entre : le partage et la protection face aux violations de données
• Qu’est-ce que l’analyse de données multimodales ? intermodale
• Toujours le choc du DOGE dans l’usage des données, ou comment tout ce que vous avez appris sur les données peut être remis en cause du jour au lendemain
• Le danger caché de la souveraineté des données
• Les bonnes et mauvaises équipes de données
• Tout est dans les données : D’où viennent les bonnes données ou enfin mettre en lumière les producteurs de données
• Les données professionnelles : la prochaine frontière de la GenAI
• L’interopérabilité des données est un sujet politique
• A lire aussi (data et sport, DAMA DMBoK deux critiques, Data workers, Data platform, gouvernance des données scientifiques)

Les données ombres de la caverne de Platon

Les données sont le reflet de choix et représente une vision limitée de la réalité. L’article suivant s’amuse à l’analogie entre la caverne de Platon et les données. Les données sont des ombres, captures de fragments d’une réalité plus profonde. Prisonniers de la caverne, il est tentant de croire que les données sont la vérité.

Enseignement : agir avec les données en toute connaissance de cause

• Il ne faut pas oublier que les données sont des ombres et apprendre à ne pas en être prisonnier.
• Rappel les données sont des modèles. Et un modèle est forcément limité, incomplet, résultat de choix, de finalités.
• Bien qu’imparfaites les données relèvent des structures, schémas, signaux du réel et c’est leur force.
• Données qui peuvent être exploité si on sait que derrière ces représentation se cachent un contexte que les ombres ne donnent pas toujours : qui a créé les ombres, avec quelles motivations, dans quelles conditions…
• Contexte qu’il faut aller chercher. Et donc retourner dans la réalité pour confronter les données au terrain (opérationnel). Avec la difficulté de l’étendue de la réalité et donc des limites de l’exercice de contextualisation.

Source : https://towardsdatascience.com/platos-cave-and-the-shadows-of-data/

Sans contexte les données ont peu de valeur

Dans la suite de l’article précédent et avec l’IA qui met encore plus en avant le sujet.
Il y a besoin d’une couche contextuelle des données dans les stacks data.
L’article discute d’une vision par couche sémantique, par couche de métriques (contexte relationnel des données – avec quoi sont reliées les données. NB : d’autres dimensions du contexte sont nécessaires).
Couche qui n’est pas forcément une bonne idée.
Les éditeurs de logiciels data l’ont proposé, mais avec une adoption faible.
Vendre un couche de cette nature n’est pas facile… sans démonstration de valeur.
Et pourtant il y a besoin de plus en plus de contexte aux données (par exemple les réponses d’un agent IA sont forcément multi-données et font appel à des liens entre données – liens sémantiques, knowledge graphs).
Et il faut aller chercher ce contexte. D’où l’idée de MCP (Model Context Protocol) qui au final s’attaque pour la nième fois au problème n°1 qu’est l’intégration (c’est couteux en temps, en effort, en maintenance, en fonctionnement…).
Avec l’erreur de vouloir que tout soit centralisé (le mythe de la vue unifiée des données et des contextes associés).

Source : https://benn.substack.com/p/the-context-layer

Les data platforms ne peuvent pas tout faire

Article : La dette de la plateforme de données que vous ne voyez pas venir.

Sauf à tout mettre son S.I. dans un même endroits, les plates-formes ne peuvent pas :

• Récupérer tous les contextes de toutes les données,
• Appréhender toutes les logiques (règles de gestion) métier liées aux données et réparties dans le S.I. (des sources aux usages). Avec le risque de duplication, d’écart d’évolution de règles, de réinventer des silos…
• S’attaquer aux frictions des cycles de vie des données que les processus d’entreprise font avancer,
• Assurer une politique d’accès complète (du bon sens : elle n’assurent que ce qu’elles contiennent),
• Être à niveau de la dynamique permanente d’évolution des données (reflet de la réalité métier), avec le problème du drift des données, d’évolution des schémas, des règles, des sources, de l’apparition temporaire puis récurrente de nouvelles données, de choix de gouvernance… Avec l’équilibre à trouver entre rigidité pour ingérer correctement les données (rôle des contrats de données par exemple) et agilité pour être au niveau de la réalité évolutive des données (d’où l’art de concevoir des modèles de données évolutifs).

Avec en conclusion, comment traiter l’obsolescence qui attaque dès sa naissance une data platform ?

Une piste (de bon sens), mesurer en continu l’apport stratégique métier. Voir la conception d’une data platform non pas comme un référentiel passif mais comme un moteur actif connecté aux processus, points de décision. Ou au pire voir sa dette non pas comme une dette technique mais comme une dette stratégique, une dette de capacité d’action (données pas ou mal exploitées par exemple).

Autre piste, voir les données comme un produit à part entière.

Ne pas oublier qu’une data platform n’est qu’une brique d’un écosystème des données. Et que c’est cet écosystème dans son ensemble qu’il faut considérer.

Source : https://www.datasciencecentral.com/the-data-platform-debt-you-dont-see-coming/

Data team : centre de coût ou centre de profit quand cela dépend de la façon de modéliser les données

Le schéma classique : les données sont vues comme des sous-produits de processus, leur modélisation est pensée pour que le processus marche (en exécution et en pilotage).
Entre valeur démontrée et valeur absente, l’équipe data (d’appui à la modélisation) navigue en zone grise quant à sa réel influence (source de frustration). Elle peut être vue comme un centre support … de coût. Les données ne sont pas faites pour sortir de leur environnement pour d’autres usages (partage, IA).

Le schéma data product : les données sont vues comme un produit à part entière. Elles structurent le processus et sont aussi faites pour sortir de leur environnement et consommées par d’autres acteurs.
La modélisation doit être pensée futurs consommateurs (un moteur de recommandation, un moteur d’IA, une vue croisée 360°…). L’équipe data dépasse (source de valorisation) l’environnement d’origine des données et pense valeur potentielle et mesurée (feedback) pour d’autres consommateurs.
Avec l’IA comme consommatrice, l’attention est d’autant plus forte sur le travail de modélisation.

Les deux schémas peuvent cohabiter au sein d’une organisation.

Source : https://practicaldatamodeling.substack.com/p/enterpriseland-and-productland

Le tournant du partage des données

Via une place de marché.

Dont le rôle n’est pas que d’inventorier, contextualiser, publier, mais aussi d’offrir un bac sable de visualisation / test, d’aider à la rationalisation des sources, à la qualité des données (contextualisée en fonction de l’usage), de suivre l’utilisation (données vedettes, non utilisées) dont les feedbacks, de suivre la dynamique d’évolution des données (versions), de traçabilité – véracité des données (l’accent est mis sur l’état des données tel que via des métadonnées), de préciser le niveau de conformité par rapport à des réglementations, d’exposer les potentiels de croisements de données (source principale de valeur), et bien entendu de supporter une part de la gouvernance.

Avec l’éternel sujet clé des métadonnées … qui doivent être visibles, actives (produites de façon structurelle dans le S.I.) et non statiques (saisies en mode manuel) ou produites en mode réactif (résultat d’enquêtes – cas demande réglementaire par exemple), apportant la capacité d’utilisation autonome des données (pour un rattachement des données en toute connaissance dans un nouveau contexte).

Et une alerte sur le raccourci place de marché et monétisation des données. L’erreur est de penser, j’ai des données dans ma place de marché et que des consommateurs vont venir « acheter » les données. La monétisation ne part pas de là, elle part d’une réflexion plus profonde tout en s’appuyant sur tout un effort amont reflété par la place de marché.

Sources : https://moderndata101.substack.com/p/where-data-comes-alive-a-scenario et https://medium.com/@community_md101/where-data-comes-alive-a-scenario-based-guide-to-data-sharing-part-2-273d9a3e0a0a

La représentation du temps dans la modélisation des données

Date et période d’effet, de validité, d’événement, de collecte, d’ingestion, de traitement … une mauvaise gestion du temps peut ruiner de nombreux usages des données. Avec deux axes, un axe représentation métier (données) et un axe représentation du temps de traitement (métadonnées). « Le temps est une préoccupation majeure pour tout système de données, et pourtant, il reste l’un des aspects les plus subtils et les plus mal compris de notre travail ».

Source : https://practicaldatamodeling.substack.com/p/time-full-chapter

Attention à la vision idéalisée de l’IoT

Une chaîne de collecte de données n’est pas une aventure tranquille.

L’article suivant décrit le sujet dans le contexte de l’agriculture connectée.

Avec les défis :

• De gérer des données hétérogènes en format, en sémantique,
• D’interopérabilité
• De qualité des données (trou de collecte, bruits)
• De récupération – réception (conditions météo, terrain, pannes)
• D’interprétation au plus près ou à la réception
• De sécurité…

Source : https://journalofbigdata.springeropen.com/articles/10.1186/s40537-025-01253-z

La croissance des données par les besoins des agents IA et par leur production en données

Le paradoxe de Jevons appliqué aux données et agents IA : plus on consomme des données, plus on va en avoir besoin.
Avec un exemple sur l’observabilité des agents qui passent par des données, elles-mêmes ingérées par des agents (pour en gérer l’efficacité), etc.
Et un autre exemple sur les données comportementales, plus on en dispose, plus on en demande…

Le problème derrière cela est d’avoir à disposition ces données et donc un S.I. préparé à cela (et dans le cas des S.I. historique on est loin du compte).
L’auteur fait l’analogie avec un verger, le bon moment pour planter un arbre c’est il y a 20 ans.
C’est vrai pour les données et avec l’avènement de l’IA encore plus.

Source : https://thenewstack.io/the-obscure-paradox-fueling-ai-and-big-data-growth/

Les données ne font pas tout … exemple d’un centre d’appel

Quid de la touche humaine, de l’empathie ?
Comment se préoccuper du contexte, de la situation du client.
C’est toute la différence entre une exécution mesurée et une exécution interprétée (que seul un être humain peut mener).

L’article expose la problématique de synergie entre données et empathie.

« Imaginez un agent qui reçoit une alerte l’informant qu’un client fidèle et précieux vient d’exprimer sa frustration sur les réseaux sociaux. Les données fournissent le contexte : l’historique du client, sa valeur, le produit spécifique dont il se plaint. Mais c’est l’empathie qui guide la réponse de l’agent : le ton de la communication, la prise en compte de ses sentiments et la solution personnalisée proposée. »
Avec laisser aux agents IA la fourniture du contexte et concentrer l’effort humain sur l’empathie … vœux pieux ?

Source : https://www.smartdatacollective.com/intersection-of-data-and-empathy-in-modern-support-careers/?amp=1

Pourquoi votre stratégie d’IA passe à côté de la moitié des données importantes. Le fossé d’interprétation

Un article qui s’attaque au sens des données, sens vu par l’IA et sens vu par l’humain.
Avec en fond la bataille autour de la communication que l’IA générative essaie de s’accaparer.
Le fossé de l’interprétation : les IA sont entraînées sur des milliards de textes mais ignorent complètement la facette interprétation. Facette qui donne sens à ce que l’humain va percevoir, sentir, comprendre de sa lecture en fonction de sa situation, d’un contexte.
Du côté humain, on a deux instants magiques qui vont de pairs, la production et l’interprétation de textes, conversations.
Du côté de l’IA, on a un instant boîte noire, la production de texte seule.
NB : rappel aucune IA ne fait appel à un quelconque sens dans ses traitements. Il ne s’agit que d’ingénierie textuelle.

Avec une difficulté supplémentaire pour les moteurs d’IA, qui est la dynamique évolutive du langage, des mots. Un même mot à deux moments, deux dates différentes peut être interprété différemment (exemple de terme cloud).
L’IA représente un moment fossilisé … qui cours après le temps.
NB : avec le danger de vouloir nous enfermer dans ce moment.

Et pour faire le lien avec l’article précédent, l’empathie ne peut pas se passer du sens … et est hors d’atteinte des moteurs d’IA (et cela s’applique aussi à l’interprétation des émotions que l’on veut enfermer dans catégories).

Tout cela est structurel pour les moteurs d’IA. Et on l’oublie souvent (NB : tout comme les hallucinations qui sont structurelles – un moteur d’IA hallucine à 100% et statistiquement une partie se révèle « correct » ou presque).

« Le fossé d’interprétation exige un changement fondamental dans la façon dont les dirigeants abordent l’intégration de l’IA. Au lieu de se demander « L’IA peut-elle effectuer cette tâche de communication ?», demandez-vous plutôt « Quelles nuances d’interprétation de cette tâche requièrent une conscience humaine ?» »

Source : https://opengovernance.net/why-your-ai-strategy-is-missing-half-the-data-that-matters-the-interpretation-gap-d1eb951c61d4

Souveraineté des données à tous les niveaux. Qui possède et contrôle vos données ?

Beaucoup d’articles sur le sujet au cours de l’été, en lien avec : l’effet Trump, les changements de politiques des entreprises Tech US vis-à-vis de la protection des données, le Data act côté Europe, la réponse CLOUD Act des US (Clarifying Lawful Overseas Use of Data Act), les offres de modernisation de systèmes obsolètes, cela à faible coût de Google, Microsoft auprès des administrations (offres biaisées bien entendu), et plus largement notre dépendance à la technologie numérique.

Exemple : « Microsoft a récemment déclaré ne pas pouvoir garantir la souveraineté des données à ses clients en France – et par extension dans le reste de l’UE – si le gouvernement américain exigeait l’accès à ces données ».

Autre exemples : « Annoncé début juillet, cet accord stipule que le géant technologique américain Google fournira gratuitement une technologie au gouvernement britannique pour moderniser ses systèmes obsolètes ». et « Par ailleurs, un nouvel accord avec Microsoft soulève des questions similaires au sein de l’UE. Selon cet accord, Microsoft investira jusqu’à 5 milliards d’euros pour moderniser l’informatique du secteur public dans l’ensemble de l’Union »… « Les services gratuits ne sont pas gratuits éternellement. ».

Informatiquement parlant, derrière la souveraineté se cache le sujet récurrent de la dépendance à des fournisseurs technologiques, de la réversibilité. Sujet que tout architecte de S.I. a vécu … sans solution miracle (NB : mais on peut limiter les dégâts, a minima préserver ses données, concevoir un S.I. en déplaçant les traitements plutôt que les données…).

Une source : https://www.politico.eu/article/data-tech-google-taxes-buying-habits-produce-eu-uk-us-microsoft/

Et pourtant la société Palantir et son offre de service et logiciel (data platform) s’étend à vitesse grand V

Palantir : le pouvoir de la data… ou la data au service du pouvoir ?

Avec Palantir, votre dépendance est encore plus profonde.
Elle se situe d’abord comme pour tout offre technologique de data platform au niveau de l’infrastructure logicielle (maniement à grandes échelles de données, de sources de données, de techniques de consolidation de données).
Mais Palantir ajoute une deuxième couche de dépendance au niveau de l’infrastructure des données, de la façon dont elles sont représentées, reliées sémantiquement via une ontologie pour en faire une vision data « opérationnelle ».

L’article revient sur l’histoire de Palantir et décrit son offre de service Foundry, Gotham…

« Peu à peu, Foundry séduit les grandes entreprises. À première vue, c’est une simple plateforme de gestion et d’analyse de données. Mais en réalité, c’est un environnement complet qui permet de faire vivre la data, de bout en bout, sans la noyer dans la complexité technique. »

« Si Foundry est pensé pour les usines, Gotham, lui, est taillé pour le champ de bataille. Ce logiciel, conçu initialement pour la CIA et le FBI, permet de croiser, visualiser et analyser des masses de données opérationnelles en temps réel. »

Et sur la dépendance : « D’autres pointent également un risque de dépendance technologique. Une fois qu’une organisation structure ses données et ses flux autour de Foundry ou Gotham, difficile de revenir en arrière. D’autant plus que les interfaces sont propriétaires, et que le support technique passe presque exclusivement par les équipes Palantir. Mais c’est peut-être là que réside la stratégie : créer des outils si utiles, si profondément intégrés aux processus, qu’ils deviennent indispensables… même pour leurs détracteurs. ».

Palantir a compris et fait de l’usage des données des armes d’action, d’influence.

Source : A lire : https://datascientest.com/palantir-tout-savoir

A lire aussi en lien – data gouvernance et données personnelles

1) Data gouvernance : le toolkit de l’UNESCO / ITU. Avec une approche basée autour du cycle de vie des données (planification, collecte, traitement, partage, analyse, utilisation). Et un focus sur la gouvernance des droits des personnes (vie privée, biais, surveillance, liberté d’expression, recours) et l’idée de digital self determination (DSD) pour redonner le contrôle des données aux personnes (gestion continue des consentements, co-gouvernance communautaire, transparence accrue sur les usages…). Le toolkit fait le lien avec d’autres approches complémentaires : principes FAIR (Findable, Accessible, Interoperable, Reusable) et CARE, règlements locaux (RGPD), les stratégies d’infrastructures publiques numériques (DPI).

https://www.broadbandcommission.org/wp-content/uploads/2025/07/Data-Governance-Toolkit.pdf

2) Une analyse approfondie du sujet de la gouvernance dans le cadre du système de santé américain : https://journals.sagepub.com/doi/abs/10.1177/20539517251357305 et en lien – Should I provide my health data for research? Citizens assessing the value of data provision – https://journals.sagepub.com/doi/full/10.1177/20539517251361117

3) Une analyse du contrôle des données personnelles dans le cadre de nos conversations avec les chatbot IA : https://www.techpolicy.press/we-need-to-control-personal-ai-data-so-personal-ai-cannot-control-us/

4) Une solution pour conserver son pouvoir sur ses données ? This AI Gives You Power Over Your Data – https://singularityhub.com/2025/07/11/this-ai-gives-you-power-over-your-data/
« Une nouvelle architecture, baptisée FlexOlmo et développée par des chercheurs de l’Allen Institute for AI (Ai2), pourrait offrir une solution de contournement potentielle. FlexOlmo permet d’entraîner des modèles sur des ensembles de données privés sans que les propriétaires aient à partager les données brutes. Elle permet également aux propriétaires de supprimer leurs données, ou d’en limiter l’utilisation, une fois l’entraînement terminé. »
Mais que faire quand …

5) Data broker entre bataille juridique et dark pattern : How did you get my number? Inside the shadowy world of data brokers – https://www.theguardian.com/world/2025/jun/09/how-did-you-get-my-number-inside-the-shadowy-world-of-data-brokers-ntwnfb

6) Et Data brokers face new pressure for hiding opt-out pages from Google – https://themarkup.org/privacy/2025/08/18/data-brokers-face-new-pressure-for-hiding-opt-out-pages-from-google

7) Et aussi Banks are selling your data. Here’s the evidence – https://unbanx.substack.com/p/banks-are-selling-your-data-heres

Le rôle vital des métadonnées commence à être largement reconnu

Une série d’articles sur le sujet.

Pour rappel : sans métadonnées, les données n’ont pas de sens, sans métadonnées on ne peut pas gouverner les données, sans métadonnées on ne peut pas partager des données…

Mais les métadonnées ne sont pas gratuites, il faut les produire, comme données elles doivent être de qualité, gouvernée … et cela a un cout.

Avec l’arrivée de l’IA, le sujet explose. On essaie de combler la faiblesse d’interprétation des données des moteurs d’IA par l’adjonction de contexte … donc de métadonnées.

1) Pourquoi les métadonnées sont la nouvelle interface entre l’informatique et l’IA ?

Les métadonnées contextualisent les données (structurées et non structurées).
Contexte indispensable aux moteurs d’IA.
Historiquement les métadonnées étaient partielles, vues comme des descriptions passives, offrant une vue statique (souvent passée). Elles doivent être maintenant actives, dynamiques pour suivre le rythme des données et donc des besoins des moteurs d’IA.

On parle d’étiquettes actives des données (vues comme produits).

Exemples : niveaux de sensibilité d’une données, source (finalité – lieu de naissance des données), annotations – labélisation, balises sémantiques, éléments de lineage…

Il existe différentes catégorisation des métadonnées, techniques, métiers… L’article propose quatre catégories : métadonnées contextuelles, métadonnées de sensibilité, métadonnées utilisateur, métadonnées générées par l’IA.

Dans cette vision les métadonnées sont là pour enrichir la capacité d’interprétation des données.

Mais on peut aller plus loin. Les métadonnées peuvent être vues comme les paramètres de configuration de workflow, de systèmes d’agents (IA).
Avec par exemple l’idée de passer des ETL à l’idée de workflows itératifs pilotés par les métadonnées.
NB : sujet bien connu en statistique, voir le processus de production statistique GSBPM où les métadonnées sont centrales dans la progression de la production.

Et comme données, les métadonnées sont également le support de pilotage, de l’observabilité, des macro contrôles des données qu’elles représentent, des usages, etc.

Dans une pile de données, les métadonnées sont centrales et l’essor de l’IA pousse à cela.
Les métadonnées deviennent un actif stratégique.
Elles doivent être gouvernées.

Source : https://www.dataversity.net/why-metadata-is-the-new-interface-between-it-and-ai/

Un autre article dans ce sens.
2) « Pensez métadonnées d’abord : Concevez des lacs de données pilotés par les métadonnées grâce à ces 8 règles d’or ».
En adoptant une data platform pilotées par les métadonnées, les promesses sont de :

• Maîtriser la multiplication des sources de données (dont la multi modalité),
• Faciliter la découvertes des données,
• Contrôler dynamiquement les accès,
• Gérer l’évolution des schémas,
• Contrôler la construction, configuration et exécution des pipelines,
• Déployer des espaces de confiances, contextualisés pour les moteurs d’IA,
• …

Les conseils : adopter l’architecture médaillons et un design by métadonnées, pour penser dès la conception aux évolutions de schémas, à une conception résistante (idempotence, reprise et migration de données), au contrôle des coûts (usage, stockage des données), à alimenter dynamiquement le catalogue de données*, au contrôle des sources et appuyer a gouvernance des données.

* Rappel une gestion manuelle est vouée à l’échec (en retard, partiel, rigide) et ne dépasse pas un périmètre limité.

Source : https://medium.com/@goyalarchana17/think-metadata-first-architect-metadata-driven-data-lakes-with-these-8-golden-rules-5e0e3524b2a4

3) Voir dans cet article un exemple de design by métadonnées au travers de l’outil Airflow.
Source : https://medium.com/@sriragav.2009/beyond-job-running-how-airflows-metadata-plane-powers-data-governance-cd354ce1c448

Graphe de connaissances fédéré : le chaînon manquant de votre stratégie de données

Le graal de la vue unifiée des données enrichies de leur contexte (dont leur inter-relations).
Au travers de l’idée de knowledge graph.
« Chez Actian, nous définissons le graphe de connaissances comme une structure de données représentant un univers de connaissances à travers un ensemble de concepts, d’entités, de relations et d’événements interconnectés. En reliant les métadonnées sémantiques, un graphe de connaissances fédéré fournit un contexte aux données et offre un cadre fiable pour l’intégration, la découverte et la gouvernance des données. »
NB : on retrouve le rôle central des métadonnées.

Avec l’accent mis sur la fédération versus une vue centralisée appauvrissante.
Vue qui permet de garder les spécificités, la connaissance locale.
« Chaque domaine de votre organisation, comme le marketing, la finance et le développement produit, peut gérer son propre graphe de connaissances localisé, reflétant son langage, ses flux de travail et ses normes spécifiques. Ces « sous-graphes » sont interconnectés, permettant aux utilisateurs de découvrir et d’utiliser les données de toute votre organisation tout en bénéficiant d’une autonomie de domaine. »

Source : https://www.actian.com/blog/data-intelligence/federated-knowledge-graph-the-missing-link-in-your-data-strategy/

La dépendance entre documents et données devient un sujet avec l’IA

Le sujet est lié à l’apport de l’IA dans l’extraction de données à partir de documents, conversations, mails, articles, posts… (données non structurées).

Document et donnée sont deux choses différentes (en richesse, en usage, en finalité, en structure de contenu et métadonnées). Et un document contient des données.
L’IA vient d’automatiser la relation via sa capacité d’extraction.

Au final, les données structurées doivent être contextualisées, les données extraites ont comme source un document (métadonnées), qui forme le contexte et qui lui-même doit être contextualisé.

Le cycle de vie des données, des documents et de leurs relations doivent être sous gouvernance.

Source : https://tdan.com/a-step-ahead-from-acts-to-aggregates-record-ness-and-data-ness-in-practice/32851

Quatre façons de comprendre la stratégie de données et d’IA de toute organisation au travers de l’idée de produits de données

Les quatre façons et les actions stratégiques (NB : plutôt tactiques, la stratégie est plutôt comment arbitrer entre ces situations) :

• Produits de données disponibles : mais à rationnaliser (couteux, peu utilisés…)
• Produits de données présentant des défis : introduire de l’observabilité, consolider
• Produits de données en vue : capacité et expertise, passage à l’échelle
• Produits de données non en vue : il faut aller les chercher (innovation)

NB : à faire le lien avec l’idée de portefeuille d’initiatives data. Et par exemple y introduire l’exploitation de l’existant, retirer ou consolider des produits de données.

Source : https://medium.com/@mustafaisonline/four-ways-to-understand-any-organizations-data-ai-strategy-35399088473c

Les contrats de données ne fonctionnent pas. Voici comment y remédier

Les contrats de données fonctionnent en théorie, mais pas en pratique.
La raison, tout simplement, si on reste au niveau de documents c’est mort (obsolescence, non pilotable, drift, absence de feedback usage, perte de confiance).
Un contrats de données doit être implémenté, actif dans les interfaces, flux.

« Les contrats statiques ne peuvent pas suivre le rythme des systèmes dynamiques, d’autant plus que l’IA s’intègre de plus en plus profondément dans la pile de données moderne. »

E l’IA a besoin du contexte fournit par les contrats de données.

NB : et un contrat est composé de métadonnées… actives.

Exemple d’aléas normaux dans la vie des données dans un S.I. :

• La logique de catégorisation a changé le mois dernier.
• Certaines catégories sont obsolètes.
• Les données de tel dataset ont vu leur schéma évoluer.

Source : https://medium.com/@salmabakouk/data-contracts-dont-work-here-s-how-we-fix-that-be7cd9335b9e

Leçons du Big Data à l’IA

Analogies Big data et IA :
A l’époque, si vous ne faisiez pas du big data vous étiez en danger (climat de peur).
La technologie conteneur (Hadoop) prime sur le contenu (les données).
Les big data ou data lake marécages par négligence des métadonnées
Des données pas prêtes à être sorties de leur environnement pour intégrer un environnement central.

Tout cela s’applique à l’actualité de l’IA.

Source : https://www.bigdatawire.com/2025/08/12/this-big-data-lesson-applies-to-ai/

Et aussi – Une étude révèle deux facteurs humains à l’origine du succès du Big Data

En synthèse (porte ouverte), la technologie, le solutionnisme big data  ne servent à rien s’ils ne sont pas associées à deux facteurs humains : des talents qualifiés et une gestion efficace des connaissances. Tout dépendent de la manière dont les données sont exploitées.

Les auteurs mettent en avant : « la capacité d’analyse du Big Data (BDAC), qui reflète la qualité de la collecte, de l’analyse et de l’exploitation des données par une organisation ; La gestion des connaissances (GC), qui détermine la manière dont les informations sont partagées et intégrées au sein des équipes, et la capacité des talents en analyse du Big Data (BDATC), qui mesure le niveau de compétence des personnes à transformer les données en actions. »

NB : retour du knowledge management (collecter les information, référencer, faire circuler les connaissances à partir des données, les intégrer au quotidien).

Et cela repose sur des talents qui savent dépasser l’aspect technologique.

Source : https://www.bigdatawire.com/2025/07/07/study-reveals-two-human-factors-behind-big-data-success/

Loi de Conway, silos, cloud et modélisation des données … théorie et réalité

Les silos sont omniprésents (la loi de Conway est passée par là).

Il faut jouer avec la loi dans l’exercice de modélisation.

Certain s’y essaie avec l’idée loi de Conway inversée : cela signifie concevoir intentionnellement la structure de leurs équipes pour obtenir l’architecture système souhaitée.

En fin de compte, une des bases de la modélisation est de rendre des modèles indépendants de l’organisation (et ou le couplage avec l’organisation est maîtrisé) – règle de base que l’on apprend en modélisation de données.

Source : https://practicaldatamodeling.substack.com/p/conways-law-and-data-modeling

Les silos sont-ils toujours néfastes ?

Dans la suite de l’article précédent.

Les silos sont naturels.

Ils sont une richesse locale (expertise, connaissance du contexte).

Les silos deviennent dangereux et acquièrent leur réputation bien méritée lorsqu’ils deviennent rigides, isolés et protectionnistes voire avec des redondances.

Les silos ne sont pas systématiquement à briser.

Ils sont à fédérer sous surveillance d’une gouvernance qui évitera leurs défauts. Source : https://practicaldatamodeling.substack.com/p/are-silos-always-a-bad-thing

Modélisation des données – Théorie vs réalité

La modélisation de données est un exercice de patience : nous n’avons pas le temps.
La modélisation de données est un exercice de recul, d’abstraction : éloigné du quotidien et de l’action urgente à traiter
La modélisation de données est un exercice d’expert (perfection), de tour d’ivoire : éloigné de la complexité, de l’incertitude récurrente, de la réalité du terrain.
La modélisation de données se limite à rétro modéliser un existant dont on a perdu le sens, la documentation des données. Dans l’urgence pour répondre à un problème immédiat de fonctionnement, d’évolution.
La modélisation est politique, reflet de jeu d’influence (priorité, définition, éléments à ignorer).
Avec toujours l’exemple bien connu, de la définition de ce qu’est un client qui va dégrader les primes des commerciaux.
La modélisation est un sujet technique (modèle relationnel, vectoriel, en étoile, vault…) : la modélisation n’est d’abord pas du tout technique (revoir pour cela la logique de formalisation d’une expression de besoin, d’une modélisation).

Il faut démontrer l’importance de la modélisation.

Source : https://practicaldatamodeling.substack.com/p/data-modeling-theory-vs-reality

La modélisation de données contrainte par le cloud

NB : l’auteur oublie, la dérivation entre modèles et la distinction utile, de modélisation conceptuelle, logique et physique (là où l’aspect cloud prend toute sa mesure).
Effectivement le cloud change la donne dans l’implémentation en termes de montée en charge, de résilience (redondance, disponibilité), gestion financière (couts de stockage), de sécurité, de multi-cloud, de testabilité, de maintien en cohérence les données
Aspects à décliner à partir de la modélisation conceptuelle, puis de la modélisation logique (exemple gestion de microservices, événementielle).
Avec les choix d’optimisation des implémentations en fonction des usages : base vectorielle, base transactionnelle, base graphe, base temporelle…
Source : https://medium.com/@sohail_saifi/why-everything-you-learned-about-data-modeling-is-wrong-in-the-cloud-era-8a20c3243b76

Quand les agents IA s’invitent dans les tâches de traitement des données

Les agents dans l’assistance aux développements des traitements au sein des architectures de données (intégration par exemple).
Les agents dans l’appui au cycle de vie des travaux de data science (exploration, choix de modèles…).
Et pour boucler la boucle, les agents pour assister au développement d’agents finaux dédiés aux utilisateurs des données.

Source : https://www.bigdatawire.com/2025/08/07/google-pushes-ai-agents-into-everyday-data-tasks/

Les vérités dérangeantes de l’analyse en libre-service

On a vendu très vite avec l’arrivée du big data l’idée d’analyse self service.
Le résultat est on ne peut plus mitigé.
Le pour, des métiers ont recruté des experts data et cela leur a permis une bonne forme d’autonomie.
Le contre, les métiers n’ont pas le temps, la totale expertise pour gérer par eux-mêmes la création d’indicateurs et tableaux de bord, de configurer des filtres. C’est une charge supplémentaire.
L’auteur va plus loin en disant « L’analyse en libre-service est une arnaque. Un mythe. Le soi-disant Saint-Graal. »
Et termine avec la remarque suivante : « Excel reste roi. Qu’on le veuille ou non, le seul outil d’analyse en libre-service véritablement universel est le tableur. »

Source : https://seattledataguy.substack.com/p/the-inconvenient-truths-of-self-service

Le problème des trois corps des données : pourquoi l’analytique, les décisions et les opérations ne s’alignent jamais

Pourquoi tant d’indicateurs, insights, tableaux de bord inutilisés, inutiles, « à côté », gaspillés ?
Les données sont bonnes, le tableau de bord est opérationnel, mais l’action ne suit pas.
Il y aurait un problème de rythme. Trois monde parallèles, qui collectent, traitent et exploitent les données de manières totalement différentes. Ils n’ont pas tort. Ils sont simplement mal alignés. Et sans rythme commun, le système bégaie.
Le premier monde est l’analytique. Il montre ce qu’il s’est passé mais ne retourne pas dans l’opérationnel (ou alors par la grâce de fichiers excel de données récupérées ou de posts it plein de données et collés par chacun pour guider son quotidien).

Le deuxième monde est la décision ou la prédiction (savoir qu’un stock va être en rupture). Mais les systèmes qui le porte ne peuvent pas passer une commande.

Le troisième monde est celui de l’opérationnel (emblématiquement porté par des ERP). Ancré dans le quotidien, le process.

« Ensemble, ces trois mondes constituent la pile de données complète d’une entreprise. Mais sans passerelle ni couche commune pour traduire et agir, chaque monde devient un silo. Le tableau de bord sait. Le modèle devine. L’équipe opérationnelle improvise. Et l’entreprise avance, désynchronisée. »
L’enjeu est de synchroniser ces trois mondes en contexte.
La réalité est là. Excel reste le roi de la synchronisation de ces mondes.
Avec Excel vous êtes aux commandes (voir l’article précédent) au croisement des mondes.

C’est là que les data platforms et les agents IA entrent en jeu. En cherchant à apporter la vision croisée des données et en faisant le lien entre les trois monde.
Ces systèmes agissent. Et cela pousse l’automatisation un cran plus loin (ils appuient sur le bouton !).
L’article présente le cas de la monétique. Si un taux de terminaux de point de vente sont soudainement indisponibles toute une chaîne d’intervention (analyse, décision, action) se déclenche souvent manuellement.

Les agents sauront-ils connecter les trois mondes, se passer d’intervention humaine ?

NB (remarques de lecture) :

• On retrouve le vieux débat de la séparation des systèmes entre le décisionnel (pilotage) et l’opérationnel.
• Modération : l’analytique est là pour comprendre et ne va pas déboucher immédiatement vers une action ou décision.
• La connexion des trois mondes, pousse plus loin la formalisation de processus. Le risque est la rigidification liée à l’automatisation de la connexion. Un processus a besoin de joint de dilatation. Les experts en supply chain connaissent bien le sujet.

Et dans la même idée – l’article https://medium.productcoalition.com/data-without-structure-is-just-noise-a42bd6dbd378. Ne pas se contenter de livrer des données (fournisseur passif) mais intervenir dans la réflexion métier (fournisseur actif). Expliquez le lien entre les données et les enjeux métier.

Source : https://medium.com/@community_md101/the-three-body-problem-of-data-why-analytics-decisions-ops-never-align-5b428763b33c

Et en lien : Comment échapper au piège des demandes de données ponctuelles

Sujet quotidien des équipes de données, des managers sur sollicités ou sur sollicitant face à un flot de demandes de données.

L’article revient sur l’état d’esprit d’un ancien directeur analytique.
Comment briser le flot de demandes ?

L’idée passer une partie des demandes d’un mode réactif (sans contrôle de valeur) à un mode proactif (être à l’initiative avec maîtrise de la valeur).
Comment ?
La réponse, l’éternel retour à se préoccuper des enjeux métier, d’entreprise et pas seulement des demandeurs.

NB : où et comment a-t-on perdu ce bon sens que toute programmation, définition de données doit être alignée avec des enjeux métier ? Un programmeur est un analyste-programmeur…

Source : https://seattledataguy.substack.com/p/how-to-escape-the-ad-hoc-data-request

Data Mesh : Réalités des premiers utilisateurs

La cible est motivante.
La question : comment la construire tout en continuant de voler, comment concilier le quotidien, les exigences à court terme et la cible à long terme.
Les points à clarifier :

• La définition de ce que sont les data products (dataset, tableau de bord, des données brutes, un cube décisionnel, selon quelle modélisation…).
• Définir les domaines de données n’est pas aussi simple que de tracer des lignes sur un organigramme. Il faut gérer des responsabilités qui se chevauchent, des capacités métier en constante évolution et des systèmes hérités qui ne correspondent pas parfaitement aux équipes actuelles
  La transversalité, la fédération sont difficiles (comment aligner, accorder tout le monde).

Source : https://towardsdatascience.com/data-mesh-diaries-realities-from-early-adopters/

Le Bon, la Brute et le Truand : Data Mesh

Le data mesh, comme remède aux défauts de la centralisation (voir les arguments et l’exemple en introduction de l’article et l’exemple cité).
Malheureusement ce n’est pas forcément le cas.
L’autonomie, responsabilisation, expertise des domaines ne suffit pas. Il faut accorder et orchestrer les domaines.
« L’équipe financière a qualifié un client d’« actif » après un seul achat ; le marketing en a exigé trois. Les tableaux de bord ont commencé à se contredire. Les discussions sur la définition de l’« achat » ont été interminables. S’agit-il d’un abonnement ? Postpayé (facture) ? Prépayé ? Quelle est la différence entre un abonnement et un prépayé ? Peut-on considérer les deux comme une facturation récurrente ? Si oui, comment appellerons-nous les paiements du contrat postpayé de deux ans ? »
NB : vécu aussi n fois, la définition de ce qu’est un client entre le marketing, les commerciaux, la comptabilité, les risques …avec chacun ses enjeux (communication, primes, réglementaire…).
La solution une vision (modèle) des données pensées en tenant compte de cela (exemple en s’appuyant sur la notion de rôles).

Accorder et orchestrer, cela concerne aussi, les plates-formes techniques, la gestion des tests dont trans domaines…
Et ne pas laisser de côté l’ancienne équipe de l’entrepôt qui s’est sentie remplacée.
Décentraliser, orchestrer joue avec les zones de confort des utilisateurs et crée généralement des zones d’inconfort.
Et tout cela a un cout qui peut laisser un directeur financier perplexe (où sont les résultats ?).

Source : https://canartuc.medium.com/the-good-bad-and-ugly-data-mesh-8f7fa35f133b

Les données écartelées entre : le partage et la protection face aux violations de données

Il existe des mécanismes de partage de données tout en permettant leur protection.
C’est technique et analytique, cela a un coût.
NB : voir l’exemple en France sur les données statistiques du CASD – https://www.casd.eu/

Pas une journée sans une annonce de violation de données.
La confiance s’effrite.
Mais on partage de plus en plus de données (par exemple au sein d’écosystèmes de partenaires, fournisseurs, clients de plusieurs centaines de membres) et le risque de violation croît (multiplication des points de vulnérabilité).
Le partage est remis en cause ou ses risques sont ignorés.
Il faudrait éliminer le transfert et le stockage externe de données tout en collaborant.

L’idée : une double approche technologique et analyse de la valeur.
Technologique avec les privacy enhancing technologies (PETs) : Secure multi-party computation (SMPC), Federated learning, Homomorphic encryption, Trusted execution environments (TEEs), data clean rooms.
Et analyse de la valeur avec l’idée de penser la manière dont on diffuse la valeur des données.

Source : https://www.weforum.org/stories/2025/08/to-end-the-data-breach-epidemic-do-we-need-to-rethink-data-sharing/

Qu’est-ce que l’analyse de données multimodales ? intermodale

Les approches traditionnelles basées sur des données monomodales négligent souvent des informations importantes issues des relations intermodales. L’analyse multimodale rassemble diverses sources de données, telles que du texte, des images, de l’audio et d’autres données similaires, pour offrir une vision plus complète d’un problème.
L’article présente une démarche et son implémentation, avec en particulier le choix de la stratégie de fusion.

1. Stratégie de fusion précoce : combine toutes les données de différentes sources et de différents types au niveau des caractéristiques avant le début du traitement
2. Méthodologie de fusion tardive : au lieu de combiner toutes les sources de données, elle traite toutes les modalités indépendamment, puis les combine juste avant que le modèle ne prenne des décisions
3. Approches de fusion intermédiaires : équilibrage les avantages de deux démarches précédentes en fonction des modalités
   L’intégration est le problème n°1 en informatique. Et l’intégration multimodale rajoute une nouvelle difficulté à cette intégration (de données issues de multiples modalités, spécifiques, hétérogènes sur différentes dimensions au sein d’un même modèle).

Source : https://www.analyticsvidhya.com/blog/2025/07/what-is-multi-modal-data-analysis/

Le défi de la multimodalité

Le sujet de la multimodalité est de plus en plus important du fait de la multiplication des sources de données pour un même sujet.
L’article, décrit de façon approfondie et un cadre de travail sur le sujet de la reconnaissance des émotions de façon dynamique à partir de vidéos, de reconnaissance de comportements, de dialogues, de voix, d’écrits.

La multimodalité soulève plusieurs défis :

• Désalignement des modalités : Les variations dans les taux, la granularité et les sources de capture des données compliquent la fusion,
• Déséquilibre des données : La sous-représentation de certaines sources, émotions conduit à des prédictions biaisées,
• …

Source : https://journalofbigdata.springeropen.com/articles/10.1186/s40537-025-01264-w

Toujours le choc du DOGE dans l’usage des données, ou comment tout ce que vous avez appris sur les données peut être remis en cause du jour au lendemain

Déjà évoqué dans les revues précédentes.

Les nombreux articles de l’été dans ce sens :
https://www.nytimes.com/2025/08/07/us/politics/trump-schools-race-data.html
https://www.reuters.com/world/us/easy-lose-hard-restore-us-data-trust-line-2025-08-05/
https://www.npr.org/2025/08/08/nx-s1-5495338/climate-change-environment-websites-trump
https://techcrunch.com/2025/08/26/doge-uploaded-live-copy-of-social-security-database-to-vulnerable-cloud-server-says-whistleblower/
https://www.numerama.com/cyberguerre/2060643-les-americains-risquent-de-se-souvenir-longtemps-du-doge-delon-musk-et-pas-pour-de-bonnes-raisons.html
https://flowingdata.com/2025/07/10/doge-goes-for-farmers-financial-and-personal-data/
https://www.latimes.com/world-nation/story/2025-07-13/trump-says-he-wants-to-deport-the-worst-of-the-worst-government-data-tells-another-story
https://www.nbcnews.com/politics/donald-trump/trump-reshaping-government-data-rcna222900

Avec en conséquence de fond … le problème structurel de la confiance.
« La principale leçon à tirer des exemples passés de perte de confiance dans les données est qu’il peut falloir des années pour que la confiance soit rétablie. »
A savoir même un jour que la confiance deviendra inutile. La tendance est plutôt à une bascule des données en (relative) confiance aux données en autoritarisme.
D. Trump a licencié la responsable des statistiques de l’emploi aux U.S. parce que les chiffres ne lui plaisaient pas – https://qz.com/trump-bureau-labor-statistics-erika-mcentarfer-fired-warning

Source : https://www.reuters.com/world/us/easy-lose-hard-restore-us-data-trust-line-2025-08-05/

Le danger caché de la souveraineté des données

L’article analyse la gouvernance des données humanitaires à travers le prisme de la souveraineté.

Avec des cas de mise en danger – exemple de données humanitaires au Yémen – Zones Houthi

– Les rebelles ont exigé le contrôle des données biométriques des bénéficiaires des actions humanitaires.

– Le Programme alimentaire mondial (PAM) a d’abord refusé puis accepté un compromis : serveurs locaux sous contrôle Houthi.

-> Reconnaissance implicite d’une « souveraineté de facto » d’un acteur non étatique.

Au Kenya, les données humanitaires ont servi à exclure des droits de citoyenneté.

Les données sont au centre de luttes de pouvoir entre États, organisations internationales, acteurs privés et populations concernées.

Source : https://journals.sagepub.com/doi/abs/10.1177/20539517251361109?ai=2b4&mi=ehikzz&af=R

Les bonnes et mauvaises équipes de données

Partout des équipes de données sont mises en place.
Mais leur rôle, fonction, place dans la gouvernance, adhérence avec le reste de l’organisation, dont leur connexion / déconnexion si changement de direction dans la stratégie d’entreprise, voire leur utilité sont peu précisés.
Plusieurs articles reviennent sur ce sujet.

Exemple de défaut :
« La plupart des équipes data utilisent un modèle de centre de services qui optimise la rapidité de traitement des tickets et la satisfaction des parties prenantes, et non l’impact sur l’entreprise. Trois dysfonctionnements cachés alimentent le problème : la réflexion axée sur les solutions, la pureté technique au détriment du pragmatisme, et l’isolation des conséquences. »
La préconisation : « Mesurez votre travail à l’aune de la mise en œuvre des décisions et des résultats commerciaux ; soyez prêt à décevoir certaines parties prenantes pour servir la stratégie de l’entreprise. »
« Le vrai problème : nous optimisions la satisfaction des parties prenantes plutôt que l’impact commercial. Chaque demande semblait tout aussi valable, car nous n’avions aucun cadre pour distinguer les attentes des besoins de l’entreprise ».
L’éternel conseil clé : passer le maximum de temps à comprendre l’entreprise et ses besoins.
« Au début, privilégiez la découverte. Interrogez les principales parties prenantes, identifiez leurs objectifs et identifiez celles qui s’alignent sur les objectifs commerciaux plus larges et qui sont intéressées par un partenariat. »
Trouver les bons projets (d’où l’importance de la gestion d’un portefeuille d’initiatives data).

L’article https://svenbalnojan.medium.com/whats-wrong-with-data-teams-d67c808ea020 raconte plusieurs retours d’expérience illustratifs.

Vécu (et aussi pour ma part) : « J’ai vu de brillants data scientists chez Unite passer six mois à créer des modèles d’ensemble pour prédire la valeur vie client avec une précision de 87 %. Le travail était vraiment impressionnant : un code propre, une validation rigoureuse, le genre de projet qui brillerait dans un portfolio universitaire.

Il n’a influencé aucune décision commerciale.

Pendant ce temps, l’équipe commerciale attribuait les territoires à l’aide de formules Excel et d’intuition. »

Des équipes « à côté , rattachées à des directeurs techniques ou à des directeurs des données, et non à des dirigeants dont elles sont censées influencer les décisions.

Et en conclusion : « Le dysfonctionnement ne réside pas dans le manque de sophistication des équipes data, mais dans le fait que nous avons confondu sophistication et impact. Tant que nous n’aurons pas corrigé ce décalage fondamental, nous continuerons à construire de magnifiques systèmes que personne n’utilise, tout en nous demandant pourquoi les organisations prennent encore des décisions basées sur l’intuition et Excel. ».

Sources :
https://svenbalnojan.medium.com/whats-wrong-with-data-teams-d67c808ea020
https://seattledataguy.substack.com/p/the-first-data-hire-series-how-to
https://svenbalnojan.medium.com/why-internal-data-teams-build-the-wrong-things-8ff5d3129a9d

Tout est dans les données : D’où viennent les bonnes données ou enfin mettre en lumière les producteurs de données

« Commençons par une vérité que trop de gens oublient encore : toutes les données ne sont pas bonnes. Ce n’est pas parce qu’une donnée est stockée dans une base de données ou un tableur qu’elle est exacte, fiable ou utile. À l’ère de l’IA et de l’analyse avancée, nous nous sommes en quelque sorte convaincus que les données – n’importe quelle donnée – peuvent être automatiquement transformées en informations. »

« Le problème, c’est que nous avons passé des décennies à prétendre que la qualité des données était un problème technique, alors qu’il s’agit en réalité d’un problème humain. Les données sont créées, interprétées et (espérons-le) exploitées par des personnes. Ainsi, si ces personnes ne sont pas alignées, formellement responsables, ou même conscientes de l’importance de leur rôle dans la transformation des données, vous vous retrouverez avec quelque chose qui ressemble à des données, mais qui s’apparente davantage à du sabotage. ».

« Les bonnes données proviennent du travail quotidien, et non d’une usine à données mythique fonctionnant dans le cloud. Elles naissent des processus d’intégration des clients, de suivi des stocks, de gestion des finances et de réponse aux e-mails. Elles sont produites par les commerciaux, les comptables, les techniciens terrain, les marketeurs et, oui, parfois même par le service informatique. Chaque clic, saisie ou exportation peut soit améliorer la qualité de nos données, soit semer le chaos. Et trop souvent, c’est le chaos. Pourquoi ? Parce qu’il n’existe aucune responsabilité formelle pour garantir la qualité des données. Personne ne dit à Bob, de la comptabilité, que ses identifiants clients incohérents vont ruiner un modèle prédictif dans six mois. C’est pourquoi la gouvernance, surtout non invasive, est si importante. Elle ne met pas Bob sous le tapis. Elle lui montre comment la piloter. ».

« Une gouvernance des données agit en coulisses, connectant les individus aux données qui les produisent et manipulent et les aidant à mieux les gérer ».

Et quand la qualité des données s’étend à la qualité de leur contextualisation.
« Les modèles d’IA ne sont pas des magiciens ; ils ne peuvent pas transformer des données erronées, biaisées ou incomplètes en décisions commerciales judicieuses. Ils peuvent simplement amplifier chaque problème caché dans votre ensemble de données. … Ils ont besoins de données contextualisées… ».
Source : https://tdan.com/all-in-the-data-where-good-data-comes-from/32821

Les données professionnelles : la prochaine frontière de la GenAI

Article à lire, quand les documents, mails, posts internes, backlogs, réponses aux clients, fournisseurs… que vous produisez sont les futures sources des IA génératives d’entreprise.
Quelques extraits :
« Les données professionnelles, c’est-à-dire le travail des travailleurs du savoir, constituent la source de données la plus précieuse pour la formation en LLM…Dans cet article, je présenterai neuf arguments à l’appui de cette affirmation. Je m’interrogerai ensuite sur le conflit d’intérêts actuel entre les propriétaires de données professionnelles et les entreprises d’IA souhaitant s’entraîner sur ces données. J’aborderai ensuite les solutions possibles et un scénario gagnant-gagnant. »
« Les données professionnelles sont évidemment de bien meilleure qualité que notre contenu Internet public. » … « Les données de travail sont souvent explicitement étiquetées. » (contextualisées).
Avec trois points d’attention : « Certaines entreprises sont particulièrement bien placées pour exploiter les données professionnelles : Microsoft, Google et d’autres fournisseurs de logiciels professionnels génériques (mail, documents, feuilles de calcul, messages, etc.) ont accès à d’énormes quantités de données professionnelles. »
Et « Ces données constituent le travail rémunéré de quelqu’un : utiliser ces œuvres pour générer des profits pour un tiers est probablement qualifié de travail non rémunéré ou d’exploitation du travail. ». … que disent les contrats de travail ?
Et le sujet du secret industriel versus formation des IA.

NB : cette réflexion peut s’appliquer aussi à nos données comportementales, graal de l’apprentissage des moteurs d’IA. Il suffit de lire les dernières versions des conditions générales de toutes les apps que nous utilisons quotidiennement.
Source : https://towardsdatascience.com/work-data-is-the-next-frontier-for-genai/

L’interopérabilité des données est un sujet politique

L’article analyse le projet d’interopérabilité (IP) de l’Union européenne, qui vise à connecter et rendre interopérables les grandes bases de données européennes en matière de migration, contrôle des frontières et sécurité.
But officiel : améliorer la sécurité intérieure de l’UE en facilitant l’échange d’informations entre systèmes existants (Eurodac, VIS, SIS, etc.) et à venir (EES, ETIAS, etc.), tout en élargissant l’accès des forces de l’ordre aux données migratoires.
Dimension coloniale et extractiviste : l’IP est qualifié de « colonialisme des données », car il collecte et exploite massivement les données de ressortissants de pays tiers, souvent issus d’anciennes colonies, sans véritable contre-pouvoir démocratique
Source : https://journals.sagepub.com/doi/full/10.1177/20539517251359227

A lire aussi (data et sport, DAMA DMBoK deux critiques, Data workers, Data platform, gouvernance des données scientifiques)

Sport et data : Mesure et démesure du sport connecté – Par Guillaume Dietsch
https://aoc.media/analyse/2025/04/24/mesure-et-demesure-du-sport-connecte/

DAMA – DMBoK : deux critiques

• Sur la prise en compte de l’idée de data product : https://medium.com/@dr.jarkko.moilanen/why-dama-and-dcam-dont-work-for-data-product-governance-eed592555e82
• Sur le fait que le DMBoK se concentre sur une vision statique des données (les données au repose) versus une vision dynamique (les données en mouvement) : https://tdan.com/thoughts-on-the-dama-dmbok/32743

Data workers : toujours l’analyse brillante de Antonio Casilli : Derrière l’IA : La Vérité qui dérange sur les Data Workers – https://www.youtube.com/watch?v=z_J_RNXaxbU

Data platform … j’ai aimé – Anyone Else Struggling to Keep Up With Data Tools- https://seattledataguy.substack.com/p/anyone-else-struggling-to-keep-up
« Tel Sisyphe, on pourrait passer chaque jour à pousser le rocher des nouvelles technologies vers le haut de la colline, pour le voir retomber en bas.

On pourrait ne travailler que sur Snowflake ou Databricks, et en vingt ans, n’avoir jamais touché à l’autre. Bon, c’est peut-être improbable, vu la façon dont certaines entreprises organisent leurs piles de données. Pourtant, même les plus petites entreprises trouvent le moyen d’utiliser les deux. Probablement un développement classique piloté par les fournisseurs.

Les outils changeront, les fondamentaux, eux, resteront.
…
C’est pourquoi, peu importe le nombre de tentatives pour supprimer SQL, il persiste, qu’on le déteste ou qu’on l’adore. »

Pour ceux qui s’intéressent à la gouvernance des données scientifiques (mais applicable plus généralement)– Research Lifecycle Management: Using Analysis Reproducibility Research Software to Define Contextual Data Governance Policies : https://hdsr.mitpress.mit.edu/pub/ulfgjwy1/release/1

---

RDV maintenant en octobre pour la revue et les actualités de septembre.

---