un diagramme pour résumer ce que nous avons vu

La reproductibilité d’un code source, c’est à dire la capacité de l’exécuter diminue avec le temps sur une même machine. Elle varie aussi selon le degré d’altérité qu’une machine entretient avec celle où le code source a été conçue. Typiquement on aura des résultats différents, voire pas de résultat du tout si on essaie de reproduire avec un ordinateur sous GNU/Linux un code souce conçu pour un ordinateur qui tourne sous Windows.

Dans la figure ci-dessus, on distingue des intervalles de reproductibilité. La zone rouge correspond à une reproductibilité très limitée dans le temps et dans la diversité des machines. Dans la zone verte, on trouvera les outils mobilisables pour garantir la plus grande reproductibilité possible dans le temps et en tenant compte de la diversité des systèmes installés sur les machines.

Pour des projets de faible ambition en matière de reproductibilité, pensons à des preuves de concept qui serviront ensuite à élaborer des codes source plus résistants, on peut se safisfaire de partager à un.e collègue qui utilise une machine quasi identique, le code source avec un fichier README pour l’aider à l’installer et à l’éxécuter.

Pour rendre possible l’exécution du code source sur un système identique mais en tenant compte que toute la pile logicielle n’a pas été préalablement installée, on aura recours à un fichier de configuration qui va liste les dépendances utilisées (renv.lock pour R, requirements.txt pour Python, environment.yml pour Conda, etc.). Cette solution permet de ne partager que les principales dépendances liées au logiciel utilisé (par exemple Python ou R), mais ne permet pas d’encapsuler certaines dépendances système ni d’exécuter le code source sur un autre système d’exploitation

Dans la zone suivante (couleur saumon), on va trouver les tentatives de capturer et mettre à disposition des systèmes d’exploitation entiers avec le code source et la pile logicielle nécessaire pour les faire tourner. Il est possible de charger l’image résultant de cette opération sur un serveur pour la mettre à disposition de toute personne intéressée. Charge à ces personnes, d’installer à travers un dispositif spécifique (un serveur de virtualisation) l’image ainsi obtenue et de l’exécuter. La complexité de ce dispositif présente des aléas, mais surtout, la solution utilisée est lourde et en cas de code ou de données volumineuses, les performantes obtenues seront moindres qu’avec un conteneur.

Dans l’aire jaune, on va donc retrouver une solution plus prisée aujourd’hui par les développeur.se.s que les machines virtuelles, c’est à dire la conteneurisation. Les pratiques diffèrent ; certains partagent l’image elle-même, d’autres le dockerfile, d’autres encore les deux. Par souci de transparence, il est préférable de partager le dockerfile (et par souci de gain de place de ne pas partager l’image elle-même). La personne souhaitant réutiliser le code source pourra l’exécuter dans un conteneur en reproduisant l’image avec les instructions présentes dans le Dockerfile. Pourtant, comme on l’a vu, cette manière de faire n’est pas exempte de problèmes concrets. Beaucoup de Dockerfiles partagés ne donnent pas assez d’informations sur les versions des dépendances utilisées. Par ailleurs, l’image de base utilisée par le conteneur peut ne plus être maintenue ou bien sa version n’est pas précisée. Comme on l’a vu, à un rythme différent selon les gestionnaires de paquets utilisés dans le Dockerfile, le temps impose ses marques peu à peu dans les dépendances mobilisées.

Pour pallier ce problème de perméabilité de l’environnement aux versions plus récentes des dépendances ou au problème d’accessibilité des packages, le gestionnaire de paquets Guix semble garantir le plus haut niveau de reproductibilité pour les machines fonctionnant avec GNU/Linux. Notamment parce que Guix capture toutes les dépendances (logicielles et système) en fixant leur version (au moyen du fichier de configuration channels.scm). Les code source de ces packages listés dans les dépôts Guix par ailleurs sont à 70% conservés dans l’archive Software Heritage ce qui nous garantit de pouvoir continuer à les utiliser pour un temps indéfini. Et si le code source doit être partagé à des utilisateurs disposant d’un autre système d’exploitation que GNU/Linux (MacOS ou Windows par exemple), il reste possible de construire l’image Docker la plus stable possible en éliminant les défauts propres au Dockerfile, puisque Guix permet de s’en passer dans le cadre d’une conteneurisation (il utilise à la place les deux fichiers de configuration manifest.scm et channels.scm).

La Science est sans doute une exploration, et cette exploration peut passer par des phases de développement légères et peu reproductibles, mais elle est surtout sujette au temps long et la reproductibilité des résultats est une exigence tout à fait légitime aujourd’hui, à l’heure de la crise de la reproductibilité afin d’augmenter la confiance du public dans la Science. Cette reproductibilité de l’expérience passe par la possibilité de reproduire correctement le code source. Correctement signifie non seulement que le programme s’exécutera bien, mais qu’en plus, à partir des mêmes données et des mêmes codes source il continuera encore très longtemps et sur des machines très différentes d’obtenir exactement les mêmes résultats.

Ce guide se veut donc comme une incitation faite aux chercheuses et aux chercheurs à s’emparer du potentiel de Guix pour affronter directement et avec les meilleures armes l’épineux problème de l’obsolescence du code source de recherche