Skip to main content

La publication de codes sources : une pratique partagée entre les différents établissements de l’ESR

Mode de production scientifique et open source : des motivations communes et des cultures intimement liées. Une multitude de projets de l’ESR en open source et un recensement complexe à mettre en œuvre

Published onDec 23, 2020
La publication de codes sources : une pratique partagée entre les différents établissements de l’ESR
·

Une prise en compte transverse au sein de l’ESR

Les établissements de rattachement des personnes ayant répondu au questionnaire sont représentatifs de la diversité des types d’organismes regroupés sous le terme d’ESR1 et répartis géographiquement sur toute la France. On y trouve ainsi à la fois :

  • des établissements de recherche (CNRS essentiellement, Institut Pasteur, INRIA, INRAE, CEA, IGN, Institut Curie, CEREMA2) ;

  • 27 Universités et 7 Grandes Écoles (Sorbonne Université, Université de Paris, Paris Dauphine, UPEM, universités de Bordeaux, Strasbourg, Poitiers, Franche-Comté, Côte d’Azur, Versailles, Lille, Toulouse, Caen, La Réunion, Rennes, Grenoble, École polytechnique, Centrale, CNAM, INSA Rennes, ENI Tarbes) ;

  • d’autres services et groupements d’intérêt public (GIP) et organisations de soutien à la recherche (ABES, INIST-CNRS, GIP FUN, GIP RECIA, GIP RENATER) ;

  • ainsi que la participation de ministères (MESRI, ministère de la Santé et des Solidarités) et d’une direction rattachée à l’éducation nationale (DSDEN) ;

  • quelques acteurs privés (entreprises ou indépendants et prestataires externes) ont également répondu au questionnaire tout autant que des acteurs ayant travaillé préalablement au sein de l’ESR.


Points clefs questionnaire:

  • Les réponses proviennent de plus d’une centaine d’institutions différentes. Le CNRS est l’institution la plus représentée (avec 41 personnes affiliées au CNRS contre 18 pour l’INRIA).

  • Les personnes ayant majoritairement répondu sont essentiellement des postes d’ingénieurs (de recherche ou d’étude).


La distinction entre les activités de recherche et de développement : fonction, domaine et responsabilité

Parmi les personnes ayant répondu, les fonctions occupées sont les suivantes :

  • ingénieurs de recherche et d’ingénieurs d’études (plus de 50 % – dont 27,6 % IR et 25,8 % IE);

  • maîtres de conférences (12 %);

  • doctorants (8 %);

  • chargés de recherche (6,5 %);

  • d’autres profils ont été indiqués notamment des post-doctorants, des bibliothécaires, des vacataires, des ingénieurs sur contrat et des développeurs/formateurs indépendants.

En revanche, les responsables des systèmes d’information (DSI) n’ont été que peu nombreux à répondre au questionnaire (3 %) tout comme les chercheurs dans le secteur privé (2,3 %) et les responsables de la valorisation et de l’innovation (1,8 %).

Les rôles majoritaires tenus dans les projets et de façon non exclusive concernent tout d’abord le développement (88,6 %) avec des fonctions d’architecture et de conception (77,8 %), mais aussi de documentation (72,4 %) et de maintenance (70,6 %). Fait intéressant, peu de personnes ont joué un rôle dans la valorisation du projet auquel elles ont participé (34,8 %). Quelques rôles supplémentaires ont été repérés dans le questionnaire en commentaires notamment celui de test, de coordination et d’encadrement du développement ainsi que de formation et de transmission des connaissances, ce qui permet d’enrichir la palette des activités nécessaires à la vie d’un projet « logiciel » ou de développement de codes sources.


Points clefs questionnaire :

  • La majorité des personnes ayant répondu au questionnaire l’ont fait en leur nom propre.

  • Seulement ~9 % de réponses ont été données au nom d’une équipe et ~ 2 % pour un établissement (cf. Figure 1)


Figure 1: À quel titre répondez vous au questionnaire ?

  • La plupart des initiatives développées sont majoritairement menées dans le cadre de missions professionnelles (93 %).

  • Les répondants sont majoritairement des hommes3.

  • La majorité des réponses proviennent de personnes dont les fonctions sont associées à des projets de développement. Environ la moitié participent également à titre personnel à de tels projets (cf. Figure 2)

Figure 2 : Dans quel cadre développez-vous des codes sources ?

  • Peu de personnes ont joué un rôle dans la valorisation du projet auquel elles ont participé.

  • Une grande majorité des personnes affirment avoir partagé le code source publiquement.


