Reading Time: 14 minutes
  • Les ordinateurs portables Jupyter ne s’exécutent avec succès que 12,4 % du temps lorsque les dépendances sont déclarées : la gestion de l’environnement explicite comble cet écart.
  • Le cadre des cinq piliers de Ziemann et al. (2023) fournit une base de référence structurée pour la documentation, le contrôle des versions, la gestion de l’environnement, le partage de données et la conformité équitable
  • La liste de contrôle Repro (Hornung et al., 2026) propose un outil pratique d’auto-audit couvrant la structure des dossiers, la spécification de l’environnement, la disponibilité des données et l’exécution déterministe
  • Les écueils courants tels que les chemins absolus, les dépendances non spécifiques et les lus manquants sont les principales causes des échecs de reproductibilité dans la recherche informatique.
  • Un workflow étape par étape, de la conception de la simulation à la documentation, à l’archivage de code et à la soumission d’un journal, fournit un pipeline de production répétable

L’écart de reproductibilité dans la recherche informatique

Lorsque vous soumettez un article basé sur une simulation, les examinateurs vérifient votre méthodologie, les conditions aux limites, les études de convergence et la comparaison avec des repères analytiques. Mais ils relancent rarement votre code. Les résultats présentés dans vos figures et tableaux deviennent l’enregistrement publié, et si ces résultats ont été générés par un flux de travail qui ne peut pas être reproduit, la publication repose sur une base non vérifiée.

Ce n’est pas un problème théorique. Samuel & Mietchen (2024) a analysé 15 817 carnets Jupyter basés sur Python de publications biomédicales indexées dans PubMed Central. Parmi les ordinateurs portables où toutes les dépendances déclarées pouvaient être installées avec succès, 87,6 % ont entraîné des exceptions lors de la rediffusion automatisée. Seuls 1 203 ordinateurs portables ont été exécutés sans erreur, et parmi ceux-ci, 324 résultats ont été différents des résultats signalés à l’origine. Les 879 ordinateurs portables restants ont produit des résultats identiques. Ce taux de réussite de 5,56 % pour une reproduction identique était en fait une amélioration par rapport à la course initiale de 2021 (5,88 %), indiquant que les ordinateurs portables récents ont tendance à être légèrement meilleurs, mais l’écart reste énorme.

Qu’est-ce qui rend la reproductibilité plus difficile pour les scientifiques informatiques ? Vous travaillez avec des solveurs numériques, des améliorations de maillage, des schémas d’intégration temporelle et des stratégies de couplage qui produisent des résultats à travers des chaînes d’opérations en virgule flottante. Une seule bosse de version Python, un paramètre par défaut modifié dans numpy ou scipy, ou un chemin relatif qui ne se résout pas sur une autre machine peut invalider chaque chiffre et chaque tableau de votre papier. Le problème s’aggrave lorsque votre flux de travail implique un raffinement de maillage adaptatif, des termes de source personnalisés ou des conditions aux limites non triviales, le type très avancé de modèles documentés dans Ressources Fipy sur ce site.

Cinq piliers de la recherche computationnelle reproductible

Ziemann et al. (2023) ont officialisé les cinq piliers de la reproductibilité informatique comme cadre de documentation et de partage de flux de travail reproductibles. Bien qu’ils soient développés à l’origine dans le contexte de la bioinformatique, ces piliers s’appliquent également aux simulations de science des matériaux, à la dynamique des fluides informatiques et aux solveurs PDE basés sur un volume fini.

1. Programmation alphabétisée

La programmation alphabétisée signifie documenter votre flux de travail informatique comme un récit qui entrelace l’explication et le code exécutable. Dans les sciences informatiques, cela se manifeste généralement sous forme de blocs-notes Jupyter, de documents R Markdown ou de scripts Python avec des doctrings étendus et des commentaires en ligne.

