Press "Enter" to skip to content

Revue data du mois (octobre 2024)

Last updated on 28 novembre 2024

Comme d’habitude une suite de sujets data en lien avec un ensemble d’articles data du mois d’octobre.

Avec une tendance de fond et un point commun l’évocation dans une majorité d’articles de la rencontre (enfin) des données avec les bons principes de génie logiciel (sujet que j’avais déjà évoqué dans des revues précédentes).

Toutes les bonnes pratiques de l’ingénierie logiciel peuvent s’appliquer à l’ingénierie des données.

Même si avec les données des problématiques spécifiques sont à considérer.

Beaucoup d’acteurs data font des constats s’en appel sur la complexité des systèmes de traitements des données qui se sont constitués au fil du temps et sans garde-fous. Avec pour conséquence des systèmes lourds, fragiles, difficile à faire évoluer, où les ingénieurs data passent plus de temps à tenir à bout de bras les pipelines existants qu’à en développer de nouveaux.

Il est temps que la fracture entre les deux mondes disparaisse.

Sinon dans ce mois d’octobre, les sujets récurrents (Data mesh, Data product, CDO, Data et IA, Data workers, Couche sémantique, Self data). Et des zooms : données et monde de la santé, REX de problématiques data et l’association TOGAF + DMBOK au service de la stratégie data.

Et pour le reste, un rapide tour d’horizon d’une sélection d’articles data.

Sommaire :

Data mesh – précision de Zhamak Dehghani

Un article de l’autrice Zhamak Dehghani à l’origine du concept de Data Mesh « Le maillage de données n’est ni sociologique ni technique, il est sociotechnique ».

Où elle précise sa pensée :

  • Le data mesh ce n’est pas d’abord organisationnel puis technique, mais bien les deux ensemble qui doivent évoluer de concert,
  • « L’objectif du maillage de données a toujours été « l’innovation rapide des données à grande échelle » tout en intégrant « la diversité (personnes et technologie) et la complexité des organisations » en son cœur ». L’idée de data mesh rejoint l’idée de framework (structure d’accueil) à l’échelle de l’entreprise avec la capacité d’accompagner ses évolutions en termes de données

Et à suivre le pan technologique proposé par NextData – https://www.nextdata.com/

Source : https://www.nextdata.com/our-pov/data-mesh-is-neither-socio-nor-technical-its-sociotechnical

Data vault – le pour et le contre

Deux articles intéressants sur le sujet.

1) Un premier article (de fin septembre mais zappé dans ma revue précédente) de Philippe Nieuwbourg (je vous recommande de le suivre sur Linkedin – https://www.linkedin.com/in/pnieuwbourg/) et qui pose LA question clé du data vault : « Mais alors, comment combiner une gouvernance des données orientée métier, et une architecture data vault forcément gérée par une équipe informatique experte ? »

J’ai connu une tentative data vault au sein d’un data lake. Je m’y suis opposé parce que le modèle créait une rupture de modèle de données trop forte entre la vision métier et la vision implémentée (cf. principes de continuité de déclinaison des modèles en génie logiciel – de l’univers métier au modèle physique). Impossible au métier de s’approprier le modèle.

Après, je ne conteste pas l’apport du data vault en termes technique et d’évolutivité. Mais tant pis, je privilégie la lisibilité.

L’article met le doigt sur un point clé qui est la capacité de gouvernance des données gérées selon un modèle data vault. Tout y est très bien dit. Je vous conseille sa lecture.

Source : https://www.decideo.fr/Combiner-l-architecture-Data-Vault-et-une-gouvernance-des-donnees-orientee-metier_a13918.html

2) Et un article technique sur la mise en œuvre du data vault et de son intérêt pour corriger dynamiquement des séquences d’enregistrement non synchronisées dans le temps (le problème classique d’enregistrements qui arrivent en retard après les autres) et éviter ainsi d’avoir des défauts de qualité avec une charge assez lourde pour les corriger.  Source : https://medium.com/the-modern-scientist/data-vault-solves-time-crime-c9a2877b855f

Et si vous voulez en savoir plus sur le data vault, à lire l’ouvrage « The Data Vault Guru: a pragmatic guide on building a data vault » de Patrick Cuba. Et aussi plus ancien (2015) –

Building a Scalable Data Warehouse with Data Vault 2.0 – Par Daniel Linstedt, Michael Olschimke

Voir aussi le site : https://data-vault.com/ Et par rebond on peut aussi s’intéresser aux modèles vectoriels – « Vector Databases Are the Wrong Abstraction ». « Vector databases treat embeddings as independent data, divorced from the source data from which embeddings are created, rather than what they truly are: derived data. By treating embeddings as independent data, we’ve created unnecessary complexity for ourselves. » Source : https://www.timescale.com/blog/vector-databases-are-the-wrong-abstraction/?

La fonction de CDO au tournant de sa survie ?

