Rédiger un PRD : Guide complet en 10 étapes + Prompts IA

Dans ce guide, nous allons vous aider à créer un excellent PRD avec des objectifs clairs, des exigences détaillées et un plan d’action réfléchi. De plus, pour vous faire gagner un temps précieux, nous mettons à votre disposition une série de prompts LLM qui généreront la majeure partie de votre PRD (ou vous fourniront au moins une solide première version !).

Qu’est-ce qu’un Product Requirements Document (PRD) ?

En résumé, un document de spécification produit détaille les fonctionnalités et caractéristiques qui doivent impérativement être incluses dans une version donnée du produit. Il sert de point de référence central pour toutes les équipes impliquées dans la conception et le développement d’un produit donné. Il est également indispensable pour l’élaboration de la feuille de route produit.

Traditionnellement utilisé dans un environnement de projet suivant la méthodologie Waterfall — où le développement du produit se fait de manière séquentielle — il peut également être employé dans la gestion produit Agile.

D'autres documents peuvent être élaborés à partir des informations recueillies dans le PRD. L’ingénierie peut créer un Document de spécifications techniques détaillant les spécifications du produit et les besoins système.

Les analystes métier peuvent rédiger un Document des exigences fonctionnelles expliquant ce qui se passe lorsqu’un utilisateur interagit avec le système, y compris des wireframes pour illustrer la conception du produit. 

Les designers expérience utilisateur (UX) peuvent rédiger un Document des exigences de l’interface utilisateur expliquant l’aspect et les sensations souhaités pour le produit.

Quels sont les bénéfices de rédiger un PRD et que contient-il ?

Rédiger un PRD complet présente plusieurs avantages. Voyons-en quelques-uns :

1. Il aligne tous les acteurs concernés sur une vision commune.
2. Il précise clairement ce qui est hors du périmètre.
3. Il favorise la collaboration entre équipes.
4. Il place le point de vue du client au cœur du produit.

En ce qui concerne la structure, un PRD typique doit contenir les éléments suivants :

• Métadonnées du document telles que la date de modification, l’historique des versions, etc.
• Les objectifs du produit que vous souhaitez atteindre.
• Données de recherche client, telles que les personas cibles.
• Liste priorisée des fonctionnalités que vous souhaitez développer.
• Périmètre négatif des fonctionnalités qui ne seront pas développées.
• Métriques clés pour tester ces hypothèses.
• Principales hypothèses que vos fonctionnalités testent.
• Stratégie de mise en production indiquant quand et comment la fonctionnalité sera livrée.

Bien que la plupart des PRD contiennent ces éléments, il est tout à fait acceptable d’ajouter ou de retirer des éléments selon vos besoins et la réalité de votre produit.

Quel est un exemple de cahier des charges produit ?

Parfois, il est plus facile de comprendre ce qui doit figurer dans un document à l’aide d’un visuel. Voici donc un exemple de PRD complété.

Comment rédiger un cahier des charges produit (avec un peu d’aide des LLMs)

Même avec toutes les informations que nous avons déjà partagées, rédiger votre premier PRD peut sembler intimidant. Pas de panique, nous sommes là pour vous ! Voici notre checklist en 10 étapes pour l’IA dans la collecte des exigences et pour créer un PRD solide. En plus, nous vous proposons même un modèle pour vous aider à rassembler toutes les informations essentielles.

Unlock the Product Vault

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Étape 1 : Clarifier le problème

Avant toute chose, il est crucial de bien identifier le problème que vous essayez de résoudre et les personas utilisateurs concernés. Cela aura un impact sur les fonctionnalités à inclure dans le produit et sur les priorités de développement pour la version à venir. 

Le Business Requirements Document doit contenir une expression du besoin précisant le problème à résoudre et la façon dont le produit devrait agir pour y répondre. Examiner le BRD et clarifier les attentes de l’entreprise à propos du produit est une étape importante avant de rédiger le PRD.

Étape 2 : Analyser l’étude de marché et la recherche utilisateur

