Faire développer un système de réservation : disponibilité, conflits et cas particuliers

Lundi, peu avant neuf heures. Deux équipes se tiennent devant la même salle de réunion, chacune avec une confirmation d’agenda à la main. L’une a réservé via le tableur que tient l’accueil, l’autre via une invitation dans sa messagerie. Les deux chemins mènent à une « réservation », mais aucun ne connaît l’autre. La scène est banale, et elle montre bien pourquoi un système de réservation est plus qu’un agenda avec un formulaire.

Prenons une entreprise d’une quarantaine de salariés. Elle possède trois salles de réunion, un appareil de mesure dont deux services ont besoin, un utilitaire et deux spécialistes qui se rendent chez les clients. Chacune de ces ressources a ses propres habitudes. L’appareil de mesure figure dans l’agenda d’une collègue, l’utilitaire est géré sur un tableau mural et les spécialistes sont coordonnés par téléphone.

Ce tableau est typique des entreprises qui ont grandi au fil du temps. Cela fonctionne tant qu’une personne a la vue d’ensemble. Si elle s’absente ou que l’entreprise grandit, la fiabilité disparaît et les questions s’accumulent. Quiconque tape « faire développer un système de réservation » dans un moteur de recherche en est généralement arrivé à ce point : la solution existante n’est pas cassée, mais plus personne ne lui fait confiance.

Une réservation isolée est triviale : ressource, début, fin, personne. Cela se complique dès que plusieurs personnes réservent en même temps, que des règles s’appliquent et que le temps cesse d’être univoque. Trois types de défaillance apparaissent dans presque toutes les situations de départ, et aucun ne se corrige par plus de discipline.

Le premier est la double réservation par simultanéité. Deux personnes voient le même créneau libre, cliquent à quelques secondes d’intervalle, et les deux demandes passent, car la vérification « est-ce libre ? » et l’enregistrement sont deux étapes distinctes. Le deuxième est la double réservation par dépendance : celui qui réserve l’utilitaire a aussi besoin d’un conducteur, et celui qui réserve une salle avec vidéoprojecteur bloque du même coup cet appareil. Le troisième est le flou du temps lui-même, de l’heure d’été au fuseau horaire d’un client à l’étranger.

S’y ajoutent des règles qui ne sont écrites nulle part. Une réservation peut-elle encore être annulée le jour même ? Y a-t-il des temps de battement pour ranger ? Les stagiaires peuvent-ils réserver du matériel, et qui valide les exceptions ? Tant que ces règles n’existent que dans les têtes, aucun système ne peut les faire respecter. La première partie du travail ne consiste donc pas à programmer, mais à mettre les choses par écrit.

Avant de créer la moindre interface, il est utile de condenser l’état des lieux en deux questions : qu’est-ce qu’une unité réservable, et quand est-elle considérée comme occupée ? Cela paraît banal et ne l’est pas. Une salle est une unité. Un appareil de mesure avec ses accessoires en forme peut-être une, peut-être deux. Une personne est réservable, mais seulement pendant ses horaires de travail, et ses congés se comportent, sur le plan fonctionnel, comme une occupation.

De cette clarification naît un modèle simple. Chaque ressource a un type, une capacité et des horaires d’ouverture. Une réservation occupe un intervalle de temps sur une ou plusieurs ressources. Les périodes bloquées, la maintenance et les absences sont aussi des occupations, simplement avec un autre motif. Les traiter de la même façon simplifie énormément la vérification : le système se demande seulement si deux intervalles se chevauchent sur la même ressource, quelle que soit la raison de leur existence.

Les décisions intéressantes se prennent à cette étape. Faut-il des temps de battement, et relèvent-ils de la réservation ou de la ressource ? Combien de temps à l’avance peut-on réserver ? Y a-t-il des quotas par service ? Chaque réponse coûte plus tard de l’effort de programmation ou en économise. C’est pourquoi les règles doivent tenir sur une page que le métier et la technique relisent ensemble avant que la première ligne de code ne soit écrite.

