Publier le code de son articleVotre revue veut votre code. Est-il prêt ?
De plus en plus de revues demandent le code derrière vos résultats, et certains relecteurs le lisent désormais. Voici ce que disent les principales politiques, et une check-list pour préparer votre code avant de soumettre.
Ce que demandent les revues
Les politiques de partage du code
Quelques exemples. Les politiques évoluent et diffèrent d'une revue à l'autre : vérifiez toujours les consignes de la vôtre. Dernière vérification le 30 septembre 2026.
| Revue | Ce qui est exigé | Depuis |
|---|---|---|
| Nature Portfolio | Le code sur mesure central pour les conclusions doit être fourni aux éditeurs et aux relecteurs sur demande, et une section Code availability est obligatoire. Le code central d'un article peut être relu. | En vigueur |
| PLOS Computational Biology | Publier tout le code écrit par les auteurs et directement lié aux résultats de l'article, sauf dérogation. Refuser de partager le code peut justifier un rejet. | 30 mars 2021 |
| PLOS Biology | Tout le code écrit par les auteurs et nécessaire pour reproduire les résultats, y compris le code d'analyse, les logiciels et les algorithmes, en accès libre à la publication. | 1er janvier 2026 |
Les financeurs vont dans le même sens. En France, le plan national pour la science ouverte consacre un axe entier aux codes sources de la recherche et recommande de les archiver dans Software Heritage.
Avant de soumettre
Une check-list en 10 points pour le code de recherche
Pas besoin d'un logiciel industriel. Il vous faut un code que quelqu'un d'autre peut trouver, exécuter, et en qui il peut avoir confiance pour reproduire les figures de votre article.
- Une version, un seul endroit. Un seul dépôt, pas des copies sur trois ordinateurs. La version utilisée pour l'article est étiquetée.
- Le code correspond à la section Méthodes. Les paramètres, seuils et règles d'exclusion du code sont ceux décrits dans l'article.
- Il s'exécute à partir de zéro. Quelqu'un d'autre que vous peut l'installer et le lancer en suivant des instructions écrites.
- L'environnement est figé. Les dépendances et leurs versions sont listées (fichier requirements, fichier de verrouillage, conteneur).
- Pas de chemins en dur. Pas de
C:\Users\moi\Bureau\donnees_finalesenfoui dans les scripts. - Chaque figure a son script. On sait quel script produit quelle figure ou quel tableau.
- Les résultats clés sont testés. Au moins une vérification que les chiffres principaux sortent toujours les mêmes.
- Le code mort a disparu. Les tentatives abandonnées et les fonctions dupliquées sont supprimées, pas mises en commentaire.
- Il a une licence. Sans licence, personne ne peut légalement réutiliser votre code.
- Il est archivé et citable. Un identifiant pérenne (par exemple un DOI Zenodo, ou une archive dans Software Heritage) et une déclaration de disponibilité du code dans l'article.
À quoi ça ressemble
Une déclaration de disponibilité du code
Courte, précise, et adossée à un dépôt qui fonctionne vraiment. C'est cette dernière partie qui demande le plus de travail.
Vous avez écrit une bonne partie de votre code avec un assistant d'IA ? C'est courant, et ce n'est pas un problème. C'est aussi là que se cachent les fonctions dupliquées, les tentatives à moitié supprimées et les paramètres modifiés en silence. Les points 2, 7 et 8 de la check-list comptent encore plus.
Comment je peux aider
De « ça marche sur ma machine » à « prêt à publier »
Avant la soumission, ou juste après l'acceptation, je reprends votre code avec vous : une seule version propre, une installation qui marche, des tests sur les résultats qui comptent, la documentation, l'archivage et la déclaration pour votre article. Quelques jours de travail, dimensionnés pour le budget de votre labo.