Déjà que le métier de CDO n’était pas simple (cf. revues précédentes – https://www.datassence.fr/2023/07/17/revue-data-du-mois-juin-2023/#_ftn3). Certains envisagent leur disparition vaincus par l’impossibilité de démontrer leur valeur pour l’IA.

Avec un risque de se retrouver absorbé par l’IT.

Pour moi, c’est vrai que la place du CDO n’est pas simple, et l’arrivée de responsables IA (Chief AI Officer) n’arrange pas la chose. Mais dire que leur place sera dans l’IT, c’est ignorer les fondamentaux du rôle de CDO. Leur place n’est surtout pas là.

L’article parle également de la gouvernance des données comme une tâche administrative, un problème de tuyauterie. Horreur ! Article quand même intéressant ensuite par les commentaires de CDO sur leur rôle dans différentes entreprises. Source : https://www.cio-online.com/actualites/lire-deja-le-crepuscule-pour-les-chief-data-officers-15886.html

Un deuxième article tour de table de CDO sur leur fonction, dans le cadre du Snowflake summit 2024. Parenthèse amusante de voir la bataille Snowflake / Databricks auprès des CDO. L’article précédent évoquait un rapport « Voice of the CDO 2024 » sponsorisé cette fois ci par Databricks – https://dataleaders.net/chief-data-officers-reach-tipping-point-in-scaling-ai/

Quelques extraits … de bon sens :

« CDO, je pense toujours qu’ils sont en première ligne en matière de gouvernance, de confidentialité et de sécurité des données » … hum s’ils ne sont pas là, ils disparaîtront effectivement !

« Davey dit qu’il se concentre sur la compréhension du lien entre les objectifs de l’entreprise et ses donnée » … hum encore, voire effrayant si cela n’est pas dans l’ADN de tout CDO !

« Faites des données la responsabilité de tous » … un vrai challenge pour le CDO comment assurer cette transformation ?

« Tout d’abord, vous ne pouvez jamais répondre à toutes les demandes de données dans l’organisation. Mais il est important de se rappeler les priorités. » … une vraie difficulté, on ne peut pas traiter toutes les données … il faut se concentrer sur certaines données, mais le choix n’est pas toujours facile.

« Enfin, Haider affirme qu’il est important pour les CDO de « continuer à développer leurs capacités » en développant les compétences technologiques au sein de leurs organisations » … les données vivent dans un environnement technique, sans cet environnement au service des ambitions des CDO c’est impossible.

En bref et pour revenir au premier article, si les CDO veulent survivre, la base est déjà de respecter ces bases de bon sens.

Source : https://diginomica.com/heres-what-it-takes-be-successful-chief-data-officer

Données et monde de la santé

Une série d’articles sur exploiter efficacement les données de santé.

1) Comment pousser les données dans les soins ?

C’est un vrai sujet de gouvernance.

Avec :

« To this end, the World Economic Forum’s Digital Healthcare Transformation (DHT) Initiative is convening stakeholders to improve standardization, effective data sharing and good governance in healthcare data. »

Des questions clés que la gouvernance doit appuyer (parce que cela implique de la collaboration, des normes, des règles de partage des données, des principes d’interopérabilité, l’intégration de principes éthiques, comment partager les valeurs obtenues à partir des données, le défi de la confiance lorsque l’on touche à ces données avec en avant les sujets de confidentialité, de sécurité…) : « Reduce costs, save lives: how healthcare data can help emerging economies. How health data collaboration can help unlock inclusive healthcare. How to unleash the enormous power of global healthcare data »

Le croisement avec des données de contexte (comme les données météorologique pour l’anticipation des risques de certaines épidémies.

Source : https://www.weforum.org/agenda/2024/09/data-in-healthcare-standardization-governance-and-sharing-can-cut-global-mortality

2) Le sujet sensible de partage des données médicales à des acteurs privés, comme les sociétés d’assurance. Avec un potentiel élevé sur l’actuariat, via le développement de systèmes d’IA actuarielle pour analyser les risques et prédire l’état de santé.

Comment cela peut être vu comme une rupture de la confiance du public sur la gestion de ses données de santé ?

Comment cela peut être vu comme un intérêt public tout en garantissant la protection sur les possibilités de discrimination et de violation de la vie privée (dépersonnalisation des données)  ?

L’article montre que « Les assureurs utilisent les données de population pour identifier de nouvelles catégories de risques, qui deviennent de la matière première pour la production d’algorithmes actuariels en boîte noire.  Le déploiement de ces algorithmes, comme nous le soutenons, a le potentiel d’accroître les inégalités en matière de santé et de réduire l’accès à l’assurance. ».

La question clé : la logique d’assurance est nécessairement discriminante au sens identification de groupes à risques. Comment la gouvernance des données peut concilier besoin des assureurs et protection des intérêts privés ?

Une réponse :

