Un modèle de PRD en Markdown :copiez-le et remplissez-le.

Le modèle

Copiez-le dans un nouveau fichier et remplacez tout ce qui est entre chevrons. Ne supprimez une section que si vous êtes sûr qu’elle ne s’applique pas, et écrivez « none » plutôt que de la laisser vide, pour qu’un lecteur voie qu’elle a été envisagée.

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

Pourquoi il est écrit ainsi

Un PRD pour un agent IA a le même rôle que pour une personne, avec moins de place pour deviner. Une personne vous demande dans le couloir ce que vous vouliez dire. Un agent comble le vide avec sa meilleure hypothèse et continue.

• Le hors périmètre est la protection la moins chère contre la dérive du périmètre. Les agents ajoutent des extras « utiles » si on ne leur dit pas de s’en abstenir.
• Les exigences numérotées (R1, R2) permettent à un plan, à un test et à un commentaire de revue de désigner la même chose.
• Les critères d’acceptation en cases de liste de tâches deviennent une liste à cocher. Voir les listes de tâches Markdown pour la syntaxe.
• Les cas limites sont l’endroit où le code généré échoue en premier : données vides, saisie invalide, connexion perdue.
• Le retour arrière vous oblige à réfléchir à la façon d’annuler le changement avant de le livrer.

Comment le remplir

1. Écrivez le problème sans la solution

   Si vous ne pouvez pas décrire le problème sans nommer une fonctionnalité, la fonctionnalité est une supposition. Dites qui est concerné et ce qui se passe aujourd’hui.

2. Rendez chaque objectif mesurable

   « Un paiement plus rapide » est un souhait. « Paiement médian en moins de 30 secondes » est un objectif.

3. Écrivez les exigences comme des comportements

   « Le système doit afficher une erreur quand le fichier dépasse 10 Mo » se teste. « Une bonne gestion des erreurs » non.

4. Associez un critère à chaque exigence

   Utilisez Given, when, then. Si vous ne pouvez pas écrire la vérification, l’exigence est floue.

5. Terminez par les questions ouvertes

   Nommez le responsable de chacune. Un agent doit les poser, pas les trancher.

Les diagrammes aident pour les flux et les états ; un bloc Mermaid dans le fichier se modifie facilement. Voir la syntaxe des diagrammes de flux Mermaid.

Confier le PRD à un agent IA

Indiquez le fichier à l’agent plutôt que de le coller : « Lis docs/prd/export.md et propose un plan ; n’écris pas encore de code. » Demandez d’abord un plan, vérifiez-le par rapport aux exigences numérotées, puis laissez-le construire. Un PRD, un plan et une liste de tâches sont en général trois fichiers distincts. Le PRD dit quoi et pourquoi, le plan dit comment, et les tâches sont les étapes.

Gardez les règles valables pour tout le projet (commandes, style, dossiers) hors du PRD, dans CLAUDE.md ou AGENTS.md, pour que le PRD ne contienne que ce qui est propre à cette fonctionnalité.

Erreurs courantes

• Une solution déguisée en problème. « Il nous faut un menu déroulant » n’est pas un problème.
• Pas de hors périmètre. Tout ce qui est proche entre dans le périmètre.
• Des exigences qui ne peuvent pas échouer. Si aucun test ne pourrait jamais la mettre en défaut, elle ne dit rien.
• Un PRD que personne ne relit. Mettez à jour le statut et les questions ouvertes au fil de l’eau.
• Dix pages pour un petit changement. Une fonctionnalité d’une journée demande une demi-page.

Les chefs de produit peuvent lire et relire les PRD dans DotMD comme des documents mis en forme, avec des commentaires sur le passage exact. La lecture est gratuite ; voir les tarifs pour l’édition et les revues.

Questions sur les modèles de PRD en Markdown

Plus de questions