Toutes les entreprises ne devraient pas faire développer un système de réservation. Pour les cas simples, comme des salles de réunion sans règles particulières, les outils d’agenda et les réservations de salles prêtes à l’emploi suffisent souvent. Ils sont vite configurés, maintenus, et ne coûtent aucun temps de développement. Celui qui veut seulement savoir si la salle deux est libre à dix heures devrait commencer par là. Les logiciels standard atteignent leurs limites lorsque les ressources dépendent les unes des autres, que les prix ou les validations dépendent de règles, ou que les données doivent alimenter des systèmes existants. Commencent alors la configuration et le bricolage, et le coût passe du développement à l’entretien des exceptions.

La troisième voie est un développement sur mesure qui démarre volontairement petit. Nous construirions d’abord la logique centrale, c’est-à-dire les ressources, les intervalles, la vérification des conflits et les règles d’annulation, et garderions tout le reste simple dans un premier temps. L’interface peut être sobre au départ. D’après notre expérience, ce n’est qu’à l’usage que l’on voit quelles demandes particulières sont vraiment nécessaires et lesquelles ne semblaient obligatoires que dans la discussion.

Une aide à la décision : si vos règles tiennent en une phrase, achetez. Si elles remplissent une page et s’écartent souvent du standard, un développement sur mesure se justifie. Et si vous hésitez, ne développez pas : testez d’abord un produit standard avec vos règles réelles. Le résultat montre très vite où se situe la limite.

Au quotidien, les utilisateurs rencontrent un enchaînement simple : choisir une ressource, fixer une période, confirmer. Derrière, il y a une chaîne de vérifications qui devrait s’exécuter dans un ordre fixe. D’abord le droit, puis les règles de la période, puis la disponibilité, enfin l’enregistrement. Il est important que les deux dernières étapes soient indissociables, afin qu’aucun vide ne subsiste entre la vérification et l’inscription.

Pour l’interface, un principe s’applique : n’affichez que ce qui est réservable, mais ne vous y fiez jamais. L’affichage des créneaux libres est une fonction de confort et peut être périmé. La vérification qui fait foi a lieu lors de l’enregistrement et doit fournir un refus compréhensible, par exemple « La salle vient d’être réservée par quelqu’un d’autre, deux alternatives sont libres ». Cela évite l’agacement que provoque un message d’erreur brut.

Pour les réservations à plusieurs ressources, par exemple une salle avec un appareil et un accompagnateur, la règle est « tout ou rien ». Soit toutes les parties sont libres et occupées ensemble, soit la réservation échoue entièrement. Les réservations à moitié, où la salle est réservée et l’appareil manque, sont à l’origine des questions les plus pénibles et ne peuvent être évitées que par une transaction commune.

Le moyen le plus robuste contre les doubles réservations est de les rendre impossibles dans le système de base de données lui-même. Une simple vérification dans le code de l’application est vulnérable : deux requêtes parallèles lisent toutes deux « libre » et écrivent toutes deux. Il existe trois outils pour y remédier. Premièrement, les verrous, qui réservent la ressource en exclusivité pendant la vérification. Deuxièmement, les niveaux d’isolation de transaction plus élevés, qui rejettent les écritures concurrentes. Troisièmement, les règles de la base de données elle-même.

Avec PostgreSQL, il existe une variante élégante : les contraintes d’exclusion sur des plages de temps. On définit que deux intervalles ne peuvent pas se chevaucher sur la même ressource, et la base de données rejette toute violation, quel que soit le nombre d’applications qui écrivent. Le principe peut aussi être reproduit dans d’autres systèmes, par exemple avec un verrou par ressource et par jour. Nous utiliserions la base de données comme instance ultime et le code seulement comme première étape conviviale.

Un détail minime aux grands effets est la définition des intervalles. Les périodes sont comprises comme semi-ouvertes : le début compte, la fin non. Ainsi, une réservation de 10 h à 11 h peut être suivie immédiatement d’une autre de 11 h à 12 h sans que le système signale un conflit. Celui qui ne le définit pas rencontre des erreurs de bord qui n’apparaissent que par hasard et restent longtemps inaperçues.

Enfin, une remarque sur le passage à l’échelle : pour des entreprises de cette taille, la charge est faible et la solution côté base de données est tout à fait suffisante. Des constructions plus complexes avec files d’attente ou verrous distribués ne se justifient qu’en cas de très forte affluence simultanée, comme dans la vente de billets. Les introduire trop tôt, c’est échanger un problème soluble contre un problème difficile à exploiter.

