Introduction aux forges logicielles dans l’ESR

Sébastien Rey Coyrehourcq (UMR IDEES 6266)

Rouen

20/01/2026

historique, enjeux et usages de ces objets pluriformes

V0.1

Technique

Humain

Bernard Stiegler a été une figure marquante des sciences humaines à l’UTC. Philosophe des techniques, il a développé une réflexion riche et profonde autour de l’idée de “constitutivité technique de l’humain”.

[...]

“On parle de “TAC” ou technologie anthropologiquement constitutive. Ce qui veut dire qu’être humain, c’est être un être technique, et ce, depuis toujours. L’évolution humaine, depuis la nuit des temps, s’est faite dans un environnement technique.

[...]

Autrement dit, il n’y a pas d’un côté l’Homme qui donne du sens et de l’autre la technique qui ne refléterait, pour ainsi dire, que des conditions matérielles.

Au contraire, c’est notre environnement technique qui nous fait “être humain”, supporte notre pensée, supporte notre conscience du temps qui n’existerait pas sans nos médiations techniques et notre environnement technique.

Cadre de réflexion

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 (nldr : rapport sur les forges logicielles dans l'ESR) 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.

Forges (et Logiciels ! ) à l'ESR

Collège "Codes Source et Logiciels"

1er usage (historique) : Logiciels et Artefacts associés

2ème usage ( plus récent ) : Généralisation à tout ce qui peut être versionné, y compris hors logiciel

 Les logiciels de recherche sont développés pour répondre à des besoins spécifiques de la science. Ils sont conçus, maintenus, et utilisés par des scientifiques (chercheurs et ingénieurs) et institutions de recherche, éventuellement dans une dimension internationale. Ils peuvent découler de travaux de recherche comme ils peuvent les favoriser, notamment par des publications avant/sur/autour/avec le logiciel. Ceux-ci peuvent se formaliser de différentes façons (une plateforme, un intergiciel, un workflow ou une bibliothèque, module ou greffon d'un autre logiciel) et être ainsi en interaction dans un écosystème ou au contraire plus autonomes.

Le logiciel de Recherche, des définitions :

Research Software includes source code files, algorithms, scripts, computational workflows and executables that were created during the research process or for a research purpose. Software components (e.g., operating systems, libraries, dependencies, packages, scripts, etc.) that are used for research but were not created during or with a clear research intent should be considered software in research and not Research Software

Les logiciels de recherche diffèrent par nature des données de la recherche

Forges (et Logiciels ! ) à l'ESR

Une problématique complexe, des acteurs en réseaux

Quels sont les différences avec "le Logiciel en général", en dehors du contexte scientifique ?

Et au fait, c'est quoi exactement un Logiciel de façon plus précise ?

En quoi le Logiciel ne serait pas de la "donnée" comme une autre ?

... etc ...

Forges (et Logiciels ! ) à l'ESR

"Code source et Logiciels"

1er Plan

National SO

2ème Plan

National SO

(+ volet logiciel)

Loi République du Numérique

2016

2017

2018

2021

2022

2023

Collège National du COSO

"Code source et Logiciels"

Thématiques de travail du collège

Exemple de production

Code Beyond FAIR : CODE roadmap

Feuille de route générale

Feuille de route pour les acteurs

Le cas des "Forges" dans l'ESR

Analyse et nomination d'un Référent National !

contact-national-forges@groupes.renater.fr

Historique

Définitions

Analyses des besoins et des limites

Enjeux et Perspectives

Catalogage

Typologies de solution (SWOT)

Le cas des "Forges" dans l'ESR

Frise chronologique issue du rapport

Ce que l'on voit

- Propriétaire vs Libre

- Nationale vs Locale

- Changement de status

- Migrations 

- Diversification des acteurs

- Recomposition / Fork

- Forge SAS (software-as-a-service) privé ou communautaire

Riche d'informations de natures différentes

Première forge ESR Nationale : SourceSup Renater

- Orienté Social vs Projet 

Le cas des "Forges" dans l'ESR

Recensement et Catalogage (WIP)

Les Forges logicielles

ESR

Radiographie d'une forge logicielle

Dispositif technique

SSH

WEB

SERVICES

Architecture de Gitlab, version simplifiée

VERSIONNEMENT

Les 3 blocs essentiels

Une forge est un agglomérat de logiciels à la fois interne et/ou externe

Tour (rapide) d'horizon d'une forge

Le cas de GitLAB 

Gitlab est une entreprise commerciale, avec 2 distributions :

- CE "Open Source" gratuite auto-hébergeable

- EE Entreprise

- A) à destination des humains (tickets, wiki, kanban, groupes et rôles, pages, etc.)

- B) à destination du contenu versionné ( Intégration Continue, Dépôts d'Images et d'Artefacts)

