Spotrak
Équipe produit
Deux clients ouvrent votre page de réservation. Le même créneau de 14h s'affiche libre pour les deux. Ils cliquent à une seconde d'intervalle. Combien de rendez-vous existent maintenant à 14h ?
Si la réponse peut être « deux », vous avez un bug que personne ne verra en démo et que tout le monde verra un jour chargé. Le double-booking est le test le plus simple pour savoir si un logiciel de rendez-vous a été pensé sérieusement.
L'interface ne protège rien
Le réflexe naïf : « on vérifie que le créneau est libre, puis on enregistre ». Entre le moment où on vérifie et le moment où on enregistre, l'autre réservation passe. Cette fenêtre dure quelques millisecondes, et c'est largement assez. Vérifier puis écrire, ce sont deux opérations ; entre les deux, tout peut arriver.
La garantie vit dans la transaction
La seule place où l'unicité d'un créneau peut être garantie, c'est la base de données, dans une transaction. On ne vérifie pas avant d'écrire. On laisse Postgres refuser la seconde écriture, via une contrainte d'exclusion sur la plage horaire et la ressource. La première réservation passe, la seconde est rejetée par la base, pas par un if. Il n'y a pas de fenêtre, parce qu'il n'y a qu'une opération.
Le détail qui change tout : la ressource et le fuseau
Un créneau, ce n'est pas qu'une heure. C'est une heure, un membre de l'équipe, et parfois une salle ou un équipement. Deux rendez-vous à 14h avec deux personnes différentes sont valides. À 14h avec la même personne, non. La contrainte porte donc sur la combinaison, pas sur l'heure seule. Et tout est stocké en UTC, pour qu'un passage à l'heure d'été ne crée ni trou ni doublon.
Ce sont des détails invisibles pour l'utilisateur. C'est exactement pour ça qu'ils comptent : un bon logiciel de rendez-vous, c'est un logiciel où la question du double-booking ne se pose même pas.