Dernière modification le 20 avril 2026
Ce mois toujours les sujets récurrents : data platform et data architecture (et le sujet du passage à l’échelle), les données comme armes, data et IA (cas des données tabulaires), les données d’identité, prix des données, ouverture des données
Le graal de la contextualisation des données au centre des discussions avec beaucoup de commentaires et d’articles.
Le retour des bons principes de génie logiciel pour coder et qualifier les données (merci à l’IA de les remettre en avant).
Et 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 :
- Data platform – architectures de données
- Données et contextualisation
- Le prix des données
- Ouvrir, mutualiser les données pour améliorer la science
- Les données comme armes
- Données tabulaire et IA
- Data et IA
- Suite sur les données d’identité
- Actualité (Designing Data Intensive Applications, Sécuriser les données dès le hardware, Collecte de données – Reddit, Données et alignement business, La distinction entre le bruit et le signal, Etude sur les travailleurs des données)
Data platform – architectures de données
1) Les défaillances (classiques) de projets de data platforms.
- Traiter la plateforme comme un projet technologique, et non comme un projet business
- Ignorer la gouvernance des données (et son implémentation opérationnelle)
- Intégrer (à l’arrache) tous les systèmes sources
- Mauvaise interprétation et implémentation de l’architecture médaillon (négligence du process de passage, des niveaux de qualité)
- Sous-estimer la gestion du changement et la culture des données (éternelle défaillance).
Les préconisations :
- Focus par domaine – logique Domain Driven Design
- Gouvernance by design
- Process de promotion des données explicite (de bronze à gold)
- Penser data products
Et lisibilité, simplicité – couche par couche, nous avons construit des systèmes de données que personne ne comprend.
2) On n’arrête pas de déplacer les données.
Le résultat est un chaos, une charge élevée d’intégration, de supervision, de contrôle.
Avec des risques élevés : de confiance, de faille.
Tous les ingénieurs de données sont à la recherche du graal de la solution ultime : pipelines observés et supervisés, data virtualisation, zéro ETL, CDC, métadonnées centric, ne plus déplacer les données mais les traitements vers les données (data centrisme)…
L’article explore la conception d’une plate-forme dédié aux mouvements des données (data hub revisité à l’ère « moderne ») – au sein de la communauté https://datadeveloperplatform.org/
3) L’ETL est mort et tout repose sur l’architecture de contexte.
Et dans la suite du déplacement des données. A voir la nième annonce de la fin des ETL. Parce ce que le contexte est devenu important.
Avec par exemple les efforts d’accompagner le déplacement des données avec leur contexte : Même des initiatives récentes comme l’ Open Semantic Interchange de Snowflake reconnaissent ce fossé : le secteur ne tente que maintenant de normaliser la façon dont le sens sémantique circule entre les outils.
Source : https://www.dataengineeringweekly.com/p/etl-is-dead
4) Les problèmes data qui n’apparaissent qu’à l’échelle.
Sujet important.
Il est facile d’illustrer des avancées data sur un exemple, un cas, un POC. Là où on n’a peu besoin de réflexion d’architecture S.I. (separation of concern), d’entreprise, de gouvernance.
Par contre, le passage à l’échelle : industrialisation, fonctionnement et cohérence d’ensemble, dans la durée amène des contraintes à lever.
Les sujets classiques de passage à l’échelle :
- la multiplication des pipelines, le plat de spaghetti, les dépendances à gérer
- l’évolutivité dans le temps : rythme, volume
- la capacité d’observabilité (à l’échelle d’un pipeline elle peut être traitée localement simplement, à l’échelle d’un S.I. elle a un cout non négligeable – idée de système de système)
- la capacité à construire et maintenir une architecture performante, évolutive, résiliente…
Source : https://aws.plainenglish.io/5-data-engineering-problems-that-only-appear-at-scale-a918a09f780f
5) Les données ne sont pas fiables.
Un sentiment, continu, diffus et persistant même avec une infrastructure de données de haute volée.
Le problème n’est pas technique.
Mais à un manque de compréhension de ce que sont réellement les données (ce n’est pas comme de l’électricité, elles ne sont pas neutres, elles dépendent d’un contexte, leur qualité dépend de l’usage…).
6) La solution Dataplex de Google pour résoudre l’accès aux données, sans les déplacer et de façon gouvernée.
« Dataplex est la plateforme de gouvernance des données unifiée de Google Cloud qui permet d’organiser les données distribuées sur plusieurs systèmes de stockage. Elle offre une gestion centralisée des données, une validation automatisée de leur qualité et une découverte intelligente, le tout sans déplacer ni dupliquer vos données. ».
Dont le rôle clé des métadonnées :
- « Métadonnées métier : Informations fournissant un contexte métier, telles que la classification des données.
- Métadonnées techniques : Détails techniques concernant la ressource de données, par exemple son schéma.
- Métadonnées dérivées des données : Informations générées à partir des données elles-mêmes, telles que les statistiques d’une table BigQuery. »
Données et contextualisation
1) Mémoire des agents. Comparaison entre l’approche Palantir et Microsoft.
Quand la couche sémantique ne suffit pas.
La pression réglementaire sur les systèmes d’IA demande de l’explicabilité, de la contextualisation : loi européenne sur l’IA (avril), directive de la réserve fédérale américaine sur les risques des modèles de conformité basé sur l’IA, GAFI.
Comment doter les agents IA d’une mémoire explicable.
Les approches Palantir et Microsoft sont actuellement insuffisantes.
L’exemple du graphe temporel : savoir ce que connaissait l’agent IA au moment de sa « décision ».
L’article fini par une présentation d’une mise en œuvre d’agents à mémoire.
2) La catégorisation des données comme part importante de leur modélisation sémantique. Et structure pour le bon traitement des données par l’IA.
NB : rejoint les bonnes pratiques de conception de nomenclatures (en terme de granularité, d’inter-cohérence, de recouvrement, de portée, etc).
Et rappel : catégoriser est une forme de pouvoir.
3) Reproduire le besoin d’accès aux données et de connaissance du contexte métier (comprendre comment l’information circule, où les décisions sont prises et quels résultats comptent) par les humains pour les agents IA.
Le projet Frontier d’OpenAI.
OpenAI l’a vécu en interne. Avec des performances améliorées par l’exploitation de six couches de contexte autour des données : modèles d’utilisation des tables, annotations humaines, analyse du code, connaissances institutionnelles, mémoire et validation en temps réel.
Une nouvelle gouvernance : la gouvernance du contexte !
Quelle part de contexte prendre en compte ? Comment l’intégrer ? Quels arbitrages en cas de conflit, de définitions différentes ? Le contexte un nouvel actif de l’entreprise – à protéger, développer.
Le contexte est intrinsèquement distribué (voir le mythe de la vue unifiée des données) : traçabilité des pipelines, propriété des catalogues, interactions clients issues des systèmes CRM, historique des incidents provenant des plateformes de support, retours de la direction via Slack, etc.
Le problème : chacun son contexte ou le chaos contextuel, des silos contextuels.
Le retour sans fin du sujet bien connu en architecture : la brique d’unification rêvée qui finalement ne fait que reproduire en son sein le plats de spaghetti – le chaos qu’elle est censée éliminer (rappel historique des systèmes hub data obèses, de data swamp…).
On a besoin d’architecte de l’hétérogénéité … ce qu’on appelait des architectes d’entreprises à une époque (d’ailleurs la couche business context d’OpenAI évoque la couche business des démarches d’architecture d’entreprise).
Et le risque de dépendance vis-à-vis des fournisseurs technologiques s’accroit, en leur confiant la représentation de votre contexte (la connaissance et la mémoire institutionnelle de votre business – voir l’exemple Palantir).
Source : https://metadataweekly.substack.com/p/openais-frontier-proves-context-matters
4) Décisions pour la couche sémantique
Un long article illustré sur les décisions à prendre pour construire une couche sémantique.
– Le niveau de granularité représenté (et la capacité de drill down – cf. la BI) : une commande client, lignes de commande, commandes journalières..
« La question essentielle est la suivante : à quel niveau se produit l’événement que nous souhaitons précisément mesurer ? »
– La prise en charge de l’évolution de la logique métier (règles), des données et des métriques (versionning). Avec le sujet des ruptures bien connu en statistiques.
– L’intégration des données et métriques dans des graphes de dépendances (et aussi voir l’idée d’arbre de métrologie d’entreprise).
– Quelle logique de représentation du temps adoptée – définition d’un cadre temporel signifiant et commun pour l’entreprise et ses activités. L’un des sujets les plus délicats (concerne : les séries temporelle, l’historisation, les dates d’événement, d’effet, les calendriers…) … avec l’analyse dans le temps, l’extrapolation et rétropolation …(avec le sujet délicat de reconstituer un contexte passé).
– La prise en charge de la résolution des identités (cas classique l’identité d’un client vue différemment dans N systèmes ERP, CRM, back office…)
Et le tout sous une gouvernance explicite : qui a le droit de modifier la couche sémantique ?
5) Quand on ne peut pas tout mettre sous forme de données, même accompagnées de leur meilleur contexte.
Extrait : « Pour mémoire, dans les années 2000, la NASA a reconnu qu’elle ne pouvait pas simplement « refaire Apollo » non faute de plans, mais parce que les compétences opérationnelles et industrielles s’étaient dispersées avec les départs à la retraite. Les documents étaient là mais la capacité collective ne l’était plus. (Why We Can’t Return to the Moon: The Need for Knowledge Management) ».
6) Et toujours le mythe de la vue unifiée des données ou ici « Le fantasme de la mémoire organisationnelle permanente »
Tout contexte est infini (sauf à vivre dans un monde fermé).
Impossible de le représenter entièrement.
Des initiatives existent pour capturer la part cognitive d’un contexte (source l’article) :
« C’est ici que la recherche académique est intéressante parce qu’elle montre que le sujet n’est pas plus d’IA » mais une formalisation plus exigeante du savoir. Des travaux récents sur des « cognitive digital twins » proposent par exemple d’intégrer des ontologies et des modèles sémantiques pour encadrer ce qui est représenté et permettre des raisonnements plus structurés (Knowledge transfer in Digital Twins: The methodology to develop Cognitive Digital Twins). Ce type d’approche va dans le bon sens mais il rappelle aussi une vérité qui fait moins plaisir : formaliser le savoir coûte cher, demande des choix, et oblige à maintenir une structure, pas seulement des contenus. »
Source : https://www.duperrin.com/2026/03/12/expertise-jumeau-numerique-retraite/
7) Le Gartner déclare 2026 « Année du Contexte™ » : tout ce que vous savez est désormais un produit de contexte.
Comme souvent, on conceptualise : des fondamentaux (signification des données), par rapport à une problématique d’actualité (l’IA a besoin de données contextualisées) et une logique de marché.
Rien de nouveau, mais on découvre que les données sans contexte n’ont pas de sens (vieux sujet déjà évoqué avec pertinence par Edgar Morin dans les années 90 – https://www.res-systemica.org/ris/vol-09/vol09-num-02/ris-vol09-num02-p105-112.pdf).
Le marché s’en empare avec les cabinet de conseil.
Source : https://joereis.substack.com/p/gartner-declares-2026-the-year-of
Dont évidemment le Gartner D&A 2026 : Quand la couche de contexte est devenue un poste budgétaire important et fondamental.
Le cout de construction d’une couche de contextualisation intégrée à l’architecture existante… et ce n’est pas du tout neutre suivant la nature de l’architecture, son historique.
Source : https://metadataweekly.substack.com/p/gartner-d-and-a-2026-where-the-context
8) Dans l’actualité de la contextualisation des données : création de Nyne (https://nyne.ai/ « The People Data Company ») qui se lance dans la création d’une couche de contexte centrée sur la connaissance des personnes (une forme supplémentaire de « surveillance » de tout à chacun !).
Le constat, les agents IA ont besoin d’avoir une connaissance approfondie des profils humains qui vont interagir dans leurs environnements. Nyne vise à fournir cette connaissance en compilant N sources de données de profils (LinkedIn, X, Facebook … les réseaux sociaux…) : « Je peux leur fournir (aux agents IA) toute information utile sur une personne pour prendre la bonne décision »
9) Dans l’esprit du mythe de la vue unifiée des données (la fausse impression de simplicité) – voir aussi point n°6
L’article : « The Single Source of Truth Illusion ».
L’illusion du graal idéal : « Nous avons besoin d’une source unique de vérité ».
Mais cela ne marche pas comme cela.
La fiabilité des données n’est pas un problème unique.
Elle dépend d’où on se place, du contexte (toujours).
Rappel : la qualité des données n’est pas intrinsèque elle dépend de l’usage.
Se dire on va uniformiser et regrouper les données est théorique. On oublie le contexte, on le perd, on réduit le local dans le global et on aggrave la situation (plus personne ne se reconnait dans la vue unique).
« la vraie question est différente : « Comment expliquer et gérer les multiples versions de la vérité ? … Un dirigeant doit comprendre non seulement le chiffre affiché, mais aussi le contexte de son calcul »
La solution ce n’est pas un point unique de vérité mais « un langage commun pour décrire de multiples vérités ».
La « vérité » est contextuelle.
NB : Vécu N fois, dans N systèmes centraux et locaux de reporting même les plus normalisés.
L’article illustre cela avec plusieurs exemples, situations.
L’erreur classique : « Au lieu d’interroger les métiers sur l’origine des différentes définitions, les architectes tentent de les supprimer par une standardisation technique. Il en résulte un système mathématiquement cohérent, mais déconnecté des processus décisionnels réels. ».
L’objectif de l’architecture des données n’est donc pas de désigner l’une d’entre elles comme la meilleure définition (ce qu’est un client), mais de placer chacune d’elles correctement au sein du système.
Et à ne pas confondre avec le besoin d’un système réglementé de métriques partagées
« Une architecture bien conçue repose sur l’équilibre de deux principes. D’une part, elle permet à chaque domaine de gérer ses propres définitions de métriques. D’autre part, elle maintient une base de données partagée où ces métriques peuvent être comparées, comprises et expliquées. ».
Une entreprise ne devrait pas avoir une seule vérité, mais un seul système pour expliquer les vérités.
Source https://medium.com/analysts-corner/the-single-source-of-truth-illusion-8029170e0a7f
10) Sur les dangers de la faible maturité en termes de sécurité du protocole MCP
Avec outre des failles, l’absence à sa création d’éléments de gouvernance, l’authentification et l’observabilité.
Source : https://medium.com/@reliabledataengineering/the-mcp-illusion-c585bf84e73c
11) Zoom sur la formalisation du contexte chez Palantir – l’ontologie (concept propriétaire).
Source : https://ai.plainenglish.io/palantir-ai-fde-when-ontology-becomes-a-strategy-engine-cc813d86d0c1
Le prix des données
Rendre le prix des données transparent
Chaque transaction, interaction en ligne produit des données (entre l’élément à l’origine de la transaction et le service).
L’idée rendre visibles les données associées à la transaction (en plus des données de transactions elles-mêmes – indispensables de fait) pour se rendre compte du prix que l’on paie à l’usage d’un service (et pouvoir comparer, savoir si cela vaut le coup, apprendre le marché, négocier).
Et quel prix à payer si l’entreprise en charge du service n’aurait pas pu collecter ces données ?
Rééquilibrer la relation entre le fournisseur de service en ligne et le consommateur.
Modifier le marché des données en rendant explicite le cout des données entre une offre gratuite avec données collectées et une offre payante sans.
« There is a policy lever that could make data markets more transparent: unbundling. Requiring firms to offer a clear choice between transactions that allow data use and those that do not, at different prices if they so choose, would reveal the implicit value of data. The price difference would make the “data discount” observable. »
Utiliser Gmail gratuitement ou une messagerie payante ? A quel cout en termes de données ?
Source : https://www.weforum.org/stories/2026/03/data-online-transaction-unbundling/
Ouvrir, mutualiser les données pour améliorer la science
1) Ici l’initiative autour des données de santé dans le cadre de la recherche sur le cancer : « CRI Discovery Engine Inaugurates New Chapter in Immunotherapy, Creating the First-of-its-Kind AI-Ready Database » – https://www.cancerresearch.org/media-room/cri-discovery-engine
Un mixte d’indexation de sources de données et de stockage de données partagées.
Voir précédemment – revue de février https://www.datassence.fr/2026/03/24/revue-data-du-mois-fevrier-2026/#_ftn7
2) Comment la réglementation sur les données personnelles a amené à plus de restrictions des accès aux données des plates-formes numériques tout en ouvrant les données à plus de partage à des tiers.
Source : https://journals.sagepub.com/doi/full/10.1177/20539517261419327?mi=ehikzz
3) Et une autre façon d’aborder le problème – maintenir une trace fiable des accès aux données (exhaustivité et confidentialité des traces).
« Sur le plan algorithmique, l’idée centrale est de fusionner l’accès à une donnée et son enregistrement dans le journal d’audit en une seule opération indivisible. Cette fusion assure qu’une lecture laisse une trace même si elle a été interrompue. »
Voir l’article : https://list.cea.fr/fr/18-mars-2026-vers-un-audit-complet-et-confidentiel-des-acces-aux-donnees-partagees/
Les données comme armes
1) Quand les données de tracking publicitaire sont détournées.
« CBP Tapped Into the Online Advertising Ecosystem To Track Peoples’ Movements ».
Le services des douanes et de la protection des frontières (US) achète des données publicitaires (géomarketing).
Source : https://www.404media.co/cbp-tapped-into-the-online-advertising-ecosystem-to-track-peoples-movements/
Quand les données collectées à des fins publicitaires (géolocalisation marketing) servent aussi à la surveillance des personnes (où quand les finalités sont bafouées).
Toujours l’exemple de la police des frontières et de l’immigration qui achète ces données pour suivre la localisation de téléphones portables.
Sources : https://gizmodo.com/feds-used-online-advertising-data-to-track-the-publics-phone-locations-2000729129 et https://www.techdirt.com/2026/03/12/docs-expose-cbps-use-of-ad-data-to-track-peoples-movements/ et https://techcrunch.com/2026/03/18/fbi-is-buying-location-data-to-track-us-citizens-kash-patel-wyden/ et aussi https://lifehacker.com/tech/how-the-government-uses-advertising-data-to-track-people
2) La constitution mobile d’un réseau de capteurs de plaques d’immatriculation pour surveiller les mouvements aux frontières (US – Californie).
Un article, sur le déploiement de ce réseau, sa dissimulation, les données récoltées, ses finalités et dérives possibles, la « normalisation » de comportements suspects détectés avec les biais – les faux négatifs, le problème de sa régulation, du partage des données et au final la pression de surveillance permanente des habitants aux frontières.
3) Quand l’accès illimité donné aux employés du DOGE, a permis à un de ses employé de récupérer (voler) les données de sécurité sociale de la population américaine.
Source : https://techcrunch.com/2026/03/10/doge-employee-stole-social-security-data-and-put-it-on-a-thumb-drive-report-says/ et https://www.engadget.com/cybersecurity/social-security-watchdog-investigating-claims-that-doge-engineer-copied-its-databases-212722061.html?src=rss
4) Des données obsolètes ont été utilisées lors de la frappe américaine contre une école primaire en Iran.
Source : https://flowingdata.com/2026/03/11/outdated-data-used-in-u-s-strike-on-elementary-school-in-iran/
5) A lire les excellents articles du Grand Continent dont « Du Goulag numérique au cyberpunk russe : la dystopie digitale de Vladimir Poutine ».
Ici un zoom où on parle données : « En Russie, on peut acheter — assez peu cher — les données personnelles les plus intimes de son voisin…Le « cyberpunk russe 3 ».
Sous cette appellation provocatrice, l’auteur dessine les contours de ce qu’il faut bien considérer comme un véritable paradoxe russe : à mesure que l’État s’efforce d’instituer une sorte de « Goulag numérique » par diverses pratiques de surveillance, de blocage et de centralisation des données, les listes, registres et autres bases de données de l’État et des entreprises privées se retrouvent en libre accès sur un marché accessible à tous. Pour une somme modique, il est possible de rassembler le maximum d’informations sur un parfait inconnu, en s’adressant à des agrégateurs de données qui nous renseignent sur ses amis et sa famille, ses biens et ses comptes bancaires, son adresse et son historique de commandes en ligne, ses déplacements en train et en avion — et même ses relations extraconjugales. ».
6) Et comment disparaitre : https://www.zdnet.com/article/delete-me-review/
Données tabulaire et IA
1) Suite sur l’offre Fundamental
Voir précédemment : https://www.datassence.fr/2026/03/24/revue-data-du-mois-fevrier-2026/?highlight=fundamental#_ftnref10
« Ces données sont stockées dans des tableaux. Et les modèles de langage à usage général n’ont jamais été conçus pour les comprendre. »
Autrement dit les données tabulaires ce n’est pas de la linguistique !
Elles ne sont pas un récit, ne repose pas sur un langage unifié, leur tokenisation n’a pas de sens, elles sont la source de calculs formels (calcul de KPI) ce que les LLM ne savent pas faire…
Fundamental se lance dans le défi d’un « LLM » des données tabulaires : NEXUS. « Entraîné sur des milliards d’ensembles de données tabulaires » (NB : à voir leurs sources ?).
Source (rattrapage février) : https://fundamental.tech/news/the-trillion-dollar-ai-blindspot-why-llms-will-never-crack-the-code-on-your-most-valuable-data et https://fundamental.tech/news/the-left-brain-of-ai-why-large-tabular-models-signal-a-renaissance-for-data-scientists
2) La course à la construction de modèles d’IA sur les données tabulaires.
Où les technologies LLM sont appliquées aux données tabulaires.
Le challenge contrairement aux LLM dont l’apprentissage repose sur le langage, avec les données tabulaires on ne dispose pas d’une souche de langage commune.
L’exemple de SAP est intéressant, en restant dans le monde SAP (terminologie et concepts ERP de SAP – pour ceux qui s’y frottent, tout une culture de concepts est à acquérir lorsqu’on déploie SAP) et comme un des leaders mondiaux de progiciels d’entreprise.
3) Quand on redécouvre les bons principes du génie logiciel pour les besoins de l’IA : un bon cahier des charges, des bonnes spécifications et exigences, une gestion des changements pour qualifier un produit de données et assurer sa production, sa gestion et son utilisation par des agents IA.
NB : et s’applique à tout ce qui concerne la génération de code par les moteurs d’IA.
4) Vos données sont prêtes pour la BI et par pour l’IA.
Voilà pourquoi !
Source l’auteur : https://substack.com/@growthman15 Vivek Dubey
Les données pour la BI finissent dans les mains humaines, analystes, décideurs, un collectif (revue de processus par exemple), avec tout un contexte discuté.
Et elles s’arrêtent là avec la gouvernance associée.
Les données pour l’IA, manque de ce contexte et ne s’arrêtent pas là. Elles servent à automatiser des décisions, le lancement d’actions par des agents.
La gouvernance est absente.
Et en plus, malheureusement le lineage des données exploitées par l’IA est rompu, limitant les capacités d’explication (problématique de confiance).
Source l’auteur : https://substack.com/@growthman15 Vivek Dubey
L’article propose ensuite les étapes pour passer de la BI à l’IA.
Construire la couche de contexte, rendre la sémantique exécutable, traiter la continuité du lineage (intelligibilité des données), intégrer les données BI dans les données d’apprentissage, étiqueter les produits de données support aux agents (prise en compte de la politique de données), définir des métadonnées d’observation destinées aux agents (seuils qualité par exemple interprétables).
Source : https://metadataweekly.substack.com/p/bi-ready-is-not-ai-ready
Data et IA
1) Valeur des contenus, des données – le standard RSL
Les moteurs d’IA pillent les contenus du web. Pour en extraire les données d’apprentissage de leurs moteurs d’IA. RSL serait le moyen d’éviter ce pillage et de rétablir l’équilibre avec les créateurs de contenu : « Voici exactement ce que l’IA peut ou ne peut pas faire avec mon contenu ».
« L’innovation majeure du RSL réside dans son modèle économique. Il propose de passer du pay-per-scrape (payer pour accéder au contenu) au pay-per-inference (payer lorsque le contenu contribue à une réponse). La rémunération est ainsi liée à la valeur réelle apportée à la réponse générée par l’IA. ».
A lire dans l’article les autres approches connues : Common creative, tdmRep, ai.txt, defined.ai.
A suivre les travaux du collectif RSL : https://rslcollective.org/
2) World model
Données des modèles du monde (world models) – un dossier CNIL qui fait un tour d’horizon.
Données textuelles, données « sensorielles », rôle des capteurs, état de la recherche, risques…
Sur les capteurs – extrait :
« Par la « fovéation » active : diriger le regard, l’attention ou l’orientation des capteurs sans affecter l’environnement ; …L’égomotion active, soit le déplacement ou le mouvement d’un capteur, ou d’une caméra par rapport à un environnement réel ou virtuel sans affecter significativement cet environnement ; »
Sources : https://linc.cnil.fr/article-12-des-modeles-de-langage-aux-modeles-de-monde et https://linc.cnil.fr/article-22-des-modeles-de-mondes-avides-de-donnees-non-sans-risques
Et le dossier associé : https://linc.cnil.fr/sites/default/files/2026-04/linc_cnil_y_a_t-il_des_humains_dans_les_world_models.pdf
Et l’avancement des travaux de Y. Le Cun : https://www.numerama.com/tech/2218539-15-millions-de-parametres-et-1-seul-gpu-yann-lecun-fait-un-premier-pas-vers-lia-qui-comprend-le-monde-reel.html
Suite sur les données d’identité
Précédemment – revue de février : https://www.datassence.fr/2026/03/24/revue-data-du-mois-fevrier-2026/#_ftn4
1) 400 spécialistes tirent aujourd’hui la sonnette d’alarme sur les risques du contrôle d’âge imposé en ligne : facile à contourner, liberticide, mettant en risque des personnes sensibles (besoin d’anonymité), partage de documents sensibles, point de failure pour des pirates, appropriation par le secteur privé et d’entrepreneurs « délicats » !
Source : https://www.lebigdata.fr/plus-de-400-experts-reclament-larret-du-controle-dage-sur-internet
2) Quand l’Europe progresse sur le sujet de l’identité numérique (eidas 2.0 et les projets associés dans le but de disposer d’un écosystème complet de gestion de notre identité numérique non forcément capté par des entreprises privées, US – enjeu de la souveraineté). Avec la difficulté de la fin de l’anonymat et de l’aspect obligatoire qui risque de s’étendre. Source : https://www.journaldunet.com/cybersecurite/1548815-eidas-2-0-la-nouvelle-frontiere-de-la-souverainete-numerique-europeenne/
Actualité (Designing Data Intensive Applications, Sécuriser les données dès le hardware, Collecte de données – Reddit, Données et alignement business, La distinction entre le bruit et le signal, Etude sur les travailleurs des données)
1) Ouvrage de référence : Designing Data Intensive Applications par Martin Kleppmann et Chris Riccomini
La 2nd édition vient d’être publiée : https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/
2) Sécuriser les données à la racine hardware de calcul
La course aux solutions entre Intel et les startups universitaires pour pouvoir exécuter des calculs sur des données encryptées.
Source : https://it.slashdot.org/story/26/03/10/2022201/intel-demos-chip-to-compute-with-encrypted-data
3) Collecte de données
Intégrer Reddit dans sa stratégie data.
Exploiter les conversations pour détecter les tendances, avis, retours clients, problèmes remontés, recommandations faites, veille concurrentiel…
4) Pertinence des modèles économiques pour les données – l’alignement business
Source l’auteur : https://substack.com/@thedataecosystem – Dylan Anderson
Source : https://thedataecosystem.substack.com/p/issue-53-business-models-and-data
5) La distinction entre le bruit et le signal
« Le bruit, c’est le volume qui n’apporte aucune information significative, qui ne fait que nous faire sur-réagir de façon non appropriée, nous transformant en névrosé constamment agité par toute information nouvelle sans intérêt décisif.
Le signal c’est l’information essentielle, celle dont il faut se préoccuper en priorité. »
Comment face aux volumes de données retrouver le signal dans le bruit ?
« Plus on observe fréquemment des données, plus on est disproportionnellement exposé au bruit (plutôt qu’à l’élément important : le signal) ».
Source : https://zonefranche.blog/2026/03/27/le-bruit-et-le-signal/
6) Sur les travailleurs des données, une longue étude sur ces travailleurs, leurs compétences, leurs actions, leurs partages, leur identité, leur marchandisation, leurs révoltes…
« L’utilisation croissante de systèmes autonomes dotés de modèles d’intelligence artificielle (IA) a entraîné une forte augmentation de la demande de traitement des données à l’échelle mondiale. Pour fonctionner efficacement, ces systèmes nécessitent l’organisation, l’étiquetage et le nettoyage d’immenses quantités de données. »
Source : https://journals.sagepub.com/doi/abs/10.1177/20539517261434334
RDV maintenant en mai pour la revue et les actualités d’avril.
Les commentaires sont fermés.