Vibe coding : coder sans coder, vraiment ?

Le terme vient d’un message publié le 2 février 2025 par Andrej Karpathy, ancien directeur de l’IA chez Tesla et cofondateur d’OpenAI. Il y décrivait une façon de programmer où l’on « se laisse porter par les vibes » et où l’on oublie que le code existe : on parle à une IA, on accepte tous ses changements sans relire les différences, on lui recolle les messages d’erreur, et on recommence jusqu’à ce que le problème disparaisse. Merriam-Webster a inscrit l’expression parmi ses termes d’argot suivis dès le 8 mars 2025, et le Collins English Dictionary en a fait son mot de l’année 2025.

Cette popularité a créé autant de confusion que d’enthousiasme. Certains y voient la fin du métier de développeur, d’autres un simple outil de maquettage. Les chiffres publiés depuis dix-huit mois racontent quelque chose de plus intéressant : la méthode raccourcit énormément le délai entre une idée et une première version visible, et elle allonge tout ce qui vient après, du débogage à la maintenance.

Qu’est-ce que le vibe coding

Le principe tient en une phrase : programmer en décrivant ce qu’on veut, au lieu d’écrire du code. Vous tapez « je veux un formulaire de contact avec validation d’email et envoi automatique » dans un outil comme Lovable, Bolt.new, Rocket.new ou v0. L’outil génère le code et l’interface. Si le résultat fonctionne, vous continuez. Sinon, vous décrivez le problème et l’IA corrige.

Dans cette approche, l’utilisateur ne lit pas toujours le code produit, et ne le comprend pas forcément. Il pilote l’IA par l’intention, le fameux « vibe », et l’outil s’occupe de l’implémentation. Une personne sans bagage technique peut donc créer une première version d’application sans ouvrir un fichier JavaScript, sans configurer une base de données et sans comprendre une architecture frontend. La qualité du résultat dépend alors presque entièrement de la qualité du brief, ce qui explique pourquoi l’art du prompt devient la compétence déterminante.

Pourquoi les outils y arrivent mieux qu’avant

Trois évolutions techniques expliquent le saut des dix-huit derniers mois. Les modèles de pointe lisent maintenant un million de tokens de contexte, ce qui leur permet de tenir une base de code entière en mémoire de travail au lieu d’un fichier isolé. Ils produisent une réflexion interne avant de répondre, avec un niveau d’effort réglable, ce qui change beaucoup sur un bug non trivial. Les éditeurs ont enfin transformé leurs assistants en agents : ils ouvrent des fichiers, lancent des commandes, lisent les erreurs et recommencent seuls.

Les résultats de bancs d’essai publiés par les éditeurs vont dans le même sens. OpenAI annonce 57,9 % pour GPT-6 Astra sur Terminal-Bench 4.0, contre 37,3 % pour GPT-5.6 Sol, et 72,6 % sur OSWorld 2.0 contre 65,7 %. Anthropic présente Claude Opus 5 comme doublant le score de son prédécesseur sur son banc interne Frontier-Bench, à un coût par tâche inférieur. Mistral revendique 77,6 % sur SWE-bench Verified pour Mistral Medium 3.5.

Ces résultats méritent une précaution. Chaque éditeur choisit ses bancs d’essai, les fait tourner lui-même et publie ce qui l’avantage. Aucun de ces tests ne mesure ce qui coûte réellement cher dans un logiciel : reprendre un projet six mois plus tard, comprendre une architecture qu’on n’a pas écrite, corriger un bug qui n’apparaît qu’en production avec du vrai trafic.

Les plateformes et ce qu’elles coûtent

Le vibe coding désigne une famille d’outils plutôt qu’un produit unique. Certains visent les non-développeurs, d’autres restent des environnements de développement assisté. Le bon choix dépend de votre objectif : une landing page, un MVP à tester, une interface React, une application complète ou l’accélération d’un projet existant. Les tarifs ci-dessous proviennent des pages officielles des éditeurs et bougent souvent, parce que la facturation à la tâche ou au token se généralise.

