prd-table-ronde

Files (15)

• SKILL.md
• design-system.css · assets/
• diagrams.md · references/
• dor-dod.md · references/
• estimation.md · references/
• gates.md · references/
• hypotheses.md · references/
• metrics.md · references/
• personas.md · references/
• pillar-files.md · references/
• reentry.md · references/
• security-lens.md · references/
• spec-json.md · references/
• traceability.md · references/
• skill.json

SKILL.md (first lines)

# PRD Table Ronde V2.2

## Mission
Transformer un brief, même incomplet, en décisions explicites puis en PRD exploitable par un humain ou un agent IA. La table ronde sert à révéler contraintes et désaccords, pas à simuler une réunion. La profondeur reste proportionnelle au risque et à la complexité. La V2.2 ajoute la couche « extrême » : savoir dire non (gate GO/NO-GO), savoir qui tranche (DACI), tuer les hypothèses avant le MVP, estimer en fourchettes, instrumenter les métriques, et transmettre aux agents en JSON. Chaque mécanisme reste conditionné au niveau : rien d'automatique, tout ce qui ne change pas une décision est retiré.

## Principes
1. **Comprendre avant de choisir.** Identifier problème, utilisateurs, contraintes et inconnues avant de figer une solution.
2. **Dimensionner, ne pas empiler.** Utiliser la plus petite table ronde capable de couvrir les perspectives qui peuvent modifier une décision.
3. **Deux users lambda.** Ajouter un regard novice/non-tech et un regard pragmatique/pressé.
4. **Séparer certitude et supposition.** Toute décision structurante porte un statut de confiance.
5. **Red Team courte.** Trois questions fixes après les arbitrages, sans persona supplémentaire.
6. **Traçabilité utile.** Relier décisions, stories et critères; étendre vers REQ/tests seulement lorsque le niveau de profondeur le justifie.
7. **Mesurable.** Éviter « rapide », « sécurisé », « intuitif » sans cible, comportement observable ou vérification.
8. **Sortie découplée.** Le contenu du PRD ne dépend pas du HTML.
9. **Préférences séparées.** Branding, signature et conventions stylistiques personnelles ne font pas partie du moteur générique.
10. **Savoir dire non.** Après les arbitrages, un gate GO/PIVOT/NO-GO explicite. Un NO-GO tracé est un succès du processus.
11. **Savoir qui tranche.** Chaque décision structurante nomme un Approver unique (DACI light) avec un délai de tranche.
12. **Les hypothèses meurent ou sont testées.** Toute hypothèse à risque élevé porte une expérience d'invalidation bon marché avant le MVP, ou devient un critère de kill.

## Ressources
Lire selon le besoin:
- `references/personas.md`: dimensionnement, fusion des regards et rôles.
- `references/traceability.md`: statuts, Decision Log et traçabilité.
- `references/pillar-files.md`: continuité pour agents, uniquement si demandée/pertinente.
- `references/diagrams.md`: patrons Mermaid, uniquement quand un diagramme clarifie réellement.
- `references/gates.md`: gate GO/NO-GO et DACI (phase 4).
- `references/hypotheses.md`: registre d'hypothèses et invalidation (phases 1 et 4).
- `references/estimation.md`: estimation en fourchettes des lots (phase 8).
- `references/metrics.md`: arbre de métriques et instrumentation (phases 5-6).
- `references/dor-dod.md`: Definition of Ready / Done (phases 6 et 8).
- `references/spec-json.md`: manifeste machine pour agents (phase 9).
- `references/reentry.md`: protocole de révision du PRD (après livraison).
- `references/security-lens.md`: 3 questions sécurité à chaque phase.
- `assets/design-system.css`: uniquement pour une livraison HTML.

## Niveau de profondeur unique
Le déterminer **une seule fois au cadrage**, puis le réutiliser dans les phases suivantes. Ne pas recalculer une autre notion de complexité phase par phase.

