Application métier · restauration (web + mobile)
Gestion de stock d'un restaurant — web et mobile, même backend
EN PRODUCTION · Vercel · vérifié 02/07/2026
Contexte
Un restaurant indépendant en Espagne — un seul établissement, équipe réduite — gère un stock d'ingrédients et de consommables dont le niveau conditionne directement le service du lendemain.
Problème
Le suivi reposait sur un processus manuel : comptage en fin de service, repérage de ce qui manque, transmission de la liste d'achat à la personne chargée des courses. Trois risques concrets : un article oublié n'est pas racheté, une saisie tardive bloque la commande, et personne ne peut vérifier a posteriori qui a saisi quoi.
Approche
Le projet a été cadré par un cahier des charges à règles métier explicites et numérotées (R01 à R07) : seuil critique par article, une seule saisie par article et par jour, articles désactivés invisibles, soumission possible à partir de 80 % d'articles saisis, saisie clôturée immuable pour le staff avec corrections manager tracées, quantités négatives refusées, dates gérées dans le fuseau horaire du restaurant. La définition de « terminé » était posée avant le développement : la liste d'achat du jour se génère et part en notification sans intervention humaine.
Ce qui a été livré
- Application web : Next.js 16 (App Router), React 19, TypeScript strict, Tailwind CSS 4, déployée en production sur Vercel.
- Backend : Supabase — PostgreSQL avec Row Level Security, authentification JWT + cookies SSR, stockage des photos d'articles.
- Trois niveaux de rôles : staff (saisie), manager (dashboard, articles, corrections, génération manuelle), admin (utilisateurs, paramètres). Redirection automatique selon le rôle, déconnexion après 8 h d'inactivité.
- Génération automatique de la liste d'achat, trois déclencheurs : clôture de la saisie du soir, bouton manager, cron quotidien de sécurité. Chaque article actif sous son seuil critique entre dans la liste, avec statuts de suivi (à commander → commandé → reçu).
- Notification WhatsApp : Meta WhatsApp Cloud API implémentée côté serveur, chaque tentative d'envoi journalisée en base.
- Application mobile : Expo SDK 56 / React Native 0.85, iOS et Android, même backend Supabase sans modification du schéma. Session chiffrée, validation côté client doublée par la RLS côté serveur ; une Edge Function Supabase porte la clôture et la génération, pour que les secrets restent côté serveur, jamais sur le téléphone.
Stack
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS 4
- Vercel
- Expo SDK 56
- React Native 0.85
- iOS + Android (build EAS)
- Supabase (PostgreSQL + RLS, Auth, Storage, Edge Function)
- Meta WhatsApp Cloud API
- cron quotidien Vercel
Résultats observés
Au 02/07/2026, l'application web répond en production sur Vercel ; la chaîne saisie du soir → contrôle des seuils → génération de la liste fonctionne sans intervention manuelle, avec un cron quotidien en filet de sécurité.
déploiement Vercel · HTTP 200 · vérifié 02/07/2026
Application mobile buildée via EAS (iOS + Android) sur le même backend Supabase ; soumission stores en attente.
build EAS · état 06/2026
Ce qui reste humain
Le système compte, compare et notifie ; il ne décide pas. Les seuils critiques et quantités de commande sont fixés par le manager. Les corrections après clôture restent une action manager, tracée dans un journal d'audit. La décision d'achat finale — fournisseur, substitution, report — appartient à la personne qui reçoit la liste. Aucun chiffre de temps gagné n'est publié : le processus antérieur n'a pas été mesuré, et ce site ne publie pas de métriques reconstruites a posteriori.