Aller au contenu
Nodary
Commencer gratuitement

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.

Télécharger le modèleOuvrir la démo

6 fichiers Markdown dans un .zip, 8 ko

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

Document d’exigences produitUtilisateurs et preuvesExigencesDesign et parcoursLancement et indicateursDécisions et questions ouvertes

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.

Documents

Fichier Modèle de PRD/Document d’exigences produit.md

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

ChampCette 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.

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.

[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.

Ce modèle est libre d’utilisation, de modification et de partage. Il vient de Nodary, où ces fichiers s’importent sous forme de carte de documents liés.

Télécharger le modèle6 fichiers Markdown dans un .zip, 8 ko

Comment s’en servir

  1. É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à.

  2. 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.

  3. 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.

  4. 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é.

Nodary pour les équipes produit et techniques
Une vue tableau en direct dans Nodary qui range les documents par statut (brouillon, en relecture, terminé, bloqué), chaque carte avec sa personne assignée et son échéance ; le projet d’exemple montré est un jeu.

É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.

À lire ensuite

Gardez les exigences là où l’équipe travaille.

Importez le modèle dans Nodary et le PRD devient une carte que votre équipe et vos agents IA tiennent à jour. Gratuit avec deux membres, un projet et dix documents, sans carte bancaire.

Commencer gratuitementOuvrir la démoTélécharger le modèle