Vibe coding : qu'est-ce que c'est et comment commencer

Le vibe coding est une façon de créer des logiciels où tu décris avec des mots simples ce que tu veux obtenir, et un modèle d'IA écrit le code à ta place. Andrej Karpathy a inventé le terme en février 2025. Pour commencer, choisis un petit projet qui ne contient les données de personne d'autre et un seul outil, par exemple Lovable ou Cursor, puis avance par petites étapes en vérifiant chaque résultat.

Une application simple peut naître en une soirée, mais une soirée suffit tout autant à produire du code que personne ne comprend, qui expose les données des utilisateurs ou qui engloutit un budget de crédits. Ce guide montre comment utiliser cette méthode sans payer ce prix.

D'où vient le terme vibe coding

Le 2 février 2025, Andrej Karpathy, cofondateur d'OpenAI et ancien directeur de l'IA chez Tesla, publie un court message sur X à propos d'un nouveau genre de programmation où tu « oublies même que le code existe ». Il parle à voix haute à Composer, la fonction de Cursor, accepte chaque changement sans lire les différences de code, et recolle les messages d'erreur sans le moindre commentaire. Quand le code dépasse ce qu'il arrive à suivre et que le modèle ne sait pas corriger un bug, il demande des changements au hasard jusqu'à ce que le bug disparaisse. Il prévient lui-même que la méthode convient à des projets de week-end, bons à jeter.

Le nom s'est répandu plus vite que cette réserve. En novembre 2025, le dictionnaire Collins a élu vibe coding mot de l'année 2025, et beaucoup de gens l'emploient aujourd'hui pour désigner toute programmation assistée par IA.

En mars 2025, le développeur Simon Willison a tracé une distinction utile dans son article Not all AI-assisted programming is vibe coding. Si un modèle a écrit le code et que tu l'as relu, testé, et que tu sais expliquer comment il fonctionne, c'est du développement logiciel ordinaire, pas du vibe coding. Le vibe coding commence là où tu renonces volontairement à comprendre le code et où tu juges uniquement le résultat.

En 2026, Karpathy a popularisé un second terme. Dans ses notes d'une conversation à Sequoia Ascent 2026, il écrit que le vibe coding relève le niveau de départ en permettant à presque tout le monde de construire un logiciel qui fonctionne, tandis que l'agentic engineering est une discipline professionnelle : les agents IA écrivent le code, et les humains conçoivent les spécifications, relisent les changements, écrivent les tests et gèrent les permissions. Ensemble, ces deux termes dessinent un parcours d'apprentissage, du jeu jusqu'au travail réfléchi.

Comment fonctionne la création d'applications à partir d'une description

Quel que soit l'outil, la boucle se ressemble : tu décris ce que tu veux, le modèle écrit ou modifie le code, l'outil l'exécute, et tu vérifies le résultat en disant ce qu'il faut corriger. Le modèle ne voit pas ton écran ; il ne sait que ce qui est arrivé jusqu'à lui dans la conversation : ta description, les fichiers du projet, les messages d'erreur et, pour certains outils, des captures d'écran et des résultats de tests. La qualité de ta description compte donc énormément.

Les outils de vibe coding se répartissent en trois familles :

1. Les générateurs d'applications dans le navigateur. Lovable, Bolt, v0 et Replit font tout le travail dans une fenêtre de chat avec un aperçu en direct. Tu n'installes rien et la publication est incluse. C'est le départ le plus simple, avec le moins de contrôle sur le code.
2. Les éditeurs avec un agent. Cursor, Windsurf, aujourd'hui développé par Cognition sous le nom Devin Desktop, et GitHub Copilot dans VS Code et d'autres éditeurs. L'agent modifie les fichiers sur ton ordinateur, exécute des commandes et montre les changements à approuver. Cursor crée des points de contrôle avant les changements importants, donc annuler une tentative ratée ne prend qu'un clic.
3. Les agents en ligne de commande. Claude Code, présenté dans l'article sur les modèles Claude, travaille sur ton dépôt depuis la ligne de commande. Il lit les instructions du fichier CLAUDE.md et dispose d'un mode plan qui ne modifie les fichiers qu'après que tu as validé le plan.

Les montants changent souvent, donc on les indique à part, d'après les sites des éditeurs en septembre 2026. Cursor démarre à 20 USD par mois, tout comme Claude Pro (17 USD par mois en facturation annuelle), qui inclut Claude Code, indisponible sur le plan gratuit. Devin Desktop Pro coûte 20 USD, Bolt Pro 25 USD, v0 Plus 30 USD par utilisateur et GitHub Copilot Pro 10 USD. La grille tarifaire de Lovable affichée en Pologne place le plan Pro à 25 EUR TTC. Vérifie la grille tarifaire actuelle sur le site de l'éditeur avant d'acheter.

