Comment rédiger un PRD avec l’IA (avec un modèle gratuit)

À quoi sert vraiment un PRD

Un PRD a deux lecteurs, et il vaut la peine d’écrire pour les deux.

Le premier, c’est la personne qui construit le produit. Elle doit savoir quel problème il résout, à qui il s’adresse, ce que contient la première version et ce qu’elle exclut délibérément. Si elle doit revenir vers vous avec des questions chaque après-midi, le document ne fait pas son travail.

Le second lecteur, c’est la personne qui vérifie le résultat après coup. Ce peut être vous, un associé, un relecteur ou un auditeur avant le lancement. Elle doit pouvoir parcourir le document ligne par ligne et dire « oui, c’est fait » ou « non, ça ne l’est pas ». Ce n’est possible que si les exigences sont formulées comme des affirmations vraies ou fausses sur le produit en fonctionnement.

La plupart des modèles de PRD servent le premier lecteur. Très peu servent le second, et c’est pourquoi tant de produits livrent « ce que nous avons construit » plutôt que « ce que nous avions convenu ».

Les sections qui comptent

Un PRD utile pour une première version compte une dizaine de sections courtes :

1. Vue d’ensemble. Nom, responsable, statut, résumé en une ligne. Si vous ne pouvez pas dire en deux lignes ce que c’est et pour qui, continuez à réfléchir avant d’écrire quoi que ce soit d’autre.
2. Problème. Le problème tel que l’utilisateur le vit, ce qu’il fait aujourd’hui à la place, et comment vous le savez. « Des entretiens avec six gérants de cliniques » est une preuve. « Tout le monde déteste ça » n’en est pas une.
3. Utilisateur cible. Un utilisateur principal, l’élément déclencheur qui le pousse à chercher autre chose, et les personnes à qui le produit ne s’adresse pas.
4. Jobs to be done. Trois à cinq, avec les mots de l’utilisateur : quand ceci se produit, je veux faire cela, pour obtenir tel résultat.
5. Périmètre du MVP. Ce que fait la première version, en lignes qu’une personne pourrait voir fonctionner.
6. Exigences. Des affirmations numérotées et vérifiables, avec critères d’acceptation et priorité.
7. Indicateurs de réussite. Ce que vous mesurerez, où, et la cible, ou un blanc si vous n’en avez pas encore.
8. Hors périmètre. Ce que cette version ne fait délibérément pas.
9. Questions ouvertes. Chacune avec un responsable et une date.
10. Validation. Qui a validé, quand, et comment proposer des modifications ultérieures.

La sixième section change tout. Elle a donc droit à sa propre partie ci-dessous.

Rédiger des exigences vérifiables

Une exigence est une affirmation unique, vraie ou fausse, sur le produit construit. « Authentification » est un sujet. « Les utilisateurs peuvent réinitialiser leur mot de passe par e-mail » est une exigence.

Chaque exigence comporte quatre éléments :

• Une clé, par exemple REQ-001. Les clés sont permanentes. On ne renumérote ni ne réutilise jamais une clé, car des tâches, des commits et des audits y feront référence.
• Des critères d’acceptation, qui décrivent comment vérifier l’exigence sur le système en fonctionnement. « Demander une réinitialisation, recevoir l’e-mail en moins d’une minute, définir un nouveau mot de passe, se connecter avec. » Si vous ne pouvez pas écrire cela, l’exigence n’est pas terminée.
• Une priorité. La méthode MoSCoW suffit pour une petite équipe : Must, Should, Could, Won’t (indispensable, souhaitable, facultatif, exclu). Les échelles à cinq niveaux ouvrent des débats sur un 3 contre un 4, alors que la seule décision qui compte est de savoir si la première version peut sortir sans.
• Un type : fonctionnelle (comportement), non fonctionnelle (rapidité, disponibilité, accessibilité) ou contrainte (réglementation, plateforme ou budget).

Deux règles gardent la liste honnête. Un seul engagement par ligne : si une phrase en contient deux, scindez-la. Et une exigence sans critères d’acceptation est marquée incomplète, pas acceptée en silence.

Où l’IA aide, et où elle n’aide pas

Voici la répartition des rôles qui fonctionne.

Donnez au modèle le contexte, pas les décisions. Collez ce que vous savez réellement : le problème avec vos propres mots, vos notes d’échanges avec des clients, les contraintes avec lesquelles vous travaillez, ce que vous avez déjà écarté. Un modèle qui rédige à partir d’une consigne d’une ligne comblera chaque lacune par quelque chose de plausible. Et le plausible est l’ennemi ici, car il se lit comme du validé.

Laissez-le rédiger la structure et un premier jet. Les modèles savent transformer des notes en vrac en dix sections, repérer un élément hors périmètre oublié et reformuler « le système doit être rapide » en quelque chose de mesurable. Ils vont vite sur les parties fastidieuses.

