TL;DR — Si tu n’as que 2 minutes

Tu démarres un projet tech cette année ? Avant de toucher à quoi que ce soit, assure-toi d’avoir fait ça :

• ☐ J’ai répondu aux 10 questions du brief par écrit, pas dans ma tête, par écrit
• ☐ J’ai une phrase claire qui résume le problème que le projet résout et pour qui
• ☐ Mon cahier des charges existe, il a été relu et validé par tous les décideurs avant le début du développement
• ☐ Mon fichier CLAUDE.md existe et pointe vers les bons documents du projet
• ☐ Mon architecture technique a été validée par un tech lead
• ☐ Je n’envoie jamais une demande sans avoir défini le comportement attendu et le critère de “c’est bon”
• ☐ J’avance une fonctionnalité à la fois, je valide avant d’étendre
• ☐ Mon équipe nettoie le contexte (/clear) à chaque nouvelle tâche dans Claude Code
• ☐ Mon équipe utilise le bon modèle pour le bon travail, pas Sonnet pour changer une couleur
• ☐ Mes réunions sont enregistrées et les transcripts sont dans le projet
• ☐ Quand quelque chose change, les fichiers sont mis à jour avant de continuer

Intro

Si tu ouvres n’importe quel outil de vibe coding et que tu demandes : “fais-moi mon app”, tu obtiendras un résultat rapide, certes, mais moyen. Les tokens aujourd’hui ça coûte pas grand-chose, mais à chaque correction, tu repaies en tokens, en temps, et en frustration.

Pour faire du code de qualité avec Claude Code, il faut plus de contexte (mais pas trop), plus de structure (mais pas trop non plus). Bref, je vais t’expliquer.

Pour moi, travailler avec l’IA demande encore plus de rigueur qu’avant. Pas moins. Le robot va vite, très vite, mais dans la direction que tu lui donnes. Si ta direction est floue, il va vite dans le mauvais sens.

J’ai appris ça de la façon la plus directe qui soit : je me suis inscrit à un hackathon de 90 minutes sans savoir coder, avec Claude Code comme seul outil. Une semaine de préparation, 90 minutes d’exécution. J’ai fini 5e sur 14. Ce qui m’a permis de tenir, c’est pas le talent technique, c’est la structure.

Voilà ce que j’ai transmis à mes équipes ensuite. 5 conseils, dans l’ordre où il faut les appliquer.

1. Brief d’abord — réponds aux 10 questions avant d’écrire un seul prompt
2. Structure le projet — PRD, architecture, et un CLAUDE.md qui sert de boussole
3. Itère petit — propose, teste, valide, implémente. Jamais tout d’un coup
4. Gère le contexte — nettoie entre chaque tâche, utilise le bon modèle pour le bon travail
5. Documente en temps réel — ce qui n’est pas écrit n’existe pas pour le robot

Cet article est écrit pour toi, entrepreneur ou chef de projet non-tech, qui s’apprête à lancer un projet avec un dev (augmenté à l’IA) ou directement avec Claude Code. Tu peux copier-coller les prompts tels quels à ton équipe ou à ton agent IA.

---

Conseil 1 — Brief d’abord

Pour toi, entrepreneur :

Le robot ne devine pas. Il exécute. Et s’il n’a pas les bonnes infos, il invente, et tu paies pour de la fiction.

Avant d’ouvrir Claude Code ou d’envoyer ton brief à ton dev, prends 30 minutes pour répondre par écrit à ces 10 questions. Tu peux demander à l’IA de t’aider à les remplir, mais ne lui délègue pas cette réflexion aveuglément. C’est toi qui connais ton projet.

1. C’est quoi le projet ? En une phrase : quel problème ça résout, pour qui.
2. Qui le crée ? Background, niveau technique, préférences de design.
3. Qui sont les utilisateurs finaux ? À l’aise avec le digital ou pas du tout ?
4. D’où vient la donnée ? CSV, base existante, saisie manuelle ?
5. Quelles fonctionnalités sont essentielles ? Et lesquelles sont hors scope pour l’instant, mais pourraient être demandées plus tard.
6. Y a-t-il une charte graphique ? Couleurs, polices, logo. Si oui, fournis-les.
7. Quelles sont les contraintes de temps ? Deadlines, jalons de paiement, périodes creuses.
8. Qui sont les acteurs ? Client, chef de projet, tech, testeurs. Leurs langues, leurs rôles, leur dispo.
9. Quels outils utilise-t-on ? GitHub, Notion, outil de tickets, intégrations MCP.
10. Où en est l’équipe avec l’IA ? Qui a déjà livré avec, qui débute.