Le temps est le domaine où des systèmes en apparence propres fournissent en silence des résultats faux. La règle de base : les instants sont enregistrés de façon univoque, par exemple en UTC, et convertis dans le fuseau horaire de la ressource pour l’affichage. De plus, le système mémorise le fuseau horaire sous forme de nom, comme « Europe/Berlin », et non comme décalage fixe, car le décalage change avec l’heure d’été.

L’heure d’été crée deux cas particuliers. Au printemps, l’horloge passe de 2 h à 3 h, et l’heure intermédiaire n’existe pas. Une réservation à 2 h 30 est donc invalide, et le système doit la refuser ou la décaler. En automne, l’heure entre 2 h et 3 h se produit deux fois, et une indication comme 2 h 30 est ambiguë. En pratique, cela concerne rarement les bureaux, mais bien le travail posté, les fenêtres de maintenance et l’utilisation nocturne des appareils.

Les séries de rendez-vous aggravent la situation. Une réservation hebdomadaire « le lundi à 9 h » doit continuer à avoir lieu à 9 h, heure locale, après le changement d’heure, et non à 8 h ou 10 h. Les séries sont donc enregistrées comme règle en heure locale et ne sont converties en rendez-vous concrets qu’au besoin. Les exceptions, comme un rendez-vous isolé déplacé, sont des entrées à part qui restent liées à la série.

Si vous travaillez avec des clients ou des sites situés dans d’autres fuseaux horaires, le système montre à chaque personne l’heure dans son heure locale, mais consigne le rendez-vous lui-même dans un seul fuseau horaire, celui du lieu où il se tient. Un rendez-vous dans la salle de réunion de Berlin est un rendez-vous berlinois, même si quelqu’un le réserve depuis Lisbonne.

Les règles d’annulation sont un conflit entre fiabilité et flexibilité. Autoriser généreusement la restitution des salles crée des trous que plus personne ne comble. Fixer des délais stricts crée des réservations fantômes que personne ne libère. Un compromis éprouvé : annulation gratuite jusqu’à un délai, puis restitution avec avis et motif documenté. L’application de frais est une décision commerciale, et le système ne fait que la mettre en œuvre.

Un deuxième allègement vient des rappels et des libérations automatiques. Si une réservation n’est pas confirmée avant une certaine échéance ou que la salle n’est pas occupée, le système peut la libérer après un avertissement. Cela semble dur et résout pourtant bien des litiges en pratique, car la règle s’applique à tous de la même manière. L’essentiel est que les règles soient visibles pour toutes les équipes avant de s’appliquer.

Les rôles gardent le jeu de règles lisible. Dans un modèle simple, il y a des personnes qui réservent, des responsables par ressource et des administrateurs. Ceux qui réservent créent et annulent leurs propres rendez-vous. Les responsables valident les exceptions, comme des occupations plus longues, et bloquent des créneaux pour la maintenance. Les administrateurs gèrent les ressources et les règles. Chaque modification est consignée avec la personne et l’horaire, afin de savoir qui a modifié quoi et quand.

La connexion à l’agenda est le point où naît l’adhésion, car la plupart des gens vivent dans leur agenda. Deux voies sont courantes. Un simple flux d’abonnement au format iCalendar amène les réservations dans Outlook, Apple Agenda ou Google Agenda, mais dans un seul sens. Une véritable synchronisation via les interfaces de Google ou de Microsoft est possible, mais implique des droits d’accès, une gestion des erreurs et de la maintenance. Nous commencerions par le flux et n’ajouterions la synchronisation bidirectionnelle que là où elle est nécessaire.

Un système de réservation résout un problème bien délimité : il rend fiable l’affirmation « libre » et uniformes les règles. Cela supprime les questions, les corrections et les disputes sur les occupations. L’ampleur du gain dépend de la friction qui existe aujourd’hui. Dans une entreprise avec deux salles et peu d’affluence, l’effet reste faible, et une solution simple aurait été plus raisonnable.