GitLab est une distribution logicielle de Forge la plus fréquemment auto-hébergée au sein de l'ESR, à l'échelle locale et/ou nationale :

Gitlab propose son propre hébergement : gitlab.com

Gitlab est encore l'alternative principale(*) face à Github avec une

quasi équivalence des outils :

(*) L'alternative communautaire forjego/codeberg progresse, et pourrait devenir un autre premier choix dans un avenir proche 

- Huma Num : https://gitlab.huma-num.fr/

- Forge Edu ministère EN : https://docs.forge.apps.education.fr/

- Inria : https://gitlab.inria.fr/explore/projects

- Inrae : https://forge.inrae.fr/explore/

- Cirad : https://gitlab.cirad.fr/explore

...

Tour d'horizon d'une forge

Accueil de la forge

Page de login ...

Tour d'horizon d'une forge

Accueil de la forge

... ou Page explore, plus ou moins directement ...

Tour d'horizon d'une forge

Exemple d'une vue projet

https://gitlab.huma-num.fr/ecrinum/pressoir

groupe

dépôt versionné

A

C

B

D

Tour d'horizon d'une forge

Le dépôt et les fichiers versionnés

A

A.1

A.2

C

status de l'intégration continue

historique des modifications

téléchargement du dépôt ou du code

branche

dernière date de modification d'un fichier

A.3

Tour d'horizon d'une forge

Le dépôt et les fichiers versionnés

A.2

téléchargement du dépôt git avec l'historique des révisions

téléchargement du code source uniquement

Tour d'horizon d'une forge

L'historique des révisions

A

A.1

date de la révision

auteur.rices

status de l'intégration continue

numéro (hash) unique correspondant à la révision

A.1.1

contenu de la révision

Tour d'horizon d'une forge

Détail d'une révision

A

A.1.1

Nom de la révision

Numéro de la révision d'avant

status de l'intégration continue

numéro (hash) unique correspondant à la révision

liste des modifications fichier par fichier

vert = ligne ajouté

rouge  = ligne supprimé

Tour d'horizon d'une forge

Information synthétique sur le dépôt

A

B

nombre de branches

A.1

renvoie vers  l'historique des révisions

tags fixés à des révisions

License

Pages web hébergé sur la forge attachés au dépôt :

https://ecrinum.gitpages.huma-num.fr/pressoir/

A.3

Tour d'horizon d'une forge

Le script pour le Déploiement Continu (CD Continuous Delivery)

A

A.3

instructions pour le Runner (la machine qui va executer le script)

construction et  déploiement de la page web

déploiement de l'environnement logiciel pour construire le site web

Le déploiement continu (CD) est un processus de livraison de logiciels qui utilise des tests automatisés pour valider si les changements apportés à une base de code sont corrects et stables en vue d'un déploiement autonome immédiat dans un environnement de production.

Tour d'horizon d'une forge

A

D

Accès aux informations et aux outils de configuration pour ce dépôt ( fonction des restrictions )

Gestion des membres

Tickets / Wiki / Jalons /etc ... 

D.1

Info sur le système de revision 

Info sur le déploiement continu

Info sur les artifacts construits et stockés

Tour d'horizon d'une forge

A

D.1

Système de Tickets

Détail d'un ticket en cours 

D.1.1

Status du ticket

Tour d'horizon d'une forge

A

D.1.1

Détail d'un Ticket

Activités Sociales

1) Esquisser un peu ce qu'est l'ingénierie logicielle ("faire du logiciel") et d'ou cela vient ?

2) Comprendre pourquoi le versionement se trouve au coeur de ce processus ?

Problème !!

Renseigne seulement statiquement et partiellement sur les activités supportées par la forge

Back to the past

Pour aller plus loin (introduction, pratique) :

- Formation de l'Ecole Doctorale HSRT & Atelier Données Normandie :

1 jour et demi à Rouen le 27/28 avril : Git + Forge

1960's

Software Engineering

Margaret Hamilton se tenant auprès du code du logiciel de navigation qu'elle et son équipe ont produit pour le programme Apollo.

I fought to bring the software legitimacy so that it—and those building it—would be given its due respect and thus I began to use the term 'software engineering' to distinguish it from hardware and other kinds of engineering, yet treat each type of engineering as part of the overall systems engineering process. When I first started using this phrase, it was considered to be quite amusing. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. Software eventually and necessarily gained the same respect as any other discipline.

M. Hamilton rentre à la NASA en 1965, après 3 ans à travailler sur le projet SAGE.

1960's

Software Engineering

La programmeuse Madeleine Carey en 1955 devant 62 500 cartes perforées (~5mb) contenant le programme d’un système de défense aérienne SAGE (Semi-Automatic Ground  Environment) utilisé sur un ordinateur d’IBM.  