Ce document, c’est ton brief. Sans lui, tout ce qui vient après est fragile.

Le prompt à donner à Claude Code (ou à ton dev) pour t’aider à remplir le brief

Copie-colle ça dans une nouvelle session Claude Code, avec tes notes brutes attachées :

Tu es mon assistant pour cadrer un projet tech. Je vais te donner mes notes brutes sur un projet que je veux lancer. Ta mission : m'aider à remplir un brief complet en répondant aux 10 questions ci-dessous.

Règles :
- Ne rédige PAS les réponses à ma place si tu n'as pas l'info. Pose-moi la question directement.
- Pour chaque question, si mes notes contiennent une réponse partielle, propose une formulation claire et demande-moi de valider.
- À la fin, produis un fichier `BRIEF.md` propre, structuré avec les 10 sections.

Les 10 questions :
1. Le projet en une phrase : problème résolu + cible
2. Le créateur : background, niveau technique, préférences design
3. Les utilisateurs finaux : profil, aisance digitale
4. Source de la donnée : CSV, base existante, saisie manuelle
5. Fonctionnalités essentielles vs. hors scope
6. Charte graphique : couleurs, polices, logo
7. Contraintes de temps : deadlines, jalons
8. Les acteurs : rôles, langues, dispo
9. Les outils : GitHub, Notion, MCP, tickets
10. Maturité IA de l'équipe

Mes notes brutes :
[COLLE ICI TES NOTES]

Commence par me poser les questions sur les infos manquantes, une par une. Attends mes réponses avant de continuer.

Et pour ajouter une fonctionnalité en cours de route

Même logique, version courte. Réponds à ces questions avant d’envoyer quoi que ce soit à ton équipe ou à l’IA :

1. C’est quoi la fonctionnalité ? Ce qu’elle fait, pour qui, dans quelle situation elle se déclenche.
2. Quel est le comportement attendu, pas à pas ? L’utilisateur fait X, il voit Y, il peut faire Z. Sans ça, le robot devine, et il devine mal.
3. Est-ce qu’elle modifie quelque chose qui existe déjà ? Si oui, quoi exactement, et est-ce que les personnes concernées sont au courant.
4. Est-ce qu’elle est dans le plan initial ? Si non, est-ce une évolution validée par les décideurs, ou juste une bonne idée qui n’a pas encore été discutée.
5. Quel est le critère de “c’est bon” ? Comment tu sauras que c’est terminé et correct. Sans critère de validation, tout reste subjectif.

Une demande sans ces réponses n’est pas une demande. C’est une intention. Et une intention, ça ne se code pas.

---

Conseil 2 — Structure le projet en trois documents

Pour toi, entrepreneur :

Avant d’écrire une ligne de code, trois documents doivent exister. Dans cet ordre.

Document 1 : le PRD (Product Requirements Document)

C’est le QUOI et le POURQUOI. Il décrit ce qu’on va construire, pour qui, dans quel ordre, et pourquoi dans cet ordre. Il liste les fonctionnalités à développer par priorité, ce qui est hors scope pour l’instant, et les critères qui permettent de dire qu’une fonctionnalité est terminée.

Claude peut rédiger une première version à partir de ton brief. Mais ce document doit être relu et validé par tous les leads, client inclus, avant que quoi que ce soit démarre. Il est hors de question de lancer le développement sans un PRD compris et accepté par tout le monde. C’est ce document qui évite les “ah mais moi je pensais que…” trois semaines plus tard.

Le prompt pour générer ton PRD :

Tu es un product manager senior. À partir du brief joint, rédige un PRD (Product Requirements Document) structuré comme suit :

