Vibe coding : guide complet 2026 (définition, outils, limites, prix)

Qu’est-ce que le vibe coding selon Karpathy ?

Le vibe coding est l’approche où un développeur ou un fondateur pilote un agent IA en langage naturel pour générer du code, sans relire ni réécrire chaque ligne de code. Le terme a été introduit par Andrej Karpathy, chercheur en IA, cofondateur d’OpenAI et ex-directeur IA chez Tesla, dans un tweet du 2 février 2025 qui a atteint environ 4,5 millions de vues.

Le verbatim Karpathy :

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good.”

Cette nouvelle façon de coder n’a pas tardé à devenir sujet de débat. Karpathy lui-même a qualifié ce tweet de “shower of thoughts throwaway tweet” et son sens strict a depuis dérivé.

Simon Willison, ingénieur de référence en LLM appliqué (grands modèles de langage), a précisé la définition dans son article “Not all AI-assisted programming is vibe coding (but vibe coding rocks)” du 19 mars 2025. Le vibe coding désigne uniquement le cas où tu acceptes le code généré sans pouvoir l’expliquer à un tiers, selon Simon Willison. Toute pratique où tu te donnes le temps de lire et comprendre chaque ligne reste de l’AI-assisted coding standard. Verbatim Willison : “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”

La majorité des fondateurs qui disent “vibe coder” en 2026 font en réalité de l’AI-assisted coding, ou programmation assistée par IA. La distinction compte pour deux raisons : qui assume la responsabilité du code en production, et qui peut le déboguer quand il casse.

Quels sont les outils de vibe coding qui dominent en 2026 ?

Cinq outils dominent le vibe coding en 2026 : Cursor (Anysphere, 2 milliards de dollars d’ARR), Lovable (400 millions de dollars d’ARR, ~200 000 projets/jour), Bolt (StackBlitz), Claude Code (Anthropic) et Replit. Windsurf, Aider et Cline complètent la liste sur des usages plus spécialisés. Les écarts de valorisation entre ces outils sont massifs et reflètent les usages dominants du marché.

Cursor atteint 2 milliards de dollars d’ARR en février 2026, selon les chiffres rapportés par Bloomberg. C’est le double du milliard de dollars d’ARR annoncé lors de la Series D de novembre 2025 par Anysphere (la société éditrice), à l’occasion d’une levée de 2,3 milliards de dollars valorisant Cursor 29,3 milliards de dollars (Cursor blog Series D, novembre 2025). Cursor reste l’outil de référence des développeurs qui veulent un IDE complet avec agent intégré.

Lovable atteint 400 millions de dollars d’ARR en février 2026 avec environ 8 millions d’utilisateurs et près de 200 000 projets générés chaque jour, d’après TechCrunch en mars 2026 qui rapporte 100 millions de dollars de revenus ajoutés sur le seul mois de février 2026, avec 146 employés. Lovable cible les fondateurs non techniques qui veulent générer une application complète à partir d’un prompt.

Bolt (StackBlitz), Claude Code (Anthropic), Replit et Windsurf complètent le haut du classement, chacun avec un positionnement distinct : Bolt sur le développement web rapide, Claude Code sur le code sur mesure côté serveur, Replit sur l’IDE collaboratif complet, Windsurf sur la productivité du développeur senior. Aider et Cline servent une audience plus technique qui veut un agent dans le terminal, sans IDE imposé.

Le choix de l’outil dépend moins de la marque que de l’intention du fondateur. Un prototype de validation marché en deux jours appelle Lovable ou Bolt. Un MVP B2B SaaS destiné à des utilisateurs payants en production appelle Cursor ou Claude Code, piloté par un humain qui sait déboguer. Pour la logique derrière le stack que j’utilise chez Ary, voir la page Notre stack.

Pour qui le vibe coding fonctionne-t-il vraiment ?

Le vibe coding fonctionne quand trois conditions sont réunies en même temps : un périmètre discipliné, un opérateur capable de détecter les schémas douteux, et un produit dont la complexité métier ne dépasse pas le contexte que l’IA peut tenir en tête.

Fondateurs non techniques qui construisent un MVP B2B SaaS sur périmètre serré (authentification + tableau de bord + paiement + une à trois fonctionnalités) tiennent généralement le délai de 4 semaines avec un vibe coding bien piloté. C’est exactement la cible chez Ary : 5 000 à 25 000 € livrés en 4 semaines.

