forges-esr/intro-etatdeslieux.md

---

title: "Forges de l’Enseignement supérieur et de la Recherche" subtitle: Définition, usages, limitations rencontrées et analyse des besoins author: "Collège Codes sources et logiciels du Comité pour la science ouverte" date: Mai 2023 logo: ouvrirlasciencelogo.jpg

cspell:disable

mainfont: Marianne

cspell:enable

toc-title: Sommaire titlepage-background: "fond_ouvrir_la_science.jpg{=latex}" titlepage-text-color: 5A28C8 titlepage-rule-color: 5A28C8 section-color: 5A28C8 caption-color: 5A28C8 table-use-row-colors: true logo-width: 12cm colorlinks: true book: true classoption: oneside

draft: Document de travail

cspell:disable

header-includes: | \usepackage{tcolorbox} \tcbuselibrary{theorems} \definecolor{box-color1}{HTML}{bbfae9} \newtcbtheorem{observation}{Observation}{left=.3cm,right=.3cm,toptitle=.3cm,bottom=.3cm,middle=.1cm,colback=box-color1,colframe=box-color1,coltitle=black,fonttitle=\bfseries}{th} \definecolor{box-color2}{HTML}{eaeaea} \newtcbtheorem{autre}{À noter aussi }{left=.3cm,right=.3cm,toptitle=.3cm,bottom=.3cm,middle=.1cm,colback=box-color2,colframe=box-color2,coltitle=black,fonttitle=\bfseries}{th} \usepackage[labelfont={color=box-color1,bf},textfont={color=box-color1}]{caption} \definecolor{bar-color1}{HTML}{7846ff} \definecolor{bar-color2}{HTML}{ffe552} \definecolor{coso-title-color}{HTML}{5A28C8} \usepackage{enumitem} \usepackage{titlesec} \usepackage{moresize} \newcommand{\hsp}{\hspace{20pt}} \titleformat{name=\chapter}[hang]{\Huge\bfseries}{\thechapter\hsp|\hsp}{0pt}{\Huge\bfseries} \titlespacing*{\chapter}{-1.5cm}{10pt}{10pt} \titleformat{name=\chapter,numberless}[hang]{\color{coso-title-color}\HUGE\bfseries}{}{0pt}{\color{coso-title-color}\HUGE\bfseries} \titlespacing*{\chapter}{-1.5cm}{10pt}{10pt} \usepackage{wrapfig} \usepackage{afterpage} \usepackage{authoraftertitle} \hyphenation{ac-ti-vi-té ac-ti-vi-tés} \hyphenation{an-cien-nes} \hyphenation{DevLog GitLab OpenAI} \hyphenation{col-la-bo-ra-tion col-la-bo-ra-tions} \hyphenation{comp-ta-bi-li-sé comp-ta-bi-li-sés comp-ta-bi-li-sée comp-ta-bi-li-sées} \hyphenation{de-ve-nue} \hyphenation{Dis-co-ve-ry} \hyphenation{dis-po-ni-bles} \hyphenation{En-sei-gne-ment} \hyphenation{évo-luent} \hyphenation{exem-ple exem-ples} \hyphenation{exi-gen-ce exi-gen-ces} \hyphenation{exis-te exis-tent} \hyphenation{fa-ci-li-té} \hyphenation{fonc-tion-na-li-té fonc-tion-na-li-tés} \hyphenation{gé-né-ra-li-sa-tion} \hyphenation{in-con-tour-na-ble in-con-tour-na-bles} \hyphenation{ins-tan-ce ins-tan-ces} \hyphenation{ins-tau-rer} \hyphenation{ins-ti-tu-tion} \hyphenation{li-mi-té li-mi-tés} \hyphenation{maxi-mum} \hyphenation{orien-tées} \hyphenation{par-ta-gea-ble} \hyphenation{per-mettre per-mettant} \hyphenation{pro-blè-me pro-blè-mes} \hyphenation{pu-blic} \hyphenation{qua-li-té} \hyphenation{re-la-ti-ve-ment} \hyphenation{respect} \hyphenation{réa-li-sant} \hyphenation{ti-cket ti-ckets} \hyphenation{tui-la-ge} \hyphenation{usa-ge} \hyphenation{uti-li-sa-teur uti-li-sa-teurs} \hyphenation{uti-li-sées} \newcommand{\nbforgestotal}{81} \newcommand{\nbforgesgitlab}{72}

cspell:enable

include-before: | \newpage \newgeometry{margin=0.5in} \color{coso-title-color}{\HUGE\thetitle}

\color{coso-title-color}{\Huge Définition, usages, limitations rencontrées et analyse des besoins}

\color{black} \Large \par\noindent\rule{1.5cm}{1.5pt} Collège codes sources et logiciels du Comité pour la science ouverte \par\noindent\rule{1.5cm}{1.5pt} GT 2: Outils et bonnes pratiques techniques et sociales

