Vibe Coding vs. Ingénierie : où je trace la ligne

Andrej Karpathy a inventé le terme « vibe coding » en février 2025, décrivant un style de développement où le programmeur « s’abandonne entièrement aux vibes, embrasse les exponentielles, et oublie que le code existe ».¹

J’ai lu ça et j’ai pensé : c’est la moitié de mon flux de travail. L’autre moitié, c’est l’exact opposé.

TL;DR

Je développe avec Claude Code tous les jours. Une partie de ce travail est du pur vibe coding : décrire ce que je veux, accepter le résultat, passer à autre chose. L’autre partie passe par 86 hooks, un gardien de sécurité git, un garde-fou contre la récursion, et un système de contrôle qualité qui bloque les commits contenant des marqueurs d’IA ou de la voix passive. La frontière entre les deux n’est pas arbitraire. Les prototypes ont droit aux vibes. La production exige de l’ingénierie. Le plus difficile, c’est de savoir quand un prototype franchit cette ligne.

---

Mon flux de travail réel

Le côté vibes

Quand j’explore une idée, je fais du vibe coding sans complexe. Mon application iOS Ace Citizenship a commencé comme une expérience de week-end : « Construis un quiz à répétition espacée pour les questions civiques de l’USCIS. » Claude Code a généré les vues SwiftUI initiales, la banque de questions et l’algorithme de planification. Je n’ai pas lu chaque ligne. J’ai lancé l’app, testé manuellement, et itéré en décrivant ce qui n’allait pas.

Les composants interactifs de ce blog (l’arbre de décision RAG, le calculateur d’intérêts composés) ont démarré de la même façon. « Construis un arbre de décision qui guide les utilisateurs entre RAG et fine-tuning avec des transitions animées. » Accepter, tester, ajuster. L’impact d’un bug dans un widget de blog se limite à une seule page.

Le côté ingénierie

Mon architecture de hooks Claude Code est l’opposé du vibe coding. Chaque hook existe parce que quelque chose a mal tourné.

git-safety-guardian.sh existe parce que Claude a fait un force-push sur main lors d’une session précoce. Le hook intercepte désormais chaque commande git, effectue un pattern-matching sur une table de sévérité (CRITICAL : force push sur main ; HIGH : ajout de fichiers .env ; MEDIUM : –no-verify), et injecte un avertissement avant l’exécution.

recursion-guard.sh existe parce qu’un sous-agent a engendré une infinité d’enfants. Le hook suit la lignée des agents dans un fichier JSON, impose des limites de profondeur, et gère un modèle de budget de spawn qui empêche les chaînes d’agents incontrôlées tout en permettant le travail parallèle légitime.

blog-quality-gate.sh existe parce que la prose générée par l’IA a le son de la prose générée par l’IA. Le hook bloque les commits vers content/blog/ s’il détecte des tirets cadratins, de la voix passive, ou des mots comme « delve », « crucial » ou « landscape ».

Aucun de ces hooks n’a été créé en vibe coding. Chacun a été écrit ligne par ligne, testé sur des scénarios de défaillance réels, et relu avant déploiement. Les 86 hooks représentent collectivement la frontière entre les vibes et l’ingénierie.

---

Où la ligne se situe réellement

Vibes : prototypes jetables

Je fais du vibe coding pour tout ce que je pourrais jeter. Un script de transformation de données que j’exécuterai une seule fois. Un outil CLI pour usage personnel. Une preuve de concept pour vérifier si une API fait ce que la documentation prétend. Le coût d’un bug dans du code jetable, c’est mon propre temps, et le gain de vitesse l’emporte sur le risque de débogage.

Vibes : exploration créative

Quand j’explore une direction de design, le vibe coding me permet de tester des patterns d’interaction plus vite que Figma. « Construis une modale de recherche avec navigation clavier, surlignage des résultats et activation par Cmd+K » produit un prototype fonctionnel en quelques minutes. J’évalue le ressenti, pas le code.²

Ingénierie : tout ce qui touche les utilisateurs

Dès que le code sert quelqu’un d’autre que moi, il franchit la ligne. Mon blog passe par un linter à 12 modules qui vérifie les citations, la hiérarchie des titres, le niveau de lisibilité, le texte alternatif des images, la densité de liens internes et la profondeur du contenu. Le linter a 77 tests. Le blog a 29 articles. Le linter a plus de tests que le blog n’a de contenu.

Ingénierie : tout ce qui persiste

Les schémas de base de données, les contrats d’API, les configurations de hooks et les manifestes de déploiement reçoivent un traitement d’ingénierie complet. Ces décisions se composent. Un schéma conçu en session de vibes devient un cauchemar de migration quand trois ans de données s’accumulent dessus.³

