PRD, spec et RFC : trois documents, trois publics, et lequel écrire en premier

Les trois documents côte à côte

Les lignes qui comptent le plus sont la première et la dernière. Chaque document répond à une question, et chacun a sa façon caractéristique de mal tourner.

À quoi sert un PRD

Un document d'exigences produit existe pour que toutes les personnes qui touchent au produit s'accordent sur le problème et sur les limites avant que quiconque ouvre un éditeur. L'entrée du glossaire sur le PRD en décrit l'anatomie complète ; les parties qui méritent leur place sont :

• Le problème en un paragraphe, avec qui l'a et comment vous le savez.
• Objectifs et non-objectifs. Les non-objectifs sont la moitié la plus utile. « Pas d'édition hors ligne en v1 » évite un mois de débats.
• Des exigences numérotées avec un identifiant stable (REQ-007), une priorité et des critères d'acceptation qu'on pourrait confier à un testeur.
• Les questions ouvertes qui le sont encore, datées.

Le PRD est le document qu'un client valide et celui contre lequel un audit des exigences vérifie ensuite ce qui a été construit. Pour que cela fonctionne, il lui faut des identifiants qui ne changent pas et une copie figée à la validation. Un PRD réécrit sur place chaque semaine ne peut pas être audité, parce que personne ne peut dire ce qui avait été convenu.

Ce qu'un PRD n'est pas : une liste d'écrans, un schéma de base de données ou une conception technique. Dès qu'il dit « stocker ceci dans une colonne JSONB », il est devenu une spec avec le mauvais chapeau.

Si vous en écrivez un de zéro, le modèle de PRD contient les sections dans cet ordre, et l'article précédent sur rédiger un PRD avec l'IA explique comment le remplir.

À quoi sert une spec

Une spec (spécification fonctionnelle, spécification technique, design doc ; les noms se confondent) traduit une exigence en un comportement assez précis pour être construit et testé. Là où le PRD dit « les clients peuvent exporter leurs données », la spec dit quels formats, comment le fichier est nommé, ce qui arrive aux pièces jointes de plus de 25 Mo, si l'export tourne en arrière-plan et ce que la personne voit pendant ce temps.

Une bonne spec a une forme différente d'un PRD :

1. Une exigence ou une fonctionnalité par spec. Les specs qui couvrent tout le produit sont des PRD trop détaillés.
2. Des états et des transitions, pas de la prose. Un tableau « quand l'utilisateur fait X dans l'état Y, Z se produit » attrape plus de bugs que des paragraphes.
3. Les cas limites listés explicitement : vide, maximum, concurrent, hors ligne, permission refusée.
4. Les interfaces : la forme de l'API, les noms d'événements, les champs et leurs types.
5. Ce qui est hors périmètre pour cette version, pour que personne ne le construise par accident.

Les specs ont le droit de changer souvent, jusqu'au moment où la fonctionnalité sort. Ce sont des documents de travail pour les personnes qui construisent, donc l'historique des versions compte plus que la validation. Dans une équipe de cinq, la spec est souvent une page sous le projet, à côté du PRD, que l'ingénieur modifie au fil de l'eau pendant que le PM commente plutôt que de réécrire.

La distinction entre spec produit et spec technique tient surtout à qui écrit les cas limites. La spec produit liste ce que la personne voit dans chaque état ; la spec technique, comment le système y arrive. Les petites équipes les fusionnent en général en un document à deux sections, et c'est très bien.

À quoi sert un RFC

Un RFC propose un changement coûteux à défaire et demande aux personnes concernées d'objecter maintenant plutôt que plus tard. Exemples tirés de la gestion d'une petite entreprise sur ces outils : passer de permissions par projet à des permissions sur tout l'espace, déplacer la facturation d'un prestataire à un autre, adopter un monorepo, ou retirer une langue du site marketing.

La forme est simple et stable depuis les années 1960, quand les premiers RFC d'internet étaient littéralement des mémos demandant des commentaires :

