Les sources de ce document sont disponibles sur gitlab.
Version du 2020-03-23.

Références complémentaires

Table des matières

Réflexions sur la stabilité des langages de programmation

Comme nous l'avons expliqué, le langage de programmation utilisé dans une analyse a une influence évidente sur la reproductibilité de l'analyse. Ce n'est pas une caractéristique du langage lui-même mais plutôt une conséquence de la philosophie de développement de la communauté sous-jacente. Par exemple, C est un langage très stable avec une spécification très claire conçue par un comité (même si certains compilateurs ne respectent cette norme).

À l’autre bout du spectre, Python a connu un développement beaucoup plus organique basé sur une philosophie de lisibilité et valorisant l'amélioration continue par rapport à la compatibilité ascendante. De plus, Python est couramment utilisé comme langage de wrapping (par exemple pour utiliser facilement les bibliothèques C ou FORTRAN) et dispose de son propre système de packaging. Tous ces choix de conception ont souvent tendance à rendre la reproductibilité un peu pénible avec Python, même si la communauté en tient lentement compte. La transition de Python 2 à Python 3, qui n'est pas totalement compatible avec les versions antérieures, a été un processus particulièrement pénible, notamment parce que les deux langages sont si similaires qu'il n'est pas toujours facile de savoir si un script ou un module donné est écrit en Python 2 ou Python 3. Il n'est même pas rare de voir des scripts Python qui fonctionnent sous Python 2 et Python 3, mais produisent des résultats différents en raison du changement de comportement de la division entière.

R, en comparaison, est beaucoup plus proche (en termes de communauté de développeurs) de langages comme SAS, très utilisé dans l'industrie pharmaceutique où les procédures statistiques doivent être standardisées et stables/solides. R n’est évidemment pas à l’abri des évolutions qui cassent les anciennes versions et gênent la reproductibilité/compatibilité avec les versions antérieures. Voici une véritable histoire relativement récente à ce sujet et des collègues qui ont travaillé sur le MOOC d'initiation à la statistique avec R sur FUN nous ont signalé plusieurs problèmes concernant quelques fonctions (gplots::plotmeans, survival::survfit ou hclust) dont les paramètres par défaut ont changé au fil des ans. Il est donc probablement utile de donner des valeurs explicites pour tous les paramètres (ce qui peut être fastidieux) au lieu de s’appuyer sur des valeurs par défaut et de restreindre autant que possible vos dépendances.

Ceci étant dit, la communauté de développement R est généralement très prudente en matière de stabilité. Nous (les auteurs de ce MOOC) pensons que l'open source (qui permet de contrôler le calcul et d'identifier les erreurs et les sources de non-reproductibilité) est plus important que la stabilité à toute épreuve de SAS, qui est un logiciel propriétaire.

Cependant, si vous avez vraiment besoin de rester sous SAS, sachez que SAS peut être utilisé dans Jupyter en utilisant les packages Python SASPy et SASKernel (tuto pas à pas ici). L'utilisation d'une telle approche de programmation alphabète alliée à un contrôle systématique de la version et de l'environnement est un plus. Des solutions similaires existent pour de nombreux langages (liste des kernels Jupyter).

Contrôler votre environnement logiciel

Comme nous l'avons mentionné dans les séquences vidéo, plusieurs solutions permettent de contrôler votre environnement :

Il peut être difficile de comprendre la différence entre ces différentes approches et de décider laquelle est la meilleure dans votre contexte.

Voici un webinaire où certains de ces outils sont présentés dans un contexte de recherche reproductible : Controling your environment (by Michael Mercier and Cristian Ruiz).

Vous voudrez peut-être aussi jeter un coup d’œil sur la convention Popper (webinaire par Ivo Gimenez par Google hangout) ou sur la présentation de Konrad Hinsen sur Active Papers.

Préservation/Archivage

S'assurer que le logiciel est correctement archivé, c'est-à-dire qu'il est stocké de manière sécurisée afin de pouvoir y accéder de manière pérenne, peut être assez délicat. Si vous n'avez jamais vu la présentation du projet Software Heritage par Roberto Di Cosmo, c'est à voir absolument. https://www.softwareheritage.org/

Si vous voulez archiver votre propre code dans Software Heritage, il y a deux façons de s'y prendre:

  1. Vous mettez votre code dans un dépôt public sur http://github.com, http://gitlab.com, ou http://bitbucket.org. Puis vous attendez que Software Heritage le récupère. Le seul inconvient est le temps d'attente (quelques mois) avant de pouvoir être sûr de l'archivage et de pouvoir citer le code par un identifiant du type SWH.

  2. Mettez votre code dans un dépôt public géré avec Git, Mercurial, ou Subversion. Puis rentrez son URL sur la page https://archive.softwareheritage.org/save/ Le temps d'attente est typiquement de quelques heures, et vous pouvez surveiller l'état de votre requête à tout moment.

Pour les données, nous vous recommandons vivement d’utiliser https://www.zenodo.org/ lorsque les données ne sont pas sensibles.

Workflows

Dans les séquences vidéo, nous avons mentionné les gestionnaires de flux de travaux (domaine d'application d'origine entre parenthèses) :

Vous voudrez peut-être consulter ce webinaire : [[https://github.com/alegrand/RR_webinars/blob/master/6_reproducibility_bioinformatics/index.org][Science Reproducible en Bioinformatique : état actuel, solutions et opportunités de recherche (par Sarah Cohen Boulakia, Yvan Le Bras and Jérôme Chopard)]].

Problèmes numériques et statistiques

Nous avons mentionné ces sujets dans notre MOOC mais nous ne pourrions en aucun cas les couvrir correctement. Nous ne suggérons ici que quelques présentations intéressantes à ce sujet.

Pratiques de publication

Vous souhaiterez peut-être consulter les webinaires suivants :

Expérimentation

L'expérimentation n'est pas couverte dans ce MOOC bien qu'il s'agisse d'un élément essentiel de la science. La raison principale est que les pratiques et les contraintes varient tellement d'un domaine à l'autre que ce thème ne pouvait pas être correctement couvert dans une première édition. Nous serions heureux de rassembler les références que vous jugez intéressantes dans votre domaine. N'hésitez donc pas à nous les fournir à l'aide du forum. Nous les intégrerons dans cette page.