Vibecoder avec Claude Code : le guide complet

Le vibecoding, c'est construire un logiciel en le décrivant en français à une IA, qui écrit et exécute le code à votre place. Vous ne lisez pas le code. Vous ne le comprenez pas. Vous regardez le résultat, vous dites ce qui ne va pas, et vous recommencez jusqu'à ce que ça marche.

Le terme a été popularisé par Andrej Karpathy début 2025, dans un sens assez littéral : on se laisse porter par l'ambiance, on accepte le code sans le relire, on itère au clavier. C'est une méthode de prototypage, pas une méthode de production.

La confusion vient de là. Beaucoup de gens entendent « je peux créer un logiciel » et comprennent « je peux créer une entreprise de logiciel ». Ce sont deux choses très différentes. Écrire le code n'a jamais été la partie difficile : la partie difficile, c'est la sécurité, la fiabilité quand mille personnes s'en servent en même temps, la conformité, la maintenance sur cinq ans, et le service client à 2 h du matin.

Pourquoi Claude Code plutôt qu'un autre outil ? Parce qu'il travaille directement dans un dossier de votre ordinateur, comme le ferait un développeur : il crée les fichiers, les modifie, lance l'application, lit les messages d'erreur et se corrige tout seul. Les générateurs de sites qui produisent un joli écran mais rien derrière plafonnent très vite. Ici, vous avez un vrai projet, que vous pourrez confier à quelqu'un plus tard.

Après une bonne centaine de projets construits de cette façon, j'ai arrêté de chercher : deux cas d'usage donnent des résultats systématiquement bons, et les autres finissent au fond d'un dossier.

À l'inverse, si votre idée est « une application de réservation pour tous les coiffeurs de France », ce n'est pas du vibecoding qu'il vous faut, c'est une équipe et un financement. Le prototype vous servira à convaincre — il ne servira pas de produit.

Réunissez ces quatre éléments avant d'ouvrir quoi que ce soit : la première session se passe beaucoup mieux quand on ne s'interrompt pas au milieu pour installer un outil manquant.

Claude Code existe sous plusieurs formes : en ligne de commande dans un terminal, dans un éditeur de code, sur le web, et dans l'application de bureau Claude. C'est cette dernière que je recommande sans hésiter à quelqu'un qui débute : tout est graphique, il n'y a pas de terminal à apprivoiser, et vous voyez les modifications de fichiers dans une vue comparative avant de les accepter.

Une session de vibecoding réussie se joue dans les trois premières minutes. Si vous démarrez par « fais-moi une application de suivi de production », vous obtiendrez quelque chose de générique que vous passerez deux heures à corriger. Si vous démarrez en fixant le rôle, la méthode et les contraintes, Claude vous interroge d'abord et construit ensuite dans le bon sens.

Voici le prompt que je colle en tout premier message, systématiquement. Remplacez uniquement la dernière ligne.

Tu es mon directeur technique. Je suis le dirigeant : je connais parfaitement mon métier, je ne connais rien au code, et je ne veux pas apprendre.

Règles de travail, à respecter pendant toute la session :
1. Parle-moi uniquement en français courant. Jamais de jargon technique sans une phrase d'explication simple juste après.
2. Ne me demande jamais de choisir entre deux options techniques. Choisis toi-même la plus simple et la plus robuste, dis-moi en une phrase pourquoi, et continue.
3. Ne me montre pas de code. Montre-moi le résultat.
4. Avance par étapes courtes. À la fin de chaque étape, dis-moi précisément quoi regarder pour vérifier que ça marche.
5. Si quelque chose ne marche pas, corrige-le toi-même avant de me le signaler. Ne me renvoie pas un message d'erreur brut.

Déroulé attendu :
- Étape 1 : pose-moi entre 5 et 8 questions, une par une, pour comprendre à quoi doit servir l'outil, qui va s'en servir et dans quelles conditions. Attends ma réponse avant la question suivante.
- Étape 2 : résume-moi en dix lignes maximum ce que tu as compris et ce que tu vas construire en premier. Demande-moi de valider.
- Étape 3 : construis la première version, la plus simple possible, et fais-la tourner sur ma machine pour que je puisse la voir dans mon navigateur.
- Étape 4 : on améliore ensemble, morceau par morceau.