Daniel LE BERRE (co-pilote GT2)
Université d'Artois/CNRS

Jean-Yves JEANNAS (co-pilote GT2)
Université de Lille/AFUL

Roberto DI COSMO (co-pilote du collège)
Inria/Université Paris Cité

François PELLEGRINI (co-pilote du collège)
Université de Bordeaux/CNRS/CNIL

\par\noindent\rule{1.5cm}{1.5pt}

\MyDate

\par\noindent\rule{1.5cm}{1.5pt} \vfill DOI : 10.52949/34 \vfill \normalsize Conception graphique : opixido

\noindent\begin{minipage}{0.2\textwidth} \includegraphics{ccby.png} \end{minipage} \begin{minipage}{0.75\textwidth}\raggedright Except where otherwise noted, this work is licensed under https://creativecommons.org/licenses/by-nd/4.0/deed.fr \end{minipage} \vfill \clearpage \restoregeometry

Résumé

Lancée en 1999, la première forge logicielle, SourceForge, a été conçue pour permettre aux développeurs de logiciels libres de construire leurs logiciels de manière collaborative et de les diffuser auprès de leurs utilisateurs. Depuis, les forges logicielles sont devenues un outil incontournable pour tous les développeurs de logiciels. Elles intègrent les outils de développement collaboratif (pour le suivi des modifications du code, la gestion des demandes et des réponses d’utilisateurs - tickets -, la gestion des contributions, la gestion du projet), l’industrialisation du processus de création du logiciel à partir de son code source (compilation, tests automatiques, assurance qualité, diffusion des livrables) et des outils de communication comme des forums.

Une forge logicielle, c’est aussi un réseau social de développeurs. Dès que l’on souhaite favoriser l’utilisation et les contributions autour d’un logiciel, se pose la question de choisir la forge en fonction du public, du réseau visé. On peut viser un public de développeurs de l’Enseignement supérieur et de la Recherche français ou international. Il existe des fédérations d’identité comme RENATER ou eduGAIN qui permettent depuis longtemps ces collaborations. Plusieurs forges de l’Enseignement supérieur et de la Recherche donnent accès à ces réseaux de collaboration. Si l’on souhaite ouvrir et partager les codes sources issus de la recherche avec la société dans son ensemble, deux alternatives existent : les forges communautaires libres ou les forges commerciales. Les forges communautaires libres permettent de diffuser au sein d’une communauté un logiciel libre qui a été coopté par cette communauté. La difficulté est donc de trouver une communauté adaptée au logiciel que l’on développe. Les forges commerciales offrent de nombreuses fonctionnalités, avec très peu de contraintes, et souvent de nombreux services quand les logiciels développés sont diffusés sous une licence libre. Parmi ces forges commerciales GitHub, propriété de Microsoft est la plus utilisée, suivi de BitBucket, propriété d’Atlassian, et de GitLab, propriété de GitLab Inc.

Certaines forges, communautaires ou commerciales comme GitLab, peuvent être auto-hébergées par des établissements de l’Enseignement supérieur et de la Recherche, certains disposant ainsi de leur propre forge publique. Cet état des lieux en comptabilise \nbforgestotal auxquelles s’ajoutent les forges à usage interne. Ces forges auto-hébergées sont souvent simples à installer : d’un simple exécutable pour des solutions comme Gogs, Gitea ou Forgejo, à un ensemble de logiciels préconfigurés intégrés à une distribution Linux pour GitLab par exemple. GitLab est en effet une forge commerciale (gitlab.com) basée sur un logiciel libre de forge que l’on peut installer sur ses propres serveurs. Le modèle économique de GitLab Inc. est basé sur la vente de licences pour apporter des fonctionnalités supplémentaires aux utilisateurs du service en ligne ou des administrateurs des forges auto-hébergées.

De fait, l’installation d’une forge auto-hébergée pour du développement collaboratif interne nécessite peu de moyens humains ou matériels, et offre une large palette de solutions. Par contre, dès que l’on souhaite s’ouvrir sur l’extérieur, intégrer des solutions d’industrialisation du développement logiciel, mettre en place des bonnes pratiques de développement, un effort plus conséquent est nécessaire et le choix de la solution peut être guidé par des critères différents : popularité de la plateforme, fonctionnalités offertes, robustesse.

Dans l’enseignement supérieur et la recherche, les développeurs de logiciels soutiens ou issus de travaux de recherche ont le choix entre diverses forges pour héberger leur production logicielle. Si leur établissement dispose d’une forge, c’est la solution la plus simple, surtout si aucune interaction en dehors de l’établissement n’est nécessaire.