• Contexte : ce qui est vrai aujourd'hui et pourquoi c'est un problème.
• Proposition : le changement, concrètement.
• Alternatives envisagées, avec la raison du rejet de chacune. Cette section est ce qui distingue un RFC d'une annonce.
• Conséquences : ce qui devient plus difficile, pas seulement ce qui devient plus facile.
• Période ouverte : une date limite pour les commentaires, et qui décide.

Un RFC est lu par plus de gens qu'il n'y en aura jamais pour agir dessus. C'est le seul des trois documents qui est terminé quand les commentaires s'arrêtent, pas quand le code est livré. Une fois tranché, il doit être marqué accepté ou refusé et laissé tel quel ; un changement ultérieur a son propre RFC qui cite le premier. Certaines équipes parlent de decision records ou d'ADR ; la mécanique est la même.

L'échec classique est le RFC écrit après la décision, pour lui donner une trace écrite. Les gens le sentent, et ils cessent de commenter le suivant.

Quel document vous faut-il maintenant ?

Parcourez ces questions dans l'ordre.

1. Y a-t-il un produit ou une fonctionnalité qui n'existe pas encore, et plus d'une personne doit s'accorder sur ce que c'est ? Écrivez un PRD. S'il s'agit d'une fonctionnalité dans un produit existant, ajoutez-la au PRD du produit comme nouvelle exigence numérotée plutôt que de démarrer un document à part.
2. Y a-t-il une exigence avec plus de deux ou trois cas limites, ou une interface sur laquelle quelqu'un d'autre construira ? Écrivez une spec pour cette exigence. Liez-la depuis l'exigence.
3. Y a-t-il un changement qui touche plus d'une équipe, coûte plus d'une semaine ou est difficile à annuler ? Écrivez un RFC et donnez-lui une date de clôture.
4. Rien de tout cela ? Écrivez un ticket avec des critères d'acceptation et sautez le document. Une tâche de deux jours n'a pas besoin de PRD.

Une équipe de six qui construit un produit client aura typiquement un PRD, trois à dix specs sur la vie du projet, et un ou deux RFC par an. Si vous avez plus de RFC que de specs, vous débattez plus que vous ne construisez.

La nouveauté de 2026 : les agents lisent ces documents en premier

Il y a deux ans, le premier lecteur d'une spec était un développeur. Aujourd'hui, c'est souvent un agent de codage, un agent de planification dans votre espace de travail, ou un assistant connecté via MCP. Cela change ce qu'est un bon document de plusieurs façons pratiques.

La structure l'emporte sur la prose. Un agent qui reçoit un PRD avec des exigences numérotées et des critères d'acceptation peut planifier des tickets en face et rendre compte de la couverture. Avec quatre pages de récit, il les résumera et perdra les limites. Titres, identifiants et tableaux ne sont plus des préférences de style ; ce sont l'interface.

Les non-objectifs sont lus au pied de la lettre. Un humain survole « pas de hors-ligne en v1 » et s'en souvient. Un agent qui planifie du travail ne le respectera que si c'est dans le document qu'on lui a donné. Mettez les non-objectifs dans le PRD, pas dans un fil de discussion.

La baseline compte davantage. Quand un agent écrit des exigences et qu'un autre planifie des tickets à partir d'elles, la dérive devient facile : une exigence est adoucie en une passe et personne ne le remarque. Figer le PRD à la validation et comparer les versions suivantes avec lui est la façon de l'attraper. Dans Atrix, l'exécution Develop de l'agent écrit un document d'exigences à partir d'un brief, les exigences peuvent être figées en baseline, et un audit des exigences montre couverture et dérive par rapport à cette baseline. Il ne scanne pas le code ; il compare des enregistrements.

Les specs deviennent le plan de test. Si la spec est un tableau d'états et de comportements attendus, un agent de codage peut transformer chaque ligne en test. Si c'est de l'intention en paragraphes, il ne le peut pas.