Contraintes techniques imposées :
- Utilise des technologies standards et très répandues, pas de choix exotique.
- Le projet doit pouvoir être repris plus tard par un développeur professionnel.
- Crée dès le départ un fichier CLAUDE.md qui décrit le projet, et tiens-le à jour.
- Aucune donnée réelle d'entreprise ou de personne dans le projet : uniquement des exemples fictifs tant que je ne dis pas le contraire.

Voici ce que je veux construire : [DÉCRIVEZ VOTRE IDÉE EN UNE OU DEUX PHRASES]

Trois choses font le travail dans ce prompt, et elles méritent d'être comprises plutôt que recopiées bêtement.

L'inversion des rôles. En vous posant comme dirigeant et Claude comme directeur technique, vous lui interdisez de vous renvoyer les décisions. Sans cela, il vous demandera « préférez-vous PostgreSQL ou SQLite ? » et vous serez bloqué.

L'interrogatoire préalable. Les cinq à huit questions valent tout le cahier des charges que vous n'écrirez pas. C'est là que sortent les contraintes que vous aviez oubliées : « ça doit marcher sur la tablette de l'atelier, sans réseau ».

La demande de fichier CLAUDE.md. C'est un simple fichier texte à la racine du projet, que Claude relit à chaque nouvelle session. Sans lui, chaque redémarrage repart de zéro et vous réexpliquez tout. Avec lui, vous reprenez où vous en étiez, même trois semaines plus tard.

Le premier écran produit par une IA est presque toujours fade : polices par défaut, couleurs violettes, dégradés partout. Ce n'est pas une fatalité, c'est un manque d'instructions. Voici ce qui fait la différence.

C'est le sujet qui me fait le plus intervenir en entreprise, souvent après coup. Un outil bricolé le week-end se retrouve en production le mois suivant, avec des données clients dedans, sans que personne n'ait posé la question. Quelques règles suffisent à éviter l'essentiel.

Le prix affiché n'est pas le sujet. Le sujet, c'est la vitesse à laquelle vous consommez votre quota — car Claude Code consomme bien plus vite qu'une conversation classique. À chaque échange, il relit des fichiers, exécute des commandes, lit les résultats : le contexte grossit, et il est renvoyé à chaque tour.

Cinq habitudes réduisent nettement la consommation, sans rien changer au résultat :

• Une session par tâche. Une conversation qui dure trois heures traîne tout son historique à chaque message. Ouvrez-en une nouvelle dès que vous changez de sujet.
• Sonnet par défaut. Gardez Opus pour les passages où vous bloquez vraiment. Le gain de qualité ne se voit pas sur les tâches courantes.
• Désignez, ne collez pas. Plutôt que de coller le contenu d'un fichier, écrivez son nom précédé de @. Claude ira le lire lui-même, et seulement s'il en a besoin.
• Un plan avant les grosses étapes. Cinq minutes de plan valident la direction et évitent une heure de travail à jeter.
• Surveillez votre consommation. Tapez /usage dans la conversation, ou ouvrez Réglages → Utilisation. Deux minutes par semaine suffisent à ne jamais avoir de surprise.

La règle d'or tient en une phrase : ne mettez jamais plus de temps à construire l'outil qu'à faire la tâche à la main. Beaucoup de gens passent une journée à automatiser quelque chose qui leur prenait dix minutes par mois. C'est de la productivité de façade : on a l'impression d'avancer, on a surtout perdu une journée.

Le dernier cas mérite qu'on s'y arrête. La tentation de tout reconstruire soi-même parce que c'est devenu possible est réelle. Mais un logiciel du marché apporte aussi les mises à jour, la conformité, le support et la reprise de vos données le jour où vous partez. Reconstruisez uniquement ce qui est spécifique à votre métier — c'est justement là que rien n'existe.

Trois signaux indiquent qu'il est temps : votre outil dépasse la dizaine d'utilisateurs réguliers, il contient des données réelles de clients ou de salariés, ou une interruption vous poserait un vrai problème d'exploitation. À partir de là, le prototype doit devenir un logiciel.

La bonne nouvelle : contrairement à un générateur de sites fermé, vous partez avec un vrai projet, dans un vrai dossier, avec son historique. Un développeur peut le reprendre. Encore faut-il lui donner de quoi comprendre en une heure ce que vous avez fait en trois semaines.

Je vais confier ce projet à un développeur professionnel qui ne le connaît pas du tout.

