Tu n'as jamais touché à un éditeur de code et tu veux essayer le vibe coding ? Tutoriel pas-à-pas : outil, prompt, premier projet en 1 après-midi.
Bannière swanbase Apprendre le vibe coding : tutoriel founder non-tech (2026)

Apprendre le vibe coding, c'est apprendre à faire écrire du code à une IA, à le tester, à itérer. Pas à devenir développeur. En 2026, un founder non-tech peut mettre en ligne un mini-projet utile en un après-midi à condition de comprendre trois choses : quel outil prendre selon ton projet (Lovable et Bolt pour du web visible, Cursor et Claude Code pour du code modifiable), comment écrire un prompt qui marche (Goal + Stack + Style + Contraintes + Edge cases), et comment réagir quand l'IA bloque ou hallucine. Tu vas de zéro à ton premier projet en 5 étapes, avec un template de prompt à copier et 3 exemples annotés. Au bout, tu sauras aussi reconnaître quand le vibe coding ne suffit plus et que tu dois passer au vrai code, ou recruter un dev.

C'est quoi le vibe coding, en 3 phrases

Définition opérationnelle

Le vibe coding consiste à décrire en français (ou en anglais) ce que tu veux qu'un logiciel fasse, et à laisser une IA écrire le code à ta place. Tu ne tapes pas de syntaxe, tu décris une intention. Tu testes le résultat dans ton navigateur, tu corriges au prompt suivant, tu avances.

C'est différent du no-code (Bubble, Webflow) sur un point qui compte : le vibe coding produit du vrai code source. Déployable, modifiable, exportable. Si tu changes d'avis dans six mois, tu peux récupérer ton code et le donner à un dev humain. Aucun lock-in propriétaire.

Pour la généalogie du terme, l'inventeur, et le contexte 2025-2026 du marché, va voir l'article de fond vibe coding : définition, outils et guide complet. Ce guide-ci part du principe que tu as compris ce que c'est, et que tu veux maintenant t'y mettre.

Différence avec la programmation classique

Vibe coding et programmation classique, face a face

Programmation classique Vibe coding
Qui écrit le code Toi L'IA
Apprentissage Plusieurs mois pour être autonome 1 après-midi pour mettre en ligne un mini-projet
Temps premier projet utile Plusieurs semaines Quelques heures
Contrôle ligne par ligne Total Tu valides au comportement
Débogage Tu lis la stack trace Tu redonnes l'erreur à l'IA
Coût mensuel typique 0 € (gratuit) 20-30 € d'abonnement outil

La différence essentielle : en code classique, tu apprends une langue. En vibe coding, tu apprends à diriger une équipe (de un agent IA) qui parle déjà cette langue. Ton métier devient celui de brief writer + product manager + testeur. La difficulté change de nature.

Avant de commencer : le matériel et le temps

Outils gratuits ou payants

Tu peux apprendre le vibe coding en restant en plan gratuit sur trois outils majeurs : Lovable, Bolt.new, Cursor (free tier limité). Pour un premier après-midi de découverte, le gratuit suffit largement. Tu vas atteindre la limite de prompts quotidiens, mais à ce moment-là tu sauras si l'outil te convient.

Pour mettre en ligne un projet utilisable au quotidien, compte un abonnement à 20-30 € par mois sur l'outil que tu finis par choisir. C'est dérisoire comparé à n'importe quelle autre méthode de mise en ligne d'un produit web.

Combien de temps prévoir pour ton premier projet

Pour un founder non-tech qui n'a jamais touché à Lovable, Bolt, Cursor ou Claude Code, compte le déroulé suivant :

  • 2 heures de découverte : tester deux outils différents avec le même prompt simple, comparer les résultats, choisir ton préféré.
  • 5 heures de premier projet : choisir un mini-projet précis (landing, todo list, calculateur), le scoper, le prompter, l'itérer jusqu'à ce qu'il marche.
  • 1 heure de finitions : un titre clair, un favicon, déployer en ligne, partager le lien.

Total : 1 après-midi (8 heures), le temps qu'il faut pour passer de « j'en ai entendu parler » à « j'ai un truc en ligne ».

Étape 1. Choisir ton premier outil

Le marché 2026 du vibe coding a quatre outils dominants pour débuter. Les quatre marchent. Le bon choix dépend de ce que tu veux faire en premier.

Quatre outils dominants pour debuter en 2026

Lovable, Cursor, Bolt, Claude Code : lequel pour un débutant total ?

Lovable

