management

Logiciels (logiciels libres en majorité) ou ressources (liées aux logiciels) utiles pour le management (la direction, le pilotage) d'entités (laboratoire, service, équipe ...) ou de projets
Fiche logiciel à valider
  • Création ou MAJ importante : 18/08/10
  • Correction mineure : 08/11/12
Mots-clés
Pour aller plus loin
Fiche en recherche de relecteurs
Cette fiche est en recherche de relecteurs. Si vous êtes intéressé(e)s, contactez-nous !

OMIL : gestion des ordres de mission dans un laboratoire

Ce logiciel est en cours d'évaluation par la communauté PLUME. Si vous utilisez ce logiciel en production dans notre communauté, merci de déposer un commentaire.
Description
Fonctionnalités générales

OMIL est une application (Français & Anglais) permettant de gérer les ordres de mission CNRS & Université (+ une autre EPST) au travers d'un formulaire web couplé à une base de données MySQL. L'usager alimente un formulaire sur 5 étapes, il reçoit un récapitulatif de sa demande par mail via pièce jointe en PDF. Au même moment le responsable du laboratoire (ou les responsables administratifs) reçoivent une notification par mail les informant de traiter la demande en accédant à leur espace d'administration. Après validation la (ou les secrétaires) sont informées par mail pour gérer la demande, elles accèdent à leur interface d'administration pour finaliser l'ordre de mission.

Finalement l'usager est informé par mail que sa demande a été traitée.

Autres fonctionnalités

OMIL peut être amélioré mais il inclut déjà :

  • un espace super-administrateur permettant de gérer l'application
  • la gestion des profils (admin, directeur, secrétaire)
  • la modification de la traduction (anglais/français) uniquement pour le formulaire
  • le changement des corps (emails) pour les notifications
  • une sauvegarde manuelle de la base de données
  • un moteur de recherche pour les demandes archivées
  • gestion de son profil personnel

OMIL est pré-configuré pour fonctionner dans une UMR (Unité Mixte de Recherche) CNRS - UCB (Université Lyon1). L'unité est gérée de manière à distribuer les crédits CNRS, UCB avec frais ou sans frais (entités dépensières définies par nom d'équipe par ex:).

Interopérabilité

Les données sont sauvées à partir de la base de données MySQL, elles sont exportables et ouvertes. Les pièces jointes (récapitulatifs) sont au format PDF.

Contexte d'utilisation dans mon laboratoire/service

OMIL version 2.0 fonctionne depuis 6 mois dans mon UMR (1er version février 2008 dont 758 OM). OMIL prend toute son ampleur si l'unité est localisée sur différents lieux géographiques (pour les utilisateurs). Auparavant notre directeur devait affecter les crédits en alimentant un formulaire papier. En cas d'absence, par exemple à l'étranger, la secrétaire devait attendre son retour. Avec OMIL, notre directeur s'authentifie sur son interface web OMIL et traite la demande; la secrétaire est automatiquement informée des crédits allouées par le directeur.

Limitations, difficultés, fonctionnalités importantes non couvertes
  • Multilinguisme anglais / français uniquement sur le formulaire et non sur l'espace d'administration
  • L'ajout d'un module pour les statistiques est à envisager
  • La sécurisation de certains fichiers est à améliorer
Environnement du logiciel
Plates-formes

Apache, MySQL, PHP4 ou PHP5 (testé sous WIndows et LAMP)

Logiciels connexes

OMIL a été développé sous Debian GNU/Linux sans framework.
Il utilise html2pdf pour générer le fichier PDF, et pjmail.
JQuery ainsi que les feuilles CSS ont été utilisées.

Environnement de développement
Type de structure associée au développement

J'ai assuré (Sad Mezzour - LASIM) le développement et continue.
D'autres contributeurs ont participé : A. Doglioni, C. Lagriffoul, F. Pinto et S. Huet.

Environnement utilisateur
Divers (astuces, actualités, sécurité)

Commencez par tester OMIL en local, ci-possible sur une version Linux. (LAMP)

Contributions

Actuellement je dispose beaucoup moins de temps pour continuer à faire évoluer OMIL, n'hésitez pas à modifier le code, juste un petit mail (sad [dot] mezzour [at] univ-lyon1 [dot] fr) pour m'informer ! Merci

Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 07/06/10
  • Correction mineure : 30/06/10