The Semi-Automated Ground Environment (SAGE) was a system of networked computers used to coordinate data from many radar stations, and collate it into one unified picture.

 

The SAGE development project started in 1953, and went operational in the late 1950’s. Developing the SAGE software was a huge undertaking at the time. It was the first software development project large enough to require a software development methodology, so the engineers at SAGE created one.

1960's

Software Engineering

A concern with the science of computing and information processing, while undeniably of the utmost importance and an historic root of our organization [i.e. the ACM – BM] is, alone, too exclusive. While much of what we do is or has its root in not only computer and information science, but also many older and better defined sciences, even more is not at all scientific but of a professional and engineering nature.

We must recognize ourselves – not necessarily all of us and not necessarily any one of us all the time – as members of an engineering profession, be it hardware engineering or software engineering, a profession without artificial and irrelevant boundaries like that between ‘scientific’ and ‘business’ applications

Anthony A. Oettinger

1960's

Nato's Conferences

In the fall of 1968 and again the in fall of 1969, NATO hosted a conference devoted to the subject of software engineering. Although the term was not in general use at that time, its adoption for the titles of these conferences was deliberately provocative.

 

As a result, the conferences played a major role in gaining general acceptance, perhaps even premature, for the term. The motivation for these conferences was that the computer industry at large was having a great deal of trouble in producing large and complex software systems.

50 ans en 2018

Software Engineering

DEFINED PLAINLY, SOFTWARE engineering is the building of nontrivial software-intensive systems in disciplined ways subject to a set of constraints. It’s widely recognized as a sociotechnical process.

On the social side, it involves a significant people and team component. On the technical side, its theoretical underpinnings are computer science and, in particular, the science of programming.

However, it’s much more than just programming.

Software Development Life Cycle (SDLC)

1973

2003

Cycle de vie logiciels

Cycle de vie logiciels

Software Development Life Cycle (SDLC)

Common SDLC phases include planning, feasibility, design, implementation, testing, deployment, and maintenance

 The Software Development Life Cycle (SDLC) is a well-structured process that guides software development projects from start to finish.

 

It provides a clear framework for planning, building, and maintaining software, ensuring that development is systematic and meets quality standards.

Cycle de vie logiciels

Software Development Life Cycle (SDLC)

1956

waterfall

 scrum

1988

spiral

agile

manifesto

1950

1960

1970

1980

1990

2000

1995

2001

1970

Royce Waterfall

formalisation

Un modèle interprété comme linéaire par l'histoire, une erreur, car en réalité intégrant déjà de l'incrémental.

Cycle de vie logiciels

Software Development Life Cycle (SDLC)

1956

waterfall

 scrum

1988

spiral

agile

manifesto

1950

1960

1970

1980

1990

2000

1995

2001

validation (“Are we building the right product?”)

verification (“Are we building the product correctly?”)

1980s Nasa V Model

Cycle de vie logiciels

Software Development Life Cycle (SDLC)

1956

waterfall

 scrum

1988

spiral

agile

manifesto

1950

1960

1970

1980

1990

2000

1995

2001

Cycle de vie logiciels

Software Development Life Cycle (SDLC)

1956

waterfall

 scrum

1988

spiral

agile

manifesto

Agile est une philosophie de gestion de projet qui repose sur un ensemble de principes et de valeurs pour aider les équipes de développement à faire face au changement. Les équipes Agile donnent la priorité aux individus et aux interactions plutôt qu'aux processus et aux outils, aux logiciels de travail plutôt qu'à une documentation complète, à la collaboration avec les clients plutôt qu'à la négociation des contrats et à l'adaptation au changement plutôt qu'au suivi d'un plan.

1950

1960

1970

1980

1990

2000

1995

2001

Scrum est un framework Agile qui aide les équipes à structurer leur travail selon de courts cycles de développement appelés sprints. Les équipes Scrum s'engagent à livrer le travail à la fin de chaque sprint et à adopter des pratiques et une structure qui leur permettent d'atteindre ce rythme.

src : Wikipedia

Aujourd'hui pour l'ESR ?

Software Management Plan (SMP)

A software management plan (SMP) helps to implement best practices during software development and ensures that software is accessible and reusable in the short and longer term. The Netherlands eScience Center and NWO, the Dutch Research Council, have taken the initiative to develop (national) guidelines for software management plans, which resulted in the publication of the Practical guide to Software Management Plans in October 2022.

Software Management Plan (SMP) (NL)

Software Sustainability Institute

