article

Article

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/07/10
  • Correction mineure : 19/12/11
Mots-clés

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

  • Type de ressource : article, compte-rendu
  • Date de publication du document ou de l'événement : Septembre 2009
  • Auteur(s) ou responsable(s) : Samuel Godey (CNRS/UREC)
  • Contact pour plus d'informations : samuel.godey@urec.cnrs.fr

La fiche

Document de base pour la rédaction de cette fiche

Date : JUIN-DECEMBRE 2009
Auteur : Samuel Godey (CDD Ingénieur d'étude de 6 mois)
Commanditaire : Patrice Koch (Directeur du CRI Université de Franche-Comté à Besançon)

Nature de la fiche

Cette fiche expose mon expérience sur l'installation du serveur fournisseur d'identités à l'université de Franche-Comté en 2009 et explique comment réaliser la mise à jour des briques logicielles nécessaires à son fonctionnement. La partie fournisseur de services ne sera pas traitée. Certaines informations dans ce texte ont été volontairement remplacées par des termes génériques. La configuration décrite ici est dépendante de l'architecture déjà en place à l'université de Franche-Comté, cependant la majorité des grandes structures utilise des technologies similaires. Les paramètres peuvent varier et sont certainement incompatibles avec votre situation. N'attendez de ce texte qu'un point de départ ou une source d'inspiration pour votre propre fournisseur d'identités.
Attention : ce document ne garantie pas le bon fonctionnement de votre installation.

Public destinataire

Cette note est à l'attention des administrateurs d'un service "fournisseur d'identités" avec la technologie Shibboleth. Veuillez prendre en considération que des connaissances sur LDAP ainsi que sur le service SSO CAS sont nécessaires pour suivre cette fiche, bien que ces services ne soient pas obligatoires pour utiliser Shibboleth. Le serveur fournisseur d'identités a été ajusté pour la fédération éducation-recherche de Renater. Je considère que les utilitaires GNU/Debian sont maîtrisés.

Complément d'information

Les supports techniques utilisés pour réaliser l'installation initiale ainsi que d'autres documentations pour l'installation sont disponibles à l'adresse : https://federation.renater.fr
Les noms des programmes mentionnés dans ce document peuvent se trouver sous la forme "logiciel-x.x.x.foo". Veuillez prendre en considération la version des programmes stables à jour afin d'adapter ce document dans le temps. Par exemple, remplacez x.x.x par 2.3.1 si la version du logiciel "logiciel" est actuellement en version 2.3.1.

Fiches PLUME en lien avec ce retour d'expérience

Pré-requis

Serveur :

  • Lenny/Debian/GNU/Linux

Application Debian non-free/contrib :

  • sun-java-6

Applications Debian main :

  • Apache 2.2
  • mod_ssl
  • mod_proxy_ajp
  • OpenSSL
  • NTP-server
  • Maven

Applications externes :

  • Apache-tomcat6
  • Shibboleth-idp
  • CAS-client

Plan

1) Introduction

1.1) Présentation des chemins d'accès
1.2) Sources des programmes

2) Procédure de mise-à-jour de la brique Shibboleth-idp

2.1) Procédure de mise-à-jour de la brique CAS-client

3) Procédure de mise-à-jour et d'installation de Tomcat
4) Configuration de Apache2.2 (lenny/debian)
5) Configuration de Shibboleth-idp

5.1) attribute-resolver.xml
5.2) attribute-filter.xml

6) Droits et sécurité

6.1) Shibboleth-idp
6.2) Tomcat
6.3) Certificat SSL Apache
6.4) Ajout des certificats non valides

1) Introduction

Veuillez considérer ce document comme un complément d'information pour un service "fournisseur d'identités" déjà en exploitation ou en test avec les briques LDAP et CAS configurées. Il est inutile d'essayer de réaliser une nouvelle installation en s'appuyant sur ce document. Si vous souhaitez installer ce service pour la première fois, il est conseillé d'utiliser les supports techniques fournis par Renater et la documentation officielle de Shibboleth :
- Support technique Renater : https://federation.renater.fr
- Documentation officielle de Shibboleth-idp : https://spaces.internet2.edu/display/SHIB2/

Dans le cas d'une mise-à-jour à cause d'un problème de sécurité ou encore parce que de nouvelles fonctionnalités sont nécessaires, il est important de conserver une copie de la configuration en cours et de procéder à une installation standard. Dès que la mise-à-jour est terminée, il faut vérifier vos fichiers de configuration et les remplacer si nécessaire par vos sauvegardes.

Remarque très importante : si vous hésitez à réaliser une mise-à-jour et que vous préférez utiliser un SNAPSHOT (point de sauvegarde instantanée) de votre machine virtuelle, vous devrez impérativement re-synchroniser l'horloge (avec ntptime) de la machine virtuelle. En effet, une petite dérive temporelle peut supprimer les sessions actives des utilisateurs. Dans le pire de cas, un redémarrage suffit est reste une valeur sûre.

1.1) Présentation des chemins d'accès

Je vous encourage à prendre en considération les chemins ci-dessous pour la lecture de ce document car je les ai déterminés arbitrairement. Par ailleurs, ces derniers peuvent ne pas être les plus judicieux. À vous de choisir des emplacements confortables.

Shibboleth-idp : /opt/shibboleth-idp
configuration de Shibboleth : /opt/shibboleth-idp/conf
certificats de Shibboleth : /opt/shibboleth-idp/credentials
méta-données (éducation-recherche) : /opt/shibboleth-idp/metadata

Données complémentaires :

fqdn shibboleth-idp : idp.mondomaine.fr
chemin source idp : /opt/shibboleth-identityprovider-x.x.x
chemin brique logicielle : /opt/shibboleth-identityprovider-x.x.x/lib/cas-client-core-x.x.x.jar
config compil : /opt/shibboleth-identityprovider-x.x.x/src/main/webapp/WEB-INF/web.xml
configuration Renater : https://services-federation.renater.fr/exemples/co...
méta-données Renater : https://services-federation.renater.fr/metadata/re...
certificat fédération Renater : https://services-federation.renater.fr/metadata/me...

Remarques :

idp.mondomaine.fr a besoin uniquement des ports 448 et 8448. Ils doivent être accessibles et sont nécessaires au bon fonctionnement du service.
À vos pare-feu : 448 et 8448 ouverts en entrée sur idp.mondomaine.fr

1.2) Sources des programmes :

shibboleth-idp url : http://shibboleth.internet2.edu/downloads/shibbole...
shibboleth-idp nom de l'archive : shibboleth-identityprovider-x.x.x-bin.zip
cas-client url : http://www.ja-sig.org/downloads/cas-clients/
cas-client nom archive : cas-client-x.x.x-release.zip
tomcat6 url : ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x...
tomcat6 nom archive : apache-tomcat-6.x.xx.tar.gz

2) Procédure de mise-à-jour de la brique Shibboleth-idp

  • Arrêtez shibboleth-idp :

    /etc/init.d/tomcat stop
  • Faites une copie de sécurité de la configuration :

    tar zcvf ~/shib-conf.tgz /opt/shibboleth-idp/conf
  • Téléchargez la dernière version :

  • Décompressez :

    jar -xf shibboleth-identityprovider-2.1.5-bin.zip
  • Éditez le fichier de compilation :

    Par commodité, je vous conseille de faire des copies de sécurité de la configuration d'accès à votre serveur CAS. À chaque nouvelle version de Shibboleth, vous devrez adapter le fichier de compilation "web.xml" avec votre système d'authentification. Le but est d'intégrer la brique "cas-client" pré-configurée sur votre réseau en ajoutant les informations locales de votre service.

    Exemple d'un fichier /opt/shibboleth-idp/cas_web.xml à adapter suivant vos besoins :

    <!-- CAS Filter Configuration -->
    <context-param>
    <param-name<serverName</param-name>
    <param-value>https://idp.mondomaine.fr</param-value>
    </context-param>
    <!-- CAS Authentication Filter -->
    <filter>
    <filter-name>CAS Authentication Filter</filter-name>
    <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
    <init-param>
    <param-name>casServerLoginUrl</param-name>
    <!-- votre page de login -->
    <param-value>https://cas.mondomaine.fr/cas/login</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas/login</param-value> -->
    </init-param>
    </filter>
    <!-- CAS Validation Filter -->
    <filter>
    <filter-name>CAS Validation Filter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <!-- Votre page de réception de ticket -->
    <param-value>https://cas.mondomaine.fr/cas</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas</param-value> -->
    </init-param>
    </filter>
    <!-- CAS HttpServletRequest Wrapper Filter -->
    <filter>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
    </filter>
    <!-- CAS Assertion Thread Local Filter -->
    <filter>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
    </filter>
    <!-- CAS Filter for Shibb RemoteUser -->
    <filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>>
    <filter-mapping>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>

    C'est dans le fichier : /opt/shibboleth-identityprovider-2.x.x/src/main/webapp/WEB-INF/web.xml
    que vous devez reporter : /opt/shibboleth-idp/cas_web.xml. Pour ce faire, ajoutez le contenu du fichier "/opt/shibboleth-idp/cas_web.xml" juste en dessous de "</listener>"

  • Copiez le client CAS dans les bibliothèques des sources de Shibboleth :

    cp /opt/cas-client-3.x.x/modules/cas-client-core-3.x.x.jar /opt/shibboleth-identityprovider-2.x.x/lib/
  • Lancez la procédure d'installation :

    cd shibboleth-identitypovider-2.x.x
    chmod +x install.sh
    ./install.sh
  • Faites le choix d'installation :

    Where should the Shibboleth Identity Provider
    software be installed ? [/opt/shibboleth-idp]
    [Acceptez ce choix] the directory '/opt/shibboleth-idp' already exists.
    Would you like to overwrite this shibboleth configuration ?
    (yes, [no]) no => Naturellement c'est "no"

    C'est maintenant terminé, vous devez avoir en bas de votre terminal un message du type :

    BUILD SUCCESFUL
    Total time : 8 seconds
  • Synchronisez l'horloge :

    ntptime
  • Vérifiez la date :

    date
  • Relancez Shibboleth :

    /etc/init.d/tomcat start
  • Contrôlez le bon fonctionnement :

    tail -f /opt/shibboleth-idp/logs/idp-process.log

2.1) Procédure de mise-à-jour de la brique CAS-client

  • Téléchargez l'achive :

    wget http://www.ja-sig.org/downloads/cas-clients/cas-cl... -O /opt/cas-client-3.1.10-release.zip
  • Décompressez :

    cd /opt
    jar -xf cas-client-3.x.x-release.zip
  • Déplacez vous dans le répertoire :

    cd cas-client-3.x.x/cas-client-core
  • Compilez :
    mvn package
    /!\ Si vous avez une erreur => "Failed to resolve artifact"
    à propos du JAR org.opensaml:opensaml:jar:1.1b
    => Utilisez la version demandée ici 1.1b
  • Déplacez-vous ici :

  • Retournez dans le repertoire cas-client :

    cd cas-client-3.x.x/cas-client-core
  • Compilez avec la commande :

    mvn install :install-file -DgroupId=org.opensaml -DartifactId=opensaml -Dversion=1.1b\
    -Dpackaging=jar -Dfile=/opt/opensaml-1.1b.jar
  • Maintenant vous devez obtenir :

    "BUILD SUCCESSFUL"

    en bas de votre écran.

    Attention l'idp n'aura aucune connaissance de cette nouvelle version de CAS-client. Pour prendre en compte cette mise-à-jour vous devez faire l'upgrade de votre idp, cf. le paragraphe 2) Procédure de mise à jour de la brique Shibboleth-idp.

3) Procédure de mise-à-jour et d'installation de Tomcat

Je tiens à préciser qu'il est impératif de fonctionner avec Tomcat en version 6 au minimum. La version 5.5 rien ne marchera pas avec la plupart des navigateurs hormis mozilla-firefox, puisqu'il y a un problème de compatibilité avec les COOKIES. Dans certain cas Tomcat6 n'est pas proposé avec les distributions stables de linux, il faut donc récupérer une version binaire pré-compilée sur le site officiel de la fédération Apache.

L'installation n'a rien de compliqué mais nécessite de prendre quelques précautions pour éviter de donner un accès global au serveur. J'indique ici comment mettre Apache2.2 en frontal de Tomcat6 avec une configuration optimale, aussi bien pour Apache2.2 que pour Tomcat6.

En résumé, Apache2.2 constitue la porte d'entrée et de sortie vers l'extérieur. Apache communique directement avec Tomcat via un proxy accessible uniquement depuis la boucle locale. Tomcat s'occupe juste d'exécuter les applications web Java (webapps). Ici il est question de "idp.war".

C'est donc Tomcat6 qui doit avoir les droits nécessaires de lecture des fichiers de configuration et d'écriture des logs de Shibboleth. De façon à soulager Tomcat, la gestion de SSL/TLS est prise en charge par Apache2.2.

