Modèle gratuit

Modèle de PRD gratuit, conçu pour être vérifié

Un document d’exigences produit à partir duquel une équipe peut construire, et qu’un auditeur peut vérifier. Problème, utilisateurs, périmètre, exigences numérotées avec critères d’acceptation, et ce que vous choisissez de ne pas faire. À copier ou télécharger en Markdown.

Voir le modèleLe faire avec Atrix AI

Gratuit · Markdown · sans inscription

Quand l’utiliser

Rédigez le PRD avant que quiconque n’ouvre un éditeur, et gardez-le assez court pour qu’on le lise. C’est le document auquel tout le reste du travail se réfère.

  • Avant la première ligne de code d’un nouveau produit ou d’une grosse fonctionnalité

  • Quand vous confiez le développement à un prestataire, un studio ou un agent de code

  • Quand deux personnes ne sont pas d’accord sur le contenu de la première version

  • Avant un audit, pour qu’il existe une base convenue à auditer

Le modèle

Le modèle complet

Tout ce qui suit est inclus quand vous le copiez ou le téléchargez. Remplacez les blancs entre [crochets] et supprimez les conseils au fur et à mesure.

Exigences produit : [Nom du produit]

Remplacez tout ce qui est entre [crochets] et supprimez chaque ligne d’aide une fois sa section rédigée. Le document est terminé quand une personne extérieure pourrait construire la première version à partir de lui, et qu’une autre pourrait vérifier qu’elle l’a fait.

01Vue d’ensemble

Deux ou trois lignes. Si vous ne pouvez pas dire aussi brièvement ce que c’est et pour qui, le reste du document n’y changera rien.

  • Produit: [Nom]
  • Responsable: [La personne qui tranche les questions de périmètre]
  • Statut: [Brouillon / En relecture / Validé]
  • Dernière mise à jour: [Date]
  • En une phrase: [Ce que c’est, pour qui, et ce que cela remplace]

02Problème

Décrivez le problème tel que l’utilisateur le vit, pas comme une fonctionnalité manquante. Dites ce qu’il fait aujourd’hui à la place, et comment vous le savez.

Aujourd’hui, [qui] [utilise quel contournement] lorsqu’il doit [accomplir quelque chose]. Cela lui coûte [du temps, de l’argent ou un risque réellement observé].

Éléments probants: [Entretiens, demandes au support, appels commerciaux, votre propre usage. Précisez lesquels et combien.]

03Utilisateur cible

Un seul utilisateur principal. Nommez le moment où il se met à chercher une solution, et pour qui ce n’est pas fait.

  • Utilisateur principal: [Rôle, taille d’entreprise, contexte]
  • Déclencheur: [L’événement qui le pousse à chercher autre chose]
  • Alternative actuelle: [Tableur, autre outil, une personne, rien]
  • Pas pour: [Qui n’est volontairement pas servi, et pourquoi]

04Jobs to be done

Ce que l’utilisateur cherche à accomplir, avec ses mots. Trois à cinq, le plus important d’abord.

  • Job 1: Quand [situation], je veux [action] pour pouvoir [résultat].
  • Job 2: Quand [situation], je veux [action] pour pouvoir [résultat].
  • Job 3: Quand [situation], je veux [action] pour pouvoir [résultat].

05Périmètre du MVP

Ce que fait la première version. Chaque ligne doit être quelque chose qu’on peut voir fonctionner.

  • [Première capacité sans laquelle on ne peut pas livrer]
  • [Deuxième capacité]
  • [Troisième capacité]

06Exigences

Une affirmation vérifiable par ligne. L’acceptation dit comment la vérifier sur le produit en service ; une exigence sans acceptation ne peut pas être auditée. La priorité suit MoSCoW : Must, Should, Could, Won’t. Le type est fonctionnel (comportement), non fonctionnel (vitesse, disponibilité, accessibilité) ou contrainte (réglementation, plateforme ou budget).

Les identifiants sont définitifs. Ne les renumérotez ni ne les réutilisez jamais : tâches, commits et audits y font référence.

