Réservation de ressources : Outils libres (2/3)

2.2. Converture fonctionnelle

2.2.1. Gestion des salles

Dans BOOKED, il est possible de configurer assez finement les salles que ce soit :

• La description, le contact, le lieu, le groupe de salle, le type de salle, la capacité

• La planning (durée d’un créneau, horaire d’ouverture et de fermeture, période de réservation, la durée minimale et maximale d’une réunion, l’espacement entre deux réunions…)

• L’administrateur et la nécessité d’obtenir son accord pour réserver

• Les permissions sur les salles pour les utilisateurs et groupes d’utilisateurs

• Autres champs personnalisables (saisie texte, sélection liste ou coche case)

Les groupes et les types de salles n’ont pas de paramètres supplémentaires et servent surtout pour sélectionner et configurer plusieurs salles en même temps.

Les utilisateurs sont organisés au sein de groupes avec des droits particuliers. Chaque groupe a un administrateur qui se charge d’ajouter ou de supprimer des membres.

2.2.2. Gestion des réservations

Chaque réservation dispose d’un numéro de référence unique. Les réservations peuvent être visualisées de plusieurs manières :

• Sur le planning par salle, par journée de la semaine et par heure avec plusieurs options d’affichage

• Sur le tableau de bord qui liste les réservations à venir de l’utilisateur, l’état en cours des salles dont l’utilisateur a les permissions et les annonces générales

• Sous forme de liste des réservations avec des options de filtre et de recherche

Les réservations peuvent être à répétition, être exceptionnellement suspendues, accueillir des participants et/ou des invités et avoir d’autres champs personnalisables.

Il est possible au demandeur de programmer des notifications et des rappels automatiques à date et heure personnalisables.

2.2.3. Gestion des prestations

BOOKED permet de gérer de manière basique les prestations. Il est possible de définir les noms et les quantités disponibles / réservées des prestations. Cependant, il n’est pas possible de définir des catégories de prestations ou de limiter les prestations à certaines salles.

2.2.4. Suivi et pilotage

BOOKED permet d’avoir un assez bon suivi et pilotage avec le tableau de bord personnalisé. Les rapports et statistiques peuvent être générés avec de nombreuses options en particulier un suivi de l’usage des salles sur une période, par utilisateur ou groupe d’utilisateur sur une salle ou un groupe de salles. Les données peuvent être exportées sous format graphique ou CSV.

3.2.2.5. Ergonomie

BOOKED dispose d’une relative bonne ergonomie. Les nombreuses commandes sont organisées dans une barre de menus. Les couleurs renseignent sur le statut des réservations.

2.3. Effort d’intégration

L’installation de BOOKED ne pose aucune difficulté particulière. Il nécessite un serveur Apache, une base de données MySQL 5.0+ et la technologie PHP 5.3+. Il est possible également d’activer n’importe quelle autre base de donnée MDB2 donc du PostgreSQL, cependant cette méthode n’est pas officiellement supportée¹. Les autres configurations à faire sont :

• Le serveur e-mail pour l’envoi des notifications et le rappel automatique

• La connexion LDAP avec l’annuaire de l’administration, la saisie des paramètres des utilisateurs et des groupes

• La saisie des caractéristiques des salles et des secteurs

Le code source PHP peut être complexe à manipuler notamment à cause de la complexité fonctionnelle de BOOKED et du manque de commentaires dans les fichiers.

Les fonctionnalités à développer pour couvrir les besoins de l’Administration sont :

• La gestion des prestations avec notamment l’interface pour le prestataire et les notifications automatiques et la restriction des prestations

• L’ajout de la facturation au système de suivi de l’usage actuel

• La mise à jour de l’interface pour s’adapter à la réservation de salles (désactivation de fonctionnalités non utilisées)

2.4. Conclusion

BOOKED se distingue par sa richesse fonctionnelle et sa maturité. La solution s’adapte parfaitement à l’usage dans une grande organisation et couvre la plupart des besoins de l’administration. L’essentiel de l’effort d’intégration se concentre sur la maîtrise du fonctionnement et le paramétrage de la solution. BOOKED est également la solution qui dispose de la plus grande communauté.

3. Oxalto Room Booking System (ORBS)

Pays d’origine : Grande-Bretagne

Licence : Apache v2

Date de création : 2013

Technologie : ColdFusion / Java

Site officiel : https://roombooking.readme.io/

Démo en ligne : http://roombooking.oxalto.co.uk/

3.1. Présentation

OxAlto Room Booking System (ORBS) est un système de réservation de salle utilisant JQuery, Fullcalendar.js et cfWheels. Ce dernier composant nécessite un serveur d’application CFML comme Railo ou Lucee, qui tourne sous Java. ORBS est développé par Tom King, un développeur web basé à Oxford dans le secteur éducatif.

ORBS est hébergé sur la forge Github où Tom King traite également les bugs et demandes de nouvelles fonctionnalités. Il n’y a pas d’autre contributeur actif mis à part lui.

