Product requirements document (PRD) : définition et modèle

Un PRD, ou product requirements document — traduit en français par document d’exigences produit — est le document qui décrit ce qu’un produit ou une fonctionnalité doit accomplir, pour quels utilisateurs, et à quelles conditions on le considérera réussi. Il énonce un problème et un résultat attendu ; il laisse délibérément à l’équipe le soin de choisir la solution.

Une notion très proche est déjà traitée ici : la spécification produit, qui déroule les cinq étapes menant des retours clients à des exigences rédigées. Si votre besoin est d’apprendre à formuler les exigences elles-mêmes, c’est cet article-là qu’il faut lire. Celui-ci prend le sujet par l’autre bout : ce que le PRD est devenu depuis qu’on l’a déclaré mort, ce qu’on y met vraiment, ce qu’on n’y met plus, et ce qui le sépare d’un cahier des charges.

Qu’est-ce qu’un PRD ? Définition et rôle

Le PRD répond à trois questions, et à trois seulement : quel problème résout-on, pour qui, et comment saura-t-on que c’est réussi. Tout le reste — l’architecture, le choix des composants, le découpage des tickets — appartient à l’équipe qui construit. Cette frontière est sa raison d’être : en séparant l’énoncé du problème de sa résolution, il laisse aux concepteurs et aux développeurs la latitude de proposer des solutions que le rédacteur n’aurait pas imaginées.

Il s’adresse à trois publics à la fois, ce qui explique sa difficulté de rédaction : l’équipe de développement y cherche le périmètre et les critères de réussite, les parties prenantes la justification et l’échéance, les fonctions transverses ce qui va changer pour elles. Un PRD qui ne parle qu’aux développeurs est une spécification ; un PRD qui ne parle qu’à la direction est une note d’intention.

PRD, spec produit, user stories : qui dit quoi

Ces documents ne sont pas concurrents : ils occupent trois altitudes. Le PRD se tient le plus haut, il cadre une fonctionnalité entière, son intention, son périmètre et ses indicateurs. La spécification produit descend d’un cran et décrit le comportement attendu, écran par écran, règle de gestion par règle de gestion. Les user stories découpent ensuite ce périmètre en unités livrables, chacune assortie de ses critères d’acceptation, qui disent de façon vérifiable quand le travail est terminé.

Un quatrième document intervient quand les chemins de traverse coûtent cher : le cas d’utilisation, ou use case, qui déroule un scénario complet avec ses variantes et ses échecs. Il ne remplace pas le PRD, il instrumente une zone risquée — un tunnel de paiement, une obligation réglementaire. La règle pratique tient en une phrase : un seul document par altitude, et des liens entre eux plutôt qu’une recopie, car dès qu’une information est écrite à deux endroits, l’un des deux devient faux.

Pourquoi on a cru le PRD mort — et pourquoi il est revenu

Le PRD a eu son texte fondateur : « How to Write a Good PRD », signé Marty Cagan pour le Silicon Valley Product Group — un guide de vingt-six pages qui décrivait un document lui-même volumineux. C’est le même auteur qui a sonné la fin de partie. Dans « Revisiting the Product Spec », publié en octobre 2006, il constate que ces documents prennent trop de temps à écrire, sont rarement lus et ne fournissent pas le niveau de détail nécessaire — et propose de leur substituer le prototype haute fidélité.

L’agilité a fait le reste. Le manifeste Agile préférant explicitement un logiciel qui fonctionne à une documentation exhaustive, une génération d’équipes a rangé le PRD au grenier avec le cycle en V. Ce qui est revenu depuis n’est pas l’ancien document : c’est un format court, page d’atterrissage d’une fonctionnalité, où le texte ne porte plus que ce que les liens vers les maquettes et les tickets ne portent pas — l’intention, le périmètre, les décisions prises.

Que met-on dans un PRD aujourd’hui ?

Il n’existe aucune norme du PRD, et c’est ce qui déroute : chaque entreprise a son modèle, chaque éditeur d’outil a le sien. Les formats qui tiennent convergent pourtant sur un même principe, celui de la page unique. Le document devient le point d’entrée d’une fonctionnalité, et tout ce qui vit ailleurs — maquettes, tickets, comptes rendus — y est lié plutôt que recopié.

Les rubriques d’un PRD d’une page

Voici un modèle générique, à adapter : il n’est tiré d’aucun produit en particulier et sert de point de départ, pas de gabarit à remplir sans réfléchir. Les rubriques restées vides sont les plus instructives — chacune est une question qu’on n’a pas encore posée.

