Comment faire du vibe coding ?

Ce que le vibe coding exige vraiment de vous

Le vibe coding ressemble à l'absence de méthode, ce qui explique précisément pourquoi cela tourne mal pour tant de gens. Laisser un modèle écrire le code supprime le problème de syntaxe, mais ne supprime pas les deux tâches qui ont toujours été la partie difficile : dire précisément ce qui doit se passer, et vérifier que c'est bien arrivé. Votre effort se déplace plutôt qu'il ne disparaît — de la frappe du code à sa spécification et sa relecture. Pour l'origine du terme, voir vibe coding.

C'est pourquoi deux fondateurs utilisant le même outil obtiennent des résultats radicalement différents. Celui qui commence par "construis-moi une marketplace" obtient une démo qui s'effondre à la deuxième fonctionnalité. Celui qui commence par un paragraphe nommant l'utilisateur, les données et la seule chose que la version un doit faire obtient quelque chose sur quoi construire. Le choix de l'outil compte moins que ne le suggèrent la plupart des comparatifs — les meilleurs outils de vibe coding détaille en quoi les familles diffèrent — car la boucle ci-dessous reste la même quel que soit celui que vous choisissez.

La boucle, étape par étape

1. Rédigez le cahier des charges avant le prompt — un paragraphe : qui utilise ceci, ce que ça doit faire, quelles données ça stocke, et ce que la version un ne fera explicitement pas. Dix minutes ici évitent la reconstruction qui survient quand le modèle devine tout ce que vous avez laissé non dit.
2. Construisez une tranche à la fois — demandez la plus petite chose qui fonctionne de bout en bout, confirmez qu'elle fonctionne réellement, puis étendez-la. Un seul prompt énorme produit une surface trop large pour être relue de façon réaliste.
3. Validez (commit) chaque fois que quelque chose fonctionne — le contrôle de version est le bouton annuler du travail génératif. Quand le prochain changement casse trois choses à la fois, un commit connu pour fonctionner est le seul chemin de retour fiable, et il ne coûte qu'une commande.
4. Relisez vous-même les lignes à risque — les connexions, les paiements, tout ce qui touche aux données clients, et tout ce qui supprime. Un modèle écrit du code plausible et ne vous dira pas quelle vérification il a sautée, donc ces chemins se relisent ligne par ligne même quand le reste ne l'est pas.
5. Testez-le comme un inconnu — parcourez l'application comme un utilisateur pour la première fois : mauvaises saisies, états vides, bouton retour, un second compte. Les applications générées sont généralement correctes sur le chemin décrit par le prompt et fragiles partout ailleurs.
6. Tenez un journal des changements — demandez au modèle de résumer ce qu'il a changé et pourquoi après chaque tranche, et conservez ce texte avec le projet. C'est la défense la moins coûteuse contre une base de code que vous ne pouvez plus expliquer à personne, vous y compris.

Où ça casse

Les modes de défaillance sont constants d'un outil à l'autre, et aucun n'est vraiment dû à un modèle mauvais en code :

• Suppositions silencieuses — le modèle construit ce que vous avez demandé, pas ce que vous vouliez dire. Tout ce que vous avez laissé non exprimé se remplit avec quelque chose de plausible, et vous découvrez l'écart quand un vrai utilisateur le rencontre.
• Des choses qui fonctionnaient et qui s'arrêtent silencieusement — les modifications générées ont une portée plus large qu'il n'y paraît. Si vous ne pouvez pas faire tourner l'ensemble après chaque changement, vous ne remarquerez ce que le dernier changement a cassé que bien plus tard.
• Une sécurité que vous n'avez jamais choisie — des règles d'accès par défaut, des politiques de base de données trop permissives et des clés commitées là où elles ne devraient pas l'être sont fréquentes dans les applications générées, et rien ne vous prévient. Vérifiez cela avant le lancement, pas après.
• Les vingt derniers pour cent — les quatre-vingt premiers arrivent en un après-midi ; pour le reste, le modèle a besoin que vous compreniez vraiment le système. Soit vous budgétez cette phase, soit vous cadrez la version un pour qu'elle n'en ait pas besoin.

Ce qui se passe une fois que ça marche

Terminer la boucle vous donne un logiciel qui fonctionne et que personne ne sait exister, ce qui est désormais la situation standard du fondateur : construire est devenu radicalement moins cher, la distribution non. Avant de construire davantage, décidez à quoi sert réellement la version un — c'est tout l'intérêt d'un produit minimum viable — et une fois que ça marche, la question suivante est comment promouvoir une application codée au feeling.

Note en interne, tirée de la construction d'AgentCeres — le directeur IA de la croissance sur agentceres.com : la plupart de notre code et de nos pages marketing sont rédigés par l'IA et relus par un humain, et la catégorie d'erreur la plus coûteuse n'a jamais été du mauvais code. C'était du travail qui disparaissait silencieusement. Deux changements générés en parallèle, chacun correct et passant chaque vérification par rapport au point de départ sur lequel il avait été écrit, et cassés au moment où ils ont été combinés — parce que personne n'a refait tourner les vérifications sur le résultat combiné. Si vous ne retenez qu'une habitude de cette page, retenez celle-ci : de petites tranches, et vérifiez ce que vous avez réellement livré plutôt que le morceau que vous venez de générer.