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 widget ouvre donc sur la semaine, pas sur un formulaire : huit journées, et un code couleur à trois états — disponible, quelques places, complet. C’est le même remplissage que celui du tableau de bord, montré de l’autre côté du comptoir. Un visiteur qui voit « quelques places » sur le samedi n’a besoin d’aucun argumentaire, et une journée complète ne reçoit plus une demande qu’il faudra refuser à la main.

Les deux mails, et ce que la plateforme n’encaisse pas

Toute la mécanique tient dans deux envois. Le premier part vers nous à la seconde où le formulaire est validé : une demande est arrivée, avec la journée, le nombre de places et le contact. Le second ne part que si nous acceptons, vers le client, et il porte le récapitulatif de sa commande et les informations de paiement.

Ce second mail est l’endroit où le choix le plus contre-intuitif du système se voit : la plateforme ne prend pas l’argent. Elle envoie de quoi payer — un lien, ou nos coordonnées pour un virement — et c’est tout. C’était une décision de la version une, prise pour la même raison que la demande plutôt que la réservation : encaisser avant de savoir si la sortie est opérable, c’est fabriquer du remboursement à chaque grain. Le prix à payer est réel — le rapprochement entre ce qui est annoncé et ce qui est reçu reste manuel — et c’est exactement ce que la section suivante gère.

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 de plusieurs —, 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 une date, d’en fermer une, ou d’aller pousser celle qui traîne. C’est la pièce qui n’existait pas avant : le remplissage vivait dans quatre fils WhatsApp et dans la tête de celui qui avait répondu le plus souvent. 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.