La diffusion du terme « vibe coding »

Andrej Karpathy, informaticien slovaquo-canadien au parcours remarquable dans le domaine de l’intelligence artificielle (IA), notamment en tant qu’ancien directeur de l’IA chez Tesla et cofondateur d’OpenAI, a créé le terme « vibe coding » en février 2025. Sa vaste expérience en apprentissage profond et en vision par ordinateur, ainsi que son rôle de principal enseignant du premier cours de Stanford sur l’apprentissage profond, CS 231n, font de lui une voix respectée dans la communauté de l’IA.

Le 2 février 2025, Karpathy a publié un message sur X/Twitter décrivant une nouvelle approche qu’il a appelée « vibe coding », où les développeurs « se laissent complètement porter par les vibes, accueillent les progrès exponentiels et oublient jusqu’à l’existence du code ». Il ne s’agissait pas simplement d’une nouvelle déclaration provocatrice d’un leader de la tech, mais de la mise en mots d’une expérience que beaucoup de développeurs vivaient déjà sans l’avoir nommée.

Karpathy a expliqué sa méthode : utiliser des commandes vocales avec SuperWhisper pour limiter l’usage du clavier, faire des demandes simples comme des ajustements d’interface, accepter systématiquement toutes les modifications suggérées sans les examiner, puis, en cas d’erreur, simplement la copier-coller dans l’IA. Il a reconnu que cette approche faisait grandir le code « au-delà de ce qu’[il] pouvait habituellement comprendre » et que corriger les bogues revenait parfois à « contourner les problèmes ou à apporter des changements apparemment aléatoires jusqu’à ce qu’ils disparaissent ».

Qu’est-ce que le vibe coding ?

Le vibe coding est une approche volontairement décontractée du développement logiciel, dans laquelle les développeurs — y compris ceux qui n’ont pas de formation ni d’expérience formelle — utilisent des assistants d’IA pour écrire du code avec très peu de supervision ou de compréhension de ce qui est généré. Au lieu d’examiner attentivement chaque modification, les adeptes du vibe coding font confiance au résultat de l’IA, acceptent en bloc les changements suggérés et traitent les messages d’erreur comme des données à renvoyer à l’IA plutôt que comme des problèmes à déboguer eux-mêmes. Cette approche n’est pas mauvaise en soi. C’est une excellente chose de voir davantage de code écrit et le processus devenir plus accessible aux personnes moins techniques.

Le code lui-même devient presque secondaire ; l’essentiel est de savoir si l’application semble fonctionner. C’est programmer « au feeling » plutôt que par compréhension, en privilégiant la vitesse et les itérations au détriment des pratiques traditionnelles du génie logiciel, comme la revue de code, les tests et la compréhension globale de sa base de code. À l’extrême, le vibe coding consiste à créer des applications sans pouvoir expliquer le fonctionnement de la majeure partie du code, parce qu’on ne l’a pas écrit et qu’on ne l’a même pas vraiment lu.

C’est partout

Le terme « vibe coding » s’est propagé à la vitesse d’Internet. En quelques heures, Amjad Masad, PDG de Replit, a réagi, en faisant remarquer qu’environ 75 % des utilisateurs de Replit écrivaient déjà du code sans le rédiger eux-mêmes. Karpathy n’avait donc pas tant inventé une nouvelle pratique que donné un nom à une pratique déjà répandue.

Le 12 février, un fil de discussion publié sur X par @rileybrown_ai, présentant « 15 règles du vibe coding », a récolté plus de 10 000 mentions J’aime. La communauté tech s’est alors emballée, produisant mèmes, articles d’opinion et déclarations à chaud à toute vitesse. Un utilisateur de X, @IterIntellectus, a créé un mème sur le vibe coding montrant Rick Rubin avec un casque qui a récolté plus de 3 000 mentions J’aime, faisant de Rick Rubin le « visage » officieux du vibe coding — un choix judicieux, étant donné son approche légendaire de la production musicale, intuitive et fondée sur le feeling.

