pouvez repérer les entrepôts académiques, tels que les archives en libre accès, ainsi que les éditeurs et les agrégateurs qui collectent et échangent tous des données. Leur mission, autrefois centrée sur les publications, s'étend désormais aux données, mais qu'en est-il des logiciels ? Si l'on veut gérer correctement des logiciels, il faut travailler avec des archives logicielles universelles, qui relient l'écosystème de la recherche à tous les autres écosystèmes et garantissent un bon archivage et un bon référencement, non seulement pour la fine couche de code source qui aura été développée dans le cadre de travaux de recherche, mais aussi pour tous les autres composants nécessaires à son fonctionnement.

L'initiative Software Heritage que nous avons lancée il y a sept ans entre en jeu ici en archivant tout ce qui est disponible au niveau mondial. Elle fournit une architecture commune à laquelle l'écosystème académique apporte une valeur ajoutée par le biais de la conservation, de la description, de la citation, du crédit, etc. En France, nous travaillons depuis de nombreuses années à la mise en œuvre concrète de cette vision. Il existe un véritable flux de travail à disposition des chercheurs aujourd'hui en France pour archiver automatiquement leurs logiciels, ainsi que les logiciels dont ils ont besoin et qui ne leur appartiennent pas nécessairement, dans l'archive Software Heritage⁴. Ils peuvent également déposer les métadonnées appropriées, qui sont conservées, sur le portail d'accès national HAL⁵. Cela vous permet de générer de belles présentations d'un projet de logiciel, avec les crédits appropriés, avec la référence à l'institut qui l'a financé, une description précise de la manière de le citer et un pointeur qui vous redirige sur cette archive universelle, Software Heritage, qui vous fournit une vue complète de ce logiciel comme de n'importe quel résultat de la recherche, et pas seulement comme d'un tas de zéros et de uns.
<figure><img src="image_43.png" /><figcaption>Fig. 15 : Infrastructures logicielles de recherche : architecture globale</figcaption></figure>

Source : EOSC Executive Board Working Group (WG) Architecture Task Force (TF) SIRS, « Scholarly Infrastructures for Research Software », Website (Publications Office of the European Union, 7 décembre 2020), http://op.europa.eu/en/publication-detail/-/publication/145fd0f3-3907-11eb-b27b-01aa75ed71a1/language-en.

Cet exemple montre que ces interconnexions peuvent être établies avec succès, et montre également comment le faire correctement. Si vous me le permettez, j'aime-rais inviter ici d'autres personnes, organisations et pays à unir leurs forces dans le même type d'initiative. Essayons d'éviter les risques et les erreurs majeurs que nous avons pris et commis dans d'autres domaines, par exemple en tombant dans le piège de la dispersion. Nous ne devons pas construire une multitude d'infrastructures et de silos différents et incompatibles un peu partout. Malheureusement, la tentation est grande pour chacun de construire « sa propre archive », mais le résultat est que vous vous retrouvez avec des artefacts dupliqués au sein de différentes archives, avec des identifiants différents, et vous devrez alors dépenser beaucoup d'argent, de temps et d'efforts pour essayer de construire une fédération après coup au lieu de la concevoir en amont. Nous devrions éviter d'utiliser des plateformes fermées ou à but lucratif que nous ne pouvons pas contrôler, ainsi que d'utiliser l'argent des projets pour financer des opérations, qui sont une question tout à fait différente, dans le secteur de la recherche.

Ce n'est qu'un aperçu des actions qui peuvent être entreprises au niveau infrastruc-turel. Prenons maintenant un peu de recul, et concentrons-nous maintenant sur les questions politiques plus larges que nous devons également aborder. Si nous voulons vraiment que les logiciels jouent le rôle fondamental qui est le leur dans la science
ouverte, il est important d'avoir des politiques favorables à la diffusion et à la réutilisation des logiciels développés pour faire de la recherche. Nous devons vraiment choisir par défaut l'open source pour les logiciels de recherche. L'open source crée de la valeur : regardez le secteur industriel, qui génère ainsi des milliards d'euros, et vous verrez que ce n'est pas incompatible avec le transfert de technologie. Nous devons simplement adapter à l'open source notre façon traditionnelle de faire du transfert de technologie.

Nous avons également besoin d'un cadre pour l'évaluation et la reconnaissance des chercheurs, car malheureusement, de nombreux pays passent encore du temps à développer de beaux logiciels de haute qualité qui sont nécessaires à la recherche, mais sans que cela compte dans la carrière d'un chercheur ou d'un ingénieur, et cela doit changer. Lorsque nous procéderons à ce type d'évaluation, nous devrons éviter les erreurs que nous avons déjà commises à propos des publications : il importe notamment d'éviter d'avoir uniquement recours à des indicateurs quantitatifs, qui sont encore plus dommageables dans le domaine des logiciels que dans d'autres domaines. Nous devrons également aborder la question de la durabilité de l'open source sur les plans technique, organisationnel et financier.

Il existe toutefois une bonne nouvelle, c'est que la prise de conscience progresse. En 2018, une quarantaine d'experts de toute la planète sont venus à Paris pour travailler sur l'Appel de Paris sur le code source des logiciels⁶. Si vous regardez cet Appel, qui a été publié sur le site de l'Unesco dès 2019, l'un de ses objectifs est de faire reconnaître le développement de logiciels comme une activité de recherche précieuse, et d'en tenir compte dans la carrière des scientifiques s'ils produisent des logiciels de haute qualité. Plus récemment, un rapport sur les infrastructures savantes pour les logiciels de recherche, rédigé par un groupe de travail créé sous l'impulsion de la Commission européenne, a appelé à rendre les logiciels de recherche disponibles en tant que source ouverte, sauf s'il existe de fortes raisons de ne pas le faire.⁷ En outre, dans la recommandation de l'Unesco sur la science ouverte, récemment publiée⁸, il est demandé de n'utiliser que des infrastructures à long terme et sans but lucratif pour la science ouverte et de fonctionner à l'échelle communautaire.

La mise en œuvre de ces recommandations de haut niveau a déjà commencé en France. Si vous regardez le 2ᵉ Plan national français pour la science ouverte⁹, il y a maintenant un chapitre entièrement consacré aux logiciels, qui est au même niveau que la publication et les données. Parmi les nombreuses recommandations figure la création d'une charte pour la politique des logiciels de recherche au niveau national et pour la reconnaissance du développement de logiciels. Ce deuxième point est déjà mis en œuvre, comme vous le verrez lors de la remise des prix du logiciel libre juste
après cette session, et le PNSO inclut a beaucoup d'autres dispositions importantes que je n'ai pas le temps d'approfondir maintenant.

Il y aurait eu tellement d'autres choses à dire, mais je devais en choisir quelques-unes qui me semblent très importantes. Si vous regardez le chemin à parcourir, il est évident que nous devons consacrer plus d'énergie, d'argent et de temps à la construction d'une infrastructure adéquate pour les logiciels de recherche et à la reconnaissance du fait que les logiciels sont un pilier fondamental de la recherche, pas seulement un outil. Les logiciels ont de nombreuses implications, et je pense que l'exposé du professeur Lucke en abordera certaines. Ensuite, nous devons bien sûr nous relier à l'écosystème de la recherche, en connectant le logiciel aux publication et aux données. Le rôle des éditeurs est ici fondamental, mais je leur demande de prendre le temps de considérer que le logiciel est un produit noble de la recherche, pas juste un paquet de données, et qu'il faut lui faut donc des infrastructures et des identifiants spécifiques.

Enfin, nous avons besoin de représentation et de soutien à un niveau institutionnel, de la même manière que cela a pu être fait pour les autres aspects de la science ouverte. Nous avons besoin d'un bureau chargé de la stratégie concernant les logiciels de recherche et les sources ouvertes, et pas seulement en termes de transfert de technologie. Nous devons aider nos collègues à assurer le financement et la gouvernance des logiciels, et ainsi de suite. Enfin, en ce qui concerne les incitations et la reconnaissance dans l'évaluation, il est possible de valoriser les logiciels de recherche de qualité, mais là encore, il faut se méfier des indicateurs quantitatifs. Nous ne voulons pas avoir un indice S(oftware) pour indice logiciel, comme l'indice h dans la publication. Il existe d'autres moyens, comme la cérémonie de remise des prix du logiciel à laquelle vous allez assister aujourd'hui. Nous devons vraiment construire ensemble le pilier logiciel de la science ouverte. Le moment est enfin venu. Comme toujours dans le monde universitaire, le changement prend du temps, mais je crois vraiment qu'ensemble, si nous travaillons de manière cohérente, nous pouvons réellement y arriver.

