Plateforme de réservation et de gestion pour restaurant

Étude de cas · Développement web fullstack · Astro · Node.js · MySQL · Docker

Éviter qu'un restaurant perde des clients à cause d'un carnet de réservations

Une réservation prise par téléphone et notée sur un carnet, un employé qui prend une journée de congé sans transmettre l'information, et c'est la table promise depuis des semaines qui n'est plus disponible à l'arrivée du client. Côté cuisine, la carte affichée en ligne n'est déjà plus à jour et le plat commandé n'existe plus. Une soirée censée être parfaite se transforme en frustration, pour le client comme pour la table d'à côté qui subit le retard du service.

Braise est la plateforme que j'ai conçue et développée, de la première esquisse jusqu'à l'infrastructure Docker, pour éliminer ce type de friction : réservation en ligne, gestion des tables et commande digitale réunies dans un seul outil, pensé à partir des vraies frustrations des clients et des restaurateurs plutôt que d'une liste de fonctionnalités à cocher.

Le problème : deux frustrations, un même service qui craque

Du point de vue du restaurateur, le succès du soir même devient le problème : entre les appels, les passages au comptoir et les réservations griffonnées sur un carnet, les noms, les tables et les horaires finissent par se mélanger. Jongler entre les commandes à emporter et le service en salle ralentit toute l'équipe. Résultat : des tables doublées, une cuisine qui découvre les couverts au dernier moment, et un personnel qui s'épuise à rattraper des erreurs évitables.

Le cadrage du projet a fait ressortir des besoins précis, à la croisée de l'expérience client et de l'organisation en cuisine :

• Centraliser la réservation : que chaque table réservée soit enregistrée une seule fois, accessible à toute l'équipe en temps réel, sans dépendre d'un carnet ou d'une passation orale entre employés.
• Fiabiliser la carte affichée en ligne : que le menu consulté par le client avant sa venue soit exactement celui que la cuisine peut servir au moment de sa commande, avec les ruptures reflétées immédiatement.
• Permettre la commande en ligne sur place, à emporter ou en livraison, avec un statut de préparation partagé entre la salle et la cuisine.
• Anticiper la préparation grâce à l'heure de réservation, pour réduire le temps d'attente entre l'arrivée du client et le service du plat.
• Donner à la direction un pilotage complet, sans dépendre d'un développeur pour la moindre modification de carte ou de promotion.

Les fonctionnalités : une plateforme vue depuis quatre rôles

Braise a été construite comme un système pensé depuis quatre points de vue : le client qui réserve et commande, le serveur qui gère la salle en temps réel, la cuisine qui suit les commandes, et la direction qui pilote l'ensemble de l'activité.

Réservation en ligne et plan de salle

Le client réserve sa table par date, heure et nombre de couverts, avec confirmation automatique ou validation manuelle selon le paramétrage choisi. Chaque réservation affiche un statut clair (confirmée, en attente, terminée), visible en temps réel par toute l'équipe, pour ne plus jamais dépendre d'un carnet ou d'une note manuscrite.

Menu digital dynamique

La carte affichée en ligne est enfin celle de la cuisine : catégories illustrées, allergènes, tags (végétarien, épicé, populaire) et disponibilité mise à jour en temps réel. Un plat en rupture disparaît instantanément de la carte publique, sans intervention manuelle.

Commande et paiement en ligne

Le client commande sur place, à emporter ou en livraison, et paie en ligne en toute sécurité. Chaque commande suit un statut précis (reçue, en préparation, prête, livrée), partagé entre la salle et la cuisine pour que les deux équipes travaillent sur la même information.

Fidélité et avis clients

Des points de fidélité convertibles en récompenses, des codes promotionnels personnalisables et le recueil d'avis après chaque expérience permettent de transformer un client d'un soir en habitué.

Tableau de bord administrateur

Une interface unique pour piloter le menu, les réservations, les commandes en cours, les statistiques de vente et les promotions, sans jamais avoir besoin d'un développeur en urgence pour un changement du quotidien.

Rôles et traçabilité

Des comptes admin, gérant et serveur aux permissions distinctes garantissent que chaque membre de l'équipe n'accède qu'à ce qui le concerne, avec un journal d'activité qui trace chaque action sensible.