- **LÉGER**: périmètre réduit, peu d'acteurs/intégrations, faible criticité, données peu sensibles, contraintes simples.
- **STANDARD**: produit client ou métier avec plusieurs rôles/intégrations et risques ordinaires nécessitant des arbitrages explicites.
- **RENFORCÉ**: paiement, données sensibles, forte criticité/exploitation, réglementation, nombreuses dépendances/équipes ou conséquences importantes en cas d'erreur.

L'ampleur seule ne décide pas du niveau: un petit outil interne sensible peut être RENFORCÉ. Le niveau pilote la taille de la table ronde, la profondeur de traçabilité, l'analyse architecture/sécurité et le détail de livraison. L'utilisateur peut imposer un niveau.

## Workflow en 9 phases

### 1 · Cadrage
Extraire objectif, utilisateurs, problème, contexte, contraintes, existant, budget/délai si connus, données sensibles, intégrations et définition du succès. Poser seulement les questions pouvant changer une décision. Si l'utilisateur veut avancer, continuer en signalant les hypothèses.

Déterminer ici le niveau `LÉGER`, `STANDARD` ou `RENFORCÉ` et le conserver pour tout le workflow.

Ouvrir le registre d'hypothèses (`references/hypotheses.md`) : lister les hypothèses structurantes avec leur statut initial. Les plus risquées devront porter une expérience d'invalidation avant le MVP.

Appliquer la lentille sécurité (`references/security-lens.md`) : inventorier dès ici les données sensibles ; elles influencent le niveau et la composition de la table ronde.

Pour les informations structurantes, utiliser au besoin `[CONFIRMÉ]`, `[HYPOTHÈSE]`, `[À VALIDER]`, `[BLOQUANT]` selon `references/traceability.md`.

### 2 · Table ronde dimensionnée
Appliquer le niveau retenu en phase 1 et `references/personas.md`. Les bandes numériques comptent les **personas/regards finaux affichés après regroupement**, users lambda compris:
- **LÉGER**: 8 à 10;
- **STANDARD**: 11 à 14;
- **RENFORCÉ**: 15 à 18, jusqu'à 20 seulement si réglementation/complexité exceptionnelle justifie chaque regard supplémentaire.

Couvrir les perspectives nécessaires avec le minimum de personas utile. Un persona peut porter plusieurs perspectives cohérentes; ne jamais fusionner deux regards lorsque l'un doit pouvoir contredire l'autre pour faire émerger une tension utile. Rendre toute fusion explicite dans le tableau, par exemple `Décideur — également utilisateur principal`.

### 3 · Débat et synthèse
Pour chaque regard utile: préoccupation, attentes, risque et compromis acceptable. Faire ressortir 3 à 7 tensions réelles (`A vs B`) puis synthétiser sans faux consensus. Préférer un tableau compact aux monologues.

### 4 · Arbitrages + Red Team
Transformer les tensions importantes en décisions `DEC-001...`. Pour chacune: contexte, options si nécessaires, décision, raison, contrepartie, statut de confiance et condition de révision. Nommer le DACI de chaque décision structurante (Approver unique + délai de tranche, voir `references/gates.md`).

Lister les **options écartées** : acheter au lieu de construire, outil existant, prototype jetable, ne rien faire. Pour chacune : pourquoi écartée, à quel coût. Une option jamais examinée n'est pas un arbitrage.

Appliquer ensuite les trois questions Red Team de `references/personas.md`. Si une réponse révèle un problème critique, corriger les arbitrages avant de poursuivre.

**Gate GO / PIVOT / NO-GO** (`references/gates.md`). La table ronde se prononce explicitement avant de produire le PRD. En cas de NO-GO, livrer la note d'arrêt d'une page au lieu du PRD.

### 5 · PRD
Produire un PRD proportionné au niveau retenu: vision/problème/résultat utilisateur; objectifs et non-objectifs; MVP/plus tard/hors scope; acteurs utiles; parcours critiques; fonctionnalités/règles métier; rôles/permissions; données/dépendances/intégrations; exigences non fonctionnelles pertinentes; métriques et risques majeurs. Ne pas créer de sections vides pour satisfaire un gabarit.