## Pour aller plus loin

« L'étape suivante consisterait à mettre en place une collaboration européenne ou internationale dans le cadre de laquelle les institutions universitaires et les organismes de recherche uniraient leurs efforts et s'appuieraient sur un terrain d'entente en matière d'archivage des logiciels, de référencement des logiciels, de fourniture de métadonnées appropriées, de crédit et de citation, et de reconnaissance du travail des chercheurs pour ce qu'ils font en matière de développement de logiciels. »
« Les prix nationaux décernés à l'occasion des journées OSEC représentent la première fois qu'au plus haut niveau institutionnel, nous mettons en lumière les personnes qui ont passé un nombre incroyable d'heures à construire les logiciels indispensables à la recherche d'aujourd'hui. »

« En dehors du monde universitaire, il y a trop de domaines où les logiciels sont considérés comme de simples outils, et vous n'avez pas beaucoup de respect pour quelque chose qui n'est qu'un outil... Lorsqu'on se rend compte qu'un logiciel est plus qu'un simple outil, on commence à se dire qu'il faut y faire attention. Nous avons donc maintenant besoin de cette impulsion. Nous avons des vice-présidents pour la science ouverte dans les universités, mais nous n'avons pas de vice-président pour l'open source dans le monde universitaire. »

« Il existe de nombreux prix pour les logiciels libres en général, mais c'est la première fois que nous mettons réellement en place un prix pour les logiciels libres dans la recherche à l'échelle d'un ministère. L'objectif est de mettre l'accent sur l'importance des logiciels pour la recherche. C'est une façon de reconnaître les chercheurs qui ont fait un travail incroyable pendant très longtemps sans être reconnus à leur juste valeur dans le milieu universitaire. Le logiciel est très vaste. Ils sont utilisés dans tous les domaines. Bien sûr, nous avons des prix pour les logiciels dans d'autres endroits, mais nous en avons besoin dans le monde universitaire parce que nous devons construire le pilier logiciel de la science ouverte. »

Références

1. Harold Abelson, Gerald Jay Sussman, et Julie Sussman, *Structure and Interpretation of Computer Programs*, The MIT Press, Cambridge, 1985.

2. Len Shustek, « What Should We Collect to Preserve the History of Software? », *IEEE Annals of the History of Computing* 28, n° 4 (octobre 2006): 112-111, https://doi.org/10.1109/MAHC.2006.78.

3. EOSC Executive Board Working Group (WG) Architecture Task Force (TF) SIRS.

4. « Software Heritage », consulté le 24 mars 2022, https://www.softwareheritage.org/.

5. « HAL Science Ouverte », consulté le 16 mars 2022, https://hal.archives-ouvertes.fr/.

6. Software Heritage, « Paris Call: Software Source Code as Heritage for Sustainable Development », 2019, https://unesdoc.unesco.org/ark:/48223/pf0000366715locale=fr.

7. EOSC Executive Board Working Group (WG) Architecture Task Force (TF) SIRS, « Scholarly Infrastructures for Research Software ».
8. Unesco, « UNESCO Recommendation on Open Science », 2021, https://unesdoc.unesco.org/ark:/48223/pf0000379949.

9. Ministère de l'Enseignement supérieur, de la Recherche et de l'Innovation, « Deuxième Plan national pour la science ouverte », *Ouvrir la Science* (blog), 29 juin 2021, https://www.ouvrirlascience.fr/deuxième-plan-national-pour-la-science-ouverte.
# Le rôle des infrastructures pour les logiciels dans la science ouverte

Ulrike Lucke
Université de Potsdam

Je vous propose de commencer par nous plonger un peu plus profondément dans les enjeux soulevés par les logiciels de recherche, avant de voir comment une infras- structure appropriée pourrait nous aider. Un logiciel est une chose complexe, qui peut avoir différents aspects. Il peut s'agir d'un artefact que nous créons dans le cadre de nos recherches, d'un outil que nous utilisons dans le cadre de nos recherches, ou d'un sujet de recherche en soi.

La dernière de ces trois perspectives est l'informatique, mais arrêtons-nous d'abord sur les deux autres, qui peuvent concerner toutes les disciplines. Malheureusement, il n'existe pas de modèle commun à tous les logiciels de recherche. Ils sont aussi diversifiés que le sont les disciplines. D'après une analyse du ministère français de la Recherche sur le panorama des logiciels utilisés en recherche¹, il existe quelques outils quelques outils plutôt génériques largement utilisés (dominés par les logiciels de bureautique propriétaires), puis un large éventail d'autres logiciels différents. Certains sont plutôt des outils, c'est-à-dire des logiciels qui sont utilisés tels quels pour la recherche. Pour d'autres, les chercheurs sont également impliqués dans la production de ce logiciel dans le cadre de leur processus de recherche. Dans les deux cas, la maintenance durable de ces logiciels pose des problèmes particuliers.

Ces problèmes nous empêchent d'être efficaces dans l'immédiat. La disponibilité à long terme des logiciels de recherche est cruciale pour la reproductibilité des résultats de la recherche, un facteur clé de l'assurance qualité en recherche. Cependant, de nombreuses études ont révélé que cette reproductibilité est souvent entravée par le manque de disponibilité des logiciels utilisés.

Les résultats d'une étude menée par Daniel Nüst et d'autres en 2018 dans le domaine des géosciences² ont montré que même si les données sont disponibles, la reproductibilité des résultats globaux est faible, voire nulle. Tout au long du processus de recherche, depuis les données brutes jusqu'à l'environnement de calcul et les
résultats finaux, en passant par le prétraitement et à l'analyse de ces données, on
observe des fuites au niveau du code ou, en dernier lieu, de son exécution.

Christian Collberg et ses collègues avaient déjà identifié les raisons de cette déper-
dition en 2014 pour le domaine des systèmes informatiques³. Leurs conclusions sont
toujours plus ou moins valables aujourd'hui. Quand il est disponible (sachant que le
principal problème est que les logiciels ne sont le plus souvent pas disponibles, ni
dans un entrepôt ni via des échanges par mail), le code-source d'un logiciel échoue
tout simplement à être proposé sous la forme d'un programme exécutable, ou alors
ce programme n'est plus exécutable sur une nouvelle plateforme.

Par conséquent, on peut en conclure qu'il faudrait mettre davantage l'accent sur
la qualité du développement, de la publication et de la maintenance des logiciels.
Les bases méthodologiques de l'ingénierie logicielle gagneraient à cet égard à être
reprises. L'ingénierie logicielle ne saurait être résumée à un simple codage. Il s'agit
plutôt d'un processus de conception structuré, dont la nature même peut aider à sur-
monter ces problèmes de reproductibilité. L'ingénierie logicielle est une activité pro-
fessionnelle qui exige des efforts, une formation et des compétences considérables.
Il ne suffit pas d'écrire 100 000 lignes de code pour mériter de la reconnaissance,
mais c'est l'utilisabilité d'un logiciel par d'autres qui en fait un résultat à valoriser.

On pourrait faire valoir que de tels problèmes ne se posent pas lorsqu'on a recours
à des outils existants ; qu'il faudrait non pas développer nos propres logiciels, mais
utiliser ceux qui existent et nous reposer sur cette base. Par exemple, ma présentation pour ces journées OSEC a été conçue avec MS Office 2013 et je m'appuie sur
cette base, tout en sachant que cela peut entraîner des conflits avec d'autres outils.
Au sein de mon groupe de recherche, de nombreux développements pour des applications de réalité virtuelle sont faits dans Unity, version 2019 pour le moment, et ils
ne fonctionneront guère avec d'autres outils. Autre exemple : l'un des outils les mieux
classés dans la liste des outils du ministère français mentionnée précédemment est
MS Excel, encore un autre outil propriétaire qui peut présenter des obstacles à la
mise à disposition de nos recherches. Malheureusement, de nombreux groupes,
associations, groupes de travail ou task forces dans le domaine de la science ouverte
utilisent encore des outils propriétaires au lieu d'outils ouverts, parce que c'est tout
simplement beaucoup plus facile. Nous devons consacrer beaucoup plus d'efforts à
des outils open source hautement fonctionnels, confortables et interoperables, pour
faire changer cette situation.

