Comment rédiger un product requirements document quand vous n’êtes pas PM

Une fondatrice avec qui nous travaillons nous a envoyé un PRD de quatorze pages l’été dernier. Page de garde, glossaire, OKRs, trois personas, découpage en sprints, métriques de succès, un prototype Figma que l’équipe n’avait pas encore construit, et une section intitulée “non-functional requirements” qui ressemblait à un copier-coller d’un template enterprise réalisé la veille au soir. L’équipe à qui elle allait remettre le brief comptait trois ingénieurs et une designer à mi-temps, dans un studio avec lequel elle n’avait jamais travaillé. Le premier appel de cadrage a duré deux heures et n’a rien tranché.

Ce document n’était pas un product requirements document. C’était un artefact de PM rédigé hors-sol, par une fondatrice qui avait lu assez de guides Atlassian et Notion pour savoir quelles intertitres mettre, et qui avait pensé trop peu à ses propres contraintes pour savoir quelles sections lui étaient vraiment utiles.

Si vous cherchez comment rédiger un product requirements document, vous êtes presque certainement dans l’une des deux situations suivantes. Vous êtes product manager dans une entreprise qui a déjà une équipe d’ingénierie, et dans ce cas les guides existants sur internet sont écrits pour vous. Ou vous êtes un fondateur non technique qui s’apprête à briefer un développeur, un petit studio, ou votre première recrue d’ingénierie, et les guides existants supposent un contexte que vous n’avez pas. Cet article s’adresse au second groupe.

La définition honnête d’un PRD

Un product requirements document est un accord écrit entre la personne qui décide ce qui doit être construit et les personnes qui le construisent. C’est tout le travail. Le reste, les personas et les user stories et les dashboards d’analytics, c’est de la pièce à conviction. La majorité des guides PRD sur internet gonflent les pièces à conviction jusqu’à les transformer en document, parce que la majorité de ces guides est écrite pour un contexte où aligner une organisation produit de quinze personnes est le vrai problème.

Votre problème est différent. Vous n’alignez pas quinze parties prenantes. Vous donnez à une petite équipe de build une image suffisamment claire de quoi construire et pourquoi, pour qu’elle puisse prendre les dizaines de petites décisions qu’elle s’apprête à prendre en votre absence sans vous envoyer un message Slack toutes les vingt minutes. Le document doit faire deux choses correctement : dire ce que le client doit pouvoir faire, et dire quels arbitrages vous avez déjà tranchés, pour qu’ils ne vous surprennent pas plus tard.

C’est un document beaucoup plus petit que ce que les templates suggèrent. La majorité des fondateurs non techniques avec qui nous travaillons aboutit à quatre à sept pages, pas vingt. Le document rétrécit quand on comprend quelles sections gagnent leur place.

Six sections qui gagnent leur place

Chaque PRD de fondateur que nous avons vu fonctionner ces trois dernières années contient ces six pièces, à peu près dans cet ordre. Les intertitres peuvent changer. La substance doit y être.

1. Le client et le moment

Un paragraphe, pas plus. Qui est l’utilisateur, et que fait-il dans les trente secondes avant de rencontrer votre produit. Pas un deck de personas. Une scène.

Une comptable indépendante d’un petit cabinet vient de recevoir quatorze factures clients sur le mois, chacune dans un format différent. Elle doit toutes les saisir dans QuickBooks avant le rapprochement de fin de semaine. Aujourd’hui cela lui prend trois heures. Elle est à son bureau avec les factures ouvertes dans quatorze onglets de navigateur.

Ce paragraphe travaille plus que trois pages de personas. L’équipe qui va construire le produit sait maintenant quelle friction compte et laquelle ne compte pas. La vitesse d’upload compte. Les jolies animations, non. La comptable ne va pas envoyer le produit à un confrère via une fiche comparative de fonctionnalités, donc le polish marketing n’est pas une priorité du v1.

2. La décision que vous avez déjà prise

Les fondateurs sautent cette section parce qu’elle leur paraît évidente. Elle ne l’est pas pour l’équipe de build. Dites-le clairement : ce qui entre dans le build, ce qui n’y entre pas, et quelles hypothèses cassent si quelqu’un les modifie.