phpMyResa : réservation de ressources (salles...)

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Site web
  • Système : UNIX-like, Windows, MacOS X
  • Version actuelle : 4.0.3 - 10 mai 2010
  • Licence(s) : GPL - v2
  • Etat : validé (au sens PLUME), diffusé, stable
  • Support : maintenu, développement en cours
  • Concepteur(s) : Comité de pilotage : Daniel Charnay, Frédéric Melot, Patricia Warin-Charpentier. Page sur les contributeurs
  • Contact concepteur(s) : phpmyresa@cc.in2p3.fr
  • Laboratoire(s), service(s)... : CC-IN2P3, LPNHE, LPSC

 

Une fiche logiciel décrit plus en détail ce développement, consultez la pour plus d’informations : phpMyResa
Fonctionnalités générales du logiciel

Gestion de la réservation de ressources (salles de réunion, salles de cours, véhicules, matériel multimédia…).

Une fiche de logiciel validé décrit plus en détail ce logiciel, consultez la pour plus d’informations.

Contexte d’utilisation du logiciel

Utilisation dans la majorité des laboratoires de l’IN2P3.

Theme Patrimoine logiciel d'un laboratoire

Nouveau thème dans PLUME : patrimoine logiciel d'un laboratoire qui a pour objectif de faciliter et de promouvoir la gestion du patrimoine logiciel des laboratoires de recherche, et de regrouper les fiches et les informations publiées sur la plate-forme PLUME qui sont utiles à cette gestion : consultez la page...

Mots-clés

Conference Le libre à cout raisonné Paris 10 juin 2010

Une conférence "Le libre à cout raisonné" est organisée le 10 juin prochain à l'Ecole Polytechnique de Palaiseau, dans le cadre de l'association Aristote.

Extrait de l'annonce

Cette initiative fait suite au séminaire organisé début 2008 par Patrick Murzeau (DGFIP) et Jean Luc Archimbaud (CNRS-UREC/projet PLUME) sur "Open Source, réussir son projet", Quels standards et quelles initiatives ?" .

En abordant les problèmes de coût, le séminaire s'adresse, outre les les utilisateurs, plus particulièrement aux DSI et "décideurs" : " Le logiciel libre est un moteur du changement qui s'opère dans les DSI et chez les acteurs de l'offre informatique. Seulement, ce logiciel s'il est parfois gratuit présente un coût : par l'internalisation des compétences, par l'achat d'un service de support, etc. A travers des témoignages d'acteurs ayant fait le choix du libre ou proposant des produits ayant un impact fort sur les centres de coûts, Aristote nous fait réfléchir sur le libre à coût raisonné."

Programme

8h45-9h15 Accueil-café

9h45-10h Badr Chentouf (Dir. Smile Consulting) Vers une vraie alternative du libre dans les logiciels d'aide à la décision (BI)

10h-10h45 Xavier Guimard (LCL, Direction générale de la Gendarmerie Nationale) Les raisons qui ont conduit la gendarmerie nationale a choisir le libre

10h45-11h30 Alexandre Zapolsky (PDG de Linagora et Président de la FNILL) 10 ans de stratégie d'usage de l'Open Source dans les très grandes organisations en France

11h30-11h45 Pause café

11h45-12h30 Genevieve Romier (Resp. tech. projet PLUME, UREC-CNRS) Laplace des logiciels libres dans l'enseignement supérieur et larecherche, dans l'administration, en France, en Europe et dans le monde

12h30-13h45 Déjeuner (salle aquarium)

13h45-14h30 Alexis de Lattre (co-fondateur de la société ANEVIA) Une PME entièrement libre

14h30-15h15 Daniel Poudroux (Res. informatique, UMR Environnement et Grandes Cultures INRA) La virtualisation du poste client: une approche Opensource

15h15-15h30 Pause

15h30-16h15 Ludovic Hirlimann (Resp. assurance qualité, Mozilla Messaging) Le logiciel libre -vue de l'éditeur, vue de l'intérieur

16h15-17h30 Tom Lehmann (CTO, Turbohercules) Continuité d'exploitation (Business Continuity) d'un ordinateur central (mainframe) et anticipation de perte de données en cas de sinistre àl'aide de l'émulateur Hercules

17h30-18h30 Laurent Séguin (Vice-président, AFUL) Les différents modèles économiques du libre

18h30 Fin du séminaire 

