Une console de réservations pour un opérateur balnéaire multi-sites. Aucun backend requis.

Des surréservations que personne ne pouvait empêcher.

Faire tourner plusieurs sites balnéaires sur un tableur partagé n'est pas un problème de workflow. C'est un problème de cohérence des données déguisé en problème de workflow. Deux managers qui ouvrent la même feuille au même moment, descendent jusqu'au même créneau et appuient sur enregistrer — l'un d'eux gagne toujours, et l'autre ne sait jamais qu'il a perdu. L'opérateur dédommageait des clients mécontents deux ou trois fois par semaine à cause d'exactement ça.

Les éditeurs de PMS qu'ils avaient évalués exigeaient tous un serveur sur site, une licence par poste et trois mois d'onboarding. Rien de tout cela ne convenait à un petit opérateur avec du personnel saisonnier, sans fonction informatique et avec une forte préférence pour ne pas posséder d'infrastructure. Le brief était clair : nous voulons quelque chose que nos managers puissent ouvrir dans un navigateur, et nous voulons que ça ne tombe pas en panne.

Une console de réservations multi-établissements, avec une synchro de disponibilité qui ne fait pas de polling.

La console donnait à chaque site une grille de réservation en direct — arrivées, départs, disponibilité par créneau, occupation par date. Un manager d'un établissement pouvait voir les changements concurrents d'un autre établissement à l'instant où ils se produisaient, sans rafraîchir la page. Réserver, modifier et annuler une réservation mettaient tous à jour l'état partagé immédiatement. Chaque session ouverte voyait chaque changement dès qu'il arrivait.

Sous la console : Firestore pour les données de réservation, Realtime Database pour la couche de synchro de disponibilité, Firebase Auth pour la gestion des sessions, et Firebase Hosting pour le SPA statique. Pas de serveur Node. Pas de processus Express à redémarrer. Pas de pipeline de déploiement au-delà d'une seule commande CLI.

La surface analytique tournait aux côtés de l'opérationnelle : démographie des clients, graphiques de tendances de réservation via Highcharts, et une vue de prévision de revenus tirée des mêmes collections Firestore que la grille de réservation lisait déjà. La génération de factures intégrée (jsPDF) et l'export CSV/XLSX géraient le workflow de fin de mois du propriétaire sans outil séparé. Trois mois et demi du premier commit à la production.

F · 01Synchro de disponibilité en direct

Firestore + Realtime Database poussent les mises à jour vers chaque session ouverte à l'instant où une réservation change. Pas de polling. Pas de rafraîchissement.

F · 02Tableau de bord multi-établissements

Une seule console couvre tous les sites. Chaque établissement a sa propre grille ; le propriétaire voit l'ensemble dans un seul onglet.

F · 03Couche de session Firebase Auth

Firebase Auth gère les sessions des utilisateurs propriétaire, manager et personnel. Pas de serveur d'authentification sur mesure, pas de table de permissions à maintenir. Des contrôles de rôle au niveau applicatif cloisonnent les surfaces.

F · 04Génération de factures

Confirmations de réservation et factures produites côté client avec jsPDF et envoyées directement par e-mail — sans outil de facturation séparé.

F · 05Import / export en masse

Import CSV et XLSX pour le chargement saisonnier en masse. Export pour le comptable du propriétaire en fin de mois. Les deux tournent dans le navigateur.

F · 06Analytique

Démographie des clients, tendances de réservation et une vue de prévision de revenus bâties sur Highcharts, lisant les mêmes collections Firestore que la grille de réservation.

Le choix du tout-Firebase, et pourquoi il a survécu à la production.

Les tentatives de réservation concurrentes sur le même créneau — deux managers réservant la dernière chaise de plage de l'après-midi — était exactement la défaillance que l'opérateur continuait de payer. Le correctif n'était pas un verrouillage à l'écriture ; c'était la vérité à la lecture. Les écouteurs en temps réel de Firestore faisaient que chaque session ouverte sur chaque appareil voyait une réservation à l'instant où elle était écrite. Une fois un créneau pris, l'écran de chaque manager l'affichait. L'échec de coordination du tableur — deux personnes travaillant sur des vues périmées de la même ligne — ne pouvait pas se produire, parce que personne ne travaillait sur une vue périmée.

La décision de se passer entièrement d'un serveur backend n'était pas un raccourci pour réduire les coûts. C'était la bonne architecture pour les contraintes de cet opérateur. Il n'y avait pas d'équipe DevOps pour veiller sur un processus Node, pas d'astreinte à nous confier, et aucune tolérance pour un serveur qui tombe un samedi d'août. Les services gérés par Firebase portent la garantie de disponibilité ; nous portons la logique applicative. La frontière est nette.

Firebase Auth gérait la gestion des sessions sans serveur d'authentification sur mesure. Le support multilingue pour une clientèle internationale passait par ngx-translate. Le bundle statique se déployait sur Firebase Hosting en moins de deux minutes. Le coût mensuel total d'infrastructure tenait dans le palier gratuit de Firebase pendant les six premiers mois de production.

Zéro double réservation. La facture d'infrastructure est restée dans le palier gratuit.

Le problème de surréservation a cessé. Au cours des douze premiers mois d'exploitation, l'opérateur a enregistré zéro réservation en conflit sur le même créneau. Le tableur est resté ouvert une semaine après le lancement, comme un filet de sécurité que personne n'a utilisé.

Le système est passé en production sur trois établissements simultanément. La propriétaire a mené elle-même la formation du personnel, en une seule après-midi, parce que la console était assez simple pour s'expliquer en une session. Le turnover du personnel saisonnier — l'autre raison pour laquelle le tableur avait été si fragile — a cessé d'être un risque d'intégrité des données dès lors que l'état vivait dans la base de données, et non dans le fichier local de quelqu'un. Les nouvelles recrues saisonnières recevaient une invitation Firebase Auth et la même console que tout le monde.

Le produit tourne sans serveur backend depuis 2019. L'opérateur ne nous a jamais ouvert d'alerte d'astreinte.