Vous pourriez rétorquer qu'il faut stoker nos données sous forme de fichiers CSV
et, oui, en effet, cela aide, mais ce n'est pas suffisant. En fonction de la version du
logiciel que vous utilisez pour traiter vos données, pour les visualiser, les choses peuvent changer. Par exemple, selon le nombre de bits utilisés pour stocker les données dans votre ordinateur, les décimales peuvent être coupées ou arrondies vers le haut ou vers le bas à l'aide de différents algorithmes. C'est pourquoi les données sont toujours étroitement liées à la version très particulière du logiciel que vous avez utilisé pour les générer, les traiter et les visualiser. Il n'y a aucun moyen de séparer complètement les données des logiciels.

Pour aggraver encore les choses, un projet de recherche donné n'utilise pas qu'un seul logiciel ou outil. Nous utilisons plutôt des environnements informatiques très complexes, dont la plupart des composants sont invisibles. Parlons par exemple des systèmes d'exploitation. Je suppose que vous savez si vous travaillez sous Windows, Linux ou Mac, mais savez-vous quels pilotes, bibliothèques et codecs vous avez installés ? Savez-vous quel environnement d'exécution votre logiciel utilise ? En général, non, et pour être honnête, cela m'est égal. Cela devrait-il être rendu plus visible ? Si vous vouliez vraiment dessiner une représentation de tous les composants logiciels que vous utilisez dans votre environnement de recherche, cela ressemblerait à un édifice branlant. Je parie que quelque part, il y aurait ce tout petit composant sur lequel tout le reste est construit – et qui fait que tout s'écroule s'il plante.

Vous souvenez-vous en 2014 du bug dans le système de cryptage openSSL, que nous utilisons tous pour communiquer sur Internet, qui a provoqué une faille de sécurité appelée « Heartbleed⁴ » et qui a mis en danger nos données locales ? Vous souvenez-vous qu'en 2016, il y avait un bug dans un logiciel d'IRMf largement utilisé pour analyser la neuro-imagerie⁵ ? Pas à cause d'un souci de sécurité, mais parce que certaines zones du cerveau étaient déclarées comme actives, alors qu'en fait elles ne l'étaient pas. C'était un problème scientifique. Vous souvenez-vous en 2021, il y a quelques semaines seulement, du bogue dans log4j⁶ ? Vous pourriez vous dire qu'alimenter un journal, ce n'est pas si critique. Pourtant si, ça l'est, dès lors que ce logiciel ouvre une porte dérobée permettant à d'autres de pénétrer dans nos ordinateurs. De tels problèmes sont typiques des logiciels qui ne sont pas bien entretenus et cela met nos recherches en danger.

Mais assez de ces mauvaises nouvelles. Passons maintenant aux bonnes nouvelles. Tout d'abord, il existe une approche technique courante dans les centres de données pour aider à résoudre ces problèmes. Les logiciels, ainsi que les données qu'ils traitent et l'ensemble de l'environnement informatique qui les entoure, peuvent être placés dans des conteneurs, des boîtes techniques. Ces conteneurs peuvent être facilement migrés vers d'autres systèmes, ils peuvent facilement être mis à jour si de nouvelles versions des composants sont publiées, et ils peuvent être facilement
récupérés après une panne. C'est un progrès considérable. Vous vous souvenez peut-être de ces Jupyter Notebooks⁷. Avec eux, il vous suffit de rassembler des données, du code et de la documentation puis de cliquer sur « exécuter », et ce grâce à l'infras-structure standardisée qui se trouve en sous-couche de ce logiciel, permettant d'exécuter et de partager facilement des résultats de recherche, y compris un logiciel.

L'utilisation d'un tel conteneur permet non seulement de maintenir, mais aussi de publier et de réutiliser le logiciel. La publication s'accompagne d'une procédure de conservation, garantissant un certain niveau de qualité. En outre, l'exécution d'un logiciel au sein d'un tel bac à sable permet d'éviter que votre système ne soit endommagé.

En ce moment, au sein de la *German National Research Data Infrastructure*, mon collègue Michael Goedicke et moi-même préparons une telle solution pour l'informationique en Allemagne⁸. Vous pouvez comparer notre approche à l'infrastructure que nous utilisons pour l'électricité, l'eau, internet, etc. : il existe un réseau invisible de canalisations, de câbles et d'interrupteurs sous la surface de nos rues alors que nous utilisons simplement les prises de courant de nos murs. Il suffit de brancher un appareil et tout fonctionne, pour autant que nous disposions du bon adaptateur électrique lorsque nous sommes à l'étranger pour une conférence. Nous ne voyons pas toutes les canalisations, les câbles et les commutateurs. Nous ne voyons pas les nombreuses personnes qui s'en occupent. Nous payons simplement notre redevance mensuelle et tout fonctionne. Cette situation peut être comparée à l'infrastructure informatique utilisée pour les logiciels de recherche. Si vous disposez de serveurs puissants dotés d'une technologie de virtualisation et de conteneurs informatiques, votre logiciel fonctionne. S'il existe une couche supplémentaire pour gérer vos recettes – oui, comme en cuisine –, vous pouvez facilement mettre en place différentes combinaisons et configurations de logiciels dans ces conteneurs. Cela peut s'appliquer à tous les outils que nous avons déjà dans notre portefeuille de recherche, ainsi qu'à tous les logiciels de recherche que nous continuerons à développer.
<figure><img src="image_44.png" /><figcaption>Fig. 16 : Infrastructure numérique de recherche</figcaption></figure>

Source : Lucke, « The role of Infrastructure for Software in Open Science ». Support utilisé lors de la présentation (disponible sur le site web de la conférence)

Cela semble difficile, n'est-ce pas ? N'essayez pas de refaire ça chez vous. Laissez les data centers faire leur travail. Ce sont des professionnels de ce genre d'infras-structure. Nous-mêmes sommes des professionnels de la recherche. Il nous suffit de savoir comment mener nos recherches, pas comment maintenir une telle infrastructure conteneurisée. Cependant, nous devrions savoir comment utiliser cette infrastructure, comment déposer nos logiciels et données dans ces boîtes et les déployer, ou comment peut-être adapter ce que quelqu'un d'autre a déployé et l'utiliser pour nos propres recherches. Cela signifie que les chercheurs ont besoin de formations supplémentaires et d'entraînement pratique pour acquérir ces compétences numériques. Là encore, il y a de bonnes nouvelles. Il existe des exemples de réussite, comme une série de hackathons organisés par un de mes collègues⁹. Peer Trilcke est l'un des principaux chercheurs en humanités numériques. Il utilise des logiciels pour répondre à des questions de philologie par le biais de recherches principalement quantitatives. C'est pourquoi il enseigne également à ses étudiants comment procéder, comment installer un environnement informatique, comment concevoir un algorithme et comment répondre à des questions de recherche. Il le fait de manière très pratique, en utilisant des données textuelles, comme Drama Corpora, des données visuelles, comme les graffitis urbains, ou les données audio de Spotify – des données culturelles au sens large. Il crée une sorte de culture de la donnée à partir de cela, que les étudiants adorent et grâce à laquelle ils apprennent énormément.
Puisque les étudiants sont capables d'apprendre à travailler de cette manière, quel que soit leur domaine de recherche, les chercheurs devraient pouvoir l'apprendre aussi. Nous préparons actuellement une évaluation systématique des compétences que les étudiants ont acquises au cours des trois dernières années grâce à ces hackathons. Pour l'instant, nous avons créé un cours d'introduction transverse aux différents domaines d'étude de cette discipline, et un cours plus général est en préparation. J'espère qu'il sera disponible gratuitement en ligne pour d'autres domaines également, peut-être sous la forme de micro-justificatifs permettant d'y faire facilement référence. Ainsi, les futurs chercheurs pourront être formés à l'utilisation de ce type d'infrastructure pour leurs travaux ultérieurs.

