Vibe coding

Le vibe coding est une façon de développer où l’on décrit en langage naturel ce que le logiciel doit faire, et où un modèle de langage écrit le code correspondant. Le développeur ne relit pas chaque ligne : il lance le résultat, regarde ce qui cloche, reformule sa demande et recommence. Andrej Karpathy a posé le terme en février 2025, dans un message où il décrivait une pratique consistant à « oublier que le code existe ». Le Collins Dictionary en a fait son mot de l’année en décembre 2025.

L’expression a beaucoup dérivé depuis. Aujourd’hui, à peu près tout usage de l’IA en développement se retrouve étiqueté « vibe coding », y compris des pratiques qui n’ont rien à voir avec la définition d’origine. Cette confusion n’est pas anodine : elle mélange une méthode d’exploration assumée et un mode de production industriel, alors que les deux n’ont ni les mêmes usages ni les mêmes risques.

Vibe coding ou développement assisté par IA : la nuance qui compte

La différence tient en une question : est-ce que quelqu’un lit le code produit ?

Dans le vibe coding au sens strict, non. On accepte la génération, on teste le comportement visible, et si l’application fait ce qu’on attend, on passe à la suite. L’IA est un exécutant dont on juge le travail au résultat, pas à la méthode. C’est rapide, et c’est parfaitement adapté à du code qu’on n’a pas l’intention de garder.

Dans le développement assisté par IA, oui. Le code généré passe par les mêmes filtres que le code écrit à la main : lecture, revue de code, tests, validation d’architecture. L’IA fait gagner du temps sur la frappe et sur le premier jet, mais la responsabilité du résultat reste humaine.

La plupart des équipes professionnelles pratiquent la seconde et disent faire la première, parce que le terme est devenu un raccourci commode. Savoir dans lequel des deux modes on se trouve à un instant donné est probablement la question la plus utile à se poser avant de générer quoi que ce soit.

Comment se déroule une session de vibe coding

Le cycle est court et se répète : décrire, générer, exécuter, corriger. On demande une page d’inscription, l’outil la produit, on la lance, ça plante, on colle le message d’erreur dans la conversation, l’IA corrige. Le développeur formule des ajustements en langage courant : regrouper les champs d’adresse, ajouter un message de confirmation, rendre le tableau triable par date.

Ce fonctionnement déplace la compétence critique. Décrire précisément un comportement attendu, ses cas limites et ses contraintes compte davantage que la maîtrise syntaxique d’un langage. C’est très proche du prompt engineering : la qualité de ce qui sort dépend directement de la précision de ce qu’on a demandé, et une demande floue produit un code plausible qui résout le mauvais problème.

Les agents IA ont rendu la boucle bien plus autonome. Ils lisent les fichiers existants, exécutent les commandes, lancent les tests et modifient plusieurs fichiers de façon cohérente. Des protocoles comme MCP leur donnent accès à la base de données, aux outils internes et à la documentation du projet, ce qui améliore nettement la pertinence du code par rapport aux premières générations d’assistants qui travaillaient à l’aveugle.

Les outils du vibe coding en 2026

L’écosystème se répartit en deux familles.

Les assistants intégrés à l’environnement de développement, comme Cursor, Claude Code, GitHub Copilot ou Windsurf, travaillent dans un projet existant. Ils voient l’arborescence, les dépendances et les conventions du code déjà écrit, ce qui les rend utilisables sur une base de code réelle.

Les générateurs d’applications, comme Lovable, Bolt, v0 ou Replit, partent d’une description ou d’une maquette et produisent une application entière : interface, composants, styles, parfois base de données et authentification. Ils sont redoutables pour montrer une idée à un client ou à un investisseur en quelques heures. Le code obtenu demande en revanche une reprise sérieuse avant d’accueillir de vrais utilisateurs.

Là où le vibe coding est vraiment rentable

Le calcul est simple : le vibe coding est rentable partout où le code n’a pas vocation à durer.

Un prototype jetable qui sert à trancher une discussion de conception, une maquette cliquable pour un entretien utilisateur, un script d’import de données qu’on lancera une fois, un outil interne utilisé par trois personnes, la structure de base d’un composant avant de la reprendre à la main : dans tous ces cas, la dette éventuelle n’existe pas, puisque le code sera jeté ou restera sans conséquence.

Pour un MVP, l’arbitrage est plus délicat. Le vibe coding permet de mettre un produit entre les mains des premiers utilisateurs bien plus tôt, ce qui est précieux. Mais un MVP qui trouve son public devient la première version du produit réel, et personne ne réécrit jamais un code qui fonctionne et qui génère du chiffre d’affaires. Autant décider dès le départ ce qui sera généré vite et ce qui sera construit pour durer.

Les limites que les démos ne montrent pas

La dette technique invisible

Le code produit fonctionne souvent du premier coup. Il n’est pas pour autant structuré. Un modèle résout le problème qu’on lui pose, sans anticiper la dixième fonctionnalité ni la reprise par un autre développeur dans six mois. Le résultat accumule des duplications, des dépendances inutiles et des choix de conception qui se paient plus tard.

