Modèle de PRD (Cahier des Charges Produit) + un Exemple Complet à Copier

Modèle de PRD (Cahier des Charges Produit) + un Exemple Complet à Copier

Dernière mise à jour : 28 juillet 2026.

La plupart des pages de modèle de cahier des charges produit vous donnent un formulaire vide et s'arrêtent là. Celle d'Atlassian, ce sont quatre sections d'instructions autour d'un tableau de métriques de succès vide. Celle de Product School affiche « (with Example) » dans le titre et ne contient aucun exemple. Le bloc Markdown en 12 sections ci-dessous est le modèle complet, en accès libre, prêt à copier. La section 4 remplit ensuite chacune de ces 12 sections pour un projet concret entièrement traité : un portail de factures client qui lit des PDF avec un LLM et envoie les cas douteux à une revue humaine. Copiez la version vide. Lisez la version remplie. Écrivez la vôtre.

Points Clés à Retenir

• Un PRD répond au quoi et au pourquoi ; le document de conception technique répond au comment.
• Les 12 sections s'adaptent à tous les formats de projet. Un one-pager, c'est le même modèle avec moins de lignes.
• Les non-objectifs doivent être écrits noir sur blanc. Un agent de codage IA ne peut pas déduire un périmètre d'une simple omission.
• Les critères d'acceptation doivent être vérifiables par une machine : « p95 sous 400ms », jamais « rapide ».

Quel Format de PRD Choisir ?

Choisissez le format selon qui va lire le document, pas selon la taille apparente du produit. Une fonctionnalité isolée destinée à vos propres ingénieurs a besoin d'un one-pager. Un projet confié à une équipe externe a besoin du PRD complet en 12 sections, car les critères d'acceptation servent aussi de jalons de validation. Un cahier des charges destiné à un agent de codage IA a besoin des mêmes douze sections, découpées en phases.

Le modèle de cahier des charges produit sur une page que tout le monde réclame n'est pas un document à part. Le one-pager de Lenny Rachitsky, largement repris et publié avec des exemples concrets dans sa newsletter, c'est la même structure débarrassée du formalisme superflu. Un one-pager n'est pas un document différent. Ce sont les mêmes douze sections, avec les lignes vides supprimées.

Les équipes agiles se posent souvent la même question, formulée autrement : est-ce qu'un PRD tient la route une fois qu'un backlog existe ? Oui, sous forme de one-pager : le PRD porte le pourquoi et les limites, les tickets portent le travail.

Le Modèle de PRD (Markdown à Copier-Coller)

Voici l'ensemble en Markdown, gratuit, sans inscription requise. Collez-le dans Notion, Confluence, Google Docs, Linear, Word, ou commitez-le sur GitHub sous le nom PRD.md pour qu'il se versionne avec le code. On nous demande ce modèle sous neuf formats différents ; le Markdown est celui qui survit au collage dans tous ces outils, et c'est le seul qu'un agent de codage IA lit proprement.

# PRD : [Nom du produit ou de la fonctionnalité]

## 1. En-tête
- Propriétaire (produit) :
- Responsable ingénierie :
- Responsable design :
- Statut : Brouillon | En revue | Approuvé | Livré
- Dernière mise à jour :
- Historique des changements : date / auteur / ce qui a changé

## 2. Énoncé du problème
Un paragraphe. Qui souffre, à quelle fréquence, ce que ça coûte aujourd'hui. Pas de langage de solution.

## 3. Objectifs et indicateurs de succès
| Objectif | Indicateur | Référence | Cible | Mesuré par | Date |
|---|---|---|---|---|---|

## 4. Non-objectifs
Formulés positivement : « Cette phase n'inclut pas X. »

## 5. Utilisateurs et personas
Qui l'utilise, ce qu'ils savent déjà, sur quel appareil, à quelle fréquence.

## 6. User stories et critères d'acceptation
En tant que [persona], je veux [action], afin de [résultat].
- Given [contexte], when [événement], then [résultat observable].

