Parcours client

Pas d'onboarding long. Les préférences ne sont demandées que lorsqu'elles changent un résultat (budget, ambiance, taille de groupe) et peuvent être ignorées.

J1 — Anonyme, « je veux faire quelque chose »

1. Ouvre /{ville}. 2. Voit la ville, la recherche, les ancrages, les modules non vides. 3. Ouvre Maintenant ou Ce soir. 4. Choisit un lieu ou un événement. 5. Action forte optionnelle : itinéraire, sauver, partager, lien de réservation.

Sans données : empty state « Rien de vérifié actuellement dans cette zone. Voici ce qui commence bientôt. » — la deuxième phrase n'apparaît que s'il existe des événements futurs réels. Sinon elle est omise.

J2 — Recherche

« bar techno », « manger après minuit », « concert gratuit », « terrasse », « rue de bourgogne » sont des intentions à supporter, pas des requêtes dont on affirme qu'elles ont des résultats à Orléans.

Parcours : saisie → suggestions (lieux, zones, catégories, événements) → résultats liste + carte → fiche.

Typo, accents, préfixe : voir Search. Zéro résultat → enregistré anonymement comme search gap + empty state. Jamais de résultat « proche » inventé présenté comme match.

J3 — Carte

Ouvre la carte → viewport = bbox de la zone ou de la ville si elle existe → marqueurs des objets dans le viewport et non expirés → scroll liste synchronisé → tap marqueur → mini-fiche → fiche.

Si les tuiles ne chargent pas : « La carte ne peut pas charger. Les résultats restent disponibles en liste. »

Géolocalisation : bannière opt-in séparée du consentement cookies. Refus = parcours intact, centré sur la zone choisie.

J4 — Fiche et confiance

L'utilisateur voit une phrase de provenance (« Mis à jour par l'établissement » + durée relative si updated_at existe, ou « Source officielle », ou « Non vérifié »). Il ne voit pas un score 0–100.

J5 — Créer ma soirée (P1, flag off par défaut)

1. Contraintes : créneau, taille de groupe, budget par personne si donné, ambiance, point de départ (zone ou géoloc). 2. Le système récupère des lieux/événements qui satisfont horaires, distance, fraîcheur. 3. Propose une séquence (ex. repas → verre → concert) uniquement avec des entités réelles. 4. Chaque étape : primary + 2 alternatives si elles existent. S'il n'y en a pas, le dire. 5. « Démarrer ma soirée » fige un parcours actif : prochaine étape, heure, distance, itinéraire si fournisseur dispo, sinon distance simple, alternative.

Si l'étape devient invalide (annulation, fermeture) : remplacement par alternative ou message « plus d'alternative vérifiée ».

Pas de chatbot qui « invente une soirée ».

J6 — Compte optionnel

Déclencheurs utiles : favori, suivi, rappel d'événement, réservation. Jamais une modale au premier écran.

Préférences réversibles : reset, couper personnalisation, couper localisation, couper notifications.

J7 — Groupe (prévu, pas MVP)

Modèle : night_plans, night_plan_members, night_plan_votes, night_plan_suggestions. Pas d'UI. Invitation = P2. plans est réservé aux abonnements. Un plan sans compte expire (défaut proposé 72 h).

Décisions

D1 — Partage sans compte

• Choix : URL de fiche et URL de plan (le plan public en lecture si l'auteur le décide).
• Risques : fuite d'un plan privé. Défaut : plan privé, lien non devinable (UUID).

D2 — Itinéraire dégradé

• Choix : abstraction RoutingProvider. Si indisponible : distance à vol d'oiseau libellée « distance directe », jamais un temps de trajet.
• THIRD-PARTY DEPENDENCY : aucun fournisseur d'itinéraires n'est sous contrat dans cette phase.
• Multi-ville : le fournisseur est global ; les modes (marche, vélo, transport) dépendent des données de la ville. Transport public : off tant que EXTERNAL DATA REQUIRED.

Erreurs

Messages précis, pas de code HTTP nu. Carte morte ≠ liste morte. Recherche morte : réessayer + lien vers Now.