_Assistant_Lead_Tech/10_product_patterns_valides.md

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
• Progression V1 sans module dédié — calcul depuis la source de vérité

---

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

---