Contexte
WebOustaou a atteint son étape v0.10.0-bêta en juillet 2026 — le point où le cœur du back-office (menu, horaires, blog, happenings, QR, analytics, facturation) est fonctionnellement complet. Cette entrée porte sur la suite : les phases déjà conçues, en partie posées dans le schéma, qui font passer WebOustaou de "gérer la présence de votre restaurant" à "faire tourner les opérations de votre restaurant".
Rien ci-dessous n'est de la spéculation pour les besoins d'un pitch — c'est la même roadmap publiée sur weboustaou.fr/roadmap, reformulée ici comme un récit d'architecture.
Phase 3 — Cœur de Commande
La phase suivante, déjà débloquée par un travail récent sur le schéma, introduit orders, order_items et order_item_modifications, ainsi qu'une table customization_rules conçue autour de ce que j'appelle la "règle Margherita" : retirer un ingrédient (le fromage, par exemple) et le prix et la modification sont capturés de façon structurée, pas en texte libre. Les commandes suivent un cycle de vie simple — panier → passée → en préparation → prête → terminée / annulée — sans traitement de paiement à ce stade.
Les ingrédients et allergènes sont déjà, aujourd'hui, des tables de référence à part entière, et non du texte incorporé dans une description de produit — un choix fait bien avant que la commande en ligne n'existe, précisément pour que cette phase n'exige pas de refonte du modèle de données.
Phase 4 — Kitchen Display System et Tablettes en Libre-Service
Voici la fonctionnalité qui mérite d'être teasée : un Kitchen Display System (KDS). Les commandes arrivent sur des écrans par poste (poste pizza, poste boissons) via Supabase Realtime, se rafraîchissant automatiquement à mesure que les tickets avancent en cuisine. Les tables stations et station_displays modélisent la cuisine physique ; une table d'enregistrement d'appareils tablets soutient la commande en libre-service en mode kiosque en salle.
La roadmap publique la liste déjà comme "en développement" : "Écran de cuisine, gestion et planification des commandes unifiés sur la plateforme, tous canaux de commande confondus," avec le routage automatique des tickets vers le bon poste comme piste envisagée ensuite.
Le terrain a été préparé bien avant la fonctionnalité elle-même : une décision d'architecture récente (ADR-023) a rattaché menu, horaires et fermetures du site public vers l'établissement physique, précisément pour que les commandes — et à terme le KDS — puissent interroger l'état de la cuisine directement par établissement, sans passer par le site public ayant reçu la commande. Une colonne shops.kds_enabled existe déjà dans le schéma comme espace réservé pour cette phase.
Phase 5 — Commande Web
Commande côté client : comptes clients distincts, persistance du panier, paiements Stripe Connect (le restaurant est payé directement, WebOustaou prélève des frais de plateforme — pas un modèle de commission par commande), notifications de commande par email et SMS, et recommande depuis l'historique.
Phase 6 — Un Agent IA au Téléphone
La phase la plus exploratoire : une intégration Twilio Voice où un LLM prend les commandes par téléphone en utilisant le même accès par function-calling à l'API de commande qu'un membre du personnel humain, soutenu par des tables de transcription phone_calls et call_turns, un SMS de confirmation avec un lien magique, et un repli humain pour tout ce que l'agent ne peut résoudre. Pour un restaurant, le téléphone ne s'arrête jamais de sonner pendant le service — c'est exactement ce problème visé.
Et le Backlog
Fidélité et récompenses, suivi des stocks, intégrations avec les plateformes de livraison, support multi-devises et un assistant conscient du menu sont suivis mais pas encore phasés — visibles sur la roadmap publique sous "à l'étude".
Pourquoi Concevoir Aussi Loin à l'Avance
Ce n'est pas du théâtre de roadmap, mais une habitude d'ingénierie systèmes : la contrainte de migrations uniquement additives qui régit le schéma de WebOustaou signifie que chaque phase future doit être imaginée avant que la phase en cours ne soit livrée, sous peine de nécessiter une refonte plutôt qu'une extension. Le multi-tenant, le RLS et l'i18n basée sur JSONB ont tous été construits dès la première migration pour la même raison — non pas parce que la Phase 0 en avait besoin pour une seule pizzeria, mais parce que la Phase 4 et la Phase 6 en auraient besoin.
Statut
La Phase 3 est la prochaine. Rien ici n'est promis à une date précise — la roadmap publique étiquette chaque élément shipped, in-dev ou considering, et le KDS est actuellement in-dev. Je tiendrai cette entrée et l'article de blog sur la roadmap à jour à mesure que les phases avancent.
Bilan
Les décisions d'architecture les plus intéressantes de WebOustaou sont celles que personne ne remarque encore — les colonnes de schéma et les frontières de packages qui existent pour une fonctionnalité qui n'a pas encore été livrée. C'est le réflexe d'architecte systèmes : concevoir pour la phase d'après, construire pour celle qui est devant soi.
