Le vibecoding est devenu le mot d’ordre des studios d’un jour : décrire une application en langage naturel à un générateur comme Lovable, Bolt ou v0, laisser l’IA écrire le code, et itérer à coups de « rends-le plus rapide », « ajoute un panier », « corrige ce bug ». Sans écrire une seule ligne soi-même, on obtient en une soirée une interface qui tourne. La démonstration est séduisante. La question est ce qu’elle cache.
Ce que le vibecoding fait très bien
Il faut d’abord être juste : pour certains usages, l’approche est réellement remarquable. Un prototype à montrer à des investisseurs, une preuve de concept interne, une landing page temporaire pour tester une idée : sur ces terrains, décrire plutôt que coder change l’ordre de grandeur du coût et du délai. Les parcours simples — un formulaire, un tableau, un flux linéaire — sortent du générateur correctement assemblés, et l’itération par prompt fonctionne.
C’est précisément là que se joue le malentendu. Un prototype n’est pas un produit, et l’écart entre les deux ne se voit pas dans une démo de cinq minutes.
Là où le modèle montre ses limites
Le premier problème est l’opacité. Quand le code est écrit par un modèle que vous n’avez pas choisi, personne — pas même vous — ne sait exactement comment l’application fonctionne. Chaque prompt supplémentaire empile des couches correctives que l’IA applique sans vision d’ensemble : la dette technique ne disparaît pas, elle se déplace, invisible.
Le deuxième problème est la dérive en production. Gérer des milliers d’utilisateurs, sécuriser des paiements, respecter des contraintes d’accessibilité ou de performance sur mobile : ce sont des exigences que le vibecoding intègre mal, parce qu’elles ne se décrivent pas en une phrase — elles se conçoivent. Les sites générés gonflent vite, chargent des bibliothèques entières pour un bouton, et personne ne sait quoi retirer sans tout casser.
Le troisième est l’enfermement. Beaucoup de ces outils livrent un projet que seul leur environnement sait faire évoluer. Vous décrivez votre application ; vous ne la possédez pas.
Prototype ou production : tracer la frontière
La règle de bon sens qui émerge en 2026 tient en une phrase : vibecodez pour apprendre, pas pour construire. Dès qu’un outil doit durer, être maintenu, sécurisé et performant, la description cesse de suffire et l’architecture commence. C’est là que le retour aux fondamentaux — un code compris, léger, maîtrisé — cesse d’être un choix esthétique pour devenir un choix économique. Les acteurs qui n’ont jamais abandonné cette approche, comme Optibiz avec ses sites statiques sur mesure, ou une agence web classique pour les besoins complexes, traitent d’ailleurs de plus en plus souvent un cas de figure récurrent : le produit « vibe codé » qui fonctionne en démo, puis qui doit être repris de zéro pour tenir en vraie conditions.
L’IA reste un formidable accélérateur — mais dans les mains de celles et ceux qui savent ce qu’elle génère. Le prompt n’a pas remplacé l’ingénierie ; il l’a simplement rendu plus facile à ignorer, jusqu’au jour où la facture arrive.
