Réservation de ressources : Généralités (1/3)

Dans le cadre d’une veille technologique pour un de nos clients publics, nous avons étudié le sujet de la réservation de ressources. Il s’agit de gérer les salles et les réservations de salles. L’article suivant constitue la 1ère partie de la série sur les généralités.

1. Présentation

La réservation d’une salle de réunion répond aujourd’hui à un besoin essentiel dans les grandes organisations. Elle assure aux collaborateurs la disponibilité de la salle au moment prévu offrant un confort certain. Cela se traduit par la réduction du temps mort et du stress engendré par les interruptions de réunion et la recherche d’une salle libre. Pour l’entreprise, elle permet une optimisation et un suivi de l’utilisation des espaces de travail et offre efficacement des prestations complémentaires.

Aujourd’hui, la tendance est de permettre aux collaborateurs de réserver directement en ligne leur salle de réunion. Le gestionnaire se libère des tâches de réception et de traitement des demandes et n’a plus qu’un rôle de supervision et de contrôle. Le guichet en libre-service de réservation de salle contribue sans aucun doute à la modernisation de l’espace de travail et plus globalement à la productivité de l’entreprise.

2. La réservation de ressources

2.1. Généralités

Un outil de réservation de ressources doit répondre aux enjeux suivants :

  • Être suffisamment configurable pour s’adapter à la complexité et à la diversité de l’infrastructure de l’Administration
  • Avoir la robustesse pour gérer la centaine de salles de réunion, les milliers d’utilisateurs du service, les réservations et les envois d’email automatiques au quotidien
  • Disposer d’une interface simple et conviviale pour permettre à tous les utilisateurs de voir les disponibilités des salles et de les réserver facilement

Nous allons décrire dans les parties suivantes les fonctionnalités attendues d’un tel outil. Celles-ci seront notamment reprises dans l’analyse QSOS des outils retenus.

2.2. Gestion de salles

2.2.1. Calendrier des salles

Le calendrier permet d’avoir une vue d’ensemble sur les réservations et les disponibilités d’une salle. L’affichage sous forme de tableau est privilégié pour voir les réservations sur une journée, une semaine ou un mois. L’utilisateur doit pouvoir cliquer sur la tranche horaire de la journée qui lui convient dans le calendrier pour faire une réservation rapide.

2.2.2. Groupes de salles

Les salles peuvent être rassemblées par site, bâtiment ou secteur pour faciliter la gestion. L’intérêt est de pouvoir visualiser le calendrier de l’ensemble d’un groupe de salles ou de chercher une salle disponible dans une zone particulière.

2.2.3. Champs personnalisables pour les salles

Chaque salle peut avoir des caractéristiques particulières selon la taille et la configuration. Le but est de permettre à l’utilisateur d’exprimer ses préférences lors de la réservation. Plus généralement, l’outil doit permettre de créer facilement des champs personnalisables pour les salles pour s’adapter au contexte de l’Administration.

2.2.4. Privatisation et gestionnaire de salles

La réservation doit pouvoir être organisée pour éviter les conflits de réservation en fonction des conditions d’accès aux salles. Une salle peut :

  • être en libre réservation ou nécessiter l’accord au préalable d’un gestionnaire
  • être publique ou privé c’est à dire restreinte à un nombre limité de personnes

Pour une grande organisation, la présence d’un gestionnaire de salle ou de secteur est obligatoire pour traiter les demandes de réservation ou tout du moins gérer les droits d’accès sur la salle ou les secteurs. Idéalement il doit exister un système de rôles hiérarchisé (administrateur central, gestionnaire de zone, utilisateur, prestataire, etc.)

2.3. Gestion des réservations

2.3.1. Suivi des réservations et gestion de conflits

Le demandeur doit pouvoir suivre le statut de sa réservation en particulier lorsqu’elle est en attente de validation, validée ou refusée. Il doit également pouvoir modifier ou annuler sa réservation à tout moment. Enfin l’outil doit prévenir les utilisateurs des éventuels conflits de réservation.

