Stratégie nationale : soutien à la publication et au développement de projets logiciels au sein de l’ESR

Inscrire le développement et le maintien de projets logiciels et open source au sein des politiques institutionnelles et de l’évaluation des chercheurs

Lever les freins à la publication des codes sources : qualité du code, compétitivité, manque de valorisation

La question des freins à la publication de code source a été abordée au sein du questionnaire. Le manque de temps (30 %) est une raison majeure mentionnée. Néanmoins d’autres raisons ont été notées se rattachant d’une part des modalités d’évaluation actuelle des chercheurs et des projets de recherche (compétitivité, etc.) et d’autre part du manque de soutien de la part des institutions vis-à-vis des initiatives d’ouverture de code source.

^{Points clefs questionnaire :}

• ^{Dans les raisons pour la non-publication, la plus plébiscitée est celle du manque de temps.}

• ^{Dans les commentaires, les répondants évoquent beaucoup de sentiments improductifs, voire négatifs en lien à la culture de recherche actuelle. Les idées les plus récurrentes concernent la peur de l’évaluation des pairs en rapport avec la qualité/propreté du code d’une part et la rivalité entre équipes de recherche. Le manque d’incitation politique institutionnelle et de valorisation pour les chercheurs de l’ouverture des codes sources est évoqué.}

Plusieurs remarques en lien avec la non-publication du code source rejoignent les réticences mentionnées à d’autres initiatives associées à la science ouverte (mise à disposition des données, publication en open access). Il s’agit à la fois de la peur de la critique et du jugement sur la qualité du code jugée trop faible. La reconnaissance par les pairs étant clef dans l’évaluation des chercheurs. Plusieurs personnes en commentaire du questionnaire notent qu’elles ne souhaitent pas exposer du code qui n’est pas « propre » ou avaient peur des répercussions négatives associées. La peur de publier les codes est aussi associée à des enjeux de compétitivité et une rivalité entre équipes et recherche comme le résument ces commentaires.

« Volonté de nettoyer le code avant. » « Peur d’être jugé sur la beauté du code. » « L’égo et l’évaluation des pairs en somme. » « Peur de la visibilité et des retours négatifs, impact sur l’image de l’organisme/service (j’ai connu ça il y a quelques années). »

Recommandation 16 : Identifier les freins personnels rencontrés face à la publication de codes, spécifiques ou non à l’ESR.

Un renforcement et une coordination des initiatives de politiques publiques déjà en cours

Le manque d’incitation de stratégie de la part des institutions a été aussi relevé avec des leviers de valorisation absents pour les personnes produisant ces codes sources au regard du risque encouru pour leur carrière ou éventuelle promotion. En résumé, alors même qu’une motivation intrinsèque est forte au sein des personnes participant à l’ouverture des codes sources, le système institutionnel en place ne crée pas les incitations nécessaires permettant de potentialiser ces initiatives.

Plusieurs besoins ont ainsi été remontés et dessinent le rôle clef de politique institutionnelle en soutien aux initiatives open source existant et aux communautés qui y participent. Ces actions peuvent s’appuyer sur les politiques déjà à l’œuvre au sein du Ministère de L’Enseignement supérieur de la Recherche et de l’Innovation (MESRI). Le Comité pour la science ouverte et un nouveau comité pour les infrastructures numériques (en cours de constitution) sont des instances clefs (pilotage, groupe de travail) pour la mise en place de politique cohérente au sein des différences institutions de l’ESR. Plus que des enjeux de science ouverte, il s’agit avant tout d’aider à la coordination d’acteurs de l’ESR en transition avec de nouveaux enjeux numériques (modèles économiques, infrastructures à déployer, adoption de nouvelles pratiques, etc.).

Recommandation 17 : Confier au CoSO, via son groupe logiciels libres, une action de coordination des politiques de publication des codes sources au sein de l’ESR.

Un référencement des initiatives existantes et la construction raisonnée d’indicateurs

L’un des problèmes identifiés est celui de la bonne identification des logiciels produits. Au-delà des difficultés que cela présente en termes d’accompagnement et de valorisation, l’absence de ces projets est préjudiciable dans l’évaluation et le pilotage de la recherche.