Au moment de rédiger votre PRD, vous devez déjà disposer de votre étude de marché et de vos personas. Mais parfois, le persona associé à une fonctionnalité spécifique peut différer de celui qui correspond à l’ensemble du produit. Donc, si c’est votre cas, générons une description du persona avec cette commande LLM :

Voici des transcriptions de plusieurs entretiens de découverte produit que j’ai menés avec mes utilisateurs.

{téléchargez vos transcriptions sous forme de fichiers txt dans ce message}

Merci d’examiner ces transcriptions, d’analyser les traits communs et de générer une description de persona en suivant cette structure (délimitée par des balises XML) :


<USER_PERSONA_STRUCTURE>

1. Nom :

(Fictionnel mais réaliste, par ex. Anna, la comptable débordée)

2. Démographie :

    •    Âge
    •    Sexe (optionnel)
    •    Lieu de résidence
    •    Profession

3. Objectifs :
    •    Objectif(s) principal(aux) recherché(s)
    •    Objectifs secondaires ou connexes

4. Défis/Points de douleur :
    •    Principaux obstacles rencontrés
    •    Frustrations ou besoins

5. Comportements :
    •    Habitudes, préférences, modes d’utilisation pertinents

6. Outils/Plateformes préférés :
    •    Applications, sites web, appareils utilisés fréquemment

7. Une courte citation (optionnelle mais puissante) :

Une phrase résumant leur ressenti vis-à-vis de leurs besoins.

(Exemple : « Je veux juste un système qui me fasse gagner du temps sans que j’aie besoin d’un manuel. »)

</USER_PERSONA_STRUCTURE>


Exemple :

Nom : Anna, la comptable débordée

Démographie : 34 ans, habite à Chicago, CPA dans un petit cabinet

Objectifs : Terminer le travail client plus vite, réduire les tâches administratives manuelles

Défis : Trop de paperasse, logiciels inefficaces, pression temporelle

Comportements : Travaille tard pendant la période fiscale, préfère des applications simples et accessibles sur mobile

Outils préférés : QuickBooks, Slack, Google Drive

Citation : « Si ce n’est pas simple, je n’ai pas le temps. »


Exigences pour la génération du persona :

- Veuillez n’utiliser que les informations fournies dans les transcriptions et ne pas inventer d’informations absentes.

- Utiliser uniquement les caractéristiques présentes dans au moins 80 % des transcriptions partagées.

- Si vous ne trouvez pas assez d’informations pour une catégorie du persona, laissez-la vide.

En résultat, vous obtiendrez une description de persona que vous pourrez inclure dans votre cahier des charges produit. Mais veuillez bien vérifier le contenu généré par le LLM, car il peut comporter des erreurs.

Étape 3 : Impliquez les acteurs fonctionnels

Comme nous l’avons mentionné, les meilleurs cahiers des charges produits sont élaborés de manière collaborative. Organisez une réunion interfonctionnelle pour recueillir l’avis de différents secteurs de l’entreprise afin d’alimenter votre document de besoins. 

C’est une excellente occasion pour les parties prenantes de signaler les hypothèses, de soulever des risques ou contraintes ou de notifier toute dépendance pouvant avoir un impact sur le processus de développement produit. 

Étape 4 : Définissez votre hypothèse centrale et vos indicateurs de produit

Quel que soit le type de fonctionnalité que vous développez, vous attendez qu’elle ait un certain impact sur vos utilisateurs ou votre entreprise. Pour pouvoir mesurer cet impact et vérifier si votre fonctionnalité est un succès ou non, il vous faut d’abord formuler une hypothèse testable.

Mon format d’hypothèse préféré s’appelle « Si-alors-parce que ». Il ressemble à ceci :

Nous pensons que si nous [développons la fonctionnalité A], alors [l’indicateur clé B] va [augmenter/diminuer] de [C quantité] parce que [expliquez pourquoi].

Par exemple, si je travaille chez Spotify, cela pourrait donner ceci.

