Modèle de PRD avec IA : les sections, un prompt pour chacune et un exemple complet

Ce que le modèle doit accomplir

Un document d'exigences produit a deux lecteurs. Celui qui construit, qu'il s'agisse d'un coéquipier, d'un prestataire ou d'un agent de code, doit savoir quoi faire et quand s'arrêter. Celui qui relit doit vérifier que ce qui a été livré correspond à ce qui a été convenu. Le modèle sert les deux quand chaque exigence est une seule affirmation testable et que chaque non-objectif est écrit noir sur blanc.

Les sections sont choisies pour que chacune réponde à un type de question différent :

Gardez l'ensemble sous deux pages. Un PRD que personne ne lit est un PRD qui n'existe pas.

Le modèle de PRD en Markdown

Copiez ce bloc dans une page, un fichier de votre dépôt ou un éditeur. Remplacez tout ce qui est entre crochets et supprimez chaque ligne de guidage une fois la section rédigée.

PRD : [Nom de la fonctionnalité ou du produit]

Responsable : [Nom]
Statut : [Brouillon / En relecture / Validé]
Dernière mise à jour : [AAAA-MM-JJ]
Résumé : [Une phrase : ce que c'est, pour qui, ce que ça remplace]

**1. Problème**
Aujourd'hui, [qui] [fait quel contournement] quand il doit [accomplir quelque chose].
Cela lui coûte [temps, argent ou risque que vous avez observé].
Preuves : [entretiens, tickets de support, appels commerciaux, votre propre usage ; dites combien]

**2. Objectifs**
G1. [Métrique] passe de [valeur actuelle] à [cible] d'ici le [date].
G2. [Métrique] passe de [valeur actuelle] à [cible] d'ici le [date].
Comment nous mesurerons : [le tableau de bord, la requête ou le rapport]

**3. User stories**
US-1. En tant que [rôle], quand [situation], je veux [action], afin de [résultat].
US-2. En tant que [rôle], quand [situation], je veux [action], afin de [résultat].
US-3. En tant que [rôle], quand [situation], je veux [action], afin de [résultat].

**4. Critères d'acceptation**
Pour chaque story, une ou plusieurs vérifications qu'un relecteur peut valider ou rejeter.
AC-1a. Étant donné [état], quand [action], alors [résultat observable].
AC-1b. Étant donné [état], quand [action], alors [résultat observable].
AC-2a. Étant donné [état], quand [action], alors [résultat observable].
Priorité : [Must / Should / Could] pour chaque story.

**5. Non-objectifs**
Nous ne faisons pas [chose] dans cette version parce que [raison].
Nous ne faisons pas [chose] dans cette version parce que [raison].

**6. Risques et questions ouvertes**
R1. [Risque]. Probabilité [faible/moyenne/forte]. Si cela arrive : [réponse].
R2. [Risque]. Probabilité [faible/moyenne/forte]. Si cela arrive : [réponse].
Ouverte : [une question à trancher avant le début du build, et qui y répond]

Deux conventions portent l'essentiel du poids. Chaque story et chaque critère ont une clé stable (US-1, AC-1a), de sorte qu'un message de commit, un ticket ou un audit peuvent y renvoyer. Et chaque critère est écrit en étant donné-quand-alors, ce qui en fait un test avant d'être du code.

Un prompt pour chaque section

Un seul prompt « écris-moi un PRD » produit un document sûr de lui avec des preuves inventées et des objectifs génériques. Demander une section à la fois, avec les faits dont vous disposez réellement, laisse au modèle moins de place pour inventer. Voici les prompts que nous utilisons ; les parties entre crochets sont ce que vous remplissez avant d'envoyer.

1. Problème. « Voici mes notes de [N] conversations clients et [N] tickets de support : [coller]. Rédige la section Problème en moins de 120 mots, sous la forme "Aujourd'hui, [qui] fait [contournement] quand il doit [tâche]. Cela lui coûte [coût]." N'utilise que des coûts qui figurent dans les notes. Termine par une ligne Preuves qui compte les sources. »
2. Objectifs. « Le problème est : [coller]. Nos chiffres actuels sont : [métrique, valeur]. Propose trois objectifs sous la forme "G#. [métrique] passe de [actuel] à [cible] d'ici le [date]". N'invente pas de valeurs actuelles ; s'il t'en faut une que je n'ai pas donnée, écris TBD. »
3. User stories. « Problème et objectifs : [coller]. Rédige au plus cinq user stories sous la forme "En tant que [rôle], quand [situation], je veux [action], afin de [résultat]". Un rôle par story. Classe-les selon leur contribution directe à G1. »
4. Critères d'acceptation. « Pour chaque story ci-dessous, rédige deux ou trois critères d'acceptation sous la forme "Étant donné [état], quand [action], alors [résultat observable]". Chacun doit pouvoir être vérifié par quelqu'un qui ne voit pas le code. Signale toute story pour laquelle tu ne peux pas écrire de critère vérifiable. » C'est l'étape où une story faible se trahit : si le modèle ne peut pas lui écrire de test, vous non plus.
5. Non-objectifs. « Étant donné ces stories, liste six choses qu'un ingénieur raisonnable pourrait croire incluses mais qui ne le sont pas. Pour chacune, écris "Nous ne faisons pas [chose] dans cette version parce que [raison]". » Puis réduisez la liste à celles qui tenteraient vraiment votre équipe.
6. Risques. « Liste les quatre façons les plus probables dont cette fonctionnalité échoue après le lancement, techniques ou commerciales. Pour chacune : probabilité, et la réponse que nous apporterions. Signale tout ce que tu devines. »

Demandez une section, lisez-la, corrigez-la, puis collez la version corrigée dans le prompt suivant. La chaîne de sections corrigées est la vraie garantie ; le modèle ne voit jamais que ce que vous avez déjà approuvé.

Exemple complet : un lien de réservation pour un cabinet de deux personnes

Voici le modèle rempli pour une petite fonctionnalité à l'allure réaliste. Les chiffres sont illustratifs.

PRD : Lien public de réservation

Responsable : Dana
Statut : Validé
Dernière mise à jour : 2026-10-28
Résumé : Une page publique où un prospect choisit un créneau de
30 minutes dans notre agenda partagé, à la place des allers-retours
par e-mail que nous faisons aujourd'hui.

**1. Problème**
Aujourd'hui, un prospect qui veut un appel nous écrit, et nous échangeons
en moyenne quatre messages pour convenir d'une heure. Sur les 22 appels
du dernier trimestre, cela a représenté environ trois heures de temps des
fondateurs, et deux prospects ont cessé de répondre avant qu'une heure
soit fixée.
Preuves : recherche dans les messages envoyés des 90 derniers jours ;
22 fils comptés.

**2. Objectifs**
G1. Messages échangés par appel réservé passe de 4 à 1 d'ici le
15 décembre.
G2. Appels réservés par mois passe de 7 à 10 d'ici le 31 janvier.
Comment nous mesurerons : nombre de fils étiquetés « planification » dans
la boîte partagée ; table des réservations dans l'espace de travail.

**3. User stories**
US-1. En tant que prospect, quand j'ouvre le lien, je veux voir les
créneaux dans mon fuseau horaire, afin de ne pas réserver à 3 h du matin
par erreur.
US-2. En tant que fondateur, quand un créneau est réservé, je veux le
voir dans mon agenda avec les coordonnées du prospect, afin de ne pas
préparer l'appel de mémoire.
US-3. En tant que fondateur, quand je suis en congé, je veux qu'aucun
créneau ne soit proposé, afin que personne ne réserve une semaine où je
suis absent.

**4. Critères d'acceptation**
AC-1a. Étant donné un visiteur en UTC+9, quand la page se charge, alors
les heures s'affichent en UTC+9 et le nom du fuseau est visible.
AC-1b. Étant donné un créneau déjà réservé, quand la page se charge,
alors ce créneau n'est pas proposé.
AC-2a. Étant donné une réservation terminée, quand j'ouvre l'agenda,
alors un événement existe avec le nom, l'e-mail et les notes du prospect
en moins de 60 secondes.
AC-3a. Étant donné une demande de congé approuvée couvrant un jour, quand
la page se charge, alors aucun créneau n'est proposé ce jour-là.
Priorité : US-1 Must, US-2 Must, US-3 Should.

**5. Non-objectifs**
Nous ne faisons pas de paiement à la réservation parce que le premier
appel est gratuit.
Nous ne faisons pas d'événements de groupe parce qu'on ne nous en a
jamais demandé.
Nous ne faisons pas de personnalisation de marque parce que nous deux
sommes la marque.

**6. Risques et questions ouvertes**
R1. Double réservation si la synchronisation de l'agenda prend du retard.
Probabilité moyenne. Si cela arrive : e-mail de confirmation avec lien de
report, vérifié chaque jour.
R2. Réservations indésirables. Probabilité faible. Si cela arrive :
exiger une confirmation par e-mail avant de bloquer le créneau.
Ouverte : proposons-nous aussi des créneaux de 15 minutes ? Dana décide
d'ici vendredi.

Remarquez ce que l'exemple ne contient pas : pas d'« expérience délicieuse », pas d'architecture, pas de captures d'écran. AC-3a est un test qu'un relecteur peut exécuter en deux minutes. Les non-objectifs sont les trois choses sur lesquelles un prestataire poserait le plus probablement des questions.

Où le conserver, et quoi en faire ensuite

Un PRD dans une fenêtre de chat est perdu dès que l'onglet se ferme. Il lui faut un emplacement avec un historique des versions, pour voir ce qui a changé entre « Brouillon » et « Validé », et un moyen de transformer ses stories en travail.

Dans Atrix, le modèle de PRD est une page hébergée avec les mêmes sections que le Markdown ci-dessus, plus un tableau d'exigences où chaque ligne a une clé, une affirmation vérifiable, son acceptation et une priorité MoSCoW. L'exécution Develop de l'agent fait aussi le chemin inverse : donnez-lui un brief court et l'étape « Rédiger les exigences » écrit le problème, l'utilisateur cible, le périmètre, les exigences numérotées et les non-objectifs dans une page ; les étapes suivantes proposent une architecture et des tickets planifiés que vous pouvez accepter dans le backlog. Les limites valent d'être connues : une exécution consomme l'une des exécutions mensuelles du plan (100 sur Builder, 500 sur Studio), il n'y a pas d'offre gratuite, et l'agent rédige à partir de votre brief, donc un brief maigre donne un PRD maigre. La page de l'agent IA liste ce que produit chaque exécution.

Si vous voulez que le PRD soit lu par un agent de code plutôt que par une personne, l'article jumeau sur rédiger un PRD que Claude Code ou Cursor peuvent construire couvre les contraintes supplémentaires.

Les erreurs courantes que le modèle est conçu pour éviter

• Des objectifs sans valeur actuelle. « Augmenter les conversions » est un souhait. « Passer de 2,1 % à 3 % d'ici mars » est un objectif. Si vous ne connaissez pas la valeur actuelle, écrivez TBD et trouvez-la avant le début du build.
• Des stories qui sont des fonctionnalités déguisées. « En tant qu'utilisateur, je veux un tableau de bord » n'a ni situation ni résultat. Demandez ce qu'il cherche à accomplir.
• Des critères qui exigent le code pour être vérifiés. « L'API renvoie 200 » est un détail d'implémentation. « Étant donné une réservation terminée, quand j'ouvre l'agenda, alors l'événement existe » est ce que l'utilisateur voit.
• Des non-objectifs vides. Si la section est vide, le périmètre n'a pas été décidé ; il le sera par celui qui construit.
• Une section risques qui ne liste que des risques techniques. « Personne ne l'utilise » est l'échec le plus fréquent et a sa place dans la liste.

FAQ

Qu'est-ce qu'un modèle de PRD avec IA ?

Un modèle de document d'exigences produit écrit pour qu'un assistant IA puisse rédiger chaque section à partir des faits que vous fournissez, et pour qu'un relecteur puisse vérifier le résultat. Celui ci-dessus a six sections : problème, objectifs, user stories, critères d'acceptation, non-objectifs et risques, chacune avec un prompt.

Un PRD pour un produit IA est-il différent d'un PRD classique ?

Les sections sont les mêmes. Ce qui change, ce sont les critères d'acceptation : une fonctionnalité IA a besoin de critères pour les cas où le modèle se trompe, est lent ou indisponible, et d'un seuil de précision explicite plutôt que « fonctionne correctement ». Ajoutez un non-objectif pour les comportements que vous ne tenterez pas de gérer dans la première version.

Quelle longueur doit faire un PRD ?

Moins de deux pages pour une fonctionnalité, trois ou quatre pour un nouveau produit. Si une section dépasse, c'est généralement un document de conception ou un backlog caché dans le PRD. Sortez-le et faites un lien.

Puis-je simplement demander à ChatGPT ou Claude d'écrire tout le PRD ?

Vous pouvez, et le résultat se lira bien, ce qui est précisément le problème. Un PRD en un seul prompt invente des preuves et des valeurs actuelles parce qu'il n'en a aucune. Demander une section à la fois avec vos propres chiffres, et corriger chacune avant la suivante, garde le document honnête.

Quelle est la différence avec GitHub Spec Kit ?

Spec Kit est une boîte à outils pour agents de code qui transforme une spécification en plan, en tâches et en code via des commandes dans le chat de l'agent. Ce modèle est la spécification elle-même, écrite pour qu'une personne la valide avant que ce processus ne commence. Les deux s'emboîtent : rédigez le PRD, puis donnez-le à l'étape specify.

Où vont les critères d'acceptation une fois le PRD validé ?

Chacun devient la définition de « terminé » d'un ticket. Dans Atrix, le tableau d'exigences de la page du PRD est ce que l'audit des exigences vérifie ensuite : il compare ce qui a été planifié à la base de référence figée, pas le code source. L'entrée du glossaire sur le PRD explique les termes.

Prochaine étape

Copiez le Markdown ci-dessus, ou ouvrez le modèle de PRD hébergé et remplissez-le avec votre équipe. Si vous préférez partir d'un brief, l'agent Atrix rédige la première version dans une page pendant l'essai de 7 jours.

Sources

Tarifs de ChatPRD et GitHub Spec Kit, tous deux consultés en octobre 2026.