Close

décembre 10, 2025

Institut Pasteur: Faire reconnaître les logiciels

grayscale photography of laptop

Les bibliothèques font progresser l’enseignement, la recherche et l’apprentissage en fournissant des ressources, en facilitant la découverte et en offrant des conseils spécialisés. Le code source des logiciels devenant de plus en plus central dans la recherche contemporaine, les bibliothèques doivent soutenir les chercheurs et chercheuses qui travaillent avec ces codes. Dans cette série d’entretiens, des professionnels partagent leur approche des logiciels de recherche. 

L’archivage de code source est souvent appréhendé à travers le prisme technique, alors qu’il s’agit avant tout d’un défi culturel. En effet, si les initiatives pour faire reconnaître le rôle clé des logiciels dans la recherche se multiplient, tout un travail de sensibilisation reste à mener au quotidien. C’est pourquoi l’Institut Pasteur place l’accompagnement des chercheuses et des chercheurs au cœur de sa stratégie. 

Fanny Sébire est data librarian au Centre de ressources en information scientifique (CeRIS) de l’Institut Pasteur. Elle accompagne les scientifiques dans la gestion, le signalement, l’archivage et la diffusion des données qu’ils produisent dans le cadre de leurs travaux (données de microscopie, de séquençage, d’études cliniques, etc.). F. Sébire collabore aussi avec les autres équipes d’appui à la recherche de l’Institut Pasteur, pour développer des outils informatiques ou contribuer à la politique institutionnelle. Elle coordonne l’équipe de rédaction du blog Open Science. 

Ingénieur logiciel en bio-informatique, Bertrand Néron est ambassadeur Software Heritage. Il fournit des solutions informatiques à des questions de recherche, en concevant l’architecture de ces outils, en travaillant sur leur design et en assurant leur passage en production. B. Néron s’intéresse particulièrement aux enjeux de reproductibilité de la recherche. 

Dans cet entretien, F. Sébire et B. Néron expliquent comment ils collaborent pour faire évoluer la perception du code source et du logiciel au sein de leur institution. 

En bref:

  • Les pratiques de développement et de gestion des logiciels de recherche demeurent très hétérogènes, il ne faut pas présupposer une standardisation des pratiques
  • Il faut faire changer la perception du logiciel : c’est moins un changement technique que culturel
  • Toutes les personnes qui produisent du code devraient apprendre à l’archiver. Chercheur·ses, ingénieur·es, et étudiant·es devraient être formé·e·s. 

Quelles ressources recommanderiez-vous à un·e collègue bibliothécaire souhaitant s’initier aux concepts d’ingénierie logicielle ? 

[Fanny Sébire] Je recommanderais notre blog dans lequel nous abordons régulièrement le sujet des bonnes pratiques de développement logiciel. Concernant l’ouverture des codes et logiciels, je recommande la collection “Passeport pour la science ouverte” du ministère de l’Enseignement supérieur et de la Recherche, qui comporte un livret dédié au logiciel. Et pour découvrir le dépôt de logiciel dans HAL, le guide de DORANum est très clair. 

En tant que professionnelle de l’information, qu’est-ce qui vous a le plus étonnée quand vous avez commencé à travailler sur les logiciels de recherche ? 

[Fanny Sébire] Lorsque j’ai commencé à travailler sur les données de recherche, j’ai rapidement compris que les pratiques étaient très variées parmi les chercheurs : chaque équipe de recherche avait sa façon de les organiser, les nommer, les décrire, les stocker, les diffuser… Je pensais que ce serait différent pour les logiciels de recherche : je croyais que les ingénieur·es auraient davantage harmonisé leurs pratiques, en utilisant des processus ou des outils communs notamment. Mais je me suis rendu compte que ce n’était pas vraiment le cas. Par exemple, l’utilisation de GitHub ou de GitLab n’est pas encore la norme à l’Institut.

Comment votre établissement facilite-t-il l’accès aux logiciels de recherche ?

[Fanny Sébire] En mai 2021, l’Institut Pasteur a publié sa politique institutionnelle qui fixe les lignes directrices en matière de gestion et de partage des données et codes logiciels. Elle résume les bonnes pratiques à mettre en œuvre tout au long du processus de recherche et renvoie vers des fiches qui aident les scientifiques à passer à l’action. Il s’agit de recommandations, et non d’obligations :

  • Se doter d’un plan de gestion de logiciel (PGL), comme outil d’aide à la réflexion et à la planification des étapes de développement et de gestion : l’objectif est de rendre le logiciel plus réutilisable et durable
  • Déposer les logiciels créés à l’Institut Pasteur dans l’instance Gitlab institutionnelle 
  • Attribuer de préférence une licence ouverte à tout logiciel pouvant être rendu public
  • Promouvoir son logiciel auprès de la communauté scientifique, le référencer dans le registre bio.tools et sur le site research.pasteur.fr
  • Archiver tout code source public dans Software Heritage et le déposer dans le portail HAL-Pasteur, pour en faciliter la citation et plus visible

