Ce document liste les principales étapes et réalisations du projet et de la plate-forme PLUME, par ordre chronologique, depuis août 2013.

Les actions et réalisations précédentes se trouvent :

• de la création en 2006 jusqu'au départ de Jean-Luc Archimbaud, en mai 2012, dans ce document,
• de juin 2012 à juillet 2013 (suite à l'évolution du comité de direction) dans ce document.

2013

• Août :
  - (été 2013) "tour de France téléphonique" de l'équipe PLUME fait par David Rousse, suite à l'évolution du comité de direction,
  - temps de travail de David Rousse diminué sur PLUME (d'un équivalent temps plein 80% à un équivalent temps plein 50%).
• Septembre :
  - participation aux JDEV 2013,
  - (ré) intégration de C. Caron comme co-responsable du thème biologie,
  - intégration de L. Pérochon comme membre du comité de suivi et d'orientation.

Depuis 2016

Les années suivantes sont ici

Que faut-il surveiller ?

Surveiller une application peut vouloir dire plusieurs choses selon les besoins et le contexte de l'application. Par exemple, une application contrôlant un élément d'un accélérateur de particules ne sera pas surveillée de la même manière qu'une application chargée d'envoyer un mail dès qu'une page d'un wiki est modifiée.

La surveillance peut être technique (est-ce que mon application fonctionne correctement, est-ce que les performances sont acceptables, combien y a-t-il d'utilisateurs en ce moment) ou fonctionnelle (combien de factures ont été traitées ce mois-ci, pour quel montant).

Quels outils pour surveiller ?

Les outils de surveillance d'une application Java peuvent se diviser en deux catégories : les outils fournissant des données instantanées, et les outils permettant de conserver un historique des données, certains outils fournissant les deux.

Beaucoup d'outils utilisent la fonctionnalité JMX, qui permet d'exposer des informations via des MBeans.

Logs

La mise en place de logs est le minimum à faire dès lors que l'on souhaite surveiller une application.

La solution la plus basique est d'utiliser la méthode System.out.println pour écrire les lignes de logs dans la console. Le problème avec cette solution est qu'elle n'est pas évolutive : on ne peut pas choisir les niveaux de logs, ni quels composants logger.

C'est pour cela que l'on utilise un cadriciel (framework) de log. Les plus courants sont les suivants :

• JUL (java.util.logging) : c'est le framework de logs implémenté dans la JVM. Il n'est pas beaucoup utilisé, car il n'a été introduit dans Java qu'à partir de la version 1.4.
• Apache Log4J : c'est l'un des framework de logs les plus utilisés.
• Logback : c'est un framework écrit par l'auteur de Log4j, qui apporte des améliorations par rapport à ce dernier.
• Apache Commons Logging et SLF4J : ce sont des façades permettant de choisir l'implémentation de logs. L'utilisation de façade est utile car dans un projet Java utilisant plusieurs librairies tierces, chacune peut utiliser un framework de logs différent. La façade permet d'unifier cela.

Les avantages à utiliser un framework de logs sont les suivants :

• Pouvoir choisir le niveau de logs à logger.
• Pouvoir choisir, composant par composant, quel est le niveau de logs.
• Les données loggées ont ainsi des priorités différentes.
• Possibilité d'utiliser des destinations différentes pour les logs (fichiers, base de données, JMS, etc).

Avoir une librairie de logs ne suffit pas pour pouvoir surveiller efficacement son application Java. Le choix de ce qu'il faut logger est très important. Il n'en faut pas trop pour ne pas noyer les informations importantes, ni trop peu pour en avoir assez.

Il peut être intéressant d'avoir plusieurs destinations de fichiers de logs, selon les besoins :

• un fichier full qui contient tous les logs,
• un fichier securité contenant les logs relatifs à la sécurité (tentatives de connexions, actions sensibles, etc.),
• un fichier audit pour pouvoir tracer les événements qui surviennent dans l'application.

Il est intéressant de noter que la destination des logs peut être autre chose que des fichiers, et qu'un même message de logs peut être envoyé vers plusieurs destinations. La plupart des librairies de logs permettent d'envoyer les logs en base de données, sur une file d'attente JMS, sur une socket, par mail ou encore sur le système de log Linux syslog. Cependant, il faut en général toujours envoyer les logs critiques au moins dans un fichier, pour être sûr qu'ils soient disponibles (une base de données peut ne pas être montée, le broker JMS peut être saturé, etc.).

L'utilisation de logs permet de surveiller ce qui se passe en temps quasi réel, mais aussi d'accéder à l'historique.

JMX

http://fr.wikipedia.org/wiki/JMX

JMX est une spécification Java permettant d'exposer des MBeans présents dans la JVM. Un MBean est simplement une classe Java exposant des getters et des méthodes.

Cela permet par exemple d'accéder à des attributs de la JVM tels que le temps total de compilation. On peut également appeler des méthodes.

Il est donc possible d'ajouter dans notre programme Java des MBeans afin de les exposer via JMX. Cela permet de remonter des valeurs, ou d'appeler des méthodes de notre programme. Par exemple, Tomcat expose les MBeans User, Role, mais aussi le nombre de requêtes pour chaque servlet. On peut également stopper un port donné, expirer une session, etc.

Utiliser JMX dans une application Java permet donc facilement, avec les outils adéquats, d'interagir avec l'application et de surveiller ce qui se passe dans la JVM, aussi bien au niveau technique qu'au niveau fonctionnel (il suffit d'écrire les MBeans correspondant).

La plupart des outils suivants se basent sur JMX pour remonter les informations.

JConsole

http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html

JConsole est présent dans le JDK. C'est une interface graphique affichant des graphes décrivant le fonctionnement de la JVM. On y trouve par exemple un graphe affichant la mémoire Heap utilisée, le nombre de threads actifs, ou encore le pourcentage d'utilisation du CPU.

JConsole permet également de consulter les MBeans exposés par la JVM.

JConsole permet de se connecter à une JVM locale, mais également à une JVM distante (il faut effectuer une configuration au niveau de la JVM distante).

Dans le cas où le réseau bloque les ports empêchant JConsole de se connecter à une JVM distante, il est possible d'utiliser un tunnel SSH. Pour cela, on peut utiliser PuTTY :

• Aller dans la section Connection/SSH/Tunnels, puis dans Add new forwarded port, renseigner un numéro de port quelconque dans Source port (ce sera le port du proxy SOCKS), puis sélectionner Dynamic.
• Cliquer sur Add. Dans le tableau au dessus, une ligne doit s'ajouter avec le numéro de port préfixé par la lettre D.
• Se connecter au serveur distant en SSH avec PuTTY.

• Lancer JConsole avec la commande suivante : jconsole.exe -J-DsocksProxyHost=localhost -J-DsocksProxyPort=10000 (avec 10000 le port renseigné dans PuTTY).

JConsole permet de voir ce qui se passe à un instant donné dans l'application, mais ne permet pas de consulter l'historique. JConsole ne conserve que l'historique depuis son démarrage.

JVisualVM

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jvisualvm.html

JVisualVM est également présent dans le JDK. Il reprend les fonctionnalités de JConsole sur l'affichage de graphes sur les mesures internes de la JVM.

JVisualVM ne permet pas de base d'accéder aux MBeans de la JVM. Cependant, il a un mécanisme de plugins qui permet de rajouter un onglet MBeans (VisualVM-MBeans) offrant les mêmes fonctionnalités que JConsole.

De plus, d'autres plugins sont intéressants :

• Visual GC : affichage précis des différents pools de mémoire de la JVM, ainsi que les temps utilisés par le Garbage Collector.
• Tracer-JVM Probes : sondes permettant d'afficher des graphes sur des comportements internes de la JVM (utilisation des Collections, les buffers NIO, etc.).

JVisualVM permet de se connecter à une JVM locale, mais également à une JVM distante (il faut effectuer la même configuration au niveau de la JVM distante que pour JConsole).

Dans le cas où le réseau bloque les ports empêchant JVisualVM de se connecter à une JVM distante, il est possible d'utiliser un tunnel SSH de la même manière que pour JConsole. Il suffit, après avoir activé le proxy SOCKS, d'aller dans JVisualVM dans le menu Tools > Options > Network (proxy SOCKS).

JVisualVM permet de voir ce qui se passe à un instant donné dans l'application, mais ne permet pas de consulter l'historique. JVisualVM ne conserve que l'historique depuis son démarrage.

JMX Term

http://wiki.cyclopsgroup.org/jmxterm

C'est un outil en ligne de commande permettant d'accéder aux MBeans. L'avantage c'est que l'on peut l'utiliser même si on n'a pas d'interface graphique (sur un serveur Linux sans X11 par exemple). Il est fourni sous forme d'un Jar exécutable.

Une fois le Jar lancé, on se connecte à une JVM locale, puis on navigue dans les domaines et les MBeans, pour enfin afficher les valeurs, les renseigner, ou appeler des méthodes.

JMX Term offre également la possibilité d'être utilisé via des outils de scripts, tels que Perl ou un shell. Voici par exemple un extrait du site de JMX Term :

open JMX, "| java -jar $jar -n";

 print JMX "help \n";

 my $host = "localhost";

 my $port = 9991;

 print JMX "open $host:$port\n";

 print JMX "domains\n";

 print JMX "close\n";

 close JMX;

JMX Term ne conserve pas d'historique.

jmxtrans

https://github.com/jmxtrans/jmxtrans

Cet outil a pour objectif d'extraire des informations de différentes JVMs, puis de les envoyer vers d'autres outils pour leur traitement. Il a pour vocation d'être performant avec un grand nombre de JVMs à analyser.

Il fonctionne en tâche de fond. Une fois lancé, il lit des fichiers de configuration écrits en JSON ou YAML, dans lesquels sont décrits les serveurs à analyser, le port JMX, les objets MBeans à interroger, et la façon dont envoyer les données des MBeans.

Par exemple, il est possible de lui demander d'interroger le MBean java.lang:type=OperatingSystem, et de récupérer les valeurs des attributs SystemLoadAverage et FreePhysicalMemorySize, puis d'envoyer ces valeurs dans un fichier texte.

La façon dont JMXTrans traite les données récupérées se fait par la notion de Writer. Il existe des Writers pour écrire les données sur la console, dans un fichier texte, mais aussi vers Graphite (outil web de visualisation de données), ou encore vers des fichiers de type RRD (utilisés entre autre par Nagios, Cacti).

JMXTrans permet donc de surveiller un ensemble de JVMs (sur des attributs de notre choix), et d'envoyer ces données à d'autres outils pour affichage ou analyse.

Par sa nature, JMXTrans permet de conserver l'historique : il tourne en tâche de fond, et les Writers accumulent les données reçues. C'est à la charge des outils externes (Graphite, Nagios, etc.) d'afficher ces données historisées.

Jolokia

http://www.jolokia.org/

Cet outil permet de récupérer les données des attributs de MBeans par des services web REST. Il se greffe dans une JVM et est ensuite interrogeable par une URL, dans laquelle on indique les MBeans à interroger (pour récupérer des valeurs d'attributs, ou appeler des méthodes). Le format retourné par l'URL est du JSON.

La façon d'intégrer Jolokia dans une JVM peut se faire de différente manière : via un war à mettre dans Tomcat, un bundle OSGi, ou un agent Java (spécifié dans la commande java lançant l'application).

Jolokia permet donc de faciliter l'interrogation d'une JVM pour obtenir des données sur son fonctionnement. Il est ensuite facile d'utiliser un autre outil tel que Nagios pour automatiser la récupération d'informations via Jolokia.

Jolokia fournit un instantané de ce qui se passe dans la JVM, c'est à la charge des outils qui l'utilisent d'historiser les données.

HawtIO

http://hawt.io/

C'est une webapp déployable sous un conteneur de servlet (Tomcat par exemple), qui permet de se connecter à une JVM locale ou distante (la connexion à une JVM distante se fait en utilisant Jolokia - Jolokia doit donc être installé sur la JVM distante).

HawtIO met à disposition une interface web permettant de consulter les données exposées (par JMX ou Jolokia) d'une JVM. Il est possible de consulter les données, mais également d'afficher des graphes pour des données numériques.

Ce projet est en plein développement, mais semble prometteur. Il a un système de plugin permettant d'afficher des vues spécifiques selon les frameworks utilisés dans la JVM. Par exemple, s'il détecte qu'il y a le broker ActiveMQ, alors il va rajouter un onglet spécifique facilitant la consultation des données du Broker. De même, si Tomcat est détecté, alors un onglet dédié permettra d'arrêter des applications, de voir les sessions, etc.

HawtIO permet de grapher les données numériques, mais l'historique se limite à la durée de connexion à HawtIO.

YourKit & JProfiler

http://www.yourkit.com/

http://www.ej-technologies.com/products/jprofiler/overview.html

Ces deux outils permettent, comme JConsole et VisualVM, de se connecter à une JVM locale et distante, et d'afficher des informations sur cette JVM.

La force de ces outils est de proposer des méthodes pour détecter ce qui consomme le plus de ressources dans le programme.

Notamment, la détection de fuites mémoire est grandement facilitée avec ces outils, qui montrent le nombre d'instances de chaque objet, et quels sont les objets qui gardent une référence sur ceux-ci, empêchant le garbage collector de les supprimer.

Eclipse MAT

http://www.eclipse.org/mat/

Cet outil est assez similaire dans les objectifs à YourKit et JProfiler, mais il fonctionne sur un Heap Dump. C'est à dire que son utilisation est plutôt post mortem.

Cette page explique comment générer un Heap Dump sur une application existante, et quels paramètres fournir à Java pour qu'il génère automatiquement un Heap Dump en cas de OutOfMemoryError. Cela permettra d'analyser a posteriori les causes d'une fuite mémoire sur un système en production.

Apache JMeter & Gatling

http://jmeter.apache.org/

http://gatling-tool.org/

Ce sont des outil de tests de performance, permettant de tester la résistance d'applications sous différents cas d'utilisation. Les tests de performances peuvent être de différents types, par exemple : tests de charge, tests de stress, tests d'endurance, etc. Cette page explique les différents types de tests.

Ils ne permettent pas d'analyser directement le fonctionnement d'une JVM (ni en cours de fonctionnement, ni à partir d'un Heap Dump), mais ils permettent de s'assurer que notre application (Java ou autre) réponde bien à différents scénarios. Ils produisent par contre des rapports et des graphiques permettant de s'assurer que notre application répondra correctement dans ces cas d'utilisation.

Description courte :

OpenSearch est une spécification qui offre des services de recherche sur un site Internet et ce, indépendamment de la technologie du moteur de recherche utilisé par ce site. L'objectif est de proposer un standard pour la recherche et la publication sur Internet.

Avec cette technologie, il est ainsi possible d'agréger et d'afficher les résultats de plusieurs sites de recherche différents. On peut par exemple effectuer la même requête sur une base de données documentaire, un dictionnaire en ligne et un wiki, et afficher les résultats sur une même page.

Il est également possible de rajouter son moteur de recherche sur n'importe quel client de recherche qui contient un agrégateur OpenSearch (dans lequel on peut configurer son fichier de description OpenSearch). L'un des exemples d'utilisation les plus connus de cette technologie est l'intégration de listes de sites de recherche dans les navigateurs web (champ de recherche situé à droite de la barre d'URL sur Firefox et Internet Explorer).

Documents de standardisation : La dernière spécification se trouve ici : OpenSearch 1.1 (Draft 5)

Description détaillée :

OpenSearch ne remplace pas un moteur de recherche mais propose donc une surcouche afin d'uniformiser les formats de publication. En ce sens, on peut apparenter cette technologie à un « service web » pour la recherche sur Internet.

Techniquement, OpenSearch utilise XML et les flux de syndication (RSS ou Atom).

Pour pouvoir offrir tous les composants nécessaires à la recherche standardisée sur Internet, la spécification OpenSearch est composée de quatre formats complémentaires :

• OpenSearch description document

  C'est un fichier XML qui identifie et décrit le moteur de recherche. En plus de l'adresse du namespace de la spécification «http://a9.com/-/spec/opensearch/1.1/», ce fichier doit contenir au moins les 3 balises obligatoires suivantes : ShortName pour le nom du service, Description pour sa description et Url qui contient l'adresse du site de recherche.

• OpenSearch URL template syntax

  Ce format contient différents paramètres qui permettent de décrire la syntaxe de recherche utilisée par le moteur de recherche. Il précise notamment les règles de grammaire de l'attribut template de la balise Url utilisée dans le document de description précédent.

• Opensearch Query element

  Ce format permet de configurer des requêtes spécifiques par un client de recherche. Il est composé d'un ensemble d'attributs de la balise Query. On peut par exemple proposer un exemple de requête qui peut être effectuée sur le moteur de recherche ou encore afficher des résultats avec des mots proches de celui utilisé par la requête (mais contenant une faute d'orthographe par exemple).

• OpenSearch response elements

  C'est le format de présentation des résultats de recherche. Les formats possibles nativement sont RSS 2.0 et Atom 1.0. D'autres formats de publication sont possibles comme HTML/XHTML.

En plus de ces formats, il existe plusieurs extensions, parmi lesquelles :

• Referrer

  Permet de fournir des informations sur la source effectuant la recherche, comme par exemple le logiciel client utilisé

• Relevance

  Permet d'indiquer le score de chaque résultat d'une recherche donnée

• Suggestion

  Permet l’auto-complétion de mots dans le champ de recherche.

Pour l'utilisation de chacune de ces extensions, il faudra ajouter l'adresse du namespace XML de la spécification dans le fichier de description.D'autres extensions sont encore à l'état de draft mais offriront des possibilités intéressantes, notamment :

• Geo extension

  Propose de fournir un mécanisme standard pour effectuer des recherches sur des données géographiques, comme des coordonnées ou des noms d'endroits.

• Mobile extension

  Propose un mécanisme standard pour adapter les recherches de type OpenSearch aux terminaux mobiles, notamment dans l'affichage des résultats.

Utilisations recommandées :

Tout site utilisant OpenSearch peut être directement intégré au navigateur en utilisant la zone de recherche adaptée.

OpenSearch peut également être utilisé sur des applications hébergeant des moteurs de recherche et fournissant des services en ligne. Cela peut rendre l'application plus générique et permet d'accepter des requêtes à partir d'autres applications. Un exemple d'application en milieu scientifique est le logiciel SITools2 qui intègre nativement un champ de recherche OpenSearch. D'autre part, de nombreux CMS ou wiki implémentent opensearch soit de manière native soit grâce à un plugin: par exemple WordPress, SPIP,Drupal, PLONE, GetNetwork, DokuWiki, MediaWiki

OpenSearch est également très utilisé pour les recherches sur les sites bibliographiques car contenant de multiples bases de données provenant de sources différentes (voir par exemple le site de la revue internationale Nature : http://www.nature.com/opensearch).

Exemple de mise en œuvre :

Pour pouvoir configurer un service OpenSearch sur un moteur de recherche, il faut effectuer les trois étapes suivantes :

• Configurer le moteur de recherche pour proposer en option une réponse au format RSS ou Atom (cela permettra d'utiliser les paramètres du format OpenSearch response elements)

• Créer un fichier de description au format OpenSearch description document

  Le fichier minimum doit être de la forme :

  <?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>${name}</ShortName>
  <Description>${name}</Description>
  <Url type="application/html" template="${url}/suggest?q={searchTerms}">
  </Url>
</OpenSearchDescription>

  Où ${name} est le nom du site et ${url} l’adresse du site.

• Publier le fichier précédent en ajoutant un lien dans le header de la page d'accueil du site de recherche.

  Si par exemple le fichier s'appelle opensearch.xml :

  <link rel="search" type="application/opensearchdescription+xml" title="${name}" href="${url}/opensearch.xml">

Une étape supplémentaire peut être d'envoyer ce fichier de description à l'un des annuaires de moteurs de recherche supportant OpenSearch pour faire connaître le service de recherche.

Il existe en outre de nombreuses bibliothèques qui implémentent les services OpenSearch. Une liste détaillée se trouve ici :
http://www.opensearch.org/Community/OpenSearch_sof...

Introduction

VNC désigne à la fois un protocole de prise en main d'un poste (sous Windows, Linux, MacOS, etc.) et les logiciels qui l'implémentent. Cette fiche ressource se veut générique dans le sens où elle décrit le protocole VNC ainsi que les caractéristiques communes aux logiciels qui l'implémentent.
Cette fiche reprend délibérément le format d'une fiche logiciel, plus exhaustif (et contraignant) qu'une fiche ressource.

Un site générique pour VNC en tant que protocole n'existe pas. Le domaine historique vnc.com renvoie vers le site de la société RealVNC, issue d'une partie de l'équipe initiale des développeurs et détenteur de la marque déposée VNC™. Voir plus loin pour les sites des différentes implémentations, commerciales ou libres, du protocole VNC.

Fonctionnalités générales

Prendre la main (vue de l'écran et contrôle du clavier et de la souris) sur une machine distante, pour faire par exemple de l'administration ou de l'assistance utilisateur. VNC utilise le protocole RFB (remote frame buffer), qui peut s'appliquer à tous les systèmes affichage "en fenêtres" (dont Windows, le protocole X11 et Macintosh). De par sa conception extensible, il a permis aux différentes implémentations (depuis la fin des années 1990) de rester largement compatible entre elles.

Plate-formes et interopérabilité

Fonctionne sur toutes les plate-formes majeures (Windows, Linux, MacOS, etc.), sans problème d'interopérabilité. Cela signifie qu'un client à partir d'un système d'exploitation donné peut se connecter à un serveur tournant sur un autre système d'exploitation. Cependant, l'interopérabilité entre les différents logiciels VNC (saveurs) n'est pas toujours donnée, surtout quand le logiciel serveur et le logiciel client ont des dates de fabrication trop éloignée l'une de l'autre.

Contexte d'utilisation dans mon laboratoire/service

• serveur VNC sur un serveur Windows pour l'administration à distance,
• serveur VNC sur des postes clients pour faire de l'assistance à distance,
• serveur VNC sous Linux, des clients VNC permettent aux utilisateurs d'accéder à cet environnement depuis des PCs Windows.

Limitations, difficultés, fonctionnalités importantes non couvertes

Le protocole est vulnérable à certains types d'attaques, quoique le mot de passe et la transmission des données soient cryptés. Des solutions à base de tunnels SSH ou de VPN sécurisés permettent de pallier cette faiblesse.

Distributions dans lesquelles ce logiciel est intégré

Quasiment toutes les distributions Linux intègrent un client/serveur VNC.

Logiciels implémentant le protocole VNC

• RealVNC: http://www.realvnc.com/, existe en version gratuite "Free" (licence propriétaire), "Personal" et "Enterprise Edition". La version Free est distribuée pour Windows, Linux x86, Solaris 7, HP-UX 11, code source (Unix) et code source pour le Viewer en Java et pour Windows.
• TightVNC: http://www.tightvnc.com/, entièrement gratuit (octobre 2011) en licence GPL. Dernière version (2.5) serveur + client disponible pour Windows. Une version précédente (1.3) également en saveur "Unix-like", ainsi que source et "binaire" en Java pour un Viewer en version 2.6.
• TigerVNC: http://tigervnc.sourceforge.net/, est un fork de TightVNC fondé par un ancien co-développeur de TightVNC pour diverses raisons. Ce dérivé se veut " high performing, stable and generic". Est disponible gratuitement en licence GPL.
  Je n'ai pas pu le tester, mais il est distribué avec Fedora 13 par exemple.
• UltraVNC: http://www.ultravnc.fr/, gratuit en licence GPL, donations possibles, pour Windows.
• Vine Server/Client : http://www.testplant.com/support/downloads/vine/, précédemment distribué sous le nom OSXvnc, est un couple serveur/client VNC libre et open-source de TestPlant, Inc., vendu également avec un service support par la même entreprise.

Des fiches logiciels pour ces applications n'existent pas actuellement dans PLUME. Si vous êtes utilisateur régulier d'une de ces "saveurs" de VNC, contactez l'auteur de la fiche pour contribuer à la collection avec votre description du logiciel.

Autres logiciels aux fonctionnalités équivalentes

• Symantec pcAnywhere (client et serveur payants).
• Windows Terminal server (payant) et client RDP (intégré à Windows ou rdesktop, FLOSS pour Unix)
• Nomachine NX, logiciel commercial, mais version gratuite "Free Edition" disponible qui est limitée à deux utilisateurs (comptes) déclarés simultanément sur la machine serveur. (Voir NX-Freenx pour une implémentation gratuite.)

Historique et Éléments de pérennité

Le protocole a été développé à l'origine dans les laboratoires de recherche joints des sociétés Olivetti et Oracle. Les laboratoires ont été vendus en 1999 à la société AT&T, qui ferma les activités de recherche en 2002. Suivant cette fermeture, plusieurs développeurs du projet ont fondé RealVNC, afin de pouvoir continuer à produire le code open source et commercial sous ce nouveau nom. Les sources ont été mises sous licence GPL et réutilisées (forked) par plusieurs autres équipes de développement.
Aujourd'hui, de (trop ?) nombreuses implémentations du client/serveur disponibles sur la majorité des plate-formes existent.
Protocole éprouvé et très répandu.

Références d'utilisateurs institutionnels

• ATLAS control room management / sysadmins (CERN).
• Accès à distance local (labo) et international (collaborations) au CPPM (CNRS).
• Utilisation de VNC pour l'administration et l'intervention à distance sur les postes gérés par les ASR du LAAS (CNRS).

Augmentation de la sécurité du protocole

Le protocole VNC n'était pas un protocole sécurisé à la base, et malgré des progrès récents, surtout dans des versions commerciales de l'implémentation, il convient de donner quelques conseils pour augmenter la sécurité.

Serveur VNC sous Windows

• Via la base de registre côté serveur, il est possible de n'autoriser que certaines adresses ou plages d'adresses IP à se connecter à un serveur VNC en paramétrant une valeur "AuthHosts" ou "Hosts" selon l'implémentation de VNC utilisée ("AuthHosts" VNC et UltraVNC , "Hosts" pour RealVNC).

• Le paramétrage d’AuthHosts est une clé de type REG_SZ employée pour indiquer un ensemble de masques d’adresses IP que les connexions entrantes doivent respecter afin d’être acceptées. Par défaut, le masque est vide et les connexions de tous les centres serveurs sont acceptées. Le masque est de la forme :
  +[masque d’IP]
  ?[masque d’IP]
  -[masque d’IP]

Explications :

Le [masque d’IP] représente l'adresse IP ou le masque de sous-réseau qui doit être pris en compte. Il peut être de la forme 192.168.1.10 (et désignera alors une adresse IP précise), ou 192.168 (et désigner l'ensemble du sous-réseau 192.168.x.x et toutes les adresses IP en faisant partie).

• le symbole "+" indique que le [masque d’IP] correspondant est autorisé.
• le symbole "-" indique que le [masque d’IP] correspondant est interdit.
• le symbole "?" indique que le [masque d’IP] correspondant doit être accepté côté serveur par l'intermédiaire d'une fenêtre de dialogue.
• le symbole ":" (VNC) ou "," (RealVNC) sert de délimiteur, permettant ainsi de définir plusieurs valeurs.

On aura donc par exemple comme valeur de clé :
HKEY_LOCAL_MACHINE\Software\RealVNC\WinVNC4
"AdminPassword"=hex:dc,c6,6b,58,6d,e4,19,7c
"Hosts"="+192.168.82.0/255.255.254.0,?192.168.0.0/255.255.0.0,-255.255.255.255/0.0.0.0"

Serveur VNC sous Linux ou Windows avec SSH

Il est possible de rediriger les ports utilisés par VNC vers la machine locale à travers un tunnel SSH afin d'en sécuriser la connexion : ainsi les mots de passe VNC ne transitent pas en clair sur le réseau.

ssh $SSH_SERVER -L$LOCALPORT:$VNC_SERVER:$VNCPORT

Le cadriciel cygwin peut fournir un serveur SSH pour une machine équipée de Windows.

Ce document liste les principales étapes et réalisations du projet et de la plate-forme PLUME, par ordre chronologique, entre mai 2012 et juillet 2013.

Les étapes précédentes, dès la création en 2006 jusqu'au départ de Jean-Luc Archimbaud, responsable de PLUME, en mai 2012 se trouvent dans ce document : PLUME : historique du projet et de la plate-forme 07/2006 - 04/2012.

Les étapes suivantes (depuis août 2013 et l'évolution du comité de direction) sont listées dans ce document : PLUME : historique du projet et de la plate-forme depuis août 2013.

2012

• Janvier-Avril : https://www.projet-plume.org/ressource/plume-histo...
• Mai : une page importante de PLUME se tourne.
• Mai : Pascal Joly (LJLL) est intégré dans l'équipe comme responsable thématique du thème Mathématiques.
• Mai : 5ième jounée PLUME Biologie.
• Mai : Conférence OWF-PLUME-System@tic-Aristote - Logiciel Libre et communautés : la clef du transfert ?
• Mai : PLUME à New York lors du congrès CHEP 2012 (avec un article sur PLUME publié).
• Mai : Jean-Marc Larré (LAAS) est intégré dans l'équipe comme co-responsable thématique, avec David Rousse (DSI-CNRS), du thème en création Système d'Information d'un laboratoire.
• Juin : le CPPM accueille la réunion de l'équipe PLUME et organise à cette occasion un Séminaire PLUME.
• Août : membre 2000 de la plate-forme (le 30 août nous avons reçu une nouvelle inscription venant du LAAS).
• Septembre : interface de recherche améliorée avec SolR.
• Septembre : Nicolas Thouvenin (INIST) arrête son rôle de responsable du théme documentation et Information Scientifique et Technique (IST), thème repris par Raphaël Tournoy (CCSd).
• Octobre : PLUME et le CNRS sont des sponsors de EOLE2012.
• Octobre : fin de la reprise et mise à jour des statistiques, voir le tableau de bord.
• Novembre : Gilian Gambini, responsable de l'exploitation de la plate-forme, passe à 80%.

2013

• Janvier : troisième école thématique ENVOL_2012 (Formation pour le dEveloppemeNt et la ValOrisation des Logiciels en environnement de recherche). Cette édition est dédiée au Développement collaboratif pour le logiciel libre.
• Février : David Rousse, animateur principal du comité technique, travaille à temps partiel sur PLUME (équivalent temps plein de 80%).
• Mars : Anne Cheylus (L2C2) est intégré dans l'équipe comme co-responsable thématique, avec Pascal Joly (LJLL), du thème Mathématiques.
• Avril : Frédéric Camps (LAAS) arrête son rôle de responsable du théme développeur, thème géré actuellement par XXXX (Inria Lille) et Pascal Dayre (IRIT).
• Avril : PLUME à Vienne lors du congrès EGU 2013 (avec le poster : PLUME and Research software).
• Avril : nouveau thème Modélisation, sous la responsabilité de Laurent Pérochon (METAFORT).
• Mai : Henri Valeins (RMSB) est intégré dans l'équipe comme responsable du thème en création Qualité.
• Mai : nouveau thème SI Laboratoire sous la responsabilité de Jean-Marc Larré (LAAS) et David Rousse (DSI-CNRS).
• Mai : action de formation MutEC et PLUME : Bases de données XML natives à l'ENS Lyon.
• Juillet : évolution du comité de direction de PLUME.
• Août-Décembre : https://www.projet-plume.org/ressource/plume-histo...

Cette présentation a été realisée dans le cadre de la journée logiciels du Laboratoire d'informatique Gaspard-Monge (Université de Marne-la-vallée) et a pour but d'analyser les questions du libre accès sur la production scientifique du laboratoire.

La production du laboratoire consiste principalement en articles (et autres publications scientifiques) et logiciels, mais il y a aussi les ressources linguistiques produites par l'équipe d'Informatique linguistique, et une autre production plus recente sur "l'Internet of things", travail en cours de I. Salhi.

La première partie de la présentation, dédiée aux logiciels, analyse les deux définitions sur le libre accès aux logiciels : celle du logiciel libre donnée par la FSF et celle du logiciel open source donnée par l'OSI et montre des différences entre les objets définis. Cette section continue avec les données sur les logiciels LIGM présentés sur PLUME.

La deuxième partie, dédiée aux articles, étudie les diverses définitions sur l'open access qui apparaissent dans le domaine des publications scientifiques. Certaines de ces définitions ont été étudiées lors de la matinée sur l'Open access gold - Un enjeu majeur pour les publications en physique. Certaines définitions apparaissent lors des déclarations, par exemple la Déclaration de Berlin ou la Déclaration de Budapest.

Cette deuxième partie analyse aussi la situation du libre accès et de l'édition scientifique au CNRS, en particulier la situation paradoxale dans la production d'articles, leur édition, l'achat des revues où ces articles sont publiées, et l'évaluation de l'activité des chercheurs. Cette situation est assez similaire dans les autres organismes de recherche en France, et pour approfondir sur ces thèmes nous invitons en particulier à la lecture de ces documents :

• Avis du Comité d’éthique du CNRS (COMETS) sur les relations entre chercheurs et maisons d’édition scientifique (30/06/2011),
• Avis de M. Farge pour le Comité d’éthique du CNRS sur les relations entre chercheurs et maisons d’édition scientifique (27/06/2011),
• Avis du Comité d’éthique du CNRS (COMETS) sur le libre accès aux publications scientifiques (« open access ») (29/06/2012) - Lire aussi les réponses aux questions de CNRS Hebdo par Michèle Leduc, présidente du Comets (06/07/2012).
• Discours de Geneviève Fioraso lors des 5e journées Open Access (24/01/2013),
• Avis du Comité d’éthique du CNRS (COMETS) : Pour un renforcement des archives ouvertes HAL (27/02/2013).

En conclusion on peut affirmer que l'édition scientifique est dans une situation très bouleversée actuellement, et son fonctionnement est en (r)évolution. La politique de diffusion, avec des licences Creative Commons (CC-by-nd), de la revue Logical Methods in Computer Science est étudié.

Nous attirons aussi l'attention du lecteur sur l'utilisation du terme open access dans le domaine des publications scientifiques : traduit souvent en français par libre accès, il peut y avoir des significations très distinctes, comme celle d'une licence CC-BY, celle donnée par la déclaration de Budapest ou celle qui indique un accès gratuit pour le lecteur d'un article, mais qui a été publié de façon payante pour son auteur. Il est donc important de clarifier le contexte avec la définition utilisée et les licences impliquées, c'est-à-dire, sur le modèle de la diffusion de logiciels.

Autres références utiles :

• Libre Accès à l'Information scientifique et technique, par l'INIST,
• Droit d'auteur, par la Direction des Affaires Juridiques du CNRS,
• Le droit d’auteur des chercheurs : droit d’auteur, politique des éditeurs et archives ouvertes, par Martin Dantant et Valérie Hospital, Direction des Affaires Juridiques du CNRS,
• La protection des logiciels, par la Direction des Affaires Juridiques du CNRS,
• Article vs. Logiciel : questions juridiques et de politique scientifique dans la production de logiciels.

Et sur les politiques des revues scientifiques :

• Site SHERPA-ROMEO
• Héloïse (politiques des éditeurs en matière de dépôt des articles)
• Directory of Open Access Journals (DOAJ)
• SPARC Europe Seal for Open Access Journals

Après la définition de fourche (ou embranchement ou fork en anglais) : programme développé à partir des sources d'un autre (voir aussi la page Wikipédia sur les forks), ce document AFUL classe les différents types de fourches comme suit :

• la continuation d'un logiciel abandonné,
• une évolution d'un programme dans une direction différente,
• une libération d'un programme sous licence propriétaire,
• une propriétarisation d'un logiciel libre,
• une divergence dans la gouvernance du projet.

Chaque point dans ce classement est suivi d'un exemple représentatif. De plus, des exemples de fourches majeures sont analysés : MySQL, OpenOffice.org et Mandriva.

Une fourche "technique" peut entraîner une fourche "de communauté", ce qui peut affaiblir le projet initial, mais aussi attirer des nouveaux collaborateurs.

Ce document contient aussi des exemples de plateformes en ligne de gestion de sources, traite la question du financement et donne des conseils aux utilisateurs.

Mon intérêt porte en particulier sur le point de la propriétarisation d'un logiciel libre, ce qui est possible si on a les droits patrimoniaux d'un logiciel ou une licence libre qui le permet, c'est le cas de l'exemple donné sur ce type de fourche : Cedega. Selon la page Wikipédia sur Cedega, il s'agit d'une version propriétaire du logiciel Wine, initialement distribué sous une licence MIT et qui, suite à ce fourchage, a changé sa politique de licence vers une licence LGPL. Dans ce cas, c'est la licence initiale de type BSD ou sans copyleft de Wine qui a permit la propriétarisation.

Similairement, la libération d'un code existant est possible si on en a les droits d'explotation. Dans l'exemple donné de Blender, l'achat du code source est une première dans l'histoire du logiciel libre (voir par exemple http://www.logiciellibre.net/2003/news20031210.php).

Un autre exemple est celui de Open-Sankoré, libération du logiciel Uniboard, c'est l'État français qui a acquis les droits d'Uniboard et l'a rendu Open source et gratuit.

Une autre possibilité pour la propriétarisation ou la libération d'un logiciel est sa réécriture complète, mais cela doit éviter les problèmes de plagiat.

L’Observatoire des Pratiques Géomatiques de l’Institut Français de l'Education (ENS Lyon) a été fondé en 2005 pour permettre de faire avancer la réflexion sur les usages et les enjeux des outils géomatiques dans l’enseignement secondaire. La géomatique regroupe l'ensemble des outils et méthodes permettant de représenter, d'analyser et d'intégrer des données géographiques. Le traitement de ces données géographiques est souvent effectué par des logiciels spécialisés appelés les Systèmes d'Information Géographique (SIG) qui sont à la fois les outils et les systèmes de gestion et de décision principaux du développement de cette discipline.

Néanmoins, à l'heure où les systèmes de cartographie en ligne prennent une place de plus en plus importante sur Internet, les pratiques se démocratisent via des applications en ligne où chaque internaute peut produire des cartes personnalisées. Dans ce contexte, la géomatique revêt à la fois des contenus pratiques et des usages à finalité double : l'utilisation de ces outils par les enseignants pour transmettre et faire réfléchir les élèves aux contenus disciplinaires (depuis le primaire jusqu'à l'université), proposer aux élèves une véritable éducation aux problématiques citoyennes de la géomatique (néogéographie, simulations, aide à la décision...)

L'observatoire a pour vocation de confronter les regards pluridisciplinaires sur des pratiques géomatiques éducatives afin de créer une communauté d’usagers diversifiée autour de ces différents usages. Il s'y emploie notamment par le croisement des approches et des regards, proposant une réflexion double, à la fois sur les enjeux pédagogiques et fonctionnels géomatiques, tout en développant des axes de recherche et d'innovation propres fondés sur ces réflexions.

Cette fiche ressource à été relue par Maud Ingarao (ENS Lyon, CNRS) et par Florence Petit (IGM).

Introduction

XML est un langage informatique de balisage (enrichissement d'information textuelle).

A noter que le contenu de cette fiche PLUME ne constitue qu'un aperçu global d'XML et des standards associés, et non une formation exhaustive sur ces différents sujets.

Origine

Issu d'une simplification de la norme SGML (Standard Generalized Markup Language), XML (eXtensible Markup Language) est le fruit de travaux communs du World Wide Web Consortium (W3C) et de plusieurs industriels, entre 1996 et 1998.

Vue d'ensemble

Les principes de base d'XML sont donc ceux du SGML :

• Séparation de la présentation et des données
• Structuration des données
• Capacité à valider la structure des données

Ces principes simples et souples donnent à XML la capacité à rendre le partage d'information ouvert, ce qui favorise les échanges informatisés basés sur des formats portables ainsi que l’interopérabilité des applications.

Schéma

Cela peut s'illustrer ainsi :

Structuration et organisation du contenu XML

Principe

XML est un langage de balisage générique qui permet de définir des documents contenant à la fois les données et des indications sur la structure de ces données. Ces balises ne sont pas prédéfinies, d'où la nature extensible du langage. Il convient de respecter des règles de construction syntaxique d'XML : on parle alors d'un document bien formé

Exemple

Un exemple de document XML est le suivant :

Ce document XML correspond à l'arbre ci dessous :

Validation du contenu XML

Principe

Un document XML contient des données, organisées selon les règles de construction d'XML : c'est la notion de document bien formé déjà mentionnée.

Une grammaire donnée permet de définir des contraintes supplémentaires sur la structure d'un document XML. La définition d'une grammaire donnée se fait via des DTD ou via des schémas XML (extension : .xsd). Les schémas sont à ce jour les plus utilisés, car par rapport aux DTD, ils présentent en effet l'avantage d'être eux-même des documents XML. La syntaxe simplifiée Relax NG est également très utilisée.

Un document valide est un document qui respecte la grammaire définie dans une DTD ou un schéma XML.

Exemple

Soit le document XML suivant :

Le contenu de ce document XML peut être validé via le schéma XML suivant :

Sur la différence entre document bien formé et document valide, voir par exemple ce récapitulatif sur le site W3schools.

Transformations de contenu XML

Principe

Comme expliqué ci-avant, un document XML contient les données et leur sémantique et ce contenu peut être validé par rapport à une grammaire donnée via des schémas XML (ou une DTD). Pour la présentation et/ou la transformation de contenu en XML, il est possible de passer par :

• des CSS (Cascading StyleSheets),
• des feuilles XSL (eXtensible Stylesheet Language), avec principalement XSLT (XSL Transformations) et XSL-FO (XSL-Formatting Objects).

Par ailleurs, le langage de requête XPath est souvent utilisé dans ce contexte de transformations de données car il permet de sélectionner des fragments de contenu XML.

Exemple

On considère le document XML ci-dessous :

La transformation de ce document en une page HTML peut se faire via le code XSLT suivant :

Le résultat de la transformation donne :

Liaisons de contenu en XML

Principe

Étant donné la structure logique en arbre d’XML, la description de relations autres que parent-enfant(s) entre nœuds n’est pas naturelle. La réponse à cette problématique de liaisons de contenu XML passe par :

• XLink, qui permet de décrire des graphes dans lesquels les sommets sont des documents (situés à des URI particuliers) et les arêtes sont les liens entre ces documents,
• XPointer, langage dédié à l’identification de fragments de documents XML, souvent utilisé en liaison avec XLink.

Exemple

Soient trois fichiers zola1.txt, zola2.txt et zola3.txt pour lesquels un lien multidirectionnel de type arc doit être construit, pour avoir :
zola1.txt <--> zola2.txt <--> zola3.txt

Via XLink, cela peut s'exprimer de la sorte :

Manipulations de contenu XML

Principe

La manière de manipuler des documents XML depuis des programmes (lecture, écriture, modification) s’implémente principalement de deux façons différentes :

• SAX (Simple API for XML), API qui aborde la notion de parsing de manière événementielle,
• DOM (Document Object Model), API qui traite un document XML avec une approche arborescente.

Exemple

Soit l’extrait de document XML suivant :

Un parseur SAX reportera typiquement les événements suivants (dans l’ordre indiqué)

Un parseur DOM va, lui, représenter la totalité du document XML en mémoire sous la forme d'un arbre, en respectant la recommandation Document Object Model du W3C.

A noter : le parsage DOM est un exemple de "XML data binding", qui signifie le fait de représenter les éléments d'un document XML en tant qu'objets en mémoire. Cf. l'article [en] XML data binding sur Wikipedia.

Conclusion

En guise de conclusion, les différents éléments précités autour de XML s'illustrent de la sorte :

Références

Le support de cours suivant traite de manière plus approfondie d'XML et des normes et standards liés.

Ce document liste les principales étapes et réalisations du projet et de la plate-forme PLUME, par ordre chronologique.

Dans les phases suivantes, de 2006 à 2010, PLUME est un projet de l'UREC, Unité Réseaux du CNRS. Ensuite le projet est piloté par le pôle ARESU, Architecture Réseaux, Expertises, Support aux Unités, de la DSI, Direction des Systèmes d'Information, du CNRS.

2006

L'UREC a plusieurs missions dont une d'animer la communauté des informaticiens dans les laboratoires du CNRS (et de mutualiser leurs compétences) et une autre de monter des projets répondant et parfois anticipant les besoins nouveaux des laboratoires en terme d'informatique proche de la science. Dans ce contexte une réflexion démarre au sujet des logiciels utilisés ou développés dans les laboratoires.

• Premiers constats et questionnement de Jean-Luc Archimbaud (UREC)
  • Les informaticiens dans les laboratoires et les universités utilisent et développent des logiciels souvent libres mais ré-inventent la roue, ne sachant pas ce qu'utilisent ou développent leurs collègues dans les mêmes environnements : perte énorme de temps et d'efficacité.
  • Il y a beaucoup de compétences pointues sur des logiciels variés dans la communauté Enseignement Supérieur - Recherche (ESR).
  • Les logiciels libres présentent maintenant des produits stables. C'est une solution bien adaptée à la communauté ESR, à la fois pour l'utilisation et pour le développement.

  --> Comment mutualiser ces compétences sur les logiciels (en particulier libres) ?

• Etude de l'existant
  • Y-a-t-il déjà des listes de logiciels libres utilisés ? : beaucoup de listes mais très restreintes, à l'initiative d'une personne très motivée la première année mais qui ensuite, moins motivée, n'assure pas un suivi. Sauf un serveur national framasoft très intéressant mais avec une cible tout public, donc beaucoup de logiciels sans intérêt pour l'ESR et sans mise à jour des informations (les descriptions n'évoluent pas).
  • Y-a-il des projets de référencement de logiciels ? Quelques uns mais pas pour l'ESR.
  • Combien d'informaticiens y-a-t-il dans la communauté ESR : environ 10 000 ingénieurs ou techniciens, sans compter les chercheurs et les enseignants : donc beaucoup.

  ---> Idée de créer un référentiel de logiciels utilisés dans l'ESR, principalement libres, avec les mises à jour nécessaires.

• En juillet 2006, une amorce de projet est élaborée dans le document Projet national pour faciliter et promouvoir l’utilisation des logiciels libres dans la communauté enseignement supérieur et recherche, document diffusé pour recueillir des avis de la communauté ESR et amorcer des contacts.
• Geneviève Romier (UREC) se joint à Jean-Luc Archimbaud (les deux pour une partie de leur activité UREC dans ce projet), rapidement appelé PLUME : Promouvoir les Logiciels Utiles Maitrisés et Economiques dans l'enseignement supérieur et la recherche. C'est une première chance du projet d'avoir un acronyme représentatif de l'objet, sympathique et mnémonique.
• Décision de monter une plate-forme de test pour publier des descriptions de logiciels utilisés dans l'ESR, sans matériel ni développement particulier, en utilisant le serveur Web existant de l'UREC (sous le CMS  SPIP), des échanges 'manuels' de mails avec les contributeurs et la publication des fiches descriptives en PDF avec un début de classification et un premier modèle de fiche. Les premières fiches sous cette forme sont publiées en septembre 2006. Ceci dans le but de :
  • Valider la faisabilité de créer un référentiel (trouver des contributeurs...) et son début d'utilité (est-ce intéressant ?)
  • Définir la structure des fiches, les processus de réalisation, l'organisation et les outils techniques nécessaires
• Sylvain Corcoral, ingénieur dans le laboratoire LSEET, rejoint pour une partie de son temps, le projet en temps que rédacteur de fiches, puis sur la définition du projet et la mise en place des outils futurs.
• Fin 2006, il y a 5 fiches en ligne sur le serveur de test PLUME (serveur Web de l'UREC) : OpenOffice.org, Autoruns, PDFCreator, modXLDAPAuth et Ad-Aware rédigées par 4 contributeurs : Geneviève Romier, Gael Beauquin, Sylvain Corcoral, Alice de Bignicourt.

2007

Le projet prend forme : une présentation de PLUME faite au CCIN2P3 le 17 janv 2007 avec une video et les transparents associés en donne le descriptif. En résumé :

• Deux objectifs principaux : référencer les logiciels utilisés dans la communauté ESR (mutualisation des compétences) et les logiciels développés dans cette communauté (promotion, valorisation) sous forme de fiches descriptives indexées avec des mots clés
• Cible : la communauté ESR et en particulier les informaticiens ou utilisateurs éclairés de l'informatique
• Rédacteurs de fiches : utilisateurs ou développeurs des logiciels
• Organisation avec plusieurs rôles : contributeurs, relecteurs, responsables de thèmes... Un thème peut être un métier, un domaine scientifique, une activité transverse, un domaine informatique. Les responsables thématiques sont des personnes qui travaillent dans un laboratoire ou une université, qui connaissent bien les logiciels d'un thème et qui acceptent de participer à PLUME comme référent pour ce thème. Ils ont pour mission principale de suivre et de coordonner la publication d'un certain nombre de fiches.
• Des entités (laboratoires...) qui soutiennent et qui sont partenaires de PLUME

La plate-forme de test

• Sur la plate-forme de test sont élaborés un modèle de fiche - une notice explicative pour remplir une fiche - une liste de mots clefs -  un processus de sollicitation, de relecture, de mise en ligne des fiches - un processus de prise en compte des propositions spontanées de rédaction de fiches - une classification des logiciels - une charte pour les contributeurs.
  Ces documents serviront de base pour l'organisation, la structuration des informations et les workflows de la plate-forme définitive.
• Un tableau de bord suit la production et la consultation du serveur de test.
• En octobre, lors de la bascule sur le serveur définitif PLUME, il y a sur le serveur de test :
  • 54 fiches descriptives sur le serveur de test rédigées par 35 contributeurs qui sont ressaisies par ces contributeurs sur la plate-forme définitive.
  • 7 responsables thématiques : Violaine Louvet (Institut Camille Jordan) pour les maths, Véronique Baudin (LAAS) et Christian Helft (LAL) pour le thème travail collaboratif, Jacquelin Charbonnel (LAREMA) et Sylvain Corcoral (IBCG) pour le thème administrateur systèmes et réseaux, Jean-Luc Archimbaud (UREC) pour le thème développements Ens Sup - Recherche et Geneviève Romier (UREC) pour le thème informatique individuelle.

La plate-forme définitive

• En parallèle, début 2007 un cahier des charges pour la plate-forme définitive est rédigé.
• En mars 2007 Pierre-Yves Gosset est recruté en CDD UREC. Il travaillera sur PLUME à plein temps toute l'année 2007 puis à 20 % jusqu'en octobre 2008. Avec le cahier des charges, il lui est confié l'étude des différentes solutions techniques avec des tests. Le choix se porte sur le CMS Drupal avec un serveur Linux.... en mai. Sa démarche est décrite dans la fiche Description du processus de choix d'un CMS pour le projet PLUME.
• Dans les mois qui suivent, Pierre-Yves Gosset installe et configure les modules nécessaires avec les premières pages de présentation. 
• Le 15 oct la plate-forme est ouverte en beta et le 5 nov le site est ouvert officiellement avec 37 fiches publiées et 33 en rédaction ou relecture. Les fiches sont uniquement des fiches de logiciels validés.
• Fin 2007, la plate-forme compte 57 fiches publiées et 42 en relecture, 35 contributeurs et 9 responsables thématiques. Les deux nouveaux responsables sont : Anne Durand (MAP, thème formation), Nicolas Thouvenin (INIST, thème IST, Information Scientifique et Technique).

La suite du projet

• En aout, un article complet de présentation du projet est publié.
• Le 23 oct une réunion (cf compte-rendu) réunissant Violaine Louvet (ICJ ), Térésa Gomez-Diaz (LIGM), Geneviève Romier (UREC), Stéphane Cordier (MAPMO et département MPPU), Jean-Luc Archimbaud (UREC) lance officiellement l'objectif de s'appuyer sur PLUME pour référencer les développements des laboratoires (en particulier de maths) dans un projet connexe qui s'appellera ensuite RELIER, REférencer les développements Logiciels Internes de l'Enseignement supérieur et de la Recherche et donnera l'année suivante les fiches Dév ESR.

Une plateforme de formation à distance (à partir de juillet)

2008

• Janv-Mars : dans le cadre du projet @2L, développement d'une offre complète de formation à distance au CMS SPIP. Plusieurs sessions de formation seront organisées en 2008 et 2009.
• Mars : intégration de Anne Durand (MAP) à 50 % de son temps dans le noyau dur PLUME en particulier pour le projet @2L et pour l'ergonomie de la plate-forme. Ces 50 % seront effectifs jusqu'en septembre 2009.
  
• Avril-mai : avec le réseau métier RESINFO, appel à projets DEVA (DEVeloppements Administrateurs systèmes et réseaux de laboratoires de recherche), sélection et soutien de 4 projets.
  
• Mai : sur la plate-forme, mise en place des pages thématiques
• Juillet : sur la plate-forme : création des premières fiches ressources. Ces fiches présentent synthétiquement des ressources liées aux logiciels :
  • articles (comparatif, compte-rendu d'expérience par exemple)
  • supports de cours, transparents d'une présentation, évènements (conférence, journée thématique, ...)
  • services (hébergement de listes de diffusion, pont de visioconférences...)
  • sites web...
• Août : sur la plate-forme : création des premières fiches de logiciels à valider (logiciels dans un état abouti, utilisés en production sur un site mais qui, à notre connaissance, ne sont pas utilisés sur d'autres sites) et de logiciels en test (pas en production mais en cours de test sur un site).
  
• Septembre : sur la plate-forme : création des premières fiches Développement ESR (Développements Enseignement Supérieur - Recherche) fiches qui décrivent les logiciels développés ou en développement dans la communauté ESR quelque soit leur état, des fiches archivées (fiches qui ne sont plus mises à jour) et de l'agenda (pour annoncer les événements autour des logiciels, en particulier libres)
  

• Octobre : première école thématique ENVOL_2008 (Formation pour le dEveloppemeNt et la ValOrisation des Logiciels en environnement de recherche)

• Octobre : recrutement de Antony Burton en CDD UREC qui travaillera jusqu'en avril 2009 sur la mise en place du portail anglophone.

Fin 2008, 314 fiches sont publiées sur la plate-forme avec 18 responsables thématiques (cf tableau de bord). Les nouveaux responsables thématiques (2008) sont : Emmanuel Courcelle (LIPM) pour le thème biologie, Emile Geahchan (CNAM) pour le thème sécurité, Teresa Gomez-Diaz (LIGM) pour le thème patrimoine logiciel d'un laboratoire,  Raphael Tournoy (ISH) et Maud Ingarao (Institut d'Histoire de la Pensée Classique) pour le thème SHS, Pascal Dayre (IRIT) et Frederic Camps (LAAS) pour le thème développeur.

2009

• Février : après un travail de préparation de plusieurs mois, pour intégrer les nouvelles fiches, de nouvelles recherches et un meilleur visuel : changement d'identité visuelle du serveur, évolution pilotés par Anne Durand
• Mars : première journée PLUME : Gérez vos références bibliographiques avec des logiciels libres
• Avril : ouverture du portail anglophone PLUME-FEATHER
• Sept : 2nde journée PLUME : Pourquoi et comment diffuser un développement logiciel de laboratoire ou d'université en libre ?
• Juin-oct : préparation du changement de version du CMS Drupal sur la plate-frome (V5 -> v6). Après l'équivalent de 7 h/mois de travail, la bascule s'est faite le 6 oct avec uniquement un jour d'interruption pour les visiteurs. Cette opération a été pilotée par Geneviève Romier.

Durant l'année 2009 PLUME a été présenté dans de nombreuses conférences : cf fiche ressource 'Participation de PLUME dans des journées (2009-2011)'

Fin 2009, 529 fiches sont publiées sur la plate-forme (+90 % par rapport à 2008), par 438 contributeurs avec 22 responsables thématiques (cf tableau de bord). Les nouveaux responsables thématiques (2009) sont : Christelle Dantec (IGF) pour le thème biologie, Anne Facq (CRPP) pour le thème chimie, Sylvain Faure et Loïc Gouarin (Labo Maths Orsay) pour le thème maths, Laurent Perrochon (INRA Phase) pour le thème agronomie, François Morris pour le thème sécurité.

2010

• Janv : intégration de Térésa Gomez-Diaz à 70 % de son temps dans le noyau dur de l'équipe PLUME en particulier pour le projet connexe RELIER au départ.
• Janv : recrutement de Samuel Godey comme ingénieur valorisation CDD financé par la DPI (Direction de la Politique Industrielle) du CNRS , qui travaillera jusqu'en juillet sur le référencement des logiciels développés dans les laboratoires.
• Fév : 3ième journée PLUME : Les alternatives libres aux outils propriétaires de maths
• Fév : lancement d'un projet d'étude de forge ESR
• Mars : départ d'un responsable thématique du thème Administrateur Systèmes et Réseaux, un des premiers participant à PLUME : Sylvain Corcoral
• Mars : demande à la MRCT, Mission des Ressources et Compétences Technologiques du CNRS, qui regroupe tous les réseaux métiers au CNRS, que PLUME soit accepté comme un réseau de compétences transverses dans la MRCT. En effet PLUME peut être un outil pour tous les réseaux métiers : refus du Directeur de la MRCT.
• Avril : mise en ligne d'une page pour référencer les développements logiciels des laboratoires de l'INSMI, Institut National des Sciences Mathématiques et de leurs Interactions du CNRS, puis d'une page pour l'INS2I, Institut National des Sciences Informatiques et de leurs Interactions.
• Avril : sur le serveur, nouvelle page thématique : patrimoine logiciel d'un laboratoire
• Avril-Oct : enquête sur les besoins en forge dans la communauté ESR et résultats de cette enquête.
• Avril-mai : formalisation plus complète de l'organisation du projet et de la plateforme PLUME avec des entités soutiens-partenaires, un comité stratégique, un comité de suivi et d'orientation, un comité technique (qui regroupe les responsables thématiques), un comité d'exploitation, un rédacteur en chef.
• Juin : journée PLUME : Communication scientifique en ligne : outils libres (CMS, wikis, blogs, ...), pratiques et analyses
• Juillet : l'UREC, unité propre de service du CNRS, qui pilote le projet PLUME n'est pas renouvelée.
• Juillet : suite au non renouvellement de l'UREC, pour  piloter le projet, une proposition d'héberger le projet et de l'équipe PLUME au CCIN2P3, avec la création d'une structure de type GIS, Groupement d'Intérêt Scientifique, est faite à la direction du CNRS. Le GIS permet un pilotage de PLUME avec d'autres partenaires que le CNRS (universités, organismes de recherche...), tout en étant une structure très légère.
  
• Sept : publication du document : Bilan à trois ans de PLUME : les services rendus aux laboratoires de recherche et aux universités.
• Sept : la direction du CNRS refuse la proposition d'hébergement du projet au CCIN2P3.
• Sept : recrutement de Laurent Pasquali  comme ingénieur valorisation CDD financé par la DPI (Direction de la Politique Industrielle) du CNRS, qui travaillera jusqu'en sept 2011 sur l'amélioration de l'accessibilité du serveur, l'ergonomie et sur de nouvelles fonctionnalités de recherche.
• Oct : seconde école thématique ENVOL 2010 (Formation pour le dEveloppemeNt et la ValOrisation des Logiciels en environnement de recherche)
• Nov : journée PLUME : Les outils libres de base utiles à tout ASR (Administrateur Système et Réseau), organisée avec le réseau métier RESINFO.
• Nov : suite au non renouvellement de l'UREC, pour  piloter le projet, une seconde proposition est faite à la direction du CNRS : la  création d'une UMS, unité mixte de service, dédiée à PLUME. L'objectif de l'UMS est de pourvoir intégrer dans le pilotage et le soutien (en terme de ressources) au projet des structures autres que le CNRS : universités, organismes de recherche...
  
• Déc : la direction du CNRS refuse la proposition précédente et décide que le pilotage de PLUME est confié au pôle ARESU, Architecture Réseaux, Expertises, Support aux Unités, de la DSI, Direction des Systèmes d'Information, du CNRS.

Durant l'année 2010 PLUME a été présenté dans de nombreuses conférences : cf fiche ressource 'Participation de PLUME dans des journées (2009-2011)'

Fin 2010, 844 fiches sont publiées sur la plate-forme, par 650 contributeurs avec 26 responsables thématiques (cf tableau de bord).
En 2010, parmi les responsables thématiques, Sylvain Corcoral a quitté PLUME et sont arrivés : Jean-Michel Glorian (CESR) pour le thème développeur, Jérôme Kieffer (ESRF) pour le thème chimie et Maurice Libes pour le thème Administrateur Systèmes et Réseaux.

2011

• Janv : organisation avec la délégation régionale du CNRS de Lyon d'une demi-journée : Comment diffuser et valoriser les développements logiciel des laboratoires à travers PLUME.
  
• Janv : Olivier Porte responsable du pôle ARESU de la DSI du CNRS est intégré dans différents comités PLUME.
  
• Mars : départ du projet des 3 responsables du thème maths : Violaine Louvet (qui arrête aussi sa responsabilité dans le projet RELIER), Loïc Gouarin et Sylvain Faure.
• Mars : arrivée de Dirk Hoffman (CPPM) comme responsable d'un nouveau thème : physique.
• Mars : demi-journée 'Votre patrimoine logiciel est-il bien valorisé ?' organisée avec l'Université Numérique en Région Nord - Pas de Calais à l'Université de Lille 1.
• Avril : la 900ième fiche est publiée sur le serveur.
• Mai : Geneviève Romier arrête ses rôles de co-responsable du comité technique, responsable du comité d'exploitation,  rédactrice en chef suppléante et responsable du thème informatique personnelle. Elle devient responsable thématique d'un nouveau thème grilles qui se mettra en place.
• Mai : ré-organisation des différents comités pour remplacer Geneviève Romier et Violaine Louvet. Arrivée de Thierry Descombes (LPSC) dans le comité d'exploitation.
• Mai : Jean-Michel Glorian (OMP) arrête son rôle de responsable du théme développeur.
• Mai : installation sur la plate-forme de la première partie du travail de Laurent Pasquali : amélioration de l'accessibilité.
• Juin : participation de PLUME aux rencontres de l'innovation en Val de Marne sur le thème 'Collaboration public-privé pour la valorisation de logiciels'.
• Juillet : arrivée dans le projet de Gilian Gambini (à 100 % sur le projet) et de David Rousse (à 20 % sur le projet jusqu'en septembre, repoussé à novembre 2011 puis à 100%). Ils prendront progressivement des responsabilités dans les différents comités et participeront à la vie et à l'évolution du projet. Début de leur formation-intégration.
• Juillet : installation de la seconde partie du travail de Laurent Pasquali sur la plate-forme : nouveaux menus.
• Aout : installation de la 3ième partie du travail de Laurent Pasquali sur la plate-forme : nouveaux types de recherche
• Septembre : reprise de toute les documentations d'administration de la plate-forme et intégration dans un wiki
• Octobre : Gilian Gambini prend en charge le pilotage du comité d'exploitation avec des départs dans ce comité : Thierry Descombes, Raphael Tournoy, Anne Durand. Gilian Gambini et David Rousse peuvent être considérés comme 'opérationnels' dans PLUME
• Octobre : arrivée d'un nouveau responsable thématique : Hervé Parmentier qui va prendre en charge progressivement le thème géographie
• Novembre : ouverture officiel du thème physique associé à mécanique
• Novembre : installation d'une nouvelle machine plus puissante pour la plate-forme PLUME
• Novembre : PLUME fête sa 1000ème fiche publiée (le communiqué de presse)
• Décembre : début d'une collaboration plus étroite avec le Groupe Logiciel pour lui apporter une expertise  sur  les  logiciels  open source  et  l'aider  à  proposer des alternatives non propriétaires aux solutions logiciels du groupe

Fin 2011, 1019 fiches sont publiées sur la plate-forme, par 762 contributeurs avec 20 responsables thématiques (cf tableau de bord).

Durant l'année 2011 PLUME a été présenté dans de nombreuses conférences : cf fiche ressource 'Participation de PLUME dans des journées (2009-2011)'.

En 2011, parmi les responsables thématiques, Violaine Louvet, Loïc Gouarin et Sylvain Faure pour le thème Maths, Jean-Michel Glorian pour le  théme développeur et  Jacquelin Charbonnel pour le thème Administrateurs Systèmes et Réseaux ont quitté l'équipe PLUME. Sont arrivés : Dirk Hoffman pour le thème physique et Hervé Parmentier pour le thème géographie. Geneviève Romier a mis fin à différentes activités dans l'équipe PLUME mais devient responsable thématique Grilles et sont arrivés Gilian Gambini et David Rousse de la DSI du CNRS.

2012

• Janvier : Clive XXXX (INRIA Lille) est intégré dans l'équipe comme responsable thématique du thème développeur.
• Janvier : suite à la sortie du comité de presse CNRS pour la 1000ème fiche PLUME, cette information est reprise dans la Lettre informatique de l'IN2P3 et dans le magazine InfoDSI.
• Janvier : Thierry Dostes (IMM) est intégré dans l'équipe comme responsable thématique du thème administrateurs systèmes et réseaux, de même que Gilian Gambini (DSI CNRS) sur le même thème.
• Février : accord de coopération avec RENATER pour dans un premier temps diffusion du flux RSS PLUME : voir la section "Actualités de la communauté" du site web de RENATER.
• Février : premières actions de la coopération PLUME avec le Groupe Logiciel (GL) : un membre de l'équipe PLUME participe comme expert logiciel libre aux travaux du groupe, dans PLUME les accords du Groupe Logiciel sont présentés et inversement sur le site du Groupe Logiciel les fiches PLUME de produits libres équivalents aux logiciels commerciaux négociés seront notées.
• Mars : nouveau thème dans PLUME : Informatique distribuée, grilles, cloud avec comme responsable thématique Geneviève Romier.
• Mars : PLUME en Espagne lors des Journées CRUE-TIC.
• Avril : organisation avec le GREYC à Caen d'une demi-journée : La valorisation de logiciels produits dans les laboratoires de recherche et PLUME.
• Avril : suite à une mutation Jean-Luc Archimbaud quitte la DSI du CNRS et donc le projet PLUME : ses tâches sont reprises par Véronique Baudin, Emmanel Courcelle, Teresa Gomez-Diaz et David Rousse.
• La suite (Mai 2012 - Juillet 2013) : https://www.projet-plume.org/ressource/plume-histo....