Le concept de reproductibilité est devenu un point essentiel de la confiance en la science. Une des conditions nécessaire mais non-suffisante pour assurer la reproductibilité d’un résultat scientifique d’une publication est la mise à disposition ouverte du logiciel et des données ayant permis ce résultat.
La réutilisabilité des données et des codes est un enjeu majeur pour la reproductibilité.
On peut distinguer plusieurs concepts essentiels (cf K. Hinsen, ReScience, 2017) :
- Rerunnable / Ré-exécutable
- Can you re-run your program ? Pouvez-vous relancer votre programme ?
- One day, one week, one month, one year (just kidding) apart ? Dans un jour, une semaine, un mois, un an ?
- Repeatable / Répétable
- Can you re-run your program and get same results ? Pouvez-vous relancer votre programme et obtenir les mêmes résultats ?
- Did you save everything, including random seed ? Est-ce que vous sauvegardez tout ce qui est nécessaire, y compris les “graines aléatoires” ?
- Reproducible / Reproductible
- Can someone re-run your program and get same results ? Est-ce que quelqu’un d’autre peut relancer votre programme et obtenir les mêmes résultats ?
- Did you save the software stack ? Est-ce que vous sauvegardez la pile logicielle ?
- Replicable / Réplicable
- Can someone reimplement your model and get same results ? Est-ce que quelqu’un d’autre peut réécrire votre modèle et obtenir les mêmes résultats ?
- Did you describe everything ? Est-ce que vous décrivez tous les éléments ?
- Reusable / Réutilisable
- Can someone reuse your program using different data ? Est-ce que quelqu’un d’autre peut utiliser votre programme avec des données différentes ?
- Is your software data-dependent ? Est-ce que votre logiciel est dépendant des données ?
Pour répondre à ces besoins de reproductibilité, la diffusion du code en licence libre est une première étape incontournable pour assurer son accessibilité. Mais c’est évidemment loin d’être suffisant, en particulier quand on considère que le code s’exécute dans un environnement complexe dont les dépendances ne sont pas réellement maîtrisées.
Il existe des outils qui permettent d’aider à contrôler et préserver l’environnement dans lequel a été obtenu les résultats : il s’agit en particulier des gestionnaires de paquets comme Nix ou Guix.
L’utilisation de notebooks permet d’intégrer dans un même document du texte rédactionnel, du code informatique et les résultats de ce code, et sont donc aussi des outils intéressants pour la reproductibilité, notamment en documentant l’usage du logiciel (favorisant la réplicabilité).
Références
- Séminaires recherche reproductible
- https://doranum.fr/tag/reproductibilite/
- https://mi-gt-donnees.pages.math.unistra.fr/guide/11-reproductibilite.html
- https://indico.mathrice.fr/event/165/contribution/1/material/slides/0.pdf
- https://lms.fun-mooc.fr/asset-v1:inria+41016+session02+type@asset+block/C028AL_slides_module2-fr-gz.pdf
Systèmes de gestion de paquets
La reproductibilité des environnements logiciels, c’est-à-dire le fait de pouvoir déployer précisément l’ensemble logiciel qui a servi à une production scientifique, est un des éléments les plus compliqués car disposer des sources d’un code ne suffit pas à assurer de pouvoir reproduire les calculs.
Les habituels systèmes de gestion de paquets (apt, rpm …) imposent des limitations qui les rendent peu utilisables dans le cadre qui nous intéresse : ils requièrent les droits d’administration système, et ils ne permettent de déployer qu’un seul environnement logiciel à la fois.
Guix et Nix sont des outils qui n’ont pas ces contraintes et permettent de créer des environnements logiciels complètement reproductibles.
Ces deux systèmes sont disponibles sur les infrastructures de calcul de GRICAD.
La documentation est accessible ici.