Le 13 février, Business Insider a publié « Le prochain acte de la Silicon Valley : diffuser le “vibe coding” dans le monde », marquant la première grande couverture médiatique du concept dans la presse tech. The New York Times a suivi le 27 février avec un article de Kevin Roose intitulé « Pas développeur ? Avec l’IA, une simple idée peut suffire ».

Le 24 février, Gitpod a publié « Le “vibe coding”, une révolution pour les créatifs optimistes », qualifiant le vibe coding de « symbole d’optimisme et de vague à venir » et indiquant avoir créé des autocollants « vibe coding » pour l’AI Engineering Summit.

L’indicateur le plus révélateur de son adoption par le grand public est peut-être le suivant : au 1er mars, Merriam-Webster avait ajouté « vibe coding » à son dictionnaire comme terme d’argot, le définissant comme « l’écriture de code informatique de manière plutôt négligée, avec l’aide de l’IA ». Du tweet au dictionnaire en moins d’un mois. Ce n’est pas seulement viral : c’est un phénomène culturel.

Garry Tan, PDG de Y Combinator, a indiqué que 25 % des startups de leur promotion hiver 2025 avaient des bases de code générées à plus de 95 % par l’IA. Il ne s’agissait donc pas simplement de gens qui s’amusaient : des entreprises entières étaient créées de cette façon.

Mais l’enthousiasme grandissait, tout comme les mises en garde. À la mi-février, un utilisateur de X, @Brycicle77, a remis en circulation une publication Reddit où un utilisateur déplorait que son « projet entièrement créé avec Cursor et Claude » soit devenu ingérable : « Plus de 30 fichiers Python, du code désorganisé, des boucles en double… Claude oublie sans cesse les imports. » La légende ironisait : « Le vibe coding et ses conséquences. »

Mais est-ce que le vibe coding, ça code vraiment ?

Pas en toute sécurité.

C’est là que le vibe se heurte à la réalité. Tandis que les développeurs acceptaient avec enthousiasme toutes les modifications et copiaient-collaient les messages d’erreur, de graves failles de sécurité s’accumulaient dans les bases de code en production.

Dans un cas notoire documenté par des chercheurs en sécurité, un développeur a utilisé l’IA pour créer la structure d’une application SaaS, sans savoir qu’il exposait sa clé API OpenAI dans le code côté client. Des pirates ont découvert la clé divulguée en quelques minutes, et le développeur « a dû négocier avec OpenAI pour qu’on lui remette sa facture ». Le vibe lui a coûté cher.

Plusieurs projets créés par vibe coding ont souffert de systèmes d’authentification défaillants. Une analyse a révélé que du code d’authentification généré par l’IA transmettait des clés API OpenAI en texte brut sur le réseau, visibles par n’importe quel utilisateur dans les outils de développement.

Un incident particulièrement inquiétant concernait un jeu Web généré par l’IA devenu viral, qui comportait une grave faille de script intersites (XSS) mettant des milliers d’utilisateurs en danger. Le développeur avait créé l’application par « vibe coding » avec ChatGPT, faisant confiance à ses résultats. Des chercheurs en sécurité mettent en garde contre les failles d’injection SQL, les vulnérabilités XSS et les fuites de données que peuvent introduire les copilotes d’IA si leur code est accepté sans vérification.

Un adepte du vibe coding a accepté du code recommandé par l’IA pour un module communautaire qui comportait un défaut de validation des entrées. Celui-ci a ensuite permis une attaque XSS persistante sur son site, rappelant les « vulnérabilités découvertes dans des extensions WordPress mal maintenues ».

Et le problème ne se limitait pas aux projets individuels. Le 18 mars 2025, une faille appelée « Rules File Backdoor » a été découverte dans GitHub Copilot et Cursor, deux des outils les plus populaires pour le vibe coding. Il s’agissait d’une vulnérabilité systémique dans l’infrastructure qui rendait cette pratique possible.

Le constat était clair : le vibe coding accélère considérablement le développement, mais aussi l’introduction de failles de sécurité. Une étude de Wiz a révélé qu’une organisation sur cinq utilisant des plateformes de vibe coding s’expose involontairement à des risques à cause de mauvaises configurations courantes.