S’appuyant sur l’initiative de l’INRIA1, une BIL généralisée simplifierait grandement l’action des ONR permettrait une plus grande mutualisation. Néanmoins la construction des indicateurs doit se faire avec prudence car plus que la diffusion d’un code source ce qui fait la réussite d’un projet sont les dynamiques de communautés sous-jacentes qui ne se mesurent que difficilement. Comme l’a montré le domaine de la scientométrie et des indicateurs des publications scientifiques, le champ des « métriques » peut amener à des mésusages et des résultats contre-productifs par une quantification excessive. Il est donc important dans le référencement de ces projets de réfléchir à une évaluation qui laisse aussi la part au qualitatif2.

Recommandation 18 : Réaliser une étude spécifique sur l’évaluation de la valorisation des logiciels dans l’ESR proposant des critères adaptés aux pratiques de l’open source.

Recommandation 19 : Établir un baromètre de l’open source dans l’ESR qui s’articule ou complète le baromètre de la science ouverte.

Le besoin d’une d’une dynamique de mutualisation et de contribution soutenue au sein de l’ESR

Le référencement des projets peut avoir pour effet une meilleure visibilité et ainsi faciliter une mutualisation des initiatives en cours. En effet, ce point est essentiel, car l’open source afin de bénéficier de ces dynamiques ne se limite pas à la publication du code source, mais à la mise en œuvre de logique de contribution entre plusieurs acteurs. Une des personnes interrogées et ayant participé au développement d’une plateforme open source de l’enseignement supérieur notait par exemple l’importance de réussir à créer une dynamique non plus seulement de service, mais de contribution.

Les bénéfices attendus à l’échelle d’un projet ou d’une organisation ne sont qu’une partie d’un bénéfice beaucoup plus important susceptible d’être réalisé à une échelle globale. Une des personnes interrogées3 notait en ce sens le besoin d’intégrer également comme coût d’amortissement la maintenance afin de pouvoir continuer à développer les logiciels open source. Face au numérique, bien souvent une structure seule ne peut pas couvrir une somme de coûts qui augmenterait continuellement. Les logiciels open source, dès lors qu’ils sont suffisamment génériques pour être transposables d’un usage à un autre, d’une administration à une autre, peuvent permettre une réelle mutualisation et répartition des coûts afin de les faire tomber vers zéro.

Ainsi, différents types de mutualisation peuvent être envisagés :

• Une mutualisation entre les centres de recherche, selon des modalités à définir (au travers de consortiums, de structures de mutualisation ou de gouvernance complètement ouverte). Des projets tels que Scilab, OrféoToolbox ou MMG3D sont ainsi des exemples de mutualisation importants (avec le CEREMA, la Maison de la télédétection ou encore l’IRSTEA). De même le projet Regards du CNES a été diffusé en open source compte tenu des économies d’échelle qu’une diffusion de ce type pouvait permettre à l’échelle de nombreux laboratoires4. Au-delà, l’open source peut favoriser une mutualisation dans le cadre d’une recherche internationale, comme ce fut le cas pour le projet SWOT (Surface Water and Ocean Topography, réalisé en collaboration étroite par la France et les USA) ou le projet GAMA (entre la France, l’Asie et les USA).

• Une mutualisation avec les autres acteurs publics. C’est notamment le cas d’EDF, qui reste très proche de la recherche universitaire et participe à l’industrialisation de certains projets. Plusieurs agences s’appuient également sur les résultats de la recherche pour mener à bien leurs propres missions5.

• Une mutualisation globale, sous réserve d’une vraie pratique d’industrialisation pour intéresser les acteurs industriels et réduire l’incertitude relative à la pérennité du projet. L’ouverture du code favorise aussi des collaborations, notamment publiques-privées, sans cela. Le constat est que les échanges sont plus subtils et complexes avec des opérateurs privés que pour le monde académique au sein duquel les recherches sont généralement ouvertes et partagées. Les industriels imposent en effet une confidentialité dans les échanges, ainsi que la prise en considération d’intérêts sociaux économiques.

Une telle vision politique et démarche de mutualisation est ainsi évoquée comme alternative viable face à la domination des géants du numérique (GAFAM ou BATX).

Recommandation 20 : Ajouter la réutilisation et la contribution à des logiciels provenant d’autres établissements de l’ESR comme critère d’évaluation vis-à-vis de leurs tutelles afin de favoriser les mutualisations.

Recommandation 21 : Définir une stratégie open source de l’ESR français bénéficiant d’un cadre d’évaluation et de pilotage national.

Services externes : économie d’échelle et réduction de coût

Deux sources de services externes ont été mentionnées dans le cadre de la valorisation de projets logiciels comme étant possiblement partiellement remplaçables dans le cadre d’une démarche de publication de codes sources :