« L’UKB a développé un cadre d’éthique et de gouvernance spécialisé (2007) et conserve un conseil d’éthique et de gouvernance indépendant en reconnaissance de cette sensibilité. Son approche de la gouvernance est considérée comme un modèle pour de nombreuses organisations de biobanques dans le monde ».

NB : tout est dans le détail, on parle de biobanques, qui induit l’idée de valeur bancaire des données de santé.

Avec des questions fascinantes de bascule d’une logique de risques mutualisés à une logique de risque ultra-personnalisés, jusqu’à essayer de faire changer de comportement les individus « Il convient de noter ici en particulier les programmes souvent décrits sous la bannière de « l’assurance comportementale », où les données sur le comportement d’un consommateur individuel sont utilisées pour fixer les tarifs : ces polices sont de plus en plus disponibles pour l’assurance automobile, l’assurance santé et l’assurance vie, et capturent des données via une variété de technologies, notamment des appareils portables, la télématique des véhicules et des applications pour smartphones (Meyers et Hoyweghen, 2018 ; Sadowski et al., 2024) »

« Comme l’a déclaré Colm Holmes, alors PDG d’Aviva et aujourd’hui PDG d’Allianz Holdings, deux des plus grandes multinationales de l’assurance au monde, dans une interview accordée à un magazine spécialisé : « Je pense que les régulateurs devront se pencher sur l’utilisation des données, car si vous vous contentez d’assurer l’individu, vous n’avez plus de secteur de l’assurance – vous créez simplement des personnes qui n’ont pas besoin d’assurance et des personnes qui ne sont pas assurables » (Littlejohns, 2020). »

Comment contrôler l’utilisation et les interprétations ultérieures de ses données ? La gouvernance joue un rôle clé :

Voir par exemple « Cette éthique a été formalisée dans la politique de gouvernance par des groupes comme le Native BioData Consortium, une biobanque qui consolide les données génétiques humaines et non humaines. »

Et pour finir … une nouvelle peur à considérer : « En d’autres termes, nous sommes tous des sujets à risque potentiels sous le regard de l’algorithme. Comme le souligne le juriste Tom Baker (2003 : 275) en référence à l’économie morale de l’assurance, « alors que certains individus « à faible risque » peuvent croire qu’ils bénéficient d’une classification des risques, un individu particulier n’est qu’à une innovation technologique de perdre son statut privilégié.» »

NB : traductions des extraits assurées via Google Traduction

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

3) Dans le même journal (Sage – https://journals.sagepub.com/ ), un article sur la datafication des données de santé.

A retenir le retour d’expérience d’un cas d’usage en Finlande :

  • La difficulté (jusqu’à l’abandon) de mettre en place un plan de données couvrant le parcours d’un patient afin d’améliorer la personnalisation des soins
  • Trois objectifs : intégrer les différentes sources de données et les solutions informatiques utilisées dans les différents domaines de santé, permettre une circulation fluide des informations et des données entre les différents sites de travail clinique et administratif en temps réel ; et enfin, permettre une collecte plus intensive des données des patients et administratives,
  • Retrait d’autorités locales du projet – perspective de couts trop élevé pour les communes, arrêt du projet après 1 an et perte des efforts de construction
  • Enquête sur la construction du projet … que je résumerais en faiblesse des principes de génie logiciel (non cité par les auteurs), complexité des parcours client (parcours trop nombreux, trop de particularités, les parcours se doivent être dynamiques en fonction des événements patient, évolution des technologies de santé et des pratiques), solution envisagée d’une vue 360° du patient, standardisation des données des différents systèmes difficiles, idée de libérer du temps pour les patients en diminuant la charge bureaucratique, voire piloter les effectifs.
  • Avec comme résultat le recensement de 3 000 demandes / exigences, la revue de 200 processus ne représentant que 10% du total des chaînes de service … difficile de formaliser cela dans un système informatique nécessairement structuré. Tentative de décomposer tous les processus en activités élémentaires – plusieurs dizaines de milliers recensées dans un fichier excel ! Remarque personnelle – on dépasse le sujet data, on est ici dans une erreur de démarche méthodologique et de conception d’une architecture système : ils se sont enfoncés dans l’approche processus, alors que c’était une fausse route – malgré l’idée de construire un plan de données patient, l’approche sémantique – data centric aurait été préférable, puis une logique de cycles de vie orchestrés par des activités définies progressivement. En termes de génie logiciel, la décomposition sous excel ne permet pas de construire une vue structurelle d’ensemble (architecture), la formalisation est difficilement cohérente entre les exigences (définitions partagées, relations, règles de gestion), difficile de proposer des évolutions sur une telle base, lien avec l’existant difficile à faire, pas d’anticipation des coûts, pas de vues par paliers …(NB qui auraient peut-être permis de ne pas arrêter le projet en totalité pour des raisons de couts globaux).
  • Même l’idée de passer par des parcours pré-planifiés – standardisés … était vouée à l’échec, car conduisant à la remise en cause de processus existants (difficile à faire adopter).

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

4) Et un événement, à suivre la diffusion des résultats « Travailler (avec) les données de santé » https://groups.google.com/g/sociologuesdelenseignementsuperieur/c/wwJYaiPJCkc et https://calenda.org/1189339