Lovable est un outil web dans ton navigateur. Tu écris ce que tu veux dans un champ texte, l'IA construit une app web, tu vois le résultat en live à droite de ton écran. Visuel, rassurant, idéal pour ta toute première session. Le tier débutant est gratuit avec une limite de prompts par jour, le passage payant est autour de 20-30 € par mois.

Lovable, le navigateur comme atelier

Bolt.new

Bolt.new ressemble à Lovable côté philosophie (prompt → app web visible immédiatement), avec une exécution plus orientée techniciens (terminal visible, tu peux télécharger ton projet et le finir ailleurs). C'est l'outil à prendre si tu veux dès le premier jour pouvoir récupérer ton code sans dépendre de la plateforme. Plan gratuit limité, plan payant autour de 20 $ par mois.

Bolt.new, le code a portee de download

Cursor

Cursor n'est pas un outil dans le navigateur. C'est un éditeur de code à télécharger (basé sur VS Code) qui intègre des modèles IA. Tu vois les fichiers de ton projet, l'IA les modifie sous tes yeux. Plus puissant que Lovable et Bolt pour des projets qui dépassent la simple page web, mais l'interface fait peur au démarrage. À garder pour ta deuxième semaine, pas pour ton premier après-midi.

Cursor, l'IDE qui dialogue

Claude Code

Claude Code est l'outil le plus minimaliste du lot : un terminal. Tu lances une commande, tu décris ce que tu veux à Claude, il modifie tes fichiers. Zéro interface graphique. C'est l'outil le plus précis et le plus rapide une fois que tu sais ce que tu fais, mais ce n'est pas le bon choix pour débuter.

Claude Code, l'agent en ligne de commande

Pour ton premier après-midi : commence par Lovable ou Bolt. Tu vois ton app se construire, tu ne rates rien. Tu passeras à Cursor ou Claude Code une fois que la magie initiale a fait son effet.

Pour un comparatif détaillé fonctionnalité par fonctionnalité, le guide comparatif outils vibe coding : Cursor, Lovable, Bolt entre dans les détails.

Étape 2. Le prompt, anatomie d'un bon brief

C'est la compétence centrale du vibe coding. Bien plus importante que le choix de l'outil. Avec un mauvais prompt, tu tournes deux heures dans un outil parfait. Avec un bon, tu obtiens un prototype utilisable en quinze minutes dans un outil moyen.

Template "Goal / Stack / Style / Contraintes / Edge cases"

Le template à copier dans un fichier texte et à réutiliser à chaque nouveau projet :