Comme l’a fait remarquer un analyste en sécurité : « L’IA n’a pas détecté des contrôles d’autorisation critiques qu’un humain aurait repérés. » Il faisait référence à un système d’authentification qui fonctionnait lors des tests, mais ne vérifiait pas les rôles comme il aurait fallu, créant une faille exploitable permettant d’obtenir des privilèges d’administrateur.

Le problème fondamental ? Si vous ne comprenez pas le code que vous déployez, vous ne pouvez pas évaluer ses implications en matière de sécurité. Le vibe a beau être impeccable, le modèle de menace est inexistant.

Rendre le vibe coding accessible

Malgré les préoccupations de sécurité, une véritable révolution est en cours : la programmation devient accessible aux personnes qui en étaient auparavant exclues.

Depuis des années, on présente les plateformes « low-code » et « no-code » comme les grands outils de démocratisation du développement logiciel. Mais elles s’accompagnent souvent de limites : modèles rigides, fonctionnalités restreintes et plafond à ne pas dépasser dans ce qu’on peut créer. Le vibe coding, en revanche, offre quelque chose qui se rapproche de toute la puissance de la programmation, grâce au langage naturel.

Le codage vocal — c’est-à-dire l’utilisation de la voix plutôt que du clavier — a gagné du terrain parallèlement au vibe coding, porté par les progrès de la reconnaissance vocale, comme Whisper d’OpenAI. Cette convergence est particulièrement bénéfique pour l’accessibilité.

L’évolution des outils de codage vocal a été régulière tout au long de 2024. En mars 2024, Aqua Voice, une startup de Y Combinator, a témoigné de l’intérêt croissant pour le codage vocal en lançant un éditeur de texte piloté par la voix, qui annonçait « 7 fois moins d’erreurs que la dictée sur macOS ». Des outils comme Serenade, un moteur open source de conversion de la parole en code permettant d’écrire du code en langage naturel et de l’utiliser dans des éditeurs comme VS Code, ont considérablement gagné en maturité.

Lors de la conférence CSUN sur les technologies d’assistance 2025, une session consacrée à l’IA pour le codage a montré comment les outils de codage vocal permettent aux programmeurs en situation de handicap moteur de participer davantage au développement logiciel. Un intervenant a montré comment créer une application Web entièrement à la voix avec Serenade et GPT-4.

C’est extrêmement important. La programmation est depuis longtemps une activité très physique : des heures de frappe au clavier, un contrôle moteur précis et la maîtrise de raccourcis clavier complexes. Les interfaces vocales associées à l’assistance de l’IA ouvrent la voie aux personnes souffrant de troubles musculosquelettiques liés aux efforts répétitifs, de handicaps moteurs ou d’autres problèmes qui rendent le codage traditionnel difficile, voire impossible.

Mais l’accessibilité ne se limite pas aux capacités physiques. Elle concerne aussi l’accessibilité cognitive : pouvoir exprimer ce que l’on veut sans connaître la syntaxe, les bibliothèques ou les modèles. Pour quelqu’un qui connaît parfaitement son domaine, mais ne sait pas programmer, le vibe coding fait office de passerelle.

Pour les concepteurs de produits et les spécialistes de l’expérience utilisateur, le défi consiste à rendre ces interfaces sûres et efficaces pour les personnes non techniques. Power Platform Copilot de Microsoft permet de créer des applications en langage naturel, tandis que les administrateurs peuvent définir les actions autorisées pour Copilot, afin que les développeurs citoyens n’exposent pas des données sensibles sans le savoir.

Salesforce a lancé un copilote d’IA qui aide les administrateurs à créer des flux d’automatisation à l’aide d’instructions textuelles. Par exemple, un administrateur Salesforce peut saisir « Lorsqu’un prospect à fort potentiel est créé, attribuez-le à un commercial senior et envoyez une alerte par e-mail », et l’IA générera un flux mettant en œuvre cette fonctionnalité.

Ces plateformes s’attaquent à une question fondamentale : comment donner aux personnes non techniques les moyens de créer des logiciels tout en les protégeant des risques dont elles ignorent l’existence ?

Et cette fois, c’est personnel

Le vibe coding comporte une autre dimension qui mérite notre attention : la personnalisation.

