La reproductibilité des notebooks computationnels
Meetup INSEE Science Ouverte 2026
2026-05-21
Constats de départ
- Interdépendance traitement des données & programmation scientifique
- Depuis 2012 : nouveau format de notebooks computationnels
- Comme pour les tableurs, un mélange de concepts & de logiciels
- Pratique & enseignement
La place de ces notebooks computationnels + favorisent-ils la reproductibilité des traitements de données ?
Expérience personnelle, réflexions dans le projet NOOS (avec Mariannig Le Béchec, Célya Gruson-Daniel et Clémence Lascombes) et le GT Notebooks
Le périmètre (large) des notebooks computationnels
De quoi parle-t-on ? Un format qui lie code et contenu inspiré de la programmation lettrée (literate programming) reposant sur un environnement d’exécution
- Des notebooks interactifs avec kernel : Mathematica, Jupyter, Marimo…
- Des notebooks statiques à compiler : Quarto, RMarkdown
- Des solutions intermédiaires : le cas de Rmarkdown notebooks in RStudio
- Des intégrations dans des plateformes data : Databricks, Deepnote, Kaggle…
Les notebooks computationnels dans ma vie
Pas un usage unique mais un spectre de pratiques (en Python uniquement)
- Test de package/API
- Doc de travail collaboratif
- analyse des missions du laboratoire, sur Onyxia
- Support finalisé de formation
- tutorial BERTOPIC sur un dépôt public
Et en parallèle : des scripts, des fichiers markdown, etc.
Quarante ans de notebooks computationnels
Remettre un peu en perspective d’un format
- 1988: Mathematica : logiciels mathématiques interactifs
- 2001: IPython : shell interactif scientifique
- 2011: IPython Notebook : le format
.ipynb en navigateur
- 2012: Rmarkdown : le format
.Rmd
- 2014: Projet Jupyter : multi-langage, indépendance institutionnelle
- 2018: JupyterLab : environnement modulaire
- 2017–2020: Google Colab, MyBinder : le notebook devient un service
- 2023+: IA générative, Marimo, agents : nouvelle vague
Une histoire de glissements : du logiciel scientifique vers la plateforme grand public
La centralité du projet Jupyter
Un format ancré dans la programmation scientifique venu de la recherche (Schultz 2023).
“If you typed Python in the command line, you got a, an interactive shell, it was a very, very primitive and it didn’t allow me to do the kinds of things that were very natural in interactive scientific workflows with tools like IDL or Mathematica that I used heavily or Matlab or Maple that other used which was simply to type a bit of code, see the results right there, open a plot, look at the files on, on the file system, et cetera.” Fernando Pérez, 2012
Une promesse “native” de reproductibilité
Avoir le code et les résultats rapprochent de la reproductibilité
Une réflexion écosystémique de la reproductibilité
En lien avec les forges, les dépots de données, etc.
![]()
Juliette Taka and Nicolas M. Thiery. Publishing reproducible logbooks explainer comic strip. Zenodo. DOI: 10.5281/zenodo.4421040 (2018).
Une très forte popularité d’adoption
Pourquoi ? De multiples facteurs, et une question ouverte
- Pensé pour faciliter la boucle d’interaction code/résultat
- Relaxe beaucoup de contraintes (ce qui peut poser des problèmes)
- Permet une trame narrative qui facilite l’exposition (et l’enseignement)
- Facilite le partage du contenu (même s’il n’est pas exécuté, il reste lisible)
- Facilite l’accès à des interfaces (notamment sous forme de service)
“I think notebooks are popular for the same reason that explains the popularity of spreadsheets such as Excel. I haven’t met a single software engineer who loves Excel. Everyone hates it and makes fun of it, but why do so many users still use it?”
Une fragmentation de l’espace des notebooks
Qui double la diversité d’usages
Format / exécution
- Jupyter (interactif, out-of-order)
- Marimo (réactif, dépendances explicites)
- Quarto / RMarkdown (statique, oriente document)
Plateformes intégrées
- Google Colab (gratuit, GPU, + Gemini)
- Databricks / Snowflake (entreprise, données)
- Hex / Deepnote (collaboratif, dashboards)
Chaque combinaison déplace les compromis : reproductibilité, collaboration, accès aux données
Utiliser des notebooks ? Un sujet polarisant
Notamment sur les aspects de reproductibilité
Tensions entre deux cultures : ingénierie logicielle et analyse de données
Une faible reproductibilité ?
Des degrés de reproductibilité : paradigme spécifique aux notebooks interactifs qui n’est pas celui des logiciels (Nguyen et al. 2025).
Une liste de griefs
Surtout vu des bonnes pratiques de la programmation (logicielle)
- Ordre d’exécution potentiellement différent (et accumulation du hidden state)
- Difficulté au versionnement de code
- Peu de gestion des dépendances
- Amène de nouveaux publics peu habitués aux bonnes pratiques de programmation
- …
(mais des critiques adressées en général à la programmation scientifique)
Des pratiques bien installées là pour rester
Les notebooks computationnels sont intéressants pour l’exploration et l’explicitation des traitements
![]()
Huang, Ruanqianqian, Savitha Ravi, Michael He, Boyu Tian, Sorin Lerner, and Michael Coblenz. 2025. How Scientists Use Jupyter Notebooks: Goals, Quality Attributes, and Opportunities. arXiv:2503.12309. arXiv. https://doi.org/10.48550/arXiv.2503.12309. Huang et al. (2025)
Des bonnes pratiques qui se stabilisent
Qui se rapprochent de pratiques générales de science ouverte
Au-delà des bonnes pratiques : tension exploration - explication
Un notebook computationnel est un artefact qui commence généralement comme un scratch pad (exploration) et peut, pour certains, finir comme un document complet (explication) — voire un livre avec Jupyter Book (Rule et al. 2018)
« We found that each task fit into one of three categories: disposable exploration, findings, and artifact » Huang et al. (2025)
Les notebooks évoluent dans le temps (Raghunandan et al. 2023) et à ce titre sont souvent des objets intermédiaires.
Les notebooks sont (souvent) une vinaigrette
- Programmation lettrée : garder ensemble (et mélangé) réflexion et traitements
- Les notebooks doivent rester utilisés (agités) — sinon ils se figent et se cassent
- Corollaire : un notebook qui n’est plus exécuté n’est plus un notebook, c’est un document fossile
- Pour construire des archives durables, ou pour séparer les usages (aller vers des logiciels), peut-être pas le format le plus fort
Il manque une sémantique pour marquer leur stade d’avancement
La question de la pérennité
Un format vivant n’est pas un format d’archive
- Le
.ipynb mélange code, sorties et métadonnées d’exécution : tout évolue indépendamment
- Dépendance forte aux versions de bibliothèques, aux noyaux, aux interfaces
- Dix ans plus tard : moteur disparu, sorties figées, URLs cassées
Pistes : Software Heritage (archivage du code), Zenodo + DOI (versionner les livrables), conversion vers HTML/PDF au moment du dépôt
Pérenniser un notebook = en sortir
Ce qu’il manque actuellement
Beaucoup d’inconnues sur les pratiques (en général, et en particulier sur les notebooks)
- Les profils d’apprentissage de la programmation
- Quel effet de commencer par des notebooks ?
- Les conditions de bifurcation & de cohabitation
- Qu’est-ce qui déclenche le passage vers un autre format ? Comment les différents formats coexistent ?
- Les formes de réutilisation des notebooks
- Comment sont utilisés les notebooks publics existants ?
- Les usages avancés
- Comment se fait l’intégration dans d’autres outils : Quarto, Jupyter Book, etc. ?
![]()
L’IA dans les notebooks — trois mouvements à distinguer
- Copilotes intégrés : Cursor, Colab + Gemini, JupyterAI — suggestion de code dans l’éditeur
- Agents de notebook : nb-cli, génération et exécution autonome de cellules
- Le notebook comme contexte à prompt : le non-code (markdown, sorties précédentes) devient ressource pour le LLM
![]()
Blog Jupyter
Opportunité : un notebook non reproductible reste réutilisable si le prompt et le contexte sont lisibles (Nguyen et al. 2025)
Conclusion — une réponse mitigée
Les notebooks favorisent-ils la reproductibilité ? Oui et non, selon ce qu’on appelle « reproductibilité ».
- Ce qu’ils favorisent : trace explicite des étapes, diffusion conjointe code / résultats / narration, abaissement du coût d’entrée à l’analyse de données
- Ce qu’ils fragilisent : hidden state et ordre d’exécution, gestion des dépendances, ancrage dans des interfaces qui évoluent vite
- Un paradigme propre : pas la reproductibilité du logiciel, plutôt celle d’un carnet de laboratoire exécutable (Nguyen et al. 2025)
Conclusion — pistes pour bien les utiliser
- Distinguer format, logiciel et infrastructure : les arbitrages ne sont pas les mêmes
- Reconnaître la diversité des usages (du scratch pad à l’artefact) : un même outil, plusieurs régimes de qualité attendus
- Garder l’humain au centre : la valeur du notebook tient à la boucle interactive, pas au seul fichier
.ipynb
- Prévoir la sortie du notebook :
- en le finalisant (linéarisation, date, licence, environnement)
- en le transformant en document ou en script quand l’usage se stabilise
L’enjeu n’est pas de choisir pour ou contre les notebooks, mais de mieux outiller leurs transitions — du brouillon vers le partage, du partage vers l’archive.
