Une Cuisine Avant un Code
J'ai grandi dans une famille de bouchers et de pizzaïolos. Dès quinze ans, j'ai travaillé en cuisine — la préparation, le rythme du service, et toutes les frustrations qui viennent avec la gestion d'un petit commerce alimentaire. Des années plus tard, en tant que développeur, j'ai reconnu ces mêmes frustrations sous un autre angle : les restaurateurs indépendants que je connaissais n'avaient que trois options pour exister numériquement — payer trop cher une agence, se battre avec un créateur de site générique qui va à l'encontre du fonctionnement réel d'un restaurant, ou dépendre de quelqu'un d'autre (souvent moi) pour la moindre mise à jour.
Rien de tout cela n'était pensé pour eux. J'ai donc construit ce que j'aurais aimé voir exister.
La Première Version N'était Pas un Produit
WebOustaou n'a pas commencé comme une plateforme SaaS. Il a commencé comme un backend privé pour une seule affaire : Darius Pizza, la pizzeria de mes parents à Cavalaire-sur-Mer. Avant que ce backend n'existe, leur "back-office" était un ensemble de clés dans une instance Upstash Redis — aucune source de vérité, aucune base de données, rien que mes parents ne pouvaient toucher eux-mêmes. Quand le menu changeait ou que les horaires évoluaient selon la saison, je modifiais du JSON à la main.
Ce n'est pas une critique d'un bricolage de début — c'est le point de départ honnête de la plupart des vrais produits. La première version fonctionnelle de WebOustaou modélisait exactement un tenant, dans un schéma Supabase pur, sans authentification et sans la moindre interface d'administration. Elle résolvait un problème réel, précis et un peu gênant avant d'essayer d'en résoudre un général.
Ce à Quoi les Petites Entreprises Font Vraiment Face
Une fois cette première version fonctionnelle, le schéma est devenu évident — parce qu'il n'était pas spécifique à la pizza. Les petites entreprises font face aux mêmes contraintes, quoi qu'elles vendent :
- Temps et connaissances techniques limités
- De multiples outils déconnectés qui ne communiquent pas entre eux
- Une gestion par défaut faible de la sécurité, de l'authentification et de la conformité
- Des logiciels tarifés et conçus pour des chaînes, pas pour un ou deux établissements
La plupart des logiciels de restauration du marché résolvent cela en étant soit trop chers, soit trop complexes, soit en prélevant une commission sur chaque commande — ce qui pénalise une entreprise pour son succès. Rien de tout cela ne rend justice à un propriétaire qui veut simplement que son menu soit correct, ses horaires exacts, et son site rapide, sans devenir administrateur informatique à mi-temps.
Construire la Fondation d'Abord
La décision qui a façonné tout ce qui a suivi a été de résoudre la couche fondation avant toute fonctionnalité métier spécifique : comptes, multi-tenant, sécurité, internationalisation, conformité. Le multi-tenant, la sécurité au niveau des lignes (RLS) sur chaque table, et l'i18n basée sur JSONB ont tous été pensés dans le schéma dès la toute première migration — alors qu'il n'y avait exactement qu'un client et aucun système d'authentification pour appliquer quoi que ce soit.
Cela ressemble à de l'ingénierie prématurée tant qu'on ne comprend pas la contrainte sous laquelle je travaillais réellement : le schéma est uniquement additif. Chaque phase future doit être absorbée en étendant l'existant, jamais en le réécrivant. Rajouter le multi-tenant ou la sécurité après coup aurait signifié une réécriture et un audit de sécurité complet ; quelques colonnes et prédicats en plus dès le premier jour évitent complètement ce scénario. C'est la même rigueur que j'applique professionnellement en tant qu'architecte systèmes — identifier les parties d'un système coûteuses à modifier plus tard, et les faire bien dès le début, même quand le premier client n'en a pas encore besoin.
Où ce Choix a Mené
Un an plus tard, cette fondation fait tourner une vraie plateforme multi-tenant : un espace d'administration, un site marketing public et un template de site consommateur duplicable, au service de restaurants au-delà de celui qui a tout déclenché — avec commande en ligne, écrans de cuisine et plus encore, conçus pour s'appuyer sur la même fondation sans nouvelle réécriture. L'architecture complète est ici, la roadmap est ici, et les résultats de Darius Pizza sont ici.
Pourquoi ça Compte Toujours pour Moi
Chaque décision produit chez WebOustaou passe par quelqu'un qui a réellement travaillé en cuisine et réellement vu une entreprise familiale se débattre avec des logiciels qui n'étaient pas pensés pour elle. Ce n'est pas une phrase marketing — c'est la raison même pour laquelle ce projet existe, et la raison pour laquelle je préfère livrer un périmètre plus restreint mais qui fonctionne vraiment pour un restaurant indépendant, plutôt qu'un périmètre large qui ne correspond qu'à moitié aux besoins d'une chaîne.
La mission est simple à énoncer et difficile à tenir : donner à chaque restaurant indépendant les mêmes outils numériques qu'une chaîne, sans la complexité, et sans prélever sur chaque commande.