La reproductibilité des notebooks computationnels

Meetup INSEE Science Ouverte 2026

Émilien Schultz (CREST/CSS@IPP)
emilien.schultz@ensae.fr

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

Question

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
    • appel ollama, en local
  • 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é

Kluyver et al. (2016)

Avoir le code et les résultats rapprochent de la reproductibilité

Peng, Roger D. 2011. « Reproducible Research in Computational Science ». Science

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?”

Le rôle d’interface des notebooks - le cas Google Colab

Accès à un écosystème + des ressources (dont GPU) depuis 2017 facilite les usages

Summarising 3 Years of Google Colab Usage — The Good, the Bad, and The Ugly

D’autres interfaces : HPC, etc. - le succès d’Onyxia

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é

The First Notebook War

Tensions entre deux cultures : ingénierie logicielle et analyse de données

Une faible reproductibilité ?

Samuel and Mietchen (2024)

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

Rule et al. (2019)

Le Béchec et al. (2024)

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.

Références

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.
Kluyver, Thomas, Benjamin Ragan-Kelley, Fernando Pérez, et al. 2016. “Jupyter Notebooks—a Publishing Format for Reproducible Computational Workflows.” Positioning and Power in Academic Publishing: Players, Agents and Agendas - Proceedings of the 20th International Conference on Electronic Publishing, ELPUB 2016, 87–90. https://doi.org/10.3233/978-1-61499-649-1-87.
Le Béchec, Mariannig, Célya Gruson-Daniel, Clémence Lascombes, and Émilien Schultz. 2024. “Notebook and Open Science : Toward More FAIR Play.” Journal of Data Mining & Digital Humanities Atelier Digit\_Hum (December): 13428. https://doi.org/10.46298/jdmdh.13428.
Nguyen, Tien, Waris Gill, and Muhammad Ali Gulzar. 2025. Are the Majority of Public Computational Notebooks Pathologically Non-Executable? arXiv. https://doi.org/10.48550/ARXIV.2502.04184.
Raghunandan, Deepthi, Aayushi Roy, Shenzhi Shi, Niklas Elmqvist, and Leilani Battle. 2023. “Code Code Evolution: Understanding How People Change Data Science Notebooks Over Time.” Conference on Human Factors in Computing Systems - Proceedings, ahead of print. https://doi.org/10.1145/3544548.3580997.
Rule, Adam, Amanda Birmingham, Cristal Zuniga, et al. 2019. “Ten Simple Rules for Writing and Sharing Computational Analyses in Jupyter Notebooks.” PLoS Computational Biology 15 (7): 1–8. https://doi.org/10.1371/journal.pcbi.1007007.
Rule, Adam, Aurélien Tabard, and James D. Hollan. 2018. “Exploration and Explanation in Computational Notebooks.” Conference on Human Factors in Computing Systems - Proceedings 2018-April: 1–12. https://doi.org/10.1145/3173574.3173606.
Samuel, Sheeba, and Daniel Mietchen. 2024. “Computational Reproducibility of Jupyter Notebooks from Biomedical Publications.” GigaScience 13 (January): 1–31. https://doi.org/10.1093/gigascience/giad113.
Schultz, Emilien. 2023. Du laboratoire à Jupyter: La trajectoire d’un instrument logiciel libre de la science ouverte.

Annexe : L’écosystème Jupyter

Architecture du projet Jupyter