Resa System Yoles

Le système de réservation de nos excursions en catamaran, écrit de zéro parce que les plateformes existantes prennent une commission par place et imposent une logique de créneaux qui n’est pas celle d’un bateau. Il est déployé, il est utilisé par ma famille et moi pendant toute la saison, et le formulaire public vit sur notre site sous forme de widget embarqué.

La demande, pas la réservation

C’est le choix structurant. Un visiteur envoie une demande, elle nous arrive par mail, et nous l’acceptons ou non depuis la plateforme. Ça a l’air moins moderne qu’un paiement immédiat, mais c’est ce que la réalité impose : la météo, la composition du groupe et l’équipage du jour décident si une sortie est opérable. Encaisser d’abord et annuler ensuite, c’est transformer chaque intempérie en remboursement et en mauvaise conversation.

Quand une journée est pleine, la demande part en liste d’attente au lieu d’être perdue, et une place libérée la veille retrouve preneur. C’est la fonctionnalité qui rapporte le plus par ligne de code de tout ce que j’ai écrit.

Le côté administration

Un seul écran, ouvert tous les jours de la saison : l’activité récente, les demandes à traiter, le remplissage journée par journée et l’aperçu financier. Chaque réservation porte le montant annoncé, le montant réellement reçu : le moyen de paiement, virement, espèces, carte, gratuité, ou un mélange des deux. La date d’encaissement et l’acompte. C’est cette distinction entre annoncé et reçu qui permet les relances, et sans elle on découvre en fin de saison que trois sorties n’ont jamais été payées.

Le reste est du pilotage : le taux de remplissage par journée et le chiffre d’affaires par saison, qui sont les deux seuls chiffres sur lesquels on décide d’ouvrir ou de fermer une date. Les saisons sont une notion de première classe dans le modèle de données, parce qu’une activité qui tourne trois semaines par an ne se compare qu’à elle-même, l’année précédente.

Ce qui a été long

Jamais le tunnel de réservation. C’est la gestion des cas tordus : la sortie annulée pour météo, le groupe qui réserve six places pour quatre personnes, le remboursement partiel, l’équipage à réaffecter la veille, le client qui écrit sur la messagerie plutôt que par mail. Un outil de réservation ne se juge que sur ces cas-là.

Côté technique, la seule décision dont je suis vraiment content : plus aucune clé dans les pages. Le widget et l’administration ne parlent qu’à trois points d’entrée serveur, et la clé de service ne quitte jamais le serveur. La première version mettait la clé publique dans le HTML. Ça marchait, et c’était une porte ouverte.

Le cas d’étude complet est dans les projets.