IdentifiantExigenceAcceptationPrioritéType
REQ-001Les utilisateurs peuvent [faire quelque chose d’observable][Étapes qui le montrent sur un système en service]MustFonctionnelle
REQ-002[Page ou action] répond en moins de [durée] sous [charge][Comment et où c’est mesuré]ShouldNon fonctionnelle
REQ-003[Limite réglementaire, de plateforme ou de budget][Preuve qu’elle est respectée]MustContrainte
REQ-004[Élément cité mais reporté][Comment on le vérifierait plus tard]Won’tFonctionnelle

07Indicateurs de succès

Comment vous saurez que la version a fonctionné. Nommez l’indicateur, l’outil de mesure et la cible. Laissez la cible vide plutôt que de l’inventer.

  • Indicateur principal: [Quoi] mesuré dans [outil], cible [valeur, ou fixée après une mesure de référence]
  • Indicateur secondaire: [Quoi] mesuré dans [outil], cible [valeur]
  • Garde-fou: [Un chiffre qui ne doit pas se dégrader, comme le taux d’erreur ou les remboursements]

08Non-objectifs

Ce que cette version ne fait volontairement pas. C’est la section qui évite le plus de débats.

  • [Un élément que tout le monde croira inclus, et pourquoi il ne l’est pas]
  • [Un deuxième non-objectif]

09Questions ouvertes

Tout ce qui reste à décider, avec une personne et une date. Une question sans responsable reste ouverte.

  • [Question] (responsable : [nom], pour le : [date])
  • [Question] (responsable : [nom], pour le : [date])

10Validation

Qui a validé cette version. Ensuite, un changement de périmètre se propose et se consigne ; il ne se glisse pas en douce.

  • Validé par: [Noms]
  • Validé le: [Date]
  • Changer le périmètre: [Comment proposer un changement, et où il est consigné]

Atrix AI

Le faire avec Atrix AI

Le mode Develop rédige ce document à partir du brief, des idées et des pages de votre projet, puis le garde utile après le premier jet.

  • Rédiger les exigences

    L’agent écrit le PRD dans votre espace de travail : problème, utilisateur cible, jobs to be done, périmètre du MVP, indicateurs de succès et non-objectifs. Une exécution, et il met à jour le même document au lieu d’en empiler des copies.

  • En faire des lignes vérifiables

    Atrix extrait chaque engagement sous forme d’exigence identifiée, avec acceptation et priorité MoSCoW, en citant la phrase d’origine. Tout reste à l’état de proposition jusqu’à votre validation.

  • Planifier et transmettre

    Les exigences validées deviennent des tickets sur votre tableau, et le paquet de transmission remet à un agent de code les documents et les identifiants, pour que le travail puisse être audité ensuite.

FAQ

Vos questions, nos réponses

Que doit contenir un PRD ?

Le problème et qui le rencontre, ce que l’utilisateur cherche à accomplir, le contenu de la première version, des exigences numérotées avec un moyen de vérifier chacune, des indicateurs de succès, des non-objectifs, les questions ouvertes et qui l’a validé. Ce modèle a une section pour chaque point.

Quelle longueur pour un PRD ?

Le plus court possible, tant que quelqu’un peut construire la première version sans vous poser de questions. Pour la plupart des premières versions, deux à cinq pages. Ce qui allonge un PRD, c’est souvent la description de solutions : restez sur les problèmes et les exigences vérifiables.

Pourquoi chaque exigence a-t-elle besoin de critères d’acceptation ?

Parce que sans eux personne ne peut dire si l’exigence est satisfaite. L’acceptation décrit comment la vérifier sur le produit en service : c’est ce qui fait d’un document quelque chose qu’un audit peut tester.

Puis-je l’utiliser dans Notion, Google Docs ou GitHub ?

Oui. C’est du Markdown simple : il se colle proprement dans tout éditeur compatible et se lit bien comme fichier dans un dépôt, à côté du code.

Le modèle est-il gratuit ?

Oui. Copiez-le ou téléchargez-le sans créer de compte. Atrix AI est facultatif : il rédige et tient le document à jour pour vous si vous le souhaitez.

Continuer la visite

Pilotez toute l’entreprise depuis un seul endroit.

Commencez avec l’offre gratuite. Ajoutez votre équipe, votre agenda et votre code quand vous êtes prêt.

Commencer gratuitementVoir les tarifs