Le développement logiciel traditionnel vise à créer des applications pour d’autres personnes, qu’il s’agisse de logiciels d’entreprise, d’applications grand public ou d’outils open source. Mais si le moyen le plus rapide de profiter d’une expérience personnalisée consistait à la créer soi-même, sur le moment, au fil d’une conversation ?

Karpathy a indiqué avoir créé un jeu de « Battleship » et une application de « lecteur de texte LLM » en environ une heure chacun, en donnant toutes les instructions à la voix. Ces créations n’étaient pas destinées à être distribuées : c’étaient des outils personnels, conçus pour son propre usage et adaptés à ses préférences.

Cela annonce un avenir où les logiciels ressembleront davantage à des plats cuisinés chez soi qu’à des repas préparés achetés tout faits. Au lieu de choisir parmi un menu d’applications existantes et d’essayer de les adapter à vos besoins grâce aux paramètres et aux options de personnalisation, vous pourriez simplement décrire ce que vous voulez et le faire créer pour vous.

On en voit les prémices avec la dernière génération de modèles d’IA. Gemini de Google expérimente l’utilisation de votre historique de recherche pour personnaliser ses réponses. Les modèles comprennent de mieux en mieux le contexte, se souviennent de ce qui vous intéresse et s’adaptent à vos besoins spécifiques.

Mais c’est là que les choses deviennent intéressantes, et un peu délicates : les LLM produisent parfois du code incorrect ou obsolète pour utiliser les API associées à ces modèles. Il ne s’agit pas pour les modèles de connaître leurs propres poids ou leur architecture : ce serait un autre type de problème. C’est plus simple et plus frustrant : des modèles comme ChatGPT sont entraînés sur de vastes jeux de données qui incluent la documentation jusqu’à une certaine date limite. Si leur API ou leur SDK change après cette date, le modèle ne le saura pas, sauf s’il est explicitement affiné par la suite.

J’en ai fait l’expérience. Lorsque j’ai essayé d’utiliser ChatGPT pour écrire du code destiné à l’API d’OpenAI, j’ai souvent obtenu une syntaxe obsolète ou des méthodes dépréciées. Sur le forum des développeurs d’OpenAI, en novembre 2024, un utilisateur s’est plaint : « GPT-4 produit systématiquement du code obsolète pour sa propre API en Node.js. Même quand je lui donne un lien vers la documentation la plus récente, il l’ignore et renvoie toujours le même vieux code. »

L’ironie est frappante : les entreprises d’IA se livrent une course pour rendre le codage accessible grâce à des interfaces conversationnelles, mais leurs propres modèles peinent à suivre l’évolution rapide de leurs propres API. Un utilisateur a fait remarquer que ChatGPT présentait encore des exemples utilisant une ancienne version de la bibliothèque openai pour Node, avec des fonctions de rappel ou d’anciens noms de paramètres, ou des points de terminaison dépréciés comme Completions.create au lieu du plus récent ChatCompletion.create.

Fait intéressant, Claude (créé par Anthropic) génère souvent mieux du code pour l’API d’OpenAI que ChatGPT lui-même. C’est peut-être parce que l’entraînement de Claude s’appuyait sur des sources plus variées et accordait moins de poids à l’ancienne documentation d’OpenAI.

Cela met en évidence un défi fondamental auquel les modèles sont confrontés lorsqu’ils tentent de personnaliser leurs réponses et de s’adapter : ils travaillent toujours à partir d’informations légèrement dépassées. Même si les dates limites de connaissance ont été considérablement repoussées (de plus de 18 mois à environ six à huit mois), ce décalage crée encore d’importantes zones d’ombre lors de la génération de code pour des frameworks et des API qui évoluent rapidement.

Au bout du compte, nous n’avons que les uns les autres

Prenons un peu de recul.

Lorsque ChatGPT est apparu fin 2022, personne ne croyait vraiment que l’IA pouvait écrire du code. L’idée de décrire un programme en anglais et d’obtenir du code fonctionnel semblait relever de la science-fiction. Aujourd’hui, moins de trois ans plus tard, nous débattons de la pertinence de créer des applications entières en « vibe coding », sans presque lire le code.