L’objectif n’est pas simplement de produire un fichier reproductible, c’est de créer un document qu’un lecteur qui ne connaît pas avec votre analyse peut suivre, comprendre et réexécuter. Samuel & Mietchen (2024) a trouvé une corrélation claire entre le rapport de réduction sur la cellule de code et la reproduction réussie : les ordinateurs portables avec un effort de documentation plus élevé (plus de cellules Markdown par rapport aux cellules de code) étaient significativement plus susceptibles de se reproduire de manière identique à la sortie d’origine.

Pour une simulation en champ de phase dans FIPY—une introduction à son architecture de base—ou un modèle de diffusion à l’aide du méthode de volume fini, la programmation alphabétisée peut ressembler à ceci :

# Set deterministic seed
import numpy as np
np.random.seed(42)

# Build a structured grid (this should match the mesh description in your paper)
nx, ny = 100, 100
mesh = CellGrid([nx, ny], varIndex=1)

# Define the transient diffusion term and boundary conditions
T = CellVariable(name='Temperature', mesh=mesh, value=initial_temperature)
eqn = TransientTerm() == DiffusionTerm(coeff=thermal_conductivity)

# Impose Dirichlet boundary conditions (see also our guide on FiPy BCs)
T.fixLeft(value=300)
T.fixRight(value=500)

Lorsque vous écrivez cette cellule de bloc-notes, vous documentez simultanément la résolution du maillage, la PDE et les conditions aux limites, et vous exécutez la simulation qui a produit votre chiffre publié.

Recommandation : Si votre ordinateur portable a moins de cellules Markdown que de codes de cellules, vous êtes sous-documenté. Visez au moins un rapport 1:1, et idéalement plus. Le Samuel & L’étude de Mietchen a révélé que le groupe de reproduction identique avait un rapport de réduction/code de 0,73, tandis que le groupe de reproduction différent n’avait que 0,49.

2. Contrôle de version de code et partage

Le contrôle de version n’est pas facultatif pour les travaux de qualité de publication. Git fournit un historique permanent et interrogeable de chaque changement de code, et GitHub, GitLab ou Zenodo archive votre référentiel en tant qu’objet citable avec un DOI.

Le but du contrôle de version est double :

  • Reproductibilité : Un hachage de validation spécifique (abc1234) associé à une date de validation spécifique indique à quiconque exactement quel code produit vos résultats publiés.
  • Responsabilité : Chaque changement de paramètre, chaque modification de terme source, chaque modification des conditions aux limites est enregistrée. Lorsqu’un critique demande « Pourquoi avez-vous utilisé ce coefficient de diffusion ? » Vous pouvez pointer vers le commit exact où il a été défini.

Lors de la publication, archivez votre référentiel sur ZeNoDo (ou GitHub avec l’intégration Zenodo activée) et incluez le DOI dans la déclaration de disponibilité des données de votre manuscrit. Cela transforme votre code de simulation en un artefact permanent et citable. De nombreuses revues recommandent désormais de déposer du code dans les référentiels avec une affectation DOI. Consultez le Joss Simulation Science Lignes directrices pour les attentes des revues sur les publications basées sur la simulation.

Règle de décision : GitHub contre Zenodo ? Utilisez GitHub pour le développement et la collaboration actifs. Utilisez Zenodo pour l’archivage. Zenodo attribue automatiquement un DOI aux référentiels GitHub lorsqu’il est lié, ce qui en fait le choix préféré pour la publication. Vous pouvez conserver un référentiel GitHub en direct et archiver la validation finale sur Zenodo pour la soumission.

3. Calculer le contrôle de l’environnement

Le contrôle de l’environnement est l’intervention technique la plus importante que vous puissiez faire. Lorsqu’un réviseur essaie de reproduire vos résultats sur une machine neuve, il doit connaître la pile logicielle exacte : version Python, version NumPy, version Fipy, bibliothèques de solveur. Sans cette information, l’examinateur est deviner – et la devinette produit ModuleNotFoundError, ImportError et FileNotFoundError (les trois exceptions les plus courantes identifiées par Samuel & Mietchen, responsable de 41,65 % de toute l’exécution échecs).

Comment capturer votre environnement :