• L’audit de code nécessaire à la mise en conformité d’un logiciel de recherche à l’égard des licences des composants tiers utilisés (d’autant plus nécessaire que le projet est exploité industriellement). Les licences des logiciels d’audit sont particulièrement élevées (d’une dizaine à une vingtaine de milliers d’euros par projet) et représentent un coût conséquent à l’échelle nationale. L’accompagnement des projets de recherche dans le cadre d’une publication de codes sources permettrait de distiller un certain nombre de bonnes pratiques notamment d’apprentissage de développement de projets collaboratifs (production de code de qualité, standardisation, test) tout autant que de renforcer la qualité juridique des projets. Au-delà, une mutualisation pourrait aussi être envisagée en s’appuyant sur une solution d’audit de code open source mutualisée entre les établissements6.

• Les « dépôts logiciels » réalisés auprès de l’Agence pour la Protection des Programmes (APP) à de multiples reprises lors de la conception, du transfert, de la valorisation et de la maturation d’un projet logiciel. Cet enregistrement permet d’identifier précisément l’objet de la maturation et d’obtenir un numéro unique d’enregistrement auquel renverra le contrat avec le partenaire (une SATT en cas de maturation, tout autre partenaire industriel en cas de valorisation directement réalisée par l’institut de recherche). Chaque dépôt étant payant, il serait opportun d’évaluer le coût complet de ce service tiers, pour dans un second temps évaluer les démarches alternatives. Dans ce contexte, la publication généralisée des codes sources pourrait générer une économie importante pour les établissements tout en répondant aux enjeux de preuve d’antériorité et de traçabilité.

Recommandation 22 : Identifier les économies susceptibles d’être générées par une démarche accompagnée de publication par principe des codes sources.

Besoin humain : une réévaluation des plans de carrière et une pérennisation des postes au sein de l’ESR dédiés au développement et à la maintenance

Le questionnaire et les entretiens menés avec des chercheurs, ingénieurs de recherche et responsables de productions logiciels dans des GIP ont permis de faire remonter différents besoins pour favoriser la publication et l’ouverture des codes sources. La problématique des ressources humaines allouées au développement de projet logiciel ou bien de leur maintenance a été abordée à plusieurs reprises. Cela concerne aussi bien des laboratoires de recherche qui subissent le manque de poste fixe pour pouvoir assurer le maintien et le suivi des projets tout autant que le recrutement de développeurs dans des structures telles que les GIP. Une des personnes interrogées7 mentionnait que dans le champ de l’enseignement supérieur, le nombre d’étudiants croît en même temps que celui des demandes de nouvelles fonctionnalités numériques – mais les ressources n’augmentent pas. Les réponses relatent ainsi des moyens insuffisants pour prendre soin du développement, mais aussi de la maintenance des infrastructures, des codes sources.

« Les instituts de recherche devraient promouvoir activement la reproductibilité des recherches effectuées par leurs agents. Pour cela, les agents faisant l’effort de le faire pourraient être plus soutenus que les autres, par exemple en financement récurrent. De plus, les directions des instituts pourraient avoir une véritable stratégie de développement, en favorisant le partage de code à partir des initiatives individuelles des agents.»

^{Points clefs questionnaire :}

^{Les répondants auraient besoin de plus d’accompagnement au sein de leur institution, et moins comme un service public généralisé à travers l’ESR.}

Au-delà des postes d’ingénierie de recherche, d’étude ou d’enseignement-recherche, il est important de noter que les entretiens et les commentaires au questionnaire mettent en avant un ensemble d’autres personnes souvent contractuelles de l’ESR (post-doctorat, vacataire)8 ainsi que des personnes indépendantes travaillant avec l’ESR (formation, développement en statut d’indépendant) contribuant au développement de projets open source. Plusieurs entretiens ont par exemple souligné la précarité des contrats (CDD) amenant au départ de personnes contribuant à des projets de développement logiciel. La publication du code source dans certains cas a été le seul moyen de pouvoir continuer des projets de développement en cours qui s’arrêterait à la fin du contrat comme le note la personne interrogée9 :

« La question, critique, était celle du devenir du projet une fois l'ingénieur en charge parti. À la fois parce qu'il voulait continuer à contribuer au développement, et parce que ses compétences allaient manquer à l'université pour envisager toute exploitation. La solution était donc une licence libre.»

