Comment rédiger un PRD que Claude Code ou Cursor peuvent construire

Pourquoi le PRD a changé en 2026

Pendant vingt ans, un PRD a été un document d'alignement. Son lecteur était une personne : un ingénieur qui poserait des questions en réunion, contesterait une mauvaise exigence et comblerait les petits trous avec son jugement. Un PRD pouvait être vague parce qu'un humain résolvait le vague.

Un agent de code résout le vague en choisissant l'interprétation statistiquement la plus probable et en la construisant, vite, sans demander. C'est tout le problème. L'ambiguïté qui coûtait une conversation de dix minutes coûte maintenant une mauvaise implémentation, une revue, un revert et une seconde exécution. Les équipes qui livrent avec des agents toute la journée ont remarqué la même chose en 2025 : la qualité du résultat suivait la qualité de la spécification écrite de plus près que le choix du modèle.

Deux projets open source ont rendu ce basculement visible. Spec Kit de GitHub, publié en septembre 2025, structure le travail de l'agent en une séquence à étapes verrouillées : une constitution de principes du projet, une spécification, un plan technique, une liste de tâches, et seulement ensuite l'implémentation. En octobre 2026, le dépôt affiche environ 143 000 étoiles. Task Master, d'Eyal Toledano, fait quelque chose de plus étroit : task-master parse-prd your-prd.txt transforme un PRD en une liste de tâches ordonnée par dépendances que Cursor, Windsurf ou Claude Code déroulent ; le dépôt affiche environ 28 000 étoiles en octobre 2026. Les deux outils supposent que le PRD est l'interface avec l'agent, pas un mémo pour l'équipe.

Voilà le basculement en une phrase : le PRD a cessé d'être un document sur lequel les gens s'accordent pour devenir l'entrée qu'un agent exécute.

Ce dont un agent a besoin dans un PRD

Un agent a besoin de quatre choses, et la plupart des PRD ne lui en donnent aucune proprement.

Des exigences numérotées et atomiques. Une phrase par exigence, avec un identifiant stable (R1, R2, R3). « L'utilisateur peut réinitialiser son mot de passe par e-mail » est une exigence. « L'utilisateur a une expérience fluide de récupération de compte » n'en est pas une. Les identifiants comptent parce que l'agent, le plan, les tâches et les tests y feront tous référence.

Un critère d'acceptation que l'agent peut tester. Pour chaque exigence, écrivez à quoi ressemble une vérification réussie, en termes que l'agent peut exécuter : une réponse HTTP, un état de base de données, un élément rendu, un code de sortie CLI. Si vous ne pouvez pas formuler la vérification, l'exigence n'est pas terminée.

Des non-objectifs explicites. Les agents surconstruisent. Laissé seul, « ajouter la réinitialisation du mot de passe » devient un flux de réinitialisation plus un limiteur de requêtes plus un journal d'audit plus une page de réglages pour les configurer. Une section de non-objectifs (« Pas de limitation de requêtes dans cette itération. Pas d'interface admin. Pas de SMS. ») est la ligne la moins chère que vous puissiez ajouter à un PRD, et elle supprime plus de travail inutile que n'importe quelle autre.

Les contraintes et la forme actuelle du système. Quel framework, quelle base de données, où vit l'authentification, quels fichiers ne pas toucher, quelles conventions suivre. Spec Kit appelle cela la constitution. Dans Cursor, cela vit dans les fichiers de règles ; dans Claude Code, dans CLAUDE.md ; dans Codex, dans AGENTS.md. Le PRD doit les référencer plutôt que les répéter.

Avant et après : la même exigence, réécrite

Le tableau ci-dessous vient de nos propres PRD. La colonne de gauche est notre ancienne façon d'écrire ; la droite est ce sur quoi un agent peut agir.

La colonne de droite est plus longue par exigence et plus courte au total, parce que les paragraphes vagues qui entouraient chaque ligne ont disparu.

Le modèle, section par section

Voici le squelette que nous utilisons. C'est du Markdown parce que tous les agents lisent le Markdown et parce qu'il se diffe proprement dans Git. Dans le bloc de code, les libellés de section sont en gras plutôt qu'en titres, pour que la structure reste visible.

**Fonctionnalité :** Réinitialisation du mot de passe par e-mail
**Responsable :** (nom)   **Statut :** Brouillon | Gelé   **Référence :** v1 (2026-10-28)

**Problème**
Les utilisateurs qui oublient leur mot de passe écrivent au support. Le
support a traité 41 e-mails de ce type en septembre 2026. Il n'existe
aucun parcours en libre-service.

**Objectif**
Un utilisateur déconnecté peut réinitialiser lui-même son mot de passe en
moins de deux minutes sans contacter personne.