A Software Management Plan (SMP) can help you to define a set of structures and goals to understand your research software including what you are going to develop; who the software is for (even if it is just for yourself); how you will deliver your software to its intended users; how it will help them; and how you will assess whether it has helped them, and contributed to research, in the ways that you intended. An SMP also helps you to understand how you can support those who wish to, or do, use your research software; how your software relates to other artefacts in your research ecosystem; and how you will ensure that your software remains available beyond the lifetime of your current project.

Aujourd'hui pour l'ESR ?

Software Management Plan (SMP)

Les logiciels constituent aujourd’hui l'un des piliers fondamentaux de la recherche, au même titre que les publications et les données. Pourtant, malgré leur rôle central, les logiciels de recherche restent difficiles à trouver, à citer et à référencer correctement. En raison de l'absence de mécanismes appropriés, les logiciels sont souvent négligés ou mal décrits dans les plans de gestion des données.

Pour répondre à ce défi, un questionnaire dédié aux codes sources et logiciels de recherche a été intégré dans la plateforme DMP OPIDoR. Il permet de décrire les logiciels et les données de recherche associées au sein d’un même plan.

Plan Gestion Logiciel PGL Français (Opidor, GT5 Atelier de la Donnée, COSO)

Comment choisir un SDLC ?

Software Development Life Cycle (SDLC)

Ressources existantes  : Turing Way Book

Comment choisir un SDLC ?

Software Development Life Cycle (SDLC)

Ressources existantes  : rapport du GT 3 valorisation et durabilité du Collège CSL (avril 2025)

Comment choisir un SDLC ?

Software Development Life Cycle (SDLC)

Ressources existantes  : TU Delft

Comment choisir un SDLC ?

Software Development Life Cycle (SDLC)

Ressources existantes  : The Carpentries (non profit)

Collaborer en 1960's-70's

Q1 : Les cycles de vie logiciels sont anciens et cumulatifs, mais au fait où et comment collabore t'on avant internet ?

Q2 : Existe-t-il un précurseur à cette notion de  forges "boite à outils" ?

"By time-sharing, I meant an operating system that permits each user of a computer to behave as though he were in sole control of a computer, not necessarily identical with the machine on which the operating system is running."

John McCarthy's 1959 proposal [...] was the vision of a computer used independently by different persons for entirely different programs. Perhaps the major step that McCarthy suggested was to optimize the use of human time rather than computer time. The optimal use of computer time was to be transparent to the user.

Le principe du

"TIME SHARING" ~1959

Usage à distance

Terminal VT101 (1978)

Schema pour la connection

Teletype ASR 33 (1963)

Time-Sharing : PLATO II 

PLATO II (Programmed Logic for Automatic Teaching Operations) démarre en 1961 

Presently more than 4000 hr of instructional material in more than 100 subjects are now available on the Illinois PLATO system (Lyman, 1974). Lessons range from elementary mathematics for primary grades through advanced level university courses.

Present status of the Illinois PLATO system network extending throughout United States and Canada is about 1000 terminals at 70 educational campuses (P1. 3). Approximately 400 terminals are in Urbana-Champaign. Other separate PLATO systems are currently being established at Minneapolis and Tallahassee.

TUTOR dedicated programming language

Time-Sharing : PLATO II 

Time Sharing : CCTS & UNIX

CCTS / Unix & Time Sharing

Illustration : https://www.harley.com/unix-book/book/chapters/22.html#figure-22-02

What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.

Relatively early in the development of CTSS, it became clear that the initial focus on providing machine cycles to users more effectively was only half the benefit of time sharing. An equally big, perhaps bigger, impact came from having an online file system and the resulting capability for sharing of data and programs and collaborations by users.

Unix se diffuse rapidement, la licence est gratuite pour les académie, le code, modifiable par tout le monde

Collaborer, pas facile facile ...

L'irruption du

gestionnaire de version

RESEAU

WEB

SERVICES

VERSIONNEMENT

Des outils et des pratiques à la base de la collaboration ET du concept de forge !

Gestion de version

“Version control is an approach to record changes made in a file or set of files over time so that you and your collaborators can track their history, review any changes, and revert or go back to earlier versions.” –

• When people are working at the same time, we want their changes to not conflict with each other.
• We want people to be able to work simultaneously, not serially.
• We want to archive every version of everything that has ever existed — ever.

The Turing Way Community (2022), chapter on Version Control.

Version Control Systems

L'idée de la boite à outils

Unix & "The Programmer's workbench"

Partagé

Systèmes de Versionnements

Fichiers

Collaborer sur du texte, du code

VERSIONNER avec PWB/Unix : SCSS

Source Code Control System

The original SNOBOL implementation didn’t have a “delta” command. Rather, it allowed the programmer to edit the on-disk source file with punched card commands to change, add, or delete source code lines. (No terminals!)

 