Néanmoins, l’open source ne permet pas d’asseoir ces projets de manière durable, car elle s’appuie sur un flou entre contribution personnelle et professionnelle. En effet, dans le cadre des développements open source, les personnes contribuant à ces projets le font souvent de façon bénévole et mêlent à la fois le développement à titre de mission professionnelle, mais aussi à titre de loisir comme le souligne un des ingénieurs de recherche interrogé10..

« La frontière entre la contribution et les missions personnelles est floue. Il y a une très forte publication pour des projets institutionnels qui sont personnels.»

Valoriser la production open source et les fonctions de maintenance des productions logicielles dans les fiches de poste et l’évolution de carrière est une manière de pérenniser ces projets. Un des commentaires du questionnaire mentionne ainsi :

« J’aimerais que la carrière de développeur soit mieux valorisée au sein du CNRS et pas bloquée par l’obligation de devenir chef de projet ou de service pour pouvoir monter en grade. À cause de cette politique, il y a peu de développeurs expérimentés et donc la qualité du code n’est pas bonne et du coup les gens ne publient pas leur code par peur des critiques ou par peur de leaker des informations confidentielles (password, adresse email, adresse ip).»

L’open source peut devenir également un élément d’attractivité pour des développeurs face à une concurrence forte du privé (meilleur salaire, condition de travail) : comme le souligne une des personnes interrogées « avec l’open source, les gens vont retrouver pourquoi ils sont dans l’ESR. »

Recommandation 23 : Recruter et pérenniser les postes de fonctions support et personnes-ressources mobilisables sur le développement et la maintenance de projets open source.

Recommandation 24 : Sensibiliser les communautés de recherche sur les compétences nécessaires à mobiliser pour pérenniser un projet open source.

Recommandation 25 : Apporter un cadre aux contributions apportées au sein des projets logiciels qui dépassent les missions de recherche et d’enseignement (notamment contributions personnelles réalisées en nom propre).

Recommandation 26 : Faire valoir le développement de code source dans les critères de recrutement et d’évaluation des professionnels de la recherche, et développer des mesures incitatives pour faciliter le développement de code source de qualité.

Besoin d’infrastructures et de formation pour de bonnes pratiques d’ouverture du code source

Infrastructure nécessaire à la publication de code de l’ESR

Une des questions du questionnaire portait sur le lieu de publication des codes sources et les modalités de leur partage (public, privé, compte d’un projet ou personnel). La plupart des projets proposés ont été publiés publiquement sur un compte d’organisation dédié au projet (71 %) ou sur un compte personnel (43 %)11La plateforme GitHub est essentiellement utilisée pour le partage des codes sources (68,8 %).

Les réponses mettent également en évidence l’existence de nombreuses forges basées sur GitLab12.

• ^{L’utilisation de forge basée sur GitLab illustre en soi les logiques d’open source soit de faciliter la réutilisation d’un outil et de mutualiser le développement de nouvelles fonctionnalités sans avoir à développer de zéro un nouvel outil.}

• ^{En ce sens, il est important de rappeler que l’open source ne se limite pas à la publication de code source. Le succès du développement logiciel open source ne se mesure pas seulement à la capacité à produire un logiciel, mais surtout sur sa capacité à créer une communauté permettant de maintenir le projet, et de l’adapter à de nouveaux usages apparaissant au quotidien.}

D’autres forges sont aussi employées (25 %) notamment la forge de Renater SourceSup. Cette plateforme web de gestion de projets à destination de l’Enseignement supérieur et des laboratoires de Recherche Français développé par Renater, a été citée à plusieurs reprises dans les commentaires du questionnaire et mentionnée au cours d’entretiens. Plusieurs critiques lui sont adressées comme un usage difficile pour un public de « non développeur », là où GitHub permet de partager aisément du code source sans connaissance poussée en informatique. Une autre raison est le « cloisonnement » qu’imposent ces plateformes. Si ces forges ont l’avantage de garantir des critères de sécurité attendus au sein de l’ESR, elles rendent difficiles les logiques de contribution souvent internationale en recherche. Une personne13 mentionnait ainsi :

« Avant j’étais surSourceSup qui était pas mal au départ. J’ai commencé les projets là-dessus, mais cela a été problématique pour donner accès aux collaborateurs non français. Ensuite c’était bureaucratique à l’extrême.»

GitHub reste ainsi la plateforme avec une utilisation la plus massive avec plusieurs raisons citées : « visibilité, praticité et intégration avec d’autres outils (npm registry, docker hub, travis...) » L’utilisation de cette plateforme suscite néanmoins des inquiétudes (rachat par Microsoft). Comme le note un commentaire :