Laissez les décisions de périmètre à une personne. Ce qui entre dans la première version, ce qui en sort et ce que « terminé » veut dire sont des décisions business. Un modèle inventera volontiers une exigence parce qu’elle paraît raisonnable ou standard. C’est exactement le périmètre que personne n’a validé, et il ressurgit souvent des semaines plus tard sous forme de travail que personne n’a demandé.

Ne le laissez jamais inventer de chiffres. Si une cible, un prix ou une date ne relève pas de ce que vous savez, laissez un blanc. Un indicateur de réussite inventé dans un PRD est traité comme un engagement.

Comparez ce qu’il a extrait avec ce qu’il a lu. Si vous utilisez un modèle pour transformer un texte rédigé en tableau d’exigences, demandez-lui de citer la phrase dont provient chaque exigence. Vous pourrez alors vérifier quarante lignes sans relire tout le document, et tout ce qui n’a pas de phrase source est une invention.

Une méthode applicable dès aujourd’hui

Si vous travaillez à la main avec un assistant généraliste :

1. Copiez le modèle de PRD dans votre éditeur.
2. Rédigez vous-même les sections problème et utilisateur cible. Elles sont courtes, et c’est là que le modèle est le moins bon, car vous seul savez à qui vous avez parlé.
3. Collez vos notes et demandez au modèle de rédiger les jobs to be done, le périmètre du MVP et le hors-périmètre, en s’appuyant uniquement sur vos notes.
4. Demandez-lui de proposer les exigences sous forme de tableau avec clé, énoncé, critères d’acceptation, priorité et type, en citant la phrase source de chacune.
5. Supprimez tout ce qui n’a pas de source. Complétez les critères d’acceptation manquants. Fixez vous-même les priorités.
6. Obtenez la validation et figez cette version. À partir de là, les modifications sont proposées et consignées, pas glissées en douce.

Le faire dans Atrix AI

Atrix AI applique cette même méthode dans votre espace de travail, avec les garde-fous intégrés.

En mode Develop, l’agent lit ce que votre projet contient déjà : son résumé, son pitch et son client cible (y compris les notes d’une idée que vous avez transformée en projet), ainsi que ses documents. Il rédige le PRD comme un document du projet, avec problème, utilisateur cible, jobs to be done, périmètre du MVP, indicateurs de réussite et hors-périmètre. Si vous le relancez, il met à jour ce même document en conservant le texte précédent comme version, au lieu de produire une nouvelle copie.

Atrix peut ensuite extraire les exigences du PRD sous forme de lignes avec clé, critères d’acceptation, priorité MoSCoW et type, chacune citant la phrase dont elle provient. Une ligne dont la citation est introuvable dans le document est écartée. Tout le reste arrive à l’état de proposition, et rien ne compte tant qu’une personne ne l’a pas accepté. Toute exigence sans critères d’acceptation, hors Won’t, est signalée, et les exigences ne peuvent pas être figées tant que chacune n’en a pas et que rien n’attend encore d’être accepté.

Les exigences acceptées peuvent être découpées en tickets de backlog, chacun indiquant la clé de l’exigence qu’il sert. Votre gestion de projet reste ainsi liée à ce qui a été convenu. Quand vous confiez le développement à un agent de code, le dossier de passation contient les documents et les clés d’exigences, et demande que les clés soient citées dans les commits.

C’est ce qui rend la dernière étape possible. Vous pouvez figer les exigences acceptées comme référence, et l’audit des exigences indique pour chacune si du travail existe, est en cours ou est terminé, et quelles exigences ont été modifiées ou abandonnées après la validation. Le rapport est calculé à partir de vos données, pas de l’avis d’un modèle. Il ne lit pas votre code : il vous dit si le travail enregistré pour chaque exigence convenue est terminé.

L’extraction des exigences et leur découpage en tickets consomment chacun une exécution IA. Les cinq exécutions mensuelles de l’offre gratuite suffisent donc largement pour un premier PRD.

Une courte checklist avant de déclarer le PRD terminé

• Quelqu’un d’extérieur à l’équipe pourrait-il construire la première version à partir de ce document sans vous poser de questions ?
• Chaque exigence Must a-t-elle des critères d’acceptation ?
• Chaque exigence est-elle une affirmation unique, vraie ou fausse ?
• Le hors-périmètre est-il écrit noir sur blanc ?
• Chaque question ouverte a-t-elle un responsable et une date ?
• Quelqu’un l’a-t-il validé, et cette version est-elle enregistrée ?

Si la réponse est oui aux six questions, votre PRD sert ses deux lecteurs. Partez du modèle gratuit, ou laissez l’agent rédiger le premier jet et consacrez votre temps aux décisions.