Dépasser les principes FAIR pour les logiciels. Mieux reconnaître et soutenir les logiciels développés par la recherche.
Nature publie un commentaire intéressant sur les logiciels de recherche, appelant à enregistrer, partager et valoriser les logiciels produits par la recherche. Le texte propose d’adapter les principes FAIR, conçus pour les données, aux spécificités du logiciel, en enrichissant les principes FAIR4RS (FAIR for research software).
L’annexe du texte que nous republions ci-dessous présente des éléments intéressants destinés à nourrir une feuille de route d’amélioration des pratiques de partage des logiciels, intitulée « CODE beyond FAIR » qui propose un certain nombre de bonnes pratiques pour faire en sorte que les logiciels soient plus transparents, plus intelligibles, plus faciles à exécuter hors du contexte de production et d’exécution classique du logiciel, et développés de façon plus collaborative.
Le texte appelle également au développement de formations aux bonnes pratiques de développement logiciel, en particulier au-delà des chercheurs en informatique. Il invite également à développer l’archivage des logiciels, à reconnaître la contribution des logiciels à l’avancée de la recherche, et à investir dans les logiciels et leurs infrastructures, qui sont souvent des piliers essentiels de la science ouverte.
« Stop Treating Code like an Afterthought: Record, Share and Value It ». Nature 646 (8084): 284‑86. https://doi.org/10.1038/d41586-025-03196-0.
Supplementary Information to: A road map to improve software sharing practices
Authors
Roberto Di Cosmo1,2, Sabrina Granger6, Konrad Hinsen3,4, Nicolas Jullien5, Daniel Le Berre7, Violaine Louvet8, Camille Maumet9, Clémentine Maurice10, Raphaël Monat10 & Nicolas P. Rougier11,∗
∗ Corresponding author: nicolas.rougier@inria.fr
Affiliations
1 Inria Paris, Paris, France
2 Universite Paris Cité, Paris, France
3 Centre de Biophysique Moléculaire (CNRS), Orléans, France
4 Synchrotron SOLEIL, Saint Aubin, France
5 IMT Atlantique, Brest, France
6 Inria Lyon, Lyon, France
7 CRIL, Université d’Artois, Lens, France
8 Laboratoire Jean Kuntzmann, Grenoble, France
9 Inria, Univ Rennes, CNRS, Inserm, Rennes, France
10 Univ. Lille, CNRS, Inria, UMR 9189 CRIStAL, Lille, France
11 Centre Inria de l’université de Bordeaux, Bordeaux, France
Table S1: Create, curate, collaborate
Many researchers and engineers write code for their research projects yet have not received specialized training in software engineering. These steps should be taken, gradually, to ensure software is suitably shared and archived.
| Mandatory | Recommended | Optional | |
|---|---|---|---|
| Make software open source: ensure that everyone can inspect and use the software | Publish code on a public platform Ensure that it is saved in a dedicated archive such as Software Heritage or Zenodo | Choose an open licence* Declare authors and rightholders | Put software under version control |
| Document: make the code intelligible to others | Use meaningful names for everything, Explain how the code works, Provide examples and tutorials | For larger projects, provide a reference documentation explaining how to use a given function, in what conditions, what are the arguments, their type and their meaning, etc. | |
| Execute: enable others to run the software | Provide a list of software and hardware dependencies. For example, the operating system on which it can be run and any other software or libraries that need to be installed prior to usage. | Provide a ready-to-run computational environment**, a test suite, and real-life usage examples |
|
| Collaborate: interact with a community of users | Have a strategy to effectively deal with any future contributions from collaborators, Describe the limits that the developers have decided concerning maintenance, feature addition and support Respond to questions Engage in active community building, such as explaining to fellow researchers and engineers how to contribute |
Table S2: Team up for good
Good practices need support and involvement from all actors of the scientific ecosystem.
Research institutions, funders, libraries and publishers have more substantial means at their disposal to support research software than research groups — and so they also have more responsibility.
| Mandatory | Recommended | Optional | |
|---|---|---|---|
| Research institutions | Provide the infrastructure and human resources required for software development Recognize the work software development and maintenance involves; embed it in employee assessments | Consider software as a valuable research output, in the same way as journal articles are, for example in researchers’ production/career evaluation | Host software developments on institutional platforms Provide training in software engineering |
| Funders | Provide durable financial support for software research, development and maintenance, beyond the cycle of research grants. The Chan Zuckerberg Foundation, for example, has made such grants available | Add reproducibility as a criterion for continued funding | Facilitate collaborations through specific funding schemes |
| Libraries | Organize, curate and maintain software metadata and archives Create reference tools addressing the specificities of software (evolution, authorship, ...) | Build catalogs of software to ensure findability, visibility and accessibility | |
| Publishers | Following the push for open science, mandate free and open-source software for all published research | Archive the version of software associated with publications | Review software |