ORBS se distingue par son interface moderne, simple et intuitive. La page d’accueil affiche directement un calendrier coloré avec choix du site et des salles à afficher. La réservation s’organise essentiellement autour des salles (Locations) et des prestations (Ressources). Notons que l’interface est disponible uniquement en anglais.

3.2. Converture fonctionnelle

3.2.1. Gestion des salles

Pour chaque salle, il est possible de renseigner un secteur, une description, une couleur qui sera celle de la réservation et la disposition. ORBS permet également d’ajouter tout autre type de champs à la salle (saisie texte, sélection dans une liste, case d’option, bouton radio…). Il n’y a pas l’option pour privatiser une salle ou lui associer un administrateur.

3.2.2. Gestion des réservations

Le calendrier peut afficher l’ensemble des réservations d’un secteur sur une journée ou une semaine et les couleurs permettent de repérer les salles qui sont réservées. La saisie d’une réservation se fait directement en cliquant sur le créneau souhaité sur le calendrier. Il est possible ensuite de :

• éditer le nom

• saisir une description plus longue

• changer l’horaire de début et de fin

• saisir un contact avec ses coordonnées avec l’option d’envoi d’email

• choisir les prestations souhaitées

• choisir la périodicité (unique, quotidien, hebdomadaire, mensuel…)

Il est également possible d’ajouter tout autre type de champs à la réservation (saisie texte, sélection dans une liste, case d’option, bouton radio…).

Il est enfin possible de voir les réservations sous forme de liste avec des options de filtres et de recherche.

3.2.3. Gestion des prestations

ORBS gère les prestations avec la possibilité de les regrouper dans des catégories, de les restreindre à certaines salles et de choisir si la prestation est de type générique ou est un élément unique. Il n’y a pas d’interface ou de notification pour le gestionnaire de la prestation.

3.2.4. Suivi et pilotage

ORBS ne dispose pas de suivi ou de pilotage si ce n’est la possibilité d’avoir un affichage simplifié des cinq rendez-vous à venir pour une ou toutes les salles.

3.2.5. Ergonomie

Le point fort de ORBS est son interface utilisateur conviviale grâce à l’utilisation des technologies Web dynamiques. Une barre de raccourcis permet d’afficher les calendriers des secteurs et des salles souhaités. Un clic sur une réservation ouvre une fenêtre pop-up qui permet d’afficher plus d’informations et de choisir une action (modifier, éditer, copier). Les icônes et les couleurs permettent également de repérer les statuts des réservations et les salles. L’outil peut être utilisé à partir d’un smartphone ou une tablette.

3.3. Effort d’intégration

ORBS est basée sur cfWheels qui requiert un serveur d’application CFML. Deux solutions open source sont disponibles : Railo (version 4.2.x) et Lucee (version 4.5.x). Au-delà de l’installation d’Apache et de mySQL ou PostgreSQL, il est nécessaire de connecter le serveur CFML aux deux premiers. Les autres configurations à faire sont :

• Le serveur e-mail pour l’envoi des notifications

• La connexion LDAP avec l’annuaire de l’administration et la saisie des paramètres des utilisateurs

• La saisie des caractéristiques des salles et des secteurs

Le code source est en CFML, un langage qui ajoute des commandes avancées au HTML pour produire des applications web riches. Le CFML peut être écrit sous forme de tags ou avec CFScript et ressemble au Javascript.

Les fonctionnalités à développer pour couvrir les besoins de l’Administration sont :

• La privatisation des salles et la gestion de secteur

• L’interface pour le prestataire et les notifications automatiques

• Le rappel automatique des réunions

• Les fonctionnalités avancées pour restreindre une réservation (plage horaire, quota, période de réservation…)

• Le suivi et le pilotage que ce soit la génération des statistiques et rapports, le suivi de l’usage et le système de facturation

• La traduction en français de l’interface

3.3.4. Conclusion

ORBS se distingue par son ergonomie et sa simplicité d’utilisation qui réjouiront les utilisateurs. Si de nombreuses personnalisations sont possibles, l’outil manque de fonctionnalités pour sécuriser son usage (gestion des droits sur les salles et gestion de la politique des réservations) et tenir informer les différents acteurs (rappel automatique au demandeur, notification des responsables de secteur et des prestataires). La spécificité du CFML et la faible maturité du produit peuvent être un frein au développement complémentaire et à l’intégration de ORBS.

3.4. Meeting Room Booking System (MRBS)

Pays d’origine : Grande-Bretagne

Licence : GPLv3

Date de création : 2001

Technologie : PHP

Site officiel : http://mrbs.sourceforge.net/

Démo en ligne : http://mrbs.sourceforge.net/mrbs

3.4.1. Présentation

Créé en 2001, Meeting Room Booking System (MRBS) est une application pour réserver des salles ou d’autres ressources. C’est un produit stable qui inclut les fonctionnalités essentielles pour gérer des réservations de réunion. L’interface sous PHP relativement veille ne répond plus aux règles d’ergonomie Web moderne. Cependant la solution est fonctionnelle et les commandes sont réactives.