Le graal de la couche sémantique

Toujours la course à la vue unifiée des données.

Avec sur le sujet de la construction d’une couche sémantique, une série d’articles.

1) Un podcast sur le langage de modélisation sémantique (SML – Semantic Modeling Language) orienté objet et open source avec l’ambition de mise à l’échelle des modèles de données d’entreprise sur plusieurs plateformes, lisible par les humains et les machines – https://github.com/semanticdatalayer/SML . A noter d’autres langages sur le même sujet Semantic Object Modeling – https://platform.ontotext.com/semantic-objects/soml/index.html ou encore les moyens de description d’ontologies. Source https://insideanalysis.com/just-a-matter-of-semantics/ et https://www.atscale.com/press/atscale-announces-the-open-source-release-of-semantic-modeling-language/. A suivre la bataille…

2) Le sujet de la couche sémantique existe depuis longtemps dans les outils de BI (cf. rappel historique de business object). L’article s’attarde sur les principes structurants de construction d’une couche sémantique : simplicité et cohérence. Avec un exemple d’application dans Looker.

Avec aussi des principes de base (génie logiciel) : « séparer la logique métier et la logique technique – part du modèle dédié aux data analyste », « adopter des conventions de nommage », « packager les règles de gestion », « associer la documentation au plus près du codage de la couche sémantique et pas dans un outil à part », « assurer la description du lineage – exemple avec Dbt core », et « une construction itérative avec confrontation systématique auprès des métiers »

Source : https://towardsdatascience.com/semantic-layer-for-the-people-and-by-the-people-ce9ecbd0a6f6?source=rss—-7f60cf5620c9—4

3) La couche sémantique au regard

  • de l’évolution des modes de capture des données avec de plus « d’intelligence » dès la capture (exemple en IoT),
  • de l’évolution de l’exploitation des données avec le besoin de plus en plus de contexte associé aux données (en particulier pour l’IA mais d’une manière générale avec la montée en maturité de la data analytics en termes d’intelligibilité des données),
  • de la multiplication des représentations physiques des données (formats, sources, domaines) à rendre cohérentes entres-elles, à traduire, à éviter la méfiance sémantique,

Le challenge : « Adds meaning and context to data (by elaborating data assets, entities, dimensions, relationships, conditions, SLOs, usage, and more). Represents in business-consumable form. Enables consistency in how data is understood. Acts as the concrete bridge between raw data & insights/knowledge ».

Dans le passé cela passait par un modèle multi-dimensionnel (en étoile – DW/DM). Avec le problème de rigidité de ce modèle (impossible de sortir de son cadre en termes de requêtes, sauf à le faire évoluer, ce qui est lourd). Les demandes / nouvelles requêtes des métiers se trouvent face à un mur. Avec le grand classique des développeurs BI, de by passer le modèle en étoile, d’attaquer les données brutes pour répondre à une sollicitation expresse d’un métier (celui qui en BI n’a jamais fait cela ment !).

L’introduction d’une couche sémantique dans les outils BI a amélioré la situation en termes de souplesse dans le requêtage … dans les limites de la couverture et l’expression de cette couche sémantique verrouillée dans l’outil BI (inaccessible pour des consommateurs de données externes).

La couche sémantique ne doit pas être limitée à un seul outil BI et doit être utile à d’autres usages que la BI … l’ambition d’une vue sémantique de portée entreprise (partagée, réutilisable).

Comment découpler la sémantique des outils support des cas d’usage (dont la BI) ?

L’idée est d’intermédier les sources de données par une approche data product, sur laquelle la couche sémantique est construire puis exploitée par les outils support aux usages des données (dont les solutions de BI, d’APIfication, de gouvernance, de qualité, d’observabilité …). NB : rejoint la logique d’évolution des data platforms.

Sans cette couche sémantique intermédiaire, il y a danger d’une sémantique dispersée, dont la cohérence est perdue, dans chaque solution data, dans chaque développement data (exemple des pipelines), avec l’émergence d’une méfiance sur le sens (la sémantique) des données.

Source : https://medium.com/@community_md101/the-semantic-layer-movement-the-rise-current-state-f8dbbb989b2e

4) Dans la même idée, l’ « enterprise global data modeling », avec le retour de l’idée de modèles de données d’entreprise. Pour transcender les silos, créer une vue cohérente des données tout en évitant une construction monolithique centralisée, le tout grâce à une solution de modélisation – https://sqldbm.com/Home/ et implémentable sur les data platforms du marché (Databricks, Snowflake…).