Fiche logiciel à valider
  • Création ou MAJ importante : 29/04/10
  • Correction mineure : 28/08/13
Mots-clés
Fiche en recherche de relecteurs
Cette fiche est en recherche de relecteurs. Si vous êtes intéressé(e)s, contactez-nous !

phpCollab : gestion collaborative de projets via le web

Ce logiciel est en cours d'évaluation par la communauté PLUME. Si vous utilisez ce logiciel en production dans notre communauté, merci de déposer un commentaire.
  • Site web
  • Système :
  • Téléchargement
  • Version évaluée : 2.5
  • Langue(s) de l'interface : français
  • Licence : GPL

    La version 2.5 est sous GPL

Description
Fonctionnalités générales

PhpCollab est un gestionnaire collaboratif de projets.

Il permet la gestion de projets par phases, tâches, sous-tâches associée à un site web communautaire. Il permet en outre de partager fichiers, discussions, tâches, support avec des utilisateurs authentifiés extérieurs pour chaque projet.

Les fonctionnalités principales sont :

  • gestion de projets (tâches, sous-tâches, diagramme GANTT, suivi des tâches) multi-lingue
  • gestion des membres 'utilisateurs' par rôle/profil (un utilisateur peut appartenir à plusieurs projets)
  • gestion de calendriers
  • gestion des modifications (notification aux membres par email ou SNMP selon profil utilisateur modifiable)
  • production de rapports (états d'avancement, historiques, exports des rapports en PDF)
  • partage de documents avec (auto-)incrémentation de versions et commentaires (un fil de discussion par fichier), état du document (approuvé, approuvé avec changements, approbation requise, aucune approbation nécessaire, non approuvé), trace des modifications
  • partage d'informations ciblées avec le site 'client' (discussions, fichiers, tâches, ...)

Sa particularité est d'autoriser pour chaque projet, un volet "client" sous forme de site web comportant autorisant des membres authentifiés à partager des discussions, fichiers, tâches. Ces membres "client" ne font pas partie de l'équipe projet et n'accèdent qu'aux informations "partagées" par l'équipe projet correspondant.

Autres fonctionnalités

Application JavaScript / PHP / SQL (MySQL, PostGresSQL) présentant pour chaque projet une interface web pour les membres de l'équipe et une interface web optionnelle pour les 'clients'.

Le code est entièrement ouvert.

Interopérabilité

Peu d'interopérabilités, surtout liées à l'aspect ouvert du logiciel :

  • Base de données SQL (MySQL, PostgreSQL)
  • Export des rapports en PDF
  • Passerelle (intégrée) avec Mantis BT
  • Export CSV des projets
Contexte d'utilisation dans mon laboratoire/service

Utilisation interne : suivi des projets internes
Utilisation communautaire : projets multi-partenaires, les partenaires sont membres des projets, les experts externes, consultants, membres d'autres projets proches, etc. sont 'clients' et peuvent être consultés via les notifications, partages de fichiers pour avis, fils de discussion, etc.

Limitations, difficultés, fonctionnalités importantes non couvertes
  • gestion de projets minimum (pas de gestion des antériorités des tâches)
  • pas de tâches cumulatives automatiques
  • pas de fonctions évoluées de gestion des tâches (chemin critique, diagrammes PERT, etc.)
  • l'ordre d'affichage des tâches dans GANTT n'est pas évident
  • le cloisonnement entre projets est ouvert par défaut : les membres d'une équipe projet peuvent consulter en lecture les autres projets dont ils ne sont pas membres, une option de l'outil permet de cloisonner les projets entre eux et interdire cette consultation
  • l'esthétique des sites (projet et clients) est très limitée et identique pour tous les projets (excepté un logo par client)
Environnement du logiciel
Plates-formes

L'outil fonctionne en client-serveur web, il nécessite un serveur web avec PHP et une base SQL

Le client est multi-plateforme, OS indépendant (HTTP/JavaScript)

 

Logiciels connexes

Utilisation de la librairie JPGraph pour la génération de graphiques, licence QPL 1.0 (Qt Free Licensee) pour les versions récentes non-commerciales.

La librairie JPGraph (v1.5.2 en GPL) est founie en standard avec certaines versions Linux (Ubuntu Karmic).

JPGraph s'appuie sur la librairie gd.

Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement

Le type de collaboration n'est pas clairement affiché.

Eléments de pérennité

Le projet a été en pause pendant 6 mois (déc. 2009 à mars 2010) alors que la version 3 était annoncée pour octobre 2009.
Une annonce de fin mars planifie une sortie avant l'été 2010.

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur

Manuel utilisateur (46 pages) en anglais
Manuel d'installation (5 pages) en anglais

http://sourceforge.net/projects/phpcollab/files/do... chapitre 'documentation'

Contributions

Guide des développeurs sur le wiki : http://www.php-collab.com/dokuwiki/doku.php?id=dev...

Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 20/04/10
  • Correction mineure : 22/07/13
Mots-clés

STUdS : outil de sondage pour déterminer une date ou un lieu de réunion, un thème de travail, .....

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Site web
  • Système : UNIX-like, Windows, MacOS X
  • Version actuelle : 0.6.4 - mars 2010
  • Licence(s) : CeCILL-B
  • Etat : validé (au sens PLUME), diffusé, stable
  • Support : maintenu, sans développement en cours
  • Concepteur(s) : Guilhem Borghesi
  • Contact concepteur(s) : contact
  • Laboratoire(s), service(s)... : Univ Strasbourg

 

Une fiche logiciel décrit plus en détail ce développement, consultez la pour plus d’informations : STUdS
Fonctionnalités générales du logiciel

STUdS permet de déterminer facilement une date ou un lieu de réunion à plusieurs en évitant le casse-tête des envois de mails. Chaque participant peut ajouter ses choix de vote dans une page web et les meilleurs résultats sont affichés automatiquement.

Cette application ne demande aucune authentification car elle se base sur des URL générées aléatoirement.

Elle permet de mettre en place l'équivalent du service Doodle (cf fiche Fiche Plume).

Contexte d’utilisation du logiciel

Le logiciel est utilisé par les personnels de l'Université de Strasbourg et même au-delà par certains particuliers, au travers du service STUdS mis en œuvre (cf fiche Fiche Plume) par ce logiciel.

Fiche logiciel validé
  • Création ou MAJ importante : 14/02/11
  • Correction mineure : 17/02/12
Mots-clés
Pour aller plus loin

GRR : réservation de ressources (salles, matériels), agenda...

Description
Fonctionnalités générales
  • GRR (Gestion et Réservations de Ressources) est un logiciel particulièrement adapté pour la réservation de salles ou de matériel.
  • Plus généralement, il peut être utilisé pour gérer la réservation de n'importe quelle ressource.
  • Il peut être utilisé comme agenda partagé.
Autres fonctionnalités

  • Possibilité d'accès par un formulaire d'identification ou à travers un SSO ;
  • Connexion LDAP possible, dans ce cas les utilisateurs seront considérés comme des utilisateurs donc ayant le droit d'effectuer des réservations ;
  • Gestion fine des droits des utilisateurs ainsi que de leur compte : activation/désactivation du compte, affectation de profils/privilèges (administrateur du logiciel, administrateurs de domaines, gestionnaires de ressources) ;
  • Création, suppression, modification des ressources ;
  • Possibilité de classer les ressources par domaine, donc de gérer plusieurs sites ;
  • Possibilité de restreindre l'accès à certains domaines ;
  • Ajout de champs additionnels pour chaque domaine ;
  • Possibilité de réserver ou non sur des périodes déterminées, et de créer des jours de fermeture ;
  • Création de fiches de présentation décrivant les ressources ;
  • Définition de types de réservations, chacun associé à une couleur ;
  • Possibilités lors d'une opération de réservation : décrire brièvement ou complètement la réservation, associer un type prédéfini, réserver plusieurs ressources du domaine, définir des périodicités, ...
  • Envois de mails aux gestionnaires de ressources et possibilité d'envoi de mails à d'autres utilisateurs, lors d'une demande de réservation ;
  • Affichage des réservations par jour/semaine/mois ;
  • Possibilité de faire des recherches avancées, d'éditer des rapports et des décomptes ;
  • Journalisation/historique des connexions ;
  • Sauvegarde de la base.

Interopérabilité

  • Import d'un fichier utilisateur au format CSV ;
  • Connexion LDAP ;
  • SSO ;
  • Export de la base au format SQL ;
  • Export des statistiques de réservation au format CSV.

Contexte d'utilisation dans mon laboratoire/service
  • Une première instance a été mise en production en 2007, afin de permettre à tout le personnel de l'Observatoire de réserver des salles sur les sites de Paris et de Meudon. Elle est utilisée par environ 900 personnes. L'accès à l'application est libre, les personnes envoient un mail de demande de réservation aux gestionnaires de domaines et de ressources.
  • Une deuxième instance est configurée afin de permettre la gestion des visites de l'observatoire.
  • D'autres instances sont utilisées comme agendas partagés.
  • Ce logiciel est également utilisé pour des prêts de matériels informatiques (portables et vidéo-projecteurs).
Limitations, difficultés, fonctionnalités importantes non couvertes

Il manque une gestion plus fine des droits utilisateurs, lorsque l'on choisit de paramétrer une connexion LDAP. Il serait intéressant que l'utilisateur LDAP ne puisse pas par défaut effectuer des réservations.

Environnement du logiciel
Plates-formes

PHP(>4.1.0)/MySQL

Autres logiciels aux fonctionnalités équivalentes

phpMyResa (voir la fiche PLUME)

Rapla

Environnement de développement
Type de structure associée au développement

Le logiciel a été programmé à l'origine par trois personnes : Laurent Delineau, Mathieu Ignacio et Marc-Henri Pamiseux. Actuellement il y a une vingtaine de contributeurs dont des entreprises.

Eléments de pérennité

La liste de diffusion est très active. Le site GRR est très bien architecturé, et la documentation du logiciel est également bien fournie.

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums

La FAQ se trouve ici :
http://grr.mutualibre.org/spip.php?article16
La page permettant de s'inscrire à la liste de diffusion:
http://grr.mutualibre.org/spip.php?article12

Documentation utilisateur

La documentation se trouve ici :
http://grr.mutualibre.org/spip.php?article14

Contributions

Pour contribuer au logiciel :
http://grr.mutualibre.org/spip.php?article42

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

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

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

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

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

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

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

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

Cas d'étude

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

Ma réponse

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

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

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

Deuxième cas d'étude

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

Ma réponse

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

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

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

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

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

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

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

Droits d'auteur

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

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

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

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

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

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

L'œuvre

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

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

La traçabilité du code

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

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

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

Les auteurs

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

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

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

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

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

Les droits patrimoniaux

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

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

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

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

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

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

La documentation d'un logiciel et les droits patrimoniaux

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

La cession des droits

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

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

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

Le personnel d'un laboratoire de recherche

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La mobilité des personnels

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

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

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

Choisir une licence

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

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

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

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

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

Respecter une licence

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

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

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

Documents pour établir un dossier du logiciel

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

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

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

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

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

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

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

Références

Fiche logiciel validé
  • Création ou MAJ importante : 21/09/13
  • Correction mineure : 21/09/13
  • Rédacteur de la fiche : Guilhem Borghesi - un des concepteurs du logiciel - Direction Informatique Univ. Strasbourg (Université de Strasbourg)
  • Relecteur(s) : Antoine Migeon (Univ Bourgogne Centre de Calcul CRI)
    Thibault Le Meur (Supélec)
  • Contributions importantes : Véronique Baudin a été le responsable thématique initial.
  • Responsable thématique : Anne Durand (CLEO)
Mots-clés

STUdS : outil de sondage pour déterminer une date ou un lieu de réunion, un thème de travail, .....

Une fiche Dév Ens Sup est en relation avec cette fiche, consultez-la pour plus d'informations : STUdS
Description
Fonctionnalités générales
  • STUdS permet de déterminer facilement une date ou un lieu de réunion à plusieurs en évitant le casse-tête des envois de mails. Chaque participant peut ajouter ses choix de vote dans une page web et les meilleurs résultats sont affichés automatiquement.
    Cette application ne demande aucune authentification car elle se base sur des URL générées aléatoirement.
  • Elle permet de mettre en place l'équivalent de Doodle ou du service de sondage fourni par RENATER, basé sur Foodle.
Interopérabilité
  • En entrée, il n'y a pas d'interopérabilité.
  • En sortie, le système crée des fichiers CSV, des fichiers ICS et des fichiers PDF.
Contexte d'utilisation dans mon laboratoire/service
  • Le logiciel est utilisé par les personnels de l'Université de Strasbourg et même au-delà par certains particuliers, au travers du service STUdS mis en œuvre par ce logiciel.
    Son utilisation est très fréquente ; pour l'exemple, plusieurs sondages sont créés par jour et de nombreux votes ont lieu également.
    Le degré de satisfaction des utilisateurs est excellent si l'on se base sur le nombre extrêmement faible de remarques et suggestions d'amélioration.

  • A Supélec, le logiciel a été mis en exploitation depuis peu avec un excellent retour utilisateur. Des modifications du code ont cependant été nécessaires. L'appropriation du produit par les utilisateurs a été immédiate (nombreux questionnaires déjà créés avant l'ouverture officielle du service car les bêta testeurs avaient déjà communiqué autour de la solution) : j'ai tout de même été amené à modifier quelques textes pour aider et guider les utilisateurs.

  • Université de Bourgogne : pas encore en production à ce jour. On apprécie le fait que ce logiciel est facilement personnalisable (via CSS) et qu'il est déjà traduit en plusieurs langues.

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

