Méthode PRP :briefer Claude pour qu'il construise juste

Un Product Requirement Prompt — un PRP — est un court document que vous rédigez avant de demander à Claude de construire une fonctionnalité. La méthode PRP : quatre sections, environ trois cents mots, vingt minutes d'écriture — et elle transforme deux jours de débogage en une à trois heures d'implémentation propre. C'est l'habitude à plus fort effet de levier dans la construction assistée par IA, et presque aucun débutant ne l'utilise.

« Claude, construis-moi un parcours d'inscription » donne l'impression d'avancer. Ce n'est pas le cas. Cet article vous donne la méthode, les quatre sections et un vrai PRP tiré de mon propre produit — mot pour mot — pour que vous puissiez copier la structure dès ce soir.

Qu'est-ce que la méthode PRP ?

L'IA ne remplace pas la réflexion. L'IA remplace la frappe. La frappe n'a jamais été la contrainte — c'était la conception de la chose que vous tapez. Quand vous donnez à Claude une instruction vague, il comble chaque trou avec des hypothèses : quelle table de base de données utiliser, comment votre appli est structurée, ce que signifie « terminé ». Certaines de ces hypothèses seront fausses, et vous les paierez en heures de débogage que vous ne pouvez pas vous permettre sur vos soirées et vos week-ends.

Un PRP comble les trous avant le début de la construction. Ce n'est pas optionnel. La différence entre « Claude, construis-moi un parcours d'inscription » et un PRP correctement structuré, c'est la différence entre deux jours à déboguer du n'importe quoi et vingt minutes d'implémentation propre.

Les quatre sections d'un PRP

Objectif. Ce que vous construisez, en une phrase. « Construire un parcours d'inscription qui crée un utilisateur, crée une entreprise, les relie et envoie un e-mail de bienvenue. »

Contexte. Tout ce que Claude doit savoir et ne peut pas déduire : votre schéma de base de données, votre fournisseur d'authentification, votre service d'e-mail, votre framework frontend, les schémas existants dans votre code, des liens vers la documentation pertinente. Plus vous fournissez de contexte, moins Claude hallucine, et plus le résultat se rapproche du niveau production.

Plan d'implémentation. Un plan étape par étape de ce que la fonctionnalité doit faire. Pas du code réel — c'est le travail de Claude — mais assez de structure pour que Claude ne puisse pas se perdre. Cela vous force à réfléchir à la fonctionnalité avant de la déléguer, et donne à Claude des rails sur lesquels construire.

Boucle de validation. Comment vous saurez que la fonctionnalité marche : les cas de test que vous exécuterez, les cas limites à gérer. Claude peut aussi écrire les tests — mais vous devez préciser quoi tester avant qu'il ne les écrive, sinon il testera les mauvaises choses.

Un vrai PRP, mot pour mot

Voici à quoi ressemblait celui d'une fonctionnalité que j'ai construite dans FIKR Space — une simple page de préférences de notifications par e-mail :

Objectif : Construire une page de préférences de notifications où les utilisateurs connectés choisissent quels types de notifications par e-mail ils reçoivent : résumé hebdomadaire, nouveautés produit, alertes de sécurité. Enregistrer les préférences dans l'enregistrement de l'utilisateur. Par défaut, tout activé.

Contexte :

• Stack : React, TypeScript, Supabase, Tailwind.
• La table users existante a les colonnes id, email, created_at. Il faut ajouter une colonne JSON notification_preferences de forme { digest: bool, updates: bool, security: bool }.
• Le contexte d'authentification fournit déjà l'utilisateur courant via le hook useAuth() dans /hooks/useAuth.ts.
• La page se trouve à /settings/notifications. Le routage est déjà configuré.
• Suivre le schéma de la page de réglages existante /pages/settings/profile.tsx pour la mise en page et le style du formulaire.

Plan d'implémentation :

1. Ajouter la colonne JSON notification_preferences à la table users via une migration Supabase. Valeur par défaut : les trois à true.
2. Créer le composant de page dans /pages/settings/notifications.tsx.
3. Au montage, charger depuis Supabase les préférences de l'utilisateur courant.
4. Afficher trois interrupteurs avec le composant existant <Switch>.
5. À chaque changement, appliquer un debounce de 500 ms, puis enregistrer dans Supabase.
6. Afficher une notification toast en cas de succès ou d'échec de l'enregistrement.
7. Gérer l'état de chargement pendant que la requête initiale est en cours.

