Pour faire du vibe coding, vous décrivez ce que vous voulez à un agent de code en langage courant, le laissez écrire et exécuter le code, vérifiez vous-même le résultat et continuez à le guider avec de courts messages. Le faire sans risque revient à ajouter un peu de structure autour de cette boucle : une courte spec, de petites étapes, des tests, un commit git après chaque étape qui marche, une revue avant toute mise en ligne.
Le terme vient du message d’Andrej Karpathy de février 2025, qui parlait de laisser l’IA écrire le code en « oubliant que le code existe » ; le dictionnaire Collins en a ensuite fait son mot de l’année 2025. Pour la définition, l’histoire et les risques, voir qu’est-ce que le vibe coding. Cet article parle du comment.
La méthode en un coup d’œil
| Étape | Ce que vous faites | Ce que vous obtenez |
|---|---|---|
| 1. Idée | Écrivez un paragraphe : pour qui, ce que ça fait | Un périmètre auquel vous pouvez dire non |
| 2. Spec | Demandez à l’agent d’en tirer un court plan | Une liste de petites tâches ordonnées |
| 3. Petites étapes | Une tâche par prompt | Des changements assez petits pour être vérifiés |
| 4. Tests | Demandez des tests sur ce qui compte | Un moyen de savoir que ça marche encore |
| 5. Commit | git commit après chaque étape qui marche | Un point sûr où revenir |
| 6. Revue | Lisez le diff, ou faites-le lire par un autre modèle | Moins de surprises plus tard |
| 7. Déploiement | Publiez sur un hébergeur avec builds de prévisualisation | Un lien en ligne à partager |
Écrites noir sur blanc, ces étapes paraissent évidentes. Les sauter transforme un après-midi sympa en week-end de « ça marchait il y a une heure ».
Étape 1 : partir d’une petite idée
Écrivez l’idée en quelques phrases avant d’ouvrir le moindre outil. Nommez l’utilisateur, la seule chose que l’app doit faire et ce qui est hors périmètre pour la première version.
Une page où mon club de course enregistre ses distances hebdomadaires. Les membres se connectent par lien magique, ajoutent une course et voient un classement du mois. Pas de paiement, pas d’app mobile, pas de panneau d’administration dans la v1.
Cette dernière phrase compte le plus. Les agents construisent volontiers des fonctions que vous n’avez pas demandées ; une liste claire « pas dans la v1 » garde le projet assez petit pour être terminé.
Étape 2 : en faire une courte spec
Ne demandez pas encore l’app. Demandez un plan :
Lis cette idée. Propose une stack, une arborescence de dossiers et une liste numérotée de 6 à 10 petites tâches pour construire la v1. Chaque tâche doit tenir en une session et se tester seule. N’écris pas encore de code.
Lisez le plan et contestez. La stack est-elle hébergeable gratuitement ? Une tâche en cache-t-elle en réalité trois ? Enregistrez la version finale sous SPEC.md (ou PLAN.md) dans le dépôt pour que chaque session suivante puisse la lire. Si vous utilisez plusieurs agents, un court CLAUDE.md ou AGENTS.md avec les commandes et les règles aide aussi ; le codage agentique marche le mieux quand l’agent a chaque fois le même contexte.
Étape 3 : construire par petites étapes
Prenez maintenant la tâche 1, et seulement la tâche 1 :
Fais la tâche 1 de SPEC.md : mets en place le projet et une page d’accueil qui dit « Hello ». Lance-le et donne-moi l’URL.
Ouvrez-la, vérifiez, puis passez à la tâche 2. Un bon rythme : une tâche, une vérification, un commit. Si une étape produit plus de quelques centaines de lignes de changements, elle était sans doute trop grosse ; demandez à l’agent de la découper la prochaine fois.
Quand quelque chose casse, collez l’erreur exacte plutôt qu’une description. « Ça ne marche pas » pousse l’agent à deviner ; la trace d’appels complète, en général non.
Étape 4 : demander des tests sur ce qui compte
Vous n’avez pas besoin de 100 % de couverture sur un projet perso. Vous avez en revanche besoin de tests sur les parties qui feraient mal en cassant silencieusement : le calcul du classement, le flux de connexion, tout ce qui touche à l’argent ou aux données.
Ajoute des tests pour le classement mensuel : égalités, un membre sans course, des courses le dernier jour du mois. Lance-les et montre-moi la sortie.
Demandez à l’agent de lancer les tests et d’afficher la sortie, pas seulement de les écrire. Plus tard, quand vous changerez quelque chose, « lance les tests » devient votre contrôle de sécurité en une ligne.
Étape 5 : committer après chaque étape qui marche
Git est le bouton d’annulation du vibe coding. Après chaque étape qui fonctionne :
git add -A
git commit -m "Add monthly leaderboard with tests"Ou dites simplement à l’agent : « Commite ça avec un message court. » Quand un changement ultérieur dérape, git diff montre ce qui a changé et git restore . (ou un reset au dernier commit) vous ramène en arrière. C’est mieux que de demander à l’agent de corriger sa propre correction pour la quatrième fois, ce qui empile un patch sur l’autre.
Étape 6 : relire avant la mise en ligne
Le vibe coding marche parce que vous ne lisez pas chaque ligne pendant la construction. Avant de déployer, quelqu’un doit le faire. Au minimum :
- Parcourez le diff de tout ce qui a changé depuis le dernier déploiement.
- Demandez à un second agent ou modèle de le relire à la recherche de bugs et de problèmes de sécurité, sans l’historique de chat du premier agent. Un lecteur neuf voit ce que l’auteur ne voit pas.
- Parcourez l’app vous-même sur un téléphone et sur un portable.
Le guide de la revue de code par IA détaille ce qu’il faut chercher et comment la mettre en place.
Étape 7 : déployer
Pour la plupart des projets web vibe-codés, un hébergeur qui compile depuis un dépôt GitHub est la voie facile : Vercel, Netlify ou Cloudflare Pages pour les sites statiques et les frameworks comme Next.js ou Astro. Poussez sur une branche, obtenez un lien de prévisualisation, vérifiez, puis fusionnez pour déployer. Gardez les secrets dans les réglages d’environnement de l’hébergeur, jamais dans le dépôt.
Choisir un outil
| Type | Exemples | Idéal pour |
|---|---|---|
| Agents de terminal | Claude Code, Codex, Gemini CLI | Projets complets sur votre machine, exécution de commandes, vrais dépôts |
| Agents d’éditeur | Cursor | Rester près du code pendant que l’IA édite |
| Générateurs d’apps dans le navigateur | Divers générateurs hébergés | Une démo rapide avec hébergement inclus |
Les agents de terminal et d’éditeur vous laissent un dépôt de code normal qui vous appartient ; les générateurs hébergés démarrent plus vite mais gardent le code sur leur plateforme. Si vous hésitez, commencez avec un agent de terminal, comme Claude Code, et utilisez-le pour tout un petit projet avant d’en essayer d’autres.
Des prompts qui marchent
Les bons prompts de vibe coding ont la même forme : un objectif, les contraintes et la façon de vérifier.
| Au lieu de | Essayez |
|---|---|
| « Construis-moi un suivi d’habitudes » | « Fais la tâche 3 de SPEC.md : le formulaire d’ajout d’habitude. Vérifie que le nom n’est pas vide. Lance les tests à la fin. » |
| « C’est cassé, répare » | « Cliquer sur Save affiche cette erreur : (collez-la). Trouve la cause avant de modifier le code, puis explique la correction en deux phrases. » |
| « Fais que ce soit plus joli » | « Reprends les espacements et les tailles de police de cette capture. Ne change pas la mise en page sur mobile. » |
| « Ajoute une connexion » | « Ajoute une connexion par lien magique avec la bibliothèque d’authentification de SPEC.md. Ne stocke pas de mots de passe. Liste tous les fichiers modifiés. » |
Trois formules méritent d’être réutilisées :
- « N’écris pas encore de code. » Pour les plans et les investigations.
- « Lance-le et montre-moi la sortie. » Pour voir des preuves, pas des affirmations.
- « Liste les fichiers que tu as modifiés. » Pour que le diff ne réserve aucune surprise.
Quand arrêter de vibrer
Le vibe coding est excellent pour les prototypes, les outils internes et les projets personnels. Ralentissez et lisez le code vous-même, ou faites-le lire par quelqu’un qui sait, quand le travail touche à :
- Connexions et permissions. Une vérification oubliée expose les données de tout le monde.
- Paiements. Webhooks, remboursements et cas limites demandent de vrais tests.
- Données personnelles. Le droit de la vie privée se moque de qui a écrit le code.
- Migrations de base de données. Un
DROPou unUPDATEsansWHEREest difficile à annuler en production. - Tout ce qui est public avec de vrais utilisateurs. Limites de débit, validation des entrées, gestion des secrets.
Autre signal : si vous avez demandé trois fois à l’agent de corriger le même bug et qu’il revient, arrêtez. Revenez au dernier bon commit, décrivez le problème depuis zéro ou lisez vous-même cette partie du code.
Construisez quelque chose
Chacun de ces guides suit la même méthode sur un projet concret :
- Créer un site web avec l’IA
- Créer un MVP SaaS avec l’IA
- Créer une app mobile avec l’IA
- Créer une extension Chrome avec l’IA
- Créer un bot Telegram avec l’IA
- Créer une automatisation ou un scraper avec l’IA
- Créer un tableau de bord de données avec l’IA
- Créer une boutique en ligne avec l’IA
- Créer un jeu avec l’IA
Le faire avec AgentVera
Tout ce qui précède marche avec un terminal et git. AgentVera exécute vos agents de code (Claude Code, Codex, Gemini CLI et d’autres, avec vos propres connexions) côte à côte dans de vrais terminaux, et ajoute quelques filets de sécurité autour de la même boucle :
- Annulation par tour. Les checkpoints enregistrent le dossier de travail au début de chaque tour : vous pouvez annuler un tour depuis le menu du volet, et annuler l’annulation. C’est un retour plus rapide qu’un git reset, pas un remplacement des commits.
- Revue automatique. Avec la revue de code activée dans les réglages du projet, un modèle Claude de votre choix lit les changements à la fin d’un tour et signale ses constats avec gravité et liens fichier:ligne ; vous pouvez les renvoyer à l’agent.
- Vérification par rapport à votre demande. AgentVera Verify (Pro et Team) extrait les critères d’acceptation de votre message et, à la fin du tour, un vérificateur distinct lance les tests et marque chaque critère réussi ou échoué, preuve à l’appui.
- Contrôle des migrations. DB Guard analyse les nouvelles migrations en fin de tour à la recherche d’instructions risquées comme
DROPouUPDATEsansWHERE. - Prévisualisations. Les environnements de prévisualisation donnent à chaque branche sa propre adresse locale et peuvent capturer des écrans mobile, tablette et bureau.
- Un seul endroit pour approuver. La review inbox rassemble le travail terminé de chaque agent pour que vous l’approuviez ou le renvoyiez avec une note.
Liste de contrôle
- L’idée tient en un paragraphe, avec une liste « pas dans la v1 ».
- Un court SPEC.md de tâches numérotées se trouve dans le dépôt.
- Une tâche par prompt ; chacune vérifiée avant la suivante.
- Des tests existent pour ce qui ferait mal en cassant.
- Un commit après chaque étape qui marche.
- Le diff a été relu avant le déploiement, idéalement par un modèle neuf et par un humain.
- Les secrets sont dans des variables d’environnement, pas dans le dépôt.
- Connexions, paiements, données personnelles et migrations ont reçu une lecture humaine attentive.
En résumé
Le vibe coding est désormais une vraie façon de construire des logiciels, pas seulement une blague. La différence entre un prototype qu’on garde et un qu’on jette est rarement le modèle ; c’est d’avoir travaillé par petites étapes, committé souvent, testé ce qui comptait et relu avant de livrer. Gardez l’ambiance pour la construction et la discipline pour les bords.