**Exigences**
R1. Un utilisateur déconnecté peut demander une réinitialisation en
    saisissant son e-mail.
    Passe : POST /auth/reset avec un e-mail connu renvoie 200 et crée une
    ligne password_reset expirant dans 30 minutes.
R2. Un e-mail inconnu renvoie la même réponse 200 et ne crée rien.
    Passe : POST /auth/reset avec un e-mail inconnu renvoie 200 ; le nombre
    de lignes est inchangé.
R3. L'e-mail de réinitialisation contient un lien qui ouvre un formulaire
    avec les champs nouveau mot de passe et confirmation.
    Passe : le lien de l'e-mail de test capturé mène à /auth/reset/:token
    et affiche les deux champs.
R4. Envoyer un jeton valide et des mots de passe identiques met à jour le
    hash, supprime le jeton et connecte l'utilisateur.
    Passe : le test d'intégration reset_happy_path se termine et
    l'utilisateur arrive sur /home.
R5. Les jetons expirés ou utilisés affichent « Ce lien a expiré » et un
    bouton pour en demander un nouveau.

**Non-objectifs**
Pas de limitation de requêtes dans cette itération. Pas de SMS. Pas
d'interface admin. Aucun changement au formulaire de connexion.

**Contraintes**
Suivre CLAUDE.md. Utiliser le mailer existant (lib/mail). N'ajouter aucune
dépendance. Les jetons font 32 octets aléatoires encodés en hexadécimal.

**Questions ouvertes**
Q1. Une réinitialisation doit-elle aussi déconnecter les autres sessions ?
    Décideur : (nom), échéance 2026-10-30. Tant que ce n'est pas décidé,
    ne pas implémenter.

**Hors périmètre pour l'agent**
La rédaction du corps de l'e-mail : un texte provisoire suffit.

Quelques remarques sur ces choix.

• Statut et référence. « Gelé » avec une version et une date signifie que l'agent construit à partir de ce texte et de rien de plus récent. Nous gelons avant la première exécution et incrémentons la version quand une exigence change, pour qu'un audit ultérieur puisse comparer ce qui a été livré à ce qui a été convenu.
• Les lignes « Passe ». Elles sont écrites à côté de l'exigence, pas dans un plan de test séparé. L'agent les lit comme une spécification de test, et la plupart écriront le test en premier.
• Les questions ouvertes avec un décideur. Une question ouverte sans responsable est un trou que l'agent comblera. « Tant que ce n'est pas décidé, ne pas implémenter » est l'instruction qui l'en empêche.

Comment en rédiger un en une après-midi

1. Écrivez le problème en trois phrases avec un vrai chiffre. Si vous n'avez pas le chiffre, allez le chercher. « Le support a traité 41 e-mails de réinitialisation en septembre » vaut mieux que « les utilisateurs ont du mal à récupérer leur compte ».
2. Listez les exigences en phrases simples, puis numérotez-les. Visez 5 à 15. Au-delà de 20, la fonctionnalité en est deux ; scindez le PRD.
3. Écrivez une ligne « Passe » sous chaque exigence. Si vous ne pouvez pas, soit l'exigence n'est pas atomique, soit vous ne savez pas encore à quoi ressemble « terminé ». Les deux valent la peine d'être découverts avant l'agent.
4. Écrivez les non-objectifs avant que quiconque lise les exigences. Demandez-vous : qu'ajouterait ici un ingénieur zélé dont nous ne voulons pas ? Notez-le.
5. Pointez vers le fichier de contraintes plutôt que de le recopier. Gardez CLAUDE.md, AGENTS.md ou vos règles Cursor comme source unique des conventions.
6. Gelez-le. Marquez le statut, fixez la version et placez-le là où l'agent peut le lire : un fichier dans le dépôt, ou une page que l'agent peut récupérer via un serveur MCP.
7. Lancez l'agent sur R1 seulement. Relisez ce résultat avant de le laisser dérouler le reste. La première exigence vous dit si l'agent peut lire le PRD tout court.

Où vit le PRD, et comment l'agent le lit

Un PRD dans un Google Doc est invisible pour Claude Code. Les options qui fonctionnent :

