Comment rédiger un PRD (cahier des charges produit) avec l'IA (modèle gratuit)

Un PRD (product requirements document, ou cahier des charges produit) est une description courte et en langage clair de ce que vous construisez, à qui cela s'adresse, ce que cela doit faire et comment vous saurez que cela fonctionne. L'IA accélère nettement sa rédaction : vous lui donnez des notes brutes, elle les transforme en sections structurées, en user stories et en cas limites. Votre rôle est de fournir les décisions que l'IA ne peut pas prendre (l'objectif, le périmètre et ce qui est laissé de côté), puis de vérifier ce qu'elle ajoute.

Ce guide couvre ce qui doit figurer dans un PRD, une méthode pas à pas pour en rédiger un avec n'importe quel assistant IA, des prompts pour chaque section et un modèle à remplir que vous pouvez copier.

À quoi sert un PRD (et à quoi il ne sert pas)

Un PRD répond à quatre questions :

1. Pourquoi construisons-nous cela ? Quel problème, pour qui ?
2. Que doit-il faire dans la première version ?
3. Que ne fera-t-il pas encore ?
4. Comment saurons-nous qu'il a fonctionné ?

Ce n'est pas une spécification technique. Il ne précise pas quelle base de données ou quel framework utiliser : cela relève d'une spécification technique distincte, si vous en avez besoin. Ce n'est pas non plus un brief marketing ou un business plan. Se limiter au comportement du produit rend le document utile à tous ceux qui le lisent : un designer, un développeur, une personne qui valide le projet, ou un générateur d'applications par IA qui le transforme en code.

À qui il s'adresse

• Les fondateurs solo qui veulent éviter la dérive de périmètre dès le départ.
• Les petites équipes qui ont besoin d'un seul endroit où vit « ce que nous avons convenu ».
• Toute personne qui embauche un freelance ou une agence, car un PRD clair permet d'obtenir des devis plus précis. Voir embaucher un développeur ou construire avec l'IA.
• Toute personne qui construit avec l'IA, car les user stories et la liste des données d'un PRD font de meilleurs prompts qu'une liste de souhaits non structurée.

Ce que l'IA sait bien faire, et ce qu'elle ne sait pas faire

L'erreur la plus fréquente est l'inverse de la dernière ligne du tableau ci-dessus : l'IA comble les vides avec des suppositions plausibles sur vos utilisateurs. Traitez tout ce qu'elle écrit sur les utilisateurs, la taille du marché ou les comportements comme une question à vérifier, pas comme un fait.

Étape 1 : rassembler ce que vous savez

Avant de formuler le moindre prompt, rédigez des notes brutes. Des puces suffisent. Couvrez :

• Le problème, en une ou deux phrases, du point de vue de l'utilisateur.
• Qui le vit. Soyez précis : « comptables freelance qui gèrent 10 à 40 clients », et non « petites entreprises ».
• Ce qu'ils font aujourd'hui à la place (un tableur, un e-mail, un outil qu'ils n'aiment pas).
• Le seul résultat qui ferait de la version un un succès.
• Ce que vous savez déjà ne pas vouloir faire.
• Les contraintes fortes : délai, budget, fonctionnement obligatoire sur mobile, intégration avec un outil déjà utilisé.

Si vous n'avez parlé à personne qui vit ce problème, commencez par là. Comment valider une idée d'application propose une méthode concrète. Un PRD fondé sur des suppositions reste une supposition bien présentée.

Étape 2 : demander à l'IA une première ébauche

Collez vos notes et demandez une ébauche selon une structure fixe. Un prompt qui fonctionne bien :

Voici mes notes sur un produit. Transforme-les en document d'exigences produit en utilisant exactement ces sections : Résumé, Problème, Utilisateurs, Objectifs et indicateurs de succès, Périmètre (inclus / exclu), User stories avec critères d'acceptation, Données, Droits d'accès, Cas limites, Questions ouvertes. Reste en dessous de deux pages. N'invente aucun fait sur les utilisateurs ou le marché : lorsque mes notes ne disent rien, formule la question dans Questions ouvertes.

La dernière consigne est importante. Demander à l'IA de placer les inconnues dans « Questions ouvertes » au lieu de les combler produit une ébauche bien plus honnête.

Étape 3 : resserrer chaque section

Relisez l'ébauche section par section. Ces prompts de suivi aident :

Problème et utilisateurs

Reformule le problème en une ou deux phrases, du point de vue de l'utilisateur. Aucun mot de solution.

Si l'énoncé du problème mentionne votre produit, il décrit une solution, pas un problème.

Objectifs et indicateurs de succès

Propose trois indicateurs de succès pour la version un que je pourrais mesurer le premier mois avec un petit nombre d'utilisateurs. Pour chacun, indique comment je le mesurerais.

Choisissez-en un ou deux. « Vingt comptables l'utilisent chaque semaine pendant un mois » est mesurable. « Améliorer la productivité » ne l'est pas.

Périmètre

Liste tout ce qui, dans ce PRD, pourrait être reporté à une version ultérieure sans casser le parcours principal.

Les outils d'IA ont tendance à ajouter des fonctionnalités. Ce prompt les oblige à faire l'inverse. Soyez impitoyable : la plupart des PRD de version un sont trop volumineux. Qu'est-ce qu'un MVP explique pourquoi de petites premières versions vous apprennent davantage.

User stories et critères d'acceptation

Écris chaque exigence sous forme de user story (« En tant que [utilisateur], je veux [action] afin de [résultat] ») avec deux à quatre critères d'acceptation au format Étant donné / Quand / Alors.

