Contexte
WebOustaou a démarré en 2025 comme une simple infrastructure pour une seule affaire : la pizzeria de mes parents, Darius Pizza, dont le "back-office" tenait dans un ensemble de clés Redis que je modifiais à la main.
Un an plus tard, c'est devenu une vraie plateforme de gestion multi-établissements : un site marketing public, un espace d'administration authentifié, et un template de site consommateur qu'on duplique pour chaque client, le tout partageant une même infrastructure et des mêmes packages internes. Le problème que vivait la pizzeria (des outils fragmentés, aucune source de vérité, tout qui passait par un développeur) est aujourd'hui résolu pour n'importe quel restaurant, boulangerie ou salon indépendant qui s'inscrit.
Ce qu'est WebOustaou aujourd'hui
La plateforme est un monorepo de trois applications Next.js partageant une couche de packages commune :
marketing(weboustaou.fr) : le site public. Tarifs, pages produit, roadmap publique, changelog et centre d'aide. Volontairement allégé en dépendances, aucun code Supabase, Stripe ou d'authentification ne peut y être compilé.admin(app.weboustaou.fr) : l'espace back-office authentifié où les propriétaires gèrent tout, du menu aux horaires en passant par les fermetures, les messages, le blog, les QR codes, les analytics, la facturation et l'accès équipe.site-template: un site consommateur mono-établissement, complet, pensé pour être dupliqué à chaque nouveau client. Chaque restaurant ou commerce obtient ainsi un site public dédié, rapide et optimisé SEO, construit sur la même base éprouvée en production.
En dessous, un seul projet Supabase (Postgres, hébergé à Paris) modélise une hiérarchie à trois niveaux : compte client, établissements, sites. La sécurité au niveau des lignes (RLS) est activée par défaut sur chaque table. Un client peut posséder plusieurs établissements physiques, et un établissement peut exposer plusieurs sites publics.
Une Seule Plateforme, pas une par Restaurant
Un propriétaire avec plusieurs établissements les gère depuis une seule connexion, en changeant de contexte plutôt qu'en jonglant entre plusieurs comptes. Les comptes d'équipe permettent d'inviter du personnel avec un accès limité, au lieu de partager un seul mot de passe pour tout le monde. Chaque table est cloisonnée par établissement via RLS depuis la toute première migration du schéma, bien avant qu'il n'existe la moindre authentification pour l'appliquer. Cette séparation n'a donc jamais été ajoutée après coup, elle fait partie de la fondation.
L'Espace d'Administration
Les propriétaires gèrent la présence digitale de leur restaurant ou commerce depuis leur téléphone ou leur ordinateur :
- Menu, catégories, produits, ingrédients et allergènes
- Horaires d'ouverture, fermetures exceptionnelles et messages temporaires
- Un blog intégré : rédaction, traduction, tags, planification et publication, avec métadonnées SEO et JSON-LD
- Les "Happenings", pour promouvoir un événement ou un pop-up en un clic, avec collecte d'intérêt sans création de compte
- Offres du menu et mise en avant de produits phares
- QR codes traçables et re-paramétrables pour les supports imprimés
- Analytics first-party, en grande partie sans cookies
Chacune de ces fonctionnalités a été livrée progressivement sur environ un an d'entrées de changelog. Pour la chronologie complète, voir l'article sur la roadmap.
QR Codes et Attribution
Les QR codes imprimés pointent vers une redirection courte (weboustaou.fr/q/{code}) plutôt que vers une URL fixe. Ça permet de repointer un code affiché sur un menu ou une vitrine sans devoir le réimprimer. Les scans sont enregistrés sans aucune donnée personnelle, ventilés par appareil et par jour. Un travail récent ajoute l'attribution de l'origine du trafic, en distinguant les scans QR, les visites directes et les liens traqués.
Facturation, Sécurité et Conformité
Les abonnements passent par Stripe (Checkout hébergé et Customer Portal). Ils sont répliqués dans Supabase et synchronisés par webhook, plutôt que traités comme source de vérité en direct : le statut de facturation reste ainsi interrogeable et protégé par RLS comme le reste. La tarification est volontairement plate et sans commission. Aucun prélèvement par commande, quoi que le commerce vende un jour en ligne.
La conformité est traitée comme une priorité, pas comme un ajout après coup : suppression de compte RGPD, bannière de consentement, analytics opt-in, contrôles de divulgation publique champ par champ (un propriétaire choisit explicitement de publier son adresse ou son numéro de téléphone), et données hébergées dans l'UE.
Un Vrai Client : Darius Pizza
Darius Pizza, la pizzeria de mes parents à Cavalaire-sur-Mer, a été le premier client de WebOustaou avant même que WebOustaou ne soit un produit. Trois ans après avoir quitté une simple page Facebook, elle se classe 2ᵉ sur Google pour "Pizza Cavalaire" (contre 8ᵉ auparavant), reçoit environ 3 800 visites par mois (contre environ 600 avant), et obtient un score de 98/100 en performance mobile. L'histoire complète, y compris ce qui reste encore à migrer vers la nouvelle plateforme, est racontée dans cette étude de cas.
Architecture Technique
- Framework : Next.js (App Router), 3 applications dans un même monorepo npm-workspaces
- Langage : TypeScript de bout en bout
- Backend & Auth : Supabase (Postgres, RLS par défaut, Auth avec email + Google OAuth)
- 15 packages internes :
ui,i18n,shared,urls,tenant,auth,analytics,consent,consumer-data,consumer-query,docs-content,docs-reader,editor, et d'autres, versionnés et publiés sur un registre privé - Facturation : Stripe (Checkout, Customer Portal, webhooks)
- Style : Tailwind CSS, shadcn/ui
- Protection anti-bots : Cloudflare Turnstile
- Hébergement : Vercel, région UE
L'architecture est volontairement séparée par frontière de compilation, pas seulement par dossier. L'application marketing ne peut pas importer Stripe, Supabase ou le module QR code, et ce n'est pas juste une convention : un test de dépendances automatisé l'impose.
Où en est le Projet Aujourd'hui
WebOustaou a atteint la v0.10.0-bêta en juillet 2026, un point où le produit cœur est fonctionnellement complet. Avant d'accueillir de vrais clients au-delà de Darius, il reste une passe de finitions ciblée. La phase suivante, c'est de passer de la finalisation de la plateforme à son utilisation concrète : construire de vrais sites clients, puis attaquer la commande en ligne.
Ce que ce Projet Représente
C'est l'exemple le plus clair dans mon portfolio d'une pensée d'architecte systèmes appliquée à un produit que je possède de bout en bout. Le schéma et la structure de packages ont été pensés dès le premier jour pour la gestion multi-établissements, la sécurité et une roadmap en cinq phases, pas retouchés une fois que ça a commencé à faire mal. Voir la seconde entrée WebOustaou pour la suite : commande en ligne, écrans de cuisine, et au-delà.
Bilan
WebOustaou, c'est ce qui se passe quand on applique à un site de petite entreprise la rigueur de l'ingénierie systèmes : traçabilité, RLS par défaut, migrations de schéma uniquement additives, une fiche de décision pour chaque choix non trivial. Rien de spectaculaire au final, et c'est tant mieux. Ça marche, tout simplement, pour un vrai commerce, tous les jours.