Il a été à l’origine développé par Daniel Gardner à partir du code de Webcalendar. Le projet a eu plusieurs contributeurs avec récemment l’arrivée de Campbell Morrison qui a implémenté de nouvelles fonctionnalités avec le support d’un autre développeur John Beranek. Il est précisé que les développeurs s’occupent du projet uniquement sur leur temps libre.

Le projet est hébergé sur SourceForge.net. Un grand nombre de bugs et de demandes de nouvelles fonctionnalités sont relevés sur cette plateforme avec peu des réponses. Le contact avec les développeurs du projet se fait essentiellement via une mailing list. Le rythme de publication de nouvelles versions est assez irrégulier et espacé avec en moyenne une version par an depuis 2012.

3.4.2. Couverture fonctionnelle

3.2.2.1. Gestion des salles

Les salles sont gérées par secteur. Seuls deux types d’affichage de calendrier sont disponibles :

• L’ensemble des salles d’un secteur sur une journée

• Une salle sur une semaine / un mois

Les paramètres modifiables pour une salle sont

• le nom et la clé de tri

• la description avec possibilité de saisir du code HTML

• la disponibilité globale

• la capacité

• l’e-mail du gestionnaire de la salle

Notons que la saisie de l’e-mail permet de recevoir les notifications lorsqu’une réservation est réalisée. Elle n’a pas d’incidence sur l’administration des salles. Les administrateurs ont accès à l’administration de tous les secteurs et leurs salles. Les utilisateurs n’ont aucun droit de gestion sur les salles.

Il n’est pas possible d’ajouter des champs personnalisables pour les salles depuis l’interface Web : il faut modifier manuellement la base de données et paramétrer le fichier de configuration.

Pour un secteur, il est possible en plus de :

• changer la plage horaire et les créneaux de réservation

• choisir la période de réservation ou d’annulation

• activer l’obligation d’avoir l’accord d’un administrateur du secteur

• limiter les durées et le nombre de réunions

• autoriser les réservations privées / publiques et leur affichage.

Notons que ces paramètres s’appliquent à l’ensemble des salles qui dépendent du secteur.

3.2.2.2. Gestion des réservations

La saisie d’une réservation se fait directement en cliquant sur le créneau souhaité sur le calendrier. Il est possible ensuite de :

• éditer le nom

• saisir une description plus longue

• changer l’horaire de début et de fin

• mobiliser d’autres salles pour la réservation

• choisir le statut (provisoire ou confirmé)

• choisir le type d’événement (interne / externe)

• choisir la périodicité (unique, quotidien, hebdomadaire, mensuel…)

Notons que la couleur affichée pour la réservation sur le calendrier est celle du type d’événement.

Deux icônes affichent également s’il y a des conflits avec d’autres réunions ou avec les conditions de réservation définies pour le secteur.

3.2.2.3. Gestion des prestations

Les prestations ne sont pas supportées par MRBS. Il est cependant possible d’ajouter des champs personnalisables dans les réservations (selon la méthode décrite précédemment) pour gérer en partie les prestations.

3.2.2.4. Suivi et pilotage

Il n’existe pas un vrai tableau de bord personnalisé pour chaque utilisateur/gestionnaire. Les statistiques peuvent être exportés :

• sous format CSV, HTML ou .ICS

• sur une période définie avec un tri par date ou par salle

• avec des filtres personnalisés

La fonction suivi de l’usage et facturation n’est pas supportée.

3.2.2.5. Ergonomie

L’interface de MRBS est relativement basique et datée. Toutes les commandes sont affichées sur la page et les pages web sont statiques. La navigation entre les dates et les différents modes d’affichage nécessite un temps d’adaptation pour les nouveaux utilisateurs.

3.4.3. Effort d’intégration

L’installation de MRBS ne pose aucune difficulté particulière. Il nécessite un serveur Apache, une base de données MySQL 5.1+ ou PostgreSQL 8.2+ et la technologie PHP 5.3.3+. Les autres configurations à faire sont :

• Le serveur e-mail pour l’envoi des notifications

• La connexion LDAP avec l’annuaire de l’administration

• La saisie des caractéristiques des salles et des secteurs

Le code source PHP est suffisamment annoté pour permettre de faire des développements complémentaires sur MRBS. Les fonctionnalités à développer pour couvrir les besoins de l’Administration sont :

• La refonte de l’interface en particulier de la navigation du calendrier

• Les champs personnalisables supplémentaires pour les réservations et les salles

• La gestion des prestations avec notamment l’interface pour les prestataires et les notifications automatiques et la restriction des prestations

• La fonction de rappel automatique

• La fonction suivi de l’usage et le système de facturation

3.4.4. Conclusion

MRBS se distingue par sa simplicité et son accessibilité. La solution s’adapte plutôt bien à l’usage dans une grande organisation mais n’intègre pas la personnalisation des champs ou la gestion des prestations. Le code PHP permet cependant de développer relativement facilement les fonctionnalités manquantes. Il est également nécessaire de revoir l’interface pour faciliter son adoption.