PRD : le document à donner à Claude Code avant de coder
Le PRD (product requirements document) définit précisément ce que vous développez, pour quel public, ainsi que ce qui demeure exclu du périmètre. Sur un projet client, c’est aussi ce qui empêche Claude Code de combler chaque vide en devinant, et votre client de recevoir à la livraison une application qu’il n’avait pas demandée. Voici le contenu d’un PRD rédigé pour Claude Code, un exemple portant sur un vrai type de projet, ainsi que les deux documents qui en découlent : le design et le plan.
Pourquoi Claude Code a besoin d’un PRD
Donnez à Claude Code « une appli de réservation pour une salle de sport », et il décidera seul de 30 choses : les comptes, les paiements, l’annulation, les notifications, l’écran d’accueil. Chaque décision est raisonnable. La moitié ne correspond pas à ce que le client avait en tête.
Le modèle ne lit que ce que vous lui donnez. Un prompt de 3 lignes laisse tout le reste à deviner, et un agent qui code devine vite, avec assurance.
Le PRD retire ces suppositions avant la première ligne. Il vit dans docs/PRD.md, versionné avec le code. Une ligne dans le CLAUDE.md du projet suffit pour que Claude Code le relise à chaque session.
Ce que contient un PRD écrit pour Claude Code
Les modèles des chefs de produit vont de 6 à 15 sections. Pour un projet client codé avec l’IA, 8 suffisent :
| Section | Ce qu’elle fixe |
|---|---|
| Problème | ce que vit le client aujourd’hui, et pourquoi maintenant |
| Solution | ce que le produit lui permet de faire, vu de l’utilisateur |
| Utilisateur cible | une personne réelle et son contexte d’usage |
| User stories | numérotées, avec les états vides, les erreurs, les cas limites |
| Critères de succès | des faits vérifiables : un clic, un mail reçu, une durée |
| Hors périmètre | ce qu’on refuse, noir sur blanc |
| Décisions d’implémentation | ce que l’utilisateur voit : limites chiffrées, formats, messages d’erreur |
| Notes | risques, dépendances, hypothèses |
Deux règles changent tout face à un agent. Les critères de succès doivent se vérifier sans interpréter : « le membre reçoit un mail de confirmation en moins d’une minute », pas « le membre comprend sa réservation ». Et le PRD ne nomme aucune techno : il dit ce que l’utilisateur observe, Claude Code choisit comment.
Un exemple de PRD sur un projet client
Prenons un studio de yoga avec 2 salles et 400 membres, qui réserve aujourd’hui ses cours par SMS. Extrait de son PRD :
## Problème
La gérante répond à 60 SMS de réservation par semaine, le soir.
Deux cours sur dix ont des places vides parce qu’une annulation
n’a pas été vue à temps.
## Critères de succès
1. Un membre réserve un cours en 3 écrans au plus depuis son téléphone.
2. Une annulation libère la place et prévient le premier de la liste d’attente par mail.
3. La gérante voit le remplissage de la semaine sur un seul écran.
## Hors périmètre
- Paiement en ligne (les membres paient à l’accueil).
- Application mobile native.
- Gestion des salaires des professeurs.
- Plusieurs langues.
Lisez la dernière section deux fois. C’est elle qui travaille le plus.
Le hors périmètre arrête les demandes en plus
Trois semaines après le début du projet, la gérante demande « juste » le paiement en ligne. Sans PRD, Claude Code l’ajoute en une après-midi, et vous voilà avec Stripe, des remboursements et un litige à gérer, pour le même prix.
Avec un PRD, la demande se pose sur la table : elle est écrite hors périmètre, signée au cadrage. Vous pouvez dire oui, mais c’est une deuxième phase, chiffrée à part. Le document vous protège, et il protège aussi le client d’un projet qui ne finit jamais.
Côté agent, l’effet est le même. Quand Claude Code hésite à ajouter une fonction « utile », la liste lui répond.
Le deuxième document : le design
Le PRD dit quoi construire. Il ne dit rien de l’allure. Sans consigne, Claude Code prend ses réglages par défaut, et l’interface ressemble à celle de tout le monde.
Le DESIGN.md fixe la typo, les couleurs, les espacements et la mise en page avant la première ligne de code. Il s’accompagne d’un aperçu HTML : un spécimen de typo, la palette et un écran type, que vous montrez au client avant de coder. Il valide un fichier, pas une application à moitié faite.
Le détail de cette étape, et ce qu’elle change au rendu, est dans l’article sur Claude Code et le design.
Le troisième document : le plan
C’est celui qui évite de tout refaire. Le PLAN.md découpe le PRD en phases, chacune testable de bout en bout : une phase traverse tout (données, écrans, tests) sur un chemin étroit, au lieu de construire toute la base, puis toutes les pages, puis tout le reste.
Pour le studio de yoga, la phase 1 peut être : un membre voit le planning et réserve un cours. Rien d’autre, mais du clic au mail de confirmation. Vous la montrez au client le 3e jour, et une erreur de compréhension coûte une phase, pas le projet.
Chaque phase reprend les numéros des user stories du PRD. Vous savez à tout moment ce qui est couvert, et Claude Code aussi.
Les faire rédiger par un skill
Vous n’écrivez aucun des trois à la main. Un skill Claude par document s’en charge : il lit le dépôt, vous pose ses questions une à une avec sa recommandation, vous validez section par section, et il écrit le fichier dans docs/.
L’ordre compte :
- le PRD, qui part du problème du client ;
- le design, qui s’appuie sur l’utilisateur cible du PRD ;
- le plan, qui découpe les user stories du PRD.
Ensuite, vous demandez à Claude Code de coder la phase 1 du plan, et il n’a plus rien à deviner. Pour la prise en main de l’outil lui-même, voyez le guide Claude Code.
Ce que vous pouvez vendre avec ça
Le cadrage trouve preneur à lui seul, avant même le développement. Pour qui : une PME de 5 à 50 personnes ayant un outil en tête (réservation, suivi de chantier, portail client) sans cahier des charges, comme un studio, un cabinet d’architectes ou un artisan avec 3 équipes.
Voici ce que vous livrez, en une semaine : le PRD, le design avec son aperçu, et le plan en phases. Trois fichiers que le client conserve, même s’il ne vous confie pas la suite.
Comment le présenter : « On définit en sept jours ce que l’outil réalise, son apparence et l’ordre de construction. Vous approuvez l’aperçu avant toute ligne de code. » Quand un client a approuvé l’aperçu ainsi que le plan, il visualise déjà son outil : la discussion sur la phase 1 démarre de cette base concrète plutôt que de zéro.