Si vous étiez une bonne fée et que vous me demandiez ce que je souhaite, je mentionnerais les trois choses suivantes :

* Tout d'abord, reconnaître la production de logiciels de recherche comme un résultat de la recherche. Cela a une incidence sur le temps dont nous avons besoin pour générer du code de haute qualité sur un projet, qui nécessite à la fois une partie du financement et certaines compétences.

* Deuxièmement, reconnaître la mise à disposition des logiciels de recherche comme un effort précieux. Nous devons étendre l'évaluation, au-delà du nombre de publications et des métriques, aux données et logiciels ouverts, et nous devons en tenir compte, par exemple, dans nos procédures de nomination lorsque nous recrutons de nouveaux professeurs.

* Troisièmement, reconnaître que la qualité des logiciels de recherche est une question fondamentale. Cela signifie que nous devons faire transformer les pratiques actuelles de codage en véritable génie logiciel professionnel, et établir des infrastructures informatiques et des structures de soutien efficaces pour les logiciels de recherche.

Il s'agit de considérer le logiciel comme un outil clé de la recherche, je pense qu'il n'y a pas d'autre solution. Comme dit, les logiciels ont énormément besoin d'une infrastructure appropriée. La fée est-elle encore dans la pièce ? Peut-être encore trois souhaits.

* En quatrième lieu : augmenter la maturité et l'intégration des infrastructures et des outils actuels. Pour cela, nous devons identifier et promouvoir davantage les approches prometteuses qui existent déjà.

* Cinquièmement, adapter les instruments de financement à l'infrastructure numérique afin d'y inclure les coûts de développement et de maintenance, alors que les coûts humains prédominent actuellement.
* Enfin, sixièmement : établir une collaboration internationale en matière d'infrastructure pour les logiciels de recherche.

Il nous faut réunir tous les acteurs concernés pour soutenir leur travail. Cela ferait avancer la recherche de manière significative. Une dernière bonne nouvelle : nous ne partons pas de zéro. Comme nous l'avons déjà entendu, il existe de nombreuses initiatives au niveau international, européen et national, auxquelles participent de nombreuses personnes intelligentes et dévouées, avec de nombreuses grandes idées. Il nous suffit donc de nous rassembler et de coopérer, comme nous le faisons aujourd'hui.

Références

1. Le Béchec, Mariannig et al., *Pratiques et usages des outils numériques chez les chercheurs en France*, janvier 2022, https://www.ouvrirlascience.fr/state-of-open-science-practices-in-france-sosp-fr/ (consulté le 15 mai 2022).

2. Daniel Nüst et al., « Reproducible Research and GLScience: An Evaluation Using AGILE Conference Papers », PeerJ 6 (13 juillet 2018): e5072, https://doi.org/10.7717/peerj.5072.

3. Christian Collberg et Todd A. Proebsting, « Repeatability in Computer Systems Research », *Communications of the ACM* 59, n° 3 (25 février 2016): 62-69, https://doi.org/10.1145/2812803.

4. « Heartbleed Bug », consulté le 24 mars 2022, https://heartbleed.com/.

5. Bec Crew, « A Bug in fMRI Software Could Invalidate 15 Years of Brain Research », *ScienceAlert*, 6 juillet 2016, https://www.sciencealert.com/a-bug-in-fmri-software-could-invalidate-decades-of-brain-research-scientists-discover.

6. Bree Fowler, « Log4j Software Bug: What You Need to Know », CNET, 21 décembre 2021, https://www.cnet.com/news/privacy/log4j-software-bug-cisa-issues-emergency-directive-to-federal-agencies/.

7. « Project Jupyter », consulté le 24 mars 2022, https://jupyter.org.

8. National Research Data Infrastructure for and with Computer Science (NFDIxCS), https://nfdixcs.org/ (consulté le 15 mai 2022).

9. Dennis Mischke Sluyter-Gäthje Peer Trilcke and Henny, « Hackathons Als Kollektiv-Kreative Bildungsereignisse. Ein Konzept Zur Gestaltung Offener Lehrveranstaltungen in Den Digital Humanities », consulté le 24 mars 2022, https://proposals.dhd2022.de/264.html.
<figure><img src="image_45.png" /></figure>
# Science ouverte, édition et code

Melissa Harrison
EMBL-EBI

Je suis éditrice, et j'ai occupé des fonctions d'éditrice pendant la majeure partie de ma carrière, en travaillant notamment chez eLife. J'occupe maintenant chez EMBL-EBI un poste d'archivage en libre accès. Nous avons plus de 7,5 millions d'articles en texte intégral et de preprints, dont un sous-ensemble COVID-19 et quelques autres. Les perspectives que j'ai acquises dans ces deux différents rôles sont intéressantes. D'un point de vue d'éditeur en libre accès, un des problèmes que nous avons rencontrés chez eLife en essayant d'encourager des comportements responsables tels que l'utilisation de logiciels et leur bonne citation, est que, si vous vous efforcez de mener ces missions à bien, vous rajoutez une contrainte supplémentaire à vos auteurs. Ceux-ci nous ont répondu : « Comment citer du code ? » Nous avons constaté un problème récurrent, qui est que lorsque nous essayions de trouver le code dont les gens parlaient, nous n'avions à disposition que la citation d'un article de recherche original, ce qui n'est pas vraiment ce que nous cherchons. Nous avons besoin d'accéder au code source qui le sous-tend, afin de le promouvoir. Il ne s'agit pas forcément de publications de recherche, les logiciels ne rentrent pas dans le cadre des styles de citation habituels, et les éditeurs ne savent pas comment les étiqueter ou comment les traiter. C'est un problème sur lequel je me suis penchée.

De plus, comme dit, les logiciels ne sont pas statiques, ils ne se comportent donc pas comme une publication de recherche pour laquelle vous obtenez votre DOI, vous le publiez et c'est fini. Ce n'est pas non plus la même chose que des données. Toutes ces questions sont problématiques pour nous, éditeurs, qui essayons de gérer la citation du code. Une solution très populaire dans le monde de l'édition a été de faire des liens entre GitHub et Zenodo. Les auteurs de code peuvent très facilement archiver leur code sur Zenodo et obtenir un DOI. Les DOI sont au cœur de l'activité des éditeurs, qui comprennent de quoi il s'agit. Nous utilisons les DOI via Crossref pour les articles de journaux depuis très, très longtemps, ce sont des éléments faciles à reconnaître pour les éditeurs et dont le code est archivé quelque part, donc tout le monde est gagnant dans cette situation. Zenodo peut également renvoyer vers le site GitHub, de sorte que si des modifications sont apportées, il est possible d'aller voir ce qui s'y trouve.
Grâce au travail d'un spécialiste des données d'Europe PMC, nous avons sélectionné 7 000 documents XML aléatoires, et y avons trouvé 300 000 citations. Sur ce grand nombre, seules 10 renvoyaient vers Zenodo, que nous avons identifiées en utilisant le système DOI de Zenodo. Comme Roberto l'a dit plus tôt, il existe des archives dédiées aux logiciels, ce que n'est pas Zenodo. Sur ces 10 citations, trois renvoyaient à des jeux de données, une à un article de journal et les autres à des logiciels. Cependant, en regardant comment les éditeurs ont intitulé ces contenus lorsqu'ils ont structuré leurs citations au format XML, nous avons constaté qu'il n'y en avait qu'une seule qui était bien identifiée comme un logiciel, toutes les autres étaient un méli-mélo de choses différentes, ce qui est problématique si nous cherchons comment citer, attribuer et réutiliser des logiciels de façon convenable.

L'un des problèmes auxquels j'ai souvent réfléchi est que Zenodo n'est pas synonyme de dépôt de code, et qu'il n'est donc pas possible pour les éditeurs de dire : « Bon, d'accord, il y a un DOI Zenodo, identifiez-le comme du code », car ce n'est pas si simple. Zenodo contient beaucoup de choses différentes.

Les éditeurs connaissent parfaitement Crossref, qui est maintenu par des éditeurs. Ils obtiennent des DOI et utilisent les outils de Crossref pour valider des références, les vérifier et récupérer d'éventuelles métadonnées manquantes ou ajouter des DOI à leurs publications si les auteurs ne les ont pas fournies.