1. **Vision & problème résolu** — 3 phrases max
2. **Personas** — qui sont les utilisateurs, leurs frictions actuelles
3. **Périmètre V1** — liste des fonctionnalités essentielles, par ordre de priorité
4. **Hors scope V1** — ce qu'on ne fait PAS maintenant, avec justification
5. **User stories** — au format "En tant que [persona], je veux [action] pour [bénéfice]"
6. **Critères d'acceptation** — pour chaque fonctionnalité, comment on sait que c'est terminé
7. **Risques & hypothèses** — ce qui pourrait mal tourner
8. **Jalons** — étapes de validation avec le client

Contraintes :
- Utilise le mode `think hard` pour structurer tes idées avant d'écrire
- Ne propose RIEN qui ne soit pas dans le brief. Si une info manque, liste-la à la fin dans une section "Questions ouvertes"
- Livre le résultat en Markdown propre, prêt à être partagé

Brief source :
[COLLE ICI LE CONTENU DE BRIEF.md]

Document 2 : l’Architecture

C’est le COMMENT. Une fois le PRD validé, un tech lead (humain ou IA en mode think hard) définit comment le projet va être structuré techniquement pour répondre aux exigences du PRD : choix des technos, organisation des fichiers, structure de la base de données, endpoints.

Ce document est validé par un tech. Toi en tant que client ou chef de projet, tu dois pouvoir l’ouvrir et te dire “ok, ce fichier existe, le sujet est couvert.”

Le prompt pour générer l’architecture :

Tu es un tech lead senior. Passe en mode `think hard`.

À partir du PRD joint, propose une architecture technique complète pour ce projet.

Ton livrable doit contenir :

1. **Stack technique recommandé** — frontend, backend, base de données, hosting. Avec justification courte de chaque choix.
2. **Structure des dossiers** — arborescence claire du projet
3. **Modèle de données** — entités principales, relations, champs clés
4. **Endpoints API** (si applicable) — liste des routes avec méthode HTTP et payload
5. **Dépendances externes** — services tiers, APIs, MCP servers
6. **Plan de déploiement** — environnements (dev/staging/prod), CI/CD minimal
7. **Points d'attention** — risques techniques, dettes potentielles

Contraintes :
- Privilégie la SIMPLICITÉ. Pas de techno exotique sans raison forte.
- Pour chaque choix, donne une alternative plus simple qu'on pourrait prendre si le scope se réduit.
- Livre le résultat dans un fichier `ARCHITECTURE.md`

PRD source :
[COLLE ICI LE CONTENU DE PRD.md]

Document 3 : CLAUDE.md

C’est la boussole de Claude à chaque session. Contrairement à ce qu’on lit souvent (“c’est comme le brief d’une nouvelle recrue”), je le vois plutôt comme le trousseau de clés du projet : il explique quelle clé ouvre quelle porte, et ce qu’il y a derrière.

Il doit contenir :

• En une phrase : pourquoi le projet existe et quel problème il résout
• Les acteurs et leurs rôles (une ligne par personne)
• Où trouver et mettre à jour la documentation
• Quels documents lire pour quel type de tâche
• Le workflow de validation : spécification → développement → test → validation → déploiement

Ce dernier point est crucial. Claude doit savoir qu’il ne code pas une fonctionnalité sans qu’elle soit spécifiée, et qu’il ne déploie pas sans qu’elle soit testée. Si tu ne lui dis pas, il improvise, et l’improvisation consomme des tokens et produit du code dont tu n’as pas besoin.

Le prompt pour générer ton CLAUDE.md :

Tu vas créer un fichier `CLAUDE.md` qui servira de boussole à Claude Code à chaque session de ce projet.

Ce fichier n'est PAS une documentation complète. C'est un index qui pointe vers les bons documents et qui fixe les règles du jeu.

Structure attendue :

## Le projet en une phrase
[Problème résolu + cible, en 1 ligne]

## Les acteurs
- [Nom] — [Rôle] — [Langue principale]
- ...

## Où trouver quoi
- Brief initial : `BRIEF.md`
- Besoins fonctionnels : `PRD.md`
- Décisions techniques : `ARCHITECTURE.md`
- Historique des réunions : `/transcripts/`
- Apprentissages & corrections : `MEMORY.md`