Ton premier projet étape par étape

Pour un premier projet, choisis quelque chose de petit, utile pour toi et qui ne traite les données de personne d'autre, par exemple un suivi d'habitudes avec un compteur de jours d'affilée. Il n'a besoin ni de connexion, ni de serveur, ni de paiement, et pourtant il contient une vraie logique que tu peux comprendre et vérifier.

1. Décris le projet avant d'ouvrir un outil

Une courte spécification t'épargne une dizaine de corrections. Note ce que l'application doit faire et ce que la première version laisse volontairement de côté :

# Suivi d'habitudes

Objectif : une page simple où je liste quelques habitudes et je les coche chaque jour.

Doit avoir :
- ajouter et supprimer une habitude
- cocher une habitude pour aujourd'hui
- un compteur de jours d'affilée pour chaque habitude
- des données enregistrées dans le navigateur (localStorage), sans connexion ni serveur

Pas maintenant :
- comptes utilisateurs, paiements ou notifications

2. Choisis un outil et demande un plan

Un générateur dans le navigateur ne demande aucune installation. Un éditeur avec un agent en demande une, mais t'apprend davantage, car tu vois chaque fichier et chaque changement. Dans les deux cas, demande d'abord un plan, pour que les malentendus apparaissent avant de devenir dix fichiers à corriger :

Construis une application web d'après la spécification ci-dessous.
Utilise du HTML, du CSS et du JavaScript natifs, sans framework ni bibliothèque supplémentaire.
Interface en français, confortable à utiliser sur téléphone.
Commence par lister un plan : quels fichiers tu vas créer et quelles fonctions chacun contiendra.
Écris le code seulement après que j'ai validé le plan.

[colle la spécification ici]

3. Vérifie avant d'aller plus loin

Ajoute une habitude avec un nom vide, une avec un nom très long et deux avec le même nom. Rafraîchis la page et vérifie que les données sont restées. Demande aussi ce que fait le compteur quand tu coches une habitude à 23h59 puis à 0h01 : les dates et les fuseaux horaires sont une source classique de bugs, même dans du code écrit par des humains. Signale chaque problème séparément.

4. Enregistre les versions qui fonctionnent

Les générateurs gardent leur propre historique de versions ; dans un éditeur, utilise Git. Chaque commit est un point où revenir quand la prochaine demande casse quelque chose :

git init
git add -A
git commit -m "Tracker : l'ajout et le suivi des habitudes fonctionnent"

5. Demande une explication et lis la partie clé

Demande au modèle comment l'application enregistre les données, puis retrouve cette partie dans le code. Elle ressemble en général à ça :

const STORAGE_KEY = 'habits'

function loadHabits() {
  const saved = localStorage.getItem(STORAGE_KEY)
  return saved ? JSON.parse(saved) : []
}

function saveHabits(habits) {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(habits))
}

localStorage ne stocke que du texte, donc la liste d'habitudes devient du JSON à l'enregistrement, puis redevient une liste à la lecture. Si rien n'a encore été enregistré, getItem renvoie null, donc la fonction renvoie une liste vide. Les données ne vivent que dans ce navigateur : tu ne les verras pas sur ton téléphone, et effacer les données du site les supprime. Connais ce genre de limites avant de promettre à quelqu'un que l'application se souviendra de sa progression.

6. Publie

Les générateurs publient en un clic ; un projet venant d'un éditeur part vers GitHub puis vers Vercel ou Netlify. Une adresse qui fonctionne est un bon moment pour prendre du recul sur ce que tu as vraiment construit.

Les formules de prompts qui marchent

La plupart des déceptions viennent de demandes évidentes pour une personne, mais ambiguës pour un modèle. Des habitudes simples aident :

• Le contexte avant la tâche. Dis à qui s'adresse l'application et ce qu'elle doit accomplir, avant de dire ce qu'il faut changer.
• Un seul changement par message. Demander cinq choses à la fois finit souvent par en annuler deux.
• Fais référence à ce qui existe déjà. « Fais un écran de statistiques dans le style de la liste d'habitudes » donne un résultat cohérent ; « ajoute des statistiques » donne quelque chose d'entièrement nouveau.
• Les limites du changement. Dis quels fichiers, quel visuel et quelles dépendances ne pas toucher.
• Les cas limites, dits clairement. Le modèle construit le chemin nominal, donc une liste vide, un échec d'enregistrement ou un changement de date à minuit demandent une mention à part.
• Le message d'erreur complet. Colle-le en entier et dis ce que tu as fait juste avant, plutôt que d'écrire « ça ne marche pas ».

La différence se voit dans un signalement de bug :

Faible : corrige le compteur, ça ne marche pas