Nous pensons que si nous développons des playlists de routine du matin, alors la rétention quotidienne augmentera de 5 % parce que davantage d’utilisateurs se serviront de Spotify chaque matin.

Pour automatiser ce processus avec l’IA, expliquez simplement avec vos mots ce que vous attendez de la fonctionnalité et demandez-lui de le formuler dans le format « si-alors-parce que ». Voici l’invite :

{insérez ici votre explication de fonctionnalité}

Veuillez formuler une hypothèse avec le format si-alors-parce que.

Exigences :

- L’hypothèse ne doit pas dépasser 100 mots.

- Merci d’utiliser uniquement le contexte que j’ai fourni.

Une fois l’hypothèse prête, vous devez également définir les indicateurs produits à mesurer pour la fonctionnalité.

Évidemment, vous voulez mesurer l’indicateur ciblé par votre hypothèse (la rétention dans le cas Spotify). Mais il existe aussi trois indicateurs clés à prévoir pour toute fonctionnalité :

• Adoption
• Rétention
• Engagement

Vous pouvez demander à l’IA de vous aider à choisir les bons indicateurs ainsi que les événements que votre outil d’analytics devra déclencher pour mesurer ces métriques. Voici une suggestion d’invite :

{insérez ici votre explication de fonctionnalité}

Voici l’hypothèse :

{insérez ici votre hypothèse du prompt précédent}

Merci de suggérer des indicateurs à suivre ainsi que leurs déclencheurs d’événement. Merci de proposer des indicateurs dans ces catégories :

- Adoption

- Rétention

- Engagement

Considérez que j’ajouterai ces indicateurs dans le cahier des charges produit pour la fonctionnalité que j’ai décrite.

Dans notre exemple Spotify, les indicateurs seraient les suivants :

Adoption : % d’utilisateurs ayant démarré une playlist du matin. Déclencheur d’événement : au lancement de la playlist par l’utilisateur.

Rétention : % d’utilisateurs qui utilisent la playlist du matin depuis 7, 14 et 30 jours. Déclencheur d’événement : au lancement de la playlist par l’utilisateur.

Engagement : Moyenne de minutes d’écoute de la playlist. Déclencheurs d’événement : démarrage et arrêt de la playlist.

Étape 5 : Préparez vos designs

Aucun PRD n'est complet sans design—si la fonctionnalité le nécessite. Certaines équipes joignent les designs finaux ; d'autres préfèrent inclure uniquement des concepts de haut niveau ou un prototype, en affinant les détails plus tard avec l'équipe.

Les deux approches ont leurs avantages et inconvénients. Les designs finaux offrent de la clarté mais ralentissent la livraison du PRD. Les concepts préliminaires accélèrent le transfert mais risquent d'être mal interprétés et de nécessiter des retouches.

Le juste milieu ? Partagez des designs qui couvrent le parcours utilisateur principal et les états majeurs, en évitant les éléments mineurs comme les états vides ou d’erreur. Heureusement, les outils de conception UX modernes permettent d’obtenir à la fois un prototype et un design en même temps.

Ainsi, vous livrez votre design et votre PRD à votre équipe plus tôt tout en minimisant le risque d’ambiguïté.

Étape 6 : Divisez votre idée en fonctionnalités indépendantes

Je pense que je n'ai pas besoin d'expliquer aux PM expérimentés les avantages de décomposer une grande fonctionnalité en histoires utilisateurs plus petites et faciles à gérer. Si vous êtes nouveau dans la gestion de produit, voici quelques avantages :

• Les petites histoires sont plus faciles à estimer pour votre équipe.
• Elles sont plus simples à livrer car l'équipe peut se concentrer sur une histoire à la fois et les terminer sans difficulté.
• Les tests sont plus rapides car vos QAs peuvent tester une histoire pendant que l’équipe travaille sur la suivante — ce qui permet de paralléliser le travail des testeurs et des développeurs.
• Vous donne la flexibilité d’écarter les histoires les moins importantes de la portée pour accélérer la livraison.