Fondateurs solos qui livrent vite : la viralité d’un projet vibe-codé en quelques heures n’est pas un mythe. Un simulateur de vol web, codé en 3 heures avec Cursor, a généré 1 million de dollars d’ARR en 17 jours avec 320 000 joueurs et 74 millions d’impressions. Le cas est documenté publiquement par l’auteur sur X. La leçon n’est pas “tout le monde peut faire 1 million d’ARR en 17 jours” mais “un prototype vibe-codé peut révéler un marché en quelques semaines avec un budget minimal”.

Validation de prototypes côté équipes techniques : Tom Blomfield, associé chez Y Combinator, a vibe-codé un site de recettes à navigation vocale en quelques semaines, avec une stack Windsurf + Claude Code + Gemini 2.5 Pro + OpenAI voice mode, pour valider l’expérience produit. C’est un usage à faible enjeu où le code n’a pas vocation à tenir en production commerciale.

Cas Ary interne : je construis Wytt, mon SaaS d’orchestration SEO en production avec des utilisateurs payants, sur stack Elixir/Phoenix LiveView avec PostgreSQL. Cursor et Claude Code pour le développement, avec un dev senior Elixir en renfort sur les composants critiques quand c’est nécessaire. C’est la preuve par la pratique sur soi : je vends ce que j’utilise au quotidien. Voir À propos.

Pour qui le vibe coding ne fonctionne pas ?

Le vibe coding échoue de manière prévisible dans quatre contextes : développeurs experts sur leur stack de référence, passage à l’échelle en grande entreprise avec architecture complexe, secteurs régulés (santé, finance, paiement, données personnelles), code propriétaire métier qui doit tenir 5 ans ou plus.

Développeurs experts sur leur stack de référence : ils écrivent plus vite manuellement que par la boucle “prompt, génère, relis, corrige”. La productivité réelle baisse de 19 % sur des développeurs open source expérimentés, selon l’étude RCT METR de juillet 2025. Le schéma est confirmé par des retours publics : un prototype Python de 3 heures avec Cursor demande ensuite 15 heures de nettoyage pour atteindre un code maintenable.

Passage à l’échelle en grande entreprise et architecture complexe : au-delà d’une certaine surface de code logiciel, l’IA perd le contexte global. Les schémas N+1, les conditions de course sur les tâches d’arrière-plan, les fuites de mémoire sur les connexions persistantes : aucun de ces problèmes n’apparaît à un agent qui regarde un point de terminaison isolé. Un développeur senior identifie un N+1 instantanément, l’IA non.

Secteurs régulés et flux métier critique : santé, finance, paiement, données personnelles à fort enjeu réglementaire. Le code IA introduit régulièrement des failles d’autorisation. Un audit de plus de 5 600 applications vibe-codées analysées par Escape.tech en octobre 2025 a relevé 175 cas confirmés de fuite de données personnelles. Dans un contexte réglementé, c’est inacceptable.

Code propriétaire métier qui doit tenir 5 ans : le coût de maintenance d’un code généré sans compréhension explose dans le temps. Les retours publics de fondateurs ayant utilisé Cursor sur plusieurs mois décrivent une explosion de la dette technique, des duplications de logique métier répétées d’un fichier à l’autre, et des heures de débogage hors-normes pour des problèmes qui auraient pris quelques minutes avec du code écrit en pleine conscience.

Quelle méthode fait tenir le vibe coding en production ?

La méthode qui fait tenir le vibe coding en production combine quatre éléments : pilotage par un fondateur identifiable, stack Elixir/Phoenix LiveView avec PostgreSQL natif, l’appui ponctuel d’un dev senior sur les composants critiques, et périmètre figé par écrit avant le démarrage. Aucune agence MVP française ne publie de méthode précise sur ce sujet en 2026 - la majorité des concurrents annoncent “prototypage IA puis refonte pro” sans nommer le stack ni le processus. Voici exactement ce que je fais chez Ary, semaine par semaine.

Avec Ary, vibe coding signifie qualité production : pilotage par un fondateur identifiable, sur stack Elixir/Phoenix LiveView avec PostgreSQL, avec un dev senior en renfort sur les composants critiques.

Semaine 1, cadrage : cahier des charges léger signé, maquettes des écrans clés, architecture technique fixée. Le périmètre est figé par écrit avant le début du développement. Si l’idée ne tient pas en 4 semaines, je le dis avant la signature, pas au milieu.

