# Product — Patterns validés : Général
> Extrait de la base de connaissance Lead_tech. Voir `knowledge/product/patterns/README.md` pour l'index complet.
---
## 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
---
## Pattern : Produit à cercle restreint — canal primaire externe conservé
- Objectif : calibrer la stratégie produit pour des communautés fermées/invitation-only.
- Contexte : app interne/associative où email/SMS précède l'usage applicatif.
- Quand l'utiliser : produit B2B/intranet/communauté restreinte.
- Quand l'éviter : produits mass-market où l'app doit devenir canal primaire.
### Description
Pour une app invitation-only (B2B/interne/associatif), email/SMS reste le canal d'information principal et fiable ; l'app le complète sans le remplacer.
### Checklist
- KPI de succès alignés sur l'usage réel (consultation/confirmation), pas sur le remplacement du canal primaire.
- Roadmap UX alignée avec une adoption progressive et non exclusive.
- Validé le : 18-04-2026
- Contexte produit : PWA / adoption progressive — RL799_V2
---
## Pattern : Trigger UX basé sur signal métier serveur (`loginCount`)
- Objectif : déclencher les prompts UX via un signal robuste et auditable.
- Contexte : prompts d'installation PWA, notifications, feedback.
- Quand l'utiliser : tout trigger UX nécessitant un critère de maturité utilisateur.
- Quand l'éviter : prompts one-shot purement contextuels de page.
### Description
Pour des prompts significatifs (install PWA, notifications, feedback), privilégier un déclencheur serveur métier (ex: `loginCount`) plutôt que des heuristiques client fragiles (timer/scroll/pages vues).
### Checklist
- Signal incrémenté côté serveur sur événement métier confirmé.
- Règle de déclenchement unique partagée entre plateformes.
- Possibilité de désactiver/ajuster sans dépendre du contexte runtime navigateur.
- Validé le : 18-04-2026
- Contexte produit : PWA / triggers engagement — RL799_V2
---