# Cahier des charges — Application utilisateur Uluana

Base : conversations du projet, `overview.md`, `ways-of-working.md`, `SPEC_format_cartes_mesure.md`, `uluana_catalog.json`, `uluana_audit.json`. État au 10/09/2026.

---

## 1. Principe directeur (non négociable)

**Une seule chose visible à la fois.** L'utilisateur est un non-initié : il ne doit jamais voir un tableau de bord, une liste de 124 cartes, ou un choix ouvert. Il voit :
1. La carte du moment (objectif → checklist → mesure)
2. Sa progression (2 barres : parcours + métrique réelle)
3. Rien d'autre par défaut

**Autonomie totale côté utilisateur.** Pas de blocage, pas d'étape imposée hors quiz initial et cadences de mesure. Il avance à son rythme, sans validation humaine requise pour progresser.

**Contrôle admin permanent et invisible.** Tout ce que l'utilisateur fait doit être traçable et modifiable côté `/control` sans qu'il en ait conscience — c'est un principe d'architecture, pas une fonctionnalité isolée.

Ces trois règles priment sur toute décision de design ultérieure.

---

## 2. Parcours utilisateur cible

| Étape | Exigence ergonomique |
|---|---|
| Landing / signup | Zéro friction, paiement Stripe en 1 écran (400 € + engagement mensuel visible avant paiement) |
| Quiz onboarding | Détermine profil P-01→P-10 + `niveau_estime`. Questions fermées uniquement, pas de champ libre. 5 min max |
| Carte recommandée | Une seule carte affichée par défaut, pas de liste. Ordre : Acquisition avant Image de marque tant que le volume de contact n'est pas établi |
| Format carte (Duolingo) | `objectif` → `checklist` (actions concrètes, tutoiement, résultat avant préparation) → `mesure` (questions par métrique, cadence propre à chaque métrique) |
| Relevé de mesure | N'afficher que les questions dont l'échéance est dépassée. Si une question booléenne = non, masquer les questions dépendantes du mois |
| Progression | XP, niveau 0–5, déblocages sociaux (forum, page catalogue, affiliation 20 %) |
| Communauté | Accès pairs plus avancés — uniquement après déblocage, contenu modéré éditorialement, jamais de commentaires bruts |

**Ordre d'implémentation imposé** : ne jamais construire un écran secondaire (communauté, page personnelle) avant que le cœur (carte → mesure → XP) soit fluide sur mobile. C'est ce cœur qui génère la rétention, donc le revenu récurrent.

---

## 3. Exigences ergonomiques strictes

- Tutoiement partout, vocabulaire zéro-jargon, orienté résultat client
- Mobile-first obligatoire : sticky toolbar, bottom-sheet, swipe — pas de pattern desktop porté tel quel
- Jamais de `confirm()` natif — `window.uluanaConfirm()` uniquement
- Autosave systématique, aucune perte de saisie possible
- Un relevé multi-questions (ex. cadence 30 j) se pose en une seule fois, jamais en plusieurs écrans
- Aucune notation ouverte, aucun avis non modéré publié brut

---

## 4. Contrôle et suivi administrateur (ordres de développement)

L'admin doit pouvoir, sans que l'utilisateur le sache :

1. **Voir en temps réel** : dernière connexion, carte en cours, historique des relevés, score de saturation/risque de décrochage
2. **Détecter le décrochage automatiquement** : alerte si aucun relevé/action depuis N jours → doit déclencher une tâche dans le module Prospection (déjà construit) pour relance manuelle
3. **Surcharger manuellement** : réassigner un parcours, forcer un déblocage, corriger un `niveau_estime` mal calculé par le quiz
4. **Piloter sans redéploiement** : tout ce qui est contenu (cartes, parcours, seuils de déblocage) doit rester modifiable depuis `/control`, jamais en dur dans le code — c'est déjà la règle pour les cartes (JSON + `_index.json`), à étendre aux seuils de déblocage et aux cadences

**Ordre** : le tableau de bord admin de suivi de décrochage n'existe pas encore — c'est la brique de contrôle la plus rentable à construire maintenant, car elle transforme un simple SaaS passif en accompagnement actif sans effort humain supplémentaire (le signal déclenche, l'humain n'a qu'à agir sur l'alerte).

---

## 5. Matrice valeur / impact / rapidité pour un effort minimal

Priorisation stricte — à exécuter dans cet ordre :

