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 commerce" à "faire tourner ses opérations au quotidien".
Tout ce qui suit vient directement de la roadmap publique sur weboustaou.fr/roadmap, racontée ici sous l'angle de l'architecture.
Phase 3 : le 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. Elle sert à capturer les modifications de produit (retirer le fromage d'une pizza, par exemple) de façon structurée : l'ingrédient concerné et son impact sur le prix sont stockés comme des données, pas comme une note 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. C'est un choix fait bien avant que la commande en ligne n'existe, justement pour que cette phase n'exige pas de refonte du modèle de données.
Phase 4 : Écrans de Cuisine et Tablettes en Libre-Service
Voici la fonctionnalité qui mérite le plus 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 a rattaché menu, horaires et fermetures du site public vers l'établissement physique, justement 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 : la 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 une 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, et c'est exactement ce problème que cette phase vise à régler.
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 déjà identifiés mais pas encore phasés. On les retrouve sur la roadmap publique sous "à l'étude".
Pourquoi Concevoir Aussi Loin à l'Avance
Ce n'est pas du théâtre de roadmap, c'est une habitude d'ingénierie systèmes. La contrainte de migrations uniquement additives qui régit le schéma de WebOustaou impose que chaque phase future soit imaginée avant que la phase en cours ne soit livrée, sous peine de devoir tout refondre plutôt que simplement étendre. La gestion multi-établissements, le RLS et l'i18n basée sur JSONB ont tous été construits dès la première migration pour la même raison, 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 plus tard.
Statut
La Phase 3 est la prochaine sur la liste. 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 aujourd'hui en 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é pas encore livrée. C'est le réflexe d'architecte systèmes, penser à la phase d'après tout en construisant celle qui est devant soi.
