PRD
Document produit qui aligne le but, les utilisateurs, le périmètre, les comportements attendus et les critères de succès avant l'exécution.
IntermédiaireSources vérifiées le .
Un PRD, Product Requirements Document, décrit le but, les utilisateurs, les besoins, le périmètre, les comportements attendus et les critères de succès d'un produit ou d'une fonctionnalité. Dans un projet agentique, il sert de contrat lisible avant que l'agent ou l'équipe ne transforme l'intention en tâches et en code.
Définition complète
Le PRD donne une direction commune avant l'exécution. Il explique le problème à résoudre, les personnes concernées, les résultats attendus, les limites du périmètre et la manière de vérifier que la fonctionnalité remplit son rôle. Une équipe produit, un développeur ou un agent peut ensuite prendre des décisions cohérentes sans deviner l'intention initiale.
Un brief expose surtout le contexte et la demande. Le PRD précise le comportement du produit et ses critères de succès, tandis que la spécification technique décrit l'architecture, les interfaces et les contraintes de réalisation. Le plan d'implémentation ordonne enfin les tâches qui transforment ces décisions en travail exécutable.
Ce qu'un PRD utile contient
Un format court peut couvrir l'objectif, les utilisateurs, leurs besoins, le périmètre inclus et exclu, les parcours attendus, les contraintes connues et les critères d'acceptation. Chaque élément doit aider à arbitrer une décision réelle pendant la construction.
Les détails techniques arrivent ensuite dans une spécification dédiée lorsque le projet le demande. Cette séparation permet de faire évoluer la solution sans perdre le besoin produit qui justifie son existence.
Exemple court
Pour une prise de rendez-vous, le PRD peut fixer un objectif simple : permettre à un prospect qualifié de comprendre les étapes, choisir un créneau et recevoir une confirmation. Le périmètre inclut le calendrier, la validation des coordonnées et le message final. Le succès se mesure avec le taux d'ouverture, le démarrage du parcours et la confirmation du rendez-vous.
Un document vivant, pas un roman
Le PRD évolue lorsqu'un apprentissage utilisateur, une contrainte ou une décision validée change le produit. Il garde la date, la raison et l'auteur de chaque évolution importante afin que l'équipe comprenne ce qui a changé.
Une documentation exhaustive ralentit la lecture et masque les décisions utiles. Le document reste assez précis pour réduire les ambiguïtés, puis renvoie vers les spécifications et plans d'implémentation quand le niveau technique devient nécessaire.
Analogie pour comprendre
Le PRD ressemble au plan d'usage d'un espace avant le travail de l'architecte. Il décrit qui va l'utiliser, dans quel but, avec quelles contraintes et comment reconnaître un résultat réussi. Les plans techniques viennent ensuite traduire cette intention en structure.
En pratique
Avant de confier le projet à une équipe ou un agent, le PRD peut tenir sur une page si le périmètre reste simple. Les zones floues deviennent des questions explicites, les critères d'acceptation restent observables et chaque décision structurante est datée.
Termes liés
Pour aller plus loin
Sources primaires
Questions fréquentes
Le PRD décrit le besoin, le comportement attendu et les critères de succès. La spécification technique explique comment l'architecture, les données et les interfaces vont produire ce comportement.
Sa longueur dépend du risque et du nombre de décisions à aligner. Une fonctionnalité simple peut tenir sur une page, tandis qu'un produit complexe demande plusieurs sections reliées à des documents techniques ciblés.
Oui, si le périmètre et les critères d'acceptation sont précis. L'agent transforme ensuite le PRD en plan d'implémentation, puis l'équipe valide les choix techniques et les actions sensibles avant l'exécution.