Outil	Offre gratuite	Payant, par mois	Terrain de jeu
Lovable	5 crédits par jour, plafonnés à 30 par mois	Pro à partir de 25 $ pour 100 crédits, Business à partir de 50 $	Application web complète depuis un prompt
Bolt.new	300 000 tokens par jour, 1 million par mois	Pro à partir de 25 $ pour 10 millions de tokens, Teams 30 $ par membre	Prototypage web avec plus de latitude technique
v0 (Vercel)	5 $ de crédits, 7 messages par jour	Plus 30 $ par personne, Business 100 $	Interfaces React et Next.js propres
Replit	Pas de formule gratuite	Core 20 $, Pro 100 $ avec 10 agents en parallèle	Créer, lancer et déployer dans le navigateur
Cursor	Offre Hobby, requêtes d’agent limitées	20 $ par personne, 40 $ par personne en équipe	Piloter une base de code existante par prompts
GitHub Copilot	2 000 complétions par mois	Pro 10 $, Pro+ 39 $, Max 100 $	Complétion et mode agent dans l’éditeur
Antigravity (Google)	Sans frais pour un développeur, selon Google	Offre entreprise sur devis	Orchestrer plusieurs agents locaux en parallèle

Lovable génère rapidement une application web à partir d’un prompt, et notre guide complet de Lovable détaille la méthode. Bolt.new mise sur le prototypage et la flexibilité, un terrain que couvre notre guide de Bolt.new. Rocket.new ajoute une couche produit, avec recherche de marché et veille concurrentielle. v0 de Vercel se concentre sur des interfaces React exploitables. Replit Agent devient intéressant quand il crée, lance et déploie un projet sans quitter le navigateur. Cursor et Windsurf restent plus techniques : ils servent à piloter une base de code par prompts sans abandonner le contrôle.

Les agents de code, l’autre moitié du sujet

À côté des plateformes visuelles, une seconde famille a pris beaucoup de place : les agents qui travaillent dans un terminal ou dans un dépôt, sur du code existant. Claude Code chez Anthropic, Codex chez OpenAI, Antigravity chez Google et Vibe Code chez Mistral suivent le même schéma. Vous décrivez une tâche, l’agent explore le dépôt, modifie plusieurs fichiers, lance les tests et rend un résultat à relire.

Ces outils déplacent la question. Avec une plateforme visuelle, vous ne voyez pas le code. Avec un agent de dépôt, vous le voyez mais vous n’en avez écrit aucune ligne, et la revue devient le vrai travail. Les équipes qui s’en sortent bien sont celles qui traitent la sortie de l’agent comme une contribution externe : lecture complète, tests, et refus sans état d’âme quand la solution contourne le problème au lieu de le résoudre. Notre article sur les agents IA explique le mécanisme général, et notre sélection d’outils pour développeurs compare les options.

À qui ça sert, et pour quoi faire

Le vibe coding a un vrai public. Les entrepreneurs y testent une idée avant d’investir. Les équipes produit fabriquent un prototype pour trancher un débat au lieu de le prolonger. Les indépendants et les PME s’en servent pour un outil interne qu’aucun budget ne financerait. Des développeurs expérimentés l’utilisent pour les tâches répétitives : premiers écrans, formulaires, migrations, code de plomberie, documentation.

L’usage change selon le profil. Un non-développeur s’en sert pour matérialiser une idée. Un développeur y gagne surtout de la vitesse d’exécution. Une équipe produit, elle, en fait un support de discussion, puisqu’on teste une version concrète au lieu d’argumenter sur une abstraction.

