###### Rencontres Huma-Num 2021 - Atelier HN Lab :::success ### Appel à contribution Dans le cadre des Rencontres Huma-Num 2021, le HN Lab lance un appel à contribution pour préparer l'atelier HN Lab. L'objectif de vos contributions en amont de l'atelier sera de permettre à chacun·e·s de s'exprimer avant et/ou pendant l'atelier, et de structurer les échanges à venir. L'équipe du HN Lab vous invite à éditer cette page, et à y écrire vos questions, vos remarques, vos expériences sur la ou les thématiques proposées. Parmi les [4 axes de recherches](https://www.huma-num.fr/hnlab/) du HN Lab, nous avons choisi pour cet atelier de revenir **sur la question de l'écriture exécutable**, une pratique encore émergente dans la communauté SHS, mais dont les usages se multiplient (pédagogie, analyse de données, nouvelles formes de communications scientifiques, etc.). Le HN Lab est particulièrement engagé dans cette réflexion (plateforme prototype, groupe de travail, accompagnement de projets), et souhaite profiter de cet atelier pour ouvrir un espace d'échange sur la question. **Comment contribuer** 1. Cette page peut-être éditée par tout un chacun. Basculez en mode édition en cliquant sur les icônes  ou en cliquant [sur ce lien](https://demo.hedgedoc.org/Lc9Y3jz3S5G3nVx_zF8Xig?both). 2. Si vous le souhaitez, ajoutez votre nom à [la liste des participants](#Participants) ci-dessous, 3. Intégrez votre contribution au thème correspondant parmi les trois proposés, 4. Respectez si possible le format suivant : un nom/pseudo, une ou plusieurs catégories, une à deux lignes (ou plus). Exemple: `@pseudo [categorie·s] : remarque` **Suggestions de catégories** - [commentaire], [projet], [question], [expérience], [référence], [retour d'usage], ... - _n'hésitez pas à créer des catégories_ ::: :::warning ### Participants _Ajouter ici votre nom ou pseudonyme_ - Mélanie Bunel (HN Lab) - Nicolas Sauret (HN Lab) - Stéphane Pouyllau (HN Lab) - Sébastien Rey-Coyrehourcq (IGR UMR IDEES) - Arthur Perret (Université Bordeaux Montaigne) - Michael Nauge (Université Poitiers) - Hugues Pecout (FR CIST) - Servanne Monjour (Sorbonne Université) - Matthieu Guionnet (CNRS - UMR Certop) - Eva Schaeffer-Lacroix (Sorbonne Université, CeLiSo) - Raphaëlle Krummeich (IRIHS, université de Rouen) - Marta Severo (Dicen, Université Paris Nanterre) - Aurelia Vasile (MSH, Clermont-Ferrand) - Fatiha Idmhand (Consortium CAHIER) - Clarisse Bardiot (UPHF, MESHS) - Pierre Willaime (AHP, CNRS) - Amar LAKEL (MICA, Université Bordeaux Montaigne ) ::: ###### Contribuez dans les thèmes ci-dessous : ## 1. Écriture exécutable : vers une heuristique des données :::info Ce premier panel propose une réflexion plus théorique sur les données et sur les pratiques d'écriture exécutable. L'hybridation au coeur des documents de l'écriture programmative (coder, manipuler, traiter) et de l'écriture discursive (documenter, analyser) ouvre pour les chercheurs SHS une nouvelle relation aux données et de nouvelles procédures de fabrique du savoir. - Quelles sont vos données ? Qu'apportent-elles ? - Qu'attendez-vous de la mise en ligne de vos données ? - Quels sont vos usages des données produites et comment les traitez-vous ? ::: ### Espace de contribution "Thème 1" ###### *Ecrire ici*: - @nicolasS. [référence] : Au-delà d'une heuristique des données, Stefan Sinclair et Geoffrey Rockwell parlent [dans leur ouvrage _Hermeneutica_](https://mitpress.mit.edu/books/hermeneutica) d'une nouvelle herméneutique autour des données à travers des outils d'analyse et de visualisation. - @sebastienRC. [référence] : Donald Knuth est une référence je crois incontournable sur la double question de la reproductibilité / Literate Programming (https://en.wikipedia.org/wiki/Literate_programming) - @sebastienRC. [référence] : Les travaux fait dans l'ANR HyperOtlet (https://hyperotlet.hypotheses.org/author/infologie) et les réflexions de Arthur Perret (https://www.arthurperret.fr/), Olivier Le Deuff peuvent être, il me semble, misent en relation avec l'écriture exécutable. (*mis à jour par @ArthurPerret*) - https://www.arthurperret.fr/fonction-documentaire-preuve-donnees-numeriques.html (surtout vers la fin de l'article) - Un exemple d'utilisation d'Observable dans le cadre du programme ANR : https://observablehq.com/@arthurperret/tree-ty-of-documentation - Une proposition à creuser : https://www.arthurperret.fr/all-papers-are-data-papers.html - @sebastienRC. [Référence, Projet] : Même si plus difficile d'accès (sous emacs), org-mode avec org-babel (https://orgmode.org/) sont des dispositifs de Literrate Programming très puissant et assez utilisé dans d'autres communautées que les SHS. Il existe un MOOC de l'INRIA qui introduit très bien l'intérêt de ces outils pour la reproductibilité (https://www.fun-mooc.fr/fr/cours/recherche-reproductible-principes-methodologiques-pour-une-science-transparente/). Emacs possède l'ensemble des outils nécessaire à l'écriture de document en LP reproductible (org-mode, org-babel, org-ref, org-roam, org-marginalia, etc.) - @sebastienRC. [Projet] : La récente plateforme collaborative https://rzine.fr/ permet la mise en ligne et l'aggrégation de Notebook reproductibles RMarkdown en R sous forme de collections (avec une revue par un comité de lecture) ou de ressources. - @sebastienRC. [Référence] : Le travail de https://www.quaternum.net/carnet/ sur "les fabriques de publications" - @sebastienRC. [Projet, Référence] : Le projet https://journalofdigitalhistory.org/en/about qui intègre une couche data (notebook) à la publication. - @michaelN. [référence] : Article executable, c'est quoi en quelques mots ? [video workshop ReproctuctibiliTeaPoitiers](https://mfr.de-1.osf.io/render?url=https://osf.io/yt5sg/?direct%26mode=render%26action=download%26mode=render). Ressources complémentaires [gitLabHN](https://gitlab.huma-num.fr/mnauge/executable-paper) - @matthieuG. [commentaire] Pour les données, avoir des plateformes d'hébergement accessibles sur lesquelles on aurait la main pour le contrôle et le partage, quelque soit la visibilité privée ou publique des données. Un projet comme [kinto](https://docs.kinto-storage.org/en/stable/) pourrait être intéressant. - @EvaSchaefferLacroix [commentaire] Je suis intéressée par un espace collaboratif sécurisé pour stocker des données multimédia (films français ou allemands et scripts d'audiodescription qui y correspondent. Cet espace devrait être accessible à des membres d'une équipe internationale, et les données doivent pouvoir être modifiées ou supprimées (pas de stockage pérenne obligé). - @servanneM. [référence] On peut aussi parler des appropriations poétiques des données, comme on peut l'observer au sein de l'Electronic Literature Organisation depuis de nombreuses années. Il y a 2 jours, Chris Tanasecu proposait une conférence ["Poetry as/of Data"](https://www.kbr.be/fr/evenement/digital-heritage-seminar-chris-tanasescu/). Il y est question d'une heuristique des données, de l'écriture exécutable dans une perspective esthétique / poétique. - @RaphaelleK. [question à @servanneM.] : les données sont-elles produites de manière native ou à partir de *documents numériques* ? Auquel cas, des *poétiques* du *document numérique* pourrait-elle s'articuler avec celles des données ? (Jacques Rancière, Le partage du sensible, ed. La fabrique, 2000) - @ClarisseBardiot [projet, référence, pub] : Le prochain colloque #dhnord2021 à la MESHS a pour thème Publier, partager, réutiliser les données de la recherche : les data papers et leurs enjeux. L'appel à communication est ouvert jusqu'au 31 mai. Infos ici : https://www.meshs.fr/page/dhnord2021-aac - (Pierre Willaime) un cas d'usage un peu en dehors de celui des notebooks : celui des textes publiés sur des sites présentant des archives. Ces textes sont souvent appelés des "focus". Le propos est centré sur une question précise en lien avec le corpus. Dans ces écrits, on souhaite mêler texte, visualisation de telle ou telle pièce, d'une chronologie du corpus, de stats, etc. Omeka S permet de construire des pages de ce type (c'est assez limité tout de même mais modulable). - @ArthurPerret [référence] Je signale le travail d'Andy Matuschak sur les évolutions possibles du livre, dans une direction qui rejoint beaucoup celle discutée aujourd'hui (interactivité, didactique) : https://andymatuschak.org/books/ et https://numinous.productions/ttft/ - @SebastienRC [projet, référence, commentaire] En lien avec ma remarque sur le reviewing et l'éditorialisation de ce type de plateforme permettant du litterate programming. Il existe des plateformes open source assez puissante comme celle-supportée par la *Coko fondation* avec l'outil https://pubsweet.coko.foundation/. Celle-ci semble fournir un certain nombre de brique de base modulaire pour l'éditorialisation, avec des journaux à la pointe dans ce domaine comme elife avec Libero (https://libero.pub/) également en Open Source. Je me demandais si il existait déjà une intégration avec des notebooks avec ces solutions, en tout cas il y a un truc à creuser ?. #### Prise de note Arthur Perret: (doctorant science de linfo: Ecriture executable: pas forcément le bon terme. reprendre la terminologie scratchpad/l'essai computationnel Différence fondamentale entre word et Jupyter: pas dans l'exécutable, car word et jupyter sont à la base du format avec balisage. Différence dans word tout est fondu dans la catégorie texte. Jupyter possibilité d'annoter plus spécifiquement les choses. Dans un environnement comme word pas possible d'injecter directement du csv, pas possibilité de sérialiser. Orienter la discussion en termes de matériau et matériau. homogénéisation des écritures de word dans un seul rendu https://medialab.sciencespo.fr/en/tools/ovide/ matériau, données, médiation, interface Waldir: JL comme architexte susceptible de se réécrire lualdir: i-même Word est propriétaire. Les logiciels proproiétaire limient l'intéropérabilité de façon importante. Utilise Prospero, fondé sur la lnangage pivot avec catégories sémantiques. ArthurP: L'écriture executable s'applique aussi à Word selon moi. Pour moi, je parlerai plus de matériau. NicolasS: tout converge dans un même milieu "le web" un ensemble d'activités (écriture des données, les récupérer, les traiter): fait la rupture avec des pratiques de recherche qui utilise un archipel de logiciels déconnectés entre eux. MichaelN: 2 classes différentes: documents didactiques (pérennes et propres) et côté exploratoire de data/fouille (scratchpad). Intérêt, on peut garder trace des essais/erreurs, pleins de loupes pour observer les données. Assez simple de faciliter le dialogue avec de la narration et graphiques, tableaux. Permet d'échanger plus de vocabulaires. On trouve une bonne interaction par ce média. NicolasS: dialogue nouveau entre les métiers et plus rapide avec les données. ClarisseB: Comment on écrit un datapaper et aussi en terme de définition. Projets de revues avec des articles sous forme de datapaper → nouvelles écritures scientifiques en SHS. Manière dont cette pratique des sciences dures peut être transféré dans le domaine des SHS en termes de litératie numérique (DH Nord). XavierR: logicisme de Gardin (?) Organiser l'écriture entre les logiques d'inférence de ces propositions. permet de livrer pas juste un récit mais l'ensemble du raisonnement. LogicisWriter: permet d'écrire directement des diagrammes d'inférences. Pouvoir constituer des corpus d'inférence réutilisables. RégisW: c'est vrai que les données sont importantes. Travail d'écriture d'un article en partant de Jupyter permet de mieux comprendre le code et l'ajout de markdown permet d'avoir un vrai support réutilisable. On a mis ça en place avec la fac de médecine de Strasbourg "body capital". Nos travaux ne sont pas que des pdf. -------------- ## 2. Les plateformes de science des données (JupyterLab, etc.) en SHS (_approche usages et pratiques_) :::info L'environnement de travail Jupyter Lab est une interface web permettant d'exécuter du code dans de nombreux langages (Python, R, Perl, etc...) et d'écrire du texte en Markdown formant ainsi des "calepins" et articles pouvant exécuter des traitements et des programmes : les *notebooks*. Depuis quelques années son utilisation est de plus en plus répandue dans le domaine de la _data science_. Le HN Lab travaille sur la mise en place, au sein des services d'Huma-Num, d'une plateforme Jupyter Hub pour les communautés SHS. Cette plateforme a vocation à faciliter l'appropriation et la généricisation du traitement et de l'analyse de données. - Quelle est votre expérience sur ces plateformes (y compris les approches pédagogiques) ? - Avez vous besoin de construire des démonstrateurs de vos traitements de données ? - Comment considérez vous cette ouverture des protocoles et du traitement comme pratique de recherche ? ::: ### Espace de contribution "Thème 2" ###### *Ecrire ici*: - @sebastienRC. [Projet] C'est encore un POC mais nous nous associons à la démarche de l'UFR santé de Rouen pour que ce projet soit étendu à l'établissement Université de Rouen. Une plateforme jupyterhub, sur le modèle de ce qui a été fait à Paris (https://plasmabio.org/) devrait être déployé pour la rentrée. Nous aimerions avoir accès à ce type d'infrastructure pour les cours de Python et de R fait en géographie. - @sebastienRC. [Projet, Commentaire] : La délégation de calcul sur environnement HPC est aussi très intéressante dans le cadre des notebook. Cela recoupe en partie cette question de la "reproductibilité" des calculs/traitements lorsque ceux ci sont couteux (en temps/calcul). Comprendre délégation comme "la possibilité d'envoyer le calcul sur un cluster pour execution pour ensuite récupérer le résultat et l'intégrer plus tard dans le notebook" Plusieurs MésoCentres expérimentent des POC avec Jupyter sur ce sujet en lien avec des chercheurs, souvent en lien avec le Machine Learning. Nous sommes également intéressé en géographie. - @michaelN. [UseCase] : Formations à l'algorithimie, pensée computationnelle, et programmation pour doctorants et chercheurs. Besoin que tous les "étudiants" ai un même environnement de travail (généraliste), clef en main, avec différents fichiers, codes, notebooks accessibles directements manipulables. Données moyennement persistantes par étudiant. (Jupyter Hub probablement très pertinent). - @michaelN. [UseCase] : Travail d'équipe sur des projets de recherches. Besoin qu'un groupe restreint ai un même environnement de travail (mais spécifique, version particulière de python et de librairies) Jupyter Hub à compléter probablement avec autre chose pour traiter le travail collaboratif à plusieurs sur une même base de code comme le propose la solution Collab de Google, par exemple. - @michaelN. [UseCase] : Diffusions d'article executables: Jupyter Hub probablement à compléter avec autre chose (un "myBinder Huma-Num" ?) pour traiter des instanciations sans création préalable de compte utilisateur et manipulation de données non persistantes. - @michaelN. [UseCase] : Diffusions d'outils de dataviz ou d'exploration de corpus "sur-mesure". Se rapprocher de ce qui est possible avec RShiny. Regarder du côté de "voilà" et des systèmes de déploiement du type Heroku. - @matthieuG. [Commentaire] bien que pas fan de R et Rshiny, je pense qu'une instance de Rstudio-server aurait son utilité. Pour l'avoir utilisé/mis à disposition connectée à un LDAP, il y a eu d'assez bons retours. Ces mêmes personnes avaient plus de mal à intégrer le principe des notebooks de jupyter. Moi même je suis heureux du projet jupyterlab qui le rapproche plus qu'un IDE comme rstudio. J'aimerai connaître la disponibilité de jupyterlab sur Huma-Num. - @sebastienRC. [Commentaire] Le besoin de reproductibilité augmente, et ces plateformes sont évidemment de la partie. Toutefois, avec la volatilité importante des packages en R ou en Python (il suffit d'essayer de faire tourner un code qui a 6 mois en R ou en Python pour se rendre compte du problème) qu'est ce qui garantit qu'un notebook RMarkdown ou Jupyter sera reproductible, même à moyen terme ? Des solutions existent mais elles sont encore peu développés / complexes : les systèmes de packages déterministes Guix / Nix permettent a) de spécifier exactement quels sont les packages impliqués dans le programme à reproduire (avec un hash), b) de s'appuyer sur des dépots de packages archivés sur le temps long, par exemple avec le travail fait par Software Heritage (qui est justement partenaire avec Guix / Nix). Quelques évenements en lien avec la reproductibilité récemment ( https://www.societe-informatique-de-france.fr/journee-reproductibilite/, https://reproduct2021.sciencesconf.org/) - @mnauge > @sebastienRC. [Commentaire de commentaire] : Nous pouvons commencer techniquement par toujours préciser de manière explicite la version de chaque paquet utilisé. Nous pouvons également fournir les algorithmes en languages pseudo-naturels avant les codes. Il est alors plus facile de re-programmer dans un autre language ou dans une nouvelle version de paquet ? - @sebastienRC [Commentaire] Jupyter permet d'executer du code, et d'y ajouter du texte, mais le support a posé problème car *entre autre* il n'était pas vraiment manipulable (voir la *notebook war* https://yihui.org/en/2018/09/notebook-war/) Jupytext (https://github.com/mwouts/jupytext => voir https://github.com/mwouts/jupytext/blob/master/docs/faq.md), Myst (https://myst-parser.readthedocs.io/en/latest/) sont des solutions mais il y'en a d'autres. - @sebastienRC [Question] Plus une question qu'un commentaire, est ce que raccrocher un réseau international comme les *Carpentries* (https://software-carpentry.org/, https://carpentries.org/) ne serait pas intéressant aussi ? - @AmarLakel [commentaire] Même chose pour R Studio (+ R Shiny + R Pub) sur la base de notebook markdown. Si on couple R + Python, on couvre 90% de la communauté autour de notebooks markdown avec scripts executables. On peut parler d'une norme de fait. En SHS, j'ai l'impression que R est plus apprécié que python car JupyterLab est arrivé trés tard par rapport à R Studio. - @AmarLakel [commentaire] La démarche me parait tellement essentielle que je suis sûr qu'on parlera de période "pré-scientifique" des SHS au XXème siècle. Le scandale de la non-reproductibilité de 70% des papiers dans des disciplines entières font bouger les frontières de la science. Sans parler de la non-cumulativité de milliers de papiers. Je renvoie à https://academic.oup.com/joc/article/71/1/1/5803422 , https://online.ucpress.edu/collabra/article/4/1/20/112998/A-Practical-Guide-for-Transparency-in , https://www.nature.com/articles/s41562-016-0021 #### Prise de note SébastienR-C: Question de la revue, qui va lire ça? Papier reproductible sont cités moins souvent que les papiers non reproductibles. Lien vers la plateformes Rzine: Comment reviewer ces notebook. Beaucoup de temps pour reviewer ces nouveaux formats de papiers. => papier en question dans Science Advance : https://advances.sciencemag.org/content/7/21/eabd1705 Amar Lakel: Datapaper problème culturel plus que technique. Nous sommes encore dans une ère préscientifique couverte par le format papier des revues scientifiques. Avec les notebooks et les datapapers, celui qui voudra vérifier des papiers surprenants ou produire une méta-analyse de papiers sur un thème pourra "nettoyer" sa discipline de conclusions infondées. XavierR: Problème d'éditorialisation de ces nouveaux formats de publications. QQch dont nous devons nous emparer d'un point de vue institutionnel. (Tout à fait!) RomainM: Préfère tableau à des slides. Permet de rendre le contenu plus interactif et de suivre la construction du propos et de la réflexion. QQch que je retrouve dans Jupyter, gains de temps et organisation. QQch dont on a peu parlé: possibilité d'intégrer du Latex et mettre en forme des équations et éléments mathématiques. Outil très intéressant pour la formation. Possibilité de mettre en place des environnements de travial en ligne déjà tout prêt pour les utilisateurs. Pas de problèmes en fonction des OS. Laurent C: Quelle est la durée de vie d’un notebook ? python existera dans 30 ans ? SP : @Laurent, je fais mes notebook en Perl :) Perl : 1987 Il est possible dans Jupyter (& co) de versionner aussi les kernel et donc des les proposer dans des émulateurs par exemple. Ex. Avec Docker aujourd’hui, sans doute autre chose demain. Après le code étant lisible, il peut être recoder :) Régis W : informatique = volatil. On fait appel à HN pour le support infra + assurer la lisibilité à terme (choix format documentés pour une techno tjrs lisible à long terme) on ne sait pas de quoi l'avenir sera fait : il faut accueillir l'avenir = logiciels libres, documentés, formats pareils etc M Nauge : aspect moins technique = le langage des algorythmes, facilite le dialogue entre personnels techniques et moins. Méthode en 3 étapes : écrire en langage naturel ce qu'on veut ; reformulation en langage ? ; passage en algorythme. Cela permet de se comprendre sur un maximum de la chaîne Serge Faraut : Quid de l'évolution des hardwares? Certaines librairies utilisent du code source compilé (ou assembleur) dépendant des processeurs... Sylvia Girel: Travail sur la production sicentifique numérique sur les éditions existantes et aussi sur un appel à proposition lancé l'an dernier sur un eproduction scientifique qui mêle image/son/texte. Projet matérialité citoyenne. Notre réflexion est de créer des espaces et des logiques de diffusion de production sicentifique en créant une dynamique d'ensemble. on réfléchit à des ouitls plus grand public dans le cadre la SO. ----------- ## 3. Écosystème d'Huma-Num pour les données :::info Le HN Lab travaille à l'intégration de nouveaux services associés à Nakala et à Isidore comme l'outil [Stylo](http://intelligibilite-numerique.numerev.com/numeros/n-1-2020/18-ecrireles-shs-en-environnement-numerique-l-editeur-de-texte-stylo.) ou demain une plateforme JupyterLab, pour un véritable écosystème de la donnée et de l'écriture en sciences humaines et sociales. - Quelles sont vos pratiques de cet écosystème ? - Selon vous, qu'est ce qui manquerait aujourd'hui à cet écosystème ? - Quels sont les changements observés dans votre approche de l'édition scientifique en SHS grâce à ce type d'écosystème numérique? ::: ### Espace de contribution "Thème 3" ###### *Ecrire ici*: - @michaelN. [retour d'expérience] : Les services Huma-Num sont larges et très complémentaires, cependant il manque à mon sens des "connecteurs" entre les différentes briques logicielles. On mets facilement en commun des fichiers images/sons dans le sharedocs, il est assez douloureux d'en basculer une partie sous Nakala quand ces fichiers sont prêts car enrichis par traitements+corrections manuelles. Les traitements sont réalisées par exemple par des OCR ou des codes ad-hoc depuis des notebooks/scripts. Une partie des fichiers enrichis sont très bien sur le GIT, car de nature textuelle et dont il est très important d'avoir traçabilité des corrections manuelles coûteuses. On se retrouve donc facilement à avoir dispersé les différents fichiers d'un même corpus d'étude dans au moins 3 services différents (Sharedocs/Nakala/Git). Sachant que les fichiers déposées sous Sharedocs, doivent être repensés pour rentrer dans la logique de data (multi-file ou single file) de Nakala. J'imagine qu'il faudrait travailler sur des "workflows + patrons de conception" d'objets numérique pour faciliter la faisabilitée d'une "connection" entre services logiciels intervenants à des moments différents d'un projet et manipulés par des métiers variés. - @RaphaelleK. [veille] Lors d'une session plénière de la conférence [DataforHistory 2021](https://d4h2020.sciencesconf.org/) (qui court de mai à juin 2021) l'approche suédoise d'une structuration nationale sous la forme d'un portail multi-applications [Sampo](https://seco.cs.aalto.fi/applications/sampo/) a été présentée par Eero Hyvönen du Semantic Computing Research Group (SeCo) de l'université d'Helsinki. Les principes sont les suivants (notes en anglais) : ```! Three generations of portals are identified: - data harmonization, aggregation, search, and browsing („first generation systems“) - integrated tools for solving research problems in interactive ways („second generation systems“) - next step ahead to „third generation systems“ is based on Artificial Intelligence: future portals not only provide tools for the human to solve problems but are used for finding research problems in the first place, for addressing them, and even for solving them automatically under the constraints set by the human researcher. ``` Il semble donc utile de découpler & articuler les services ressources/données (transcriptions & indexations - écritures) & modélisations FAIR (finalité de dépôts RDF dans le LOD) des interfaces UI qui pourraient bénéficier des développements logiciels de divers projets ou consortium HumaNum par exemple. #### Prise de note SébastienR-C: Communauté ML utilise beaucoup Jupyter (mésocentre). Volonté forte de déléguer les calculs qui vont durer plusieurs heures sur le calculateurs, récupérer le résultats et l'avoir sur leur notebook. Question de la reproductibilité et pérennisation des notebooks. Solutions de bricolage par les gens qui font du ML. Délégation du calcul se pose. Capacité de pouvoir rejouer un clacul qui parfois prend des 10aine d'heures. RaphaelleK: en veille technologique. Dépôts Nakala. La question de l'écriture est impactée par ces démarches. Axe données du HNLab: aspects métadonnées dans Stylo. Si on génère des données thématiques par rapport à ce que va produire du code, cette partie métadonnée pourrait être connectée. Démarche engagée par les suédois. MichaelN: sur le terrain quand on traite les questions de recherche. Matériaux sur Sharedoc. Traitement spécifique additionnels (python, git). Fichiers générés en txt. Nécessite un gros travail de gestion de projet, vite très comliqué de savoir ce qu'on a à quel endroit, qui a accès à quoi. Waldir NicolasS: La problématique de la publication. RégisW: j'ai pas de solutions pour intéresser des publics sur des datapapers. Partie textuelle Jupyter, markdown. Permet de différencier le fond de l'article de la forme. Maximise les chances que les gens lisent. Penser au format qu'on utilise. Waldir: travail autour de la defragmentation de l'espace public. Nouvelle distribution linux pour ça.