Mais c'est DataCite qui fournit des DOI à Zenodo, et beaucoup d'éditeurs n'utilisent pas les outils de DataCite pour vérifier leurs références. Par conséquent, si des DOI sont générés pour Zenodo, ils ne bénéficient souvent pas des étapes de validation supplémentaires qui permettent à l'éditeur de préciser s'il s'agit d'un code, de données ou autre.

Une solution autre que Zenodo est la solution Software Heritage, dont a parlé Roberto. C'est la voie qu'a empruntée eLife. L'équipe avait le pressentiment que les DOI n'étaient finalement que des constructions d'éditeurs, et donc pas nécessairement la meilleure voie à suivre pour référencer toutes les différentes variétés de logiciels. Software Heritage archive des contenus provenant d'un grand nombre de sources différentes. Il renvoie à des éléments spécifiques de code, il interroge et génère des mises à jour et indexe davantage de sources, mais un autre élément décisif pour eLife était qu'il n'est pas nécessaire de demander aux auteurs d'indexer, de créer le lien Zenodo et d'archiver leur code eux-mêmes. Nous pouvions le faire pour eux, ce qui a été fondamental pour nous car, comme vous le savez, ma première remarque a été : « Oh non, encore une autre chose qu'ils me demandent de faire. »
Nous avons estimé que nous ne voulions pas insister pour qu'ils fassent le travail supplémentaire. Nous allions le faire pour eux.

<figure><img src="image_46.png" /><figcaption>Fig. 17 : Citations de logiciels dans eLife au fil du temps</figcaption></figure>

Source : Harrison, «Open Science, Publications and Code». Support utilisé lors de la présentation (disponible sur le site web de la conférence)

En ce qui concerne l'expérience eLife, je suis vraiment fière des nombreuses évolu-
tions que nous avons lancées. En ce qui concerne les publications VoR (version of
record) publiées au fil du temps, eLife est une revue de taille modeste par rapport
à Europe PMC que j'ai rejoint maintenant, mais fin 2021, nous avions un total de
citations de logiciels égal au nombre de publications de VoR. Cela ne veut pas dire
que chaque article publié contenait une citation de logiciel – certains ont pu en avoir
deux ou trois et d'autres aucune – mais c'est très loin de notre situation de départ,
donc c'est vraiment formidable à voir. Cependant, cela demande du temps et des
efforts et eLife, qui est une organisation à but non lucratif, disposait des ressources
et du temps nécessaires pour se pencher sur la question. Nous avons mis en place
un contrôle qualité, des instructions et de la documentation. Nous avons formé notre
personnel et nos fournisseurs. Nous avons introduit des contrôles automatisés. Nous
avons écrit beaucoup de codes pour nous assurer que toutes nos productions étaient
bien découvrables, qu'il s'agisse de trouver un lien GitHub dans un article, de l'identi-
fier et d'en demander la référence à l'auteur, ou encore de valider et de vérifier toutes
les références logicielles, et l'équipe éditoriale, ainsi que l'équipe de production, ont fourni beaucoup d'efforts dès le début, ce qui était formidable.

Pour revenir à un point de vue plus large, en utilisant les compétences d'Europe PMC et les archives dont nous disposons, en utilisant les mêmes 7 000 documents XML sélectionnés au départ de manière aléatoire, nous avons trouvé que 15 d'entre eux étaient catégorisés comme des logiciels, et qu'ils provenaient uniquement d'eLife et de PeerJ, représentant une fraction minuscule des citations disponibles. Après cette découverte, mon collègue a restreint son analyse aux publications de eLife et PeerJ, ce qui a permis d'identifier 6 205 références de logiciels, 46 % des sources identifiées pour ces références n'étaient pas disponibles, puis un grand nombre venaient de GitHub, puis un autre ensemble d'une de ses variations. Il y avait ensuite une longue, longue queue de sources uniques.

Un de mes chevaux de bataille en tant qu'éditrice est JATS for Reuse¹, que je préside toujours. La plupart des éditeurs qui créent des ressources en texte intégral le font en XML et JATS, *Journal Article Tagging Suite*, est une norme que la plupart des gens utilisent. Comme un grand nombre d'éditeurs y a recours, elle est très complexe et il faut qu'elle soit suffisamment souple pour répondre aux besoins de tout le monde. JATS4R a donc été créé pour favoriser cette réutilisation. Le groupe initial qui l'a développé était composé d'éditeurs en libre accès, qui travaillaient à l'interopérabilité de leurs contenus et à comment en extraire de l'information.

Un groupe de travail sur la citation des logiciels a travaillé de 2017 à 2020, avant de publier une recommandation en novembre 2021². Notre groupe est encore relativement jeune, mais je me rappelle que lorsque nous l'avons créé, beaucoup d'éditeurs disaient qu'ils ne savaient pas comment citer les logiciels, qu'il n'y avait pas de règle ou de terme à utiliser. eLife en utilisait un inventé de toutes pièces puis généralisé, mais nous avons réalisé que cela posait problème à beaucoup d'éditeurs. Un des éléments clés de notre recommandation est donc de laisser aux éditeurs la possibilité de reconnaître qu'il est possible de faire référence à un logiciel, et de l'indiquer dans le XML afin que cela soit clair pour toute personne qui réutilise cette référence ou qui a besoin de rechercher des références de ce type.

Un autre objectif est de faire en sorte que cette recommandation soit aussi légère que possible, car plus on ajoute de complexité à ces choses, plus il est difficile pour les gens de s'en emparer et de se lancer. eLife a fait beaucoup d'efforts pour générer des références structurées très complètes, mais c'est difficile.
Nous voulions également des identifiants pérennes, largement connus et attribuables à tout matériau correctement archivé. Malheureusement, GitHub ne produit pas d'éléments de ce genre, mais Zenodo et Software Heritage le font. Dans le sous-ensemble d'articles d'eLife et de PeerJ que nous avons examinés, nous avons constaté que 202 d'entre eux avaient un identifiant pérenne, tous des DOI. À défaut, la meilleure solution consiste à intégrer dans la référence un lien externe, même si nous en connaissons tous les limites. Il est bien mieux d'intégrer des identifiants-systèmes dans les références, mais à défaut, des liens externes fonctionnent, et nous avons identifié dans notre sous-ensemble 2 524 entrées avec des liens externes. Cela signifie malheureusement que 3 834 autres ne contenaient ni identifiant pérenne ni lien externe, ce qui les rend beaucoup plus difficiles à identifier, interroger et réutiliser du point de vue de leurs références.

Je conclurai en reconnaissant que la route est encore longue, nous le savons, mais de nombreux progrès ont déjà été réalisés. Les logiciels gagnent du terrain. Le fait qu'il s'agisse de l'un des piliers de la conférence d'aujourd'hui montre à quel point ils sont importants et à quel point les gens pensent qu'ils devraient l'être. Dans le monde de l'édition, le fait qu'autant de personnes aient contribué au sein du groupe de travail JATS4R à la rédaction de notre recommandation et à sa mise en œuvre est remarquable.

L'un des enjeux qui persiste est la difficulté à choisir quelle voie prendre. Par exemple, chez eLife, nous avons choisi la voie du patrimoine logiciel. Il y a aussi Zenodo. Je suis sûre qu'il y en aura d'autres et qu'il y aura différentes manières de travailler. Cette diversité peut poser problème en attendant d'atteindre ce point de basculement où tout le monde se retrouvera sur la même voie, mais pour l'instant l'avenir est incertain.

Nous sommes nombreux à travailler en ce sens. Il n'y a pas que les éditeurs, les auteurs ou les chercheurs. Le paysage actuel est très mouvant, et un enjeu majeur à l'heure actuelle est de former les gens, des éditeurs aux chercheurs, car tout le monde a besoin d'être formé. Nous nous en sommes rendu compte en parlant à nos fournisseurs, en leur expliquant des notions liées à la production, à l'édition et au retour d'information, ainsi que la mise à jour de l'outillage. Car d'un point de vue d'éditeur, l'utilisation de DataCite et l'automatisation des vérifications aideraient grandement à résoudre nos problèmes.
Pour aller plus loin