Décomposer la fonctionnalité est un excellent début, mais ce n'est que la moitié du travail. L’autre moitié consiste à les prioriser. Toutes les histoires ne se valent pas. Certaines parties de votre fonctionnalité représentent le parcours principal, tandis que d'autres sont des options supplémentaires agréables à avoir. Dans notre exemple Spotify, voici à quoi ressemblera la liste des histoires importantes et moins importantes avec la méthode de priorisation MoSCoW.

En regardant la liste ici, il est clair que la possibilité pour les utilisateurs de voir la playlist du matin et d'y accéder en un seul tap est bien plus importante que la possibilité de modifier la playlist.

Ainsi, si vous devez livrer rapidement à cause de contraintes temporelles, vous pouvez retirer l’histoire d’édition de la version et la reporter à des versions futures.

Certaines personnes élaborent cette liste sur un tableur. Mais je recommande d’utiliser un outil dédié de planification de roadmap produit car il propose également des fonctionnalités natives pour la priorisation et l’intégration.

Étape 7 : Définir la stratégie de mise en production

Dans la vie réelle, les mises en production sont rarement simples — terminer toute la fonctionnalité puis la déployer en production. La plupart du temps, la livraison d’une grande fonctionnalité (justifiant son propre PRD) se déroule en plusieurs phases et peut inclure les étapes suivantes :

• Développer une version MVP contenant uniquement les histoires incontournables et effectuer une mise en bêta.
• Recueillir les retours, corriger les problèmes, ajouter les histoires recommandées et préparer la mise en production.
• Procéder à un déploiement progressif en production, par étapes.
• Ajouter les fonctionnalités facultatives si un besoin se manifeste.

Pour accélérer l’élaboration d’une stratégie de mise en production, vous pouvez demander de l’aide à votre LLM en utilisant cette suggestion.

