Vibe coding, ce que ça vaut vraiment et ce que ça ne remplace pas

Le terme a été posé en février 2025 par Andrej Karpathy, cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla. L’idée tient en une phrase. On décrit ce qu’on veut, l’IA écrit le code, et on ne relit pas.

Le dictionnaire Collins en a fait son mot de l’année 2025. Ce qui en dit long sur la vitesse à laquelle la pratique s’est répandue.

La ligne de partage est nette, et beaucoup la brouillent. Un développeur qui utilise une IA mais qui relit, corrige et arbitre ne fait pas du vibe coding. Il fait son métier avec un outil de plus. Le vibe coding commence exactement là où on cesse de regarder le code.

Cette distinction n’est pas un détail de vocabulaire. Elle décide de qui répond des dégâts.

Sous un seul mot se cachent des pratiques qui n’ont pas le même coût d’entrée ni les mêmes limites.

• Demander à un assistant conversationnel. Vous décrivez un petit programme, il vous le rend. Vous ne savez ni dans quel langage ni comment. C’est le niveau d’entrée, et il suffit pour un usage personnel.
• Utiliser un outil qui contient de l’IA. Un créateur de site en ligne qui vous propose de réécrire un texte ou de générer une image. Vous gardez la main sur le résultat, pas sur le code.
• Les plateformes de génération d’application. Vous décrivez, l’outil produit une application complète, hébergée chez lui. Vous voyez le code, vous pouvez le corriger. C’est ce que la plupart des gens appellent vibe coding.
• L’IA dans votre éditeur. Le rapport s’inverse. Vous travaillez dans votre environnement, sur vos fichiers, et l’IA vous assiste. Il faut déjà savoir organiser un projet.
• L’IA en ligne de commande, sur votre machine. Vous pilotez un ou plusieurs assistants sur vos propres dossiers. C’est le niveau le plus puissant et le plus exigeant.

Rien n’oblige à gravir tous les étages. Mais il faut savoir à quel étage on se trouve, parce que les garanties ne sont pas les mêmes.

Il serait malhonnête de ne parler que des risques. La rupture est réelle.

Le prototype ne coûte plus rien. Ce qui demandait une journée se monte en quelques heures. Une idée peut être testée le soir même, et abandonnée le lendemain sans regret.

Les outils sur mesure deviennent possibles. Une application qui n’intéresse qu’une seule personne n’a jamais été rentable à développer. Personne ne passera des mois sur un besoin unique. Maintenant, cette personne peut la faire elle-même, mal codée peut-être, mais utile.

Le champ des créateurs s’élargit. Des gens qui n’auraient jamais écrit une ligne de code donnent forme à leurs idées. Sur le nombre, il y aura des choses remarquables qui n’auraient jamais existé.

C’est un vrai gain, et il ne faut pas le minimiser sous prétexte que le résultat est imparfait.

Le récit qui circule le plus est celui d’un créateur qui a lancé un service payant entièrement généré par IA, en expliquant publiquement qu’il n’avait pas écrit une ligne. En quelques jours, son service subissait des intrusions, ses quotas explosaient, des inconnus contournaient l’inscription. Il l’a retiré, en reconnaissant qu’il n’aurait pas dû mettre en ligne un produit qu’il ne pouvait pas sécuriser.

Ce n’est pas une histoire d’incompétence, c’est une histoire de responsabilité. Le jour où quelqu’un paie, vous manipulez une adresse, un moyen de paiement, parfois bien plus. La barre n’est plus la même.

Les chiffres qui circulent dans le métier vont dans le même sens. Environ 41% du code produit aujourd’hui serait généré par IA, et 45% de ce code porterait une faille de sécurité connue. Un accélérateur de start-ups réputé a indiqué qu’un quart de sa dernière promotion travaillait sur des bases de code générées à 95% par IA.

⚠ Ces chiffres viennent du secteur et méritent d’être vérifiés à la source avant d’être cités ailleurs. Ils donnent un ordre de grandeur, pas une mesure.

Elle est si constante qu’elle mérite d’être montrée. Vous demandez une fonction qui récupère les informations d’un utilisateur. L’IA écrit ceci.

// ⚠ NE JAMAIS METTRE ÇA EN LIGNE
export async function getUser(userId: string) {
  // L'identifiant arrive de l'extérieur, et personne ne vérifie
  // qui appelle. N'importe qui peut demander n'importe quel compte.
  return await db.user.findUnique({ where: { id: userId } });
}

Le code fonctionne. La démonstration passe. Et n’importe qui peut lire les données de n’importe qui en changeant un numéro dans la requête.

La version correcte ne prend pas l’identifiant en paramètre. Elle le déduit de la session, c’est-à-dire de la personne réellement connectée.

export async function getUser() {
  // L'identité vient de la session vérifiée par le serveur,
  // jamais de ce que le visiteur envoie.
  const session = await auth();
  if (!session?.user?.id) throw new Error('Non connecté.');

  return await db.user.findUnique({ where: { id: session.user.id } });
}