Le process : des choix d'architecture guidés par le service, pas par la mode

Une fois les fonctionnalités définies, restait la question qui détermine si la plateforme tient la charge un vrai vendredi soir. Plutôt que de partir d'un framework à la mode, chaque décision d'architecture a répondu à une contrainte réelle du métier de restaurateur.

1. Ne jamais interrompre le service pour une mise à jour

Le risque identifié dès le départ était simple : une mise à jour anodine du site, une photo changée, un correctif de design, ne devait jamais obliger à redémarrer les serveurs en pleine prise de commande. Le front Astro et l'API Express vivent donc dans deux dépôts distincts, avec leurs propres pipelines. Le site statique peut être reconstruit et republié sans jamais toucher aux conteneurs applicatifs qui gèrent les réservations et les paiements en cours.

2. Une vitesse de chargement pensée pour un client pressé, sur mobile

Un client qui hésite devant la vitrine, carte en main sur son téléphone, ne patiente pas plusieurs secondes qu'une page se charge. L'architecture en îlots d'Astro isole le JavaScript aux seules zones réellement interactives (le formulaire de réservation, le panier de commande, le tableau de bord admin) et laisse le reste de la page, menu, présentation, avis, se charger en HTML statique quasi instantané. Le LCP reste rapide puisqu'aucune hydratation ne bloque l'affichage du contenu principal, et le CLS est maîtrisé grâce à des dimensions d'image réservées en amont.

3. Un backend prêt à encaisser le coup de feu

Côté cuisine, quand les commandes s'enchaînent, l'API Express expose un endpoint dédié au monitoring et le pool de connexions MySQL évite l'ouverture d'une connexion par requête. C'est précisément ce type de détail qui absorbe sans broncher le pic du service du midi et du soir, quand réservations et commandes se concentrent sur des fenêtres très courtes.

Le stack technique

Chaque couche technique a été choisie pour répondre à une contrainte concrète du métier de restaurateur, plutôt que pour suivre une tendance.

Frontend et contenu

• Astro pour le contenu public (carte, vitrine, avis), majoritairement statique et consulté sur mobile : du HTML pur, sans JavaScript par défaut, adapté à une connexion 3G devant le restaurant
• Routing FR / EN / ES natif Astro, avec un contenu traduit et indexable séparément par les moteurs de recherche, sans librairie i18n tierce côté client, pour une clientèle internationale

Backend et données

• Node.js et Express pour une API REST légère, sans ORM lourd, entre le front Astro et la base de données, suffisante pour le volume de trafic d'un établissement indépendant
• JWT et bcrypt pour une authentification sans état, adaptée à une API consommée à la fois par le site public et le back-office, avec un hachage des mots de passe conforme aux standards actuels
• MySQL comme base de données relationnelle, adaptée à un modèle fortement lié (réservations, commandes, paiements, fidélité) avec des contraintes d'intégrité fortes

Déploiement

• API, MySQL et phpMyAdmin conteneurisés séparément et orchestrés par Docker Compose, servis derrière un reverse proxy HTTPS
• Front Astro buildé en statique et livré indépendamment, pour deux cycles de déploiement totalement découplés

Le résultat : la soirée qui ne tourne plus au fiasco

Avec Braise en place, le scénario du vendredi soir raté n'a plus lieu d'être : les réservations arrivent en ligne et se confirment seules, la carte affichée sur le site est celle que la cuisine vient de mettre à jour depuis le tableau de bord, et chaque commande suit son statut en temps réel jusqu'en salle.

Ce projet part d'une frustration vécue à la fois par le client et par le restaurateur, en déduit les vraies priorités, puis choisit chaque brique technique (Astro, Node, MySQL, Docker) pour ce qu'elle résout concrètement, pas pour sa popularité. Les évolutions envisagées portent sur l'intégration d'un vrai prestataire de paiement, des tests automatisés sur l'API, et des notifications en temps réel entre la cuisine et la salle.

Étude de cas rédigée dans le cadre d'un portfolio de développement web. Projet personnel, brief client simulé.

Développeur fullstack · plateformes web pour la restauration