Source : https://medium.sqldbm.com/enterprise-data-modeling-global-modeling-cce4e6560d28

Une série d’articles de Crafting Impactful Data & AI Products sur les développements data

1) Pipelines de données

La multiplication des données va de pair avec la multiplication des chaînes de traitement (pipelines). Et leur problème d’orchestration, de supervision et de traitement des défaillances se pose. Avec l’éternel impact sur la confiance des données : tel traitement a-t-il été correctement exécuté ? Pour contrôler cela doit tout centraliser, peut-on au contraire décentraliser ? La centralisation, abouti à un goulet d’étranglement, un éloignement des besoins. Quant à la décentralisation, elle pose des problèmes de cohérence, de synchronisation entre domaines (délais, qualité).

Source : https://craftingdataproducts.substack.com/p/the-data-death-cycle

2) Les 5 pièges courants vus par une équipe data science

Le piège de la technologie : commencer par la solution technique avant d’évaluer les besoins business (du bon sens mais rappel des échecs Big data !)

Le piège de l’action : répondre à une problématique avec une réponse familière, déjà éprouvée. Autrement dit, revenir à une démarche analytique proposée par les méthodes classiques.

Le piège du projet : l’imprévisibilité des données et ce que l’on peut en tirer (analytique data science IA) rentre difficilement dans le mode projet

Le piège du silo : une réponse par les données passe rarement par une seule équipe, un seul domaine métier (voir le sujet précédent sur les pipelines de données)

Le piège de la performance avant tout : se concentrer sur la performance technique des modèles analytiques appliqués et viser des performances toujours plus élevées (le concours de X% de réussite à détecter tel pattern)

Le tout pour aboutir à un résultat mort-né, que personne n’utilise.

Source : https://craftingdataproducts.substack.com/p/the-data-death-cycle

3) Et la suite pourquoi l’agile classique échoue face aux data

« Uncertainty: Data work involves far more unknowns than traditional software development. A data scientist can’t predict how long it will take to reach 90% model accuracy.

Value Demonstration: While software engineers can show working features early, data scientists often can’t demonstrate progress until deep into a project.

Different Backgrounds: Data professionals often come from academic or research backgrounds, where the scientific method is valued over iterative development. »

Source : https://craftingdataproducts.substack.com/p/why-agile-and-product-management

Avantages et inconvénients du self data

Avantages :

  • autonomie et responsabilisation locale,
  • proximité et accélération des analyses (versus goulet d’étranglement et distance d’une équipe centrale).

Inconvénients :

  • Manque d’expertise sur la manipulation des données (pipelines, nettoyage-préparation-mise en qualité des données, modélisation, calculs, data visualisation, lineage, métadonnées, standardisation)
  • Manque d’expertise sur l’interprétation des données – biais – culture data – culture analytique (gestion d’hypothèses, statistiques de base…)
  • Risque d’incohérence – chacun sa vérité data
  • Redondances – par exemple de traitements réglementaires
  • Limites sur la complexité de structure de certaines données, sur les volumes
  • Accumulation dans le temps aboutissant à un ensemble de produits data (analyses, datasets, tableau de bord) difficile à gérer ensemble, à faire évoluer (sauf à jeter et refaire)
  • Fausse bonne réponse aux besoins des métiers, qui veulent de l’information de qualité et rapidement exploitable et pas forcément mettre la main dans la cuisine des données (tout le monde n’a pas la vocation d’être le cuisinier des données). Il faut des données prêtes à être transformées en informations.
  • Les outils de self data sont fait pour les data analyste et non pas pour les décideurs (voir point data problématique)

Commentaire : le self data n’a de sens que dans un cadre prévu à cet effet, avec des ressources d’appui, une infrastructure sous gouvernance IT, un cadre de gouvernance instancié, des outils qui vont au-delà du Lo/No code qui n’est qu’un petit bout du problème…

Sources : https://www.dataversity.net/self-service-analytics-pros-and-cons/

https://eric-sandosham.medium.com/the-illusion-of-data-democratisation-self-service-0af50077397c

Data et IA

(Sur ce thème voir aussi la rubrique suivante Data workers)

1) Sur ce sujet data et IA, s’il y avait une seule chose à lire, c’est ce dossier.

Dossier « 9 ways to see a Dataset »  à l’ère de l’IA – de l’ingestion brutale de tout type de données (la course à la taille) à l’ingestion raisonnée.

