# Un court état des lieux de la recherche reproductible

Christophe Pouzat

IRMA, Université de Strasbourg et CNRS

christophe.pouzat@math.unistra.fr

31 mai 2023

# 1 Introduction

## 1.1 Qu'est-ce que la « recherche reproductible » et pourquoi en faire ?

La recherche reproductible a pour but de diminuer l'écart entre un idéal — les résultats de recherche publiés devraient être « reproductibles » — et la réalité — il est souvent difficile, même pour leurs auteurs, de reproduire des ou leurs résultats. Concrètement, c'est une démarche qui consiste à fournir aux lecteurs d'articles, d'ouvrages, etc., l'ensemble des données et des programmes utilisés pour obtenir les résultats présentés *accompagnés d'une description algorithmique de la façon dont les programmes ont été appliqués aux données, ainsi que, si besoin, de l'environnement de calcul*.

Un élément implicite mais important de la définition précédente est que, dans la pratique, ce qui est entendu par « reproduction » est tout ce qui vient *après* la collecte des données; il serait donc plus judicieux de parler d'*analyse reproductible des données*. Mais comme l'approche requiert un *accès libre* à celles-ci, elles deviennent critiquables et comparables, *ce qui devrait améliorer la reproductibilité des données elles-mêmes*<fnref n="1" />.

<footnote n="1">1. Il est souvent frustrant pour un expérimentateur de ne pas pouvoir comprendre un résultat obtenu par un autre laboratoire, bien que la description, nécessairement succincte, des données (valeur moyenne, écart-type, auto-corrélation, agrémentés d'une figure « représentative ») suggère qu'elles sont semblables à celles qu'il collecte lui-même. L'acquisition des données implique en effet d'innombrables « détails » qui ne peuvent être tous décrits dans un article, ni même dans un ouvrage technique. Avoir un accès complet aux données des collègues, devrait ainsi permettre d'identifier précisément en quoi les données des deux laboratoires diffèrent. Cela rendrait plus efficace, par un dialogue entre laboratoires, l'identification, parmi les « détails » ci-dessus, de ceux qui sont effectivement des détails, car ils sont sans influence, de ceux qui n'en sont pas.</footnote>
Du fait du caractère très explicite de la présentation des résultats que la recherche reproductible impose, considérée comme méthodologie, elle intéresse un public beaucoup plus large que celui des (enseignants-)chercheurs produisant des publications. Même si les résultats ne sont pas rendus publics, comme au sein d'une entreprise privée, cette façon de travailler permet une préservation des savoir-faire. Cette méthodologie peut aussi être adoptée avec grand profit lors de la préparation de cours, de didacticiels ou d'ouvrages techniques.

## 1.2 Reproductibilité, replicabilité, répétabilité ?

Le lecteur curieux effectuant une recherche sur Internet s'apercevra vite qu'un débat assez intense porte en ce moment sur la terminologie : on parle ainsi beaucoup de reproducibilité (reproducibility), de réplicabilité (replicability), mais aussi de répétabilité (repeatability)<fnref n="2" /> [4, 1, 8, 7]. Trace des débats en cours, la nomenclature recommandée par l'acm (Association for Computing Machinery) a changé entre 2016 et 2020 : les sens donnés à « reproductibilité » et à « réplicabilité » ont été échangés! La version de 2020, traduite ci-dessous, semble s'imposer peu à peu :

- répétabilité (même équipe de recherche, même dispositif expérimental) : la mesure peut être obtenue avec la précision indiquée par la même équipe utilisant la même procédure de mesure, le même système de mesure, dans les mêmes conditions de fonctionnement, au même endroit et lors d'essais multiples — pour les expériences numériques, cela signifie qu'un chercheur peut répéter de manière fiable son propre calcul —;

- reproductibilité (quipe de recherche différente, même dispositif expérimental) : la mesure peut être obtenue avec la précision indiquée par une équipe différente utilisant la même procédure de mesure, le même système de mesure, dans les mêmes conditions de fonctionnement, dans le même lieu ou dans un lieu différent, lors d'essais multiples — pour les expériences numériques, cela signifie qu'un groupe indépendant peut obtenir le même résultat en utilisant les « outils » de l'auteur (logiciels, mais aussi potentiellement le même « environnement de calcul » : architecture matérielle, système d'exploitation, compilateurs, etc.) <fnref n="3" /> —;

