PRD (Product Requirement Document) : le guide complet et template

Le PRD fait partie de ces documents que beaucoup d'équipes utilisent mal, mais qui restent malgré tout utiles quand ils sont pris pour ce qu'ils sont vraiment.

J'ai vu des PRD écrits beaucoup trop tôt, alors que le problème était encore mal posé. J'en ai vu d'autres arriver beaucoup trop tard, quand les grandes décisions étaient déjà prises de manière implicite. Et j'en ai vu beaucoup devenir des documents longs, plutôt bien présentés, que presque personne ne relisait ensuite.

Le problème, dans tous ces cas-là, n'est pas le format.

Le problème, c'est qu'on demande souvent au PRD de faire autre chose que ce pour quoi il est utile.

Ce qu'un PRD est censé faire

Pour moi, la fonction principale d'un PRD n'est pas de "documenter".

Sa fonction principale est d'aligner.

• sur le problème que l'on traite
• sur la raison pour laquelle on le traite maintenant
• sur ce que l'on cherche à obtenir
• sur le périmètre que l'on accepte
• et sur les principales inconnues qu'il reste à réduire

Vu comme ça, le PRD n'est ni un backlog, ni une spec technique, ni un business case.

Il se situe à un endroit intermédiaire : entre la réflexion stratégique et l'exécution concrète.

Ce que le PRD ne doit pas devenir

Il y a deux dérives que j'essaierais d'éviter.

La première, c'est le PRD-fossile : un document très complet en apparence, mais qui fige trop tôt une solution qui devrait encore évoluer.

La seconde, c'est le PRD-vitrine : un document qui cherche à montrer qu'on a bien travaillé, plus qu'à aider l'équipe à mieux penser et mieux exécuter.

Dans les deux cas, on produit de la forme sans créer beaucoup plus de clarté.

Les sections que je trouve vraiment utiles

Je ne crois pas beaucoup aux templates universels, mais il y a un certain nombre de blocs qui me semblent régulièrement utiles.

1. Un résumé lisible

Une page, ou presque.

Pas pour simplifier abusivement, mais parce qu'en pratique beaucoup de personnes ne liront pas le document en entier. Si le coeur du sujet n'est pas compréhensible rapidement, le PRD risque de perdre une grande partie de sa valeur d'alignement.

• En une phrase: quel problème résolvons-nous et pour qui ?
• Quel est l’impact mesurable attendu (ordre de grandeur) ?
• Quel est le pari principal (hypothèse critique) ?
• Quelle est la fenêtre de temps et le niveau d’effort (~T-shirt size) ?
• Quels sont les 2–3 risques majeurs à surveiller ?

2. Le problème et son contexte

À mes yeux, c'est la section la plus importante.

Avant de parler de solution, il faut pouvoir expliquer ce qui ne fonctionne pas aujourd'hui, pour qui, avec quels éléments de preuve et pourquoi ce problème mérite une attention maintenant.

Un PRD qui saute cette étape commence déjà à glisser vers une logique de livraison plus que de résolution. Cette section doit être factuelle, concise et centrée sur l’utilisateur. ⚠️ Attention aux pièges de suivre une tendance par mimétisme (“les concurrents le font”), sans données solides.

3. Le lien avec la direction

Pourquoi cette initiative existe-t-elle dans l'ensemble plus large de la stratégie ?

Ce point est souvent traité en une phrase très générique, alors qu'il mérite mieux. Relier explicitement le sujet à une priorité produit ou business évite de traiter le PRD comme une pièce isolée. On évite les phrases de type “On fait ça car c’est innovant.” mais plutôt “Cette initiative soutient notre vision d’efficacité client en automatisant X, en ligne avec notre objectif stratégique Y.

4. Les objectifs et indicateurs

Ici aussi, j'essaierais de rester sobre.

Quelques objectifs clairs, quelques indicateurs bien choisis, une baseline si possible, une cible si elle a du sens. Pas besoin d'en faire trop. En gros, Quels sont les objectifs business ? Quels résultats concrets attend-on côté utilisateur ? Comment allons-nous les mesurer ? Quel est le délai réaliste pour observer l’impact ?