« La chose la plus difficile à surmonter pour améliorer la citation des logiciels a probablement été la résistance des auteurs, lorsqu'on a essayé de leur expliquer combien il est important d'accéder au code source et de le citer plutôt que de citer un article qui y est associé. »

« Les logiciels sont très différents des données, il y a différentes infrastructures impli-
quées et c'est un environnement différent, mais je dirais définitivement que j'ai beau-
coup appris de la mise en œuvre des citations de données et de leur application aux
logiciels, même si c'est un type de contenu différent. »

Références

1. « JATS4R », JATS4R, consulté le 24 mars 2022, https://jats4r.org/.

2. JATS4R sofwtare citation subgroup, « Software Citations », JATS4R, novembre 2021, https://jats4r.org/software-citations/.
# Politiques de soutien aux logiciels libres et à la science ouverte

Sayeed Choudhury
Johns Hopkins University

Le logiciel est l'un des piliers de la science ouverte. Les universités produisent essentiellement trois de ces piliers : des articles, des données et des logiciels. Ils sont liés entre eux et, à bien des égards, ces piliers et leurs interconnexions participent de ce que Roberto a décrit comme un écosystème scientifique. Sous plusieurs aspects, ils sont au cœur des projets que les universités mènent dans le cadre de leurs recherches. Ils sont généralement financés par des subventions et d'autres types de financement externe, et concernent principalement des choses qui se passent entre les murs des universités. Or à un moment donné, si vous souhaitez que l'impact de la recherche et de l'éducation dépasse les murs de l'université, vous devez les traduire. Il est utile de publier des articles et d'accumuler des données. Il est également extrêmement utile de partager les logiciels.

Au cours des deux dernières années, nous avons tous fait l'expérience de la COVID-19, ainsi que des nombreuses discussions sur la façon dont la science ouverte a conduit aux vaccins qui nous ont permis d'y faire face. Je dirais que l'élément le plus important n'était pas le partage d'articles ou même de données, mais plutôt le logiciel, le code que les gens utilisaient pour analyser les données associées aux vaccins que nous avons finalement développés.

Les Bureaux de programmes open source (Open Source Programs Offices, OSPO) sont des organisations académiques pouvant apporter leur soutien à ces missions de traduction. Nous avons créé une unité de ce type au sein de l'université Johns Hopkins¹ pour aider nos chercheurs à transposer leurs activités de recherche et d'éducation en dehors des murs de l'université. L'une des façons dont nous avons fait progresser le travail de l'OSPO est ce que vous avez entendu de la part des pré-cédents intervenants, cette déclaration ou affirmation que le logiciel est un objet de recherche primaire. Si vous demandez à des gens au sein d'une université, qu'il s'agisse de chercheurs, d'administrateurs ou même d'étudiants, si les logiciels libres les intéressent, vous obtiendrez des réponses différentes, mais si vous leur demandez s'ils s'intéressent à la recherche, chacun d'entre eux vous répondra oui, bien sûr. Par conséquent, pouvoir affirmer que le logiciel libre intervient en soutien à la
recherche, qu'il est un outil, mais aussi un objet de recherche comme nous l'avons entendu, a été incroyablement important pour faire avancer le travail de notre OSPO au sein de l'université Johns Hopkins.

Nous avons également fait valoir, comme vous l'avez entendu plus tôt aujourd'hui, que le logiciel est en fait plus utile pour comprendre quelles données sont produites que les articles qui citent ces données. La citation ou la connexion entre un article et un jeu de données est souvent une sorte de lien mécanique direct, mais la connexion entre données et logiciels est beaucoup plus riche. Si vous regardez un logiciel, vous pouvez en fait en comprendre beaucoup plus sur les données utilisées et sur la façon dont elles sont analysées. Je vais prendre un exemple spécifique sur ce sujet.

Nous avons créé à Johns Hopkins un bureau des programmes open source, ou OSPO, mais c'est quelque chose qui est aussi utilisé par des entreprises du secteur privé, des entreprises high-tech, mais aussi des entreprises comme American Airlines ou Walmart pour gérer leurs logiciels open source. Bien qu'il y ait des éléments communs entre l'OSPO d'une entreprise du secteur privé et celui d'une université, l'OSPO de l'université fait également des choses uniques, fondamentales dans un contexte de recherche, d'éducation et de traduction. Nous contribuons à un grand nombre de bonnes pratiques décrites dans les exposés précédents, qui ont trait à des éléments tels que la bonne façon de concevoir un logiciel, les licences à choisir, les risques à prendre en compte dans ces choix et la façon dont travailler avec les éditeurs, et même directement avec la société en général. L'OSPO s'appuie donc sur ce qui se passe dans le secteur privé, mais il l'étend et le développe dans le contexte de l'université.

Je suis également heureux de constater que si Johns Hopkins a créé le premier OSPO universitaire aux États-Unis, il en existe désormais au moins trois autres à l'université de Californie, Santa Cruz, à l'Institut de technologie de Rochester et à l'université du Vermont. Je crois savoir que d'autres universités créeront des OSPO, de sorte que nous nous voyons bien constituer un réseau de ces organisations.

Johns Hopkins participe à un projet appelé *Observational Health Data Sciences and Informatics*, ou projet OHDSI². Notre collègue Paul Nagy, qui est chercheur dans notre école de médecine, participe à ce projet. Il m'a contacté après avoir entendu parler de notre OSPO en disant qu'ils avaient besoin d'aide. Il m'a expliqué que les données médicales ou de santé sont très difficiles à partager en dehors d'une équipe de recherche. Cela nécessite généralement d'établir des accords juridiques très complexes, qui doivent être approuvés par toutes les parties qui le signent, ce qui peut prendre beaucoup de temps. À la place, le groupe OHDSI a créé des logiciels libres
et les a mis à disposition. En partageant ces logiciels, ils ont appris énormément de choses sur les types de données que chacun d'entre eux utilisait et sur les types d'analyses qu'ils effectuaient sur ces données. Cela nous ramène à ce que j'ai dit plus tôt, à savoir que les logiciels ont un lien plus riche avec les données, comme nous l'avons également entendu chez les intervenants précédents. Au bout du compte, l'OHDSI s'est retrouvé avec un grand nombre de logiciels libres qu'il avait du mal à gérer. Il s'est alors adressé à l'OSPO pour lui demander son aide, et nous avons ainsi pu fournir le soutien technique, managérial et infrastructurel nécessaire à la bonne gestion de ces logiciels.

Je suis tout à fait d'accord pour dire que les chercheurs doivent se renseigner sur l'infrastructure. Ils doivent se renseigner sur les problèmes qu'ils peuvent rencontrer. Leur sensibilisation est très importante. Cependant, il me semble que ce n'est pas à eux de devoir soutenir une infrastructure ou l'entretenir. Roberto a affirmé précédemment que des subventions ne devraient pas être utilisées pour des dépenses opérationnelles. Je ne pourrais pas être plus d'accord avec lui. L'OSPO est une unité qui contribue à la formation, à la sensibilisation, mais qui, en fin de compte, ne fait que soutenir une équipe comme l'OHDSI. Ce que j'ai entendu clairement de la part de nos chercheurs, c'est qu'ils ne veulent pas devenir des experts des logiciels libres, ils veulent juste apprendre à les utiliser et ensuite, laisser des experts se charger de leur maintenance et de leur support. Dans un certain sens, l'OSPO est donc un centre d'excellence, un centre de connaissances ou un centre d'information.

Dans le domaine pédagogique, au cours du dernier semestre 2021, nous avons organisé un cours à Johns Hopkins intitulé « *Semesters of Code* ». Ce cours était donné par Stephen Walli, un cadre de Microsoft ayant plus de 40 ans d'expérience dans le domaine du génie logiciel. Selon lui, même si les diplômés d'universités comme Johns Hopkins ont de très bonnes compétences, les entreprises se rendent compte qu'il leur faut entre trois et six mois d'adaptation avant de comprendre comment travailler au sein d'un projet open source, comment travailler en équipe. L'idée est donc que si nous pouvons commencer ce processus éducatif le plus tôt possible dans leur carrière universitaire, ils seront mieux préparés à travailler dans des entreprises comme Microsoft. Plus généralement, nous reconnaissons l'énorme impact et la valeur qu'ils peuvent tirer d'un tel apprentissage, qu'ils travaillent pour une entreprise, deviennent chercheurs ou travaillent dans une organisation à but non lucratif.