Le terrain où la méthode donne le meilleur d’elle-même se délimite assez bien : landing pages, prototypes, mini-outils internes, tableaux de bord simples, formulaires, MVP exploratoires et interfaces de démonstration. Vous pouvez demander une page de vente pour une nouvelle offre, un suivi de prospects, un outil de calcul interne, une maquette d’application mobile ou une interface de réservation, puis ajuster textes, couleurs et fonctionnalités par conversation. Si votre besoin se limite à un site vitrine, notre comparatif des IA pour créer un site web sans coder propose des options plus simples encore.

Ce que disent les études mesurées

Les démonstrations impressionnent, les mesures nuancent. L’expérience la plus citée reste celle de METR, publiée en juillet 2025 : 16 développeurs open source expérimentés ont traité 246 tâches réelles sur leurs propres dépôts, tous de grande taille. Avec l’autorisation d’utiliser l’IA, ils ont mis 19 % de temps en plus. Avant l’expérience, ils s’attendaient à gagner 24 % de vitesse, et après l’avoir vécue, ils croyaient encore avoir gagné 20 %. L’écart entre la sensation et la mesure constitue le résultat le plus important de cette étude. Elle a ses limites, que les auteurs signalent eux-mêmes : petit échantillon, développeurs très familiers de leur code, et outils de la génération précédente.

Le rapport DORA 2025, publié le 23 septembre 2025 auprès de près de 5 000 professionnels, donne une photographie plus large. Environ 90 % des répondants utilisent l’IA au travail et plus de 80 % estiment leur productivité en hausse, mais 30 % déclarent peu ou pas de confiance dans le code généré. Le point le plus utile concerne la livraison : l’adoption de l’IA s’accompagne d’un débit de livraison plus élevé et, dans le même temps, d’une stabilité plus faible. L’accélération révèle les faiblesses en aval quand les garde-fous manquent.

L’enquête développeurs de Stack Overflow 2025 complète le tableau. 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA, et la première frustration citée par 66 % d’entre eux tient en une formule : des solutions « presque justes, mais pas tout à fait ». Pour 45,2 %, déboguer du code généré prend plus de temps. Surtout, 72,2 % affirment que le vibe coding ne fait pas partie de leur travail professionnel, contre 11,9 % qui le pratiquent. La méthode reste donc marginale chez les développeurs de métier, alors qu’elle explose chez ceux qui n’en sont pas.

Côté jeunes pousses, la bascule est réelle. TechCrunch rapportait en mars 2025 qu’un quart de la promotion d’hiver de Y Combinator travaillait sur des bases de code générées à environ 95 % par IA. Ces équipes assument un arbitrage clair : la vitesse de mise sur le marché passe avant la propreté du code, parce que le produit changera peut-être entièrement dans trois mois.

Dette technique et sécurité du code généré

Trois séries de mesures distinctes convergent, et elles pèsent lourd dans la décision de confier ou non un projet au vibe coding.

• La sécurité ne progresse pas avec la puissance — le rapport GenAI Code Security de Veracode, publié le 30 juillet 2025, a testé plus de 100 modèles sur des tâches en Java, Python, C# et JavaScript. 45 % des échantillons produits échouent aux tests de sécurité et introduisent des failles du top 10 de l’OWASP. Le taux monte à 72 % en Java, contre 45 % en C#, 43 % en JavaScript et 38 % en Python. Sur les cas concernés par les failles de type XSS, les modèles ont manqué la défense dans 86 % des cas. Conclusion la plus gênante du rapport : les modèles plus récents écrivent du code plus fonctionnel, sans écrire du code plus sûr.
• Le code se duplique au lieu d’être réutilisé — GitClear a analysé 211 millions de lignes modifiées entre janvier 2020 et décembre 2024, dans des dépôts appartenant notamment à Google, Microsoft et Meta. Le copier-coller est passé de 8,3 % des lignes en 2021 à 12,3 % en 2024, dépassant pour la première fois les lignes simplement déplacées. Dans le même temps, la part des lignes liées à une refactorisation est tombée de 25 % à moins de 10 %. Autrement dit, on écrit plus de code, et on nettoie beaucoup moins.
• Les revues de code voient la différence — l’éditeur CodeRabbit a comparé, dans une étude publiée le 17 décembre 2025, 470 pull requests open source, dont 320 co-écrites par une IA et 150 écrites par des humains. Les premières comptent 10,83 problèmes par requête contre 6,45, avec jusqu’à 2,74 fois plus de failles de sécurité et environ 75 % de problèmes de logique en plus. L’étude vient d’un éditeur d’outils de revue, et l’attribution repose sur les signatures de co-auteur dans l’historique Git, deux réserves à garder en tête.