## 7. Exigences fonctionnelles
Numérotées. Une exigence par ligne. Testable. Aucune phrase contenant « et ».

## 8. Exigences non fonctionnelles
Performance / sécurité et cloisonnement / résidence et rétention des données / accessibilité / disponibilité.

## 9. Dépendances et intégrations
Systèmes externes, API, identifiants, qui possède l'accès, délai nécessaire.

## 10. Jalons et phasage
| Phase | Périmètre | Critères de sortie | Date cible |
|---|---|---|---|

## 11. Questions ouvertes et risques
| Question ou risque | Responsable | Nécessaire avant le | Impact si sans réponse |
|---|---|---|---|

## 12. Annexe et liens
Maquettes, recherche, notes concurrentielles, tickets précédents, contrats.

Les douze sections, dans l'ordre : en-tête, énoncé du problème, objectifs et indicateurs de succès, non-objectifs, utilisateurs et personas, user stories avec critères d'acceptation, exigences fonctionnelles, exigences non fonctionnelles, dépendances et intégrations, jalons et phasage, questions ouvertes et risques, annexe.

Que Doit Contenir un PRD ? Les 12 Sections, et la Version Faible de Chacune

Un document d'exigences produit doit contenir un énoncé du problème, des objectifs mesurables, des non-objectifs explicites, des personas, des user stories avec critères d'acceptation, des exigences fonctionnelles et non fonctionnelles, des dépendances, des jalons, des questions ouvertes avec des responsables, et un historique des changements. Tout le reste va en annexe. Le test à appliquer à chaque ligne est celui que la norme ISO/IEC/IEEE 29148:2018 applique aux exigences en général : vérifiable, non ambiguë, unique.

La plupart des PRD échouent à ce test aux trois mêmes endroits.

Deux sections méritent plus d'attention qu'elles n'en reçoivent généralement.

Les exigences non fonctionnelles sont l'endroit où le périmètre double discrètement. Performance, cloisonnement, résidence des données, rétention, accessibilité, disponibilité : chacune de ces exigences est une décision d'ingénierie qui a un coût, et aucune n'apparaît dans une user story. Mettez la ligne sécurité ici plutôt que dans une réponse vague, et rédigez-la de la façon dont vous voudriez qu'elle soit vérifiée, en vous appuyant par exemple sur notre checklist de sécurité avant lancement comme liste de référence. Si le projet a une composante IA, les exigences de préparation à la production ont aussi leur place ici, pas dans une future phase de « durcissement » qui ne sera jamais planifiée : notre checklist PoC vers production est la version que nous utilisons.

Les questions ouvertes ont besoin de trois colonnes, pas d'une seule. Question, responsable, date limite. Une question sans responsable, c'est une décision que personne ne prend, et elle refera surface sous forme de demande de changement en semaine six. À noter : un PRD, c'est ce qu'on écrit après avoir décidé de construire plutôt que d'acheter. Si l'énoncé du problème ressemble encore à une liste de courses de fonctionnalités, l'arbitrage construire-ou-acheter n'a pas vraiment eu lieu.

L'Exemple Concret : Un PRD de Portail de Factures, Rempli

Voici un exemple concret complet, avec les 12 sections remplies. Le projet : un portail de factures client pour un opérateur logistique de taille moyenne. Les clients téléversent des factures PDF, un LLM extrait les lignes, le système signale les écarts par rapport au bon de commande, et tout ce dont il n'est pas sûr part dans une file de revue humaine. Stack : Next.js, Supabase/Postgres, une étape d'extraction par LLM. Copiez-le, imprimez-le, exportez-le en PDF, comme vous voulez.

# PRD : Portail de Factures Client, Phase 1

## 1. En-tête
- Propriétaire (produit) : Directeur des opérations, côté client
- Responsable ingénierie : Responsable delivery, Techsy
- Responsable design : Designer produit, Techsy
- Statut : Approuvé pour développement
- Dernière mise à jour : 2026-07-28
- Historique des changements :
  - 2026-07-14 / produit / première version
  - 2026-07-21 / ingénierie / ajout de la règle de seuil de confiance à 6.2
  - 2026-07-28 / produit / écriture retour ERP déplacée vers les non-objectifs