## Quel document lire selon la tâche
- Tu dois coder une feature → lis `PRD.md` + `ARCHITECTURE.md`
- Tu dois débugger → lis `MEMORY.md` + le code concerné
- Tu dois prendre une décision produit → demande à [Nom], ne décide jamais seul
- Tu dois prendre une décision technique → demande à [Nom], ne décide jamais seul

## Workflow de validation obligatoire
1. Spécification écrite (dans PRD.md ou ticket) avant tout code
2. Plan proposé avant implémentation
3. Validation humaine du plan avant d'écrire le code
4. Test après implémentation
5. Validation humaine avant déploiement

## Règles non-négociables
- Ne JAMAIS coder une fonctionnalité qui n'est pas spécifiée
- Ne JAMAIS déployer sans test
- Ne JAMAIS modifier `ARCHITECTURE.md` ou `PRD.md` sans validation écrite
- À chaque nouvelle tâche : `/clear` pour repartir propre
- Pour une édition simple : utiliser Haiku. Pour une tâche de conception : Sonnet + `think hard`

Génère le fichier à partir des infos du brief joint.

Brief :
[COLLE ICI LE CONTENU DE BRIEF.md]

---

Conseil 3 — Itère petit, toujours

Pour toi, entrepreneur :

C’est l’erreur la plus répandue. Tu arrives avec une idée complète, tu dis “fais-moi l’app”, et il fait. Sauf que le design est raté, la structure ne correspond pas à ce que tu imaginais, et tu dois tout reprendre. Tu viens de dépenser des tokens pour rien.

La règle est simple :

Propose → Teste → Valide → Implémente.

Jamais tout d’un coup. Toujours sur une unité réduite.

Exemple : plutôt que “fais-moi la page d’accueil”, tu dis “fais-moi la première section, juste celle-là, en t’inspirant du design de ce site [URL]. On regarde, on ajuste, et ensuite on continue.” Tu valides une section avant de passer à la suivante. Une fonctionnalité avant la suivante. Une décision à la fois.

💡 PRO TIP : Pour aller à l’essentiel, demande à Claude Code de se concentrer sur le cas d’usage principal en premier. Les edge cases (cas à la marge) viennent après.

Le prompt à utiliser pour CHAQUE nouvelle fonctionnalité

Je veux ajouter une fonctionnalité au projet. Avant d'écrire du code, suis ce protocole strict :

ÉTAPE 1 — Compréhension
Reformule dans tes mots ce que tu as compris de ma demande. Inclus :
- Le comportement utilisateur attendu, pas à pas
- Les fichiers existants qui seront modifiés
- Les fichiers nouveaux qui seront créés
- Les dépendances ou APIs externes concernées

ÉTAPE 2 — Questions ouvertes
Liste les ambiguïtés ou décisions que tu ne peux pas prendre seul. Pose-moi des questions précises. N'invente rien.

ÉTAPE 3 — Plan d'implémentation
Propose un plan en étapes numérotées. Pour chaque étape : le fichier touché + l'action. Concentre-toi sur le cas d'usage principal, laisse les edge cases pour plus tard.

ÉTAPE 4 — Critère de validation
Propose un critère de test clair : "la fonctionnalité est terminée quand [X est vrai]".

STOP. Attends ma validation écrite avant de coder.

Ma demande :
[DÉCRIS ICI TA FONCTIONNALITÉ]

Des outils comme OpenSpec permettent de formaliser ce processus : proposer, archiver ce qui est validé, déployer ce qui est prêt. Mais même sans outil dédié, une simple checklist.md avec le statut de chaque livrable suffit à garder le contrôle.

L’idée centrale : l’IA propose, tu testes, tu valides, elle implémente. Dans cet ordre. Toujours.

---

Conseil 4 — Gère le contexte proprement

Pour toi, entrepreneur :

Claude Code relit l’état du projet à chaque nouvelle session. Si ton équipe accumule du contexte sans nettoyer, chaque nouvelle demande coûte plus cher et devient moins précise.

Trois règles simples à imposer à ton équipe ou à toi-même :

1. À chaque nouvelle tâche : /clear. C’est le seul réflexe à avoir.
2. Le bon modèle pour le bon travail :

– Tâches de conception (PRD, sprint, architecture) : mode think hard + plan. C’est là que tu as besoin de la puissance.