Les RFC restent humains. La décision d'un RFC est un jugement sur les compromis que l'organisation est prête à faire. Un agent peut bien rédiger la section des alternatives et résumer les commentaires. Il ne devrait pas être celui qui décide.

Garder les trois au même endroit

L'endroit où vivent les documents compte plus qu'avant, parce qu'un agent ne peut lire que ce qu'il atteint. Un PRD dans Google Docs, une spec dans un wiki et un RFC dans la description d'une pull request, ce sont trois permissions, trois champs de recherche et aucun lien entre eux.

Ce qui a marché pour nous : une arborescence de pages par produit. Le PRD est la page de tête, chaque spec est une page enfant liée depuis son exigence, et les RFC vivent dans un dossier au niveau de l'espace avec le statut dans le titre. Les éléments de roadmap renvoient aux exigences, donc quand un élément glisse, l'exigence qu'il sert est à un clic. Le modèle de roadmap produit est construit sur ce lien.

Atrix est une façon d'y parvenir, avec des pages imbriquées sous un projet, la coédition en direct, l'historique des versions et l'export Markdown ; son serveur MCP permet aussi à un assistant externe de lire les mêmes pages. Notion et Confluence font aussi l'imbrication et l'historique. La propriété qui compte est que les trois documents soient accessibles par le même outil, avec les mêmes permissions.

FAQ

Quelle est la différence entre un PRD et une spec ?

Un PRD dit quoi construire et pourquoi, au niveau d'exigences numérotées avec critères d'acceptation. Une spec dit comment l'une de ces exigences se comporte dans chaque état, assez précisément pour être construite et testée. Le PRD est validé puis figé ; la spec change jusqu'à la sortie de la fonctionnalité.

Un RFC est-il la même chose qu'un design doc ?

Pas tout à fait. Un design doc explique comment quelque chose sera construit ; un RFC demande si un changement doit être fait et invite aux objections avant une décision. Beaucoup de design docs incluent une section « alternatives envisagées » façon RFC, et certaines équipes emploient les noms indifféremment, mais ce qui définit le RFC est la période de commentaires et la décision à la fin.

Les startups ont-elles besoin de PRD ?

Une équipe de deux qui construit sa première version peut se contenter d'un énoncé du problème d'une page et d'une liste de tickets. Dès la première fois qu'un client, un investisseur ou une recrue doit savoir ce qui a été convenu, un PRD avec exigences numérotées se rentabilise. Le déclencheur est que plus d'une personne doive s'accorder, pas la taille de l'entreprise.

Qui écrit la spec, le PM ou l'ingénieur ?

En général l'ingénieur ou le designer le plus proche du travail, avec le PM en relecture. Le PRD est le document du PM ; la spec, celui de qui construit. Dans une équipe sans PM, le fondateur écrit le PRD et celui ou celle qui construit la fonctionnalité écrit la spec.

Un PRD doit-il contenir des détails techniques ?

Non. L'architecture, les schémas et les formes d'API relèvent d'une spec ou d'une conception technique. Un PRD qui fixe l'implémentation verrouille des décisions qui reviennent aux personnes qui construisent, et il se périme dès qu'un ingénieur choisit une autre approche.

Un agent IA peut-il écrire ces documents ?

Il peut rédiger les trois, et il rédige bien les PRD et les specs quand on lui donne un brief clair et les pages existantes en contexte. Les parties à garder humaines sont l'énoncé du problème dans le PRD, la décision dans un RFC, et la validation qui transforme les exigences en baseline.

Prochaine étape

Si vous démarrez un produit, écrivez d'abord le PRD ; le modèle de PRD est une page Markdown avec les sections ci-dessus dans l'ordre. Une fois les exigences en place, le modèle de roadmap produit relie chaque élément de roadmap à l'exigence qu'il sert, et c'est le lien dont un audit dépendra plus tard. Pour voir comment ces documents fonctionnent dans un espace de travail avec un agent, consultez docs et tableaux blancs et la page de l'agent IA.