Une Roadmap Sans Dates, Volontairement
La roadmap interne de WebOustaou évite délibérément de s'engager sur des dates. Chaque phase est conçue pour être livrable indépendamment, et le schéma est construit pour ne faire que grandir, jamais pour exiger une réécriture afin d'atteindre la phase suivante. Voici ce qui a réellement été livré, dans l'ordre, et ce qui vient ensuite.
Ce qui a été Livré : un An d'Entrées de Changelog
Le changelog public est daté et précis, ce qui en fait une source plus honnête que n'importe quel pitch. Une chronologie condensée :
- Juillet 2025 — le premier site restaurant WebOustaou est mis en ligne : menu, photos, horaires, une carte, pensé mobile-first dès le premier jour. Le panneau d'administration suit deux semaines plus tard.
- Août 2025 — Darius Pizza devient le premier restaurant à tourner sur WebOustaou en production. La gestion des photos et des dates de fermeture suivent peu après.
- Septembre 2025 — gestion multi-établissements depuis un seul compte, et première démo publique en ligne.
- Octobre 2025 — un site vitrine dédié (header, hero, navigation complète du menu) devient le standard pour chaque nouveau client, dupliqué depuis le même template en production. Le statut ouvert/fermé en temps réel arrive avec lui.
- Novembre 2025 — QR codes : création, personnalisation et diffusion de liens traçables et re-paramétrables.
- Décembre 2025 — pages légales et bannière de consentement aux cookies, avant tout effort pour accueillir plus de clients.
- Janvier 2026 — comptes d'équipe : plusieurs membres du personnel, un seul espace de travail, accès révocable plutôt que mot de passe partagé.
- Février 2026 — statistiques de scans pour les QR codes, et gestion structurée des ingrédients.
- Mars 2026 — améliorations du SEO local.
- Mai 2026 — un centre d'aide bilingue est mis en ligne, documentant le produit tel qu'il est réellement utilisé.
- Juin 2026 — la roadmap publique elle-même est livrée, teasant ce qui est couvert ci-dessous.
- Juillet 2026 — un mois dense : publication de blog intégrée, la fonctionnalité "Happenings" pour la promotion d'événements en un clic, offres du menu et mise en avant de produits, analytics d'origine de trafic — et l'étape v0.10.0-bêta, que l'équipe décrit elle-même dans son changelog comme le point où "le produit cœur est fonctionnellement complet."
Soit environ un an entre le premier site et une bêta fonctionnellement complète — pas rapide selon les standards du hype, et c'est volontaire. Chaque élément ci-dessus tourne toujours en production pour le client qui était là dès le premier.
Ce que Signifie Vraiment la Bêta v0.10
Atteindre la bêta ne signifie pas que la roadmap est terminée — cela signifie que le cœur du back-office (menu, horaires, fermetures, messages, blog, happenings, offres du menu, tracking QR, analytics, facturation, comptes d'équipe) est assez complet pour arrêter de construire la fondation et commencer à construire dessus. Ce qu'il reste avant d'accueillir des clients au-delà du premier est une passe de finitions ciblée, pas une nouvelle architecture.
Ce qui est Conçu Ensuite
La roadmap publique étiquette chaque élément à venir shipped, in-dev ou considering — pas de vague "bientôt disponible". Actuellement in-dev ou en tête de liste :
- Cœur de commande — commandes, lignes de commande, et règles de modification structurées (retirer un ingrédient change le prix et la composition, pas seulement une note textuelle), construit sur des données d'ingrédients et d'allergènes déjà traitées comme des entités à part entière dans le schéma.
- KDS — gestion et planification unifiées des commandes — un Kitchen Display System : écrans par poste, routage des commandes en temps réel vers la cuisine, unifié sur tous les canaux de commande. Listé comme
in-devsur la roadmap publique.
Plus loin, sous à l'étude : la commande web avec comptes clients et paiements, la commande sur tablette en salle, le routage automatique des tickets vers le bon poste de cuisine, et — l'élément le plus ambitieux de la liste — un agent IA capable de prendre directement les commandes téléphoniques d'un restaurant, avec un repli humain pour tout ce qu'il ne peut traiter.
Pourquoi la Roadmap se Lit Ainsi
Aucune de ces phases ultérieures n'est une surprise greffée sur un produit existant. Les décisions de schéma décrites dans l'article sur l'architecture — RLS dès la première migration, ingrédients en tant que tables de référence plutôt qu'en texte incorporé, le récent rattachement des données opérationnelles du site vers l'établissement — ont été prises précisément pour que cette roadmap n'exige pas de réécrire ce qui fonctionne déjà. Un aperçu plus détaillé de ce qui arrive, y compris la conception du KDS lui-même, se trouve ici.
Une roadmap sans dates n'est pas un manque d'ambition — c'est le pari que livrer la bonne fondation une seule fois vaut mieux que livrer la mauvaise rapidement et la reconstruire deux fois.