Phases
Projet
5 phases. Chacune a un objectif précis, des livrables concrets, et une gate de validation. Passer à la phase suivante sans franchir la gate est la définition de la dette stratégique.
Design system Figma complet (tokens, composants cœur, guidelines). Schéma Firestore documenté + Security Rules rédigées et testées sur l'émulateur. Projet Flutter bootstrappé avec architecture (navigation, state management, design tokens). Abstraction AIProvider implémentée. Pipeline CI/CD Codemagic opérationnel.
Construire la fondation technique et design avant d'écrire la première ligne de code produit. Chaque raccourci pris ici coûte 3× plus cher à corriger à M6.
C'est aussi la phase de recrutement des 20 beta users stylistes — commencer maintenant, pas quand le produit est prêt.
S1-2 : Auth (Apple + Google) + questionnaire 5 questions + profil_v0
S3-4 : Upload photo + background removal + AI analysis pipeline + wardrobe grid
S5-6 : Moteur de suggestion rule-based (2 combos) + outfit logging 1-tap
S7-8 : Profil display + basic paywall + polish (états vides, erreurs, loading)
S9-10 : QA + fixes + App Store submission
Construire le produit le plus simple qui peut tester l'hypothèse centrale : "les utilisateurs trouvent suffisamment de valeur dans le miroir stylistique pour uploader leur garde-robe."
Tout ce qui n'est pas dans la liste de livrables ci-dessus est hors scope. Sans exception. Les discussions "on pourrait aussi faire X" sont des discussions pour la Phase 3.
TestFlight (iOS) + APK interne (Android) distribués à 50-100 beta users recrutés manuellement. User interviews (au moins 15) pour comprendre le rapport à l'aha moment. Fixes critiques basés sur les feedbacks. Données D7 retention sur les premières cohortes.
Un signal qualitatif fort : est-ce que quelqu'un dit "c'est étonnamment précis sur moi" sans qu'on lui pose la question ? Ce signal qualitatif est plus important que toute métrique à ce stade.
Si ce signal n'existe pas après 100 beta users, ce n'est pas un problème de marketing — c'est un problème de proposition de valeur. Il faut itérer le MVP avant de lancer publiquement.
App disponible sur App Store et Google Play. Compte TikTok fondateur actif (3-4 vidéos/semaine). Blog SEO premiers articles publiés. Analytics PostHog configuré. Support Intercom en place. Premier Rapport health hebdomadaire envoyé.
Objectif à la fin de cette phase : 500 utilisateurs activés, D7 retention confirmée >25%.
Si après 500 utilisateurs la rétention D7 est structurellement inférieure à 18%, arrêter l'acquisition et passer 4 semaines d'itération intensive avant de relancer. Un mauvais produit amplifié par l'acquisition brûle le capital et la réputation simultanément.
Morning suggestion avec météo + push notification contextualisé. Style Clarity Score visible + expliqué. Purchase Alignment Check. Style Journal (timeline basique). Memory triggers. B2B Pro beta (20 stylistes). Bulk import Vinted. Privacy Dashboard complet.
Transformer un produit validé en produit habituel. Les features V1 ont un seul objectif : créer l'habitude quotidienne et la rétention émotionnelle longue durée. Toute feature qui n'adresse pas directement la rétention ou l'activation est différée.
Sprint
Planning
Un sprint n'est pas une liste de tâches. C'est un engagement collectif sur ce qui sera livrable et démo-able vendredi.
PM présente le top 5 des features à construire (toutes avec PRD complet). Dev Lead estime en points (1/2/3/5). Designer confirme les designs prêts. Capacité sprint : 20 points/dev × 2 devs. Si une feature n'a pas de PRD → elle n'entre pas dans le sprint.
Sync obligatoireThread Slack quotidien avant 10h : 1) Hier, 2) Aujourd'hui, 3) Bloquants. Dev + design en parallèle (designer finalise les features du sprint suivant pendant que dev build le sprint actuel). Si bloquant non résolu en 24h → escalade au PM.
Async · Slack DevRapide : avance réelle vs prévision. Si > 20% de retard → couper une feature du sprint (jamais dépasser la date). Ce meeting n'est pas une réunion de problèmes — c'est une vérification de capacité.
Sync · 30minMercredi : features freeze — plus de nouvelles choses, uniquement polish et fixes. Jeudi : build staging + smoke test des 5 journeys critiques sur 3 devices. PR Review obligatoire avant tout merge.
QA · Smoke testDemo : chaque dev montre ce qui tourne — pas de slides, pas de Figma, du produit réel. Si rien ne tourne, le sprint a dysfonctionné. Rétro : 2 questions — qu'est-ce qu'on a appris ? qu'est-ce qu'on change dans notre façon de travailler ?
Sync · 1hRègle du PRD obligatoire : toute feature dans un sprint doit avoir un PRD documenté (objectif, user flow, règles métier) avant le sprint planning. Les features "de dernière minute" ou "ça prend 2 heures" sans spec sont statistiquement les plus coûteuses sur le long terme.
Règle de l'hypothèse : avant d'ajouter une feature au backlog, le PM doit écrire la phrase "cette feature existe parce que nous croyons que [comportement utilisateur]. Nous saurons qu'elle fonctionne si [métrique] s'améliore de [X%] en [Y jours]." Si cette phrase ne peut pas être écrite, la feature n'entre pas dans le backlog.
Priorités
Ce qui est dans la liste "avoid early" n'est pas une mauvaise idée. C'est une bonne idée au mauvais moment — ce qui est parfois plus dangereux.
- Questionnaire 5 questions + profil_v0
- Upload photo + AI analysis (OpenAI Vision)
- Wardrobe grid (30 items max free)
- Suggestion 2 combos rule-based
- Outfit logging 1-tap
- Auth Apple + Google
- Paywall basique (willingness test)
- 5 journeys testés sur 3 devices
- RGPD minimum légal (Privacy Policy + export)
- Morning suggestion météo + push notification
- Style Clarity Score visible
- Purchase Alignment Check
- Style Journal timeline basique
- Memory triggers (3+ mois)
- B2B Pro beta (20 stylistes)
- Bulk import Vinted / commandes
- iOS widget écran d'accueil
- Privacy Dashboard complet
- Features sociales (co-styling, feed)attirer les Performeurs Sociaux dérive la communauté
- Style Wrapped annuelnécessite 12 mois de données utilisateur
- ML custom model200K items d'entraînement minimum requis
- Multi-région Firebasecomplexité sans utilisateurs hors UE
- Dark mode completinvestissement UI sans impact PMF
- Data API marques B2B500K profils nécessaires pour valeur réelle
- Marketplace shoppingconfiance non établie avant M18 minimum
Dépendances
Une dépendance non anticipée à J-30 peut décaler le lancement de 2 mois. Ces dépendances doivent être gérées avant même d'écrire la première ligne de code.
| Dépendance | Délai réel | Gravité si absent | Action requise |
|---|---|---|---|
| Flutter Dev Senior | 3-6 mois recrutement | Bloquant total | Initier le recrutement au moins 12 semaines avant le début du projet. Prévoir des freelances Dart senior comme backup. Ne jamais attendre d'avoir le budget confirmé pour démarrer le recrutement. |
| Apple Developer Account + DUNS | 2-4 semaines | Distribution iOS impossible | Créer le compte Apple Developer immédiatement. Demander le D-U-N-S number (si entité juridique) dès la création de la société. Ce processus prend 2-3 semaines et est souvent oublié. |
| Entité légale + compte Stripe | 2-6 semaines | Pas de paiement possible | Créer la structure légale (SAS recommandée en France) avant de commencer le développement. Stripe exige une entité légale pour accepter des paiements. Sans ça, le paywall est non-fonctionnel. |
| OpenAI API key + billing + DPA | 24-72h pour accès · 1-2 semaines pour DPA | AI pipeline cassé | Créer le compte OpenAI dès que l'entité légale existe. Signer le Data Processing Agreement avec OpenAI (nécessaire pour RGPD). Sauvegarder la clé API de façon sécurisée — jamais dans le code source. |
| Design System Figma complet | 3-4 semaines de design | Dev frontend bloqué | Aucun développeur frontend ne doit commencer avant que le design system soit complet dans Figma. Chaque composant manquant en cours de sprint = 0.5 jour perdu en coordination design-dev. |
| 20 beta users stylistes recrutés | 6-8 semaines de recrutement | B2B Pro sans utilisateurs au lancement | Commencer le recrutement en Phase 0, pas en Phase 2. LinkedIn, Instagram pro, associations de styling. Ces 20 personnes doivent être identifiées et engagées avant que le produit soit construit. |
| Firebase project configuré | 1-2 jours | Backend bloqué | Créer le projet Firebase sur GCP avec la région europe-west1 (RGPD). Configurer la facturation, les budgets d'alerte, et les quotas. Activer Firebase App Check dès la création. |
| Solution RGPD documentée | 2-4 semaines avec cabinet spécialisé | Risque légal au lancement | Engager un cabinet RGPD spécialisé dès le début de la Phase 0. Privacy Policy, CGU, DPA avec tous les sous-traitants (OpenAI, Firebase, Stripe), et mécanisme de consentement pour les données émotionnelles. |
Jalons
Chaque jalon est une question à laquelle le marché répond — pas une étape qu'on coche. Si le marché répond "non", ajuster avant de continuer.
3 utilisateurs beta qui disent spontanément "c'est étonnamment précis" ou "c'est la première fois qu'un produit me comprend vraiment" sans être sollicités. Ce signal est subjectif — mais sa présence ou son absence est le signal PMF le plus honnête qui existe à ce stade.
200 utilisateurs activés sur la première semaine post-lancement App Store. D7 retention > 25% sur la première cohorte publique. Premier Rapport Health hebdomadaire envoyé à l'équipe avec métriques réelles. Au moins un utilisateur qui ouvre l'app 7 jours de suite sans être notifié.
50 abonnés premium payants (€8.99). 5 stylistes Pro en beta payante (€49). MRR > €1,000. Ce jalon ne valide pas le business — il valide que des humains réels sortent leur carte bancaire pour BeYourself. C'est fondamentalement différent de la traction gratuite.
D30 retention > 25% sur 3 cohortes consécutives. DAU/MAU > 30%. Churn mensuel < 7%. C'est le jalon le plus important du produit — il confirme que l'habitude s'est formée et que les utilisateurs considèrent BeYourself comme irremplaçable. Ce signal déverrouille la construction de la V1.
2 000 abonnés premium payants. K-factor > 0.25 (chaque utilisateur amène en moyenne 0.25 nouveaux utilisateurs). MRR > €20K. CAC blended < €40. Ces métriques ensemble prouvent que le produit peut croître sans dépendre de publicité payante — c'est le signal de santé long-terme d'un business SaaS consumer.
Planning
30/60/90 jours
Post-lancement App Store uniquement. Les 90 premiers jours définissent si le produit mérite d'être scalé ou s'il nécessite une itération majeure.
Valider que le funnel d'onboarding fonctionne à scale réel. Pas de nouvelles features.
500 installs. 200 activés (40% activation). D7 premier signal (>22%). 10 abonnés premium.
Monitoring quotidien du crash rate, SAR, AI latency. Fix immédiat de tout bug bloquant. 10 user interviews avec utilisateurs qui ont churné en D3.
Confirmer le signal D7 et lire le premier D14. Activer les premiers leviers de rétention.
1 200 installs cumulés. D7 >25% confirmé. 50 abonnés premium. Push notification opt-in >45%.
Notifications push matinales (contextualisées). Style Clarity Score visible. Fix de tous les bugs signalés dans les premières 4 semaines.
Lire le premier D30. Prendre la décision : build V1 en accéléré ou itération MVP nécessaire.
2 500 installs cumulés. D30 première lecture. 150 abonnés premium. MRR >€2,000.
Si D30 >25% ET SAR >45% ET MRR >€2K → déclencher la V1. Si deux de ces trois signaux sont négatifs → 6 semaines d'itération intensive MVP avant toute décision de scale.
Go-to-Market
Un lancement "sur l'App Store" n'est pas un lancement. Un lancement, c'est les 50 premières personnes qui utilisent le produit de façon intensive et en parlent autour d'elles.
Pas App Store — TestFlight + invitations manuelles. Cibler : 15 stylistes ou coaches en image, 20 femmes/hommes en transition professionnelle ou personnelle, 15 personnes du réseau personnel qui "se plaignent de ne jamais savoir quoi porter". Chaque recrutement est une conversation — pas un email de masse. Ces 50 personnes construisent la culture du produit.
Le fondateur (ou co-fondateur) crée un compte TikTok racontant la construction de BeYourself. Format : "J'essaie de créer l'app qui analyse ton identité stylistique depuis ta garde-robe — voici ce que j'ai appris sur les vêtements et la psychologie cette semaine." Pas de pub — du contenu authentique. 3-4 vidéos/semaine. Objectif : 500-1 000 abonnés avant le lancement officiel.
Publier 3 articles de fond sur le blog avant même que l'app soit lancée : "Pourquoi vous achetez des vêtements que vous ne portez jamais", "Ce que votre garde-robe dit vraiment de vous", "Comment construire un style qui vous ressemble sans acheter plus". Ces articles créent les premiers liens entrants et capturent les utilisateurs en recherche active du problème que BeYourself résout.
La submission App Store arrive quand 200 beta users ont déjà utilisé le produit et que le crash rate est sous 0.3%. Les premiers reviews App Store viennent de ces beta users. Un produit lancé avec 15 avis 5 étoiles existants convertit 2× mieux qu'un produit lancé à 0 avis. Ne jamais lancer à 0.
Identifier un créateur TikTok à 20-50K abonnés dans le domaine "développement personnel" ou "identité / être soi-même" (pas mode). Lui proposer un accès gratuit premium + €200-500 pour une vidéo authentique sur sa découverte de BeYourself. Pas de script — une vraie découverte filmée. Ce type de contenu génère 5× plus de conversions qu'une publicité produite.
Participation genuine sur r/femalefashionadvice, r/capsulewardrobe, r/minimalism. Pas de promotion directe — des réponses de fond à des questions sur "comment trouver son style". Le fondateur comme expert bienveillant. BeYourself peut être mentionné quand c'est la réponse naturelle à une question. La crédibilité Reddit prend 4-6 semaines à construire — commencer tôt.
Checklist
Lancement
Rien ne peut être lancé si un élément critique est manquant. Cette liste est la gate finale avant soumission App Store.
- 5 journeys critiques QA passent sur iPhone SE + iPhone 15 + Samsung A53sans ça, l'app ne peut pas être soumise
- Crash rate < 0.5% sur 100+ sessions TestFlightun lancement > 1% crash = désinstallation massive
- Tous les error states gérés (aucun écran blanc vide)un écran blanc = impression de produit mort
- Paywall fonctionnel avec Stripe (mode live, pas sandbox)sans paiement live, pas de revenue day 1
- Privacy Policy + CGU liées dans l'app ET sur l'App StoreApple rejette sans ça
- Firebase Analytics configuré + tous les events critiques loggéssans events, les décisions J30 seront aveugles
- PostHog installé + funnels onboarding configurés
- Sentry error tracking actif + alertes configurées
- GCP Budget Alerts à 120% et 200% du plan mensuel
- Dashboard PostHog : funnel onboarding + D7 retention visible
- Firebase Security Rules testées avec emulator (cross-user access impossible)faille de sécurité critique si absent
- Firebase App Check activé (iOS DeviceCheck + Android Play Integrity)sans ça, abus du pipeline AI possible
- Rate limiting sur l'endpoint upload (max 10/heure/compte)
- Cloud Function error monitoring actif
- Runbook incidents production rédigé (3 scénarios minimums)
- Intercom installé + email support configuré et surveillépremier utilisateur frustré sans réponse = désinstallation
- FAQ avec les 10 questions les plus attendues
- Séquence email onboarding D0/D2/D5 configurée dans Brevo
- Template réponse App Store Review (reviews positifs et négatifs)
- 200 beta users notifiés du lancement public (premiers reviews)
- Screenshots iOS optimisés (pas de mockup — produit réel)les screenshots sont le premier test de conversion
- Description App Store sans le mot "mode" dans les 3 premières lignes
- Keywords ASO optimisés : "style identité", "garde-robe", "connaissance de soi"
- Review Notes expliquant chaque data point collecté (évite le rejet)
- Compte Google Play configuré en parallèle (release simultanée)
- 3 articles SEO publiés sur le blog
- Compte TikTok fondateur avec 5+ vidéos publiées avant le lancement
- Thread Reddit de lancement préparé (3-4 subreddits pertinents)
- Email de lancement prêt pour les 200 beta users
- URL de téléchargement avec UTM tracking par canal
// regle_absolue : aucun élément marqué "critique / bloquant" ne peut être absent au moment de la soumission App Store. La checklist est vérifiée par le PM ET le Tech Lead. La soumission ne se fait jamais le vendredi. Le délai de review iOS de 3-7 jours doit être intégré dans la date de lancement planifiée — ce n'est pas un retard, c'est une contrainte connue.