De nombreux utilisateurs ont été amenés a réaliser des modifications mais le chef de ce projet opensource est trop chargé pour réaliser les reviews de code et appliquer les patches. C'est dommage car nombreux sont ceux qui pourraient bénéficier de ces améliorations. Il faudra certainement trouver une autre organisation communautaire pour garantir que le logiciel soit pérenne.

Il faut impérativement corriger les failles par injection SQL dans certains formulaires avant la mise en production. La base de données est également peu protégée (type TEXT partout).

Fonctionnalités non couvertes :

  • Support de PostgreSQL seulement dans la version de base (patch disponible auprès d'Antoine Migeon/uB).
  • Réponse Oui/Non, mais pas Peut-être comme c'est le cas avec Doodle.
  • Authentification pour la création ou l'administration d'un sondage.
Environnement du logiciel
Plates-formes
  • Apache, PostgreSQL, PHP.
  • Il faut que le serveur soit configuré pour accepter l'encodage UTF-8.
Logiciels connexes

Navigateurs pour accéder à l'application : Firefox, Opéra, Konqueror, Safari, Links, IE.

Autres logiciels aux fonctionnalités équivalentes
  • Doodle : seul le service est disponible (le logiciel n'est pas distribué), pas de licence de distribution. Avec authentification optionnelle. Service gratuit mais non libre. Affichage de publicités sur les pages de sondage.
  • RDVZ : licence GPLv3 et licence CeCill. Avec authentification. Gratuit et libre. Pas de publicité.
  • Framadate : fork de Studs développé par Framasoft.
  • Service de sondage fourni par RENATER : basé sur Foodle.
Environnement de développement
Type de structure associée au développement

Direction Informatique de l'Université de Strasbourg

Eléments de pérennité

Dépôt des sources sur Sourcesup, mise en place d'un dépôt de sources au sein de la structure hébergeante.

Références d'utilisateurs institutionnels
  • Université de Strasbourg : actuellement, 600 sondages en production. Environ 3000 sondages déjà créés. Un nombre d'usagers dépassant le millier depuis la mise en service de l'application.

  • Extrait de messages d'autres sites début mars 2010 :

A Supélec, actuellement 40 sondages actifs une semaine après l'annonce de l'ouverture de ce service.

Observatoire de Paris : l'application est installée, et sera mise en production rapidement.

ESPCI ParisTech : en production à l'ESPCI ParisTech.

Univ de Bourgogne : nous l'avons mis en place à l'université de Bourgogne. Ce n'est pas encore vraiment en production (les utilisateurs ne sont pas au courant). Corrections php, custom et intégration de MDB2 pour l'interface à la base de données (MySQL). J'ai envoyé les modifications à Guilhem Borghesi. Outil simple et efficace. Facile à administrer et à modifier.

IPB : nous l'avons mis en place à l'ipb. Après correction du php pour un problème de « quotage » des données injectées dans la base. Correction envoyées également à l'auteur.

Environnement utilisateur
Documentation utilisateur

Les sources contiennent un fichier README et un fichier INSTALL qui aident à installer l'application.
Les pages de l'application contiennent l'aide nécessaire à l'utilisation du logiciel.

Divers (astuces, actualités, sécurité)

Il est impératif d'appliquer un patch pour se prémunir contre des attaques de type SQL injection.
Étant donné que le serveur n'utilise pas d'authentification, et qu'il est certainement ouvert à l'extérieur (utile pour communiquer avec des interlocuteurs extérieurs), le patch CAPTCHA est un plus pour éviter des attaques de DoS sur la base de données de Studs et l'envoi de Spam automatique par Studs sous l'influence d'un robot.

Contributions

Actuellement, des contributions sont réalisées par des personnes qui installent ce logiciel sur leur site , on peut citer :

  • Thibault Le Meur (Supélec), contributions non encore validées/intégrées : corrections PHP, patch SQL injection, patch de customisation, patch CAPTCHA.
  • Antoine Migeon, université de Bourgogne : corrections PHP et ajout d'une couche d'abstraction à la base de données (module PEAR MDB2) afin de pouvoir utiliser MySQL. Modifications non intégrées au projet actuellement.

Il y a certainement matière à créer une communauté pour assurer la pérénité de ce logiciel.

Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 01/03/10
  • Correction mineure : 01/03/10
Mots-clés

cses : service web pour la rédaction des rapports et l’aide à la décision des commissions de spécialistes

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Système : UNIX-like, Windows, MacOS X
  • Etat : utilisé en interne
  • Support : maintenu, développement en cours
  • Concepteur(s) : Agnès Joly Carrette
  • Contact concepteur(s) : ajoly@math.univ-lyon1.fr
  • Laboratoire(s), service(s)... : ICJ

 

Fonctionnalités générales du logiciel

Le service web "cses" (http://cses25-26.univ-yon1.fr, ouvert uniquement quand c'est nécessaire) fait état des postes de Professeurs et de Maîtres de Conférences mis au concours l'année en cours. Il est relié à une base de données de type Mysql dans laquelle ont été reportés les champs essentiels des dossiers de type Excel transmis par l'Education Nationale. Ce service possède deux fonctions fondamentales :

  1. Rédaction des rapports. Il donne aux rapporteurs, pour chaque candidature pour laquelle il doit rapporter, l'accès à un formulaire qui comporte trois parties :
    1. un descriptif succinct du dossier administratif de la candidature,
    2. une partie concernant les publications, à compléter par ses soins et ceux de l'autre rapporteur,
    3. un espace pour rédiger son rapport et donner son appréciation sur la sélection de la candidature au(x) poste(s) candidaté(s).

    Les parties 1. et 2. du formulaire concernant une candidature sont identiquement visibles par chacun des deux rapporteurs.
    La partie 3. est réservée au rapporteur qui traite le formulaire. Son contenu n'est pas et ne sera pas visible par l'autre rapporteur.

  2. Aide à la décision de sélection. Au cours de la réunion de la commission, trois possibilités peuvent être actives simultanément sur des ordinateurs portables personnels des membres de la commission et/ou un écran de la salle :
    1. visualiser en une page, le sommaire de chaque dossier complété avec les rapports et les propositions de sélection de chacun de ses deux rapporteurs,
    2. introduire et/ou modifier un avis de sélection au poste considéré par la réunion de la commission,
    3. visualiser la liste globale de toutes les candidatures triées par avis.

    Les possibilités 1. et 3. sont accessibles à tous les membres de la commission détenant un ordinateur personnel et au membre agissant en gestionnaire de la visualisation sur écran.
    La possibilité 2. n'est accessible qu'au président de commission par accès spécifiquement réservé.

Contexte d’utilisation du logiciel

Le service "cses" permet l'édition des rapports et se révèle être un outil d'aide à la décision pour les commissions de spécialistes chargées de sélectionner les candidatures aux postes d'enseignants (Maîtres de Conférence et Professeurs des Universités).

Il a été développé en 2006 pour aider la commission 25-26 de l'UCBL à sélectionner mille candidatures se présentant à dix postes. Depuis lors, il a fonctionné chaque année pour les mêmes commissions 25-26 et associées.

Il pourrait être utilisé par toute commission de spécialistes.

Son usage exige d'effectuer immédiatement après la réception des dossiers de l'E.N. et en un minimum de jours :

- la transcription d'une sélection des éléments du tableau Excel en une base Mysql,
- la détermination de l'ensemble de tous les rapporteurs et leurs affectations des dossiers,
- la détermination des codes spécifiques d'accès réservés.

Après quoi les rapporteurs peuvent traiter les dossiers via l'interface web, à leur gré jusqu'à l'heure des réunions des commissions.
Après délibération des commissions, les rapports peuvent être édités pour être transférés à l'administration.

Publications liées au logiciel

Cf site http://cses25-26.univ-yon1.fr (ouvert uniquement lorsqu'il y a des postes au concours)

Syndiquer le contenu