Le Vibe Coding en 2026 : Ce que les données révèlent après 16 mois

En résumé

• Andrej Karpathy a inventé le terme « vibe coding » le 2 février 2025. À la mi-2026, il le considère déjà dépassé et a adopté un nouveau cadre de travail.
• Une étude METR de juillet 2025 a révélé que les développeurs expérimentés sont 19 % plus lents avec les outils IA, alors qu'ils prévoyaient un gain de 24 %.
• 91,5 % des applications développées par vibe coding présentent au moins une faille de sécurité, selon une analyse du premier trimestre 2026 portant sur cinq études indépendantes.
• Le vibe coding fonctionne bien pour : les MVP, les outils internes, et les non-développeurs qui veulent valider une idée rapidement.
• Il échoue de manière prévisible pour : tout ce qui touche à l'authentification, aux paiements ou aux données utilisateurs sans relecture experte.
• L'évolution professionnelle s'appelle « agentic engineering » — mêmes outils, mais l'ingénieur lit chaque diff et reste responsable du résultat.

Le 2 février 2025, Andrej Karpathy a publié ce qu'il a lui-même qualifié de « tweet impulsif sous la douche » : « Il existe un nouveau style de programmation que j'appelle le 'vibe coding', où l'on s'abandonne complètement aux vibrations, on embrasse les exponentielles, et on oublie que le code existe. »

Ce tweet est devenu le mot de l'année 2025 du Collins Dictionary. Le marché qui s'est construit autour pèse aujourd'hui 4,7 milliards de dollars. Lovable, l'un des outils phares, a atteint 200 M d'ARR et une valorisation de 6,6 Mds à la mi-2026. Dans la cohorte Winter 2025 de Y Combinator, 25 % des startups tournaient sur des bases de code générées à 95 % par l'IA.

Seize mois, c'est suffisamment long pour cesser de se demander « est-ce que ça marchera ? » et commencer à se demander « que disent les données ? » La réponse est plus nuancée que le battage médiatique, plus utile que les critiques, et genuinement différente selon le profil de chacun.

Les chiffres de productivité ne racontent pas toute l'histoire

Les statistiques principales sont faciles à trouver : achèvement des projets 55 % plus rapide, développement d'applications 5,8 fois plus rapide, 74 % des développeurs déclarant des gains de productivité. Ce que ces résumés omettent systématiquement, c'est l'étude METR de juillet 2025.

Elle a testé des ingénieurs logiciels expérimentés sur des tâches réelles, avec et sans outils IA. Résultat : ils étaient 19 % plus lents avec l'assistance IA, alors qu'ils estimaient être 24 % plus rapides. L'écart entre prévision et réalité atteignait 43 points de pourcentage dans le mauvais sens.

Ce n'est pas un argument contre les outils IA. C'est un signal sur qui en bénéficie réellement. Les gains de productivité sont réels, mais très inégalement répartis :

• Les développeurs seniors avec plus de 3 ans d'expérience rapportent des gains de 40 à 81 % sur des tâches mesurées par des tiers
• Les développeurs juniors ne montrent aucune amélioration de production statistiquement significative
• Les non-développeurs, qui représentent 63 % des utilisateurs actifs du vibe coding (chefs de produit, fondateurs, designers), accèdent à quelque chose de fondamentalement différent : une capacité qu'ils n'avaient pas auparavant

Le résultat METR prend tout son sens quand on comprend ce que les outils IA font réellement. Ils réduisent les frictions sur les tâches bien définies et modulaires. Les ingénieurs expérimentés passent l'essentiel de leur temps à l'architecture, au débogage et aux décisions de jugement — pas à taper du code. Taper plus vite ne sert à rien quand le goulot d'étranglement est la réflexion. En revanche, un fondateur qui ne pouvait pas du tout créer un prototype avant peut désormais en construire un en un week-end.

L'outil est genuinement utile. Il n'est pas universellement utile de la même façon pour les mêmes personnes.

Le problème de sécurité est structurel, pas accidentel

Les statistiques sur les vulnérabilités proviennent de plusieurs sources indépendantes et convergent vers la même conclusion. OX Security rapporte que 62 % du code généré par l'IA est livré avec des failles de sécurité. Une analyse du premier trimestre 2026 publiée par SoftwareSeni a révélé que 91,5 % des applications développées par vibe coding présentent au moins une vulnérabilité, sur cinq études indépendantes. Escape.tech a analysé 5 600 applications de vibe coding accessibles publiquement et a documenté plus de 2 000 vulnérabilités à fort impact, plus de 400 secrets exposés, et 175 cas de données personnelles exposées dans des systèmes de production en ligne.

