Vue d'ensemble
Produit
BeYourself n'est pas une app de photos de vêtements. C'est un moteur d'identité personnelle alimenté par des données comportementales vestimentaires. Voici sa mécanique réelle.
BeYourself transforme une garde-robe désorganisée en intelligence identitaire personnelle, via trois couches successives : ingestion des données (ce que tu possèdes), analyse comportementale (ce que tu portes réellement), et inférence identitaire (qui tu es à travers ce que tu portes).
Le système s'améliore à chaque interaction. Chaque tenue portée, chaque achat évalué, chaque suggestion acceptée ou refusée alimente un profil qui devient plus précis avec le temps. C'est le fondement du switching cost émotionnel et de la rétention longue durée.
- Contexte capturé (météo, agenda, humeur)
- Suggestion générée depuis la garde-robe
- Tenue choisie + loggée (1 clic)
- Profil raffiné silencieusement
- Suggestion demain plus précise
- Photo ou URL de pièce envisagée
- Analyse de cohérence avec profil
- Score d'alignement identitaire affiché
- Décision d'achat informée
- Données d'intention enrichissent le profil
- Journal de style consulté
- Patterns et évolutions visualisés
- Style Clarity Score progressant
- Rétrospective partageable générée
- Recommandation de "gaps" dans la garde-robe
Couche 1 — Inventaire : La garde-robe digitale. Chaque pièce possédée avec ses métadonnées (couleur, type, silhouette, fréquence de port). La fondation. Sans elle, rien ne fonctionne.
Couche 2 — Profil d'identité : L'intelligence construite sur l'inventaire. Les patterns détectés, le vocabulaire stylistique personnel, les contextes d'usage, le Style Clarity Score. C'est le moat — impossible à reconstruire chez un concurrent.
Couche 3 — Surfaces d'activation : Les points de contact quotidiens : suggestion matinale, check avant achat, journal de style. Chaque surface génère de la rétention et alimente la couche 2.
Couche 4 — Écosystème : Les extensions qui amplifient la valeur : outils B2B stylistes, partage social, intégrations partenaires (Vinted, Zalando). Construire uniquement après validation des couches 1-3.
Le produit est fondamentalement un système d'apprentissage. Sa valeur ne vient pas de ses fonctionnalités mais de ce qu'il apprend sur toi. C'est ce qui explique pourquoi la rétention s'améliore avec le temps — l'inverse de la plupart des apps.
Modules
Principaux
Six modules. Trois critiques pour le MVP. Trois construits après la validation product-market fit.
Sous-Modules
La granularité qui permet de prioriser les sprints, d'éviter de construire trop tôt, et d'identifier les avantages concurrentiels au niveau feature.
| Sous-module | Rôle | Données | Phase |
|---|---|---|---|
| item_ingestion | Upload photo → background removal → extraction AI des métadonnées (couleur, type, silhouette). C'est le goulot d'étranglement UX de l'onboarding — doit être le plus rapide possible. | Image brute → item{color, type, fit, texture, brand} |
MVP |
| item_catalog | Recherche, filtres, organisation par catégories. L'interface principale de navigation dans la garde-robe. Doit être fluide — c'est ce que l'utilisateur voit en premier. | Items indexés pour recherche full-text + filtres | MVP |
| usage_tracker | Log de port pour chaque item (quand, dans quel contexte). Calcule le coût-par-port, identifie les pièces jamais portées. Alimente directement le profil d'identité. | outfit_log{items, date, context, mood} |
MVP |
| bulk_import | Import depuis Vinted historique d'achats, Zalando/ASOS orders, Instagram saves. Réduit drastiquement la friction d'onboarding. Clé pour atteindre le seuil de valeur plus vite. | External APIs → items normalisés | Moat acquisition |
| item_valuation | Calcul du coût-par-port, valeur marchande estimée des pièces (pour Vinted). Use case secondaire fort pour la détox vestimentaire. | Prix d'achat + fréquence port + prix marché secondaire | Phase 2 |
| Sous-module | Rôle | Données | Phase |
|---|---|---|---|
| style_temperament | Questionnaire onboarding 5 min → profil initial sans aucune photo. Produit la première valeur immédiate. C'est l'aha moment zéro — sans lui, l'utilisateur doit uploader 50 pièces avant de voir quoi que ce soit d'intéressant. | Questionnaire réponses → style_profile_v0 |
MVP — critique |
| visual_dna | Analyse des patterns visuels de la garde-robe : palettes dominantes, silhouettes récurrentes, textures préférées. Construit sur les embeddings des photos d'items. C'est le moat. | Item embeddings → color_palette, silhouette_graph, texture_map |
MVP |
| context_mapper | Profil multi-context : qui tu es au travail, le week-end, en soirée. Détecte la fragmentation identitaire (si les 3 contextes sont très différents → insight pertinent). | Outfit logs par contexte → context_personas[] |
MVP light |
| style_clarity_score | Métrique de cohérence identitaire (0-100). Mesure l'alignement entre ce que tu possèdes, ce que tu portes, et les patterns détectés. Gamification légère — la progression du score est un puissant moteur de rétention. | Visual DNA + usage patterns → clarity_score{value, delta, reasons} |
Moat rétention |
| purchase_alignment | Analyse si un achat envisagé est cohérent avec le profil actuel. Prédit si la pièce sera portée. Use case "check avant achat" — la feature la plus différentielle du marché. | Nouveau item + profil courant → alignment_score + reasoning |
MVP |
// note_architecture : le style_temperament et le visual_dna sont les deux sous-modules les plus critiques pour l'aha moment. Les construire en premier, les optimiser en premier. Tout le reste peut être imparfait en V1 — ces deux-là ne peuvent pas l'être.
Flux
Utilisateurs
Chaque flux a une émotion dominante, un risque précis et un mode UX. Les ignorer, c'est construire un produit qui fonctionne techniquement mais échoue humainement.
Vient d'une recommandation, d'un contenu TikTok ou d'une recherche Google. Motivation élevée, méfiance latente.
5 questions visuelles sur les vêtements et contextes. Pas de champs texte. Chaque question produit un micro-insight immédiat.
Le premier profil d'identité stylistique est présenté — avant tout upload. "Voici ce qu'on sait déjà de toi."
"Pour affiner ce profil, ajoute tes 5 premières pièces." Pas 50 — 5. Avec un contexte de valeur clair pour chaque effort demandé.
Avec 10+ items, la première suggestion de tenue est générée. Elle doit être surprenante — une combinaison que l'utilisateur n'aurait pas pensée seul mais qui lui semble juste.
"Cette app me comprend mieux que je ne pensais." L'utilisateur devient un utilisateur régulier. C'est la conversion comportementale — avant la conversion monetaire.
Suggestion matinale
Le produit doit disparaître. 3 clics maximum de l'ouverture à la décision finale. Toute friction ici détruit l'habitude. La rapidité est le produit.
Journal de style
Moment contemplatif. L'interface ralentit volontairement. Animations douces, espace blanc, temps de lecture. L'émotion doit pouvoir s'installer.
Onboarding
L'utilisateur est guidé à chaque micro-étape. Aucune décision ambiguë. Chaque action demandée est accompagnée d'une raison et d'un bénéfice immédiat visible.
Check avant achat
L'app s'intègre dans le flux d'achat comme un outil de décision silencieux. Le score d'alignement est visible en 2 secondes. L'interface ne s'impose pas.
Paywall
Le paywall arrive après l'aha moment, non avant. Il est présenté comme "débloquer ce qui est déjà tien" — l'utilisateur a déjà investi dans son profil. La conversion est la continuité logique.
Flux de
Données
Ce qui circule, entre quels modules, et pourquoi certaines données sont le vrai actif stratégique du produit.
Photos d'items + métadonnées extraites (couleur, type, silhouette, texture, marque). Fondation de tout le reste. Circule de ingestion → visual_dna → suggestion_engine.
Ce que l'utilisateur porte réellement (vs ce qu'il possède). Fréquences, contextes, associations. Personne d'autre dans le marché n'accumule cette donnée. C'est le vrai avantage compétitif data.
Météo (API externe), agenda (opt-in, local-only), état émotionnel (déclaré, local-only). Utilisés uniquement pour la suggestion matinale. Non stockés durablement par défaut.
Humeur déclarée le matin, contexte émotionnel lors des transitions. Architecture : stockage local prioritaire. Transmission serveur optionnelle et explicitement consentie. Une fuite ici = fin de confiance.
Accepter / refuser / modifier une suggestion. Chaque signal affine le profil. La valeur s'accumule de façon non-linéaire : les 100 premiers feedbacks améliorent le profil 10× plus que les 100 suivants.
Événements comportementaux anonymisés (écrans vus, features utilisées, temps de session). Séparés des données identitaires. Utilisés pour les décisions produit et growth — jamais pour cibler l'utilisateur.
La donnée la plus précieuse de BeYourself n'est pas la garde-robe (Whering l'a aussi). C'est la combinaison : ce que les gens possèdent + ce qu'ils portent réellement + dans quels contextes + leur évolution dans le temps. Cette quadruple corrélation n'existe nulle part ailleurs. À 500K profils actifs, c'est la base d'une API d'intelligence marché que les marques paieraient des centaines de milliers d'euros par an.
Architecture
Logique
Monolith modulaire en V1. Microservices uniquement quand la douleur est réelle — pas anticipée. L'architecture doit servir la vitesse, pas les slides d'investisseur.
Firebase impose une architecture naturellement serverless et event-driven — ce qui est un avantage réel pour une petite équipe. Les Cloud Functions se déclenchent sur des événements Firestore (item.onCreate → appel OpenAI Vision → résultat réécrit dans Firestore) ou par appel HTTPS direct depuis Flutter. Pas de serveur à gérer, auto-scaling intégré, cold starts minimisés avec minInstances sur les fonctions critiques.
Le point d'architecture le plus important : Firestore seul ne suffit pas. Firestore est excellent pour les données opérationnelles simples (items, logs, journal — des documents indépendants). Mais le Profile Engine nécessite des requêtes vectorielles, des agrégations complexes et des jointures que Firestore ne supporte pas. La solution : architecture hybride — Firestore pour le temps réel et les lectures simples, Cloud SQL + pgvector pour l'intelligence identitaire. Les deux s'écrivent via Cloud Functions, invisible côté Flutter.
L'AI pipeline reste le seul service à isoler explicitement : Cloud Tasks remplace BullMQ pour la queue asynchrone des jobs d'analyse d'items. Même logique — traitement non bloquant, retry intégré, swappable si OpenAI devient trop cher. Interface AIProvider abstraite obligatoire dès le début.
Point de vigilance Firebase : le vendor lock-in Google est réel et plus fort que Supabase (open source). Les Security Rules Firestore ne sont pas portables. Anticiper cette contrainte dès le design — documenter la logique métier dans les Cloud Functions, pas dans les Rules, pour faciliter une éventuelle migration partielle.
Architecture
Fonctionnelle
Comment les couches interagissent. Les responsabilités de chaque service. Les zones sensibles à ne pas mélanger.
| Service | Responsabilités | Dépendances | Zone sensible |
|---|---|---|---|
| UserService | Création compte, profil utilisateur, préférences, abonnement. Stocké dans Firestore (collection users/{uid}). Custom claims Firebase Auth pour le statut premium et le rôle Pro. |
Firebase Auth, Firestore, Stripe webhook | Multi-tenancy pro : un compte styliste accède à N profils clients via un custom claim clientIds[]. Les Security Rules Firestore doivent refléter cette logique dès V1. |
| WardrobeService | CRUD items dans Firestore (users/{uid}/items/{itemId}), upload vers Firebase Storage, déclenchement du pipeline AI via Cloud Tasks. Ne connaît pas le profil d'identité. |
Cloud Tasks, Firebase Storage, Firestore | L'upload est synchrone côté Flutter mais asynchrone côté traitement. Firestore Realtime listener dans l'UI permet d'afficher "analyse en cours..." puis la mise à jour automatique quand le résultat AI arrive. |
| ProfileService | Construit et maintient le profil d'identité. Lit depuis Firestore (comportements), écrit dans Cloud SQL (profil enrichi + embeddings). Calcule le Style Clarity Score. C'est le service le plus important stratégiquement. | Firestore (lecture), Cloud SQL + pgvector (écriture profil), Cloud Memorystore (cache) | Le profil est recalculé après chaque interaction significative via une Cloud Function. Politique claire sur la fréquence : recalcul immédiat pour les interactions directes (feedback suggestion), batch nocturne pour les analyses de patterns. |
| SuggestionService | Cloud Function callable depuis Flutter. Combine profil Cloud SQL + items Firestore + contexte externe. Résultat mis en cache dans Cloud Memorystore (100K+) ou Firestore (V1). Feedback utilisateur transmis au ProfileService. | ProfileService (Cloud SQL), Firestore (items), Weather API, Cloud Memorystore | Objectif : <500ms ressenti côté Flutter. En V1 : pré-calcul nocturne via Cloud Scheduler → résultat écrit dans Firestore → lecture quasi-instantanée le matin. Pas de calcul en temps réel au réveil. |
| AI Pipeline | Cloud Functions déclenchées par Cloud Tasks. Analyse d'items (OpenAI Vision), génération d'embeddings (text-embedding-3 + CLIP), recalcul de profil intensif. Résultats écrits dans Firestore (métadonnées item) et Cloud SQL (embeddings). Interface AIProvider abstraite — swappable. | Cloud Tasks, OpenAI API, Firestore, Cloud SQL pgvector | Coût par appel API OpenAI. Monitoring de coût GCP configuré dès J1 avec alertes. Cache SHA256 des images pour éviter l'analyse en double. |
Stack
Technique
Chaque choix est justifié. Pas de hype tech. Priorité : vitesse de livraison MVP, RGPD-compliant, scalabilité réaliste à 1M users.
| Couche | Choix | Justification |
|---|---|---|
| Mobile | Flutter + Dart | Performance native iOS/Android depuis un seul codebase. Rendu GPU-acceleré — les animations identitaires et transitions de journal seront plus fluides qu'avec React Native. Dart est typé, compilé, et l'intégration Firebase est first-class. Le recrutement Dart/Flutter est plus compétitif en Europe qu'il y a 3 ans. |
| Navigation | go_router | Standard de facto Flutter post-Navigator 2.0. Routing déclaratif, deep linking natif (important pour les notifications qui ouvrent directement une tenue du journal), gestion des guards d'authentification propre. Maintenu par l'équipe Flutter officielle. |
| State Management | flutter_riverpod | S'intègre naturellement avec les streams Firestore — quand un item est analysé, le profil se met à jour dans l'UI sans code manuel. Compile-safe, testable. Alternative : BLoC si l'équipe préfère une séparation plus stricte. Éviter Provider seul — trop limité pour la complexité du profil identitaire. |
| BaaS | Firebase (region: europe-west1) | Auth + Firestore + Storage + FCM + Analytics dans un écosystème cohérent, réduit la surface à maintenir pour une petite équipe. Obligatoire : configurer la région EU dès la création du projet Firebase — elle n'est pas modifiable après coup. RGPD-compliant avec les bonnes configurations. Vendor lock-in Google à assumer consciemment. |
| Auth | Firebase Auth | Email/password, Google Sign-In, Apple Sign-In, magic link — tout intégré. Gratuit jusqu'à 10K MAU. Security Rules Firestore liées à l'UID Firebase = contrôle d'accès au niveau document sans code backend. Gestion multi-tenant Pro via custom claims sur les tokens. |
| Base principale | Firestore | Document store pour toutes les données opérationnelles simples : items de garde-robe, outfit logs, journal, données Pro. Sync temps réel natif (item analysé → UI Flutter mise à jour sans polling). Offline mode SDK intégré. Limites à connaître : pas de JOINs, pas de requêtes vectorielles, pas d'agrégations complexes → compensé par Cloud SQL pour le Profile Engine. |
| Base Profile Engine | Cloud SQL (PostgreSQL) + pgvector | Le Profile Engine nécessite des requêtes vectorielles (similarité de style), des agrégations (Style Clarity Score), et des jointures (patterns multi-contexte) que Firestore ne peut pas faire. Architecture hybride : Firestore pour le temps réel, Cloud SQL pour l'intelligence. Les deux accédés via Cloud Functions — transparent côté Flutter. |
| Backend | Firebase Cloud Functions v2 (Node.js) | Serverless, auto-scaling, déclenchable par events Firestore ou HTTPS. Pas de serveur à maintenir. Cold start v2 réduit à 200-400ms vs v1. Configurer minInstances: 1 sur les fonctions critiques (SuggestionService, AuthService) pour éliminer le cold start à l'usage quotidien. Coût : €0.40/million d'invocations. |
| Job Queue | Cloud Tasks | Remplace BullMQ. Queue managée GCP : retry configurable, délai, rate limiting, ciblage de Cloud Functions HTTP. Parfait pour le pipeline AI asynchrone (item uploadé → Cloud Task créé → Cloud Function analyse → résultat dans Firestore). Pas de Redis nécessaire pour la queue. |
| Storage images | Firebase Storage | Cloud Storage managé, Security Rules Firebase (seul le propriétaire de l'UID peut lire ses images). Intégré nativement avec Flutter. Plus cher que R2 à l'échelle ($0.026/GB/mois) — surveiller les coûts à 100K users, envisager migration vers Cloud CDN + règles custom si le coût devient significatif. |
| Cache | SDK Firestore offline → Cloud Memorystore (100K+) | Le SDK Firestore gère automatiquement un cache local côté client — pas besoin de Redis en V1. À 100K users, Cloud Memorystore (Redis managé GCP) pour le cache serveur des suggestions pré-calculées (les générer la nuit, les servir depuis Redis le matin en <50ms). |
| AI Vision | OpenAI GPT-4o-mini Vision | Inchangé. Interface AIProvider abstraite obligatoire. À noter : Vertex AI (natif GCP) est une alternative à évaluer sérieusement dans un stack Firebase/GCP pour simplifier l'infrastructure et potentiellement réduire la latence inter-services. Décision à prendre à 50K users selon les coûts comparés. |
| Embeddings | text-embedding-3-small + CLIP → Cloud SQL pgvector | Embeddings calculés via Cloud Functions, stockés dans Cloud SQL pgvector. En V2 : Vertex AI Matching Engine est l'alternative naturelle dans l'écosystème GCP — moteur vectoriel managé, intégration native, plus scalable que pgvector à 50M+ vecteurs. |
| Paiements | Stripe | Inchangé. Webhooks gérés via une Cloud Function dédiée. Stripe + Firebase Auth = mise à jour du custom claim "isPremium" sur vérification de l'abonnement actif à chaque session. |
| Notifications | FCM via firebase_messaging (Flutter) | FCM est natif dans l'écosystème Firebase. firebase_messaging gère iOS (APNs via FCM) et Android en une seule API Flutter. La suggestion matinale est envoyée via une Cloud Function schedulée (Cloud Scheduler) à l'heure de réveil configurée par l'utilisateur. |
| Analytics | Firebase Analytics + PostHog | Firebase Analytics pour les événements produit de base (gratuit, zéro config). PostHog en parallèle pour le feature flagging (A/B tests), l'analyse comportementale fine (funnels, rétention par cohorte) et le session replay. Firebase Analytics seul est insuffisant pour les décisions produit complexes. |
| Monitoring | Firebase Crashlytics + Cloud Monitoring | Crashlytics = standard pour les crashes Flutter (meilleure intégration que Sentry sur mobile natif, stack traces Dart déobfusquées). Cloud Monitoring + Cloud Logging pour les métriques Cloud Functions et les alertes de coûts. Alertes de coût GCP configurées dès J1 — essentiel avec Firestore (facturation à l'opération). |
| CI/CD | Codemagic + GitHub Actions | Codemagic est spécialisé Flutter : gère le code signing iOS, la distribution TestFlight/Google Play, les builds Dart optimisés. GitHub Actions pour le pipeline backend (lint, tests Cloud Functions, deploy). Alternative : GitHub Actions avec Fastlane si l'équipe préfère tout centraliser. |
| // ne_pas_construire_avant_100k_users : Vertex AI Matching Engine (rester sur pgvector), modèles ML custom, Cloud Memorystore Redis (Firestore offline suffit), multi-région GCP, architecture microservices, équipe MLOps interne. | ||
Dépendances
Système
Ce qui est acceptable aujourd'hui peut devenir un risque existentiel à l'échelle. Identifier maintenant pour anticiper les mitigation.
Analyse d'items (item_ingestion). Coût : ~$0.002/image × 50 items × users = critique à l'échelle. Mitigation : couche d'abstraction AIProvider dès V1, cache des résultats d'analyse, évaluation Gemini Flash comme alternative moins chère.
Distribution principale iOS. Risque : changement de politique sur la catégorie "mode" ou "santé". Mitigation : investir dans la version web progressive (PWA) en parallèle. Ne jamais être mono-dépendant d'Apple pour la distribution.
Auth + Firestore + Storage + Cloud Functions + FCM — le cœur de l'infrastructure. Vendor lock-in fort : les Security Rules Firestore, les triggers de Functions et la structure des SDK ne sont pas portables. Mitigation : encapsuler toute la logique métier dans les Cloud Functions (pas dans les Rules), documenter les schémas Firestore indépendamment. En cas de migration forcée, les Cloud Functions sont extractibles plus facilement que les Rules. Surveiller les coûts Firestore à l'opération dès 50K users.
Facturation à l'opération : $0.06/100K lectures, $0.18/100K écritures. Un utilisateur actif daily peut générer 500+ lectures/jour (profil, items, suggestions). À 100K MAU actifs = potentiellement €3-8K/mois juste en lectures Firestore. Mitigation : conception des requêtes Firestore optimisée dès V1, cache côté client agressif, dénormalisation des données pour éviter les lectures multiples.
Paiements et abonnements. Risque : faible, standard de l'industrie. Commission 1.4%+0.25€ (EU). À l'échelle : explorer négociation de frais custom. Pas de migration avant €5M ARR.
iOS 16+ nécessite un opt-in explicite. Taux de consentement moyen : 40-50% sur apps lifestyle. La suggestion matinale via push dépend de cet opt-in. Mitigation : alternative via widget iOS, intégration agenda, SMS opt-in premium.
Import historique d'achats pour réduire friction onboarding. Risque : ces APIs ne sont pas publiques, accès via scraping ou partenariat officiel. Commencer par le scraping légal (CGU-compliant), négocier partenariats officiels à 100K users.
Contexte pour suggestions (réunion importante → tenue pro). Opt-in très sensible — beaucoup d'utilisateurs refuseront. Traiter comme une feature bonus, pas un prérequis. Fallback : contexte déclaré manuellement ("aujourd'hui je vais au bureau").
Scalabilité
Produit
Ce qui fonctionne parfaitement à 1K users explose souvent à 100K. Voici ce qui casse, quand, et ce qu'il faut anticiper dès maintenant.
Firebase Spark → Blaze pay-as-you-go. Cloud Functions v2, Firestore, Firebase Storage. Cloud SQL micro instance pour le Profile Engine. Coût infra : <€150/mois hors AI. Firebase gratuit jusqu'à ~50K lectures/jour.
Coûts AI Vision : ~€0.10/user pour l'onboarding. Cold starts Cloud Functions si minInstances = 0. Les alertes de coût GCP ne sont pas configurées par défaut — risque de surprise sur la facture.
Configurer les alertes de budget GCP dès J1. Cache des résultats d'analyse AI (hash image → résultat). minInstances=1 sur SuggestionService et AuthService. Modéliser Firestore pour minimiser les lectures (dénormaliser le profil dans le document user).
Firebase Blaze + Cloud Memorystore Redis (suggestions pré-calculées). Cloud SQL scale up (db-standard-2). Cloud CDN pour Firebase Storage. Coût infra : €3-8K/mois. Firestore devient le premier poste de coût — surveiller les lectures par session.
Coûts Firestore : ~€3-5K/mois à ce stade si les requêtes ne sont pas optimisées. Cold starts Cloud Functions sous charge élevée (7h30 spike suggestion matinale). Coûts AI Vision : €10-15K/mois si pas de cache.
Cloud Scheduler + Cloud Functions pour pré-calculer les suggestions la nuit (servir depuis Memorystore le matin). Audit Firestore : identifier et éliminer les listeners inutiles. Évaluer Vertex AI vs OpenAI pour l'analyse d'items (même écosystème GCP = latence réduite).
Cloud Functions → Cloud Run (containers, plus de contrôle sur la concurrence). Cloud SQL vers Cloud Spanner si les requêtes Profile Engine deviennent un bottleneck. Vertex AI Matching Engine pour les embeddings (remplace pgvector). Coût infra : €25-60K/mois.
Firestore lectures à cette échelle = premier poste de coût absolu (~€15-25K/mois). pgvector sur Cloud SQL ralentit à 50M+ vecteurs. La modération des features sociales (si activées) nécessite une équipe dédiée. Cloud Functions ne suffisent plus pour les jobs CPU-intensifs (profil recalcul).
Migration vers Vertex AI Matching Engine pour les embeddings. Cloud Run pour les services à haute concurrence. BigQuery pour le data warehouse (API Intelligence Marché B2B). Négociation contrat Google Cloud enterprise pour réduction tarifaire.
Multi-région (EU + US + APAC). Modèles ML propriétaires (plus rentable que l'API OpenAI à cette échelle). Architecture event-driven pour le profil en temps réel. Équipe platform engineering dédiée.
Modération communautaire à grande échelle. RGPD multi-pays complexifié. Diversité culturelle des profils stylistiques (modèles entraînés sur données EU mal adaptés à d'autres marchés). Coûts infra : €150-500K/mois.
À 10M profils, le dataset de préférences esthétiques réelles est unique au monde. L'API Intelligence Marché B2B devient la principale source de revenus haute marge. Impossible à répliquer par un concurrent sans les années de données accumulées.
// bottleneck_numero_un : les coûts AI Vision à l'onboarding. Chaque utilisateur uploadant 50 items coûte ~€0.10 en analyse. À 100K users = €10K juste pour l'onboarding. Implémenter le cache d'analyse (SHA256 hash d'image → résultat stocké), la réutilisation pour items similaires, et l'évaluation d'alternatives moins chères dès que le volume justifie l'investissement d'optimisation.