L’IA n’a pas commis d’erreur. Elle a écrit ce qu’on lui a demandé. Personne ne lui a dit de vérifier qui appelle, alors elle ne l’a pas fait. C’est toute la différence entre un code qui marche et un code qui tient.

Un développeur expérimenté a fait l’expérience de reconstruire son propre projet 2 fois, une fois à la main et une fois sans jamais toucher au code. Son constat est utile parce qu’il est mesuré.

Au démarrage, l’écart est énorme. Ce qui lui prenait des heures était produit en quelques minutes. Sur cette phase, il n’y a pas de match.

Puis la courbe s’inverse. Plus le projet grandit, plus il redevenait le plus rapide des 2. Non pas parce que l’IA ralentissait, mais parce qu’elle ne faisait pas exactement ce qu’il voulait, et qu’expliquer prenait plus de temps que faire.

La cause technique porte un nom, la fenêtre de contexte. C’est la quantité de texte que le modèle garde en tête. Tant que le projet est petit, il le voit en entier. Quand il grossit, il en oublie des morceaux pour faire de la place, et se met à casser ce qui marchait la veille.

C’est précisément le moment où chaque correction en crée une autre, et où beaucoup abandonnent.

Les dépendances inventées ou piégées. Une IA cite parfois une bibliothèque qui n’existe pas. Plus gênant, des acteurs malveillants publient de vrais paquets dont le nom ressemble à s’y méprendre à un paquet connu, en pariant sur cette confusion. Un projet peut ainsi embarquer du code hostile sans que personne ne l’ait voulu.

L’assistant vous donne toujours raison. Ces modèles sont entraînés à satisfaire. Proposez-leur une mauvaise idée, ils la trouveront excellente et la mettront en œuvre avec enthousiasme.

Sur un projet long, l’effet est sournois. On finit par ne plus jamais être contredit, et on prend la fluidité pour de la justesse. Certains créent volontairement un second assistant chargé de les contredire, avec pour seule consigne de chercher l’angle mort et de ne jamais complimenter.

C’est une bonne pratique, et elle dit quelque chose d’important. Le vrai risque n’est pas que l’IA se trompe, c’est qu’elle ne vous arrête jamais.

Il existe une manière sérieuse de pratiquer, et elle tient en quelques règles.

Partez d’une base existante. C’est le meilleur raccourci pour qui ne code pas. Un socle de projet déjà construit apporte une authentification, une organisation de fichiers et des protections que l’IA n’inventera pas seule. Vous ne partez plus d’une page blanche, vous partez d’une maison aux fondations posées.

Apprenez le vocabulaire, pas la syntaxe. Vous n’avez pas besoin d’écrire une boucle. Vous avez besoin de savoir ce qu’est une base de données, la différence entre ce qui tourne chez le visiteur et ce qui tourne sur le serveur, et ce qu’est une clé d’accès. Sans ce vocabulaire, vous ne pouvez pas juger une réponse.

Avancez par petits morceaux. Une demande énorme donne un résultat que vous ne pourrez ni vérifier ni corriger. Une demande à la fois, testée, puis la suivante.

Sauvegardez souvent. Enregistrez chaque état qui fonctionne, même imparfait. Quand l’IA part en vrille, et elle partira en vrille, vous revenez au dernier point stable au lieu de tout reprendre.

Faites le ménage. Le vibe coding produit énormément de code jamais utilisé, écrit dans l’élan. Il rend le projet illisible et chaque correction plus difficile.

Nous ne sommes ni du camp qui prétend que le métier de développeur est terminé, ni de celui qui refuse l’outil par principe.

Ce qui se transpose depuis notre métier. La rigueur, les tests, la relecture, le suivi des versions, l’habitude de se demander ce qui peut mal tourner. Rien de tout cela ne devient inutile, tout devient plus nécessaire.

Ce que nous ne déléguons pas. La sécurité, le traitement des données personnelles et la mise en ligne. Ce sont les 3 endroits où une erreur coûte de l’argent réel, et où l’IA écrit un code qui marche sans être juste.

Ce qu’un client peut nous demander sans hésiter. Reprendre un prototype généré par IA et le mettre au niveau. C’est devenu une demande courante, et c’est un bon point de départ, parce que l’idée est déjà validée par l’usage.

Le détail le plus parlant de toute cette histoire, c’est le créateur français dont la plateforme a été attaquée après qu’il a parlé publiquement de vibe coding. La seule faille trouvée se trouvait dans du code qu’il avait écrit lui-même, à la main, 3 ans plus tôt. Tout ce qui avait été généré par IA a tenu.

La conclusion n’est donc pas que l’IA code mal. C’est que la démocratisation de la création est aussi une démocratisation de la responsabilité. Si vous voulez construire quelque chose qui dure, parlons-en, c’est exactement notre métier de développement sur mesure.