– Tâches d’édition simple (corriger un fichier, ajuster un style, renommer une variable) : un modèle léger comme Haiku suffit. Inutile de solliciter Sonnet pour changer une couleur.

1. Quand Claude se trompe : interroge-le avant de recommencer.

Le prompt à utiliser quand Claude livre un mauvais travail

Plutôt que de corriger et repartir, arrête-toi et envoie ça :

Ce que tu viens de livrer ne correspond pas à ce que j'attendais.

Avant que je te demande de recommencer, je veux comprendre ce qui a mal tourné. Réponds aux 4 questions suivantes :

1. Quelle information t'a manqué pour faire ça correctement du premier coup ?
2. Où aurait-elle dû être documentée pour que tu y aies accès ?
3. Quelle instruction ambiguë dans mon prompt t'a induit en erreur ?
4. Qu'est-ce que je devrais ajouter à `CLAUDE.md` ou à `MEMORY.md` pour que ce problème ne se reproduise plus ?

Après tes réponses, propose une version à ajouter à `MEMORY.md`. Je validerai avant qu'on reprenne la tâche.

Ce retour-là vaut souvent plus que la correction elle-même, et il améliore tous les prochains cycles. En équipe, centralise ces apprentissages dans un fichier MEMORY.md que Claude relit au démarrage.

---

Conseil 5 — Documente en temps réel

Pour toi, entrepreneur :

Chaque décision prise en réunion qui n’est pas écrite n’existe pas pour le robot. Et souvent, elle finit par ne plus exister pour l’équipe non plus.

Trois réflexes à installer :

1. Enregistre tes réunions. Récupère le transcript. Mets-le dans un répertoire /transcripts du projet. Claude peut s’y référer pour comprendre pourquoi une décision a été prise.
2. Quand une fonctionnalité change, un milestone bouge, un retour client arrive : mets à jour les fichiers. Le PRD.md et le CLAUDE.md sont des documents vivants, pas des archives.
3. Nouvelle décision = mise à jour avant de continuer. Pas de “je le fais plus tard”.

Le prompt à utiliser après chaque réunion importante

Voici le transcript d'une réunion projet. Ta mission :

1. Résume les DÉCISIONS prises (pas les discussions, les décisions).
2. Pour chaque décision, indique :
   - Qui l'a prise
   - Ce qui change concrètement
   - Quel(s) fichier(s) du projet doivent être mis à jour (`PRD.md`, `ARCHITECTURE.md`, `CLAUDE.md`, autre)
3. Liste les action items avec responsable et deadline si mentionnée.
4. Propose les modifications exactes à apporter aux fichiers concernés. Pour chaque fichier : indique la section à modifier + le nouveau contenu proposé.

STOP après cette analyse. Je validerai les modifications avant que tu les appliques.

Sauvegarde aussi le transcript original dans `/transcripts/[DATE]-[SUJET].md`.

Transcript :
[COLLE ICI LE TRANSCRIPT]

Le robot est aussi bon que les informations qu’on lui donne. Fichiers à jour : il travaille vite et juste. Fichiers obsolètes : il part dans la mauvaise direction, et tu passes ton temps à corriger des choses qui n’auraient pas dû être faites.

---

Bonus — Consultation gratuite

Tu veux démarrer un projet tech cette année et ne pas partir dans le mauvais sens ?

Je propose une session de consultation gratuite où je fais une revue complète des instructions et du setup de ton projet avec l’IA.

Voilà comment ça se passe :

1. Tu m’envoies ce que tu as : brief, PRD si tu en as un, CLAUDE.md, architecture, tickets, prompts récurrents.
2. Je les analyse avant qu’on se parle. Pas de “on verra pendant l’appel”.
3. On se voit 45 minutes. On regarde ensemble ce qui manque, ce qui est flou, et comment structurer ça correctement avant de lancer quoi que ce soit.
4. Tu repars avec une roadmap claire, même si on ne travaille pas ensemble derrière.

L’idée est simple : que tu saches exactement quoi préparer, quoi faire valider, et quoi demander à ton équipe (ou à ton IA) pour que ton projet avance sans te coûter ni temps ni argent.

👉 Réserver une session gratuite →