2888 lines
125 KiB
TeX
2888 lines
125 KiB
TeX
%%
|
||
% 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 default font family
|
||
% 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}
|