- réplicabilité (quipe de recherche différente, dispositif expérimental différent) : la mesure peut être obtenue avec la précision indiquée par une équipe différente, un système de mesure différent, dans un lieu différent et lors d'essais multiples — pour les expériences numériques, cela signifie qu'un groupe indépendant peut obtenir le même résultat en utilisant des artefacts (logiciels, etc.) qu'il a développés de manière totalement indépendante.

<footnote n="2">2. Parmis ces trois termes, seul « reproductibilité » est dans le Larousse, le Robert, le TLFi et le Wiktionnaire, les deux suivants ne se trouvent que dans le Wiktionnaire, mais nous entendons clairement par « réplicabilité » : « qui peut être répliqué » et par « répétabilité » : « qui peut être répété ».</footnote>

<footnote n="3">3. Cet aspect sera développé et discuté en section 3.2.</footnote>
## 1.3 Plan de l'article

La section 2 présente, dans un contexte historique, la première « tentative aboutie » de mise en œuvre de la recherche reproductible — entendue au sens de l'« acm 2020 » — et ses outils. Un article sur le sujet écrit il y a dix ans se serait arrêté là [3]. La section 3 présente les développements récents sous l'influence de trois facteurs :

- la demande croissante d'outils de recherche reproductible de la part de communautés scientifiques — en biologie et sciences humaines notamment — au bagage informatique ou numérique « faible »;

- conséquence du point précédent, l'usage de plus en plus fréquent de langages interprétés nécessitant de nombreuses bibliothèques — Python est ici le principal acteur — dont l'évolution est très (trop) rapide;

- le fait que la recherche reproductible exposée en première partie demande un surcroît de travail pour peu de bénéfices à court terme, ce qui constitue un problème majeur pour la carrière des (jeunes) chercheurs.

Il sera alors temps de conclure cet article (section 4).

# 2 Première époque

## 2.1 Un constat déjà ancien

Au début de la conclusion d'un article [9] de 1976 intitulé : *Molecular Dynamics and Monte Carlo Calculations in Statistical Mechanics*, Wood et Erpenbeck écrivent :

> Nous souhaitons néanmoins insister sur le fait que ces études [basées sur des simulations] ont de nombreuses caractéristiques communes avec les travaux expérimentaux habituels : elles sont sujettes à des erreurs aussi bien statistiques que systématiques. De ce point de vue, nous considérons que nos articles devraient respecter les mêmes critères que les articles expérimentaux. Ils devraient ainsi inclure une estimation de l'erreur statistique, une description des conditions expérimentales (c'est-à-dire les paramètres des calculs) ainsi que des informations sur la conception de l'appareil de mesure (le programme), une comparaison avec les résultats d'études antérieures, une discussion des erreurs systématiques, etc. C'est seulement dans ces conditions que les résultats pourront être utilisés pour améliorer notre compréhension théorique...

Cette citation traduit, à mon sens, les problèmes entraînés par l'absence de section « Méthodes » dans la plupart des publications que nous classerions aujourd'hui comme « computationnelles ». Mais il se trouve que pour ce type de travail, la section « Méthodes » des articles expérimentaux peut être rendue beaucoup plus explicite grâce aux outils de développement logiciels. C'est ce qu'a démontré l'approche proposée au début des années 90 par le *Stanford Exploration Project* (SEP).
## 2.2 Le Stanford Exploration Project

En 1992, Jon Claerbout et Martin Karrenbach dans une communication au congrès de la Society of Exploration Geophysics écrivent :