Les critères d'acceptation forment la liste de contrôle que vous utiliserez pour tester plus tard. « Étant donné un créneau réservé, quand un autre client consulte le calendrier, alors le créneau n'est pas affiché » est testable. « La réservation fonctionne bien » ne l'est pas.

Cas limites et droits d'accès

Pour chaque user story, liste ce qui se passe avec des données vides, une saisie invalide, une requête réseau lente ou échouée, et un utilisateur qui ne devrait pas avoir accès.

C'est là que l'IA est utile. Elle repère rapidement les états vides et les failles de droits d'accès que l'on oublie souvent.

Étape 4 : relisez-le en sceptique

Relisez l'ensemble une fois de plus et vérifiez :

• Chaque affirmation sur les utilisateurs vient de vous ou d'une étude, pas de l'IA.
• Le périmètre « exclu » est au moins aussi long que le périmètre « inclus ».
• Chaque user story a des critères d'acceptation que quelqu'un peut tester sans vous poser de questions.
• La section données liste chaque type d'enregistrement que l'application conserve et qui peut le voir.
• Les questions ouvertes ont un responsable et une date.
• Rien de technique ne s'est glissé, sauf s'il s'agit d'une vraie contrainte (« doit fonctionner hors ligne » est une exigence ; « utiliser Redis » ne l'est pas).

Puis faites-le relire par une personne qui utilisera ou construira le produit, et demandez-lui ce qui n'est pas clair. Ses questions révèlent les trous.

Modèle de PRD à remplir

Copiez ceci dans un document et remplacez les crochets. Supprimez les sections qui ne s'appliquent vraiment pas.

Nom du produit : [nom] Responsable : [personne responsable des décisions] Statut : [brouillon / en relecture / validé] — Dernière mise à jour : [date]

1. Résumé

[Deux ou trois phrases : ce que c'est, pour qui et le résultat principal.]

2. Problème

[Le problème du point de vue de l'utilisateur. Ce qu'il fait aujourd'hui et pourquoi c'est pénible.]

3. Utilisateurs

4. Objectifs et indicateurs de succès

• Objectif : [le résultat que la version un doit atteindre]
• Indicateur : [comment vous le mesurerez, et la cible]
• Non-objectif : [ce que les gens pourraient supposer, et que cette version ne cherche pas à faire]

5. Périmètre

Dans la version un :

• [fonctionnalité]
• [fonctionnalité]

Pas dans la version un :

• [fonctionnalité, et pourquoi elle peut attendre]
• [fonctionnalité, et pourquoi elle peut attendre]

6. User stories

Story 1 : En tant que [utilisateur], je veux [action] afin de [résultat].

• Étant donné [contexte], quand [action], alors [résultat].
• Étant donné [contexte], quand [action], alors [résultat].

Story 2 : En tant que [utilisateur], je veux [action] afin de [résultat].

• Étant donné [contexte], quand [action], alors [résultat].

7. Données

8. Droits d'accès

[Qui peut se connecter, quels rôles existent, et ce que chaque rôle peut voir et modifier.]

9. Cas limites

• [État vide : ce qui s'affiche quand il n'y a encore aucune donnée]
• [Saisie invalide : ce qui se passe avec une adresse e-mail incorrecte ou un champ manquant]
• [Accès : ce qui se passe quand quelqu'un ouvre une page qu'il ne devrait pas voir]

10. Intégrations et contraintes

[Paiements, e-mail, outils existants, délais, budget, appareils sur lesquels cela doit fonctionner.]

11. Questions ouvertes

Du PRD aux prompts

Un bon PRD se transforme presque directement en prompts pour un générateur d'applications par IA :

• Le résumé, les utilisateurs et le tableau des données deviennent votre premier prompt.
• Chaque user story devient un prompt de suivi.
• Chaque critère d'acceptation devient quelque chose que vous testez dans l'aperçu.
• La liste « pas dans la version un » est ce que vous refusez de demander pour l'instant.

Construire une story à la fois et vérifier ses critères d'acceptation avant de passer à la suivante est bien plus fiable que de coller tout le PRD en demandant tout d'un coup. Comment rédiger des prompts pour les générateurs d'applications par IA détaille davantage l'aspect prompts.

Erreurs courantes

• Écrire la solution à la place du problème. « Les utilisateurs ont besoin d'un tableau de bord » est une solution. « Les propriétaires ne peuvent pas voir quelles factures sont en retard sans ouvrir chacune d'elles » est un problème.
• Pas de section « hors périmètre ». Sans elle, chaque discussion rouvre le périmètre.
• Laisser l'IA inventer des utilisateurs. Les personas inventés par l'IA semblent réels et ne le sont pas.
• Des indicateurs impossibles à mesurer. Si vous ne pouvez pas le compter, ce n'est pas un indicateur.
• Ne jamais le mettre à jour. Un PRD qui ne correspond plus à ce que vous construisez est pire que pas de PRD du tout. Gardez une date de « dernière mise à jour » et modifiez-la quand les décisions changent.

Utiliser un PRD avec Mythex

Si vous construisez avec Mythex, vous pouvez coller votre PRD directement dans le chat. Commencer en mode Plan convient bien à un PRD : l'agent le lit, propose une approche et une liste d'étapes que vous examinez dans un onglet de plan, et ne modifie les fichiers qu'après que vous avez appuyé sur Build. Vous pouvez aussi enregistrer les éléments qui doivent toujours s'appliquer (public cible, marque, règles) comme connaissances du projet, pour ne pas les répéter dans chaque conversation. La documentation du chat explique les modes Build, Plan et Ask, et les modèles sont un moyen rapide de visualiser à quoi pourrait ressembler une première version avant de rédiger le document complet.

Questions