[Bertrand Néron] La politique institutionnelle et les recommandations visent à rendre la science plus ouverte et plus reproductible. Cela se traduit notamment par la volonté de rendre publics tous les codes de la recherche qui peuvent l’être, de leur attribuer systématiquement une licence de diffusion/exploitation et de les archiver dans Software Heritage pour garantir la traçabilité et la reproductibilité des publications. 

Depuis 2021, la charte de l’Institut Pasteur pour le libre accès aux publications demande aux chercheuses et chercheurs de déposer leurs publications dans HAL. Actuellement, peu de personnes savent que l’on peut également y déposer des logiciels et bon nombre ne connaissent pas Software Heritage. Je travaille avec le CeRIS pour que les codes de la recherche bénéficient de la même attention que les publications.

Quelle est la stratégie de la bibliothèque concernant la gestion des données de recherche et du code source qui y est associé? 

[Fanny Sébire] Je collabore étroitement avec l’équipe de la plateforme de data management de l’Institut Pasteur. Nous nous appuyons beaucoup sur les plans de gestion des données (PGD) de projet ou d’une entité, pour inciter les scientifiques à se poser les bonnes questions le plus tôt possible. Je me charge de la relecture de ces PGD, ce qui me permet d’orienter les scientifiques vers les réflexes méthodologiques à adopter, les bons outils ou les bons interlocuteurs. Par exemple, si certain·es chercheur·ses se posent des questions sur l’utilisation de Gitlab ou le choix d’une licence logicielle, je peux les orienter vers Bertrand Néron.

Nous aimerions également nous appuyer sur les PGD pour inciter les chercheurs à archiver leurs données et le code source en fin de projet. Actuellement, je travaille avec le pôle Archives et la Direction des Systèmes d’Information sur une solution d’archivage électronique des données, codes et logiciels privés. Les codes publics ont quant à eux vocation à être archivés sur Software Heritage. Notre objectif principal est de veiller à ce que données et logiciels archivés soient correctement documentés et contextualisés afin de garantir leur intelligibilité et exploitabilité sur le long terme.

Par ailleurs, mes collègues de la bibliothèque chargés de la modération dans HAL-Pasteur souhaitent renforcer la sensibilisation sur le dépôt logiciel et le couplage avec Software Heritage :

  • En organisant des ateliers/formations au cours desquels les participantes et les participants pourraient déposer leur code
  • En identifiant les publications et préprints déposés dans HAL-Pasteur qui comportent un lien vers une forge, afin d’envoyer un email aux auteurs pour proposer de les accompagner dans l’archivage de leur code et le dépôt dans HAL

[Bertrand Néron] A l’heure actuelle, je pense qu’il y a de nombreuses solutions techniques à notre disposition pour gérer efficacement les codes et logiciels de la recherche. Pour moi, le problème principal n’est pas d’ordre technique, mais culturel. Codes et logiciels ne sont pas encore considérés comme des productions scientifiques à part entière, mais davantage comme des artefacts de moindre importance. 

Les prochaines étapes sont de deux ordres. D’une part, il faut sensibiliser les chercheur·ses. Il s’agit de leur faire comprendre l’importance des codes et logiciels dans la production académique. L’objectif est que toutes et tous accordent plus d’importance à la bonne gestion de leur code source. Il faut aussi faire évoluer la perception des instances d’évaluation, afin de (re)valoriser le fait de produire du code et des logiciels comme de mobiliser de meilleures pratiques d’ingénierie logicielle. D’autre part, il s’agit de concevoir des guides et de former aux solutions, tel que le couplage SWH-HAL, qui contribuent à réduire la non-reproductibilité des résultats de recherche.

Comment la bibliothèque collabore-t-elle avec l’ambassadeur Software Heritage ? 

[Fanny Sébire] J’ai commencé à travailler avec Bertrand [Néron] dans le cadre d’une « Rencontre data » co-organisée en 2020 avec Anne-Caroline Delétoille, la responsable de la plateforme de data management. Le thème était la gestion des codes et logiciels de recherche. Nous avions sollicité Bertrand pour intervenir sur les bonnes pratiques de développement logiciel. Nous avons ensuite continué à échanger régulièrement et à nous solliciter mutuellement. Par exemple, nous avons organisé des réunions avec les responsables d’unités de recherche, au cours desquelles étaient présentées les préconisations pour mieux gérer données et logiciels. Nous aimerions développer davantage certains sujets dans les prochains mois :

  • La mise en oeuvre de plans de gestion de logiciels (PGL). Après avoir suivi une formation sur le sujet, Bertrand a récemment rédigé son premier PGL. Nous pourrions nous fonder sur son expérience pour inciter d’autres ingénieur·es ou chercheur·ses à l’imiter.
  • Les modalités d’archivage du code source: dans Software Heritage si le code est public, en interne si le code est fermé. Bertrand a testé la procédure conçue avec le pôle Archives pour archiver du code fermé. 