«Au final on a le choix entre utiliser des plates-formes commerciales fiables et visibles, ou se battre contre beaucoup de lourdeurs administratives pour des outils bricolés avec les moyens du bord.»

La visibilité et l’effet réseau qu’offre cette solution centralisée et commerciale rendant peut-être à terme captif ses utilisateurs.

Si des personnes plébiscitent l’existence d’une « forge nationale de qualité basée sur Gitlab », plusieurs commentaires nuancent l’existence d’une solution centralisée nationale. Ces personnes notent que la centralisation irait à l’encontre d’une culture en recherche largement décentralisée à l’image des critiques faites à des plateformes telles que HAL (atteinte à l’indépendance des chercheurs, renforcement des mesures d’évaluation, etc.). Par ailleurs, la proposition d’une plateforme centralisée (une alternative nationale à un GitHub) risquerait de ne pas être adoptée pour des raisons pratiques comme le souligne ce commentaire :

« Je ne sais pas s’il faudrait un GitHub français souverain pour des raisons pratiques on veut pas se retrouver dans une solution de devoir pusher sur différentes forges remote. Il faut une seule source de vérité pour le code.»

À défaut, l’accès aux fonctionnalités d’une plateforme moderne, ou une modernisation de SourceSup conformément à ces standards, répondrait aux besoins des projets open source non ou insuffisamment outillés.

Une solution proposée qui rejoint code.etalab.gouv est le développement d’une vitrine de visibilité des codes produits moissonnés automatiquement avec la publication du code source sur une liste de forges recommandées. Cela permettrait d’intégrer les productions logicielles dans les éléments d’impact des universités et instituts.14

Une plateforme de partage de code source doit ainsi à la fois disposer de fonctionnalités adaptées aux chercheurs et à des modes de travail décentralisé tout en assurant la visibilité des projets. Outre le partage du code source, ces plateformes doivent pouvoir s’intégrer (interopérabilité) avec un ensemble d’autres outils et d’initiatives à l’œuvre sur le référencement, l’indexation, l’attachement à des identifiants pérennes, le référencement dans des plateformes de type HAL15, l’archivage du code source nécessitant également un accompagnement à ces principes pour garantir la pérennisation de projets16 17. Le travail sur la citation et le référencement est en cours avec des solutions d’interfaçage qu’il s’agit de continuer.

Recommandation 27 : Moderniser les services offerts aux projets de l’ESR pour le développement et la publication de code source.

Recommandation 28 : Favoriser l’interopérabilité entre les différentes plateformes de développement et partage de code source à l’échelle de l’ESR et à l’échelle nationale.

Recommandation 29 : Évaluer les besoins de plateformes d’hébergement ou de mise en visibilité des codes sources de l’ESR et penser les conditions de leurs interfaçages avec les autres plateformes pré- existantes (Software Heritage, HAL, etc.).

Faciliter le développement de logiciels au code source pérenne et de qualité : documentation, archivage et référencement

Les besoins de formation ont été remontés par les personnes ayant répondu au questionnaire à l’image de ce commentaire :

« Il serait intéressant de disposer d’un accompagnement méthodologique et parfois technique pour aider à la diffusion des codes sources notamment dans les petits établissements comme le mien qui ne peuvent pas élaborer un tel accompagnement par manque de compétences et de moyens.»

Autre point la majorité des personnes ayant répondu au questionnaire ne connaissent pas les ressources mises à disposition par Etalab au sujet de la publication de code source.

Points clefs questionnaire :

La plus grande partie des répondants ne connaît pas les ressources publiées par Etalab et la DINUM.

Recommandation 30 : Faire travailler le CoSO et Etalab de façon plus étroite pour la valorisation de ce contenu et l’évaluation régulière de leur pertinence.

La documentation du code, l’apprentissage au développement collaboratif et à l’ingénierie logicielle (« au-delà du code prototype, plein de bugs, sans tests ni doc. ») ont été mentionnés. Des initiatives étrangères telles que le « Software Sustainability Institute », le « Reproducible Research Oxford » ou encore l’initiative « Essential Open Source for Science » de la fondation Chan Zuckenberg apparaissent comme des exemples à suivre18. Le développement d’open badges19 pour faciliter des dynamiques communautaires et la production de code de qualité est un point soulevé pour favoriser « une meilleure valorisation et ouvrant la voie à la création d’un écosystème dynamique. ». Certains commentaires proposent d’aller plus loin avec la proposition de labels de qualité. À l’image des plans de gestion de données (DMP) nécessaires désormais pour le financement de projets de recherche (ERC, ANR), un plan de gestion logiciel tel que le modèle PRESOFT (research software management plan20)21 pourrait être également un outil employé dès la conception d’un projet logiciel.

