Tous les projets
Étude de cas · 05

SaaS · Multi-restaurant · Web

QR Menu SaaS

L’idée initiale part d’un besoin simple : proposer aux petits établissements un menu mobile propre, facile à administrer et accessible sans application. Le produit a progressivement évolué vers une plateforme unique capable de servir plusieurs restaurants et d’activer des modules selon leurs besoins.

Statut
Projet personnel — en développement
Mon rôle
Conception et développement du produit : architecture, frontend, API, données, authentification et fiabilité du parcours commande → cuisine.
Stack
React · Vite · TypeScript · Tailwind · Node.js · Express · SQLite · Better Auth · Playwright
05

Du QR code à l’écran cuisine multi-restaurant

01

Contexte produit

QR Menu est une application web multi-restaurant construite autour d’un menu accessible par QR code. Le produit sert plusieurs établissements depuis un même socle, avec une gestion des produits et disponibilités côté restaurateur, et s’étend progressivement vers la commande et l’écran cuisine.

  • Menu public accessible par QR code ou URL
  • Administration du menu, des produits et des disponibilités par le restaurateur
  • Socle multi-restaurant, isolé par établissement
  • Extension progressive vers la commande et l’écran cuisine

02

Parcours principal

Le parcours relie la configuration du menu par le restaurateur jusqu’au suivi de la commande en cuisine, avec des règles strictes côté serveur à chaque étape.

  • Le restaurant configure son menu, ses catégories, produits, prix et disponibilités
  • Un client ouvre le menu public depuis un QR code ou une URL
  • Il compose une commande, liée à une table ou préparée pour un retrait
  • La commande est enregistrée et confirmée, sans exposer d’identifiant interne
  • L’équipe cuisine la reçoit dans un écran dédié
  • Son état évolue selon une machine à états contrôlée jusqu’à sa finalisation

03

Menu et commande

Chaque restaurant structure son menu par catégories et articles, avec prix, disponibilité, options et formules. Une commande peut être liée à une table via un QR contextualisé, ou préparée pour un retrait.

  • Catégories, articles, prix et disponibilités
  • Options et formules
  • Commande liée à une table ou à un retrait
  • Commande structurée et confirmée avant envoi en cuisine
Menu public QR Menu consulté sur mobile, avec catégories et articles.
Menu public consulté sur mobile.
Écran de confirmation d’une commande QR Menu.
Confirmation d’une commande, avant transmission à la cuisine.

04

Écran cuisine

Un écran cuisine dédié permet à l’équipe de suivre les commandes en cours et leur progression, du dépôt jusqu’à la finalisation.

  • Commandes actives, avec table ou mention retrait
  • Transitions contrôlées : en attente → en préparation → prêt → terminé, avec annulation possible dans les états autorisés
  • Âge de la commande et heure de retrait lorsqu’elle existe
  • Actions disponibles selon l’état courant de la commande
Écran cuisine QR Menu affichant les commandes actives avec leur état.
Écran cuisine (KDS) : commandes actives et transitions d’état.

05

Architecture générale

L’architecture reste volontairement simple, avec une stack cohérente entre frontend, API et données.

  • Frontend — React · Vite · TypeScript · Tailwind
  • API — Node.js · Express · TypeScript · Zod
  • Données — SQLite
  • Authentification / sécurité — Better Auth · sessions serveur · rôles · isolation multi-tenant · rate limiting
  • Qualité — Vitest · Supertest · Playwright

06

Fiabilité et exploitation

La fiabilité du parcours commande → cuisine a été traitée avant l’ajout du paiement, avec plusieurs garde-fous.

  • Clé d’idempotence contre les doubles clics et retries réseau
  • Transitions de statut contrôlées pour éviter les écrasements concurrents
  • Token public opaque pour le suivi d’une commande
  • Journal des changements de statut
  • Tests du parcours complet avec Playwright
  • Isolation des données par restaurant (multi-tenant)

07

Limites actuelles

Le projet n’est pas encore lancé commercialement. Cette page reflète uniquement les fonctions effectivement développées et testées au moment de sa publication.

  • Paiement client réel non intégré au périmètre publié
  • Abonnements SaaS réels non intégrés au périmètre publié
  • Pas de lancement commercial à ce stade
  • Déploiement de production, pilote réel et contraintes opérationnelles encore à valider

Projet suivant

L’Infinie de la Chaize