Mieux : le compteur de jours d'affilée affiche 0 après un rafraîchissement
de la page, alors que l'habitude "Lecture" est cochée hier et aujourd'hui.
Je m'attends à 2. Trouve la cause, décris-la en deux phrases et corrige
seulement la fonction qui compte la série. Ne change ni le visuel ni les
autres fichiers.

Mets les règles que tu répètes dans chaque conversation dans un fichier de projet. Cursor lit les règles de projet depuis le dossier .cursor/rules ou un fichier AGENTS.md, tandis que Claude Code lit CLAUDE.md et peut aussi utiliser AGENTS.md. Un court fichier suffit :

# Règles du projet

- HTML, CSS et JavaScript natifs, sans framework ni nouvelle dépendance
- Données uniquement dans localStorage sous la clé "habits"
- Avant un changement important, présente un plan et attends la validation
- Après chaque changement, liste les fichiers modifiés et la raison
- Ne supprime pas de fonctions existantes sans demander

Limites et risques

Le vibe coding fonctionne très bien pour les prototypes et les outils à usage personnel. Les ennuis commencent quand une application touche d'autres personnes, stocke leurs données ou doit tourner pendant des années.

Sécurité

Un code qui fonctionne n'est pas forcément sécurisé. Veracode teste régulièrement le code généré par les modèles, et sa mise à jour de mars 2026 rapporte que seulement 55 % des tâches de génération de code ont produit du code sécurisé, un chiffre qui a à peine bougé en deux ans de sorties de modèles.

Trois erreurs reviennent sans cesse dans les applications construites par description. Les clés des services externes finissent dans le code qui tourne dans le navigateur, où n'importe qui peut les lire. Les règles d'accès à la base de données restent ouvertes, donc un utilisateur peut voir les données des autres, ce qui, avec un backend Supabase, signifie en général une absence de sécurité au niveau des lignes (row level security). Les permissions ne sont vérifiées que dans l'interface, pas sur le serveur. L'article sur Lovable montre comment vérifier ça rapidement.

Les agents aux permissions larges forment un risque à part. En juillet 2025, un agent de Replit a supprimé une base de données de production dans un projet mené par Jason Lemkin, fondateur de la communauté SaaStr, malgré une consigne de ne rien changer sans autorisation. Les données ont été récupérées, bien que l'outil ait prétendu qu'un retour en arrière était impossible. Tiens donc les agents à l'écart des données de production, et fais en sorte que toute commande qui supprime quelque chose demande ta confirmation.

Du code que tu ne comprends pas

Tant que tout fonctionne, ne pas comprendre le code ne pose pas de problème. Les ennuis commencent avec le premier bug que le modèle n'arrive pas à corriger, et grandissent à chaque fonctionnalité ajoutée sans avoir compris les précédentes. Dans l'enquête Stack Overflow 2025, la plus grande frustration avec les outils d'IA, citée par 66 % des répondants, concernait des solutions presque bonnes, mais pas tout à fait, et 45,2 % ont estimé que déboguer du code généré par IA prend plus de temps. Dans la même enquête, 72 % ont répondu que le vibe coding ne fait pas partie de leur travail professionnel.

Coûts

Les générateurs facturent en crédits ou en tokens, les éditeurs par abonnement avec des limites, et les modèles utilisés via une API facturent chaque token traité. Ce sont les boucles de correction qui coûtent le plus : quand le modèle ne comprend pas le problème, le même changement revient cinq fois, et chaque tentative coûte. S'ajoutent l'hébergement, une base de données, un nom de domaine et les services payants que ton application utilise. Avant de passer à un plan supérieur, vérifie dans le tableau de bord où est parti l'usage, et fixe des limites de dépenses partout où c'est possible.

Pourquoi les bases de la programmation comptent encore

Le vibe coding déplace le travail de l'écriture du code vers la description, la vérification et la décision, et chacune de ces tâches demande des connaissances. Pour décrire une tâche, il faut connaître le nom des éléments d'une application. Pour juger un résultat, il faut distinguer une solution correcte d'une solution qui en a seulement l'air. Pour corriger un bug que le modèle n'arrive pas à gérer, il faut savoir lire les erreurs et le code.

À Sequoia Ascent, Karpathy l'a résumé ainsi : tu peux confier ta réflexion à un modèle, mais pas ta compréhension. Si tu ne sais pas expliquer ce que fait un morceau de code, ne le laisse pas entrer dans des applications utilisées par d'autres.

Un minimum qui facilite énormément le travail avec l'IA :

• les bases de HTML, CSS et JavaScript, pour lire le code de l'interface,
• comment le navigateur communique avec un serveur et où peuvent se cacher des secrets,
• Git, pour enregistrer des versions et annuler des changements ratés,
• lire les messages d'erreur et utiliser les outils de développement du navigateur,
• les bases des bases de données et de la connexion, avant de construire quoi que ce soit avec des comptes utilisateurs.