| # | Action | Valeur / impact | Effort | Pourquoi c'est prioritaire |
|---|---|---|---|---|
| 1 | Centraliser Stripe sur `stripe-config.json` | Protège le revenu (fin des prix codés en dur, source d'erreurs de facturation) | Faible | Un seul fichier à corriger, impact direct sur chaque euro encaissé |
| 2 | Finaliser Threads (OAuth + premier token + import corpus) | Acquisition gratuite et automatisée | Faible | Backend déjà fait à 90 %, il ne manque que l'activation |
| 3 | Alerte admin de décrochage (§4.2) | Rétention → réduit le churn sans effort commercial | Moyen | Réutilise les données déjà collectées, aucun nouveau tracking à créer |
| 4 | Débllocage 3 — affiliation 20 % à vie | Croissance virale, coût d'acquisition proche de zéro | Moyen | Mécanique déjà spécifiée dans `overview.md`, juste à implémenter |
| 5 | `niveau_estime` pour pondérer les recommandations | Meilleure pertinence → meilleure rétention précoce | Moyen | Le quiz existe déjà, il manque le calcul et son injection dans le tri des cartes |
| 6 | Parcours de parrainage Accompagné (essai 14 j + crédit 40 %) | Ticket moyen élevé (jusqu'à 4 000 €), fort effet de levier | Élevé | Flux non encore défini précisément — à cadrer avant de coder, sinon reprise coûteuse |
| 7 | Déblocages 1 et 2 (forum, page personnelle catalogue) | Rétention + désirabilité sociale | Élevé | Nécessite des conditions multi-critères et une UI dédiée |

Ordre 1 → 2 → 3 → 4 → 5 avant tout le reste : chaque item protège ou fait croître le revenu avec un effort de développement inférieur à une semaine, contrairement aux items 6-7.

---

## 6. Ordres de communication

Positionnement à respecter dans tout contenu produit (humain ou généré par l'agent Threads) :

- **Ton** : « partenaire discret qui fait progresser sans brusquer » — jamais la posture du formateur classique
- **Preuve sociale uniquement issue de données réelles** : les blocs de preuve sociale sur les cartes (stat agrégée, avant/après) sont calculés depuis les relevés utilisateurs, jamais rédigés à la main — ne pas dévier de cette règle même pour aller vite
- **Contenu communautaire toujours édité par Uluana** avant publication — aucun commentaire brut, aucune note ouverte
- **Axe prioritaire de communication actuel** : Threads (agent IA déjà branché), pas de nouveau canal tant que celui-ci n'est pas activé et mesuré
- **Message de vente** : l'offre se justifie par l'action mesurable, pas par la promesse — chaque carte doit pouvoir citer un résultat chiffré réel dès que le volume de données le permet (cf. règle preuve sociale ci-dessus)
- **Cadence de contenu** : s'appuyer sur le corpus auto-importé des réponses déjà publiées plutôt que d'écrire chaque post de zéro — l'agent est fait pour ça, l'utiliser en premier avant rédaction manuelle

### Interviews artisans — source de contenu prioritaire

Le mécanisme central d'Uluana est de convertir l'expérience réelle des artisans avancés en actions détaillées pour les pairs. Les interviews sont donc du contenu produit, pas une activité annexe :

- **Double usage de chaque interview** : (1) matière brute pour rédiger/valider des cartes du catalogue (méthode réellement appliquée par un artisan qui a des résultats), (2) témoignage édité pour Threads et les pages de vente — jamais publié brut, toujours reformaté éditorialement (cohérent avec la règle UGC déjà fixée)
- **Priorité aux artisans du niveau le plus avancé disponible** : ce sont eux qui alimentent les cartes des niveaux inférieurs, effet de levier direct sur la pertinence du catalogue
- **Transcription** : passer par Whisper (déjà exploré) pour ne pas perdre de temps en retranscription manuelle
- **Ne jamais laisser l'interview remplacer la preuve sociale chiffrée des cartes** — les deux coexistent, l'interview est narrative et humaine, la stat de carte reste calculée depuis les relevés réels

---

## 7. Système de vente — funnel prospect → client

Ordre imposé, chaque étape a une seule fonction, ne pas en fusionner deux :

| # | Étape | Fonction | Ce qu'il faut réellement construire |
|---|---|---|---|
| 1 | Landing page | Premier contact, présente l'offre | Déjà en place (système de pages existant) — juste alimenter le contenu par offre |
| 2 | Nurturing | Construire la confiance avant de vendre quoi que ce soit | Séquence de 2-3 messages entre le premier contact et le rdv — pas un nouvel outil, une séquence de contenu programmée (manuel au départ via les templates de prospection existants) |
| 3 | Scheduled (prise de rdv) | Convertir l'intérêt en engagement calendaire | Brancher un outil de réservation externe existant (type Calendly) — **ne pas développer d'outil maison**, ça n'a aucune valeur différenciante et coûte du temps de dev pour rien |
| 4 | VSL courte | Préqualifier avant l'appel — le prospect arrive déjà convaincu du concept | Contenu à produire (vidéo courte), pas de développement — hébergement simple, lien envoyé après la prise de rdv |
| 5 | Cadrage attentes | Éviter que le prix ou le format soit une surprise pendant l'appel | Se fait dans l'email de confirmation de rdv ou dans la VSL elle-même : offre, prix, déroulé annoncés avant l'appel, pas pendant |
| 6 | Appel | Qualifier, répondre aux objections, humaniser | Toi, en direct — aucun outil requis au-delà du calendrier |
| 7 | Closing | Signature + paiement | Déjà en place (Stripe) |

**Règle de fond** : un prospect qui arrive à l'étape 6 (l'appel) sans être passé par 2, 3 et 4 est un appel à froid déguisé en appel programmé — le funnel perd sa raison d'être si une étape est sautée pour aller plus vite. Mieux vaut moins d'appels mais tous préqualifiés.

**Aucun développement lourd requis pour ce funnel** — le seul point qui touche le code déjà construit : envisager, plus tard et pas maintenant, un champ "étape funnel" sur `prospect_contacts` ou `pilotage_hebdo` pour tracer où chaque prospect en est. Hors scope tant que le funnel n'a pas tourné manuellement au moins une fois.

---

## 8. Ce qui ne doit PAS être fait maintenant

Pour respecter la règle effort minimal / impact maximal, explicitement hors scope tant que les points 1 à 5 de la matrice ne sont pas livrés :

- Nouveaux templates de landing page personnelle
- Expansion géographique hors Pyrénées-Atlantiques
- Nouveau canal de communication en dehors de Threads
- Toute fonctionnalité communautaire ouverte (avis libres, messagerie non modérée)

---

*Document de travail — à faire évoluer au fil des décisions. Toute modification du barème de déblocage, des cadences de mesure ou des seuils de prix doit rester pilotable depuis `/control`, jamais figée dans le code.*