Since all edits went through SCCS, it knew what constituted the delta. But, in going to UNIX, it was obvious that “ed” had to be used, and this presented a problem: How would the system know what had happened? The “diff” command existed then, and it was amazingly good. So, I incorporated that into the system, resulting in the “delta” command.

 

As I recall, it invoked “diff” as a subprocess; I didn’t incorporate the code itself. There was only one editor for UNIX at the time, but, of course, many others came along later, such as “vi”.

Collaborer sur du texte, du code

au coeur du versionnement : commande DIFF

V0

V1

V2

V3

V4

...

1

2

3

4

5

Présent dans le PWB avec SCSS !

fichier

Collaborer sur du texte, du code

Workflow UNIX pour construire logiciel

Déjà SCCS, puis RCS qui partage le même workflow local, possède  un grand nombre de concepts que l'on retrouve aujourd'hui

Versionnement fichier par fichier, avec principe de verrouillage.

Améliorations et nouveaux workflows

Invention de Patch en 1985

fichier patch permettant de passer d'une version à une autre

patch is a shell command that updates text files according to instructions in a separate file, called a patch file. The patch file is a text file that lists the differences between the input file and the desired content. The command is designed to support patch files created via diff.

V0

V1

V2

V3

V4

...

fichier

V3

Améliorations et nouveaux workflows

Invention de Patch en 1985

 The main benefit to patch when it came out was that it allowed any collaboration at all, since back in the day nobody had the bandwidth to just keep resending the whole project over and over. [...]

Anyway, patch did help launch the whole open source movement, and I'm content with that, even if patch itself is wandering vaguely in the direction of the sunset.

 

Décentralisation des workflows de collaboration ont été largement accéléré par l'invention de la commande "Patch" qui permet l'envoi de Diff léger par emails.  

Décentralisé

Partagé

Systèmes de Versionnements

Fichiers

Dossiers

Centralisé

démocratisation du  WEB

Améliorations et nouveaux workflows

CVS & SVN : centralisé, fonctionnement par projets

CVS (1986) puis SVN (2000) permettent un workflow centralisé sur un repository stocké sur serveur, accessible via un client connecté aux réseaux via plusieurs protocoles.

Centralisé c'est à dire 1 seul dépot / repository et un mode client / serveur.

Améliorations et nouveaux workflows

CVS & SVN : centralisé, fonctionnement par projets

Les communautés autour du logiciel libre peuvent collaborer entre machines sur Internet bien AVANT (ex: USENET/UUCP en 1980) la création du Web (1992) et des Navigateurs, mais ce nouveau protocole va s'imposer très très rapidement, y compris en France

RENATER à l’origine n’est pas un réseau Internet au sens strict, mais un réseau qui, avant de voir le tout IP s’imposer, a supporté plusieurs solutions : un réseau multi-protocoles. [...] Les informaticiens sont attentifs, par exemple à l’INRIA, aux développements qui entourent Unix, ainsi qu’aux Newsgroups qui circulent au sein du réseau Usenet et leur fournissent de riches éléments d’information sur leur activité. La genèse dans la première moitié des années 1980 de ce qui deviendra l’association Fnet à l’INRIA, un des premiers backbones Internet avec l’IRCAM et le CNAM, témoigne de la précocité de l’attrait pour les solutions Unix, UUCP puis Internet dans cette communauté.

Cyclades, l'autre internet ...

Améliorations et nouveaux workflows

Première forge WEB : SourceForge

It decided to launch a Web site to host the work of open source software developers. The site would offer a full box of tools, from a Concurrent Versioning System (CVS) to a bug tracker to mailing lists. And the site would be – in the spirit of 1999 – totally free of charge.

Le première service Web permettant le dépot et l'accès à du Versionnement (code, texte) est SourceForge en 1999

Décentralisé

~70% Git
SO survey 2015

Partagé

Systèmes de Versionnements

Fichiers

Dossiers

Centralisé

démocratisation du  WEB

Histoire des forges web aurait pu s'arrêter avec le succès de SourceForge mais ...

Améliorations et nouveaux workflows

Invention de Git en 2005 : Décentralisation

Tout le monde possède l'historique complet des modifications faits sur les fichiers, et s'avère donc complétement AUTONOME sur le projet.

Passage d'un Versionnement centralisé à un Versionnement "plus" décentralisé qui répond au besoin d'un projet particulier ...

Git

Linus Benedict Torvalds

Créateur du noyau Linux, ~10.000 ligne de code,

en 1991 à 22 ans

En 2015 19.5 M lines of code contributed by almost 14,000 programmers.

src : wikipedia

Pas de VCS avant 2002 !!
Linus n'aime pas le dev. centralisé

Créateur de Git pour le Kernel linux en 2005

GIT doit aussi (bcp) son succès à GITHUB

50000

1M

10M

75M

Gratuite (+/-) mais non open-source ...