Semaines 2 et 3, construction du cœur : je code en pilotant Cursor et Claude Code sur stack Elixir/Phoenix LiveView avec PostgreSQL natif. Sur les composants sensibles, un dev senior Elixir intervient en relecture : authentification, paiement Stripe, contraintes de sécurité au niveau Ecto, tâches d’arrière-plan, intégrations API tierces. Tu ne le vois pas. Tu me parles à moi. La responsabilité reste la mienne. Démonstration vidéo chaque vendredi.

Semaine 4, lancement : recette, corrections, mise en production sur Fly.io ou Cloudflare. Dépôt GitHub transféré le jour de la livraison, documentation incluse, accès serveur partagés. 30 jours de support sur les bugs critiques inclus après le lancement.

Dans ce flux de travail, le principe de relecture n’est pas “le développeur senior valide le code de l’IA comme un junior bien intentionné”. C’est “le développeur senior audite le code comme une contribution externe d’un contributeur rapide mais non fiable”. La distinction change tout : tu cherches activement les schémas qui cassent, tu ne fais pas confiance au “ça compile donc c’est bon”.

Le choix du stack n’est pas neutre. La majorité des outils vibe coding génèrent du Next.js + Supabase par défaut. C’est aussi la stack la plus représentée dans les incidents de sécurité documentés en 2025-2026. PostgreSQL natif avec contraintes au niveau du code (Ecto plus authentification manuelle) garde la sécurité dans les fichiers source, pas dans des politiques RLS configurées par prompts. La logique détaillée est sur la page Notre stack.

Le coût et le délai sont publics : 5 000 à 25 000 € livré en 4 semaines, garantie remboursable contractuelle signée avant le démarrage. Voir les tarifs, la méthode en détail et la garantie 4 semaines.

Quelles sont les limites de sécurité du vibe coding ?

Les limites de sécurité du vibe coding sont mesurables : 45 % du code généré par IA introduit une vulnérabilité OWASP (Veracode 2025), plus de 5 600 applications vibe-codées scannées en octobre 2025 contiennent plus de 2 000 vulnérabilités et 175 fuites de données personnelles confirmées (Escape.tech), et la CVE-2025-48757 documente une faille critique CVSS 9.3 sur les applications Lovable antérieures à avril 2025. Trois études publiques cadrent l’écart entre le marketing des outils et la réalité de production. Pour la cartographie complète des limites au-delà de la sécurité, voir les limites du vibe coding.

Quel taux de vulnérabilités OWASP sur le code généré par l’IA ?

45 % des completions de code généré par IA introduisent une vulnérabilité OWASP, selon le 2025 GenAI Code Security Report de Veracode publié le 30 juillet 2025, qui a testé plus de 100 LLMs sur 80 tâches de sécurité standard sur quatre langages (Java, JavaScript, Python, C#). Le rapport est consultable sur la page Veracode. Les détails par langage et par type de vulnérabilité sont dans le PDF téléchargeable.

Combien de vulnérabilités sur les applications réelles ?

Escape.tech a publié en octobre 2025 son rapport “State of Security of Vibe-coded Apps”, consultable sur le site Escape. Sur plus de 5 600 applications vibe-codées scannées, l’audit a identifié plus de 2 000 vulnérabilités, 175 cas confirmés de fuite de données personnelles, et plus de 400 secrets exposés dans le code. Ces chiffres documentent l’état réel des MVPs vibe-codés en circulation, pas un test de laboratoire.

La CVE Lovable + Supabase de mai 2025

Parmi les problèmes de sécurité les plus médiatisés, l’incident le plus documenté reste la CVE-2025-48757, publiée le 29 mai 2025 sur la base NIST. Score CVSS 9.3 Critical, classification CWE-863 (Incorrect Authorization). La vulnérabilité affectait des applications générées par Lovable avant le 15 avril 2025 et permettait à des attaquants non authentifiés de lire ou écrire dans des tables arbitraires des sites générés, en raison d’une politique de Row-Level Security insuffisante. La fiche officielle est sur la base NIST. Note importante : le vendeur conteste la CVE et la NVD ne l’a pas enrichie. La leçon reste valable : les RLS configurés par prompt IA sont fragiles par défaut, indépendamment du verdict final sur cette CVE spécifique.

Quel schéma de sécurité l’IA ne détecte jamais ?

Les failles de sécurité que l’IA ne détecte jamais sont au nombre de six : authentification sans limitation de débit, politiques RLS contournables, suppressions logiques manquantes exposant des données archivées, validation des entrées purement côté client, secrets API codés en dur dans le paquet JavaScript, et points de terminaison administrateur sans contrôle de permission. Ces failles ressortent à 8 à 14 occurrences sur un audit typique d’application vibe-codée. Un agent IA les reproduit à grande échelle en recopiant des modèles publics ; un développeur senior les repère en relecture. C’est l’écart structurel qui justifie la relecture.

Le code IA est-il plus risqué quand on a confiance ?

Les développeurs qui utilisent un assistant IA écrivent du code objectivement moins sécurisé, mais auto-évaluent leur code comme plus sécurisé que ceux qui codent sans assistant, selon une étude Stanford de 2022 (Perry et al., arXiv 2211.03622, présentée à CCS 2023). C’est l’effet d’excès de confiance. Le risque sécurité du vibe coding ne vient pas seulement de l’IA, il vient aussi de la confiance accordée à l’IA sans vérifier.

Le vibe coding rend-il vraiment les développeurs plus productifs ?

Le vibe coding ne rend pas systématiquement les développeurs plus productifs. Les développeurs expérimentés perdent 19 % de productivité réelle avec Cursor + Claude alors qu’ils en anticipaient +24 %, selon l’étude RCT METR de juillet 2025 (16 développeurs, 246 tâches réelles). Le marketing GitHub Copilot annonce +55 % de vélocité depuis 2023 ; la réalité mesurée par une étude indépendante est l’inverse.

L’étude Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv 2507.09089, Joel Becker, Nate Rush, Elizabeth Barnes, David Rein) a observé 16 développeurs open source expérimentés sur 246 tâches de code réelles, avec Cursor Pro et Claude 3.5/3.7. Après l’expérience, ils continuaient à estimer leur productivité à -20 %, alors qu’ils étaient objectivement plus lents.