## 2. Énoncé du problème
Les équipes ops reçoivent les factures clients sous forme de PDF par e-mail et
les ressaisissent manuellement dans le système de commandes. Le volume dépasse
300 factures par semaine, le temps de traitement moyen est d'environ 6 minutes
chacune, et environ 4% contiennent une erreur de saisie détectée seulement lors
du rapprochement de fin de mois. Chaque correction coûte un second passage et
un appel.

## 3. Objectifs et indicateurs de succès
| Objectif | Indicateur | Référence | Cible | Mesuré par | Date |
|---|---|---|---|---|---|
| Réduire le traitement manuel | Temps de traitement moyen | 6 min | moins de 90 sec | Tableau de bord ops, médiane hebdomadaire | 2026-11-01 |
| Réduire les erreurs de saisie | Factures corrigées au rapprochement | 4% | moins de 1% | Rapport financier de fin de mois | 2026-12-01 |
| Contenir la charge de revue | Part envoyée en revue humaine | n/a | moins de 25% | Métriques de file du portail | 2026-11-01 |

## 4. Non-objectifs
Cette phase ne prend pas en charge les factures multidevises, l'écriture
retour ERP, les avoirs en libre-service côté client, ni une application
mobile. L'extraction couvre uniquement le PDF. Les photos de factures papier
et les scans en dessous de 200 DPI sont rejetés au téléversement avec un
message expliquant pourquoi.

## 5. Utilisateurs et personas
- Agent ops (principal, 6 personnes) : travaille sur la file d'exceptions
  toute la journée, connaissance métier approfondie, poste de bureau
  uniquement.
- Contact AP client (externe, ~140 comptes) : téléverse les factures, faible
  tolérance aux frictions de configuration de compte.
- Responsable financier (secondaire) : extrait le rapport de fin de mois, a
  besoin d'une piste d'audit par facture.

## 6. User stories et critères d'acceptation
6.1 En tant que contact AP client, je veux téléverser une facture PDF, afin
de ne pas avoir à l'envoyer par e-mail et attendre.
- Given un PDF de moins de 20 MB à 200 DPI ou plus, when je le téléverse, then
  le portail renvoie un numéro de référence en moins de 5 secondes et affiche
  « En cours de traitement ».

6.2 En tant qu'agent ops, je veux que les extractions à faible confiance
soient retenues, afin qu'aucune erreur ne soit approuvée automatiquement.
- Given une facture analysée, when le score de confiance d'une ligne est
  inférieur à 0.85, then la facture part dans la file de revue et n'est
  jamais auto-approuvée.

6.3 En tant qu'agent ops, je veux voir l'écart en un seul endroit, afin de
pouvoir le résoudre sans ouvrir le système de commandes.
- Given une facture rapprochée d'une commande, when la quantité ou le prix
  unitaire d'une ligne diffère de la commande, then le portail affiche les
  deux valeurs côte à côte et signale l'écart.

6.4 En tant que responsable financier, je veux filtrer les factures, afin
de pouvoir clôturer le mois.
- Given la liste des factures, when je filtre par fournisseur, plage de dates
  et statut, then les résultats reviennent en moins de 400ms au p95 et l'état
  vide propose « Effacer les filtres ».

## 7. Exigences fonctionnelles
1. Le téléversement n'accepte que le PDF, 20 MB maximum, un fichier par
   soumission.
2. L'extraction renvoie le fournisseur, le numéro de facture, la date, la
   devise, et les lignes avec quantité, prix unitaire et total.
3. Chaque ligne porte un score de confiance compris entre 0 et 1.
4. Le rapprochement compare la facture extraite à la commande ouverte par
   numéro de bon de commande.
5. Les exceptions entrent dans une file ordonnée de la plus ancienne à la
   plus récente, assignable à un seul agent.
