Vision produit

Statut : architecture. Rien n'est implémenté. Aucun chiffre d'usage n'existe.

Énoncé

La plateforme est le système d'exploitation numérique contextuel d'une ville : elle répond à « que puis-je faire ici, maintenant ? », pas à « quels établissements sont recensés ? ».

Elle relie, dans une seule décision :

où · quoi · quand · maintenant · avec qui · budget · distance · disponibilité connue · ambiance · itinéraire.

Trois produits, un seul graphe de données :

North stars comportementales (définitions, pas des cibles chiffrées — aucune cible numérique n'est inventée) :

• Client : ouvrir la plateforme quand on veut faire quelque chose. Succès de session = une action forte (itinéraire, réservation, sauvegarde d'événement, favori, partage, plan de soirée, usage d'offre).
• Pro : publier ce qui est vrai aujourd'hui. Actif = connexion récente ou publication ou modification d'événement ou mise à jour d'offre.
• City Manager : densité utile et fraîcheur, pas le nombre brut de fiches. Mille fiches périmées valent moins que moins de fiches fiables.

Décisions

D1 — OS de ville, pas annuaire

• Choix : le cœur est un moteur temporel (ouvert / en cours / bientôt / expiré) branché sur une géographie configurable.
• Alternatives : annuaire SEO ; clone de carte ; média éditorial ; logiciel de caisse.
• Compromis : moins de pages indexables au départ ; plus de logique métier.
• Risques : sans données fraîches, le produit retombe en annuaire. Cold start = risque n°1.
• Pourquoi Orléans puis d'autres villes : Orléans sert à prouver la densité sur un petit territoire de sorties. Le moteur ignore le nom de la ville ; seule la City DNA change.

D2 — Trois expériences, un domaine

• Choix : interfaces séparées, identité / lieux / événements / offres / fraîcheur / recherche / reco / analytics / permissions partagés.
• Alternatives : trois produits et trois bases ; un seul écran « mode » qui mélange pro et public.
• Compromis : plus de surfaces UX à tenir cohérentes ; une seule vérité évite les fiches divergentes.
• Risques : le dashboard pro dérive en back-office administratif. Garde-fou : la première question de l'accueil pro est « comment attirer du monde aujourd'hui ? ».
• Multi-ville : un compte pro peut, plus tard, gérer plusieurs lieux dans plusieurs villes sans dupliquer le code. Le rôle City Manager est scopé à une ville.

D3 — Le compte n'est pas un péage

• Choix : découverte, recherche, carte, fiches accessibles sans compte. Le compte sert favoris, suivis, notifications, réservation, historique, préférences.
• Alternatives : inscription forcée (plus de données, moins d'usage) ; jamais de compte (pas de rétention outillée).
• Compromis : personnalisation faible au début. C'est accepté.
• Risques : dark patterns d'inscription. Interdits.

D4 — Honnêteté comme fonctionnalité

• Choix : tout libellé LIVE, OPEN NOW, AVAILABLE, TONIGHT, TRENDING, BUSY a une définition technique (voir Live, Freshness, City Pulse). Si la donnée manque : UNKNOWN, jamais une supposition.
• Alternatives : scores « magiques », fréquentation inventée, trending éditorial déguisé en signal.
• Risques : l'UI paraît plus vide que les concurrents. C'est le bon vide.

D5 — Monétisation après densité

Ordre : fiches gratuites → dashboard pro → abonnement → visibilité sponsorisée étiquetée → réservation / billetterie → ads avancés → multi-sites. Les prix ne sont pas dans le code et ne sont pas fixés dans cette architecture (étude commerciale absente).

Hors produit (ne pas construire)

Microservices « par principe », blockchain, métavers, VR, monnaie de fidélité complexe, agents autonomes partout, réseau social complet, API publique au MVP.

Flags

• Densité initiale Orléans : EXTERNAL DATA REQUIRED (sources autorisées uniquement).
• Aucune North Star chiffrée : pas de cible WAU inventée.