Ingénierie : tout ce qui touche à la sécurité

Le code généré par l’IA reflète la posture de sécurité de ses données d’entraînement, qui incluent des tutoriels et des réponses Stack Overflow omettant régulièrement l’authentification, la validation des entrées et la gestion des erreurs par souci de brièveté.⁴ Mes hooks interceptent une partie de ces problèmes (le gardien de sécurité git signale les ajouts de .env, les fichiers de credentials et les force pushes), mais le code critique pour la sécurité fait l’objet d’une revue manuelle dans tous les cas.

---

Le problème du déficit de compréhension

Le pattern le plus dangereux du vibe coding, ce n’est pas le mauvais code. C’est le code qui fonctionne jusqu’à ce qu’il ne fonctionne plus.

J’ai généré une couche de cache pour mon système de traduction i18n. Elle fonctionnait parfaitement pour le contenu en anglais. Quand j’ai ajouté le coréen et le chinois traditionnel, la génération des clés de cache produisait silencieusement des collisions pour certains points de code Unicode. Le débogage a pris quatre heures parce que je n’avais jamais lu la fonction de génération des clés. Le code était correct pour l’ASCII, ce que les données d’entraînement privilégiaient.⁵

La leçon : les systèmes codés en mode vibes échouent aux frontières que les données d’entraînement sous-représentent. Si vos utilisateurs opèrent à ces frontières (écritures non latines, forte concurrence, conditions réseau inhabituelles), les implémentations en vibe coding comportent un risque caché.

---

Le contrôle de revue

Chaque morceau de code destiné à la production dans mon système passe par un contrôle de revue, que je l’aie écrit ou que Claude Code l’ait fait :

1. Lire chaque ligne. Le code généré est une pull request d’un contributeur non vérifié. Relisez en conséquence.
2. Vérifier la gestion des erreurs. Vérifiez que les chemins d’erreur reflètent les exigences métier, pas des patterns try-catch génériques.
3. Auditer les dépendances. L’IA résout chaque prompt de manière isolée, important la bibliothèque qui résout la requête immédiate. Après 50 prompts, vous pourriez avoir trois bibliothèques de dates et deux clients HTTP.
4. Ajouter des tests. Le code généré couvre rarement les cas limites spécifiques à votre domaine.
5. Vérifier la sécurité. Lancez une analyse statique. Vérifiez l’authentification, les autorisations et la validation des entrées.⁶

Le contrôle de revue n’est pas optionnel. C’est la différence entre utiliser l’IA comme multiplicateur de force et utiliser l’IA comme béquille.

---

La scission de l’industrie

L’ingénierie logicielle se scinde en deux niveaux. Le premier utilise l’IA comme multiplicateur de force : générer du code répétitif, explorer des espaces de solutions et accélérer l’implémentation de patterns bien compris tout en maintenant la compréhension et les standards de qualité. Le second génère des applications entières sans comprendre le résultat, troquant la vélocité à court terme contre la fragilité à long terme.⁷

Cette scission reflète les débuts du développement web. Les constructeurs de templates comme Squarespace ont démocratisé la publication web et produit des millions de sites fonctionnels. Le développement web professionnel persiste parce que les systèmes en production exigent une qualité, une sécurité et une maintenabilité que les templates ne peuvent fournir.

J’opère délibérément dans les deux niveaux. Mon système de hooks et mes contrôles qualité existent précisément pour détecter le moment où un travail de niveau deux doit être élevé aux standards du niveau un. Les 86 hooks ne sont pas de la bureaucratie. Ils sont le système immunitaire qui me permet de faire du vibe coding librement tout en empêchant le travail codé en mode vibes d’atteindre la production sans revue.

---

Points clés à retenir

Pour les ingénieurs qui utilisent l’IA au quotidien : - Tracez une ligne explicite entre exploration et production ; faites du vibe coding librement pour le travail jetable, mais imposez des contrôles de revue avant que quoi que ce soit ne touche les utilisateurs ou ne persiste - Construisez des garde-fous automatisés (hooks, linters, contrôles qualité) au lieu de compter uniquement sur la discipline ; la discipline faiblit à 2 h du matin, les hooks non

Pour les responsables techniques : - Établissez des frontières claires entre le code de qualité prototype et le code de qualité production ; les prototypes en vibe coding qui se glissent en production créent une nouvelle catégorie de dette technique - Évaluez la productivité par les résultats (fonctionnalités livrées, bugs par fonctionnalité, satisfaction utilisateur) plutôt que par les métriques de vélocité ; le vibe coding gonfle le nombre de lignes sans améliorer proportionnellement les résultats

---

Références