Les personnes ayant répondu ont majoritairement une pratique de production de code source et une familiarité avec les principes open source de par des valeurs et modes d’organisation qui sont connexes. En effet, l’open source rejoint des pratiques et des modalités de fonctionnement ancrées au sein de certaines cultures disciplinaires de l’ESR (partage, relecture par les pairs, mutualisation, organisation en réseau).

Mode de production scientifique et open source : des motivations communes et des cultures intimement liées

Il est important de rappeler que les principes du logiciel libre et de l’open source sont nés au cœur des universités au début des années 1970. Face à un mouvement d’appropriation des logiciels – pleinement matérialisé par la consécration d’un droit d’auteur spécifique dans les années 80 – les universités ont ainsi joué un rôle crucial – en s’appuyant sur leur force économique et intellectuelle – pour s’assurer de l’existence de logiciels libres et open source nécessaire à leur autonomie. Au-delà de leur contribution technique, les universités et centres de recherche ont aussi fortement contribué dans les années qui suivirent à renforcer les outils juridiques associés aux pratiques de l’open source4.

Ainsi, au classement des motivations à publier les projets en open source dans le questionnaire, la première motivation est celle de « favoriser la mutualisation du travail d’équipe » (classement 1 : 41,2 %). Ensuite, il s’agit « d’encourager la réutilisation du code source » (classement 2 : 30,3 %). La « pérennisation du code source » et « la valorisation logicielle » ne se positionnent qu’en troisième position (20,4 % et 16,6 % respectivement). Enfin « favoriser la citation et la reconnaissance des contributions » ne vient qu’en dernier lieu (classement 4 : 18,1 %)5.


Points clefs questionnaire :

  • La mutualisation et l’encouragement à la réutilisation des codes sont les premières motivations pour publier des codes sources, la pérennisation, la reconnaissance et la valorisation venant en dernier lieu.


Un chercheur6 note ainsi que l’open source s’est démocratisé, devenant un usage commun là où il était l’exception. Cela renvoie à une dimension générationnelle forte confirmée par ailleurs, les nouveaux chercheurs et ingénieurs de recherche étant beaucoup plus enclins à partager leur production et familiers avec les outils et processus de l’open source.

« Aujourd’hui c’est devenu la normalité pour les plus jeunes. Au début il fallait se battre et maintenant [c’est] un sujet connu notamment des ingénieurs de recherche. »

Au départ, la personne note que l’open source n’était accepté que s’il n’y avait pas de valorisation7.


DevLog : Un exemple de réseau d‘acteurs du Développement LOGiciel au sein de l’Enseignement Supérieur et de la Recherche

Sa mission essentielle est de favoriser les échanges, le soutien aux réseaux régionaux dans leurs actions, des offres complémentaires d’actions et de formations. Le réseau vise à faciliter le lien entre la communauté et les tutelles afin de remonter les réalités du terrain. Voir http://devlog.cnrs.fr/


Le partage du code source pour favoriser les mutualisations, le travail collaboratif, mais aussi la vérification par d’autres personnes contribuant au projet fait écho à l’idéal de la démarche scientifique. Néanmoins, les pratiques open source diffèrent en fonction des communautés disciplinaires qui n’ont pas les mêmes cultures de recherche (communautés épistémiques)8. Néanmoins, l’adoption de pratiques d’ouverture au sein de l’ESR9 évolue ces dernières années en faveur d’un rôle de plus en plus important reconnu aux données, leur gestion, leur analyse et leur mise à disposition (science ouverte, science des données)10 au sein d’un champ disciplinaire élargi (notamment en SHS11). Cette même idée se retrouve dans le questionnaire comme le souligne ce commentaire « Les pratiques évoluent très vite ces dernières années, avec un usage de plus en plus tôt de forges et de code ouvert ». De fait, les pratiques sont encore hétérogènes de par la nature « hybride » des logiciels12 et naviguent entre :

  • un code source diffusé « de fait » dans des disciplines telles que les mathématiques ou l’informatique, car la production de logiciels est considérée comme un résultat même de recherche ou bien un objet d’étude (comme artefact)13;

  • un code source graduellement partagé pour des logiciels considérés comme moteurs et outils de traitement d’analyse au sein de travaux de recherche, faisant également de l’open source une pratique de plus en plus fréquente au sein de nouvelles disciplines scientifiques touchées par l’essor du numérique. En effet, ces dernières années, les utilisations de langages de programmation open source – dont les deux plus répandus sont Python et R – ont été de plus en plus fréquentes avec une offre de formation grandissante au sein des instituts, écoles doctorales, etc. Les sciences humaines et sociales développent également des outils open source : dans le cadre de l’analyse de réseau, par exemple, ou encore du traitement naturel du langage (Natural Language Processing).