L’intérêt se mesure à l’aide de quelques indicateurs que vous pouvez déjà relever avant. Combien de doubles réservations ou de réclamations y a-t-il eu en un mois ? Combien de temps le secrétariat passe-t-il en coordination et en corrections ? Quelle est la part du temps réservé mais inutilisé, c’est-à-dire des réservations auxquelles personne ne s’est présenté ? Celui qui note ces valeurs avant le démarrage peut comparer après trois à six mois, au lieu de s’en remettre à des impressions.

Les analyses elles-mêmes sont un gain annexe. Le taux d’occupation par ressource, les heures de pointe, le taux d’annulation et la part des modifications de dernière minute montrent si trois salles suffisent ou si l’appareil de mesure devient un goulot d’étranglement. Ces chiffres n’existent que grâce au système et permettent de décider des achats. Mais ils ne sont fiables que dans la mesure de la discipline avec laquelle on réserve, d’où l’importance, au quotidien, des règles de libération et des rappels.

On ne peut pas promettre la vitesse à laquelle les collaborateurs s’y habitueront. Les nouveaux systèmes échouent rarement pour des raisons techniques, mais parce que l’ancien chemin reste plus simple. Il est donc judicieux de désactiver systématiquement les anciens chemins au lieu de les laisser fonctionner en parallèle. Si le tableur reste autorisé, la double réservation reste aussi.

Premièrement : la base de données est le lieu de la vérité. Les agendas, les e-mails et les affichages sont des reflets, et plus cette séparation est claire, moins il y a d’erreurs de synchronisation. Deuxièmement : les règles relèvent de la configuration, non de conditions éparpillées dans le code. Quand les délais, les temps de battement et les rôles sont au même endroit, on peut les modifier sans risquer de casser des fonctions.

Troisièmement : les cas particuliers devraient être recensés avant le démarrage et consignés comme cas de test. Une réservation à cheval sur minuit, un rendez-vous le jour du changement d’heure, une série avec un rendez-vous isolé supprimé, une demande simultanée de deux personnes. Celui qui vérifie ces cas automatiquement repère immédiatement les régressions et peut faire évoluer le système sans souci. Ce sont les tests auxquels nous renoncerions en dernier.

Quatrièmement : la première version devrait être petite. Une version avec ressources, réservation, annulation, rôles et flux d’agenda couvre l’essentiel du besoin. Les prix, les chaînes de validation et la synchronisation bidirectionnelle peuvent être ajoutés quand l’exploitation montre qu’ils sont nécessaires. Cela réduit le risque et raccourcit le délai avant le premier bénéfice.

Un système de réservation vaut la peine quand vos ressources dépendent les unes des autres, que vos règles dépassent le standard et que la fiabilité de l’occupation compte au quotidien. Ce n’est pas une obligation pour toutes les entreprises, et parfois un agenda bien tenu suffit. L’intérêt ne vient pas de la technique, mais du fait qu’il existe enfin une réponse unique et fiable à la question de savoir ce qui est libre et quand.

La prochaine étape est petite et ne coûte rien. Écrivez vos ressources et les dix règles les plus importantes sur une page : qui peut réserver, jusqu’à quand on peut annuler, quels créneaux sont bloqués, ce qui vaut pour les exceptions. Souvent, cette feuille montre déjà si un produit standard suffit ou si un développement sur mesure devient pertinent. Nous la passons volontiers en revue avec vous et vous donnons une évaluation claire.

Pour situer l’effort : après cette clarification, un premier cadre d’ampleur et de durée peut être indiqué, pas avant. Celui qui promet un prix fixe à l’avance n’a pas encore vu les cas particuliers. Nous indiquons une fourchette dès que les règles sont posées, et distinguons ouvertement ce qui relève du noyau et ce qui peut suivre plus tard.

Une dernière remarque concerne l’exploitation. Un système de réservation n’est pas un projet qui disparaît après la livraison : des ressources s’ajoutent, les règles changent, les fournisseurs d’agenda adaptent leurs interfaces. Prévoyez donc dès le début qui entretient les règles, qui recueille les retours et comment se déroulent les sauvegardes et les mises à jour. Cela coûte peu si c’est réglé tôt, et beaucoup si on ne s’en aperçoit qu’après qu’une salle a été réservée deux fois pour la troisième fois.