# In Python, use the session-info package to export your environment
!pip install session-info
import session_info
session_info.show()

# Conda environment export (alternative)
conda env export > environment.yml

# pip requirements (for simpler projects)
pip freeze > requirements.txt

Règle de décision : Conda vs PIP contre Docker ? Pour la plupart des flux de travail en sciences informatiques de Python, Conda est le meilleur équilibre entre pratique et exhaustivité. Il gère à la fois les packages Python et les dépendances non-Python (tels que les bibliothèques HDF5 ou les temps d’exécution MPI). Docker fournit une isolation totale au prix de la complexité ; Utilisez Docker lorsque vous devez partager un flux de travail avec des chercheurs sur différents systèmes d’exploitation qui ne peuvent pas installer Conda ou lorsque votre flux de travail dépend des bibliothèques au niveau du système.

La liste de contrôle Repro (Hornung et al., 2026) recommande explicitement de spécifier des versions de logiciels dans le README et de fournir un fichier de spécification d’environnement. Ils notent : « Pour la reproductibilité à long terme, l’environnement logiciel doit également être clairement documenté, y compris les versions de tous les packages supplémentaires utilisés. »

4. Partage de données persistant

Le partage de données va de pair avec le partage de code. Vos sorties de simulation – configurations de maillage, tableaux de champs, séries chronologiques de variables – doivent être déposées dans un référentiel qui attribue un identifiant persistant (DOI).

Pour les données de simulation, cela signifie généralement :

  • Sorties de simulation brutes (Tableau de champ, fichiers maillés, séries temporelles) déposés à côté du code
  • Résultats intermédiaires pour les simulations de calculs intensifs (voir la recommandation Repro sur les résultats intermédiaires)
  • Données de test synthétiques si vos données réelles ne peuvent pas être partagées publiquement en raison de la confidentialité ou des restrictions légales

Les Principes FAIR (Wilkinson et al., 2016) fournissent un cadre pour la gestion des données—voir Les conseils Go Fair sur le Principes pour les orientations officielles sur la recherche, l’accessibilité, l’interopérabilité et la réutilisabilité.

  • Retrouvable : Attribuer des identifiants persistants (DOI) et inclure des métadonnées riches
  • accessible : stocker des données dans des référentiels avec des protocoles ouverts (ZeNoDo, FigShare, Material Data Facility)
  • Interopérable : Utilisez des formats standard (HDF5, NETCDF, JSON) et des vocabulaires formels
  • Réutilisable : Documentation de la provenance, des licences et des données

Pour la science des matériaux et la physique informatique, des plateformes comme le cloud des matériaux et le référentiel Nomad Fournit une infrastructure conforme aux données de simulation, avec des schémas de métadonnées et un accès à l’API.

5. Documentation

La liste de contrôle des repro met l’accent sur la documentation, non pas après coup, mais comme composante structurelle d’un travail reproductible. Un fichier Lisez-moi doit :

  • Lister chaque fichier dans le référentiel et son objectif
  • Spécifiez l’ordre d’exécution exact (les scripts produisent quels chiffres ou tableaux)
  • Fournir des temps d’exécution approximatifs et des exigences matérielles
  • Référencez les chiffres de la figure et du tableau correspondants de la publication

Pour les flux de travail de simulation, la documentation signifie également documenter vos méthodes numériques. Lorsque vous écrivez un solveur personnalisé ou un script Fipy avec fractionnement d’un opérateur, Strag Splitting et des schémas IMEX pour les solveurs PDE, vous devez documenter :

  • Le schéma de discrétisation
  • La méthode d’intégration du temps
  • Les tolérances du solveur
  • Le critère de convergence

Si un autre chercheur ne peut pas comprendre la méthode numérique derrière vos résultats, il ne peut pas évaluer si les résultats sont valides ou les reproduire sur un solveur différent.

La liste de contrôle Repro en tant qu’outil d’auto-audit