Le point important est surtout de ne pas confondre un objectif avec une fonctionnalité livrée. Je recommande de se limiter à 2 ou 3 indicateurs clés, avec une baseline (état actuel) et une cible (objectif mesuré).

5. Les utilisateurs et scénarios

Cette partie sert à rappeler pour qui l'on construit et dans quel contexte d'usage.

Je trouve ça particulièrement utile pour éviter que le document soit aspiré uniquement par la logique interne de l'équipe. Sans utilisateur concret, on peut très vite écrire un PRD parfaitement cohérent qui ne protège de rien.

Les questions

• Quels sont les personas ciblés ?
• Quels sont leurs jobs-to-be-done, leurs contraintes et les besoins ?
• Quels sont dans quelles situations interagiront-ils avec votre produit ? Que cherchent-ils à accomplir ?
• Quels problèmes, s’ils sont résolus, génèrent la plus grande valeur ?
• Quels handicaps/accessibilité à considérer (A11y) ?

Tout ça pour créer une solution ancrée dans le réel et non dans une vision abstraite ou biaisée. Utilisez les interviews, sondages ou encore les analytics. Construisez l’empathie sur des preuves, pas sur des suppositions.

6. Le périmètre, y compris ce que l'on ne fait pas

La partie "hors périmètre" est souvent sous-estimée, alors qu'elle fait une grande différence.

Un projet sans bords nets dérive presque toujours.

• In scope : ce qui est inclus dans ce projet (fonctionnalités, parcours, cas d’usage).
• Out of scope : ce qui est explicitement exclu (même si intéressant).
• Qu’est-ce qui peut être repoussé sans tuer la valeur ?
• Y a-t-il des dépendances qui conditionnent la faisabilité ou le timing ?

Dire explicitement ce qui n'est pas pris en charge maintenant, ce n'est pas renoncer. C'est protéger la qualité des choix du moment.

7. Les grandes fonctionnalités ou solutions envisagées

Ici, j'éviterais de tomber dans la micro-spécification. Le PRD n'a pas besoin de tout contenir. Il doit plutôt décrire la logique de la solution, les grands blocs, les points sensibles, et les hypothèses encore à valider.

8. Les contraintes, dépendances et risques

Cette partie me semble souvent plus importante que les descriptions de features elles-mêmes.

Parce qu'un projet échoue moins souvent par manque de belles idées que par sous-estimation des contraintes réelles.

• Contraintes techniques, légales, ou liées à des tiers
• Dépendances internes (ex : une API pas encore disponible)
• Quels risques doivent être anticipés et qui en est responsable ?

Chaque dépendance ou risque doit avoir un responsable identifié, et si possible une stratégie pour faire sans. Une sorte de plan B.

9. Les questions ouvertes et les décisions prises

J'aime bien cette section parce qu'elle évite de faire semblant qu'un projet est plus clair qu'il ne l'est.

Un bon PRD peut parfaitement contenir de l'incertitude, à condition qu'elle soit nommée.

Ce qu'un bon PRD change dans une équipe

Quand il est bien fait, un PRD fait surtout trois choses.

Il évite que chacun parte avec sa propre version implicite du problème.

Il rend visibles les hypothèses qui demandent encore du travail.

Et il donne un point de référence commun, suffisamment stable pour aligner, mais pas si rigide qu'il empêche d'apprendre.

Je trouve que c'est cette dernière tension qui compte le plus. Un PRD utile doit être assez structuré pour clarifier, mais assez vivant pour évoluer.

Les erreurs les plus fréquentes

Si je devais résumer les dérives les plus courantes :

• écrire un document trop long pour être réellement utilisé ;
• détailler la solution avant d'avoir bien posé le problème ;
• oublier le lien avec la stratégie ;
• confondre objectifs, moyens et livrables ;
• laisser le document vieillir sans jamais le revisiter.

Au fond, la question n'est pas "faut-il un PRD ?"

La vraie question est plutôt : de quel niveau de clarification partagée a-t-on besoin pour avancer sans malentendus coûteux ?

Dans beaucoup de contextes, le PRD reste une bonne réponse. À condition de le considérer comme un outil d'alignement, pas comme une preuve de sérieux documentaire.

Le template

Le template du PRD est disponible sur Notion et sur Google Drive.