> Une révolution dans la formation et dans le transfert technologique résulte du mariage du traitement de texte et des interpréteurs en ligne de commande de type script. Ce mariage permet à un auteur d'associer à chaque légende de figure une étiquette référençant tout ce qui est nécessaire à le régénération de la figure : les données, les paramètres et les programmes. Ceci fournit une exemple concret de reproductibilité en science computationnelle. Notre expérience, au *Stanford Exploration Project*, montre que la préparation de ce type de document électronique ne demande pas beaucoup plus de travail que celui nécessaire à la préparation d'un rapport classique; il faut juste tout archiver de façon systématique.

### Les outils du Stanford Exploration Project

Les géophysiciens du SEP effectuent l'analyse de gros jeux de données ainsi que des simulations de modèles géophysiques « compliqués » (basés sur des EDPs); ainsi :

- ils ont l'habitude des langages compilés et normalisés comme le Fortran et le C;

- ils emploient des moteurs de production comme Make;

- ils écrivent leurs articles en TFormula [5] et LATEX [6].

L'idée clé est d'utiliser le moteur de production, non seulement pour générer les « exécutables », mais aussi pour appliquer ces derniers aux données grâce à des scripts — et ainsi (ré)générer les figures et les tables de l'article automatiquement — avant de compiler le fichier .tex.

Avec cette approche, nous voyons que tout (données, codes sources, scripts, textes) est conservé dans une collection de répertoires imbriqués ce qui rend le travail « facile » à sauvégarder et à distribuer; de plus un accent est mis dès le départ sur l'utilisation de logiciels libres avec un recours aux langages de programmation normalisés. Par contre, l'emploi de TFormula (ou LATEX) se prête mal à la « prise de notes »<fnref n="4" /> et constitue souvent un véritable obstacle pour les chercheurs hors des maths et de la physique. De plus, la gestion d'une arborisation de fichiers, pour ne pas dire l'ensemble de l'approche, s'avèrent « lourdes » dans le cadre d'une analyse exploratoire « au quotidien ».

### Les « nouveaux » outils qui permettent à tout un chacun de mettre en œuvre l'approche du SEP

Au début des années 2000, le verrou constitué par LATEX a été essentiellement éliminé par le développement des langages de balisage léger comme : Markdown; reStructuredText; Asciidoc; Org mode (utilisé pour écrire ce texte). Avec le logiciel pandoc il est possible de

<footnote n="4">4. J'entends par là qu'il est important, pour la prise de notes, d'avoir à taper au clavier aussi peu de caractères que possible. De ce point de vue, les balises de LATEX, si elles restent plus courtes que celle du HTML, peuvent quand même sembler (trop) longues. Le section suivante éclairera ce propos.</footnote>
passer quasi instantanément de l'un à l'autre et, grâce à l'extension pandoc de Markdown, un débutant avec une heure de pratique peut générer un fichier LATEX qui ferait envie à un expert [2].

Le mariage du langage de balisage léger avec des langages interprétés populaires comme Python et R a résulté dans des « cahiers de notes numériques »<fnref n="5" /> (notebooks) qui permettent très facilement de mélanger un texte descriptif / explicatif avec des lignes de codes. On obtient ainsi des documents dynamiques dans lesquels, les figures et les tables ont été remplacées par les instructions qui les génèrent. Il est alors possible de recalculer les résultats, mais aussi d'inspecter et de modifier les instructions qui les ont générés.

La gestion d'arborisation de fichiers est maintenant grandement facilitée par la diffusion du logiciel de gestion de version décentralisé git et des serveurs associés GitHub et GitLab<fnref n="6" />. En fait, la combinaison langage de balisage léger / serveur git est tellement efficace et accessible qu'elle peut être employée avec profit par toute personne travaillant sur des textes (je pense aux disciplines littéraires).

Le partage des données, nécessaires à une mise en œuvre complète de la recherche reproductible, a aussi longtemps été un obstacle majeur pour les disciplines qui en génèrent en grande quantité. Les astrophysiciens confrontés très tôt au problème avaient dès les années 70 développés des formats de fichiers permettant de stocker des grandes quantités de données hétérogènes — le format FITS (Flexible Image Transport System), toujours utilisé — ainsi que des serveurs hébergés, par exemple, par la NASA. Ces idées ce sont généralisées avec, au niveau du format de fichiers, le Hierarchical Data Format (HDF5) et, au niveau des serveurs de données, des initiatives comme zenodo.

