# Patterns produit / métier validés Ce fichier contient des patterns de **cadrage produit, priorisation et analyse fonctionnelle** : - observés en conditions réelles, - validés sur des projets livrés, - utiles à réutiliser sur d'autres produits. Objectif : éviter de redélibérer sur des sujets déjà tranchés, capitaliser ce qui fonctionne du point de vue product management et analyse métier. Dernière mise à jour : 2026-03-20 --- ## Index - [Epic UI Fondation — prérequis bloquant avant Epic 1](#pattern-epic-ui-fondation) - [Progression V1 sans module dédié — calcul depuis la source de vérité](#pattern-progression-v1-sans-module) --- ## Règle d'or Si ce n'est pas **validé par l'expérience projet**, ça n'a pas sa place ici. - Pas de frameworks théoriques génériques (pas de "appliquer le RICE scoring" sans contexte) - Toujours préciser le contexte (type de produit, taille d'équipe, stade du projet) --- ## Périmètre couvert - Patterns de cadrage et découverte (discovery) - Priorisation et arbitrages (backlog, roadmap) - Gestion des exigences et user stories - Patterns d'analyse fonctionnelle récurrents - Décisions produit structurantes validées - Anti-patterns de pilotage produit (dans ce fichier ou dans un fichier dédié) --- ## Format standard d'un pattern ## Pattern : - Objectif : … - Contexte : … - Quand l'utiliser : … - Quand l'éviter : … - Avantage : … - Limites / vigilance : … - Validé le : DD-MM-YYYY - Contexte produit : (obligatoire) ex. `SaaS B2B / early-stage` ou `App mobile / feature mature` ### Description (comportement attendu, logique de décision, règles d'application) ### Checklist (si pertinente) --- ## Pattern : Epic UI Fondation — prérequis bloquant avant Epic 1 - Objectif : éviter les régressions et la dette de migration générées par l'insertion tardive d'un epic de fondation UI. - Contexte : app mobile ou SPA avec un design system à créer (design tokens + composants primitifs). - Quand l'utiliser : dès qu'un epic design tokens / composants de base existe dans la roadmap. - Quand l'éviter : si le design ad-hoc est un choix délibéré assumé (prototype jetable, MVP ultra-contraint). - Avantage : - les screens livrés ultérieurement utilisent d'emblée les bons tokens et composants - pas de double système d'espacement ni de migration de composants partagés en cours de route - les composants primitifs (Button, FilterChip...) sont stables avant d'être utilisés partout - Limites / vigilance : - si l'insertion tardive est inévitable, prévoir une story de smoke test explicite sur tous les parcours critiques refactorisés - Validé le : 19-03-2026 - Contexte produit : App mobile / early stage — app-alexandrie rétrospective Epic 0 ### Description Un Epic "UI Fondation" inséré après Epic 1 (ou plus tard) génère trois risques spécifiques : 1. **Régression sur screens livrés** : les fichiers refactorisés avaient déjà une logique métier validée — toute modification structurelle rouvre un risque de régression. 2. **Composants partagés modifiés** : migrer `Button`, `FilterChip` de `TouchableOpacity` vers `Pressable` après utilisation partout est un breaking change API silencieux. 3. **Double système de tokens** : les screens livrés avaient adopté les anciennes constantes — la migration est une dette qui s'accumule à chaque epic. **Règle** : L'Epic UI Fondation (tokens + composants primitifs) est un **prérequis bloquant de Epic 1**. Il doit être fait en tout premier, avant toute logique métier — ou ne pas être fait du tout (accepter le design ad-hoc). ### Checklist (insertion tardive inévitable) - [ ] Story de smoke test explicite sur tous les parcours critiques touchés - [ ] Grep systématique des usages des composants modifiés avant merge - [ ] Vérification que l'ancien système de tokens est entièrement purgé (`grep from '@/constants/theme'`) --- ## Pattern : Progression V1 sans module dédié — calcul depuis la source de vérité - Objectif : exposer une feature de progression/gamification sans créer prématurément un domaine `achievements` ou `analytics`. - Contexte : produit early-stage avec une source de vérité existante (`content`, `billing`, `posts`...) et un besoin de progression MVP. - Quand l'utiliser : première itération d'une feature de progression, objectifs, stats utilisateur. - Quand l'éviter : si les compteurs sont déjà complexes, multi-sources ou nécessitent une persistance d'état (ex : streaks, badges conditionnels). - Avantage : - zéro scope creep — pas de tables `achievements` ni de service dédié en avance de phase - logique explicite et testable en code, pas en DB - couture propre vers un module `achievements` réel si le besoin se confirme - Limites / vigilance : - ne convient pas si les calculs de période sont coûteux à chaque appel — à surveiller sur le volume - la couture vers les sources futures doit être prévue dès le départ (pas de calcul hardcodé sur une seule table) - Validé le : 10-03-2026 - Contexte produit : App mobile / early stage — app-alexandrie ### Description Plutôt que d'ouvrir un domaine `achievements` ou `analytics` dès la V1 : 1. **Garder l'agrégat dans le domaine métier source de vérité** (`content`, `billing`, etc.) 2. **Calculer les compteurs de période** (`thisWeek`, `thisMonth`) directement en base via `count` / agrégations filtrées 3. **Centraliser le catalogue d'objectifs en code** — explicite, versionné, testable 4. **Prévoir des coutures zéro-safe** pour les sources futures (`contributions`, `posts`...) sans inventer les tables en avance ### Checklist - [ ] Aucune table `achievements` / `progress` créée sans besoin confirmé - [ ] Compteurs calculés depuis la source de vérité existante - [ ] Catalogue d'objectifs en code (pas en DB) - [ ] Interface de sortie stable même si les sources de données évoluent ---