Modèle de revenu opaque (2008-2018 ?)

100M

37M

dépots

utilisateurs

Une recentralisation des usages

GitHUB & GIT

Github vs SourceForge

SourceForge a plusieurs défauts majeurs :

- Basé sur la publicité ...
- Passage a SVN seulement en 2006, git en 2009
- Ux catastrophique ...
- Problèmes techniques (ralentissement, etc.)
- Petite équipe
- Scandales (adware, malware, etc.)
- Processus de dépot pas si simple

Avec Github et sa proposition d'héberger des sites web directement sur la forge, deux autres outils ont un peu chamboulé le paysage de la publication sur le web. Il s'agit de markdown et Jekyll en 2008.

3 Millions d'utilisateurs et 300000 projets en 2013 pour SourceForge /  10 Millions pour Github en 2013

De son côté, Github  :
- s'appuie sur git
- bénéficie d'une Ux orienté réseau social, au moment ou justement ceux-ci explose en popularité,
- n'est pas open-source, avec un modèle de revenu assez opaque (2008-2018) jusqu'à son rachat par Microsoft,
- ce qui n'est pas sans causer des problèmes à beaucoup de monde ...
- mais lui permet de rester gratuit (ou presque) et sans publicité

Activités sociales

Les forges logicielles, support historique pour l'ingénierie logicielle, aujourd'hui extensible à d'autres usages

Accélérateurs dans la diversification des usages :

Techniques :

- Accès simplifié à l'hébergement de Pages web

- Support direct de l'intégration continue sans logiciel extérieur (jenkins, etc.)

Sociaux

- Aspects Réseaux Sociaux (rappel : facebook : 2004, twitter 2006)

- Croissance de l'Open Science ESR

- Crise de la reproductibilité

GIT devient le Standard mondial, mais les autres systèmes continuent d'exister malgré tout

Ce n'est pas fini, la décentralisation (forge, système de revision) n'a pas dit son dernier mot : Radicle, etc.

Forges sont hétérogènes dans leur support des systèmes de révision : mono ou multi support

Workflow décentralisé via git, par email, résiste à la re-centralisation au sein des forges web

GIT et le reste du monde ...

Choisir une Forge ?

Quelques grands critères pour évaluer la compatibilité avec la logique d'OpenScience : 

- Interne / Externe à l'ESR

- Commerciale / Communautaire

- Locale / Nationale

Forges à l'ESR

Aide à la décision ?

Pérénité ?

Reproductibilité ?

Souveraineté ?

SWOT à la rescousse

Forges à l'ESR

Aide à la décision ?

Aide à la décision ?

Exemple

Paul et Léo sont ingénieurs dans une UMR en Sociologie à l'Université de Rouen, ils co-développent un logiciel d'analyse et d'annotation d'images depuis 3 ans en utilisant Git installé sur un serveur de l'université (sans Forge). Paul vient d'obtenir un financement ANR qui va lui permettre d'encadrer des doctorants en charge d'intégrer de nouvelles fonctionnalités à la pointe de l'état de l'art à son logiciel.

Une équipe informatique Allemande spécialisé dans l'analyse d'image est partenaire du Projet, elle est amené à participé au développeur du logiciel pendant toute la durée du projet.

En amont du lancement du projet, il aimerait planifier un Software Management Plan et un cycle de vie logiciel appuyé par une Forge Logicielle.

Le logiciel n'a pas bénéficié de publication jusqu'à présent, mais c'est un objectif prioritaire vis à vis de l'ANR.

Voici comment il a positionné ces besoins sur ce diagramme, que lui proposeriez vous comme solution ?

Atlassian. (s. d.-a). Déploiement continu. Atlassian. Consulté 28 janvier 2026, à l’adresse https://www.atlassian.com/fr/continuous-delivery/software-testing/continuous-deployment

Atlassian. (s. d.-b). Qu’est-ce que Scrum selon la méthodologie Agile ? |. Consulté 28 janvier 2026, à l’adresse https://www.atlassian.com/fr/agile/scrum/agile-vs-scrum

Atlassian. (s. d.-c). Sdlc. Consulté 28 janvier 2026, à l’adresse https://www.atlassian.com/agile/software-development/sdlc

Berre, D. L., Jeannas, J.-Y., Cosmo, R. D., & Pellegrini, F. (2023). Forges de l’Enseignement supérieur et de la Recherche—Définition, usages, limitations rencontrées et analyse des besoins [Report, Comité pour la science ouverte]. https://doi.org/10.52949/34

Cameron, L. (2018, octobre 5). First Software Engineer. IEEE Computer Society. https://www.computer.org/publications/tech-news/events/what-to-know-about-the-scientist-who-invented-the-term-software-engineering

