Compte et Monetisation

Compte et monétisation

Statut : 🟡 Brouillon · Màj : 2026-10-14 · Tickets : #383 (brouillon, à valider)

Principe

Consultation intégrale sans compte. Le compte est le prix de l'engagement, jamais celui de la découverte : aucune barrière avant la fiche parcours ; le compte est demandé au premier favori, à la première programmation, à la première création ou au premier signalement, et l'action reprend après la connexion (PU-02 dans Personas-et-Parcours-Utilisateurs). Le freemium est dans le MVP (décision d'Ilan, 21 septembre 2026), recentré le 24 septembre 2026 (D-023) : rien n'est limité dans l'usage, favoris et programmations compris ; Premium ouvre les parcours Premium et la création au-delà du premier parcours, offert à tous.

Anonyme vs compte

Fonction	Sans compte	Avec compte
Carte, recherche, filtres, météo	oui	oui
Fiche parcours complète, timeline, étapes	oui	oui
Partager un parcours (lien)	oui	oui
Ouvrir dans Google Maps	non : pas depuis la fiche, et le lancement demande un compte (D-014, D-029)	une fois le parcours lancé (E-07)
Favoris	—	oui, sans limite
Programmer, notifications	—	oui, sans limite
Go avec suivi, notation, historique	—	oui
Parcours Premium (access = premium)	fiche sans le détail des étapes 2 et suivantes (D-014)	idem en gratuit ; fiche complète, Programmer et Go en Premium
Créer un parcours	—	oui, sans limite (D-023 révisé, décision d'Ilan du 2026-09-28)
Confirmer ou signaler un lieu	—	oui
Profil public de créateur	consultation	oui

Un identifiant anonyme d'appareil sert à l'analytics et aux recherches récentes locales ; il est rattaché au compte à la connexion.

Authentification

• Apple (obligatoire sur iOS dès qu'une connexion tierce est proposée), Google, e-mail avec lien magique.
• Firebase Authentication comme fournisseur d'identité ; l'API vérifie le jeton Firebase et gère ses propres utilisateurs en base (id interne, rôle, plan).
• Rôles : user, editor (équipe Widoo, publie sans modération), moderator, admin.
• Première connexion : prénom ou pseudo, prérempli par Apple ou Google et alors facultatif (règle de l'App Review), obligatoire pour une connexion par e-mail (E-10, D-025).
• Suppression de compte depuis l'app (exigence des stores), sans choix (décision d'Ilan, D-025) : les parcours publiés restent en ligne, signés « Membre Widoo », sans lien vers le profil, avec leurs avis ; les avis que la personne a laissés sur d'autres parcours restent aussi, signés « Membre Widoo » (décision d'Ilan du 2026-09-28) ; profil, photo, anecdotes, favoris, programmations, historique, brouillons, parcours privés et signaux sont supprimés. Confirmation par alerte système ; une reconnexion peut être demandée si la session est ancienne. L'abonnement du store n'est pas résilié avec le compte : la page de suppression le rappelle aux abonnés. Après suppression, la même identité Apple, Google ou e-mail peut aussitôt recréer un compte, qui repart de zéro (décision d'Ilan, D-027).

Modèle économique

Les champs de monétisation (users.plan, routes.access, steps.booking_provider, routes.sponsored) existent dès le premier schéma, pour éviter une migration le jour où ils servent.

Freemium (MVP)

Révision du 2026-09-28 (décision d'Ilan du 2026-09-28) : la création de parcours devient gratuite et sans limite (les créateurs sont l'offre, la modération filtre) ; Premium ne porte plus que l'accès aux parcours Premium, en trois formules : abonnement (mensuel, annuel), pass 7 jours sans renouvellement, déblocage d'un parcours à l'unité. Les créateurs seront rémunérés après le MVP (affiliation et parcours Premium). Écrans à reprendre dans le ticket design de la révision (#210 : page Premium E-17 et fiche E-05 validées le 2026-09-29, D-072 ; pass en cours, compte facultatif, création et site dans les planches suivantes).

	Gratuit	Premium
Catalogue, fiches, recherche, filtres	tout	tout
Favoris, programmations, Go	sans limite	sans limite
Parcours Premium (Widoo ou utilisateurs)	fiche sans le détail des étapes 2 et suivantes, non programmables	complets et programmables
Création de parcours	sans limite	sans limite
Vérification, notation	oui	oui

• Formules Premium (révision du 2026-09-28) : abonnement mensuel et annuel ; pass 7 jours, achat non renouvelable (accès Premium complet pendant 7 jours) ; déblocage d'un parcours à l'unité, achat définitif pour ce parcours (route_unlocks). Prix (fixés le 2026-09-28 sur délégation d'Ilan, à partir de l'abonnement à 3,99 € par mois) : pass 7 jours 2,99 €, déblocage d'un parcours 1,99 € ; deux déblocages coûtent autant qu'un mois d'abonnement, ce qui oriente les réguliers vers l'abonnement et laisse le pass aux séjours courts.
• Abonnement mensuel et annuel par achat intégré (Apple et Google l'imposent pour du contenu numérique). Gestion via RevenueCat pour ne pas réimplémenter les reçus, les renouvellements et la restauration ; l'API reçoit les webhooks RevenueCat et met à jour users.plan et plan_expires_at.
• Prix décidés (21 septembre 2026, prix mensuel révisé le 25 septembre, D-040) : 3,99 € par mois, 29,99 € par an. Le prix n'est jamais en dur dans l'app, il vient du store.
• Essai gratuit de 7 jours sur les deux abonnements (décision d'Ilan, 25 septembre 2026, D-040) : offre d'introduction des stores (une fois par compte Apple ou Google), rappel et résiliation gérés par le store ; sans droit à l'essai, le bouton devient « S'abonner ». Les deux produits RevenueCat portent l'offre.
• Issues de l'achat (D-044) : annulation dans la fenêtre du store sans message ; échec en toast « Achat impossible » avec « Réessayer » ; achat en attente d'une validation (contrôle parental, paiement différé) : Premium s'active à la validation, par le webhook RevenueCat ; « Restaurer les achats » passe par la restauration de RevenueCat et rend l'abonnement et le pass ; les parcours achetés seuls sont rattachés au compte Widoo (route_unlocks) et ne dépendent pas de la restauration du store (D-073) ; toast si rien n'est trouvé ; hors connexion, achat et restauration désactivés.
• Présentation (D-072, E-17) : les trois formules sur le même plan, le pass mis en avant pour les visiteurs (téléphone dans une autre langue que le français ou région hors de France : pass en tête et présélectionné ; sinon l'annuel), et « Seulement ce parcours » depuis un parcours ; l'encart de la fiche d'un parcours Premium vend le parcours à l'unité directement. Acheter ne demande pas de compte (App Store, règle 5.1.1(v)) ; un achat fait sans compte vit sur le téléphone et le compte du store, et se rattache au compte Widoo dès la connexion. Juste après un parcours débloqué sans compte, la sheet de connexion propose de créer un compte « pour le garder » (recommandation du chef de projet reprise par Ilan, D-073) : sans compte, le déblocage reste sur le téléphone. Rien après un pass ou un abonnement, qui se restaurent par le store.
• L'écran Premium (E-17) s'ouvre depuis « Débloquer avec Premium » et l'encart d'un parcours Premium, et depuis l'encart Widoo Premium (en tête des Réglages, en bas de mon profil et de Modifier le profil, pour un compte gratuit), avec la raison. Rien n'est bloqué avant. Aucune relance push au MVP : la fin du pass est annoncée par un toast à la première ouverture qui suit, avec « Prolonger » (D-073). Pendant un pass, les Réglages montrent sa date de fin et « Prolonger » ; un nouveau pass s'ajoute au bout du premier ; programmer un parcours Premium après la fin du pass affiche une alerte avec « Débloquer ce parcours ».
• Création (révisée le 2026-09-28) : gratuite et sans limite ; seule limite, anti-spam : 3 parcours en attente de modération au plus par compte (settings.max_pending_routes), au-delà POST /routes/:id/submit répond 429 rate_limited et l'app le dit dans « Avant de soumettre » (E-14, D-073). Ancienne règle, abandonnée : un compte gratuit avait droit à un parcours, au-delà POST /routes répondait 402 premium_required (details.reason = create_limit). Compte tout parcours non supprimé, brouillon compris ; supprimer son unique parcours libère la place. La limite est dans settings (free.max_routes, 1).
• Un abonné qui repasse en gratuit, ou dont le pass 7 jours se termine, garde tous ses parcours, publiés ou non, et continue d'en créer (création gratuite depuis le 2026-09-28) ; les parcours Premium redeviennent verrouillés, sauf ceux débloqués à l'unité. Ses sorties Premium déjà programmées restent dans À venir, sans départ ni changement de date : « Votre sortie » propose « Débloquer avec Premium », le déblocage du parcours seul et le pass (D-038, révisé en D-073).
• Signature et Premium sont deux notions distinctes (D-014, précision d'Ilan) : Signature = tout parcours créé par l'équipe Widoo (auteur au rôle editor), badge bleu ; Premium = parcours réservé aux abonnés, routes.access = premium, badge encre à couronne dorée, qu'il soit de Widoo ou d'un utilisateur. Un Signature peut être gratuit ou Premium. Règle d'attribution de access = premium (décision d'Ilan du 2026-09-28) : automatique, un parcours est Premium s'il a 4 étapes ou plus, ou s'il a au moins 50 avis avec une note moyenne supérieure à 4,5 ; seuils dans settings (premium.min_steps 4, premium.min_ratings 50, premium.min_rating 4.5), recalculés à la publication et chaque nuit ; un parcours qui devient Premium reste accessible pour les sorties déjà programmées ; objectif initial de 5 à 10 Signature au lancement conservé. Sans abonnement : l'étape 1 est complète, les suivantes se réduisent à l'heure, la catégorie, la durée et le trajet à pied ; ni nom, ni lieu, ni coordonnées, ni conseil, ni tracé, dans la fiche comme sur la carte (départ seul). Le filtrage se fait dans l'API, pas seulement dans l'app, et ne s'applique qu'à qui n'a pas droit au parcours : l'abonné (et, avec #66, le titulaire d'un pass en cours ou d'un déblocage à l'unité) reçoit le détail complet sur la carte comme dans la fiche, dès la recherche, avec tracé, étapes et tooltips comme pour un parcours gratuit (D-075 ; contrat dans API › Card de recherche) ; le paywall E-17 s'ouvre depuis « Débloquer avec Premium » et l'encart de la fiche.

Fin de la limite de création (brouillon #383)

🟡 Brouillon du 2026-10-14, à valider par Ilan, en réponse à #383. Rien n'est retiré du texte validé tant qu'Ilan n'a pas tranché : les pages API, Analytics, Ecrans et Modele-de-Donnees portent une note qui renvoie ici. Après validation : entrée D-xxx au Design-Changelog et nettoyage des passages cités.

Constat. D-073 (révision du 2026-09-28) rend la création gratuite et sans limite ; E-17 ne s'ouvre plus depuis « Créer un parcours » (D-072, D-073) et POST /routes crée un brouillon sans limite (#48, PR #420). Le wiki garde des traces de la limite de D-023 :

• API › Conventions : create_limit parmi les details.reason de premium_required, et details.limit « pour la création » ;
• API › Compte : canCreateRoute dans GET /me, « faux pour un compte gratuit qui a déjà son parcours » ;
• Analytics : raison create_limit et source create de paywall_shown ; KPI Freemium « ou la limite de création » ;
• Modele-de-Donnees › settings : « création gratuite free.max_routes 1 » ;
• sur cette page, la puce Création de Freemium, qui décrit encore l'ancienne règle et sa clé free.max_routes.

Dans le code (lu le 2026-10-14) : canCreateRoute n'a jamais été ajouté à GET /me (schéma Me de packages/shared) ; aucune limite de création n'existe ; create_limit ne survit que dans paywall_shown.reason (packages/shared/src/analytics.ts, retrait suivi par #415), sans aucun appelant. La limite anti-spam de D-073 est livrée (#66, PR #410 ; #48, PR #420) : POST /routes/:id/submit répond 429 rate_limited avec details: { reason: 'pending_routes', limit } quand l'auteur a déjà settings.max_pending_routes (3) autres parcours en attente de relecture ; le parcours reste dans son statut. Une révision en attente d'un parcours publié compte pour un ; un compte de l'équipe (editor) publie sans relecture et n'est pas limité. Ces deux règles ne sont écrites nulle part dans le wiki (question 4).

Proposition.

1. canCreateRoute sort du contrat de GET /me, sans remplaçant. « Créer un parcours » (compte requis) ouvre l'assistant (E-12) sans appel préalable : il n'y a plus rien à vérifier avant de créer.
2. La seule limite reste celle de D-073, à la soumission. L'app l'apprend par la 429 de POST /routes/:id/submit (details.reason = pending_routes) et affiche la variante validée de « Avant de soumettre » (E-14), avec le nombre lu dans details.limit, jamais en dur. « Enregistrer en privé » reste toujours possible.
3. premium_required (402) ne porte plus qu'une raison, premium_route ; details.limit sort de ses détails et passe à rate_limited (429), avec details.reason (pending_routes) pour le distinguer d'une limite de débit.
4. Analytics : paywall_shown.reason vaut premium_route ou premium_card ; la source create sort aussi, plus aucun paywall ne s'ouvrant depuis la création ; KPI Freemium : « part des utilisateurs actifs qui rencontrent un parcours Premium dans le mois, conversion paywall → achat par raison, churn mensuel ».
5. E-17 garde toutes ses autres ouvertures et raisons (parcours Premium, encart d'un parcours Premium, encart Widoo Premium, sortie Premium après la fin de l'abonnement ou du pass, « Prolonger ») : seule l'ouverture liée à la création disparaît, et les maquettes l'ont déjà retirée (D-072, D-073).
6. free.max_routes sort de la liste des réglages ; la puce Création ne garde de l'ancienne règle qu'une phrase : « Ancienne règle (D-023), abandonnée le 2026-09-28 : un parcours par compte gratuit. »

Pourquoi. La limite anti-spam porte sur la soumission, pas sur la création : un brouillon ou un parcours privé ne coûte rien à la modération et sert à son auteur (programmer, partager par lien). Un indicateur dans GET /me ne serait juste qu'au moment de l'appel (une place se libère dès qu'un parcours sort de relecture), alors que l'API vérifie la limite dans la transaction de soumission ; la 429 suffit, et E-14 validé (« Soumettre » toujours actif, la fenêtre « Avant de soumettre » dit la limite) se construit dessus.

Ce qu'elle écarte.

• Redéfinir canCreateRoute en « faux quand le compte a atteint max_pending_routes » : le nom mentirait (on peut toujours créer), il pousserait l'app à fermer l'éditeur alors que D-073 laisse créer et enregistrer en privé, et il doublerait une règle que l'API tient déjà.
• Le remplacer par canSubmitRoute ou par un compteur pendingRoutes { count, limit } dans GET /me pour prévenir avant « Soumettre » : aucun écran validé ne l'affiche avant le geste (question 2).
• Garder create_limit dans le catalogue pour l'historique : aucun écran ne l'a jamais émise.

Impact sur les pages et les écrans.

Page ou écran	Aujourd'hui	Après validation
API › Conventions	premium_required : premium_route ou create_limit, details.limit pour la création	premium_route seulement ; rate_limited documente details.reason (pending_routes) et details.limit
API › Compte, GET /me	canCreateRoute	retiré ; le reste de la ligne inchangé
API › Création, POST /routes/:id/submit	422 coherence_blocked seulement	plus 429 rate_limited (pending_routes, limit) ; révision en attente comptée ; compte editor non limité
Analytics, paywall_shown et KPI Freemium	create_limit, source create, « limite de création »	retirés
Modele-de-Donnees › settings	free.max_routes 1	retiré
Freemium, puce Création	détail de l'ancienne règle	une phrase d'historique
Ecrans › E-17	ne s'ouvre déjà plus depuis « Créer un parcours » (D-072)	inchangé, aucune maquette à reprendre
Ecrans › E-11	ne cite pas la limite	inchangé
Ecrans › E-12	l'assistant s'ouvre depuis « Créer un parcours » (D-073 : création sans E-17)	inchangé : aucun contrôle avant l'ouverture
Ecrans › E-14	« Avant de soumettre », trois parcours en relecture, 429 rate_limited (D-073)	inchangé ; le nombre vient de details.limit ; cas hors connexion selon la question 5

Tickets, à découper par MANAGER après validation : #45, la puce « Limite de création (D-023) » et le critère « Un compte gratuit qui a déjà un parcours n'entre pas dans l'éditeur » deviennent « Créer un parcours ouvre l'éditeur sans appel à GET /me ; un compte gratuit crée plusieurs parcours ; au-delà de 3 en relecture, Soumettre montre la variante de Avant de soumettre et Enregistrer en privé reste possible » ; #415 libéré, avec la source create si la question 3 est retenue ; côté API, rien à retirer (canCreateRoute n'a jamais été codé) ; un critère sur GET /me n'est nécessaire que si la question 1 est tranchée autrement.

Questions à Ilan.

1. Retirer canCreateRoute de GET /me, sans remplaçant ? Recommandé : oui, pour les raisons ci-dessus.
2. Prévenir l'auteur avant qu'il touche « Soumettre » qu'il a déjà 3 parcours en relecture (compteur dans GET /me, ou mention dans Parcours › Créés) ? Recommandé : non au MVP ; la fenêtre validée de E-14 le dit au bon moment, et trois parcours en relecture à la fois resteront rares avec une réponse sous 72 h.
3. Retirer aussi la source create de paywall_shown ? Recommandé : oui, plus aucun paywall ne s'ouvre depuis la création.
4. Confirmer deux règles déjà codées et absentes du wiki : une révision en attente d'un parcours publié compte dans les 3 ; un compte de l'équipe (editor) n'est pas limité. Recommandé : confirmer les deux ; sans la première, un auteur contournerait la limite par des modifications de parcours publiés ; la seconde suit E-14 (« Compte Widoo : publié sans relecture »).
5. Un parcours soumis hors connexion (E-14 : « Envoi au retour du réseau ») et refusé par la 429 au retour du réseau : que voit l'auteur ? Recommandé : le parcours reste dans son statut (brouillon ou privé) dans Parcours › Créés, et un toast d'erreur à l'envoi, « « {titre} » n'est pas parti : 3 parcours en relecture, c'est le maximum. », avec « Voir mes parcours » ; si Ilan préfère un écran, il passe par une planche de l'éditeur.

Préparé, non activé

• steps.booking_url et steps.booking_provider (restaurant, ticketing, activity, other) : lien externe simple au MVP, remplaçable par un lien affilié sans changement de schéma.
• routes.sponsored booléen, false partout, prévu pour la mise en avant partenaire avec mention obligatoire.
• Événements analytics booking_link_opened avec le fournisseur, pour mesurer le potentiel d'affiliation avant de la négocier.

Pistes après validation du MVP

• Premium élargi : mode Surprise, personnalisation, badges exclusifs, selon les données d'usage.
• Affiliation : restaurants (TheFork), billetterie (musées, expositions), activités. Cohérente avec la programmation.
• Partenariats : offices de tourisme, villes, hôtels, lieux culturels ; parcours co-créés et marqués.
• Mise en avant sponsorisée : parcours ou lieux partenaires, toujours signalés comme tels pour préserver la confiance.

Ce qui est exclu

Publicité display, vente de données, limitation du nombre de parcours consultables ou de fiches ouvertes en gratuit : la consultation reste illimitée pour garder une mesure propre de l'intérêt du produit.

Profil public et communauté

• Profil public de créateur (E-16) dès le MVP, même page que mon profil (E-09) sans « Modifier le profil » : photo ou initiale, prénom ou pseudo, badge Créateur certifié, quartier (facultatif) et ancienneté, bio (150 caractères), chiffres (parcours publiés, sorties sur ses parcours, note moyenne, chacun affiché seulement s'il existe), À la une (jusqu'à 3 parcours publiés choisis, dans l'ordre choisi), anecdotes (jusqu'à 3 : une question choisie dans une liste gérée côté serveur, huit au lancement, réponse de 150 caractères), tous ses parcours publiés avec tri (Récents, Mieux notés, Durée) et filtre par ambiance à partir de 4 parcours. Accessible depuis toute fiche et toute card. Pas de contact, pas d'abonnement, pas de messagerie.
• Créateur certifié (D-023) : sceau bleu sur le profil et après le prénom sur chaque parcours du créateur. Attribué automatiquement quand les trois critères sont remplis, tous comptés sur ses parcours publiés (D-091) : au moins 3 parcours vérifiés (badge Vérifié : tous leurs lieux vérifiés) ; une note moyenne de 4,5 ou plus, moyenne de tous les avis de ses parcours, chaque avis comptant une fois ; au moins 3 sorties sur ses parcours, c'est-à-dire des sorties menées jusqu'au bout (completed) par d'autres utilisateurs, une par personne et par parcours : ni ses propres sorties, ni les sorties arrêtées, annulées ou « Pas fait ». Le chiffre « sorties sur ses parcours » du profil suit la même définition. Recalcul chaque nuit, badge retiré si un critère n'est plus rempli ; un nouveau parcours pas encore vérifié ne le fait pas perdre. Seuils dans settings, réglables sans mise à jour de l'app. L'équipe peut attribuer ou retirer le badge dans l'admin, et ce choix l'emporte sur le calcul.
• Sur son propre profil : encart « Devenez créateur certifié » tant que le badge n'est pas obtenu, avec ce qui manque ; encart « Complétez votre profil » (photo, bio, anecdote) jusqu'à ce que les trois soient faits. Les visiteurs ne voient ni l'un ni l'autre.
• Un utilisateur peut rendre son profil non public par l'interrupteur « Profil public » des Réglages (users.is_public = false, D-025) : ses parcours affichent alors « Membre Widoo » sans lien ni sceau, son profil est introuvable par lien ; tout revient quand il réactive.
• Après le MVP : espace perso avec statistiques ; badges (premier parcours publié, 10 vérifications, parcours 100 fois programmé), abonnement à un créateur, fil d'activité. Le modèle prévoit une table badges et user_badges sans les implémenter.

Liens de réservation et affiliation

Quand une étape a à la fois un lien de réservation du créateur et un lien partenaire de Widoo, c'est le lien du créateur qui s'affiche (décision d'Ilan du 2026-09-25, D-048) : c'est sa rémunération, et ce qui l'incite à créer. Le lien partenaire de Widoo ne sert que si le créateur n'en a pas mis. Un lien déclaré affilié s'affiche avec la mention « Lien affilié » près de « Réserver ».