Product Requirements Document (PRD)

Planification

Delivery

Prise de décision

Cadrez votre produit avant de coder. Le PRD aligne product, design et ingénierie sur le quoi et le périmètre avant que la première ressource soit engagée.

Description

Le product requirements document (PRD) est un document structuré qui formalise ce qu'un produit doit accomplir : son objectif, ses fonctionnalités prioritaires et ses critères de succès mesurables. Sa finalité est d'aligner product, design et ingénierie sur un périmètre commun avant que la première ressource soit engagée. Sans PRD, chaque membre de l'équipe travaille sur sa version mentale du produit. Le designer imagine une chose, le développeur code autre chose, et le PM découvre l'écart lors de la démo. Comme un permis de construire qui fixe les limites du chantier avant que les ouvriers arrivent, le PRD transforme une idée floue en décision documentée que tout le monde peut relire six semaines plus tard. Cette comparaison n'est pas anodine : de même que personne ne commencerait à poser des fondations sans permis validé, lancer un cycle de développement sans product requirements document revient à construire à l'aveugle. Marty Cagan, qui a formalisé la pratique au sein du Silicon Valley Product Group, résumait l'enjeu en une formule précise : le PRD doit décrire le quoi, jamais le comment. L'équipe d'ingénierie garde l'autonomie sur les solutions techniques ; l'équipe produit reste propriétaire des objectifs et des contraintes. Un PRD rigoureux inclut aussi une section "non-goals" : la liste explicite de ce que le produit ne fera pas dans cette itération, aussi critique que le scope inclus pour prévenir la dérive de périmètre. Selon les travaux classiques du génie logiciel, corriger une erreur de spécification en production coûte jusqu'à cent fois plus cher qu'en phase de planification. Ce seul chiffre justifie d'investir quelques heures dans un product requirements document structuré avant de lancer le développement.

Objectifs

Structurer le développement
Améliorer la collaboration d'équipe
Assurer l'alignement stratégique
Assurer l'alignement stratégique

Utilisé par

-Google (le product requirements document est un standard de documentation interne, décrit par de nombreux anciens PMs dans des articles et témoignages publics)
-Meta (utilise des product specs proches du PRD pour cadrer le développement des nouvelles fonctionnalités sur Facebook et Instagram)

Avantages

Alignement avant développement. Un seul document partagé élimine les versions mentales divergentes et réduit les allers-retours de clarification pendant les sprints.
Réduction du rework. Les erreurs de spécification détectées avant le développement coûtent une fraction du coût de correction en production.
Décisions défendables. Quand un stakeholder demande "pourquoi cette feature n'est pas dans le scope ?", le PRD répond à sa place et évite les débats d'opinion répétés.
Accélère l'onboarding. Un nouveau membre de l'équipe ou un prestataire externe comprend le contexte du produit en lisant le PRD, sans dépendre de transmissions orales.

Limites

Risque de sur-documentation. Un PRD trop exhaustif devient un document waterfall déguisé. Gardez-le court, actionnable, et centré sur le quoi. Si votre PRD dépasse 10 pages, découpez le scope.
Moins adapté à l'exploration pure. Pour un problème que vous ne comprenez pas encore, un PRD prématuré fige des décisions sans base empirique. Préférez un Opportunity Solution Tree ou une phase de discovery avant de rédiger.
Demande une discipline de mise à jour. Un PRD non maintenu devient trompeur. Si l'équipe ne le consulte plus parce qu'il est obsolète, il fait plus de mal que de bien.
Efficace uniquement si les parties prenantes le lisent vraiment. Partager un PRD ne garantit pas l'alignement. Exigez des retours écrits explicites pour confirmer que chaque section a été lue et comprise.

Comment appliquer Product Requirements Document (PRD)

1
Définir le problème et le contexte
Formulez le problème utilisateur en une ou deux phrases. Précisez pourquoi le résoudre est prioritaire maintenant, et quel contexte business ou marché rend ce sujet urgent. Output : énoncé du problème validé par les parties prenantes.
2
Identifier les utilisateurs cibles et leurs besoins
Listez les segments d'utilisateurs concernés par cette fonctionnalité ou ce produit. Pour chaque segment, formalisez le besoin principal et les comportements actuels qui confirment l'existence du problème. Output : 1 à 3 profils utilisateurs avec leur besoin documenté.
3
Formuler l'objectif et les métriques de succès
Rédigez l'objectif du PRD en une phrase : "Ce produit/feature permettra à [utilisateur cible] de [action] afin de [résultat attendu]." Puis définissez 2 à 4 métriques mesurables qui confirmeront que l'objectif est atteint (taux d'adoption, réduction du temps de traitement, NPS, etc.). Output : objectif validé et métriques de succès avec seuils.
4
Rédiger le scope : fonctionnalités incluses
Listez les fonctionnalités qui seront développées dans cette itération. Pour chaque fonctionnalité, rédigez une description courte (1 à 3 phrases) centrée sur l'expérience utilisateur, pas sur l'implémentation technique. Restez au niveau du "quoi", pas du "comment". Output : liste de fonctionnalités incluses avec description utilisateur.
5
Définir les non-goals (hors-scope explicite)
C'est la section la plus sous-estimée du product requirements document. Listez explicitement ce que ce cycle de développement ne fera pas. Cette liste prévient les demandes de dernière minute et aligne les attentes avant le démarrage. Un bon non-goal est formulé comme une décision assumée, pas comme un oubli. Output : liste de 3 à 7 non-goals validés par l'équipe.
6
Documenter les hypothèses et les contraintes
Identifiez les hypothèses sur lesquelles reposent vos décisions produit (comportement utilisateur supposé, capacité technique, adoption estimée). Listez également les contraintes non négociables : délais, dépendances techniques, contraintes réglementaires ou budgétaires. Output : journal d'hypothèses et liste de contraintes documentées.
7
Rédiger les critères d'acceptation
Pour chaque fonctionnalité incluse dans le scope, définissez les critères d'acceptation : les conditions mesurables et vérifiables qui permettront à l'équipe de confirmer qu'une fonctionnalité est correctement implémentée. Ces critères évitent les débats subjectifs lors de la validation. Output : critères d'acceptation rédigés pour chaque fonctionnalité.
8
Faire valider le PRD par les parties prenantes
Partagez le PRD avec engineering, design, data, et toute partie prenante clé avant de lancer le développement. Demandez des retours écrits. Si un lecteur a besoin d'explications orales pour comprendre une section, cette section n'est pas assez claire : récrivez-la. Output : PRD annoté et validé avec une liste des désaccords résolus.
9
Maintenir le PRD comme référence pendant le développement
Le PRD n'est pas un document figé signé et oublié. Mettez-le à jour si le contexte change, si une hypothèse est invalidée ou si une fonctionnalité est redéfinie en cours de sprint. Documentez chaque modification avec une date et une justification. Output : PRD versionné qui sert de boussole pendant tout le cycle de développement.