Le logiciel open source était l'angle d'approche retenu pour évoquer les pratiques d'ingénierie logicielle et, en plus des cours, pendant lesquels Stephen couvrait des sujets qui n'étaient pas nécessairement liés à l'ingénierie, comme des questions juridiques, des questions économiques, ou l'histoire de l'open source, chaque étudiant
travaillait sur un projet open source du monde réel, dont les contributeurs et les
développeurs étaient leurs mentors. Les étudiants ont travaillé sur ces projets en
entretenant une relation directe avec un mentor pour les guider à travers le projet, les
aider à se former dessus, puis les accompagner dans la réalisation de missions per-
sonnelles. Nous avons reçu leurs évaluations et leurs retours il y a quelques semaines,
et je suis heureux de constater que les étudiants ont beaucoup apprécié. L'un d'entre
eux a dû abandonner le cours parce qu'il était en train de passer un diplôme et qu'il
ne pouvait pas intégrer ce cours à sa charge de travail, mais il a continué à travailler
sur le projet. Un autre étudiant n'a pas terminé le travail qu'il avait décidé de faire,
mais il s'est demandé s'il pouvait le faire seul et a continué à travailler avec le mentor.
Les élèves ont donc vraiment apprécié cette opportunité de se concentrer sur des
projets du monde réel.

L'un de ces projets du monde réel s'appelle Lutece³, il s'agit d'une plateforme de
services numériques open source de la ville de Paris. Elle est utilisée depuis de nom-
breuses années pour fournir des services aux citoyens de Paris, et les étudiants de
Johns Hopkins ont travaillé sur le code de Lutece et y ont contribué. Notre OSPO
a repris ces contributions et les a retravaillées, mises à jour puis réintégrées dans
Lutece, que nous utilisons actuellement dans un centre communautaire de l'ouest de
Baltimore, le St Francis Neighbourhood Center. Vous avez donc une plateforme logi-
cielle développée à Paris, sur laquelle travaillent des étudiants et des ingénieurs logi-
ciel de Johns Hopkins et qui est utilisée dans un centre communautaire de l'ouest de
Baltimore. Je mentionne ceci pour souligner que si nous avions dû signer un accord
juridique pour que Paris, Johns Hopkins et ce centre communautaire travaillent
ensemble, cela aurait pris beaucoup de temps. Au lieu de cela, la licence open source
de Lutece est l'accord juridique en vertu duquel nous avons effectué notre travail.

Un autre point que je souhaite aborder à propos de l'open source, en particulier en
ce qui concerne son impact en dehors des universités, est qu'il s'agit d'un moyen
beaucoup plus facile de créer des partenariats. Il n'est pas nécessaire d'obtenir des
subventions. Vous n'avez pas besoin de passer des accords juridiques. La licence
open source elle-même est le moyen grâce auquel vous pouvez mener des travaux
avec d'autres partenaires.

J'ai mentionné qu'il y a de nombreuses universités aux États-Unis qui sont en train
de créer ce type d'OSPO. Il existe un réseau appelé OSPO++ qui a été créé comme
une communauté et un réseau de ces OSPO⁴. Il ne concerne pas seulement les États-
Unis. Nous avons des participants d'Europe et d'autres parties du monde qui se réu-
nissent pour discuter de la manière dont les OSPO peuvent continuer à apporter leur
soutien à différents types d'activités au sein des universités, et à augmenter l'impact
de la recherche au-delà du monde académique.

Enfin, OSPO++ a récemment travaillé sur un guide des meilleures pratiques par le biais des Académies nationales des sciences aux États-Unis. Ces NAS, comme on les appelle, ont récemment mis en place un comité qui s'est penché sur la science ouverte et a produit, dans le cadre de son rapport final, un guide d'introduction aux logiciels libres⁵. L'OSPO++ a réuni des représentants d'universités, d'entreprises et d'organisations gouvernementales et non gouvernementales, dont l'Open Forum Europe, un groupe de réflexion qui a travaillé en étroite collaboration avec la Commission européenne, afin de mettre à jour et de créer cette introduction aux logiciels libres. Une recommandation politique importante faite par ce rapport des NAS converge avec une recommandation faite au sein de l'Union européenne pour créer 20 de ces OSPO, à la fois au sein des universités et de gouvernements, et pour que ces OSPO travaillent ensemble de manière coordonnée. L'objectif est que les États-Unis créent un réseau d'OSPO, puis que l'Europe et d'autres parties du monde créent aussi des OSPO, afin que nous puissions commencer à coorderner cette activité et à travailler vers des politiques plus communes et de meilleures pratiques, ainsi qu'à aider nos chercheurs à gérer leurs logiciels libres.

Pour aller plus loin

« Il y a un mouvement croissant très important autour de l'éthique dans les données. Il en va de même pour les logiciels. Nous parlons parfois des préjugés qui sont intégrés dans les données ou dans les outils ou algorithmes utilisés pour traiter ces données par le biais de logiciels. Il y a absolument une composante éthique à travailler sur un logiciel, même s'il est open source, mais l'un des avantages des logiciels open source est qu'ils sont transparents, ce qui nous permet de mieux voir ce qui est réellement fait en termes d'analyse des données. »
Références

1. « Open Source Programs Office (OSPO) – Digital Research and Curation Center », Johns Hopkins Sheridan Libraries (blog), consulté le 24 mars 2022, https://drcc.library.jhu.edu/open-source-programs-office/.

2. « OHDSI – Observational Health Data Sciences and Informatics », consulté le 24 mars 2022, https://www.ohdsi.org/.

3. « Lutece Framework - Home », consulté le 24 mars 2022, https://lutece.paris.fr/lutece/.

4. « OSPO++ », OSPO++, consulté le 24 mars 2022, https://ospoplusplus.com/.

5. « Good Practices Primer - Code and Software », 3 décembre 2021, https://doi.org/10.17605/OSF.IO/T4BAW.
# Cérémonie de remise des prix de la science ouverte

Claire Giry
Directrice générale de la Recherche et de l'Innovation, ministère de l'Enseignement supérieur, de la Recherche et de l'Innovation

Daniel Le Berre
Université d'Artois

**Claire Giry** : Notre ambition pour la science ouverte est de vraiment ouvrir l'ensemble du processus de recherche : les publications, ce qui se fait depuis un petit peu plus longtemps que le reste, les données, et les codes sources. Notre souhaitons ainsi contribuer à une science plus cumulative, plus robuste, plus reproductible. Chaque année, nous mesurons les résultats de cette ouverture, à l'aide d'un Baromètre de la science ouverte permettant de prendre la mesure du chemin parcouru depuis le 4 juillet 2018, date à laquelle nous avons lancé notre Plan national pour la science ouverte. Nous venons de présenter les résultats de ce baromètre 2021, et nous évauons aujourd'hui que 62 % des 166 000 publications savantes françaises publiées en 2020 étaient en accès ouvert en décembre 2021. C'est une progression de 10 points en un an : nous sommes très satisfaits de voir que la communauté savante suit le mouvement et que les choses avancent. Notre ambition est d'atteindre à terme 100 % des publications en accès libre. Nous nous en approchons progressivement, mais le partage des données reste un défi pour garantir la reproductibilité des résultats de la recherche, réduire les efforts à placer dans la reproduction de données et favoriser les nouvelles innovations. L'objectif de la science ouverte est de rendre facilement accessibles tous les résultats, méthodes, codes sources et logiciels. C'est la raison pour laquelle nous allons ultérieurement enrichir notre Baromètre de la science ouverte, avec des indicateurs en matière d'ouverture des données et des codes logiciels.