Ces chiffres ne condamnent pas la méthode. Ils indiquent où placer les garde-fous : revue systématique, analyse statique automatisée, et gestion des secrets. Un outil comme Snyk Code détecte une partie de ces failles avant la mise en ligne, et l’activer coûte beaucoup moins cher qu’une fuite de données.

Les incidents documentés

Deux affaires reviennent dans toutes les discussions, parce qu’elles montrent des mécanismes plutôt que de la malchance.

Les applications Lovable exposées, mai 2025

Matt Palmer et Kody Low, deux salariés de Replit, ont scanné 1 645 applications construites avec Lovable et mises en avant par l’éditeur. Selon Semafor, 170 d’entre elles laissaient fuir des données sensibles : noms, adresses e-mail, informations financières et clés d’API. Lovable a reconnu publiquement ne pas être au niveau visé en matière de sécurité, puis a ajouté un scanner. Des spécialistes ont relevé que ce scanner vérifie seulement si les contrôles d’accès de la base sont activés, pas s’ils sont correctement configurés. La provenance de l’étude mérite d’être signalée, puisque ses auteurs travaillaient pour un concurrent direct.

La base de production supprimée chez SaaStr, juillet 2025

Jason Lemkin, fondateur de SaaStr, a raconté publiquement son expérience avec l’agent de Replit, relayée par The Register. En trois jours et demi, sa facture atteignait 607,70 $ de frais d’usage, en plus de son abonnement Core à 25 $ par mois. L’agent a fabriqué des données et de faux rapports de tests, notamment une base de 4 000 personnes inexistantes. Puis il a supprimé la base de production alors qu’un gel du code avait été explicitement demandé. Replit a d’abord indiqué que la restauration était impossible, avant qu’elle fonctionne. Le problème de fond apparaît clairement : aucune séparation nette entre les environnements de préversion, de test et de production.

Un épisode plus récent concerne l’open source. The Register rapportait en juin 2026 une dispute dans le projet rsync, après qu’une version 3.4.3 a cassé des sauvegardes, des contributeurs mettant en cause des commits assistés par IA. Le sujet dépasse ce seul cas : plusieurs mainteneurs de projets libres décrivent depuis le début de l’année 2026 un afflux de contributions générées, plausibles en apparence et coûteuses à évaluer.

Les limites du vibe coding : ce que les démos ne montrent pas

Les articles sur le sujet montrent presque tous le même scénario : quelqu’un tape un prompt, une application apparaît, applaudissements. Le vrai test commence après la démo, et c’est là que les limites deviennent visibles.

Du code que personne ne comprend

L’IA produit des dizaines de fichiers que vous n’avez pas écrits. Quand un bug apparaît dans un fichier jamais ouvert, vous êtes coincé. Vous redemandez une correction, l’outil rustine par-dessus, le code s’empile, et après quelques itérations plus personne ne maîtrise ce qui se passe. Les développeurs parlent de « code orphelin ».

La sécurité, le point aveugle

Les applications générées contiennent des failles classiques : injections SQL, clés d’API écrites en dur, absence de validation des entrées, règles de base de données trop permissives. L’explication est simple : le modèle reproduit des schémas appris dans des dépôts publics, sans vérifier la sécurité de ce qu’il produit. Un prototype peut donc sembler parfaitement fonctionnel tout en étant dangereux à exposer à de vrais utilisateurs. Les 45 % d’échantillons vulnérables mesurés par Veracode chiffrent précisément ce risque.