Ce résultat dit deux choses qui comptent. D’abord, les développeurs ne perçoivent pas qu’ils sont ralentis par les outils. Le décalage entre auto-évaluation et mesure est massif. Ensuite, le contexte de mesure (développeurs open source expérimentés sur leur stack de référence) ne couvre pas tous les cas d’usage. Sur un fondateur non technique qui n’a pas de stack de référence, l’écart est probablement positif. Sur un développeur senior sur sa stack de référence, il est négatif.

84 % des développeurs utilisent ou prévoient d’utiliser un outil IA en 2025, contre 76 % en 2024, mais le sentiment positif chute de 70 %+ en 2023-2024 à 60 % en 2025 (-10 points), selon le 2025 Developer Survey de Stack Overflow (survey.stackoverflow.co, n = 49 000+ répondants). 45,2 % des répondants disent que déboguer du code généré par IA prend plus de temps que déboguer leur propre code. Le décalage entre adoption qui monte et confiance qui baisse révèle un usage utilitaire sans illusion.

L’écart 2023-2025 dans le code généré au quotidien (un rapport GitClear sur 211 millions de lignes de code entre 2020 et 2024) montre une dégradation de la qualité du code en développement logiciel : la fréquence de copier-coller passe de 8,3 % à 12,3 %, et le taux de réécriture du code (lignes réécrites dans les deux semaines suivant l’écriture initiale) passe de 5,5 % en 2020 à 7,9 % en 2024. La productivité immédiate compense en partie la dette technique générée, jusqu’à ce que la dette devienne le goulot d’étranglement.

Combien coûte un MVP livré en vibe coding ?

Le prix d’un MVP livré par une agence MVP qui utilise du vibe coding est de 5 000 à 25 000 € en 4 semaines chez Ary, sur stack Elixir/Phoenix LiveView avec PostgreSQL. Le palier exact dépend du périmètre : léger 5 000 à 10 000 € (validation rapide, 1 à 2 fonctionnalités), standard 10 000 à 18 000 € (MVP SaaS B2B complet), avancé 18 000 à 25 000 € (avec intégrations tierces et interface d’administration).

J’évalue ici le vibe coding comme méthode et je vends des MVP livrés ainsi ; les données sécurité (Veracode, Escape.tech, METR, NIST) restent sourcées indépendamment.

Pour le détail complet (ventilation poste par poste, première année réelle, coût de reprise, aides 2026 cumulables qui ramènent le coût net sous zéro), voir le guide prix MVP 2026.

Pour les paliers détaillés et les inclusions par tarif, voir les tarifs publics.

Vibe coding ou no-code, lequel choisir pour ton MVP ?

