Product requirements document (PRD) : un exemple rempli
Un product requirements document (PRD) se limite à une ou deux pages et expose le pourquoi ainsi que le quoi, en omettant toujours le comment. Ce document, vous le transmettez à votre client avant tout développement : il le consulte seul, l’approuve, et ainsi personne ne réalise trois semaines après qu’il espérait autre chose. Voici un PRD intégral divisé en 8 parties, complété pour un véritable petit produit, ainsi que la méthode permettant à Claude Code de le rédiger grâce au skill /cadre.
Un plan d’architecte pour votre code
Sur un chantier, le maçon, le plombier et l’électricien travaillent depuis le même plan. Pas d’instructions différentes selon la personne à qui vous parlez : un seul document fait foi pour tout le monde.
Le PRD (Product Requirements Document) joue ce rôle pour votre code. L’IA, vous et votre client partent de la même source. Je le range dans un répertoire docs/, qui regroupe tous les documents de référence du projet.
Ce que le PRD dit, et ce qu’il ne dit jamais
Le PRD dit pourquoi vous faites ce produit, pour qui, ce qu’il fait et ce qu’il refuse de faire.
Il ne dit jamais comment. La technologie se choisit plus tard, dans le plan. C’est ce qui le rend stable : il vieillit beaucoup moins vite que le code, et n’importe qui peut le lire. Vous devez pouvoir l’envoyer à un client ou à un associé non technique sans rien expliquer.
Les 8 sections, remplies sur un calculateur de TJM
Le produit de l’exemple : un outil web qui dit à un freelance combien facturer par jour pour atteindre son objectif de revenu. /cadre le pose en 8 sections fixes :
## Problème
Un freelance fixe son TJM au doigt mouillé. Il découvre en fin d’année que ses charges,
ses impôts et ses jours non facturés ont mangé l’objectif qu’il s’était donné.
## Solution
Un calculateur web : le freelance saisit le revenu net qu’il vise, son statut et ses
jours facturables, et obtient le TJM à facturer pour l’atteindre.
## Utilisateur cible
Le freelance qui démarre, en micro-entreprise ou en société, qui facture à la journée.
## User Stories
- US-1 : En tant que freelance, je veux saisir le revenu net que je veux gagner, afin
d’obtenir le TJM que je dois facturer pour l’atteindre.
- US-2 : En tant qu’auto-entrepreneur, je veux être alerté quand mon chiffre d’affaires
dépasse le plafond de la micro-entreprise, afin de comprendre qu’un autre statut est
plus adapté.
## Critères de succès
- Le TJM affiché varie quand on change le statut ou le nombre de jours facturables.
- L’alerte de plafond apparaît dès que le chiffre d’affaires calculé le dépasse.
## Hors périmètre
- Aucun compte utilisateur, aucune sauvegarde en ligne.
- Aucune facturation ni déclaration à l’administration.
## Décisions d’implémentation
- Les taux de charges sont ceux en vigueur pour chaque statut, sourcés et datés.
## Notes complémentaires
- Les taux changent chaque année : leur date de mise à jour s’affiche.
Les deux user stories viennent de la vidéo. J’ai complété le reste pour l’exemple, en gardant une règle : chaque ligne doit se vérifier sans discussion.
Les 3 garde-fous qui font un bon PRD
Les critères de succès se vérifient. Un événement que l’on observe ou une mesure, jamais « l’utilisateur comprend son TJM ». Si un critère ne se teste pas, l’IA ne saura pas si elle a fini.
Le hors périmètre est exhaustif. C’est la section qui protège votre devis : tout ce que vous n’y avez pas exclu finit par être demandé « en passant ».
Les user stories sont numérotées. US-1, US-2 : le plan s’y réfère phase par phase, et vous savez à tout moment ce qui est livré. Le PRD fixe la destination ; le chemin, c’est le travail de /planifie.
Lancer /cadre dans Claude Code
npx skills add naiersaidane/claude-mastery
Puis /cadre ou une phrase : « cadre ce projet ». Le skill vous interroge section par section et écrit docs/PRD.md. Pour un projet complet, il vient après /interroge et avant /planifie : je montre l’enchaînement dans les 6 Claude Code skills, dans l’ordre d’un projet. Et quand un bug arrive malgré le cadrage, la méthode de debug en 4 phases prend le relais.
Ce que vous pouvez vendre avec ça
Votre client, c’est le dirigeant de PME qui vous dit « j’ai une idée d’outil » sans savoir encore ce qu’il veut : un cabinet d’expertise comptable, un artisan avec trois équipes, une agence qui jongle avec ses tableurs.
Vous lui remettez le PRD de deux pages au terme d’une ou deux réunions avec lui. Ce livrable complet, facturé en amont du développement, lui permet de repartir avec un document qu’il pourra transmettre à n’importe quel prestataire.
Pour le présenter : « Avant d’établir un devis pour le développement, je vous soumets deux pages détaillant les fonctions de l’outil, ses destinataires ainsi que ses exclusions. Vous les validez, et mon devis porte exactement là-dessus. » Il voit enfin ce qu’il achète, et votre devis repose sur un périmètre écrit.