Les 20 % restants coûtent cher

Un prototype impressionne en démonstration avec trois utilisateurs. En production avec du vrai trafic, les problèmes surgissent : performances qui s’effondrent, fuseaux horaires buggés, requêtes qui saturent la base, absence de tests, erreurs impossibles à reproduire. Ce passage du prototype au produit marque l’endroit exact où la méthode ne suffit plus.

La maintenance devient le vrai sujet

Générer une application est une chose, la maintenir en est une autre. Dès que vous ajoutez des fonctionnalités, corrigez des bugs ou changez le modèle de données, il faut comprendre l’architecture. Sans cette compréhension, chaque modification devient un pari. Plus un projet vibe codé grossit, plus il réclame de méthode, de documentation et de contrôle qualité, et les chiffres de GitClear sur la chute de la refactorisation décrivent exactement cette pente.

Faut-il s’y mettre ou attendre

S’y mettre, oui, mais pas n’importe comment. La méthode excelle pour les prototypes, les MVP, les outils internes jetables, les scripts d’automatisation et les maquettes interactives, tout ce qui doit exister vite sans devenir le produit final. Une idée de service peut se matérialiser en quelques heures, au lieu d’être décrite pendant des semaines dans un cahier des charges que personne ne lira.

Dès que vous visez la production, avec de vrais utilisateurs, des données personnelles et de la montée en charge, le vibe coding seul ne tient pas. Il vous faudra des compétences techniques pour auditer le code, ou un développeur qui sait travailler avec l’IA. Prévoyez aussi des tests, une gestion des accès, une stratégie de sauvegarde et une surveillance des erreurs. Le rapport DORA le formule autrement : l’IA amplifie ce qui existe déjà, les bonnes pratiques comme les mauvaises.

La règle que personne n’énonce assez clairement tient en une ligne : le vibe coding produit des brouillons, pas des produits finis. Ces brouillons sont rapides et parfois bluffants, mais ils restent des brouillons. Traitez-les comme un produit et vous aurez un problème. Utilisez-les comme point de départ et vous gagnez un avantage considérable.

Comment bien démarrer

Commencez petit. Choisissez un projet à une seule promesse, sans données sensibles, et formulez votre demande comme un brief complet : objectif, cible, fonctionnalités, style, contraintes et critères de réussite. Plus le brief est précis, moins l’outil inventera à votre place. Notre article sur la méthode de travail avec l’IA détaille cette étape de cadrage.

Avancez ensuite par paliers. Demandez la structure générale, validez-la, améliorez les écrans, puis ajoutez les fonctionnalités une par une en testant après chaque modification. Cette discipline ralentit légèrement le départ et vous épargne les projets impossibles à reprendre après dix prompts contradictoires. Deux réflexes complètent utilement la méthode : versionnez votre projet sur GitHub dès la première version qui fonctionne, et séparez immédiatement l’environnement de test de celui que voient vos utilisateurs.

Ce que le vibe coding change pour vous

Le rapport de force a déjà bougé. Avoir une idée sans savoir coder signifiait dépendre entièrement de quelqu’un d’autre pour la réaliser. N’importe qui peut désormais matérialiser un concept en quelques heures, le montrer, le tester, puis décider s’il vaut un investissement. Ce raccourci-là est acquis, et les chiffres de Y Combinator montrent que des entreprises se construisent déjà dessus.

Le métier de développeur, lui, se déplace vers la revue, l’architecture et la sécurité, précisément là où les mesures montrent que l’IA pèche encore. Les 19 % de lenteur mesurés par METR sur des experts et les 72,2 % de développeurs qui refusent le vibe coding dans leur travail disent la même chose : la méthode fait gagner du temps à l’entrée du projet et en fait perdre à la sortie. Sachez de quel côté vous vous trouvez avant de lancer votre premier prompt.