Risques
Techniques
Les bugs qu'on anticipe ne font jamais autant de dégâts que ceux qu'on n'a pas vus venir. Ces risques sont identifiés précisément parce qu'ils sont évitables.
Toute la proposition de valeur (analyse de vêtements, profil identitaire) repose sur cette API. Une interruption de service de 12h = 12h où aucun nouvel item ne peut être analysé = 12h d'onboarding cassé. Une hausse de tarifs non-anticipée peut rendre le modèle économique non-viable du jour au lendemain.
Ce risque est particulièrement dangereux car il survient précisément au moment où le produit prend de la valeur — et donc où les coûts deviennent significatifs.
Ce n'est pas la lecture du dressing seule. C'est l'accumulation : le dressing, les suggestions, le profil, le journal, les logs — toutes ces collections sont lues à chaque session sans pagination ni cache côté client. Chaque développeur qui ajoute un listener Firestore "pour la simplicité" ajoute des coûts qui s'accumulent de façon invisible jusqu'à ce que la facture GCP surprenne tout le monde.
Ce n'est pas un bug — c'est une limitation fondamentale de tout système de recommandation basé sur des données. La qualité de la suggestion est proportionnelle à la richesse du profil. Un profil avec 8 items ne peut pas produire une suggestion aussi précise qu'un profil avec 50 items. Ce risque affecte 100% des nouveaux utilisateurs et s'atténue seulement avec le temps d'usage.
La réponse UX (questionnaire, profil_v0, gamification upload) atténue ce risque mais ne l'élimine pas.
La routine matinale est le mécanisme de rétention principal. Trois matins consécutifs avec une suggestion lente ou absente brisent l'habitude de façon permanente. Ce n'est pas récupérable par un email de réengagement. La vitesse de la suggestion matinale est une promesse — toute violation de cette promesse est une rupture de confiance.
BeYourself détient des données très intimes (garde-robe, humeurs, patterns comportementaux). Une fuite, même brève, détruirait la confiance de façon irrémédiable dans un marché français très sensible à la vie privée. La presse tech n'aurait besoin que d'un titre pour désactiver des mois d'acquisition.
Risques
Business
Certains risques n'apparaissent qu'après 6-9 mois de croissance, quand le momentum initial masque des problèmes structurels.
Un produit avec 8K MAU actifs ressemble à un succès. Les fondateurs sont occupés à améliorer les features, l'acquisition progresse, la communauté se forme. Le fait que la conversion soit à 6.5% au lieu de 14% peut rester invisible pendant des mois si la métrique n'est pas mise en avant. Ce délai rend la correction plus douloureuse — changer la structure freemium avec des utilisateurs existants crée des frictions de confiance.
Apple a déjà rejeté des apps pour collecte de données "excessives" et modifié ses directives sur les apps financières, médicales et sociales. Une app qui collecte des données émotionnelles quotidiennes ET fait de la recommandation algorithmique est dans un territoire que les reviewers Apple pourraient questionner. La mitigation (PWA web parallèle) doit être construite avant que ce scénario se produise.
Si la rétention D30 est structurellement inférieure à 20%, il ne s'agit pas d'un problème d'UX à corriger — c'est un signal que la proposition de valeur elle-même n'est pas suffisamment forte pour justifier l'effort de cataloguer sa garde-robe. Cette situation nécessite un pivot du produit core, pas une optimisation d'onboarding. La reconnaissance rapide de ce signal est ce qui différencie les équipes qui survivent de celles qui dépensent 12 mois supplémentaires sur un produit qui ne fonctionnera pas.
Whering est fondamentalement un produit de durabilité. Leur communauté et leur branding sont construits sur "achetez moins". Un pivot vers l'identité psychologique créerait une dissonance de marque. La profondeur de l'engagement identitaire de BeYourself (journal, mémoire, profil émotionnel) est difficile à construire avec une base d'utilisateurs "eco-conscious" qui n'ont pas consenti à partager leurs émotions quotidiennes.
Risques
Légaux
BeYourself collecte des données parmi les plus sensibles qui existent : émotions quotidiennes, patterns comportementaux, identité. Le régime légal applicable est plus strict que pour une app de shopping ordinaire.
| Enjeu légal | Exposition | Ce que ça implique concrètement |
|---|---|---|
| Article 22 — Décision automatisée | Élevée | BeYourself fait de la recommandation algorithmique (suggestions de tenues) basée sur un profil comportemental + émotionnel. C'est une décision automatisée au sens RGPD. L'utilisateur a le droit de s'y opposer et d'obtenir une explication. Cela doit être dans les CGU et dans le Privacy Dashboard — explicitement, pas noyé dans du legalese. |
| Données émotionnelles | Élevée | Les données d'humeur (humeur du matin, contexte émotionnel) peuvent être qualifiées de données sensibles selon l'interprétation de certaines DPAs. Si classifiées comme telles, elles nécessitent un consentement explicite séparé — pas inclus dans les CGU générales. |
| Profilage comportemental | Moyenne-haute | La création d'un "profil d'identité" à partir de données comportementales est du profilage au sens RGPD. Must have : Privacy Policy qui explique précisément comment le profil est construit, droits d'effacement granulaires, et notification en cas de modification majeure de l'algorithme. |
| Transfert de données hors EU | Moyenne | Firebase/GCP avec la région europe-west1 est correctement localisé. OpenAI Vision : les images envoyées pour analyse passent par les serveurs OpenAI (US). Documenter le DPA avec OpenAI et inclure les clauses standard contractuelles (SCCs) dans la politique de confidentialité. |
| Droit à la portabilité (Article 20) | Moyenne | Les utilisateurs ont le droit de récupérer toutes leurs données dans un format lisible. La feature "Export données" (JSON/CSV) du chapitre 5 n'est pas un nice-to-have — c'est une obligation légale. Ne pas l'implémenter est une violation passive du RGPD. |
Recommandation critique : nommer un DPO (Data Protection Officer) ou engager un cabinet spécialisé RGPD dès le MVP. Le coût d'un audit RGPD préventif (€2-5K) est inférieur au coût d'une mise en conformité forcée après un incident (€20-100K minimum, sans compter les dommages réputationnels). La CNIL a considérablement augmenté ses investigations sur les apps mobiles depuis 2023.
Risques
Sécurité
BeYourself n'est pas une cible de premier plan pour les hackers — mais sa donnée est suffisamment sensible pour que les risques de sécurité méritent une attention sérieuse.
Firebase App Check (vérifie que les appels viennent de l'app légitime), rate-limiting sur l'endpoint d'upload (max 10 uploads/heure/compte), limite de comptes créés depuis la même IP/device en 24h, monitoring d'alerte sur la dépense GCP (si facture journalière > 2× la moyenne → alerte immédiate). Ces protections ne sont pas des options — elles sont des obligations dès J1.
Le Style Clarity Score est aussi utilisé comme donnée interne pour améliorer le moteur de suggestion. Si 5-10% des profils sont manipulés, la qualité de l'entraînement du modèle se dégrade. Ce n'est pas un risque de sécurité classique — c'est une corruption silencieuse de la valeur produit.
Firebase App Check couvre partiellement. Mais les profils publics (opt-in) sont par définition accessibles. La vraie protection est architecturale : ne jamais exposer les embeddings bruts ou les données comportementales via l'API — uniquement les représentations UX (palette couleurs, vocabulary) qui ont moins de valeur sans le contexte algorithmique.
Risques
Scalabilité
Chaque palier de croissance révèle des problèmes différents. Ce qui est imperceptible à 10K users peut être fatal à 100K.
Firebase coûts gérables (~€300-600/mois). OpenAI 50K items/mois = ~€4K.
Le moteur de suggestion rule-based tient. SAR autour de 55-60%. Premium features correctement limitées.
Équipe de 6 personnes couvre le produit. Support géré par le fondateur + Intercom.
Firebase sans optimisation : €8-15K/mois. OpenAI sans cache : €20-50K/mois.
Le moteur rule-based atteint son plafond de qualité (SAR ~62%). Les utilisateurs avancés notent la répétitivité des suggestions.
Support : 50-100 tickets/jour. Communauté naissante difficile à modérer sans rôle dédié.
Infrastructure Firebase nécessite refactoring majeur. Ou migration partielle vers PostgreSQL pour les requêtes analytiques complexes.
Le modèle ML custom est indispensable — sans lui, l'investissement de l'utilisateur (données) ne se traduit plus en amélioration visible de la valeur.
Équipe complète requise (18-22 personnes). Communauté nécessite modération 24/7. Support : 200-500 tickets/jour.
Contraintes
Techniques
Certaines contraintes sont des facts of life du développement mobile. Les ignorer crée des retards douloureux. Les anticiper les transforme en contraintes planifiées.
| Contrainte | Impact | Gestion |
|---|---|---|
| iOS App Store Review (3-7 jours) | Bloquant si non-planifié | Chaque release iOS mobilise 1 semaine de marge minimale. Ne jamais planifier une release critique un vendredi. Ne jamais promettre une date de feature publique sans buffer App Store. Le délai peut atteindre 14 jours lors des périodes de forte activité (WWDC, nouvelles sorties iOS). |
| Limite 1MB document Firestore | Architectural dès M4 | Un utilisateur avec 200 items dont chacun contient des métadonnées AI, des URLs de photos, et des logs — peut dépasser la limite si les données ne sont pas correctement distribuées entre collections. Cette contrainte doit guider le schéma dès le J1, pas lors de la première erreur en production. |
| FCM Android — restrictions constructeurs | Rétention silencieusement impactée | Samsung, Xiaomi, Huawei et OPPO ont des mécanismes aggressifs d'optimisation de la batterie qui tuent les processus background et les notifications push. 15-25% des utilisateurs Android sur ces appareils ne recevront pas les notifications matinales de façon fiable. La seule mitigation : widget home screen + documentation utilisateur sur les paramètres à activer. |
| Flutter packages instables | Retards de développement | Certains packages Dart/Flutter critiques (partage de fichiers, accès caméra avancé, background processing) ont une qualité inégale selon la plateforme. Toujours évaluer un package sur iOS ET Android avant de l'intégrer. Un package qui "fonctionne sur iOS" mais a des issues ouvertes non-résolues sur Android depuis 8 mois est un risque de retard de plusieurs semaines. |
| OpenAI Vision — pas de batch natif efficace | Coûts et latence | L'API OpenAI Vision n'est pas conçue pour le traitement en batch d'images similaires à coût réduit. Chaque image est facturée individuellement. La mise en cache SHA256 est la mitigation principale. À 200K items/mois, l'absence de cache = €16K/mois. Avec cache à 60% = €6.4K/mois. L'implémentation du cache n'est pas optionnelle dès la V1. |
Multi-région Firebase : déployer en europe-west1 uniquement en MVP/V1. Le multi-région (pour réduire la latence mondiale) est un problème à régler quand BeYourself a des utilisateurs au Japon ou en Australie — soit en V3 minimum. Chaque région Firebase supplémentaire multiplie la complexité des Security Rules et les coûts.
Microservices : une architecture microservices pour une équipe de 4-6 développeurs est une dette organisationnelle catastrophique. Les Cloud Functions de Firebase sont des nano-services suffisants. Ne pas migrer vers une architecture distribuée avant 500K users et une équipe de 10+ ingénieurs.
ML custom en V1 : le fine-tuning d'un modèle de vision custom est un projet de 6-9 mois qui nécessite des données d'entraînement, une infrastructure MLOps, et un ML engineer dédié. En V1, OpenAI Vision + rules-based suggestion est le bon compromis. Construire le ML custom avant d'avoir validé le produit est la forme la plus coûteuse de sur-ingénierie.
Contraintes
Budget
La startup qui manque de cash ne le voit jamais venir. Les coûts variables de BeYourself ont des comportements non-linéaires qui surprennent les équipes non-averties.
La règle des 3 seuils : surveiller activement le coût AI par item à 5K users (premier signal d'optimisation nécessaire), le coût Firebase par user actif par jour à 20K users (doit rester sous €0.05), et le CAC blended à 50K users (doit rester sous €40 pour maintenir LTV/CAC > 4:1). Ces trois métriques sont les signaux d'alerte précoce les plus importants de la santé économique du produit.
Plans de
Mitigation
Un plan de mitigation sans propriétaire, sans trigger de déclenchement, et sans plan de fallback n'est pas un plan. C'est une intention.
Implémenter l'abstraction AIProvider dès J1. L'interface accepte n'importe quel modèle de vision derrière elle. Tests de Gemini Vision Flash mensuels pour maintenir une alternative activable en 4h. Cache SHA256 dès V1 pour réduire la dépendance au volume d'appels.
Alerte GCP si coût AI journalier > 150% de la moyenne des 7 derniers jours. Dashboard de suivi du coût/item en temps réel. Monitoring du taux d'erreur OpenAI API — si > 5% sur 30 minutes → alerte immédiate sur Slack.
Si hausse de tarif : activation du fallback Gemini Vision dans les 4 heures via AIProvider.switchTo(GeminiVision). Si interruption : mode dégradé — items uploadés avec métadonnées manuelles uniquement, analyse AI reportée en queue. Pas de blocage de l'upload.
À 200K items analysés : démarrer le fine-tuning d'un modèle custom sur les données BeYourself. À 500K items : le modèle custom remplace OpenAI pour 80% des analyses. Ce n'est plus une dépendance externe — c'est un actif propriétaire.
Dénormaliser dès le schéma initial : les données fréquemment lues ensemble sont stockées ensemble. Implementer Firestore offline cache côté Flutter. Pagination obligatoire sur toutes les collections. Interdire les listeners sur des collections entières — uniquement sur des documents spécifiques.
Cost Allocation Labels sur GCP pour attribuer chaque coût à une feature. Budget Alert à 120% du plan mensuel. Dashboard "coût par user actif par jour" — si > €0.07 → investigation immédiate.
Si coût explose : identifier les listeners mal fermés via Cloud Monitoring (chercher les collections avec lecture > 1M/heure). Activer Cloud Memorystore Redis pour les données les plus lues (profil actuel, liste d'items, dernières suggestions).
À 200K users : évaluer la migration partielle vers Cloud SQL pour les requêtes analytiques complexes (Profile Engine). Firestore reste pour les données temps réel et les updates. Hybrid architecture — pas de migration totale.
Documenter tous les points de collecte de données dans les App Store Review Notes à chaque soumission. Se conformer aux App Store Guidelines section 5.1 (Privacy) avant la première soumission. Ne pas mentionner "emotional data" dans les screenshots ou descriptions — utiliser "style preferences" et "outfit history".
Suivre activement les App Store Review Guidelines updates (Apple publie régulièrement). Maintenir une veille des rejections publiques d'apps similaires sur les forums développeurs Apple.
App rejected : utiliser le canal "Appeal" Apple dans les 24h avec documentation complète de la conformité. Expedited review request pour les bugs critiques. Plan de réponse pré-rédigé pour les 3 motifs de rejet les plus probables.
PWA (Progressive Web App) web parallèle développée dès la V1 et maintenue à parité de fonctionnalités avec l'app native. En cas de rejet App Store prolongé, les utilisateurs basculent vers la PWA sans perte d'accès à leurs données.
Définir avant le lancement MVP les critères précis de succès et d'échec du MVP (D7 > 25%, SAR > 40%) et les décisions qui suivent chaque scénario. Éviter le "on verra" post-lancement. La clarté des seuils empêche le biais de confirmation qui pousse à ignorer les signaux négatifs.
Cohorte hebdomadaire tracée dès J1 dans PostHog. Alerte automatique si D7 rétention < 22% sur 2 cohortes consécutives. Reviews mensuelles d'analyses qualitatives (user interviews) pour comprendre pourquoi les utilisateurs partent.
Si D30 < 20% sur 3 mois consécutifs : session de crise de 1 semaine. 20 user interviews avec les utilisateurs qui ont churné. Identifier le point de rupture précis (onboarding ? première suggestion ? manque d'habitude ?). Correction ciblée basée sur les data — pas sur des hypothèses.
Si après 6 mois et 3 itérations majeures la rétention reste structurellement faible : considérer un pivot. Options : focus exclusif sur les stylistes B2B (revenu plus direct), pivot vers un outil de capsule wardrobe plus utilitaire (moins identitaire), ou pivot vers un marché géographique différent avec une culture plus orientée "style conscient".
Firebase App Check activé dès le J1 (DeviceCheck iOS, Play Integrity Android). Rate-limiting Cloud Function upload : max 10 uploads/heure/compte, max 50/jour. Limite comptes créés depuis la même IP : 3 comptes/24h. Validation côté serveur de chaque upload (taille max 10MB, formats acceptés uniquement).
Alerte GCP si coût AI > 200% de la moyenne en moins de 2 heures. Dashboard des comptes avec comportements anormaux (uploads > 30/heure). Sentry alerte sur les rate limit hits anormaux.
Si attack détectée : Cloud Function emergency kill switch (désactive les nouvelles analyses AI en 5 minutes via Firebase Remote Config). Suspension automatique des comptes avec comportement anormal. Contact OpenAI pour signalement si nécessaire.
GCP Budget Alert à 150% du plan mensuel → email immédiat + Slack. Budget Alert à 200% → suspension automatique des Cloud Functions non-critiques. Jamais laisser une facture dépasser 3× le budget prévu sans intervention humaine.