Recherche non reproductible ? Un guide pratique

Une recherche non reproductible se produit lorsqu’un groupe indépendant, avec les mêmes données, le même code et les mêmes méthodes décrites, ne peut pas obtenir le même résultat, un problème documenté dans toutes les disciplines que les informaticiens peuvent attaquer directement parce que le logiciel, et non la technique de laboratoire humide, est généralement le point d’échec. Des normes telles que le rapport 2019 des National Academies Reproducibility and Replicability in Science définissent le vocabulaire de travail, et les solutions pratiques sont concrètes : contrôle de version, dépendances épinglées, conteneurisation et automatisation de la construction.

• La reproductibilité et la réplicabilité sont distinctes : la reproductibilité signifie réexécuter la même analyse sur les mêmes données et obtenir les mêmes chiffres ; la réplicabilité signifie qu’une nouvelle étude parvient à une conclusion cohérente.
• La plupart des recherches informatiques non reproductibles sont dues à quatre causes : code manquant ou muté, environnements logiciels non épinglés, provenance des données non documentées et étapes manuelles cachées.
• Une construction reproductible est une transformation déterministe des entrées source vers les sorties — la même idée que les builds reproductibles dans les packages logiciels, appliquée aux pipelines d’analyse.
• Le correctif minimum viable est un référentiel avec un fichier de verrouillage, un point d’entrée unique (make, Snakemake ou un script) et un README qu’un étranger peut suivre sans vous poser de questions.
• Les conteneurs (environnements Docker, Apptainer/Singularity, Conda) résolvent la dérive de l’environnement ; ils ne résolvent pas le nettoyage des données non documentées ou les algorithmes non déterministes.
• La reproductibilité est un spectre, pas un binaire : visez “un étranger compétent peut régénérer vos figures”, pas la perfection.

Que signifie réellement « reproductible » (et ce que cela ne signifie pas)

La recherche reproductible est la pratique consistant à présenter une étude de manière à ce qu’un chercheur indépendant puisse régénérer ses résultats à partir des données et du code d’origine. Le mot a une signification technique spécifique qui diffère de l’usage quotidien : dans le sens du dictionnaire, « reproductible » signifie simplement capable d’être produit à nouveau, mais en science informatique, il implique un déterminisme, une provenance et une documentation suffisante pour que la régénération ne dépende pas des connaissances tacites détenues par les auteurs originaux.

La reproductibilité en recherche appartient à une famille de termes apparentés qui sont souvent confondus. L’étude consensuelle des National Academies de 2019 distingue la reproductibilité informatique (mêmes données, même code, mêmes résultats) de la réplicabilité (nouvelles données, résultats cohérents).

Les statisticiens ajoutent la répétabilité, ce qui signifie que le même analyste obtient deux fois le même résultat. Une étude peut être reproductible mais non réplicable – le code régénère fidèlement un résultat qu’une nouvelle expérience ne parvient pas à confirmer – et cette distinction est importante pour diagnostiquer un échec.

La variante orthographique « reproductible » apparaît souvent dans les requêtes de recherche et dans l’écriture informelle, mais l’anglais standard utilise « reproducible ». Le suffixe s’attache à la racine « reproduire » sous la forme « -ible », correspondant à « productible » et « déductible ». Les guides de style et les dictionnaires ne répertorient que « reproductible » ; traitez « reproductible » comme une faute d’orthographe, même si vous le rencontrerez dans d’anciens messages de forum et dans des manuscrits dont l’anglais n’est pas la langue maternelle.

Pourquoi la recherche n’est pas reproductible : les quatre modes d’échec

Le code manquant ou muté représente une grande partie des tentatives de reproduction échouées. Un scénario courant : l’article publié décrit une analyse, l’auteur correspondant a quitté le laboratoire et le référentiel soit n’existe pas, soit contient une version obsolète, soit fait référence à un ensemble de données privé. Le code qui “fonctionne sur ma machine” mais qui n’a pas d’historique de versions ne peut pas être audité, et sans hachage de commit, il n’y a aucun moyen de savoir quelle version a produit la figure publiée.

Connexes : Dataquest — Parcours de science des données basés sur des projets avec un terminal guidé et des ensembles de données réels.

Les environnements logiciels non épinglés arrêtent la reproduction en silence. Un pipeline NumPy écrit avec la version 1.20 peut produire différents résultats en virgule flottante, des avertissements de dépréciation ou des erreurs pures et simples sous 2.x.