• En-tête — nom de la fonctionnalité, auteur, date de dernière mise à jour, état d’avancement. Sans date, un document vivant est indiscernable d’un document mort.
• Problème — ce qui ne va pas, pour qui, sur quelles observations. C’est la sortie du travail de product discovery, pas une intuition de réunion.
• Objectifs et indicateurs — ce que le produit doit changer, en résultat mesurable. Le format OKR convient bien, à condition de s’en tenir à un ou deux indicateurs.
• Utilisateurs concernés — les segments visés, et surtout ceux qu’on ne vise pas.
• Périmètre — ce qui entre dans cette version : un MVP assumé n’appelle pas les mêmes exigences qu’une refonte, et une priorisation MoSCoW suffit à trancher.
• Hors-périmètre — la rubrique la plus rentable : elle éteint les demandes récurrentes sans avoir à les rediscuter.
• Expérience attendue — un lien vers les wireframes et les maquettes, jamais une capture recopiée, périmée la semaine suivante.
• Questions ouvertes — les décisions en attente, avec un responsable et une échéance. C’est cette rubrique qui rend le document vivant.

Ce squelette recoupe le modèle d’exigences produit publié par Atlassian, qui ajoute deux rubriques que je trouve sous-estimées : les hypothèses de l’équipe, énoncées noir sur blanc pour être réexaminées en cours de route, et une section explicite « ce que nous ne faisons pas ».

Ce qu’on n’y met plus

Un PRD moderne se définit autant par ses absences. Voici ce qui en est sorti, et où c’est parti — car rien n’a disparu, tout a changé de support.

• Le détail d’implémentation — schéma de base de données, structure des tables, noms de méthodes. Le PRD dit le quoi ; l’équipe technique reste maîtresse du comment.
• La liste exhaustive des user stories — elles vivent dans le backlog produit, priorisées et estimées. Le PRD y renvoie, il ne les duplique pas.
• Les scénarios d’erreur complets — quand ils sont critiques, ils justifient un cas d’utilisation dédié ; sinon, ils se traitent en critères d’acceptation.
• Le planning détaillé — les dates de jalons vieillissent plus vite que tout le reste et discréditent le document entier.
• Le circuit d’approbation par signatures — Atlassian range d’ailleurs l’approbation formelle de toutes les équipes avant démarrage parmi les anti-schémas à surveiller. Un document approuvé est un document que plus personne n’ose modifier.

PRD vs cahier des charges : deux logiques opposées

La confusion est fréquente en France, où le cahier des charges structure la commande depuis longtemps. Les deux documents décrivent un produit à construire, mais ils n’ont ni le même statut ni le même destin. Le cahier des charges est un document contractuel entre un client et un prestataire : il engage, il se signe, et toute évolution passe par un avenant. Le PRD n’engage personne — c’est un outil de travail interne, dont la valeur vient de sa capacité à être corrigé le lendemain.

Critère	Cahier des charges	PRD
Statut	contractuel, opposable	interne, sans valeur d’engagement
Qui le rédige	le client, ou son assistance à maîtrise d’ouvrage	l’équipe produit, avec le design et la technique
Quand	avant la consultation, une fois	dès le cadrage, puis en continu
Niveau de détail	exhaustif : il fixe le périmètre payé	juste assez pour décider
Un changement	donne lieu à un avenant	donne lieu à une mise à jour
Ce qu’il décrit	des exigences et des livrables	un problème, un périmètre, des critères de réussite
Fin de vie	archivé à la recette	archivé quand la fonctionnalité est stabilisée

Un détail de vocabulaire entretient le malentendu : beaucoup d’organisations françaises appellent « cahier des charges » ce qui est en réalité un PRD interne, sans la moindre contrepartie contractuelle. La question à se poser est simple. Ce document sert-il à faire signer quelqu’un ? Si oui, c’est un cahier des charges, et l’exhaustivité y est une protection. Si non, c’est un PRD, et l’exhaustivité lui nuit.

Quand le cahier des charges reste le bon outil

L’opposition ne vaut pas jugement. Le cahier des charges reste le bon document dès qu’un tiers doit s’engager sur un résultat : prestation externe au forfait, marché public, contrainte réglementaire, projet comportant du matériel dont la fabrication ne se reprend pas. Le périmètre y est figé parce que c’est lui qui est acheté, audité ou certifié. Le PRD ne le remplace pas : il l’alimente en amont, en clarifiant le problème avant qu’on ne le contractualise, et lui succède quand l’équipe reprend la main sur l’évolution du produit.

Comment rédiger un PRD qui reste utile après le lancement

Rédiger un PRD n’est pas remplir un gabarit de haut en bas. C’est une suite de décisions, et l’ordre dans lequel on les prend détermine à peu près tout ce que vaudra le document. Six règles suffisent.

