Vibe coding: quand explorer et quand spécifier

Définition utile (pas le hype)

Le vibe coding désigne un mode de développement assisté par LLM où tu décris l'intention en langage naturel, tu laisses le modèle générer le code, et tu te concentres sur le résultat visible (la démo, quelques tests manuels rapides), souvent sans relecture profonde du diff. Le terme a été popularisé en février 2025 par Andrej Karpathy, et il a vite glissé du « weekend throwaway » au discours produit.

Tout usage d'IA dans l'IDE n'est pas du vibe coding pour autant. L'ingénierie assistée, avec une spec, une revue, des tests et de l'ownership, reste du craft. Le vibe au sens strict, c'est accepter d'« oublier que le code existe » le temps d'itérer.

Le time-to-demo est excellent. Le produit durable, lui, n'arrive que si tu poses une frontière. Les critiques récurrentes portent sur l'accountability floue, la maintenabilité et la surface de sécurité: l'auth, les secrets, les dépendances inventées.

Où le vibe coding marche

Le vibe coding brille sur les terrains où l'échec ne coûte rien:

• Les spikes et les preuves de concept
• L'UI jetable et les scripts one-shot
• L'exploration d'une lib inconnue
• Le scaffolding, sur des branches throwaway avec une date de péremption

En solo ou en fondateur, il permet de valider une hypothèse en quelques heures. Pour apprendre, tu peux lire le code généré comme un tuteur, à condition de le comprendre avant de merger.

La règle tient en une phrase: l'échec doit être bon marché. Si un client paie, si des données perso ou un paiement passent, tu sors du mode vibe pur.

Où ça casse en production

La confusion entre la démo et le produit coûte cher: la dette silencieuse (les styles divergents, les tests absents, les secrets dans le chat) dépasse vite le gain initial.

Côté sécurité, on retrouve l'auth bricolée, les validations oubliées et les dépendances non auditées. Le code généré « skip » souvent les revues si l'équipe ne force pas une checklist.

Le dernier symptôme est humain: plus personne n'ose toucher le module. Rappelle-toi que plus de commits ne veut pas dire plus de valeur. On regarde les incidents et le temps de revue.

Quand le besoin n'est pas clair, arrête de prompter en boucle et spécifie. La clarté du besoin bat la créativité du prompt.

De la vibe aux specs et au RPI

Une spec minimale tient sur une page: l'objectif utilisateur, le hors-scope, les données interdites, des critères d'acceptation testables et les risques.

La boucle RPI (Research, Plan, Implement) structure le reste: tu cherches le contexte, tu planifies les fichiers et les tests, puis tu n'implémentes qu'après un plan validable. Sur les bases complexes, un RPI trop court ne suffit pas: on ajoute une phase de design et des handoffs entre les phases (voir le compact de Claude Code si la session s'allonge).

Les subagents servent à isoler la recherche: leur contexte ne pollue pas l'agent d'implémentation.

Le code jetable reste autorisé en branche isolée. Il est interdit sur main sans rewrite dès qu'un chemin critique est touché.

Planning vs acting

Agir sans plan accélère le bruit, et planifier sans shipper aussi. La règle d'équipe est simple: un plan court reviewable, puis l'action. Si l'action dérape, on re-planifie, on ne « vibe » pas plus fort.

Avant de merger, la checklist tient en cinq points:

• Une spec versionnée
• Des tests ou des scénarios
• Aucun secret dans le code ou le chat
• Une revue humaine sur l'auth, le paiement et les PII
• Une métrique de succès

Si vous voulez un atelier vibe coding / specs sur un repo réel, on peut cadrer en 20-40 minutes.