6. Chaque changement d'état écrit une entrée d'audit avec acteur,
   horodatage, valeur précédente.
7. Les factures approuvées s'exportent en lot CSV pour le système financier.

## 8. Exigences non fonctionnelles
- Performance : liste des factures avec p95 sous 400ms. L'extraction se
  termine en moins de 90 secondes après le téléversement, au p95.
- Sécurité et cloisonnement : isolation par tenant appliquée au niveau ligne
  de la base de données. Un client ne peut jamais lire la facture d'un autre
  client. Vérifié par un test automatisé à chaque version.
- Résidence et rétention des données : documents stockés dans l'UE.
  Originaux conservés 7 ans, données d'extraction 90 jours.
- Accessibilité : file entièrement utilisable au clavier, contraste WCAG 2.2
  AA.
- Disponibilité : 99.5% mensuel, support pendant les heures ouvrées.

## 9. Dépendances et intégrations
- Données de commandes : réplique Postgres en lecture seule. Accès géré par
  l'IT client, identifiants nécessaires avant le 2026-08-15.
- Fournisseur d'extraction LLM : contrat et accord de traitement des données
  signés avant le démarrage du projet.
- Notifications e-mail : fournisseur transactionnel existant, domaine
  d'expéditeur vérifié par le client.

## 10. Jalons et phasage
| Phase | Périmètre | Critères de sortie | Date cible |
|---|---|---|---|
| P1 | Téléversement, extraction, routage par confiance | 50 factures réelles de bout en bout, moins de 25% en file | 2026-09-19 |
| P2 | Rapprochement de commandes et vue des écarts | Écart correctement signalé sur 20 cas de test | 2026-10-10 |
| P3 | Piste d'audit, export CSV, reporting | La finance clôture un mois dans le portail | 2026-11-01 |

## 11. Questions ouvertes et risques
| Question ou risque | Responsable | Nécessaire avant | Impact si sans réponse |
|---|---|---|---|
| Quel numéro de bon de commande fait foi quand une facture en affiche deux ? | Directeur des opérations client | 2026-08-08 | Logique de rapprochement bloquée |
| Les 12 plus gros clients envoient-ils des PDF scannés ou natifs ? | Responsable delivery | 2026-08-08 | Le seuil de confiance pourrait être erroné |
| La rétention de 7 ans est-elle confirmée avec le service juridique du client ? | Responsable financier client | 2026-08-22 | La conception du stockage et les coûts changent |
| Coût d'extraction par facture à 300/semaine | Responsable delivery | 2026-09-05 | Économie unitaire inconnue |

## 12. Annexe et liens
Jeu d'exemples de factures anonymisées (40 fichiers), schéma de la table des
commandes, étude actuelle du temps de traitement, parcours Figma pour le
téléversement et la file, statement of work signé.

Quatre choix méritent d'être soulignés, parce que la version paresseuse de chacun coûte de l'argent réel.

Section 3, la référence. « 6 minutes » n'est pas de la décoration. Sans référence, impossible de dire si le projet a fonctionné, et six mois plus tard, quelqu'un en débat en réunion sans aucune donnée. La version paresseuse, « améliorer l'efficacité », rend le projet infalsifiable.

Section 4, le non-objectif. L'écriture retour ERP a été déplacée vers les non-objectifs le 2026-07-28, après avoir été supposée acquise pendant un appel de revue. L'écrire comme non-objectif a coûté une ligne et évité un débat de périmètre.

Section 6.2, le seuil de confiance. C'est la règle que nos propres premiers brouillons oublient le plus souvent. L'omettre, et le système auto-approuve des factures qu'un humain aurait dû voir, ce qui correspond exactement à l'échec qui efface les gains de temps promis en section 3.

Section 11, les responsables. Chaque question ouverte a un nom et une date. Cette colonne fait la différence entre un document et une liste de tâches dont personne n'est responsable.

Le PRD vous dit quoi. Il ne vous dit pas combien de temps ni combien ça coûte, ce qui est un exercice à part : voyez le cadrage du projet pour cette moitié-là. Et un non-objectif que vous n'avez pas écrit est une fonctionnalité que quelqu'un finira par construire.