Construire l'arbre de métriques (`references/metrics.md`) : une north star, 2-4 métriques d'entrée, 1-3 garde-fous. Chaque métrique : définition, cible chiffrée, horizon, source. Pas de métrique sans moyen de mesure.

### 6 · User stories, acceptation et traçabilité
Créer les stories importantes `US-001...`, reliées aux décisions qui les motivent, puis des critères observables `AC-...`. Utiliser Given/When/Then seulement s'il clarifie permissions, erreurs, workflow, états ou règles métier; une checklist concise suffit sinon.

Appliquer le niveau de phase 1:
- **LÉGER / STANDARD**: chaîne minimale `DEC -> US -> AC`, sauf besoin explicite supérieur;
- **RENFORCÉ**: étendre lorsque utile vers `Besoin/Risque -> DEC -> REQ -> US -> AC/Test -> Lot`.

Lier chaque story à ses hypothèses d'origine : `HYP -> DEC -> US -> AC` (voir `references/hypotheses.md`).

Appliquer la Definition of Ready avant d'admettre une story en lot, et la Definition of Done pour clore un lot (`references/dor-dod.md`). Toute US portant une métrique ajoute un AC d'instrumentation (`references/metrics.md`).

Voir `references/traceability.md` sans inventer d'IDs supplémentaires s'ils n'améliorent ni exécution ni vérification.

### 7 · Architecture, sécurité et exploitation
Appliquer le niveau de phase 1. Déduire l'architecture des contraintes et comparer plusieurs options seulement lorsqu'un vrai arbitrage existe. Pour un choix structurant: coût, complexité, compétences, maintenance, sécurité, performance/offline, lock-in et vitesse de livraison. Une matrice pondérée n'est utilisée que si plusieurs options restent réellement disputées après analyse.

Appliquer la lentille sécurité à chaque phase (`references/security-lens.md`), pas seulement ici : données sensibles, surface d'attaque, plan en cas de fuite ou d'abus. Le premier lot vertical inclut toujours le socle sécu (auth, secrets, logs).

Approfondir sécurité, vie privée, sauvegarde, reprise, observabilité et exploitation à proportion du niveau retenu. Produire uniquement les diagrammes qui améliorent la compréhension.

### 8 · Plan d'exécution et continuité
Découper le MVP en lots verticaux livrables avec résultat observable, dépendances, stories couvertes et vérification attendue. Éviter un lot 0 hypertrophié.

Estimer chaque lot en fourchette avec niveau de confiance (`references/estimation.md`) : jamais un chiffre unique. Inclure dev, revue, tests, documentation et déploiement dans chaque lot.

Si l'utilisateur veut démarrer ou transmettre le développement, générer les fichiers utiles selon `references/pillar-files.md` et l'agent cible (`CLAUDE.md`, `AGENTS.md`, etc.). Ne jamais supposer qu'un fichier propre à un agent est universel, ni y placer de secret réel.

### 9 · Contrôle et livraison
Faire une revue qualitative courte: hypothèse présentée comme fait? décision sans statut? story critique orpheline ou sans AC? feature prématurée conservée malgré Red Team? contrainte terrain/sécurité/exploitation oubliée? profondeur cohérente avec le niveau retenu? décision sans Approver nommé? hypothèse à risque sans expérience d'invalidation? lot estimé en chiffre unique?

Corriger les défauts évidents puis livrer, sans score artificiel ni prétention de certification.

Si un agent doit coder à partir de ce PRD (dès STANDARD), générer `spec.json` selon `references/spec-json.md` : le même contenu, structuré par IDs. Le Markdown reste la source de vérité.

Joindre le protocole de ré-entrée (`references/reentry.md`) : quelles phases rejouer quand une hypothèse tombe, un bloquant se lève ou un risque nouveau apparaît.

## Format de livraison

From BlackAngel242/skill-market, MIT.

More from BlackAngel242/skill-market