Boucle de validation :

• Se connecter. Aller sur /settings/notifications. Les trois interrupteurs doivent apparaître activés.
• En désactiver un. Rafraîchir la page. L'interrupteur doit toujours être désactivé.
• Couper le réseau. Basculer un interrupteur. Un toast d'erreur doit s'afficher.
• Rétablir le réseau. Rebasculer. L'enregistrement doit se faire et un toast de succès s'afficher.

Cela fait environ trois cents mots. Claude génère l'implémentation en moins de dix minutes. Durée totale entre « je veux cette fonctionnalité » et « elle est en production » : peut-être quatre-vingt-dix minutes, en comptant la rédaction du PRP, la génération du code, les tests manuels et le déploiement.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Ce qui se passe sans PRP

Comparez avec la même fonctionnalité sans PRP. Vous tapez « construis-moi une page de préférences de notifications » dans Claude. Il produit quelque chose. Ce quelque chose ne sait pas quelle table de base de données utiliser, alors il en invente une. Il ne connaît pas votre bibliothèque de composants existante, alors il génère de nouveaux composants qui ne ressemblent pas au reste de l'appli. Il ne connaît pas vos conventions d'enregistrement, alors il enregistre à chaque frappe. Vous passez deux heures à réécrire l'essentiel de ce qu'il vous a donné pour l'aligner sur votre code. La fonctionnalité est livrée en une demi-journée au lieu d'une heure et demie — et le code obtenu est pour moitié le vôtre et pour moitié des suppositions de Claude cousues ensemble.

Pourquoi le PRP paraît lourd — et pourquoi vous l'écrivez quand même

La méthode PRP paraît lourde au début. Elle donne l'impression de plus de travail que de simplement taper dans Claude en espérant. La première fois que vous en sautez un et que Claude génère quinze cents lignes à jeter, vous comprendrez. Vingt minutes d'écriture vous économisent de quatre à huit heures de nettoyage par fonctionnalité, et sur une construction complète, cela se cumule en la différence entre livrer en huit semaines et livrer en vingt.

Taper dans Claude en espérant a un nom et une fin prévisible — j'ai écrit séparément sur le piège du vibe coding. En bref : la vitesse sans structure donne l'impression d'avancer jusqu'au moment où ce n'est plus le cas. Le PRP est la façon de garder la vitesse et d'éviter l'effondrement.

Et remarquez ce que le PRP vous impose discrètement : réfléchir. Écrire le plan d'implémentation, c'est parcourir la fonctionnalité étape par étape avant que le moindre code existe. Écrire la boucle de validation, c'est décider de ce que « ça marche » veut dire avant de voir quelque chose qui a l'air de marcher. Cette réflexion est votre travail — c'est la partie que l'IA ne sait pas faire, et celle que le cadre BUILD entraîne délibérément.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Qu'est-ce qu'un Product Requirement Prompt (PRP) ?

Un PRP est un court document que vous rédigez avant de demander à l'IA de construire une fonctionnalité. Il comporte quatre sections — objectif, contexte, plan d'implémentation et boucle de validation — et son rôle est de supprimer les hypothèses que Claude ferait sinon sur votre base de données, vos conventions et le sens de « terminé ».

Quelle longueur doit avoir un PRP ?

Environ trois cents mots pour une fonctionnalité de taille moyenne, soit à peu près vingt minutes d'écriture. Vous obtenez ainsi une fonctionnalité qui marche en une à trois heures de construction, au lieu des mêmes heures plus deux jours de débogage en prime.

Faut-il être technique pour écrire un PRP ?

Non. Le plan est en langage simple, étape par étape, pas en code — « vérifier si l'e-mail existe déjà, créer l'utilisateur, envoyer l'e-mail de bienvenue ». Vous décrivez ce qui doit se passer et comment vous le vérifierez ; Claude gère l'implémentation. Connaître votre produit en profondeur compte bien plus que connaître la syntaxe.

Combien de temps la méthode PRP fait-elle réellement gagner ?

De quatre à huit heures de nettoyage par fonctionnalité. Sur une construction de huit semaines avec une fonctionnalité majeure par semaine, cela se cumule en une livraison en huit semaines au lieu de vingt — mêmes outils, même IA, discipline différente.