• Un fichier dans le dépôt. docs/prd/password-reset.md, référencé depuis CLAUDE.md ou AGENTS.md. Le plus simple, versionné, et tous les agents peuvent le lire. Spec Kit et Task Master supposent tous deux cela.
• Une page que l'agent récupère via MCP. Si votre équipe rédige ses PRD dans un outil d'espace de travail plutôt que dans le dépôt, un serveur MCP permet à l'agent de lire la page directement. Atrix expose ses pages, tickets et cycles via un serveur MCP avec 85 outils et OAuth 2.1 ; il est référencé dans l'Official MCP Registry et sur Glama. L'effet pratique : un agent de code peut lire la page du PRD gelé, créer les tickets planifiés et les mettre à jour en terminant, sans copier de texte entre outils. La limite, dite clairement : l'agent lit et écrit des objets de l'espace de travail ; il n'exécute ni votre code ni vos tests.
• Les deux. Nous gardons le PRD canonique comme page, et l'agent copie la version gelée dans le dépôt au début d'une exécution pour que le commit enregistre exactement ce à partir de quoi il a construit.

Pour Cursor et Codex en particulier, l'intégration Cursor et l'intégration Codex décrivent la configuration : une connexion OAuth, puis l'agent voit le PRD, le backlog et le cycle en cours comme des outils.

Ce qu'il faut laisser de côté

Tout ce dont un humain a besoin et pas un agent :

• Les personas et la recherche utilisateur. Gardez-les dans une page liée ; l'agent a besoin de l'exigence, pas du persona.
• L'analyse concurrentielle. Idem.
• Les maquettes, sauf si l'exigence est visuelle. Si elle l'est, une capture d'écran que l'agent peut voir vaut mieux que trois paragraphes qui la décrivent.
• Les calendriers. L'agent ne planifie pas de sprints ; c'est le rôle de votre cycle.

Le PRD classique existe toujours ; il cesse simplement d'être le document que lit l'agent. Si vous voulez la forme longue pour les parties prenantes, notre modèle de PRD avec IA couvre cette version, et le modèle de PRD du site est la copie hébergée que vous pouvez dupliquer.

FAQ

Un PRD pour un agent de code IA est-il la même chose qu'une spécification en développement piloté par la spécification ?

Presque. Le développement piloté par la spécification, tel que Spec Kit le présente, sépare la spécification (quoi et pourquoi) du plan (comment, avec quelle pile) et des tâches (le travail ordonné). Le PRD décrit ici est la couche spécification. Le plan et les tâches en sont générés, par l'agent ou par un outil comme Task Master.

Quelle longueur pour un PRD destiné à Claude Code ou Cursor ?

Assez court pour tenir dans le contexte de l'agent à côté du code qu'il touche. En pratique, 400 à 1 200 mots, avec 5 à 15 exigences numérotées. Si c'est plus long, scindez la fonctionnalité.

Ai-je encore besoin de user stories ?

Pas sous la forme « En tant qu'utilisateur, je veux ». L'agent a besoin de l'exigence et du critère d'acceptation ; l'enveloppe de la story ajoute des mots sans ajouter de contenu testable. Gardez les stories si votre équipe s'en sert pour planifier, mais mettez les exigences numérotées en premier.

Que mettre dans CLAUDE.md ou AGENTS.md plutôt que dans le PRD ?

Les conventions vont dans le fichier de règles : pile, arborescence, commandes de test, style, fichiers à ne pas toucher. Le PRD est par fonctionnalité et référence le fichier de règles. Répéter les conventions dans chaque PRD crée des divergences.

L'agent doit-il rédiger le PRD ?

Il peut en rédiger un brouillon à partir d'un brief, et ce brouillon est souvent une bonne liste de ce que vous n'avez pas encore décidé. L'agent d'Atrix le fait dans une exécution Develop : un brief en entrée, des exigences, une architecture et des tickets planifiés en sortie, 100 exécutions par mois sur Builder. Mais le gel, les non-objectifs et les décisions sur les questions ouvertes vous appartiennent. Un agent ne saura pas ce que vous ne voulez pas voir construit.

Comment savoir si l'agent a construit ce que disait le PRD ?

Comparez le résultat à la référence gelée, exigence par exigence, avec les lignes « Passe ». L'audit d'exigences d'Atrix fait cette comparaison contre la page gelée ; il vérifie la couverture et la dérive des exigences, pas le code lui-même. Pour le code, lancez les tests qu'impliquent les lignes « Passe » et relisez à la main les parcours d'authentification et de paiement.

Prochaine étape

Copiez le modèle de PRD, rédigez R1 avec sa ligne « Passe » et lancez votre agent sur cette seule exigence avant d'écrire R2. Si vos PRD vivent hors du dépôt, le serveur MCP est le moyen par lequel Claude Code, Cursor et Codex les lisent.

Sources

Dépôt GitHub Spec Kit, nombre d'étoiles relevé le 27 octobre 2026 ; Spec-driven development with AI: get started with a new open source toolkit, GitHub Blog, septembre 2025 ; Dépôt Task Master, nombre d'étoiles relevé le 27 octobre 2026.