"10 Years Reproductibility Challenge" : pour l'amour du code pérenne

Seriez-vous capable de faire fonctionner aujourd’hui le code que vous avez créé pour des recherches menées il y a dix ans et plus ? C’est le défi que lance le concours Ten Years Reproductibility Challenge, une initiative de la revue ReScience C. Entretien avec son éditeur en chef, Nicolas Rougier, chercheur à INRIA au LABRI.

Grand Labo : Qu'est-ce que ReScience C ?

Nicolas Rougier : ReScience C est un journal académique en open access sur Github, au reviewing complètement ouvert, que j’ai cofondé avec Konrad Hinsen en 2015. Son but est de publier des réplications de travaux en sciences computationnelles. Dans nos disciplines, les articles publiés sont basés sur du code. Il y a quelques années, ce code était rarement présent dans l’article en lui-même : pour y avoir accès, le lecteur devait contacter l'auteur de l'article. Cela posait des problèmes pratiques épineux, notamment lorsque le code était perdu... Il fallait tout recoder ! Or, avant que ReScience C ne soit lancé, nous n’avions pas d’endroit pour partager entre collègues l’article sur le code duquel nous avions dû retravailler. D'où l'idée de ReScience C.

G.L : « Reproducible Science is good. Replicated Science is better » est inscrit au fronton de Rescience C. Qu’est-ce que ça signifie ?

N.R : On peut distinguer entre reproduction et réplication. Reproduire une étude scientifique, c’est vérifier, à partir d’un même jeu de données et le même code que ceux de la recherche initiale, que l’on obtient un résultat proche ou identique à celui l’article de départ. Répliquer un travail de recherche, c’est, en suivant le protocole présenté dans l’article, refaire entièrement le code, en en changeant que des paramètres non essentiels, comme le langage informatique, en passant de Python à C+, par exemple. Dans ReScience, ce travail de réplication permet de décrire les erreurs de l’auteur de l'article original, de le complémenter.

G.L : Pourquoi vous êtes vous personnellement intéressé à ces questions ?

N.R : En arrivant au laboratoire dans lequel je travaille aujourd'hui, j'ai voulu réutiliser un modèle mis au point par un post-doc, parti avant mon arrivée. J'ai demandé où était le code source. Impossible de mettre la main dessus. Nous avons réussi à recontacter le post-doc, pour qu'il nous envoie le code... Et nous nous sommes aperçus qu'il était écrit dans un langage informatique désuet. Il a fallu tout refaire... Je crois que c'est de cette mésaventure que tout est parti.

G.L : D'après vous, les chercheuses et chercheurs sont-ils assez sensibilisés à ces questions ?

N.R : Les choses changent, je crois. La prise de conscience varie beaucoup selon les domaines scientifiques. Nous avons d'ailleurs publié un livre en libre accès sur la reproductibilité qui montre qu’on peut commencer par changer des choses toutes bêtes. Par exemple, tout simplement, d'avoir différentes versions d’un même document !

G.L : Que répondez-vous à ceux qui ne se sentent pas concernés par ces enjeux de reproductibilité ?

N.R : Le premier bénéficiaire de bonnes pratiques de recherche reproductible, c’est le chercheur lui-même ! Elles facilitent sa vie professionnelle sur le long terme et au quotidien. Supposons que vous soumettiez un papier à une revue, et que le reviewer ne reviennent vers vous qu'un an après en vous demandant d'ajouter telle ou telle information dans un de vos graphiques auquel vous n'avez plus touché depuis... Le risque est grand, si l'on n'a pas adopté certaines bonnes habitudes, de se retrouver ennuyé.

G.L : L'équipe de ReScience lance la première édition d’un concours, « Ten Years Reproductibility Challenge ». Quel est le principe ?

N.R : La question posée est celle-ci : seriez-vous capable de faire tourner un code utilisé pour un papier vieux de dix ans ? De retrouver vos résultats d’il y a dix ans ? L’idée est de sensibiliser les chercheurs à la question de la reproductibilité des travaux de recherche, quelle que soit leurs domaines scientifiques ou le langage informatique utilisé. On peut participer jusqu’au 1 avril 2020. En juin, un événement sera organisé à Bordeaux pour présenter les résultats de ce challenge.

G.L : En quoi est-ce un défi ?

N.R : Ça l’est à plusieurs titres. D’abord, du fait de l’obsolescence des supports… CD et disquettes étaient notre quotidien et ont progressivement disparu. Ensuite, du fait de l’abandon de certains logiciels. La version 2 du langage Python, langage très utilisé par les chercheurs, n’est par exemple plus maintenue depuis 1er janvier 2020.

G.L : En matière de reproductibilité, est-ce que les bonnes pratiques peuvent tout faire ?

N.R : Non, sans doute. C’est pourquoi des politiques nationales et européennes se mettent progressivement en place et que différentes initiatives structurantes ont vu le jour ces dernières années, telles que des projets d’archivage de logiciels, comme SoftWare Heritage. Mais nos bonnes pratiques individuelles et collectives sont indispensables. Encore une fois, elles ne supposent pas de changer du tout au tout sa manière de travailler.

G.L : Partager son code, donner accès à ses données… pour certains chercheurs, cela revient à se déposséder de ce qu’il y a de plus précieux à leurs yeux...

N.R : Et pourtant, il n’y a pas assez d’une vie pour exploiter les codes et les données que l’on produit au cours de sa carrière : les partager, c’est permettre à d'autres chercheurs d'en faire une utilisation à laquelle on n'aurait soi-même pensé. Et ouvrir son code, c'est aussi un moyen de le faire améliorer par la communauté.

J’ai l’impression que les jeunes chercheurs sont peut-être un peu mieux habitués à la question de l’open source et l’open data. Au-delà de ses convenances personnelles, je rappelle que l’Europe impose le partage des données de recherches produites par des financements européens. Cela dit, ces discours officiels mettent du temps à devenir concrets. La revue Nature, par exemple, est censée respecter cette obligation. Dans les faits, il est difficile de récupérer le code utilisé par les auteurs des articles qu'elle publie. Bref, il y a encore du travail.

Quelques liens :

• La revue Rescience C sur Github
• Le projet ReScience C expliqué sur HaL
• Ten Years Reproductibility Challenge
• Ten Simple Rules for Scientific Fraud & Misconduct par Nicolas Rougier et John Timmer