L'Appel de Paris qui nous réunit pendant ces deux journées de conférence européenne ambitionne de reconnaître toutes les formes de production de la recherche de manière à engager durablement les équipes de recherche dans des pratiques actives de partage, d'ouverture et de collaboration. Avec le deuxième Plan national pour la science ouverte annoncé en juillet 2021, nous avons voulu reconnaître la diversité des contributions à la science ouverte et la diversité de ses formes. Notre ministère a pris dans ce deuxième plan l'engagement de créer et décerner
chaque année trois prix de la science ouverte pour récompenser des équipes, des enseignants-chercheurs, des chercheurs, mais aussi tous les contributeurs impliqués dans la recherche ou qui sont en soutien à la recherche, et qui mènent un travail exemplaire en matière de science ouverte. Les trois familles de prix que nous allons décerner sont le Prix science ouverte du logiciel libre, le Prix science ouverte des données de la recherche et le Prix science ouverte de la thèse. L'appel à candidatures pour le Prix science ouverte des données de la recherche est en cours, nous remettrons ce prix d'ici l'été 2022. La première édition du Prix science ouverte de la thèse aura lieu en 2023. Nous pouvons profiter de ces journées européennes pour honorer les lauréats de cette première édition de la remise des prix science ouverte du logiciel libre de recherche.

Le logiciel libre est un pilier de la science ouverte. Il remonte au début des années 1980, bien avant que l'on parle de science ouverte, il a donc un côté très pionnier. Le logiciel de recherche est un outil qui participe du processus de recherche, du traitement des données et de la création de connaissances, mais il est aussi en soi un objet d'étude et un résultat de recherche, il est donc très complexe. À travers ce prix, nous souhaitons récompenser des logiciels libres de recherche qui sont utiles à de larges communautés, récompenser des équipes qui depuis des années ont conçu ces logiciels en les rendant accessibles à tous, en les documentant pour qu'ils soient réutilisables, en créant et en animant des communautés de contributeurs pour favoriser des développements plus collaboratifs, plus innovants, et aller toujours plus loin. Nous sommes très heureux du succès de cette première édition, avec 129 logiciels candidats issus de tous les domaines de la recherche. Le jury a souligné la très grande qualité des logiciels libres candidats à ce prix. Un premier panorama s'ouvre à nous et nous montre vraiment l'engagement de la recherche française dans la production de logiciels libres, la richesse de cette production dans différents domaines d'application, et ce depuis déjà une quinzaine d'années. Le format de la cérémonie d'aujourd'hui ne nous permet pas de remettre aux lauréats le trophée de leur prix Science ouverte, mais nous le lui remettrons lorsque le contexte sera plus favorable.

**Daniel Le Berre** : 129 candidats, 4 prix à la fin, comment faire ? Cela a été très difficile pour le jury. Nous avons 3 catégories de prix, que l'on peut voir comme 3 dimensions, plus le prix du jury. Nous étions un peu frustrés, car idéalement nous aurions voulu en attribuer 129, mais ce n'était pas possible, alors nous avons dû trouver des critères. Le premier de ces critères est la reconnaissance scientifique, la reconnaissance des pairs envers la partie scientifique et technique, car c'est ce qui est important dans la science. Elle peut être mesurée par la citation, comme cela a été dit tout au long de cette journée, ou par le fait que ces logiciels soient utilisés dans la société. Dans certains domaines scientifiques, il arrive que seuls les spécialistes,
les personnes à l'origine de la création d'un logiciel puissent le modifier, mais ensuite beaucoup de personnes peuvent l'utiliser. Par ailleurs, dans certaines communautés, on peut avoir beaucoup plus de contributeurs que dans d'autres, ce qui doit être pris en compte si on veut faire des comparaisons. Enfin, le point faible des logiciels libres, c'est généralement la documentation. C'est d'autant plus vrai pour les logiciels libres de recherche, qui sont des preuves de concept que l'on met à disposition. Quand ils commencent enfin à être utilisés, si on n'a pas fait les choses bien dès le départ, on a des problèmes après... Il fallait donc prendre aussi cet aspect-là en considération, donc nous avons créé une catégorie « Documentation associée au logiciel ». Si certains logiciels doivent être utilisés pendant des dizaines d'années, il faut vraiment que la documentation soit importante, à la fois pour les utilisateurs mais aussi pour les développeurs et futurs développeurs.

Il a été compliqué de trouver des lauréats. Nous avions une telle diversité de profils que nous avons des lauréats qui sont les meilleurs sur la dimension que nous essayions d'étudier, mais aussi des logiciels remarquables. Les *accessits* ne sont pas remis aux deuxièmes, mais à tous les logiciels remarquables que le jury souhaitait mettre en avant.

# Palmarès des prix science ouverte du logiciel libre de la recherche

## Catégorie Scientifique et technique

- Lauréat : The Coq proof assistant (https://coq.inria.fr/)

- Accessit : Coriolis VLSI CAD Tools (http://coriolis.lip6.fr/)

## Catégorie Communauté

- Lauréat : Scikit-learn (https://scikit-learn.org/)

- Accessits : Vidjil (https://www.vidjil.org/) et WebObs (https://ipgp.github.io/webobs/)

## Catégorie Documentation

- Lauréat : Faust (https://faust.grame.fr/)
Accessit : OpenViBE (http://openvibe.inria.fr/)

## Prix du jury

Lauréat : Gammapy (https://gammapy.org/)

Accessits : GAMA (https://gama-platform.org/) et SPPAS (http://www.sppas.org/)
Table des matières

<table><tr><td><strong>Ouverture de la conférence</strong></td><td><strong>9</strong></td></tr><tr><td>Premier discours inaugural</td><td>11</td></tr><tr><td>Deuxième discours inaugural</td><td>15</td></tr><tr><td>Troisième discours inaugural</td><td>19</td></tr><tr><td>Quatrième discours inaugural</td><td>23</td></tr><tr><td>Cinquième discours inaugural</td><td>27</td></tr></table>

<table><tr><td><strong>Transparence des recherches en santé</strong></td><td><strong>31</strong></td></tr><tr><td>Transparence des recherches en santé</td><td>33</td></tr><tr><td>Comment la psychologie aborde la science ouverte.</td><td>41</td></tr><tr><td>Biais de publication et de reporting : un long chemin vers la science ouverte</td><td>49</td></tr><tr><td>Conférence conclusive : Ouvrir et transformer la recherche biomédicale</td><td>59</td></tr></table>

<table><tr><td><strong>Avenir de l'édition scientifique</strong></td><td><strong>67</strong></td></tr><tr><td>L'édition scientifique et la science ouverte – Où en sommes-nous ?</td><td>69</td></tr><tr><td>Nouvelles formes de publication. Pourquoi ? Comment ? Jusqu'où ?</td><td>81</td></tr><tr><td>L'édition scientifique et l'Amérique latine</td><td>89</td></tr><tr><td>Un plan d'action pour l'édition Diamant</td><td>97</td></tr></table>

<table><tr><td><strong>Évaluation de la recherche – Première session</strong></td><td><strong>103</strong></td></tr><tr><td>Les intersections entre DORA, science ouverte et équité</td><td>105</td></tr><tr><td>La science ouverte n'a pas besoin de martyrs</td><td>113</td></tr><tr><td>De quelle manière les jeunes chercheurs sont-ils précurseurs du changement ?</td><td>121</td></tr></table>

<table><tr><td><strong>Évaluation de la recherche – Deuxième session</strong></td><td><strong>127</strong></td></tr><tr><td>Science ouverte et évaluation académique dans un monde pluriel</td><td>129</td></tr><tr><td>Science ouverte et évaluation de la recherche</td><td>139</td></tr><tr><td>Faire de la place pour les talents de chacun</td><td>145</td></tr><tr><td>Science ouverte, évaluation de la recherche et SHS</td><td>151</td></tr><tr><td>Table ronde : Évaluation de la recherche</td><td>159</td></tr></table>

<table><tr><td><strong>Le pilier logiciel de la science ouverte</strong></td><td><strong>181</strong></td></tr><tr><td>Construire le pilier logiciel de la science ouverte</td><td>183</td></tr><tr><td>Le rôle des infrastructures pour les logiciels dans la science ouverte</td><td>193</td></tr><tr><td>Science ouverte, édition et code</td><td>201</td></tr><tr><td>Politiques de soutien aux logiciels libres et à la science ouverte</td><td>207</td></tr><tr><td>Cérémonie de remise des prix de la science ouverte</td><td>213</td></tr></table>
Réalisé sur les presses de l'imprimerie Ciaco
en impression à la demande
depuis le mois de septembre 2022
à Louvain-la-Neuve, Belgique
N° d'imprimeur : 89470