Avec des articles et auteurs intéressants :

  • Kate Crawford – « les améliorations de l’IA nécessiteront de prêter beaucoup plus d’attention et de réflexion à la manière dont les données sont collectées et organisées. … Quelles inflexions politiques et culturelles sont intégrées dans les ensembles de formation ? Qui et qu’est-ce qui est représenté ? Qu’est-ce qui est rendu invisible et inintelligible ? Qui profite de toutes ces données, et aux dépens de qui ? Quelles questions juridiques soulève l’extraction massive de données en matière de droits d’auteur, de vie privée, de droits moraux, etc. »
  • Mike Ananny – Sur le dataset NYTAC comme représentation « d’habitudes » qui peuvent s’infiltrer dans les moteurs d’IA « As an institutional achievement, the NYTAC shows how countless largely invisible human and nonhuman actions combine to create taken-for-granted objects with the power to organize disparate communities. » « The NYTAC is simultaneously a reflection of news cultures and organizational patterns, a dataset with a life beyond journalism, and a standard for data engineers building derivative products. As “loosely coupled array of standardized éléments »
  • Christo Buschek – Comment capter le contexte de création d’un dataset « When researchers investigate datasets, we are not doing this within the context or field in which the dataset was created, but instead, we engage with the dataset on our turf. Datasets are created with certain assumptions, values, and constraints in mind. More often than not, those are implicit rather than explicit. A properly structured investigation recognizes that nothing exists in a vacuum but always is the product of power relations and interests. ».
  • Hamsini Sridharan – l’étiquetage des données repose sur des catégories (nomenclatures), le problème, ces catégories ne sont pas forcément stables, les frontières entre catégories sont mouvantes, pas stables, contestées (et même pour des catégorisations que l’on pense évidente comme pour les oiseaux) … avec les erreurs générées
  • Sasha Luccioni – Le problème de la duplication d’un même datasets en N versions, avec la propagation des biais contenus – exemple « ImageNet contient de nombreux biais intégrés dans ses catégories ainsi que dans les images qui les peuplent »
  • Will Orr – Les datasets sont le résultat de compromis, choix – « Rather, viewing datasets through the lens of their creators shows them to be less stable and far more complex and arbitrary than commonly understood, resulting from trade-offs, compromises, and constraints present at their formation. In short, datasets are products of their sociotechnical contexts. ». Comment retrouver ces choix, ces compromis, les conditions initiales de création ? Le nettoyage de données n’est jamais neutre. Avec des choix difficile, arbitraire que l’on va pourtant retrouver dans les moteurs d’IA et donc dans les résultats qu’ils produisent – « The team was reluctant to impose their own beliefs about what constitutes « good web content » to properly curate Common Crawl. They acknowledged the immense responsibility of creating a block list or filtering heuristic that defines what harmful web content is, as well as content considered permissible and safe for training. However, no one on the team felt capable of coordinating or leading this effort. ». Remarque on retombe sur le problème impossible, comment formaliser ce qui est correct, à blacklister dans un dataset … les données d’IA sont rattrapées par l’univers des données formelles.
  • Jason Schultz – La lourde problématique des droits d’auteurs des textes, images… embarqués dans le datasets alimentant les moteurs d’IA. Comment déterminer ce droits ? Y-a-t-il des droits sur les métadonnées ? Quid des erreurs qu’elles embarquent ?
  • Jer Thorp – Est-ce possible de tout annoter, avec le bon contexte (on ne peut voir que ce type d’oiseau à tel endroit, à tel moment), la bonne expertise … « If you can say with confidence that you’ve seen an Iceland gull, I can say with confidence that you’re a birder » – « In the case of iNaturalist, the datasets it uses for machine learning (and releases publicly) are constructed by its community of users – more than 1.5 million people who have made at least one verified observation on the platform. » – « Machine learning datasets are designed to carry world views » … dont la l’exemple iNaturalist la caractérisation des traces laissées par une espèce (un mégot !).

Source : https://knowingmachines.org/publications/9-ways-to-see

A ajouter pour moi, la prise en main d’un dataset prend du temps : contextualiser le contenu (au sens environnement physique, culturel temporel), contextualiser la naissance, vérifier, intégrer – versus utiliser les data tout de suite dans un outil.

2) L’idée de coopératives de données pour fournir des données qualifiées et contextualisées aux moteurs d’IA. Exemples cités : Swash, datum, MIDATA, Gener8, SAOS, GISC, and the Data Worker’s Union. Avec une idée de monétisation, de pouvoir de négociation dans le respect de la vie privée.

« It is here where data cooperatives offer a new approach to data governanceby enabling workers to co-own and manage their collective data through a more or less decentralized decision-making process. This happens because the members of a data cooperative can pull data currently siloed in different sources into one bundle.». L’article pousse plus loin en parlant de syndicat des données créées par les travailleurs. Le tout avec l’IA comme moteur à alimenter.

Source : https://hbr.org/2024/09/data-collectives-are-the-next-frontier-of-labor-relations

Sujet déjà évoqué le mois précédent : https://www.datassence.fr/2024/10/08/revue-data-du-mois-septembre-2024/#_ftn12

3) Le sujet récurrent du scrapping des contenus du web pour former des datasets d’entraînement. Avec le cas des contenus Linkedin. Source : https://techcrunch.com/2024/09/18/linkedin-scraped-user-data-for-training-before-updating-its-terms-of-service/

