forges-esr/etatdeslieux.md

De l'importance des forges

Développer un logiciel nécessite toujours la mise en œuvre de bonnes pratiques. En effet, quelles que soient les caractéristiques du logiciel à développer, il est toujours plus facile de démarrer avec des bonnes pratiques, que d'essayer a posteriori d'en instaurer. Quoiqu'il arrive, la qualité du logiciel n'en sera que meilleure. Un point important par exemple, mais pas suffisant comme nous le verrons plus tard, est la gestion des évolutions du code source. Elles doivent être systématiquement tracées avec un système de gestion de versions comme par exemple Git, Mercurial ou Subversion.

De nombreuses plateformes web, souvent appelées forges logicielles, comme par exemple BitBucket, Gitea, GitHub, GitLab, Gogs et ForgeJo, simplifient la mise en oeuvre de ces bonnes pratiques et facilitent le développement de logiciels de meilleure qualité, ainsi que la constitution de communautés de contributeurs et d'utilisateurs.

Des instances de ces plateformes peuvent être mises en place localement par des équipes de recherche, des laboratoires, des départements, voire même l’établissement d'appartenance ou par une infrastructure de recherche, comme Huma-Num pour les sciences humaines et sociales.

Les communautés de chaque plateforme peuvent apporter des bénéfices appréciables et participer à la recherche de bogues, à l'ajout de nouvelles fonctionnalités, à la contribution de documentation, etc.

Pour bénéficier de l’apport d’une communauté, il faut investir le temps et l’énergie nécessaires pour organiser son fonctionnement : fournir de la documentation sur les moyens et les possibilités de contributions, évaluer et gérer rapidement les suggestions et contributions apportées, planifier la feuille de route du développement logiciel, etc.

Voir [@codeetlogiciel] pour une discussion plus détaillée du sujet.

Surveiller l'évolution du code source