La montée conjointe de l’usage des langages de programmation R et Pyhton :

Le développement de bibliothèques autour des langages de programmation Python et R en fonction des projets et disciplines permet des usages spécifiques et adaptés à certaines disciplines ou bien, tout au contraire, des développements transverses. On peut citer par exemple le projet phare SciKitlearn (bibliothèque Python de machine learning) avec des usages qui dépassent largement la communauté académique (utilisé massivement dans le milieu de la data science). Pour le traitement statistique, une personne interrogée14 notait le remplacement du logiciel STATA ou encore de Matlab de statistique propriétaire par l’usage de R dans les enseignements :

« ce qui joue beaucoup c’est la montée conjointe des langages R et Python dans les domaines où Stata et Matlab étaient habituellement utilisés ».15


Recommandation 1 : Reconnaître le rôle et la place de l’open source dans l’enseignement supérieur et la recherche française et situer la France dans une perspective internationale.

Une multitude de projets de l’ESR en open source et un recensement complexe à mettre en œuvre

Une multitude de projets 16ont été recensés lors de cette étude, qui pour certains jouent rôle majeur à l’échelle des communautés de recherche (développement d’outil phare dans des disciplines), mais aussi plus globalement par un tissu d’acteurs socio-économiques et administratifs, car le code source a été ouvert.

Dresser un panorama exhaustif de ces projets se révèle complexe compte tenu de l’éclatement des initiatives17 et en l’absence d’inventaire à l’échelle des instituts de l’ESR. Faisant écho à une culture de la recherche qui s’appuie sur des communautés de chercheurs distribuées et mondiales, les projets open source et leurs écosystèmes sont souvent difficiles à circonscrire et ne rentrent pas dans les processus généralement utilisés par les instituts de l’ESR pour dénombrer et valoriser les logiciels produits. Ainsi, seuls les projets logiciels les plus importants sont visibles, comme le mentionne un commentaire du questionnaire :

« Du fait de cette décentralisation et non-planification, les universités, labos et EPST sont souvent incapables de lister les logiciels qui y sont produits, exception faite des plus visibles.»

Comme le souligne une personne interrogée18, certains projets19 n’auraient pas connu un succès international s’ils n’avaient pas été en open source. D’autres logiciels spécifiques sont aussi développés pour les besoins de communautés données. On trouve également des infrastructures numériques clefs pour le soutien à l’enseignement supérieur et à la recherche20.

Des projets de recensement logiciels sont néanmoins à mentionner à l’échelle de laboratoires ou d’institut. Le laboratoire LGIM par exemple possède une politique de patrimoine logiciel afin d’étudier la mise en place de services (suivi de versions, publications) et de favoriser leur visibilité.21 L’INRIA a par exemple mis en place une base de données de ses logiciels (BIL)22, mais comme le note une personne en commentaire du questionnaire « elle est probablement incomplète et datée, car mise à jour simplement en fonction de besoins ponctuels (création de startups, dépôt APP, demande de moyens) ». De même le projet PLUME23 initié au CNRS – dont le but était de promouvoir les logiciels libres, de mutualiser et de valoriser les compétences sur les logiciels – s’est arrêté en 2013 après 7 ans d’existence et un travail conséquent de référencement logiciels avec la production de 406 fiches descriptives de logiciels validés dont 95 développés dans la communauté de l’ESR24.

Plus encore, les entretiens ont révélé que la nature même de l’open source complique l’identification des logiciels qui « passent au travers des mailles » des processus de recensement et de valorisation. Point important, les processus envisagés pour identifier de tels projets sont susceptibles de générer un formalisme ou une charge complémentaire qui est considérée comme inutile par les projets ne souhaitant pas se tourner vers une valorisation économique. Par ailleurs, toute démarche administrative supplémentaire ajoutée au travail des chercheurs est perçue négativement et risque d’être contre-productive comme le souligne une des personnes interrogées25.

« Il faut trouver un processus qui combine un gain de temps et des bénéfices immédiats pour les chercheurs – de sorte que l’évaluation de l’open source ne soit pas perçue comme générant une étape bureaucratique supplémentaire. »

Recommandation 2 : Améliorer le recensement actuellement existant au sein de l’ESR des projets open source afin de construire une politique publique représentative de ces usages.
Recommandation 3 : Corréler davantage les processus que mettent en place les établissements de l’ESR pour piloter leur activité avec les bénéfices et avantages que retirent les projets.
Comments
0
comment

No comments here