La vitesse de cette transformation est véritablement déconcertante. Il est facile de se concentrer sur les risques : les failles de sécurité, la dette technique, les cauchemars liés à la maintenabilité. Ces préoccupations sont réelles et sérieuses.

Mais il se passe aussi autre chose, qui mérite d’être célébrée : de plus en plus de personnes créent des choses.

Garry Tan, PDG de Y Combinator, a salué le vibe coding parce qu’il permet aux petites équipes d’en faire davantage. Selon lui, les outils de codage par IA permettent à « 10 ingénieurs d’accomplir le travail de 100 ». Des artistes, des designers et des experts métier qui n’auraient jamais appris la programmation traditionnelle créent désormais des logiciels fonctionnels. Des personnes en situation de handicap, jusque-là exclues du codage, trouvent de nouvelles voies pour s’y lancer.

Oui, certains de ces projets auront des bugs. Oui, certains présenteront des problèmes de sécurité. Oui, le code sera parfois un vrai fouillis. Mais vous savez quoi ? C’était aussi le cas au début du Web, des applications mobiles et de chaque nouvelle vague de développement logiciel. Nous avons appris. Nous avons élaboré de meilleures pratiques. Nous avons créé de meilleurs outils.

Le consensus qui se dessinait était que le vibe coding « donne l’impression d’avoir un code de triche… mais dès qu’on dépasse le stade des projets jouets, la réalité vous rattrape brutalement ». C’est sans doute une bonne chose. Le vibe coding a trouvé sa place : prototypage rapide, outils personnels, projets du week-end et exploration. Pour les systèmes de production qui traitent des données sensibles ou remplissent des fonctions critiques, il faut davantage de rigueur.

Les développeurs et les experts en sécurité définissent des bonnes pratiques pour le code généré par l’IA : traiter l’IA comme un développeur junior dont le code doit être examiné, exécuter des outils d’analyse statique et des linters, utiliser des outils comme le DCAIF de Snyk pour corriger automatiquement les vulnérabilités, et indiquer explicitement à l’IA les exigences de sécurité avant de commencer à coder.

Namanyay Goel a publié « Karpathy’s ‘Vibe Coding’ Movement Considered Harmful » le 27 mars, qualifiant la confiance aveugle dans la génération de code de « rupture fondamentale des responsabilités d’ingénierie ». Il a raison. Mais il a également reconnu que les copilotes d’IA sont des outils puissants lorsqu’ils sont utilisés de manière responsable.

L’avenir du développement logiciel reposera probablement sur une collaboration entre les développeurs humains et les outils d’IA. Le vibe coding représente une première étape, quelque peu chaotique, de cette collaboration. C’est désordonné. C’est passionnant. C’est parfois imprudent. Cela permet à des personnes de créer des choses qu’elles n’auraient pas pu créer auparavant.

Simon Willison a utilement précisé que « toute programmation assistée par l’IA n’est pas du vibe coding », en distinguant l’utilisation courante d’outils comme Copilot de l’approche extrême de Karpathy, qui consiste à « faire confiance à l’IA ». Il existe tout un éventail de possibilités et la plupart d’entre nous se situeront probablement quelque part entre les deux, en utilisant l’IA pour accélérer notre travail tout en gardant la maîtrise et en assurant une supervision.

La véritable leçon du vibe coding n’a peut-être rien à voir avec le code. Elle concerne l’expérimentation, la réduction des obstacles et la possibilité donnée à chacun d’essayer, même sans tout comprendre. C’est ainsi que l’on apprend à coder depuis toujours : en copiant des exemples, en tâtonnant, en cassant des choses et en les réparant.

L’IA ne fait qu’accélérer le cycle.

Alors, faites du vibe coding, mais gardez peut-être un œil ouvert. Lisez au moins une partie des différences. Lancez vos outils d’analyse de sécurité. Posez des questions. Apprenez. Et lorsque votre projet créé en vibe coding rencontrera inévitablement des problèmes, rappelez-vous : c’est en déboguant que l’on apprend vraiment.

Au bout du compte, nous n’avons que les uns les autres. Les humains et l’IA, conçue par et pour les humains, qui cherchent ensemble à comprendre tout cela.