# Journée d'Etude GT Notebook

Page du Séminaire : https://gt-notebook.gitpages.huma-num.fr/site_quarto/seminar.html
Annuaire CV (CV) : https://pinkmypad.net/hackmd/bVNTSDazRAG8EhOUdV-Mxw
La Petite Bibliothèque (collaborative) des JE : https://pinkmypad.net/hackmd/Sy8He90byx
Participants (HumanID) : https://hackmd.io/MWhmfy2KQ_2ZC3BuorsGkA
[TOC]

Géographie, SAS puis R pour la statistique, puis Python pour la géomatique
GT Notebook issuu d'un atelier IMEC et désir d'élargir à d'autres disciplines

GT/collectif organisé avec sur infra HumaNum + RENATER
- COPIL pluri-disciplinaire, ouvert, sans rôle assigné
- projet de charte ?
- Axes de réflexions : epistémologie, écosophie, littéracie, reproductibilité
Actions et réalisations
- cycles de webinaires mensuel (plus ou moins) => 250 personnes dans la mailing listes
- chaines Canal U
- prise de note collaboratives
- JE automne 2024 pour permettre de se rencontrer et échanger
- Envies (*slow science*)
- découvrir / discuter
- articuler/partager => co-construire des outils
- perspective critique socio-économique

## Conférences

### _L’éloge du bug_

:::info
**Présentateur(visio):** Marcello Vitali-Rosati, Philosophe et spécialiste d’édition numérique, professeur au département des littératures de langue française de l’Université de Montréal et titulaire de la Chaire de recherche du Canada sur les écritures numériques | L’éloge du bug
**Discutant:** Nicolas Sauret

:::

_Résumé_

À partir de son ouvrage _Éloge du bug, être libre à l'époque du numérique_, Marcello Vitali-Rosati proposera une réflexion épistémologique sur l'écriture et la modélisation informatique. Là où l'environnement d'écriture et de calcul des Notebooks a ouvert la programmation à de nouveaux usages pour l'enseignement, la modélisation et la recherche, Marcello Vitali-Rosati pointe les risques de paresse face à la facilité offerte par les langages de haut niveau. Il rappelle l'enjeu scientifique des modèles, et la nécessité de conserver la maîtrise sur la modélisation des objets de recherche.

_Notes_

Bricoler, manipuler, casser => réfléchir avec du code

Rapport aux technologies et aux environnements numériques en SHS (particulièrement litterature) en mode lampe d'Aladdin (*Solutionism*)

Outil complètement opaque et on s'en fout de comment ça parche tant que ça donne la solution au problème. (Exemple du smartphone)

L'outil miracle, le LLM qui fait tout.
- rhétorique du fonctionnel: c'est simple et performant
- on arrive à avoir des résultats étonnament bon sans effort intellectuel
- notion de succès (ou pas) dans les sciences : Chomsky notionde succès ne devrait pas exister en science

Le bug, le non-fonctionnement : questionner, porter à réfléchir dans la recherche
Il ne faut pas gagner du temps, il faut en perdre : chercheurs => oisifs militants
- approfondir notre questionnement oisif de la connaissance

Démon qui empêche Socrate de faire tout le temps : Socrate buggue tout le temps.
Objectif de la philosophie: ne mene à rien ?

Modèles et Manipulation

Rhétorique de l'imatérialité : le chercheur pense et l'ingénieur va bricoler un truc pour implémenter cette pensée.
Bricolage comme lieu de la pensée critique
- modèle théorique riche est celui qui émerge d'une manipulation longue
- théorie "immatérielle" est un manipulation pauvre et paresseuse
- le modèle se précise quand on commence à toucher le texte

La manipulation du code

Oblige à spécifier des modèles formels
1. modèle théorique (en langage naturel)
2. implémentation dans un modèle formel (numérique)
3. modèle matériel dans un notebook exécuté sur une machine

Perte des ambiguités du modèle théorique lors de la création du modèle formel
Questions qui ne se posent que quand on manipule l'objet d'étude

