Le vibe coding, c’est du vrai développement ?

C’est une façon de produire du logiciel, avec ses forces et ses angles morts. La question utile n’est pas sa noblesse mais son domaine de validité : excellent pour démarrer, fragile pour durer.

Est-ce que je dois apprendre à coder pour m’en servir ?

Non pour démarrer, et c’est tout l’intérêt. Mais plus le projet grandit, plus il faut savoir décrire précisément ce qu’on veut — ce qui est une compétence distincte, et qui s’apprend sans écrire une ligne.

D’où vient le terme exactement ?

D’un message public du chercheur Andrej Karpathy, début février 2025, décrivant sa façon de construire en se laissant porter par l’outil. L’expression a été reprise en quelques semaines partout.

Ça marche pour un site professionnel ?

Pour le construire, souvent oui. Pour le maintenir pendant deux ans, cela dépend entièrement de ce que tu as mis en place autour — sauvegardes, consignes écrites, vérifications.

Vibe coding : ce que c’est, et où ça casse

Tu décris ce que tu veux, l’IA le fabrique, et ça marche. C’est grisant. Puis un jour ça casse, tu ouvres le projet, et tu ne comprends rien à ce qui a été écrit pour toi. Tu ne peux ni réparer, ni expliquer, ni même demander de l’aide correctement.

Le vibe coding consiste à décrire ce qu’on veut en langage courant et à laisser l’IA écrire le code, sans le relire. Le terme a été lancé début 2025 par le chercheur Andrej Karpathy. La méthode fonctionne remarquablement bien jusqu’à trois moments précis où elle se retourne.

D’où vient le mot

Le terme est né début février 2025, dans un message public du chercheur Andrej Karpathy, ancien responsable de l’intelligence artificielle chez Tesla.

Il y décrivait une façon de travailler qu’il pratiquait lui-même : parler à l’outil, regarder ce qui sort, relancer, copier-coller, et oublier que le code existe. Se laisser porter, littéralement.

Le message a été vu des millions de fois en quelques jours et l’expression s’est répandue partout. Elle décrit aujourd’hui une pratique très concrète : décrire ce qu’on veut en français courant, laisser la machine produire le code, et juger le résultat à ce qu’il fait plutôt qu’à ce qu’il contient.

Pourquoi ça marche si bien au début

Il faut le dire franchement, parce que les critiques du procédé l’oublient souvent : ça fonctionne réellement.

Une personne qui n’a jamais écrit une ligne de code obtient en une soirée quelque chose qui s’affiche, qui réagit, qui ressemble à ce qu’elle avait en tête. C’était impossible il y a trois ans. Ce n’est pas une illusion, c’est un vrai changement.

Et pour une grande partie des projets — une page de présentation, un formulaire, un outil interne, un prototype à montrer — cette façon de faire suffit largement. Inutile de se compliquer la vie.

Le problème n’est pas la méthode. C’est de croire qu’elle couvre tout.

Premier moment où ça casse : quand tu ne peux plus décrire ce que tu veux

Tant que la demande tient en une phrase — « ajoute un bouton qui envoie le formulaire » — tout va bien.

Le mur arrive quand la demande devient une intention à plusieurs étages : « quand quelqu’un s’inscrit, vérifie que l’adresse n’existe pas déjà, envoie un message de confirmation, et si l’envoi échoue, garde quand même l’inscription ».

Là, l’écart entre ce que tu voulais et ce que tu as demandé devient énorme, et il ne se voit pas. Le résultat marche à l’écran. Il fera autre chose que prévu le jour où un cas particulier se présente.

Ce n’est pas un problème de code. C’est un problème de formulation — et c’est pour ça que la compétence qui compte le plus n’est pas de savoir coder, mais de savoir décrire.

Deuxième moment : quand tu ne peux plus vérifier

Le vibe coding repose sur un principe simple : on juge au résultat visible.

Ce principe tient tant que tout ce qui compte est visible. Il lâche dès qu’une partie du travail ne se voit pas : une sauvegarde qui ne se déclenche pas, une donnée mal enregistrée, un cas d’erreur jamais testé, une clé de sécurité inscrite au mauvais endroit.

Rien de tout cela ne s’affiche à l’écran. Le site a l’air parfait. Le problème existe déjà et attend son moment.

C’est la raison pour laquelle « ça marche » n’est pas la même chose que « c’est bon ». La différence se paie plus tard, et elle se paie cher quand le site casse.

Troisième moment : quand la conversation devient plus grosse que ta mémoire

Celui-là surprend tout le monde, parce qu’il n’a rien à voir avec la difficulté du projet.

Une conversation avec une IA a une taille limite. Au-delà, le plus ancien sort du champ. Une décision prise il y a deux heures — « on ne touche pas à cette partie » — cesse d’être appliquée sans que rien ne le signale.

Or le vibe coding produit exactement ce genre de conversation : longue, continue, où tout se décide au fil de l’eau et où rien n’est écrit ailleurs. Plus tu avances, plus le début s’efface.

C’est pour ça que le même outil, sur le même projet, semble « devenir bête » en fin de journée. Il ne devient pas bête : il ne voit plus le début.

Ce qu’il faut en retenir

Le vibe coding n’est pas une mauvaise méthode. C’est une méthode sans mémoire et sans filet — ce qui est parfaitement adapté à un prototype, et parfaitement inadapté à quelque chose qui doit durer.

La bonne question n’est donc jamais « est-ce que je fais du vibe coding ou du vrai développement ». Elle est : est-ce que ce que je construis a besoin de survivre à la conversation qui l’a produit ?

Si la réponse est non, continue comme ça, c’est très bien. Si la réponse est oui, il te manque trois choses — de quoi écrire ce qui doit survivre, de quoi vérifier ce qui ne se voit pas, et de quoi revenir en arrière. Aucune des trois ne demande de savoir coder.