%%
% Copyright (c) 2017 - 2021, Pascal Wagler;
% Copyright (c) 2014 - 2021, John MacFarlane
%
% All rights reserved.
%
% Redistribution and use in source and binary forms, with or without
% modification, are permitted provided that the following conditions
% are met:
%
% - Redistributions of source code must retain the above copyright
% notice, this list of conditions and the following disclaimer.
%
% - Redistributions in binary form must reproduce the above copyright
% notice, this list of conditions and the following disclaimer in the
% documentation and/or other materials provided with the distribution.
%
% - Neither the name of John MacFarlane nor the names of other
% contributors may be used to endorse or promote products derived
% from this software without specific prior written permission.
%
% THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
% "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
% LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
% FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
% COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
% INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
% BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
% LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
% CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
% LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
% ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
% POSSIBILITY OF SUCH DAMAGE.
%%

%%
% This is the Eisvogel pandoc LaTeX template.
%
% For usage information and examples visit the official GitHub page:
% https://github.com/Wandmalfarbe/pandoc-latex-template
%%

% Options for packages loaded elsewhere
\PassOptionsToPackage{unicode}{hyperref}
\PassOptionsToPackage{hyphens}{url}
\PassOptionsToPackage{dvipsnames,svgnames*,x11names*,table}{xcolor}
%
\documentclass[
  paper=a4,
  oneside  ,captions=tableheading
]{scrbook}
\usepackage{amsmath,amssymb}
\usepackage{lmodern}
\usepackage{setspace}
\setstretch{1.2}
\usepackage{ifxetex,ifluatex}
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provide euro and other symbols
\else % if luatex or xetex
  \usepackage{unicode-math}
  \defaultfontfeatures{Scale=MatchLowercase}
  \defaultfontfeatures[\rmfamily]{Ligatures=TeX,Scale=1}