Crée un fichier HANDOFF.md à la racine, écrit pour lui, qui contient :
1. À quoi sert cet outil, qui l'utilise et dans quel contexte, en langage métier.
2. Les technologies utilisées et pourquoi elles ont été choisies.
3. Comment installer et lancer le projet sur une machine neuve, étape par étape.
4. Où sont stockées les données, sous quelle forme, et comment on les sauvegarde.
5. Comment fonctionne l'authentification, s'il y en a une.
6. La liste honnête de ce qui est fragile, bâclé ou provisoire — sois franc, c'est le point le plus utile du document.
7. Ce qu'il faudrait reprendre en priorité avant une mise en production réelle, classé par ordre d'importance.
8. Ce qui a été volontairement laissé de côté, et pourquoi.

Précise clairement en introduction que ce projet est un prototype construit sans expertise technique, et qu'il doit être audité avant tout usage en production.

Transmettez ensuite le dossier complet, le fichier HANDOFF.md, le CLAUDE.md, et surtout : dites la vérité sur la façon dont il a été construit. Un développeur qui sait qu'il reprend un prototype de vibecoding sait exactement quoi regarder. Un développeur à qui on présente ça comme un logiciel professionnel perdra trois jours à comprendre pourquoi rien ne ressemble à ce qu'il attend.

Ces formulations donnent de bons résultats parce qu'elles précisent toutes la même chose : qui s'en sert, dans quelles conditions, et ce qu'on doit voir à l'écran. Adaptez les mots entre crochets.

Construis un formulaire de saisie utilisable sur tablette, en atelier, par des opérateurs qui portent des gants. Champs : [LISTE]. Gros boutons, peu de champs par écran, validation impossible tant qu'un champ obligatoire est vide. Chaque saisie s'enregistre avec la date, l'heure et le nom de l'opérateur choisi dans une liste.

Je vais déposer un export [Excel / CSV] de [DÉCRIRE]. Construis un tableau de bord qui le lit et affiche : les trois indicateurs les plus parlants en haut, une évolution dans le temps, et un tableau filtrable en dessous. Si je dépose un nouvel export, tout doit se mettre à jour sans que j'aie à toucher au reste.

Fais une maquette cliquable, sans base de données, avec des données fictives crédibles. Elle sert à présenter [IDÉE] à [PUBLIC] lors d'une réunion. Trois écrans maximum, on doit pouvoir naviguer entre eux. Priorité absolue à la clarté visuelle : c'est projeté sur un écran, à cinq mètres.

Aujourd'hui, [NOMBRE] personnes remplissent le même fichier Excel et s'écrasent mutuellement. Construis l'équivalent en application, où chacun saisit de son côté sans conflit, avec l'historique de qui a modifié quoi. Garde exactement les mêmes colonnes qu'aujourd'hui pour ne pas perturber les habitudes.

Construis un calculateur de [PRIX DE REVIENT / DEVIS / DIMENSIONNEMENT]. Les règles de calcul sont : [DÉCRIRE EN FRANÇAIS]. Je dois pouvoir modifier les paramètres depuis un écran de réglages, sans toucher au code. Le résultat s'affiche en direct et peut être exporté en PDF.

Ajoute une page de connexion. Seules les personnes dont j'aurai autorisé l'adresse email peuvent entrer, et chacune ne voit que ses propres données. Explique-moi en français où sont stockés les comptes et comment j'ajoute ou retire quelqu'un.

Je veux mettre cet outil en ligne pour que mon équipe y accède depuis n'importe où. Choisis toi-même l'hébergement le plus simple et le moins cher, mets-le en place, et donne-moi ensuite la marche à suivre en français pour publier une nouvelle version quand j'aurai fait des modifications.

Relis le CLAUDE.md et fais le point : où en est ce projet, qu'est-ce qui fonctionne, qu'est-ce qui est en cours, et qu'est-ce qui reste à faire ? Réponds en français, en dix lignes maximum, sans me montrer de code.

Ne cherchez pas l'idée parfaite. Cherchez l'agacement le plus proche. La question qui marche le mieux, je la pose à tous mes clients : « Quelle est la tâche que vous faites toutes les semaines, qui vous prend entre vingt minutes et deux heures, et que vous détestez ? » La réponse arrive en général en moins de dix secondes. C'est votre premier projet.

Une dernière chose. Le vibecoding a une valeur qu'on sous-estime largement : il vous apprend à formuler un besoin. Après trois projets, vous saurez décrire ce que vous voulez avec une précision qui changera aussi vos échanges avec vos prestataires, vos éditeurs et vos équipes. Ce bénéfice-là dure bien plus longtemps que l'outil que vous aurez construit.