Le développement d'un logiciel, en particulier l'écriture de son code source (qu'on appelle programmation), est une activité itérative et incrémentale. Le code source d'un logiciel est amené à être modifié tout au long de son cycle de vie, et non pas juste à sa création. En effet, un logiciel évolue dans le temps : on parle de maintenance corrective quand il s'agit d'évolution dont l'objet est de corriger des bogues et de maintenance évolutive quand il s'agit de prendre en compte les évolutions de l'environnement d'exécution – évolution du matériel support, du système d'exploitation, des bibliothèques utilisées, etc. – ou d'introduire de nouvelles fonctionnalités.

Pour prendre en compte ces évolutions, il est d'usage de s'appuyer sur des outils qui peuvent enregistrer toutes les modifications faites à chaque étape de l'évolution du code : on les appelle des outils de gestion de versions (en anglais « version control systems » ou VCS). L'un des gestionnaires de versions les plus utilisés actuellement est Git.

Le gestionnaire de versions permet donc de suivre finement l'historique d'écriture d'un code, c'est-à-dire chaque contribution (les « commits »), de facilement comparer plusieurs versions du code du logiciel (les « branches »), et de formaliser des versions précises d'un logiciel (les « releases »).

Piloter tout le cycle de vie du logiciel

Le développement d'un logiciel de qualité ne s'arrête pas à la phase de réalisation du logiciel, c'est-à-dire la phase d'écriture du code. En effet, le code est certes un artefact important issu du processus de développement logiciel, mais les spécifications (aussi appelées « ensemble des exigences » ou encore « cahier des charges »), les modèles de conception, les tests, les documentations concepteur et utilisateur en sont d'autres tout aussi importants si l'on souhaite développer un code de qualité et pérenne dans le temps, c'est-à-dire maintenable, voire réutilisable.

Le gestionnaire de versions est donc l'un des outils à mettre en œuvre, mais pas le seul. Pour gérer tout le cycle de vie d'un logiciel, on a souvent besoin de gérer en plus les besoins des utilisateurs, de consigner les défauts constatés du logiciel, de produire des versions diffusables du logiciel, de lancer des tests périodiquement, de produire de la documentation, etc.

Pour faire tout cela, il est recommandé d'utiliser un ensemble d'outils intégrés au sein d'une plateforme souvent appelée « forge logicielle ».

Les forges peuvent être utilisées dès la création d'un logiciel, au sein d'un espace de travail privé. Quand le logiciel est prêt à être diffusé publiquement, il y a alors deux solutions : soit le projet devient public (et l'on peut consulter l'historique de son développement), soit un nouveau projet public est créé (avec un historique du développement vierge, l'ancien n'étant pas accessible).

Permettre et faciliter la collaboration

L'intérêt d'une forge est de favoriser la collaboration autour d'un logiciel, notamment par la collecte des défauts rencontrés dans son utilisation et le recueil des cas d'usage non couverts par le logiciel, mais aussi de permettre la contribution de code. Une personne peut contribuer au code en communicant un correctif ou une amélioration au projet, soit sous forme de « patch » (fichier contenant les changements apportés), soit en réalisant une requête de fusion des changements (une « pull request », PR, ou « merge request », MR, selon les plateformes). C'est aussi un moyen de conserver une copie du logiciel sur une infrastructure mutualisée, qui peut être archivée par Software Heritage quand il s'agit d'un logiciel dont le code source est public.

La forge permet aux auteurs du logiciel de gérer finement ces collaborations en choisissant les personnes autorisées à faire des contributions, via un système de gestion de droits.

Les exemples de logiciels libres de recherche à grand succès confirment que faciliter le plus possible les contributions est un levier très important pour permettre l'émergence d'une communauté de contributeurs. Une telle communauté peut alors décharger les créateurs initiaux du logiciel de diverses tâches de maintenance et de développement, et permet au logiciel de prendre son envol. Les obstacles tels que le parrainage ou la modération pour la création de compte peuvent freiner de manière importante (et invisible !) la venue de nouveaux contributeurs.

On trouvera dans [@bazaar] et [@cosssuccessful] par exemple des conseils généraux pour le développement de logiciels libres. Ils soulignent notamment l'importance de la collaboration dans ce contexte.

Construire le logiciel, analyser son code source

Une fonctionnalité que l'on retrouve souvent dans ces forges est l'« intégration continue » (ou « continuous integration », CI), c'est-à-dire la possibilité de construire le logiciel automatiquement à partir de ses sources. Il s'agit en quelque sorte de la garantie que la forge contient toutes les informations nécessaires pour construire le logiciel. Les technologies actuelles permettent de cibler simultanément diverses plateformes (multiples systèmes d'exploitation et architectures de processeurs).

Pour les développeurs, l'intégration continue permet aussi de tester le fonctionnement du logiciel au fur et à mesure des développements, d'éviter les régressions (perte ou mauvais fonctionnement des fonctionnalités existantes) et de disposer de métriques sur la « qualité » du code développé.

On peut classer les solutions de forges libres auto-hébergeables par le niveau de fonctionnalités offertes.

Typologie de forges

Niveau	Fonctionnalités	Exemples
0	Hébergement de code source versionné (pas de système de tickets ou de CI)	cgit
1	Niveau 0 + système de tickets et de revue de code	Redmine, Gerrit, Trac
2	Niveau 1 + système de pull/merge request	Gitea/Forgejo, Gogs
3	Niveau 2 + CI/CD, voire autres modules (GitLab pages, SourceHut pages)	GitLab, SourceHut, Tuleap

Au delà du code source

Si les forges ont été conçues au départ pour gérer le cycle de vie de logiciels, elles sont aujourd'hui utilisées dans un cadre plus large :

Publication et maintenance de sites web

à l'aide d'outils comme GitHub/GitLab/SourceHut pages ;

Rédaction d'articles scientifiques

en utilisant des outils de composition de documents tels que LaTeX, en passant éventuellement par un langage semi-structuré comme Markdown, AsciiDoc ou reStructuredText plus simple à appréhender comme source ;

Partage de données, de modèles

La gestion fine des contributions et la mise en ligne de contenu permet la création de communautés autour du partage de données, de modèles (voir par exemple la communauté HTR United).

Toutes les remarques suivantes sur le logiciel sont aussi valables pour ces usages.

Évolution du public visé par les forges

Il y a vingt ans, les forges étaient le lieu de rencontre entre les utilisateurs et les développeurs d'un logiciel. Basées sur la version libre de la forge sourceforge.net (telle que notamment la forge GForge), on y retrouvait deux fonctionnalités importantes pour les utilisateurs : le téléchargement des différentes versions du logiciel et des forums ou listes de diffusion pour demander de l'aide et interagir avec l'équipe de développement. La gestion du code source du logiciel était une fonctionnalité parmi d'autres. Il existait une séparation claire entre les membres de l'équipe de développement, qui avaient les droits de modification sur le code source, et les autres utilisateurs.

Les logiciels et les pratiques de développement ont évolué. Certains logiciels sont fournis sous forme de services, ce qui fait qu'il n'est plus nécessaire de les télécharger. Les bibliothèques sont diffusées par des entrepôts (maven, pip, npm, etc) qui sont couplés à des outils de gestion des dépendances. Des sites d'entraide comme StackOverflow deviennent des sources d'information alternatives aux forums officiels des logiciels.

Avec l'arrivée de GitHub en 2007, le positionnement des forges a changé : le code source est devenu central, c'est la première chose que l'on voit quand on arrive sur un projet. Toutes les discussions sont contextuelles, liées à des tickets ou des contributions. Avec la possibilité de créer très facilement une divergence (ou « fork «) d'un projet, le code source devient un bien commun, modifiable et diffusable par tous, ce qui favorise les contributions. On constate en parallèle l'émergence des environnements de développement en ligne, et la généralisation de l'intégration et du déploiement continus. Le public de la forge devient plus spécialisé : il faut déjà connaître les pratiques de développement pour s'y retrouver, alors que disparaissent les forums servant à poser des questions et permettre à la communauté d'y répondre.

À ce titre, il convient de noter que GitHub permet de nouveau depuis fin 2020 les échanges entre utilisateurs sans ouvrir de tickets à l'aide de la fonctionnalité « discussion ».

\begin{observation}{}{} La forge devient un réseau social de développeurs autour d’un bien commun : le code source. \end{observation}

Cas particulier du logiciel libre de recherche

Le logiciel libre de recherche est souvent issu d'une preuve de concept. Il n'a pas vocation initialement à être diffusé en dehors du monde académique, et n'a donc pas été conçu pour cela. L'un des enjeux de la science ouverte est de rendre visible cette production logicielle, en permettant aux laboratoires d'intégrer les bonnes pratiques qui leur permettront de rendre visible leur production logicielle à moindre effort.

\begin{observation}{}{} Le logiciel libre de recherche est conçu dans des laboratoires qui peuvent avoir des tutelles diverses. Les interactions doivent donc pouvoir se faire entre membres de ces différentes tutelles, ce qui signifie qu'idéalement, les personnels de ces différentes tutelles puissent avoir accès au même outil.\

Des logiciels sont parfois développés lors de projets collaboratifs qui peuvent inclure des entreprises. Il est important de pouvoir accueillir ce type de projets. Dans ce cadre, l'outil en question ne doit pas être limité au monde académique.\

Plus généralement, il est aussi important, pour certains projets, de pouvoir interagir avec des utilisateurs hors Enseignement supérieur et Recherche (collecte de retours via des « tickets », contribution de code, de documentation). C'est un facteur décisif pour qu'une communauté d'utilisateurs et de contributeurs puisse se développer autour de ces logiciels. \end{observation}

La modularité et la construction de logiciels par l'intégration de composants (c'est-à-dire d'autres briques logicielles), rendues disponibles grâce au cadre de la science ouverte et une diffusion libre, sont aussi des vecteurs facilitateurs de collaborations, disciplinaires comme interdisciplinaires.

Les logiciels libres de la recherche peuvent aussi servir de sujets d'étude pour les chercheurs en génie logiciel. Les rendre accessibles sur une forge bien identifiée favoriserait leur réutilisation dans ce cadre. De plus, en intégrant l’état de l’art en matière de génie logiciel (analyse statique de code, tests, assurance qualité, documentation, etc.), une forge académique permettrait à l'ensemble de la communauté de profiter des nouvelles avancées dans ce domaine.

La facilité de « reproductibilité » offerte par l'intégration continue (via des images d'environnements d'exécution maîtrisés) est aussi un aspect très important en science ouverte.

Favoriser l'utilisation d’outils standards faciliterait la formation et l’acculturation au sein des laboratoires. L'automatisation de tâches à l'aide de l'outil informatique est devenue une compétence importante dans toutes les disciplines académiques [@bestpracticesscientificcomputing]. La forge logicielle doit devenir un outil comme un autre dans la boite à outils des chercheurs et des ingénieurs.

Publics de l'ESR visés par les forges

Une forge peut être utilisée à différents moments d'un projet de recherche.

Lors du déroulement d'un projet, elle peut être utilisée pour le développement d'une preuve de concept. Ce travail peut être réalisé par des personnels ingénieurs ou chercheurs, qui peuvent être temporaires (stagiaires de recherche ou contractuels: ingénieurs et chercheurs doctorants ou docteurs) ou permanents. On créera dans ce cas un projet privé, pour lequel l'historique du gestionnaire de versions constituera un moyen commode de connaître la contribution de chacun au logiciel produit. C'est une pratique à encourager.

À un moment donné, pour tout projet se pose la question de diffuser les résultats obtenus, dont les logiciels font partie. Quand il s'agit de diffuser ces résultats sous forme de logiciels libres, plusieurs stratégies peuvent être mises en œuvre.

Une stratégie minimaliste est de diffuser le logiciel en l'état, sans favoriser outre mesure l'interaction avec d'autres groupes de recherche ou la société. On peut simplement diffuser le code exécutable du logiciel, par exemple en le rendant disponible sur une page web sous forme de fichier archive (.tar ou .zip). Cependant, un tel mode de diffusion limite l'impact de la mise à disposition, en rendant difficile les contributions.

Une stratégie plus volontariste est de diffuser le logiciel sur une forge, pour permettre des retours d'autres utilisateurs (notamment via un système de tickets). Il est alors préférable de réaliser en amont un effort de documentation sur le fonctionnement et la construction du logiciel, pour éviter des sollicitations fréquentes sur ces sujets. Il s'agit ici d'une véritable approche de valorisation du logiciel. De plus en plus de projets de recherche intègrent cet aspect durant le déroulement du projet.

Une stratégie accomplie est d'ouvrir le développement même du logiciel, pour faciliter les contributions d'autres développeurs (au travers des MR/PR). Il est alors pertinent de documenter le fonctionnement interne du logiciel pour faciliter la plongée dans le code, par exemple en rédigeant un « manuel de maintenance ». Il est aussi utile de documenter le processus de contribution : style de code attendu, processus de soumission de MR/PR, de relecture de code, fonctionnement de la CI, accord de cession de droits d'auteur, etc. Les forges permettent généralement de faciliter ce processus, pour favoriser les contributions. Cela peut être décisif dans la prise d'envol d'un projet logiciel, dont la maintenance et le développement peuvent alors être supportés par une communauté internationale (bénéficiant donc d'une puissance de travail importante), plutôt que la seule équipe de recherche à l'origine du logiciel (avec ses moyens limités).

Les forges utilisées pour le déroulement du projet et pour la valorisation du logiciel peuvent être différentes, afin de s'adapter aux besoins respectifs de ces deux versants.

\begin{observation}{}{} Il existe actuellement de nombreux logiciels libres issus de la recherche française qui sont développés depuis des années grâce à une communauté active et hébergés sur des forges commerciales. \end{observation}

Paysage des forges de l'ESR

Nous faisons le point dans ce chapitre sur le type de forges utilisées dans l'enseignement supérieur dans le cadre de la recherche. Si ce panorama n'est pas exhaustif, il permet de noter des tendances. Une analyse des raisons qui ont contribué a aboutir à cette situation est aussi proposée.

Utilisation importante des forges commerciales

La plupart des logiciels libres issus de l’Enseignement supérieur et de la Recherche et désireux d'interaction avec la société utilisent une solution d'hébergement commerciale ouverte à tous, comme github.com, gitlab.com ou sourceforge.net [@githubinpublications]. Il suffit de regarder les dépôts où sont hébergés les logiciels récompensés lors du prix science ouverte du logiciel libre pour s'en convaincre :

Première édition (2022) :

• Coq : https://github.com/coq/coq
• Coriolis : https://gitlab.lip6.fr/vlsi-eda/coriolis
• Scikit-learn : https://github.com/scikit-learn/scikit-learn
• Vidjil : https://github.com/vidjil/vidjil
• WebObs : https://github.com/IPGP/webobs
• Faust : https://github.com/grame-cncm/faust
• OpenVibe : https://gitlab.inria.fr/openvibe/meta.git
• Gammapy : https://github.com/gammapy/gammapy
• SPPAS : https://sourceforge.net/projects/sppas/
• Gama : https://github.com/gama-platform/gama

Seconde édition (2023) :

• Brian simulator : https://github.com/brian-team/brian2
• Fink : https://github.com/astrolabsoftware
• Hyphe : https://github.com/medialab/hyphe
• KeOps : https://github.com/getkeops/keops
• NoiseCapture : https://github.com/Universite-Gustave-Eiffel/NoiseCapture/
• OCaml : https://github.com/ocaml/ocaml
• PPanGGOLIN : https://github.com/labgem/PPanGGOLiN/
• Smilei : https://github.com/SmileiPIC/Smilei

La plateforme code.gouv.fr référence, au 11 février 2023, 9818 dépôts relevant de l’Enseignement supérieur et de la Recherche. 29 % de ces dépôts (2627) sont hébergés sur GitHub. Seulement 30 dépôts sont hébergés sur gitlab.com. Les autres solutions commerciales ne sont pas encore comptabilisées.

La plateforme Software Heritage permet d'avoir une idée du nombre de projets publics globaux trouvés sur les forges commerciales : 156 M pour GitHub, 4 M pour GitLab, 2 M pour Bitbucket, pour les plus utilisées début février 2023. On note que GitHub contient bien plus de projets publics que les autres forges.

Le principal intérêt de se tourner vers ces solutions pour un projet libre de l’Enseignement supérieur et de la Recherche est de faciliter les contributions de code ou de documentation en adoptant un modèle de « réseau social de développeurs ». En effet, pour les nombreux développeurs ayant un compte sur ces plateformes, contribuer à un projet public de ces forges se fait de manière très naturelle. C'est la raison pour laquelle des structures communautaires comme Eclipse par exemple ont décidé d'intégrer ces forges commerciales, alors qu'elles maintiennent aussi leur propre forge.

Cependant, les forges commerciales ne sont pas des solutions pérennes pour héberger des logiciels de la recherche. Ainsi, en août dernier, GitLab prévoyait d'archiver automatiquement les projets non actifs depuis un an [@gitlab2022], alors que certains logiciels matures peuvent avoir un cycle de développement plus lent et des périodes d’inactivité prolongées, sans que cela remette en cause leur utilité. Par le passé, on a pu voir la fermeture de forges commerciales comme Google Code [@googlecode] et même de services communautaires comme Gitorious [@gitorious] ou la suppression de centaine de milliers de projets suite à la décision de BitBucket de ne plus offrir d’hébergement pour les projets utilisant le système de contrôle de version Mercurial [@mercurial]. Ces fermetures ont conduit à la disparition d’un patrimoine important, concernant les historiques de modifications et les échanges de forums.

Les conditions d’utilisation des forges commerciales peuvent donc poser des problèmes dans ce contexte.

Enfin, les forges commerciales ne répondent pas forcément aux besoins de l'ensemble du cycle de vie d'un projet. L'utilisation de forges commerciales pour des projets privés doit se faire dans le respect de la réglementation européenne sur la protection des données, qui préconise que les serveurs soient hébergés sur le sol européen, et ne soient pas soumis à des législations extra-européennes (telles que : CLOUD Act, FISA 702, etc.). Plus d'informations à ce sujet sont disponibles sur le site de la CNIL.

\begin{observation}{}{} Les conditions d’utilisation des forges commerciales doivent être acceptées de manière individuelle par les personnels de l’Enseignement supérieur et de la Recherche pour leur permettre d’accéder à ces plateformes. Cela peut poser des problèmes si un personnel n’accepte pas ces conditions. \end{observation}

Utilisation des forges communautaires libres

Il existe de nombreuses communautés libres, comme la Free Software Foundation (FSF), et son projet GNU, Apache, Eclipse, OW2 et bien d'autres qui, en plus de leurs projets propres, accueillent des projets libres issus du monde de la recherche. Elles permettent de faire émerger des projets, en les accompagnant au delà du simple démarrage. Quand elles sont parties prenantes de ces projets, elles peuvent pérenniser les productions logicielles. Ces communautés peuvent aussi avoir leur propre positionnement concernant la science ouverte ; voir par exemple celui d'OW2.

Cependant, ces forges hébergent des projets mûrs, professionnels, qui ont vocation à être utilisés de façon large. Ces communautés décident des projets qu'elles hébergent et soutiennent, selon leurs critères propres. Il peut s'agir de la thématique du projet, de son niveau de maturité, de ses processus de développement ou de gouvernance, de son positionnement dans le monde économique ou sociétal.

\begin{observation}{}{} Les forges communautaires libres sont donc une solution pour des projets académiques qui ont obtenu une certaine visibilité, ou qui ont une stratégie de valorisation bien définie. Elles ne sont pas une solution pour le développement de preuves de concepts dans les laboratoires. \end{observation}

La forge d'OW2 peut cependant être utilisée comme forge d'expérimentation, via les « community user » c'est à dire les membres individuels, qui peuvent disposer de deux projets en leur nom propre. Ces projets individuels n'entrent pas dans le processus classique de soumission d'un projet communautaire.

Voici quelques exemples de logiciels des fondations OW2, Eclipse et du Projet GNU issus de la recherche publique :

• ASM (licence BSD) : https://asm.ow2.io/
• MPFR (licence GNU LGPL) : https://www.mpfr.org/
• OM2M (licence EPL) : https://www.eclipse.org/om2m/
• Papyrus (licence EPL) : https://www.eclipse.org/papyrus/
• Sat4j (licence GNU LGPL/EPL) : https://www.sat4j.org/
• SensiNact (licence EPL) : https://projects.eclipse.org/projects/technology.sensinact
• Spoon (licence CeCILL-C/MIT) : https://spoon.gforge.inria.fr

La forge nationale SourceSup

La forge SourceSup (https://sourcesup.renater.fr) a été mise en service en 2004 par RENATER. Il s'agissait à l'époque d'une instance de GForge. Ce service a basculé sous FusionForge en 2009, quand la solution GForge a cessé d'être libre. Cependant, la solution FusionForge n'est plus développée depuis quelques années (la dernière version majeure date de 2018). Des briques fonctionnelles supplémentaires ont été rajoutées en 2015 : MantisBT pour la gestion de tickets, Testlink pour la gestion des campagnes de tests, Sonarqube pour l'assurance qualité, Nexus pour la gestion d'artefacts, Jenkins pour l'intégration continue, et Nuxeo pour la gestion documentaire. L'infrastructure est virtualisée, selon un principe de séparation des applications gourmandes en ressources. Une personne assure la maintenance et le support de « niveau 2 » des briques logicielles. Le support de « niveau 1 » est mutualisé avec les autres applications RENATER.

En décembre 2022, la forge SourceSup contenait 762 projets publics sur plus de 5200 projets au total, et comptabilise plus de 13 000 utilisateurs.

Quelques exemples de projets hébergés sur SourceSup :

AGATTE :

Progiciel de gestion des congés, utilisé dans beaucoup d'établissements de l’Enseignement supérieur et de la Recherche

WIMS :

Logiciel d'enseignement interactif

OTAWA :

Cadriciel C++ pour déterminer le temps d'exécution au pire de cas de programmes.

La forge accepte des projets publics ou privés. Tout personnel de l’Enseignement supérieur et de la Recherche peut demander la création d'un projet. Cependant, les projets étudiants ne sont pas acceptés.

\begin{observation}{}{} L'évolution technique et fonctionnelle de SourceSup est décidée par le comité de direction de RENATER. Aucune évolution majeure de SourceSup n'est prévue à ce jour. \end{observation}

La solution SourceSup est actuellement assez différente des autres forges que l'on peut trouver dans l’Enseignement supérieur et la Recherche. Tout d'abord, elle a gardé son positionnement orienté utilisateur, avec ses listes de diffusion et ses forums (à la SourceForge). De plus, elle maintient un support de Subversion. En effet, de nombreux projets ont commencé avec ce gestionnaire de versions centralisé, qui était le plus utilisé avant l'apparition de Git. Si SourceSup permet d'utiliser Git comme gestionnaire de versions, comme les autres forges, il propose aussi d'utiliser Subversion.

SourceSup a fait le choix d'utiliser des outils de différentes provenances pour fournir tous les services nécessaires au développement de logiciels. Cette démarche détone par rapport à l'évolution des forges commerciales comme GitHub ou GitLab.com, mais aussi des forges auto-hébergées qui offrent désormais la plupart de ces outils au sein d'une seule et unique solution, afin de faciliter leur appropriation par les utilisateurs et leur maintenance par les établissements.

Le choix d'outils distincts permet une certaine forme de souveraineté, en maîtrisant finement les logiciels utilisés pour chaque besoin. Cependant, c'est aussi un frein à l'adoption de la forge par de nouveaux utilisateurs, qui ne retrouvent pas les outils qu'ils ont désormais l'habitude d'utiliser.

\begin{autre*}{la forge nationale éducative} Récemment, le ministère de l’éducation nationale et de la jeunesse a annoncé la création d’une nouvelle forge nationale, dite « forge des communs numériques éducatifs » :\

\textit{Par ailleurs, les communautés d’enseignants (et d’autres acteurs de l’éducation) peuvent également être des lieux de construction de nouveaux outils. Des professeurs, notamment de NSI ou de SNT, sont en attente d’une « forge » qui leur permettrait de collaborer entre pairs et de partager du code informatique. Le ministère répond dorénavant à ce besoin avec la mise à disposition d’une forge technologiquement souveraine et mutualisée à l’échelle nationale.}\

Cette forge est depuis l'automne 2023 déployée à l'adresse \url{https://forge.apps.education.fr/}. \end{autre*} Source : Stratégie du numérique pour l'éducation 2023-2027 (MENJ), page 25 [@strategiemenj]

\nbforgestotal forges publiques auto-hébergées dans l’ESR

En 2023, on compte au moins \nbforgestotal forges auto-hébergées publiques dans les établissements de l’Enseignement supérieur et de la Recherche, sans compter les forges à usage strictement interne des établissements.

La liste des forges répertoriées, disponible en annexe A, ne se veut pas exhaustive. Elle est issue, d’une part, des déclarations qui alimentent la plateforme code.gouv.fr et, d’autre part, du réseau de connaissance des membres du groupe de travail à l’origine de ce rapport à qui a été envoyé le questionnaire en annexe C. Il faut la considérer comme un recensement préliminaire qui, bien qu'incomplet, fournit d'ores et déjà des informations intéressantes pour le présent rapport. Bien qu'il puisse être intéressant de la compléter, il faut garder en tête les difficultés sous-jacentes à un tel recensement exhaustif. Il est par nature difficile de répertorier toutes les installations de forges, car celles-ci peuvent être opérées à divers niveaux : groupe de recherche, laboratoire, établissement, etc. Certaines de ces instances sont exclusivement dédiées aux usages internes d’un établissement de l'Enseignement supérieur et de la Recherche (celle de l’université d’Artois, par exemple), et ne sont donc pas répertoriées ici.

On peut noter, à la lecture de cette liste, que :

• les grands organismes de recherche nationaux disposent de leur propre forge ou sont sur le point d’en disposer ;
• des universités ou écoles proposent leurs forges, en séparant éventuellement l’enseignement et la recherche (comme pour CentraleSupélec par exemple) ou sur une granularité plus fine encore (l'université de Lille propose sa propre instance GitLab, le laboratoire CRIStAL la sienne et le département informatique de la faculté des sciences et technologies une autre).

\begin{observation}{}{} Beaucoup de forges auto-hébergées sont des instances de GitLab. Bien que GitLab soit un logiciel libre auquel chaque personne peut contribuer, il convient de s'interroger sur la dépendance que cela implique par rapport à la société GitLab Inc. qui, en pratique, en dirige le développement. \end{observation}

Analyse de la situation

Frise chronologique des forges mentionnées dans ce document

En avant propos, pour comprendre la situation actuelle, il est important d'avoir en tête les quelques dates clés liées aux forges logicielles que nous considérons :

• 1999 : apparition de SourceForge, la première forge de logiciels libres
• 2002 : apparition de GForge, l'alternative libre à SourceForge pour l'auto-hébergement
• 2004 : apparition de Git (logiciel libre de gestion de versions)
• 2007 : apparition de GitHub (forge commerciale basée sur git)
• 2011 : apparition de GitLab (logiciel libre fonctionnellement similaire à GitHub pour l'auto-hébergement de projets privés)
• 2012 : apparition de GitLab.com (forge commerciale basée sur le logiciel GitLab, projets privés)
• 2014 : GitLab.com auto-héberge son développement, devenant ainsi une alternative à GitHub

L'apparition d'une version libre du logiciel de SourceForge a permis la création des premières forges auto-hébergées. Quand la licence de diffusion en est devenue propriétaire, des forks issus de la communauté ont vu le jour (SourceForge/GForge/FusionForge par exemple). Des changements de technologie apparaissent régulièrement. La forge sourceforge.net utilise désormais le logiciel libre Apache Allura.

On peut noter, à la fin des années 2010, le passage de la technologie GForge/FusionForge vers GitLab pour l'auto-hébergement au sein de plusieurs structures. Les premières versions de GitLab ne permettaient que l'hébergement de projets privés. C'est en octobre 2013 (GitLab 6.2) que GitLab a introduit la notion de projet public, et qu'il est devenu une véritable alternative à GForge/FusionForge. En janvier 2014, le développement collaboratif de GitLab se fait à l'aide de GitLab.

Pourquoi tant de forges auto-hébergées ?

Il est difficile de répondre à cette question car il existe sans doute de nombreuses raisons à cet état de fait. Il est néanmoins possible d'avancer quelques éléments susceptibles d'expliquer cette situation.

Tout d'abord, on peut noter que la quasi-totalité des forges répertoriées sont des instances de GitLab. Ce logiciel est très simple à installer et à maintenir, et n'est pas gourmand en ressources informatiques. Il peut donc être facilement déployé dans un établissement à moindre coût, humain et financier.

Notamment, dans les universités ou les écoles d'ingénieurs possédant une spécialité informatique, ces forges sont nécessaires pour permettre l'apprentissage de leur utilisation dans un cadre pédagogique. Si dans certains établissements il existe une distinction entre forges d'enseignement et de recherche, ce n'est pas le cas dans d'autres.

Des forges sont également souvent déployées dans les laboratoires d'informatique, ces derniers ayant à la fois les compétences techniques pour mettre en place ces solutions et la connaissance des limites des solutions commerciales.

Le principal intérêt d'utiliser une forge auto-hébergée est de maîtriser la localisation des serveurs, et donc de respecter la législation européenne sur le traitement des données à caractère personnel (le RGPD) et de prendre en compte si nécessaire les enjeux de souveraineté (pour les projets privés ou pour les partenariats avec des industriels par exemple).

Un autre intérêt de l'auto-hébergement est de pouvoir maîtriser l'accès à ce service, son usage, les règles de diffusion des logiciels, etc. Cela permet à l'établissement de mettre en œuvre une politique propre concernant les logiciels de la recherche.

Enfin, d'un point de vue pratique, disposer de sa propre forge permet de centraliser soit le développement des logiciels, soit d'exposer l'ensemble de sa production logicielle en y installant systématiquement un miroir des projets hébergés sur d'autres forges. L'établissement peut ainsi avoir une vision globale de sa production logicielle.

On peut se demander pourquoi tant d'établissements du supérieur ont installé leur propre forge alors qu'une forge nationale, SourceSup, existe. Parmi les arguments qui peuvent être avancés, on peut citer son évolution technique hétérogène, l’absence de voix des utilisateurs dans le comite de pilotage, ou encore l’absence d’une stratégie de communication dans les deux sens (de SourceSup vers les utilisateurs, et des parties prenantes vers SourceSup). Cette trajectoire peut être mise en regard de l'histoire des autres forges, comme Inria dans l'Enseignement supérieur et la Recherche, ou OW2 et Eclipse dans les communautés libres. À Inria, après qu’une nouvelle forge basée sur GitLab a été mise en place, la forge Inria basée sur GForge a été arrêtée en décembre 2020, après une période de « tuilage » visant à assurer la migration des projets. Depuis janvier 2023, Inria dispose de deux instances de GitLab : une instance pour ses projets collaboratifs publics et une autre pour ses projets internes. Il en est de même pour OW2 : sa forge historique basée sur GForge a été remplacée par une instance de GitLab en 2018. Plus récemment, Eclipse a décidé de migrer vers GitLab sa plateforme technique éprouvée combinant Git, Gerrit et BugZilla. Denis Roy, de la fondation Eclipse [@eclipsegitlab], a justifié cette migration par les arguments suivants :

Kids born in 2005 are turning 17 years old this year. They've likely been using Eclipse at school. They've been using Eclipse at home to learn to code. They've been using Eclipse to hack Minecraft mods. And they use GitHub to pull code from. Some may even know how to fork a repo and submit a Pull Request.

If Eclipse projects want any hope of drawing those fresh young minds into their open source world, and turning casual explorers into productive contributors, it needs to be as simple as pulling a Minecraft mod. It needs to be on GitHub, or on a modern stack that works just like it, such as GitLab.

Pour résumer, les pratiques de développement ont évolué de façon significative, avec le passage rapide en quelques années des forges orientées utilisateurs aux forges orientées développeurs qui ont mis au centre de l’attention le code source et facilité l’adoption massive de l’approche de contribution via les forks et les pull requests ou merge requests.

\begin{observation}{}{} Un défi majeur pour une forge nationale est donc de surveiller activement les évolutions des usages et des solutions techniques, et d’engager les transformations nécessaires pour permettre d’offrir à tous les utilisateurs un environnement familier et cohérent avec les outils qu’ils utilisent lorsqu'ils collaborent sur d’autres projets logiciels. \end{observation}

C’est une tâche difficile, parce que, comme il a été dit, le développement logiciel est une activité qui dépasse largement la sphère de l'Enseignement supérieur et de la Recherche : les évolutions peuvent survenir à tout moment et les technologies évoluent vite.

En l’absence d’une stratégie ambitieuse dans ce sens, et au vu de la facilité d’installer des forges auto-hébergées récentes, on aboutit à la situation de fragmentation actuelle, caractérisée par une multitude de forges éparpillées dans les différents établissements.

Difficulté d'interaction avec la société

La principale limitation des forges disponibles actuellement dans l'Enseignement supérieur et de la Recherche est le fait que le public de ces forges (c'est-à-dire les personnes pouvant créer un compte) est limité : la plupart des instances de forges disponibles ne permettent pas à une personne extérieure à l'Enseignement supérieur et de la Recherche de créer elle-même un compte sur ces plateformes. Il existe donc un frein à l'interaction avec la société.

Si certaines de ces forges permettent la création de comptes externes, elles sont souvent difficiles d’accès (par exemple, pour gitlab.inria.fr, un compte externe doit être « parrainé » par une personne membre d’une équipe-projet Inria) et limitées (le compte externe GitLab ne permet pas de créer ses propres projets). Il est donc souvent impossible, ou à tout le moins très difficile, de proposer des changements avec ce genre de compte, car cela nécessite d'effectuer un fork du projet original, et donc de créer un projet propre sur la forge. Rapporter un bogue nécessite d’avoir obtenu un compte au préalable, ce qui peut être rédhibitoire.

Cela peut aussi avoir des conséquences fâcheuses avec d'autres communautés du logiciel libre de recherche. Par exemple, le Journal of Open Source Software, un journal qui évalue et publie environ 400 papiers courts et les logiciels correspondants par an nécessite que le logiciel soumis "soit hébergé à un endroit où les utilisateurs peuvent créer des tickets et proposer des changements de code sans validation manuelle ou paiement pour la création de compte". Cette politique a été mise en place car JOSS est intéressé par la mise en avant de logiciels qui peuvent être utilisés et maintenus par une large communauté. Un de ses critères d'évaluation concerne les lignes directrices de la communauté, et cela inclus "il doit y avoir des règles claires pour des tiers qui souhaiteraient : contribuer au logiciel ; remonter des dysfonctionnements ; demander de l'aide". Ces activités ne peuvent se faire si la forge ne permet pas une inscription automatique gratuite et ouverte à tous.

Par ailleurs, des projets tels que l'« Extreme-scale Scientific Software Stack » (E4S) intègrent dans leur politique la nécessité de pouvoir soumettre des contributions: « Public Repository: Each E4S member package will have a public repository, for example at GitHub or Bitbucket, where the development version of the package is available and pull requests can be submitted ». Le PEPR NumPEx envisage de s'inspirer de cette exigence pour faciliter l'intégration de sa pile logicielle, et considère notamment que gitlab.inria.fr n'est pour le moment pas assez ouvert pour ses besoins.

L'approche d'OW2 est pragmatique : elle permet à chacun de créer un compte sur sa plateforme, mais limite par défaut à deux le nombre de créations de nouveaux projets. Cela permet à un utilisateur d'un logiciel OW2 d'interagir facilement avec le système de tickets et de pouvoir proposer une contribution de code. Les gestionnaires de la forge ont pu constater que cette ouverture par défaut n'est pas une source de création de comptes fantômes. OW2 délègue cependant la création de comptes à son annuaire, et pas directement à sa forge.

RENATER propose la création d'un compte réseau universel (CRU) pour permettre aux personnes extérieures à l'Enseignement supérieur et de la Recherche d'accéder à ces services en acceptant ce fournisseur virtuel d'identité. Certaines forges permettent l'authentification à l'aide du compte CRU.

\begin{observation}{}{} En général, les logiciels de forge tels que GitLab ne permettent pas de limiter la création de projets à de simples contributions (c'est-à-dire à des \textit{forks} de projets de la plateforme). Il n'y a pas non plus de moyen d'empêcher un utilisateur de déposer des photos ou vidéos sur son espace de projet.

Or, permettre la création de projets à des personnes extérieures à l'établissement peut poser des problèmes juridiques, tels que de respect de \href{https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042031970}{la loi du 24 juin 2020 relative à la lutte contre les contenus haineux sur Internet}. \end{observation}

Une approche parfois mise en œuvre est l'authentification distribuée EduGAIN / Shibboleth, qui automatise la création de comptes et évite de multiplier les étapes d'authentification. Il faut cependant que l'institution qui gère l'authentification fournisse les informations nécessaires à la création du compte (identifiant utilisateur, adresse courriel). Certaines institutions utilisent une liste blanche de tiers autorisés : leurs utilisateurs doivent alors explicitement demander l'ajout à cette liste pour pouvoir utiliser cette authentification. Sans cela, un message d'erreur plus ou moins cryptique sera retourné (« Empty uid », « Email can't be blank », « Email is invalid », voire « 500 Whoops, something went wrong on our end »), déroutant complètement l'utilisateur. Il vaut mieux que l'institution utilise une page de consentement permettant à l'utilisateur de confirmer la demande immédiatement plutôt que d'avoir à deviner qu'il doit demander à sa DSI locale de l'ajouter à la liste blanche.

En février 2023, le support de Shibboleth a été supprimé de GitLab 15.9 car le composant Ruby fournissant cette fonctionnalité n'était plus maintenu. Cela empêche en pratique les montées de versions de nombreuses forges de l'Enseignement supérieur et de la Recherche à moins de modifier le code de l'application. Un appel à la communauté a été lancé pour mettre à jour ce composant. Une solution de contournement est de déléguer la gestion de Shibboleth à un système d'authentification unique. Le support de Shibboleth a été rétabli en juin 2023, dans GitLab 16.1, grâce à la communauté.

La limitation d'accès à une communauté complique aussi la gestion de comptes utilisateurs vis-à-vis de l'évolution de leur statut (départ de ou arrivée dans l'Enseignement supérieur et de la Recherche, l'institution ou le laboratoire).

La forge GitLab portée par l'infrastructure HumaNum étend cette approche « EduGAIN / Shibboleth » en permettant, grâce à son système d'HumanID, de s'authentifier, en plus d'eduGAIN, par son compte ORCID, HAL, Twitter, LinkedIN ou Google.

Un autre point compliqué à gérer, du fait de la possibilité de s'inscrire sur la plateforme sans validation, est celui des spams, qui sont mis en ligne via les fonctionnalités d'exemples de code et de tickets pour les projets publics.

En pratique, OW2 indique ne pas souffrir de spam sur son instance, car cette plateforme recourt à une création de compte indépendante de GitLab. Pour la fondation Eclipse, la situation est plus compliquée, notamment concernant leur service Wiki.

\begin{observation}{}{} Pour résumer, sur les multiples forges existantes dans l'Enseignement supérieur et de la Recherche, tant pour l’interaction entre personnels qu'avec la société, un problème essentiel à résoudre est la définition d’une politique d’accès cohérente qui maximise les interactions sans mettre en danger les infrastructures. \end{observation}

Niveau de support et besoin de confiance

Il peut exister une différence entre le niveau de support attendu d'une forge et le niveau de support fourni, notamment parce que ce support sera forcément comparé à celui des forges commerciales. Si dans la majorité des cas, le support fourni correspond au besoin, il peut arriver que des évolutions techniques doivent être mises en place pour rétablir des fonctionnalités face à l'évolution permanente de l'environnement technique.

Par exemple, sur les forges GitLab, l’intégration continue basée sur des images Docker est impactée par les changements de politique des registres d'images Docker (Docker Hub, registre d'images GitLab) qui limitent le nombre d'accès par machine et par jour. Par conséquent, chaque jour, au bout d'un certain nombre d'appels au registre Docker par l'intégration continue, les connexions peuvent être refusées et les intégrations continues échouer. Pour contourner ce problème, les mainteneurs de chaque instance doivent installer un registre local, qui sert de cache et réduit les appels aux registres publics à accès limités. Cependant, ces solutions ne sont pas mises en place de manière systématique. Pour l'utilisateur, pas forcément au courant de ces subtilités techniques, il en résulte une impossibilité de travailler sereinement.

\begin{observation}{}{} Plus généralement, il existe un besoin de confiance dans une plateforme qui soit robuste et pérenne, sur laquelle les usagers puissent compter dans le temps pour diffuser leurs travaux de recherche, quelle qu'en soit la forme. \end{observation}

Licence libre ou propriétaire ?

Les solutions disponibles pour l'auto-hébergement peuvent être diffusées sous licence libre ou sous licence propriétaire, dans ce dernier cas généralement avec plus de fonctionnalités ou de support. On peut citer par exemple la version « Ultimate » de GitLab, diffusée sous licence propriétaire, qui offre des fonctionnalités supplémentaires par rapport à la version diffusée sous licence libre.

La question du choix de la licence peut alors se poser : est-il avantageux d'utiliser la solution sous une licence non-libre pour bénéficier de plus de fonctionnalités ?

\begin{observation}{}{} Choisir un logiciel de forge sous licence propriétaire est un frein à l'ouverture de la forge. En effet, les licences d'utilisation non-libres sont généralement porteuses de certaines restrictions, telles qu'un nombre de comptes maximal et un périmètre d'utilisation limité. \end{observation}

Le choix d’une version payante peut cependant résulter de la volonté assumée de fournir aux entités éditrices de ces outils les moyens de poursuivre leur activité, gage de pérennité des solutions qu’elles proposent et donc des forges qui les utilisent. La fourniture sous licences fermées de certains de leurs codes et les modèles économiques « freemium » mis en place sont en effet pour ces entités le moyen de disposer de revenus récurrents à même de garantir les emplois de leurs développeurs.

La suite de ce chapitre va s'attacher à analyser l’usage courant de ces forges en mettant en avant trois grandes difficultés rencontrées dans leur mise en œuvre, à savoir l’organisation de la forge et de son cycle de vie, son périmètre et la gestion du droit d’auteur et des licences.

Points d'attention sur les forges

Lors de notre étude, nous avons noté un certain nombre de points d'attention lorsque l'on met en place une forge. Il n'y a pas de bonne ou de mauvaise façon d'utiliser une forge. Il s'agit plutôt de mettre en cohérence le fonctionnement des forges et leurs objectifs.

Vitrine ou simple outil ?

Il y a deux façons orthogonales de considérer le fonctionnement de ces forges.

La première est de considérer qu'il s'agit principalement d'outils, qui sont mis à disposition de la communauté. Il s'agit en l'espèce de favoriser les bonnes pratiques en donnant accès à des outils de qualité pour la gestion des projets. Cette vision semble correspondre à celle de la majorité des forges de l'Enseignement supérieur et de la Recherche.

La seconde, non exclusive, est de considérer que les projets publics sont la vitrine de la communauté, et que cette dernière a donc le droit et le pouvoir de décider ce qui est rendu public. Cette vision se retrouve essentiellement au sein des communautés libres (Apache, Eclipse, OW2¹).

Cependant, au sein de nombreuses forges, la création de projets publics n'est pas « validée ». On y retrouve donc des projets publics allant de « hello word » à une grosse application maintenue depuis des années. Cette hétérogénéité constitue un problème tant vis-à-vis de l'objectif de proposer une vitrine mettant en avant des projets d'une certaine « qualité », que de celui de lister la production logicielle d'une communauté. En revanche, ce n'en est pas forcément un si l'objectif principal est de favoriser l'usage d'un outil et des méthodes associées.

\begin{observation}{}{} L'absence de contrôle (ou le faible contrôle) des créations de projets peut rendre leur gestion compliquée. Il est difficile, voire impossible, pour les administrateurs de déterminer quels projets doivent être conservés ou pas. \end{observation}

Pour gérer plus finement les contenus d'une forge, il semble nécessaire de définir un processus et un cycle de vie des projets, par exemple en définissant un niveau de maturité (comme le Market Readiness Level proposé par OW2 par exemple). Chez Eclipse ou Apache, il existe la notion de « projet en incubation » pour les logiciels qui évoluent beaucoup. Eclipse propose également la notion de « train » qui inclut des briques a priori matures. Cette forge met également en œuvre la notion de « mentor », dont le rôle est de valider la création d'un projet.

Par ailleurs, et sans trancher entre la notion de simple outil ou de vitrine, il convient de noter que les forges, en regroupant les développements d'une communauté, d'une unité de recherche ou d'une tutelle, aident à suivre et à pérenniser l'activité de production logicielle de celles-ci. Les constructions de sites de référencement comme code.gouv.fr ou de l'archive universelle des logiciels Software Heritage se sont appuyées sur la fonctionnalité d'indexation offerte par les forges.

L'université de Strasbourg propose une approche intermédiaire sur son instance GitLab en permettant à tous les usagers de créer des projets publics mais en localisant dans un groupe particulier (community) les développements « officiels » de l'université.

Organisation des projets

\begin{observation}{}{} L'une des principales difficultés dans la gestion d'une forge est de savoir comment organiser les projets. Une solution peut être de créer un espace dédié pour chaque sous-structure (projet de recherche, équipe ou laboratoire), qui aurait la charge de la création de ses projets dans cet espace. Cette solution induit deux autres problèmes : où placer les projets communs aux sous-structures ? Comment gérer le cas des sous-structures qui n'ont pas de compétences ou de ressources internes pour assurer cette mission ? \end{observation}

Par exemple, au niveau de l'IRD, la gestion s'effectue en premier lieu par UMR, celles-ci déclarent ensuite des sous-projets. Sur demande argumentée, des racines peuvent être déclarées pour des projets de longue durée inter-UMR. Les projets sont accessibles par défaut aux utilisateurs connectés. L'IRD tend vers un principe d'ouverture aux personnes connectées dès le démarrage des projets afin de susciter des collaborations le plus en amont possible. Cette politique est en cours de réalisation mais intégrera probablement ces aspects.

Gestion du droit d'auteur

Si les développeurs du logiciel ont tous le même employeur, ou appartiennent tous à la même structure multi-tutelles, il n'existe pas de problème particulier pour la gestion des droits d'auteur.²

À l'inverse, dès que l'on intègre du code qui vient d'un développeur extérieur, il convient de se préoccuper de la gestion de ses droits d'auteur. Cela s'effectue généralement de deux manières : de façon légère, au moyen des Developer Certificate of Origin (DCO), ou de façon plus encadrée, au moyen des Contributor License Agreement (CLA). Indépendamment de la solution choisie, se pose la question du moment auquel le faire. Il faut que la situation soit claire au moment de la contribution du code, car cette information constitue un élément de décision pour l'intégration ou pas du code dans le logiciel.

Le demander à l'inscription sur la forge risque de décourager des personnes qui souhaitent simplement signaler un défaut. De plus, il faut vérifier régulièrement que le document choisi est toujours valable (notamment, parce que l'employeur du contributeur peut changer). Chez Eclipse, les contributeurs doivent revalider régulièrement leur Eclipse CLA.

Le demander avant une première contribution, par exemple pour pouvoir créer une MR/PR, peut faire peur à un développeur qui n'est pas habitué à ce procédé.

Le demander avant d'intégrer le code dans le projet est une pratique courante : le développeur sait à ce moment-là que son code est prêt à être intégré, et qu'il manque seulement pour cela le versant « administratif » du processus. Lorsque la contribution est extrêmement petite, ce processus peut être contourné, et la correction effectuée par les développeurs principaux, en mentionnant le contributeur dans le texte du commit.

Gérer un projet sur plusieurs forges

Il est possible de synchroniser des forges auto-hébergées (de l’Enseignement supérieur et de la Recherche) avec des forges commerciales (gitlab.com ou github.com). Cependant, on perd alors la centralisation des informations. Il est alors pertinent de désactiver le système de tickets publics, afin de conserver les tickets sur la forge locale, si la forge locale permet l’inscription libres de contributeurs externes (qui peuvent créer des tickets, mais pas proposer de contributions de code). Cette solution n’est cependant pas pratique pour les contributeurs, qui doivent utiliser deux comptes : un pour les alertes (tickets, rapports de bogues, et suggestions) et l’autre pour les contributions (de code, de documentations). Il est d’autant plus difficile de s’astreindre à cette discipline lorsqu’il existe un renouvellement important des contributeurs dans les projets de recherche.

La fondation Eclipse utilise plusieurs forges (l'une auto-hébergée, d'autres commerciales). Même si un miroir est mis en place entre les forges, chaque projet est géré sur une seule forge, pour éviter les problèmes évoqués.

Pour faire face à cette limitation, il faut noter des initiatives en cours visant la fédération des forges. Par exemple, on peut citer les travaux réalisés dans le cadre du projet open-source Forgejo, une alternative communautaire à GitLab et GitHub, visant à spécialiser le protocole ActivityPub issu des travaux plus génériques autour de la fédération des univers Fediverse avec ForgeFed. Une implémentation de ce standard dans Forgejo devrait voir le jour en 2024. Le support de ce protocole est aussi en cours d'implémentation dans GitLab. L’initiative ForgeFriends va également dans ce sens.

Nous ne pouvons pas conclure ce chapitre sans souligner un besoin montant qui devient de plus en plus présent et important, l’intégration continue.

Toujours plus de services en intégration continue

La gestion d'un projet logiciel n'est pas la seule fonctionnalité attendue d'une forge. Offrir une documentation à jour est important, et disposer de moyens de publication de sites web à partir d'une forge est un atout supplémentaire (par exemple, le service « GitHub/GitLab/SourceHut Pages »). De plus, de nombreux outils basés sur l'analyse du contenu des dépôts peuvent s'avérer importants pour la maintenance du logiciel :

• analyse de la compatibilité juridique des licences du logiciel et de ses composants ;
• détection de composants possédant des vulnérabilités connues ;
• détection de vulnérabilités dans le code produit ;
• détection de mauvaises pratiques de développement dans le projet ;
• etc.

La plupart de ces fonctionnalités sont basées sur la possibilité de faire de l'intégration continue, c'est-à-dire de déclencher l'exécution de programmes en fonction de certains événements ou sous certaines conditions, comme par exemple à chaque mise à jour du code.

Le besoin de sobriété énergétique du numérique implique que cette intégration continue soit configurée de manière à limiter les déclenchements inutiles. Des tests rapides sont généralement exécutés à chaque changement, et des traitements par lots peuvent être exécutés à des temporalités différentes selon les outils utilisés : chaque nuit ou chaque semaine par exemple, voire chaque mois. Un filtrage des tests lancés peut également être opéré selon les fichiers effectivement modifiés.

Il faut noter que les machines utilisées pour gérer l'intégration continue partagée d'une instance GitLab de l'Enseignement supérieur et de la Recherche sont généralement plus puissantes que celles utilisées par l'instance GitLab elle-même. En effet, si une modification de code va mobiliser le serveur GitLab quelques secondes au maximum, son intégration continue peut nécessiter plusieurs minutes, voire plusieurs heures, d'exécution. C'est donc une fonctionnalité qui passe difficilement à l'échelle sans une architecture adéquate, permettant d'adapter les ressources disponibles à la demande, et donc demande des moyens conséquents.

De plus, mettre en œuvre du déploiement continu, c'est à dire la mise en production automatique du logiciel dans un environnement donné, nécessite une architecture plus sophistiquée, qui permet d'accéder de manière sécurisée à ces différents environnements dynamiques.

La solution préconisée à l'heure actuelle se base généralement sur l'utilisation de conteneurs qui permettent de déployer des ressources d'intégration continue à la demande, et d'en faciliter la mise à niveau.

Des questions techniques supplémentaires doivent être traitées, telles que la signature des logiciels pour permettre leur installation sur des systèmes d'exploitation récents sans avoir à changer leur niveau de sécurité. Mutualiser cet effort permettrait de diffuser plus facilement dans la société des logiciels issus de la recherche.

\begin{observation}{}{} Être capable de maintenir une telle architecture sur la durée nécessite des ressources et des compétences particulières, qu'il est pertinent de mutualiser. \end{observation}

Proposer des ressources d’exécution, souvent appelées runners, pour l'intégration continue pose des questions de sécurité et de risque de mésusage. Les forges commerciales ont réduit ou simplement désactivé les comptes qui permettent d'utiliser gratuitement du temps CPU sur des runners.

Récapitulatif des solutions

Les matrices SWOT suivantes résument les forces et faiblesses des différents types de forges actuellement disponibles pour diffuser du logiciel libre ou tout autre artefact issu de la recherche, du point de vue de l'usager de ces forges.

Forges externes commerciales

On considère ici les forges telles que github.com, gitlab.com, bitbucket.org, sr.ht, etc.

\tcbset{arc=0mm,width=\linewidth/2, before=,after=\hfill,fonttitle=\bfseries,box align=top} \newtcolorbox{myforces}{coltitle=black,colback=bar-color2!15!white,colframe=bar-color2,adjusted title=Forces} \newtcolorbox{myfaiblesses}{colback=bar-color1!15!white,colframe=bar-color1!80!black,adjusted title=Faiblesses} \newtcolorbox{myopportunités}{coltitle=black,colback=box-color1!15!white,colframe=box-color1,adjusted title=Opportunités} \newtcolorbox{mymenaces}{coltitle=black,colback=box-color2!15!white,colframe=box-color2,adjusted title=Menaces}

\begin{myforces} \begin{itemize}[leftmargin=0in] \item Intégration des fonctionnalités «tout en un» \item Gratuité d'un ensemble de fonctionnalités de base \item Disponibilité acceptable pour la plupart des projets \item Pour GitHub~: une ergonomie devenue familière \item Pour sr.ht~: un support humain très réactif \item Visibilité internationale \item Communauté internationale \end{itemize} \end{myforces} \begin{myfaiblesses} \begin{itemize}[leftmargin=0in] \item Dépendance à l'égard de la politique commerciale de la société \item Pas de contrôle sur les ressources allouées aux fonctionnalités \item Pas de possibilité d'être associé aux décisions stratégiques \item Non souveraineté \item Pas de garantie de pérennité \end{itemize} \end{myfaiblesses} \begin{myopportunités} \begin{itemize} \item Nombreuses ressources disponibles pour la formation à ces outils \end{itemize} \end{myopportunités} \begin{mymenaces} \begin{itemize}[leftmargin=0in] \item Dépendance à la réglementation du pays ou siègent ces sociétés \end{itemize} \end{mymenaces}

\newpage

Forges externes communautaires

On considère ici les forges de fondations comme Apache, Eclipse, OW2 ou la FSF.

\begin{myforces} \begin{itemize}[leftmargin=0in] \item Fonctionnalités \item Disponibilité \item Support \item Pérennité \item Visibilité au niveau de la communauté \item La communauté elle même \end{itemize} \end{myforces} \begin{myfaiblesses} \begin{itemize}[leftmargin=0in] \item Nécessité d'acceptation du projet par la communauté \item Non couverture de toutes les thématiques par les communautés de logiciels libres \end{itemize} \end{myfaiblesses} \begin{myopportunités} \begin{itemize}[leftmargin=0in] \item Promotion de son projet dans un écosystème \item Bénéfice d'un accompagnement méthodologique \item Bénéfice de la confiance accordée à la communauté pour son propre projet \end{itemize} \end{myopportunités} \begin{mymenaces} \begin{itemize}[leftmargin=0in] \item Dépendance à la réglementation du pays ou siègent ces fondations/associations \end{itemize} \end{mymenaces}

Forges auto-hébergées à l'échelon local

\begin{myforces} \begin{itemize}[leftmargin=0in] \item Fonctionnalités sur mesure \item Disponibilité sur mesure \item Souveraineté \item Résilience \item Support (dépend des instances) \item Pérennité (dépend des instances) \item (Proximité) \item Visibilité au niveau de l'institution \item Communauté au niveau de l'institution \end{itemize} \end{myforces} \begin{myfaiblesses} \begin{itemize}[leftmargin=0in] \item Disponibilités (dépend des instances) \item Support (dépend des instances) \item Multiplicité des solutions disponibles \item Difficulté d'accès en dehors de l'institution porteuse \end{itemize} \end{myfaiblesses} \begin{myopportunités} \begin{itemize}[leftmargin=0in] \item De facto, catalogue institutionnel de logiciels \item Mise en œuvre d'une politique institutionnelle de développement des logiciels de recherche \item Expertise maintenue au niveau de l'institution \item Diffusion de bonnes pratiques \end{itemize} \end{myopportunités} \begin{mymenaces} \begin{itemize}[leftmargin=0in] \item Evolution de la solution choisie (périmètre des fonctionnalités sous licence libre vs fonctionnalités devenant payantes) \item Expertise difficile à trouver nécessaire pour maintenir la solution au niveau de l'institution \end{itemize} \end{mymenaces}

Forge auto-hébergée à l'échelon national

\begin{myforces} \begin{itemize}[leftmargin=0in] \item Fonctionnalités \item Disponibilité \item Support \item Souveraineté (projets publics) \item Pérennité \item Sobriété \item Visibilité nationale \item Communauté nationale \end{itemize} \end{myforces} \begin{myfaiblesses} \begin{itemize}[leftmargin=0in] \item Souveraineté (projets privés) \item Ouverture en dehors du cadre national \end{itemize} \end{myfaiblesses} \begin{myopportunités} \begin{itemize}[leftmargin=0in] \item De facto, catalogue national de logiciels \item Mise en œuvre de préconisations nationales pour le développement de logiciels de recherche \item Mutualisation de l'effort de maintenance \item Soutien par une politique publique globale \end{itemize} \end{myopportunités} \begin{mymenaces} \begin{itemize}[leftmargin=0in] \item Evolution de la solution choisie (périmètre des fonctionnalités sous licence libre vs fonctionnalités devenant payantes) \end{itemize} \end{mymenaces}

\newpage

Conclusion

Les pratiques de développement logiciel ont profondément évolué, avec la généralisation de l'usage d'outils qui permettent de fluidifier grandement la collaboration sur des projets logiciels. Cela a progressivement conduit à transformer les forges en réseaux sociaux de développeurs, et la facilité d'intégrer la contribution de collaborateurs, même occasionnels, est devenue un facteur clé pour accompagner l'essor des logiciels libres et la création de communautés autour d'eux. Au delà du logiciel, les forges sont aussi utilisées pour la rédaction d'articles ou la gestion communautaires de données ou de modèles.

Dans ce contexte, le monde de la recherche a besoin d’une forge a minima ouverte sur l’ensemble de l'Enseignement supérieur et de la Recherche, et idéalement ouverte sur la société toute entière.

S’il existe bien une forge nationale pour l'Enseignement supérieur et la Recherche, SourceSup, son évolution fonctionnelle a divergé des pratiques d’une bonne partie des développeurs de l'Enseignement supérieur et de la Recherche, et aucune évolution majeure n'est prévue à ce jour ; sous sa forme actuelle, elle ne répond donc plus aux besoins exprimés.

La disponibilité de solutions sous licences libres pour installer des forges qui intègrent les fonctionnalités attendues, et leur facilité d'installation et de maintenance, ont fait qu'il existe actuellement au sein de l’Enseignement supérieur et de la Recherche de multiples forges maintenues par des individus, des équipes, des laboratoires ou des établissements. Sur ces forges, tant pour l’interaction entre personnel de l’Enseignement supérieur et de la Recherche qu’avec la société, un des problèmes essentiels à résoudre est la définition d’une politique d’accès cohérente qui maximise les interactions sans mettre en danger les infrastructures.

Pour résoudre ces difficultés, de nombreux logiciels libres issus de la recherche française ont dû migrer ailleurs. Pour des projets académiques qui ont obtenu une certaine visibilité, ou qui ont une stratégie de valorisation bien définie, une alternative est offerte par les forges maintenues par des communautés de logiciels libres, mais cette piste n'est pas exploitable pour des logiciels qui sont à l'état de preuves de concepts dans les laboratoires.

Beaucoup de projets se retrouvent donc sur des forges commerciales, qui permettent la création de projets sans restriction, mais leur usage nécessite que des personnels de l’Enseignement supérieur et de la Recherche acceptent individuellement leurs conditions d'utilisation, pratique qui peut poser problème, d'autant que les forges commerciales n'offrent aucune garantie de pérennité.

Tous ces enjeux doivent être pris en compte de façon globale.

D'un coté, s'expriment les besoins des personnels de l’Enseignement supérieur et de la Recherche qui développent des logiciels de recherche :

• une forge dans laquelle ils puissent avoir confiance : robuste et pérenne, sur laquelle il doit être possible de compter dans le temps pour diffuser ses travaux de recherche, quelle qu'en soit la forme ;
• une forge qui évolue avec l'état de l'art : il doit être possible d'y retrouver des outils d'un niveau comparable à ceux mis à disposition des développeurs sur d'autres forges ;
• une forge qui permette de construire et faire croître facilement la communauté de contributeurs : l’inscription et la création de projets doit être facile, et son usage simple et ergonomique ;
• une gestion simplifiée des démarches liées à la propriété intellectuelle.

De l'autre, se posent les défis à relever par qui doit fournir ces services :

• l’absence de contrôle (ou le faible contrôle) des créations de comptes et de projets sur une forge est importante pour la création de communautés, mais peut rendre leur gestion compliquée, et induit des risques techniques et juridiques pour les infrastructures. Il devient difficile, voire impossible, pour les administrateurs de déterminer quels projets doivent être conservés ou pas, et faire le tri entre usages normaux et abusifs peut demander des ressources conséquentes ;
• le suivi de l'évolution technologique, et des usages, nécessite une activité de veille, et la capacité opérationnelle de déployer des nouvelles solutions, y compris à titre expérimental, tout en maintenant les anciennes en production, y compris dans le cadre de « tuilages » ;
• fournir un service à une communauté très large nécessite de réfléchir à l’organisation des projets sur cette forge, en particulier pour des projets multi-tutelles, et à la mise en œuvre pratique d'une telle politique dans des laboratoires ayant des compétences hétérogènes ;
• faciliter les collaborations entre établissements de l’Enseignement supérieur et de la Recherche pourrait nécessiter la mise en place d'une gestion des droits mutualisée au sein d'une fédération d'identités.

Enfin, ce sujet possède des enjeux stratégiques majeurs : les forges logicielles commerciales n'apportent pas de garantie de pérennité, et les plus populaires d'entre elles sont soumises à des juridictions extra-européennes. Chaque base de code qui est déposée sur une forge commerciale offre un aperçu très en amont sur les activités de recherche et industrielles des personnels des pays déposants (dans le cadre des projets privés), vient enrichir les données sur lesquelles la plateforme s'appuie pour l'apprentissage des outils d'aide à l'écriture de code (OpenAI Codex/GitHub copilot, GitLab suggestions, etc.), et donc contribue à la domination des GAFAM sur le numérique. La maîtrise de l’usage du code issu de nos laboratoires constitue en cela un enjeu majeur de souveraineté.

Il est urgent d'apporter une réponse réfléchie et coordonnée à l'ensemble des besoins et défis exprimés. Déployer une forge auto-hébergée est relativement facile, mais la maintenir à l’état de l’art sur la durée en termes d’infrastructure et de fonctionnalités, mettre en place des politiques d'accès et d'organisation des projets, suivre et accompagner les usages, et éviter les abus nécessite des ressources et des compétences particulières, qu'il est nécessaire de mutualiser.

---

1. OW2 permet cependant la création de deux projets personnels publics pour chaque utilisateur. ↩︎

2. On suppose ici que l’employeur bénéficie du transfert de la titularité des droits des différents contributeurs, et que les employés sont autorisés à publier en open source le code qu'ils produisent. ↩︎