Les trajectoires de dynamique moléculaire générées avec une version de GROMACS ou LAMMPS peuvent différer d’une autre lorsque les indicateurs du compilateur, les bibliothèques FFT ou la décomposition parallèle changent. Le correctif consiste à enregistrer les versions exactes - un «requirements.txt» avec des hachages, un «conda env export», un «renv.lock» pour R ou un résumé d’image de conteneur - pas seulement une liste de noms de packages.

La provenance des données non documentées est le troisième mode de défaillance. La sortie brute des instruments, les fichiers de redémarrage de simulation et les archives HDF5 passent souvent par plusieurs étapes de nettoyage et de conversion qui ne sont jamais affichées dans la section méthodes.

Ça vaut le coup d'oeil : Coursera Plus — Un abonnement pour les certificats Python et de science des données soutenus par l'université.

Si un collaborateur a filtré manuellement les valeurs aberrantes dans une feuille de calcul, cette étape est invisible et non reproductible. La provenance signifie enregistrer l’origine de chaque entrée, quelles transformations ont été appliquées et dans quel ordre.

Les étapes manuelles cachées sont la quatrième. Cliquer sur une interface graphique pour exporter un tracé, renommer des fichiers à la main ou copier des numéros entre des outils interrompt l’automatisation. Le test est simple : quelqu’un qui ne vous a jamais rencontré pourrait-il faire fonctionner votre pipeline de bout en bout sans un appel téléphonique ? Si la réponse est non, les étapes manuelles sont à l’origine du problème.

Comment rendre la recherche reproductible : un flux de travail pratique

Le contrôle de version est la base. Git (ou Mercurial pour les projets existants) suit chaque modification apportée au code, aux manuscrits et aux petits fichiers de configuration.

Commitez tôt, rédigez des messages de commit significatifs et marquez le commit exact qui correspond à un article soumis. Pour les artefacts binaires volumineux (trajectoires, fichiers HDF5, poids de modèle entraînés), utilisez les référentiels Git LFS, DVC ou Zenodo/figshare avec des DOI plutôt que de consacrer des gigaoctets au référentiel.

L’épinglage des dépendances vient ensuite. Les projets Python doivent fournir un fichier de verrouillage (pip-compile, Poetry ou uv) ; Les projets R doivent utiliser « renv » ; Les projets Julia ont “Project.toml” et “Manifest.toml”. Épinglez les dépendances transitives, pas seulement les dépendances directes, car un changement profond à trois niveaux peut modifier la sortie numérique. Enregistrez le système d’exploitation, le compilateur et toutes les bibliothèques spécifiques au matériel (BLAS, CUDA) qui affectent les résultats.

Un point d’entrée unique transforme un dossier de scripts en pipeline. L’outil classique est make : un Makefile déclare les cibles, les dépendances et les commandes, et make reconstruit uniquement ce qui a changé.

Connexes : O'Reilly Learning Platform — Une bibliothèque technique approfondie de livres, de vidéos et de formations en informatique scientifique.

C’est l’essence même de la recherche reproductible avec Make : le graphique de construction documente le flux de travail et applique l’ordre. Les alternatives modernes incluent Snakemake, Nextflow et Targets (pour R). N’importe lequel d’entre eux bat un README qui dit “exécutez script1.py, puis script2.py, puis…”.

La conteneurisation capture l’ensemble de l’environnement. Les images Docker, les images Apptainer/Singularity (communes sur les clusters HPC où Docker n’est pas disponible) et les environnements Conda résolvent chacun la dérive de l’environnement.

Un conteneur avec un résumé épinglé constitue la meilleure garantie que votre analyse s’exécute de manière identique sur un ordinateur portable, un cluster et la machine d’un réviseur. Le compromis est la taille de l’image et le temps de construction ; une image de base allégée et des constructions en plusieurs étapes permettent de gérer les deux.

Si vous faites du shopping : DataCamp — Cours interactifs Python et science des données que vous codez directement dans le navigateur.

La documentation boucle la boucle. Un README doit indiquer la configuration logicielle requise, la commande exacte pour reproduire chaque figure, le temps d’exécution attendu et le résultat attendu. Un fichier « CITATION.cff » ou « codemeta.json » aide les autres à citer correctement les logiciels. Lorsqu’une étape est véritablement interactive, décrivez-la suffisamment précisément pour qu’un lecteur puisse la répéter.

Recherche reproductible avec R : un exemple concret

R possède l’un des écosystèmes de reproductibilité les plus matures, c’est pourquoi la « recherche reproductible dans R » est une recherche courante. Le package renv capture les versions du package dans un fichier de verrouillage, donc renv::restore() reconstruit la bibliothèque exacte sur laquelle un projet a été développé. R Markdown et Quarto intègrent le code, la sortie et la prose dans un seul document qui se régénère une fois généré, éliminant ainsi les erreurs de copier-coller entre l’analyse et le manuscrit.

