Organisation
par Phase
Une équipe trop grosse trop tôt est aussi paralysante qu'une équipe trop petite. Chaque recrutement doit déverrouiller quelque chose de précis.
- Fondateur / PM / Designer
- Flutter Dev Senior
- Flutter Dev Mid
- Backend / Firebase Dev
- PM (fondateur ou dédié)
- Product Designer (temps plein)
- Flutter Dev Senior
- Flutter Dev Mid
- Backend / Firebase Dev
- Growth / Content (50%)
- PM
- Product Designer
- 2× Flutter Dev
- Backend Dev
- ML / AI Engineer
- Growth Manager
- B2B Sales / Stylistes
- QA (freelance ou partiel)
- Support client (partiel)
- 2× PM (B2C + B2B)
- 2× Product Designer
- 3× Flutter Dev
- 2× Backend Dev
- ML Engineer
- Data Analyst
- DevOps / Infra
- Growth Manager
- Community Manager
- 2× Support client
- 2× Content Creators
La règle de recrutement BeYourself : recruter quand une absence crée un blocage mesurable sur les métriques produit ou sur la vitesse d'exécution — pas par anticipation. Un recrutement anticipé sur un poste dont le travail n'existe pas encore crée de la dette organisationnelle.
| Rôle | Erreur classique | Quand vraiment recruter |
|---|---|---|
| QA Engineer | Recruter un QA dès le MVP pour "assurer la qualité". En MVP, le budget de QA est mieux dépensé à améliorer le produit qu'à tester ce qui n'existe pas encore. Les fondateurs testent. | Quand la codebase a atteint un volume que les développeurs ne peuvent plus tester manuellement exhaustivement. En pratique : V1 avancée ou dès que les régressions deviennent fréquentes. |
| Data Engineer | Construire une infrastructure data complète avant d'avoir des données à analyser. Au MVP, Firebase Analytics + PostHog couvrent largement les besoins. | Quand les données existent en volume suffisant (100K+ events/jour) pour que des pipelines structurés apportent une valeur réelle de décision. |
| DevOps / Infra Engineer | Gérer l'infrastructure comme un problème d'ingénierie complexe alors que Firebase/GCP sont des services managés conçus pour les équipes sans DevOps. | Quand la stack dépasse Firebase et que des optimisations d'infrastructure spécifiques (Kubernetes, multi-cloud) sont justifiées économiquement. En pratique : V2 avancée à 200K+ users. |
| Growth Manager | Recruter un Growth avant d'avoir un produit à faire croître. Growth sans rétention = amplifier le churn. | Après que D30 retention > 25% est confirmée. Un bon Growth manager peut multiplier les acquisitions par 3-5× — mais seulement si le produit retient. |
Rôles &
Responsabilités
Chaque rôle doit avoir un ownership clair. Dans une petite équipe, un rôle flou est une décision non prise.
Écrire et maintenir les PRDs. Prioriser le backlog (RIRE framework). Animer les sprint plannings. Définir et surveiller les métriques produit. Arbitrer les conflits entre product et tech. Être le gardien de la proposition de valeur.
En pré-MVP : le fondateur fait ce rôle. C'est souvent la meilleure configuration — personne ne connaît mieux la vision. Recruter un PM dédié uniquement quand le fondateur technique est submergé par le produit et la technique simultanément, ou quand l'équipe dépasse 6 personnes.
Architecture de l'app Flutter (navigation, state management, design system implementation). Définit les conventions de code. Review toutes les PRs. Gère les dépendances des packages Dart. Coordonne le travail mobile entre les développeurs.
Ce rôle est le risque de recrutement le plus élevé. Un mauvais senior Flutter prend des décisions d'architecture qui coûtent 2-3 mois à défaire. Privilégier quelqu'un qui a déjà livré une app Flutter en production — pas quelqu'un qui "connaît Flutter" en théorie.
Architecture Firestore (schéma, Security Rules, indexation). Cloud Functions (pipeline AI, notifications, scheduling). Intégration OpenAI Vision et AI providers. Cache SHA256 et optimisations coûts. Stripe webhooks et gestion abonnements.
La conception des Security Rules Firestore doit être faite par ce profil dès le J1 — elles définissent qui peut lire/écrire quoi, et les corriger en production avec des utilisateurs actifs est extrêmement risqué. L'architecture multi-tenant pour le B2B Pro doit être pensée par ce profil avant la première ligne de code Pro.
Concevoir tous les écrans et flows depuis les wireframes jusqu'aux maquettes finales. Maintenir le design system Figma aligné avec les tokens Flutter. Produire les specs de handoff pour les développeurs. Conduire les tests utilisateurs. Garder la cohérence de l'expérience sur toutes les features.
Un designer qui code (a minima, qui comprend les contraintes Flutter). La friction de handoff entre Figma et Flutter est l'une des causes les plus fréquentes de retard. Un designer qui comprend les limitations des widgets Flutter évite de concevoir des écrans impossibles à implémenter en 3 jours.
Améliorer le moteur de suggestion (au-delà des règles métier du MVP). Développer le modèle d'embeddings pour le Visual DNA Profile. Fine-tuner un modèle d'analyse de vêtements sur les données BeYourself. Optimiser les coûts AI (cache, batch processing, modèles alternatifs).
En MVP et V1, le moteur rule-based suffit pour valider l'aha moment. Un ML engineer sans suffisamment de données d'entraînement est un investissement prématuré. Commencer le recrutement à M8, opérationnel à M10-12 quand les données de feedback (suggestion acceptée/refusée) sont suffisamment nombreuses.
Produire le contenu SEO (blog). Gérer le compte TikTok BeYourself. Coordonner les partenariats créateurs. Mesurer et optimiser les funnels d'acquisition. Gérer les campagnes de referral. Reporter sur le K-factor et le CAC par canal.
Recruter un Growth Manager qui arrive avec un playbook paid social. BeYourself n'a pas besoin de paid social en early stage — il a besoin de quelqu'un qui comprend le content marketing identitaire et les mécaniques de distribution organique. Évaluer les candidats sur leur compréhension du positionnement, pas sur leur expérience en ads.
Workflow
Agile
Le Scrum strict est une sur-ingénierie pour une équipe de 5 personnes. Un Kanban légèrement structuré avec une cadence prévisible est plus efficace.
Ice Box : toutes les idées de features qui ont été identifiées mais pas encore validées. Sans contrainte de format. Le PM seul peut ajouter ici. Pas de dates, pas de priorités.
Backlog validé : features avec une PRD écrite, une spec technique estimée, et un design Figma prêt. Seules les features dans cet état peuvent entrer dans un sprint. Cela empêche les features "idée de lundi matin" de se retrouver en sprint sans réflexion.
Sprint actif : les features engagées pour le sprint en cours. Une fois en sprint, pas de modification sauf incident bloquant. La résistance aux changements en cours de sprint est un signal de discipline produit, pas de rigidité.
La règle du 70% : si une spec est à 70% claire, commencer le développement. La clarté totale à 100% avant de coder n'existe pas — et l'attendre crée de la paralysie. Les 30% restants se clarifient pendant l'implémentation.
La règle du "time-box decision" : aucune décision de design ou d'architecture ne peut bloquer une tâche pendant plus de 24h sans escalade. Si la décision est bloquée à 24h, le PM fait un choix provisoire documenté — qui peut être révisé mais qui débloque l'équipe immédiatement.
La règle des bugs en sprint : les bugs critique (crash, data loss) entrent dans le sprint immédiatement et remplacent une tâche équivalente. Les bugs importants (UX dégradée) entrent dans le prochain sprint. Les bugs mineurs (cosmétiques) vont dans l'ice box et sont évalués au planning suivant.
Gestion
Projet
Les outils ne sont pas une stratégie. Ils doivent rendre les décisions plus rapides et les dépendances visibles — pas créer de la bureaucratie.
- LinearIssues, sprints, roadmap€8/seat
- GitHubCode + PRs + code review€4/seat
- CodemagicCI/CD Flutter iOS + Android€75/mois
- FigmaDesign + prototypes + specs€15/seat
- NotionDocumentation + PRDs€8/seat
- SlackCommunication async équipe€7/seat
- PostHogProduct analytics + funnels€0 (self-hosted)
- SentryError tracking + alertes crash€26/mois
- Firebase ConsoleApp analytics + CrashlyticsInclus GCP
- LoomVidéos async (démos, specs)€12/seat
La dette technique n'est pas un problème à éviter. C'est une décision à gérer consciemment. Deux types de dette doivent être traités différemment :
Dette stratégique (acceptable) : simplifications délibérées en MVP pour aller vite. Ex : pas de cache AI au MVP, règles métier hard-codées plutôt que configurables, absence d'i18n en V1. Ces dettes ont un plan de remboursement explicite dans la roadmap.
Dette accidentelle (dangereuse) : architecture Firestore sous-optimale qui coûtera 3 mois à refactoriser à 50K users, Security Rules incorrectes qui créent des failles, absence de tests sur les flows critiques (paiement, upload). Ces dettes s'accumulent sans plan et peuvent bloquer l'équipe entière.
Règle de priorisation tech debt : réserver 20% de chaque sprint à la dette technique dès la V1. Pas 30%, pas "quand on a le temps" (= jamais). 20% est le seuil où la dette diminue progressivement sans ralentir le product velocity. En dessous, la dette s'accumule. Au-dessus, le produit n'avance pas assez vite.
Quelle feature est dans le prochain sprint. Basé sur le framework RIRE (Impact_Identité × Reach × Rétention × Revenue / Effort). Input de toute l'équipe, décision finale du PM.
Quelle approche technique choisir (Firestore vs SQL, Cloud Functions vs Cloud Run, etc.). PM donne le contexte business, Tech Lead décide.
Ce qui est dans vs hors scope d'une feature précise. Discussion PM + designer + dev, timeboxée à 30 minutes. Si pas de consensus : PM décide.
Comment répondre à un bug critique en production. Le Tech Lead décide immédiatement sans attendre l'alignement. Post-mortem dans les 24h après résolution.
Changer le positionnement, modifier la structure de monétisation, entrer sur un nouveau marché. Décision fondateur(s) uniquement, après data et discussion équipe.
Documentation
La documentation n'est pas une fin en soi. Elle existe pour qu'un développeur qui rejoint l'équipe en M6 puisse être productif en 2 jours, pas en 2 semaines.
| Document | Propriétaire | Niveau de détail | Durée de vie |
|---|---|---|---|
| Architecture Decision Records (ADRs) | Tech Lead | Court (1-2 pages). Format : contexte → décision → alternatives rejetées → conséquences. Ne jamais supprimer — l'histoire des décisions est précieuse. | Permanent |
| Schéma Firestore + Security Rules | Backend Dev | Complet. Chaque collection documentée avec les champs, les types, les règles d'accès. C'est le document le plus critique pour un nouveau développeur. | Mis à jour à chaque modification |
| PRDs des features (ch05) | PM | Complet (user flow, règles métier, états, erreurs). Living document — mis à jour au fur et à mesure de l'implémentation réelle. | Vivant · mis à jour |
| Runbook incidents production | Tech Lead | Concis mais précis. "Si crash rate > 1% → étapes 1, 2, 3". Pas de théorie — des actions. | Mis à jour après chaque incident |
| Guide d'onboarding développeur | Tech Lead + PM | Moderate. Setup env local, conventions de code, comment déployer, qui contacter pour quoi. | Mis à jour à chaque recrutement |
| Design System documentation | Designer | Dans Figma — pas en dehors. Chaque composant documenté avec ses variants et ses règles d'usage. Synchronisé avec les tokens Flutter. | Vivant · dans Figma |
Comptes-rendus de réunions : personne ne les relit. Les décisions prises en réunion doivent être documentées dans Linear (en tant que commentaire sur l'issue concernée), pas dans un doc séparé. Un doc "CR meeting du 15 nov" sans lien avec une tâche est mort à la création.
Wikis de process trop détaillés : une page de 3 000 mots sur "comment créer une feature" sera ignorée. Préférer des templates courts dans Linear ou Notion. Ce qui doit guider le comportement doit tenir en 5 bullet points.
Documentation de fonctionnalités abandonnées : archiver clairement plutôt que maintenir. Une doc de feature abandonnée sans marquage explicite crée de la confusion pour les nouveaux développeurs.
Process
QA
Pas de QA engineer en MVP/V1 — mais pas d'absence de QA non plus. La qualité est une discipline collective, pas un département.
| Type de test | Qui le fait | Fréquence | Outils |
|---|---|---|---|
| Tests unitaires (logique métier) | Dev (auteur) | À chaque PR. Obligatoire pour : calcul du Style Clarity Score, algorithme de suggestion, parsing des résultats AI, logique de paiement. | flutter_test |
| Tests d'intégration (flows critiques) | Dev (review) | Sur les 5 flows critiques avant chaque release : onboarding complet, upload + analyse AI, suggestion + log, paywall + subscription, purchase check. | integration_test (Flutter) |
| Tests UX manuels | PM + Designer | Sur chaque nouvelle feature avant merge en main. Focus : est-ce que l'état empty, le loading state et l'error state sont gérés correctement ? | Simulateur iOS + Android physique |
| Tests de régression | Dev (review) | Avant chaque release. Smoke test des 10 user actions les plus fréquentes sur 3 devices réels (iPhone SE, iPhone 15, Samsung Galaxy A53). | Checklist manuelle standardisée |
| Tests de performance | Tech Lead | Mensuel ou après toute modification du pipeline AI ou Firestore. Mesurer : cold start, temps d'affichage suggestion, latence AI p95. | Firebase Performance Monitoring |
| Tests sécurité Security Rules | Backend Dev | À chaque modification des Security Rules Firestore. Firebase Security Rules Emulator — tester explicitement les cas "utilisateur A accède aux données de B". | Firebase Emulator Suite |
Toute release doit passer par ce smoke test manuel. 30 minutes maximum. Si une de ces 5 journeys est cassée, la release est bloquée.
J1 — Onboarding complet : nouvel utilisateur → questionnaire → profil_v0 → upload 3 items → premier accès à la wardrobe.
J2 — Upload + analyse : photo prise → background removal → analyse AI → item visible dans la grille avec métadonnées correctes.
J3 — Suggestion + log : ouverture app → suggestion visible → sélection d'une tenue → log automatique confirmé.
J4 — Paywall + abonnement : trigger paywall déclenché → affichage pricing → paiement Stripe sandbox → accès premium activé.
J5 — Push notification : notification reçue → ouverture app → contenu correspondant affiché correctement.
Gestion
Releases
Une release mobile n'est pas une déploiement web. Le process App Store impose une contrainte temporelle qui doit être intégrée dans la planification dès le départ.
Développement en branche feature. PR ouverte vers main quand la feature est complète. Review obligatoire par 1 autre développeur.
Review technique (Tech Lead ou pair) + review UX (PM/Designer si feature visible). Pas de merge sans approbation.
Build automatique + tests unitaires + tests d'intégration. Blocage automatique si un test échoue. Artefacts de build stockés.
Build staging distribué via Firebase App Distribution aux testeurs internes (fondateurs + quelques beta users). Smoke test des 5 journeys critiques.
Soumission Apple (iOS) + Google Play (Android). Délai : 3-7 jours pour iOS, quelques heures pour Android. Ne jamais soumettre le vendredi.
Release approuvée. Monitoring 24h : crash rate, AI latency, error rate. Rollback trigger : crash rate > 1% ou erreur critique bloquant un flow.
Sévérité 1 — Critique (crash > 1%, data loss, paiements échoués) : rollback immédiat via le flag Firebase Remote Config sans attendre App Store review. Le rollback côté serveur (Cloud Functions, Firestore rules) est possible en minutes. Pour le rollback app, utiliser la feature phased rollout Google Play — stopper la progression de la release.
Sévérité 2 — Haute (UX dégradée, feature centrale non-fonctionnelle) : hotfix en urgence soumis à l'App Store avec demande d'expedited review (Apple accepte les expedited reviews pour les bugs critiques). Délai : 24-48h. Communiquer au support et sur les stores.
Sévérité 3 — Moyenne (bug mineur, cosmétique, cas limite) : correction dans le prochain sprint régulier. Aucune urgence de release.
Communication
Interne
Une startup de 5-8 personnes n'a pas de problème de communication. Quand les problèmes arrivent, c'est presque toujours un problème de décisions non prises ou d'informations non partagées — pas de réunions manquantes.
Async par défaut : 90% de la communication doit se faire de manière asynchrone (Slack, Linear comments, Loom vidéos). Les réunions synchrones sont réservées aux décisions complexes qui nécessitent un débat en temps réel. "Une réunion pour transmettre de l'information" est du temps volé à l'équipe.
Les décisions vivent dans Linear ou Notion — jamais dans Slack : une décision prise dans un thread Slack est une décision perdue. Chaque décision importante doit être documentée dans le ticket concerné (Linear) ou dans le PRD (Notion). Quand quelqu'un demande "pourquoi on a fait ça ?", la réponse doit être linkable.
La culture du Loom : pour expliquer une feature, une démo, ou une spec complexe, un Loom de 3 minutes vaut mieux qu'une réunion de 30 minutes. Enregistrable, rejouable, non-interruptif.
Format fixe dans un thread Slack dédié : 1) Hier 2) Aujourd'hui 3) Bloquants. Posté avant 10h. Pas de réunion standup — elle est remplacée par ce thread. Maximum 3 phrases par item. Si quelqu'un a un bloquant, les autres répondent dans le thread.
Les 3 questions auxquelles cette réunion répond : qu'est-ce qu'on build ce sprint ? Pourquoi dans cet ordre ? Qui fait quoi ? Pas de discussion sur les features — elles sont validées avant. Si une feature n'a pas de PRD, elle n'entre pas dans le sprint.
Chaque développeur montre ce qui a été livré cette semaine — pas des specs, pas des slides, pas de Figma. Du produit qui tourne. Si rien n'est démo-able, quelque chose a dysfonctionné dans l'organisation du sprint. C'est un signal, pas une punition.
30 minutes de métriques (DAU/MAU, SAR, D30 retention, MRR) + 30 minutes de discussion produit (qu'est-ce qu'on a appris ce mois-ci qui change nos priorités ?). Pas de rapport — une conversation. La réunion se termine avec "la décision du mois" : une chose concrète qu'on change dans notre approche.
Revue des OKRs du trimestre. Ce qui a bien marché, ce qui n'a pas marché, ce qu'on ne referait pas. Planification des OKRs du trimestre suivant. Optionnel : format offsite (hors bureau) pour créer une rupture mentale avec l'opérationnel quotidien.
Les anti-patterns les plus fréquents dans les startups de cette taille : "on se verra demain pour en parler" sans date confirmée = décision jamais prise. "Slacke-moi ça" pour une décision complexe = responsabilité diluée. "On verra ça en retro" pour un problème urgent = blessure qui s'infecte. La culture de communication d'une startup se crée dans les 6 premiers mois — les mauvaises habitudes prises tôt survivent à la croissance.