Éviter les doubles réservations : pourquoi les systèmes échouent, et le modèle qui ne peut pas
Une double réservation n'arrive presque jamais parce qu'un calendrier a « fait une erreur ». Elle arrive parce que le logiciel a vérifié qu'un créneau était libre, puis l'a réservé, en deux étapes distinctes avec un intervalle entre elles — et un second client s'est glissé dans cet intervalle. Fermez cet intervalle et le reste du calendrier peut être aussi simple ou aussi élaboré que vous le souhaitez. Laissez-le ouvert, et aucun polish sur le widget de réservation n'empêchera deux personnes d'atterrir occasionnellement sur la même chaise.
Là où l'écart se creuse vraiment
La séquence ordinaire derrière presque toute réservation : vérifier « ce créneau est-il encore libre ? », recevoir « oui », puis écrire la réservation. Une lecture, puis une écriture — et entre les deux, aussi brièvement soit-il, une fenêtre. Une seconde requête qui vérifie le même créneau pendant cette fenêtre voit aussi « oui, encore libre ». Les deux croient désormais réserver un créneau ouvert, car au moment où chacune a regardé, c'était vrai.
Vous ne pouvez pas savoir, en cliquant dans une démo un mardi après-midi tranquille, si la vérification et l'écriture sous-jacentes sont solidement liées ou dangereusement séparées — le calendrier a l'air identique dans les deux cas.
Pourquoi "il suffit d'un plus beau calendrier" ne règle rien
Beaucoup de logiciels de réservation sont, sous le widget, un générateur de formulaire générique jamais conçu pour deux personnes réclamant la même chose limitée en même temps. Le choix de date peut être fluide, la disponibilité avoir l'air en direct, l'écran de confirmation être soigné — et le back-end vérifie quand même avec une lecture et écrit avec une écriture séparée, plus tardive. Un trafic réel et simultané trouve la faille.
Le modèle qui comble vraiment l'écart
Cessez de traiter « vérifier » et « réserver » comme deux opérations : relancez la vérification de disponibilité et écrivez la réservation à l'intérieur d'une seule transaction de base de données qui verrouille les lignes de ce créneau. Quelle que soit la requête qui arrive en premier, elle termine sa vérification-et-écriture sans interruption ; la seconde attend son tour, puis revérifie contre la nouvelle réalité. Aucune fenêtre ne subsiste dans laquelle une information « encore disponible » périmée pourrait être exploitée — la base de données impose l'ordre, plutôt que le code applicatif qui espère qu'aucune course ne se produira.
Ce qui se passe vraiment quand deux personnes cliquent sur « réserver » en même temps
1
Les deux demandes arrivent presque en même temps
2
Une requête obtient le verrou en premier
3
La première requête revérifie et écrit, en une seule fois
4
La seconde requête revérifie face à la nouvelle réalité
5
Le deuxième client est prévenu immédiatement
Comment Olmira gère cela
Le moteur de réservation d'Olmira exécute la revérification de disponibilité et l'enregistrement de la réservation en une seule étape, à l'intérieur d'une unique transaction de base de données verrouillée — de sorte que lorsque deux clients visent le même créneau en même temps, une réservation est validée et l'autre est informée, avant que le moindre paiement ne soit engagé, que le créneau vient de partir. Le même verrou couvre la ressource sous-jacente, et pas seulement le service vendu : deux services différents partageant une salle ou un membre de l'équipe ne peuvent donc pas non plus la réserver deux fois en douce entre eux. Un garde-fou distinct, plus modeste, intercepte l'accident le plus courant — le même client qui double-clique sur « réserver » — et lui demande de confirmer plutôt que de créer silencieusement deux rendez-vous. Voyez comment tout s'articule sur la page réservations.
Guides associés
Rendez-vous manqués : ce qui fait vraiment bouger le chiffre
Non — un trafic élevé ne fait que le révéler plus tôt. La faille sous-jacente existe dès lors que plus d'une requête peut être en cours pour le même créneau, ce qui est vrai même sur une page peu fréquentée ; une entreprise à faible trafic peut simplement passer des mois entre les rares moments où deux personnes cliquent en même temps. C'est une propriété de la conception, pas une fonction de votre affluence.
Non. Le calendrier, c'est ce que voit le client ; la partie qui empêche la double réservation se joue entièrement sur le serveur, de façon invisible, à l'instant précis où une réservation est enregistrée. Une interface de calendrier soignée ne vous dit rien de ce qui se passe en dessous quand deux personnes cliquent sur le même créneau à la même seconde.
Ils devraient apprendre immédiatement — avant tout encaissement — que le créneau vient d'être pris, et se voir proposer la prochaine option réellement disponible. Le mode de défaillance vraiment préoccupant est l'inverse : un système qui laisse passer les deux réservations et ne fait apparaître le conflit que plus tard, en général quand quelqu'un se présente.
Le même mécanisme s'applique partout où l'on réserve une ressource partagée et limitée : une table, une salle, un équipement, un créneau de livraison. La correction a toujours la même forme : verrouiller et revérifier la ressource réellement contrainte au moment de l'engagement, pas un instant avant.
Oui, dans certains secteurs : les compagnies aériennes surréservent depuis toujours des sièges en fonction d'un taux prévisionnel de non-présentation, en tant que décision commerciale délibérée et modélisée, assortie d'une politique d'indemnisation. C'est autre chose que le cas accidentel dont traite ce guide, où personne ne l'avait voulu et où personne n'est content de le découvrir.