Voici la procédure à suivre :

  • Emplacement de réception :

    cd /opt/
  • Récupérez l'archive "

    wget ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x... -O /opt/apache-tomcat-6.x.xx.tar.gz
  • Décompressez l'archive :

    cd /opt
    tar zxvf apache-tomcat-6.x.xx.tar.gz
  • Supprimez les binaires et scripts pour windows :

    cd apache-tomcat-6.x.xx
    rm bin/*.exe bin/*.bat
  • Créez un lien symbolique par commodité :

    cd /opt
    ln -s /opt/apache-tomcat-6.x.xx tomcat
  • Activez le connecteur PROXY AJP pour Tomcat :

    Ajoutez à la section <Service name="Catalina"> du fichier /opt/tomcat/conf/server.xml le connecteur comme ci-dessous :

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
  • Commentez le connecteur sur le port 8080 dans le fichier /opt/tomcat/conf/server.xml :

    <!--
    <Connector executor="tomcatThreadPool"
    port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />
    -->
  • Supprimez les webapps de base offerts avec Tomcat :

    rm -rf /opt/tomcat/webapps/*
  • Ajoutez la webapp Shibboleth-idp dans le fichier /opt/tomcat/conf/Catalina/localhost/idp.xml

    <Context
    docBase="/opt/shibboleth-idp/war/idp.war"
    privileged="true"
    antiRessourceLocking="false"
    antiJARLocking="false"
    unpackWAR="false" />

    Remarque : vous pouvez ajouter l'attribut autoDeploy="true". Dans ce cas l'application sera chargée au lancement de Tomcat.

  • Par mesure de sécurité, supprimez les utilisateurs qui peuvent s'authentifier sur Tomcat :

    Retirez simplement le contenu de l'instance : tomcat-users dans le fichier /opt/tomcat/conf/tomcat-users.xml comme ci-dessous :

    <?xml version="1.1" encoding='utf-8 ?>
    <tomcat-users>
    </tomcat-users>
  • Lancez Tomcat au démarrage :

    Aucun script "System V" n'est fourni avec la distribution de Tomcat. Vous allez donc devoir en créer un. Par ailleurs ce procédé permet de simplifier la maintenance, mais aussi d'assurer le lancement automatique de Tomcat au démarrage du serveur. Cela permet aussi d'en profiter pour initialiser les variables d'environnement.

    Créez le fichier /etc/init.d/tomcat comme ci-dessous :

    #!/bin/sh

    RETVAL=$?
    JAVA_HOME=/usr/lib/jvm/java-6-sun
    JAVA_OPTS="-Xmx1000m -XX:MacPermSize=512m"
    CATALINA_HOME=/opt/tomcat
    IDP_HOME=/opt/shibboleth-idp

    export JAVA_HOME
    export JAVA_OPTS
    export CATALINA_HOME
    export IDP_HOME

    case "$1" in
    start)
    if [ -f $CATALINA_HOME/bin/startup.sh ];
    then
    echo $"Starting Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/startup.sh
    fi
    ;;
    stop)
    if [ -f $CATALINA_HOME/bin/shutdown.sh ];
    then
    echo $"Stoping Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/shutdown.sh
    fi
    ;;
    *)
    echo $"Usage: $0 {start|stop}"
    exit 1
    ;;

    exit $RETVAL

    Maintenant il ne reste plus qu'à positionner le script dans les differents niveaux de démarrage comme ci-dessous :

    chmod 755 /etc/init.d/tomcat
    update-rc.d tomcat default
  • Lancez Tomcat avec un utilisateur spécifique :

    Il est préférable de lancer Tomcat avec un utilisateur spécifique avec des privilèges limités. Le script suivant vous aidera à le créer :

    #!/bin/sh

    if ! id tomcat > /dev/null 2>&1 ; then
    adduser --system --home /opt/tomcat --no-create-home \
    --ingroup nogroup --disable-password --shell /bin/false \
    tomcat
    fi

4) Configuration de Apache2.2 (Lenny/Debian)

  • Activez les ports d'écoute dans le fichier :

    /etc/apache2/ports.conf

    Vérifiez que Apache écoute bien les deux ports comme ci-dessous :

    Listen 443
    Listen 8443
  • Configurez vos deux accès :

    - Créez le fichier /etc/apache2/sites-available/idp ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:443>
    ServerName idp.mondomaine.fr:443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/ssl/certs/idp.mondomaine.fr.pem
    SSLCertificateKeyFile /etc/ssl/private/idp.mondomaine.fr.key
    SSLCertificateChainFile /etc/ssl/certs/globalsign_ct_root.pem
    SSLCACertificateFile /etc/ssl/certss/sureserverEDU.pem
    SSLOptions +StdEnvVars

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all

    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

    - Créez le fichier /etc/apache2/sites-available/idp-aa ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:8443>
    ServerName idp.mondomaine.fr:8443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
    SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key
    SSLVerifyDepth 10
    SSLOptions -StdEnvVars +ExportCertData

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all
    </proxy>
    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

  • Activez les deux accès :

    a2ensite idp idp-aa
  • Activez le module ssl :

    a2enmod ssl
  • Activez le module proxy_ajp :

    a2enmod proxy_ajp
  • Relancez le server Apache2:

    apache2ctl -t
    apache2ctl -k restart

5) Configuration de Shibboleth-idp

Il s'agit de la configuration principale et donc celle que vous devrez utiliser pour administrer Shibboleth. Elle se trouve dans deux fichiers :

- Fichier de génération d'attributs : /opt/shibboleth-idp/conf/attribute-resolver.xml

Ce fichier est nécessaire pour configurer les connecteurs, LDAP, BDD et Statique. Il sera aussi très pratique pour déterminer les attributs nécessaires aux ressources.

- Fichier de contrôle de la propagation d'attributs : /opt/shibboleth-idp/conf/attribute-filter.xml

Ce fichier détermine quels attributs seront fournis aux ressources.

Le support technique Renater offre des fichiers d'exemples qui servent de base à la fédération. Pour une utilisation classique, il faut naturellement changer la configuration des connecteurs et filtrer la propagation des attributs, le but étant d'avoir le contrôle de son fournisseur d'identités.
Fichiers de configuration d'exemples Renater : https://services-federation.renater.fr/exemples/co...

5.1) attribute-resolver.xml

Modifiez attribut-resolver.xml à partir de la section "Data connectors" comme ci-dessous :
(Ces connecteurs sont obligatoires pour mondomaine.fr)

<resolver:DataConnector id="StaticAttributes"
xsi:type="Static"
xmlns="urn:mace:shibboleth:2.0:resolver:dc">

<Attribute id="eduOrgLegalName">
<Value>
Idp MonDomaine.fr
</Value>
</Attribute>

<Attribute id="EduPersonEntitlement">
<Value>
urn:mace:dir:entitlement:common-lib-terms
</Value>
</Attribute>

</resolver:DataConnector>

<resolver:DataConnector id="votreLDAP"
xsi:type="LDAPDirectory"
xmlns:"urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://ldap.mondomaine.fr"
baseDN="ou=people,dc=mondomaine,dc=fr"
principal="cn=cri,ou=services,dc=mondomaine,dc=fr"
principalCredential="VotreMotDePasse">

<FilterTemplate>
<![CDATA[
(uid=$requestContext.princpalName)
]]>
</FilterTemplate>

</resolver:DataConnector>

<resolver:DataConnector id="computedID"
xsi:type="ComputedID"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
generatedAttributeID="computedID"
sourceAttributeID="uid"
salt="VotrePointeDeSel">

<resolver:Dependency ref="votreLDAP" />

</resolver:DataConnector>

5.2) attribute-filter.xml

Ce fichier est indispensable pour l'ajout d'un fournisseur de services. Les fournisseurs de services mentionnés dans ce fichier seront accessibles. Voici un exemple pour ajouter un fournisseur de services :

  • Déplacez vous dans la partie suivante :

    <AttributeFilterPolicy id="releaseAttributesToSelectedSP">
  • Ajoutez le fournisseur dans "PolicyRequirementRule" :

    <PolicyRequirementRule xsi:type="basic:OR">
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_a" />
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_b" />

    <!-- Mettez à la suite les fournisseurs de services -->
    <!-- Remplacez url_fournisseur_a par l'url de votre fournisseur
    exemple http://www.cairn.info
    -->
    </PolicyRequirementRule>

  • Les paramètes suivants sont les attributs propagés aux fournisseurs url_fournisseur_x :

    <!-- Ex nom complet sans accent d'une personne -->
    <AttributeRule attributeID="commonName">
    <PermitValue xsi:type="basic:ANY" />
    </AttributeRule>

    <!-- Ex nom complet avec accents -->
    <AttributeRule attributeID="DisplayName">
    <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>

  •  Attention Pour que vos modifications soient appliquées il faut impérativement relancer Tomcat.
    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

6) Droits d'accès et sécurité

Les droits d'accès peuvent être réglés avec beaucoup de souplesse. Voici un ensemble de règles pour protéger le service et les informations sensibles.

6.1) Shibboleth-idp

Shibboleth doit être accessible par Tomcat :

chown -R tomcat logs metadata credentials
chmod 755 logs metadata
chmod 750 credentials
chown tomcat conf/attribute-filter.xml
chmod 660 conf/attribute-filter.xml

chmod 444 /opt/shibboleth-idp/credentials/metadata-federation-renater.crt
chown tomcat /opt/shibboleth-idp/credentials/idp.key
chgrp root /opt/shibboleth-idp/credentials/idp.{key,crt}
chmod 440 /opt/shibboleth-idp/credentials/idp.key
chmod 644 /opt/shibboleth-idp/credentials/idp.crt

6.2) Tomcat

D'origine les droits sont bien réglés, mais assurez-vous que l'utilisateur "tomcat" est bien le propriétaire de :

/opt/tomcat

chown -R tomcat /opt/tomcat

6.3) Certificat SSL Apache

Les certificats SSL permettent d'identifier le serveur via une procédure de signature. Les échanges d'identités entre les utilisateurs et les ressources seront chiffrées. Protégez vos certificats :

chown root:root /etc/ssl/private/idp.mondomaine.fr.key
chmod 640 /etc/ssl/private/idp.mondomaine.fr.key

chown root:root /etc/ssl/certs/globalsign_ct_root.pem
chown root:root /etc/ssl/certs/idp.mondomaine.fr.pem
chown root:root /etc/ssl/certs/sureserverEDU.pem

chmod 640 /etc/ssl/certs/globalsign_ct_root.pem
chmod 640 /etc/ssl/certs/idp.mondomaine.fr.pem
chmod 640 /etc/ssl/certs/sureserverEDU.pem

 Attention Remarque : le prestataire qui assure la sécurité des certificats peut changer. Ce qui précède est donc valable jusqu'à la réception de nouveaux certificats (sauf si vous passez par GlobalSign).

Veuillez prendre note des modifications suivantes pour les nouveaux certificats.

  • Afin de simplifier la gestion des certificats, réalisez un document.cnf : /etc/ssl/idp.mondomaine.cnf. Ce document permet de conserver les paramètres utilisés lors de la création du certificat requête.

    Ci-dessous son contenu :

    [req]
    default_bits = 1024
    default_keyfile = idp.mondomaine.fr.key
    distinguished_name = req_distinguished_name
    prompt = no

    [ req_distinguished_name ]
    C = FR
    O = Mon Etablissement
    CN = idp.mondomaine.fr
    emailAddress = idpmaster [at] mondomaine [dot] fr

  • Maintenant si vous voulez générer un certificat requête avec votre clé privée correspondante, vous pouvez utiliser le script ci-dessous (fichier /root/bin/req) :

    #!/bin/sh
    # Fourni dans le répertoire courant :
    # la clé (pour Apache)
    # idp.mondomaine.fr.key
    # le certificat requête (pour votre RSSI)
    # idp.mondomaine.fr_req.pem
    openssl req -new -nodes -out idp.mondomaine.fr_req.pem\
    -config /etc/ssl/idp.mondomaine.fr.cnf

  • Vous devez remplacer la clé "RSA PRIVATE KEY" par la nouvelle clé :

    cat ./idp.mondomaine.fr.key > /etc/ssl/private/idp.mondomaine.fr.key
  • Pour terminer, il faut remplacez les chaines de certificats. Vous devez adapter les chaînes de certificats selon votre prestataire.

6.4) Ajoutez des certificats non valides

Malheureusement un bon nombre d'aministrateurs n'utilise pas SSL dans les règles de l'art. Les serveurs mal administrés ne sont pas considérés comme dignes de confiance et Java ou les navigateurs internet n'accepteront pas les connexions avec ces serveurs. Pour résoudre ce problème et forcer Java à utiliser ces serveurs, vous devez ajouter manuellement les certificats dans son KeyStore de la façon suivante :

  • Téléchargez le programme Java suivant :

  • Compilez le programme :

    javac InstallCert hostname

     Attention Pour mondomaine.fr hostname=cas.mondomaine.fr

  • On vous demande d'ajouter les certificats. Ajoutez les tous.

    Enter certificate to add to trusted keystore or 'q' to quit: [1]

     Attention 1 pour certificat numéro 1, recommancez autant de fois que vous avez des certificats, cf. le paragraphe 3).

  • Copiez le KeyStore Java "jssecacerts" crée dans le répertoire courant ici :

    cp jssecacerts $JAVA_HOME/jre/lib/security
  • Vérifiez les droits ou fixez les :

    chown root:root $JAVA_HOME/jre/lib/security/jssecacerts
    chmod 644 $JAVA_HOME/jre/lib/security/jssecacerts
  • Pour finir, relancer Tomcat :

    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

    Remarque : si vous souhaitez que ces certificats soient reconnus comme de "confiance" par toutes vos applications Java et pas seulement JSSE, écrasez "cacert" avec "jssecacerts".

Choisir un bon mot de passe

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 15/07/10
  • Correction mineure : 10/04/12
Fiche archivée
Ce texte date de 1992 et n'a pas été mis à jour depuis. Néanmoins le fond est toujours valable et c'est un document qui fait partie de l'histoire de la sécurité informatique au CNRS.
Mots-clés

Choisir un bon mot de passe

Cette fiche n'est plus à jour. Elle a été archivée pour la raison exposée ci-contre.

Ce petit texte alerte les utilisateurs de l'informatique sur l'importance du mot de passe et donne des conseils pour le bon choix et la bonne confidentialité de celui-ci. Il introduit aussi le nouveau poste de chargé de mission sécurité informatique qui venait d'être créé au CNRS et que j'ai occupé. Ce texte est un des premiers documents de sécurité informatique destiné aux utilisateurs venant du CNRS qui a été publié. Il a été repris dans de nombreux autres environnements.

Fichier attachéTaille
choisir_mot_de_passe.pdf17.69 Ko

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 11/04/10
  • Correction mineure : 27/05/13

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

Cet article n'est pas un document officiel d'un organisme ou d'une autre entité. Il continue l'étude commencée avec les documents qui sont décrits dans : Documents de référence PLUME pour mieux gérer les développements logiciels, les diffuser et les valoriser dans un laboratoire Fiche Plume, en répondant aux questions :

  • Quelles sont les bonnes pratiques à suivre lorsqu'on prépare la diffusion d'un logiciel ?
  • Quelles sont les démarches à faire ?
  • Quels sont les documents importants à conserver (la traçabilité est une question essentielle !) ?
  • Quelles notions importantes du droit d'auteur s'appliquent ?

À la différence des documents cités, ce texte prend la perspective de l'auteur ou responsable d'un logiciel dans un laboratoire ou une institution de recherche.

L'auteur principal de cet article est Teresa Gomez-Diaz, chargée du référencement des développements de son laboratoire LIGM et responsable thématique PLUME, mais les procédures présentées ont été étudiées avec Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée). D'autres ont ensuite relu et complété : Jean-Luc Archimbaud (UREC), Geneviève Romier (UREC), Vincent Guhur (DAJ CNRS). Des versions de ce document ont été aussi relues par : M.-P. Béal, directrice du LIGM, Véronique Baudin, Pascal Dayre, Samuel Godey, Konrad Hinsen.

Ce texte a été motivé par l'étude d'un cas qui nous a été soumis, et qui est illustratif : regulièrement, des développements logiciels dans les laboratoires de recherche font surgir des problèmes analogues.

Cas d'étude

Un projet logiciel a abouti. Le projet a été dirigé par un professeur (laboratoire L1) et un maître de conférences (laboratoire L2) de l'Université G1. Un premier logiciel a été développé par un stagiaire, lors d'un stage gratifié (S1) de deux mois en 2008. Ce premier logiciel n'a pas été diffusé, mais il a été complètement repris par un nouvel étudiant lors d'un deuxième stage en 2009 gratifié par le CNRS (S2) : ce deuxième stage a donné lieu à un logiciel abouti. Le professeur prépare la diffusion du logiciel sous licence libre, une publication associée et sa présentation pour un prochain congrès. De nouvelles évolutions du logiciel sont prévues, avec l'intervention de nouveaux stagiaires.

Ma réponse

Ceci ne constitue pas une réponse officielle ; c'est mon opinion, sans aucun engagement de ma responsabilité ou celle des différents relecteurs de cette fiche.

Le logiciel du stage S1 ne peut pas être modifié sans l'accord explicite du premier stagiaire, pour le second stage, le stagiaire doit donc repartir à zéro (au niveau du code). Si l'on prévoit de diffuser le logiciel du stage S2, le mieux est de le faire sous une licence libre, avec l'accord (signé) de tous les intervenants au projet, ceci avant de lancer la soumission à publication ou la présentation au congrès. Cela simplifie les évolutions futures du logiciel, et en particulier tous les collaborateurs pourront le faire évoluer sans obstacle légal. L'Université G1 intervient dans la décision de licencier ce logiciel, même si on détecte souvent l'oubli de ce point. Je pense que les tutelles des laboratoires doivent définir leurs politiques sur les logiciels et fournir des procédures simples et adaptées pour permettre la diffusion rapide des logiciels sous licence libre.

Même si les responsables du projet n'ont pas écrit de code, ils ont proposé le projet et le code n'aurait pas pu s'écrire sans leur expérience et leur savoir-faire. C'est parfois difficile de décider quels sont les auteurs d'un logiciel. Etablir une liste d'auteurs, en leur assignant un pourcentage de participation, est la solution adoptée par d'autres projets (voir la présentation Développer en logiciel libre : Empaquetage et diffusion par exemple) : c'est une très bonne solution. Je n'ajouterais pas le premier stagiaire comme auteur du logiciel : ce sont des briques logicielles indépendantes, je recommanderais de simplement citer ce premier travail.

Deuxième cas d'étude

Lors de la rédaction de cette fiche, un autre cas nous a été posé, sur un projet logiciel proposé à des étudiants, ce type de projets étant nécessaire pour valider leur diplôme. Les étudiants n'ont pas le statut de stagiaires. La rédaction de la proposition explicite que le logiciel obtenu sera soumis à une licence libre.

Ma réponse

Dans ce cas il n'y a pas de convention de stage ni de contrat. Il me semble qu'un document signé qui établit l'accord des étudiants sur leur participation au développement d'un logiciel libre est indispensable. Ce document doit indiquer le nom du logiciel, décrire le projet, indiquer qui en est le responsable et quelle est la licence prévue ainsi que la liste des participants et la durée du projet. Ce document doit être daté et signé par tous les participants.

Procédure pour la diffusion d'un logiciel (résumé des paragraphes suivants, pour les lecteurs pressés)

Voici les principaux points de la procédure proposée qui sont explicités dans les paragraphes suivants (que nous vous conseillons de lire, même si vous êtes un lecteur pressé) :

(*) À revoir à chaque nouvelle version du logiciel.

Il est primordial d'établir une licence avant de diffuser un logiciel.

Il est important aussi d' informer la direction du laboratoire de cette diffusion. L'utilisation de sa fiche PLUME pour donner à la direction les informations sur le logiciel, nous semble un bon moyen :). Si une fiche est créée pour chaque nouveau logiciel du laboratoire, celui-ci pourra plus tard facilement accéder à toutes les fiches de logiciels développées et mettre un pointeur depuis son site Web vers cette liste (voir par exemple la liste de logiciels du LIGM).

À noter que toute cette liste de points s'applique aussi pour un développement diffusé avec une licence commerciale : il faut de même établir la liste des auteurs...

Droits d'auteur

Un logiciel est considéré comme une œuvre au sens du Code de la Propriété Intellectelle (CPI). D'après l'article L112-2 : "Sont considérés notamment comme œuvres de l'esprit au sens du présent code :

1° Les livres, brochures et autres écrits littéraires, artistiques et scientifiques ;
...
13° Les logiciels, y compris le matériel de conception préparatoire ;
..."

Toutefois, il est important de noter que seules les œuvres présentant un caractère original sont protégées par le droit d'auteur.

Puisque les logiciels ne connaissent pas les frontières, il est important de connaître que le cadre légal international est donné par la Convention de Berne pour la protection des œuvres littéraires et artistiques. Cette convention est gérée actuellement par l'Organisation mondiale de la propriété intellectuelle (OMPI).

Avant de pouvoir appliquer les règles établies par le CPI, il est essentiel de pouvoir répondre à tout moment à deux questions qui semblent innocentes :

  • qui est l'auteur ?
  • de quelle œuvre ?

L'œuvre

  • Il est nécessaire de nommer le logiciel. Le titre du logiciel bénéficie aussi de la protection par le droit d'auteur (s'il présente un caractère original). Il est important de choisir un nom qui ne porte pas atteinte aux droits des tiers (par exemple, il faut éviter de donner au logiciel un nom similaire à celui d'une marque désignant un autre logiciel). Afin de savoir si un nom est déposé en tant que marque vous pouvez consulter la Base de données des marques de l'Institut National de la Propriété Industrielle (INPI).
    Il est utile de choisir des noms faciles à prononcer (lbqavr-tsy n'est pas un bon nom de logiciel).
  • Il faut savoir qui en est le(s) propriétaire(s). Ce sont les détenteurs des droits patrimoniaux associés au logiciel. Selon la loi française, aucun propriétaire ne peut prendre l'initiative d'exploiter une œuvre sans l'autorisation explicite des autres propriétaires.
  • Le logiciel doit avoir un caractère original. Il faut rédiger un descriptif du logiciel avec : son contenu, ses foncionnalités, ses applications envisagées, en quoi est-il une nouvelle œuvre par rapport à l'existant (i.e. l'originalité apportée).
  • Il faut dater le logiciel. La protection par le droit d'auteur s'appliquant de plein droit du fait de la création de l'œuvre, il est nécessaire de pouvoir déterminer sa date de création. Plusieurs dates sont importantes : date du matériel préparatoire, date de diffusion, date de chaque version, dates des contrats et conventions liés au logiciel.
  • Il faut savoir localiser le logiciel (par une adresse ou un point de contact si l'œuvre n'est pas distribuée).
  • Il faut pouvoir citer le logiciel. Comme pour toute œuvre produite dans un laboratoire ou une institution de recherche, l'utilisation d'une référence est fondamental pour l'évaluation et la gestion du patrimoine scientifique (voir Préciser la genèse des documents diffusés).

Note : ni le lieu de développement (bureau, maison, avion...) ni l'heure (2 heures du matin) sont retenus comme des informations importantes dans la production d'une œuvre, en revanche il est tenu compte de ce que l'œuvre est en relation avec votre activité professionnelle.

La traçabilité du code

Face à un problème légal, il est essentiel de pouvoir tracer le code et de pouvoir apporter des preuves (sur les dates, le contenu, les auteurs, ...) Des organismes comme l'INRIA proposent d'effectuer des dépôts dans l'Agence de protection des programmes (APP) Fiche Plume pour renforcer cette traçabilité (entre autres objectifs), et cela à chaque version majeure ou à chaque départ d'un contributeur important.

Constituer un dossier de dépôt APP est un moment privilégié de communication entre les responsables d'un projet logiciel et les services de valorisation, et cette communication est nécessaire et doit se développer.

Il peut arriver néanmoins que les services de valorisation d'autres entités de recherche ne soient pas aussi bien établis que ceux de l'INRIA et que faire des dépôts APP peut s'avérer une tâche compliquée sans le soutien adéquat. Malgré cela, il peut être utile d'assurer la traçabilité du code en archivant le code d'un logiciel à chaque étape importante : nouvelle fonctionalité, arrivée ou départ d'un contributeur, modification du financement du code (contrats, ...) ; bref, à chaque évolution importante des données essentiels de l'oeuvre. Pour cela on peut par exemple garder des fichiers .tar.gz ou utiliser des forges.

Les auteurs

Il est parfois complexe de déterminer le ou les auteurs d'un logiciel notamment lorsqu'il s'agit d'un logiciel qui a été enrichi tout au long des années et des collaborations, cela peut demander l'intervention d'avocats dans des cas extrêmes (voir la page 28 du document Report on the proposed IPR tracking methodology, Deliverable A1.D2.1.4 du projet Quality Platform for Open Source Software (Qualipso) Fiche Plume). Voilà pourquoi il faut établir des documents qui clarifient la question. Il ne s'agit pas de prévoir toutes sortes de controverses possibles, mais de bien établir des documents qui peuvent s'avérer indispensables dans des utilisations imprévues et futures du logiciel.

Il faut donc établir une liste d'auteurs, avec le nom de leur laboratoire et leur statut (en particulier pour les stages, thèses, postdocs, ...). Il peut être utile d'associer à chaque auteur un pourcentage de collaboration (donc à ne pas oublier). Cette liste doit être revue à chaque version du logiciel, surtout s'il y a de nouveaux intervenants, ou un changement de responsable du projet logiciel.

L'auteur d'une œuvre est celui qui l'écrit, rien de plus clair... Cependant, un logiciel peut avoir plusieurs auteurs dans des cadres de collaboration très différents (stage, doctorat, collaboration avec des entreprises, ou entre plusieurs établissements de recherche). Le Code de la Propriété Intellectelle (CPI) définit dans son article L113-2 différentes catégories d'œuvres : œuvre de collaboration, œuvre collective, œuvre composite. Toutes ces catégories peuvent, suivant le cas, s'appliquer à un même logiciel.

Le concept d'œuvre de collaboration indique une collaboration "horizontale" : les collaborateurs participent au même niveau et sont tous considérés comme auteurs de l'œuvre (pourcentage égal de participation). L'œuvre collective correspond à une collaboration "verticale" : une seule personne sera auteure de l'œuvre. Dans le cas particulier des stages, le développement ne peut pas se faire sans l'expérience du responsable de stage : il y a à la fois une collaboration verticale et horizontale. Il est donc difficile d'utiliser une seule de ces catégories pour caractériser les logiciels quand des stages sont inclus.

La liste d'auteurs avec leur pourcentage de participation est ainsi un outil indispensable pour clarifier ce point.

Les droits patrimoniaux

L'article L113-9 du CPI stipule : "Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer."

Donc en cas de travail salarié, l'auteur d'un logiciel est différent du détenteur des droits patrimoniaux (qui est l'employeur). Cela ne s'applique pas dans le cas des stages car un stagiaire ne peut pas être assimilé à un salarié ou à un agent de l'Etat. Donc il est essentiel de connaître le statut des personnes ayant collaboré à la création du logiciel. La question "qui est propriétaire des droits patrimoniaux ?" est aussi complèxe que celle des auteurs et peut requérir la décision d'un juge.

Si le logiciel est lié a un contrat de collaboration, les droits patrimoniaux du logiciel produit peuvent y être attribués. Ces contrats peuvent aussi établir les licences qui lui seront associées. Les négociateurs du contrat doivent être attentifs sur ces deux points.

Concernant les autres contributeurs non salariés du laboratoire (bourses, stages non gratifiés, thèses sans rémunération... ) il est indispensable de leur faire signer un engagement comportant des clauses sur la propriété intellectuelle et des règles de confidentialité à respecter.

Finalement, la liste des détenteurs des droits patrimoniaux découle directement de la liste d'auteurs et de leur statut, d'où l'importance de bien établir cette première liste.

Note : la liste de détenteurs des droits patrimoniaux s'indique dans le code source du logiciel (ligne de copyright, voir la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume).

La documentation d'un logiciel et les droits patrimoniaux

On peut parfois considérer que la documentation d'un logiciel est soumise aux normes classiques de la propriété intellectuelle, or le CPI stipule que les règles des droits patrimoniaux s'appliquent aux logiciels et leurs documentations. En conséquence, toute décision qui fait intervenir ces droits patrimoniaux (licence, diffusion...) correspond aux détenteurs de ces droits.

La cession des droits

Le Code de la Propriété Intellectuelle traite dans son chapitre III de la cession des droits d'auteur, aussi appellée parfois cession des droits patrimoniaux. Il est impossible de céder les droits moraux, qui restent toujours associés aux auteurs d'une œuvre.

Récemment nous avons vu le cas d'une demande de cession des droits (disclaimer of rights) faite par la FSF (Free Software Fondation) à une Université, dans le cadre d'un stage d'un étudiant de l'Université dans un autre établissement pour faire évoluer le logiciel GCC.

Le logiciel GCC possède une longue liste d'auteurs, et donc il peut être très compliqué de contacter tous les propriétaires du logiciel face à un problème légal. La FSF pourra faire face au problème et représenter les intérêts de la communauté des développeurs si les cessions de droits sont faites. Voir How to contribute à GCC, GDB, Binutils et autres.

Le personnel d'un laboratoire de recherche

Dans cette section nous parcourons la liste des différents types de personnel d'un laboratoire et leur régime (salarié ou pas), ce qui déterminera les droits patrimoniaux associés à leur participation au développement d'un logiciel.

Note : pour les unités mixtes de recherche (UMR), le concept d'établissement hébergeur peut s'appliquer avec des conséquences importantes. Ce point s'étudie lors de la signature des contrats quadriennaux.

Régime salarié. L'auteur a la qualité d'employé ou d'agent de l'Etat, des collectivités publiques ou des établissements publics à caractère administratif. L'université ou l'établissement employeur est le détenteur des droits patrimoniaux associés à l'œuvre. Cette règle s'applique si l'auteur est :

  • chercheur (chargé de recherche, directeur de recherche),
  • enseignant-chercheur (maître de conférences et professeur des universités),
  • enseignant-chercheur associé (maître de conférences et professeur des universités associé ou invité),
  • ingénieur, assistant ingénieur, technicien,
  • un chercheur en accueil en délégation (CNRS, INRIA...),
  • un doctorant allocataire de recherche.

Même s'il s'agit des postes non-permanents, le régime salarié peut s'appliquer aussi pour les postes suivants :

  • post-doctorants,
  • attachés temporaires d'enseignement et de recherche (ATER),
  • doctorants : contrat doctoral, bourses CIFRE,
  • CDD.

Pour les doctorants et post-doctorants la source du financement est promordiale et il faut veiller à la signature de documents qui comportent des clauses sur la propriété intellectuelle et la confidentialité.

Lors des congés pour recherches ou conversions thématiques (CRCT), l'employeur ne change pas. Lors de la mise à disposition, du détachement, de disponibilité d'un agent, il faut étudier le cas d'un changement de régime (salarié/non-salarié) et le changement d'employeur (pour tenir en compte le détenteur des droits patrimoniaux associé à cette période).

L'auteur n'a pas la qualité d'employé. Dans ce cas, l'auteur est aussi le détenteur des droits patrimoniaux (en fonction du pourcentage de participation au projet logiciel). Cette règle s'applique si l'auteur a la qualité de :

  • professeur émérite, retraité,
  • boursier,
  • stagiaire (voir la Circulaire du 23 juillet 2009 relative à l'accueil des étudiants de l'enseignement supérieur en stage),
  • étudiant participant sur des projets sans le statut de stagiaire.

Ce dernier statut ne correspond pas, bien entendu, à des personnels du laboratoire, mais il apparaît souvent lié aux activités d'enseignement du personnel du laboratoire. L'étudiant pourrait, par exemple, être sous contrat d'apprentissage, ce qui est une forme de contrat de travail. L'étudiant peut suivre d'autre type de formation en alternance, selon des cadres juridiques différents tels que contrat de travail (entre entreprise et salarié), convention de stage (entreprise-stagiaire-université ou centre de formation), convention CIFRE (montage pluri-contractuel entreprise-salarié-université-ANRT), ou convention de formation continue (entreprise-université).

Le statut de retraité ne correspond pas non plus à des personnels d'un laboratoire, mais il arrive parfois que des personnes à la retraite continuent à s'impliquer dans des projets (logiciels) commencés lors d'un travail salarié.

En l'absence de dispositions prévues par convention signés par ces personnes (stage, d'accueil, cession de droit, ...), elles conservent les droits de propriété des logiciels auxquels elles ont participé (selon leur pourcentage de participation). Pour obtenir plus d'information sur les clauses des conventions nécessaires, on peut s'adresser aux services de ressources humaines ou aux services des affaires juridiques de vos établissements.

Vous l'aurez compris, ce sont des cas un peu hétéroclites qui posent des questions délicates. Il faut les traiter avec prudence, les conséquences légales pouvant s'avérer importantes.

La mobilité des personnels

La mobilité des personnels qui ont collaboré à un projet logiciel peut devenir un casse-tête lorsqu'il est nécessaire de contacter tous les acteurs intervenant aux décisions importantes dans son évolution. Bien que cela puisse sembler rare, cela arrive assez souvent et il vaut mieux en prévoir les conséquences.

Une possible solution est d'ajouter, dans le document d'accord de licence une adresse de contact pour chaque auteur et une clause qui indique l'engagement des parties à donner une nouvelle adresse de contact lorsque celle qui figure sur le texte ne fonctionne plus.

Lorsque les responsables d'un projet logiciel changent de laboratoire, il nous semble qu'une copie du dossier du logiciel doit rester au laboratoire. Pour la gestion de ces dossiers, la figure de correspondant logiciels du laboratoire est une solution à étudier.

Choisir une licence

Pour plus d'informations concernant les licences libres nous vous invitons à consulter la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume et la fiche PLUME Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ? Fiche Plume qui étudie les avantages des logiciels libres dans le monde scientifique. Ces deux documents vous seront peut-être utiles pour étudier la question du choix de licence.

Si le logiciel est lié à un contrat de collaboration, la licence sous laquelle le logiciel obtenu sera distribué peut y être indiquée et fait partie des négociations habituelles à la rédaction du contrat. Il peut y avoir des contrats différents qui financent un projet, il faut y indiquer quelles sont les parties du logiciel ou les fonctionnalités qui sont attachées au contrat et veiller à la "compatibilité" des contrats (ou des licences associées).

Si le logiciel est une œuvre dérivée d'un logiciel sous licence GPL, sa diffusion doit se faire en respectant cette licence : le logiciel dérivé sera diffusé en code source et sous licence GPL. Rien n'empêche l'utilisation simultanée de plusieurs licences qui seront peut-être utiles selon le cadre de collaboration mais cela n'est pas possible pour tous les types de licences des briques initiales.

Dans les autres cas, la licence doit être décidée avec les détenteurs des droits patrimoniaux. Pour les licences libres, les tutelles peuvent établir des procédures qui donnent un accord au préalable et simplifient la diffusion rapide des logiciels produits dans les laboratoires de recherche sous ce type de licence.

Il est utile d'établir un accord de licence daté et signé par tous les auteurs : << Les auteurs du logiciel X et signataires de ce document manifestent leur accord pour diffuser le logiciel (nom, description) sous la licence...>>

Respecter une licence

Si vous avez utilisé des briques logicielles dans votre logiciel, cela veut dire que vous connaissez quels sont les droits associés à ces briques (ie. que vous connaissez leurs licences) et quelles sont les obligations qui vous sont imposées (et que vous avez acceptées).

Il y a des licences qui indiquent qu'un logiciel est de libre utilisation pour la recherche mais pas pour des utilisations commerciales, d'autres indiquent qu'il faut citer un ouvrage lié au logiciel... Ces obligations doivent être respectées.

Les documentations des logiciels sont aussi soumises à des licences, qui à leur tour imposent des obligations à respecter.

Documents pour établir un dossier du logiciel

Voici donc la liste des documents à rassembler lors du développement d'un logiciel :

  • Matériel préparatoire : notes, articles... Il sert à dater le logiciel.
  • Document de description, avec nom, dates importantes, liste d'auteurs (avec pourcentage de participation) et leur affiliation.
  • Liste des briques logicielles avec leur licence (ou documents qui accordent des droits d'utilisation, de rediffusion, ...).
  • Document d'accord de licence avec liste d'auteurs, leur adresse de contact, leur signature...
  • Contrats
  • Conventions de stage, conventions d'accueil...

Ces documents sont à revoir à chaque nouvelle version du logiciel.

Les divers types de collaboration au développement d'un logiciel

La fiche PLUME Guide laboratoire pour recenser ses développements logiciels Fiche Plume étudie la question du recensement des logiciels produits dans les laboratoires de recherche.

La procédure proposée dans ce document étudie les logiciels qui sont développés complétement dans le cadre d'un ou plusieurs laboratoires de recherche, mais il arrive souvent que des chercheurs et des développeurs d'un laboratoire s'impliquent dans des projets logiciels libres et parfois externes aux établissements de recherche français. Dans ce cas, et en fonction de l'importance de la contribution, il est conseillé d'informer le laboratoire de cette contribution et de mentionner dans votre collaboration le détenteur des droits patrimoniaux de votre travail.

Comment gérer les collaborations de chercheurs de plusieurs laboratoires, y compris à l'étranger ? À notre avis, cette question doit se traiter de façon similaire à celle des publications du laboratoire, en faisant attention "à la signature" du logiciel : auteur (avec pourcentage de participation) et détenteur des droits patrimoniaux.

Références

Construire une communauté autour du Logiciel Libre

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 06/03/10
  • Correction mineure : 06/03/10
Mots-clés

Construire une communauté autour du Logiciel Libre

  • Type de ressource : article, transparents
  • Date de publication du document ou de l'événement : Mai 2009
  • Auteur(s) ou responsable(s) :

    Stéphane Ribas, Michel Cezon

  • Contact pour plus d'informations : stephane.ribas AT inria.fr, michel.cezon AT inria.fr

Cette fiche ressource a pour objectif d'indiquer deux références/articles sur le thème "Construire une communauté autour du Logiciel Libre" :

Etude sur les métiers de l’informatique dans les laboratoires de recherche (BAP E)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 23/02/10
  • Correction mineure : 05/07/10
Mots-clés

Etude sur les métiers de l’informatique dans les laboratoires de recherche (BAP E)

Cette étude CNRS porte sur les métiers de l’informatique au sein des unités de recherche.

Elle décrit comment ces métiers influent directement sur la qualité des recherches et comment ces derniers sont intégrés au plus près des programmes développés. A partir d’une analyse détaillée de la situation actuelle et des tendances d’évolution, ce rapport propose des recommandations pour l’avenir, en particulier pour optimiser le développement de la recherche qui est très fortement corrélé au développement de l’informatique.

L’analyse est issue d’une enquête et d’entretiens qui ont permis de :

[1] caractériser quantitativement et qualitativement ces métiers de l'informatique qui recouvrent de nombreuses spécificités au sein des unités de recherche. Il s'agit d'identifier et de décrire, les activités individuelles, mais aussi les pratiques collectives liées à l’informatique et les conséquences attendues en termes d’organisation, de métiers et de développement professionnel.

[2] préciser la nature et le contenu des pratiques collectives et les conséquences induites en termes de modes d’organisation, d’évolution technologique et de développement professionnel.

L’analyse conduit à un certain nombre de recommandations pour optimiser les moyens en informatique :

1) Mener une réflexion sur la création d’une famille professionnelle dédiée à l’exploitation des bases de données scientifiques en BAP E en intégrant le transversalité avec les familles professionnelles voisines des BAP A, D ou F.

2) Mener une réflexion sur les modalités d’accompagnement par expert métier au plan local pour formaliser les demandes de postes et assurer un meilleur suivi des parcours professionnels et des mobilités.

3) Mener une réflexion sur un rattachement secondaire à la BAP E pour les personnels ayant une double compétence informatique et autre domaine scientifique.

4) Augmenter la visibilité des offres de formation locales et nationales

5) Inciter la mise en place de plans de formation des réseaux métiers informatique au-delà des ANGD

6) Adapter les formations à destination des informaticiens par la création notamment d’écoles technologiques

7) Mener une réflexion pour la mise en place d’une coordination nationale pour l’informatique en appui à la recherche scientifique

Les chapitres de cette étude sont :

1 Introduction
1.1 Le contexte
1.2 La finalité de l’étude
1.3 Le périmètre de l'étude
1.4 La méthodologie utilisée

2 Les métiers de l’informatique dans les laboratoires de recherche
2.1 L’architecture du système d’information et l’administration des systèmes et des réseaux (SISR)
2.2 L’informatique scientifique
2.3 Les caractéristiques des métiers de l’informatique
2.3.1 Les métiers liés au SISR
2.3.2 Les métiers de l’informatique scientifique

3 L’organisation de l’informatique
3.1 Au niveau de l’organisme
3.2 Au sein des laboratoires
3.2.1 L’organisation des moyens humains affectés au SISR
3.2.2 L’organisation des moyens humains affectés à l’informatique scientifique
3.3 Les conséquences de ce mode d’organisation
3.3.1 Les points forts
3.3.2 Les points d’amélioration
3.3.3 Les risques

4 L’évolution de l’environnement, des usages et des métiers
4.1 L’évolution des besoins scientifiques et des usages
4.1.1 Le domaine du SISR
4.1.2 Le domaine de l’informatique scientifique
4.2 L’impact des évolutions technologiques sur les métiers
4.2.1 Le domaine du SISR
4.2.2 Le domaine de l’informatique scientifique
4.3 L’évolution (structure, contraintes environnementales)
4.3.1 Le domaine du SISR
4.3.2 Le domaine de l’informatique scientifique
4.4 L’acquisition des compétences
4.4.1 Compétences des personnels en regard de leurs fonctions
4.4.2 La formation

5 Les recommandations
5.1 L’organisation au niveau institutionnel
5.2 L’organisation au niveau (inter)-laboratoire
5.3 La reconnaissance et le développement des compétences

6 Annexes
6.1 Annexe 1 : Lettre de cadrage
6.2 Annexe 2 : Contributeurs
6.3 Annexe 3 : Questionnaire centré sur les métiers liés au Système d’information, du laboratoire, aux systèmes réseaux.
6.4 Annexe 4 : Questionnaire centré sur les métiers liés au développement au calcul scientifique, aux statistiques et aux SI scientifiques
6.5 Annexe 5 : Trame de l’entretien avec les directeurs de laboratoire

NB: Cette fiche de résumé a été rédigée par Maurice Libes et validée par Françoise Berthoud

Méthode pour tracer la propriété intellectuelle dans des codes logiciels

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 15/02/10
  • Correction mineure : 15/10/10
Mots-clés

Méthode pour tracer la propriété intellectuelle dans des codes logiciels

Le Deliverable A1.D2.1.4 (en anglais, sous licence CC by-sa) du projet Qualipso Fiche Plume (Quality Platform for Open Source Software  propose une méthode pour tracer la propriété intellectuelle (IPR tracking methodology en anglais).

Résumé document

Améliorer la qualité légale et la sécurité des briques logicielles ou des logiciels diffusés sous licences libres est généralement considéré de grande importance pour la communauté des logiciels open source. Le projet QualiPSo étudie ces questions dans l'activité "Questions légales" en contribuant à augmenter la sensibilisation de la communauté et de son écosystème.

L'objectif de ce document est de fournir un cadre de travail général pour Tracer les droits de la propriété intellectuelle (en anglais : Intellectual Property Rights Tracking (IPRT)) des logiciels dont le développement s'appuie dans la réutilisation des briques logicielles et dans les projets collaboratifs. La méthode proposée est néanmoins aussi générale que possible et peut s'appliquer dans d'autres cadres de développement (comme par exemple les logiciels hybrides ou tout simplement propriétaires).

La méthode IPRT évalue les processus de licence in (licences des briques logicielles utilisées) et de licence out (licence de l'ensemble du logiciel proposé pour sa réutilisation et son exploitation). Elle décrit les éléments clé qui ont des conséquences dans le statut légal du logiciel : les "bonnes pratiques" qui respectent les droits de la propriété intellectuelle ont une importance considérable.

On propose dans ce document d'étudier le processus de développement du point de vue légal, de façon à obtenir des logiciels avec un statut légal contrôlé et qui correspond aux modèles d'exploitation et de diffusion définis pas ses propriétaires ou les éditeurs du logiciel. Cela permet de déterminer les risques associés à l'utilisation des briques dont le statut légal n'est pas bien déterminé (ou de compatibilité peu claire) et de prendre les actions nécessaires pour éviter ces risques (techniques, légales, garanties).

Dans la section 2 on présente les objectifs de la méthodologie IPRT, de même que le concept de Satut légal du logiciel. La section 3 présente la méthodologie IPRT et la section 4 décrit le module d'audit et les éléments clé qui ont des conséquences dans le statut légal des logiciels. Ce module est un exemple d'implémentation de la méthodologie IPRT, il a été appliqué au projet européen PALETTE et au projet DIET.

Fichier attachéTaille
A1.D2.1.4.pdf2.1 Mo

La place des logiciels libres dans l'Enseignement Supérieur et la Recherche, dans l'administration, en France, en Europe et dans le monde

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/01/10
  • Correction mineure : 21/10/10
Mots-clés

La place des logiciels libres dans l'Enseignement Supérieur et la Recherche, dans l'administration, en France, en Europe et dans le monde

Cet article est sous licence Creative Common By NC ND.
Il a été présenté aux journées JRES 2009 sous le titre "La place des logiciels libres dans l'Enseignement Supérieur et la Recherche, état des lieux à travers PLUME. Et que font les autres ?". Vous pouvez consultez : l'article Fichier PDF, les transparents Diaporama et la video associée de la présentation Vidéo (malheureusement tronquée).

Résumé

Cet article compile un ensemble d'informations sur la place des logiciels libres dans notre communauté de l'Enseignement Supérieur et la Recherche (ESR), en partie à travers PLUME. Puis il examine ce qui se passe dans les autres administrations, dans les entreprises françaises, ensuite en Europe et dans le monde. Il termine par un retour sur notre communauté et sur l'évolution des modes de diffusion des développements logiciels de celle-ci, qui devient productrice de logiciels libres, à travers l'expérience de PLUME.

Le logiciel libre

Un logiciel est dit « libre » ou « open source » lorsque sa licence donne à l'utilisateur 4 libertés :

  • l'utiliser pour tout usage,
  • étudier son fonctionnement et pouvoir l'adapter (nécessite l'accès aux sources),
  • le re-distribuer,
  • l'améliorer et redistribuer ses améliorations (nécessite l'accès aux sources).

On notera qu'il n'est pas question ici de gratuité : libre ne veut pas dire gratuit !

Ce type de licence, formalisé au début des années 80, aux Etats-Unis, par Richard Stallman est considéré par certains comme la source d'une rupture dans le monde de l'édition logicielle semblable à la révolution industrielle. Le libre commence à peser dans l'économie du logiciel : le chiffre d'affaire du secteur en France était de 1,1 Milliards d'Euros en 2008, il devrait atteindre 1,5 milliards d'Euros en 2009 et pourrait dépasser les 3 milliards d'Euros en 2012 selon le cabinet Pierre Audoin Consultants.

Le libre dans l'Enseignement Supérieur et la Recherche en France

La position officielle des établissements vis-à-vis du libre

Il n'y a pas, à notre connaissance, de position officielle ferme d'une université, d'une grande école ou d'un établissement de recherche sur le choix du libre, avec une stratégie, un plan de migration...
Pourtant, la notoriété des établissements facilite la mise en avant des accords qu'ils passent avec les grands acteurs du libre ou les éditeurs majeurs du secteur.

On ne peut ignorer par exemple que l'Université Pierre Mendès France Grenoble a adhéré à l'April (association pour promouvoir et défendre le logiciel libre) début 2009. Le communiqué précise : « En adhérant à l’April, l’université veut soutenir le logiciel libre symbole d’équité sociale et de distribution du savoir ». Mais depuis, il ne semble pas y avoir de suite sur le terrain ...

D'autres établissements investissent aussi bien dans le libre que dans le propriétaire.
C'est par exemple le cas de l'INRIA qui, d'un côté, soutient publiquement le logiciel libre en sponsorisant fortement l'Open World Forum les 1 et 2 octobre 2009. Sur son stand un document met en avant le CIRILL, nouveau Centre de Recherche et d'Innovation sur le Logiciel Libre, son travail sur les licences CeCiLL, sa participation au consortium Object web... Et, d'un autre côté, le 6 octobre, en présence de la ministre de l'Enseignement Supérieur et de la Recherche et de Steve Ballmer, son directeur et celui du laboratoire de Microsoft à Cambridge (R.U.) renouvellent leur programme de collaboration.

Il en est de même pour le CNRS, porteur du projet PLUME, également associé avec Microsoft et l'Ecole Polytechnique pour créer la chaire «Optimisation et Développement Durable». « Inaugurée officiellement le 3 juin 2009, celle-ci vise à développer des techniques et des outils d'optimisation qui pourront être appliqués à des problèmes réels liés au développement durable » dit le communiqué sur le site des différents partenaires.

A l'opposé du libre, on voit aussi plusieurs universités ou grandes écoles mettre en place des partenariats avec certains éditeurs propriétaires (comme SAP, ORACLE, Microsoft...), très avantageux financièrement mais très contraignants et qui, de fait, participent à la promotion de ces produits. Ces éditeurs parient avec bon sens, sur le fait qu'un étudiant qui connait un outil cherchera à l'utiliser aussi dans vie professionnelle et deviendra donc un client.

La France est le seul pays, à notre connaissance, dans lequel un « groupe logiciel » au sein du ministère de l'Enseignement Supérieur et de la Recherche, mutualise les négociations avec des éditeurs. Ce groupe veille à ce que les accords qu'il conclut proposent les conditions les plus favorables possibles aux étudiants et aux établissements, ce qui est très efficace. Mais il n'a pas de position forte vis à vis de solutions libres.

Au-delà des annonces chocs dans la presse, il existe partout au sein de la communauté une démarche pragmatique d'utilisation conjointe du libre et du propriétaire au cas par cas. La plate-forme PLUME est un exemple de mutualisation de compétences pour accompagner cette démarche pragmatique.

Les projets et consortia

Une autre démarche pragmatique est la conduite de projets et la mise en place d'organisations. En France, plusieurs établissements de recherche et des entreprises de taille importante participent à des consortia autour des logiciels libres. Ces structures sont quasiment toujours internationales et intercontinentales.

On peut citer l'exemple d'OW2 né d'une initiative française. En 2002, l'INRIA, Bull et France-Télécom initient Objectweb suite à plusieurs projets RNTL2. Objectweb fusionne en 2006 avec Orientware (Chine) après 2 ans de travaux en commun pour donner naissance au consortium OW2. Environ 100 projets, orientés autour des intergiciels - « middleware » - et 5000 personnes participent actuellement à OW2 qui se présente à la fois comme une communauté open source et une organisation pilotée par la communauté. : « open source community and a community-driven organization ». Parmi les 15 membres « stratégiques », on note les initiateurs mais aussi Alcatel Lucent, Red Hat, Thales et parmi les membres « corporate », le Ministère de l'Intérieur, de l'Outre-mer et des Collectivités Locales. Récemment, à l'occasion d'un accord franco-brélisien, SERPRO, entreprise brésilienne, et Bull, qui coopéraient déjà dans le cadre de OW2, ont annoncé qu'ils travailleront ensemble autour des technologies de portail, des environnements de développement applicatif et sur le marché des logiciels libres pour l’éducation en ligne. Cet exemple souligne la visibilité et les opportunités offertes aux entreprises qui coopèrent dans le cadre des consortium initiés par des organismes de recherche.

Il existe bien d'autres consortia sur le même modèle : Qualipso qui regroupe 18 membres en Europe, Brésil et Chine et dont les thèmes sont les modèles économiques, les licences, les forges ; FOSSbazaar qui est une communauté de réflexion autour d'intérêts communs et aussi une vitrine pour les membres de la communauté. Il est intéressant à ce propos de lire la charte qui explique l'intérêt d'y participer...

Les membres de ces consortia participent souvent à plusieurs de ces structures et il arrive même qu'un consortium adhère à un autre. Ces structures sont des majors du secteur et leur influence conséquente.

Le groupe thématique logiciel libre du pôle System@tic

Le gouvernement français a mis en place des pôles de compétitivité qui rassemblent, sur un territoire donné, des entreprises, des centres de recherche et des organismes de formation, afin de développer des synergies et des coopérations au travers de projets coopératifs innovants. Le pôle System@tic Paris Région, créé en 2005, regroupe 5 domaines sectoriels, dont un consacré au logiciel libre : le Groupe Thématique Logiciel Libre dont le rôle est de fédérer les acteurs du logiciel libre en Ile-de-France, de promouvoir l'émergence d'une industrie du libre en contact étroitement liée avec le monde de l'enseignement et de la recherche, dans le but de favoriser le développement de logiciels libres innovants qui profitent des avancées scientifiques de l'Ile-de-France. Les sujets traités sont, par exemple, le développement coopératif et distribué, le cycle de vie très court, les grandes bases de code source, la compatibilité de licences. Le Pôle soutient actuellement 14 projets dont les partenaires sont industriels et académiques. Il faut noter que ce pôle bien qu'étant dénommé « mondial » ne concerne que l'écosystème de la région parisienne. Ancré dans la société, il est membre de Syntec informatique.

Les formations

Le logiciel libre est, par construction – puisqu'il donne accès aux sources et qu'il permet l'étude complète et en profondeur des logiciels – un excellent outil d'aide à la formation à tous les niveaux, depuis le programmeur, jusqu'à l'expert. Il existe de nombreuses formations autour des logiciels libres, professionnelles, diplômantes, à distance.... Une fiche PLUME est un bon point d'entrée vers plusieurs référentiels de formations.

Les entreprises du secteur ne négligent pas cet aspect puisqu'en mars 2009, le Syntec Informatique publie les Résultats de l’étude OPIIEC « Impact du logiciel libre en France » (décrite ci-après), avec le sous-titre « investir dans la formation pour optimiser les apports du logiciel libre ». Pour conserver l'avance de la France dans ce secteur, il propose des actions très précises telles que l'investissement en formations initiales et professionnalisantes avec, entre autres, la formation d'experts capables d'influencer les gros projets internationaux, d'informaticiens capables d'intégrer libre et propriétaire dans un même projet, la valorisation de l'expérience et la formation à l'écosystème du libre (droit, économie du libre, collaboration, gestion de projets...).Mais de nombreux professeurs en informatique d'universités adeptes du libre regrettent que les logiciels libres ne soient pas plus pris en compte dans l'enseignement des méthodes de développements et de gestion de projets informatiques. Ceux-ci remettent en cause les traditionnelles méthodes de développement et nécessitent d'autres démarches (ré-utiliser l'existant...).

Une analyse à travers le projet PLUME et sa plate-forme

Le projet PLUME vise à mutualiser les compétences en logiciels, principalement libres, et à promouvoir l'utilisation de ces logiciels dans la communauté de l'Enseignement Supérieur et la Recherche. La plate-forme, ouverte depuis novembre 2007, compte actuellement :

  • 221 fiches descriptives de logiciels validés,
  • 25 de logiciels à valider,
  • 8 de logiciels en test,
  • 82 de développements Enseignement Supérieur – Recherche, autrement dit développements issus des laboratoires
    120 ressources et 13 fiches en anglais avec 406 contributeurs,
  • 891 membres et plus de 40 000 visites par mois.

La quasi totalité de ces données traitent de logiciels libres. Le nombre de logiciels (> 350), de contributeurs volontaires 'non rémunérés' (> 400) qui ont rédigé ou relus ces fiches, est déjà significatif et démontre le poids du libre dans l'informatique de cette communauté.
Cette plate-forme est aussi un point d'observation pour avoir une certaine photographie de la pénétration du libre par domaine scientifique, métier, activité et domaine informatique. Un coup d'œil sur la page  où est indiqué le nombre de documents PLUME par mot-clé révèle les orientations.
A noter que les tendances décrites ci-dessous ne représentent que le « taux de participation à PLUME ».

Si certains groupes ne sont pas présents c'est peut-être qu'ils désapprouvent ce projet, ne sont pas intéressés ou qu'ils n'ont pas une démarche d'échange et de diffusion de leurs connaissances (contribuer à PLUME c'est donner une partie de son savoir). Mais néanmoins, PLUME reçoit des propositions de contributions tout à fait spontanées, vraiment très variées, émanant de personnes que l'équipe PLUME connait très rarement. Les contributions ne sont donc pas restreintes à un cercle d'initiés.

Concernant les domaines scientifiques, les outils pour les mathématiques (76 fiches), la biologie (47) et l'informatique sont très présents dans PLUME. Sciences de l'Homme et de la Société (27), chimie(15), mécanique (12) suivent. Mais la physique et les sciences de l'univers sont quasiment absents.

Les métiers et les activités les plus représentés sont les logiciels pour les développeurs, les administrateurs systèmes et réseaux ainsi que le calcul scientifique, puis, le travail coopératif et la documentation-IST. Mais fait surprenant, il y a proportionnellement très peu d'outils pour la formation (formation s'entend au sens enseignement et formation permanente) alors que l'enseignement est une activité majeure de la communauté. De même pour le management (au sens large) où peu d'outils sont référencés. Les logiciels propriétaires doivent être très majoritaires dans ces deux activités.

Globalement, le nombre très important de logiciels métiers (souvent très pointus) de la recherche proposés dans PLUME est très surprenant. Il y a donc beaucoup de libre dans les logiciels métiers de la recherche.

Tous les domaines informatiques sont représentés dans PLUME proportionnellement à leur utilisation dans l'informatique dans notre communauté. Bien évidemment les outils Internet, d'administration réseaux et systèmes sont souvent des logiciels libres. Sauf un domaine qui est sous-représenté : la gestion (au sens logiciel de gestion, système d'information) où très peu d'outils sont présents. Ceci peut éventuellement s'expliquer par les produits proposés par les structures nationales d'informatique de gestion (DSI du CNRS et AMUE) qui sont uniquement des logiciels propriétaires et aussi par l'existence du consortium ESUP portail.

Le nombre de fiches PLUME ne peut pas permettre de mesurer la pénétration de Linux comme poste de travail, ni l'utilisation de OpenOffice.org et de Firefox, qui sont souvent les trois produits transversaux libres de référence. Néanmoins, lorsqu'on regarde les statistiques d'accès des visiteurs sur PLUME, il y a 66 % de Windows, 18 % Linux et 12 % MacOS avec comme navigateur : 62 % de Firefox-mozilla et 25 % d'IE. Les chiffres de Framasoft ('l'équivalent de PLUME' pour le grand public) sont 83 % de Windows, 11 % Linux, 5 % Mac avec 57 % de Firefox et 35 % d'IE.

Le secteur public en France

Examinons maintenant la situation dans les autres administrations. Il n'y a plus actuellement d'incitation à passer au libre dans l'administration.
Le secteur public dans notre pays, est soumis à des règlementations administratives a priori semblables à celles de l'enseignement supérieur et de la recherche. La première contrainte règlementaire est celle des marchés publics : on peut avoir l'impression que les règlementations empêchent tout choix de logiciels libres. Or il existe actuellement toute la documentation nécessaire pour intégrer le libre dans les réponses potentielles et on verra dans la suite de cet article que de nombreuses entités publiques savent bien adresser cette difficulté. On se réfèrera par exemple au très précieux Guide pratique d'usage des logiciels libres dans les administrations qui détaille comment rédiger des appels d'offre.

Autres règlementations : les référentiels RGI, RGAA, RGS. Le RGI et le RGAA sont en vigueur depuis quelques jours. Il n'y a pas dans ces documents d'incitation pour ou contre le libre.

Comment s'organisent les ministères et les grandes administrations ?

Les ministères, comme les universités, sont libres de leurs choix techniques et leurs choix de logiciels ne dérogent pas à la règle. On verra dans ce chapitre quels sont les ministères les plus avancés vers le libre et pour quelles raisons.

Pour réduire ses coûts informatiques dans un contexte budgétaire difficile et gagner en indépendance vis-à-vis des éditeurs, la gendarmerie mise sur ses ressources internes, une petite équipe d'informaticiens, et sur les logiciels libres. La migration des postes de travail a été organisée avec soin. Après inventaire des applications nécessaires, la gendarmerie avait déjà adopté OpenOffice.org comme suite bureautique et Thunderbird pour le client de messagerie ainsi que le navigateur Firefox. Elle a également placé sur un intranet web un certain nombre d'applications très dépendantes au système pour plus de modularité. Annoncé en janvier 2008, la migration de 70 000 postes Windows sous Linux Ubuntu s'achèvera en 2013. 7 M euros/an devrait être ainsi économisés, en réduisant le coût total de possession du poste de travail (TCO). Selon la gendarmerie, une migration vers Vista aurait été plus difficile. La migration se fait avec le soutien gratuit de Canonical Ltd. (sous forme d'une petite équipe technique). Dans un futur proche, un marché doit être passé pour ce soutien. Canonical et la gendarmerie se disent satisfaits. Tous les gendarmes devraient donc être équipés de postes Ubuntu à moyen terme. Ce projet devrait permettre d'accroitre l'efficacité du système d'information de la gendarmerie tout en économisant des sommes importantes en coûts de licences. La gendarmerie donne ainsi un exemple ambitieux et réussi de migration, sur la durée, avec des ressources internes.

Un besoin majeur du ministère de la défense est de disposer d'une messagerie sécurisée. Depuis 2008, une directive négociée pendant 18 mois entre les différentes entités (marine, armée de terre, gendarmerie,...et le ministère) recommande maintenant Thunderbird et Postfix dans le ministère (sinon, il faut justifier !). Il a choisi de prendre en compte les communautés et les méthodes du libre et d'y participer en contribuant à Thunderbird pour proposer des extensions spécifiques utiles à la défense, mais aussi à l'industrie privée. Les informaticiens du ministère sont donc devenus membres actifs de la communauté et cette participation a donné naissance à Trustedbird, fonctionnalités complémentaires à Thunderbird et nécessaires à la défense, projet soutenu par DGA/ministère de la défense et BT. Les compléments développés dans ce cadre sont donc proposés sous licence libre et versées à la communauté.
Le Ministère des Affaires Étrangères et Européennes a démarré en 2003 un projet de développement interne pour répondre à ses propres besoins web. Le produit passe en licence CeCiLL en 2005 pour régler des difficultés juridiques et faciliter la passation de marchés pour les projets métiers. Acube est actuellement déposé dans la forge de l'Adullact. La communauté des utilisateurs, entreprises contributrices et partenaires est officialisée sous forme d'une association en 2008. On remarquera que la démarche est complètement différente des précédentes puisque tous les développements sont réalisés par des entreprises privées dans le cadre de marchés.

De son côté, la Caisse des Dépôts et Consignations , après étude approfondie, a souhaité à la fois, réduire ses coûts bureautique et assurer la pérennité des documents créés en utilisant un format normalisé. Le format ISO Open Document a été choisi et une opération de migration vers OpenOffice.org organisée avec l'aide d'une SSLL. Toutes les applications développées devront utiliser le format Open Document pour réduire la dépendance des logiciels métiers aux applications tierces. Pour les échanges de documents ne nécessitant pas de modifications, c'est le format PDF qui est utilisé.

Ces différents exemples montrent que les raisons des administrations pour choisir le libre sont diverses, même si le coût de licences apparaît souvent et que les moyens utilisés pour les migrations sont également divers.

Les administrations territoriales et l'ADULLACT

Les administrations territoriales sont nombreuses en France, leurs profils sont différents mais leurs besoins métier sont souvent identiques. La gestion des cimetières est un exemple de besoin commun des 36 000 communes françaises.

Partant du principe que l'argent public ne doit payer qu'une seul fois, l'association ADULLACT créée en 2002, s'emploie à développer un porte-feuille de logiciels métier pour les besoins des collectivités publiques. La méthode est simple et efficace : regrouper les besoins, lancer un appel d'offre de développement libre et mettre à disposition les développements sur une forge bien visible. L'empreinte de l'association est importante puisqu'en septembre 2009 elle comptait plus de 7500 structures territoriales adhérentes pour une population totale de 48 millions de personnes. Plus de 4500 développeurs travaillent aux 437 projets sur la forge et les téléchargements approchent les 700 000. L'association est très active : travail de fond, représentation active à l'international...

Il est bien évident que les collectivités utilisent également des logiciels libres pour des besoins transverses et la presse ne manque pas de faire écho des opérations importantes.

Le monde des entreprises françaises

Comment savoir ce qui se passe au sein des entreprises françaises ? Nous avons choisi d'appuyer nos propos sur les différentes enquêtes publiées par l'INSEE et les organisations professionnelles et publiées au cours de conférences par les grands acteurs du secteurs.

Que dit l'INSEE ?

L'INSEE a récemment publié « E-administration, télétravail, logiciels libres : quelques usages de l’internet dans les entreprises ». Dans ce document, les auteurs signalent un léger développement des systèmes d'exploitations libres. « Ces systèmes restent très minoritaires mais sont en légère progression (14 % des entreprises d’au moins 10 salariés qui ont un ordinateur en janvier 2008 contre 12 % en 2007). On retrouve ici les clivages habituels : ce sont les entreprises de 10 à 19 salariés qui utilisent le moins ces outils (10 %) particulièrement celles de la construction et du transport ; celles de 20 à 249 salariés (16 %) adoptent peu à peu les systèmes d’exploitation libres (près d’un quart des entreprises de 20 à 249 salariés des services aux entreprises en janvier 2008) ; tandis que la moitié des entreprises d’au moins 2 000 salariés disposent d’un système open source ». Cette enquête révèle peu d'information hormis un point intéressant sur la répartition par taille d'entreprises, information que ne donnent pas les rapports des cabinets de consultants.

Qu'en disent les organisations professionnelles et paritaires en France ? : l'OPIIEC

En 2008 l'OPIIEC, Observatoire Paritaire des Métiers de l’Informatique, de l’Ingénierie, des Études et du Conseil commande une étude sur le logiciel libre en France au cabinet Pierre Audoin Consultants. Cette étude a été réalisée en interrogeant les utilisateurs.
Pour ce cabinet, l'industrie du logiciel est en pleine mutation, en partie grâce/à cause du logiciel libre qui ouvre des marchés, relance l'innovation, la collaboration. Cependant, il procure aux décideurs de nouvelles difficultés : comment choisir, quel coût total ? Le plus important dans le choix est finalement le respect des standards. Ce marché est orienté vers les services tout au long du processus de vie du logiciel : depuis l'identification des solutions pouvant répondre aux besoins exprimés et leur qualification, jusqu'à la contribution/maintenance par la société de service dans le cadre de la communauté du logiciel choisi.

Au sein de l’OCDE, la France est le pays le plus avancé en usage des logiciels libres. Cela représente 3,6% (1105 millions d’euros) de la demande en logiciels et services. Et d'après les experts, ce marché va croître fortement (32,7% de croissance annuelle moyenne) sur les 4 prochaines années (2009-2012), pour atteindre près de 10% de la dépense en logiciels et services. La France dispose de nombreux atouts : des compétences en logiciel libre : cursus adaptés, formation dispensées dans les écoles et universités, entreprises spécialisées et compétences internes aux entreprises client final. Le marché du libre en croissance a aussi un impact fort sur celui du modèle propriétaire et on voit plus de concurrence, une baisse du prix des licences dans certains cas. Le tissu économique français est aussi constitué pour une bonne part d'entreprises dont la valeur ajoutée repose sur l'informatique comme l'aérospatiale, les industries de l'énergie...

Pour l'instant, la marge réalisée par les SSLL (Sociétés de Services en Logiciels Libres) ou SSII est faible, les entreprises sont donc contraintes à faire « du volume », la concurrence entre elles est très forte, les SSII s'insèrent dans ce secteur et on voit apparaître des expertises. Malgré tout, ces entreprises coopèrent souvent pour mutualiser ces expertises (voir encore le cas de Topcased en fin d'article).
Pierre Audoin Consultants signale cependant une possible avance des entreprises anglo-saxones dans le domaine de l'édition libre en raison de leurs usages, propices au libre, de l'étendue de leur marché et du soutien de leur capital-risque. Le cabinet pense aussi que le logiciel propriétaire, talonné par le libre, est nécessaire pour maintenir la course à l'innovation et qu'il est plus innovant dans la plupart des domaines. Les entreprises travaillent souvent sur des projets mêlant libre et propriétaire (projets dits « blended »). Enfin le rapport signale que les entreprises françaises, très en avance il y a 10 ans sur ce marché perdent actuellement cette avance. Il préconise d'investir sur la formation, nous en avons parlé plus haut.

Les SSLL

Les SSLL ou Sociétés de Services en Logiciels Libres, sont représentées en France au même titre que les autres entreprises du domaine par le Syntec Informatique - syndicat majeur en matière de sociétés informatiques - et plus spécifiquement par la FniLL, Fédération Nationale de l’Industrie du Logiciel Libre, qui regroupe environ 100 entreprises du Logiciel Libre soit plus de 20 % de la profession. Les SSLL sont les acteurs principaux du marché devant les communautés et éditeurs libres. Bien que concurrencées par les SSII généralistes, elles restent en meilleure place sur ce marché qui est en cours de concentration avec des rachats. Les SSLL, spécialisées dans les projets libres, disposent à la fois d'experts du domaine et souvent d'entrées dans les communautés. Certaines sont également sollicitées pour apporter une aide au choix de logiciel pour les administrations ou les entreprises. A partir de cette aide au choix, en 2004, la méthode QSOS voit le jour à l'initiative de quelques personnes de la société ATOS Origin, QSOS est publiée sous licence Creative Commons. Elle permet d'appuyer sur des bases systématiques l'évaluation et le choix d'un logiciel pour un cahier des charges donné, en mutualisant une grande partie des études nécessaires. En effet, il n'est pas simple de choisir un logiciel libre pour répondre à un besoin donné. Il ne suffit pas de s'assurer que ce logiciel remplit les fonctionnalités demandées mais il faut aussi vérifier sa qualité, que sa licence est bien compatible avec le contexte d'utilisation, que la communauté ou l'entreprise éditrice sont pérennes... QSOS donne une méthode, une grille d'appréciation et un ensemble de fiches d'évaluation renseignées par les participants au projet. Malheureusement, le site web de QSOS semble inactif depuis début 2009.

Les entreprises utilisatrices, des grands comptes aux PME et TPE

Plus de la moitié des entreprises en France disent utiliser des logiciels libres ! Plus exactement, plus de la moitié des salariés interrogés et travaillant au sein des DSI ou des services informatiques disent utiliser des logiciels libres. Il ne faudrait pas en déduire trop rapidement que ces entreprises n'utilisent que du libre, ni que ce soit un choix voulu – voire même connu - par leur direction. En effet, comme bien souligné par exemple dans une enquête européenne, "Study on the: Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU", une part importante des utilisateurs disent ne pas utiliser de logiciel libre mais aussi qu'ils utilisent Linux ou Apache...

Le marché français est dopé par les administrations et en particulier le domaine de la défense. Mais le secteur privé montre une demande croissante au même rythme que dans les autres pays développés. Le secteur de la finance est actuellement utilisateur pour l'infrastructure mais déjà la Caisse d'Epargne ou Groupama utilisent des intranet ou GED libres. Dans le secteur des télécommunications, l'utilisation est faible, concentrée sur les outils pour l'infrastructure. Le secteur industriel est le second en chiffre d'affaire après le secteur administratif plutôt encore pour l'infrastructure, les portails, les CMS, la messagerie. On peut citer l'exemple de PSA qui a migré 20 000 postes de travail sous Linux. Les PME/PMI sont moins utilisatrices que les grands comptes, elles disposent généralement de peu de ressources internes pour choisir, installer, administrer les outils et préfèrent acheter des solutions propriétaires pour lesquelles elles disposent du support de l'éditeur. Il existe une exception notable à cette généralité, un secteur porteur, celui des PME du e-commerce. Dans le secteur des services, également moins porté sur le libre, on peut noter voyages-sncf.com qui utilise un serveur d'applications libre.

Il est intéressant de connaître les motivations de ces entreprises qui choisissent le libre.
Beaucoup d'entreprises utilisatrices ont une démarche pragmatique en choisissant les solutions les plus pertinentes, qu'elles soient libres ou propriétaires. La solution appelée « good enough » est souvent privilégiée : inutile d'acheter un produit très riche mais dont on n'utilisera que quelques fonctionnalités de base quand un produit open source, même moins complet, convient. Les domaines d'utilisation dans lesquels le libre est crédible et généralement performant vis-à-vis du propriétaire sont les systèmes d'exploitation (Linux), les outils de gestion de contenu (CMS, wikis...), les logiciels pour les serveurs Internet (Apache,...) et les outils bureautiques (navigateurs internet tels que Firefox, clients de messagerie comme Thunderbid, suites bureautiques comme OpenOffice.org...). Le libre a fait et fait encore baisser les prix des licences propriétaires en offrant de très bons challengers aux outils habituels des entreprises. On remarquera que ces produits ont un usage plutôt transverse dans l'entreprise et qu'il existe assez peu d'outils « métier » libres même si l'enquête Actuate Open Source Survey 2009 – ciblée secteur public, industrie et finance- signale 44% des utilisations du libre en France pour ces applications, mais l'étude y intègre la gestion de contenu (CMS).

Le besoin de standardisation est aussi un bon argument pour choisir le libre, les logiciels libres implémentant les standards souvent bien avant les logiciels propriétaires. Cette standardisation peut être recherchée par les utilisateurs soit comme garantie d'interopérabilité pour faciliter les échanges avec leurs partenaires, fournisseurs ou clients, soit encore pour répondre à leur besoin d'indépendance vis-à-vis des éditeurs. Que faire en effet si le format de stockage des informations du système de l'entreprise est « propriétaire » et que l'éditeur disparaît ? Comment faire si l'éditeur arrête le produit ?

Une autre raison d'utiliser des logiciels libres peut être liée à la gestion très compliquée des licences lorsque les utilisateurs sont nombreux et les systèmes distribués. Qui est capable de savoir à coup sûr s'il faut une licence client pour un terminal de vente relié à un serveur ou combien il faut en prévoir pour des systèmes virtualisés sur un serveur multi-processeur ou multi-coeur ? L'exposé du système de « licensing » par un commercial de l'éditeur peut à lui seul être la promesse de complications inutiles. Il n'est pas anodin de noter que même ITIL s'est penché sur la question de la gestion des actifs logiciels et que l'opération dite de « réconciliation » qui consiste à faire coïncider au plus juste le nombre de licences achetées avec le nombre de licences installées pour chaque version de chaque produit et chaque usage nécessite des compétences indéniables bien au-delà de la simple patience. Enfin, comment faire encore quand un sous-traitant ou un partenaire doit accéder au système d'information de l'entreprise ? Qui va supporter le sur-coût lié aux licences nécessaires ? Le libre est ainsi une opportunité pour des entreprises travaillant ensemble sur un projet (cas de Topcased une nouvelle fois, en fin d'article).

L'acheteur actuel dans le domaine de l'informatique étudie de plus en plus souvent le coût total de possession, le coût de sortie en plus du coût d'entrée. Si ces mêmes acheteurs ont bien compris que le libre a un coût en support et en formation, ils savent aussi maintenant comment le comparer avec celui du propriétaire.

Enfin, l'adaptabilité est un argument également pour certains pour lesquels l'accès aux sources et la possibilité de les modifier est un gage de flexibilité et d'adéquation avec leur besoin.

On voit donc que les arguments sont nombreux et diversifiés pour passer au libre. On retrouve ces différents arguments quelle que soit la structure, entreprise ou entité administrative et quel que soit le pays concerné dans le monde.

Les événements autour du libre

Bien évidement, les entreprises du libre s'appliquent à promouvoir le modèle économique sur lequel elles s'appuient pour construire leur « business » et elles travaillent ensemble pour proposer des événements spécifiques et des concours dotés de prix. Elles s'entourent de soutiens politiques quand c'est possible. Tous les événements plus ou moins techniques, plus ou moins professionnels, sont relayés abondamment par la presse spécialisée et sont souvent le lieu d'annonces choc.

La FniLL, par exemple, assure la promotion de la profession en organisant « Paris Capitale du Libre » qui décerne des Lutèce d'Or aux meilleurs projets dans plusieurs catégories. Cet événement, né en 2006 à l'initiative de son président était pour sa dernière édition en 2008, soutenu par la Mairie de Paris, le Ministère de l'Economie et des Finances, le Sénat et de nombreuses entreprises. En 2010, Paris Capitale du Libre deviendra le World Open Source Forum. On notera que le nouveau nom prête un peu à confusion avec l'événement concurrent qu'est l'Open World Forum.

De format un peu différent, l'Open Word Forum est organisé conjointement par des consortiums, associations et partenaires institutionnels. Il propose des conférences orientées retours d'expériences, présentations de projets issus de toutes les régions du monde. L'événement, financé par des sponsors est gratuit et ouvert à tous. C'est aussi une occasion de participer à une roadmap 2020 proposée par les organisateurs. Espace collaboratif de réflexion sur les logiciels libres, cet espace est hébergé par System@tic et Cap Digital, le pôle de compétitivité des contenus numériques.

On peut citer encore, plus traditionnel, le salon « Solutions Linux/Open Source » organisé par Tarsus France, un spécialiste de l'organisation de salons.

Les associations, les citoyens

Le secteur associatif est très actif en France. Framasoft propose depuis des années un excellent site grand public produit de façon collaborative par le grand public. L'APRIL a publié un livre blanc sur le secteur économique du libre en France, l'AFUL donne beaucoup d'informations sur son site web et de nombreuses associations locales – GUL ou GULL – sont à l'initiative de manifestations grand public, conférences ou « install parties ». Les Rencontres Mondiales du Logiciel Libre sont probablement les plus connues d'entre elles. L'accès est libre et gratuit et l'organisation bénévole soutenue par quelques sponsors académiques et publics et généralement la chambre de commerce du lieu d'organisation.

Et l'Europe ?

L'Europe, de façon générale, contribue beaucoup plus au marché qu'elle n'en profite et pourtant l'enquête Actuate Open Source Survey 2009 ciblée sur les secteurs finance, industrie et secteur public donne les chiffres suivants : 67% des personnes interrogées en France utilisent l'Open Source, pour 60 % en Allemagne et 42 % au Royaume Uni et 41 % en Amérique du Nord. On peut donc en déduire que l'Europe produit énormément de logiciels libres ! Voyons d'abord comment les institutions européennes participent.

L'Europe en tant qu'institution

OSOR, « Open Source Observatory and Repository » est financé à travers le programme IDABC de la Commission européenne et soutenu par les gouvernements européens, au niveau national, régional ou local. Elle propose une plate-forme d'information sous forme d'un site web, des guides pour l'utilisation des logiciels libres dans les administrations, une forge sous forme d'une fédération de forges et d'un service personnalisé d'hébergement de forge. La plate-forme héberge également des espaces pour des communautés d'intérêt et des descriptions de projets. OSOR est également auteur d'une licence libre européenne (EUPL). Cette licence a pour caractéristique essentielle d'être traduite dans les 22 langues de la communauté et juridiquement valide dans chacun des pays de la communauté. OSOR encourage et promeut le développement mutualisé de logiciels libres et la réutilisation de ceux-ci au sein des différentes administrations. Les objectifs principaux sont de réduire les coûts de réplication des logiciels du secteur public quand ils existent sous une forme similaire ailleurs, de réduire le coût des solutions de e-gouvernement, de répandre les bonnes pratiques au sein des administrations.
L'IDABC et l'OSOR participent activement à de nombreux événements autour du libre (en France par exemple, le OpenWorld Forum, les RMLL...) et proposent souvent des sessions dédiées aux administrations au sein de ces conférences.

Les états et les administrations

La situation est différente selon les pays européens et nous vous présentons ici trois cas représentatifs : les Pays-Bas où le gouvernement a une démarche incitative vers le libre, une ville pionnière qui sert d'exemple en Allemagne et les débuts d'un pays peu concerné par le libre jusqu'à présent : le Royaume Uni.

Aux Pays-Bas, le programme gouvernemental NoIV « Netherlands in Open Connection » a pour objectif de promouvoir les standards ouverts et les logiciels libres dans le secteur public avec les mots-clés : ouverture, transparence, sécurité, durabilité, compétitivité des entreprises, innovation et baisse des coûts. La réglementation oblige l'état à choisir le libre quand deux solutions propriétaire et libre offrent la même qualité. Les standards ouverts doivent faciliter les échanges. Depuis 5 ans, de nombreux secteurs ont migré comme le système téléphonique par exemple.

La ville de Munich, en Allemagne, a entamé en 2001 une démarche de refonte de son système d'information. Après étude approfondie en coûts complets des différentes solutions, elle a choisi l'indépendance vis-à-vis des éditeurs pour son système d'information. La démarche ressemble beaucoup à celle de la gendarmerie en France : outils bureautique d'abord, puis, applications métier impossibles ou trop chères à migrer modifiées pour être accessibles par une interface web ou en terminal serveur ou encore sur une machine virtuelle, puis enfin, migration du système d'exploitation. La différence dans la démarche est sur l'aide apportée par des sociétés de service autour de ce projet. Pour Munich l'objectif n'était pas l'économie, mais l'indépendance à long terme, la ville préférant financer un système adapté plutôt que des licences. L'économie viendra aussi mais à moyen terme. Depuis 2008 Munich sert de modèle en Allemagne et de nombreux organismes viennent y prendre des leçons d'indépendance et de migration.

Les responsables de ces deux projets ont fait état lors d'une table ronde à l'Open World Forum en octobre à Paris des nombreuses difficultés à surmonter : difficultés humaines liée à la peur du changement par exemple et le coût de sortie très important de certaines applications.

Le Royaume Uni est un des états les moins avancés en Europe pour l'usage des logiciels libres. Le « national digital ressource bank » est le premier projet autour du « libre » initié par l'état en Grande Bretagne dans son plan d'actions. Basé sur le plate-forme Agrega de e-learning (développé par le Ministère de l'Industrie, du Tourisme et du Commerce espagnol et placé sous licence EUPL), le projet est au bénéfice des établissements d'enseignement. Les ressources sont proposées au format SCORM et sous « copyright cleared ». Les membres ne paient qu'une quote-part des frais de fonctionnement de l'infrastructure. Ce projet est confié à la société Sirius et allie logiciels libres, standards ouverts et contenus libres.

Les entreprises

Il est difficile de trouver des informations récentes sur l'usage du libre dans les entreprises en Europe. Actuate Open Source Survey nous indique que 60 % des entreprises allemandes disent utiliser un logiciel Open source et les deux raisons principales de ce choix sont le coût et l'accès au code alors qu'au Royaume Uni, dans le secteur financier et le secteur public, ce sont 42% d'utilisateurs. La présentation « Economic Impact of FLOSS » de Rishab Aiyer Ghosh aux Nations Unies donne des informations issues de plusieurs études et on peut retenir que, en moyenne 40%, des entreprises européennes utilisent des logiciels libres. Cette moyenne cache des situations très disparates puisque les PME d'Allemagne sont plus utilisatrices que les grandes entreprises du Royaume Uni. La plupart des utilisations ne sont pas critiques mais 45% le sont pour les entreprises. Les utilisations les plus fréquentes concernent les serveurs web et les systèmes d'exploitation et la raison majeure est le coût.

Et sur les autres continents ?

Attachons nous d'abord à étudier le rôle des organisations internationales. L'UNESCO a mis en place un portail pour les logiciels libres et propose des documents, un répertoire de logiciels, un répertoire d'associations et de nombreux documents et études. On note en particulier « Breaking Barriers: The Potential of Free and Open Source Software for Sustainable Human Development - A Compilation of Case Studies from Across the World » qui analyse 14 cas de réussite répartis dans les différentes régions du globe. L'analyse montre que la gratuité des logiciels est souvent, surtout dans les pays pauvres, le premier critère de choix. Cependant, aucune concession n'est faite quand à la qualité des outils utilisés. La disponibilité du code comme source d'enseignement et la redistribution des modifications vers d'autres utilisateurs sont également très appréciées dans ces situations. A noter également, et c'est un point très important, que les logiciels propriétaires ne sont souvent disponibles qu'en anglais ou dans les langues pratiquées dans les pays industrialisés alors que les logiciels open source peuvent être traduits dans toutes les langues de tous les pays y compris les dialectes (les mécanismes techniques et les procédures d'internationalisation et de localisation sont très souvent proposés par les logiciels libres. Par exemple, OpenOffice.org gère les langues qui s'écrivent de droite à gauche ou verticalement) pour peu que des ressources soient disponibles pour la traduction. Ces projets ont contribué au renforcement économique des régions concernées en permettant à la fois la formation des utilisateurs mais aussi des entreprises locales. Le logiciel libre est un outil de développement pour les populations et pays concernés par cette étude.

Cependant, comme un grand nombre d'autres organismes, l'UNESCO ne fait pas que promouvoir les logiciels libres. En 2009, l’UNESCO et Microsoft annoncent la création d’un Groupe d'étude sur l’enseignement supérieur et les TIC lors de la Conférence mondiale sur l’enseignement supérieur (CMES) de l’UNESCO. Le manque de moyens financiers alloués à l'enseignement supérieur par les états et la crise financière actuelle semblent être la raison essentielle de cet accord. Microsoft proposera dans ce cadre « un ensemble de ressources adaptées pour l’amélioration de l’enseignement supérieur à court terme qui comprendra des programmes, des formations et un accès abordable aux logiciels de collaboration et de développement. »

Google, grand utilisateur de logiciels libres, participe à sa façon, non pas en reversant à la communauté ses propres développements, mais en finançant certains développements. Avec les « Google Summer of Code » , Google finance chaque année depuis 2005, des projets pour contribuer à des logiciels libres existants ou en créer d'autres. Chaque projet accepté est développé par un étudiant encadré par un représentant du logiciel. Quand la contribution est réussie, Google rétribue l'étudiant. Depuis 2005, 2500 duos étudiant-mentor de 98 pays y ont participé.

Impossible de pas étudier ce qui se passe aux Etats Unis. Le logiciel libre y est né et de nombreuses fondations y ont été créées. Les intervenants à Paris Capitale du libre 2007 indiquaient qu'il y est plus facile qu'en Europe d'obtenir des financements grâce aux capitaux à risque, que les investisseurs connaissent le libre et ses modèles économiques et qu'il y a souvent des responsables « Open Source » dans les entreprises. Cependant, l'enquête Actuate indique que les pays d'Amérique du Nord sont à la traine pour l'adoption des logiciels libres dans l'industrie, dans les secteurs ciblés par cette étude (secteur public, finance, télécom). Seulement 40 % des personnes interrogées utilisent un logiciel open source. Mais elle signale une évolution positive et l'arrivée de l'administration Obama pourrait changer la donne. En février 2008, la presse faisait écho de l'entrée des logiciels libres au département de la défense américain DoD, les objectifs attendus étant le coût modeste, la flexibilité et la possibilité de modifications et l'absence de dépendance aux éditeurs. Fin octobre 2009, le passage à Drupal du Web de la Maison Blanche confirme que l'équipe Obama utilisera les logiciels libres. Cela risque de faire « boule de neige » sur les autres acteurs du pays.

L'étude de l'UNESCO nous a permis de voir l'impact du libre dans les pays émergents où il peut aider à réduire la fracture numérique et de nombreux pays asiatiques en ont bien compris l'intérêt. Mais ce tour du monde serait vraiment incomplet si nous ne présentions pas le cas type du Brésil.
Le gouvernement du Brésil considère le logiciel comme un droit social au même titre que l'eau ou le logement, un bien public, produit par la société et prévu pour la société. Il a donc mis en place en 2007 un espace virtuel accessible à tous, le « Brezilian public software portal ». Cet outil est destiné à évoluer vers un portail de marché qui favorise l'émergence de groupes d'intérêts. Les logiciels, développés par des fonds publics, pour tous, sont définis comme « public software » et déposés sous licence GPL. Le portail rassemble offre et demande, chacun devant y trouver son compte. Il favorise les opportunités professionnelles pour ceux qui participent, les source des revenus, les échanges d'expériences.
L'écosystème ainsi créé fait aussi l'objet de recherches pour les aspects sociaux, les retombées économiques, l'adoption des logiciels proposés... Les conclusions sont plutôt positives et des exemples précis sont étudiés de logiciels développés à l'initiative de l'état pour son usage propre qui sont maintenant utilisés dans différents contextes. Des entreprises privées ont construit une offre autour et participent maintenant aux développements. Une retombée politique est le renforcement du mouvement libre dans le monde. Un point moins positif est la faible participation comparée au 50 000 utilisateurs du portail. La raison principale semble être le manque de compétences et des initiatives pour « l'inclusion digitale » semblent nécessaires. Le Brésil offre avec ce concept politique piloté de bout en bout et étudié par des chercheurs sur tous ses aspects un modèle original pour le développement d'un pays. Le ministre du Plan, Corinto Meffe et un chercheur ont présenté le concept lors de l'Open World Forum en octobre à Paris. Ils participent au chapitre Brésil de la roadmap2020.

La communauté Enseignement Supérieur - Recherche comme producteur de logiciel libre

Le libre, comme Internet, a ses origines dans le monde de la recherche. Dans les débuts de l'informatique, le logiciel était gratuit, et les chercheurs, très gros utilisateurs d'informatique à l'époque (les PC et donc l'informatique grand public n'existait pas), pouvaient étudier le code source, l'améliorer pour leurs recherches, faire des échanges... Avec l'arrivée des codes fermés, des sociétés comme Microsoft qui vivent uniquement de la vente de licences propriétaires, la recherche, en particulier en informatique s'est vite retrouvée handicapée et frustrée : impossible de savoir avec précision ce que font ces programmes livrés sous forme binaire (incompatible avec la démarche scientifique où on doit vérifier les hypothèses, les modèles, les algorithmes...), de faire évoluer les codes... Richard Stallman, considéré comme le père du logiciel libre, était un chercheur du MIT qui « en avait marre » de cette situation.
Donc la recherche a toujours été très utilisatrice de logiciels libres, de même que l'enseignement supérieur, peut-être pour des raisons plus économiques et pratiques, inutile de gérer des licences pour tous les étudiants par exemple. Cette communauté a aussi beaucoup contribué aux logiciels libres.
Mais avec la pression très forte à la valorisation des résultats de recherche, valorisation au sens « argent sonnant et trébuchant », tout a été essayé pour vendre les développements logiciels des laboratoires : accords, start-up.... Sans prendre en compte que ces développements sont rarement utilisables en l'état et qu'on ne s'improvise pas éditeur de logiciel : il faut gérer n versions de logiciel avec n licences pour n clients différents. Ce métier demande des compétences et des pratiques bien éloignées de la recherche. Si on effectuait un bilan financier de ce qu'a coûté l'activité valorisation des logiciels ces dernières années (en ressources humaines...) et de ce que ca a rapporté, il ne serait certainement pas brillant. En effet, très peu de logiciels issus de la recherche sont actuellement diffusés avec une licence propriétaire qui rapporte de l'argent à un établissement d'enseignement supérieur et de recherche.

Depuis quelques mois, l'intérêt de diffuser en libre progresse. Côté développeurs, de nombreux chercheurs disent : « nos publications sont publiques, pourquoi nos codes ne le seraient-ils pas ? Nous savons développer du code innovant mais pour le vendre il faut le rendre utilisable par tous, avec une bonne ergonomie... ce n'est plus notre travail ». Du côté des services de valorisation, on prend conscience du très gros volume de développements très divers effectués dans les laboratoires, qui ne peuvent pas rapporter des royalties, mais qui se perdent, ne sont même pas répertoriés, alors que c'est un patrimoine important. Donc, autant les diffuser librement. Diffuser les connaissances est aussi un des objectifs des organismes de recherche, peut-être avant la valorisation financière.

Ainsi des laboratoires ont demandé au projet PLUME, qui au départ ne diffusait que des fiches de logiciels utilisés, de diffuser des descriptions de développements issus de la Recherche et de l'Enseignement Supérieur : cela a donné le projet connexe à PLUME : RELIER . Fin octobre il y avait déjà 82 descriptions de développements internes dans PLUME (appelées fiches Dév ESR). Et très récemment, la Direction de la Politique Industrielle du CNRS a accordé un an d'ingénieur pour référencer les développements des laboratoires sur PLUME.

D'après les fiches Dév ESR dans PLUME il est prématuré de tirer des tendances sur le développements par domaine scientifique... Ce dont on peut s'apercevoir, c'est que la politique du laboratoire ou de l'université est primordiale dans cette diffusion : soit les logiciels ne l'intéressent pas, soit elle considère que c'est important et encourage le référencement dans PLUME. Donc les laboratoires qui commencent à publier des descriptifs dans PLUME essaient ensuite d'avoir un référencement exhaustif.

Pour avoir une photographie de la situation actuelle des développements diffusés en libre dans la communauté ESR, on peut consulter les supports et les vidéos des présentations des journées PLUME « Pourquoi et comment diffuser un développement logiciel de laboratoire ou d'université en libre ? » où plusieurs chercheurs ont décrit leur retour d'expérience sur la diffusion de leurs code en libre, où les services de valorisation ont expliqué les procédures actuelles et où des recommandations (forge, licence...) ont été faite.

La diffusion en libre concerne tout type de développement, comme des développements d'envergure, avec des industriels et où le choix libre a été fait délibérément pour faciliter des collaborations très diverses, l'amélioration du code... que ne permettrait d'autres modes de diffusion. On peut citer, le cas du logiciel Topcased, atelier de développement d'applications et de systèmes critiques . Participent à ce développement 30 partenaires : des industriels comme Airbus, ATOS Origin, CS, Thalès, des laboratoires comme LAAS, IRIT, des écoles comme l'ENSEEIHT. Ce développement a été présenté dans les journées ci-dessus. On peut extraire de cette présentation quelques idées.

« La diffusion en libre nous a permis de pérenniser les développements (en embarqué on ne peut pas dépendre d'un éditeur qui peut disparaître), faire travailler sur un même code des partenaires divers et concurrents (dans les partenaires, il y a des industriels concurrents qu'il serait impossible de faire travailler ensemble sous une licence propriétaire), avoir une visibilité mondiale, avoir des utilisateurs très divers ce qui permet de mieux tester le code et améliorer les fonctionnalités, mieux répondre aux appels d'offre : Europe, ANR... ».

Topcased n'est qu'un exemple, beaucoup d'autres développements tout à fait différents par leur taille, leur objet, leurs utilisateurs se félicitent de la diffusion en libre.

Que peut il se passer dans les années qui viennent ? On peut penser, espérer ?, qu'à moyen terme :

  • Tout développement de recherche sera par défaut diffusé en libre. Cela n'est pas exclusif avec la commercialisation de certains, partenariats industriel....
  • Tout développement sera référencé pour que les autres chercheurs ne ré-inventent pas la roue...
  • Les développements de la recherche seront considérés comme un patrimoine scientifique important.
  • Le développement sera pris en compte dans l'évaluation des chercheurs (et des ingénieurs)

Ce chapitre parle principalement des logiciels de recherche. On peut extrapoler pour les autres développements de support à la recherche et de services réalisés par les ingénieurs des les services informatiques. On peut reprendre les 4 points ci-dessus. Il faudrait qu'ils soient diffusés en libre par défaut, les référencer (pour que chacun ne ré-invente pas la roue), les considérer comme importants et les prendre en compte dans la carrière. Certains sont aussi présents dans la plateforme PLUME sous forme de fiches Dév ESR ou de logiciel validé, à valider ou en test.

Incitation

  • Si vous pensez que notre communauté ESR doit plus et mieux utiliser les logiciels libres : faites partager votre expérience sur un logiciel libre que vous appréciez en rédigeant une fiche PLUME de logiciel validé : cela le fera connaître et pourra contribuer à sa diffusion dans notre communauté.
  • Si vous avez développé un logiciel, que vous pensez intéresser d'autres : rédigez une fiche PLUME dév ESR.

La démarche est la même :

JRES 2009 : articles, présentations, vidéos et liens PLUME

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 09/08/10
  • Correction mineure : 11/10/10

JRES 2009 : articles, présentations, vidéos et liens PLUME

Les journées réseaux JRES présentent un panorama très complet en termes de technologies, d'usages, de stratégies, d'organisation et de développement dans le monde des réseaux. Elles réunissent, tous les 2 ans, les acteurs qui contribuent au déploiement et à l'essor des nouvelles technologies de l'information et de la communication dans les établissements d'enseignement supérieur et de recherche.

Pour la 8ème édition, les JRES 2009 se sont déroulées du 2 au 5 décembre 2009 à Nantes et ont fait une part importante aux logiciels libres utilisés ou développés dans la communauté Ens Sup - Recherche. Elles ont réuni plus de 1300 professionnels, avec 4 sessions en parallèle. Celles-ci ont été enregistrées.

Ci-dessous les différentes présentations sont classées par thème, avec les liens vers l'article ou le poster (Fichier PDF), le diaporama (Diaporama), l'enregistrement vidéo (Vidéo), et éventuellement une fiche PLUME (Fiche plume) qui décrit un logiciel présenté dans la présentation. Ces présentations sont aussi accessibles sur la page du programme sur le serveur JRES2009.

Les thèmes ci-après sont classés ainsi : sessions plénières, messagerie, authentification-authorisation, développement, administration système et gestion de parc, réseaux, hébergement, stratégie-organisation, sécurité, ToIP/VoIP, collaboratif, autres, posters.

Sessions plénières

  • Ubiquité, communication, co-présence, recommandation : entre promesses et menaces les réseaux changent notre manière de produire de la connaissance, d' échanger ou partager savoirs et culture (Hervé Le Crosnier) : Diaporama   Vidéo
  • The Future of Indoor Plumbing (Ken Klingenstein) : Diaporama   Vidéo
  • Innovation and international collaboration in the research and education networking environment (Valentino Cavalli) :  Diaporama   Vidéo
  • Création artistique en réseau (Bruno Cohen, Georges-Albert Kisfaludi) : Diaporama   Vidéo
  • Mozilla : Développement collaboratif et innovation distribuée (Tristan Nitot) :  Diaporama   Vidéo   Fiche plume

Messagerie Fiche plume

  • Virtualisation du service de soumission de messages (Didier Benza, Denis Joiret) : Fichier PDF   Diaporama   Vidéo
  • Évolution de l'architecture de messagerie d'Osiris (Pierre David, Alain Zamboni, Philippe Pegon, Jean Benoit) : Fichier PDF   Diaporama   Vidéo
  • DKIM et les listes de diffusion, application au moteur de listes Sympa (Serge Aumont) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Projet TrustedBird, un client de messagerie de confiance (Laurent Cailleux) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Méthodologie d'évaluation d'un filtre anti-spam (José-Marcio Martins da Cruz ) : Fichier PDF   Diaporama   Vidéo
  • Le service antispam de RENATER est arrivé ! (Jean-Luc Munier, Franck Simon, Serge Aumont, Olivier Hussenet) : Fichier PDF   Diaporama   Vidéo

Authentification, authorisation Fiche plume

  • Déploiement d'une Javacard à l’IMAG (Jean-François Desnos, Gérard Forestier) : Fichier PDF   Diaporama   Vidéo
  • La gestion des identités au CNRS (Christelle Ecrepont, Claude Gross) : Fichier PDF   Diaporama   Vidéo
  • Shibboleth et la haute disponibilité (Olivier Salaün, Mehdi Hached) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Identity Federation: Starting small and reaching way beyond (Thomas Lenggenhager) : Fichier PDF   Diaporama   Vidéo
  • Symbiose des référentiels utilisateur avec Fedora Directory Server et Active Directory dans un contexte de fédération d'identités (Nicolas Carel, Hugo Étiévant) : Fichier PDF   Diaporama   Vidéo
  • SCS est mort, vive TCS ! (Jean-Francois Guezou, Serge Aumont, Dominique Launay) : Fichier PDF   Diaporama   Vidéo
  • Réferentiel d'authentification interopérable et ouvert: Kerberos (Emmanuel Blindauer) : Fichier PDF   Diaporama   Vidéo

Développement Fiche plume

  • mod_rewrite, mod_perl, Mason : que la force soit dans Apache (Alexandre Simon, Vincent Delove) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Technologies pour Web Services faciles : REST, JSON (Pierre Gambarotto) : Fichier PDF   Diaporama   Vidéo
  • OrbisGIS : un SIG du domaine public pour exploiter la composante spatiale d'un Système d'Information de campus (Thomas Leduc) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • L'interopérabilité en astronomie : Retour d'expérience du projet Aladin (Pierre Fernique, Thomas Boch, François Bonnarel) : Fichier PDF   Diaporama   Vidéo   Fiche plume

Administration système et gestion de parc Fiche plume

  • GUSTAV: Gestion Unifiée des Systèmes de fichiers Transposée aux Appareillages Virtuels (Jacques Landru, Tovoherizo Rakotonavalona) : Fichier PDF    Diaporama   Vidéo
  • Nouvelles stratégies et technologies de sauvegarde (Boris Valera, Laurent Blain, Stéphane Larroque) : Fichier PDF   Diaporama   Vidéo
  • « HOME@INSA » : un service universel de stockage de documents (Damien Berjoan, Pierre Giraud, Olivier Franco) : Fichier PDF   Diaporama   Vidéo
  • Bacula : une solution de sauvegarde par le réseau (Matthieu Guionnet) : Fichier PDF   Diaporama   Vidéo Fiche plume
  • Comment mutualiser sans centraliser ? (Romaric David,  Mehdi Amini) : Fichier PDF   Diaporama   Vidéo
  • Gestion de parc Windows depuis Unix (Pascal Cabaud, Laurent Joly) : Fichier PDF   Diaporama   Vidéo
  • Déploiement simplifié de stations sans disque avec Faddef (Philippe Depouilly, Zouhir Hafidi) : Fichier PDF   Diaporama   Vidéo
  • Etude de solutions automatisées pour le déploiement de salles d'enseignement (Nicolas Rouanet, Cédric Morin) : Fichier PDF   Diaporama   Vidéo
  • Virtualisation du poste de travail: Le cas de l'université Rennes 2 (Humberto Duarte) : Fichier PDF   Diaporama   Vidéo

Réseaux Fiche plume

  • Fourniture de service de bout en bout (Hassan Hassan, Catherine Grenet, Bernard Rapacchi) : Fichier PDF   Diaporama   Vidéo
  • RENATER-5 (Jérôme Durand, Franck Simon) : Fichier PDF   Diaporama   Vidéo
  • Retour d'expérience sur l'édification et la gestion du réseau SIGFIP en Côte d'ivoire (Debohi Arnaud, Lucien Kehin) : Fichier PDF   Diaporama   Vidéo
  • SW, le couteau switch (Olivier Lacroix, Vincent Delove) : Fichier PDF   Diaporama   Vidéo
  • Métrologie: pour maitriser les évolutions, les performances, la disponibilité des réseaux (Luc Saccavini, Didier Benza, Bernard Tuy) : Fichier PDF   Diaporama   Vidéo
  • Mise en quarantaine dynamique : une question de métrologie  (Emmanuel Reuter, Nicolas Bonicco) : Fichier PDF   Diaporama   Vidéo
  • La refonte du backbone de RAP (Laurent Gydé) : Fichier PDF   Diaporama   Vidéo
  • Faciliter l'usage de services réseaux avancés : le cas de SIRES 2 sur RAP (Catherine Grenet, Ludovic Ishiomin) : Fichier PDF   Diaporama   Vidéo
  • Du NAC ... à la réalité (Frédéric Boivent, Pierre-Antoine Angelini) : Fichier PDF   Diaporama   Vidéo

Hébergement

  • Expérimentation d'une plate-forme de portage à l'INRIA (PIPOL) (Maurice Bremond, Yann Genevois, Eric Ragusi, Nicolas Turro, Roger Pissard) : Fichier PDF   Diaporama   Vidéo
  • Le farming dans DokuWiki, intérêt et mise en œuvre (Etienne Meleard) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Evolution d'une salle d'hébergement : retour d'expérience (Olivier Lacroix) : Fichier PDF   Diaporama   Vidéo
  • Infrastructure pour un datacenter haute densité (Cédric Houssier, Matthieu Clavier, Nathalie Delestre) : Fichier PDF   Diaporama   Vidéo
  • Réaménagement de locaux réseaux (Présentation commune Réseau Académique Parisien et Observatoire de Paris) (Lionel David, Emmanuel Halbwachs, Joël Marchand) : Fichier PDF   Diaporama   Vidéo

Stratégie et organisation

  • Impacts organisationnels et techniques d'un noeud de grille dans un laboratoire du CNRS (Denis Pugnere, Guillaume Baulieu, Yoan Giraud) : Fichier PDF   Diaporama   Vidéo
  • La sous-traitance : outils et organisation illustrés par l'expérience sur RAP (Laurent Gydé) : Fichier PDF   Diaporama   Vidéo
  • Guide de bonnes pratiques organisationnelles pour les Administrateurs Systèmes et Réseaux dans les unités de recherche  (Olivier Brand-Foissac, Laurette Chardon, Marie David, Maurice Libes, Gilles Requilé, Alain Rivet) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Externalisation et respect de la loi "Informatique et Libertés" (Solenn Houssay) : Fichier PDF   Diaporama   Vidéo
  • Référentiel de Données Partagées : Experience d'une mise en oeuvre en Open Source (David Rongeat) : Fichier PDF   Diaporama   Vidéo
  • La place des logiciels libres dans l'Enseignement Supérieur et la Recherche, état des lieux à travers PLUME. Et que font les autres ? (Geneviève Romier, Jean-Luc Archimbaud) : Fichier PDF   Diaporama   Vidéo   Fiche plume

Sécurité Fiche plume

  • Utilisation de la méthode EBIOS : de l’organisation projet aux composants du système de management de la sécurité de l'information (SMSI) (Philippe Tourron, Matthieu Grall) : Fichier PDF   Diaporama   Vidéo
  • Projet de PSSI générique pour les établissements d'enseignement supérieur (Dominique Launay, Jean-Paul Le Guigner) : Fichier PDF   Diaporama   Vidéo
  • Élaboration d'une PSSI au sein d'une unité propre du CNRS : utilisation de la méthode EBIOS (Martine Culiioli, Maurice Libes, Michel Kourilsky, Thierry Mouthuy) : Fichier PDF   Diaporama   Vidéo   Fiche plume
  • Sécurité du DNS et DNSSEC (Stéphane Bortzmeyer) : Fichier PDF   Diaporama   Vidéo
  • Un reverse proxy, pour quoi faire ? (Pascal Cabaud) : Fichier PDF   Diaporama   Vidéo

ToIP/VoIP

  • Retour d'expérience sur le déploiement de la solution de ToIP libre Asterisk au sein de l'université de la Polynésie française (Alexandre Gouverneur, Franck Mével) : Fichier PDF   Diaporama   Vidéo
  • Service pilote ToIP dans RENATER (Simon Muyal, Bernard Tuy) : Fichier PDF   Diaporama   Vidéo

Collaboratif

  • Construire une documentation structurée des dépendances des services (Rafael Diaz Maurin) : Fichier PDF   Diaporama   Vidéo  Fiche plume (logiciel protégé)
  • Démonstration de la chaîne éditoriale Chainedit (Romuald Lorthioir, Frédéric Hannouche) : Fichier PDF   Diaporama   Vidéo
  • Alfresco : une solution d'espaces collaboratifs (Frédéric Saint-Marcel, Philippe Tremelet) : Fichier PDF   Diaporama   Vidéo
  • ESCO-Portail et la gestion des groupes (Arnaud Demain, Christian Daviau) : Fichier PDF   Diaporama   Vidéo
  • Retour d'expériences sur une centralisation de messagerie et la mise en place d'outils collaboratifs à l'Inserm (Patrick Lerouge, Laurent Moizo, Julio Martins, Guillaume Stevens, Louis Rechaussat) : Fichier PDF   Diaporama   Vidéo
  • Vidéodiffusion des savoirs : pour une solution qui lave plus libre (François Bouhet, Marc Chanove, Clément Chapu, Marc Chavot, Jean Louis Mas) : Fichier PDF   Diaporama   Vidéo

Autres

  • Des Grilles de calcul au Cloud computing (Dominique Boutigny) : Fichier PDF   Diaporama   Vidéo
  • Développement durable & TIC - les enjeux de la surveillance énergétique et environnementale (Patrick Grossetete) : Fichier PDF   Diaporama   Vidéo
  • Services numériques, PRES, UNR... quels enjeux pour les DSI d'universités? quelles mutations? (Thierry Bédouin) : Fichier PDF   Diaporama   Vidéo
  • IPv6 et EGEE : Migration d’un système d’information complexe vers IPv6, gLite (Etienne Dublé, Xavier Jeannin) : Fichier PDF   Diaporama   Vidéo
  • OAR : gestionnaire de ressources pour grandes grappes de calcul (Bruno Bzeznik, Joseph Emeras, Romain Cavagna, Richard Olivier) : Fichier PDF   Diaporama   Vidéo   Fiche plume

Posters

  • Gestion collaborative de l'administration des systèmes (Yves Agostini) : Fichier PDF
  • Pxxo : développement Web par composants graphiques réutilisables (Nicolas Thouvenin, Stéphane Gully) : Fichier PDF   Fiche plume
  • ARCHANN, une architecture d'annuaire et d'authentification interopérable pour un SSO unifié en environnement hétérogène (Pascal Levy) : Fichier PDF
  • La haute disponibilité sur le réseau de l'université Toulouse 3 (Christian Escaffre, Dominique Incerti) : Fichier PDF
  • Rationalisation de l'exploitation de serveurs Zope/Plone avec Xen (Philippe Daubias) : Fichier PDF Fiche plume Fiche plume
  • Lodel - Logiciel d’édition électronique (Pierre-Alain Mignot, Bruno Cénou, Marin Dacos) : Fichier PDF   Fiche plume
  • Esup-CIL : Outil de tenue de registres d'Esup-Portail (Guy Bisiaux, Jean-Luc Tessier) : Fichier PDF
  • Base IP et Application Switch (Philippe Poplimont) : Fichier PDF
  • « Linux live » pour chercheur mobile pas tout à fait dans les nuages... (Jean-Daniel Dubois) : Fichier PDF
  • Expérience de modernisation du système informatique de l'université de cocody Abidjan  - Côte d'Ivoire (Florence Late Kouamé, Didier Kouadio N'Gouin-Claih, Valentin N'douba, Antoine Tako) : Fichier PDF
  • PLACO, un générateur de plate-forme collaborative au service des communautés scientifiques (Jacquelin Charbonnel, Philippe Depouilly, Jacques Foury, Benoit Métrot, Damien Ferney) : Fichier PDF   Fiche plume
  • Fédération d'identité : Interopérabilité shibboleth / microsoft (Jean Marie Thia) : Fichier PDF
  • Vi4RT : la virtualisation pour les salles de travaux pratiques (Anthony Hinsinger, Philippe Arnould) : Fichier PDF
  • Locauxtech : Une application de gestion et d'administration des locaux techniques (Thierry Hénocque) : Fichier PDF
  • Grille régionale Rhône-Alpes (Yonny Cardenas) : Fichier PDF

Documents de référence PLUME pour mieux gérer les développements logiciel, les diffuser et les valoriser dans un laboratoire

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/04/10
  • Correction mineure : 01/04/13

Documents de référence PLUME pour mieux gérer les développements logiciel, les diffuser et les valoriser dans un laboratoire

  • Type de ressource : article, référentiel, résumé
  • Date de publication du document ou de l'événement : Oct 2009
  • Auteur(s) ou responsable(s) : Contributeurs PLUME

Les documents ci-dessous sont destinés principalement aux développeurs dans les laboratoires pour mieux gérer leur code, le diffuser et le faire connaître. Nous pensons que ce sont des documents de référence que tout développeur, responsable de projet, chargé de valorisation devrait lire :

Plusieurs de ces documents ont été présentés lors d'une journée PLUME, avec transparents et vidéos disponibles.

Guide laboratoire pour recenser ses développements logiciels

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 14/09/09
  • Correction mineure : 20/04/12

Guide laboratoire pour recenser ses développements logiciels

Cet article n'est pas un document officiel d'un organisme ou d'une autre entité. Il s'adresse principalement aux responsables de laboratoires, mais aussi aux chercheurs, développeurs et responsables des tutelles qui souhaitent mettre en place ou améliorer les procédures de recensement des logiciels de recherche (logiciels libres et logiciels propriétaires) développés dans le laboratoire (ou l'ensemble des laboratoires d'une tutelle).
Les logiciels sont devenus des éléments principaux dans les processus de recherche, aussi bien comme outil que comme résultat. Améliorer leur référencement dans le laboratoire est le premier pas pour leur mise en valeur.
L'auteur principal de cet article est Teresa Gomez-Diaz, chargée du référencement des développements de son laboratoire LIGM et responsable thématique PLUME, mais les procédures présentées ont été étudiées avec Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée).
D'autres ont ensuite relu et complété : Jean-Luc Archimbaud (UREC), Geneviève Romier (UREC), Nathalie Rousse (INRA).
D'autres contributions sur ce texte sont souhaitables, merci de contacter l'auteur ou d'ajouter un commentaire.
Note : ce texte se veut auto-contenu, mais les lecteurs sont supposés connaître le contenu de la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume.

Autres documents PLUME

Ce document est une des fiches d'information et de recommandations rédigées par des responsables thématiques PLUME et destinées aux développeurs (et personnes en charge de la valorisation) dans les laboratoires de recherche et les universités. Les autres sont :

Introduction

L'évaluation d'un laboratoire de recherche s'effectue sur la base du rapport scientifique qui présente les activités de recherche du laboratoire pendant les 4 dernières années. Une grande partie de ce rapport consiste à énumérer les références des publications produites par les membres du laboratoire, généralement classées en : articles de revues, actes de conférences et autres communications, livres et chapitres de livres, thèses et habilitations, divers.
De plus les laboratoires disposent en général de bons outils pour gérer une telle liste bibliographique, ils peuvent en particulier utiliser le serveur HAL.
Par contre, pour les logiciels, il n'y a aucun outil connu autre que celui proposé par le projet RELIER de PLUME. Or, les logiciels sont devenus des éléments principaux dans le développement de la recherche, aussi bien comme outil que comme résultat. Améliorer leur connaissance est le premier pas pour leur mise en valeur. L'objectif de ce document est ainsi de proposer des procédures pour la gestion de la liste de logiciels, souvent libres mais pas uniquement, produits par un laboratoire de recherche. Ces procédures peuvent être aussi étendues aux bases de données, souvent produites et utilisées dans les laboratoires de recherche (données linguistiques, astronomiques, biologiques, ...). En effet les problèmes qui se posent avec ces bases de données (droits d'utilisation, références, citations, ...) sont de même nature que ceux que nous avons rencontrés avec les logiciels.
Le concept de production scientifique d'un laboratoire doit donc être élargi pour tenir compte de ces autres productions.

Les logiciels d'un laboratoire

Dans ce document, on entend par logiciel du laboratoire tout programme ou fragment de programme utile pour faire avancer la recherche, au sens large, et qui a été produit avec la participation d'un ou plusieurs membres du laboratoire. Il arrive souvent que des publications de recherche soient associées à un logiciel. Selon l'intérêt et la politique du laboratoire, on peut englober les logiciels à l'état de projet (logiciels en préparation, non encore terminés) et les logiciels 'utilitaires' développés au laboratoire pour améliorer le travail en interne (par exemple un outil de gestion de bibliographie).
Cette définition incite à la comparaison entre logiciel de recherche et article de recherche, mais cela ne se fait pas sans difficulté. Comment mettre dans la même balance un logiciel qui implémente un algorithme pour étude et amélioration et un livre élaboré après des longues années avec l'intervention de plusieurs personnes ? Mais en fait, cette difficulté existe aussi entre les diverses catégories des publications de recherche : comment comparer un article préparé en quelques semaines à un livre longuement élaboré ? Le point clé est dans la bibliographie fournie par le laboratoire : la comparaison ne se fait pas, la référence de l'article et du livre sont données.
Donnons donc aussi une référence pour les logiciels. De façon similaire à celle d'un article, la référence logiciel doit contenir la liste de ses auteurs, une date, mais aussi un numéro de version, une licence, une adresse et d'autres informations clés pour identifier le logiciel.
L'élaboration de la liste de logiciels d'un laboratoire est un élément fondamental de sa politique scientifique : cette liste permet de mesurer la production logicielle et permet l'évaluation de la diversité des productions. Cette liste deviendra un élément clé dans l'évaluation d'un laboratoire, mais aussi dans la détermination de son futur stratégique.

Référencer les logiciels libres et les autres

Rappelons qu'un logiciel dit libre respecte les 4 libertés mentionnées, par exemple, par la FSF :

  • liberté d'exécuter le logiciel (utilisation à l'infini),
  • liberté d'étudier le fonctionnement (disponibilité du code),
  • liberté de redistribuer des copies,
  • liberté d'améliorer le logiciel et de publier ces améliorations.

On reconnait un logiciel libre par la présence d'une licence qui indique ce statut. Un logiciel qui n'est pas libre est dit propriétaire. Plus d'informations sont données dans la FAQ Fiche Plume Licence & copyright pour les développements de logiciels libres de laboratoires de recherche.
Les logiciels propriétaires d'un laboratoire de recherche font souvent l'objet de collaborations avec des partenaires non-académiques ce qui conduit parfois à des contrats avec ces partenaires, et souvent, ces contrats sont gérés par les services de valorisation (du CNRS, SAIC, ...) des établissements. Il n'est donc pas très difficile (en principe) d'obtenir la liste des contrats, mais une autre chose est d'obtenir la liste des logiciels qui ont abouti à la fin de ces contrats.
Faisons ici une petite parenthèse pour indiquer deux types de logiciels propriétaires, qui se trouvent parfois dans les laboratoires : ceux qui font l'objet de licences propriétaires et ceux qui ne sont pas accompagnés de licence (ou logiciel public sans licence). La diffusion d'un logiciel sans licence est à éviter.

Il est en général plus difficile d'obtenir la liste des logiciels libres. À notre connaissance, très peu de laboratoires peuvent produire une telle liste, ces logiciels ne se recensent pas systématiquement, les chercheurs ne les mentionnent parfois même pas dans leurs rapports de recherche. Or comme nous l'avons déjà souligné, les logiciels sont maintenant un patrimoine avec une valeur scientifique qui sera de plus en plus importante donc il faut les référencer.

La solution à ce problème est d'établir des procédures dans le laboratoire pour référencer tous les logiciels développés. Des procédures différentes sont possibles et chaque laboratoire doit décider en conseil de laboratoire la procédure qui s'adapte le mieux à sa situation, ses habitudes. Ce document propose un peu plus bas, deux procédures possibles pour servir d'exemple.

Les droits patrimoniaux

Ces procédures doivent respecter les détenteurs des droits patrimoniaux d'un logiciel. En effet, la plupart des logiciels d'un laboratoire sont développés, à un moment ou autre, dans un cadre de travail salarié, et les droits patrimoniaux reviennent aux employeurs des développeurs. Ces employeurs sont en général les tutelles du laboratoire.
Qu'arrive-t-il quand il y a plusieurs tutelles au laboratoire ? Comment gère-t-on la ligne copyright qui indique les détenteurs des droits patrimoniaux et qui apparaît dans l'en-tête de tout fichier du code source ?
Il arrive aussi que des étudiants ou stagiaires avec des financements extérieurs à l'établissement participent aux développements logiciels. Ils sont détenteurs, au même titre que l'établissement, des droits patrimoniaux.
Pour l'ensemble de ces questions, qui ne sont pas l'objet de cet article, on se référera au document Fiche Plume Licence & copyright pour les développements de logiciels libres de laboratoires de recherche.

Le projet RELIER

Le projet RELIER, sous-ensemble du projet PLUME, vise à REférencer les développements Logiciels Internes de l'Enseignement supérieur et de la Recherche. Ce projet permet à chaque membre de laboratoire (développeur...) de rédiger des descriptifs des logiciels produits dans le laboratoire sur la plate-forme PLUME qui sont ensuite publiés sous forme de fiches (appelées fiches Dév ESR) avec des mots clés pour la recherche. Cette plate-forme permet aussi de présenter la liste des logiciels produits par chaque laboratoire (voir par exemple http://www.projet-plume.org/fr/IGM-Labinfo/) et chaque tutelle. Cette plate-forme est donc un outil très intéressant et gratuit qui permet au laboratoire de faire un inventaire de ses logiciels et de les faire connaître donc les valoriser.

Une première procédure proposée

Cette procédure contient quatre étapes.
Mais avant, il faut identifier certains développements logiciel qui nécessitent des conseils des experts 'droits patrimoniaux, licences, valorisation...' et leurs appliquer le rappel ci-dessous.

Rappel : travaillez avec les services de valorisation.

Avant toute diffusion, avant toute collaboration, contacter le SAIC de l'université et/ou des services de valorisation des tutelles (cf annuaire des services SPV du CNRS) s'il y a développement de logiciels dans :

  • Une réponse à un appel à projets.
  • Un contrat.
  • Une participation au développement de personnes dont le financement est extérieur à l'établissement.
  • Un dépôt à l'Agence de Protection des Programmes.
  • Une rédaction de brevet.
  • Une recherche de partenaires industriels.
  • Une diffusion d'un logiciel sous licence propriétaire.

 

Étape 1 : Identification du logiciel à référencer (référence RELIER - fiche Dév ESR)

Une référence de logiciel doit pouvoir identifier le logiciel tout au long de sa vie, en tenant compte de ses possibles évolutions. La référence RELIER (fiche Dév ESR) comporte les champs suivants :

  • nom,
  • auteur(s),
  • propriétaires des droits patrimoniaux (tutelles et autres),
  • licence(s) (voir note),
  • version,
  • date,
  • mots clés,
  • fonctionnalités,
  • contexte d'utilisation,
  • publications liées au logiciel.

Note : Tout logiciel diffusé doit être sous licence, libre ou propriétaire.

Étape 2 : Notification des logiciels de recherche à la direction du laboratoire

La direction du laboratoire doit être notifiée du souhait de référencement de chaque logiciel de recherche (ainsi que de la licence choisie pour la diffusion). Cela comprend tous les logiciels en production au laboratoire. La publication des références de logiciels soumis à des clauses de confidentialité dans des contrats est à étudier.

Étape 3 : Notification aux tutelles et demande d'accord des détenteurs des droits patrimoniaux.

Cette étape concerne principalement les logiciels libres : avant sa diffusion et recensement, la ligne copyright, contenant les détenteurs des droits patrimoniaux  et qui est insérée dans le code du logiciel doit être établie. Plus d'informations sur le copyright sont données dans le document Fiche Plume Licence & copyright pour les développements de logiciels libres de laboratoires de recherche. La procédure proposée est que la direction du laboratoire adresse (par message électronique) aux tutelles une demande de validation de la mise en ligne du logiciel libre, avec une proposition de ligne copyright. Si elle n'obtient pas de réponse au bout de 30 jours, la direction du laboratoire considère sa demande de diffusion de logiciel libre et sa ligne copyright comme validée par les tutelles. Ce délai de réponse de 30 jours n'a pas été validé officiellement mais il nous parait raisonnable.
La situation courante actuelle est que les développeurs diffusent en libre sans forcément en référer aux tutelles, il faut que ceci évolue comme le propose cette procédure.

Pour les logiciels propriétaires qui font l'objet d'un contrat, la ligne copyright doit être définie dans le contrat.

Étape 4 : Saisie de la référence RELIER (fiche dév ESR de PLUME) et publication

La ligne copyright est insérée dans le code, la licence est établie pour le code source et/ou le code binaire du logiciel.
Un membre du laboratoire peut alors saisir la description du logiciel sur le serveur PLUME. Cela se fait en ligne, il faut d'abord devenir membre PLUME puis proposer une fiche et après acceptation saisir la fiche. Après relecture, la référence est publiée. Sur le serveur PLUME, ce nouveau logiciel est ajouté à la liste officielle des logiciels du laboratoire.

Sur cette première procédure

Cette procédure a été conçue pour respecter les détenteurs des droits patrimoniaux de chaque logiciel, et leur accorder un délai raisonnable pour la vérification des engagements des tiers ou contractuels que ces logiciels peuvent entraîner.
Par contre elle peut s'avérer inadéquate dans certaines occasions qui requièrent une diffusion rapide d'un logiciel sous licence libre. Par exemple une soumission d'article pour une conférence : pour valider les résultats de recherche de l'article il est souhaitable d'avoir un accès au logiciel, or une licence doit être mise en place avant toute diffusion d'un logiciel.
Cette procédure peut aussi s'avérer trop contraignante pour des chercheurs qui n'ont jamais reçu d'instruction sur cette question et qui ont toujours agi selon leur propre volonté.
Pour ces raisons nous proposons une deuxième procédure quand une clause spécifique a été ajoutée dans le contrat quadriennal.

Une deuxième procédure proposée

Cette procédure est envisageable si la ligne copyright d'un logiciel libre a été clairement définie lors de la signature du contrat quadriennal entre les établissements tutelles du laboratoire. En effet, lors de cette signature les tutelles arrêtent un accord sur la signature des articles de recherche, nous proposons que la ligne copyright des logiciels libres soit aussi discutée et définie, tout en respectant les détenteurs des droits patrimoniaux.
Il y a aussi, de même que pour les publications de recherche, une délégation implicite aux développeurs de la responsabilité des engagements (contrats, absence de contrefaçon...) concernant le logiciel.

Dans ce cas, les étapes rappel, 1 et 2 sont les mêmes que dans la procédure précédente, mais les deux dernières étapes sont interverties.

Étape 3 : Saisie de la référence RELIER (fiche Dév ESR) et publication

La ligne copyright est insérée, la licence est établie pour le code source et/ou le code binaire du logiciel. Le logiciel  est distribué sous licence libre. Le logiciel est décrit dans PLUME et la référence RELIER (fiche Dév ESR) est publiée. Un nouveau logiciel est ajouté à la liste officielle des logiciels du laboratoire.

Étape 4 : Notification aux tutelles.

La direction du laboratoire adresse aux tutelles (par message électronique) la notification de la mise à jour de sa liste officielle des logiciels.

Le parallèle entre publications et logiciels d'un laboratoire

En résumé on propose que la liste de logiciels d'un laboratoire de recherche soit produite et gérée de la même façon que celle de ses publications, c'est essentiel pour la connaissance et la pérennisation du patrimoine scientifique.
Pour la production de la bibliographie, les laboratoires peuvent utiliser le serveur HAL ; ils peuvent utiliser la plate-forme PLUME/RELIER pour le référencement des logiciels. Un lien depuis le Web du laboratoire vers la page laboratoire dans PLUME (ou la récupération d'un flux RSS de PLUME vers le Web du laboratoire) permet aussi d'accéder à ce référencement dans le Web du laboratoire et d'avoir une visibilité laboratoire.
De la même façon que la signature des publications est définie lors de la négociation des contrats quadriennaux des établissements, la ligne copyright pour identifier les détenteurs des droits patrimoniaux des logiciels libres peut être établie ; ceci facilite ensuite la diffusion rapide des logiciels libres des laboratoires.
Les publications de recherche sont souvent soumises à des procédures de validation (soumission et acceptation d'une publication) des résultats qui y sont publiés. Les logiciels n'ont pas ce type de procédure mais les publications associées à ces logiciels sont un élément pour leur validation. Et dans le cas des logiciels libres, la communauté d'utilisateurs qui accompagne habituellement ces logiciels renforce le processus de validation. Ces deux informations sont données dans les fiches PLUME-RELIER. Pour les logiciels propriétaires leur validation passe par les contrats qu'ils attirent.
La liste de publications d'un laboratoire permet son évaluation mais aussi la diffusion d'un savoir-faire qui alimente la recherche et contribue à son évolution permanente. De la même façon, la diffusion de la liste de logiciels d'un laboratoire peut conduire à leur incorporation comme brique logicielle dans d'autres développements, les laboratoires et les organismes de recherche doivent garantir les meilleures conditions pour ce processus de rayonnement.

Un correspondant logiciel dans le laboratoire ?

Chaque développeur peut suivre une des procédures proposées ci-dessus. Mais lorsque la production de logiciels est importante dans un laboratoire, la direction peut désigner une personne qui coordonne et éventuellement fasse le travail de saisie des descriptifs dans PLUME... En centralisant ce travail, cela permet d'homogénéiser l'ensemble des présentations, de gagner du temps et d'avoir une personne avec une vue d'ensemble de toutes les productions logicielles. C'est ce qu'a fait mon laboratoire en me désignant : cela a beaucoup facilité le référencement.
Le terme 'correspondant logiciel' s'inspire de celui de 'correspondant formation' utilisé au CNRS entre autres. En effet, un réseau de correspondants logiciels nous semble souhaitable et permettra la mise en place d'une vraie politique de valorisation de logiciels.

Si vous désirez mettre en place ce type de procédure et avez besoin de conseils relier-pilote [at] services [dot] cnrs [dot] fr (Ecrire à Plume à l'équipe RELIER).

Syndiquer le contenu