Quand un besoin d’interaction plus important est nécessaire, les communautés qui développent des logiciels de recherche se tournent fréquemment vers les forges commerciales en ligne, comme en témoignent les lauréats du premier prix science ouverte du logiciel libre de recherche : 9 projets hébergés sur GitHub et un projet hébergé sur SourceForge. L’effet réseau social « on va ou il y a le plus de monde », et la portée internationale des projets justifient ce choix. Il faut cependant se souvenir qu’une forge commerciale peut disparaître en peu de temps : ce fût le cas pour la forge de google, Google Code, dont l’activité a cessé au bout de neuf années d’existence, en quelques mois. La même mésaventure est arrivée à la solution d’hébergement Gitorious. De plus, ces forges ont des conditions d’utilisation que chaque membre doit accepter à titre individuel et non au titre de son établissement.

Les forges auto-hébergées sont un moyen de minimiser ce genre de problème. Il peut cependant aussi arriver que la solution choisie ne soit plus maintenue, ou développée sous une licence libre : c’est arrivé avec le code de SourceForge, maintenu dans une version communautaire sous le nom de GForge, qui a lui même changé de licence, pour être maintenu dans une version communautaire sous le nom de FusionForge, pour arriver à un logiciel peu développé maintenant (la dernière version du logiciel date de 2018).

Le choix de l’auto-hébergement, et de la forge utilisée, n’est donc pas anodin. Sur les \nbforgestotal forges répertoriées, \nbforgesgitlab sont des instances de GitLab (les autres forges utilisent FusionForge, Gitea, Gogs, Redmine, Trac ou Tuleap). On peut expliquer cette domination de GitLab par sa simplicité d’installation et de maintenance et la richesse des fonctionnalités offertes.

L’intérêt de disposer d’une forge spécifique à l’Enseignement supérieur et de la Recherche, quelle que soit l’échelle (établissement, nationale, européenne, internationale) se pose donc. Les forges d’établissement apportent une réponse quand le développement est interne à l’établissement et qu’une forge d’établissement existe. On maîtrise dans ce cas les fonctionnalités offertes, et l’accès aux données, par contre cela n'autorise que très peu ou pas le développement entre plusieurs établissements. Quand une forge d'établissement n'existe pas ou n'offre pas aux porteurs de projets d'inviter des contributeurs externes, une forge nationale ou européenne permettrait d’offrir une alternative à l’utilisation des forges commerciales.

Au milieu des années 2000, une forge nationale, SourceSup, a été mise en place par RENATER pour dépasser ces restrictions d’interaction. Cependant, cette forge, qui représentait l’état de l’art lors de sa création, propose désormais à ses utilisateurs une collection d’outils qui sort des standards de développement actuels.

Cet état des lieux dresse le panorama des forges et pratiques existantes et met en avant un certain nombre d’observations et de points de vigilance sur la situation actuelle.

...

Introduction

Ce rapport porte sur les forges logicielles utilisées dans les établissements de l’enseignement supérieur et de la recherche (ESR). En particulier, il s'intéresse aux pratiques et aux besoins, en terme de génie logiciel, pour valoriser au mieux les productions logicielles issues de la science ouverte. L’objectif de ce document est de faire un premier état des lieux des forges logicielles utilisées dans l’Enseignement supérieur et la recherche français et d’identifier les moyens de rendre plus visibles les productions logicielles issues de la science ouverte.

Les forges logicielles sont principalement conçues pour gérer sur tout leur cycle de vie les différents artéfacts associés aux activités de génie logiciel, comme le code source, les fichiers binaires ou encore les documentations. Les forges peuvent aussi être utilisées pour la rédaction collaborative d’articles scientifiques ou de documentation, ou encore de pages web, à l’aide d’outils de transformation de fichiers textes faiblement structurés (par exemple, Markdown et AsciiDoc). Ces activités nécessitent de plus une intégration continue avec les outils de transformation, de déploiement et de publication ouverte du code source, de la documentation. Ce document n’est donc pas strictement limité au logiciel proprement dit, son code source et ses binaires, mais à la gestion de tous les artefacts produits et échangés pour produire un logiciel de qualité, partageable et réutilisable. Les forges logicielles sont aussi utilisées pour partager des données, des modèles, de manière collaborative. Leur usage impacte donc les trois piliers de la science ouverte.

Notons que cette analyse ne concerne que les besoins de l’activité recherche de l’Enseignement supérieur et de la Recherche. Elle ne concerne pas les besoins de forges en enseignement, ni ceux des outils de système d’information pour le fonctionnement des établissements. Il s’agit en premier lieu de faire un état des lieux des pratiques actuelles et des propositions d’actions afin de favoriser de bonnes pratiques de développement et de valorisation de la production logicielle. Cette proposition d’action s’appuie sur une analyse des limitations actuelles, et une première estimation des besoins communs.

Ce document structuré autour de trois chapitres précise pour tous le rôle des forges logicielles et dresse pour les publics avertis en développement logiciel un premier état des lieux des forges de l’Enseignement supérieur et de la Recherche et de leurs usages. Sur la base de l’analyse des limitations rencontrées par les établissements de l’Enseignement supérieur et de la Recherche, des premières pistes d’action sont suggérées.