Comment Écrire un PRD Qu'un Agent de Codage IA Peut Vraiment Exploiter ?

Un PRD écrit pour un agent de codage IA sacrifie la brièveté au profit de l'explicite. L'agent n'a aucun contexte informel partagé, aucun historique commun, et aucun instinct pour deviner ce que vous n'avez évidemment pas voulu dire. Quatre règles couvrent l'essentiel de la différence, et elles viennent de ce que nous avons observé, cahiers des charges qui réussissent ou échouent, sur nos propres projets assistés par agent.

1. Formulez les non-objectifs positivement. Les humains déduisent le périmètre d'une omission. Pas les agents. « N'ajoutez pas d'authentification dans cette phase » doit être une phrase écrite dans le document, sinon l'authentification sera construite, testée, et vous sera livrée.

2. Découpez le travail en phases. Un seul monolithe de 40 pages produit une pull request confiante, tentaculaire et à moitié correcte. Découpez le PRD en passes qu'un agent termine en une seule exécution bornée, chacune avec ses propres critères de sortie.

3. Rendez les critères d'acceptation vérifiables par une machine. « Rapide » n'est pas une exigence, c'est une impression. « p95 sous 400ms sur l'endpoint de liste des factures » est un test que l'agent peut écrire avant même d'écrire la fonctionnalité.

4. Mettez les chemins de fichiers et les contraintes techniques dans le document, pas dans le chat. Le contexte du chat s'évapore entre les sessions. Le cahier des charges, lui, reste. C'est aussi pour ça que le mode plan de Claude Code compte : il lit vos fichiers et propose un plan sans rien modifier tant que vous n'avez pas approuvé, et cette étape de validation est bien plus utile quand le plan est vérifié par rapport à un cahier des charges écrit plutôt qu'à votre souvenir de ce que vous aviez demandé.

Voici le portail de factures, découpé en une phase qu'un agent peut exécuter en une seule passe.

# Tâche de build : Téléversement et extraction de factures (Phase 1 sur 3)

## Contraintes techniques (ne pas remplacer)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. Aucune nouvelle dépendance sans demander d'abord.

