# Modèle de document d’exigences produit (PRD)

Six documents liés qui mènent une fonctionnalité du problème au lancement : pour qui elle est faite, ce qu’elle doit faire, son parcours, comment savoir qu’elle a marché, et chaque décision en chemin. Téléchargez-les en fichiers Markdown : ils s’ouvrent dans n’importe quel éditeur, affichent leur diagramme sur GitHub et dans Obsidian, et s’importent dans Nodary sous forme de carte.

Gratuit, sans compte, sans e-mail. Utilisez-le, modifiez-le, partagez-le.

[Télécharger le modèle (.zip)](https://nodary.ai/downloads/modele-prd.zip)

## Lisez chaque page avant de télécharger

La vue d’ensemble tient sur un écran et renvoie à cinq parties : le développement, le design et le support trouvent chacun leur page, et un changement reste petit. Les lignes en italique disent quoi écrire ; les exemples suivent une même fonctionnalité d’exemple, des liens de partage qui expirent.

- Document d’exigences produit: La page que tout le monde lit d’abord : le problème, les objectifs, ce qui est dedans et dehors, et un lien vers chaque partie.
- Utilisateurs et preuves: Pour qui est la fonctionnalité, ce que ces personnes font aujourd’hui sans elle, et la recherche derrière le problème.
- Exigences: Ce que la fonctionnalité doit faire, chaque exigence avec sa priorité et la vérification qui la prouve.
- Design et parcours: Comment l’utilisateur traverse la fonctionnalité : le parcours, les écrans, les états et les cas limites.
- Lancement et indicateurs: Comment savoir que cela a marché, comment la fonctionnalité est déployée, et ce qui vous ferait revenir en arrière.
- Décisions et questions ouvertes: Chaque décision qui a changé le PRD, avec qui l’a prise et pourquoi, et les questions encore ouvertes.

### Document d’exigences produit

_Mode d’emploi : les lignes en italique sont des consignes. Remplacez-les par vos propres mots, puis supprimez-les. Les valeurs entre crochets sont à remplir. Gardez cette page sur un écran : c’est ce qu’un lecteur pressé, un nouveau venu ou un agent IA lit en premier._

#### En bref

| Champ | Cette fonctionnalité |
| --- | --- |
| Fonctionnalité | [Nom] |
| En une phrase | [Ce que l’utilisateur peut faire une fois qu’elle est sortie] |
| Responsable produit | [nom] |
| Responsable technique | [nom] |
| Responsable design | [nom] |
| Statut | [brouillon, en relecture, approuvé, livré] |
| Version visée | [date ou version] |

#### Problème

_Qui a le problème, ce qu’il lui coûte aujourd’hui, et comment vous le savez. Un problème sans preuve est une supposition : liez la recherche dans_ [Utilisateurs et preuves](https://nodary.ai/fr/templates/prd#doc-users).

_Exemple (une fonctionnalité d’exemple) : Des personnes partagent un document avec un client pour relecture, puis oublient que le lien existe. Des mois plus tard, il s’ouvre toujours. Trois clients ont demandé le trimestre dernier comment faire cesser un lien à une date donnée._

[Le problème, en deux ou trois phrases]

#### Objectifs et non-objectifs

_Les objectifs disent ce qui change pour l’utilisateur, pas ce que l’équipe construit. Les non-objectifs sont les décisions qui empêchent le périmètre de grossir en silence._

- Objectif : [ce que l’utilisateur peut faire, ou n’a plus à faire]
- Objectif : [...]
- Non-objectif : [ce que cette version laisse de côté exprès]
- Non-objectif : [...]

#### Le succès en une ligne

_La mesure qui vous dira, un mois après le lancement, si cela a marché. La liste complète est dans_ [Lancement et indicateurs](https://nodary.ai/fr/templates/prd#doc-launch).

[Indicateur] passe de [valeur de départ] à [cible] d’ici [date].

#### Le reste du PRD

_Chaque partie est un document à part. Liez-la plutôt que de la recopier : chaque fait vit à un seul endroit et change à un seul endroit._

- [Utilisateurs et preuves](https://nodary.ai/fr/templates/prd#doc-users) : pour qui est la fonctionnalité, et la recherche derrière le problème
- [Exigences](https://nodary.ai/fr/templates/prd#doc-requirements) : ce qu’elle doit faire, avec priorités et critères d’acceptation
- [Design et parcours](https://nodary.ai/fr/templates/prd#doc-design) : le parcours, les écrans, les états et les cas limites
- [Lancement et indicateurs](https://nodary.ai/fr/templates/prd#doc-launch) : indicateurs, déploiement et liste de lancement
- [Décisions et questions ouvertes](https://nodary.ai/fr/templates/prd#doc-decisions) : ce qui a été décidé, par qui et pourquoi, et ce qui reste ouvert

_Ce modèle est libre d’utilisation, de modification et de partage. Il vient de_ [Nodary](https://nodary.ai/fr)_, où ces fichiers s’importent sous forme de carte de documents liés._

### Utilisateurs et preuves

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

_Pour qui est la fonctionnalité et ce que vous savez de ces personnes. Chaque affirmation ici doit renvoyer à sa source._

#### Pour qui

| Qui | Ce qu’il cherche à faire | Ce qui l’en empêche |
| --- | --- | --- |
| [Utilisateur principal] | [...] | [...] |
| [Utilisateur secondaire] | [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : Une chargée de compte partage un projet de proposition avec un client pour une semaine de commentaires. Aujourd’hui, elle se met un rappel pour couper le lien, et l’oublie parfois._

#### Aujourd’hui, sans la fonctionnalité

_Ce que font les utilisateurs aujourd’hui, étape par étape, contournements compris. Le contournement est souvent la meilleure spécification que vous aurez._

1. [Étape]
2. [Étape]
3. [Contournement]

#### Preuves

| Source | Ce qu’elle dit | Date | Lien |
| --- | --- | --- | --- |
| [Entretien client] | [...] | [date] | [...] |
| [Tickets de support] | [...] | [...] | [...] |
| [Données d’usage] | [...] | [...] | [...] |

#### Questions ouvertes

- [ ] [Question], [qui y répond], [pour quand]

Voir aussi : [Document d’exigences produit](https://nodary.ai/fr/templates/prd#doc-overview) · [Exigences](https://nodary.ai/fr/templates/prd#doc-requirements) · [Design et parcours](https://nodary.ai/fr/templates/prd#doc-design)

### Exigences

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

_Une ligne par exigence, écrite comme une chose que l’utilisateur peut faire. La priorité est indispensable, souhaitable ou possible : une version sort quand chaque exigence indispensable passe._

#### Récits utilisateur

| ID | En tant que | Je veux | Afin de | Priorité |
| --- | --- | --- | --- | --- |
| E1 | [utilisateur] | [...] | [...] | [indispensable, souhaitable, possible] |
| E2 | [...] | [...] | [...] | [...] |
| E3 | [...] | [...] | [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : E1. En tant que personne qui partage un document, je veux choisir le jour où un lien cesse de marcher, afin qu’un client perde l’accès à la fin du projet. Indispensable._

#### Critères d’acceptation

_Pour chaque exigence indispensable, les vérifications qui prouvent qu’elle marche. Écrivez-les pour qu’un testeur, ou un agent IA, puisse les dérouler sans vous demander._

| Exigence | Étant donné | Quand | Alors |
| --- | --- | --- | --- |
| E1 | [une situation de départ] | [une action] | [le résultat que quelqu’un peut vérifier] |
| E1 | [...] | [...] | [...] |

#### Exigences non fonctionnelles

| Domaine | Exigence |
| --- | --- |
| Performance | [...] |
| Sécurité et confidentialité | [...] |
| Accessibilité | [...] |
| Langues | [...] |
| Compatibilité | [navigateurs, appareils, versions] |

#### Hors périmètre

- [Ce que cette version ne fait pas, et pourquoi]
- [...]

#### Questions ouvertes

- [ ] [Question], [qui y répond], [pour quand]

Voir aussi : [Utilisateurs et preuves](https://nodary.ai/fr/templates/prd#doc-users) · [Design et parcours](https://nodary.ai/fr/templates/prd#doc-design) · [Lancement et indicateurs](https://nodary.ai/fr/templates/prd#doc-launch)

### Design et parcours

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

_Liez les fichiers de design plutôt que de les coller. Gardez ici le parcours et les décisions qui l’expliquent, pour que le texte et les écrans ne se contredisent jamais._

#### Parcours utilisateur

_Le chemin principal, de là où l’utilisateur part à ce qu’il obtient. Si l’équipe ne sait pas le dessiner, il n’est pas encore arrêté._

```mermaid
flowchart LR
  n0["Point d’entrée"]
  n1["Première action"]
  n2["Choix clé"]
  n3["Confirmation"]
  n4["Résultat"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
```
_Le parcours principal, de [où part l’utilisateur] à [ce qu’il obtient]_

#### Écrans

| Écran | Rôle | Lien vers le design | Statut |
| --- | --- | --- | --- |
| [Écran] | [...] | [...] | [croquis, maquette, final] |
| [Écran] | [...] | [...] | [...] |

#### États

_Chaque écran a plus d’états que le cas nominal. Cochez chacun une fois dessiné, ou écrivez pourquoi il ne peut pas arriver._

- [ ] Vide : rien à montrer pour l’instant
- [ ] Chargement
- [ ] Erreur, avec ce que l’utilisateur peut faire ensuite
- [ ] Pas les droits
- [ ] Connexion lente ou perdue
- [ ] Texte très long et très grands nombres

#### Cas limites

| Cas | Ce qui se passe |
| --- | --- |
| [...] | [...] |
| [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : Quelqu’un ouvre un lien une minute après sa date de fin : il voit que le lien a expiré et à qui le demander, jamais une page d’erreur._

#### Questions ouvertes

- [ ] [Question], [qui y répond], [pour quand]

Voir aussi : [Exigences](https://nodary.ai/fr/templates/prd#doc-requirements) · [Lancement et indicateurs](https://nodary.ai/fr/templates/prd#doc-launch)

### Lancement et indicateurs

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

_Un indicateur principal, deux ou trois secondaires, et un garde-fou : quelque chose qui ne doit pas se dégrader pendant que le principal progresse._

#### Indicateurs

| Indicateur | Type | Départ | Cible | Mesuré par | Date de revue |
| --- | --- | --- | --- | --- | --- |
| [...] | [principal] | [...] | [...] | [...] | [date] |
| [...] | [secondaire] | [...] | [...] | [...] | [...] |
| [...] | [garde-fou] | [...] | [...] | [...] | [...] |

#### Déploiement

| Étape | Qui l’a | Date | On passe à la suite quand |
| --- | --- | --- | --- |
| [Interne] | [l’équipe] | [...] | [...] |
| [Bêta] | [...] | [...] | [...] |
| [Tout le monde] | [...] | [...] | [...] |

#### Liste de lancement

- [ ] Article d’aide écrit
- [ ] Équipe support informée
- [ ] Note de version rédigée
- [ ] Événements d’analyse vérifiés
- [ ] Retour arrière testé

#### Retour arrière

_Ce qui vous ferait couper la fonctionnalité, et comment. Décidez-le avant le lancement, quand personne n’est encore attaché au résultat._

- On revient en arrière si : [...]
- Comment : [un drapeau, une version, un script]
- Qui décide : [nom]

Voir aussi : [Document d’exigences produit](https://nodary.ai/fr/templates/prd#doc-overview) · [Exigences](https://nodary.ai/fr/templates/prd#doc-requirements) · [Décisions et questions ouvertes](https://nodary.ai/fr/templates/prd#doc-decisions)

### Décisions et questions ouvertes

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

_Quand une décision change le PRD, ajoutez une ligne ici et mettez à jour la page concernée. Le journal dit pourquoi ; la page dit ce qui est vrai aujourd’hui._

#### Journal des décisions

| Date | Décision | Décidé par | Pourquoi | Page modifiée |
| --- | --- | --- | --- | --- |
| [date] | [...] | [...] | [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : Les liens marchent jusqu’à la fin de leur dernier jour dans le fuseau horaire de leur propriétaire, pas jusqu’à minuit UTC. Décidé par la responsable produit et le responsable technique, parce que des clients d’autres fuseaux perdaient l’accès un jour trop tôt pendant la bêta. Page modifiée : Exigences._

#### Questions ouvertes

| Question | Qui y répond | Pour quand | Réponse |
| --- | --- | --- | --- |
| [...] | [nom] | [date] | [...] |

Voir aussi : [Document d’exigences produit](https://nodary.ai/fr/templates/prd#doc-overview) · [Exigences](https://nodary.ai/fr/templates/prd#doc-requirements) · [Lancement et indicateurs](https://nodary.ai/fr/templates/prd#doc-launch)

## Comment s’en servir

### Écrivez le problème avant la solution

Remplissez d’abord le problème, les objectifs et les non-objectifs de la vue d’ensemble, avec le développeur et le designer qui feront la fonctionnalité. Si vous n’êtes pas d’accord tous les trois sur le problème, arrêtez-vous là.

### Rendez chaque exigence testable

Donnez à chaque exigence indispensable des critères d’acceptation que quelqu’un d’autre peut vérifier. Une exigence que personne ne peut tester est un souhait.

### Faites-le relire, puis tenez-le juste

Demandez une relecture quand les exigences sont prêtes, et mettez le PRD à jour quand une décision les change. Un PRD qui s’arrête au lancement du projet est faux au lancement du produit.

### Notez ce qui a changé et pourquoi

Chaque décision va dans le journal des décisions, avec qui l’a prise. Quand quelqu’un demande pourquoi la fonctionnalité marche ainsi, la réponse est à un lien.

## Importez-le dans Nodary en carte

Nodary est un espace de travail IA où les documents d’une équipe se relient au lieu de s’empiler. Importez le .zip : le PRD arrive avec ses cinq parties rangées sous lui, les liens entre les pages conservés et le diagramme dessiné. Passez-le en relecture et demandez à un propriétaire ou un administrateur de l’espace ou du projet de l’approuver, voyez ce qui a changé depuis votre dernière visite, et laissez les agents IA connectés par MCP lire les exigences avant d’écrire du code.

1. Ouvrez la carte d’un projet et choisissez Importer.
2. Choisissez l’onglet Dossier ou ZIP, puis Choisir un ZIP.
3. Sélectionnez le fichier téléchargé, vérifiez l’arborescence et importez.

L’offre gratuite compte dix documents par espace de travail, page du projet comprise : les six du modèle tiennent dans un nouvel espace, avec de la place pour trois autres. Nodary a aussi un modèle de spécification produit (PRD) d’une page intégré.

## Écrire un PRD dont l’équipe se sert vraiment

Un PRD échoue de deux façons : il décrit une solution que personne n’a questionnée, ou il cesse d’être mis à jour après le lancement du projet. Ces habitudes évitent les deux.

### Partez du problème

Écrivez qui a le problème et ce qu’il lui coûte avant toute solution. Les équipes d’accord sur le problème se disputent moins sur les écrans.

### Dites ce que vous ne ferez pas

Les non-objectifs sont aussi des décisions. Les écrire, c’est ce qui empêche une fonctionnalité de grossir d’une semaine à l’autre.

### Rendez les exigences testables

« Rapide » et « simple » ne se vérifient pas. « Le lien cesse de s’ouvrir dans la minute qui suit sa date de fin » se construit et se teste.

### Priorisez : indispensable, souhaitable, possible

Une version sort quand chaque exigence indispensable passe. Le souhaitable et le possible sont ce que vous échangez quand la date approche.

### Liez les preuves

Chaque affirmation sur les utilisateurs renvoie à l’entretien, au ticket ou aux données qui la fondent : un relecteur la vérifie au lieu de la croire.

### Faites-le vivre

Mettez le PRD à jour quand une décision le change, et notez pourquoi. À la fin, il doit décrire ce qui est sorti, pas ce qui était prévu la première semaine.

## Questions sur le PRD

### Qu’est-ce qu’un PRD ?

Un PRD (product requirements document, ou document d’exigences produit) décrit une fonctionnalité ou un produit avant sa fabrication : le problème qu’il résout, pour qui, ce qu’il doit faire, comment on mesure le succès et ce qui est hors périmètre. Un product manager en est souvent responsable ; développeurs, designers, support et, de plus en plus, agents IA de code le lisent.

### Que doit contenir un PRD ?

Au minimum le problème et ses preuves, les objectifs et non-objectifs, les utilisateurs, des exigences priorisées avec leurs critères d’acceptation, les parcours principaux et les cas limites, les indicateurs de succès, le plan de déploiement et un journal des décisions et des questions ouvertes. Ce modèle a un document pour chaque groupe.

### Quelle longueur doit faire un PRD ?

Assez pour que l’équipe construise et teste la fonctionnalité sans vous poser deux fois la même question. La vue d’ensemble doit tenir sur un écran ; les exigences grandissent avec les décisions, pas avec les idées.

### Quelle différence entre un PRD et un document de conception technique ?

Le PRD dit ce que la fonctionnalité doit faire et pourquoi. Le document de conception technique dit comment le système le fera : architecture, données, interfaces et risques. Écrivez d’abord le PRD, puis reliez les deux.

### Les agents IA peuvent-ils se servir du PRD ?

Oui. Un PRD en documents liés donne à un agent le contexte dont il a besoin. Dans Nodary, les agents connectés par MCP, comme Claude, ChatGPT ou Cursor, lisent les exigences et le journal des décisions avec vos droits avant d’écrire.

### Puis-je utiliser le modèle hors de Nodary ?

Oui. Les fichiers sont en Markdown : Obsidian ouvre le dossier décompressé comme un coffre avec tous ses liens, et GitHub affiche les fichiers avec leur diagramme. Les outils qui importent le Markdown fichier par fichier gardent le texte et les tableaux ; vérifiez comment ils traitent les liens entre fichiers.

La page : https://nodary.ai/fr/templates/prd