Vibe coding : la méthode en 4 phases pour livrer une app

Le vibe coding consiste à construire une application en décrivant vos besoins à une IA, sans écrire ni relire le code vous-même. Pour un client, l’approche « tout en un prompt » livre une application fonctionnelle à moitié et engendre une longue série de corrections ; la version en 4 phases lui permet de valider ce qu’il paie avant même la première ligne de code. Voici la définition, suivie de la méthode appliquée sur un véritable tableau de bord CRM avec Claude Code.

2 h 06 · extrait d'une vidéo de 4 h 38

Vibe coding : la définition

Le terme vient d’Andrej Karpathy, chercheur en IA, début février 2025 : on décrit son idée à un modèle, on accepte ce qu’il produit, et on finit par « oublier que le code existe ». On juge le résultat à l’écran, pas dans le code.

Refaire une page d’accueil en un prompt, comme je le fais au début de la masterclass, c’est du vibe coding. Et ça marche très bien pour une page. Le problème commence avec une vraie application.

Pourquoi le vibe coding « big bang » casse

Quand on débute, on envoie un prompt qui contient tout, et on attend que le résultat réponde à tout le besoin. J’appelle ça l’approche big bang. Elle pose quatre problèmes :

1. Le débogage explose. Toutes les fonctionnalités arrivent d’un coup et ne marchent pas forcément ensemble : vous passez votre temps à faire corriger ici, revenir là.
2. Vous recevez plus de fonctionnalités que nécessaire. Vous avez décrit le besoin en quelques phrases, alors le modèle brode autour.
3. Le stress monte à 9 sur 10. Rien ne marche du premier coup, et on finit par abandonner en concluant que le vibe coding ne fonctionne pas.
4. Vous ne comprenez pas ce qui a été construit, donc vous ne savez pas guider l’agent quand il se trompe.

La méthode en 4 phases, dont 3 avant le code

Je ne l’ai pas inventée : j’ai assemblé des méthodes de la communauté, et je l’utilise pour mes projets et pour ceux de mes clients.

1. Découvrir les fonctionnalités auxquelles vous n’aviez pas pensé, et retirer celles qui ne servent pas.
2. Planifier, c’est-à-dire écrire la documentation : c’est la clé de tout le système.
3. Préparer l’environnement de travail (le setup), avec les bons outils dès le départ.
4. Bâtir une fonctionnalité à la fois.

Le développement arrive à la toute fin, et ça frustre au début. En échange, chaque fonctionnalité se vérifie seule, les bugs se trouvent vite, le nombre de fonctionnalités est maîtrisé, et le stress descend nettement.

Le cas réel : mon CRM est dans ClickUp, et son tableau de bord ne me convient pas. Je veux une application où je dépose l’export CSV de mon CRM, et qui m’affiche les indicateurs clés de mon activité. Le fichier de démonstration compte 25 lignes, anonymisées.

Phase 1 : découvrir ce que l’outil doit faire

Seul, ou avec le client : trois questions

Pas de LLM pour commencer. Vous réfléchissez seul, ou avec votre client si c’est pour lui :

1. Que voulez-vous construire ? La liste des fonctionnalités.
2. À quoi ça sert ? Un MVP pour valider une idée, un outil pour vous, un test pour un client, une fonctionnalité pour une application en production qui a des utilisateurs. La réponse change tous les choix techniques qui suivent.
3. Dans quel ordre ? Rangez chaque fonctionnalité dans l’une de ces cases : le MVP (le minimum pour montrer quelque chose), la V1 (les ajouts importants), la V2 ou « plus tard » (le bonus), et le hors périmètre (ce que vous ne ferez pas). Le hors périmètre guide autant que le reste.

Avec un LLM : ajouter et retirer des fonctionnalités

Ensuite, une discussion avec le LLM de votre choix. J’ai pris Gemini, avec le CSV joint et cette consigne : quelles questions me poser, quelles fonctionnalités ajouter, en se concentrant sur le quoi et le pourquoi, pas sur le comment.

Il m’a posé ses questions (qui lit le tableau de bord, faut-il maximiser le nombre de deals ou leur valeur) et proposé des indicateurs. J’ai trié :

• J’ai gardé le pipeline total, une probabilité de signature par statut (je lui ai laissé fixer les pourcentages), le pipeline pondéré, un graphique en entonnoir, les alertes de retard, le panier moyen et le top 5 des opportunités.
• J’ai retiré la segmentation par secteur, le suivi d’équipe, la matrice d’urgence et la jauge d’objectif.
• J’ai mis hors périmètre la connexion par mot de passe et le paiement : c’est un outil pour moi seul.
• J’ai repoussé à plus tard l’enregistrement en base de données.