[Bertrand Néron] Je suis ingénieur de recherche au HUB de bioinformatique et biostatistique, un service qui accompagne les scientifiques dans le domaine des analyses bioinformatiques et biostatistiques, ainsi que dans le développement d’applications de recherche. Ce service est composé d’une quarantaine d’ingénieurs. Je développe principalement des applications d’annotation automatique de génomes bactériens. Au sein de mon unité, je fais partie d’un groupe de travail chargé de réécrire nos guides de gestion de projets. Nous y intégrons des recommandations en termes d’analyses et/ou développement. Ainsi, dans la dernière version, nous avons ajouté la rédaction des plans de gestion des logiciels et l’archivage des codes publics dans Software Heritage. Ce travail est le résultat d’une collaboration avec la plateforme de data management et avec Fanny, du CeRIS. 

L’objectif est de proposer au personnel de l’Institut Pasteur des solutions simples, robustes et pérennes, comme:

  • L’archivage des codes publics dans Software Heritage
  • L’édition de métadonnées dans HAL-Pasteur 
  • Le recours à une solution d’archivage interne pour ajouter des éléments de contexte (emails, appels d’offres, …) et lier les unes aux autres les références de différents éléments d’un même projet

Cette approche nous permet de ne pas dupliquer les informations existantes et de tirer parti de la puissance de Software Heritage pour notamment résoudre certains problèmes de reproductibilité. La découvrabilité de nos logiciels est renforcée grâce à l’édition de leurs descriptifs dans HAL. Ainsi, il s’agit de contribuer à une science reproductible et ouverte, l’un des axes stratégiques de l’Institut Pasteur. Cette nouvelle politique est en cours d’approbation. Nous espérons la mettre en œuvre rapidement au sein du HUB de bioinformatique et biostatistique puis la décliner pour d’autres unités.

Quelles synergies identifiez-vous entre Software Heritage et les services existants dans votre institution ?

[Fanny Sébire] La synergie évidente est celle entre notre portail HAL-Pasteur et Software Heritage, qui est grandement facilitée par l’interconnexion entre les deux. En ouvrant et pérennisant les publications et le code source, les deux outils contribuent à une science plus ouverte et reproductible.

Je pense également qu’il peut y avoir une synergie entre Software Heritage et notre pôle Archives, car les deux entités ont pour mission de préserver le patrimoine scientifique. Il me semble important de travailler de concert : utiliser l’outil Software Heritage pour préserver le code et accompagner les scientifiques pour qu’ils archivent en interne tous les documents liés à ce code. La réponse à l’appel à projets, le diaporama présentant le projet, le rapport d’activité, sont autant d’éléments pemettant de comprendre le contexte. 

[Bertrand Néron] Dans les sciences du vivant, la majorité des codes de recherche sont créés pour engendrer des connaissances, souvent mesurées à l’aune des publications qui en découlent. Dans cette perspective, le code suscite moins d’intérêt que les articles car il est considéré seulement comme un moyen, et non pas comme une finalité. Or, pour évoluer vers une recherche plus reproductible, il est important de faire changer cette conception. En rejoignant le programme des ambassadeurs Software Heritage, je bénéficie d’informations de première main sur les solutions disponibles. J’ai aussi accès à des ressources pédagogiques pour informer, former mes collègues sur les bonnes pratiques de gestion des codes. Je peux également rencontrer d’autres ambassadeurs dans des domaines proches et échanger sur leurs actions, m’en inspirer ou collaborer. 

Enfin, le fait d’être ambassadeur me procure de la légitimité au sein de mon institution : ma hiérarchie m’identifie comme un interlocuteur pour faire progresser la prise de conscience de l’importance du code. J’explique les bénéfices pour les utilisateur·trices et pour l’institution.  

Quels sont les principaux défis rencontrés en matière d’archivage de code source ? 

[Fanny Sébire] À mon sens, la première difficulté vient du fait que trop peu de chercheur·ses connaissent Software Heritage au sein de l’Institut Pasteur. Vient ensuite le fait qu’ils ou elles ne perçoivent pas l’intérêt d’archiver leur code, car ils ou elles estiment que les forges jouent ce rôle. Le risque n’est pas compris. 

Pour la bibliothèque, il est important d’inciter les auteur·trices de logiciels à décrire le code source, en complétant un fichier codemeta.json et en déposant le logiciel sur HAL. C’est surtout sur ce point que nous rencontrons des difficultés : très souvent, les chercheur·ses considèrent qu’il s’agit d’une tâche administrative chronophage. 