La Repro Checklist (Hornung et al., 2026), publiée dans Royal Society Open Science (Full Paper), a été développée par un consortium international d’éditeurs de reproductibilité de revues pour fournir un Cadre de recherche reproductible. Bien qu’il s’applique largement à toutes les disciplines, plusieurs éléments sont particulièrement pertinents pour les travaux de simulation informatique.

Voici comment utiliser la liste de contrôle Repro comme auto-audit préalable à la soumission :

A. Structure et lecture

Vérifier : Avez-vous un répertoire data/, code/ et results/ (ou output/ ? Votre fichier Lisez-moi répertorie-t-il chaque fichier, spécifie-t-il l’ordre d’exécution et fait-il référence aux chiffres correspondants de chaque script ?

Échec commun : Les chercheurs organisent leur code de simulation dans un seul dossier sans structure. Un fichier README est souvent entièrement omis. Sans README, un critique n’a aucun moyen de savoir quel script produit quel chiffre, et il peut exécuter les scripts dans le mauvais ordre, produisant des résultats entièrement différents.

B. Spécification de l’environnement

Check : Votre environment.yml ou requirements.txt est-il inclus dans l’archive ? Les versions Python et Package sont-elles explicitement spécifiées ?

Échec commun : La raison la plus courante pour laquelle les ordinateurs portables échouent sont des dépendances manquantes ou en conflit. Samuel & Mietchen a constaté que 34,32 % des ordinateurs portables ont échoué à l’étape d’installation des dépendances, même si aucun des fichiers n’a été malformé. La cause principale est souvent des versions de package non spécifiées ou obsolètes.

C. Disponibilité des données

Vérifier : Un examinateur peut-il exécuter votre code à partir de zéro en utilisant les données fournies ? Si vous ne pouvez pas partager de données réelles, avez-vous inclus des données synthétiques qui imite la structure de calcul ?

Échec commun : Lorsque les données réelles ne peuvent pas être partagées (en raison de contraintes juridiques, éthiques ou institutionnelles), le code doit toujours être exécutable avec des données synthétiques. La liste de contrôle Repro recommande de générer des données synthétiques à l’aide de packages tels que synthpop ou simdata dans R, ou numpy.random en Python.

D. Exécution déterministe

Vérifier : Les graines de générateurs de nombres aléatoires sont-elles explicitement définies ? Pour les simulations parallèles, des flux de nombres aléatoires reproductibles sont-ils utilisés ?

Échec commun : C’est l’une des causes les plus courantes et les plus subtiles d’irréproductibilité. Une simulation qui utilise numpy.random.randn() sans établir une graine produira des résultats différents à chaque exécution, et même avec une graine, les travailleurs parallèles peuvent chacun générer des flux aléatoires qui se chevauchent. La liste de contrôle Repro recommande d’utiliser la génération basée sur SeedSequence de Numpy pour des flux aléatoires déterministes et sûrs.

from numpy.random import default_rng
rng = default_rng(42)  # Fixed seed

Pour les simulations parallèles, utilisez numpy.random.SeedSequence pour générer des flux indépendants et reproductibles :

from numpy.random import SeedSequence
seq = SeedSequence(42)
children = seq.spawn(n_children)  # Deterministic per-child seeds

E. Résultats intermédiaires

Vérifier : pour les simulations de calculs intensifs (par exemple, les balayages de paramètres, les études de Monte Carlo), les résultats intermédiaires sont-ils enregistrés afin que les examinateurs puissent reproduire des chiffres spécifiques sans relancer l’analyse complète ?

Échec courant : Lorsqu’une simulation prend des heures ou des jours, les examinateurs ne peuvent pas le réexécuter à partir de zéro. La liste de contrôle Repro recommande d’enregistrer les résultats intermédiaires (sortie brute avant la génération finale de la figure) afin que les examinateurs puissent rapidement vérifier des sorties spécifiques. Ceci est particulièrement important pour les études de simulation avec des réplications parallèles.

Flux de travail étape par étape, de la conception de la simulation à la soumission

Cette section fournit un flux de travail concret qui intègre les cinq piliers et la liste de contrôle Repro dans un pipeline de production répétable.

Phase 1 : conception de la simulation et organisation du code

  1. Créer la structure du projet :
project/
├── README.md
├── environment.yml
├── data/
│   ├── input/         # Simulation inputs, initial conditions
│   ├── output/        # Raw simulation outputs
│   └── synthetic/     # Synthetic test data (if real data is restricted)
├── code/
│   ├── mesh.py        # Mesh configuration
│   ├── solve.py       # Main simulation script
│   ├── postprocess.py # Figure generation
│   └── test/          # Unit tests and convergence checks
└── results/
    ├── figures/
    └── tables/
  1. Contrôle des versions : Initialisez le référentiel et validez la structure.
git init
git add README.md environment.yml
git commit -m "Initial project structure"

Phase 2 : Exécution et documentation de la simulation

  1. Écrivez la simulation dans un format alphabétisé. Utilisez des ordinateurs portables ou des fichiers de script Jupyter avec des commentaires étendus. Documentez chaque méthode numérique, chaque choix de solveur, chaque condition aux limites.
  2. Définir les graines déterministes. Incluez np.random.seed(42) (ou une configuration SeedSequence plus sophistiquée pour les courses parallèles) en haut de chaque script.
  3. Capturez l’environnement. RUN session_info.show() ou conda env export pendant une exécution réussie et incluez la sortie dans le README.
  4. Enregistrez les résultats intermédiaires. Si votre simulation est gourmande en calculs, enregistrez les sorties brutes aux points de contrôle afin que les examinateurs puissent vérifier des chiffres spécifiques sans tout relancer.

Phase 3 : Validation et vérification

  1. Exécutez des études de convergence. Vérifiez que vos résultats convergent comme prévu lorsque vous affinez le maillage. Cela fait partie de la vérification – vérifier que la solution numérique aborde la solution exacte à mesure que les paramètres de discrétisation diminuent. Pour un cadre pratique, consultez notre guide sur validation et vérification des simulations PDE.
  2. Écrire les tests unitaires. Testez les fonctions individuelles, les conditions aux limites et les solveurs. Si vous utilisez FIPY, cela peut inclure le test de la bonne initialisation correcte des valeurs CellVariable ou de DiffusionTerm. Consultez notre article sur Modèles de test pour le code scientifique pour plus de détails.

Phase 4 : archivage et soumission

  1. Archive sur Zenodo. Poussez le dernier engagement sur GitHub et liez-le à Zenodo pour l’affectation DOI.
  2. Exécuter la liste de contrôle REPRO Audit :
    • Fichier README avec ordre d’exécution ?
    • Spécification de l’environnement inclus ?
    • Données disponibles (réelles ou synthétiques) ?
    • Semences déterministes Définir ?
    • Résultats intermédiaires enregistrés ?
  3. Soumettez-le avec le code et les données DOI dans la déclaration de disponibilité des données de votre manuscrit. De nombreuses revues l’exigent désormais lors de la soumission ou de la révision.

Des pièges courants et comment les éviter

Pitfall 1 : chemins absolus

L’utilisation de chemins absolus comme /home/user/simulations/output/data.csv dans votre code casse la reproductibilité sur n’importe quelle machine autre que celle où vous avez développé le projet.

FIX : Utilisez les chemins relatifs de la racine du projet. Si vos scripts attendent des données dans un répertoire data/, référencez data/input.csv quel que soit l’endroit où le projet est cloné.

Pitfall 2 : Dépendances non programmées

Un ordinateur portable importe scipy.stats mais ne déclare pas que scipy est requis. Lorsqu’un autre chercheur exécute le bloc-notes, il peut avoir une version incompatible scipy ou la manquer entièrement.

FIX : Incluez toujours un requirements.txt ou environment.yml et vérifiez-le en supprimant l’environnement local et en réinstallant à partir de zéro avant l’archivage.

Pitfall 3 : Lisez-moi manquant

Sans Readme, les critiques ne peuvent pas savoir :

  • Quel script produit quelle figure
  • Quels scripts d’ordre doivent être exécutés
  • À quelle exécution approximative s’attendre
  • Quelle version ou version de package Python a été utilisée

Correction : Écrivez un README qui répertorie chaque fichier, chaque étape d’exécution et chaque estimation d’exécution. Faites référence aux chiffres de votre publication.

Pitfall 4 : Dérive de la version Python

Python 3,6 était le coucher du soleil en 2021 ; Python 3.7 était le coucher du soleil en juin 2023. De nombreux cahiers dans le Samuel & Mietchen Corpus a utilisé des versions Python obsolètes, et le décalage entre la version lors de la publication et la version disponible lorsque les critiques tentent de reproduire provoque de subtiles incompatibilités.

Correction : Utilisez une version Python récente et activement prise en charge et spécifiez-la dans votre fichier d’environnement. La liste de contrôle Repro recommande de documenter la version Python dans le README.

Piège 5 : nombres aléatoires non déterministes

Une simulation qui génère des conditions initiales aléatoires sans fixer la graine produit à chaque fois des sorties différentes. Même avec une graine, les travailleurs parallèles peuvent générer des flux qui se chevauchent.

FIX : Définissez une graine fixe pour toutes les opérations aléatoires. Utilisez numpy.random.SeedSequence pour la reproductibilité de Parallel-Safe. La liste de contrôle Repro recommande explicitement ce modèle.

Quand choisir les conteneurs par rapport aux environnements légers

Pour la plupart des flux de travail de simulation, la gestion de l’environnement léger (CONDA, PIP, UV) est suffisante. Vous obtenez la reproductibilité en spécifiant des versions exactes du package, et les réviseurs peuvent installer l’environnement avec une seule commande.

Choisir conda/UV/PIP quand :

  • Vous travaillez avec des solveurs basés sur Python (FIPY, OpenPDE, FENICS)
  • Vous avez le contrôle de l’environnement de calcul de votre côté
  • Vous voulez un flux de travail léger et portable

Choisissez Docker quand :

  • Vous devez partager un flux de travail avec des chercheurs qui ne peuvent pas installer Conda ou des bibliothèques spécifiques au niveau du système.
  • Votre flux de travail dépend des solveurs C++/Fortran qui doivent être compilés
  • Vous soumettez à un journal qui nécessite une reproductibilité en conteneur (par exemple, Computo)

Pour la grande majorité des documents de science et de physique des matériaux informatiques, le Conda ou les UV est le meilleur choix – il est plus simple, plus rapide et suffisant pour la reproductibilité dont les examinateurs et les lecteurs ont besoin.

Une note pratique sur les attentes des revues

La liste de contrôle de repro documente l’hétérogénéité des politiques de reproductibilité des journaux. Certaines revues (comme journal biométrique ou journal de l’American Statistical Association) nécessitent des contrôles de reproductibilité actives par des éditeurs dédiés. D’autres (comme le BMJ) nécessitent la soumission de code mais n’effectuent pas de vérifications d’exécution indépendantes.

Pour les travaux de simulation informatique, les attentes minimales dans la plupart des revues sont les suivantes :

  • Disponibilité du code : Le code d’analyse doit être fourni sous la forme d’un fichier supplémentaire ou d’un référentiel ouvert (GitHub, Zenodo)
  • Disponibilité des données : Les données utilisées pour l’analyse doivent être accessibles au public ou justifiées
  • Spécification de l’environnement : Les versions et les packages de logiciels doivent être documentés

C’est le sol, pas le plafond. En suivant les cinq piliers et la liste de contrôle des repro positions votre travail au-dessus du sol et signale que vous prenez au sérieux la reproductibilité.

Étapes suivantes pour votre flux de travail de simulation

Si vous débutez dans les pratiques de simulation reproductibles, commencez par les trois changements les plus importants :

  1. Ajouter un fichier Lisez-moi à votre projet avec des descriptions de fichiers et un ordre d’exécution
  2. Exportez votre environnement (conda env export ou uv export) et incluez-le dans vos archives
  3. Définir des graines aléatoires dans chaque script de simulation et utiliser SeedSequence pour les exécutions parallèles

Ces trois changements à eux seuls élimineront 80% des échecs de reproductibilité identifiés par Samuel & Mietchen.

Si vous avez besoin d’aide pour concevoir un workflow de simulation reproductible, de la documentation des ordinateurs portables à l’archivage de code et à la soumission d’un journal, notre équipe peut fournir des consultations sur la conception du flux de travail, la spécification de l’environnement et l’archivage des données conforme à la norme. Contactez-nous pour discuter de votre projet de simulation spécifique. Construire une communauté de logiciels de recherche durable (comment nous abordons le développement communautaire) fait partie de ce processus : la reproductibilité s’améliore lorsque toute l’équipe partage des normes communes.

Conclusion

Les pratiques de publication reproductibles pour les résultats de simulation ne sont pas un complément facultatif, elles sont une exigence pour une communication scientifique crédible. Les cinq piliers (programmation alphabétisée, contrôle des versions, gestion de l’environnement, partage de données, documentation) et la liste de contrôle Repro fournissent une base structurée et exploitable pour la reproductibilité qui s’applique à toutes les disciplines.

L’échelle de l’écart de reproductibilité – 12,4 % de reproduction identique réussie dans le Samuel & ; L’étude de Mietchen est un appel à l’action. Chaque flux de travail de simulation qui comprend un fichier de lecture, un fichier d’environnement et des graines déterministes comble une partie mesurable de cet écart. L’investissement est modeste : heures, pas mois. Le retour est la possibilité pour tout lecteur, examinateur ou futur chercheur de vérifier vos résultats de manière indépendante.

Pour le chercheur informatique, la reproductibilité n’est pas simplement une vertu méthodologique, c’est le fondement de la crédibilité scientifique. Les cinq piliers vous donnent un cadre. La liste de contrôle Repro vous donne une liste de contrôle. Les outils (git, conda, zenodo) sont disponibles. Ce qui reste, c’est la décision de les utiliser.

FAQ

Quel est le cadre des cinq piliers de la reproductibilité ?

Les cinq piliers proposés par Ziemann et al. (2023), sont la programmation alphabétisée, le contrôle de version du code, le contrôle de l’environnement de calcul, le partage de données persistants et la documentation. Ils forment un cadre structuré pour documenter et partager des flux de travail de calcul reproductibles.

Quelle est la liste de contrôle des repro ?

La liste de contrôle de Repro, publiée par Hornung et al. (2026), est un outil concis et multidisciplinaire pour créer des analyses reproductibles. Il couvre la structure du code et des données, les exigences en matière de lecture, la spécification de l’environnement, la disponibilité des données, la génération de nombres aléatoires déterministes et les résultats intermédiaires.

Pourquoi les ordinateurs portables Jupyter échouent-ils si souvent ?

Samuel & Mietchen (2024) ont constaté que 87,6 % des ordinateurs portables basés sur Python avaient entraîné des exceptions lors de la rediffusion automatisée. Les causes principales sont des dépendances manquantes ou contradictoires (ModuleNotFoundError et ImportError), des chemins de fichiers non résolus (FileNotFoundError) et une génération de nombres aléatoires non déterministes.

Comment choisir entre Conda et Docker ?

Utilisez Conda (ou UV) pour la plupart des flux de travail de simulation basés sur Python. Utilisez Docker lorsque vous avez besoin d’une isolation complète entre les systèmes d’exploitation ou lorsque votre flux de travail dépend des solveurs C++/Fortran compilés.

Comment rendre mes résultats de simulation reproductibles sans partager de données brutes ?

Générez des données synthétiques qui imite la structure de calcul de vos données réelles. La liste de contrôle Repro recommande d’utiliser des packages tels que synthpop ou simdata dans R, ou numpy.random en Python, pour créer des données de test synthétiques qui permettent une vérification indépendante de votre code d’analyse.