Un plan étape par étape pour apprendre tout ça se trouve dans comment apprendre à coder, et si tu envisages de travailler dans le secteur, dans comment devenir développeur. De bons premiers pas sont les bases de HTML et CSS et JavaScript pour débutants.

Comment apprendre le vibe coding de façon responsable

Il ne s'agit pas d'éviter l'IA, mais de savoir plus après chaque projet qu'avant. Des règles simples fonctionnent :

1. Du vibe coding pur seulement quand rien n'est en jeu, comme pour des prototypes et des outils à usage personnel. Une application qui contient les données d'autres personnes a besoin d'une revue de code.
2. Ne publie pas de code que tu ne sais pas expliquer. C'est la règle de Willison en pratique : relire, tester, expliquer.
3. Git dès le premier jour. De petits commits sont l'assurance la moins chère contre une demande ratée.
4. L'IA comme tuteur. Demande-lui d'expliquer les erreurs, de donner des indices plutôt que des réponses toutes faites, et de t'interroger sur le nouveau code.
5. Un morceau en solo. Après chaque projet, réécris une fonction sans aide, par exemple le compteur de jours d'affilée, pour voir ce que tu comprends vraiment.
6. Une revue de sécurité et un budget. Avant tes premiers utilisateurs, vérifie les clés, les règles d'accès aux données et les permissions côté serveur, et fixe à l'avance tes dépenses d'outils.

Sur CodeWorlds, le monde pirate Vibecoding couvre ce sujet en 14 modules et plus de 300 exercices, et sa page de cours estime la durée d'apprentissage entre 100 et 150 heures. Tu y construis des applications avec Cursor et Claude Code, depuis la configuration de l'éditeur jusqu'aux tests et au déploiement, en passant par des clones de services connus. C'est un monde pour niveau avancé qui suppose React et Next.js, enseignés dans les mondes JavaScript et React et Next.js, ainsi que les bases de TypeScript du Parc Jurassique. Tu démarres de zéro ? Commence par le cours HTML et CSS.

Pour bien démarrer, ouvre Introduction à Cursor, Créer un projet Next.js avec Cursor et Git et GitHub, puis passe à Découvrir Claude Code, les tests avec Jest et React Testing Library et le déploiement sur Vercel ou Netlify. Tu peux lire gratuitement les leçons de ce monde sur le site, tandis que ses exercices dans l'application demandent le plan premium. Le plan gratuit couvre le cours HTML et CSS dans l'application et te donne 10 unités de carburant par jour, ce qui convient bien à de courtes sessions quotidiennes.

FAQ

Qui a inventé le terme vibe coding ?

Andrej Karpathy, cofondateur d'OpenAI et ancien directeur de l'IA chez Tesla, dans un message sur X du 2 février 2025. En novembre 2025, Collins a choisi vibe coding comme mot de l'année.

Faut-il savoir coder pour faire du vibe coding ?

Pas pour un simple prototype, et c'est le plus grand avantage de la méthode. Pour une application utilisée par d'autres, les bases sont nécessaires : sans elles, tu ne peux ni évaluer la sécurité, ni corriger un bug que le modèle ne sait pas gérer, ni maintenir le projet au-delà de quelques semaines.

Par quel outil commencer ?

Sans installation, commence par Lovable ou Bolt. Pour apprendre à programmer en chemin, choisis un éditeur avec un agent, comme Cursor, où tu vois chaque fichier et chaque changement. Passe à Claude Code une fois à l'aise avec le terminal et Git.

Une application construite en vibe coding est-elle sécurisée ?

Il n'y a aucune garantie de ce genre. Les tests de Veracode montrent qu'une grande part du code généré contient des vulnérabilités connues, et les modèles négligent souvent les règles d'accès aux données et la protection des clés. Avant de partager l'application, vérifie ces points ou demande à quelqu'un qui code de la relire.

Combien coûte le vibe coding ?

Tu peux commencer gratuitement, car la plupart des outils ont des plans gratuits avec une limite. Les plans payants vont de 10 USD par mois pour GitHub Copilot à 20-30 USD ou EUR pour les autres outils présentés ici, plus l'hébergement et les services qu'utilise ton application. Les prix changent souvent, donc vérifie-les chez les éditeurs.

En quoi le vibe coding diffère-t-il de l'agentic engineering ?

Le vibe coding consiste à construire par description sans regarder le code, ce qui convient aux prototypes et à l'apprentissage. L'agentic engineering est le terme de Karpathy pour le travail professionnel avec des agents IA : les agents écrivent le code, tandis qu'une personne conçoit la spécification, relit les changements, écrit les tests et répond de la qualité.