Usages du notebook
- enseignement
- production de support de cours
- résultats du notebook moins intérressant que la réflexion derrière
- ne pas cacher les bugs mais apprendre à aimer les erreurs, apprendre à lire une erreur
- erreur pointe soouvent les limites de la modélisation (prise en compte d'exception par exemple)
- modélisation
- code toujours très très sale car issu du bricolage, souvent pas d'idée préalable très arrêtée.
- différence entre Python et Haskell où le modèle doit être très précise avant d'exécuter le code
- le bricolage permet de préciser le modèle théorique, au fur et à mesure que le code tourne
- recherche
- terme _intuitif_ qui revient tout le temps, les outils sont intuitifs pour les enfants si ils ont le temps de les manipuler

Risques
- Le risque de la paresse
- magie des langages de haut niveau : réalisation complexes sans avoir aucune idée de ce qu'on fait
- outil miracle : concetration d'usage, fermeture vers d'autres outils
- modélisation brouillonne: risque de ne jamais nettoyer son code

Outil notebook très intéressant
- multi langage
- ébauche de réflexion façon cahier de brouillon
mais attention à ne pas généraliser les usages

- risque de dépendances aux plateformes (exemple COllab)

_Questions/Réponses_

Eloge de la paresse vis à vis de l'éloge de l'oisif:
- oisivité: *scole* positif opposé à l'*ascoliaù* c'est le travail, inverse en grec et en latin
- cigales trop occupées à chanter pour les muses : oisivité militante, oisivité est un non travail
- ne soyons pas paresseux, salissons-nous les mains à faire des choses triviales

Est-ce que les notebooks réouvrent les perspectives de littéracie pour les chercheurs ?
Groupe de personnes qui partagent les valeurs qui rendent le partage aux plus jeunes plus facile, avec des notebooks notamment

Comment rendre ses problématiques plus accessibles à un autre public (autres chercheurs )?
- avantage un notebook peu être lu par rapport à seulement un fichier script

Impératif fonctionnel
- fonctionel regroupe 2 notions : efficacité et fiabilité
- l'oisiveté fournit l'autonomie utilisateur qui permet d'assurer la fiabilité
- les fragitlités des systèmes techno-sociaux permettent de mettre en question les pré-supposés

Travail de compréhension des données, implémentation de la compréhension du modèle , les questions deviennent le modèle qui portent le projet
l'ingénieur se pose les questions précises

Noteboook dispositif maïeutique ?
- "trouvez-vous même la solution"
- LM notebook de Google : discussion avec une IA, technique de RAG ? utilisation plus experte des LLM
- risque de la paresse, pression immense de production incite à être paresseux à utiliser la machine
- tokenisation prévus à la base vecteurs de token qui ne sont pas des mots
- pas de connaissance des poids du texte fournis par rapport à la base d'apprentissage: valeur scientifique égale à 0

Les nouveaux concepts littéraires ne sont plus des mots mais des algorithmes ?

- le sens est la manipulation, c'est ça l'idée. ce n'est pas une idée désincarnée
- un discours théorique qui ne serait pas matérialisé est moins intéressant

Au lieu d'utiliser des algorthimes pour obtenir des résultats, utilisation plutôt pour produire des concepts (et vérifier les définitions formelles)

"En sciences humaines, souvent on discute de choses dont on ne sait pas ce que c'est"

### _Le langage et les styles informatiques_

:::info
**Présentateur:** Baptiste Mélès, Chargé de recherche CNRS, AHP-PReST UMR 7117, université de Lorraine, Organisateur du séminaire Codes sources | Le langage et les styles informatiques
**Discutant:** Konrad Hinsen
:::

_Résumé_

L'intelligibilité des langages de programmation tient pour une part aux emprunts qu'ils font à des langues naturelles. C'est par exemple l'usage de lexèmes empruntés à l'anglais qui rend le langage assembleur plus « lisible » que le langage binaire, alors même que les deux langages sont globalement isomorphes. Mais jusqu'où les langages de programmation sont-ils dépendants de langues naturelles particulières ? Nous distinguerons différents niveaux linguistiques de dépendance — de la graphématique à la pragmatique — et appliquerons à la programmation des méthodes de linguistique comparée pour voir en quoi la grammaire des langages de programmation peut induire, ou non, des façons différentes de penser la programmation.

_Notes_

étude de la partie non littéraire du code et langues dont dérives languages de programmation

Système de codage
- assembleur ressemble à l'anglais
- resseblance avec des langues qu'on connait aide beaucoup à l'intelligibilité

la plupart des langages de praogrammations s'appuient sur l'anglais
- alphabet
- lexique
- morphologie compositionnelle (exemple *bus.station*)
- syntaxe

Pourquoi l'anglais ?
- langue très analytique (allemand francisé ?), caractère attendu dans les langages formels
- langue internationale utilisée partout ? proximité géographique

Jusqu'où programme-t-on anglais ?

Programmation : Langue écrite, alphabet, mot-clés mais pas de formes de mot-clés, syntaxe et sémantique, style de programmation

Est-ce qu'un langage dérive de l'anglais ? de l'alphabet ? de la syntaxe ? etc.

Exemple *irzha*, language rust en ukranien : anglais ukrainisé, mais la syntaxe reste anglaise. Traduction mot à mot
On écrit dans une autre langue mais on ne pense pas dans cette langue

Exemple: scratch, comparaison du même code dans plusieurs langues
- alphabet peut changer
- le lexique change
- mais la structure (syntaxe) ne change pas
- avec des petites variations

La différence avec l'anglais reste superficielle et ne cherchent pas profiter des spécificités de la langue "exotique".
Exceptions :
- Perligata language de programmation en latin, morphologie très riche du latin avec beaucoup de variations où le mot porte sa fonction
- Wenyan, langage en chinois classique

Programme-t-on différemment en chinois classique ?
- chinois classique similaire au rôle du latin en occident, utilisée comme une langue savante pendant 2 millénaires
- différence avec le chinois moderne
- haute densité : mot monosyllabique, grande souplesse grammaticale (changement selon le contexte et l'ordre des mots), aucune flexion ni de ponctuation, incitation à la concision
- "horizontalité" syntaxique : faible niveau de récursion et utilisation de l'anaphore et de pronoms
- Wenyan lourdingue mais du Wenyan
- ce n'est pas de l'anglais, il y a des structures adaptées à la langue

_Questions/Réponses_
Langague *Inform* écrit en langue naturelles (literate problématique)
Exemple d'*Isabelle* en français ou le langage *Catala* pour les textes de loi

Exemple de Small Talk: mots anglais mais syntaxe différente

Exposition à un paradigme (fonctionnel vs procédural) et difficultés à s'en extraire

### _Les notebooks au miroir de la sociologie du code : réflexions à partir d'une enquête sur l'écriture informatique_

:::info
**Présentateur:** Gabriel Alcaras, Sociologue du travail, post-doc au MediaLab de SciencePo | Les notebooks au miroir de la sociologie du code : réflexions à partir d'une enquête sur l'écriture informatique
**Discutant:** Emilien Schultz
:::

_Résumé_
Comment la sociologie et l'anthropologie de l'écriture informatique peuvent-elles éclairer nos usages des notebooks ? À partir de vignettes tirées de ma recherche sur la gestion de versions et de considérations issues de la littérature existante, j'explorerai les dynamiques de collaboration, les normes d'usage, et les enjeux économiques liés à ces outils. À partir de ces exemples, nous formulerons quelques hypothèses pour une approche critique et réflexive des notebooks, afin de mieux se les approprier dans nos pratiques de l'enseignement et de la recherche.

_Notes_

#### Dimensions épistémiques

L'automisation produit de la connaissance par réflexivité

> La science est une connaissance que nous compenons si bien que nosu pouvons l'enseigner à un ordinateur [...].
> Computer Programming as an Art (Knuth, 1974)

La programmation ne doit pas devenir une science mais doit nous permettre de nous aider à définir notre art

Aspects épistiques du code.
Savoir et ignorance dans la production logicielle :

"Codes. L'informatique comme elle s'écrit", RESET (2022)

Ionescu : _Hardcoding the Smart Factory_ → introduction de boite noire dans le code

Elements pour une sociologie de l'activité de programmation (Florian Jaton)

Sortir de la perception du code comme une simple exécution technique. → en fait on peut apprendre des choses de la pratique de programmation.

Penser l'informatique dans le prolongement de l'écriture
- continuité entre l'informatique et les infrastructure de l'écrit

Informatique dans le prolongement des indastructures d'écriture administrative
- Control through communication (Yates 1993)
- Government mahcine (agar, 2003)
- écrire, calculer, classer (delphine gardey 2008)

Sociologie et anthropologie de l'écriture
- Goody → l'écriture comme Technologie intellectuelle
- Latour → inscriptions comme support matériel pour produire des choses de l'écrit (de la théorie)
- Jaton 2021 → programmation comme alignement d'inscriptions → moment de programmation, de débuggage : la programmation comme alignement de diff. inscriptions, par exemple le code, les messages d'erreur, la documentation, recherche google, annotations, etc → production d'alignement entre ces sources. => production d'une "mini" connaissance qui permet de comprendre ce qui s'est passé.
- besoin de mobiliser tout un tas d'annotations qui permettent de comprendre ce qu'il se passe

- interrogation du rôle de l'écriture dans les société humaines
- création de processus de pensée différents ? point de vue critiqué
- dans un laboratoire, énorménent d'écrits (*inscripitions*), support matériel pour produire les éléments de l'esprit

Git et ses inscriptions

git blame : inscriptions
qui à coder quoi et quand
- histoire social du code et si connaissance de la personne, déterminiation d'hypothèses sur les choix faits

graph de commits : "conscription device" (Henderson, 1998)

graphe comme inscription qui permet la collaboration.

dispositif de recrutement, cad sur lequel tout le monde partage la même vision du problème.

Dans le cadre collaboratif, le graphe permet de visualiser le travail.

Git, outil de narration
- l'historique des modifications permet de raconter une histoire
- git rebase permet d'arranger l'histoire de manière performative → raconter pour convaincre

Notebooks

- Carnet de terrain statistique → réflexivité
- pas seulement descriptif, mais on y écrit aussi ses propres pensées, comment on a vécu les choses
- oblige à réfléchir à ce qu'on est en train de faire
- Alignement d'inscriptions → (alt gr + i) production de connaissances locales
- dans un notebook, inscriptins qui ne cohabitent pas ensemble habituellement (du texte et du code)
- notebook comme espace de convergence
- Un outil de narration -> des inscriptions efficaces pour convaincre
- notebook comme un gros bac à sable
- ou bien comme un outil de narration → inscriptions efficaces pour convaincre

#### Questions d'usage

Est-ce que l'utilisation de nb/git modifie les pratiques ?
QU'est ce que ça fait d'utiliser git ?

La gestion de version dans les années 80, c'est le sale boulot du travail informatique.
- reconciliation de version manuelle en comparant
- à l'opposé du travail de développeur qui est d'automatiser
- mise en place de routines pour automatiser ce sale travail

Génèse de Git pour faire le sale boulot sur des récriminations des années 90
- popularité exponentielle de Linux mais pas de gestion de version
- Linus Torvalds reçoit des patchs de plus en plus nombreux, avec beaucoup de changement sans information sur ce que ça fait.
> je veux que les gens m disent ce que fait ce code
- responsabiliser les auteurs des correctifs
- créer un logiciel qui va partager le sale boulot

Avant avec SVN, il fallait être le premier à commiter et partir avant 18h. Maintenant il faut gérer les conflits de ton côté sinon ton code ne sera pas mergé
-> tout le monde doit faire de la gestion de version dans l'organisation collective du travail qui a été décidée

Diffusion de certaines pratiques associées à du sale boulot ?
- travail sur la donnée est un travail de petite main qui ne font pas la planification

#### Positions dans l'industrie

Git logiciel libre

Opensource et grandes entreprises de l'informatique marchande/

2018, rachat de gitub par Microsoft
- fin des communs numériques ?
- explotation d'un travail gratuit ?

Passer du Concept de communs au concept des biens industriels publics
- sociologie du travail/antrhropologie
- hypothèse des bons antagonistes
- les communs existent indépendamment des marchés
- informatique marchande, salariat, grandes entreprises
- se poser la question de la place des logiciels libres dans l'industrie
- Les biens industriels publics comme autre moment de la production informatique, par d'autre moyens pas possibles dans l'informatique marchande, avec une organisation différente
- économie : on fait des choses, la partie marchande n'est qu'une partie

||Communs|Bien industriels publics|
|:--|:--|:--|
|Littérature | Théorique politique, histoire des idées | Sociologie économique, sociologie du travail|
|Hypothèses| Mondes antagonistes (Zelizer, 2001) | Continuité |

Création de CVS: besoin d'un outil pour répondre à un besoin lors du travail dans la startup Prisma

Origine de git-stash: mettre de côté temporairement son travail et pouvoir y revenir

L'irruption du marchand dans le logiciel libre, ce n'est pas nouveau
- une partie des développeurs de git dès le départ sont rémunérés
- en 2020, 10% des dévelloppeurs sont rémunérés
Travail rémunénéré est à la fois une règle et une exception -> minorité des développeurs sont rémunurés mais produisent une majorité de commit

Rythme de travail des bénévoles (*heatmaps*)
- certains travaillent le week-end et le soir (bénévolat)
- certains travaillent pendant les heures de bureau (David et Nicolas)
- pas payés par leur employeur pour travailler sur git, mais leur activité est lié intrinsèquement liée à git

Instituionnalisation des logiciels libres

Transformations des rapports entre informatique marchande et l'informatique libre
- nombreux logiciels libres sont légitimés et valorisés
- changements générationnels => mailleure connaissance du libre et comment l'intégrer dans les entreprises

Bien industriels publics sont des ressources stratégiques pour les entreprises comme pour les ingénieurs

Salarisation est ambigüe: car subordination et impacte la propriété du code
- puissance des licences pour ma protection du code ?
- distance entre le développement sur le temps long du logiciel libre et l'entreprise qui produisent et ont besoin des correctifs très rapidement

Retour au notebooks : quelques idées d'enquête:

- Analyse de trajectoires de développeures (bénébole, salariat, etc.)
- Identifier les milieux professionnels et les employeurs des développeures, y comrpis les bénévoles
- Lurkers (ceux qu'on ne voit pas dans les listes de discussion, dans les PR, dans les commits) : tout ne se passe pas en ligne ou dans les commits
- retracer les étapes de formalisation (gouvernance structurée/boards, Google Summer of Code → forme associative pour recevoir des sous) qui donnent plus de prises aux entreprises

_Questions/Réponses_

versionnement du code ok mais se pose la question des données, modèles 3D etc.

Question de la propriété du code ?

Question des licences libres qui sont parfois plus restrictives pour la réutilisation dans les entreprises.
- libgit2 créé par Microsoft
- logique d'ouverture et de réutilisation par le plus grand nombre
Distinction en logiciel libre et opensource n'est pas vraiment féconde
La partie qui se développe le plus n'est pas forcément la plus militante
Briques parfois importantes pour les infrastructures mais pas pour les entreprises

Mesurer les points de friction et à quel moment les financements se déclenchent ? Quand est-ce que la communauté recule ou progresse ?

Notebookx crééent dans des milieux académiques plutôt qu'industriels

[The secret life of open source developers](https://media.ccc.de/v/bucharest-322-the-secret-life-of-open-source-developers)

La salarisation du travail dans le logiciel libre permet à plus de femmes d'y particper car elles ne pouvaient pas auparavant (double journée, aide)

Travail important de liant, d'animation de la communauté sans forcément de contributions directes.

## Ateliers

:::info
Template Ateliers : https://hackmd.io/ADCOLFRlS6mUakncv6Ut1A
:::

### Jupyter Lite: du notebook au déploiement dans le navigateur, Jérémy & Pierre

- Synopsis : Qu'offre la technologie WebAssembly/WASM en terme de déploiement et de reproductibilité des notebooks ?
- Pré-requis :
- connaître l'écosystème Jupyter (notamment Jupyter Lab)
- avoir déjà utilisé une plateforme comme GitHub ou GitLab
- ordinateur portable, connexion wifi via Eduroam ou autre, navigateur web récent, compte [GitHub](https://github.com/)
- Durée : 1h15
- Matériel :
- [Hackmd](https://hackmd.io/W5W9b4M6S7KomyVxDiKwPg)
- [PinkMyPad](https://pinkmypad.net/hackmd/W5W9b4M6S7KomyVxDiKwPg)

### Atelier plurilingue "Ticket Chic & Ticket Choc"

- Synopsis : Il s’agit de proposer de résoudre et de présenter la résolution d’une problématique spatialisée dans les divers langages et pratiques de notebook des participant⋅es aux journées, en fonction de leur point géographique de départ d’où ils et elles partent pour se rendre **en métro parisien** sur le site des journées du GT notebook.
- Pré-requis :
- savoir collecter des données, les organiser, les spatialiser et représenter
- expliciter la démarche et les choix effectués pour résoudre le problème
- le cas échéant, verser la réalisation dans un dépôt git
- Matériel :
- [pinkmypad](https://pinkmypad.net/hackmd/ykPgs6ztRZ6u18k_I2Z62A)
- deux exemples de résolution :
- https://git.unistra.fr/cesar/tp-ratp/
- https://codeberg.org/khinsen/ratp-points-of-sale
- Durée : 2 fois 1h

### Des notebooks R plus reproductibles avec Quarto, Renv et targets (Nicolas Roelandt)
- Synopsis: La reproductibilité computationnelle est un objectif difficile à atteindre et plusieurs niveaux doivent être maitrisés. Sans proposer une solution idéale, cet atelier propose à travers la mise en œuvre de plusieurs outils autour du langage R de permettre d'améliorer la reproductibilité des analyses. Ainsi le package targets fournira un meilleur contrôle des traitements réalisés, le package Renv fera lui des instantanés de l'environnement R enfin Quarto est un outil de programmation lettrée.
- Pré-requis: R, Quarto, Rstudio, packages R: targets, Renv,
- Plan
- Quarto et la programmation lettrée
- Contrôle du workflow avec {targets}
- Gestion de l'environnement logiciel avec {Renv}
- Aller plus loin
- Gestion fine de l'environnement avec Guix
- Création d'un paquetage
- Materiel :
- [PinkMyPad](https://pinkmypad.net/hackmd/rkPPxOPZyg)
- [Support](https://gt-notebook.gitpages.huma-num.fr/workshop/je_notebook_2024/notebooks-r-plus-reproductibles/support/)
- [Scripts](https://gitlab.huma-num.fr/gt-notebook/workshop/je_notebook_2024/notebooks-r-plus-reproductibles/scripts)
- Durée :

### Atelier Contribution aux Connaissances sur le Notebook

- Synopsis: Cet atelier propose plusieurs pistes de réalisations qui peuvent se faire en parallèle en petit sous-groupe de réflexion.
- Travaux orienté structure & écriture :
- Initier un travail d'écriture collectif pour améliorer la page [Wikipédia Française](https://fr.wikipedia.org/wiki/Notebook_(programmation))
- Réfléchir à la structuration et à la présentation de la base [Zotero](https://www.zotero.org/groups/4416056/gt-notebooks/library)
- Lister/Structurer/Définir les entrées dans la base de connaissance (PKM) sur les Notebook
- Travaux orienté code & outils collectifs/collaboratifs :
- Améliorer la base de connaissance collaborative (PKM) en partant d'un [premier prototype](https://gitlab.huma-num.fr/gt-notebook/workshop/je_notebook_2024/atelier-bdc-notebooks/fork-mkdocs-zettelkasten) développé sous MKDocs, packagé sous GUIX
- ajout d'un graph (voir obsidian) pour la navigation sur la page
- ajout d'un bouton edit, couplage système asynchrone (git) avec un outil d'écriture synchrone (hackmd, stylo, etc.)
- déployer le site web BDC avec le CI Gitlab, avec Guix

- Bonus : Participer au packaging d'outils de LP sous Guix
- Côté R : [Litedown](https://yihui.org/litedown/), [RMarkdown](https://rmarkdown.rstudio.com/), [Quarto](https://quarto.org/)
- Côté [Python](https://executablebooks.org/en/latest/tools/)
- Matériel : [Support](https://hackmd.io/cyrAmOdTQp-hr-DA3rkzXQ) & [PinkMyPad](https://pinkmypad.net/hackmd/cyrAmOdTQp-hr-DA3rkzXQ)
- Pré-Requis
- Durée : 2 * 2h

## Questions transversales aux ateliers

### **Littératie/langage, associer calcul et philologie**

### **Qualifier la nature des notebooks**

Un notebook est composé de texte, de code, de données, et de visualisations. On dit souvent qu'un notebook est un document, parfois qualifié de « computationnel » et d'« exécutable ». Mais on voit aussi le notebook cité comme une forme de logiciel scientifique. La notion du logiciel scientifique est elle-même assez complexe, comme l'explique [cet article](https://www.nature.com/articles/s43588-024-00651-2). Quid alors du notebook ? Peut-on le décrire également de plusieurs points de vue complémentaires pour arriver à une vue d'ensemble ?

### **Un paysage de nouvelles pratiques aux interfaces inter-disciplinaire**

Les notebooks, popularisés notamment par le projet Jupyter, ont amenés de nouvelles pratiques dans le quotidien de la recherche autour du traitement des données, de leur reproductibilité et du partage des codes et des résultats dans la mouvance de la science ouverte. Ils sont aussi devenus de nouvelles interfaces pour accéder à différentes ressources (scripts, HPC, etc.). Ce faisant, les notebooks sont progressivement devenus des "objets frontières" au sein des équipes, d'abord entre les chercheurs qui produisent les traitements et ceux.lles qui sont surtout intéressé.es par les résultats, mais aussi entre les collectifs de recherche, spécialités voire disciplines. Ces nouvelles interfaces en retour donnent naissances à de nouvelles pratiques, qui se déclinent différemment suivant les communautés épistémiques et de pratiques. Ce faisant, les notebooks contribuent à la fois à rapprocher des domaines éloignés, mais aussi à introduire de nouvelles spécificités. Or, ce paysage de la programmation scientifique en pleine mutation fait encore peu l'objet de discussion au-delà de la nébuleuse des "data science" [(Le Béchec et al.)](https://hal.science/hal-04549986/document), et appelle à croiser les regards, que ce soit concernant leur hybridation dans les usages que les enjeux d'ouverture et de propriété intellectuelle.

### **La convivialité**

Dans son livre "La Convivialité" (titre original : "Tools for conviviality"), Ivan Illich définit la technologie conviviale comme une technologie que ses utilisateurs peuvent adapter à leurs besoins, plutôt que de devoir s'adapter à la technologie. Un de ses exemples est le vélo qui est convivial alors que la voiture ne l'est pas. La convivialité des outils informatiques est un sujet important, en particulier dans la recherche scientifique. Après tout, les scientifiques sont censés comprendre et maîtriser les outils qu'ils utilisent.

Les notebooks (Jupyter, RMarkdown, Emacs/Org-mode, ...) sont-ils conviviaux ? Les technologies qui les supportent sont-elles conviviales ? Les environnements de calcul sur lesquels les notebooks s'appuient sont-ils conviviaux ? Existe-t-il des technologies alternatives plus conviviales dont nous pourrions nous inspirer ? La convivialité dans la recherche doit-elle être évaluée au niveau du chercheur individuel, d'une équipe, ou d'une communauté disciplinaire ? Telles sont les questions que nous examinerons dans cet atelier.

### **La reproductibilité**

Dans l'idéal, tout calcul fait dans le cadre d'un projet de recherche devrait être reproductible. N'importe qui devrait pouvoir partir de la description publiée, refaire le calcul, et trouver des résultats identiques. La réalité reste pour l'instant assez loin de cet idéal.

Les notebooks sont souvent proposés comme une technologie qui améliore la reproductibilité (voir par exemple [le titre de cette publication ](https://doi.org/10.3233/978-1-61499-649-1-87). Par rapport à un calcul qui n'est pas du tout documenté, c'est sûrement vrai. Mais quand on teste la reproductibilité de notebooks publiés (voir [ces](https://doi.org/10.1109/MSR.2019.00077) [deux](https://doi.org/10.1093/gigascience/giad113) études), on trouve que là encore, la réalité diffère des ambitions.

Que peut-on donc valablement affirmer au sujet de la reproductibilité ? Et comment peut-on faire mieux dans l'avenir ?

### **Ecosophie**