Vibe coding distinguons les usages, repensons les organisations

En février 2025, un tweet devenu viral d'Andrej Karpathy introduit le terme de "vibe coding". Karpathy décrit une expérience où le code devient invisible, un dialogue naturel avec un LLM.

Avec le vibe coding, plus besoin de taper des lignes de code : on voit, on dit, ça se construit. Si cette définition initiale a popularisé le concept, elle ne distingue pas les deux grands types de vibe coding qui ont émergé depuis.

Deux visages, deux usages

Le premier, que l'on pourrait appeler le vibe coding technique, s'appuie sur des outils comme Cursor, Claude Code ou Codex. Il s'adresse à des profils techniques qui conservent une visibilité complète sur le code généré, peuvent reprendre la main à tout instant et calibrent eux-mêmes le niveau d'autonomie accordé à l'IA. L'IA agit comme un binôme de pair programming : extrêmement talentueux et rapide, mais capable de faire des choix erronés si on lui laisse les commandes sans surveillance.

Le second, le vibe coding produit, repose sur des plateformes comme Lovable ou Base44. Il s'adresse à des profils non techniques, fondateurs, product owners, équipes innovation, qui souhaitent transformer une idée en prototype fonctionnel sans passer par un cycle de développement traditionnel. La promesse : abaisser drastiquement la barrière d'entrée et concrétiser une vision en quelques clics.

Deux approches très différentes, parfois complémentaires selon les phases du projet. Mais dans les deux cas, sans une approche cohérente et holistique, les limites apparaissent rapidement.

Le design : la cohérence ne s'improvise pas

En mode vibe coding, le point de départ est souvent un simple prompt conversationnel. Mais ajuster précisément les écrans demande de multiples itérations. Sans design system formalisé en amont une logique de composants réutilisables et cohérents, le processus devient chronophage, imprécis, et produit des interfaces visuellement incohérentes avec l'identité de marque. Un retour aux outils traditionnels de design ou à minima à une logique de design system est nécessaire pour structurer cette étape.

Le prototype qui se transforme en produit

C'est le piège le plus insidieux. Le produit se construit au fil des injonctions parfois contradictoires, ajoutées sans vision globale de l'architecture. Résultat : un code fonctionnel en apparence, mais fragile, difficile à maintenir et coûteux à faire évoluer. Une application “100% vibe codée”, en quelques prompts, constitue souvent un bon prototype rarement un bon produit. Rien de nouveau en réalité, dans le monde d’avant, rare était les prototypes lancés en production.

Le refactoring, l'étape éternellement mal-aimée

Comme dans les modes de production traditionnels, des pauses sont nécessaires pour revoir le code, restructurer l'architecture et optimiser les traitements. Cette étape est souvent négligée dans l'ivresse du vibe coding. Elle peut pourtant être réalisée, elle aussi, avec un LLM. La dette technique existe même avec l’IA, la traiter au fil de l’eau reste une bonne pratique.

La sécurité : le borgne au pays des aveugles

Un LLM génère du code fonctionnel, pas nécessairement du code sécurisé. Sans relecture experte, qui elle aussi peut être assistée par l’IA, le vibe coding peut prendre des raccourcis. Les exemples d’applications vibe codées hackées se multiplient. Cloisonner les données, ne pas exposer les tokens et secrets, des principes qui restent valables.

Un organisation de la production à repenser

Les sociétés IA natives (Cursor, Anthropic...), les nouveaux rois de cette nouvelle ère, ont bien conscience de ces limites. Les IDE augmentés par l'IA s'intègrent avec des outils de design comme Figma, et développent des capacités de prototypage rapide (Google Stitch, Claude Design d'Anthropic). Les plateformes grand public (Lovable, Bolt,...), donnent désormais accès au code source généré et permettent de l'éditer. Anthropic lance des produits  dédiés à la sécurité. Etc.

Mais l'enjeu dépasse les outils : l'orchestration de bout en bout reste un problème humain. 

Dans des organisations et des processus de production pensés avec les outils d’hier comment adapter les modèles de production ? Comment faire le lien entre le design, le code et les autres couches IA ? Quelle répartition des rôles dans un monde où tout le monde peut générer du code ? Comment structurer les équipes pour en tirer le meilleur ?

Les premières adaptations sont mises en œuvre, souvent par des sociétés avec une forte culture technique. Les équipes se resserrent pour gagner en efficacité… une pizza c’est déjà trop.

Chez Doctolib, les PO poussent du code généré avec de l’IA, revue ensuite et validé par un lead développeur. 

Finalement, les solutions se trouvent peut-être dans les concepts d’hier revisités à l’aune de ces nouveaux outils. 

Une certitude, le sujet n’est plus uniquement technique. Les organisations se doivent d’évoluer radicalement sous peine de décrochage massif.