Data workers

L’univers fascinant des travailleurs de la données pour alimenter les moteurs d’IA.

Sujet déjà largement abordé dans les revues précédentes.

Mais dont l’ampleur est gigantesque lorsqu’on songe aux centaines de milliers de personnes mobilisées.

1) Avec un phénomène de sous-traitance évoqué dans ces deux articles.

Sources : https://maisouvaleweb.fr/comment-sabsoudre-des-dilemmes-lies-a-la-sous-traitance-du-travail-de-la-donnee/

https://journals.sagepub.com/doi/10.1177/20539517241285372

2) Un marché gigantesque.

« The appetite for AI and the need to provide labeled data for its development have ballooned the market for annotation services. Dimension Market Research estimates that it’s worth $838.2 million today — and will be worth $10.34 billion in the next 10 years. While there aren’t precise estimates of how many people engage in labeling work, a 2022 paper pegs the number in the “millions. »

3) Où les data workers sont en concurrence (en coopération) avec l’usage de données synthétiques.

« Synthetic data generation has become a business in its own right — one that could be worth $2.34 billion by 2030. Gartner predicts that 60% of the data used for AI and an­a­lyt­ics projects this year will be synthetically generated. »

Et sujet récurrent du côté mister Hyde et docteur Jekyll des données synthétiques.

Source : https://techcrunch.com/2024/10/13/the-promise-and-perils-of-synthetic-data/

(NB : à noter l’intérêt des données synthétiques comme données de test pour éprouver la pour pertinences des besoins en métadonnées, en annotations).

4) Un rapport récent sur « L’IA a un problème de données » : qualité, disponibilité, coûts, standardisation … produit par Appen https://www.appen.com/whitepapers/state-of-ai-2024 société spécialisée dans l’annotation de données.

« There are three broad types of data that organizations are using for AI, according to the report. Appen found 27% of uses cases are using pre-labeled data, 30% are using synthetic data, and 41% are using custom-collected data. »

Source : https://www.bigdatawire.com/2024/10/23/ai-has-a-data-problem-appen-report-says/

5) Le sujet de l’annotation des données. Avec des outils dédiés. Exemple : https://snorkel.ai/data-labeling-and-data-annotation/

6) Sur ce sujet voir un exemple frappant dans l’univers de la justice en France, l’article date de 2023, mais il permet de visualiser l’effort demandé pour annoter les décisions de la cours de cassation (annotations réalisées par une équipe de plus d’une quinzaine de personnes).

Voir par exemple les extraits de réunions sur comment catégoriser une donnée d’annotation. « Extrait 1 : réunion d’équipe janvier 2021, notes de terrain : Émergence de la catégorie « établissement » de la catégorie « personne morale ».

Si vous voulez voir l’envers du décor des données pour l’IA, c’est à lire.

Référence : https://journals.openedition.org/reset/4731

Data problématiques – leçons data

Des problématiques data moins souvent évoquées :

  • La maîtrise des couts des données : une requête SQL peut couter cher (cout CPU), couts de stockage – d’infrastructure (non forcément linéaire dans le cloud), couts de mise à l’échelle d’une solution data (pas cher localement ou sur une portée faible de données, à élevée lorsqu’on change de dimension), cout des ressources (compétences, formations data), tracer les valeurs produites par les données (esprit ROI)
  • La BI selon le modèle données tabulaires, tableaux de bord n’est pas efficace. Ce n’est pas forcément la bonne façon de passer des données à la décision (fracture de la BI entre la technologie et les jeux de la prise de décision). Le data storytelling vise à combler cela mais n’est pas suffisamment automatisé. La BI collaborative est une piste de solution (impliquer les data analystes dans les décisions). Les décideurs travaillent d’abord avec des documents qui mêlent contexte, narration, vues dans le temps, commentaire et données structurées. La BI ne s’intéresse qu’à la partie données structurées. Il faut inverser la pensée, la BI tout de suite intégrée dans les processus versus la BI en fin de chaîne,
  • Dans la suite de cette idée : « The McNamara fallacy is what occurs when decision-makers rely solely on quantitative metrics while ignoring qualitative factors. The fallacy is named after Robert McNamara, the U.S. Secretary of Defense during the Vietnam War, where his over-reliance on measurable data led to several misguided strategies. ». Autrement dit, quand les chiffres rendent aveuglent, lorsque le contexte, le qualitatif associé n’est pas bien pris en compte (exemple cité, la note du meilleur restaurant de tel quartier, correspondant au gout des nombreux étudiants en fin de soirée … versus une vision pour touristes) ou encore quand les chiffres ne s’intéresse qu’à la surface et pas aux causes profondes.
  • Et si on veut vraiment pousser jusqu’au bout l’idée on peut aller jusqu’à la conception d’architectures data centric, où la logique système-processus source de données, extractions, interprétations n’a plus lieu d’être. Voir par exemple ce qui est dit ici – https://towardsdatascience.com/data-architecture-lessons-learned-3589b152a8a6?source=rss—-7f60cf5620c9—4,
  • Et cela d’autant plus que l’on constate une accumulation de data pipelines, fragiles du fait d’avoir oublié les principes de base du génie logiciel (voir l’introduction de cette revue).