1. Écrire le problème avant tout le reste. Tant qu’il n’est pas formulé en une phrase compréhensible par quelqu’un d’extérieur à l’équipe, il est trop tôt pour écrire la suite.
2. Fixer les critères de réussite tout de suite. Ce que vous ne savez pas mesurer avant le développement, vous ne le mesurerez pas après. Un indicateur, deux au maximum, avec la valeur de départ.
3. Écrire le hors-périmètre en même temps que le périmètre. C’est la moitié la moins agréable à rédiger et la plus utile à relire : elle transforme un refus implicite en décision assumée et datée.
4. Rédiger à plusieurs. Le document écrit seul par le responsable produit puis « présenté » à l’équipe figure parmi les anti-schémas les mieux documentés du genre.
5. Lier plutôt que recopier. Maquettes, tickets, comptes rendus d’entretiens : des liens. Une capture d’écran collée est fausse dès la première itération de design, et personne ne pense à la remplacer.
6. Dater, et rouvrir. Chaque décision prise en cours de route se répercute le jour même. Un PRD qui n’a pas bougé depuis le début du développement ne décrit plus le produit qu’on construit.

Le test honnête : le document que personne ne rouvre

Il existe un critère de qualité plus fiable que toutes les grilles de relecture : après la mise en production, quelqu’un rouvre-t-il le PRD ? Si l’équipe y revient — pour vérifier une règle, retrouver pourquoi telle option a été écartée, préparer la version suivante — le document a fait son travail. S’il n’est jamais rouvert, ce n’est pas qu’il était inutile : c’est qu’il était trop long pour qu’on espère y retrouver quoi que ce soit.

La longueur est le symptôme, pas la cause. La cause est presque toujours la même : le document a été écrit pour se couvrir, non pour décider. On reconnaît un PRD défensif à ses marqueurs — un « contexte » de deux pages, un glossaire, des exigences numérotées pour pouvoir dire plus tard qu’elles avaient bien été annoncées. Un PRD de décision se reconnaît à ses questions ouvertes.

Un PRD n’est pas un document qu’on termine. C’est un document qu’on rouvre.

Mon avis, après plus de dix ans passés entre e-commerce, agences et éditeurs de logiciels : le procès fait au PRD visait le mauvais accusé. Ce n’est pas le fait d’écrire qui pose problème, c’est le fait d’écrire une fois pour toutes. Une page tenue à jour pendant six mois vaut mieux que trente pages figées la veille du lancement. Reste que le document ne dispense de rien : il ne remplace ni la conversation avec l’équipe, ni le travail de product discovery qui lui fournit sa matière. Il en conserve la trace, ce qui est déjà considérable.

FAQ — Tout savoir sur le PRD

Que signifie PRD ?

PRD est l’acronyme de product requirements document, traduit en français par document d’exigences produit. Il décrit ce qu’un produit ou une fonctionnalité doit accomplir, pour quels utilisateurs et selon quels critères de réussite, sans prescrire la solution technique retenue pour y parvenir.

Qui rédige le PRD ?

Le responsable produit — product manager ou product owner — en tient la plume. Mais un PRD écrit seul puis présenté à l’équipe est un contresens : le design et la technique doivent contribuer aux hypothèses, au périmètre et aux questions ouvertes dès la première version, faute de quoi le document se transforme en commande interne.

Quelle longueur doit faire un PRD ?

Il n’existe pas de norme, mais le format qui survit à l’usage tient sur une à deux pages, liens compris. Le bon indicateur n’est de toute façon pas le nombre de pages : c’est de savoir si quelqu’un rouvre le document après le lancement. Si la réponse est non, il était trop long.

Quelle différence entre un PRD, un BRD et un MRD ?

Le BRD, business requirements document, énonce le besoin de l’entreprise et sa justification économique. Le MRD, market requirements document, décrit le marché visé et ses attentes. Le PRD traduit ces deux niveaux en exigences produit. Ces distinctions viennent du logiciel d’entreprise des années 2000 ; hors de ce contexte, elles ont largement fusionné en un seul document.

Existe-t-il un template de PRD à réutiliser ?

Oui, la plupart des outils de documentation d’équipe en proposent un, de Confluence à Notion, et les rubriques listées plus haut suffisent à démarrer sans outil. Le modèle importe moins que la discipline de mise à jour : un gabarit rempli une fois puis abandonné produit exactement le document que le PRD moderne cherche à éviter.

Le PRD est-il compatible avec Scrum ?

Oui, à condition qu’il reste au-dessus du backlog. Scrum ne prescrit aucun document en dehors de ses artefacts, et rien n’interdit une page de cadrage qui explique pourquoi un ensemble de stories existe. Le conflit n’apparaît que si le PRD prétend figer le contenu d’un incrément avant sa livraison.

Peut-on faire rédiger un PRD par une intelligence artificielle ?

Un modèle de langage produit très vite une structure propre et complète, ce qui aide à ne rien oublier. Il ne peut pas, en revanche, fournir la matière : les observations utilisateurs, les arbitrages de périmètre, les décisions déjà prises. Un PRD généré sans ce travail en amont est un gabarit bien rempli, pas un document de cadrage.