Si vous payez un vendor, chaque hypothèse non écrite devient une question qu’il vous posera plus tard, qui devient un retard, qui devient un re-cadrage. Écrire les hypothèses coûte moins cher que les rouvrir en plein milieu du projet.

Une version propre se lit ainsi : on construit un web app, pas une app mobile, parce que nos utilisateurs sont devant un bureau. On intègre QuickBooks Online, pas Xero, pas Sage, parce que quatre-vingts pour cent de notre pipeline est sur QBO. On ne construit pas de système de facturation en v1 ; on facturera à la main pendant les six premiers mois. La cible est Chrome et Safari sur desktop. Mobile et Edge ne sont pas dans le v1.

Ce paragraphe vous économise quatre heures de réunion.

3. La plus petite version qui rapporte de l’argent ou de l’apprentissage

C’est ce que les vrais gens du produit appellent le MVP, et c’est la partie que la plupart des fondateurs non techniques rate. Un v1 n’est pas “tout ce que prévoit la vision long-terme, en plus petit.” Un v1 est la plus petite surface qui permet de facturer un vrai client ou de tuer l’idée. La plupart des choses que vous voulez mettre dans le v1 n’y sont pas.

Rédigez cette section comme une liste de jobs visibles par l’utilisateur que le v1 doit accomplir de bout en bout. Pas des features. Des jobs. “Uploader une facture et la voir apparaître dans QuickBooks en cinq minutes” est un job. “Glisser-déposer pour l’upload” est une feature. L’équipe de build saura choisir la bonne feature pour livrer le job. Elle ne peut pas choisir le bon job, parce qu’elle ne sait pas pour quels jobs vos clients vont payer.

Un v1 de pre-seed compte généralement entre trois et six jobs. Si votre liste en a douze, vous ne rédigez pas un v1 ; vous rédigez une wishlist. Coupez.

4. Les arbitrages que vous ne rouvrirez pas plus tard

Les ingénieurs prennent des centaines de petites décisions pendant un build. La plupart vous sont invisibles. Quelques-unes ne le sont pas, et ce sont celles-là qui deviendront des disputes si vous ne les avez pas écrites avant.

Trois arbitrages reviennent sur presque chaque build :

Le premier, c’est périmètre contre finition. Vous pouvez avoir une tranche fine qui fait dix choses passablement, ou deux choses parfaitement. Choisissez. L’équipe choisira pour vous si vous ne choisissez pas, et elle ne choisira pas ce que vous auriez choisi.

Le deuxième, c’est vitesse contre durabilité. Vous pouvez livrer quelque chose tenu avec du chatterton en quatre semaines, ou quelque chose de maintenable en huit. Choisissez. Nous avons vu des fondateurs insister sur la version quatre semaines, sprinter pour la démo de fundraise, puis passer les douze mois suivants à s’excuser auprès des ingénieurs pour le chatterton. Décidez quelle erreur vous préférez commettre.

Le troisième, c’est custom contre off-the-shelf. Chaque build a des morceaux qu’il faut acheter, pas construire. L’auth en est l’exemple évident ; personne ne devrait construire des écrans de login depuis zéro en 2026. Exemples moins évidents : stockage de fichiers, email transactionnel, paiements, recherche. Dites à l’équipe de build où vous voulez qu’elle trace ces frontières, sinon elle les tracera à des endroits qui vous surprendront.

5. À quoi ressemble le succès en semaine huit

Choisissez un résultat observable qui signifie que le v1 a fonctionné. Pas un dashboard de KPIs. Une phrase.

Un cas réel d’une fintech avec qui nous avons travaillé l’an dernier : “D’ici la semaine huit, trois clients payants auront effectué au moins une clôture mensuelle complète sur le produit, de bout en bout, sans intervention de notre équipe support.” Cette phrase est un contrat. Toute l’équipe de build peut la garder en tête et l’utiliser pour trancher les débats de périmètre. “Cette feature aide-t-elle à atteindre la métrique de clôture-sans-support ?” Si oui, on construit. Si non, on reporte.

La plupart des PRD de fondateurs que nous lisons n’ont pas cette section. Ils ont un dashboard avec douze KPIs et une aspiration vague. Ce n’est pas un objectif ; c’est de la comptabilité de désir.

