Ce mois d’octobre une grande diversité de thèmes.
Des classiques (data gouvernance, data mesh, data et IA, données synthétiques, pouvoir des données) et des sujets sensibles (collecte des données, données d’identité, données de notre sensibilité, de nos sentiments, neurodonnées).
Une grille de lecture sur comment sont appréhendés les univers des données par les personnes : l’idée d’imaginaire des données.
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 :
- Collecte des données
- L’imaginaire des données
- Neurodonnées
- Data et IA : structure de données, contextualisation, auto phagocytage, métadonnées, le graal des données de santé, empoisonnement
- Quand les données s’attaquent à la part humaine … non rationnelle
- Quand les S.I. se redessinent autour des données, data platforms, data mesh, data products, data agents, dette de données, TCO, data engineering, multi data environnements, data factory
- Gouvernance des données : résistance, automatisation, qualité des données, dégradation
- Valeur et pouvoir des données
- Données synthétiques – étude de cas sur une population à risque
- Les données à fort enjeu : les données d’identification et le travail invisible d’interopérabilité
- Le monde des données est un monde continu … sans fin
- Vrac (Numérisation de l’Histoire, Grille de lecture quantique appliquée aux données, Nos données après notre mort, OpenData, Conservation des données telecom, Data et sport : le volley, L’offre data du London Stock Exchange Group)
Collecte des données
1) Changer l’asymétrie collecteur de données (entreprise de la tech), producteurs de données (nous)
« The global economy runs on data, yet those who generate it — individuals, communities, and entire societies — remain largely powerless over its use and excluded from its economic value. Many tech giants have built vast, multi-billion‐dollar businesses whose core revenue streams épend heavily on collecting, analyzing, and monetizing user data. However, alternative models that give people genuine control over their digital assets struggle to scale beyond promising pilots. »
Il faut un changement systémique.
Les alternatives : l’idée de coopératives de données et d’infrastructure de données étatique conçue autour d’une agence citoyenne de données.
Exemples : les coopératives médicales européennes de patients pour la contribution à la recherche ou le système X-Road de contrôle citoyen des données de l’état Estonien.
Il y a besoin d’une politique coordonnée internationale pour que ces alternatives ne restent pas marginales. Et aussi face à la demande de l’IA, à la recherche de données de qualité et à valeur.
Problème : « les cadres juridiques conçus pour les actifs physiques ne s’adaptent pas facilement aux actifs numériques. ». Quels sont les droits en termes de propriété des données (NB : vaste sujet – avec au départ l’idée de propriété des données a-t-elle un sens ?!).
Comment concurrencer la manne d’argent publicitaire issue des données collectées pour financer les plates-formes des solutions alternatives.
Entre la vague de l’IA et de son besoin en données et la montée en puissance des alternatives comment le fossé peut être comblé ?
L’article fait un point de la situation :
Source : https://www.techpolicy.press/how-unga-80-could-shift-power-in-the-data-economy/
Et sur les coopératives de données voir le rapport : « Data Co-ops as a Scalable Alternative to the Centralized Digital Economy » – Source : https ://www.projectliberty.io/news/data-coops-as-alternative-to-centralized-digital-economy/
2) La mécanique de relation sociale comme moyen de collecte de données
On le sait les réseaux sociaux sont les plus grands collecteurs de données (NB : en passe d’être dépassés par les IA conversationnelles).
Et c’est sans fin, exemple de la mécanique sociale déployées dans des applications de questions anonymes échangées entre utilisateurs (principalement adolescents) comme moyen de collecte et de manipulation de données. Source :
3) Dette de collecte : Inégalité femme-homme dans les données.
Le sujet est connu, de plus en plus médiatisé, la majorité des jeux de données, lorsqu’ils concernent des individus ne traduisent pas l’inégalité homme-femme et également la non représentativité de minorités. Avec des conséquences critiques.
A lire l’entretien avec Julisa Tambunan, directrice exécutive adjointe d’Equal Measures 2030, une coalition féministe mondiale qui met les données au service du plaidoyer et de l’action en faveur de l’égalité des genres.
Extraits : « And so the question of making sure that we understand that what data is collected is political, what we know is political »
« Data alone is not enough, and people think it is. The same data can be used different ways depending on the narrative behind it.
Tambunan: Yeah, it’s definitely creating a lot of anger with me as well. I think that’s why I started with data justice. Data alone is not enough, and people think it is. »
Source : https://issues.org/not-now-but-soon-who-is-worth-measuring/
L’imaginaire des données
1) Activisme et données
L’article décrit l’imaginaire des données ou comment les données sont vues par des acteurs ici des activistes dans des mouvements sociaux et comment cela influence leurs actions.
L’idée d’imaginaire des données fournit une grille d’analyse / de lecture, alimente le processus de construction du sens et permet d’élaborer des opportunités d’action liées à la datafication / numérisation (concept formalisé par différents auteurs – imaginaire sociotechnique des données – voir les références dans l’article : Jasanoff, 2004, 2015, Lehtiniemi et Ruckenstein (2019), Benford et Snow, 2000 ; Snow et al., 1986)
Trois vues des données sont appelées : 1) les données comme infrastructure de traces (transactions, géolocalisation, téléphonie, biométrie), 2) les données personnelles instrumentées par les institutions voire vues comme armes punitives, 3) les données intégrées à l’environnement comme opératrices de surveillance (vidéosurveillance, mobilier urbain avec capteurs – exemple lampadaires « intelligents »).
L’article est riche d’exemples : comment la société civile utilise les données à la fois comme outil et comme objet de contestation, comment les initiatives d’ouverture des données présentées comme neutres sont imprégnées de contexte et de rapports de pouvoir…
L’article propose d’étendre le concept d’imaginaire des données, en allant plus loin qu’un simple cadre narratif déployé par les militants (comment les données sont « lues »). L’imaginaire fournit une vision globale, de la reconnaissance du problème (comment il est constitué) à l’avenir envisagé (quels sont les possibles – exemple modèles de menaces), en passant par une dimension émotionnelle (exemple surveiller équivaut à dominer ou à protéger).
Exemple d’imaginaire : l’utilisation des traces de tout un écosystème, de la vidéo surveillance avec reconnaissance faciale en temps réel dans les gares ou aéroports, en passant par l’utilisation des données des opérateurs téléphoniques et des données de transactions dans les restaurants (cartes de restauration), croisées avec les données d’analyse des reportages des médias et des publications dans les réseaux sociaux, sous la craintes de détournement des cartes d’identité intelligentes de Hong Kong équipée de la technologie d’identification par radiofréquence (RFID), le tout transmis / utilisé par la police.
Avec en réponse, la mise en place de résistances – utilisation de messageries cryptées, VPN, masques à porter pendant les manifestations, utilisation de téléphones vierges – avec SIM pré-payées, limiter l’utilisation de ses cartes de crédit personnelles
Les données comme armes imaginaires : preuves contre les manifestants / activistes.
Les données comme moyens de rétorsion : syndrome du crédit social qui vous permet ou non suivant votre score de voyager, acheter un logement, bénéficier de tel service…
L’idée d’imaginaire conduit à penser en termes d’amplification (« exagérer » les craintes liées aux données), d’extension (élargir les craintes des activistes à tous les citoyens), d’opposition (utiliser les données comme résistance).
Le processus de construction du sens se déploie à travers trois mécanismes interconnectés de transformation de concepts abstraits data : 1) appel à des références culturelles Black mirror et 1984 ne sont pas loin ! 2) spéculation sur les capacités des données 3) transformation en actions de lutte (gestes comme le port de masque, ou actions plus violente comme la destruction de matériels) … remodeler la datafication.
NB : la datafication permet de basculer d’un mode d’investigation / contrôle a posteriori (qui sont les coupables) à a priori (tous potentiellement coupable).
NB bis : La réalité d’un imaginaire temps réel des données, d’interopérabilité et d’une traçabilité systématique intégrée et contextualisée ;.. est sûrement exagérée quand on connait comment les environnements de données sont conçus, maintenus, opérés.
Source : https://journals.sagepub.com/doi/full/10.1177/20539517251389866
2) Le cas de l’idée de surveillance des données et les publicités ciblées.
L’enjeu des publicités ciblées.
Nécessite une collecte (surveillance) de données (dans le cadre de Tiktok et de l’univers des mèmes).
L’article interroge les utilisateurs et leur perception face à cela.
L’auteur fait appel au cadre d’imaginaire algorithmique pour analyser le phénomène.
Extraits :
« It is not the users who are being watched, but rather their digital, datafied avatar; “it is our data that is being watched, not our selves” (Cheney-Lippold, 2017: 21). »
« Such tension situates users in a tricky position: even if they are aware that their data is being collected, the data subject they represent for the algorithm is unavailable for them to either question, analyze, or meaningfully influence. »
« Sörum & Fuentes note that such positive yet deeply passive imaginary relies on a belief that data extraction benefits consumers by serving company interests in delivering the best experiences and goods (2021: 32–33). Targeted ads, alongside other forms of dataveillance, are considered as convenience (Strycharz et al., 2019; Zhang et al., 2024: 2714). »
« These tiktoks share a commonality with a previous finding of Bucher (2017), who speaks of “whoa moments,” that is, an encounter with an algorithmic recommendation that makes the user realize that profiling takes place; “whoa moments arise when people become aware of being found” (2017: 35). »
« Despite ambiguous truthfulness of these claims and no clear empirical evidence (Nicholas et al., 2021: 3), many users believe that their devices are constantly listening to them for targeted advertising purposes (Zhang et al., 2024, following Fowler, 2019). The Antagonistic Passive Imaginary expressed in these two TikToks reflects this belief. »
« Targeted ads are a record of the past, intimately tracking the daily life (also one’s “past” life). »
Source : https://journals.sagepub.com/doi/abs/10.1177/20539517251386041
Neurodonnées
Les données issues de la capture des signaux électroniques de notre cerveau, des données personnelles pas comme les autres. A la fois données de santé, données d’identification, données d’activité mentale (comportementale, cognitive).
Le RGPD s’applique.
Mais elles introduisent de nouveaux défis : qu’est-ce que notre identité mentale, doit-on parler de liberté cognitive, la notion de vie privée mentale a-t-elle un sens, a-t-on besoin d’un « Mental Data Protection Impact Assessment » ?
A lire de la CNIL tout un dossier sur le sujet – Source : https ://linc.cnil.fr/article-22-des-neurodonnees-personnelles-pas-comme-les-autres
Et aussi, un zoom sur les implants cérébraux, mais aussi les moyens de suivi des mouvements oculaires au service de malades et le besoin de protéger la vie privée mais aussi des risques de hacking : https ://www.weforum.org/stories/2025/10/beyond-neural-data-a-technology-neutral-approach-to-privacy/
Voir aussi une actualité de 2024 sur le sujet : https://www.datassence.fr/2024/05/02/revue-data-du-mois-avril-2024/?highlight=neurodonn%C3%A9es#_ftn8
Data et IA : structure de données, contextualisation, auto phagocytage, métadonnées, le graal des données de santé, empoisonnement
1) Une bonne structure de données est centrale
Pour ceux qui s’intéressent à la façon dont une bonne structure de données conditionne l’efficacité algorithmique – ici le cas des moteurs d’IA. Source : https ://towardsdatascience.com/foundation-models-in-tabular-data/
2) Quand l’IA tue ses sources de données par une double lame (auto phagocytage)
Première lame, l’IA a besoin de données, elles s’est servie sans scrupule jusqu’à la réaction de nombreuses sources. Sources qui se ferment. Deuxième lame, l’IA se place en intermédiaire de ses sources. Elle les prive de trafic (source de revenu) et les met en danger. Source : https ://qz.com/ai-data-chatbots-publishers-copyright
3) Comment prendre en compte le contexte d’entreprises dans un moteur LLM – la vision d’Oracle (L. Ellison)
Les LLM sont entraînés sur des données « publiques ».
Comment faire pour tenir compte des contextes, connaissances métier, données opérationnelles, expertises sectorielles spécifiques ?
Comment mobiliser ces données qu’ont besoin les moteurs d’IA sans les partager ?
La solution : l’intelligence contextuelle, la capacité de fournir aux modèles d’IA un contexte spécifique à l’entreprise sans compromettre la sécurité des données ni nécessiter d’importants efforts de réentraînement.
On comprend tout l’intérêt d’Oracle sur ce segment (via sa maîtrise de la pile complète de l’infrastructure aux progiciels métiers en passant par les bases de données).
L’approche d’Oracle est centrée sur la génération augmentée par la récupération (RAG).
« Ellison demonstrated this with Oracle’s first internal use case: taking all of Oracle’s customer data, vectorizing it, and using RAG to answer:
What Oracle customers are likely to buy another Oracle product in the next six months, and what product will each customer buy?
The AI agent identified likely buyers, determined the best customer references for each prospect based on their industry and geography, and sent personalized emails. »
Avec l’accent mis sur le secteur de la santé (« obsession » de L. Ellison) – voir aussi l’échange entre L. Ellison DG Oracle et T. Blair sur le sujet des données de santé – https://www.datassence.fr/2025/11/20/revue-data-du-mois-octobre-2025/#_ftnref8
Quand l’IA va décider de votre sort de santé !
« Outlining the challenge, Ellison depicted how hospitals need to provide the best possible care to patients, but that care must also be fully reimbursable by insurers or government healthcare systems. These are often competing goals—the best drug for a condition might not be covered by insurance, or available via national healthcare.
Oracle’s AI agent uses RAG to access two data sources. First, it accesses the latest medical literature, clinical trial data, and the patient’s electronic health records to help determine optimal care. Second, it accesses insurance policies and reimbursement rules to determine what’s covered.
The agent then proposes « the best possible care at the highest reimbursement level achievable. » It can flag exceptions—for instance, if a patient’s body mass index crosses a threshold that makes them eligible for a drug that’s normally not covered. »
Source : https://diginomica.com/ellisons-ai-vision-oracle-robot-surgeons-meet-enterprise-data-reality
Et en complément : https://www.journaldunet.com/intelligence-artificielle/1545205-l-ia-generative-n-est-pas-magique-le-vrai-pouvoir-du-rag-reside-dans-les-donnees/
4) Les métadonnées, la glue d’interprétation des données pour les moteurs d’IA.
Toujours le sujet du contexte (à rapprocher de l’intelligence contextuelle indispensable aux moteurs d’IA). Ici la couche sémantique est vu comme moyen de fédérer les données entres elles pour leur donner du sens :
Et cette couche est spécifique à votre environnement :
« If your customer churn model is trained on transaction data, the AI doesn’t know what a “high-value customer” means unless your semantic layer defines it.
If you’re using AI for risk scoring, the model needs to know how “risk category” fields are derived and what thresholds apply. ».
Source : https://www.firstsanfranciscopartners.com/blog/metadata-is-the-new-gold-standard-for-ai/
5) Industrie des données – étude sur la plateformatisation du travail d’annotation des données (pour l’IA) par les travailleurs handicapés en Chine. Source : https://journals.sagepub.com/doi/abs/10.1177/20539517251386046
6) Empoisonnement – corruption des LLM par les données
Un article qui montre qu’avec 250 documents malveillants, on peut créer une faille de sécurité dans un moteur LLM « A poisoning attack happens when an attacker intentionally creates and publishes malicious text, hoping it gets swept up in the training data. This text can teach the model a hidden, undesirable behavior that only activates when it sees a specific trigger phrase. ». Source : https://www.analyticsvidhya.com/blog/2025/10/llm-data-poisoning
Un autre article sur les tentatives de « Mess AI » qui en générant un maximum de données erronées vise à nuire au phase d’entraînement des LLM. A mettre en regard aussi de l’initiative « Pause AI » (https://pauseai.info/ ).
L’article référence un certain nombre d’actions d’empoisonnement. Dont par l’utilisation d’une IA (combat d’IA). Jusqu’à « Also good and sincere messages to future AI can be distorted by thousands of prompt injections and AI will learn to ignore any human messages. ».
Sources : https://www.lesswrong.com/posts/bMNALJCsXQevaJEuM/mess-ai-deliberate-corruption-of-the-training-data-to et https://dataconomy.com/2025/10/15/just-250-bad-documents-can-poison-a-massive-ai-model/
Et un dernier article – une étude approfondie de chercheurs sur la possibilité de manipulations Russes des moteurs LLM via leur inondation par des données de désinformation. Les chercheurs n’ont finalement pas reconnu l’hypothèse de « reprogammation » des moteurs par ces données « Addressing this requires strengthening the availability of trustworthy content on underreported issues, rather than overstating the threat of manipulation over AI by hostile actors. ».
Et ne pas confondre manipulation et données manquantes (data void – voir https://datasociety.net/library/data-voids/ ) – « Disinformation may appear not because LLMs were groomed, but as a byproduct of informational scarcity. ».
Quand les données s’attaquent à la part humaine … non rationnelle
Are they lovers or friends? Evaluating LLMs’ Social Reasoning in English and Korean Dialogues
Les données s’attaquent à la part humaine, non rationnelle … tout se discrétise en mesures.
Extraits :
« We adopt soft labeling, where each relationship type is annotated with likelihood-based categories: HIGHLY LIKELY, LESS LIKELY, UNLIKELY »
« While important, this line of work does not evaluate the capacity to integrate social contexts into the reasoning process (Hilton, 1995) »
« Honorifics are another key site of cultural divergence, encoding social relationships directly into linguistic forms (Ide, 1989) »
« As humans naturally engage in social relationship reasoning in their daily interactions, we argue that LLMs should also be able to perform such reasoning to generate contextually appropriate utterances and to prevent potential social harm. ».
« We introduce SCRIPTS, a benchmark for social relationship reasoning in multi-turn dialogues across two languages (English, Korean). » … avec la constitution d’un datasets labélisé selon une logique formalisée d’une relation humaine : « Comparative Analysis of Relational Dimension Distributions for Six Relationship Types Present in Both English and Korean Top10 Relations. Legend labels denote intimacy (O: intimate, X: unintimate, △: neutral), formality (O: formal, X: informal, △: neutral), and hierarchy (<: hierarchical, =: equal). »
… à lire.
Et on y trouve aussi une limite des LLM dans leur capacité à reproduire le schéma de relation : « We find four key failure modes in English and Korean: Models (1) confuse whether an address term refers to the speaker, the addressee, ora third party, (2) fail to aggregate multiple contextual cues when they contradict each other, (3) exhibit stereotyping in relational interpretations, failing to recognize beyond typical relationships, and (4) fail to capture culture-specific nuances in social relationship reasoning, which is a highly culture-dependent task. »
Source : https://arxiv.org/pdf/2510.19028
Et aussi quand cela touche à l’intime, aux sensations, à la pensée avec l’exemple du problème du suicide – quelle formalisation, mesures pour la reconnaissance (un filtre sur le mot suicide n’est pas suffisant quid de ce qui touche à la terminologue pour exprimer mettre fin à sa vie par exemple) – voir H. Guillaud
https://www.lebigdata.fr/un-million-de-personnes-tentent-le-suicide-via-chatgpt-openai-est-horrifie
Voir sur ce sujet les articles de H. Guillaud – vu récemment https://danslesalgorithmes.net/stream/objectiver-la-douleur/ et aussi https://danslesalgorithmes.net/2025/06/17/pour-une-science-de-la-subjectivite/
Quand les S.I. se redessinent autour des données, data platforms, data mesh, data products, data agents, dette de données, TCO, data engineering, multi data environnements, data factory
1) REX Toyota
A voir ce que cela va devenir. Extrait « « Nous déployons un hub de gouvernance data à partir d’un datalake Snowflake, précise Thierry Martin. Nous créons des domaines pour chaque division, chaque pays ou chaque usine. Et chacun de ces domaines sera chargé de créer son propre data product dans Snowflake, qui sera ensuite publié dans une marketplace Collibra. » C’est via cette dernière que les consommateurs de services feront la demande d’accès à des data qui apparaissent par exemple dans Dataiku. « Enfin, chaque fois qu’un indicateur ou une prévision sera créé dans Dataiku, il sera à son tour intégré à Collibra ».
Un modèle de gouvernance que Toyota envisage d’étendre également aux agents IA sous forme « d’agent mesh ». « Nous voulons créer des agents qui iront dans le datamesh, mais aussi dans Snowflake, dans Dataiku, explique Thierry Martin. Qui plus est, nous utilisons aussi Copilot de Microsoft. Cela commence à être un peu chaotique, et nous allons donc tout connecter via un MCP, afin de disposer d’un bon orchestrateur d’accès aux agents IA »
2) Data mesh – point de situation après l’engouement de départ
L’idée de data products et de data contracts est ancrée.
La gouvernance sous forme de code est de fait une cible.
Les data platforms sont capables de gérer des logiques de domaines de données.
Mais avec des dérives : manque d’uniformisation des domaines qui choisissent leurs propres solutions, les catalogues de données factices (non ancrés dans les systèmes).
Source : https ://medium.com/@2nick2patel2/data-mesh-2025-buzzword-or-delivering-dca3e4fef29a
3) Data Mesh : le retour d’expérience de CASTROL
Pourquoi CASTROL a passé d’une logique data centralisée à décentralisée.
Comment CASTROL a déployé la logique data mesh avec l’instanciation de domaines data, de data products accompagnés d’une gestion des métadonnées.
L’article est complet jusqu’à illustrer techniquement des exemples détaillés de data products, d’implémentation de policy…
Quelques extraits :
Avant le déploiement data mesh : une centralisation à bout de souffle, 18 systèmes de données différents, 6 mois de déploiement pour de nouvelles analyses, insatisfaction du business quant au résultats … malgré 18M$ d’investissement pour construire un data lake central.
2 ans après sa mise en place : 78% des datasets non à jour ou non utilisés, une multiplication de pipelines spécifiques, métiers irrités de ne pas avoir les réponses à leurs questions ou bloqués en attendant que les données arrivent en central…
La centralisation a tué, l’agilité (réactivité, fluidité, évolutivité), la contextualisation locale des données, la capacité à suivre la dynamique data.
Et ce n’est pas propre à CASTROL d’autres sociétés Unilever, Shell, Nestlé et Siemens ont basculé dans la logique data mesh.
NB : toutes des sociétés aux chaînes d’approvisionnement mondiales, à la réglementation complexe et aux opérations décentralisées.
Exemple sur les déclarations de substances chimiques, le Brésil exige une déclaration auprès de l’ANVISA, l’UE exige la conformité au règlement REACH, les US exigent l’étiquetage EPA, la Chine exige la norme GB … Chaque réglementation a ses propres champs, formats et échéances
Les principes adoptés :
- Pas d’entrepôt de données monolithique
- Chaque domaine gère ses propres pipelines, crée ses propres data products (pas de création de data product central quand la responsabilité est au niveau domaine – exemple pas de data product Ventes mais un data product Ventes par Région)
- Découvrabilité des données au cœur (catalogage)
- Infrastructure mutualisée et sous une couche d’abstraction permettant la gestion par domaine, par data product, métadonnées, le contrôle du code des pipelines le tout via des templates partagés à respecter (par exemple pour décrire un data product)
- Gouvernance dans le code (exemple idée de meta data product)
- Un pilotage du maillage : score de santé des data products
- Et des incentives gains de crédits suivant l’usage de data products
4) La place des data contracts dans le cycle de vie des données.
Les data contracts sont une bonne chose, mais il faut savoir bien les placer dans le cycle de vie des données.
Le bon sens être au plus près de la source et non pas quelque part en aval.
Mais rien n’interdit de devoir en positionner avant la consommation (par exemple pour se protéger des défaut de qualité de données qui pourraient impacter des clients).
Et rappel les data contracts sont des outils socio-technique (j’aurais dit MOA-MOE / métier-technique à une époque). Et ils doivent faciliter le problème n°1 des architectes : l’intégration.
Source : https://dataproducts.substack.com/p/your-data-contracts-are-in-the-wrong
5) Data platform : la force de Palantir : ontologie – couche sémantique et gestion du dernier km – des insights à l’action
Construire une vue unifiée de toutes ses données contenues dans une couche historique de systèmes est un mythe.
Mais au vu de l’hétérogénéité et complexité de cette couche certains n’hésitent pas à construire un nouveau système orienté data en parallèle. Plus qu’un nouvel entrepôt, sa mission est à la fois de contextualiser les données et de gérer le gap entre données et actions (NB : deux dimensions souvent absentes des systèmes traditionnels de BI).
« Most tools start from scratch, connecting to sources, modeling data, building logic, and then designing the interface. Workshop starts where they finish. It assumes your operational system already exists, with the data model defined in the Ontology, security governed through Markings, and audit trails built in by design. Actions, when needed, evolve alongside the application, not before it. »
C’est l’offre et l’ambition de Palantir : la couche sémantique de l’ontologie unifie contextualise les données (tels appareils – avions sont liés à tels dossiers de maintenance qui concernent telles pièces…) et les actions possibles sont elles-mêmes inscrites dans l’ontologie (exemple « retarder un vol » suite à insight d’alerte de maintenance).
Maintenant derrière cette solution, ce cache l’éternel problème de l’intégration à construire avec les systèmes opérationnels existants… Et c’est LA difficulté.
L’article détail l’offre de Palantir.
6) Le retour d’expérience de Netflix sur les data products.
Attention toute les entreprises ne sont pas des Netflix !
Mais on peut en retirer des enseignements :
- Ce que sont les data products : « At Netflix, data products — from high leverage telemetry, warehouse tables, key metrics and dashboards to ML models »
- La pensée produit appliquée jusqu’au bout (exemple ce produit pour quels consommateurs – usages, avec quels ingrédients pour quelle valeur, bien étiqueté, avec une gestion de la péremption…le tout contrôlé et en amélioration continue)
- Facilité au maximum l’usage (éliminer les frictions)
7) Quand les coopératives agricoles deviennent aussi des coopératives de données.
Un article intéressant du rôle des données sur le terrain.
Extrait « La stratégie data de Cooperl vise donc en premier lieu à rapprocher les enjeux d’évolution de l’élevage et les initiatives remontées du terrain. Le plan comprend un premier volet centralisé, traditionnel, avec de la BI, des data scientists et un service innovation. « Mais cela devient vite un goulet d’étranglement, reconnaît le data manager de la coopérative. Avec nos 600 métiers, les équipes data sont, en effet, contraintes à chaque fois de comprendre les processus, le fonctionnement de l’exploitation, les indicateurs, etc. » Cooperl a donc décidé d’ouvrir un second front, décentralisé cette fois. ». (NB : j’ai souligné – l’importance d’être à la source au plus près du contexte de départ).
8) La dette de donnée des banques (NB mais pas que dans les banques !).
« Dette de données techniques : les systèmes centraux existants, les plateformes complémentaires et les innombrables systèmes tiers. C’est le niveau le plus facile à identifier et à financer, mais il ne représente que la partie émergée de l’iceberg.
Dette de données sémantiques : le fait que le terme « actifs » ait une signification différente dans la gestion de patrimoine et dans le crédit commercial. C’est ce niveau qui engendre des coûts de rapprochement considérables, bloque la prise de décision en temps réel et rend impossible le déploiement à grande échelle des initiatives d’IA.
Dette de données de gouvernance : l’absence de transparence et de responsabilité. Lorsque les autorités de régulation demandent : « D’où vient ce chiffre ?» et que la réponse est une feuille de calcul, il y a un angle mort en matière de gouvernance. C’est le niveau le plus dangereux, car il conduit directement à des amendes réglementaires et à des décisions catastrophiques. La plupart des banques déploient des solutions technologiques (de niveau 1) pour résoudre un problème qui prend racine aux niveaux 2 et 3. »
9) Remise en cause de la logique de peuplement d’une data platform (tout collecter d’abord), jusqu’à l’idée même de centralisation
Collecter d’abord, utiliser après (mais la centralisation n’est pas la finalité)
Collecter d’abord, schéma après (schéma on read) (mais contextualisation sous-estimée)
Collecter d’abord, par tous en autonomie, régenter après (mais en résultat un chaos de pipelines)
Collecter d’abord, sécuriser après (mais RBAC inadapté non évolutif)
Pour finir par remettre en cause l’idée de centralisation (rappel du mythe de la vue data unifiée).
Source : https://www.datasciencecentral.com/best-practices-that-break-data-platforms/
10) La fin du modern data stack bousculé par l’IA agentique (par Sifflet)
La durée de vie des « concepts » sur les plates-formes data est fascinant (mais les DW/DM voire infocentres sont toujours là).
NB : datalake, datalake house, data platform, data stack, modern data stack, data platform intégrée relèvent tous de la même logique et sont plutôt le reflet d’une bataille marketing (voir sur ce point : https://seattledataguy.substack.com/p/when-words-become-data-architecture ).
Se cachent derrière quand même deux points incontournables
1) Ce n’est pas du tout le même travail de se lancer dans l’intégration de son stack data versus en utiliser un tout intégré.
2) Les données dans ces stacks ne sont qu’une brique de la vue des data et cela nécessite d’avoir une vision plus large (sources, transformations amont, pipelines…) pour contrôler la production de résultats (ce point objet de l’observabilité). Les stacks ne maîtrisent que ce qui est dans leur espace.
Pour l’éditeur Sifflet (spécialiste de l’observabilité https://www.siffletdata.com/ ) tout naturellement ils se positionnent sur l’ensemble des chaînes data avec « We’re entering a world of self-aware data systems: pipelines that reason, remediate, and learn. The data engineer of tomorrow won’t write monitors; they’ll supervise agents that do. ».
Commentaires :
- Ils n’ont pas tort, l’observabilité doit être de bout en bout,
- On a besoin d’eux parce que les systèmes historiques n’ont pas intégré l’observabilité à leurs racines,
- Mais l’idée que les agents data sont le futur … encore fallu-t-il avoir les moyens de repenser tout son S.I. data (quid du poids de l’existant)
- Et si on repense son S.I. data autant intégrer l’observabilité nativement et dans ce cas Sifflet est inutile.
11) Les 4 tensions que tout data engineer doit gérer
1) Control vs Speed
Préserver la qualité, la traçabilité et la conformité vs délivrer des modèles / pipelines
Règles : automatiser la gouvernance
2) Context vs Abstraction
Disposer de systèmes évolutifs par l’abstraction tout en préservant le contexte des données (leur sens). Rendre explicite les règles métier : contrôles, sémantique, circuits … en faire des métadonnées exposées
3) Autonomy vs Integration
Offrir de l’autonomie de façon décentralisée tout en préservant une homogénéité d’ensemble (définitions, référentiels, politiques)
L’intégration des couches basses est à centraliser, celle des couches métiers doit être fédérée.
4) Vision vs Reality
Savoir anticiper les évolutions, la cible idéale tout en étant dans la réalité.
Pour cela être en mesure de versionner son architecture (datasets, interfaces, règles de contrôle…).
Comment faire, l’approche de l’auteur : « That’s exactly what the Composable Functional Data Fabric (CFDF) does. In CFDF, each dataset, transformation, and policy is a composable function described as data itself. »
Et surtout préserver la simplicité.
NB : Avec une question clé, disposer d’un framework où l’intégration des différentes briques (pipelines, métadonnées, catalogage, data management, traçabilité…) est faite versus construire un framework avant de se lancer. Et les questions associées : choix des briques, qui paie l’effort d’intégration… Avec en tête : le problème n°1 c’est l’intégration.
12) Multi data environnements – résoudre les silos de métadonnées
Le problème : quand chaque outil data parle son propre langage (définitions, traçabilité, lineage d’exécution, expression des politiques…de données : métadonnées)
Les infrastructures de données modernes sont tentaculaires. Entrepôts de données, lacs de données, outils de BI, moteurs de transformation et orchestrateurs stockent chacun les métadonnées différemment. Aucun de ces outils ne communique dans le même langage.
Le problème n’est plus le big data mais le multi data environnements voir https://www.datassence.fr/2025/01/16/revue-data-du-mois-decembre-2024-tendances-2025/?highlight=%22multi%20data%22#_ftnref1 ).
L’article présente une architecture pour résoudre ce problème grâce à la standardisation de la capture des métadonnées, à OpenLineage pour la traçabilité des données à l’exécution, les standards W3C (DCAT, PROV-O) pour la sémantique et un graphe de connaissances pour le stockage.
Extraits :
« Pour une organisation de données de taille moyenne, ce chaos représente un coût annuel de 800 000 $ à 2 millions de dollars en temps d’ingénierie gaspillé, en frais de conformité et en décisions prises sur la base de données non fiables ».
13) Retour d’expérience de l’ESA sur une infrastructure data factory et aussi sur l’exploitation de l’IA générative – avec deux problématiques clé : la contextualisation dans le temps et la spécificité du langage technique utilisé.
Extrait : « …certains des documents associés ont plus de 20 ans. Et ont été conçus dans un langage, mais aussi avec des méthodes de reporting totalement différentes. L’ESA teste différents LLM sur ce corpus, qu’il s’agisse de Mistral ou d’OpenAI, mais « entraîner un modèle à comprendre nos documents en contexte, à interpréter la façon dont ils ont été écrits, etc., c’est très complexe. ».
Gouvernance des données : résistance, automatisation, qualité des données, dégradation
1) Résistance à la gouvernance des données
Qui n’a pas connu des forteresses de données difficile à ouvrir ? Personnellement, j’en ai rencontré pas mal dont sur des données stratégiques (financières par exemple). Avec les craintes, d’être dépossédé (perte de pouvoir, de moyens voire risque de disparition), d’une mauvaise lecture des données par des tiers, de mise en lumière de choix voire de cuisine interne dans le traitement des données (vécu l’application de règles non écrites, de données que l’on sait erronées mais qu’il faut surtout ne pas corriger…). L’article reprend ce sujet au travers d’exemples : https ://blog.masterdata.co.za/2025/10/07/how-internal-politics-poison-your-data-quality-and-how-to-fight-back/
2) Gouvernance des données automatisée
Les conseils d’un architecte data dans l’automatisation de la gouvernance des données (indispensable … vitale) : 1- automatiser les contrôles qualité 2- mettre en place du lineage dynamique 3- configurer des alertes automatiques par rapport aux politiques de données. Le détail et la suite ici : https ://medium.com/data-science-collective/automated-data-governance-in-2025-how-ai-is-transforming-compliance-3da3f6450399
3) Les ennemis invisibles de la qualité des données
Omission : le fléau silencieux de la fiabilité (exclusion de données qui vont à l’encontre d’objectifs)
Inflation et duplication : fumée et miroir (surperformance en manipulant les données … compter plusieurs fois un contrat)
Déformation : la vérité prise entre deux feux (deux interprétations différents de mêmes données)
Guerres de définitions : quand le langage devient une arme (refus de s’accorder sur des définitions communes … un client, utilisateurs … actifs…).
Silos de données : forteresses de méfiance (voir le sujet sur la résistance à la gouvernance des données).
4) La dégradation des données (data rot)
Dans l’amplitude du flux de production de données, on ne se rend pas compte de la perte de fiabilité.
Avec insidieusement la saturation et la perte de confiance.
La gouvernance des données doit avoir en tête l’objectif d’ajuster la charge mentale liée aux données (flots de tableaux de bord, manque de contexte, non alignement avec les questions du quotidien, changements des sources non intégrés, remise en cause des chiffres … alors que les prises de décisions s’accélèrent et sont continues).
Vécu : plus d’une centaine de tableaux de bord pour piloter un processus. La simple lecture du ppt contenant ces tableaux de bord était une charge mentale extraordinaire. Jusqu’à enfin l’idée de simplification.
Source : https://tdan.com/all-in-the-data-brain-rot-vs-data-rot/33009
5) L’infrastructure technique des S.I. doit répondre aux exigences de la gouvernance des données
L’architecture S.I. / data (flux, stockage, hébergement, data platforms…) doit être en mesure de répondre aux besoins de gouvernance. Exemples : capacité de décentralisation par domaines, gestion de métadonnées actives, gestion des droits à la racine des données, contrôles finops – qui paie à quels coûts , observabilité des données support des data contracts, approbation de produits de données, garantie réglementaires…
Source : https://medium.com/version-1/data-governance-that-scales-3f90eec4ad35
6) Total Cost of Ownership – TCO – vue d’ensemble
L’erreur la plus couteuse en architecture data
« Confusing Run Cost with Total Cost of Ownership(TCO) »
« Run cost is like looking at the price of a gym membership and forgetting about the commute, the shoes, and the guilt of not going.
It’s the visible part of a very large, very expensive iceberg called Total Cost of Ownership (TCO). »
L’article détail le TCO dans un cadre data – vue d’ensemble : « TCO = Run Cost + Process Cost + Interoperability Cost + Human Effort + Flexibility Cost + Change Management Cost + Oppurtunity Cost ».
Valeur et pouvoir des données
1) Toujours plus de pouvoir des données : ICE, DOGE, Palantir…en temps réel
Dans la suite des revues précédentes (https://www.datassence.fr/?s=DOGE ).
« L’ICE prévoit un système de surveillance intégrant davantage de flux de données et une surveillance continue (24h/24 et 7j/7) ». Source : https ://flowingdata.com/2025/10/07/ice-planning-a-surveillance-system-that-integrates-more-data-streams-and-24-7-monitoring/
2) Et aussi quand l’esprit DOGE essaime
Le modèle d’action du DOGE (par les données) s’exporte.
A lire la chronique d’Hubert Guillaud (toujours aussi intéressante).
Avec (vision données) : les violations d’accès aux données, la récupération de données gouvernementales au-delà de leur finalité initiale et leur utilisation sans contrôle, sans contexte (dont par l’IA) avec les dangers associés. Source : https://danslesalgorithmes.net/2025/10/15/apres-le-doge-les-doges/
3) Quand l’arrêt de publication de données suite au shutdown US obscurcit la vision des décideurs politiques y compris à l’extérieur des US. L’exemple des Banques Centrales (Japon) dépendantes des données de la FED. Source : https://www.reuters.com/world/asia-pacific/data-darkness-us-spreads-global-shadow-2025-10-15
4) Le nerf de la guerre, la monétisation de nos données par la publicité
Et l’IA générative n’y échappera pas. Avec l’exploitation des conversations pour cibles des publicités. Et on imagine bien en poussant le bouchon plus loin, jusqu’où cela peut aller !
Sources : https ://www.lebigdata.fr/meta-ai-ce-bon-vieux-zuck-va-fouiller-vos-discussions-pour-cibler-ses-pubs
5) Les données de santé (ici UK) un trésor plus qu’attirant
Voir l’exercice conjoint de Larry Ellison (Oracle) et Tony Blair (et son think tank TBI) sur le sujet. Avec l’IA en fond.
« the NHS and its unique population-level health data. Tech experts talk about Britain’s health records in almost hushed tones. While Europe and the US have some comparable health data sets — such as US veterans’ medical records — none have the depth and breadth of NHS records dating back to 1948. Its potential commercial value, from drugs to genome sequencing, has been estimated at between £5 billion and £10 billion per annum ».
« In May 2024, TBI wrote a report that called for “two radical actions” to fix Britain’s “data access problem”: create a “single front door” providing “seamless access” to NHS data; and host all of this data outside the NHS, while retaining government control of the program. »
« Less than two months after Starmer’s win, TBI health policy director Charlotte Refsum was invited into the health department to meet digital policy chief Felix Greaves, documents obtained under FOI show. Greaves asked for her help in designing a giant public consultation on GP data and digital health ID. »
Source : https://www.crikey.com.au/2025/09/26/tony-blair-larry-ellison-ai-influence-nhs-data/
Données synthétiques – étude de cas sur une population à risque
Le cas des données synthétiques appliqué au données sur les victimes de la traite des êtres humains.
Pour préserver l’identité des individus transformés en unité statistique et dont la traduction en données synthétiques doit préserver tout risque de ré-identification.
Mais avec les limites des données synthétiques : politiques, éthiques et juridiques.
L’article étudie ces limites sur le cas cité, à l’aide du cadre de L. Taylor « What is data justice? The case for connecting digital rights and freedoms globally » – https://journals.sagepub.com/doi/full/10.1177/2053951717736335
Économie politique : qui contrôle la technologie et les infrastructures de synthèse ? Avec le biais de l’asymétrie entre un acteur économique (Microsoft dans l’article) puissant et des populations sans « moyens » – asymétrie de pouvoir
(In)visibilité : quelles populations sont rendues visibles, invisibles ou abstraites ? Qui ou quoi est rendu visible par les ensembles de données synthétiques ? (avec l’exemple de quartiers rendus visibles alors que les individus sont invisibilisés … mais impacté suivant leur quartier, leur groupe d’appartenance).
(Dés)engagement : les personnes concernées peuvent-elles exercer un choix ou retirer leurs données ?
Non-discrimination : comment les biais et les fabrications inhérentes aux données synthétiques affectent-elles leur représentativité ? (véhicules de stéréotypes et aussi « Second, tabular synthetic data constitutively rely on what Lee et al. (2025) call “intersectional hallucinations”: the fabrication of attribute combinations that do not exist in the original data modelled by synthetic data. ».
« “There’s a kind of quirk with the synthetic datasets that the synthetic data is not the best representation of the kind of cases with a combination of attributes. The aggregate dataset is the better kind of representation of that.” »
…et les risques de détournement comme la constitution d’une base de données des itinéraires de traite avec le risques de profilage et de surveillance accrue de populations déjà sensibles.
L’article fait appel aussi aux analyses précédentes dont « Jacobsen (2023), on the other hand, subtly demonstrates how various companies position synthetic data as a fix to the ethical problems of machine learning algorithms, allegedly rendering them risk-free. He argues against this, proposing that scholars remain attentive to how synthetic data shape ideas of the social good, (ab)normality, and notions of difference. »
Source : https://journals.sagepub.com/doi/abs/10.1177/20539517251381670?ai=2b4
Les données à fort enjeu : les données d’identification et le travail invisible d’interopérabilité
1) La maîtrise des identités / identifiants
Celui qui les maîtrise est le roi du monde.
NB : dans le cas des individus citoyens à ne pas laisser entre les mains du privé – lui laissé mettre en place ses systèmes de contrôle d’identité (sauf si un esprit libéralisme va jusqu’à ne plus se soucier de l’identité des personnes).
En 2026 EIDAS 2.0 entrera en vigueur en Europe. A suivre…
2) Data interopérabilité et data friction : le travail invisible sur les données – cas de l’identification de personnes
Quand le renforcement de l’interopérabilité objectif de toute bonne architecture de données peut aussi à contre-courant être au contraire réduite. Avec autour du renforcement ou de l’affaiblissement l’idée de data friction Edwards, 2010 (complétée par : l’idée d’encouragement des data frictions plutôt que de les surmonter – Bates (2017) et de coûts associés – afin de rendre visible les data frictions Pelizza (2016
L’interopérabilité est un sujet politique (voir : https://www.datassence.fr/2025/09/23/revue-data-du-mois-juillet-et-aout-2025/?highlight=politique#_ftn32 )
L’article s’intéresse au cas de l’identification de ressortissants de pays tiers – migrants dans les systèmes – infrastructures de données du pays d’accueil : systèmes administratifs, agence d’immigration, systèmes de contrôle – policiers – frontaliers…
L’interopérabilité pour ré-identifier correctement les personnes avec les data friction à lever (doublons, qualité des données personnelles – incomplètes – obsolètes – erronées, incohérences, normes différentes entre systèmes, oubli des données anciennes).
Avec les couts invisibles pour résoudre les frictions (couts organisationnel, couts de normalisation, justification des données, mise en place de systèmes passerelles – rapprochement de données – transcodification). Dont les « IT human middleware »* que l’on retrouve nombreux dans toutes les organisations – qui extraient, transforment, traitent les incohérences, nettoient, intègrent des données entre différents systèmes. NB : un travail sur les données invisibilisé indispensable au fonctionnement des S.I.
* terme adopté au cours d’une mission sur les échanges de données que j’ai mené, d’identification de ces personnes dans un grande banque.
Sur le sujet de l’identification voir aussi le règlement eIDAS et la loi sur l’interopérabilité en Europe qui considèrent l’identification transfrontalière comme une condition préalable à la fourniture de services à l’échelle européenne (interopérabilité : juridique – lois harmonisées, organisationnelle – processus harmonisés, sémantique – garantie d’interprétation, syntaxique – garantie d’exactitude, technique – garantie de fonctionnement inter-systèmes).
Il existe des cadres de qualification de l’interopérabilité qui proposent différents axes, niveaux d’interopérabilité (voir les références dans l’article) : stratégique, politique, tactique, opérationnel, syntaxique, fonctionnel, sémantique, technique, gestion – data management et lié aux tâches de l’utilisateur.
Source : https://journals.sagepub.com/doi/abs/10.1177/20539517251388349
Le monde des données est un monde continu … sans fin
Les données sont l’expression de notre rapport au monde. Et ce monde est tout sauf statique.
Le travail sur les données n’est jamais terminé : drift data, nouvelles sources de données, évolution des schémas, évolution des variétés-volumes, reconfiguration des processing data (pipelines)… tout en essayant de conserver une cohérence d’ensemble (rôles des métadonnées, des couches sémantiques… de la gouvernance).
L’article décrit le cas de la modélisation de données … qui doit être vue comme un travail continu et non pas comme une activité projet à terminer.
« Le modèle de données est le reflet vivant de l’entreprise, et à mesure que celle-ci évolue, le modèle doit évoluer avec elle, non pas par à-coups, mais de manière fluide et continue.
Elle part du principe que la carte ne sera jamais le territoire et que notre rôle est de la maintenir aussi utile et précise que possible, en permanence. » Source : https://practicaldatamodeling.substack.com/p/the-done-delusion-why-data-modeling
Vrac (Numérisation de l’Histoire, Grille de lecture quantique appliquée aux données, Nos données après notre mort, OpenData, Conservation des données telecom, Data et sport : le volley, L’offre data du London Stock Exchange Group)
1) Comment les historiens se sont appropriés le numérique et la collecte de données – un podcast de France Culture
« Pendant six ans, des dizaines d’historiens, historiennes et archivistes ont dialogué et réfléchi sur un blog wordpress pour envisager dans quelle mesure la manière de chercher et d’écrire l’histoire a été bouleversée par le numérique.
Ce qu’on pourrait se dire, c’est que la numérisation des fonds, accélérée ces dernières années bien qu’il reste encore de nombreux corpus exclusivement sur papier, a simplement rendu accessibles les archives. Optimisant au passage la mise en série de documents qui ont désormais le statut de données. ». Source :
2) Les questions de la mécanique quantique comme grille de lecture projetée aux données
Un article surprenant qui projette les questions de la mécanique quantique sur l’univers des données (exercice d’analogie) et qui résume bien que les données ne sont pas de simples objets directement accessibles / lisibles.
Avec : le rôle des métadonnées qui suivant leur présence / qualité offrent une vision claire ou floue des données, la traçabilité des données où comment mettre des intrications invisibles entre systèmes dans une chaîne / un pipeline de données, la difficulté d’une donnée de référence (originale – originelle, copie, clone … perturbent leur lecture … quelle est la vérité des données clients ?), les erreurs de qualité de données sont intrinsèques – c’est impossible de toutes les éliminer – l’essentiel s’assurer de la qualité continue du sens…
3) Un dossier de la CNIL quel statut et que deviennent nos données après notre mort
Source : https://linc.cnil.fr/cahier-ip10-nos-donnees-apres-nous
4) Actualité OpenData – lancement d’une fabrique des données : https://opendatafrance.fr/lancement-fabrique-donnee-territoriale/
5) Actualité : règlement sur la conservation des données des opérateurs telecoms : https://www.clubic.com/actualite-583825-sebastien-lecornu-signe-un-decret-qui-valide-la-conservation-de-masse-des-donnees-par-les-operateurs-telecoms.html
6) Data et Sport : exemple du volley
et article présente une boîte à outils open source basée sur Python, qui étend la bibliothèque PyDataVolley et permet le traitement, la visualisation et l’analyse avancés des données de recrutement.
Une étude de cas portant sur la finale de la Coupe d’Italie 2025 entre Consolini Volley et Trentino Volley illustre l’impact concret de cette boîte à outils. Tout au long de la saison 2024-2025, Consolini Volley a affiché des performances supérieures à celles de Trentino Volley. Cependant, lors de la finale, Trentino Volley a mis en œuvre une stratégie tactique ciblée, inspirée par les analyses de la boîte à outils, qui a efficacement perturbé le jeu de Consolini. En conséquence, Consolini Volley a affiché une baisse générale de tous ses principaux indicateurs de performance lors de la finale.
Source : https://journalofbigdata.springeropen.com/articles/10.1186/s40537-025-01284-6
7) L’offre data du London Stock Exchange Group
Comment le London Stock Exchange Group (LSEG) tire un peu plus de 20% de ses revenus de la monétisation de données et « protège » ce business (propriété des données, non reproductibilité par exemple par des IA).
33 pétaoctets de données.
Dont une part issue des connexions avec 575 bourses et plateformes d’exécution à travers le monde.
Valeur ajoutée :
- Standardisation et traduction des données de marché dans un langage commun pour les transmettons directement aux institutions financières mondiales.
- Correction et enrichissement par plusieurs milliers de conseillers financiers et juridiques en y intégrant tout un contexte informationnel, transactionnel (25 000 contributions humaines) -> exhaustivité, exactitude, normalisation de curation (norme LSEG), étiquetage
Contrôle de la distribution des données auprès de partenaires / clients via MCP Model Context Protocol – surveillance des accès, éviter le téléchargement.
Et aussi à lire, confiance, données et produits basés sur l’IA : la vision de l’avenir selon la PDG du NASDAQ. Source : https ://diginomica.com/trust-data-and-ai-enabled-products-how-nasdaqs-ceo-sees-shape-things-come
RDV maintenant en décembre pour la revue et les actualités de novembre.
Les commentaires sont fermés.