Re: Reproductibilité

Merci pour ces retours très intéressants ! Je vais essayer de répondre en vrac aux remarques ci-dessus :)

1. Terminologie du mot "reproductibilité"

Effectivement, comme déjà mentionné dans les commentaires ci-dessus, on peut avoir des points de vue légèrement différents sur ce qu'on entend par "reproductibilité" selon la terminologie qu'on utilise. Dans le cadre de ce journal, j'aurais peut-être dû utiliser "automatisation" plutôt que "reproductibilité".

D'un côté, on peut considérer la reproductibilité d'une expérience ou d'une analyse d'un jeu de données. Dans ce cas, ce qui est nécessaire et suffisant pour "reproduire" les choses c'est une description précise des méthodes utilisées (à la manière d'une bonne section "Matériels et Méthodes" dans un rapport scientifique qui doit permettre de reproduire un modèle statistique ou une analyse, même sans avoir accès aux détails de l'implémentation dans le code). Dans ce cas, la présentation des résultats de l'analyse ne rentre pas dans ce critère de reproductibilité : un tableau de résultats ou une figure sont juste un format de présentation de l'information produite par l'analyse, et c'est l'information elle-même qui doit être reproductible, pas sa présentation en tableau ou figure.

D'un autre côté, on peut considérer la reproductibilité de tout un pipeline qui produit un document final (un rapport pour des décideurs ou un manuscrit à soumettre à un journal). Dans ce cas, le besoin à satisfaire est de pouvoir "reproduire" toutes les étapes de l'analyse et de la production du document final, afin de pouvoir produire un document en suivant exactement les mêmes recettes très facilement. Bien sûr, si les données en entrée changent, le document final va aussi changer, mais la recette appliquée aux données pour produire le document reste la même. Dans ce cas, le mot "reproductibilité" recouvre en fait un mélange de "reproductibilité" comme définie au paragraphe précédent et d'"automatisation".

2. Reproductibilité et exécution planifiée/avec Jenkins

Je n'utilise pas Jenkins (cela a l'air assez avancé et au-delà de mes compétences actuelles :) ) mais c'est vrai que l'approche proposée dans le journal se prête bien à l'utilisation des options d'intégration continue sur GitLab et GitHub.

Pour préciser un peu le contexte, dans mon précédent groupe de recherche en biologie nous utilisions R pour les analyses de données et la préparation de figures, R Markdown pour la préparation de rapports, LaTeX ou Google Docs pour la préparation de manuscrits et Git pour la gestion de versions. Pour travailler de manière collaborative sur un projet, on utilisait GitLab.

Après un certain temps, notre méthode de travail collaboratif a plus ou moins convergée vers les éléments suivants :

• Pour chaque projet de recherche, on structure notre code et on stocke nos données à la manière d'un paquet R¹ . Bien sûr, le paquet en question n'est pas destiné à une publication sur CRAN, mais cela nous permet de suivre une structure claire pour organiser les fichiers et de profiter de tous les outils de documentation (roxygen2) et de test (testthat) disponibles pour les paquets R.

• Toujours en suivant l'approche "un projet = un paquet", les analyses sont stockées en tant que vignettes R markdown dans le dossier vignettes/ du projet. Là encore, on profite de l'écosystème R : écrire une vignette par analyse nous permet ensuite d'utiliser pkgdown pour générer automatiquement une documentation complète du projet à partir du code R.

• Finalement, tout cela est partagé entre collaborateurs en utilisant GitLab et son intégration continue : à chaque fois que quelqu'un met à jour le code du projet sur GitLab, le paquet est assemblé, documenté, testé, et les vignettes sont exécutées par pkgdown pour préparer le site web contenant l'ensemble de la documentation et des résultats du projet.

C'est une approche très agréable, parce qu'elle permet d'avoir un site propre et toujours à jour sur un projet, et de détecter tout de suite quand une analyse marche sur la machine personnelle d'un collaborateur mais échoue sur l'instance GitLab. Cela permet aussi de faciliter le partage de la recherche de manière publique : soit en basculant le dépôt GitLab de "privé" à "public" lorsque l'article final est accepté, soit en ayant tout en "public" dès le début pour une recherche vraiment ouverte !

Je pense que cela rejoint sans doute un peu ce que tu avais à l'esprit en mentionnant une exécution planifiée avec Jenkins ?

3. Reproductibilité et paquets

C'est vrai que l'utilisation de paquets peut rendre les choses plus compliquées. Il n'est pas toujours possible de se passer de paquets tierces pour des raisons pratiques (par exemple, si on a besoin de faire tourner un modèle Bayésien en utilisant une approche HMC, il vaut mieux utiliser rstan plutôt que d'essayer d'écrire sa propre implémentation). Il y a plusieurs outils qui existent dans l'écosystème R pour essayer de pallier à ce problème, comme par exemple les paquets packrat ou renv (voir aussi les autres entrées dans la section "Package Reproducibility" de la CRAN Task View: Reproducible Research). Dans tous les cas, une bonne pratique est d'ajouter à la fin des sorties de scripts R toutes les informations retournées par sessionInfo() afin de garder la trace de l'environnement utilisé (y compris les versions de R et des paquets).

4. Utilisation de ggplot2

J'aime beaucoup ggplot2 pour une utilisation interactive, notamment pour explorer les données. Les figures produites sont en général claires et jolies, et le code est court et simple, ce qui permet une manipulation très rapide pour essayer différentes visualisations des données. Cependant, pour les figures finales d'un papier, j'ai presque toujours besoin d'une disposition différente de celle par défaut de ggplot2, et j'ai souvent l'impression de devoir nager à contre-courant lorsque je personnalise trop une figure faite avec ggplot (mais c'est sans doute aussi lié au fait que je connais mieux les commandes R de base que celles de ggplot pour faire des graphiques). Donc en général, pour les figures, j'utilise ggplot2 pour l'exploration et j'utilise les fonctions de base (avec beaucoup de grid aussi) pour les figures à publier. Et c'est pour ces dernières que j'ai plusieurs fois eu à faire quelques ajouts manuels :)

5. Shiny

J'aimerais bien apprendre à me servir de Shiny un jour ! Pour ceux et celles qui ne connaissent pas, Shiny permet de créer des applications web à partir de code R² . C'est un outil très puissant pour explorer les données de manière interactive, et c'est vrai que c'est sans doute une excellente façon de partager des résultats compliqués avec des collaborateurs !