Chacon, S. (2024, septembre 9). Why GitHub Actually Won. Butler’s Log. https://blog.gitbutler.com/why-github-actually-won

CHM. (s. d.). Programmer standing beside punched cards—CHM Revolution. Consulté 28 janvier 2026, à l’adresse https://www.computerhistory.org/revolution/memory-storage/8/326/924

Contato, A., Brambilla, F., & Corrado, D. (s. d.). Video Games : The People, Games, and Companies: Stage Two: From 1980 to 1984: Vol. 2. Retroedicola Videoludica.

Cosmo, R. D., Granger, S., Hinsen, K., Jullien, N., Berre, D. L., Louvet, V., Maumet, C., Maurice, C., Monat, R., & Rougier, N. P. (2025, février 5). CODE beyond FAIR. https://inria.hal.science/hal-04930405

Erdogmus, H., Medvidovic, N., & Paulisch, F. (2018). 50 Years of Software Engineering. IEEE Software, 35(5), 20‑24. https://doi.org/10.1109/MS.2018.3571240

Foster, G. (2024). How GitHub monopolized code hosting. Graphite. https://graphite.com/blog/github-monopoly-on-code-hosting

Gruenpeter, M., Katz, D. S., Lamprecht, A.-L., Honeyman, T., Garijo, D., Struck, A., Niehues, A., Martinez, P. A., Castro, L. J., Rabemanantsoa, T., Chue Hong, N. P., Martinez-Ortiz, C., Sesink, L., Liffers, M., Fouilloux, A. C., Erdmann, C., Peroni, S., Martinez Lavanchy, P., Todorov, I., & Sinha, M. (2021). Defining Research Software : A controversial discussion. Zenodo. https://doi.org/10.5281/ZENODO.5504016

GT Inter-Réseau CNRS sur la Données MITI 2023 et Al. ;  gtdonnees-gitlab2023 : Gitlab, le compagnon pour votre production scientifique : logiciels, données, publications... https://gtdonnees-gitlab2023.sciencesconf.org/

1/4

Hamilton, M. H. (2018). What the Errors Tell Us. IEEE Software, 35(5), 32‑37. https://doi.org/10.1109/MS.2018.290110447

Ivie, E. L. (1977). The programmer’s workbench—A machine for software development. Communications of the ACM, 20(10), 746‑7

Lee, J. A. N. (1992a). Claims to the term « time-sharing ». IEEE Annals of the History of Computing, 14(1), 16‑54. https://doi.org/10.1109/85.145316

Lee, J. A. N. (1992b). Time-Sharing at MIT: Introduction. IEEE Annals of the History of Computing, 14(1), 13‑15. https://doi.ieeecomputersociety.org/10.1109/MAHC.1992.10001

Lenay, C., Levillain, F., & Raimondi, V. (s. d.). Bernard Stiegler, une figure emblématique de Costech—Interactions—Le magazine des technologies émergentes. Consulté 28 janvier 2026, à l’adresse https://interactions.utc.fr/thematiques/technologie-et-sciences-de-l-homme/bernard-stiegler-une-figure-emblematique-de-costech/

Louvet, V. (2025, décembre 4). Actualités du collège Codes Sources et Logiciels. RDA France. https://www.rd-alliance.org/wp-content/uploads/2025/12/Actus_College_Logiciels_dec25_VLouvet.pdf

Maguire, J. (2011, août 4). The SourceForge Story—Datamation. https://web.archive.org/web/20110804024950/http://itmanagement.earthweb.com/cnews/article.php/3705731

Margery, D., Bertot, J., Demarey, C., & Inglebert, C. (2007, novembre). InriaGforge : Leçons de 2 ans d’exploitation de Gforge à l’Inria. JRES (Journées réseaux de l’enseignement et de la recherche ) 2007. https://hal.science/hal-04802760

Mårtensson, H. (s. d.). Waterfall vs. Agile : Battle of the Dunces or A Race to the Bottom? Waterfall vs. Agile. Consulté 28 janvier 2026, à l’adresse https://kallokain.blogspot.com/2023/11/waterfall-vs-agile-battle-of-dunces-or.html

Martinez-Ortiz, C., Martinez Lavanchy, P., Sesink, L., Olivier, B. G., Meakin, J., de Jong, M., & Cruz, M. (avec Akhmerov, A., Ancion, Z., de Bruin, J., Culina, A., Erdmann, C., Grootveld, M., Psomopoulos, F. E., Sarkol, V., van Leeuwen, C. M., & Vinju, J. J.). (2023). Practical guide to Software Management Plans. Zenodo. https://doi.org/10.5281/ZENODO.7589725

McCarthy. (s. d.). Reminiscences on the Theory of Time-Sharing. Consulté 30 janvier 2026, à l’adresse http://jmc.stanford.edu/computing-science/timesharing.html

