Les 6 documents à préparer avant de vibe coder ton site ou ton app
Ce qu'il faut mettre dans chacun, un exemple concret, l'erreur classique, et le prompt qui les écrit avec Claude.
Quand tu demandes à Claude de construire un site sans lui dire précisément quoi, il ne s'arrête pas pour te poser vingt questions : il décide à ta place. La page d'accueil, les couleurs, la base de données, l'ordre des étapes, tout est choisi au mieux, c'est-à-dire au hasard de ce qui ressemble le plus à un projet moyen. Tu passes ensuite des heures à défaire ce que tu n'avais pas demandé.
Six documents courts règlent ça. Chacun répond à une question que Claude se poserait de toute façon, et qu'il tranche seul si tu ne l'as pas fait. Ils se lisent en dix minutes, ils vivent dans un dossier docs/ à côté du code, et un prompt en bas de ce guide les écrit avec toi, question par question.
Les six, et dans quel ordre les écrire
Dans l'ordre où ils se nourrissent les uns les autres. Le plan vient en dernier parce qu'il dépend de tout le reste.
PRD, ce que fait le produit, fonctionnalité par fonctionnalité.
App flow, les pages et ce qui se passe quand on clique.
Design system, couleurs, polices, et à quoi ressemble chaque page.
TRD, le document technique : la stack et les services.
Schéma back-end, où vivent les données et qui peut les voir.
Plan d'implémentation, quoi construire, dans quel ordre, sans rien casser.
Le PRD : ce que fait ton produit
PRD veut dire Product Requirements Document. C'est la liste des fonctionnalités, une par une, avec leur priorité. Tout ce qui n'y est pas n'existe pas : c'est la règle que Claude doit suivre.
Ce que tu mets dedans
Le produit en trois phrases. Pour qui, quel problème, ce qui le rend différent.
Les utilisateurs. Chaque type de personne qui s'en sert, et ce que chacun veut faire. Le client et le restaurateur n'ont pas la même appli.
Les fonctionnalités, avec une priorité. Indispensable pour la v1, souhaitable, plus tard. Une fonctionnalité, c'est une action complète : « réserver une table », pas « page de réservation ».
Ce qui est hors périmètre. Écrit noir sur blanc. C'est la ligne qui évite les dérives.
Ce qui prouve que ça marche. Un ou deux critères mesurables : une réservation complète en moins d'une minute, zéro double réservation.
Réserver une table (indispensable) Le client choisit une date, une heure, un nombre de couverts. Si le créneau est complet, on propose les deux créneaux les plus proches. Confirmation par e-mail. Annulation possible jusqu'à 2 h avant. Hors périmètre v1 : paiement en ligne, menu, avis.
L'app flow : ce qui se passe quand on clique
La liste des pages, et pour chaque action le chemin exact : ce qu'on voit, où mène chaque bouton, ce qui s'affiche quand c'est vide, quand ça charge, quand ça échoue. C'est ce document qui évite les boutons qui ne mènent nulle part.
Ce que tu mets dedans
La liste des pages. Avec leur adresse et qui y a accès : visiteur, client connecté, restaurateur.
Les parcours, clic par clic. Un parcours par fonctionnalité du PRD, du point de départ à la fin, en phrases courtes.
Les états qu'on oublie. Vide (aucune réservation), chargement, erreur, succès, et le retour en arrière.
Les règles de navigation. Que fait un visiteur non connecté qui clique sur « Mes réservations » ? Où atterrit-on après la connexion ?
Parcours : réserver
Accueil -> bouton « Réserver » -> page /reserver
formulaire : date, heure, couverts, nom, e-mail, tel
-> valider
créneau libre -> /confirmation + e-mail envoyé
créneau complet -> message + 2 autres créneaux
champ manquant -> le champ passe en rouge, rien
n'est envoyéLe design system : à quoi ça ressemble
Un design system complet, c'est pour une équipe. Toi, tu as besoin d'un design brief : les valeurs exactes et une description de chaque page en mots. Sans lui, Claude sort le même site bleu et gris que tout le monde.
Ce que tu mets dedans
Les couleurs, en code hexadécimal. Fond, texte, accent, succès, erreur. Pas « un orange chaleureux » : #C2410C.
Les polices. Une pour les titres, une pour le texte, où les télécharger, les tailles de base.
Les composants de base. Bouton, carte, formulaire, message d'erreur : rayon des coins, ombre, espacement. Trois lignes chacun suffisent.
L'allure de chaque page, en mots. Ce qu'on voit en premier, l'ordre des blocs, ce qui est mis en avant. Une référence visuelle si tu en as une (un lien, une capture).
Le ton. Tutoiement ou vouvoiement, longueur des textes, humour ou pas.
Couleurs : fond #FAF7F2, texte #1F1A17, accent #C2410C, erreur #B91C1C Polices : titres Fraunces, texte Inter, base 16 px Boutons : coins 12 px, pas d'ombre, accent plein Page d'accueil : photo plein écran, une phrase, un seul bouton « Réserver ». Rien d'autre au-dessus de la ligne de flottaison.
Le TRD : les outils utilisés
TRD veut dire Technical Requirements Document. C'est la stack figée : le framework, la base de données, l'authentification, les e-mails, le paiement, l'hébergement. Figée, parce que la pire chose qui puisse arriver est que Claude change d'outil en cours de route.
Ce que tu mets dedans
Un outil par besoin, et un seul. Framework, base, auth, e-mails, hébergement, et pour chacun pourquoi celui-là. Si tu ne sais pas, laisse Claude proposer, puis valide et fige.
Les services externes et ce qu'ils coûtent. Le gratuit a des limites : combien d'e-mails par jour, combien de lignes en base. Écris-les.
Les variables d'environnement, par leur nom. Les clés vivent dans un fichier .env qui n'est jamais partagé, jamais collé dans une conversation. Le document liste les noms, jamais les valeurs.
Les contraintes. Mobile d'abord ou pas, langues, performance attendue, accessibilité.
Les interdits. Pas de nouvelle dépendance sans accord, pas de changement de base de données, pas de code en dur pour une clé.
Framework : Next.js (App Router) Base + auth : Supabase, projet en région Europe E-mails : Resend (100 e-mails/jour en gratuit) Hébergement : Vercel Variables : SUPABASE_URL, SUPABASE_ANON_KEY, RESEND_API_KEY (valeurs dans .env, jamais ici) Interdit : ajouter une dépendance sans me le dire
Le schéma back-end : où vivent les données, qui peut les voir
La liste des tables avec leurs champs, les liens entre elles, et pour chaque table qui a le droit de lire et d'écrire. C'est le document qui évite qu'un client voie les réservations des autres. Et en France, ce n'est pas un détail : c'est la base de ta conformité RGPD.
Ce que tu mets dedans
Les tables, champ par champ. Nom, type, obligatoire ou non, valeur par défaut. Les liens entre tables (une réservation appartient à un client).
Les droits, table par table. Qui lit, qui écrit, qui supprime : visiteur, client, restaurateur, administrateur. C'est ce qui devient les règles de sécurité de la base.
Les données personnelles, marquées comme telles. Nom, e-mail, téléphone, adresse : tout ce qui identifie une personne. Pour chacune : pourquoi tu la collectes, et si tu peux t'en passer.
Où elles sont stockées. Le service et sa région. Les grands hébergeurs te laissent choisir une région européenne à la création du projet : fais-le à ce moment-là, c'est beaucoup plus simple qu'après.
Combien de temps on les garde. Une durée par type de donnée, et ce qui se passe à la fin (suppression, anonymisation). Les sauvegardes et comment on restaure.
Table reservations id, client_id -> clients, date, heure, couverts, statut (confirmée / annulée), créée_le Lecture : le client voit les siennes, le restaurateur voit tout. Écriture : le client crée et annule les siennes. Suppression : restaurateur seulement. Données personnelles : nom, e-mail, téléphone (clients) Pourquoi : confirmer et prévenir en cas de changement Où : Supabase, région Europe Conservation : 12 mois après la dernière réservation, puis suppression
Le plan d'implémentation : quoi construire, dans quel ordre
Le dernier, et celui qui empêche de tout casser. Une suite d'étapes courtes, chacune construite sur la précédente, chacune vérifiable dans le navigateur avant de passer à la suivante. C'est lui que tu donnes à Claude, une étape à la fois.
Ce que tu mets dedans
Des étapes qui tiennent en une session. Si une étape demande une journée, elle est trop grosse : coupe-la. Une session qui s'arrête au milieu d'une étape, c'est du code à moitié posé.
Un ordre qui respecte les dépendances. Squelette et design, puis authentification, puis les données, puis les fonctionnalités dans l'ordre des priorités du PRD, puis le paiement s'il y en a un, puis la mise en ligne.
Pour chaque étape, ce qu'on vérifie. Une phrase que tu peux tester toi-même : « je réserve une table et je reçois l'e-mail ». Tant que ce n'est pas vrai, l'étape n'est pas finie.
Ce qu'on ne touche pas. Les étapes précédentes sont figées. Changer une chose finie passe par une nouvelle étape, pas par une retouche en passant.
1. Squelette : pages vides, navigation, design appliqué Vérif : je navigue entre toutes les pages sur mobile 2. Authentification client (inscription, connexion) Vérif : je crée un compte, je me reconnecte 3. Table reservations + formulaire + règles d'accès Vérif : je réserve ; un autre compte ne voit pas ma réservation 4. E-mails de confirmation et d'annulation 5. Espace restaurateur 6. Tests de bout en bout, mise en ligne
Le prompt qui écrit les six documents avec Claude
Ouvre Claude Code dans le dossier vide de ton projet et colle ce prompt. Il ne rédige rien d'un coup : il t'interroge document par document, propose ce qu'il peut déduire, marque ce dont il doute, et n'écrit chaque fichier que quand tu as répondu. Compte une demi-heure de questions. C'est la demi-heure la plus rentable du projet.
Je vais construire [un site / une appli] : [deux phrases sur ce que c'est et pour qui]. Avant d'écrire une ligne de code, on prépare six documents dans un dossier docs/ : 01-prd.md ce que fait le produit, par fonction 02-app-flow.md les pages et ce qui se passe au clic 03-design.md couleurs, polices, allure de chaque page 04-trd.md la stack et les services utilisés 05-backend.md les données, leur emplacement, les accès 06-plan.md quoi construire, dans quel ordre Méthode : 1. Pose-moi tes questions document par document, cinq maximum à la fois, en commençant par le PRD. Si tu peux déduire une réponse de ce que j'ai déjà dit, propose-la et demande confirmation. 2. N'invente aucune fonctionnalité, aucun chiffre, aucun outil que je n'ai pas validé. Écris [À CONFIRMER] quand tu doutes. 3. Écris chaque document quand ses réponses sont complètes, en français, en listes courtes. 4. Dans 05-backend.md, identifie chaque donnée personnelle, où elle est stockée (région comprise), qui peut la lire et l'écrire, et combien de temps on la garde. 5. Dans 06-plan.md, chaque étape tient en une session et se termine par quelque chose que je peux vérifier dans le navigateur. 6. Termine par un CLAUDE.md qui renvoie aux six documents et interdit de coder une fonctionnalité absente du PRD.
À la fin, tu as un dossier docs/ avec six fichiers et un CLAUDE.md qui pointe dessus. Claude Code lit ce fichier à chaque session : c'est ce qui fait que les documents sont respectés sans que tu les recolles.
Puis, pour construire
Une étape du plan par session, jamais plus :
Lis docs/06-plan.md et construis uniquement l'étape [1]. Avant de commencer, résume-moi en cinq lignes ce que tu vas faire et ce que tu ne toucheras pas. Respecte docs/01-prd.md à la lettre : si une fonctionnalité te semble manquer, note-la dans docs/a-discuter.md au lieu de la coder. Termine par la liste de ce que je dois vérifier dans le navigateur.
Des documents vivants, pas un rituel
Les six documents ne servent que s'ils restent vrais. Tu changes d'avis sur une fonctionnalité, tu ajoutes une table, tu remplaces un service : le document se met à jour d'abord, le code ensuite. Sinon Claude lit un PRD périmé et reconstruit fidèlement ce que tu ne veux plus.
On vient de changer [ce qui a changé]. Mets à jour les documents concernés dans docs/ (dis-moi lesquels et pourquoi), puis vérifie que 06-plan.md reste cohérent avec le reste. Ne touche pas au code dans cette étape.
Lire un guide, c'est bien.
Construire pendant 30 jours, c'est autre chose.
Ce guide t'a donné une méthode. Le problème, c'est qu'on enregistre des astuces IA et qu'on n'en applique aucune. Le Challenge IA, c'est l'inverse : un défi par jour, un système construit par jour, pendant 30 jours. Les inscriptions ouvrent bientôt.
Un challenge par jour
30 jours, 30 systèmes qui tournent pour toi.
Tes propres agents
Prompts et agents à installer pendant que tu construis.
Vidéos et démos réelles
Je construis devant toi, tu refais derrière.
Accès à vie
Ce que tu construis reste à toi, sans limite de temps.
Gratuit et sans engagement. Les inscrits sont prévenus en premier.
Pas le temps d'apprendre ? On le fait pour toi.
Des solutions IA sur mesure, clés en main, pour automatiser tes process, réduire tes coûts et gagner du temps sur ce qui compte. Agents IA, automatisations, outils internes : on construit, tu récoltes.
De 0 à 70 000 abonnés en 3 mois. Ne cherche plus jamais quoi poster.
Je l'ai construite pour moi, parce que je perdais mes journées à chercher quoi poster. Zoe surveille les créateurs de ta niche, repère les Reels qui explosent cette semaine, comprend pourquoi ils marchent, et t'écrit le script du tien avec ta manière de parler. Elle tourne toujours sur mon compte tous les jours. Elle est maintenant ouverte à tout le monde.
Elle repère
Les Reels qui font x5 la moyenne du compte qui les a publiés.
Elle explique
Ce qui a marché dans la vidéo, hook par hook.
Elle écrit
Le script prêt à tourner, avec ta manière de parler.
Sans engagement, résiliable en un clic. Les résultats dépendent de ton travail : Zoe te dit quoi tourner, elle ne tourne pas à ta place.
Lis la suite gratuitement
Entre tes infos pour débloquer le guide complet.