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
   

   View Slide

2. Enjeux autour des codes sources et des logiciels libres
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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?
   

   View Slide

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.
   

   View Slide

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 ?
   

   View Slide

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.
    

    View Slide

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?
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.)
    

    View Slide

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.
    

    View Slide