C’est quoi le vibe coding ? Définition, fonctionnement — et le chapitre que les guides sautent

Tout outil de vibe coding, quoi qu’en dise son marketing, exécute une version de la même boucle : décrire → générer → exécuter → réagir. Vous écrivez « une liste de tâches triées par date limite » ; l’agent planifie le changement, écrit le code dans tous les fichiers nécessaires, compile le projet, voit les mêmes erreurs qu’un programmeur verrait, les corrige et vous montre un résultat qui fonctionne. La phrase suivante — « les tâches en retard doivent être en rouge » — relance la boucle sur tout ce qui existe déjà.

Trois choses à l’intérieur décident si cette boucle produit quelque chose de bon, et il vaut la peine de les connaître parce qu’elles expliquent chaque différence de qualité entre outils :

Le contexte. L’agent ne peut respecter que ce qu’il voit — vos décisions précédentes, le code existant, le système de design. Les outils diffèrent énormément sur ce qu’ils retiennent et sur la façon dont ils choisissent quoi regarder.

La structure. Demandez les fonctionnalités une à une sans plan et l’agent improvise une architecture à chaque prompt — bien pour une démo, mal d’une façon qui s’accumule jusqu’à la vingtième fonctionnalité. Les outils qui décident la structure avant (ou vous la font décider) produisent du code qui reste utilisable.

La vérification. Les meilleurs outils ne vous livrent pas du code qui devrait fonctionner : ils le compilent, l’exécutent, le testent et corrigent leurs propres erreurs avant que vous ne voyiez quoi que ce soit. La différence entre « génère du code » et « livre un logiciel » est presque entièrement ici. Apple elle-même a intégré dans Xcode des agents qui itèrent entre compilation et correction.

Remarquez ce qui manque dans cette liste : votre capacité à programmer. Ce que la boucle consomme vraiment, c’est votre capacité à décrire avec précision et à réagir honnêtement — et c’est pour cela que les gens de produit l’ont prise en main plus vite que tout le monde. Écrire ce qui doit exister, scénario par scénario, c’était déjà leur travail.

Réussi, aujourd’hui : passer de l’idée au logiciel qui fonctionne en une séance ; itérer à bas coût (le « réessaie » qui coûtait l’après-midi d’un développeur coûte maintenant une phrase) ; les surfaces standard d’un produit — écrans, formulaires, listes, comptes, paiements sur des backends managés ; et laisser la personne qui a le jugement produit construire directement, au lieu de faire passer le message par des couches.

Échoue encore, honnêtement : le travail sans spécification descriptible (si vous ne savez pas dire à quoi ressemble « juste », l’agent ne peut pas le savoir non plus) ; les algorithmes vraiment nouveaux et la programmation système rare ; sauver une grande base de code ancienne qu’il n’a pas construite ; et compenser l’absence de réflexion produit — un agent amplifie la qualité des décisions dans les deux sens.

Et une façon d’échouer vient de l’utilisateur, pas des outils : confondre une démo avec un produit. N’importe quel outil de cette page vous donne une démo impressionnante en un après-midi. Un produit a besoin, en plus, d’une structure qui survit à la vingtième fonctionnalité, de comptes qui marchent, de données qui restent, de mises à jour qui sortent et d’un code qui vous appartient. Les outils diffèrent bien plus sur cette seconde moitié que sur la vitesse de la démo — et cela nous amène à la carte.

La plupart des listes classent par vitesse et par finition. Classez plutôt par résultat — en quoi se transforme vraiment ce que vous décrivez — et tout le marché se divise en cinq groupes. (Pas de prix ici : ils changent, et chaque outil publie les siens. La question à poser est toujours la même : dans quel forfait puis-je publier et emporter le code ?)

Les créateurs web — résultat : application web. Lovable est la référence : applications en React, synchronisation GitHub, backend sur Supabase ; sa propre documentation dit que « Lovable does not generate React Native projects ». v0 de Vercel et Bolt jouent le même match. Pour les produits web, ils publient vraiment ; pour prototyper n’importe quoi, ils sont excellents. Les alternatives à Lovable, classées par ce que vous voulez vraiment, ont leur propre page.

Les outils de prototypage — résultat : démos interactives jetables. Figma Make vit dans l’écosystème du design et est honnête sur ce qu’il est : fait pour explorer, pas pour publier.

Les agents de code, avec votre propre IA — résultat : ce que vous arrivez à diriger. Claude Code, Cline, Aider : des agents qui travaillent dans une vraie base de code avec votre abonnement ou votre clé API. Liberté maximale, aucun rail — excellents pour les développeurs, et la voie où les gens de produit ont le plus besoin de la structure qu’apporte le groupe suivant.