[Bertrand Néron] L’une des difficultés est le manque de connaissance de Software Heritage. Les chercheur·ses et étudiant·es utilisent les forges logicielles comme s’il s’agissait de solutions pérennes. Toutes et tous sous-estiment les problèmes potentiels liés à l’hébergement de code, notamment lorsqu’il est géré avec une solution privée. Mais les décisions récentes du gouvernement américain ont jeté une lumière crue sur les enjeux d’archivage des données de recherche. 

Par ailleurs, un obstacle structurel subsiste : les revues ne tiennent pas suffisamment compte des spécificités du logiciel. Par exemple, des relecteur·tricesréclament fréquemment le DOI d’un code source, plutôt qu’un SoftWare Hash IDentifier. Or, quand bien même les auteur·trices utiliseraient des SWHIDs, une fois le processus éditorial engagé, il est trop tard pour tenter d’infléchir des habitudes bien ancrées si cela n’est pas prévu par la revue. 

Enfin, les chercheur·ses ne perçoivent pas la valeur ajoutée des métadonnées. Par conséquent, alors que le retour sur investissement est majeur pour tous·tes, compléter un fichier Codemeta reste perçu comme une tâche superfétatoire. À cela peut s’ajouter une incompréhension : une partie des utilisateur·trices considèrent en effet à tort les fichiers codemeta.json comme étant spécifiques à l’archivage dans Software Heritage. Or, CodeMeta est un standard. Ajouter un fichier de métadonnées intrinsèques à son code repository constitue une bonne habitude, quelle que soit la solution d’archivage choisie (Zenodo, Figshare, etc.). 

Quelles collaborations faut-il mettre en place ou renforcer pour assurer plus efficacement la pérennité du code source des logiciels de recherche ? 

[Fanny Sébire] Il me semble qu’il pourrait être utile de renforcer la collaboration avec les services d’Archives des universités et institutions de recherche. Je ne suis pas certaine qu’ils connaissent tous Software Heritage alors qu’ils pourraient en être de bons ambassadeurs auprès des scientifiques.

Par ailleurs, étant donné que les données et les codes sont très souvent associés et publiés en parallèle, je pense qu’une collaboration avec les entrepôts de données serait importante. Il ne s’agirait pas d’interconnecter techniquement Software Heritage à la multitude d’entrepôts existants. Les entrepôts de données pourraient simplement informer les déposants qu’il est préférable d’indiquer un SWHID plutôt qu’un lien vers une forge pour assurer la pérennité du lien entre données et codes.

[Bertrand Néron] Il faudrait former à l’archivage dans Software Heritage toutes les personnes qui rédigent du code source, qu’il s’agisse de chercheur·ses, d’ingénieur·es, d’étudiant·es. La clé est de s’appuyer sur des exemples concrets dans leur domaine pour leur faire comprendre les bénéfices de l’archivage. Ces formations devraient mettre l’accent sur la pratique afin de souligner à quel point il est facile de passer à l’action. Une formation au dépôt de logiciel dans HAL est par exemple organisée en novembre 2025. 

À l’Institut Pasteur, les étudiant·es et post-docs produisent une grande quantité de code, mais ces personnes ne restent pas forcément au sein de l’institution. L’enjeu est donc d’inscrire l’effort de formation dans la durée, pour tenir compte du renouvellement régulier des personnes à accompagner. 

Enfin, il faut sensibiliser en priorité les commissions d’évaluation des carrières afin que les logiciels soient mieux pris en compte, et pas seulement les publications associées. Je suis sûr que si le code prenait une place plus importante dans l’évaluation, les chercheur·ses, les ingénieur·es et les étudiant·es prendraient le temps de le rendre plus visible, notamment en le déposant sur HAL. 

Repérer les mentions de logiciels dans les articles 

Identifier les publications et les prépublications qui incluent un lien vers un code repository ou une mention de logiciel est à la fois un défi et un prérequis majeur pour une meilleure évaluation de l’impact des logiciels. En raison de la diversité de leurs formes, les mentions aux logiciels sont difficiles à tracer. Le projet SoFAIR a pour objectif d’améliorer et de semi-automatiser le processus d’identification, de description, d’enregistrement et d’archivage des logiciels de recherche, en s’assurant qu’ils sont associés à un SWHID (SoftWare Hash Identifier). SoFAIR a été conçu pour enrichir les services des infrastructures scientifiques ouvertes de référence (CORE, Software Heritage, HAL). Il doit aussi permettre d’améliorer des outils exploités par les partenaires du consortium, tels que GROBID, en fournissant une solution efficace pour la gestion du cycle de vie des logiciels de recherche.

À venir