Le piège du vibe coding : 7 garde-fous pour shipper du code propre

"Vibe coding" est l'expression qu'on utilise pour décrire le fait de coder en pur mode conversationnel avec un LLM, sans plan, sans revue, sans test. Tu prompts, ça marche, tu mergese, tu passes. En 2025, c'est devenu un sport national chez les devs enthousiastes. En 2026, on en paye les premiers intérêts.

Le problème n'est pas l'outil. Claude Code, Cursor et bolt.new produisent du code honnête quand on les pilote bien. Le problème est l'absence de méthode. Un dev junior sans méthode produit un code gérable en relecture. Un LLM sans méthode produit 10× plus vite — et 10× plus de dette.

Voici les sept garde-fous qu'on enseigne pour transformer le vibe coding en coding sérieux.

Garde-fou 1 — Toujours partir d'un plan écrit

Avant d'ouvrir Claude Code ou Cursor sur une tâche non-triviale, écrivez trois lignes :

• Ce qu'on veut à la fin.
• Les fichiers qu'on va toucher.
• Les risques identifiés.

Trois lignes. 60 secondes. Cette étape divise par deux le nombre de fichiers que l'IA va toucher inutilement. Elle prévient aussi la dérive classique : commencer à corriger un bug et se retrouver à refactorer un module de 1 200 lignes parce que "l'IA a trouvé mieux".

Garde-fou 2 — Ne jamais merger une PR qu'on n'a pas lue

Ça paraît évident. C'est massivement violé. Les devs qui font confiance à leur IDE pour l'autocomplétion transfèrent cette confiance au LLM qui propose une PR entière. Grave erreur.

Lisez chaque ligne. Pas en diagonal. Chaque ligne. Si vous n'en avez pas le temps, la PR ne devrait pas exister.

Petit rappel : les LLMs hallucinent moins qu'en 2024, mais ils hallucinent encore. Ils inventent des fonctions qui n'existent pas, des imports qui ne sont pas dans votre codebase, des signatures qui ont changé dans la version de la lib que vous utilisez. 95% du code est juste. 5% est faux d'une manière subtile. Lisez.

Garde-fou 3 — Verrouiller le périmètre dans le prompt

Les trois mots magiques à ajouter dans tout prompt de modification : "Ne touche que".

Exemple :

Corrige le bug de tri dans components/table.tsx. Ne touche que ce fichier. Si tu identifies d'autres problèmes ailleurs, liste-les en fin de réponse sans les modifier.

Sans ce verrou, le LLM est biaisé à maximiser la "valeur apportée". Il va refactorer des fonctions connexes, ajouter des types, uniformiser un naming. C'est parfois bien. C'est souvent un enfer à reviewer, et c'est toujours une source de régression.

Garde-fou 4 — Tests avant, pas tests après

C'est le garde-fou le plus exigeant et le plus rentable.

Avant de demander à l'IA d'implémenter une nouvelle logique, demandez-lui d'écrire les tests. Lancez-les. Ils doivent échouer. Puis demandez l'implémentation. Lancez-les à nouveau. Ils doivent passer.

Cette discipline fait deux choses :

1. Elle force l'IA à comprendre ce qu'on attend avant de coder.
2. Elle vous donne un filet de sécurité automatique pour accepter ou rejeter la solution.

Les équipes qui adoptent ce pattern témoignent d'une baisse nette des régressions. On parle de divisions par 3 à 5 sur les incidents en prod attribuables à du code généré par IA.

Garde-fou 5 — Isoler la logique générée du reste

Quand vous générez une nouvelle feature, mettez-la dans son propre module, son propre dossier, son propre namespace. /lib/feature-x/. Pas éparpillée dans utils/, helpers/, misc/.

Raison : si dans 3 mois vous constatez que cette feature vieillit mal, vous pouvez la remplacer sans chirurgie. Le code généré à l'arrache est plus remplaçable que corrigible. Organisez votre codebase pour que le remplacement soit une option viable.

Garde-fou 6 — Observer avant d'optimiser

Un travers qu'on voit partout : l'IA propose spontanément des "optimisations". Pré-calcul, cache, denormalisation. Ces propositions sont souvent séduisantes. Elles sont presque toujours prématurées.

Règle simple : aucune optimisation sans donnée. Si vous n'avez pas un profiling qui montre un goulot d'étranglement, vous n'optimisez pas. Le code plus simple gagne. Il est plus lisible, plus debuggable, plus extensible. L'optimisation, quand elle est nécessaire, vient tard et locale.

Dans votre CLAUDE.md : "N'ajoute pas de cache, de mémoïsation ou de dédoublonnement sans justification factuelle. Le code simple passe par défaut."

Garde-fou 7 — Cadencer les dettes avec une review IA différée

Toutes les deux semaines, lancez une revue de votre codebase par l'IA. Pas pour corriger — pour lister. Un sous-agent dédié : "Parcours /app et /lib. Liste les fichiers qui montrent des signes de code généré non relu : imports inutilisés, variables nommées tmpX, commentaires vides, try/catch vides, fonctions de plus de 80 lignes sans tests."

La liste qui sort est précieuse. Elle vous donne votre roadmap de dette technique, priorisée. Vous n'avez plus à improviser.

Ce que ces sept garde-fous changent

Sur nos missions 2025-2026, les équipes qui adoptent ces sept règles maintiennent un code qui vieillit à peu près comme du code humain normal. Les équipes qui les ignorent voient leur qualité chuter de manière mesurable au bout de 3 à 6 mois. Le code s'empile, les abstractions se multiplient sans cohérence, la vélocité réelle (lead time moyen) commence à baisser alors que la vélocité apparente (PRs mergées) continue de grimper.

La leçon centrale : l'IA ne remplace pas l'ingénieur sénior. Elle multiplie l'ingénieur sénior et catastrophe l'ingénieur sans méthode. C'est peut-être la décennie la plus exigeante qu'on ait connue pour la discipline d'ingénierie, pas la plus relâchée.

Nos formations développeurs consacrent une demi-journée complète à ces garde-fous, sur des cas concrets tirés de votre codebase. C'est systématiquement la session que les participants citent comme la plus utile six mois plus tard.