National Geographic editors. (2026, janvier 28). How supercomputers paved the way for laptops and chatbots. History. https://www.nationalgeographic.com/history/article/worlds-first-supercomputers-photos

Oettinger, A. G. (1966). President’s Letter to the ACM Membership. Communications of the ACM, 9(8), 545‑546. https://doi.org/10.1145/365758.3291288

RIATES. (s. d.). Sciences ouvertes pour les SHS : scripts, codes et logiciels – École Thématique SO-SHS. Consulté 28 janvier 2026, à l’adresse https://so-shs.gitpages.huma-num.fr/

2/4

Ritchie, D. M. (1980). The evolution of the unix time-sharing system. In J. M. Tobias (Éd.), Language Design and Programming Methodology (Vol. 79, p. 25‑35). Springer Berlin Heidelberg. https://doi.org/10.1007/3-540-09745-7_2

Rochkind, M. J. (1975). The source code control system. IEEE Transactions on Software Engineering, SE-1(4), 364‑370. https://doi.org/10.1109/TSE.1975.6312866

Rochkind, M. J. (2025). A Retrospective on the Source Code Control System. IEEE Transactions on Software Engineering, 51(3), 695‑699. https://doi.org/10.1109/TSE.2024.3524947

Rochkind, M., & Soria Parra, D. (s. d.). A History of Source Control Systems : SCCS and RCS (Part 1) | dsp. Consulté 31 janvier 2026, à l’adresse https://experimentalworks.net/posts/2024-03-18-a-history-of-vcs-part1/

Royce, W. W. (2021). Managing the Development of Large Software Systems (1970). In H. R. Lewis (Éd.), Ideas That Created the Future (p. 321‑332). The MIT Press. https://doi.org/10.7551/mitpress/12274.003.0035

SANTANGELO, M. G. (2025). La nouvelle fonctionnalité pour décrire la gestion des codes et logiciels dans DMP OPIDoR. https://doi.org/10.5281/ZENODO.17964749

Schafer, V. (2012). De Cyclades à Renater. Histoire de la recherche contemporaine. La revue du Comité pour l’histoire du CNRS, (Tome I-N°2), 180‑187. https://doi.org/10.4000/hrc.115

Schafer, V., & Tuy, B. (2013, décembre). Que nous apprend l’histoire de RENATER? JRES (Journées réseaux de l’enseignement et de la recherche ) 2013. https://hal.science/hal-04804909

Sherwood, B. A. (1977). The TUTOR language. Control Data.

Sink. (s. d.). Version Control by Example. Consulté 31 janvier 2026, à l’adresse https://ericsink.com/vcbe/index.html

Software engineering : Report on a conference sponsored by the Nato Science Committee, Garmisch, Germany, 7th to 11th October, 1968. Chairman: F.L.Bauer, co-chairmen: L.Bolliet, H.J.Helms,. (1969). Brussels : Scientific Affairs Division, NATO. http://archive.org/details/softwareengineer0000unse

Software Sustainability Institute. (s. d.). Software Management Plans. Consulté https://www.software.ac.uk/news/software-management-plans

Spinellis, D. (s. d.). CSDL | IEEE Computer Society. IEEE. Consulté 28 janvier 2026, à l’adresse https://www.computer.org/csdl/magazine/so/2018/05

Target, S. (s. d.). Version Control Before Git with CVS. Consulté 1 février 2026, à l’adresse https://twobithistory.org/2018/07/07/cvs.html

Tonda-Goldstein, S., Clément-Fontaine, M., Jullien, N., Robineau, J., & Sabot, F. (2025). Quelles stratégies de diffusion et pérennité pour les logiciels de recherche dans les établissements publics français ? [Report, Comité pour la science ouverte]. https://doi.org/10.52949/82

3/4

Turing Way Collective. (s. d.). Project Management Frameworks Overview—The Turing Way. Consulté 28 janvier 2026, à l’adresse https://book.the-turing-way.org/project-design/project-management-methodologies/overview/

Walden, D., & Van Vleck, T. (2011). The Compatible Time Sharing System (1961–1973) : Fiftieth Anniversary Commemorative Overview. IEEE Computer Society History Committee. https://ethw.org/File:Walden,_David_and_Van_Vleck_-_The_Compatible_Time-Sharing_System_(1961-1973).pdf

Wall, L. (2016, juillet 18). The Slashdot Interview With Larry Wall—Slashdot. https://developers.slashdot.org/story/16/07/14/1349207/the-slashdot-interview-with-larry-wall

Wikipedia. (2026). Margaret Hamilton (scientifique). In Wikipédia. https://fr.wikipedia.org/w/index.php?title=Margaret_Hamilton_(scientifique)&oldid=232639468

4/4