Le chiffre de 91,5 % est alarmant. Il l'est. Mais comprendre pourquoi est plus utile que d'être simplement alarmé.

L'IA génère du code en fonction de ce que vous lui demandez. Quand vous écrivez « crée-moi une application de tâches avec des comptes utilisateurs », l'IA écrit une authentification fonctionnelle. Elle n'ajoutera pas de protection contre les injections SQL, de limitation du nombre de tentatives de connexion, ou de jetons CSRF à moins que vous ne le demandiez explicitement. Ces couches de sécurité nécessitent une expertise métier pour savoir qu'elles existent.

Escape.tech a nommé ce schéma directement : les échecs du vibe coding tendent à être structurels, c'est-à-dire que des couches de sécurité entières n'ont jamais été implémentées parce que l'IA n'a jamais été invitée à le faire. C'est différent d'une IA qui écrit du code défaillant. L'IA a écrit exactement ce qu'on lui a demandé. Les éléments manquants n'ont jamais été sollicités.

C'est corrigeable par les personnes qui savent quoi demander. Ce n'est pas corrigeable en espérant que l'IA s'en occupera sans qu'on le lui demande.

L'analyse de CodeRabbit de décembre 2025 a révélé que le code co-écrit par l'IA contient environ 1,7 fois plus de problèmes « majeurs » par rapport au code écrit par des humains, dont un taux de vulnérabilités de sécurité 2,74 fois plus élevé. Ces données couvrent tout le code assisté par l'IA, pas seulement les applications de vibe coding pur, ce qui suggère que le problème s'amplifie à mesure qu'on réduit la supervision humaine.

Comprendre le spectre des outils

Le « vibe coding » est devenu un raccourci pour tout développement piloté par les prompts, ce qui crée de la confusion car les outils servent des utilisateurs très différents.

Les constructeurs IA sans code (Lovable, Bolt.new, Replit Agent) vous permettent de décrire ce que vous voulez en langage naturel. La plateforme génère, héberge et gère le code. Vous ne voyez jamais les fichiers sous-jacents. Ils sont conçus pour les non-développeurs et pour la validation rapide d'idées.

Les éditeurs de code IA (Cursor, Windsurf, Claude Code) nécessitent des connaissances en programmation. Ils génèrent du code dans votre environnement de développement, où vous lisez et révisez chaque modification avant de la valider. L'IA est un collaborateur très rapide, parfois peu fiable, pas un constructeur autonome.

Le point d'échec que rencontrent la plupart des équipes : commencer avec Lovable, atteindre 80 % d'un MVP fonctionnel, puis essayer de l'étendre en système de production sans comprendre ce qui a été construit en dessous. Les bases de code générées sans code ont souvent des patterns optimisés pour le générateur, pas pour la maintenabilité à long terme.

Un cadre de décision pratique :

Karpathy est déjà passé à autre chose

Celui qui a inventé le terme dit désormais qu'il est dépassé.

Lors de Sequoia Ascent 2026, Karpathy a présenté un cadre qu'il appelle « agentic engineering ». Son argument : dès décembre 2025, la fiabilité des modèles s'est suffisamment améliorée pour que le vrai goulot d'étranglement se déplace. La question n'est plus de savoir si l'IA peut écrire du code. C'est de savoir si les humains peuvent maintenir une supervision significative des systèmes écrits par l'IA.

La distinction qu'il établit :

Le vibe coding élève le plancher. N'importe qui peut construire quelque chose de fonctionnel. La qualité du code est souvent ce que Karpathy appelle « boursouflée, pleine de copier-coller, avec des abstractions maladroites et fragiles ». Ça se livre, et c'est précieux. Une faible responsabilité est appropriée car les enjeux sont faibles.

L'agentic engineering élève le plafond. Les développeurs professionnels orchestrent des agents IA tout en maintenant une responsabilité totale. Ils conçoivent des spécifications avant de prompter, révisent les diffs avant de les fusionner, écrivent des tests, construisent des boucles d'évaluation, et gèrent les permissions avec soin.

La phrase la plus citée de la conférence : « Vous pouvez déléguer votre réflexion, mais vous ne pouvez pas déléguer votre compréhension. »

