article

Article

Information pour installer IPv6 dans un laboratoire ou une université

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

Information pour installer IPv6 dans un laboratoire ou une université

  • Type de ressource : article
  • Date de publication du document ou de l'événement : Janv 2011
  • Auteur(s) ou responsable(s) :

    X. Jeannin CNRS

  • Contact pour plus d'informations : Xavier.Jeannin@urec.cnrs.fr

1. But de cette fiche plume

Le but de cette fiche plume n’est pas d’expliquer IPv6 mais plutôt de fournir à la communauté « éducation recherche » une synthèse sur le pourquoi d’IPv6 et sur les informations pour mettre en œuvre un déploiement d’IPv6 dans le contexte particulier de la communauté « éducation recherche ». Cette fiche ne réécrit pas ce qu’une littérature abondante explique déjà bien, mais fournit des pointeurs vers des sources d’information : livre, article, site, liste de diffusion.

2. Pourquoi IPv6 et pourquoi maintenant

La nouvelle génération de "IP", qui a fini par prendre pour nom IPv6, a été conçue pour corriger un certain nombre de problèmes d’IPv4 et offre donc naturellement de nombreux avantages sur IPv4. Seule une partie de ces avantages a été adaptée et mise en place sur IPv4 comme par exemple IPsec. Le premier frein au déploiement de IPv6 est que le poids de l’existant est tel, que la mise en place d’IPv6 a été reportée tant que la pénurie d’adresses publiques IPv4 n'a pas été effective.

Le second frein pour le déploiement d’IPv6 est dû au fait qu’il est nécessaire de changer une partie du code des applications réseau. Même si ce changement est très localisé (à l’ouverture de la socket, puis dans la gestion du DNS), cet inconvénient a vraiment été le frein principal pour l’adoption d’IPv6. L’article suivant (http://www.urec.cnrs.fr/IMG/pdf/EGEE-III-IPV6_Compliance_C_Cpp_Java_Python_Perl.pdf) explique dans le détail, avec des exemples concrets, comment porter votre application sur IPv6.

Annoncée au cours des années 90 (1994), la pénurie d’adresses chez le distributeur mondial des adresses, IANA (Internet Assigned Numbers Authority), est désormais prévue pour l’année 2011 (février 2011 au moment de la rédaction de cette fiche, voir le site de prédiction de la fin des adresses IPv4 potaroo). Cette erreur de prédiction est dûe principalement au développement de l’usage des classes d'adresses privées, à la mise en place de solutions de traduction d’adresse NAT (Network address translation) et à l’usage des CIDR (Classless Internet Domain Routing). Cette erreur de prédiction a notamment beaucoup décrédibilisé les tenants du déploiement d’IPv6. Quoiqu’il en soit, nous sommes désormais face à cette pénurie d’adresses IPv4. Il convient cependant de noter que, de par le fonctionnement de la distribution des adresses IP, la pénurie ne se fera sentir pour l’usager que plusieurs mois après l’épuisement des adresses chez IANA. Car entre IANA et l’usager final, les Regional Internet Registries (RIR, un par
continent, RIPE pour l’Europe) et les Local Internet Registries (LIR, par exemple RENATER) ont un stock d’adresses IPv4 qu’ils vont distribuer eux aussi jusqu’à épuisement.

L’épuisement des adresses IPv4 ne va pas signifier l’arrêt de l’internet mais plutôt la fin de sa croissance. Néanmoins, la fin de cette croissance va sans doute impacter douloureusement les sociétés de l’internet, et comme de nombreux réseaux ne seront pas prêts pour IPv6, on parle déjà de surcoût dû au non déploiement d’IPv6 pour les entreprises.

Enfin, certains envisagent de nouvelles mesures pour prolonger la vie d’IPv4. Le CGN “Carrier Grade Nat” (CGN), qui est une sorte de "super NAT", en est un exemple. Mais ces mesures ajoutent encore un niveau de complexité et donc de nouveaux problèmes. A l'inverse, la connectivité IPv6 doit permettre de simplifier l'architecture des réseaux, car l'espace d'adressage étant beaucoup plus important, chaque équipement peut être connecté à l'internet avec une adresse publique, donc sans devoir recourir à une quelconque traduction d'adresses.