6. Ce qui est hors-périmètre, et pourquoi

Les choses que vous ne construirez pas méritent leur propre section, parce qu’autrement elles reviendront en douce pendant le build. Écrivez-les. Écrivez-les avec la raison. “App mobile : non, parce que les utilisateurs sont au bureau.” “Multi-devises : non, parce que les clients du v1 sont uniquement aux États-Unis.” “SSO : non, parce que les clients du v1 sont des indépendants.”

Vous-du-futur remerciera vous-du-présent pour cette section en semaine six, quand un investisseur vous demandera pourquoi vous n’avez pas d’app mobile et que vous pourrez répondre en une phrase au lieu de retourner au document.

Six sections qui ne devraient pas figurer dans le PRD du fondateur

Celles-ci appartiennent aux PRD écrits pour des organisations produit établies. Elles n’appartiennent pas au brief d’un fondateur non technique. Les y mettre est la façon la plus fiable de passer trois semaines à rédiger un document et de ne pas avoir un plan constructible pour autant.

Un glossaire. Si vous avez besoin d’un glossaire, vous n’avez pas assez taillé le document. L’équipe de build ne devrait pas avoir besoin de chercher un terme. Utilisez les mots que ses ingénieurs et vos clients emploient vraiment.

Personas. Les personas sont un outil pour prioriser entre plusieurs types d’utilisateurs. En pre-seed, vous avez un seul type d’utilisateur, et vous devriez le connaître par son prénom. Écrivez plutôt le paragraphe client-et-moment.

OKRs. Les OKRs sont un outil d’alignement organisationnel. Un fondateur qui briefe une équipe de quatre n’en a pas besoin. La phrase “à quoi ressemble le succès en semaine huit” fait le même travail.

Une roadmap au-delà du v1. La roadmap après v1, c’est de la spéculation. Tout vendor ou recrue qui traite votre roadmap post-v1 comme un vrai plan ne fait pas attention. Gardez la roadmap hors du PRD ; ce qui est dans le v1 est le plan, ce qui vient après est une hypothèse.

Des user stories détaillées avec critères d’acceptation. Les critères d’acceptation, c’est la manière dont les PMs traduisent une roadmap dans un tracker. Une petite équipe de build n’en a pas besoin en amont ; elle les écrira elle-même contre vos six sections, et vous demandera quand quelque chose est ambigu. C’est plus rapide.

Des wireframes que l’équipe n’a pas dessinés. Si vous avez ébauché les écrans dans Figma vous-même, ne les mettez pas dans le PRD. L’équipe de build va les redessiner, et elle doit. Montrer votre ébauche tend à ancrer tout le monde sur une mise en page qui peut ne pas survivre au contact de la vraie implémentation. Décrivez le job de l’utilisateur ; laissez l’équipe dessiner l’écran.

Un exemple concret : à quoi ressemblait un PRD de fondatrice

L’exemple de la comptable plus haut est tiré d’une vraie fondatrice. Le PRD de son v1, après que nous l’avons recoupé, faisait cinq pages. La structure suivait exactement les six sections ci-dessus. Trois jobs dans la liste du v1 : uploader des factures, les voir dans QuickBooks en cinq minutes, envoyer un message Slack à la comptable quand quelque chose échoue. Deux arbitrages tranchés en amont : livrer en six semaines plutôt que trois, tenir une seule intégration QBO. Une métrique de succès : dix cabinets payants bouclant le mois sans support d’ici la semaine dix.

Le build a pris huit semaines au lieu de six. Un job a glissé en v1.5 (notifications d’échec). Dix cabinets payants ont atteint la métrique en semaine douze. Le PRD a tenu. La version de quatorze pages que nous avions remplacée n’aurait pas tenu, parce que trop de ses sections étaient des disputes en attente.

C’est le test d’un bon PRD de fondateur : a-t-il survécu au contact du build, et quelqu’un a-t-il dû rouvrir ses hypothèses au milieu de la semaine quatre ? Si oui, le document était trop long, trop vague, ou les deux.

Quand écrire plus, et quand écrire moins

La structure en six sections n’est pas une règle dure. Deux situations appellent un document plus long.