Il m’a ensuite proposé un découpage, que j’ai corrigé. MVP : l’import du CSV, son nettoyage et les indicateurs (pipeline, chiffre d’affaires, panier moyen, répartition par étape). V1 : la probabilité et le tableau complet des deals. V2 : les filtres avancés. Plus tard : la base de données.

Une variante : demander à Claude Code de générer l’application d’un coup, pour naviguer dedans et voir ce qui vous plaît, puis tout jeter. Le code coûte si peu à générer qu’il ne faut pas hésiter à repartir de zéro.

Phase 2 : planifier, du PRD à l’architecture

Dernière demande à Gemini : « Peux-tu mettre notre discussion au format Markdown ? » Le résultat devient PRD.md dans le dossier du projet : le Product Requirements Document, qui dit ce que fait l’application et ce qu’on attend d’elle (performance, sécurité, nombre d’utilisateurs pour un SaaS).

J’en retire deux choses : la phrase de politesse du début, et les contraintes techniques que les LLM adorent ajouter. Le PRD parle de fonctionnel, pas de technique. Il n’a pas besoin d’être parfait : c’est une première version qui vous sort de la page blanche. Un PRD complet, section par section, est détaillé dans notre exemple de product requirements document.

L’architecture, je la confie à Claude Code, en mode plan (Maj+Tab jusqu’à « plan mode on ») :

Quelle stack serait idéale pour mon application décrite dans @PRD.md ?
Crée un rapport qui compare les différentes options, puis recommande un choix.

Le premier Claude a comparé 4 stacks sur 11 critères et recommandé React, TypeScript et Vite. Il parlait aussi d’une migration future pour la base de données, ce que je ne voulais pas : je lui ai dit que la base arriverait plus tard et qu’il fallait une stack qui tienne jusque-là.

Mon meilleur atout face à Claude Code, c’est Claude Code lui-même. J’en ai lancé un second en parallèle, avec le même prompt. Celui-là m’a posé des questions (mon niveau, ma priorité, mes contraintes) et recommandé Next.js 15, React 19 et TypeScript, en expliquant pourquoi : la base de données s’ajoute plus tard sans tout réécrire. Sa réponse était nettement plus complète. Je lui ai demandé de tout consigner :

Je suis OK avec ta recommandation Next.js. Documente l’ensemble des choix
techniques dans un fichier architecture.md qui ne contient que les choix
retenus. S’il reste des points à éclaircir, demande-moi.

Il m’a encore demandé ma stratégie de tests (unitaires, plus des tests de bout en bout avec Playwright) et l’hébergement (Vercel). Pour valider l’architecture à fond, un sous-agent de revue existe dans le plugin comprehensive-review, mais il tourne sur Opus et consomme davantage.

Vous avez travaillé le quoi et le pourquoi, Claude a travaillé le comment.

Phase 3 : le setup d’un professionnel

C’est le setup que j’utilise pour mes projets et celui que j’ai vu dans de grandes entreprises. Il marche seul comme en équipe.

1. Les permissions, dans .claude/settings.json, le fichier partagé avec l’équipe. Les nouvelles règles que vous acceptez arrivent dans settings.local.json : reportez celles qui servent à tous.
2. Le dépôt GitHub, le Google Drive du code : l’historique, le retour en arrière, le partage. Je le demande à Claude Code, en lui disant d’inclure le dossier .claude et d’exclure les fichiers .env. Un « commit » pose un repère en local, un « push » envoie le code sur GitHub. Quand il veut lancer un rm, je valide à la main, sans jamais l’ajouter aux règles.
3. Le fichier .env.example, généré à partir du PRD et de l’architecture : base de données, authentification, suivi des erreurs, stockage, API externes. Les vraies clés iront dans un .env.local, que .gitignore tient hors de GitHub.
4. OpenSpec, la méthode de développement piloté par la spécification. J’en ai testé quatre : Spec Kit (GitHub), que je ne trouve pas géniale ; BMAD, très complète mais lourde, pensée pour de grandes équipes ; feature-dev, le plugin d’Anthropic ; et OpenSpec, la moins intrusive. openspec init crée un dossier specs (la spécification de référence) et un dossier changes (chaque fonctionnalité en cours).
5. Deux serveurs MCP : Context7 pour la documentation à jour, Playwright pour les tests. Je les ai détaillés dans l’article sur Claude Code et le MCP.
6. Deux skills : frontend-design pour le design, et un skill Playwright pour tester l’interface. Comment les choisir : l’article sur les plugins de Claude Code.
7. Le CLAUDE.md complété : l’objectif du projet, l’architecture, une interface claire et minimaliste, jamais de clé d’API exposée côté client, les composants existants plutôt que de nouvelles bibliothèques, un test Playwright à la fin de chaque développement d’interface, les liens vers le PRD et l’architecture, Context7 pour tout code généré, et les spécifications en français.