En pratique, la frontière entre les deux approches ne se situe pas dans l'outil utilisé. Elle se situe dans ce que vous faites après que l'IA a généré du code. Un développeur utilisant Cursor qui accepte toutes les suggestions sans les lire fait du vibe coding. Un développeur qui traite chaque diff généré comme une PR d'un ingénieur junior, le lit ligne par ligne, et refuse de fusionner ce qu'il ne peut pas expliquer, fait de l'agentic engineering. Même outil. Discipline différente.

Ce qu'il faut toujours écrire ou relire soi-même

Sur la base des schémas d'échec documentés, certaines catégories ne devraient jamais passer en production sans relecture humaine, quelle que soit l'approche :

• La logique d'authentification : hachage des mots de passe, gestion des sessions, validation des jetons
• Le traitement des paiements : gestion des webhooks, clés d'idempotence, récupération des états d'erreur
• Les requêtes de base de données avec saisie utilisateur : tout code qui construit des requêtes à partir de données externes
• Les vérifications d'autorisation : qui peut lire, écrire ou supprimer quels enregistrements
• La gestion des secrets : variables d'environnement, rotation des clés API, stockage des jetons

Tout le reste est un candidat raisonnable pour la génération assistée par IA avec relecture. Ces cinq catégories sont là où les défaillances structurelles se concentrent.

FAQ

Les non-développeurs peuvent-ils vraiment déployer des applications en production grâce au vibe coding ?

Oui, avec une distinction importante sur ce que « production » signifie. Un outil interne utilisé par 5 personnes est différent d'une application grand public qui stocke des données de paiement pour 5 000 utilisateurs. Les non-développeurs construisent et déploient avec succès la première catégorie. Pour la seconde, le consensus des chercheurs en sécurité en 2026 est le suivant : validez votre idée avec le vibe coding, puis faites auditer les chemins critiques pour la sécurité par un développeur avant de servir de vrais utilisateurs avec de vraies données.

Quelle est la vraie différence entre Lovable et Cursor ?

Lovable abstrait entièrement le code. Vous décrivez, il construit, vous déployez, vous ne touchez jamais aux fichiers. Cursor est un éditeur de code où l'IA vous aide à écrire plus vite, mais vous restez dans la base de code, lisant et validant chaque modification. Le bon choix dépend de votre capacité à lire du code, pas des meilleures critiques d'un outil. Pour les développeurs, Cursor. Pour tous les autres qui débutent, Lovable ou Bolt.

Le vibe coding est-il mort ?

En tant que pratique, non, c'est devenu courant. GitHub rapporte que 46 % du nouveau code est désormais généré par l'IA. En tant que terme décrivant précisément ce que font les ingénieurs expérimentés avec ces outils, il est en train de disparaître. Karpathy lui-même est passé à autre chose. Les outils sont les mêmes ; l'exigence professionnelle de supervision a changé.

Combien coûte réellement le démarrage avec le vibe coding ?

Le plan payant de Lovable commence à 25 /mois (en juin 2026). Cursor Pro est à 20 /mois. Bolt.new propose un niveau gratuit avec des tokens limités par jour. Claude Code est facturé à l'usage via l'API d'Anthropic. Un fondateur solo qui construit un MVP peut généralement rester sous 50 /mois à faible utilisation. Les charges de travail en production sur de grandes bases de code peuvent atteindre 200 à 500 /mois selon l'intensité des opérations consommatrices de tokens.

Le verdict final

Le vibe coding n'est pas une arnaque et ce n'est pas un remplacement du génie logiciel. C'est un spectre : d'un côté, des personnes non techniques qui construisent de vraies choses pour la première fois ; de l'autre, des ingénieurs expérimentés qui utilisent l'IA comme collaborateur à haute vélocité tout en maintenant leur responsabilité sur ce qui est déployé.

Les échecs sont prévisibles. Ils suivent un schéma : accepter de grandes quantités de code généré sans le lire, sauter des couches de sécurité qui n'ont jamais été demandées, et essayer de faire évoluer un prototype sans code en système de production sans comprendre l'architecture sous-jacente.

Les personnes qui tirent le plus parti de ces outils à la mi-2026 ne sont pas celles qui « s'abandonnent complètement aux vibrations ». Ce sont celles qui savent exactement quand déléguer à l'IA et exactement quoi inspecter quand le résultat revient.

Pour un panorama des outils d'IA pour le développement, notre guide des meilleurs assistants IA pour le code couvre tout le spectre, de Cursor à GitHub Copilot, avec les tarifs de 2026.

Si vous commencez à construire des workflows pilotés par des agents au-delà de la simple génération de code, comment utiliser les agents IA présente les patterns d'orchestration pratiques qui distinguent la génération ponctuelle des systèmes automatisés reproductibles.