GOAL : [Une phrase qui décrit ce que ton app doit faire, du point de vue de l'utilisateur final.]

STACK : [Le type de produit : web, mobile, API. Les services à brancher : auth, base de données, paiement.]

STYLE : [3 mots pour le design + 1 référence visuelle existante.]

CONTRAINTES : [Ce qui n'est pas négociable : taille de l'écran, navigateur, langue, performance.]

EDGE CASES : [3-5 situations où ton app doit bien se comporter : utilisateur qui tape n'importe quoi, perte de réseau, double clic, etc.]

5 blocs. Pas un de plus. Tu peux le coller dans n'importe quel outil de vibe coding et l'IA aura tout ce qu'il lui faut pour démarrer.

3 exemples annotés (du mauvais au bon prompt)

Du prompt vague au brief structure

Niveau 1, le prompt vague (ne fais pas ça) :

"Fais-moi une todo list."

Ce que l'IA va te livrer : une todo list générique, design moche, sans persistance des données, sans rien de ce que TU avais en tête. Tu vas perdre 30 minutes à corriger ce qui aurait pu être bien briefé d'entrée.

Niveau 2, le prompt correct (la moyenne des gens) :

"Crée une todo list en React avec ajout et suppression de tâches. Design moderne et sombre."

Mieux. L'IA sait quelle stack utiliser et quelle direction prendre côté design. Mais il manque la persistance, les contraintes, les edge cases. Résultat : ton app se vide à chaque refresh, et tu vas le découvrir à la mauvaise étape.

Niveau 3, le prompt complet (utilise ça) :

GOAL : Une todo list personnelle pour un founder : je note des tâches, je les coche, je les supprime. Tout reste là quand je refresh la page.

STACK : App web (React + localStorage, pas de backend). Pas d'auth.

STYLE : Minimaliste, sombre, dense (3 colonnes : à faire / en cours / fait). Inspiration : Linear.

CONTRAINTES : Mobile-first. Lisible en plein soleil. Une seule page.

EDGE CASES : Tâche vide (interdire le submit). Caractères spéciaux dans le titre. Plus de 200 tâches sans ralentir. Cocher / décocher une tâche met à jour le compteur en haut.

Résultat : l'IA livre un truc proche de ce que tu avais en tête dès le premier prompt. Tu passes le reste de ton temps sur les finitions plutôt que sur les trous du brief.

Règle d'or : un bon prompt vibe coding contient cinq choses : un objectif, une stack, un style, des contraintes, et des cas limites. Si une seule manque, l'IA improvisera, souvent mal.

Étape 3. Ton premier mini-projet (walkthrough)

Choisir un projet petit mais utile

Pour ton premier projet, vise un truc que tu utiliserais toi-même la semaine suivante. C'est la seule façon d'avoir la motivation de finir et de vraiment tester.

Trois projets faisables en un après-midi :

  1. Une landing page de pré-lancement pour une idée que tu as en tête (titre, description, champ email, compteur d'inscriptions). Utile, montrable, vendable.
  2. Une todo list personnelle avec ton workflow (3 colonnes, tags, raccourcis clavier). Si tu en utilises 5 différentes par mois, celle-ci aura tes règles.
  3. Un calculateur métier pour ton cas (calcul de CAC, de runway, de marge selon ton secteur). Plus utile que la 47e version sur le web.

Ce que tu évites pour ce premier projet : une app multi-utilisateurs avec auth, paiement et notifications. Tu y arriveras, mais pas le premier jour. L'objectif d'aujourd'hui : mettre quelque chose en ligne.

Publier, tester, corriger, republier

Cinq etapes pour mettre en ligne ton premier projet vibe-code

Une fois ton prompt initial envoyé, tu rentres dans une boucle :

  1. Génère : l'IA construit la première version.
  2. Teste : utilise l'app comme un utilisateur lambda, clique partout, tape n'importe quoi, ouvre-la sur mobile.
  3. Corrige : chaque bug devient un prompt. "Le bouton de submit ne marche pas si le champ est vide, ajoute un message d'erreur." "La couleur du texte n'est pas lisible sur mobile, force le contraste."
  4. Publie : tu déploies (Lovable et Bolt font ça en un clic), tu mets le lien quelque part (Twitter, Discord, un ami), tu regardes la réaction.

Chaque itération doit prendre moins de 5 minutes. Si tu sens que tu tournes en rond sur un même bug, change d'angle. Reformule le problème. Donne plus de contexte. Ou repars de zéro sur ce module avec un prompt plus précis.

Étape 4. Lire son code généré sans paniquer

Tu n'es pas obligé de tout comprendre. Mais tu dois être capable de reconnaître ce que tu vois.

4 patterns visuels à reconnaître

Ouvre ton fichier de code dans l'outil. Tu vas voir 4 grandes familles de blocs :

  1. Les imports en haut (lignes qui commencent par import ou from) : ce sont les briques externes que ton projet utilise. Si tu vois import React, ton app est en React. Si tu vois from supabase, elle parle à une base Supabase. Tu peux ignorer le détail, juste savoir reconnaître les noms.
  2. Les fonctions (function ... ou const ... = () =>) : ce sont les actions de ton app. "Ajouter une tâche", "supprimer une tâche", "sauvegarder en local". Un nom de fonction clair veut dire que l'IA a bien structuré.
  3. Le JSX / HTML (les balises <div>, <button>, etc.) : c'est ton interface. Modifier un texte affiché à l'utilisateur se fait souvent là.
  4. Les styles (classes Tailwind type className="bg-black text-white p-4" ou bloc CSS) : c'est l'apparence. Changer une couleur ou un espacement se règle là.

Tu n'as pas besoin d'écrire ces blocs. Juste de savoir qu'ils existent et de reconnaître dans quelle famille tu te trouves quand tu lis un fichier.

Quand demander à l'IA de t'expliquer

À tout moment, tu peux poser à ton outil la question : "Explique-moi ce que fait ce fichier en français, comme si je n'avais jamais codé". Tu vas recevoir une réponse en 4-5 lignes claires. Fais-le pour chaque fichier important de ton premier projet. Trois sessions de ce genre et tu auras une carte mentale propre de ce qu'est un projet web.

C'est la meilleure école de code accélérée qui existe en 2026. Répète « explique-moi » fichier par fichier.

Étape 5. Quand passer au code écrit à la main (ou à un dev)

Le plafond du vibe coding

Tu vas rencontrer des limites, et les rencontrer prouve que tu progresses. Quatre signaux :

  1. L'IA tourne en rond. Tu lui demandes le même fix trois fois, à chaque fois elle casse autre chose. Le projet est devenu trop gros pour son contexte.
  2. Tu as besoin de garanties. Données sensibles, paiements, conformité RGPD, infos santé : il te faut un humain qui signe sur la sécurité.
  3. Tu vises plus de quelques milliers d'utilisateurs actifs. Tu vas avoir besoin d'optimisations que le vibe coding ne fait pas par défaut.
  4. Tu veux vraiment comprendre ce qui se passe. C'est sain. À ce moment-là, soit tu apprends une base solide, soit tu t'entoures.

Que faire ensuite : apprendre la base ou recruter

Deux chemins sains, à choisir selon ton appétit et ton temps :

  • Apprendre la base de la stack que tu utilises (HTML, CSS, JavaScript, un peu de React, un peu de SQL). 3 mois à raison de quelques heures par semaine et tu lis ton code sans aide. Tu continues à vibecoder, mais tu pilotes mieux. Idéal si tu veux rester founder solo longtemps.
  • Recruter un dev humain qui prend le relais. Tu lui donnes le code, il l'audite, il réécrit les parties critiques, il continue. Idéal si tu veux te concentrer sur le produit et la vente.

Sur le choix entre agence, freelance ou dev recruté, le guide vibe coding : agence ou faire soi-même entre dans le détail des coûts et du framework de décision.

Erreurs classiques à éviter (10 secondes)

Trois erreurs à esquiver dès ton premier projet :

  • Mettre une clé API en clair dans le code. Si l'IA te génère du code qui contient sk-... ou STRIPE_SECRET=... visible, tu retires et tu utilises les "secrets" ou "variables d'environnement" de ton outil. Sinon, n'importe qui peut piocher dans ton compte.
  • Ne jamais relire ce que l'IA a écrit. Pas besoin de comprendre, juste de scanner. Un fichier de 800 lignes pour afficher un bouton, c'est suspect.
  • Confondre prototype et produit livrable. Ton premier projet n'est pas prêt pour des utilisateurs payants. Il est prêt pour tester ton idée. Ne le mets pas en prod commerciale sans audit.

Pour les 10 erreurs complètes avec matrice gravité × probabilité et checklist de récupération, le guide erreurs vibe coding : les 10 pièges est la suite logique de cet article.

FAQ

Faut-il savoir un peu coder avant d'essayer le vibe coding ?

Non. Strictement zéro prérequis technique pour ouvrir Lovable ou Bolt et obtenir un résultat. Tu vas apprendre des morceaux de vocabulaire en cours de route (composant, base de données, déploiement) parce que l'IA va les utiliser, et c'est très bien comme ça : tu apprends en faisant, dans le bon ordre. Si tu sais déjà bricoler en HTML ou en Python, tu iras plus vite, mais ce n'est pas la condition d'entrée.

Vibe coding c'est juste pour les nuls ?

C'est l'inverse. Andrej Karpathy, qui a inventé le terme, est cofondateur d'OpenAI, ancien directeur IA chez Tesla et docteur de Stanford. Selon Jared Friedman, managing partner de Y Combinator, un quart des startups du batch W25 ont une base de code générée à 95 % par l'IA. Le vibe coding est un changement de couche d'abstraction. Le même que celui qu'a vécu le code lui-même quand on est passé de l'assembleur à Python.

Quel budget mensuel prévoir pour les outils ?

Pour ton apprentissage et tes premiers projets : 0 à 30 € par mois. Tu peux rester en gratuit pendant ta phase de découverte (Lovable, Bolt, Cursor ont tous un free tier). Une fois ton premier projet sérieux lancé, compte 20-30 € par mois pour l'outil principal que tu auras choisi. Ajoute 25 € si tu connectes une base de données type Supabase Pro et le 1 % de Stripe sur tes éventuelles ventes. Tu es très loin du coût d'un développeur freelance.

Le vibe coding peut-il remplacer un développeur ?

Pour un MVP, un outil interne, une landing, une démo investisseur, un calculateur métier : oui. Pour un produit critique qui sert 50 000 utilisateurs avec paiement, données sensibles, et SLA contractuel : non. Le bon usage 2026 du vibe coding : ne plus mobiliser un dev sur les cas simples où on sortait l'artillerie lourde. Sur les cas qui restent, un dev humain est indispensable, et mieux employé.