La première, ce sont les industries régulées. Si vous construisez en healthtech, fintech, ou partout où une équipe compliance va regarder le système, vous aurez besoin d’un document séparé pour cette équipe et d’une section dans le PRD qui dit “review compliance dans le périmètre, voir annexe.” Ne sautez pas cette étape ; le coût de découvrir un trou de compliance en semaine six est bien plus élevé que le coût de l’écrire en semaine zéro.

La seconde, c’est quand vous payez un vendor en prix fixe. Les contrats à prix fixe poussent toute ambiguïté dans la négociation contractuelle, parce que le vendor facturera tout ce qui n’est pas spécifié. Dans ce cas, le PRD devient document contractuel, et on l’écrit plus long parce que chaque ligne non écrite est un futur change order. Nous recommandons généralement aux fondateurs d’éviter les contrats à prix fixe à ce stade pour exactement cette raison ; construisez avec un partner en time-and-materials, et le PRD peut rester court.

Deux situations appellent un document plus court. Si vous travaillez avec un ingénieur en qui vous avez confiance et avec qui vous avez déjà livré, un brief d’une page avec trois jobs et une métrique de succès suffit. La confiance fait le travail que ferait le document. Et si votre v1 est sincèrement un prototype et non un produit, écrivez un paragraphe et un croquis et livrez en deux semaines. Appeler cela un PRD relève du théâtre.

La version que vous écrivez en semaine un n’est pas celle qui passera en prod

Le plus dur, en rédigeant un PRD comme fondateur non technique, c’est d’accepter que le document va changer. Les PMs qui rédigent les guides sur Atlassian et Notion le savent ; leurs équipes modifient des PRD en plein vol tous les jours. Les fondateurs qui rédigent leur premier PRD le traitent souvent comme un livrable one-shot, le passent, et se sentent trahis quand la réalité force une édition.

Écrivez le document avec une hypothèse : il sera faux quelque part avant la fin de la semaine deux. L’équipe de build va découvrir quelque chose qui casse une hypothèse. Le travail du PRD n’est pas d’avoir raison ; c’est d’être suffisamment précis pour que se tromper se voie clairement et vite. Un document vague se trompe en silence. Un document précis se trompe à voix haute, et c’est ce genre d’erreur qui se rattrape.

Si vous n’en avez jamais rédigé, la première version vous semblera inconfortablement tranchée. Tant mieux. Le contraire de tranché, c’est “chacun a sa propre lecture de ce qu’on construit,” qui est précisément le mode d’échec que le document existe pour éviter.

FAQ

Quelle est la différence entre un PRD et un product brief ?

Dans la plupart des contextes de fondateur non technique, il n’y a pas de différence utile. Les PMs utilisent parfois “product brief” pour un document d’une page en stade très précoce et “PRD” pour la version plus longue. Choisissez un terme et tenez-vous-y ; le document fait le même travail.

Combien de pages devrait faire un PRD de fondateur ?

Quatre à sept pages pour un v1, d’après notre expérience. Si le vôtre en fait vingt, l’équipe de build ne le lira pas ; elle parcourra les trois premières et vous posera les questions du reste en call.

Faut-il utiliser un template de PRD ?

Les templates sont une structure de départ, pas un document fini. Le danger est qu’un template vous pousse à remplir chaque section, y compris celles dont vous n’avez pas besoin. Utilisez les six sections ci-dessus comme checklist ; traitez toute section qu’un template vous demande de remplir et qui n’y figure pas comme optionnelle.

L’IA est-elle utile pour rédiger un PRD ?

Pour rédiger le texte, oui. Pour décider de ce qui entre dans le v1, non. Les décisions des sections deux à six vous appartiennent et n’appartiennent qu’à vous ; un LLM peut vous aider à les écrire plus vite, mais il ne peut pas choisir quels arbitrages sont les bons pour votre business. Servez-vous de l’IA pour la frappe, pas pour la pensée.

Et si mon ingénieur réclame plus de détail que ce que donne le PRD ?

Répondez à la question, et décidez si elle mérite d’entrer dans le document. Si c’est une question récurrente qu’un autre ingénieur posera plus tard, écrivez-la. Si c’est un éclaircissement ponctuel, répondez sur Slack et avancez. Le PRD est un document de travail, pas un contrat.