Les créateurs pour téléphone — résultat : application mobile, avec une bifurcation à l’intérieur du groupe que presque aucune liste ne nomme. Vibecode, Newly et Bolt avec Expo génèrent du React Native/Expo — du JavaScript multiplateforme qui tourne sur le téléphone à travers un pont, avec les mêmes écrans sur les deux systèmes. FlutterFlow assemble des applications Flutter visuellement. Rork est passé en 2026 au code natif — Swift pour iPhone, Kotlin pour Android — sous forme de deux applications séparées dans un même projet : selon ses propres docs, « each app has its own code ». Et Modaal (le nôtre) génère du vrai code natif de chaque plateforme — Swift/SwiftUI pour iPhone, Kotlin/Jetpack Compose pour Android — à partir d’un seul projet, la logique de chaque fonctionnalité écrite une fois et un écran natif par plateforme, avec un plan que vous approuvez avant chaque fonctionnalité, le code sur votre Mac et des prompts illimités dans le plan gratuit. Pourquoi cette bifurcation compte, c’est le chapitre suivant — parce que c’est la partie du vibe coding que les guides continuent de sauter. (Les dix créateurs, classés par ce qu’ils produisent, sont dans notre comparatif en anglais.)

C’est l’étrange lacune de tous les guides de vibe coding publiés jusqu’ici, en français comme en anglais : ils expliquent la boucle, listent les outils, montrent une démo web — et s’arrêtent au téléphone. « Pour mobile » apparaît, quand il apparaît, sous la forme « votre application web marche aussi dans le navigateur du téléphone ». Pour qui a un produit qui appartient à l’écran d’accueil d’un téléphone, cette phrase cache les trois faits qui comptent le plus :

1. Un site web sur le téléphone n’est pas une application. Notifications push, fonctionnement hors ligne, caméra et capteurs, widgets, montre et paiements dans les stores appartiennent aux vraies applications. Le test rapide : vos utilisateurs arrivent-ils en touchant un lien ou en ouvrant une icône ? La comparaison complète est dans notre guide en anglais.

2. Emballer votre application web faite en vibe coding ne franchit pas le fossé. Le raccourci évident — mettre l’application web dans une coquille en forme d’application — se heurte à la revue d’Apple, qui refuse régulièrement les coquilles fines autour d’un site, et à toutes les limites ci-dessus, parce que l’application reste un site déguisé.

3. Le fossé se franchit maintenant avec la même compétence. C’est ce qui a changé et ce que les guides n’ont pas encore enregistré : la boucle décrire-itérer produit désormais du vrai code natif. Dans la version de Modaal, la boucle est volontairement plus structurée que le vibe coding web — un document produit quand le projet commence et, pour chaque fonctionnalité, l’agent écrit d’abord un plan que vous pouvez lire (scénarios, approche, risques, tests) et ne construit qu’après votre approbation ; le résultat est du Swift et du Kotlin qu’un développeur de la plateforme reconnaît, compilé et testé, sur votre Mac. Du vibe coding où l’improvisation est remplacée par des spécifications — exactement la correction qui rend possible un résultat de production.

La conséquence pratique : la voie web et la voie mobile commencent maintenant de la même façon — par une description — et n’ont plus à finir par une réécriture. Vous avez validé quelque chose dans Lovable qui s’est révélé être une application ? Le backend survit généralement au déménagement ; la partie visible devient une vraie application native, décrite dans la même langue que celle du prototype. Et si le produit est pour les deux stores, la logique est écrite une fois et chaque plateforme reçoit son propre écran natif — sans rien reconstruire pour Android. Créer une application Android détaille cette voie côté Google.

La rampe d’entrée d’une séance, dans l’ordre qui évite les erreurs classiques :

1. Choisissez quelque chose de réel mais petit. Pas le produit phare de votre entreprise — un outil que vous voulez pour vous. L’apprentissage est dans la boucle, et les petites choses tournent plus vite.

2. Écrivez cinq phrases avant de toucher un outil. Ce que ça fait ; trois scénarios « l’utilisateur fait X, voit Y » ; ce que la première version laisse volontairement de côté. C’est la différence entre diriger et dériver — et c’est l’habitude qui passe ensuite à l’échelle jusqu’à la production. Le guide en neuf étapes met ces phrases à leur place dans l’ordre complet.

3. Choisissez l’outil par le résultat, pas par la démo. Produit web → créateur web. Produit mobile → outil à résultat mobile (et décidez consciemment entre natif et multiplateforme). Vous explorez seulement → n’importe lequel, sans remords.

4. Réagissez avec précision. « C’est mal » n’apprend rien à l’agent ; « le bouton va en bas, là où le pouce arrive » corrige en une étape. Donnez vos instructions à l’agent comme à un développeur très littéral et très rapide — une compétence que les gens de produit ont déjà.

5. Itérez tôt sur un vrai téléphone, si le produit est mobile — le simulateur est poli, le pouce est honnête.

Commencer ne coûte rien qui compte : les créateurs web ont des plans gratuits, et le plan gratuit de Modaal est un projet complet avec des prompts illimités ; Pro coûte 9 € par mois en paiement annuel — les détails sont sur la page des prix. Ce que coûte vraiment une application par chaque voie, avec chaque chiffre vérifiable, est dans le prix de création d’une application mobile ; et ce qu’on peut construire sans payer, avec nous et avec les autres, dans créer une application gratuitement. La ressource rare est celle de toujours — savoir quoi construire. Les outils ont seulement cessé de la cacher.