Liste des
Fonctionnalités
Groupées par logique produit — pas par écran ou par page. Chaque groupe existe pour une raison stratégique précise.
Features explicitement supprimées : Feed social type Instagram, likes/commentaires publics sur les tenues, intégration e-commerce push (bannières de marques), système de points/badges gamifiés. Ces features créent soit de la toxicité, soit une dérive de la proposition identitaire vers la performance sociale.
Fonctionnalités
MVP
Un MVP n'est pas un produit incomplet. C'est le produit le plus simple qui permet de tester si la proposition de valeur est réelle.
// critere_mvp : l'utilisateur doit être capable d'atteindre son aha moment ("cette app me comprend") en moins de 30 minutes d'usage total, avec moins de 15 items uploadés. Si ce critère n'est pas atteignable avec le scope MVP, le MVP est trop restreint.
Onboarding 5 questions
Produit de la valeur avant tout upload. Sans ça, l'utilisateur doit photographier 50 vêtements avant de voir quoi que ce soit. 70% partent avant d'atteindre ce seuil.
Photo + AI metadata
Fondation de tout le reste. Sans items, pas de profil, pas de suggestion. MVP simplifié : background removal automatique, métadonnées IA basiques (couleur dominante, type de vêtement). Pas besoin de tout cataloguer — 15 items suffisent pour le MVP.
Profil stylistique basique
C'est l'aha moment. La première fois que l'utilisateur voit son profil et pense "c'est étonnamment juste". MVP simplifié : palette couleurs + 2-3 insights sur les patterns. Pas le profil complet — juste assez pour créer la surprise.
2 tenues depuis la garde-robe
MVP version : pas de contexte météo ni agenda. Juste 2 combinaisons cohérentes depuis les items uploadés. L'objectif n'est pas la perfection — c'est de montrer que l'app peut générer quelque chose d'utile avec peu de données.
1-clic après choix tenue
Génère les données comportementales sans lesquelles le profil ne peut pas s'améliorer. MVP ultra-simplifié : bouton "J'ai porté ça aujourd'hui" avec date automatique. Pas de contexte, pas d'humeur — juste le log brut.
Email + Google + Apple
Nécessaire pour persister les données. Pas de friction : Sign in with Apple/Google en premier. L'email reste disponible mais n'est pas le flow par défaut.
Freemium gate après valeur
Même en MVP, le paywall doit être présent pour valider la willingness to pay. Déclenché uniquement après que l'utilisateur a vu son profil (pas avant). Gate sur "profil complet" et "suggestions illimitées".
Hors MVP délibérément : notifications push (trop tôt — pas de rythme établi), journal de style (peu de données en MVP), purchase check (nécessite un profil mature), B2B Pro (scope séparé), features sociales (construction communautaire après PMF). Ces absences sont des décisions, pas des oublis.
Fonctionnalités
V1
V1 ne signifie pas "tout ce qu'on voulait faire". Ça signifie : les features qui transforment un produit validé en produit habituel.
Avec météo + agenda + humeur
La version MVP a des suggestions basiques. La V1 les rend contextualisées — météo via API, contexte du jour déclaré en 3 secondes. C'est la différence entre "une appli de tenues" et "mon assistant personnel du matin". Crée l'habitude quotidienne et le trigger de rétention principal.
Heure configurable + contenu contextuel
Sans notification, la suggestion matinale n'est consultée que par les utilisateurs qui y pensent. La notification transforme un comportement actif en comportement passif — l'app vient chercher l'utilisateur. Heure configurable car un développeur et un boulanger ont des matins différents.
Photo ou URL → score profil
Feature différentielle la plus forte du marché. Nécessite un profil mature (minimum 30 items, 30 jours d'usage) pour que le score soit crédible — d'où l'absence en MVP. C'est la feature qui fait dire "je ne peux plus acheter sans vérifier dans BeYourself".
Archive visuelle chronologique
Après 2-3 semaines de logging, l'utilisateur a accumulé assez de données pour que le journal soit intéressant. En MVP il n'y a pas assez de données — ça aurait été vide et décevant. En V1, c'est la feature de rétention émotionnelle longue durée. Premier déclencheur de réengagement.
Progression visible avec explications
Le score existait en MVP mais comme donnée interne. En V1 il devient visible, avec une explication ("ton score a progressé parce que tes choix de couleurs sont plus cohérents cette semaine"). Motivation à continuer à logger, à rafiner le profil. Driver de conversion premium.
Vinted historique + Zalando orders
Réduit la friction d'onboarding pour les nouveaux utilisateurs qui arrivent après le MVP. Un utilisateur Vinted peut importer 30 items en 2 clics au lieu de les photographier un par un. Réduit le taux d'abandon onboarding de façon significative.
Gestion multi-clients
20 stylistes en beta fermée dès la V1. Revenue immédiat sans attendre l'échelle B2C. Canal d'acquisition B2C déguisé. Scope minimal : profil client partageable + notes de session. Le reste vient après.
"Il y a un an..."
Nécessite 1 an de données — impossible en MVP. En V1 (après 3+ mois), commence à fonctionner avec des "il y a 3 mois". Taux d'ouverture de notification le plus élevé du produit. Réengagement sans effort marketing.
Contrôle RGPD visible
Obligatoire pour le marché français. En V1 car en MVP le volume de données sensibles collectées est encore limité. Construit la confiance — directement lié à la willingness to share des données de qualité.
Fonctionnalités
Futures
Uniquement les features avec un impact business démontrable. Pas de features cool-sans-raison.
Rétrospective partageable
Acquisition organique à coût zéro. Millions d'impressions UGC potentielles si bien conçu. Condition : nécessite 1 an de données + volume suffisant d'utilisateurs pour que le partage ait un effet réseau.
Amis, partage, avis
Mécanique sociale non-compétitive. Risque principal : peut dériver vers la performance si mal designé. Construire seulement avec une politique communautaire claire et une équipe de modération. Condition : 50K+ utilisateurs actifs avec engagement prouvé.
Détox vestimentaire
"Analyser avant de vendre." Distribution massive via la base Vinted + intention parfaite. Condition : partenariat officiel ou scraping légal stable. Nécessite négociation avec Vinted — à initier à 100K users comme levier de négociation.
API données marques B2B
Le plus grand levier de revenu à long terme. Insights anonymisés sur les préférences réelles des consommateurs vendus aux marques. Condition stricte : minimum 500K profils actifs pour que la donnée soit statistiquement significative et vendable.
Remplace OpenAI Vision
Fine-tuning CLIP sur les données BeYourself → meilleure précision sur les vêtements spécifiques, coûts divisés par 5-10. Condition : viable seulement à partir de 200K+ items analysés (masse d'entraînement suffisante) et quand les coûts OpenAI justifient l'investissement.
Voyage, mariage, entretien
Préparer une valise ou une tenue pour un événement avec aide IA. Feature à haute valeur perçue, très partageable. Potentiel de feature virale ("j'ai préparé tout mon voyage avec BeYourself"). Condition : profil mature + journal V1 établi.
Spécifications
Détaillées
PRD complet des 7 fonctionnalités cœur. Format directement utilisable pour coder.
Produire un premier profil d'identité stylistique avant tout upload de vêtement. Créer la valeur immédiate qui justifie de continuer l'onboarding. C'est le premier moment de vérité du produit — si ce moment déçoit, l'utilisateur abandonne.
| Max questions | 5 strictement. Au-delà, le taux de complétion chute de 30% par question supplémentaire. |
| Input exclusivement visuel | Aucun champ texte libre. Uniquement des grilles d'images ou des options avec visuels. Réduit la friction cognitive. |
| Progression visible | Barre de progression "3/5". Ne jamais cacher à l'utilisateur où il en est. |
| Réponses partielles OK | Si l'utilisateur quitte à Q3, sauvegarder les réponses. Reprendre là où il s'est arrêté à la prochaine session. |
| Profil_v0 toujours généré | Même avec réponses partielles (minimum 3 questions), générer un profil partiel. Ne jamais laisser l'utilisateur sans résultat. |
| guest (non connecté) | Peut accéder au questionnaire. Le profil est généré mais non sauvegardé. Invitation à créer un compte après affichage du résultat. |
| user (connecté) | Profil sauvegardé dans Firestore. Peut refaire le questionnaire à tout moment depuis les settings. |
| pro (styliste) | Peut lancer le questionnaire au nom d'un client. Le résultat est enregistré dans le profil client. |
| API timeout | Si la génération du profil_v0 dépasse 3s, afficher un état "calcul en cours" avec animation. Jamais un écran blanc. |
| Réponses insuffisantes | Si < 3 questions répondues et abandon, ne pas générer de profil factice. Sauvegarder les réponses et proposer de reprendre. |
| Résultat trop générique | Si le profil_v0 ne peut pas différencier l'utilisateur (toutes les réponses moyennes), afficher quand même un résultat mais avec message "Tes 5 premières pièces nous permettront d'être beaucoup plus précis." |
questionnaire.startedquestionnaire.question_answeredquestionnaire.completedquestionnaire.profile_viewedLes réponses au questionnaire sont des données de profil sensibles. Stockées dans Firestore sous users/{uid}/questionnaire avec Security Rules limitant l'accès au uid propriétaire uniquement. Pas d'accès admin ou analytics direct — uniquement des agrégats anonymisés.
Technique : génération du profil_v0 en <2 secondes p95. UX : >70% de taux de complétion (Q5 atteint). Business : >60% des utilisateurs qui complètent le questionnaire uploadent au moins 1 item dans les 24h. Data : le profil_v0 est significativement différent entre les utilisateurs (variance suffisante pour montrer la personnalisation).
Transformer une photo de vêtement en donnée structurée analysable. C'est le point d'entrée de toute l'intelligence identitaire. La qualité et la rapidité de cette étape déterminent directement si l'utilisateur continue l'onboarding ou abandonne.
pending_analysis.| Taille max image | 10MB. Compression côté client avant upload si >2MB (flutter_image_compress). Réduire la consommation de données et les coûts Storage. |
| Formats acceptés | JPEG, PNG, HEIF (iPhone natif). WebP accepté mais converti en JPEG avant traitement. |
| Cache analyse | Hash SHA-256 de l'image → résultat d'analyse stocké. Si même image uploadée 2 fois (même utilisateur ou différent), réutiliser l'analyse existante. Économie majeure sur les coûts AI. |
| Limite free tier | 50 items maximum en version gratuite. Au-delà, gate premium. La limite est visible à 40 items pour inciter la conversion avant la frustration. |
| Minimum viable | Un item est considéré comme "analysé" même si l'IA n'a extrait que la couleur et le type. Les autres métadonnées peuvent être incomplètes sans bloquer. |
| Connexion perdue pendant upload | Reprendre l'upload depuis le dernier chunk. Ne jamais perdre la photo. Firebase Storage handles resumable uploads nativement. |
| OpenAI Vision timeout (>30s) | Marquer l'item comme analysis_failed. Afficher à l'utilisateur "Analyse en attente — on réessaie." Cloud Task retry automatique avec backoff exponentiel (3 tentatives max). |
| Image illisible | Si OpenAI Vision retourne une confiance <40%, demander à l'utilisateur de retaker la photo ou de saisir les informations manuellement. |
| Background removal échec | Continuer avec l'image originale. L'analyse IA fonctionne même sans background removal — c'est une amélioration, pas un prérequis. |
Item déjà présent : si le hash de l'image correspond à un item existant du même utilisateur, proposer de mettre à jour l'existant plutôt que créer un doublon. Photo de soi portant l'item : le système doit détecter et ignorer le corps humain pour analyser uniquement le vêtement. Item endommagé ou incomplet : pas de validation de "qualité de vêtement" — tout item uploadé est valide même s'il est abîmé. Tentative d'upload de contenu inapproprié : Firebase App Check + modération probabiliste côté AI (si l'image ne contient pas de vêtement, retourner une erreur claire).
item.upload_starteditem.analysis_completeditem.metadata_correcteditem.analysis_failedToutes les images sont stockées dans Firebase Storage sous users/{uid}/items/{itemId}. Security Rules : lecture et écriture uniquement par le propriétaire du uid. Pas d'URL publique par défaut — accès via signed URLs temporaires (expiration 1h) générés côté Cloud Function. Les signed URLs empêchent le hotlinking et le scraping de la galerie utilisateur.
Technique : analyse AI complétée en <15 secondes p95. Taux de succès >95%. UX : l'utilisateur voit la mise à jour de l'item sans avoir à recharger l'écran (Firestore realtime). Business : coût moyen <€0.15/item analysé (cible : optimisation à €0.05 avec cache à V1). Qualité IA : taux de correction manuelle <15% (valider que les métadonnées extraites sont suffisamment précises).
Créer l'habitude quotidienne. La suggestion matinale est le seul trigger qui peut transformer BeYourself d'une app qu'on ouvre "de temps en temps" en une app qu'on ouvre chaque matin. Sa qualité et sa fiabilité sont la métrique de rétention la plus critique du produit.
| Seuil minimum items | 15 items analysés pour générer une suggestion. En dessous, afficher un message d'encouragement à uploader plutôt qu'une mauvaise suggestion. |
| Pas de répétition | Une même tenue exacte ne peut pas être suggérée 2 fois dans la même semaine. Sauf si l'utilisateur l'a explicitement portée et loggée entre les deux. |
| Rotation des items | Chaque item doit apparaître en suggestion au moins 1 fois toutes les 3 semaines (si compatible avec le profil). Évite que certains items soient perpétuellement ignorés. |
| Météo obligatoire | Si l'API météo est indisponible, ne pas générer de suggestion sensible à la température. Générer une suggestion "météo-neutre". |
| Saisons vestimentaires | Les items sont filtrés par saison (détectée automatiquement depuis les métadonnées). Pas de pull proposé en juillet même s'il est dans la garde-robe. |
| Aucun item en stock pour la météo | Afficher les 2 items les plus appropriés disponibles avec message "Ton dressing ne couvre pas tous les temps — voici ce qui se rapproche le plus." |
| Calcul nocturne échoué | Fallback : calcul en temps réel au moment de l'ouverture. Latence acceptée jusqu'à 3 secondes avec indicator de chargement. |
| 3 refus consécutifs | Après 3 jours consécutifs de refus de toutes les suggestions, déclencher un mini-questionnaire de recalibration (2 questions). Le profil s'est peut-être déphasé. |
suggestion.generatedsuggestion.openedsuggestion.selectedsuggestion.all_rejectedsuggestion.outfit_loggedTechnique : suggestion disponible en <500ms après ouverture de l'app (pré-calculée). Taux d'échec calcul nocturne <1%. UX : taux d'ouverture de la notification push >35% (benchmark lifestyle apps). Business : taux de sélection d'une suggestion >55% parmi les utilisateurs actifs. Qualité : taux de refus total <25% à J30+ (le modèle apprend).
Construire et afficher en continu le profil d'identité visuelle de l'utilisateur. C'est le moat du produit — la donnée irréplicable qui crée le switching cost émotionnel. Plus précis avec le temps, jamais figé. Le Style Clarity Score est la gamification bienveillante qui motive le retour.
| Composante | Source de données | MVP ou V1 |
|---|---|---|
| style_temperament | Questionnaire onboarding. Mise à jour si questionnaire refait. | MVP |
| color_palette | Embeddings couleur des items × fréquences de port. Top 5 couleurs + patterns chromatiques. | MVP |
| silhouette_signature | Métadonnées silhouette des items portés (>2×). Détecte les coupes récurrentes. | MVP |
| context_personas | Analyse des outfits loggés par contexte déclaré. 3 "modes" : work/casual/occasion. | V1 |
| purchase_patterns | Ratio items achetés vs portés. Fréquence d'achat. Type d'impulsion. | V1 |
| style_vocabulary | Mots-clés générés par IA depuis les patterns détectés. "Tu portes du minimalisme structuré..." | V1 |
| style_clarity_score | Algorithme de cohérence : variance de la palette × fréquence de port × contexte-alignment. | MVP (interne) / V1 (visible) |
Le score (0-100) mesure la cohérence identitaire — pas la qualité du style. Formule simplifiée V1 :
score = (palette_coherence × 0.3) + (silhouette_consistency × 0.25) + (port_frequency_ratio × 0.25) + (context_alignment × 0.2)
Chaque composante est normalisée 0-100. Le score global ne monte pas si on "s'habille mieux" — il monte si on est plus cohérent avec qui on est. Un score de 45 stable vaut mieux qu'un score de 90 éphémère.
| Seuil de précision | Le profil n'est présenté comme "complet" qu'à partir de 20 items analysés et 14 jours d'usage. En dessous, afficher "Profil en construction" avec le % de progression. |
| Recalcul | Recalcul du score après chaque : nouvel item analysé (si +5 items depuis le dernier calcul), outfit loggé (batch toutes les 5 logs), questionnaire refait. |
| Non-jugement | Le profil ne contient jamais de langage normatif ("ton style pourrait être amélioré"). Il décrit uniquement — jamais ne prescrit. |
| Évolution historique | Le profil garde un historique des versions (snapshot mensuel). Permet de montrer "ton profil a changé depuis 3 mois". |
Qualité : le style_vocabulary généré doit être perçu comme "juste" par >70% des utilisateurs interrogés (validation qualitative nécessaire en beta). Différenciation : deux utilisateurs aux goûts différents doivent avoir des profils significativement différents. Progression : le score doit progresser de façon mesurable pour >60% des utilisateurs actifs entre J7 et J30.
Permettre à l'utilisateur de vérifier en quelques secondes si une pièce envisagée est cohérente avec son identité stylistique avant de l'acheter. C'est la feature la plus différentielle du marché — aucun concurrent ne fait ça. Elle s'appelle "check" et non "validation" : elle ne dit jamais non, elle éclaire.
| Profil minimum requis | Feature disponible uniquement si le profil a >30 items et >14 jours d'usage. En dessous, le score d'alignement n'est pas fiable et peut induire en erreur. |
| Score intentionnellement neutre | Un score de 35/100 n'est pas présenté comme "mauvais" — il est présenté comme "cette pièce est différente de ton style actuel — peut-être une exploration ?" |
| Limite gratuite | 3 checks/mois en version gratuite. Illimité en premium. La limitation doit être annoncée avant le 3ème check, pas après. |
| Pas de revente de données d'intention | Les items checkés mais non achetés sont des données hautement sensibles. Usage limité au profil personnel — jamais transmises à des marques ou des partenaires. |
Item identique déjà dans la garde-robe : détecter et afficher "Tu as déjà un item très similaire — veux-tu voir comment tu l'utilises ?" Item de luxe inaccessible : pas de filtre prix — le check s'applique à tout type de pièce. URL non-vêtement : si l'URL ne pointe pas vers un vêtement (erreur humaine), retourner une erreur claire avec invitation à utiliser la photo à la place.
purchase_check.initiatedpurchase_check.completedpurchase_check.purchasedpurchase_check.passedTechnique : score affiché en <5 secondes après soumission de l'image. Qualité : les utilisateurs qui utilisent le purchase check doivent percevoir le score comme "pertinent" à >65% (survey in-app post-utilisation). Business : la feature doit être citée comme driver de conversion premium par >20% des utilisateurs convertis. Impact : réduction mesurable des retours e-commerce parmi les utilisateurs actifs vs non-utilisateurs (KPI à suivre sur 3 mois).
Créer la rétention émotionnelle longue durée en transformant les logs de tenues en une archive identitaire consultable. L'utilisateur doit avoir l'impression que BeYourself se souvient de lui mieux qu'il ne se souvient lui-même. C'est la feature qui empêche de partir même en période de faible engagement.
| Composante | Description | Phase |
|---|---|---|
| timeline_view | Scroll chronologique des tenues loggées. Groupées par semaine. Photos des items, date, contexte. Infinite scroll vers l'arrière. | V1 |
| pattern_insights | Bulles d'insights periodiques dans la timeline : "Tu portes du bleu les lundis. C'est ça." Générés par IA, toujours descriptifs jamais prescriptifs. | V1 |
| memory_triggers | Notifications "Il y a X mois/an, tu portais ça à [contexte]". Déclenchées par Cloud Function quotidienne. | V1 |
| style_eras | Chapitres esthétiques marqués manuellement par l'utilisateur ("Mon été minimaliste") ou suggérés automatiquement par l'IA quand un shift de style est détecté. | V2 |
| wrapped_annuel | Rétrospective annuelle générée en décembre. Shareable card. Couleurs de l'année, top 5 pièces, évolution du score. | V2 |
| Seuil d'activation | Le journal est accessible dès le 1er log. Mais les insights ne sont générés qu'à partir de 14 logs (2 semaines d'usage quotidien hypothétique). |
| Memory trigger fréquence | Maximum 1 memory trigger par semaine par utilisateur. Jamais le lundi matin (trop de notifications ce jour-là). Préférence : mercredi ou jeudi, 9h-11h. |
| Privacy du journal | Le journal est strictement privé par défaut. Aucune donnée du journal ne peut être vue par d'autres utilisateurs, même en version Pro. L'opt-in social explicite est nécessaire pour tout partage. |
| Suppression d'un log | L'utilisateur peut supprimer n'importe quelle entrée du journal. La suppression n'impacte pas rétroactivement le profil calculé (pour éviter manipulation intentionnelle du score). |
Rétention : les utilisateurs qui ont 30+ logs dans le journal ont un taux de churn 3× inférieur à ceux qui n'en ont pas — si ce n'est pas le cas, la feature n'est pas assez engageante. Memory triggers : taux d'ouverture des memory triggers push >40%. Partage Wrapped : taux de partage du Wrapped >15% des utilisateurs actifs qui le reçoivent (benchmark Spotify Wrapped : 30%).
Convertir les utilisateurs activés en abonnés payants au moment précis de valeur maximale perçue. Le paywall ne doit jamais être vécu comme une frustration — il doit être vécu comme l'aboutissement logique d'un investissement déjà consenti.
| Trigger | Contexte | Message |
|---|---|---|
| Score >60% | L'utilisateur tente d'accéder au profil complet quand son score dépasse 60% | "Ton profil est complet à 82%. Débloque ta signature stylistique complète." |
| Limite 50 items | L'utilisateur veut uploader son 51ème item | "Tu as construit une vraie garde-robe intelligente. Continue sans limite." |
| 3 purchase checks | L'utilisateur a utilisé ses 3 checks gratuits du mois | "Protège chaque achat — checks illimités avec Premium." |
| Suggestion refusée 2 fois | L'utilisateur veut plus d'options que les 2 suggestions gratuites | "Plus de suggestions, plus précises — avec ton profil complet." |
| Pas de paywall avant J7 | Aucun paywall ne peut s'afficher dans les 7 premiers jours, quelle que soit l'utilisation. L'utilisateur doit avoir le temps d'établir une valeur perçue. |
| Freemium toujours fonctionnel | La version gratuite doit rester genuinement utile. Un utilisateur free ne doit pas se sentir dans une version dégradée — il doit se sentir dans une version incomplète mais fonctionnelle. |
| Pas de dark patterns | Aucune pré-sélection de l'abonnement annuel, aucun compte à rebours artificiel, aucune case pré-cochée. Le choix de l'utilisateur doit être libre et éclairé. |
| Annulation transparente | La gestion de l'abonnement (annulation incluse) est accessible en 3 clics max depuis les settings. Ne jamais cacher la procédure d'annulation. |
| Carte refusée | Message clair non-culpabilisant. 3 tentatives automatiques sur 7 jours (Stripe dunning). Email de notification avant chaque tentative. |
| Abonnement expiré | Accès premium maintenu 3 jours après expiration pour éviter la friction d'un lundi sans suggestion. Notification jour 1, 2, 3 avec CTA renouvellement. |
| Remboursement | Traité via Stripe. Politique : remboursement intégral dans les 14 jours si demandé (droit de rétractation EU). Automatisé — pas de friction manuelle. |
Le statut premium est stocké comme custom claim sur le Firebase Auth token — vérifié côté Cloud Function à chaque requête sensible. Il ne peut pas être modifié côté client. Les custom claims sont mis à jour par les Stripe webhooks via une Cloud Function dédiée. Résistant à la manipulation client-side.
Conversion : taux de conversion freemium → premium >12% à J30 (cible à terme : 18%). Timing : le paywall ne doit pas s'afficher avant que l'utilisateur ait vécu au moins 1 "aha moment" identifiable dans les logs (suggestion acceptée ou profil consulté >2 fois). Perception : survey post-paywall — "Avez-vous senti que la valeur justifiait le prix ?" doit être >70% positif. Churn : taux de churn mensuel premium <5%.