Vibe coding : définition, promesses et limites

Le vibe coding consiste à créer un logiciel en décrivant ce que l'on veut à une intelligence artificielle qui écrit le code, avec des outils comme Claude Code, Cursor, Lovable ou Bolt. On formule une demande en langage courant, l'IA produit le code, on regarde le résultat, on ajuste, et une application prend forme en quelques heures là où il fallait des semaines. Le terme a été popularisé début 2025 par le chercheur en IA Andrej Karpathy, et la pratique a largement dépassé le cercle des développeurs : des dirigeants et des équipes métier construisent aujourd'hui de vrais outils sans écrire une ligne de code.

Si vous avez construit quelque chose ainsi, vous avez bien fait de commencer : c'est la meilleure façon de valider une idée avant d'y engager un budget. Ce guide pose la définition, explique pourquoi la méthode fonctionne, puis détaille ce qu'on ne vous dit pas : pourquoi les projets bloquent autour de 80 % du chemin, ce que « fini » veut dire en production, et quand passer en mode ingénierie.

Comment ça marche : décrire, regarder, ajuster

Le vibe coding repose sur un LLM, le grand modèle de langage qui comprend et produit du texte, entraîné aussi sur d'immenses volumes de code. Vous décrivez la fonctionnalité attendue dans un prompt, les instructions en langage naturel qui cadrent ce que l'IA doit produire, et l'outil génère le code correspondant, l'exécute et vous montre le résultat. La boucle est immédiate : ce qui vous plaît reste, ce qui cloche se reformule. Le nom dit bien la posture : on avance à l'intuition, en jugeant le résultat à l'écran plutôt qu'en relisant le code.

Les outils se rangent en deux familles. Côté environnement de développement, Claude Code et Cursor s'adressent aux profils déjà proches du code : Claude Code fonctionne comme un agent IA, une IA qui enchaîne des actions pour accomplir une tâche de bout en bout, capable de lire vos fichiers, d'écrire le code, de lancer les tests et de corriger ses propres erreurs. Côté navigateur, Lovable et Bolt génèrent une application complète, interface, base de données et hébergement compris, sans rien installer : c'est la porte d'entrée des non-développeurs.

Pourquoi le vibe coding marche vraiment

Pour ce qu'il sait faire, le vibe coding est remarquablement efficace, et le balayer d'un revers de main serait une erreur. Trois usages en tirent une valeur immédiate.

• Prototyper en heures plutôt qu'en semaines. Une maquette cliquable qui manipule de vraies données vaut mieux que cent diapositives. Montrer à une équipe ou à un client un outil qui fonctionne, même imparfait, change la qualité de la discussion.
• Valider un besoin avant d'investir. Si personne n'utilise le prototype, vous venez d'économiser le coût d'un développement complet. S'il est adopté, vous savez exactement quoi construire : le prototype montre le besoin au lieu de le décrire.
• Outiller l'interne sans file d'attente. Un tableau de suivi, un calculateur métier, un formulaire branché sur un tableur : des besoins trop petits pour justifier un projet, parfaitement servis par un outil vibe codé qu'un humain garde à l'œil.

Cette étape n'est donc pas un détour, c'est le bon point de départ. Le paradoxe : le problème commence quand le prototype réussit, car on veut alors le mettre entre les mains de vrais utilisateurs.

Pourquoi ça bloque autour de 80 % du chemin

Le schéma se répète d'un projet à l'autre : la démo fonctionne, les premières fonctionnalités arrivent vite, puis chaque nouvelle demande casse quelque chose d'existant, les corrections tournent en rond et les derniers 20 % semblent inaccessibles. Ce n'est ni un défaut de l'utilisateur ni un défaut passager des outils. Les 80 premiers pour cent sont la partie descriptible du logiciel, celle qu'on peut formuler dans une conversation. Les 20 derniers sont sa partie structurelle, celle qui ne se voit pas dans une démo et qu'on ne pense donc jamais à demander. Quatre murs la composent.

La sécurité, invisible dans une démo

Une démo qui fonctionne ne prouve rien sur la sécurité, car la sécurité est précisément ce qui ne se voit pas à l'écran. Qui peut se connecter, qui peut lire les données des autres, ce qui se passe quand quelqu'un contourne l'interface pour interroger directement le serveur : autant de questions qu'on ne pose jamais à l'IA, qui produit donc un code où ces protections manquent ou restent superficielles. Le prototype expose alors des données réelles dès qu'on l'ouvre à de vrais utilisateurs. Et si votre application embarque elle-même de l'IA, les garde-fous décrits dans la sécurité des agents IA s'ajoutent à cette liste.

Les cas limites que personne n'a décrits

