En marge des mesures du plan national de la science ouverte

Support de la présentation faite lors du séminaire #FLOSS_ESR du 3 février 2022 organisé par le Comité pour la science ouverte et le pôle logiciels libres.

Voir https://communs.numerique.gouv.fr/rencontres/.

Le support est publié sous licence Creative Commons BY 4.0.

Transcript

1. En marge des mesures du plan national de la science ouverte 3 février 2022 - séminaire FLOSS_ESR Comité pour la science ouverte Pôle logiciels libres d’Etalab
2. Enjeux autour des codes sources et des logiciels libres
3. C’est déjà parti ! • Établir une liaison pérenne entre le Comité pour la science ouverte et la mission logiciels libres de la Direction interministérielle du numérique (DINUM). • Créer un prix du logiciel libre pour la recherche qui récompense les équipes et projets exemplaires dans le domaine. • Créer un collège des codes sources et des logiciels au sein du Comité pour la science ouverte. • Établir une liaison avec les acteurs nationaux et internationaux, en particulier le groupe de travail « logiciels » de l’EOSC, le groupe de travail FAIR for Research Software commun à la RDA, à FORCE11 et à la Research Software Alliance ReSA. • Soutenir Software Heritage et recommander son adoption pour l’archivage et le référencement des codes sources.
4. Science ouverte : mobiliser à tous les étages (1/2) • Dans le cadre du soutien public aux revues et actes de conférences, recommander l’adoption d’une politique de logiciels libres associés aux articles, le développement d’articles sur les logiciels et l’expérimentation d’approches qui lient articles, données et codes. • Développer le lien entre données et logiciels grâce au réseau des administrateurs des données, des algorithmes et des codes sources dans les établissements.
5. Science ouverte : mobiliser à tous les étages (2/2) Le mouvement de la science ouverte a sensibilisé aux enjeux de reproductibilité, mais… • Clarifier des concepts clefs : logiciels, données, publications, domaine d’application pertinent (ou non) pour les principes FAIR, etc. • Reconnaître la complexité de l’objet “logiciel de recherche” (finalités, maturité, mode de développement et de financement, de réutilisation) et la nécessité d’une approche fine pour l’évaluation et la valorisation de ces objets. • Concevoir des incitations pour les chercheurs • Solliciter une implication plus forte des institutions • Développer des formations et de l’accompagnement sur les “bonnes pratiques” (dev, outils, édition, etc.) • Penser à des stratégies de pérennisation des efforts investis par les acteurs de la recherche dans la publication des codes sources. • La publication des codes sources de recherche doit pouvoir s’articuler avec l’écosystème existant de l’édition et des données.
6. Science ouverte : construire les bases (1/2) • Développer une bonne articulation entre les forges logicielles, les archives ouvertes de publications, les entrepôts de données et le secteur de l’édition scientifique. • Proposer la standardisation du Software Heritage Identifier (SWHID), qui complètera les DOI pour les logiciels.
7. Science ouverte : construire les bases (2/2) • Quel sont les liens entre un projet logiciel, les dépôts de code source sur lesquels il repose, les publications qui l’inspirent voire le déterminent, les versions sur lesquelles se sont appuyés d’autres publications ? • Comment citer un “logiciel” dans une publication de façon à tenir compte de tous ces liens ? Par exemple, il faut distinguer l’identification d’un projet (“Octave”) et celle d’un artefact logiciel (telle version utilisée pour une expérience). • En quoi la reproductibilité dépend-elle à la fois de données, de codes sources, du recours à des logiciels libre, ainsi que du lien entre ces ressources ? • Quelles bonnes pratiques de développement, de diffusion et d’archivage des codes sources sont nécessaires à la reproductibilité des résultats scientifiques?
8. Archivage, référencement, catalogage (1/2) • Soutenir Software Heritage et recommander son adoption pour l’archivage et le référencement des codes sources. • Construire un catalogue des logiciels issus de la recherche en utilisant un schéma de métadonnées normalisé et partagé entre tous les acteurs de l’enseignement supérieur, de la recherche et de l’innovation.
9. Archivage, référencement, catalogage (2/2) • « Cela va des projets individuels non financés aux projets ANR ou européens avec une large visibilité… » • Quels codes sources diffuser? Quels formats? Quelles licences? Dans quelles finalités? • Quels processus de vérification et de modération pour le dépôt et l’archivage ? • Comment tenir compte de la complexité des projets : le code source contient des algorithmes, mais le logiciel peut contenir des données, un environnement, une documentation et peut plus largement faire référence à une communauté. • Comment tenir compte de la diversité des contributions à un code source ? • Comment valoriser différemment les codes sources “ad hoc” et les projets communautaires? • Comment assurer la complémentarité entre plusieurs outils (HAL, SWH, les revues, etc.) ? • Faut-il proposer un catalogue ESR des logiciels de la recherche ? • Faut-il publier des métadonnées de projets dont les codes sources ne sont pas publics ?
10. Suivre et encourager (1/2) • Suivre dans le temps la production de codes et logiciels de la recherche française pour en identifier les dynamiques, l’ouverture et les impacts grâce au baromètre de la science ouverte. • Mieux valoriser les productions logicielles dans la carrière des chercheurs, des personnels d’accompagnement à la recherche et dans l’évaluation des structures de recherche.
11. Suivre et encourager (2/2) • « On n’évalue pas une production scientifique logicielle comme le reste … comment reconnaître les différents rôles des uns et des autres ? » • La production logicielle dans la recherche peut être le fait de doctorants ou post-doctorants qui n’ont pas de visibilité sur la pérennité de leur implication. • La contribution à un projet logiciel (code, documentation, test) est souvent considérée comme un « plus », non comme une production de l’activité de la recherche à part entière. On assiste à un manque de reconnaissance de la part des institutions et des communautés scientifiques dans les carrières. • Comment “évaluer” un logiciel vs. évaluer un article? Quelle “fonction d’utilité” d’un logiciel? relative à une communauté scientifique? un sujet technique de niche? au contraire un besoin très générique?
12. Valorisation économique : acculturer (1/2) • Émettre des recommandations auprès des organismes financeurs pour accompagner au mieux le développement logiciel. • Faire monter en compétence les structures de valorisation sur les modèles économiques associés à la production de logiciels libres.
13. Valorisation économique : acculturer (2/2) • Etablir des grilles d’analyse pour identifier des projets logiciels stratégiques • Mener des actions pour pérenniser les projets logiciels stratégiques • Lancer et référencer les dispositifs d’accompagnement des établissements • Développer des partenariats entre entités publiques et industrielles pour mutualiser les coûts, les moyens et les ressources ? • Lancer des appels à projet spécifiques de l'ANR ? • Comment mutualiser des ressources rares ? « Des équipes de développeurs permanents pourraient donner du temps sur des projets libres définis dans d’autres laboratoires qui n’ont pas forcément accès à des informaticiens » • Des correspondants “logiciels libres” dans les services de valorisation? Faciliter les échanges entre porteurs de projets logiciels et services de valorisation • Créer et partager un boîte à outils juridiques. Construire une base de connaissances commune orientée “valorisation des logiciels libres de recherche” : modèles économiques, cas d’étude, etc.
14. Autres constats et propositions partagées • Un cadre culturel commun à établir : ◦ Des oppositions structurelles sont présentes entre services de valorisation et la culture de la science ouverte. Cela mène souvent à une mise en open source de la part des équipes de développement sans consultation des services de valorisation. • Des obstacles psychologiques et opérationnels à lever : ◦ La mise en open source des logiciels rencontre plusieurs freins comme la peur du jugement par les pairs, la peur de perdre le contrôle du projet, de perdre des contrats ou partenariats notamment industriels, le manque de compétences pour l’ouverture du code et la gestion future du projet (financement, vision, communauté, debugs, etc.)
15. Conclusion : mobiliser ! • Parmi les prochaines actions du collège « codes sources et logiciels » du Comité pour la science ouverte : établir une charte nationale des logiciels libres issus de l’enseignement supérieur, de la recherche et de l’innovation.