Nous disposons ainsi à présent d'outils de bases, essentiellement dérivés du développement logiciel, qui permettent après un apprentissage peu « chronophage » de mettre en œuvre la recherche reproductible. J'ai néanmoins bien conscience que le tour d'horizon proposé dans cette section a été très (trop) bref. J' invite donc le lecteur curieux d'en savoir plus à suivre le CLOM (MOOC)<fnref n="7" /> gratuit, qu'Arnaud Legrand, Konrad Hinsen et moi même avons préparé : Recherche reproductible : principes méthodologiques pour une science transparente.

# 3 L'évolution actuelle

## 3.1 Nouvelles communautés, nouvelles contraintes, nouvelles solutions

Avec la généralisation des approches quantitatives, de plus en plus de communautés scientifiques de tailles considérables, comme la biologie au sens large et les sciences hu-

<footnote n="5">5. Il s'agit pour le logiciel R du paquet RMarkdown dont l'usage est rendu aussi simple que celui d'un éditeur de texte par l'environnement de développement RStudio. Les utilisateurs de Python peuvent quand à eux employer Pweave ou le « carnet de notes » (notebook) de jupyter. jupyter peut également être utilisé avec Matlab ou Mathematica. Ce dernier logiciel, tout comme Maple, dispose d'une fonctionnalité notebook « intégrée ».</footnote>

<footnote n="6">6. De nombreux instituts de recherche comme l'INRIA, l'INSMI (les maths du CNRS) et de plus en plus d'universités proposent aux chercheurs leurs propres serveurs basés sur GitLab</footnote>

<footnote n="7">7. Cours en Ligne Ouvert Massif / Massive Open On-line Course.</footnote>
maines, se sont mises à produire une partie de leur résultats par analyse ou simulations sur
ordinateurs. Les membres de ces communautés, de par le cursus qu'ils ont suivis, ont ra-
rement une culture informatique ou numérique comparable à celle des chercheurs du SEP.
Leur bagage dans ce domaine se limite souvent à un cours d'introduction à Python (par-
fois à Matlab ou R) et ni les langages compilés, ni les moteurs de production comme Make
ne font partie de leur « boîte à outils ». Leur demande de « solutions tout en un » génère
dès lors une profusion de bibliothèques ou de modules utilisables directement depuis leur
langage interprété et interactif favori : Python dans la majorité des cas. De plus, ces bibliothèques ou modules tendent à être développés par un petit groupe dont les membres sont
renouvelés souvent. Par-rapport à l'exemple précédent du SEP, nous sommes ainsi passés d'une situation où le gros des utilisateurs (de bibliothèques ou modules) étaient eux-mêmes développeurs et où ils avaient tendance à s'inscrire dans la durée (les perspectives de l'emploi scientifique étant alors plus favorables) à une situation où les développeurs sont bien moins nombreux que les utilisateurs (qui n'ont en plus pas le bagage nécessaire à critiquer les outils qu'ils utilisent) et où développeurs comme utilisateurs travaillent souvent pendant peu de temps sur ou avec un outil. Cela a des conséquences importantes pour la recherche reproductible sur lesquelles nous reviendront dans la section suivante.

Enfin, du fait de la complexité des tâches de récupération et d'agrégation de données ou du fait de la complexité des chaînes de traitement utilisées, ces « nouvelles » communautés ont poussé de façon très intéressante le développement d'extension du moteur de production traditionnel pour aboutir aux *workflows* ou *pipelines* modernes — Ricardo Wurmus a donné une présentation courte et lumineuse des enjeux et problèmes des *workflows* dans le cadre de la recherche reproductible au FOSDEM 2021 <fnref n="8" />. Ces outils <fnref n="9" /> intéressent *a priori* toute personne impliquée dans la recherche reproductible.

## 3.2 Reproductibilité dans la durée

