MVP et roadmap

25 — P1 / P2 / P3

Découpage honnête : MVP produit (ce qu'il faut pour un pilote réel) ≠ premier incrément livrable dans cet environnement (pas de PostGIS garanti, pas de Redis, pas de tuiles sous contrat, pas de données Orléans).

MVP produit — Orléans draft

Inclus :

• City DNA versionnée + console d'édition
• Villes, zones (géométrie quand on l'a)
• Lieux, horaires, exceptions, closed_until
• Événements, offres, live updates
• Live / Freshness / Trust (définitions du doc 12)
• Recherche (FTS ou repli)
• Now, Ce soir, Week-end
• Carte : liste + couche géographique au niveau disponible (schéma ou tuiles)
• Fiches lieu et event, provenance
• Claim + file de revue
• Dashboard pro : aujourd'hui (counts réels), publier, studio event, offres
• Admin : DNA, modération, qualité, audit, flags
• CMS minimal (guide lié à des entités)
• SEO (indexation sélective, sitemap, structured data sans champs fictifs)
• Analytics first party
• PWA : manifest, shell, installable — le plugin de cet environnement existe déjà ; le service worker hors-ligne « lieux sauvés » est basique
• RBAC serveur
• Comptes optionnels

Exclus du MVP (même s'ils sont dans le schéma) :

• Créer ma soirée UI (P1) — le modèle peut être posé
• Notifications push
• Abonnements encaissés
• Campagnes sponsorisées actives
• City Pulse
• Billetterie, booking partenaire
• Avis
• QR redemption
• Groupe
• API publique
• Apps natives

Incrément environnement (démo architecturale puis produit)

Tant que les sources externes manquent, l'UI doit montrer les définitions, les empty states et un parcours avec fixtures marquées FIXTURE / non réelles. Les fixtures ne sont pas du contenu Orléans. Elles ne sont pas indexées (noindex, ville draft).

P1

Plan de soirée, notifications opt-in, abonnements Stripe, campagnes étiquetées, analytics pro un peu plus riches, favoris / follows.

P2

City Pulse (définition stricte), ticketing, booking, groupe, reco avec signaux, CRM opt-in, multi-lieux. Avis si juridique ok.

P3

Natif si le web ne suffit pas (pas avant mesure), API publique, dashboards partenaires institutionnels, ads plus larges.

Gate ville 2

Pas de deuxième ville published avant, qualitativement :

• usage du pilote réel (pas une démo) ;
• des pros qui reviennent publier ;
• fraîcheur acceptable au sens de la politique ;
• répétition côté public ;
• process city manager écrit.

Aucun seuil chiffré ici : les fixer sans données serait un faux critère. Le super admin coche une revue, l'audit garde la trace.

Checklist publication d'une ville

• Zones nommées ; géométrie ou acceptation explicite « sans carte polygonale »
• Données sourcées, licence notée
• Périmètre assumé (pas toute la métropole par défaut)
• SEO : title, description, pas de thin
• Un owner modération nommé
• Qualité : pas de héros Now rempli d'objets STALE
• Ville encore draft ou soft_launch tant que ces cases sont vides

Décision

• Choix : MVP = découverte + fraîcheur + publication pro + city DNA. Le reste est modèle ou phase.
• Alternative rejetée : tout le prompt en une livraison.
• Risque : pression pour afficher une ville « pleine ». Garde-fou : fixtures étiquetées, indexation fermée.
• Multi-ville : le wizard existe au MVP admin ; le publish de la ville 2 est gaté.