Le vibe coding, c'est quoi ? C'est créer un logiciel en décrivant ce que l'on veut en langage courant, puis laisser une intelligence artificielle écrire tout le code, sans le lire. Vous donnez la direction et vous jugez le résultat à ce qui s'affiche dans le navigateur. Ce guide explique d'où vient le terme, quels outils on utilise, où la méthode fonctionne et à quel moment elle devient un risque pour une application qui a de vrais clients.
Si votre application est déjà en ligne et que son code est sur GitHub, la dernière partie explique comment continuer à la modifier avec une relecture.
D'où vient le terme
C'est Andrej Karpathy, cofondateur d'OpenAI et ancien directeur de l'intelligence artificielle chez Tesla, qui l'a lancé dans un message sur X publié début février 2025. Il y décrivait une façon de programmer où l'on s'abandonne complètement aux vibes, au point d'oublier que le code existe. Deux détails de ce message sont souvent passés sous silence, alors que ce sont eux qui expliquent le mieux le terme : Karpathy acceptait toutes les modifications sans lire les différences, et il trouvait cela acceptable pour des projets de week-end, faits pour être jetés.
L'expression s'est répandue très vite. Merriam-Webster l'a recensée comme argot dès mars 2025, et le dictionnaire Collins en a fait son mot de l'année 2025 le 6 novembre, ce que Le Figaro a relayé le lendemain. En français, on garde le terme anglais au masculin : le vibe coding. Il n'existe pas encore d'équivalent officiel, ni dans les dictionnaires de référence ni du côté des instances de terminologie. Le lexique québécois de l'IA DataFranca propose « codage au ressenti », tandis que les formules du type « codage d'ambiance » viennent de pages d'entreprises traduites automatiquement.
Le vibe coding n'est pas la programmation assistée par l'IA
La distinction la plus utile vient du développeur Simon Willison, en mars 2025 : faire du vibe coding, c'est construire un logiciel avec un modèle de langage sans relire le code qu'il écrit. Un développeur qui utilise l'IA mais lit, teste et comprend chaque modification avant de l'enregistrer fait tout simplement du développement logiciel, avec un nouvel outil.
Un an plus tard, Karpathy lui-même a proposé un autre nom pour cette version professionnelle et relue : agentic engineering, où une personne pilote plusieurs agents d'IA et assure la supervision. Il n'a pas renié le terme d'origine ; il l'a laissé à ce qu'il désignait au départ, les prototypes et les essais.
L'enquête développeurs de Stack Overflow 2025 montre bien l'écart : environ 84 % des répondants utilisent ou comptent utiliser des outils d'IA, mais 72 % disent que le vibe coding ne fait pas partie de leur travail.
Comment ça marche en pratique
Vous ouvrez un outil, vous écrivez quelque chose comme « je veux une application de prise de rendez-vous pour mon salon de coiffure, avec une connexion et un tableau de bord pour l'équipe », et en quelques minutes vous obtenez une interface qui fonctionne et un lien à partager. Si quelque chose ne vous plaît pas, il suffit de le redemander.
| Outil | Offre gratuite | Offre payante la moins chère |
|---|---|---|
| Lovable | Oui | Pro, 25 USD par mois |
| Bolt | Oui | Pro, 25 USD par mois |
| Replit | Oui | Core, 20 USD par mois |
| v0 | Oui | Plus, 30 USD par utilisateur et par mois |
| Base44 | Oui | Starter, dès 16 USD par mois en paiement annuel |
| Cursor | Oui | Pro, 20 USD par mois |
| Claude Code | Non | Inclus dans Claude Pro, 20 USD par mois |
Prix en dollars relevés sur le site de chaque éditeur le 12 octobre 2026 ; la TVA peut s'y ajouter dans l'Union européenne. Les quatre premiers créent des applications de zéro sans montrer le code. Cursor et Claude Code s'adressent à ceux qui travaillent dans le code.
Là où ça fonctionne vraiment
- Tester une idée avant d'y investir. Un prototype qui fonctionne convainc mieux que n'importe quelle présentation.
- De petits outils internes, comme un tableau de bord pour votre équipe que personne d'extérieur ne verra.
- Des pages de campagne et des sites vitrines qui ne stockent pas de données sensibles.
Dans ces cas, la vitesse compte plus que tout et une erreur coûte peu.
Quand ça devient un problème
Tout change le jour où le premier vrai client s'inscrit et commence à payer.
Le premier risque, c'est la sécurité. En mai 2025, la vulnérabilité CVE-2025-48757 a été publiée au sujet d'applications créées avec Lovable : le chercheur a examiné 1 645 projets et en a trouvé 170 dont la base de données pouvait être lue ou modifiée de l'extérieur, faute de règles d'accès suffisantes. Lovable conteste qu'il s'agisse de sa faille, chaque client étant responsable de la protection des données de son application, et a depuis ajouté une analyse de sécurité. Le fond du problème reste le même : si personne ne lit le code, personne ne vérifie ces règles. Pour une application qui traite des données de clients européens, le RGPD s'ajoute : c'est l'éditeur de l'application qui en répond, pas l'outil qui a servi à la construire.
Le deuxième risque, c'est un agent qui a accès à la production. En juillet 2025, l'agent de Replit a supprimé la base de données de production de SaaStr en pleine expérience de vibe coding ; le PDG de Replit a jugé l'incident inacceptable, et l'entreprise sépare depuis les bases de développement et de production. Le même mois, la société de sécurité Wiz a découvert chez Base44 une faille de la plateforme elle-même qui permettait d'entrer dans des applications privées ; elle a été corrigée en moins de 24 heures.
Le troisième, c'est la maintenance. Une application dont personne ne comprend le code devient fragile : changer un prix peut casser une autre page que vous n'avez pas touchée, et vous ne l'apprenez que lorsqu'un client se plaint.
En profiter sans mettre votre application en danger
- Gardez le code sur GitHub, dans un compte de l'entreprise plutôt que dans celui d'une seule personne.
- Vérifiez vos clés. Si votre application utilise Supabase, l'outil gratuit de Refinar pour vérifier une clé Supabase indique en quelques secondes si la clé visible sur votre site est publique ou secrète.
- Séparez les données de test de celles de vos clients, pour ne jamais essayer une modification sur de vrais comptes.
- Faites relire par quelqu'un qui sait programmer toute modification qui touche à la connexion, aux paiements ou aux données clients avant de la publier.
Et après le lancement ?
Refinar est conçu pour ce moment-là. Il ouvre votre application à partir de son dépôt GitHub, telle qu'elle est, et la fait tourner dans le cloud. Vous décrivez la modification avec vos mots, ou vous montrez la partie de l'écran concernée, et un agent d'IA la réalise sous vos yeux sur une copie qui fonctionne, avant qu'elle n'atteigne vos clients. Le quatrième point de la liste ci-dessus fait partie de son fonctionnement : aucune modification touchant à la connexion, aux paiements ou aux données clients n'est publiée toute seule, elle part chez un développeur. Le reste, vous le publiez vous-même ou vous l'envoyez à votre équipe pour relecture (comment ça marche). Les offres commencent à 50 USD par mois (tarifs).
Si votre application est née du vibe coding et que vous voulez continuer à l'améliorer sans risque, essayez Refinar sur votre application.