Des différentes réponses au questionnaire, des entretiens réalisés tout autant que du recensement de projets open source, il en ressort une dynamique communautaire forte au sein des communautés de recherche de part des pratiques open source proches des valeurs soutenues au sein de l’Enseignement Supérieur et de la Recherche. Ces initiatives souvent développées par les communautés de recherche elles-mêmes gagneraient à être mises en visibilité pour favoriser des dynamiques de mutualisation et de méthodes ouvertes collaboratives. Ces dernières peuvent se construire et se renforcer non pas en opposition aux processus de « valorisation » mises en œuvre au sein de l’ESR mais en se combinant. Pour cela, une définition élargie de « la valeur » et une réflexion sur les indicateurs associés est une piste féconde pour à la fois souligner l’impact de tels projets (financiers, sociaux, environnementaux, etc.) tout en se basant sur le développement d’une évaluation centrée sur la vitalité de tels écosystèmes.

^{Messages clefs de l’article « Conjuguer open source et science ouverte opportunités et leviers d’action»}22 ^:

1. ^{Valoriser par l’open source nécessite de prendre de la hauteur, d’opérer un changement de vision et de logique par rapport au mode de valorisation habituel. Évaluer le plein potentiel de ces projets implique de prendre en considération des dynamiques multi-échelles (vision macro dépassant le périmètre usuel de l’institut de recherche). L’open source tire sa force de dynamiques de contribution et mutualisation qu’il s’agit de faciliter et maintenir tout en trouvant des mesures de valorisation adaptées aux logiques écosystémiques.}

2. ^{L’open source répond au besoin de repenser les relations privé/public en les insérant dans un réseau d’acteurs aux priorités différentes (recherche, économique, etc.) coopérant pour la réussite du projet. Le succès escompté implique de mettre en place des règles de gouvernance soutenues par un cadre contractuel discuté et établi en amont du projet puis durant ses étapes de développement, ce qu’offrent pleinement les outils contractuels de l’open source. Mettre en place un tel cadre et partager ces « bonnes pratiques » apparaissent comme des catalyseurs afin de mieux articuler le rôle des parties prenantes dans différentes phases et potentialiser les bénéfices propres et communs à chaque secteur (instituts de recherche, entreprises partenaires, etc.)}

3. ^{La valorisation par l’open source se base sur le développement d’une évaluation centrée sur la vitalité d’un écosystème. Aux mesures usuelles économiques et technologiques, s’ajoutent des éléments de valeur ancrés dans des dynamiques contributives saines. Tenir compte de valeurs spécifiques aux établissements de recherche et aux communautés amène à évaluer des usages, complexes par nature et différemment quantifiables. Valoriser par l’open source nécessite une attention toute particulière au développement d’indicateurs et de métriques se construisant avec les communautés et acteurs concernés. Il s’agit en premier lieu de comprendre les raisons des usages existants et de les faire évoluer, si besoin est, vers d’autres pratiques plus adaptées et pertinentes pour la valorisation tout autant que pour la communauté en elle-même qui gagne en réflexivité sur ces propres usages.}

4. ^{Les politiques publiques pour une science ouverte constituent un tremplin pour l’adoption de l’open source au sein des instituts de recherche. Il semble néanmoins que les opportunités croisées entre ces deux domaines ne soient pas encore exploitées à leur juste mesure. Les axes principaux du plan national de la science ouverte mettent en priorité les questions de l’accès aux publications et aux données. Si les logiciels libres et open source font partie d’une thématique d’un groupe de travail du CoSO en qualité d’« outil », « objet de recherche » ou « résultat au service de la recherche » (qualité, reproductibilité, avancée scientifique), il semble aussi que la généralisation de l’open source participe à l’émergence nécessaire des infrastructures (ouvertes) de la science ouverte (édition, partage des données). Penser la science ouverte à l’aune des dynamiques open source en s’appuyant sur le renversement de logique et de culture que les logiciels libres et open source matérialisent est aussi un moyen de questionner les modalités économiques et de gouvernance de la production des savoirs de la recherche publique. Toutes et tous, acteurs de la recherche ou industriels, acteurs privés ou publics, organisations et individus, gagneront à l’émergence et à la gouvernance partagée d’une telle infrastructure ouverte produite par et pour la recherche. Un chantier encore à développer.}