Si cette méthode vous paraît lourde pour un petit outil, la mienne tient en trois fichiers Markdown : les 6 skills pour cadrer avant de coder.

Phase 4 : bâtir, une fonctionnalité à la fois

La boucle, pour chaque fonctionnalité, toujours après un /clear :

1. OpenSpec propose : il rédige la spécification et la liste des tâches. Votre travail, c’est de lire la spécification et de la corriger.
2. Claude Code applique la proposition.
3. Claude teste avec Playwright, puis vous testez vous-même.
4. Vous archivez : la spécification de référence se met à jour.
5. Vous envoyez sur GitHub, puis vous recommencez.

Avant le premier tour, j’envoie toute la configuration sur GitHub : si le développement ne me plaît pas, je reviens à ce point propre.

Le premier tour : l’import du CSV et les indicateurs

La proposition, pour une petite partie du MVP seulement :

/openspec:proposal Upload CSV et affichage des KPI macro du MVP défini dans le PRD.md

OpenSpec a créé le changement add-mvp-dashboard : une proposition, une liste de tâches et une spécification par scénario. Par exemple : « l’utilisateur sélectionne un fichier CSV valide ; le fichier est lu ; un message de succès s’affiche ; les indicateurs et le graphique sont mis à jour », puis le rejet d’un fichier qui n’est pas un CSV. Votre rôle n’est pas de relire le code ligne par ligne : c’est de valider ces scénarios et de tester l’application.

/clear, puis l’application du changement : une vingtaine de minutes. Claude a écrit le code et les tests unitaires, lancé le serveur, corrigé deux fois.

Le test, sur mon CSV : 22 deals, environ 310 000 € de chiffre d’affaires, un panier moyen d’environ 14 100 €, et la répartition (7 prospects, 6 qualifiés, 5 en négociation, 4 gagnés). Sauf que le fichier compte 25 lignes. J’ai demandé pourquoi : les lignes au statut « à relancer » étaient écartées, parce que ce statut n’existait pas dans la spécification. C’est exactement le genre d’écart que seul votre test trouve. Une erreur Next.js est ensuite apparue : je lui ai demandé de tester lui-même avec Playwright, il a vu l’erreur et s’est corrigé seul.

Puis l’archivage (/openspec:archive add-mvp-dashboard) : le changement part dans archive avec sa date, et la spécification de référence intègre ses 3 composants et une vingtaine d’exigences. Enfin, « commit et push » : Claude décrit lui-même ce qu’il envoie, mieux que je ne le ferais. Il avait créé deux fichiers vides et un README vide : je lui ai fait supprimer les premiers et remplir le second.

Le deuxième tour : le tableau des deals

Même boucle pour la V1 : « la fonctionnalité tableau complet de la V1, et uniquement celle-là, décrite dans le PRD.md ». Proposition, /clear, application. Le tableau trie chaque colonne, filtre par nom (je tape « Antoine », il ne reste que sa ligne) et formate les montants.

Une remarque : Claude ne lance pas toujours ses tests Playwright à la fin. Vérifiez, et demandez-les : à chaque fois qu’il les fait, il trouve quelque chose à corriger. Et si une fonctionnalité part de travers, demandez-lui de restaurer la dernière version envoyée sur GitHub.

La mise en ligne sur Vercel, qui ferme la boucle, est résumée dans le guide complet de Claude Code. Et pour que ce tableau de bord ne trahisse pas l’IA au premier coup d’œil : le dashboard Claude Code qui fait sur-mesure.

Ce qui a changé depuis le tournage

• OpenSpec est passé de la version 0.17.2 à la 1.15.0. Il s’installe en un seul fichier, sans Node.js, et ses commandes ont changé : /opsx:explore pour réfléchir avant de proposer, puis /opsx:propose, /opsx:apply et /opsx:archive.
• Dans la vidéo, j’ajoute « think hard » au prompt d’architecture. Claude Code le lit aujourd’hui comme du texte ordinaire : seul ultrathink pousse la réflexion d’un tour, et /effort règle le niveau de la session.
• Maj+Tab part maintenant du mode auto, puis passe par manual, accept edits et plan.
• frontend-design existe en plugin officiel, et Context7 s’installe par npx ctx7 setup --claude.

Les 4 phases, elles, tiennent telles quelles. Cette partie fait 2 h 06 de la masterclass.