Le no-code (Bubble, Webflow) reste rentable en dessous de 5 000 à 15 000 $ de MRR, à 2 000 à 8 000 € à la livraison plus 349 $/mois minimum. Le vibe coding en code sur mesure devient rentable au-dessus de ce seuil, à 5 000 à 25 000 € à la livraison avec dépôt GitHub transféré dès le jour 1 et aucun plafond d’usage. Les deux répondent à des usages différents, pas au même produit.

Le no-code (Bubble, Webflow) coûte 2 000 à 8 000 € à la livraison mais 349 dollars par mois minimum sur le plan Growth de Bubble, avec des workload units qui explosent à partir de 30 000 à 50 000 enregistrements. Tu loues l’infrastructure, tu ne la possèdes pas. Si Bubble change ses conditions tarifaires, tu n’as aucun recours rapide. La migration off-Bubble coûte 5 000 à 50 000 € selon la complexité de l’application existante.

Le vibe coding en code sur mesure coûte 5 000 à 25 000 € à la livraison chez une agence MVP spécialisée en 2026, avec un dépôt GitHub transféré au client dès le jour 1, aucun plafond d’usage, et la possibilité de réembaucher n’importe quel développeur sur la même stack pour reprendre le projet.

Le seuil de bascule économique se situe vers 5 000 à 15 000 dollars de MRR. En dessous, le no-code reste rentable. Au-dessus, le coût des workload units dépasse le coût annualisé d’un MVP en code sur mesure équivalent, et la reconstruction devient une nécessité économique. C’est le moment où le coût de reprise no-code entre en jeu, et c’est précisément ce que tu paies en plus pour avoir choisi la voie qui semblait moins chère au départ.

Pour la logique détaillée du choix de stack chez Ary (pourquoi Elixir/Phoenix LiveView plutôt que Next.js + Supabase, et pourquoi PostgreSQL natif plutôt que Supabase), voir la page Notre stack.

Le vibe coding est-il déjà passé par l’agentic engineering ?

Le vibe coding n’est pas encore dépassé par l’agentic engineering en 2026, malgré le pivot annoncé par Andrej Karpathy et Simon Willison eux-mêmes, parce que l’agentic engineering autonome n’a pas encore ses CVE documentées, ses études de productivité indépendantes, ni ses méthodes de relecture stabilisées. Le débat agite pourtant la communauté tech depuis le début 2026, et vient d’un endroit inattendu : les deux personnes qui ont défini le vibe coding en 2025.

Andrej Karpathy lui-même, dans une intervention rapportée par The New Stack début 2026 (“Vibe coding is passé”), déclare préférer désormais l’agentic engineering et résume sa pratique courante par le fait qu’il n’écrit plus directement le code 99 % du temps, via des agents orchestrés plutôt que par prompts directs. La nuance compte : il ne s’agit plus de “fully give in to the vibes” comme dans le tweet originel de février 2025, mais d’orchestrer plusieurs agents IA qui coopèrent sur un projet, avec un humain qui définit l’architecture et valide les jalons.

Simon Willison, le 6 mai 2026, publie “Vibe coding and agentic engineering” sur son blog où il admet une convergence personnelle inquiétante entre les deux pratiques. Il écrit que pour ses propres outils il ne relit plus le code généré, et s’interroge ouvertement sur la responsabilité de l’utiliser ainsi en production. C’est l’inverse exact de ce qu’il défendait en mars 2025.

Pour un fondateur non technique francophone qui construit un MVP B2B SaaS en 2026, la conclusion utile n’est pas “il faut migrer vers l’agentic engineering”. C’est plutôt : le terrain bouge vite, et la majorité des outils prêts pour la production reposent encore aujourd’hui sur le vibe coding strict avec relecture humaine. L’agentic engineering autonome reste un domaine de pionniers et de configurations expérimentales, où les schémas de production solides ne sont pas encore stabilisés.

Chez Ary, je continue à livrer en vibe coding piloté, épaulé ponctuellement par un dev senior quand le périmètre l’exige, parce que c’est la méthode qui tient en production en 2026 sur des MVP B2B SaaS. Le jour où l’agentic engineering aura ses CVE documentées, ses études de productivité indépendantes, et ses méthodes de relecture stabilisées, je pivoterai. Pour l’instant, c’est trop tôt.

Si tu veux discuter de ton projet directement avec moi, je suis Parham, fondateur de mon agence MVP à Paris.

Foire aux questions