Sources :

https://towardsdatascience.com/three-crucial-data-lessons-that-i-learned-from-a-data-conference-thats-not-related-to-ai-f802f7097d67?source=rss—-7f60cf5620c9—4

https://svenbalnojan.medium.com/whats-wrong-with-bi-d293124f2179

https://bigthink.com/business/the-mcnamara-fallacy-when-data-leads-to-the-worst-decision/

DMBOK + TOGAF pour les data

Une proposition de combinaison intéressante entre une démarche d’architecture d’entreprise (TOGAF – https://www.opengroup.org/togaf) et une démarche de data management (DAMA – DMBOK – voir https://dama-france.org/).

De la construction d’une stratégie data à sa mise en oeuvre :

  • Etat actuel des systèmes de données (TOGAF)
  • Maturité en termes de données (DMBOK)
  • Poser les enjeux business : vision de l’architecture d’entreprise (TOGAF)
  • Comment les données peuvent permettre d’atteindre cette vision (DMBOK)
  • Déclinaison en architecture technique et de données (TOGAF)
  • Appui à la modélisation et la définition de l’architecture de données (DMBOK)
  • Définition de la gouvernance des données nécessaire et de sa déclinaison en fonctions de data management (DMBOK)
  • Elaboration de la feuille de route (TOGAF)
  • Implémentation de la gouvernance (TOGAF)
  • Gestion des changements (TOGAF)
  • Acculturation data (DMBOK)
  • -> le tout en démarche continue.

Source : https://medium.com/@arindamsg/from-data-strategy-to-implementation-navigating-the-path-with-dmbok-and-togaf-62a8deeec359

En vrac (Data portabilité, SDMX, Data et sécurité, Data platforms, Active Data architecture)

1) Data portabilité

Un article complet sur le sujet de la portabilité des données personnelles (mais applicable à d’autres données). De la vision fonctionnelle à la vision technique en passant par la problématique de gouvernance.

Source : https://link.springer.com/article/10.1007/s12599-023-00815-w

2) La norme de partage de données statistiques – SDMX

Un article d’Opendatasoft sur la normes SDMX de partage des données statistiques. Avec une illustration sur la cas de la Banque de France. Source : https://www.opendatasoft.com/fr/blog/sdmx-et-portails-data-comment-faciliter-lacces-lechange-et-le-partage-de-donnees-statistiques/

Norme aussi utilisée par l’Insee, voir par exemple un service web SDMX : https://www.insee.fr/fr/information/2862759

3) Data et sécurité

Le défi de la sécurité des données tout en permettant leur large utilisation.

« Si vous êtes un hôpital qui stocke les données de vos clients, vous êtes contraints par la loi que le serveur externe qui stocke vos données n’apprenne rien sur vos patients, mais vous voulez pouvoir faire des recherches sur votre base de données de clients. ». Les réponses proposées à lire dans l’interview de Brice Minaud, chercheur en cryptographie. Source : https://interstices.info/quel-est-le-prix-a-payer-pour-la-securite-de-nos-donnees/

4) Data platforms

Salesforce continue à se renforcer et construit brique par brique une data platform complète.

Avec le rachat d’une solution de sauvegarde et de récupération de données incluant la gestion du cycle de vie des données (data management) et des fonctions de sécurité : https://www.owndata.com/ de OwnCompany.

Source : https://techcrunch.com/2024/09/05/salesforce-acquires-data-management-firm-own-for-1-9b-in-cash/

Et d’autres annonces (Microsoft, Dremio, Databricks)

https://next.ink/brief_article/microsoft-lance-drasi-une-plateforme-open-source-pour-suivre-les-changements-de-donnees/

https://medium.com/data-engineering-with-dremio/virtualization-lakehouse-mesh-data-at-scale-e5d27f1839b0

https://medium.com/towards-data-engineering/data-mesh-databricks-a-match-made-in-heaven-9d15beff3f03

5) Active Data architecture

Un document publié par Denodo : 2024 Edition Active Data Architecture (TM)

https://www.denodo.com/system/files/document-attachments/Wisdom%20of%20Crowds%C2%AE%20Active%20Data%20Architecture%20Report%20-%20Licensed%20to%20Denodo%20-%20%C2%A9%202024%20Dresner%20Advisory%20Services%20(1).pdf


RDV maintenant en décembre pour la revue et les actualités de novembre.


L’attribut alt de cette image est vide, son nom de fichier est Datassence_Logo1_1.png.

Comments are closed.