## Fichiers que vous pouvez créer ou modifier
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Ne pas toucher
- lib/auth/*  (l'authentification arrive en Phase 2 ; ne pas ajouter de flux
  de connexion maintenant)
- Tout ce qui se trouve sous app/(marketing)/
- Le schéma de commandes existant. Le lire. Ne jamais le migrer.

## Critères d'acceptation (à écrire d'abord comme des tests)
1. POST /api/invoices rejette les fichiers non-PDF avec 415 et les fichiers
   de plus de 20 MB avec 413.
2. Une ligne avec une confiance < 0.85 met invoice.status = 'review',
   jamais 'approved'.
3. Chaque insertion écrit une ligne d'audit avec actor_id, action,
   created_at.
4. GET /api/invoices?vendor=&from=&to=&status= répond en moins de 400ms sur
   un jeu de données de 10,000 lignes.

## Hors périmètre pour cette passe
Rapprochement de commandes, interface des écarts, export CSV, notifications
e-mail.

Trois choses ont changé par rapport à la version humaine : les chemins de fichiers sont apparus, une liste des zones interdites est apparue, et les critères d'acceptation sont devenus des assertions plutôt que des phrases. L'agent auquel vous le confiez compte moins qu'on ne le pense, même si la comparaison des agents de codage vaut le détour avant de trancher. Gardez les exigences et les règles de projet dans des fichiers séparés : les règles Cursor et CLAUDE.md portent les conventions et l'outillage, le PRD porte ce qu'il faut construire. Si vous voulez de l'aide de l'IA pour produire le périmètre plutôt que pour le consommer, c'est un workflow différent. Et pour l'étape d'extraction elle-même, le choix du modèle et la boucle d'évaluation relèvent d'un travail d'intégration IA à part entière.

Ce Qui Change Quand le PRD Part Chez une Équipe Externe

Quand le PRD part chez une agence ou un prestataire, il cesse d'être un document d'alignement pour devenir du langage contractuel. L'ambiguïté qu'une équipe interne résout en deux minutes de discussion devient une demande de changement avec un prix. Le Pulse of the Profession du PMI a constaté que 47% des projets en échec manquent leurs objectifs à cause d'une gestion imprécise des exigences. C'est toute la raison d'être de ce document.

Trois sections pèsent de manière disproportionnée dans ce contexte. Les critères d'acceptation deviennent des jalons de validation, ils doivent donc être observables par quelqu'un qui n'est pas ingénieur. Les questions ouvertes ont besoin d'un responsable nommé côté client, parce que le prestataire ne peut pas y répondre et construira en contournant le vide. Et l'historique des changements cesse d'être bureaucratique : c'est la trace de ce qui a été convenu et quand, la première chose que tout le monde va chercher en cas de désaccord.

La phrase qu'on a vue tourner mal plus d'une fois, c'est une variante de « les utilisateurs peuvent exporter leurs données ». Personne n'écrit dans quel format. Chez nous, la version coûteuse de ça s'est traduite par un export CSV livré alors que le client voulait un pack de factures PDF mis en forme avec sa charte graphique, et refaire le travail a englouti environ une semaine d'ingénierie que personne n'avait budgétée. Honnêtement, la faute se trouvait dans le document, pas dans la livraison. Un critère d'acceptation l'aurait détecté en cinq minutes : given une demande d'export, when le fichier est généré, then c'est un PDF conforme à la mise en page fournie. Une ligne de non-objectifs l'aurait aussi détecté, dans l'autre sens. C'est donc devenu une règle dans notre phase de découverte : toute exigence accrochée à un nom comme « export », « rapport » ou « notification » se voit attribuer un format, un déclencheur et un exemple concret avant la signature d'un statement of work.

C'est en grande partie ce qu'est notre façon de mener les projets d'applications web : transformer la moitié floue du cahier des charges d'un client en lignes testables avant que quiconque n'écrive du code.

Ce Que Dit Vraiment r/ProductManagement sur les Modèles de PRD

Cherchez product requirements document template reddit et vous trouverez la même plainte qui revient sans cesse sur r/ProductManagement : la surcharge de modèles. Des PRD que personne ne lit. Des sections remplies parce que le modèle avait un titre, pas parce que quelqu'un avait besoin du contenu. Des documents qui périment le lendemain du kickoff et se font discrètement remplacer par un fil Slack. C'est une critique juste pour la plupart des modèles, y compris plusieurs parmi les dix premiers résultats de cette recherche.

Notre réponse : supprimer les sections plutôt que les remplir de rien. Les personas partent en premier quand les utilisateurs sont évidents. L'annexe part en second. Les jalons peuvent vivre dans le tracker à la place. La seule qu'on ne supprime jamais, c'est les non-objectifs, parce que c'est la seule section qui raccourcit à mesure qu'on avance, et la seule qui empêche vraiment le débat qu'on aurait sinon en semaine six.

Foire Aux Questions

Qu'est-ce qu'un document d'exigences produit ?

Un document d'exigences produit (PRD) énonce ce qu'une équipe construit et pourquoi : le problème, les objectifs et leurs indicateurs, les non-objectifs, à qui c'est destiné, et les exigences qui définissent le « terminé ». Il exclut délibérément les détails d'implémentation, qui relèvent d'un document de conception technique rédigé ensuite par l'ingénierie.

Comment rédiger un document d'exigences produit ?

Commencez par l'énoncé du problème et refusez d'y utiliser un langage de solution. Ajoutez des objectifs mesurables avec une référence et une date cible, puis rédigez les non-objectifs. Remplissez les personas, les user stories avec des critères d'acceptation Given/When/Then, les exigences fonctionnelles et non fonctionnelles, les dépendances, les jalons, et les questions ouvertes avec leurs responsables.

Que doit contenir un PRD ?

Douze sections : en-tête avec historique des changements, énoncé du problème, objectifs et indicateurs de succès, non-objectifs, utilisateurs et personas, user stories avec critères d'acceptation, exigences fonctionnelles, exigences non fonctionnelles, dépendances et intégrations, jalons et phasage, questions ouvertes et risques, et une annexe. Tout ce qui n'entre dans aucune de ces cases n'est probablement pas une exigence.

Quelle doit être la longueur d'un PRD ?

Une à deux pages pour une fonctionnalité isolée, trois à cinq pour une phase produit, cinq à huit quand une équipe externe le construit et que les critères d'acceptation font office de jalons de validation. La longueur suit le nombre de décisions enregistrées, pas la taille du produit. Les sections vides doivent être supprimées, pas gonflées artificiellement.

Un PRD est-il la même chose qu'un BRD ?

Non. Un document d'exigences métier (BRD) énonce le résultat commercial que l'organisation souhaite et les contraintes autour de celui-ci, généralement avant qu'une solution soit choisie. Un PRD décrit le produit qui le délivre : utilisateurs, comportement, critères d'acceptation, non-objectifs. Dans les plus petites entreprises, le BRD se résume souvent à la section énoncé du problème.

Les équipes agiles écrivent-elles encore des PRD ?

Oui, en général sous forme de one-pager. Le backlog porte le travail, mais les tickets sont très mauvais pour porter le pourquoi, les non-objectifs et l'indicateur de succès. Les équipes qui sautent complètement le PRD tendent à le redécouvrir sous forme d'une page Confluence appelée « contexte » trois sprints après le début du projet.

Peut-on écrire un PRD en Markdown ?

Le Markdown est le meilleur format pour ça. Il se colle proprement dans Notion, Confluence, Google Docs et Linear, se versionne dans Git à côté du code sous le nom PRD.md, se diffe correctement dans une pull request, et c'est le seul format qu'un agent de codage IA lit sans perdre la structure. Le modèle ci-dessus est en Markdown pour exactement ces raisons.

Comment écrire un PRD pour un agent de codage IA ?

Soyez explicite là où vous seriez normalement bref. Formulez les non-objectifs positivement, parce qu'un agent ne peut pas déduire un périmètre d'une omission. Découpez le document en phases réalisables en une seule passe. Rédigez les critères d'acceptation comme des assertions chiffrées. Nommez les fichiers que l'agent peut modifier et ceux auxquels il ne doit pas toucher.

Quelle est la différence entre un PRD et un document de conception technique ?

Le PRD répond au quoi et au pourquoi : problème, utilisateurs, comportement, critères d'acceptation, non-objectifs. Le document de conception technique répond au comment : architecture, modèle de données, contrats d'API, arbitrages envisagés. Le produit possède généralement le premier, l'ingénierie le second, et le document de conception doit pouvoir se lire comme une réponse au PRD.

Qui est propriétaire du PRD : le produit, l'ingénierie ou le client ?

Le produit possède le document et les décisions qu'il contient. L'ingénierie possède le retour sur la faisabilité et les exigences non fonctionnelles. Sur les projets en agence, le client possède l'énoncé du problème, les objectifs, et toute question ouverte concernant son propre métier. Une propriété partagée de l'ensemble du document signifie généralement que personne ne le maintient.

Pour Conclure

Trois choses à retenir. Le modèle n'est utile qu'une fois rempli, donc copiez la structure de l'exemple concret plutôt que la version vide. Les non-objectifs sont la section qui a le plus de valeur par mot dans le document, et la première que les gens sautent. Et des critères d'acceptation écrits comme des assertions testables servent aussi bien deux lecteurs : un ingénieur qui valide une livraison, et un agent qui écrit le test.

Si vous rédigez un PRD destiné à une équipe externe et que vous voulez un second avis avant qu'il ne devienne un contrat, on est ravis de le lire et de marquer les lignes ambiguës. C'est exactement la même passe qu'on applique sur nos propres projets d'applications web.