La situation est donc maintenant devenue tendue et plusieurs états (Japon, Corée, Chine), la communauté européenne, des ministères (Department Of Defense, USA), des opérateurs et grands acteurs de l’Internet (Google, Facebook, Yahoo!, Akamai et Limelight Network), lancent des actions pour favoriser le déploiement d’IPv6 : le world IPv6 day (http://isoc.org/wp/worldipv6day/, http://test-ipv6.com/ipv6day.html), l'exigence de la compatibilité IPv6 dans tous les appels d’offres, des projets européens autour d’IPv6, …

IPv6 apporte les avantages suivants par rapport à IPv4 :

  • Un espace d’adressage beaucoup grand.
  • La possibilité de bénéficier d’adresses publiques tellement importante qu'elle évite la nécessité de translation d'adresses NAT et
    rétablit la connexion de bout en bout (très utile pour certaines applications: voix sur IP, etc …).
  • Un espace d’adressage hiérarchique qui permet de réduire considérablement les tables de routages. La taille de ces tables est en effet un problème pour les routeurs de cœur de l’Internet.
  • Les problèmes de mobilité des postes sont bien mieux traités avec IPv6.
  • L’auto-configuration des postes clients.

Les systèmes d’exploitation et les équipements réseaux récents sont désormais compatibles avec IPv6. Le protocole IPv6 et ses implémentations sont aujourd’hui matures et les exemples de déploiement réussis montrent que
celui-ci est facile à réaliser.

3. Les adresses IPv6

Les adresses IPv4 sont codées sur 32 bits soit 2 à la puissance 32 adresses possibles soit 4,294 milliards d’adresses en IPv4. Les adresses IPv6 sont codées sur 128 bits soit 2 à la puissance 128 soit 3,4 x10 à la puissance 38.

Exemple d’une adresse IPv6 : 2001:0660:3003:0001:0000:0000:6543:210F

L'écriture simplifiée donne : 2001:660:3003:1::6543:210F

(les :: successifs signifient une suite de 0)

Les 64 premiers bits de gauche sont utilisés pour tout ou partie pour former le préfixe du réseau. Pour l’adresse de l’interface
de l’hôte dans le réseau (sans le préfixe), on doit utiliser au minimum les 64 derniers bits de droite. On ajoute la notation /XX par exemple /48 pour indiquer la longueur du préfixe, c.a.d. le nombre de bits à gauche dédiés au préfixe.

2001:660:3003:1::6543:210F/48 veut dire que le préfixe est 2001:660:3003 et l’adresse de l’interface de l’hôte
est 0001:0000:0000:6543:210F dans le réseau 2001:660:3003.

Une interface réseau peut avoir plusieurs adresses en IPv6, mais nous ne détaillerons pas ce point qui dépasse le cadre de cet article.

Pour l’instant le plan d’adressage décidé pour IPv6 au niveau de l’internet n’utilise qu’un huitième de tout l’espace disponible en IPv6, il donc possible de changer ce dernier si des problèmes apparaissaient.

4. Méthode de déploiement

a. le dual-stack (double pile)

Il existe différentes manières de déployer IPv6, cela dépend surtout de votre existant : votre matériel, vos applications et l’offre de votre opérateur. La période de transition verra certainement une mise en oeuvre d’IPv6 au coté d’IPv4 au sein de l’Internet grâce à des systèmes dits « dual-stack » (double pile) et ceci pour une période qui pourra être longue. Le dual-stack permet à une machine de "parler" à la fois IPv4 et IPv6. Dans cette architecture, le DNS joue un rôle primordial, c'est lui qui permet à l'initiateur d'une connexion réseau de choisir s'il veut se connecter en IPv4 ou en IPv6 selon ses propres possibilités et les possibilités de la machine à laquelle il veut accéder. Quand un client compatible IPv6 demande l'adresse IP d'une machine, le DNS renvoie les deux types d'adresses (IPv6 et IPv4) selon les possibilités de la machine ou service visé. Si le client n'est pas compatible IPv6, il utilise alors l'ancienne forme d'appel DNS, et le DNS ne lui renverra que l'adresse IPv4. Le dual-stack assure le maintien de l’existant, c.a.d. le maintien des vieilles applications et vieux matériels non compatibles IPv6. La technique dite de double pile, peut convenir à tous les environnements actuels – bien qu‘elle ne règle pas le problème de la pénurie des adresses IPv4.

Avantages :

  • Assurance de pouvoir maintenir l’intégralité de l’existant
  • Possibilité de déployer IPv6 dans un sous-réseau sans que les nœuds soient tous compatibles IPv6
  • Progressivité possible (IPv6 dans un testbed, pour les services réseaux ou pour tous les nœuds, tous les sites ou seulement certains d’entre eux)
  • Il s’agit dans ce cas plus d’un déploiement que d’une migration

Inconvénients :

  • Un surcoût de gestion de deux versions du protocole IP
  • Persistance d’IPv4 plus longtemps
  • Les utilisations du réseau continueront de passer en grande majorité par IPv4 dans un premier temps

La solution dual-IP possède donc quelques inconvénients mineurs mais l’immense avantage est de garantir le bon fonctionnement des services et applications sous IPv4, ce qui assure que les applications et les services, pour l’instant incompatibles avec IPv6, resteront opérationnels.

b. Méthodologie de déploiement, phases

La méthode retenue est de déployer IPv6 au côté d’IPv4 en utilisant des machines double pile. Les phases proposées pour un projet de déploiement d’IPv6 sont :

  • Vérifier les pré-requis : cela passe par la vérification que votre réseau de collecte fournisse le service de connectivité IPv6, par un inventaire de la compatibilité IPv6 des équipements réseaux et par une acquisition de compétences IPv6 (formation).
  • Les préparatifs: après avoir obtenu un préfixe IPv6 auprès de votre opérateur réseau (RENATER ou autre), vous définissez un plan d’adressage et votre stratégie de gestion du DNS, premier service nécessaire au déploiement d’IPv6.
  • La phase de test : elle consiste en la configuration sur une zone test des premières machines et routeurs, puis vous ajoutez leurs adresses IPv6 dans la configuration de votre DNS.
  • La phase pilote : vous vous raccordez au réseau de collecte et paramétrez votre routage externe et interne. La sécurité doit être mise en place au travers de filtres comme en IPv4, mais avec quelques spécificités IPv6 qu’il convient de prendre en compte.
  • La phase de déploiement des services : vous migrez progressivement vos services réseaux sous IPv6. La quasi-totalité des services TCP/IP classiques supportent IPv6 et sont faciles à mettre en place.
  • La phase de déploiement au public : après avoir déterminé une stratégie pour l’auto-configuration, vous pouvez déployer IPv6 chez les utilisateurs.

Le document suivant (http://www.urec.cnrs.fr/IMG/pdf/IPv6_par_ou_commencer.pdf) propose une méthodologie de déploiement d’IPv6 pour le CNRS que vous pourrez adapter à votre contexte.

5. La sécurité

La sécurité en IPv6 ressemble fortement à celle en IPv4 à quelques exceptions près. De manière générale le sujet a été traité de manière approfondie dans le document suivant « Guidelines for the Secure Deployment of IPv6 » (http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf) et de manière plus pratique pour notre contexte dans le document « La sécurité dans une transition vers IPv6 » (http://www.urec.cnrs.fr/IMG/pdf/secu.articles.Archi.Securite.IPv6.pdf).

L’un des points importants est que la sécurité de votre réseau repose sur du filtrage comme en IPv4. Cependant, même si les fournisseurs de firewall proposent les mêmes fonctionnalités, il se peut que les performances obtenues avec IPv6 soient moindres (il arrive que des fonctionnalités implémentées au niveau matériel en IPv4 le soient au niveau logiciel en IPv6, il faut donc bien se renseigner au préalable).

6. La métrologie reseau

La métrologie réseau recouvre les mesures de la performance du réseau avec pour objectifs :

  • Connaître le taux d’utilisation du réseau : comptabilité 
  • Connaître la charge des liens : bonne répartition et architecture du réseau ? Goulots d’étranglement ? 
  • Connaître la nature du trafic : sécurité, analyse, statistiques 
  • Connaître les performances du réseau : contrat de service, QoS

Ces objectifs sont réalisés en IPv6 comme en IPv4.Le protocole SNMP peut récupérer des mesures concernant IPv6 à partir d'un transport soit en IPv4 soit en IPv6. Les MIB pour IPv6 sont globalement disponibles mais il faut vérifier que les contructeurs les ont bien implémentées. Les outils classiques de mesures acties comme Iperf, etc. sont compatibles avec IPv6 en général.

Pour la partie analyse de flux, c'est à partir de NetFlow version 9 qu'IPv6 est supporté.

7. La supervision

La supervision d’un réseau IPv6 se fait de la même manière qu’en IPv4. L’important est d’utiliser le même outil pour les deux versions du protocole afin de ne pas augmenter le travail de supervision.
Argus (http://argus.tcp4me.com/) est un outil très simple et facile à déployer, il convient très bien pour un petit environnement.
Nagios (http://www.projet-plume.org/fr/fiche/nagios) est très connu et fournit plus de fonctionnalités, il convient très bien pour un environnement plus étendu.

 

8. Des références

Livre et documentation générale

  • Gizèle Cizault - (ouvrage collectif du G6) - IPv6 Théorie et Pratique disponible sur le site http://livre.g6.asso.fr/index.php/Main_Page
  • IPv6 : The New Internet Protocol C. Huitema Prentice Hall, Englewood Cliffs, New Jersey -1996. 188 pages
  • IPv6 and the TCP/IP Protocols Stephen A. Thomas Wiley Computer Publishing -1996. 481 pages ( disponible chez Eyrolles et au CNET )

Sites Internet autour d’IPv6

Projet de réseaux métropolitains, régionaux et mise en place de service

Vous trouverez de nombreux exemples de mise en place de services réseaux comme DNS, SMTP, IMAP, POP, HTTP etc. sur ces sites

Configuration d’un hôte

Fonctionnement d’IPv6 sur un serveur ou un client

Sécurité

  • 6net Large scale international IPv6 pilot network, http://www.6net.org/
  • Migration IPv6 : enjeux de sécurité, CERTA n°CERTA-2006-INF-004
  • Davis, Mohacsis - Recommendations for Filtering ICMPv6 Messages in Firewalls, IETF Draft draft-ietf-v6ops-icmpv6-filtering-recs-00.txt
  • La sécurité sous IPv6 - UREC/CNRS - Gaël Beauquin

Métrologie réseau

La métrologie réseau recouvre les mesures de la performance du réseau avec pour objectifs :

  • Connaître le taux d’utilisation du réseau : comptabilité 
  • Connaître la charge des liens : bonne répartition et architecture du
    réseau ? Goulots d’étranglements ? 
  • Connaître la nature du trafic : sécurité, analyse, statistiques 
  • Connaître les performances du réseau : contrat de service, QoS

Outil de supervision

Quelques articles dans notre communauté

Transition vers IPv6

Liste de diffusion

  • forumIPv6 [at] g6 [dot] asso [dot] fr (généraliste)
  • ipv6tech [at] g6 [dot] asso [dot] fr (technique)
  • ipv6 [at] ietf [dot] org (technique)

Epuisement des adresses IPv4 et action pour le déploiement d’IPv6

Opérateurs

Article OPAL - Les réseaux virtuels invités - nov 2010

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

Article OPAL - Les réseaux virtuels invités - nov 2010

Cet article a pour objectif de décrire comment, à l'intérieur de machines hôtes, il est possible de créer un réseau complexe de machines virtuelles. Celles-ci pouvant être placées sur des VLAN différents, utiliser le protocole 802.1Q, communiquer entre-elles ou avec d'autres machines physiques. L'article décrit la méthode mise en oeuvre au travers de l'utilisation de KVM, Libvirt et du commutateur virtuel VDE mais aussi de la solution qu'il a fallu créer pour améliorer la gestion de tout l'environnement. Des résultats de performances réseau sont également exposés.

Article OPAL - Conception d'une ferme de calcul pour la plateforme bioinformatique ATGC - nov 2010

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

Article OPAL - Conception d'une ferme de calcul pour la plateforme bioinformatique ATGC - nov 2010

L’augmentation de la quantité de données biologiques crée des besoins en infrastructure de calcul. L'équipe de recherche Méthodes et Algorithmes pour la Bioinformatique (MAB) développe des méthodes et des outils pour la biologie moléculaire à grande échelle. Ces travaux sont valorisés et distribués sur la plateforme ATGC. Les besoins de l'équipe sont liés à deux usages : un usage de production et un usage dédié aux expérimentations. L'équipe RéseauX du Service Technique Informatique (STI-RX) du Laboratoire d'Informatique de Robotique et de Microélectronique de Montpellier (LIRMM) a répondu aux besoins de la plateforme en proposant une architecture basée sur Sun Grid Engine et Mosix. L'équipe MAB est autonome sur certaines tâches de gestion, notamment par le biais d'un outil développé en interne : nadm.

L'agence de protection des programmes (APP) et le registre Inter Deposit Digital Number (IDDN)

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

L'agence de protection des programmes (APP) et le registre Inter Deposit Digital Number (IDDN)

  • Type de ressource : article, compte-rendu, événement
  • Date de publication du document ou de l'événement : 13 avril 2010
  • Auteur(s) ou responsable(s) : Les matinales du SAIC, Université Paris-Sud 11
  • Contact pour plus d'informations : http://app.legalis.net/, http://www.iddn.org/

Ce texte recueille les notes prises lors de la présentation "Logiciels : Inscription au registre IDDN", par Sylvie Rozenfeld, de l'Agence de Protection de Programmes (APP) et une partie des réponses aux nombreuses questions qui ont été posées... Cette présentation a été organisée par le Service des Activites Industrielles et commertiales (SAIC) de l'Université Paris-Sud 11 dans le cadre "Les matinales du SAIC" le 13 avril 2010.

Ces notes peuvent être inexactes, incomplètes et désorganisées, et refléter les centres d'intérêt d'une informaticienne du CNRS. Elles ont été parfois complétées. Aucune erreur dans ce texte ne peut être attribuée à Sylvie Rozenfeld ou à l'APP, ou aux organisateurs de cette matinale. Elles ont été relues par Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée) et par Anne-Catherine Letournel (LRI).

La confèrence commence, Sylvie Rozenfeld se présente : elle est juriste et son travail consiste à apporter de l'assistance juridique aux déposants à l'Agence de Protection de Programmes (APP). L'APP est une association selon la loi de 1901 et a été créée en 1982, avant que la loi de 1985 ne protège formellement le logiciel par le droit d'auteur.

Une première précision : le logiciel est protégé par la loi, pas par l'Agence de Protection des Programmes. Le logiciel est protégé du seul fait de la création, contrairement aux marques et brevets où le dépôt est constitutif de droits : il n'a pas de titre (ou document de propriété) établi ni un monopole d'une certaine durée.

Le logiciel est protégé par le droit d'auteur (N.B. voir le Code de la propriété intellectuelle - CPI). Le droit d'auteur avait été initialement conçu pour protèger la création artistique, et y faire rentrer les logiciels dans ce cadre a généré la surprise des experts juridiques. Le cadre juridique international est donné par la convention de Berne.

Le dépôt APP consiste en une déclaration sur l'honneur, ce n'est pas un titre de propriété.

Dans une oeuvre, on distingue l'originalité de la nouveauté : l'originalité est protégée par le droit d'auteur, on protège l'empreinte de la personalité de l'auteur, son style ; la nouveauté (d'un procédé) est protégée par le brevet. Il y a une seule condition pour que le droit d'auteur s'applique (et cela automatiquement) : c'est l'originalité de l'oeuvre qui représente l'apport personnel de l'auteur.

L'APP ne détermine pas l'originalité d'un logiciel, on accepte le postulat de l'originalité de l'oeuvre déposée. En cas de procès, c'est un juge qui doit prendre la décision sur l'originalité de l'oeuvre (et donc de sa protection ou pas par le droit d'auteur) : si l'on suspecte une oeuvre B d'être une copie d'une oeuvre initiale A, l'auteur de l'oeuvre B peut argumenter que l'oeuvre A n'est pas une oeuvre originale et qu'elle n'est donc pas protégée par le droit d'auteur. Le juge nomme un expert pour réaliser une étude, et décide en fonction des conclusions de cette étude si l'oeuvre A est originale (et donc protégée) et si B est une copie d'A.

Définition : Qu'entend-on par "logiciel" (en termes juridiques) ? L'arrêté du Ministre de l'Industrie du 22 décembre 1981 relatif à l'enrichissement du vocabulaire de l'informatique donne la définition suivante : « Ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au fonctionnement d'un ensemble de traitement de données ». C'est donc un concept large.

Dans la réalisation d'un logiciel, depuis l'idée initiale (qui n'est pas protégeable par le droit d'auteur en soi-même) à sa réalisation finale, il y a une étape à partir de laquelle le logiciel va pouvoir faire l'objet d'un dépôt APP. Les idées ne sont pas protégeables par la loi pour éviter que celle-ci soit un frein à l'innovation. La loi protège la forme, la manière dont une idée va être mise en forme. Le cahier des charges, les algorithmes ne sont pas non plus protégeables. Ce qu'on protège donc dans un logiciel est le code (code objet, code source), ainsi que le matériel préparatoire. Les fonctionnalités d'un logiciel ne sont pas protégeables par le droit d'auteur, c'est plus du ressort des brevets.

Le dépôt APP d'un logiciel n'est pas exigible par la loi. Ce dépôt peut faire partie d'une stratégie de "Pre-constitution de moyens de preuve" : on peut déposer un produit quand il est finalisé, mais on peut aussi commencer par le déposer dès les premières versions du logiciel (cahier des charges...) et renouveler le dépôt avec des versions successives. Cela sert à établir des dates associées au logiciel, le plus tôt possible est le mieux. Cela oblige les possibles adversaires (dans le cas d'un problème juridique) à fournir l'effort de prouver que leur création est antérieure : le dépôt APP peut donc constituer un avantage juridique. Le seul dépôt d'un cahier des charges (en tant que matériel préparatoire) n'est pas utile s'il n'a pas un produit logiciel associé par la suite.

Quelques remarques sur les logiciels libres qui ne sont pas "libres de droits" : aux USA, les logiciels sont protégés par le "copyright" qui relève du droit économique. Le droit d'auteur (en France) donne plus de droits puisqu'il y a la distinction entre les droits patrimoniaux ("monnayables", et que l'on peut céder) et les droits moraux (qui sont éternels et non cédables, par exemple les héritiers de Victor Hugo peuvent toujours opposer le droit d'auteur à certaines oeuvres pour défendre l'oeuvre de leur ancêtre). Il n'y a pas cette distinction entre les droits moraux et patrimoniaux dans le droit du copyright. Donc les licences de logiciels libres cèdent beaucoup de droits qui, aux USA, appartiennent à l'auteur (contrairement à ce qui arrive avec le droit d'auteur en France). En France, tout droit qui n'est pas explicitement octroyé est interdit.

Le droit d'auteur protège les créateurs, mais dans le cas d'un logiciel, il arrive souvent qu'il y ait plusieurs développeurs. Le CPI distingue, entre autres types, les oeuvres collectives, dont les droits (d'auteur) appartiennent à la personne morale qui initie l'oeuvre (N.B. On prend souvent l'exemple d'un dictionnaire pour ce type d'oeuvre : les auteurs des définitions ne sont pas auteurs de l'oeuvre collective).

Sauf dispositions particulières, c'est l'employeur d'un développeur qui est propriétaire des droits patrimoniaux du logiciel. Par exemple, des dispositions contraires à cette clause peuvent être incluses dans un contrat.

En matière de logiciel, le dépôt n'est pas prévu par la loi. En plus de l'APP, il y a d'autres possibilités pour établir des preuves (principalement sur la date associée au logiciel pour déterminer son orginalité). Il faut être certain de la fiabilité de ces preuves d'un point de vue légal. En voici quelques possibilités (N.B. j'ai complété la liste) :

On mentionne parfois l'enveloppe Soleau, produit de l'Institut National de la Propriété Industrielle (INPI) comme moyen de constituer une preuve de date pour une création, mais cette enveloppe ne doit pas comporter de “corps durs” (par exemple un CD, ou autre moyen contenant les sources d'un logiciel). Ce moyen sert donc à dater une description (texte) ou une reproduction en deux dimensions (schémas, dessins, photos, etc.) de votre logiciel.

L'APP compte plus de 12.000 adhérents : entités, particuliers, laboratoires, toute sorte de public peut adhérer l'APP (N.B. Des entités comme le CNRS, l'INRIA sont adhérentes à l'APP).

Pour déposer un logiciel, l'APP propose à ses adhérents deux enveloppes en plastique scellées qui vont contenir des CDROM à l'intérieur avec un (même) numéro d'ordre. Une fois que ce type d'enveloppe est fermé, son ouverture implique son déchirement et l'enveloppe perd sa valeur juridique. Le numéro d'ordre indique l'inscription du logiciel contenu dans le CDROM au repertoire IDDN (Inter Deposit Digital Number). Une enveloppe sera gardée en lieu sûr par l'APP, l'autre reste aux mains de l'adhérent. L'expert mandaté par un juge peut ouvrir l'enveloppe scellée de l'adhérent pour effectuer une étude. Une nouvelle enveloppe sera utilisée après l'étude pour contenir à nouveau le logiciel sous enveloppe scellée. Lorsqu'un expert est mandaté par un juge pour réaliser une expertise juridique, il mettra en place des séances de travail pour confronter les deux parties.

L'utilisation de CDROMs pose le problème de la pérennité du support. Il y a d'autres moyens pour dater un logiciel, mais la personne ou entité doit garder le logiciel (son contenant) dans un lieu sûr, à l'abri des incendies, vols et autres incidents.

Un dépôt APP consiste donc en :

  • un logiciel dans une enveloppe plastique scellée (en deux exemplaires),
  • un formulaire avec une demande de dépôt et la déclaration sur l'honneur,
  • un numéro IDDN (Inter Deposit Digital Number),
  • et un certificat délivré par l'APP.

On peut réaliser plusieurs types de dépôts : un dépôt de diffusion (attention : cette procédure ne permet pas l'accès contractuel aux sources), un dépôt des sources (permet un accès aux sources sous réserve d'une autorisation explicite écrite), ou un dépôt controlé (qui garantie que le dépôt a fait l'objet d'une vérification par un tiers, c'est un service payant de l'APP). L'APP propose aussi une procédure de référencement de logiciel, moins chère que le dépôt. Il faut adhérer à l'APP pour pouvoir réaliser un dépôt.

Le formulaire à remplir donne des actes juridiques, indique le nom du logiciel, qui fait le dépôt... En cas de plusieurs titulaires des droits, il y a un un seul déposant (appellé mandataire), indépendamment des accords de pourcentages de titularité que les propriétaires ont décidés. Le dépôt est effectué par les détenteurs des droits patrimoniaux (ie. les propriétaires du logiciel). La seule date garantie par le dépôt est la date du dépôt (pas la date du contenu du CDROM), le dépôt retro-actif n'est pas possible. C'est un acte déclaratif et pas constitutif de droit. On déclare ce qu'on peut prouver.

Dans un dépôt APP, il est possible d'inclure du code externe (qui n'appartient pas aux déposants). Alors on utilise la formule "sous réserve de droits de tiers" qui indique qu'on ne revendique pas des droits sur le code dont on n'a pas la propriété.

Dans le cadre d'une collaboration internationale pour le développement d'un logiciel, il faut la signature des partenaires étrangers détenteurs de droits. Il peut arriver que le dépôt APP soit utile dans une procédure juridique étrangère, mais aussi que ce dépôt ne soit pas reconnu par un tribunal étranger.

Une question a été posée sur un logiciel obtenu de la traduction d'un premier dans un autre language informatique. C'est la même situation que dans la traduction d'un livre, il s'agit d'une oeuvre dérivée : le traducteur apporte son empreinte, mais s'appuie dans une oeuvre pré-existante. L'auteur de la première oeuvre est aussi auteur de l'oeuvre derivée.

Une autre question a été posée sur le dépôt d'accès aux sources : si l'entreprise disparaît, les utilisateurs peuvent aller à l'APP pour recupérer le code source déposé si c'est ainsi prévu dans le contrat.

Ma conclusion personnelle est qu'il est très important d'associer une première date à tout logiciel (ou à son matériel préparatoire), et aussi aux différentes versions du logiciel, surtout s'il y a apport de nouvelles fonctionnalités importantes. Ces dates doivent avoir une valeur juridique pour pouvoir faire face à des problèmes légaux (assez rares dans notre communauté d'Enseignement Supérieur et Recherche, mais possibles).

Il me semble aussi important de faire attention à la documentation (et aux dates des versions différentes) qui doit accompagner le logiciel, et qui est soumise (article L113-9 du CPI) aux mêmes conditions que le logiciel lui même en termes de détenteurs de droits patrimoniaux.

Plusieurs moyens sont à la disposition des propriétaires des logiciels pour établir ces dates, chacun doit prendre le moyen le plus adapté à sa situation et à ses moyens économiques. Dans les laboratoires, il est possible d'utiliser le cahier du laboratoire (voir par exemple http://www.cnrs.fr/infoslabos/cahier-laboratoire/) pour inscrire et dater les évolutions d'un logiciel.

Des institutions comme le CNRS et l'INRIA utilisent les dépôts APP pour connaître et gèrer leur patrimoine logiciel, mais nous pensons que cette procédure n'est pas très bien adaptée à tous les types de logiciel qui sont développés aux laboratoires (voir par exemple le Guide laboratoire pour recenser ses développements logiciels).

Une question intéressante associé à ce sujet : quelle est la valeur légale des dates associées à un logiciel par une forge ?

UREC : Unité REseaux du CNRS

UREC : Unité REseaux du CNRS

L'UREC, Unité REseaux du CNRS, a été une Unité Propre de Service (UPS) du CNRS, de 1990 à 2010. Sur décision de la Direction du CNRS, l'entité spécifique UREC avec des missions, une stratégie et une gestion propre n'a pas été renouvelée en juillet 2010. La direction du CNRS a décidé de continuer les projets et les activités de l'UREC dans la Direction des Systèmes d'Information (DSI) du CNRS.

Parallèlement, les personnels UREC (13 personnes) ont été affectés dans la DSI du CNRS. Début décembre 2010, deux personnes ont demandé et obtenu leur affectation dans d'autres laboratoires, 5 personnes cherchent une mutation interne, six personnes sollicitent une mise à disposition auprès du GIP RENATER.

J'ai participé à toute l'aventure UREC pendant 20 ans. Cela a été passionnant, avec toujours de nouveaux domaines à explorer. Je ne me suis jamais ennuyé, je ne suis jamais tombé dans la routine et j'ai pu participer (modestement) aux débuts et à la montée en puissance des infrastructures réseau, des services associés, de la sécurité, des grilles...  Il me semble aussi que les réalisations de l'UREC ont été utiles aux laboratoires et plus largement. Fin de l'autosatisfaction.
Cette fiche essaie de décrire les principales activités et réalisations de l'UREC durant ces années, sans être exhaustif, loin s'en faut. Ce n'est pas un document officiel du CNRS, elle reflète la vision de l'auteur avec les informations (partielles sur l'histoire de l'unité) dont il dispose. N'hésitez pas à me contacter si vous relevez des erreurs. Elle est malheureusement incomplète. J'ai commencé la rédaction fin juillet 2010 et l'ai complétée progressivement. Je pensais pouvoir la terminer rapidement. Mais début décembre, ce n'est toujours pas le cas et je ne pense pas pouvoir dégager beaucoup de temps dans les mois qui viennent. Je la publie donc incomplète et la compléterai au fil du temps avec l'aide de mes collègues de l'UREC.

Toutes les activités et projets de l'UREC cités ci-dessous ont été portés par les personnels de l'unité, le directeur ne jouant souvent qu'un rôle de pilotage stratégique et d'animateur. Je n'ai pas voulu les citer à chaque item pour simplifier la lecture mais ils se reconnaitront...

Missions

L'UREC était une UPS, c'est à dire une unité, entité similaire à un laboratoire de recherche, qui ne fait pas de recherche mais qui assure des services. Dans le cas de l'UREC, qui était une unité nationale transverse, les services étaient destinés à l'ensemble des autres laboratoires et services du CNRS, avec des liens forts avec les universités et les autres organismes de recherche publics.

L'activité de l'unité couvrait les domaines :

  • de l'infrastructure et des services de base réseau,
  • des services Internet,
  • de la sécurité informatique,
  • des grilles de calcul,
  • des logiciels utilisés ou développés dans les laboratoires.

A travers ses missions, elle a eu un rôle de :

  • conseil, avec l'établissement de recommandations nationales,
  • test, parfois de développement et de déploiement de solutions innovantes,
  • participation ou de conduite de projets,
  • représentation du CNRS dans les instances nationales et internationales,
  • formation,
  • mutualisation des compétences,
  • animation de communauté informatique.

Organisation - personnel - pilotage

Elle a été créée en 1990 par Christian Michau, premier directeur jusqu'en 2002. J'en ai assuré la direction jusqu'en 2006, puis Bernard Rapacchi m'a succédé jusqu'en 2010.

L'unité a regroupé deux secrétaires-gestionnaires et  un ensemble d'ingénieurs en informatique (2 au départ, jusqu'à 20 en 2004 avec de nombreux CDD, une douzaine en moyenne) souvent experts dans un ou plusieurs domaines thématiques de l'unité.

Les personnels permanents en 2010 (avec leur date d'arrivée)

  • Catherine Dejancourt (sept 1990)
  • Jean-Luc Archimbaud (sept 1990)
  • Claude Gross (juillet 1993)
  • Geneviève Romier (sept 2001)
  • Xavier Jeannin (janv 2002)
  • Gaël Beauquin (déc 2005)
  • Bernard Rapacchi (juillet 2006)
  • Fabienne Tola (janv 2007)
  • Laurent Aublet-Cuvelier (sept 2008)
  • Hassan Hassan (déc 2008)
  • Alice de Bignicourt (déc 2008)
  • Etienne Dublé (déc 2009)
  • Bénédicte Sabatier-Labeyrie (mai 2010)

Les personnels permanents avant 2010 (avec leur période de présence à l'UREC)

  • Christian Michau (juillet 1990 - juin 2001)
  • Jacqueline Denyset (juillet 1990 - janv 1998)
  • Mitra Kani (oct 1990 - sept 1991)
  • Jean-Paul Marteau (mai 1991 - fév 1993)
  • Jacky Renaudineau (déc 1991 - janv 1993)
  • Jean-Paul Gautier (janv 1992 - oct 2007)
  • Cathy Treca de Kerday (janv 1992 - janv 1999)
  • Bernard Phan Dinh Tuy (sept 1992 - mars 2000)
  • Bernard Rapacchi (juillet 1996 - juillet 1998)
  • Philippe Leca (janv 1997 - janv 2003)
  • Nicole Dausque (mai 1997 - mars 2008)
  • François Collignon (sept 1999 - nov 2008)
  • Marie-Claude Quidoz (sept 1999 - mai 2008)
  • Sophie Nicoud (nov 2000 - nov 2006)
  • Catherine Grenet (sept 2001 - oct 2009)

D'autres tableaux récapitulatifs listent :

Cette unité a toujours été répartie sur 2 sites principaux, Paris et Grenoble. A certains moments certains personnels ont aussi été hébergés dans des laboratoires à Lyon, Marseille et Montpellier.

Elle a été rattachée, au CNRS, successivement au département SPI (Sciences Pour l'Ingénieur 1990-2000), au département STIC (Sciences et Technologies de l'Information et de la Communication 2000-2005), au Secrétariat Général (2006-2010). De 1990 à 2006, elle a été pilotée par le COMI, Comité d'Orientation des Moyens Informatiques au CNRS, où siégeaient les chargés de mission informatique de chaque département scientifique. Le COMI a été dissout en 2006. Le secrétaire général du CNRS a ensuite piloté directement l'UREC.

Partenaires

L'UREC a toujours travaillé en collaboration avec de nombreuses autres entités du CNRS, des organismes de recherche et des universités. En particulier :

Serveur d'information national

L'UREC a toujours regroupé et diffusé de très nombreux documents produits par des ingénieurs de l'UREC mais aussi par de très nombreux membres de la communauté Enseignement Supérieur - Recherche. Son site d'information (FTP anonyme, puis gopher, puis site web : http://www.urec.cnrs.fr mis à jour jusqu'en juin 2010 et qui disparaitra peut être) a toujours été une référence de documents techniques dans les domaines de compétence de l'unité. Le site dormant (http://www.urec.cnrs.fr) contient encore de nombreuses publications de l'UREC : descriptions et productions de projets et groupes de travail, recommandations, articles, cours...

Ci-dessous sont présentées quelques réalisations-actions de l'UREC, chronologiquement, par période de quatre ans, périodicité de renouvellement de l'unité et de son directeur.

1990 : création (Christian Michau)

L'UREC a été mise en place en 1990 sous l'impulsion du COMI (Comité d'Orientation des Moyens Informatiques) du CNRS, avec 4 missions dans le domaine des réseaux informatiques pour le CNRS :

  • Coordination, orientation et planification à l'intérieur du CNRS
  • Concertation et coordination techniques avec les partenaires nationaux et internationaux
  • Suivi de l'évolution du réseau dans la stratégie retenue par le CNRS
  • Affectation des moyens aux divers intervenants

et avec 5 volets complémentaires :

  • Coordination/fédération des actions
  • Administration globale du réseau CNRS : nommage, adressage, routage, sécurité, gestion des infrastructures communes
  • Veille technologique, appels d'offre communs
  • Information et formation sur les réseaux
  • Participation technique aux actions internationales

On peut rappeler qu'en 1990, l'Internet et le Web n'existaient pas et que les ménages n'étaient pas équipés d'ordinateur personnel mais de minitel. Dans le monde de la recherche, RENATER n'existait pas, les seules liaisons informatiques, quelques dizaines seulement, étaient des liens point à point pour connecter 2 gros centres de calcul, sous protocle SNA, DECNET... mais pas IP, loués à l'opérateur national France Télécom qui avait le monopole ainsi que des accès TRANSPAC sous protocole X25 à 64 K maximum (j'ai bien dit Kilo). 

1990 : premières actions (Christian Michau)

Au démarrage l'UREC a piloté ou participé comme représentant du CNRS :

  • Au projet de réseau national de la recherche qui donnera RENATER
  • A tous les projets de réseaux régionaux qui se montaient
  • Au Réseau Académique de la Recherche Européenne, RARE
  • A différents groupes de travail : X25, messagerie, DECNET, IP...
  • Au démarrage d'actions de sécurité informatique : un ingénieur UREC a été nommé chargé de mission sécurité informatique du CNRS auprès du fonctionnaire de sécurité défense de l'organisme. Il le restera jusqu'en 2006.
  • A la mise en place d'une première formation réseau

Fin 1990 l'UREC regroupait un directeur, 3 ingénieurs et une secrétaire, installée à Jussieu avec un ingénieur à Grenoble. 

1990-1994 (Christian Michau)

(Contenu à compléter)

Nouveaux projets / activités / réalisations

  • Participation au COMI, Comité d'Orientation des Moyens Informatiques (cf ci-avant). Le directeur de l'UREC, ensuite assisté du directeur adjoint-chargé de mission sécurité participeront à toutes les réunions de ce comité (durant une période le directeur de l'UREC pilotera ce comité) jusqu'à la fin du COMI en 2006. Dans ce comité, l'UREC expertisait tous les dossiers de demande de financement sur les réseaux et leurs applications (et aidait les laboratoires à les monter).
  • Participation très active à la définition et à la mise en place technique de RENATER, en étant le représentant du CNRS et des laboratoires, en animant ou co-animant de nombreux groupes de pilotage ou de travail (comme le groupe de travail qui a défini le service IP et le modèle de point d'accès). Pendant plusieurs mois la sécrétaire-gestionnaire de l'UREC a aussi été celle de RENATER et le directeur de l'UREC a œuvré quotidiennement dans la petite structure qui a lancé RENATER. RENATER a mobilisé un grand nombre de ressources UREC pendant plusieurs années. Jusqu'à la fin de l'UREC, un ou plusieurs ingénieurs ont participé à tous les groupes techniques ou stratégiques importants de RENATER comme expert et/ou représentant des laboratoires CNRS.
  • Suivi de tous les projets de réseaux régionaux en tant que représentant du CNRS et experts techniques.
  • Participation active à la définition et à la mise en place du CERT Renater (Computer Emergency Response Team), premier CERT français qui existe encore actuellement.
  • Suite à une présentation de WWW par une personne du CERN lors d'une réunion GERET (cf ci-dessous) en septembre 1993 (ça démarrait au CERN), il y aura à partir de cette période en croissance exponentielle de très nombreux documents de synthèse, cours, présentations sur WWW, HTML et les services faits par l'UREC.

Continuité des projets/activités antérieurs

  • Continuité et montée en puissance du groupe GERET Groupe des Exploitants des Réseaux Ethernet TCP/IP (le terme administrateur de réseau n'existait pas, le métier était ingénieur système) avec des journées thématiques régulières. Pour exemple, 14 réunions durant ces 4 années : les analyseurs de réseaux,  SNMP et l’administration de réseau, les réseaux régionaux et métropolitains, intégration des micros dans les réseaux TCP/IP, les sauvegardes, le routage, FDDI, le câblage, X11 et les terminaux X, les services (ftp anonymous, wais, gopher, www),  DNS et Sendmail, administration de réseau (outils du domaine public et stations d’administration), les petits services qui rendent de grands services (modem, RTC, SLIP, PPP, RNIS, minitel, fax), la sécurité des réseaux  (PGP, TIS, filtres, xinetd, sendmail, legislation, IPng).
    Ce groupe avait été créé en mars 1990 par un ingénieur qui a rejoint l'UREC en septembre 1990. Ce groupe continuera jusqu'en 1998 avec au départ une quinzaine de participants et en fin une centaine à chaque événement.
  • Participation et ensuite animation de la liste IP, créée au départ par un ingénieur du CICB (Centre Interuniversitaire de Calcul de Bretagne), liste de diffusion électronique utilisée au départ principalement pour le groupe GERET. Cette liste sera le principal outil d'échanges et de diffusion d'information techniques pour tous les administrateurs de réseaux (ce métier n'existait pas à l'époque) des laboratoires et des universités pendant 15 ans, avec plusieurs messages quotidiens. En 2010 cette liste compte encore plus de 700 abonnés mais a maintenant peu d'échanges : les réseaux IP sont opérationnels et les administrateurs formés.

Le document 'UREC : bilan d'activité, période 1991 - 1993' décrit plus précisément les projets et activités durant cette période.

1994-1998 (Christian Michau)

Nouveaux projets / activités / réalisations

  • Veille technologique très active autour du Web et création de très nombreux documents didactiques et de formations sur le la mise en place de serveur Web, HTML... L'UREC devient une référence et un pôle de compétence technique dans ce domaine émergeant.
  • Mise en œuvre d'un annuaire des serveurs Web français qui pendant de nombreuses années sera une référence en France (il n'y avait pas de moteur de recherche).
  • Evaluation des solutions de cache Web avec mise en place d'une solution sur le campus de Jussieu. Les liaisons nationales étaient saturées par le Web et leurs débits ne pouvaient être augmentés à des prix raisonnables. L'objectif était de réduire le traffic généré par le Web sur ces liaisons en installant des caches pour le traffic Web en entrée de chaque gros campus. Depuis les débits disponibles, loin d'être saturés rendent inutiles des idées de cache.
  • Mise en œuvre d'un réseau d'expérimentation IPV6 à l'UREC et mise en place d'un backbone national IPv6 relié aux réseaux étrangers similaires.
  • Pilotage ou participation à différents projets expérimentaux haut débit (Nationale-MIRIHADE et SAFIR, Ile-de-France EFRA, Grenoble-C3I2)
  • Développement d'un outil d'analyse et de mesure de trafic IP, IPTrafic, concrètement un logiciel sur un PC (de tels outils ou logiciels n'existaient pas à l'époque). Ce développement a ensuite été repris par le CRU. En 1998 il était en exploitation sur 60 sites.
  • Veille technologique intense sur ATM, protocole réseau populaire à l'époque, avec organisation de plusieurs formations.
  • Suivi des travaux de l'IETF et participation à RIPE (Réseaux IP Européens).
  • Lancement d'une nouvelle liste URECOR, correspondants UREC, qui deviendra la liste ASR (Administrateur Système et Réseau). En 2010 cette liste est toujours très active et compte plus de 500 abonnés.
  • Organisation de formations intensives à Paris (ARS) et à Grenoble (ASR) pour former des Administrateurs Systèmes et Réseaux (200 h). Tous les supports avaient été mis en ligne et seront intensivement réutilisés dans le CNRS, les universités et plus largement.
  • Création du groupe des correspondants sécurité (informatique) de laboratoire. Ce groupe servira à identifier une personne contact sécurité dans chaque laboratoire pour diffuser des recommandations, des avis de sécurité, traiter les problèmes d'intrusions, faire remonter les besoins. 160 personnes y sont inscrites en 1998. Ce groupe se structurera dans les années suivantes avec des coordinateurs régionaux (l'ensemble prenant le nom de 'chaîne opérationnelle de sécurité informatique') et continuera très activement jusqu'en 2006. En 2006, il y avait 720 correspondants sécurité et 65 coordinateurs régionaux/thématiques. Le service du fonctionnaire de défense du CNRS reprendra alors l'organisation en remplaçant les coordinateurs régionaux par des CRSSI, Correspondants Régionaux de la SSI et des chargés de la sécurité CSSI dans les laboratoires.
  • Développement d'une méthode d'auto-évaluation de la sécurité informatique des laboratoires. Cette méthode sera diffusée dans de très nombreux laboratoires (200 environ) à travers des opérations sécurité dans chaque région.
  • Création d'une formation d'une semaine  : Sécurité Informatique pour les Administrateurs Réseaux et Systèmes (SIARS). Cette formation sera donnée dans de très nombreuses régions.
  • Mise en œuvre du serveur de noms cnrs.fr qui restera opéré par l'UREC jusqu'à la fin de l'unité. En 1998 il gère 57 zones, est serveur primaire pour 12 zones et secondaire pour 184.
  • Mise en œuvre d'un serveur de listes de diffusion électronique services.cnrs.fr. En 1998 ce serveur héberge 25 listes. Il continuera d'être exploité jusqu'à la fin de l'UREC.
  • Organisation avec le CRU, des premières journées réseaux JRES à Chambery en 1995, qui ont réuni 350 informaticiens pendant une semaine. Ces journées ont ensuite été organisées tous les 2 ans en reprenant les principes des premières, l'assistance augmentant régulièrement. RENATER et l'INRIA se sont ensuite joints aux organisateurs initiaux, l'UREC et le CRU. Les JRES de 2009 ont regroupé 1500 personnes.
  • Coordination éditoriale avec le CRU et rédaction de nombreux articles d'une monographie 'L'internet professionnel' de 450 pages publiée par CNRS Edition, sortie en mars 1995 et diffusée à 10 000 exemplaires dans les laboratoires et les universités : une référence pendant de nombreuses années pour les laboratoires et les universités.

Continuité des projets/activités antérieurs

  • Conduite de projet ou expertise technique pour la mise en place de différents réseaux de gros laboratoires ou de campus (campus Vitry, MSH Aix, campus Ivry, campus CNRS Sophia, Inst maths Bordeaux, MSH Poitier, Institut du gout, Collège de France, Nanterre)
  • Réunions régulières du groupe GERET, organisation et participation aux conférences JRES97...

En 1998 l'UREC regroupait 2 secrétaires et 8 ingénieurs

Le document 'UREC : rapport d'activités Aout 1998' est un résumé des projets-activités UREC durant cette période.

1998-2002 (Christian Michau)

(Contenu à compléter)

Nouveaux projets / activités / réalisations

  • Participation à la conception et à la mise en œuvre du réseau RAP, Réseaux Académique Parisien. Un ingénieur de l'UREC en a été le directeur technique dans toute cette phase. Le réseau a été ouvert  en 2001.
  • Ouverture du service IGC CNRS, permettant de délivrer des certificats électroniques à toutes les personnes qui travaillent dans un laboratoire CNRS et pour tous les serveurs, avec un logiciel (40 000 lignes de code), une plateforme et une organisation développée par l'UREC.
  • Participation au groupe logiciel enseignement supérieur recherche comme représentant le CNRS. Cette participation continuera jusqu'à la fin de l'unité.

Continuité des projets/activités antérieurs

  • Expertise et aide à la mise en place des réseaux de campus, poursuite des opérations sécurité dans des régions, organisation et participation aux conférences-formations : JRES99, JRES2001...
  • Poursuite de la diffusion du cours d'une semaine Sécurité Informatique pour les Administrateurs Réseaux et Systèmes (SIARS) dans les régions.

Continuité des services assurés

2002-2006 (Jean-Luc Archimbaud)

Nouveaux projets / activités / réalisations

  • Développement d’un outil de surveillance réseau MapCenter dans le cadre du projet européen de grille de calcul Datagrid (ancêtre de EGEE, cf ci-dessous).
  • Création de la fédération de réseaux de métier d'administrateurs systèmes et réseaux RESINFO copilotée par l’UREC à cette époque. En 2010, 16 réseaux seront regroupés dans cette fédération avec plus de 1700 administrateurs systèmes et réseaux participants.
  • Coordination de la rédaction d’un cours de 400 pages de sécurité informatique, cours d’une semaine enseigné plus de 30 fois, rédaction de plusieurs dizaines de fiches techniques de produits de sécurité.
  • Etude sur le chiffrement des portables.
  • Organisation de 2 écoles thématiques de sécurité (une semaine, 70 participants pour chaque) : Vers des communications et des applications réseaux plus sécurisées (vCARS).
  • Mise en œuvre d'une branche projets-grille dans l' IGC CNRS.
  • Développement d'un outil (47 000 lignes de code) de travail collaboratif, installé dans un département scientifique du CNRS et dans plusieurs Intranets de laboratoires.
  • Responsabilité de l’exploitation du projet de grille de calcul française e-Toile.
  • Dans le projet européen de grille de calcul et de stockage EGEE, participation aux activités qualité et sécurité, responsabilité de l’activité réseaux, fourniture de 800 certificats électroniques.

Continuité des projets/activités antérieurs

  • Expertise et aide à la mise en place des réseaux de campus (campus CNRS de Montpellier et d’Orléans, réseau métropolitain PHOCE’AN à Marseille), participation à la rédaction du cahier des charges de RENATER (version 3 et 4), conférences-formations (JRES2003, JRES2005...).

Continuité des services assurés

Le document 'UREC : rapport d'activités synthétique 2002-2006' (juin 2006) décrit plus précisément les projets et activités durant cette période, la plaquette UREC (novembre 2005) en est une présentation synthétique.

2006-2010 (Bernard Rapacchi)

Nouveaux projets / activités / réalisations

  • Déploiement d'IPv6 dans les laboratoires avec des formations...
  • Formation sur IPv6 (une centaine de personnes formées)
  • Etudes sur la téléphonie sur IP, le service (réseau) de bout en bout, la sécurisation des sites Web, la mise en place d'un service messagerie-outils collaboratifs @cnrs.fr
  • Projet JANUS, gestion des identités au CNRS basé sur le logiciel shibboleth intégré dans la Fédération d'identité éducation-recherche. En juin 2010, ce service est utilisé par plusieurs applications du CNRS en particulier par le progiciel de gestion des ressources humaines.
  • Diffusion de certificats électroniques de serveurs TCS pour les laboratoires CNRS.
  • Sur la sécurité trois formations de formateurs (2 jours avec 50 participants pour chacune) : Aide à l’Acquisition d’Information sur une Machine Piratée (A2IMP), Aide à l’Analyse de Actions Intentées sur une Machine Piratée (A3IMP), Aide à la Détection des Faiblesses d'un site Web (ADF). Ces cours ont ensuite été redonnés dans de nombreuses régions par les formateurs ainsi formés.
  • Lancement du projet et de la plateforme PLUME, Promouvoir les Logiciels Utiles Maitrisés et Economiques dans l'enseignement supérieur et la recherche. En novembre 2010, la plateforme proposait 800 fiches descriptives de logiciels ou de ressources liées aux logiciels.

Continuité des projets/activités antérieurs

  • Participation au projet européen de grille de calcul EGEE, avec une collaboration avec le CCIN2P3 : l'UREC a été responsable de l'activité réseau, responsable de la qualité dans cette activité et a beaucoup contribué aux 2 sous-activités : IPV6 et le monitoring réseau.
  • Expertise pour les projets de réseaux de campus, chiffrement des portables, organisation et participation à de nombreuses conférences-formations JRES2007, JRES2009...

Continuité des services assurés

  • Serveur de noms cnrs.fr qui à la fin de l'UREC gère 339 zones, est serveur primaire pour 35 zones et secondaire pour 453 zones.
  • Responsable de l'IGC CNRS et de son évolution pour les certificats électroniques au CNRS et pour une activité internationale de grille de calcul. A la fin de l'UREC, près de 12 000 certificats de personnes et 2 700 de machines sont actifs, pour plus de 1100 laboratoires (CNRS et autres), avec la branche pour les grilles de calcul utilisée par 36 organismes nationaux ou internationaux (CNRS, CEA...).
  • Service de listes de diffusion

Synthèse de l'étude "Pratiques de développement - ForgeESR"

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 22/10/10
  • Correction mineure : 30/07/13
Fiche archivée
Fiche archivée en accord avec son auteur, les résultats de l'enquête étant obsolètes aujourd'hui.
Mots-clés

Synthèse de l'étude "Pratiques de développement - ForgeESR"

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

Préambule

Le projet PLUME, le groupe Calcul et le réseau DevLog travaillent sur un projet visant à réaliser une étude prospective sur l'opportunité de proposer à la communauté Enseignement Supérieur - Recherche des solutions adaptées pour l'hébergement des développements des laboratoires de recherche.

Ce projet est décrit ici: http://www.projet-plume.org/ressource/projet-de-forge-ens-sup-recherche-le-perimetre-restant-a-definir

L'objectif est tout d'abord d'identifier les pratiques de développement dans la communauté Enseignement Supérieur et Recherche, au travers d'une enquête auprès de tous les membres de cette communauté amenés à développer du logiciel.

Cette enquête a été réalisée au printemps 2010 et a fait l'objet d'une très large diffusion, tant dans les réseaux métiers (Calcul, DevLog, ResInfo) que dans la communauté Plume et dans les structures de recherche (Instituts du CNRS, GDR …). Plus de 300 personnes ont répondu à cette enquête qui a été dépouillée en juillet 2010.

Elle permet d'avoir une idée des pratiques de développement actuelles dans les laboratoires de recherche, ainsi que des besoins exprimés par les personnes pratiquant cette activité.

Ce document propose une analyse synthétique des résultats de ce questionnaire. La première partie permet d'identifier les profils des répondants, tant en terme de tutelles, que de types d'activités et de pratiques de développement. La deuxième partie résume les outils actuellement utilisés dans le cadre du développement logiciel et la troisième partie permet d'identifier les besoins exprimés par les personnes ayant répondu à l'enquête. En conclusion, nous formulons quelques propositions.

Plan du document

1. Caractérisation des profils des répondants

2. Caractérisation des pratiques actuelles et outils utilisés

3. Caractérisation des besoins exprimés par rapport à une forge

4. Conclusions et propositions

Ce document a été rédigé par Véronique Baudin, Loic Gouarin et Violaine Louvet, après dépouillement de l'enquête, et complété par les remarques et corrections de Jean-Luc Archimbaud, Philippe Depouilly....

1. Caractérisation des profils des répondants

Le nombre de personnes ayant rempli le questionnaire est de 309. Dans ces réponses, on compte 204 questionnaires complets et 105 incomplets. Nous nous limiterons dans la suite de ce document à l'analyse des réponses complètes.

L'ensemble des tutelles du milieu de la recherche académique sont assez bien représentées. Nous comptons 86 personnes issues du CNRS et 38 personnes issues des Universités. Nous retrouvons également d'autres établissements publics. Si nous les donnons par ordre d'importance, nous avons l'INRA, l'INRIA, l'ENS, le CEA, l'INSA, …

Parmi ces personnes, 60% sont des ingénieurs et un peu plus de 28% sont des chercheurs et enseignants-chercheurs. Quelques doctorants ont répondu au questionnaire (7%). En revanche, très peu de techniciens y ont répondu (seulement 1,5%). L'activité de développement est, pour la plupart, permanente avec un peu plus de 64% des répondants, contre un peu plus de 31% pour lesquels cette activité est occasionnelle. Si nous regardons un peu plus finement comment se répartissent les fonctions de chacun dans ces deux formes d'activités de développement, nous constatons que la plupart des personnels disant développer de manière permanente sont des ingénieurs. Ces réponses semblent cohérentes avec les fonctions principales de ceux-ci. Concernant le développement occasionnel, les personnels sont partagés entre les ingénieurs et les chercheurs et enseignants-chercheurs. Les doctorants ont plus une activité de développement permanente avec 60% d'entre eux.

Les types de développement sont assez bien répartis et ne dépendent pas du type d'activité scientifique. Nous retrouvons dans les réponses les types suivants : développements web, création de logiciels de soutien, de bibliothèques, de codes de calcul et de composants logiciels. Si nous regardons les activités scientifiques des personnes réalisant des développements web, nous constatons qu'il n'y pas de liens forts avec leurs thématiques scientifiques. Nous pouvons donc en déduire que le développement web est annexe (création de sites web pour valoriser des projets). Nous constatons également que, les développeurs permanents développent des IHM pour leurs projets ce qui n'est pas encore le cas des développeurs occasionnels.

Ces développements font partie de projets internes ou externes à la structure et nous pouvons donc en déduire facilement qu'il n'y a pas en règle générale de développement à titre personnel. La majorité des codes développés sont publics ou destinés à le devenir. En règle générale, la diffusion se fait avec maintenance sauf pour les développeurs occasionnels qui peuvent diffuser sans maintenance. Le support semble être un point important pour les développeurs permanents. On peut également remarquer que les développements réalisés sont destinés soit à une diffusion ciblée, soit à une diffusion large.

Plus de 70% de ces développements se font en interaction avec des personnes extérieures, qui sont pour la plupart des ingénieurs et des chercheurs ou enseignants-chercheurs. Les disciplines de ces extérieurs sont essentiellement l'informatique, la physique, le calcul scientifique. La méthode de développement la plus utilisée est la méthode itérative (enrichissement du code par étapes successives : développement puis test par l'utilisateur final pour chaque étape). Nous retrouvons ensuite les méthodes agiles et l' "extreme programming".

2. Caractérisation des pratiques actuelles et outils utilisés

Dans cette enquête, nous avons interrogé les développeurs sur les différents outils qu'ils utilisent (gestion de version, forum, liste de diffusion, gestionnaire de tâches, ...). Les résultats obtenus nous permettent d'évaluer leur taux d'utilisation dans la communauté développeurs de l'enseignement supérieur et la recherche. Il est à noter que ces outils sont généralement présents dans une forge, outil offrant un ensemble d'outils permettant de développer dans des conditions optimales.

2.1 Outils de gestion de version

96,9% des développeurs permanents utilisent un système de gestion de version. Nous retrouvons le même pourcentage pour les développeurs occasionnels. Cet outil de développement est donc complètement entré dans les pratiques habituelles de tous les types de développeurs.

Nous pouvons distinguer 3 outils principalement utilisés : cvs (37,43% d'utilisation), Fiche Plume subversion (80% d'utilisation) et Fiche Plume git (21% d'utilisation). L'évolution naturelle correspond au degré de maturité de ces outils : abandon progressif de cvs, usage intensif de subversion et glissement vers des systèmes décentralisés comme git.

Il est important de noter que ces systèmes sont plutôt installés en local : 87% des développeurs pratiquant Git l'utilisent en local, 89,7% pour subversion et 73,9% pour cvs.

A noter enfin que 13% des répondants utilisent un autre logiciel de gestion de version. Les plus cités sont : mercurial (46%), bazaar (19%) et darcs (11%).

2.2 Outils de forum

Ces outils semblent très peu exploités dans le cadre des développements logiciels au niveau des laboratoires de recherche : seul 26% des répondants déclarent utiliser un système de ce type. Par ailleurs, dans ce cas, les outils cités correspondent essentiellement à des logiciels de forge.
L'emploi de forums est donc directement lié à l'usage d'une forge.

2.3 Outils de listes de diffusion

36% des répondants déclarent ne pas utiliser de listes de diffusion pour les utilisateurs et/ou les co-développeurs des codes. Ceux qui ont recours à ces outils le font majoritairement en local (62%).

2.4 Outils de suivi de tâches

63% des personnes n'utilisent aucun outil de suivi de tâches. Les autres pratiquent massivement Fiche Plume trac (à 64%). Nous pouvons noter une différence selon le degré d'activité de développement : 41,7% des développeurs permanents déclarent utiliser un système de suivi de tâches contre 27% pour les développeurs occasionnels.

2.5 Outils de génération de documentation

Les outils de génération de documentation sont globalement assez utilisés, par 71,2% des développeurs permanents et 63,5% des développeurs occasionnels.
Les systèmes les plus cités sont doxygen et javadoc.

2.6 Communication autour des projets

La communication et l'échange d'information autour des projets de développement logiciel passent majoritairement par la mise en place de site web dédié (64%) sans pour autant y associer des outils de calcul de statistiques d'utilisation et de téléchargements (seulement 22% des sites en sont équipés).

2.7 Autres outils

Les autres outils mentionnés dans la pratique du développement de logiciels sont en général des IDE comme Eclipse (souvent cité) et des outils de construction, d'optimisation et de tests (autoconf , valgrind , gcov...).

2.8 Utilisation de forges

D'une manière générale, les outils de forges sont peu utilisés : seul 32.6% des développeurs permanents et 31.7% des développeurs occasionnels ont recours à ces systèmes.

Les trois forges les plus citées par les personnes qui y ont recours sont :

Il faut noter également la multiplication de forges locales, dédiées à un établissement ou à un laboratoire.

Le choix d'un hébergement se fait principalement selon les critères suivants :

  • proximité contextuelle (lien avec la communauté, la structure d'appartenance) ou géographique
  • visibilité externe, diffusion large
  • facilité et simplicité d'utilisation, réactivité du support, flexibilité
  • pérennité

A noter que le temps de réponse du serveur hébergeant la forge est souvent vu comme un point à améliorer.

Pour résumer l'analyse des pratiques actuelles, on peut mettre l'accent sur les points suivants :

  • L'utilisation des systèmes de gestion de version est une pratique habituelle de tous les développeurs. Ces outils sont essentiellement installés de façon locale.
  • Les outils de génération de documentation sont assez massivement utilisés.
  • La pratique des autres outils comme les outils de gestion de tâches ou les outils de forums semble très liée à l'utilisation d'une forge.
  • La communication autour des projets de développement passe majoritairement à travers des sites web dédiés autonomes.
  • De manière générale, les forges sont peu utilisées, et il semble exister un nombre important de forges locales (niveau laboratoire, service ou établissement). Cette proximité contextuelle et/ou géographique est un point essentiel dans la motivation à héberger ses projets sur un site particulier. De même, les aspects visibilité externe, facilité et simplicité d'utilisation sont des critères décisifs du choix de l'hébergement.

3. Caractérisation des besoins exprimés par rapport à une forge

La dernière partie de l'enquête a concerné l'identification des besoins des utilisateurs en termes de forges. Ces besoins ont été listés par rapport à des besoins généraux ou globaux sur la forge, des besoins liés à chaque projet développé, aux services attendus de l'équipe administrant une forge. Nous avons proposé un ensemble de besoins et donné la possibilité aux personnes ayant répondu de compléter ces propositions. Pour chaque catégorie, nous donnerons les principaux besoins proposés par l'enquête ainsi que les besoins exprimés.

93,6% des personnes ayant répondu à cette enquête ont noté les besoins listés. Ce chiffre est à comparer aux 32% des développeurs utilisant déjà une forge. Les avis donnés ne sont donc pas dûs uniquement à des utilisateurs de ces outils, mais également à d'éventuels futurs utilisateurs de ceux-ci. Les résultats sont donnés en fonction des réponses des développeurs permanents (P) ou occasionnels (O).

3.1 Besoins globaux

Le classement par ordre de préférence donne les résultats suivants concernant les besoins globaux au niveau de la forge :

  • Recherche parmi les projets
  • Catégorisation des projets ; Bibliothèques de bouts de code (P et ordre inverse pour O)
  • Affichage, gestion de nouvelles (P) ; Recherche, invitation de développeurs (O)

Parmi les autres fonctionnalités données par les personnes ayant répondu à l'enquête, on peut extraire les points suivants :

  • Affichage des projets par entité / laboratoire
  • Recherche de développeurs par champs ou domaine de compétences : langages / méthodes / domaine d'application …
  • Aide au choix de la licence et de la diffusion.

3.2 Besoins concernant les projets déposés

Le classement par ordre de préférence donne les résultats suivants concernant les besoins au niveau des projets déposés sur la forge :

  • Outils de gestion de versions, forum (P) ; Informations générales sur le projet (O)
  • Informations générales sur le projet (P) ; Système de suivi (O)
  • Système de suivi (P) ; Outils de gestion de versions, forum (O)
  • Listes de discussion , Site Web (P et ordre inverse pour O)
  • Wiki (P) ; FAQ (O)
  • FAQ (P) ; Nouvelles, annonces (O)
  • Gestion de tâches

Parmi les autres fonctionnalités données par les personnes ayant répondu à l'enquête, on peut extraire les points suivants :

  • Citations des publications concernant le projet
  • Tests de non régression et intégration continue
  • Outils d'automatisation de création de paquetage
  • Hébergement des documents produits par doxygen, javadoc …
  • Vérificateur de liens
  • Accès à une ferme de compilation et de tests avec différentes architectures (tests de portabilité)
  • Analyse de code
  • Mots-clé, tags

3.3 Besoins concernant les services

Le classement par ordre de préférence donne les résultats suivants concernant les besoins au niveau des services disponibles sur la forge :

  • Sauvegardes
  • Assistance aux porteurs de projets
  • Ouverture aux projets publics et privés

Parmi les autres fonctionnalités données par les personnes ayant répondu à l'enquête, on peut extraire les points suivants :

  • Simplicité d'utilisation
  • Plateforme permettant de mutualiser tout type de travaux scientifiques : données expérimentales, modèles, outils de calcul, pilotage d'expérience à distance, publications …
  • Pour les projets SHS notamment, outils de publication/transformation de sources encodées en xml

4. Conclusions et propositions

L'enquête réalisée dans le cadre du projet « Forge ESR » de Plume a permis d'identifier les pratiques et besoins des membres de la communauté Enseignement Supérieur et Recherche dans le domaine de l'hébergement des développements logiciel des laboratoires.

La première partie de cette analyse montre que le profil des personnes ayant répondu à cette enquête reflète bien la diversité des cadres de travail, des activités et des types de développement du milieu de la recherche académique.

Les pratiques actuelles se résument essentiellement à une pratique intensive des outils de gestion de version, en particulier subversion, et à une utilisation courante d'outils de génération de documentation.
Cependant, il semble que l'usage d'autres types d'outils soit plus confidentiel.
Un aspect important est le fait que la plupart des outils pratiqués sont installés de façon locale à la structure d'appartenance du développeur.

Les forges existantes sont globalement peu utilisées, mais les besoins exprimés sont importants.

D'une façon globale :

  • les forges sont souvent vues comme des "usines à gaz" manquant de simplicité,
  • l'aspect visibilité est un point important de l'intérêt d'une forge,
  • la proximité géographique ou thématique est un critère essentiel dans le choix de l'outil d'hébergement.

Il semble donc nécessaire :

  • d'accompagner les développeurs vers l'utilisation des forges,
  • de respecter le critère de proximité pour les hébergements,
  • de s'assurer que les hébergements existants ou à venir proposent les outils répondant aux besoins exprimés dans cette enquête.

Dans ce but, nous suggérons un certain nombre de propositions afin d'améliorer l'environnement de travail des personnes qui développent des logiciels dans les laboratoires de recherche, d'augmenter la visibilité de ces développements et d'encourager les relations entre ces personnes.

Proposition 1

Réfléchir et développer un argumentaire fort pour promouvoir l'usage des outils collaboratifs comme les forges logicielles. Cette réflexion pourrait se réaliser dans le cadre d'un groupe de travail du réseau DevLog en lien avec le groupe Calcul et le projet Plume.

Proposition 2

Favoriser et encourager tout type de formation liée à l'usage des outils de développement collaboratifs et des forges en particulier. Ces formations ont vocation à être proposées dans le cadre des réseaux métiers, mais aussi par les services de formation permanente des établissements.

Proposition 3

Élaborer un scénario pour répondre aux besoins exprimés lors de l'enquête concernant la mise à disposition d'outils à vocation nationale.

Différents scénarios peuvent être proposés :

  1. Scénario 1 : Mise en œuvre d'une forge nationale pour la communauté « Enseignement Supérieur et Recherche »

    Les forges nationales existantes imposent des contraintes d'utilisation qui ne sont pas toujours compatibles avec les besoins des utilisateurs, notamment en terme d'hébergement de projets privés. Une des possibilités serait donc de proposer une forge nationale levant cette contrainte, et dont les outils constituants pourraient répondre aux besoins exprimés dans l'enquête.

    L'intérêt principal de ce scénario est de coller réellement aux besoins des développeurs.

    Cependant, il y a un certain nombre d'inconvénients :

    • ce scénario ne prend pas du tout en compte l'existant et notamment le grand nombre de petites forges de laboratoires ou de services qui ont déjà été déployées,
    • l'hébergement d'une telle forge suppose un consensus entre les différents établissements de recherche concernés (CNRS, Universités…), de même que la répartition entre ces entités des financements et la mise à disposition de ressources (moyens humains et matériels).
  2. Scénario 2 : Référencement et informations autour des forges existantes

    L'enquête a montré qu'il existait un nombre non négligeable de forges déjà installées dans certaines structures en plus des forges référencées dans la FAQ-Forge de PLUME

    Ce deuxième scénario consiste à recenser et référencer toutes les forges existantes afin que les développeurs soient informés des outils disponibles, de leurs potentialités et des contraintes d'utilisation associées.

    • L'avantage principal de cette solution est l'utilisation de l'existant et une mise en œuvre simplifiée, l'hébergement de ce référencement pouvant se faire sur un serveur comme Plume.
    • L'inconvénient est de ne pas proposer d'alternatives à l'existant, notamment pour les personnes n'appartenant pas aux structures proposant un hébergement ou ayant des contraintes de confidentialité pour leur projet.
  3. Scénario 3 : Création d'un portail de forges et accompagnement pour la mise en place d'outils d'établissement ou de service

    Ce dernier scénario consiste comme le précédent à recenser sur un même portail l'ensemble des forges des différentes structures existantes pour faciliter leur accès . Il va plus loin dans le sens où il serait proposé un accompagnement spécifique pour la mise en place de forges dans les entités intéressées, le partage d'expérience, la mise en commun d'informations…

    Les principaux avantages de ce scénario sont donc :

    • La prise en compte de l'existant tout en permettant une ouverture vers de nouveaux outils et services. La mutualisation des expériences et des informations faciliterait l'émergence de nouveaux hébergements.
    • Le fait de conserver l'existant permettrait aussi de préserver la visibilité, l'autonomie et l'indépendance des établissements et laboratoires en terme de développement logiciel.
    • Cette mutualisation faciliterait également l'organisation de formations.
    • Enfin, les moyens humains et financiers nécessaires seraient moindre par rapport au premier scénario.

Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités - septembre 2010

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

Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités - septembre 2010

Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités

Jean-Luc Archimbaud (Animateur du projet PLUME)
Geneviève Romier (Responsable du Comité Technique PLUME)

Ce document dresse un bilan du projet et de la plateforme PLUME en tant que service après trois ans de production. Un autre document présentera les évolutions et l'organisation envisagées à partir de ce bilan. Vous pouvez aussi imprimer une version PDF, sans liens HTML.

Le projet PLUME (http://www.projet-plume.org), Promouvoir les Logiciels Utiles Maîtrisés et Economiques dans l'Enseignement Supérieur et la Recherche, lancé en 2007, met en œuvre un outil stratégique pour l'efficacité des laboratoires et services des universités et organismes de recherche. Cet outil, une plate-forme web qui propose aujourd'hui 760 fiches, sert de support à une réelle production d'informations : 568 descriptions de logiciels utilisés ou développés dans les laboratoires, descriptions rédigées et relues par 610 contributeurs et 184 fiches ressources (cours, articles...). 185 nouvelles fiches sont en cours de rédaction ou de relecture. La progression annuelle en terme de production, contribution et accès est de l'ordre de 60 %. Des journées thématiques, écoles et autres actions de formation et d'animation de la communauté complètent ce dispositif.

Cette dynamique de progression a conduit PLUME à devenir la principale plate-forme de description et de référencement des logiciels métier utilisés ou produits dans les laboratoires de recherche et les universités, à la fois base de connaissances en appui aux scientifiques et outil de valorisation du patrimoine logiciel. Elle assure à la communauté enseignement supérieur et recherche une économie de moyens en fournissant un service mutualisé et pluridisciplinaire aux informaticiens, chercheurs et enseignants des laboratoires de recherche et universités qui recherchent un logiciel validé par leurs pairs pour supporter leurs activités scientifiques et techniques. Son rayonnement, au-delà de la communauté enseignement supérieur recherche, et la qualité du contenu proposé en font une vitrine reconnue des développements internes pour les directions et services de valorisation des laboratoires, instituts, universités, organismes de recherche.

Les paragraphes suivants décrivent plus en détails les objectifs, les services rendus, la production actuelle, et l'organisation.

Les objectifs

Le projet PLUME, Promouvoir les Logiciels Utiles Maîtrisés et Economiques dans l'Enseignement Supérieur et la Recherche, a pour objectifs principaux de :

  • mutualiser les compétences sur les logiciels, la plupart libres, utilisés ou créés dans les laboratoires et les universités créant ainsi une économie de moyens,

  • valoriser les développements logiciels effectués dans les laboratoires quelle que soit la discipline scientifique.

Ces objectifs sont poursuivis en s'appuyant sur une plate-forme web (http://www.projet-plume.org/) ouverte en octobre 2007 sur laquelle sont publiées actuellement 568 fiches descriptives de logiciels. Ces descriptions sont rédigées par des utilisateurs intensifs (logiciels validés)ou des développeurs du logiciel présenté, puis suivent un processus similaire à la publication scientifique (relecture par des personnes du domaine, indexation, bon à publier). Ceci est possible grâce à une organisation humaine répartie.

Les services rendus aux laboratoires de recherche et aux universités

PLUME offre maintenant un service pour :

  • les informaticiens (ou utilisateurs éclairés de l'informatique) des laboratoires et universités qui doivent choisir, installer, utiliser des logiciels pour le travail de recherche, d'enseignement et de services. C'est un catalogue actualisé de logiciels validés par des personnes de l'Enseignement Supérieur et la Recherche. A ce catalogue s'ajoutent des journées de formation thématiques dont les présentations enregistrées sont disponibles sur le site PLUME ainsi que des écoles thématiques.

  • les chercheurs et enseignants de toutes les disciplines qui veulent faire connaître leurs développements logiciel, lier des contacts avec leurs homologues pour partager leurs idées, leurs codes ou démarcher des entreprises pour initier des collaborations : PLUME est un filtre et une référence pour présenter, indexer, valider la production des développements logiciels.

  • les directions de laboratoires qui peuvent ainsi référencer et valoriser la production logicielle de leur laboratoire ; il en est de même, avec le même objectif, pour chaque institut du CNRS ou service de valorisation d'université ou d'organisme de recherche comme le CNRS. Par exemple, la DPI, Direction de la Politique Industrielle, devenue DIRE du CNRS soutient fortement ce projet. PLUME est une vitrine pour le patrimoine logiciel des laboratoires maintenant reconnue des professionnels du logiciel, et son rayonnement s'étend au-delà de la recherche publique et au-delà du territoire national. PLUME est très bien référencé par les moteurs de recherche comme Google (une recherche de 'plume' dans ce moteur de recherche place le projet en premier site proposé).

En focalisant les compétences du domaine, avec finalement une économie de moyens notable, PLUME peut être désormais considérée comme la plate-forme de description et de référencement des logiciels métier utilisés ou produits dans les laboratoires de recherche, à la fois base de connaissance stratégique pour l'efficacité dans les laboratoires et vitrine reconnue des acteurs du secteur.

L'ouverture vers l'international

La plate-forme est à la base en français. Cependant un portail en anglais est en place destiné à la valorisation des développements des laboratoires avec une cinquantaine de fiches présentées. Des contacts ont été pris avec d'autres pays pour des référencements croisés... Ce portail anglophone est, faute de moyens, actuellement insuffisant à notre avis. Il constitue un des axes prioritaires d'évolution.

La production et les contributeurs

Mi-septembre 2010 sont présentés sur la plate-forme :

Ces descriptions de logiciels ou de ressources liées aux logiciels sont publiées sous forme de fiches avec des champs imposés et des mots-clés permettant la recherche.

Les fiches PLUME sont des documents rédigés spécifiquement pour PLUME. Elles constituent donc une réelle production d'information importante reposant sur l'expérience utilisateur du rédacteur sur la mise en oeuvre du logiciel dans nos environnements et pas simplement un référencement d'informations existantes ou un assemblage de copier-coller comme de nombreux serveurs le font.

Les fiches sont rédigées par des utilisateurs très réguliers ou des développeurs du logiciel présenté, après proposition spontanée de leur part, même si un des rôles des responsables thématiques est de favoriser cette spontanéité. Ces contributeurs sont des chercheurs, enseignants-chercheurs, ingénieurs de laboratoires CNRS mais aussi INRA, INRIA, CEA,... et des universités et grandes écoles. Il y a actuellement 610 contributeurs (rédacteurs ou relecteurs).

Après la saisie, les fiches suivent un processus similaire à la publication scientifique : relecture et ajouts par
des personnes compétentes du domaine, indexation, bon à publier de l'auteur... S'ajoute une mise à jour régulière des fiches qui est demandée aux auteurs, avec un archivage des fiches non mises à jour.

Chaque fiche est rattachée à un ou plusieurs thèmes (activité scientifique/métier : biologie, formation, développeur...) géré par des responsables thématiques (cf ci-dessous l'organisation).

La formation et l'animation de la communauté Enseignement Supérieur - Recherche

En parallèle, des journées thématiques sont organisées à raison actuellement de deux-trois par an. Chaque journée a réuni entre 80 et 100 personnes en présentiel, au moins 50 à distance (les journées sont retransmises sur Internet) avec enregistrement et mise en ligne des vidéos. Les intervenants sont les contributeurs qui ont rédigé ou relu les fiches descriptives des logiciels présentés. Les thèmes traités ont été :

La prochaine journée est prévue à Paris, le 22 novembre 2010, sur le thème 'Les outils libres de base utiles à tout ASR', ASR pour Administrateur Système et Réseau.

Deux écoles thématiques (une semaine, 80 participants développeurs dans des laboratoires), ANGD dans le jargon CNRS, ont été organisées en septembre 2008 et 2010, appelées ENVOL : formation pour le dEveloppemeNt et la ValOrisation des Logiciels en environnement de recherche.

L'organisation

La plate-forme matérielle consiste en deux serveurs ordinaires hébergés au Centre de Calcul de l'IN2P3 de Lyon, dans de très bonnes conditions : très bons débit réseau, sauvegarde, climatisation, surveillance 24h/24... Ce centre de calcul est partenaire PLUME.

Le personnel noyau dur PLUME est constitué de :

  • Geneviève Romier, ingénieur permanent CNRS, responsable du comité d'exploitation de la plate-forme et co-responsable du comité technique PLUME qui regroupe les responsables thématiques (cf ci-dessous).

  • Jean-Luc Archimbaud, ingénieur permanent CNRS, directeur du projet et rédacteur en chef.

  • Teresa Gomez Diaz, ingénieur permanent CNRS du laboratoire LIGM, avec une convention pour qu'elle travaille à 70 % dans PLUME, en charge de la partie valorisation des logiciels de laboratoires.

  • Laurent Pasquali, ingénieur CDD valorisation jusqu'en mars 2011, sur un poste affecté à PLUME par la DPI du CNRS (devenu DIRE, Direction Innovation et Relations avec les Entreprises), sur la présentation des logiciels de laboratoires dans PLUME.

Un poste d'ingénieur en informatique et un autre d'assistant-gestionnaire-communication ont été demandés au CNRS pour 2011.

25 responsables thématiques assurent le rôle de référent pour certains thèmes. Ils acceptent les propositions de fiches, sollicitent certaines contributions, relisent, valident les fiches et coordonnent leur mise à jour. Un thème est un domaine scientifique, un domaine informatique ou un métier. Les thèmes couverts actuellement par des responsables thématiques sont : biologie, maths, chimie, documentation-IST, développement, administration système, formation, informatique personnelle, patrimoine logiciel de laboratoire, travail coopératif, sciences humaines et sociales, sécurité des systèmes d'information. Astronomie, physique, SI de laboratoire sont des thèmes sur les rails. Ces responsables thématiques sont généralement des ingénieurs en informatique qui consacrent 10 à 15 % de leur temps à PLUME. Ils travaillent dans un laboratoire ou une université dans la thématique qu'ils ont en charge et donc connaissent les logiciels, les besoins et les autres laboratoires du domaine qu'ils couvrent.

Le noyau dur et les responsables thématiques constituent l'équipe PLUME.

Pour terminer 290 personnes ont déjà rédigé des fiches PLUME et 320 en ont relu. Ces 610 contributeurs apportent leur connaissance et leur compétence au projet chacun dans le domaine de sa pratique professionnelle.

La valeur ajoutée et le retour sur investissement

Le retour sur investissement est difficile à évaluer. Quel gain de temps pour un informaticien qui trouve immédiatement dans PLUME le logiciel utile pour son travail parce qu'il a été décrit par des collègues d'autres laboratoires, par rapport à une recherche à l'aveugle sur Internet, suivie de tests plus ou moins concluants ? Quel impact pour un chercheur et par extension un laboratoire qui décrit ses développements logiciels dans PLUME ? Combien de personnes bénéficient des informations disponibles dans PLUME ? Cependant, l'impact et la portée du service rendu peuvent être évalués à travers certains éléments factuels comme la participation, la pluridisciplinarité, la production, la consultation du site, la notoriété et les partenariats-soutiens :

  • Participation : 1400 membres PLUME sont inscrits sur le site, 610 contributeurs (+ 67 % en un an) : rédacteurs ou relecteurs des fiches. La forte participation et son évolution montre l'intérêt.

  • Pluridisciplinarité : une douzaine de thèmes principaux qui couvrent plusieurs disciplines scientifiques, d'autres étant en cours de création.

  • Production : en un an (août 2009 - août 2010) le nombre de fiches publiées est passé de 440 à 760 (+ 72 %). Environ 180 fiches sont en cours de rédaction ou de relecture (non encore publiées).

  • Consultation du site : l'accès mensuel en juin 2010 a été de 200 000 pages lues et 1 360 000 hits (+ 50 % en un an). Ce nombre a baissé durant juillet-août , vacances obligent.

  • Notoriété : les membres de l'équipe PLUME sont de plus en plus sollicités pour présenter PLUME et ses productions dans des conférences (une quarantaine dans la dernière année), certaines internationales.

  • Partenariats et soutiens : De nombreux laboratoires, universités et entités liées à la recherche soutiennent officiellement le projet (cf ci-dessous). La DIRE (Direction Innovation et Relations avec les Entreprises) du CNRS, a ainsi attribué un ingénieur valorisation d'un an au projet en 2010.

Le pilotage et les entités soutiens-partenaires

Le projet a été initié par l'UREC en 2007, Unité Propre de Service (UPS) du CNRS et a été porté par le CNRS à travers l'UREC. Cette unité a été intégrée dans la DSI du CNRS en juillet 2010. Le projet continue, toujours soutenu par le CNRS.

Mais la portée de PLUME s'étend à un ensemble large de l'enseignement supérieur et de la recherche qui participe et bénéficie des services de PLUME. Ainsi il est soutenu officiellement par 45 soutiens-partenaires :

  • des laboratoires importants (CC-IN2P3, LAAS, INIST, ICJ, LIGM, LAL...)

  • des universités ou grandes écoles (INSA Lyon, association des DSI des universités...)

  • des instituts ou services du CNRS (INSMI, DIRE, DGD-R...)

  • des services d'organismes de recherche (ESRF, INRA, INRIA, IRD...)

  • des structures transverses (RENATER, MRCT réseaux métiers CNRS...)

  • des structures industrielles (OW2, System@tic...)

Ces soutiens se sont manifestés progressivement selon les collaborations. Plusieurs d'entre eux ont été force de proposition et le service est devenu stratégique pour leur activité. Deux structures de pilotage sont en place : un comité de suivi et d'orientation avec les membres de l'équipe PLUME parmi les plus impliqués et un comité stratégique récemment créé qui regroupe dix directeurs des entités soutiens et partenaires. Une réflexion est en cours pour monter une structure pérenne, représentative et ouverte pour le service PLUME, et sera présentée dans un  autre document.

 

 

Webinaire : description et outils

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

Webinaire : description et outils

  • Type de ressource : article
  • Date de publication du document ou de l'événement : Sept 2010
  • Auteur(s) ou responsable(s) :

    Hassan Hassan (CNRS/UREC)

Description

La diffusion de séminaires ou de conférences en direct sur le web s’est largement répandue ces dernières années. En effet, la diffusion sur le web permet d’atteindre une audience plus large. De plus, l’enregistrement de ces évènements comme documents audiovisuels permet de les visionner en mode différé.

Toutefois, la diffusion en directe ou en différé sur le web a dépassé récemment le cadre des séminaires ou des conférences classiques. Aujourd'hui beaucoup de séminaires ont lieu uniquement sur le web, donnant naissance à un autre type d'évènements : les webinaires (en anglais webinars).

Un webinaire est donc un séminaire diffusé uniquement sur le web. L’organisation d’un webinaire demande beaucoup moins de ressources qu’un séminaire classique, ce qui explique le succès des webinaires pour diffuser de l'information dans tous les domaines : scientifique, commercial...

Organisation d'un webinaire

La diffusion sur le web uniquement offre plusieurs possibilités pour l'organisation d'un webinaire.

  • Les intervenants sont réunis dans un studio de diffusion, équipé de façon professionnelle.
    Ce type de webinaire s'apparente plus à des programmes télévisés diffusés en direct.  Même si ce type de webinaire reste plus facile à organiser qu’un séminaire classique, il présente un inconvénient. Il faut disposer d’un studio pour accueillir les intervenants et la participation d’un intervenant l’oblige à se déplacer au studio.
  • Les intervenants sont réunis dans une salle virtuelle.
    Beaucoup de logiciels (voire plus loin) offre la possibilité de réserver une salle virtuelle pour organiser un webinaire. Les intervenants, comme l’audience, peuvent se connecter à cette salle via le web. Ce type de webinaire offre un avantage indéniable : les intervenants peuvent participer depuis n’importe quel endroit. Il suffit que l’intervenant dispose d’une connexion Internet de bonne qualité, et bien sûr d'un système de captation d'image et de son correct (surtout le son, très souvent les webinaires n'ont pas de canal video en dehors de la retransmission des diapos). L’organisation d’un webinaire est ainsi largement facilité.

Une troisième possibilité consiste à combiner les deux modes précédents en studio et à distance, même si elle très peu utilisée en pratique.

Déroulement d'un webinaire

Avant de parler des outils qui permettent d'organiser un webinaire, nous allons passer en revue le mode de fonctionnement d'un webinaire. Ceci afin de mieux en comprendre les avantages.

Un webinaire comporte deux parties :

  • Présentations des intervenants.
  • Questions de l'audience.

Les questions de l'audience sont adressées en mode texte via le web. L'organisateur du webinaire se charge de la sélection des questions. Les questions sont posées à la fin de chaque présentation. 

L'interaction avec l'audience via le web offre une autre possibilité : questionner l'audience pendant la présentation. Ainsi, au cours d'une présentation, un intervenant peut inclure un sondage et solliciter l'audience pour avoir son avis en direct. Une évaluation de la pertinence du webinaire peut être également proposée à la fin de la session.

A la fin de la session, une analyse statistique des connexions au cours du webinaire permet de mieux connaître la réaction de l'audience aux sujets présentés. La durée moyenne des connexions,  la fluctuation du nombre de connexions, etc. sont des données importantes qui peuvent être croisées avec les présentations et les sujets abordés. Ce point est l’une des clefs qui explique le succès des webinaires dans les présentations commerciales. En effet, les industriels disposent avec les webinaires d'un outil redoutable pour analyser la façon dont leurs clients potentiels réagissent à leurs produits.

Les webinaires pour la communication scientifique

L'utilisation des webinaires commence à avoir du succès dans la communauté scientifique également. L'organisation des conférences et des workshops nécessite souvent des ressources importantes, et demande plusieurs mois de préparation. Tandis qu'avec les webinaires, un évènement peut être planifié en peu de temps. Dans une communauté où les avancés sont  importantes et rapides, les webinaires deviennent un outil de communication très efficace. Les scientifiques utilisent les webinaires pour organiser des sessions de travail ouvertes à une audience internationale.

Les outils pour organiser des webinaires

Il y a beaucoup d'outils pour organiser des webinaires. Si quelques outils existent depuis très longtemps pour organiser des sessions de travail privées, par exemple Webex et DimDim, d'autres ont été conçus pour les cours à distance, par exemple Moodle, tandis que d'autres ont été pensés pour faire de la visio sur le web comme EVO. Il est évident que n'importe quel outil qui permet de diffuser des présentations en temps réel sur le web avec un flux audio, et accessoirement vidéo, peut être utilisé pour organiser un webinaire. Toutefois, la grande différence entre ces outils réside dans le traitement des informations récoltées au cours d'un webinaire. Les industriels qui cherchent à sonder leurs clients sont plus sensibles aux outils de traitement statistique de l'information qui accompagnent les webinaires, car le but d'un webinaire est de mieux connaître les clients. Par contre, pour les scientifiques, l'accessibilité des outils et leur coût restent des facteurs déterminant pour le choix d'un outil. Voici quelques produits libres et propriétaires qui permettent d'organiser des webinaires. Cette liste n'est pas exhaustive.

  • Webex. Un outil propriétaire, leader mondial dans le webconferencing, récemment acquis par Cisco. Cet outil reste de loin le plus performant dans la diffusion sur le web et le traitement statistique des informations de connexions. Il existe des licences dégressives pour l'enseignement supérieur et la recherche, toutefois Webex reste un outil très onéreux. Il s'agit d'un service, Webex ne peut pas être hébergé au niveau client. http://www.webex.com.
  • DimDim. Disponible en version open source limitée à vingt participants, DimDim offre la possibilité d'organiser des webinaires professionnels jusqu'à mille participants dans sa version pro. Ses tarifs sont plus intéressants que ceux de Webex, toutefois les outils de traitement statistique de données ne sont pas aussi aboutis. Les outils de conduite de réunion par contre dépassent parfois ceux de Webex.http://www.dimdim.com et la fiche PLUME
  • Moodle. Cet outil a été conçu pour les cours à distance. Des webinaires peuvent être organisés avec Moodle via un plugin supplémentaire. Moodle est proposé en Open Source. Deux modes existent pour l’archivage des webinaires avec Moodle. Soit sur un serveur dédié proposé par Moodle orné de publicités commerciales, soit par l’installation d’un serveur Moodle personnel.
    Cette dernière solution, même si elle est intéressante pour la confidentialité des données, nécessite un investissement humain important. Une solution Webex ou DimDim payante reste beaucoup plus accessible en pratique. http ://www.moodle.com et la fiche PLUME
  • EVO. À la différence des outils précédemment cités, EVO ne propose pas d'interface web spécifique pour les webinaires. EVO est un outil pour la visioconférence à travers un client lourd installé automatiquement sur un poste de travail Linux, Windows ou MacOS X. EVO a été adapté pour la diffusion des présentations et peut servir pour l'organisation des webinaires. Toutefois, les outils de traitement statistique d'information qui accompagnent EVO sont très limités. EVO est soutenu par RENATER et largement utilisé pour les visioconférences dans la communauté recherche et enseignement supérieur. Comme Webex, c'est un service, il n'est pas hébergeable chez soi. http://evo.caltech.edu et la fiche PLUME
  • Encours.org : Proposé par un chercheur français, encours.org est un outil qui permet de travailler autour d’une présentation à distance. L’ambition d’encours.org est de proposer l’outil le plus simple possible pour permettre à un intervenant de faire une présentation devant une audience virtuelle à travers le web. Encours.org est un produit libre, simple, qui peut servir pour organiser des webinaires, mais sans post-traitement statistique des informations de connexions. A essayer et à enrichir.  http://www.encours.org/

Conclusion

Les webinaires fournissent un outil de communication moderne, très efficace, particulièrement utile dans le contexte de l'enseignement supérieur et la recherche. Les besoins des utilisateurs peuvent être très différents en fonction de l'objectif de la communication et l'audience visée. Quel que soit l'outil choisi pour organiser des webinaires, il faut privilégier la facilité d'utilisation. Le but reste de disposer d'un outil flexible, facile à utiliser pour une meilleure communication.

Billet d'un membre du projet Scenari : les apports de PLUME

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

Billet d'un membre du projet Scenari : les apports de PLUME

Le projet Scenari est un système de gestion de chaînes éditoriales (un ensemble de logiciels pour produire des documents), initié à l'Université de Technologie de Compiègne. Il compte une grande partie de ses utilisateurs pionniers et nouveaux dans l'enseignement supérieur. Il est référencé sur PLUME depuis fin 2008.

PLUME est un apport significatif :

  • Pour la visibilité du projet : PLUME offre des possibilités de recherche très riches, texte intégral ou basée sur de nombreux critères. Il se distingue des annuaires traditionnels de logiciels en offrant une véritable indexation des logiciels utiles, ce qui contribue à orienter les utilisateurs qui en ont besoin vers un projet tel que Scenari.
  • Pour la diffusion d'informations sur le projet : la fiche plume étant une vue synthétique des informations sur le logiciel, qu'il décide ou pas de l'utiliser, le lecteur de la fiche plume est amené à en apprendre sur son fonctionnement et ses concepts. C'est particulièrement important dans le cadre du projet Scenari, car les bonnes pratiques véhiculés par certaines chaînes éditoriales (séparation fond/forme, édition WYSIWYM, réutilisation sans duplication...) ne sont pas encore aussi populairement connu que ce que l'on pourrait imaginer, souvent par manque de diffusion de l'information.
  • Pour la crédibilité du projet : les critères pour que la fiche d'un logiciel soit active apportent de la crédibilité au projet et mettent en confiance l'utilisateur potentiel, avec 2 témoignages utilisateurs, des demandes de mises à jour régulières, et une validation finale avant publication.
  • Le suivi des fiches par l'équipe du projet PLUME permet de fluidifier la démarche d'ajout d'une fiche, d'éviter d'oublier une fiche restée en attente ou de trouver des réponses aux questions qu'un rédacteur de fiche peut se poser, quand elles ne sont pas déjà présentes dans des fiches d'aide. La réactivité de mes interlocuteurs PLUME a été exemplaire.

En résumé, PLUME n'est pas seulement un service rendu aux utilisateurs "visiteurs", mais aussi un réseau particulièrement bénéfique pour la diffusion des logiciels qu'il promeut.

Linux et les choses : site d'information sur l'emploi des logiciels libres dans la recherche et l'enseignement en sciences humaines

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 27/07/10
  • Correction mineure : 27/07/10
  • Auteur : Christophe Masutti (Institut de Recherches Interdisciplinaires sur les Sciences et la Technologie - Departement d'histoire des sciences de la vie et de la santé)
  • Responsable thématique : Maud Ingarao
Mots-clés

Linux et les choses : site d'information sur l'emploi des logiciels libres dans la recherche et l'enseignement en sciences humaines

Site web créé en 2006 par Christophe Masutti, chercheur, pour partager avec ses collègues et connaissances ses usages des logiciels libres et de GNU/Linux - en particulier dans le domaine des sciences humaines - Linux et les choses est une aventure éditoriale qui s'est inscrite dans la durée et compte aujourd'hui près de 200 pages et un millier de visiteurs mensuels. On y trouve des fiches de présentation de logiciels, de la documentation sur les logiciels libres et des articles de réflexion sur le libre et ses usages en sciences humaines et sociales.

Comme il est écrit dans son édito, le site est parti d'une réflexion sur les usages des logiciels en sciences :

Pourquoi produire des connaissances dont la finalité est d'être partagées, par des outils informatiques qui, eux, ne sont pas libres de l'être ?

Pourtant Linux et les choses ne prétend pas à l'exhaustivité. Les logiciels libres sont depuis fort longtemps connus dans différentes disciplines, y compris dans les sciences humaines. L'objectif est d'orienter les pratiques professionnelles qui n'ont pas encore saisi l'avantage des logiciels libres, en termes de coût, d'intégration et d'efficacité. L'accent est mis plus particulièrement sur les outils d'écriture et de communication.

S'adressant à l'utilisateur, et partant de l'expérience personnelle de l'auteur, le site propose des notices courtes sur des logiciels libres et renvoie systématiquement le lecteur au site officiel et aux articles déjà présents sur Internet. Linux et les choses agit donc à la fois comme un signalement et comme une veille stratégique. On notera de même la présence d'un modèle de thèse en sciences humaines au format LaTeX, nommé Bredele, ainsi que plusieurs notices plus complètes que les autres selon le degré de leur utilisation par l'auteur (par exemple: un fiche sur Mutt, ou encore cette longue liste de logiciels de gestion bibliographique libres).

Syndiquer le contenu