Une structure minimale de projet R ressemble à ceci : un renv.lock pour les dépendances, un répertoire R/ pour les fonctions, un répertoire data-raw/ pour les scripts d’ingestion, un répertoire data/ pour les objets traités et un Makefile ou _targets.R qui orchestre la construction. Le package targets étend le suivi des dépendances de style make à R, en sautant les étapes dont les entrées n’ont pas changé. Pour un traitement plus approfondi, le livre Reproducible Research with R and RStudio de Christopher Gandrud est une référence standard, et R Programming for Data Science de Roger Peng et les supports de cours de reproductibilité de Johns Hopkins couvrent le flux de travail du début à la fin.

Les mêmes principes s’appliquent à Python. Un pyproject.toml avec des dépendances épinglées, un workflow Makefile ou Snakemake et un manuscrit Quarto ou Jupyter Book vous donnent l’équivalent de la pile R. L’outillage diffère ; ce n’est pas le cas de la discipline.

Que sont les builds reproductibles ?

Les builds reproductibles sont une pratique de génie logiciel dans laquelle la compilation du même code source avec la même chaîne d’outils produit un binaire identique octet par octet. Le concept est né dans le monde du logiciel libre – les projets Debian et Tor en ont été les pionniers – et constitue désormais un standard formel maintenu par le projet Reproducible Builds. La motivation est la confiance : si quelqu’un peut reconstruire un binaire et obtenir le même hachage, il peut vérifier que le binaire distribué correspond à la source publiée et ne contient aucune modification cachée.

L’analogie avec les pipelines scientifiques est directe. Un build d’analyse reproductible prend les entrées source (données brutes, code, configuration) et produit des sorties (figures, tableaux, statistiques) de manière déterministe.

Le non-déterminisme brise cela, rendant la recherche non reproductible : des graines aléatoires non fixées, des réductions parallèles qui s’additionnent dans un ordre variable, des horodatages intégrés dans les fichiers de sortie et des opérations à virgule flottante qui dépendent du nombre de threads provoquent toutes des variations d’une exécution à l’autre. La réparation des graines, le tri avant réduction et la suppression des horodatages sont des remèdes standards.

Toutes les sources de non-déterminisme ne peuvent pas être éliminées. La dynamique moléculaire avec l’accélération GPU peut produire des trajectoires légèrement différentes sur différents matériels en raison de différents arrondis en virgule flottante, et les méthodes de Monte Carlo sont intrinsèquement stochastiques. L’approche honnête consiste à documenter la variation attendue, à la signaler et à s’assurer que la conclusion scientifique y est robuste – et non à revendiquer une identité au niveau binaire que vous ne pouvez pas fournir.

Critères pour juger si une étude est reproductible

Critère	Faible	Fort
Disponibilité des codes	”Disponible sur demande”	Dépôt public avec une version étiquetée et DOI
Environnement	Noms de packages uniquement	Fichier de verrouillage ou conteneur avec résumé épinglé
Point d’entrée	Scripts numérotés, commande manuelle	Workflow make, Snakemake ou targets
Provenance des données	Paragraphe méthodes	Scripts d’ingestion et sommes de contrôle documentés
Déterminisme	Aléatoire non ensemencé	Graines fixes, variation attendue documentée
Documents	Suppose la connaissance de l’auteur	Un étranger peut régénérer chaque figure

Utilisez-le comme un auto-audit avant la soumission pour vous assurer que votre recherche est reproductible. La plupart des revues et des bailleurs de fonds exigent désormais une déclaration de disponibilité des données et du code, et certains – y compris plusieurs revues du portefeuille AGU, PLOS et Nature – exigent que le code soit déposé dans un référentiel avec un DOI. Atteindre la rubrique « fort » est de plus en plus une condition de publication, et non un bonus.

Objections courantes et compromis honnêtes

Le coût du temps est l’objection la plus évoquée, et elle est réelle. Conditionner correctement un pipeline peut prendre des jours pour un projet déjà « terminé ».

Le contre-argument est que le coût de ne pas le faire est payé plus tard, souvent par un étudiant ou un collaborateur qui passe des semaines à procéder à la rétro-ingénierie d’une analyse. Une voie médiane pragmatique : investissez immédiatement dans un contrôle de version et un fichier de verrouillage, et conteneurisez uniquement les projets que vous attendez des autres qu’ils réutilisent.