Cette dette technique a une particularité désagréable : elle est invisible tant que le produit est petit. Elle se manifeste au moment où l’on veut modifier un comportement et où personne, dans l’équipe, ne sait précisément pourquoi le code existant fait ce qu’il fait. Chaque évolution devient alors un pari.

La sécurité

C’est le point le plus documenté, et le plus inquiétant. Les modèles ne vérifient pas spontanément la validation des entrées, la gestion des droits d’accès ou l’exposition de données sensibles. Une application peut faire exactement ce qu’on attend d’elle tout en laissant ses données lisibles par n’importe qui.

Les chiffres sont sans ambiguïté. La société française Escape.tech a analysé plus de 5 600 applications créées en vibe coding et y a relevé plus de 2 000 vulnérabilités, plus de 400 secrets exposés comme des clés d’API ou des jetons d’accès, et 175 cas de fuite de données personnelles. Pour tout produit qui reçoit des données utilisateurs, une relecture de sécurité du code généré n’est pas une précaution, c’est une obligation.

Le paradoxe de productivité

Le gain de vitesse ressenti n’est pas toujours un gain réel. Un essai contrôlé mené par l’organisation indépendante METR sur des développeurs open source expérimentés a montré un écart frappant : ils pensaient avoir gagné 20 % de temps grâce à l’IA, alors qu’ils avaient en réalité mis 19 % de plus à terminer leurs tâches. Nous avons détaillé ce mécanisme et ses conséquences dans notre analyse de l’impact de l’IA sur la productivité des développeurs.

L’explication tient au temps invisible : relire, corriger, comprendre pourquoi une correction en a cassé une autre. Sur une base de code maîtrisée et complexe, ce temps dépasse parfois celui qu’on aurait passé à écrire soi-même. Sur du code neuf et standard, l’accélération est bien réelle.

La logique métier complexe

Le vibe coding brille là où le résultat se vérifie d’un coup d’œil : interfaces, formulaires, visualisations, intégrations simples. Il devient risqué sur les calculs métier, la concurrence d’accès, les systèmes distribués ou tout ce qui touche à la facturation. Dans ces domaines, une erreur ne produit aucun symptôme visible, et on la découvre au moment où elle coûte cher.

Ce qu’il faut mettre autour pour que ça tienne

Un code généré vite a besoin de garde-fous proportionnels à la vitesse à laquelle il arrive. Trois pratiques changent tout.

Les tests automatisés d’abord, parce qu’ils sont la seule façon de vérifier qu’une génération n’a pas cassé ce qui marchait hier. Ils coûtent d’autant moins cher que l’IA sait très bien les écrire.

Une architecture logicielle décidée par un humain ensuite. Le découpage en modules, les frontières entre couches et le modèle de données doivent être posés avant de générer, sinon chaque prompt improvise sa propre structure et le projet devient un empilement incohérent.

Une revue systématique enfin, y compris et surtout sur le code qu’on n’a pas écrit. C’est le moment où quelqu’un reprend la responsabilité de ce qui part en production.

FAQ vibe coding

Le vibe coding va-t-il remplacer les développeurs ?

Il change leur travail plutôt qu’il ne le supprime. Concevoir une architecture, diagnostiquer un problème complexe, arbitrer entre sécurité, coût et performance : rien de tout cela ne se formule dans un prompt. Ce que le vibe coding absorbe, ce sont les tâches répétitives et prévisibles, et la part de l’écriture pure dans le métier diminue au profit de la conception et de la validation.

Peut-on lancer un vrai produit en vibe coding ?

Pour valider une idée auprès des premiers utilisateurs, oui, et c’est souvent la bonne décision. Pour un produit qui accueille des clients payants et leurs données, le code généré doit être audité, restructuré, testé et sécurisé avant la mise en production. Notre analyse détaillée sur le sujet, peut-on vraiment coder un SaaS avec l’IA, décrit précisément où passe la frontière.

Quelle est la différence entre vibe coding et no-code ?

Le no-code construit des applications via des interfaces visuelles, sans jamais produire de code source manipulable. Le vibe coding génère un vrai projet de code, modifiable, versionnable et déployable comme n’importe quel autre. La flexibilité est bien supérieure, la contrainte aussi : il faut des compétences techniques pour le maintenir, alors qu’une plateforme no-code assume elle-même cette partie.

Comment Polara Studio utilise le vibe coding

Nous nous en servons là où la vitesse d’itération compte plus que la propreté du code : prototypes, explorations d’interface, outils internes, premiers jets de composants standards. C’est un gain de temps considérable sur ces phases, et nous n’avons aucune raison de nous en priver.

En revanche, rien ne part en production sans relecture humaine, tests et audit de sécurité. Nous posons l’architecture avant de générer, pas après, et nous traitons le code produit par l’IA exactement comme celui d’un développeur junior talentueux mais pressé : utile, rapide, et à vérifier. C’est cette séparation entre ce qu’on génère et ce qu’on garantit qui permet de livrer vite sans transmettre au client un produit que personne ne pourra faire évoluer dans deux ans.