\fi
% Use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
\IfFileExists{microtype.sty}{% use microtype if available
  \usepackage[]{microtype}
  \UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\makeatletter
\@ifundefined{KOMAClassName}{% if non-KOMA class
  \IfFileExists{parskip.sty}{%
    \usepackage{parskip}
  }{% else
    \setlength{\parindent}{0pt}
    \setlength{\parskip}{6pt plus 2pt minus 1pt}}
}{% if KOMA class
  \KOMAoptions{parskip=half}}
\makeatother
\usepackage{xcolor}
\usepackage{sectsty}
\definecolor{default-linkcolor}{HTML}{A50000}
\definecolor{default-filecolor}{HTML}{A50000}
\definecolor{default-citecolor}{HTML}{4077C0}
\definecolor{default-urlcolor}{HTML}{4077C0}
\IfFileExists{xurl.sty}{\usepackage{xurl}}{} % add URL line breaks if available
\IfFileExists{bookmark.sty}{\usepackage{bookmark}}{\usepackage{hyperref}}
\hypersetup{
  pdftitle={Forges de l'Enseignement supérieur et de la Recherche},
  pdfauthor={Collège Codes sources et logiciels du Comité pour la science ouverte},
  colorlinks=true,
  linkcolor=default-linkcolor,
  filecolor=default-filecolor,
  citecolor=default-citecolor,
  urlcolor=default-urlcolor,
  breaklinks=true,
  pdfcreator={LaTeX via pandoc with the Eisvogel template}}
\urlstyle{same} % disable monospaced font for URLs
\usepackage[top=2cm, bottom=1.5cm, left=1cm, right=1cm,a4paper,margin=1in,left=4.5cm]{geometry}
\usepackage[export]{adjustbox}
\usepackage{graphicx}
\usepackage{listings}
\newcommand{\passthrough}[1]{#1}
\lstset{defaultdialect=[5.3]Lua}
\lstset{defaultdialect=[x86masm]Assembler}
\usepackage{longtable,booktabs,array}
\usepackage{calc} % for calculating minipage widths
% Correct order of tables after \paragraph or \subparagraph
\usepackage{etoolbox}
\makeatletter
\patchcmd\longtable{\par}{\if@noskipsec\mbox{}\fi\par}{}{}
\makeatother
% Allow footnotes in longtable head/foot
\IfFileExists{footnotehyper.sty}{\usepackage{footnotehyper}}{\usepackage{footnote}}
\makesavenoteenv{longtable}
% add backlinks to footnote references, cf. https://tex.stackexchange.com/questions/302266/make-footnote-clickable-both-ways
\usepackage{footnotebackref}
\usepackage{graphicx}
\makeatletter
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
\makeatother
% Scale images if necessary, so that they will not overflow the page
% margins by default, and it is still possible to overwrite the defaults
% using explicit options in \includegraphics[width, height, ...]{}
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
% Set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother
\setlength{\emergencystretch}{3em} % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{5}

% Make use of float-package and set default placement for figures to H.
% The option H means 'PUT IT HERE' (as  opposed to the standard h option which means 'You may put it here if you like').
\usepackage{float}
\floatplacement{figure}{H}

\usepackage{tcolorbox}
\tcbuselibrary{theorems}
\definecolor{box-color1}{HTML}{bbfae9}
\newtcbtheorem{observation}{Observation}{left=.3cm,right=.3cm,toptitle=.3cm,bottom=.3cm,middle=.1cm,colback=box-color1,colframe=box-color1,coltitle=black,fonttitle=\bfseries}{th}
\definecolor{box-color2}{HTML}{eaeaea}
\newtcbtheorem{autre}{À noter aussi }{left=.3cm,right=.3cm,toptitle=.3cm,bottom=.3cm,middle=.1cm,colback=box-color2,colframe=box-color2,coltitle=black,fonttitle=\bfseries}{th}
\usepackage[labelfont={color=box-color1,bf},textfont={color=box-color1}]{caption}
\definecolor{bar-color1}{HTML}{7846ff}
\definecolor{bar-color2}{HTML}{ffe552}
\definecolor{coso-title-color}{HTML}{5A28C8}
\usepackage{enumitem}
\usepackage{titlesec}
\usepackage{moresize}
\newcommand{\hsp}{\hspace{20pt}}
\titleformat{name=\chapter}[hang]{\Huge\bfseries}{\thechapter\hspace{20pt}|\hspace{20pt}}{0pt}{\Huge\bfseries}
\titlespacing*{\chapter}{-1.5cm}{10pt}{10pt}
\titleformat{name=\chapter,numberless}[hang]{\color{coso-title-color}\HUGE\bfseries}{}{0pt}{\color{coso-title-color}\HUGE\bfseries}
\titlespacing*{\chapter}{-1.5cm}{10pt}{10pt}
\usepackage{wrapfig}
\usepackage{afterpage}
\usepackage{authoraftertitle}
\hyphenation{de-venue}
\hyphenation{faci-lité}
\hyphenation{an-ciennes}
\hyphenation{re-lativement}
\ifluatex
  \usepackage{selnolig}  % disable illegal ligatures
\fi
\newlength{\cslhangindent}
\setlength{\cslhangindent}{1.5em}
\newlength{\csllabelwidth}
\setlength{\csllabelwidth}{3em}
\newenvironment{CSLReferences}[2] % #1 hanging-ident, #2 entry spacing
 {% don't indent paragraphs
  \setlength{\parindent}{0pt}
  % turn on hanging indent if param 1 is 1
  \ifodd #1 \everypar{\setlength{\hangindent}{\cslhangindent}}\ignorespaces\fi
  % set entry spacing
  \ifnum #2 > 0
  \setlength{\parskip}{#2\baselineskip}
  \fi
 }%
 {}
\usepackage{calc}
\newcommand{\CSLBlock}[1]{#1\hfill\break}
\newcommand{\CSLLeftMargin}[1]{\parbox[t]{\csllabelwidth}{#1}}
\newcommand{\CSLRightInline}[1]{\parbox[t]{\linewidth - \csllabelwidth}{#1}\break}
\newcommand{\CSLIndent}[1]{\hspace{\cslhangindent}#1}

\title{Forges de l'Enseignement supérieur et de la Recherche}
\usepackage{etoolbox}
\makeatletter
\providecommand{\subtitle}[1]{% add subtitle to \maketitle
  \apptocmd{\@title}{\par {\large #1 \par}}{}{}
}
\makeatother
\subtitle{Définition, usages, limitations rencontrées et analyse des
besoins}
\author{Collège Codes sources et logiciels du Comité pour la science
ouverte}
\date{Mai 2023}



%%
%% added
%%

%
% language specification
%
% If no language is specified, use English as the default main document language.
%

\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[shorthands=off,main=english]{babel}
\else
    % Workaround for bug in Polyglossia that breaks `\familydefault` when `\setmainlanguage` is used.
  % See https://github.com/Wandmalfarbe/pandoc-latex-template/issues/8
  % See https://github.com/reutenauer/polyglossia/issues/186
  % See https://github.com/reutenauer/polyglossia/issues/127
  \renewcommand*\familydefault{\sfdefault}
    % load polyglossia as late as possible as it *could* call bidi if RTL lang (e.g. Hebrew or Arabic)
  \usepackage{polyglossia}
  \setmainlanguage[]{english}
\fi



%
% for the background color of the title page
%
\usepackage{pagecolor}
\usepackage{afterpage}
\usepackage{tikz}

%
% break urls
%
\PassOptionsToPackage{hyphens}{url}

%
% When using babel or polyglossia with biblatex, loading csquotes is recommended
% to ensure that quoted texts are typeset according to the rules of your main language.
%
\usepackage{csquotes}

%
% captions
%
\definecolor{caption-color}{HTML}{5A28C8}
\usepackage[font={stretch=1.2}, textfont={color=caption-color}, position=top, skip=4mm, labelfont={color=caption-color}, singlelinecheck=false, justification=raggedright]{caption}
\setcapindent{0em}

%
% blockquote
%
\definecolor{blockquote-border}{RGB}{221,221,221}
\definecolor{blockquote-text}{RGB}{119,119,119}
\usepackage{mdframed}
\newmdenv[rightline=false,bottomline=false,topline=false,linewidth=3pt,linecolor=blockquote-border,skipabove=\parskip]{customblockquote}
\renewenvironment{quote}{\begin{customblockquote}\list{}{\rightmargin=0em\leftmargin=0em}%
\item\relax\color{blockquote-text}\ignorespaces}{\unskip\unskip\endlist\end{customblockquote}}

%
% Source Sans Pro as the de­fault font fam­ily
% Source Code Pro for monospace text
%
% 'default' option sets the default
% font family to Source Sans Pro, not \sfdefault.
%
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
    \usepackage[default]{sourcesanspro}
  \usepackage{sourcecodepro}
  \else % if not pdftex
    \usepackage[default]{sourcesanspro}
  \usepackage{sourcecodepro}

  % XeLaTeX specific adjustments for straight quotes: https://tex.stackexchange.com/a/354887
  % This issue is already fixed (see https://github.com/silkeh/latex-sourcecodepro/pull/5) but the
  % fix is still unreleased.
  % TODO: Remove this workaround when the new version of sourcecodepro is released on CTAN.
  \ifxetex
    \makeatletter
    \defaultfontfeatures[\ttfamily]
      { Numbers   = \sourcecodepro@figurestyle,
        Scale     = \SourceCodePro@scale,
        Extension = .otf }
    \setmonofont
      [ UprightFont    = *-\sourcecodepro@regstyle,
        ItalicFont     = *-\sourcecodepro@regstyle It,
        BoldFont       = *-\sourcecodepro@boldstyle,
        BoldItalicFont = *-\sourcecodepro@boldstyle It ]
      {SourceCodePro}
    \makeatother
  \fi
  \fi

%
% heading color
%
\definecolor{heading-color}{RGB}{40,40,40}
\addtokomafont{section}{\color{heading-color}}
% When using the classes report, scrreprt, book,
% scrbook or memoir, uncomment the following line.
%\addtokomafont{chapter}{\color{heading-color}}

%
% variables for title, author and date
%
\usepackage{titling}
\title{Forges de l'Enseignement supérieur et de la Recherche}
\author{Collège Codes sources et logiciels du Comité pour la science
ouverte}
\date{Mai 2023}

%
% tables
%

\definecolor{table-row-color}{HTML}{F5F5F5}
\definecolor{table-rule-color}{HTML}{999999}

%\arrayrulecolor{black!40}
\arrayrulecolor{table-rule-color}     % color of \toprule, \midrule, \bottomrule
\setlength\heavyrulewidth{0.3ex}      % thickness of \toprule, \bottomrule
\renewcommand{\arraystretch}{1.3}     % spacing (padding)

% TODO: This doesn't work anymore. I don't know why.
% Reset rownum counter so that each table
% starts with the same row colors.
% https://tex.stackexchange.com/questions/170637/restarting-rowcolors
%
% Unfortunately the colored cells extend beyond the edge of the
% table because pandoc uses @-expressions (@{}) like so:
%
% \begin{longtable}[]{@{}ll@{}}
% \end{longtable}
%
% https://en.wikibooks.org/wiki/LaTeX/Tables#.40-expressions
\let\oldlongtable\longtable
\let\endoldlongtable\endlongtable
\renewenvironment{longtable}{
\rowcolors{3}{}{table-row-color!100}  % row color
\oldlongtable} {
\endoldlongtable
\global\rownum=0\relax}

%
% remove paragraph indention
%
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
\setlength{\emergencystretch}{3em}  % prevent overfull lines

%
%
% Listings
%
%


%
% general listing colors
%
\definecolor{listing-background}{HTML}{F7F7F7}
\definecolor{listing-rule}{HTML}{B3B2B3}
\definecolor{listing-numbers}{HTML}{B3B2B3}
\definecolor{listing-text-color}{HTML}{000000}
\definecolor{listing-keyword}{HTML}{435489}
\definecolor{listing-keyword-2}{HTML}{1284CA} % additional keywords
\definecolor{listing-keyword-3}{HTML}{9137CB} % additional keywords
\definecolor{listing-identifier}{HTML}{435489}
\definecolor{listing-string}{HTML}{00999A}
\definecolor{listing-comment}{HTML}{8E8E8E}

\lstdefinestyle{eisvogel_listing_style}{
  language         = java,
  numbers          = left,
  xleftmargin      = 2.7em,
  framexleftmargin = 2.5em,
  backgroundcolor  = \color{listing-background},
  basicstyle       = \color{listing-text-color}\linespread{1.0}\small\ttfamily{},
  breaklines       = true,
  frame            = single,
  framesep         = 0.19em,
  rulecolor        = \color{listing-rule},
  frameround       = ffff,
  tabsize          = 4,
  numberstyle      = \color{listing-numbers},
  aboveskip        = 1.0em,
  belowskip        = 0.1em,
  abovecaptionskip = 0em,
  belowcaptionskip = 1.0em,
  keywordstyle     = {\color{listing-keyword}\bfseries},
  keywordstyle     = {[2]\color{listing-keyword-2}\bfseries},
  keywordstyle     = {[3]\color{listing-keyword-3}\bfseries\itshape},
  sensitive        = true,
  identifierstyle  = \color{listing-identifier},
  commentstyle     = \color{listing-comment},
  stringstyle      = \color{listing-string},
  showstringspaces = false,
  escapeinside     = {/*@}{@*/}, % Allow LaTeX inside these special comments
  literate         =
  {á}{{\'a}}1 {é}{{\'e}}1 {í}{{\'i}}1 {ó}{{\'o}}1 {ú}{{\'u}}1
  {Á}{{\'A}}1 {É}{{\'E}}1 {Í}{{\'I}}1 {Ó}{{\'O}}1 {Ú}{{\'U}}1
  {à}{{\`a}}1 {è}{{\'e}}1 {ì}{{\`i}}1 {ò}{{\`o}}1 {ù}{{\`u}}1
  {À}{{\`A}}1 {È}{{\'E}}1 {Ì}{{\`I}}1 {Ò}{{\`O}}1 {Ù}{{\`U}}1
  {ä}{{\"a}}1 {ë}{{\"e}}1 {ï}{{\"i}}1 {ö}{{\"o}}1 {ü}{{\"u}}1
  {Ä}{{\"A}}1 {Ë}{{\"E}}1 {Ï}{{\"I}}1 {Ö}{{\"O}}1 {Ü}{{\"U}}1
  {â}{{\^a}}1 {ê}{{\^e}}1 {î}{{\^i}}1 {ô}{{\^o}}1 {û}{{\^u}}1
  {Â}{{\^A}}1 {Ê}{{\^E}}1 {Î}{{\^I}}1 {Ô}{{\^O}}1 {Û}{{\^U}}1
  {œ}{{\oe}}1 {Œ}{{\OE}}1 {æ}{{\ae}}1 {Æ}{{\AE}}1 {ß}{{\ss}}1
  {ç}{{\c c}}1 {Ç}{{\c C}}1 {ø}{{\o}}1 {å}{{\r a}}1 {Å}{{\r A}}1
  {€}{{\EUR}}1 {£}{{\pounds}}1 {«}{{\guillemotleft}}1
  {»}{{\guillemotright}}1 {ñ}{{\~n}}1 {Ñ}{{\~N}}1 {¿}{{?`}}1
  {…}{{\ldots}}1 {≥}{{>=}}1 {≤}{{<=}}1 {„}{{\glqq}}1 {“}{{\grqq}}1
  {”}{{''}}1
}
\lstset{style=eisvogel_listing_style}

%
% Java (Java SE 12, 2019-06-22)
%
\lstdefinelanguage{Java}{
  morekeywords={
    % normal keywords (without data types)
    abstract,assert,break,case,catch,class,continue,default,
    do,else,enum,exports,extends,final,finally,for,if,implements,
    import,instanceof,interface,module,native,new,package,private,
    protected,public,requires,return,static,strictfp,super,switch,
    synchronized,this,throw,throws,transient,try,volatile,while,
    % var is an identifier
    var
  },
  morekeywords={[2] % data types
    % primitive data types
    boolean,byte,char,double,float,int,long,short,
    % String
    String,
    % primitive wrapper types
    Boolean,Byte,Character,Double,Float,Integer,Long,Short
    % number types
    Number,AtomicInteger,AtomicLong,BigDecimal,BigInteger,DoubleAccumulator,DoubleAdder,LongAccumulator,LongAdder,Short,
    % other
    Object,Void,void
  },
  morekeywords={[3] % literals
    % reserved words for literal values
    null,true,false,
  },
  sensitive,
  morecomment  = [l]//,
  morecomment  = [s]{/*}{*/},
  morecomment  = [s]{/**}{*/},
  morestring   = [b]",
  morestring   = [b]',
}

\lstdefinelanguage{XML}{
  morestring      = [b]",
  moredelim       = [s][\bfseries\color{listing-keyword}]{<}{\ },
  moredelim       = [s][\bfseries\color{listing-keyword}]{</}{>},
  moredelim       = [l][\bfseries\color{listing-keyword}]{/>},
  moredelim       = [l][\bfseries\color{listing-keyword}]{>},
  morecomment     = [s]{<?}{?>},
  morecomment     = [s]{<!--}{-->},
  commentstyle    = \color{listing-comment},
  stringstyle     = \color{listing-string},
  identifierstyle = \color{listing-identifier}
}

%
% header and footer
%
\usepackage{fancyhdr}

\fancypagestyle{eisvogel-header-footer}{
  \fancyhead{}
  \fancyfoot{}
  \lfoot[Forges de l'Enseignement supérieur et de la Recherche]{Forges
de l'Enseignement supérieur et de la Recherche}
  \cfoot[]{}
  \rfoot[\thepage]{\thepage}
  \renewcommand{\headrulewidth}{0pt}
  \renewcommand{\footrulewidth}{0pt}
}
\pagestyle{eisvogel-header-footer}

%%
%% end added
%%


\begin{document}

%%
%% begin titlepage
%%
\begin{titlepage}
\newgeometry{top=2cm, right=4cm, bottom=3cm, left=4cm}
\tikz[remember picture,overlay] \node[inner sep=0pt] at (current page.center){\includegraphics[width=\paperwidth,height=\paperheight]{fond_ouvrir_la_science.jpg}};

\noindent
\vskip -3cm
\hskip -4cm
\includegraphics[width=12cm, left]{ouvrirlasciencelogo.jpg}

% The titlepage with a background image has other text spacing and text size
{
  \vskip 4cm
  \begin{tcolorbox}[boxsep=.7cm,left skip=4cm, right skip=-4cm, colback=white,colframe=white]
  \color[HTML]{5A28C8}
  \setstretch{2}
  \vfill
  \noindent {\Huge \textbf{\textsf{Forges de l'Enseignement supérieur et
de la Recherche}}}
    \vskip 0.6em
  {\huge  \textbf{\textsf{Définition, usages, limitations rencontrées et
analyse des besoins}}}
    \vskip 0.6em
  \par\noindent\rule{1.5cm}{1.5pt}\vfill
  \noindent {\Large \textsf{Collège Codes sources et logiciels du Comité
pour la science ouverte} 
  \par\noindent\rule{1.5cm}{1.5pt}
  \vskip 0.4em \textsf{\textbf{\huge Mai 2023}}}
  \end{tcolorbox}
}

\end{titlepage}
\restoregeometry

%%
%% end titlepage
%%

\definecolor{section-color}{HTML}{5A28C8}
\sectionfont{\color{section-color}}

\frontmatter


\newpage
\newgeometry{margin=0.5in}  
\color{coso-title-color}{\HUGE\thetitle}

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

\color{black}
\Large
\par

\noindent

\rule{1.5cm}{1.5pt}

Collège codes sources et logiciels du Comité pour la science ouverte

\par

\noindent

\rule{1.5cm}{1.5pt}

GT 2: Outils et bonnes pratiques techniques et sociales

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

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

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

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

\par

\noindent

\rule{1.5cm}{1.5pt}

\MyDate

\par

\noindent

\rule{1.5cm}{1.5pt}
\vfill

\normalsize

Conception graphique : opixido

\noindent

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

\hypertarget{ruxe9sumuxe9}{%
\chapter*{Résumé}\label{ruxe9sumuxe9}}
\addcontentsline{toc}{chapter}{Résumé}

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

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

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

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

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

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

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

Le choix de l'auto-hébergement, et de la forge utilisée, n'est donc pas
anodin. Sur les 39 forges répertoriées, 37 sont des instances de GitLab
(les deux autres forges utilisent respectivement Tuleap et Gogs). On
peut expliquer cette domination de GitLab par sa simplicité
d'installation et de maintenance et la richesse des fonctionnalités
offertes.

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

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

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

\renewcommand*\contentsname{Sommaire}
{
\hypersetup{linkcolor=}
\setcounter{tocdepth}{2}
\tableofcontents
}
\mainmatter
\hypertarget{historique}{%
\chapter*{Historique}\label{historique}}
\addcontentsline{toc}{chapter}{Historique}

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.20}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.22}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.59}}@{}}
\toprule
Version & Date & Commentaire \\
\midrule
\endhead
1 & 02/05/23 & Version initiale du collège codes sources et logiciels du
Comité pour la science ouverte \\
\bottomrule
\end{longtable}

Ce document est diffusé sous licence créative commons attribution (CC BY
4.0). Vous pouvez contribuer à l'évolution de ce document disponible en
version source
\href{https://gitlab.in2p3.fr/coso-college-codes-sources-et-logiciels/forges-esr}{sur
la forge publique de IN2P3}.

Nous recommandons l'utilisation de
\href{https://gitlab.in2p3.fr/coso-college-codes-sources-et-logiciels/forges-esr/-/issues}{tickets}
pour nous faire part de vos suggestions et compléments d'information.
\newpage

\hypertarget{introduction}{%
\chapter{Introduction}\label{introduction}}

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

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

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

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

\hypertarget{de-limportance-des-forges}{%
\chapter{De l'importance des forges}\label{de-limportance-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 \href{http://bitbucket.org/}{BitBucket},
\href{http://gitea.io/}{Gitea}, \href{http://github.com}{GitHub},
\href{http://gitlab.com}{GitLab}, \href{http://gogs.io}{Gogs} et
\href{http://forgejo.org}{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 \href{https://www.huma-num.fr}{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 (\protect\hyperlink{ref-codeetlogiciel}{Pellegrini, Di Cosmo,
Romary, Janik, Hodenq, Coutanson, et Géroudet, 2022}) pour une
discussion plus détaillée du sujet.

\hypertarget{surveiller-luxe9volution-du-code-source}{%
\section{Surveiller l'évolution du code
source}\label{surveiller-luxe9volution-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 \emph{outils de
gestion de versions} (en anglais «~\emph{version control systems}~» ou
VCS). L'un des gestionnaires de versions les plus utilisés actuellement
est \href{http://git-scm.org}{Git}.

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

\hypertarget{piloter-tout-le-cycle-de-vie-du-logiciel}{%
\section{Piloter tout le cycle de vie du
logiciel}\label{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
«~\href{https://fr.wikipedia.org/wiki/Forge_\%28informatique\%29}{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).

\hypertarget{permettre-et-faciliter-la-collaboration}{%
\section{Permettre et faciliter la
collaboration}\label{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 «~\emph{patch}~» (fichier contenant les
changements apportés), soit en réalisant une requête de fusion des
changements (une «~\emph{pull request}~», PR, ou «~\emph{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 \href{https://www.softwareheritage.org/}{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 (\protect\hyperlink{ref-bazaar}{Raymond, 2001}) et
(\protect\hyperlink{ref-cosssuccessful}{Bangerth et Heister, 2013}) 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.

\hypertarget{construire-le-logiciel-analyser-son-code-source}{%
\section{Construire le logiciel, analyser son code
source}\label{construire-le-logiciel-analyser-son-code-source}}

Une fonctionnalité que l'on retrouve souvent dans ces forges est
l'«~intégration continue~» (ou «~\emph{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.

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.05}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.64}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.31}}@{}}
\caption{Typologie de forges}\tabularnewline
\toprule
Niveau & Fonctionnalités & Exemples \\
\midrule
\endfirsthead
\toprule
Niveau & Fonctionnalités & Exemples \\
\midrule
\endhead
0 & Hébergement de code source versionné avec Git (pas de système de
tickets ou de CI) & \href{https://git.zx2c4.com/cgit/about/}{cgit} \\
1 & Niveau 0 + système de tickets et de revue de code &
\href{https://www.redmine.org}{Redmine},
\href{https://www.gerritcodereview.com/}{Gerrit},
\href{https://trac.edgewall.org}{Trac} \\
2 & Niveau 1 + système de \emph{pull/merge request} &
\href{https://gitea.io/}{Gitea}/\href{https://forgejo.org}{Forgejo},
\href{https://gogs.io/}{Gogs} \\
3 & Niveau 2 + CI/CD, voire autres modules (GitLab pages, SourceHut
pages) & \href{https://about.gitlab.com/}{GitLab},
\href{https://sourcehut.org}{SourceHut},
\href{https://www.tuleap.org/}{Tuleap} \\
\bottomrule
\end{longtable}

\hypertarget{au-deluxe0-du-code-source}{%
\section{Au delà du code source}\label{au-deluxe0-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 :

\begin{description}
\item[Publication et maintenance de sites web]
à l'aide d'outils comme GitHub/GitLab/SourceHut pages~;
\item[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~;
\item[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é \href{https://htr-united.github.io}{HTR
United}).
\end{description}

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

\hypertarget{uxe9volution-du-public-visuxe9-par-les-forges}{%
\section{Évolution du public visé par les
forges}\label{uxe9volution-du-public-visuxe9-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
\href{https://stackoverflow.com}{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 «~\emph{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}

\hypertarget{cas-particulier-du-logiciel-libre-de-recherche}{%
\section{Cas particulier du logiciel libre de
recherche}\label{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), rendus
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 devenu une compétence importante dans
toutes les disciplines académiques
(\protect\hyperlink{ref-bestpracticesscientificcomputing}{Wilson,
Aruliah, Brown, Chue Hong, Davis, Guy, Haddock, Huff, Mitchell,
Plumbley, Waugh, White, et Wilson, 2014}). La forge logicielle doit
devenir un outil comme un autre dans la boite à outils des chercheurs et
des ingénieurs.

\hypertarget{publics-de-lesr-visuxe9s-par-les-forges}{%
\section{Publics de l'ESR visés par les
forges}\label{publics-de-lesr-visuxe9s-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 stagiaires (stage de recherche), par des doctorants ou
postdoctorants, des ingénieurs et/ou des chercheurs. 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}

\hypertarget{paysage-des-forges-de-lesr}{%
\chapter{Paysage des forges de l'ESR}\label{paysage-des-forges-de-lesr}}

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.

\hypertarget{utilisation-importante-des-forges-commerciales}{%
\section{Utilisation importante des forges
commerciales}\label{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
\passthrough{\lstinline!github.com!},
\passthrough{\lstinline!gitlab.com!} ou
\passthrough{\lstinline!sourceforge.net!}
(\protect\hyperlink{ref-githubinpublications}{Escamilla, Klein, Cooper,
Rampin, Weigle, et Nelson, 2022}). Il suffit de regarder les dépôts où
sont hébergés les logiciels récompensés lors du premier prix science
ouverte du logiciel libre pour s'en convaincre~:

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

La plateforme \href{https://code.gouv.fr/\#/repos}{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. \textbf{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 \href{https://archive.softwareheritage.org}{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
\href{https://blogs.eclipse.org/post/denis-roy/moving-eclipse-projects-github-and-gitlab}{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 (\protect\hyperlink{ref-gitlab2022}{Sharwood, 2022}), 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
(\protect\hyperlink{ref-googlecode}{Staff, 2015}) et même de services
communautaires comme Gitorious
(\protect\hyperlink{ref-gitorious}{Degeler, 2015}) 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 (\protect\hyperlink{ref-mercurial}{Chan,
2020}). 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
\href{https://www.cnil.fr/fr/la-cnil-appelle-evolutions-dans-utilisation-outils-collaboratifs-etatsuniens-enseignement-superieur-recherche}{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}

\hypertarget{utilisation-des-forges-communautaires-libres}{%
\section{Utilisation des forges communautaires
libres}\label{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
\href{https://openscience.ow2.org/}{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}

\begin{quote}
La forge d'OW2 peut cependant être utilisée comme forge
d'expérimentation, via les «~\emph{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.
\end{quote}

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

\begin{itemize}
\tightlist
\item
  ASM (licence BSD)~: https://asm.ow2.io/
\item
  MPFR (licence GNU LGPL)~: https://www.mpfr.org/
\item
  OM2M (licence EPL)~: https://www.eclipse.org/om2m/
\item
  Papyrus (licence EPL)~: https://www.eclipse.org/papyrus/
\item
  Sat4j (licence GNU LGPL/EPL)~: https://www.sat4j.org/
\item
  SensiNact (licence EPL)~:
  https://projects.eclipse.org/projects/technology.sensinact
\item
  Spoon (licence CeCILL-C/MIT)~: https://spoon.gforge.inria.fr
\end{itemize}

\hypertarget{la-forge-nationale-sourcesup}{%
\section{La forge nationale
SourceSup}\label{la-forge-nationale-sourcesup}}

La forge SourceSup (https://sourcesup.renater.fr)
\href{https://www.amue.fr/systeme-dinformation/metier/articles/article/sourcesup-le-cru-propose-une-plate-forme-gratuite-pour-le-developpement-de-projets/}{a
été mise en service en 2004} par RENATER. Il s'agissait à l'époque d'une
instance de \href{https://www.gforge.com}{GForge}. Ce service a basculé
sous \href{http://fusionforge.org}{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~: \href{https://www.mantisbt.org\%5B}{MantisBT}
pour la gestion de tickets, \href{https://testlink.org}{Testlink} pour
la gestion des campagnes de tests,
\href{https://www.sonarqube.org}{Sonarqube} pour l'assurance qualité,
\href{https://fr.sonatype.com/products/nexus-repository}{Nexus} pour la
gestion d'artefacts, \href{https://www.jenkins.io}{Jenkins} pour
l'intégration continue, et \href{https://www.nuxeo.com/fr/}{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~:

\begin{description}
\tightlist
\item[AGATTE~:]
Progiciel de gestion des congés, utilisé dans beaucoup d'établissements
de l'Enseignement supérieur et de la Recherche
\item[WIMS~:]
Logiciel d'enseignement interactif
\item[OTAWA~:]
Cadriciel C++ pour déterminer le temps d'exécution au pire de cas de
programmes.
\end{description}

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
\href{https://subversion.apache.org}{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.}
\end{autre*}

Source~: Stratégie du numérique pour l'éducation 2023-2027 (MENJ), page
25 (\protect\hyperlink{ref-strategiemenj}{MENJ, 2023})

\hypertarget{forges-publiques-auto-huxe9berguxe9es-dans-lesr}{%
\section{39 forges publiques auto-hébergées dans
l'ESR}\label{forges-publiques-auto-huxe9berguxe9es-dans-lesr}}

En 2023, on compte au moins 39 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
\protect\hyperlink{liste-des-forges-publiques-auto-huxe9berguxe9es-de-lesr}{en
annexe A}, ne se veut pas exhaustive. Elle est issue, d'une part, des
déclarations qui alimentent la plateforme
\passthrough{\lstinline!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 \protect\hyperlink{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~:

\begin{itemize}
\tightlist
\item
  les grands organismes de recherche nationaux disposent de leur propre
  forge ou sont sur le point d'en disposer~;
\item
  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).
\end{itemize}

\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}

\hypertarget{analyse-de-la-situation}{%
\section{Analyse de la situation}\label{analyse-de-la-situation}}

\hypertarget{frise-chronologique-des-forges-mentionnuxe9es-dans-ce-document.}{%
\subsection{Frise chronologique des forges mentionnées dans ce
document.}\label{frise-chronologique-des-forges-mentionnuxe9es-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~:

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

\begin{figure}
\centering
\includegraphics{frise/forge-timelines.png}
\caption{Dates d'apparition de différentes forges}
\end{figure}

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 \emph{forks} issus de la
communauté ont vu le jour (SourceForge/GForge/FusionForge par exemple).
Des changements de technologie apparaissent régulièrement. La forge
\passthrough{\lstinline!sourceforge.net!} utilise désormais le logiciel
libre \href{http://allura.apache.org}{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
\href{https://about.gitlab.com/releases/2013/10/17/gitlab-ce-6-dot-2-released/}{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
\href{https://about.gitlab.com/blog/2014/01/07/hosting-gitlab-on-gitlab/}{janvier
2014}, le développement collaboratif de GitLab se fait à l'aide de
GitLab.

\hypertarget{pourquoi-tant-de-forges-auto-huxe9berguxe9es}{%
\subsection{Pourquoi tant de forges auto-hébergées
?}\label{pourquoi-tant-de-forges-auto-huxe9berguxe9es}}

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 susceptible 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
(\protect\hyperlink{ref-eclipsegitlab}{Roy, 2022}), a justifié cette
migration par les arguments suivants~:

\begin{quote}
\emph{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.}
\end{quote}

\begin{quote}
\emph{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.}
\end{quote}

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 \emph{forks} et les \emph{pull
requests} ou \emph{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.

\hypertarget{difficultuxe9-dinteraction-avec-la-sociuxe9tuxe9}{%
\subsection{Difficulté d'interaction avec la
société}\label{difficultuxe9-dinteraction-avec-la-sociuxe9tuxe9}}

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
\passthrough{\lstinline!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 \emph{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.

\begin{quote}
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.
\end{quote}

\begin{quote}
RENATER propose la création d'un
\href{https://services.renater.fr/federation/outils/comptes-cru/index}{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.
\end{quote}

\begin{observation}{}{}
En général, les logiciels de forges 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 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é («
\emph{Empty uid} », « \emph{Email can't be blank} », « \emph{Email is
invalid} », voire « \emph{500 Whoops, something went wrong on our end}
»), déroutant complètement l'utilisateur. Il vaut mieux que
l'institution utilise une
\href{https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631715/ConsentConfiguration}{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.

\begin{quote}
En février 2023, le support de Shibboleth a
\href{https://gitlab.com/gitlab-org/gitlab/-/issues/393065}{é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.
\end{quote}

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).

\begin{quote}
La forge GitLab portée par l'infrastructure
\href{https://www.huma-num.fr/}{HumaNum} étend cette approche «~EduGAIN
/ Shibboleth~» en permettant, grâce à son système
d'\href{https://huma-num.gitpages.huma-num.fr/mkdocumentation/humanid/}{HumanID},
de s'authentifier, en plus d'eduGAIN, par son compte ORCID, HAL,
Twitter, LinkedIN ou Google.
\end{quote}

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

\begin{quote}
En pratique, OW2 indique ne pas souffrir de \emph{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.
\end{quote}

\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}

\hypertarget{niveau-de-support-et-besoin-de-confiance}{%
\subsection{Niveau de support et besoin de
confiance}\label{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.

\begin{quote}
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
limite le nombre d'accès par machine et par jour. Par conséquence,
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, il faut que
les mainteneurs de chaque instance installent un registre local qui sert
de cache pour réduire le nombre d'accès aux registres publics à accès
limités. Cependant, ces solutions ne sont pas forcément toujours 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.
\end{quote}

\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}

\hypertarget{licence-libre-ou-propriuxe9taire}{%
\subsection{Licence libre ou propriétaire
?}\label{licence-libre-ou-propriuxe9taire}}

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.

\hypertarget{points-dattention-sur-les-forges}{%
\chapter{Points d'attention sur les
forges}\label{points-dattention-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.

\hypertarget{vitrine-ou-simple-outil}{%
\section{Vitrine ou simple outil ?}\label{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\footnote{OW2 permet cependant la création de deux projets
  personnels publics pour chaque utilisateur.}).

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
« \emph{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}

\begin{quote}
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
\href{https://www.ow2.org/view/MRL/}{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.
\end{quote}

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 \href{https://code.gouv.fr/\#/repos}{code.gouv.fr} ou de l'archive
universelle des logiciels
\href{https://www.softwareheritage.org/}{Software Heritage} se sont
appuyées sur la fonctionnalité d'indexation offerte par les forges.

\hypertarget{organisation-des-projets}{%
\section{Organisation des projets}\label{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}

\begin{quote}
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.
\end{quote}

\hypertarget{gestion-du-droit-dauteur}{%
\section{Gestion du droit d'auteur}\label{gestion-du-droit-dauteur}}

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.\footnote{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 \emph{open source} le code qu'ils produisent.}

À 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
\href{https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin}{Developer
Certificate of Origin (DCO)}, ou de façon plus encadrée, au moyen des
\href{https://en.wikipedia.org/wiki/Contributor_License_Agreement}{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.

\hypertarget{guxe9rer-un-projet-sur-plusieurs-forges}{%
\section{Gérer un projet sur plusieurs
forges}\label{guxe9rer-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.

\begin{quote}
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.
\end{quote}

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
\href{https://forgejo.org/}{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
\href{https://en.wikipedia.org/wiki/Fediverse}{Fediverse}. L'initiative
\href{https://forgefriends.org}{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ésents et importants,
l'intégration continue.

\hypertarget{toujours-plus-de-services-en-intuxe9gration-continue}{%
\section{Toujours plus de services en intégration
continue}\label{toujours-plus-de-services-en-intuxe9gration-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
«~\emph{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~:

\begin{itemize}
\tightlist
\item
  analyse de la compatibilité juridique des licences du logiciel et de
  ses composants ;
\item
  détection de composants possédant des vulnérabilités connues ;
\item
  détection de vulnérabilités dans le code produit ;
\item
  détection de mauvaises pratiques de développement dans le projet ;
\item
  etc.
\end{itemize}

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 certain événement ou sous certaines
conditions, comme par exemple à chaque mise à jour du code.

\begin{quote}
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.
\end{quote}

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 \emph{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
\emph{runners}.

\hypertarget{ruxe9capitulatif-des-solutions}{%
\chapter{Récapitulatif des
solutions}\label{ruxe9capitulatif-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.

\hypertarget{forges-externes-commerciales}{%
\section{Forges externes
commerciales}\label{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

\hypertarget{forges-externes-communautaires}{%
\section{Forges externes
communautaires}\label{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}

\hypertarget{forges-auto-huxe9berguxe9es-uxe0-luxe9chelon-local}{%
\section{Forges auto-hébergées à l'échelon
local}\label{forges-auto-huxe9berguxe9es-uxe0-luxe9chelon-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}

\hypertarget{forge-auto-huxe9berguxe9e-uxe0-luxe9chelon-national}{%
\section{Forge auto-hébergée à l'échelon
national}\label{forge-auto-huxe9berguxe9e-uxe0-luxe9chelon-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

\hypertarget{conclusion}{%
\chapter{Conclusion}\label{conclusion}}

Les pratiques de développement logiciel ont profondément évolué, avec la
généralisation de l'usage d'outils qui permettent de \emph{fluidifier
grandement la collaboration} sur des projets logiciels. Cela a
progressivement conduit à transformer les forges en \emph{réseaux
sociaux de développeurs}, et la facilité d'intégrer la contribution de
collaborateurs, même occasionnels, est devenue un \emph{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 \emph{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~:

\begin{itemize}
\tightlist
\item
  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~;
\item
  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~;
\item
  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~;
\item
  une gestion simplifiée des démarches liées à la propriété
  intellectuelle.
\end{itemize}

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

\begin{itemize}
\tightlist
\item
  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~;
\item
  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~»~;
\item
  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~;
\item
  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.
\end{itemize}

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
(\href{https://openai.com/blog/openai-codex}{OpenAI
Codex}/\href{https://github.com/features/copilot}{GitHub copilot},
\href{https://about.gitlab.com/blog/2022/03/02/bringing-ai-gitlab-repository/}{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.

\newpage
\appendix
\newgeometry{margin=1in}

\hypertarget{liste-des-forges-publiques-auto-huxe9berguxe9es-de-lesr}{%
\chapter{Liste des forges «~publiques~» auto-hébergées de
l'ESR}\label{liste-des-forges-publiques-auto-huxe9berguxe9es-de-lesr}}

\hypertarget{uxe9tablissements}{%
\section{Établissements}\label{uxe9tablissements}}

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.24}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.20}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.18}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.13}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.23}}@{}}
\toprule
Forge & Identification & Hors ESR & Intégration continue & Autres
services \\
\midrule
\endhead
CEA \href{https://codev-tuleap.cea.fr}{codev-tuleap.cea.fr} & LDAP CEA &
& & \\
CentralSupelec
\href{https://gitlab-research.centralesupelec.fr}{gitlab-research.centralesupelec.fr}
& LDAP Centrale SupElec (+ invités) & & & \\
CIRAD \href{https://gitlab.cirad.fr}{gitlab.cirad.fr} & Renater & Non &
GitLab CI & GitLab Pages \\
CNRS \href{https://src.koda.cnrs.fr}{src.koda.cnrs.fr} & CNRS (Janus) &
Non & Oui, mais pas de \emph{runner} partagé & Non \\
\href{https://gitlab.in2p3.fr}{gitlab.in2p3.fr} &
\href{https://edugain.org}{EduGAIN} & utilisateurs externes & GitLab CI
& GitLab Pages \\
\href{https://plmlab.math.cnrs.fr}{plmlab.math.cnrs.fr} & Renater &
Invitation & CI/CD avec \emph{runners} partagés & Pages avec domaines
personnalisés, gestionnaire d'artefact, registre d'images Docker \\
\href{https://gitlab.mbb.cnrs.fr}{gitlab.mbb.cnrs.fr} & LDAP MBB +
invitations & Non & Oui, mais pas de \emph{runner} partagé & registre
d'images de conteneurs \\
\href{https://forge.ins2i.fr}{forge.ins2i.fr} & Auto-inscription, CNRS
(Janus) en cours & En cours de réflexion & Oui, mais pas de
\emph{runner} partagé & Gestionnaire d'artefacts, registre d'images de
conteneurs \\
\href{https://gitlab.huma-num.fr}{gitlab.huma-num.fr} &
\href{https://edugain.org}{EduGAIN},ORCID,HAL & LinkedIn, Twitter et
Google & GitLab CI & GitLab pages \\
IMT \href{https://gitlabev.imtbs-tsp.eu/}{gitlabev.imtbs-tsp.eu} &
Annuaire Interne + Shibboleth IMT & Non & CI & \\
INRA \href{https://forgemia.inra.fr}{forgemia.inra.fr} & Renater & CRU &
GitLab CI/CD (4 runners partagés) & GitLab Pages, Gestionnaire
d'artefacts, Registre d'images Docker, Mattermost \\
INRIA \href{https://gitlab.inria.fr}{gitlab.inria.fr} & Inria &
invité·es externes parrainé·es & GitLab CI & GitLab Pages, registre
d'images Docker \\
IRD \href{https://forge.ird.fr}{forge.ird.fr} & Renater & CRU - autres
en cours & En cours & GitLab pages \\
IRSTEA \href{https://gitlab.irstea.fr}{gitlab.irstea.fr} & LDAP &
utilisateurs externes & Gitlab CI/CD & \\
TelecomParis
\href{https://gitlab.telecom-paris.fr}{gitlab.telecom-paris.fr} & & &
& \\
U. Bordeaux \href{https://gitub.u-bordeaux.fr}{gitub.u-bordeaux.fr} &
Université de Bordeaux & Après validation, limités & Non & \\
\href{https://gitlab.emi.u-bordeaux.fr}{gitlab.emi.u-bordeaux.fr} &
Université de Bordeaux, étudiants & Non & Oui & CI, GitLab pages \\
U. Caen \href{https://git.unicaen.fr}{git.unicaen.fr} & Renater & &
GitLab CI & \\
U. Gustave Eiffel
\href{https://gitlab.univ-eiffel.fr}{gitlab.univ-eiffel.fr} & Adresse
email Gustave Eiffel & Non & CI/CD & Pages \\
U. Grenoble
\href{https://gricad-gitlab.univ-grenoble-alpes.fr}{gricad-gitlab.univ-grenoble-alpes.fr}
& UGA & Oui~: sur simple inscription (sans validation) mais avec des
droits limités. & GitLab-CI (avec \emph{runners} partagés) & gitlab
pages (pages privées et publiques), registre de container \\
U. La Rochelle \href{https://gitlab.univ-lr.fr}{gitlab.univ-lr.fr} &
Annuaire & Invitation & Non & \\
U. Lille \href{https://gitlab.univ-lille.fr}{gitlab.univ-lille.fr} &
RENATER & & & \\
U. Limoge \href{https://git.unilim.fr/}{git.unilim.fr} & Annuaire
interne & Non & CI & \\
U. Littoral \href{https://gogs.univ-littoral.fr/}{gogs.univ-littoral.fr}
& LDAP ULCO & invités & Non & \\
U. Lyon1 \href{https://forge.univ-lyon1.fr}{forge.univ-lyon1.fr} & CAS
univ Lyon 1 & & & \\
U. Montpellier 2
\href{https://gitlab.mbb.univ-montp2.fr}{gitlab.mbb.univ-montp2.fr} &
LDAP + invités & & & \\
U. Nantes \href{https://gitlab.univ-nantes.fr/}{gitlab.univ-nantes.fr} &
Annuaire Interne & Invitation & CI/CD & Pages, gestionnaire d'artefact,
registre d'images Docker \\
U. Paris Saclay
\href{https://gitlab.dsi.universite-paris-saclay.fr/}{gitlab.dsi.universite-paris-saclay.fr}
& Annuaire interne & Non & GitLab CI & GitLab pages, gestionnaire
d'artefacts \\
U. Pau \href{https://git.univ-pau.fr}{git.univ-pau.fr} & LDAP Université
& & & \\
U. Strasbourg \href{https://gitlab.unistra.fr}{gitlab.unistra.fr} &
Auto-inscription & Non & CI/CD & GitLab Pages, Security Testing,
Analytics, Error Tracking (Sentry) \\
\href{https://gitlab.math.unistra.fr}{gitlab.math.unistra.fr} & LDAP
IRMA & Utilisateurs externes & CI/CD avec runners partagés & Pages avec
domaines personnalisés, gestionnaire d'artefact, registre d'images
Docker \\
ESRF \href{https://gitlab.esrf.fr/}{gitlab.esrf.fr/} & Annuaire interne
& Invitation, création de compte ESRF & CI/CD & Pages, gestionnaire
d'artefact, registre d'images Docker \\
\bottomrule
\end{longtable}

\hypertarget{laboratoires}{%
\section{Laboratoires}\label{laboratoires}}

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.24}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.20}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.18}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.13}}
  >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.23}}@{}}
\toprule
Forge & Identification & Hors ESR & Intégration continue & Autres
services \\
\midrule
\endhead
CRIStAL
\href{https://gitlab.cristal.univ-lille.fr}{gitlab.cristal.univ-lille.fr}
& LDAP CRIStAL & & & \\
IRIT \href{https://gitlab.irit.fr}{gitlab.irit.fr} & Annuaire & Invités
LDAP & & \\
FRESNEL \href{https://gitlab.fresnel.fr}{gitlab.fresnel.fr} & Institut
Fresnel + invités & & & \\
LIMOS \href{https://gitlab.limos.fr}{gitlab.limos.fr} & Annuaire LIMOS &
Invité dans l'annuaire & CI/CD & \\
LIP6 \href{https://gitlab.lip6.fr}{gitlab.lip6.fr} & LDAP LIP6 & Non &
GitLab CI (sans runner partagé) & \\
OBSPM \href{https://gitlab.obspm.fr}{gitlab.obspm.fr} & LDAP & Non &
CI/CD avec runners partagés & Pages, registre d'images Docker,
mattermost \\
OCA \href{https://gitlab.oca.eu/}{gitlab.oca.eu} & eduGAIN (seuls les
membres de l'OCA peuvent créer des projets) & Invitation & CI & Pages,
gestionnaire d'artefact \\
\bottomrule
\end{longtable}

\clearpage
\restoregeometry

\newpage

\hypertarget{contributeurs}{%
\chapter{Contributeurs}\label{contributeurs}}

\hypertarget{membres-du-colluxe8ge-codes-sources-et-logiciels}{%
\section{Membres du collège codes sources et
logiciels}\label{membres-du-colluxe8ge-codes-sources-et-logiciels}}

\begin{itemize}
\tightlist
\item
  Ludovic Courtes, Inria
\item
  Roberto Di Cosmo, Inria/Université Paris Cité
\item
  Sébastien Gérard, Université Paris-Saclay/CEA List
\item
  Timothée Giraud, CNRS
\item
  Jean-Yves Jeannas, Université de Lille/AFUL
\item
  Nicolas Julien, IMT Atlantique
\item
  Daniel Le Berre, Université d'Artois/CNRS
\item
  Violaine Louvet, CNRS/GRICAD/Université Grenoble Alpes
\item
  François Pellegrini, Université de Bordeaux/CNIL
\item
  Nicolas Rougier, Inria/Université de Bordeaux/CNRS
\item
  Francois Sabot, IRD
\item
  Samuel Thibault, Université de Bordeaux
\end{itemize}

\hypertarget{invituxe9s}{%
\section{Invités}\label{invituxe9s}}

\begin{itemize}
\tightlist
\item
  Denis Arrivault, David Margery Inria
\item
  Céline Blitz CIRAD
\item
  Gérald Dherbomez CNRS INS2I
\item
  Alban Espie-Guillon, Pierre-Yves Gibello, Antoine Mottier OW2
\item
  Bastien Guerry DINUM
\item
  Alexis Kauffmann DNE MENJ
\item
  Philippe Krief Fondation Eclipse
\item
  Christian Poirier INRAE
\item
  Jean-Christophe Souplet OpenEdition
\end{itemize}

\hypertarget{communautuxe9s}{%
\section{Communautés}\label{communautuxe9s}}

\begin{itemize}
\tightlist
\item
  GDR GPL
\item
  Réseau Calcul
\item
  Réseau DevLog
\end{itemize}

\newpage

\hypertarget{questionnaire}{%
\chapter{Questionnaire}\label{questionnaire}}

\emph{Le questionnaire suivant a été envoyé au GDR GPL et réseaux Calcul
et DevLog en septembre 2022 avec une version préliminaire de l'état des
lieux.}

\hypertarget{url-de-la-forge}{%
\section{URL de la forge}\label{url-de-la-forge}}

Cette information permettra d'identifier de manière unique la forge dont
il s'agit.

\hypertarget{par-qui-est-proposuxe9emaintenue-cette-forge}{%
\section{Par qui est proposée/maintenue cette forge
?}\label{par-qui-est-proposuxe9emaintenue-cette-forge}}

Veuillez sélectionner une réponse ci-dessous

\begin{itemize}
\tightlist
\item
  Une personne
\item
  Une structure interne (équipe)
\item
  Un laboratoire
\item
  Une structure institutionnelle : UFR, école, université
\item
  Autre :
\item
  Sans réponse
\end{itemize}

\hypertarget{cette-forge-est-elle-publique}{%
\section{Cette forge est elle publique
?}\label{cette-forge-est-elle-publique}}

Une forge est considérée comme publique si la totalité ou même une
partie des codes sources qu'elle héberge est accessible à tous sans être
identifié.

Une forge privée (ou interne) nécessite d'être identifié pour pouvoir
accéder aux projets.

Si vous donnez des informations sur une forge privée via ce
questionnaire, elles ne seront pas publiées dans l'état des lieux, mais
elles nous permettront d'avoir une idée du nombre et des fonctionnalités
des forges privées.

\begin{itemize}
\tightlist
\item
  Oui
\item
  Non
\item
  Sans réponse
\end{itemize}

\hypertarget{comment-sidentifie-ton-sur-cette-forge}{%
\section{Comment s'identifie t'on sur cette forge
?}\label{comment-sidentifie-ton-sur-cette-forge}}

L'identification se fait généralement à l'aide d'un annuaire.

Certaines forges permettent l'utilisation de fédérations d'identité pour
ce connecter (renater, eduGAIN).

Certaines permettent la création de compte, d'autres pas.

Cochez la ou les réponses

\begin{itemize}
\tightlist
\item
  Annuaire interne
\item
  RENATER
\item
  EDUGAIN
\item
  Invitation
\item
  Auto-inscription (création de compte libre)
\item
  Autre :
\end{itemize}

\hypertarget{quels-sont-les-services-disponibles}{%
\section{Quels sont les services disponibles
?}\label{quels-sont-les-services-disponibles}}

Il existe de nombreux services annexes possibles autour de la forge. Le
plus souvent, on y retrouve de l'intégration continue, de la gestion
d'artefacts, d'images docker, des outils d'analyse statique de code
comme Sonarqube, etc.

Cochez la ou les réponses

\begin{itemize}
\tightlist
\item
  Intégration continue
\item
  ``Gitlab pages''
\item
  Déploiement continu
\item
  Gestionnaire d'artefact
\item
  Gestionnaire d'images docker
\item
  Assurance qualité (sonarqube)
\item
  Autre :
\end{itemize}

\hypertarget{comment-sont-organisuxe9s-les-projets}{%
\section{Comment sont organisés les projets
?}\label{comment-sont-organisuxe9s-les-projets}}

Une des difficultés des forges publiques est de gérer la façon dont sont
organisés les projets : on ne souhaite pas forcément avoir un projet lié
à une personne en particulier, mais plutôt à une équipe de recherche, un
projet scientifique, voire un laboratoire de recherche.

Il est possible dans le cas là de créer une structure arborescente de
projets.

Se pose alors le problème des projets transverses à plusieurs équipes,
projets, laboratoires.

Vous avez l'occasion de décrire ici librement la façon dont sont
organisés les projets logiciels sur cette forge.

\hypertarget{commentaire-libre}{%
\section{Commentaire libre}\label{commentaire-libre}}

Commentaire libre sur le document de travail. \newpage

\hypertarget{glossaire}{%
\chapter{Glossaire}\label{glossaire}}

\hypertarget{c}{%
\subsection*{C}\label{c}}

\begin{description}
\item[commit]
unité de modification
\end{description}

\hypertarget{f}{%
\subsection*{F}\label{f}}

\begin{description}
\item[forge]
outil de développement logiciel collaboratif
\item[\emph{fork}/divergence]
évolution alternative du code source
\end{description}

\hypertarget{g}{%
\subsection*{G}\label{g}}

\begin{description}
\item[génie logiciel]
champ de l'informatique s'intéressant à la gestion et au cycle de vie
des projets logiciels
\item[git]
outil de gestion de versions
\end{description}

\hypertarget{i}{%
\subsection*{I}\label{i}}

\begin{description}
\item[intégration continue]
capacité pour une forge de permettre la construction automatique du
logiciel depuis l'ensemble de ses sources et en fonction de certains
paramètres
\end{description}

\hypertarget{m}{%
\subsection*{M}\label{m}}

\begin{description}
\item[\emph{merge request} (MR)]
proposition de révision
\end{description}

\hypertarget{p}{%
\subsection*{P}\label{p}}

\begin{description}
\item[plateforme]
site internet qui fait fonctionner un logiciel permettant d'avoir accès
à des fonctionnalités spécifiques au travers d'un navigateur Web
(exemple : plateforme de formation à distance)
\item[\emph{pull request} (PR)]
synonyme de \emph{merge request} (l'appellation peut être différente
selon les plateformes)
\end{description}

\hypertarget{s}{%
\subsection*{S}\label{s}}

\begin{description}
\item[Software Heritage]
initiative internationale visant à conserver pour l'Histoire les codes
source des logiciels dont le code source est public
\item[souveraineté]
Capacité d'un individu, d'un groupe ou d'un état à préserver ses données
d'un accès et d'un usage sans contrôle par des personnes ou entités
extérieures
\end{description}

\hypertarget{t}{%
\subsection*{T}\label{t}}

\begin{description}
\item[ticket]
Déclaration en ligne d'un incident ou d'un dysfonctionnement, ou
proposition d'amélioration du logiciel
\end{description}

\newpage

\hypertarget{bibliographie-indicative}{%
\chapter*{Bibliographie indicative}\label{bibliographie-indicative}}
\addcontentsline{toc}{chapter}{Bibliographie indicative}

\hypertarget{refs}{}
\begin{CSLReferences}{0}{0}
\leavevmode\vadjust pre{\hypertarget{ref-cosssuccessful}{}}%
Bangerth Wolfgang, Heister Timo. {«~What makes computational open source
software libraries successful?~»}. \emph{Computational Science \&
Discovery} {[}En ligne{]}. novembre 2013. Vol. 6, n°1, p.~015010.
Disponible sur : \url{https://doi.org/10.1088/1749-4699/6/1/015010}

\leavevmode\vadjust pre{\hypertarget{ref-mercurial}{}}%
Chan Denise. {«~Sunsetting Mercurial support in Bitbucket~»}.
\emph{BitBucket blog} {[}En ligne{]}. 2020. Disponible sur :
\url{https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket}

\leavevmode\vadjust pre{\hypertarget{ref-gitorious}{}}%
Degeler Andrii. {«~Code collaboration platform GitLab acquires rival
Gitorious, will shut it down on June 1~»}. \emph{The Next Web} {[}En
ligne{]}. 2015. Disponible sur :
\url{https://thenextweb.com/news/gitlab-acquires-rival-gitorious-will-shut-june-1}

\leavevmode\vadjust pre{\hypertarget{ref-githubinpublications}{}}%
Escamilla Emily, Klein Martin, Cooper Talya, Rampin Vicky, Weigle
Michele C., Nelson Michael L. {«~The Rise of GitHub in Scholarly
Publications~»}. In : Silvello G, Corcho O, Manghi P, Di Nunzio GM,
Golub K, Ferro N, Poggi A, Éd. \emph{Linking Theory and Practice of
Digital Libraries}. Cham : Springer International Publishing, 2022. p.
187‑200.ISBN~:
\href{https://worldcat.org/isbn/978-3-031-16802-4}{978-3-031-16802-4}.

\leavevmode\vadjust pre{\hypertarget{ref-strategiemenj}{}}%
MENJ. \emph{Stratégie du numérique pour l'éducation 2023-2027} {[}En
ligne{]}. 2023. Disponible sur :
\url{https://www.education.gouv.fr/strategie-du-numerique-pour-l-education-2023-2027-344263}

\leavevmode\vadjust pre{\hypertarget{ref-codeetlogiciel}{}}%
Pellegrini François, Di Cosmo Roberto, Romary Laurent, Janik Joanna,
Hodenq Sacha, Coutanson Romane, Géroudet Madeleine. \emph{Science
ouverte -- codes et logiciels} {[}En ligne{]}. 2022. Disponible sur :
\url{https://www.ouvrirlascience.fr/science-ouverte-codes-et-logiciels/}

\leavevmode\vadjust pre{\hypertarget{ref-bazaar}{}}%
Raymond Eric S. \emph{The cathedral and the bazaar - musings on Linux
and open source by an accidental revolutionary (rev. ed.)}. {[}s.l.{]}~:
O'Reilly, 2001. ISBN~:
\href{https://worldcat.org/isbn/978-0-596-00108-7}{978-0-596-00108-7}.

\leavevmode\vadjust pre{\hypertarget{ref-eclipsegitlab}{}}%
Roy Denis. {«~Moving Eclipse projects to GitHub and GitLab~»}.
\emph{Denis Roy's blog} {[}En ligne{]}. 2022. Disponible sur :
\url{https://blogs.eclipse.org/post/denis-roy/moving-eclipse-projects-github-and-gitlab}

\leavevmode\vadjust pre{\hypertarget{ref-gitlab2022}{}}%
Sharwood Simon. {«~GitLab plans to delete dormant projects in free
accounts~»}. \emph{The Register} {[}En ligne{]}. 2022. Disponible sur :
\url{https://resana.numerique.gouv.fr/public/document/consulter/3231705?slug=160133}

\leavevmode\vadjust pre{\hypertarget{ref-googlecode}{}}%
Staff ARS. {«~Google to close Google Code open source project
hosting~»}. \emph{ARS Technica} {[}En ligne{]}. 2015. Disponible sur :
\url{https://arstechnica.com/information-technology/2015/03/google-to-close-google-code-open-source-project-hosting/}

\leavevmode\vadjust pre{\hypertarget{ref-bestpracticesscientificcomputing}{}}%
Wilson Greg, Aruliah D. A., Brown C. Titus, Chue Hong Neil P., Davis
Matt, Guy Richard T., Haddock Steven H. D., Huff Kathryn D., Mitchell
Ian M., Plumbley Mark D., Waugh Ben, White Ethan P., Wilson Paul.
{«~Best Practices for Scientific Computing~»}. \emph{PLOS Biology} {[}En
ligne{]}. janvier 2014. Vol. 12, n°1, p.~1‑7. Disponible sur :
\url{https://doi.org/10.1371/journal.pbio.1001745}

\end{CSLReferences}

\backmatter
\end{document}