Les données sensibles ou restreintes rendent le partage difficile. Les données cliniques, exclusives et certaines données instrumentales ne peuvent pas être publiées publiquement. Dans ces cas, la reproductibilité signifie publier le code, le schéma et un échantillon synthétique ou anonymisé, accompagnés d’une description claire de la procédure d’accès. L’objectif est qu’un chercheur qualifié disposant d’un accès légitime puisse régénérer les résultats.

Le code hérité est une autre contrainte. Les simulations Fortran et C des années 1990 ne peuvent pas être compilées sur les systèmes modernes sans correctifs. Les envelopper dans un conteneur avec une ancienne chaîne d’outils est souvent plus facile que de les réécrire, et cela préserve les chiffres d’origine. Documentez les correctifs que vous avez appliqués et pourquoi.

Enfin, la reproductibilité n’est pas la même chose que l’exactitude. Un pipeline peut être parfaitement reproductible et néanmoins se tromper : un bug fidèlement reproduit reste un bug. La reproductibilité est une condition préalable à l’examen minutieux, et non un substitut. L’examen par les pairs, la réplication indépendante et l’analyse de sensibilité restent nécessaires pour garantir que la recherche n’est pas reproductible seulement dans ses erreurs.

Questions fréquemment posées

Qu’est-ce que cela signifie lorsque la recherche n’est pas reproductible ?

La recherche n’est pas reproductible lorsqu’un chercheur indépendant, utilisant les mêmes données et le même code, ne peut pas régénérer les résultats publiés. La cause est généralement un code manquant, un environnement logiciel non épinglé, un traitement de données non documenté ou des étapes manuelles qui n’ont jamais été automatisées. Il s’agit d’une propriété des artefacts, et non d’un jugement sur l’honnêteté des auteurs originaux.

Quelle est la différence entre reproductibilité et réplicabilité ?

La reproductibilité signifie réexécuter la même analyse sur les mêmes données et obtenir le même résultat. La réplicabilité signifie mener une nouvelle étude – de nouvelles données, de nouveaux échantillons – et parvenir à une conclusion cohérente. Le rapport 2019 des National Academies traite ces concepts comme des concepts distincts, et une étude peut être reproductible même si elle ne peut pas être répliquée.

Comment rendre ma recherche reproductible ?

Commencez par le contrôle de version (Git) et marquez le commit qui correspond à votre article. Épinglez les dépendances avec un fichier de verrouillage ou une image de conteneur. Fournissez un point d’entrée unique tel qu’un workflow « Makefile », Snakemake ou targets. Documentez la provenance des données et les résultats attendus dans un fichier README. Testez le tout sur une machine propre avant de soumettre.

« reproducable » est-il une orthographe correcte ?

Non. L’anglais standard orthographie le mot « reproducible », formé de « reproduce » plus le suffixe « -ible ». Les dictionnaires et les guides de style répertorient uniquement « reproducible ». La variante « reproducable » apparaît dans les écrits informels et dans certains textes non anglais, mais n’est pas acceptée dans les écrits scientifiques formels.

Que sont les builds reproductibles en calcul scientifique ?

Les builds reproductibles sont des builds qui produisent des sorties identiques à partir d’entrées identiques, une norme formalisée par le projet Reproducible Builds pour l’empaquetage de logiciels. En science, le même principe s’applique aux pipelines d’analyse : des graines aléatoires fixes, des réductions déterministes et des chaînes d’outils épinglées permettent de régénérer exactement les résultats. Lorsqu’une variation en virgule flottante dépendante du matériel est inévitable, documentez la plage attendue.

La reproductibilité nécessite-t-elle de partager toutes mes données ?

Pas toujours. Les données restreintes, cliniques ou exclusives peuvent être traitées en publiant du code, des schémas et des échantillons synthétiques parallèlement à une procédure d’accès documentée. De nombreux bailleurs de fonds et revues exigent une déclaration de disponibilité des données plutôt que des données ouvertes. Le test consiste à savoir si un chercheur qualifié disposant d’un accès légitime pourrait régénérer vos résultats.

Lectures complémentaires et outils

Le document Reproducibility and Replicability in Science (2019) des National Academies est la référence conceptuelle faisant autorité lorsque la recherche n’est pas reproductible. Le projet Reproducible Builds documente la norme de génie logiciel.

Pour les outils de workflow, consultez la documentation de GNU Make, Snakemake, Nextflow, targets, renv et Quarto. The Turing Way est un manuel communautaire ouvert couvrant les pratiques de recherche reproductibles dans toutes les disciplines, et le Software Sustainability Institute publie des conseils pratiques pour les ingénieurs logiciels de recherche.