2.3.2. Réservation à répétition

Le demandeur doit pouvoir faire une réservation périodique (journalier, hebdomadaire, mensuel, etc.) de manière simple, c’est à dire sans devoir les faire une par une.

2.3.3. Envoi de notification et rappel automatique

Il est important que le demandeur soit notifié par e-mail lors d’un changement de statut de sa réservation. De même que l’outil doit permettre d’envoyer un rappel automatique quelques jours avant au demandeur, notamment pour lui demander d’annuler la réservation si la réunion n’est plus d’actualité.

2.3.4. Restriction des réservations

La restriction des réservations permet de poser des limites aux demandeurs. Il peut par exemple s’agir d’un système de « quota », d’une plage horaire des salles ou une plage d’ouverture et de fermeture des réservations.

2.3.5. Personnalisation des formulaires de réservation

L’outil doit permettre de personnaliser les formulaires de réservation pour s’adapter au contexte de l’Administration. En particulier les champs de saisie doivent être personnalisables.

2.4. Gestion des prestations

2.4.1. Ajout et personnalisation des prestations

Les prestations sont des services qui viennent s’ajouter aux réservations de salle. Ce sont des services variés qui demandent une préparation en amont de la réunion : bouteille d’eau, traduction, équipement audiovisuel, etc. L’outil doit permettre de choisir les prestations offertes ainsi que les quantités.

2.4.2. Interface et notification prestataires

Il est important que les fournisseurs puissent être notifiés de manière automatique des réservations qui nécessitent des prestations. De même qu’un accès dédié aux prestataires au sein de l’outil. En particulier, le prestataire doit pouvoir saisir la réalité des prestations effectuées et/ou consommées afin que les reporting tiennent compte de la réalité et non de la prévision.

2.4.3. Restriction des prestations

L’outil doit pouvoir limiter la réservation de prestations. Les prestations peuvent être réservées à certaines salles ou dans le cas des équipements matériels, être limitées en termes de nombre.

2.5. Suivi et pilotage

2.5.1. Tableau de bord

L’outil doit présenter au sein d’une page un récapitulatif des réservations en cours du demandeur, des réunions à venir de l’utilisateur ou sur un site spécifique, des salles disponibles. Le but est d’offrir une vue synthétique de l’activité des salles de réunion en particulier à destination des agents d’accueil, du secrétariat ou des prestataires.

2.5.2. Statistiques et rapports

L’outil doit pouvoir générer des statistiques et rapports pour que les gestionnaires suivent l’utilisation des salles d’un site ou d’un groupe d’utilisateurs. L’export de ces données est également souhaitable, de même que la génération automatique de rapports d’activité.

2.5.3. Suivi de l’usage et facturation

Il doit être possible de mesurer l’usage d’une salle par un demandeur et d’évaluer le coût financier d’une telle réunion en tenant compte des prestations demandées, de la durée et d’autres éléments du contexte. L’objectif est d’avoir un aperçu des consommations par entité et de pouvoir au besoin faire une refacturation.

2.6. Ergonomie

L’ergonomie est un des points faibles de l’outil ROLL’S existant et est un frein à la généralisation de celui-ci. Le nouvel outil de réservation de ressources doit avoir une interface conviviale et être facile d’utilisation pour les utilisateurs.

2.7. Technique

L’outil doit pouvoir s’intégrer relativement facilement dans l’infrastructure existante de l’Administration en particulier :

  • le support de LDAP permet d’utiliser l’authentification avec l’annuaire des agents de l’Administration
  • l’export du calendrier au format .ICS permet d’intégrer des événements sur les agendas Outlook, Thunderbird, …
  • la présence d’une API est utile pour développer une interface complémentaire pour les utilisateurs

L’outil doit enfin se conformer aux prérequis techniques de l’Administration (technologie PHP ou Java, base de données MySQL ou PostgreSQL), être suffisamment robuste pour une grande structure et pouvoir s’exécuter sur la diversité du parc logiciel (navigateur, appareil, systèmes d’exploitation…)