Je souhaite construire {insérez ici l'explication de votre fonctionnalité}.

Voici une liste d'histoires utilisateur pour cette fonctionnalité, priorisée à l'aide de la méthode MoSCoW :

{insérez ici la liste des fonctionnalités de l'étape précédente}

Veuillez créer une stratégie de mise en production pour celle-ci. La stratégie doit :

- Regrouper les fonctionnalités listées ci-dessus en plusieurs versions, y compris la version MVP.

- Si vous le jugez nécessaire, inclure une phase de version bêta

- Si vous le jugez nécessaire, inclure un déploiement progressif en 2 phases ou plus avec leurs calendriers, les pourcentages d'utilisateurs concernés à chaque phase, ainsi qu'une description des types d'utilisateurs inclus dans chaque phase de déploiement.

Critères pour décider si une version bêta est nécessaire (au format CSV, délimité par des balises XML) :

<BETA_RELEASE_CRITERIA>

Critère,Publication de la version bêta,Publication directe en production

Risques pour l’utilisateur,Moyen à élevé – impact utilisateur incertain ou risque potentiel de régressions,Faible – la fonctionnalité est bien testée et à faible risque pour les utilisateurs

Maturité de la fonctionnalité,MVP ou expérimental ; peut manquer de finition ou d’UX complète,Entièrement développée et stable

Besoins en retours,Élevés – retour utilisateur précoce crucial pour valider l’orientation ou les choix d’UX,Faibles – la valeur et l’ergonomie de la fonctionnalité sont assurées

Confiance QA,Modérée – nécessite des tests en conditions réelles pour compléter le QA interne,Élevée – testé de façon approfondie en interne

Incertitude de l’impact business,Incertitude quant à l’impact sur les KPIs clés (rétention, conversion, etc.),Impact attendu positif ou neutre, validé au préalable

</BETA_RELEASE_CRITERIA>

Critères pour décider si un déploiement progressif est nécessaire (au format CSV, délimité par des balises XML) :

<GRADUAL_RELEASE_CRITERIA>

Critère,Déploiement progressif,Déploiement intégral immédiat

Risques pour l’utilisateur,Élevés – la fonctionnalité pourrait causer des régressions, des bugs, ou de la confusion en cas de large déploiement,Faibles – perturbation utilisateur minimale même en cas de souci inattendu

Risque de charge système,Élevé – la fonctionnalité peut augmenter la charge serveur ou backend ; comportement de montée en charge inconnu,Faible – les performances sont validées avec les charges de pointe attendues

Périmètre du changement,Grand – impacte des parcours critiques, des flux cœur UX ou la logique backend,Petit – autonome, optionnel ou périmètre limité

Préparation au monitoring,Les métriques, alertes et logs sont prêts pour détecter les incidents sur de petits cohortes,Non essentiel – risque faible de panne silencieuse ou régression difficilement détectable

Complexité du rollback,Élevée – difficile à revenir après déploiement total (ex : migrations de schéma, changements de données),Faible – facile à désactiver ou à corriger en cas de problème

</GRADUAL_RELEASE_CRITERIA>

Il est très probable que les calendriers proposés par le LLM soient irréalistes. N'hésitez donc pas à les ajuster en fonction de la capacité de votre équipe et de vos objectifs produits.

Étape 8 : Rédiger le PRD

À partir des informations recueillies à l'étape précédente, vous pouvez désormais rédiger le PRD.

Encore une fois, pour gagner du temps, nous allons demander à notre LLM préféré de la faire pour nous à l'aide de cette consigne.

Veuillez créer un Document de Spécification Produit (PRD) en utilisant cette structure (délimitée par des balises XML) :


<PRD_STRUCTURE>

1. Objectif

    - Vision
    - Objectifs
    - Persona(s)

2. Fonctionnalités (tableau avec les colonnes suivantes)

    - Nom court de l’histoire utilisateur
    - Brève description de l’histoire utilisateur
    - Priorité de l’histoire utilisateur

3. Parcours utilisateur et design

    - Laissez un texte de remplacement ici "veuillez insérer ici votre parcours utilisateur et les liens vers le design"

4. Stratégie de mise en production

    - Phases de mise en production avec périmètre. Incluez une version bêta si j’en ai fourni une ci-dessous dans le contexte de la publication
    - La stratégie de déploiement progressif si j’en ai fourni une ci-dessous dans le contexte de la publication. Si un déploiement progressif est pertinent, incluez les pourcentages d’utilisateurs concernés à chaque phase, ainsi qu'une description des types d’utilisateurs inclus dans chaque phase de déploiement.

5. Analytique

    - Hypothèses principales
(tableau contenant ces colonnes)
    - Indicateur
    - Objectif de variation
    - Déclencheur de l'événement

</PRD_STRUCTURE>


Veuillez utiliser ces éléments de contexte pour générer le PRD (délimités par des balises XML) :

<USER_PERSONAS>

{insérez ici la description du persona}

</USER_PERSONAS>


<CORE_HYPOTHESIS>

{copiez et collez ici l’hypothèse de base des étapes précédentes}

</CORE_HYPOTHESIS>


<KEY_METRICS>

{copiez et collez ici la liste des indicateurs clés des étapes précédentes}

</KEY_METRICS>


<USER_STORIES>

{copiez et collez ici la liste des histoires utilisateur des étapes précédentes}

</USER_STORIES>


<RELEASE_STRATEGY>

{copiez et collez ici la stratégie de mise en production des étapes précédentes}

</RELEASE_STRATEGY>

Il ne vous reste plus qu’à relire rapidement le contenu du PRD. Portez particulièrement attention à la vision et aux objectifs, car le LLM essaiera de les générer en se basant sur la description de votre fonctionnalité. Si cela ne vous convient pas, n’hésitez pas à corriger.

Étape 9 : Obtenir une validation

Une fois le PRD finalisé, assurez-vous qu’il soit validé par le client. Pour un projet interne, cela peut être le sponsor du projet ou la direction. Cela permet de garantir l’alignement business et le soutien au processus de développement produit. 

L'approbation des critères de mise en production est essentielle pour lever toute ambiguïté sur ce que le produit pourra vraiment faire en termes de fonctionnalités, d’utilisabilité et de performance à la fin du processus de développement.

Étape 10 : Partager et communiquer

Après validation du PRD, partagez l’endroit où il sera stocké et communiquez le processus d’accès, de consultation et de modification du PRD au cours du cycle de vie du développement produit. 

Le PRD finalisé doit être utilisé comme point de référence tout au long du projet et peut être mis à jour en temps réel si les exigences évoluent. Toutefois, il doit toujours être possible d’identifier ce qui avait été initialement convenu et chaque modification doit être bien documentée et accompagnée d'une justification.

Meilleures pratiques pour les documents d'exigences produit

Nous espérons avoir clarifié ce qu’un PRD doit contenir, alors passons maintenant à quelques meilleures pratiques pour le rédiger efficacement.

• Recueillez les avis des parties prenantes. Les meilleurs PRD sont rédigés avec la contribution de toutes les parties prenantes clés. Il ne sert à rien d’établir une longue liste de fonctionnalités essentielles si les ingénieurs expliquent ensuite qu’elles ne sont pas réalisables. Impliquer les autres équipes dès le début apporte de la clarté et permet d’identifier les hypothèses, contraintes et dépendances.
• Tirez parti des outils modernes. Heureusement, de nombreux outils de documentation orientés logiciels peuvent nous aider à la création et à la gestion des PRD. Notion, par exemple, propose des modèles de PRD prêts à l’emploi et permet d’utiliser des tableaux à la mise en forme enrichie pour lister vos hypothèses ou fonctionnalités. Confluence, quant à lui, intègre nativement Jira et BitBucket, vous permettant d’intégrer des tâches et des livraisons dans le document.

• Itérez selon les besoins. Le PRD est conçu pour être un document évolutif. L’évolution des besoins des clients ou du marché peut conduire à renforcer, réorganiser ou supprimer certaines capacités produit. Le calendrier peut aussi devoir être raccourci pour assurer une position de premier sur le marché ou rallongé si une hypothèse ne se vérifie pas.

• Utilisez le contrôle des versions. Il est important que le PRD soit relu et mis à jour selon les besoins, mais il est essentiel que le chef de produit puisse toujours revenir à ce qui avait initialement été convenu. L'utilisation du contrôle des versions et l’attribution des niveaux d’accès appropriés garantissent qu’il existe toujours un historique des accords initiaux, des modifications effectuées et de leurs justifications.

• Gardez-le visible. Un PRD n’est pas un document à usage unique destiné à finir oublié dans un tiroir après la réunion de planification du projet : c’est un atout essentiel pour la gestion de projet. Comme nous l’avons évoqué, votre PRD sert de point de référence pour tous les membres de l’équipe travaillant sur le produit, il est donc indispensable qu’il reste à portée de tous. 

More Articles

• L’IA dans la recherche utilisateur : comment l’IA transforme la compréhension des utilisateurs
• Livraison de produits pensés pour le global sans casse-tête mondial : comment intégrer la localisation dans votre workflow produit
• L’IA dans la planification de sprint : Comment l’IA améliore l’efficacité de l’équipe

Modèle de document d'exigences produit

Pour conclure, voici un modèle de PRD à utiliser pour rédiger dès aujourd’hui votre premier document d’exigences produit. 

Pensez à le personnaliser selon les besoins de votre projet, en ajoutant ou supprimant des sections pour gagner en clarté.

Modèle de document d’exigences produit

Gagnez en clarté sur vos exigences produit dès aujourd’hui

Si vous avez suivi attentivement les informations ci-dessus, vous êtes bien parti pour créer un excellent document d’exigences produit.

Cela peut demander un peu de travail en amont, mais les bénéfices en valent la peine, et notre exemple de modèle peut vous aider à planifier et à développer votre prochain grand produit.

Nous sommes une communauté de spécialistes produit (comme vous !), donc si vous avez trouvé ces informations utiles, abonnez-vous à notre newsletter. Nous vous tiendrons au courant avec des articles pratiques, des guides méthodologiques, des revues d’outils et bien plus encore.