L'IA code ce qu'on lui décrit, et l'on décrit spontanément le chemin idéal : l'utilisateur remplit bien le formulaire, le fichier a la bonne taille, la connexion tient. La réalité produit tout le reste : un champ laissé vide, un fichier cent fois trop lourd, deux personnes qui modifient la même fiche au même moment, un import interrompu à mi-course. Aucun de ces cas n'ayant été décrit, aucun n'existe dans le code, et chacun surgit au pire moment. Une grande partie de l'ingénierie logicielle consiste justement à traiter ces cas avant qu'ils n'arrivent.

Le semi-automatique qui exige un humain à chaque exécution

Beaucoup d'outils vibe codés ne fonctionnent que lorsque leur créateur les lance et les surveille : il relance quand ça bloque, corrige à la main la donnée mal formée, tolère l'étape qui échoue une fois sur dix. Ce semi-automatique subi ne doit pas être confondu avec le human in the loop, la validation humaine volontairement conservée aux étapes sensibles d'un processus automatisé : dans un système conçu, l'humain intervient là où on l'a décidé, dans un prototype, il intervient partout où le code ne tient pas. Un logiciel n'est réellement automatique que s'il tourne quand personne ne regarde.

La maintenance quand l'outil ou l'API change

Un logiciel vit dans un environnement qui bouge : les modèles d'IA évoluent, les services tiers modifient leur API, l'interface par laquelle les logiciels communiquent directement entre eux, et les composants publient des correctifs de sécurité. Un code généré que personne n'a relu est un code que personne ne sait réparer : au premier changement d'environnement, la panne arrive sans qu'on sache ni où ni pourquoi. La maintenance n'est pas un service annexe du développement, c'est la condition pour que le logiciel existe encore dans six mois.

Ce que « fini » veut dire en production

Le mot « fini » change de sens quand un logiciel doit servir sans vous, et l'étalon le plus honnête n'est pas théorique : ce sont les exigences des systèmes réellement livrés. La plateforme conversationnelle de Labo M, fondée sur le RAG, la technique qui fait chercher les bons passages dans vos documents avant que l'IA ne rédige sa réponse, guide les clients dans un catalogue de 72 000 références et résout 90 % des requêtes sans intervention humaine. Ce qui la rend exploitable ne se voit dans aucune démo : un juge de pertinence anti-hallucination qui contrôle ce que l'IA avance, une traçabilité qui journalise chaque étape de chaque requête et permet de rejouer les décisions du système, et des prompts versionnés, modifiables sans redéploiement.

Même logique chez CS Events, dont la plateforme e-commerce de location événementielle est éditable par des agents IA : chaque modification de page est précédée d'un instantané sauvegardé, ce qui rend l'action réversible. L'instantané avant chaque changement chez CS Events, la journalisation de chaque requête et le juge de pertinence chez Labo M : aucune de ces briques n'apparaît à l'écran, et elles concentrent une part majeure du travail. C'est exactement la part que le vibe coding ne produit pas, parce que personne ne pense à la demander.

Continuer seul ou passer en mode ingénierie

Le bon critère n'est pas la taille du projet, c'est l'enjeu d'une défaillance. Continuez seul tant que l'outil reste personnel ou interne à faible enjeu : pas de données clients, un humain qui peut surveiller chaque exécution, une panne qui coûte au pire un peu de temps. Dans ce périmètre, le vibe coding est exactement le bon outil, et le consolider serait de l'ingénierie superflue.

Le projet change de nature dès qu'un des signaux suivants apparaît : des utilisateurs externes, des données personnelles ou sensibles, une exécution qui doit se faire sans surveillance, ou une activité qui commence à dépendre de la disponibilité de l'outil. À ce stade, la démarche est déroulée pas à pas dans le guide pour reprendre un projet vibe codé : ce qu'un développeur regarde en premier, ce qui se conserve du prototype et ce qui se consolide. Si votre construction est plutôt un scénario qui enchaîne des actions avec de l'IA dans un outil comme Zapier ou Make, le guide pour fiabiliser une automatisation IA traite ce cas précis. Et si ce que vous avez maquetté agit de lui-même sur vos logiciels, la méthode pour créer un agent IA détaille les règles de l'art.

Dans tous les cas, le prototype garde sa valeur : il a validé le besoin et cadré le périmètre, deux choses qu'aucun cahier des charges écrit ne fait aussi bien. Le travail qui reste consiste à consolider, pas à recommencer.

Vous avez un prototype vibe codé qui fonctionne et l'étape d'après vous semble floue ? Un audit IA fait exactement ce travail : évaluer ce qui existe, identifier ce qui manque pour la production et chiffrer l'écart, avant d'engager le moindre développement. Je suis Antoine Guerra, développeur IA freelance dans l'IA depuis 2018, j'utilise quotidiennement ces outils de développement assisté par IA et je livre des systèmes en production. Le premier échange est gratuit et vous repartez avec un devis clair sous 48 h. Si un terme reste flou, chaque définition est reprise dans le lexique en bas de page.