Dernière modification le 12 mars 2024
Cette revue est basée sur un ensemble de publications du mois de février 2024, issues de sources en lien avec le sujet Data. A piocher suivant vos centres d’intérêts.
Pour ce mois de février les deux sujets pivots, actualité des data platforms et actualité data et IA. La fin des tendances 2024 , le sujet des data architectures et on parle déjà de data mesh 2.0.
Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.
Sommaire :
- Data platforms
- Data et IA
- La fin des tendances data 2024
- Data qualité (et encore l’IA)
- Data architecture
- Data mesh 2.0
- En vrac (le duo données et contexte, data unicorn, données synthétiques, effacer les données, métadonnées pour les financiers, l’hiver data)
Data platforms
L’IA au service des data platforms :
Observabilité des données augmentée par l’IA : Dynatrace® Data Observability, suivi de la disponibilité des couches d’infrastructure de delivry des données, de la fraicheur, de la qualité, du lineage, de l’évolution des schémas, de la variation de volume, de la distribution des données (valeurs aberrantes, écarts), le tout sous l’œil de l’IA (root cause analysis, prédictif…).
Sources : https://www.dynatrace.com/news/press-release/dynatrace-unveils-data-observability-for-its-analytics-and-automation-platform/ et https://www.dynatrace.com/platform/artificial-intelligence/
Les data platforms au service de l’IA :
Performance de volumes, de calculs pour aller vers le temps réel : moteur data exploitant les dernières innovation hardware (distribution GPU). Acquisition de Claypot IA (real time IA) par Voltron data (NB : utilisé par Snowflake pour son infrastructure data).
Sources : https://www.datanami.com/2024/02/01/voltron-aims-to-unblock-ai-with-gpu-accelerated-data-processing/ et https://voltrondata.com/resources/voltron-data-acquires-claypot-ai
La fusion naturelle entre data platform et AI platform, un tour d’horizon des fonctions et briques technologiques à prendre en compte. NB : et bon courage à ceux en charge de l’intégration en construction et en exécution !! Rappel L’INTEGRATION le pain point numéro 1.
Le partenariat entre Vast Data (data infrastructure) et Run:ai pour l’orchestration pour l’IA https://insidebigdata.com/2024/02/13/vast-data-and-runai-revolutionize-ai-operations-with-full-stack-ai-solution-powered-by-nvidia-accelerated-computing/. Sur Vast Data voir aussi la présentation faite ici https://www.datanami.com/2024/02/14/the-vast-potential-for-hosting-genai-workloads-data/
Et aussi l’enquête menée auprès de 500 data leaders sur comment l’IA générative pousse à faire évoluer les data stacks – https://hakkoda.io/state-of-data-report-2024/
Source : https://www.datanami.com/2024/02/26/hakkoda-study-reveals-the-need-to-modernize-data-stack-in-2024/
Extrait : « While all roads lead to GenAI, organizations will have to pass through data quality and governance hurdles. One of the key factors in an organization’s ability to overcome these challenges is leadership alignment. »
Dans la suite du rôle de l’infrastructure data, capacité des data platforms à exploiter des données issues de différents environnements hybrides. Dans la longue liste des éditeurs de data platforms issus du stockage, la proposition d’Actian (pour ceux qui l’ont connu – à l’origine de la base de données Ingres) – https://www.actian.com/data-platform/
Et pour ceux qui s’intéresse à la lignée des data platforms issues de l’univers des bases de données – voir la revue et l’analyse proposée par Ventana – https://www.ventanaresearch.com/value_index/data/data_platforms/market-report/2023 (Actian, EDB Postgres, IBM DB2, MariaDB, Microsoft SQL Server, SAP HANA…).
L’architecture MDS (Modern Data Stack), sa genèse (ETL -> ELT, découplage stockage-calculs), ce quelle est (plus que du stockage, du calcul), c’est aussi de l’orchestration de services, du data management, de la sécurité, de la gestion de politiques de données, de l’observabilité…, son devenir (surveillance de la performance des données, adopter l’IA générative).
Source : https://tdan.com/the-modern-data-stack-why-it-should-matter-to-data-practitioners/31557
Le défi du partage rationnalisé et en toute confiance de données (exemple du changement climatique avec les multitudes de sources de données et d’interlocuteurs) : besoin d’un cadre de confiance (transparence, preuve en interopérabilité de bout en bout entre tous les acteurs), pour ouvrir les données (sur les exemples de l’open banking, de l’open energy). Vue de quelqu’un qui a présidé l’open bankink et connu l’open energy : montrer comment le cadre va résoudre les problèmes existants, apporter de la valeur et gérer les risques (dans l’open banking, les régulateurs ont joué un rôle clé – menace, dans l’open energy la pression des reporting carbone). Un cadre sans centralisation, sans blockchain mais basé sur la circulation encadrée/contrôlée des données (gestion de consentements de transferts de données, gestion de contrats d’échanges – protection juridique, gestion de contrats d’interface entre systèmes– protection technique – exemple capacité de révocation d’API). Avec comme conclusion : commencez à construire votre cadre de confiance des données avant de parler de stack data. Le succès passe par là.
Source : https://diginomica.com//why-sustainability-data-sharing-needs-start-trust-framework
Construire une data platform en 2024. Ce qui a changé depuis 2/ 3 ans : le niveau d’échelle des données à gérer, on se rapproche des acteurs data de type Netflix, Uber…, le temps réel, le streaming arrivent en force, l’orchestration des traitements sur différentes données, différents systèmes sources devient un sujet central (voir Airflow), il faut être en mesure de joindre les données de N sources, l’ingénierie logicielle doit s’appliquer aux données / traitements de données (la force de Dbt), la data visualisation évolue avec l’arrivée de nouvelles approches (voir Streamlit racheté par Snowflake – 2022), la production d’insight doit intégrer les systèmes de production (voir l’idée d’ETL inversé – exemple Hightouch), l’observabilité des données est devenue une nécessité (rôle clé des métadonnées, du lineage de bout en bout, pour surveiller les plates-formes, leur contenu, leur activité (voir Monte Carlo et Great Expectations). Le constat, il n’existe pas de solution avec un fournisseur unique. Même s’il y a une course à l’armement aujourd’hui.
Voir aussi : https://thenewstack.io/the-architects-guide-to-the-modern-data-stack/
Toujours la tendance vers le temps réel et ses défis. Un nouvel acteur https://www.artie.so/ (real time database replication).
Une proposition de valeur par Neurelo (https://www.neurelo.com/ ), proposer la génération automatique des interfaces entre applications et sources de données et lever ainsi la difficulté pour les développeurs de créer des interfaces ad hoc à chaque fois en mobilisant N technologies différentes. L’idée est de générer un set d’API à partir d’une description schéma as code. Source :
Et pour finir, le retour de la propriété ACID (atomicité, cohérence, isolation et durabilité) transactionnelle dans les stacks data, avec le défi des formats de données et le rôle des métadonnées. Source : https://www.datanami.com/2024/02/26/putting-your-data-on-the-table/
Data et IA
1) Interroger « naturellement » par un moteur LLM (IA générative) ses bases de données. Un article explicatif sur un exemple simple. Source :
https://towardsdatascience.com/querygpt-63fdfefaa888?source=rss—-7f60cf5620c9—4
Autre exemple de l’apport d’un moteur d’IA pour les données : la labélisation automatique d’images
Source :
2) IA et données d’entreprise
2.1) Le rôle de l’approche RAG (retrieval augmented generation) en lien avec un moteur LLM pour que les résultats de l’IA générative se base sur les données d’entreprise. Source :
https://fr.blog.businessdecision.com/rag-enrichir-ia-generatives-avec-donnees-entreprise/
2.2) Comment intégrer ses données dans un moteur d’IA. Source :
2.3) Pourquoi exploiter les sources de données externes pour ses besoins via l’IA. Avec des exemples dont, l’exemple dans le domaine du recrutement, la combinaison de sources externes (« Google Scholar, GitHub, Quora, Kaggle, and LinkedIn ») pour identifier les profils potentiels. Autre exemple dans le domaine de l’investissement. Source :
https://hbr.org/2024/02/external-data-and-ai-are-making-each-other-more-valuable
3) La couche sémantique sur les données, une brique indispensable aux moteurs d’IA : pour la construction du contexte d’analyse des données fournies à l’IA, pour le dialogue utilisateurs sur les données via l’appui d’une IA (interroger les données en langage naturel), pour le contrôle des résultats fournis par l’IA (conformité à la couche sémantique, conformité à des politiques d’accès aux données insérées dans la couche sémantique – exemple sensibilité des données). Source :
https://www.kdnuggets.com/2024/02/cube-semantic-layers-missing-piece-ai-enabled-analytics
4) Le sujet sensible, clé, de l’origine des données utilisées par les moteurs d’IA. Un tour d’horizon proposé par Fred Cavazza. Il ne faut pas se mentir, il s’agit de la face obscure de l’IA générative. Comment se justifie la prise en compte de vaste jeux de données, images d’artistes, textes produits, livres, publications scientifiques.. résultat d’une somme gigantesque d’efforts … sans contrepartie ? Avec quels risques (qualité, biais, détournements…). Source : https://fredcavazza.net/2024/02/14/lembarrassante-question-de-lorigine-des-donnees-dentrainement-des-ia-generatives/
Voir aussi sur ce sujet, le travail de Antonio A. Casilli (https://www.casilli.fr/) sur les travailleurs des données au service des IA.
Et ce qui est dit ici « There’s no getting away from manual curation, some experts would argue — at least not if one hopes to achieve strong results with an AI model. The largest vendors today, from AWS to Google to OpenAI, rely on teams of human experts and (sometimes underpaid) annotators to shape and refine their training datasets. ». Source : https://techcrunch.com/2024/02/22/datologyai-is-building-tech-to-automatically-curate-ai-training-data-sets/
5) Dans la suite de l’origine des données, plusieurs articles sur le traitement de la qualité des données pour les moteurs d’IA :
Toutes les données ne sont pas égales, ne valent pas la même chose en fonction de la cible de l’IA (exemple pour générer des emails), DatalogyAI – https://www.datologyai.com/ – se positionne sur ce créneau et propose la conception de jeux de données adaptés (d’apprentissage) en fonction de la cible du moteur d’IA : ciblage des données suivant la cible générative, enrichissement conceptuel, mise en qualité, contrôle éthique (sujet sensible des données d’entraînement avec des données non appropriées).
Et une bonne citation à avoir en tête de Y. Le Cun : « “Models are only as good as the data on which they’re trained, but identifying the right training data among billions or trillions of examples is an incredibly challenging problem,” LeCun told TechCrunch in an emailed statement. » Source l’article déjà précédemment cité : https://techcrunch.com/2024/02/22/datologyai-is-building-tech-to-automatically-curate-ai-training-data-sets/ et aussi https://siliconangle.com/2024/02/22/datologyai-raises-11-65m-automate-data-curation-efficient-ai-training/
6) Une approche intéressante par SyntheaticAI https://www.synthetaic.com/ . Fournir un croquis à une IA, et elle repère les images qui comportent un objet ou une situation correspondant au croquis, sans passer par un apprentissage supervisé. C’est-à-dire sans une intervention humaine de labélisation des images d’apprentissage.
Source :
La fin des tendances data 2024
(voir la revue de janvier : https://www.datassence.fr/2024/02/10/revue-data-du-mois-janvier-2024/#_ftn1)
- L’analyse automatique des données par l’IA attendue dans toutes les data platforms.
- Avec le sujet du contexte aux données indispensable et dans la logique de l’approche RAG (retrieval augmented generation).
- Le génie logiciel pour les traitements de données (Enfin !).
- L’observabilité des données, sur toutes les données (structurées, non structurées, en vecteur, en streaming), de façon dynamique
- Le big data évolue (il devient petit !). J’aime bien l’image « Now, with modern Macbooks boasting the same computational power as the AWS servers Snowflake launched their MVP warehouse on in 2012 »
- Maîtriser les couts d’infrastructure – cloud (les dépenses peuvent augmenter de 30% par an !)
- Le format Apache Iceberg couteau suisse pour permettre l’interrogation des données de N façons (dont SQL)
Source : https://barrmoses.medium.com/top-10-data-ai-trends-for-2024-7f830196db65
Le temps réel de bout en bout, de la prise en compte des données transactionnelles à leur analyse.
L’IA générative s’attaque aux données structurées (interrogation en langage naturel, dialogue pour la construction d’analyses, construction de data products).
Convergence (logique) entre les fonctions de data sharing et l’approche par produit de données (data products).
Tendances ETL : temps réel (encore), gestion des données non structurées, cloud natif, doit s’intégrer dans une logique d’orchestration des traitements, mappage des données facilité par l’IA, intégration by design dans les traitements des règles de gouvernance et de sécurité. Source : https://dataconomy.com/2024/02/12/future-trends-in-etl/
Data qualité (et encore l’IA)
Penser la data qualité en la combinant au niveau patrimoine des données (assets) et data product : avec l’exemple dans Dbt (et le rôle des métadonnées – fichiers dbt yml), de l’équipe d’Airbnb de scores qualité attachés aux data products. Source :
https://medium.com/@mikldd/measuring-data-quality-bringing-theory-into-practice-41742e54d62f
Sans surprise, le sujet de la qualité des données est au cœur de l’IA générative en entreprise – étude Informatica présentée ici : https://www.datanami.com/2024/02/05/data-quality-top-obstacle-to-genai-informatica-survey-says/
Mais attention, l’IA générative n’est pas faite pour intervenir directement sur la qualité des données structurées. Elle peut indirectement aider à produire du code, des règles de contrôle qualité.
Elle peut aussi faire le lien entre des données structurées qu’elle sait extraire de documents (données non structurées) avec des données structurées connues par ailleurs. Et ainsi permettre des contrôles. Source : https://tdan.com/data-speaks-for-itself-is-ai-the-cure-for-data-curation/31552
NB : avec toujours les deux facettes de l’IA par rapport aux données, l’IA a besoin de données de qualité. Et l’IA peut être au service des données … pour leur mise en qualité.
Enfin, l’exemple impressionnant de la construction d’une base mondiale des bâtiments sur fond géographique (avec plusieurs milliards d’instances à intégrer) – https://overturemaps.org/ et le rôle d’appui de l’IA pour : la déduplication, le discernement des bâtiments sur images (exemple satellites), la classification des bâtiments, l’attribution d’un identifiant stable. Source : https://insidebigdata.com/2024/02/12/scaling-data-quality-with-computer-vision-on-spatial-data/
Data architecture
Partage d’idées autour des architectures de données :
- Prendre du recul par rapport à la frénésie et à la course aux nouvelles technologies, aux nouvelles solutions data ! Que faire face à l’abondance de solutions ?
- Partir du produit final qui sera proposé aux consommateurs, utilisateurs finaux : délais de livraison attendus, niveau d’observabilité envisagé (alertes sur quel périmètre), comment la documentation- catalogage sera établie, avec quelles métadonnées (et leur origine), interfaces de consommation de données attendues, s’appuyer sur des stratégies de collecte bien formalisées, par lots ou en temps réel -> quels cas d’usage, quelles données de référence, le modèle de données parfait et couvrant tous les cas d’usage n’existe pas …ne pas se laisser déborder par les cas d’usage atypiques.
- Ensuite faire le choix de construire ou d’acheter (avez-vous les compétences pour construire ? quels dépendances acceptez-vous vis-à-vis d’un fournisseur ?)
- Comment éviter de transformer en marais vos supports de stockage de données (du data lake au data swamp) : rôle de la gouvernance de données opérationnelle (implémentation de politiques : qualité, catégorisation de données, régulation, utilisation des données, traçabilité, règles liées au cycle de vie dont la fin de vie – archivage – suppression des données. Le tout comme fonctions d’appui au data stewardship),
- Data lake house quelle réalité entre un DW et un Data lake : le rôle clé du requêtage de données – SQL multi-sources, le choix de formats multi-natures de données et multi-usages, comment assurer la capacité multi-accès aux données
- Stocker les données c’est bien, mais stocker les événements qui ont produit ces données cela peut être plus intéressant (par exemple pour retracer un historique, créer des alertes plus rapidement. NB voir l’exemple d’implémentation auquel j’ai participé ici : https://www.insee.fr/fr/information/7722095?sommaire=7722116)
- Adopter ou non la représentation data vault (personnellement, j’évite sur la base du principe d’être le plus aligné sans rupture de représentation entre les sources de données connues des métiers et les usages de ces données. Le fait d’introduire une rupture de représentation perd les acteurs métiers).
- L’approche microservices pour les données versus une approche monolithique, se justifie de plus en plus, d’autant que les données sont reparties et cela plus particulièrement dans différents clouds.
- L’objectif d’une couche sémantique proposant une vue unifiée des données devient central. Avec différentes approches : par virtualisation, par catalogage/data shop, par la constitution d’une couche sémantique externe ou interne à une data platform (pour ses propres données mais aussi pour des données d’autres supports), au travers d’une gestion des traitements multi-sources/multi-stockages (comme Dbt le propose), en complément d’un moteur distribué SQL, et bien entendu via une IA générative ( !), etc. Le tout s’appuyant sur un plan de métadonnées.
- Ce dernier point est central : toute data architecture doit être metadata centric. Ou autrement dit les métadonnées sont la glue de toute architecture de données. Avec la question première : quelle stratégie avez-vous sur les métadonnées ?
Sources :
https://medium.com/@anmol.aj/data-philosophy-blueprint-for-data-architecture-1a0a3589e1fa
https://www.kdnuggets.com/a-data-lake-you-call-it-it-a-data-swamphttps://www.datanami.com/2024/02/06/the-data-lakehouse-is-on-the-horizon-but-its-not-smooth-sailing-yet/
https://insidebigdata.com/2024/02/02/introducing-the-streaming-datalake/https://towardsdatascience.com/microservices-vs-monolithic-approaches-in-data-8d9d9a064d06?source=rss—-7f60cf5620c9—4
https://siliconangle.com/2024/02/20/metadata-glue-federated-data-silos-metadata-governance/https://www.dataversity.net/hybrid-architectures-in-data-vault-2-0/
Data mesh 2.0
On parle déjà de la 2.0 du data mesh : aller plus loin dans l’avantage à l’échelle, vers une vue d’ensemble avec plus de confiance pour la découvrabilité, l’accès et l’usage des données. Avec la gestion de la connaissance des données au centre (contextualisation, métadonnées).
Cela passe par encore plus d’attention au maillage : comment des produits de données interagissent pour plus de valeur et comment assurer cette interaction ? Mise en avant du rôle de la gouvernance fédérée : alliant initiatives locales et règles de cohérence globales (principes d’interopérabilité : métier et technique), le tout automatisable.
Les défis du data mesh : disposer d’une infrastructure data commune – on parle aussi de data platform horizontale (avec les compétences techniques spécialisées indispensables) versus chaque domaine métier choisit ses solutions techniques (attention à ce que chaque domaine métier ne réinvente pas ses solutions pour des problèmes partagés / communs à chaque domaine – la collaboration entre domaine métier doit être pensée). Avec l’idée de provisionnement de ressources d’infrastructure à la demande (réponse aux besoins métier, exemple exécution de pipelines pour ses data products).
Au centre d’une data platform horizontale : la gestion de la vue d’ensemble des données du maillage grâce aux métadonnées et une gouvernance axée sur l’interopérabilité au sein du maillage. Avec la possibilité de gestion de data products inter-domaines métier. Et avec l’idée d’observabilité « étendue » aux liens entre data products.
Source :
NB : La qualité des données dans le data mesh ne s’arrête pas à la qualité des data products. Mais va jusqu’à la qualité du maillage. Et c’est sa force, sa capacité de passage à l’échelle.
Cette qualité dépend de la gouvernance fédérée, avec l’Idée d’enchâssement des règles de gouvernance suivant la portée d’usage / d’influence du data product :
- Portée locale : règles locales (définition par le domaine métier)
- Portée interfonctionnelle (exemple dans le cadre d’un processus inter-domaines, d’un suivi de bout en bout, d’une vue 360°) : règles interfonctionnelles (définition par le cadre interfonctionnel – domaines concernés, responsable de processus…)
- Portée globale : règles globales (définition de niveau entreprise – stratégique, d’agrégation – exemple pour les systèmes de compta-gestion, suivant des expertises transverses – juridique – sécurité – risques – compliance…)
Rappel de ce que dit Zhamak Dehghani sur la qualité du maillage :
- Elle dépend des politiques – des règles de gouvernance (définition et application) à respecter. Ces règles sont issues d’exigences de gouvernance. Exemples d’exigences / de politiques : d’interopérabilité, de sécurité, d’accès, réglementaires…
- Elle dépend des relations entre domaines métier : producteurs / consommateurs (rôle « oublié »)
- Elle implique :
- Les domaines métier : qui sont responsables et autonomes au niveau des data products (principe de base du data mesh)
- Des collectifs de domaines métier et le niveau global : qui sont responsables de définir les règles collectives
- L’IT en charge d’automatiser au maximum les règles de gouvernance dans les plates-formes data (stockage, échanges…). La fédération s’applique aussi à la gouvernance IT des différentes plates-formes (qui doivent supporter le maillage).
- Elle doit suivre le changement continu qui entoure les données. Le changement est intrinsèque aux données. Il n’est pas une exception. La gouvernance doit être bâtie sur cette base : réduire toutes les frictions qui impliquent du délai, des efforts dans la circulation et manipulation des données.
A voir par rapport à ce sujet, la façon dont les équipes data sont constituées et positionnées : centralisées (mutualisation, mais goulot et risque d’obésité), décentralisées (autonomie plus forte mais risque de double effort et sujet du plan de charge), fédérées avec des approches mixtes.
Voir ce qui est dit dans cet article : https://medium.com/coriers/centralized-vs-decentralized-vs-federated-data-teams-05dc14e8338d
Un domaine de données particulier (au sens data mesh) : l’ERP, le CRM, le progiciel RH, de GMAO et souvent les chaines d’instances de ces systèmes dans les grandes entreprises (le progiciel RH de la filiale, qui communique avec le progiciel RH Groupe).
Les données dans ces systèmes ont une représentation complexe (se frotter à un modèle SAP par exemple) et le contexte des données est inscrit dans la logique du progiciel.
En faire un domaine métier est souvent une évidence, avec les indispensables sachants pour interpréter les données et les exploiter ensuite en data products. Une fois cet effort fait, cela va faciliter l’accès à ces données, les faire rentrer dans le cadre data mesh pour le bénéfice de tous.
En vrac (le duo données et contexte, data unicorn, données synthétiques, effacer les données, métadonnées pour les financiers, l’hiver data)
1) Un bel exemple du duo données et contexte indispensable pour la bonne utilisation des données :
https://diginomica.com//how-uk-water-industry-collaborating-contextualize-water-data
Et un autre exemple sur comment l’UNESCO veut recueillir les données pour mesurer l’éducation des enfants dans le monde
https://www.weforum.org/agenda/2024/02/unesco-data-gap-global-education/
2) Qui sont les licornes de données (data unicorn) et en quoi ils se différencient ? Je dirais des acharnés du sens des données sachant exploiter tous les ressorts des techniques data. Analyste (data) programmeur … dans l’ancien temps.
3) Toujours le sujet des synthétiques data (voir par exemple dans la revue de janvier – Les données synthétiques : le bien et le mal : https://www.datassence.fr/2024/02/10/revue-data-du-mois-janvier-2024/#_ftn6
Avec ici, comment générer des données synthétique sur la base de données recueillies et ne pouvant pas être utilisées pour des raisons de sensibilité. Et comment s’assurer de la similarité des deux jeux de données : réelles et synthétiques. Source :
Et un article sur le risque de réidentification et l’impact des données synthétiques par rapport au RGPD. Source : https://journals.sagepub.com/doi/abs/10.1177/20539517241231277?ai=2b4&mi=ehikzz&af=R
5) On en parle beaucoup moins, mais savoir effacer des données … peut être aussi important que d’en créer. Exemple – et source : https://www.lebigdata.fr/mozilla-monitor
Et challenge, tout en tenant compte de systèmes de recovery de données : https://www.smartdatacollective.com/data-recovery-services-crucial-in-big-data-era/
6) Les métadonnées sont centrales pour l’IT, pour les métiers mais aussi pour les financiers au travers du suivi des coûts financiers induit par la gestion des données. Source :https://www.datanami.com/2024/02/22/overcoming-the-financial-breaking-point-how-businesses-can-overcome-data-cost-anxiety/
7) Et pour finir – sommes nous proche d’un hiver data ?
Restriction des réseaux sociaux de l’accès à leurs données à des fins de recherche, difficultés du partage de données privé-public, privatisation et marchandisation des données climatiques, il y aurait une tendance à une diminution de l’accès aux données pour l’intérêt public. Au cœur du problème la facture entre ceux qui ont les moyens de recueillir les données et ceux qui veulent les exploiter pour le bien commun. Et facteur renforcé par l’arrivée de l’IA générative qui incite à moins partager ses données de peur de les retrouver dans les bases d’apprentissage. Avec le constat que le Data Act de l’Europe n’est pas au rendez-vous sur le partage de données (du fait d’avoir négligé l’aspect pratique, opérationnel du partage de données).
Maintenir les données accessibles à des fins publics est un défi.
https://sverhulst.medium.com/are-we-entering-a-data-winter-f654eb8e8663
NB : voir aussi sur ce sujet ce qui est dit dans l’ouvrage de Serge Abiteboul et François Bancilhon – « Vive les communs numériques ! » – volet données – https://www.odilejacob.fr/catalogue/sciences/informatique/vive-les-communs-numeriques-_9782415007980.php et aussi ce lien https://cnnumerique.fr/lettre-dinformation/cenum-la-lettre-du-conseil-62-communs-numeriques-et-democratie
RDV maintenant en avril pour la revue et les actualités de mars
Les commentaires sont fermés.