Une expérience souvent désagréable attend le chercheur qui se lance dans la recherche reproductible : malgré un document dynamique préparé avec le plus grand soin et permettant effectivement de régénérer une étude complète *au moment de la création du document*, cette régénération échoue six mois ou deux ans après. Cet échec résulte de la non prise en compte de la dépendance des résultats (numériques) de l'étude vis à vis de l'environnement logiciel dans lequel celle-ci a été effectuée<fnref n="8" />. Cela peut se traduire concrètement (c'est une expérience tout à fait réelle) par une mise en œuvre de la méthode d'optimisation quasi-Newton BFGS (Broyden-Fletcher-Goldfarb-Shanno) ayant complètement changé lors d'une mise à jour de la bibliothèque SciPy de l'« écosystème Python scientifique ». Ainsi, la même optimisation sur les mêmes données ne donne plus les mêmes résultats. Clairement, dans cette situation, une saine attitude scientifique consiste à faire une comparaison détaillée des deux mises en œuvre pour déterminer celle qui est (la plus) correcte. Mais une

<footnote n="8">8. https://fosdem.org/2021/schedule/event/guix_workflow/.</footnote>

<footnote n="9">9. Il y en a profusion — voir le dépôt GitHub : *Awesome Pipeline* —, l'évolution est rapide ce qui rend toute recommandation délicate à ce stade.</footnote>
tendance lourde en recherche reproductible, la reproductibilité bit à bit<fnref n="10" />, pourrait amener à « évacuer » cette question pour privilégier un critère évaluable par une machine. Des échecs de reproduction dûs à un changement de la mise en œuvre de la méthode BFGS ou à un changement des couleurs par défauts utilisées par la bibliothèque graphique de Python, `matplotlib`, se verraient ainsi attribués le même poids<fnref n="11" />. Le choix d'une reproductibilité bit à bit combiné à l'adoption de logiciels de « haut niveau », qui évoluent vite, sans que les développeurs se soucient outre mesure de la rétrocompatibilité (*backward compatibility*) de leurs bibliothèques — un problème récurrent de l'écosystème Python<fnref n="12" /> — expliquent le recours de plus en plus systématique aux *conteneurs* comme *Docker* ou *Singularity*. Ceux-ci permettent, théoriquement au moins, de préparer une image exécutable contenant *tout* ce qui est nécessaire à la réplication d'un calcul (programmes, logiciels, bibliothèques), en figeant l'état, c'est-à-dire la version, de chaque élément constitutif de l'image. Une critique claire de cette approche est développée par R. Wurmus⁸ — le lecteur qui voudrait se familiariser rapidement à ce type d'outils pourra consulter avec profit le cours en ligne *Reproducible research* du projet *Code Refinery*. Il est clair que la reproductibilité bit à bit constitue le critère idéal de reproductibilité dans une période où les instances d'évaluation se focalisent d'une part sur des indices bibliométriques et, d'autre part, commencent à demander une « recherche reproductible » : avec la reproductibilité bit à bit, on peut faire une telle recherche sans trop perdre de temps — car on fige sa pile logiciel plutôt que de décrire précisément ce qu'on fait — et on produit plus (d'articles). Je ne suggère pas ici que la reproductibilité bit à bit est sans intérêt en soi, je suis le premier à vérifier que mes calculs, effectués avec les mêmes paramètres et des exécutables générés à partir des mêmes fichiers sources, mais des compilateurs différents, donnent les mêmes résultats (au bit près). Je suggère par-contre qu'il y a « danger » à voir la reproductibilité bit à bit être considérée comme une condition suffisante pour faire de la recherche reproductible. Après tout, le critère de reproductibilité pour l'acm 2020 correspond bien, dans le cadre numérique, à la reproductibilité bit à bit; et mon expérience de critique ou *reviewer* de manuscrits (en « neurosciences computationnelles ») va dans le sens de l'implication ci-dessus.

Il y a potentiellement une alternative — à la combinaison logiciels de « haut niveau » plus conteneurs — que les chercheurs plus âgés, ayant déjà un emploi permanent, peuvent s'offrir le luxe d'explorer : cloisonner au maximum les étapes d'une étude; avoir recours le plus possible à des programmes écrits dans un langage compilé et normalisé comme le Fortran, le C ou le C++; utiliser Python au minimum et essayer de se limiter à sa bibliothèque standard. Les langages normalisés évoluent, mais moins vite; une grande importance est accordée par les comités de normalisation à la rétrocompatibilité d'une version à l'autre; plusieurs compilateurs de grande qualité sont systématiquement disponibles.

<footnote n="10">10. Une étude génère une collection de fichiers qui peut être vue comme une séquence de bits et l'étude est reproductible si, lorsque le document dynamique est relancé, une séquence identique est obtenue.</footnote>

<footnote n="11">11. Dans les cas extrêmes, on accorde plus de crédit à un résultat faux mais reproductible bit à bit, qu'à un résultat scientifiquement correct mais non reproductible bit à bit car la couleur par défaut des graphes est passée du noire au bleu.</footnote>

<footnote n="12">12. Le lecteur, pour s'en convaincre, est fortement encouragé à lire la justification de la refonte totale de la génération de nombres (pseudo)aléatoires dans la bibliothèque ` numpy`, par le seul (!) développeur responsable de cette fonctionnalité : https://numpy.org/neps/nep-0019-rng-policy.html.</footnote>
Cette approche n'élimine pas tous les problèmes de dépendance, mais elle les limite fortement.

# 4 Conclusions

Mettre en œuvre une recherche reproductible « au quotidien » ne présente plus aujourd'hui de gros problèmes. Le chercheur n'a pas besoin de changer radicalement sa façon de travailler, juste de systématiser un peu son travail; les outils nécessaires sont disponibles et maintenant bien documentés; des cours sont développés. Mais la recherche reproductible est une approche jeune qui doit faire face à des problèmes pas toujours pleinement anticipés, comme la reproductibilité dans la durée. Comme toute discipline nouvelle et dynamique elle voit se présenter de nombreuses propositions de solutions, pas toujours compatibles entre elles, aux problèmes rencontrés. Nous avons ainsi aujourd'hui de nombreux moteurs de workflow à disposition, plusieurs systèmes de conteneurs, etc. Comme l'un des enjeux majeurs est la fiabilité dans le temps il va nous falloir faire preuve de patience et d'ouverture.

# Remerciements

Je remercie mes collègues (et complices) Konrad Hinsen et Arnaud Legrand pour leurs critiques toujours pertinentes, argumentées et constructives.

# Références

[1] Lorena A. BARBA. *Terminologies for Reproducible Research*. 2018. arXiv: 1802.03311 [cs.DL].

[2] Jean-Daniel BONJOUR. *Élaboration et conversion de documents avec Markdown et Pan-doc*. Sous licence CC BY-SA 4.0. 2014. URL: https://www.jdbonjour.ch/cours/markdown-pandoc/

[3] Matthieu DELESCLUSE et al. "Making neurophysiological data analysis reproducible: Why and how?" In: *Journal of Physiology-Paris* 106.3-4 (mai 2012), p. 159-170.

[4] Steven N. GOODMAN, Daniele FANELLI et John P. A. IOANNIDIS. "What does research reproducibility mean?" In: *Science Translational Medicine* 8.341 (2016), 341ps12-341ps12.

[5] Donald E. KNUTH. *The TeXbook*. Reading, Massachusetts: Addison-Wesley, 1984, p. x+483.

[6] Leslie LAMPORT. *LaTeX: A Document Preparation System*. Reading, Massachusetts: Addison-Wesley, 1986.

[7] NATIONAL ACADEMIES OF SCIENCES, ENGINEERING AND MEDICINE. *Reproducibility and Replicability in Science*. Washington, DC: The National Academies Press, 2019.

[8] Hans E. PLESSER. "Reproducibility vs. Replicability: A Brief History of a Confused Terminology". In: *Frontiers in Neuroinformatics* 11 (2018).

[9] W W WOOD et J J ERPENBECK. "Molecular Dynamics and Monte Carlo Calculations in Statistical Mechanics". In: *Annual Review of Physical Chemistry* 27.1 (oct. 1976), p. 319-348.