Maîtriser Claude Code Partie 10 : La philosophie du Vibe Coding

Tu as appris les outils. Commandes, skills, subagents, serveurs MCP, automatisation headless — tu sais comment Claude Code fonctionne. Mais connaître les outils, ce n'est pas la même chose que d'être en symbiose avec eux.

Ce dernier chapitre parle d'état d'esprit. La philosophie qui transforme les utilisateurs compétents de Claude Code en développeurs qui avancent à une vitesse complètement différente.

Qu'est-ce que le Vibe Coding ?

Le terme vient du tweet viral d'Andrej Karpathy en février 2025 :

« Il y a un nouveau type de coding que j'appelle "vibe coding", où tu te laisses complètement porter par l'ambiance, tu embrasses les exponentielles, et tu oublies que le code existe. C'est possible parce que les LLMs deviennent trop bons. »

Il décrivait son workflow : accepter tous les changements sans lire les diffs, copier-coller les messages d'erreur sans commentaire, demander à l'IA des trucs triviaux comme « diminue le padding de la sidebar de moitié » parce qu'il a la flemme de les trouver.

Puis il a ajouté la nuance cruciale : « Ce n'est pas si mal pour des projets de week-end jetables, mais c'est quand même assez amusant. »

Cette nuance compte. Le vibe coding n'est pas une approche universelle — c'est un mode de travail approprié pour des contextes spécifiques.

Le spectre du développement assisté par IA

Simon Willison l'a bien formulé : « Tout le développement assisté par IA n'est pas du vibe coding. »

Il y a un spectre :

Vibe Coding pur — Accepte tout, ne lis pas les diffs, copie-colle les erreurs, laisse l'IA se débrouiller. Super pour les hacks de week-end et les prototypes jetables.

Développement guidé par IA — Tu diriges, Claude implémente, tu révises. L'approche qu'on a couverte tout au long de cette série.

Ingénierie augmentée par IA — Discipline d'ingénierie traditionnelle avec accélération IA. Documents de conception, revues de code, tests, audit de sécurité — tout se passe encore, juste plus vite.

La plupart du travail professionnel se situe au milieu. Le vibe coding pur d'un côté est risqué pour tout ce qui va au-delà de l'expérimentation. Le coding 100% manuel de l'autre côté, c'est laisser de la vitesse sur la table.

La compétence, c'est de savoir où sur le spectre tu devrais être pour chaque tâche donnée.

Quand vibrer

Le vibe coding fonctionne quand :

• C'est un prototype — Tu explores une idée, tu ne livres pas aux utilisateurs
• Tu peux le jeter — Si ça ne marche pas, tu repars de zéro
• La sécurité n'importe pas — Pas de vraies données utilisateur, pas de credentials de production
• Tu es le seul utilisateur — Personne d'autre ne dépend de ce code
• La vitesse compte plus que la qualité — Tu valides un concept, tu ne construis pas une infrastructure

Exemples de tâches appropriées pour le vibe :

"Construis-moi un dashboard rapide pour visualiser ces données CSV"
"Fais une extension Chrome qui fait X"
"Prototype cette idée de feature pour que je puisse la montrer aux stakeholders"

Quand NE PAS vibrer

Recule du mode vibe quand :

• La sécurité est en jeu — Auth, paiements, données utilisateur. Révise toujours ce code.
• D'autres en dépendent — Membres de l'équipe, utilisateurs, systèmes de production
• De l'argent est en jeu — Coûts d'API, facturation, calculs financiers
• C'est difficile à annuler — Migrations de base de données, opérations destructives
• Tu dois le maintenir — Du code avec lequel tu vas vivre pendant des mois ou des années

Pour ces cas, passe au développement guidé par IA : Claude implémente, tu révises chaque changement, tu comprends ce qui se passe.

L'état d'esprit du chef d'orchestre

Même sans faire du vibe coding pur, l'insight fondamental s'applique : tu es le chef d'orchestre, pas l'instrumentiste.

Coding traditionnel : Tu écris chaque ligne.

Coding assisté par IA : Tu diriges l'orchestre. Claude s'occupe du doigté, tu décides quelle musique jouer.

Toi : "On a besoin d'authentification"
         ↓
Ton job : QUOI construire, POURQUOI, les contraintes
         ↓
Le job de Claude : COMMENT implémenter
         ↓
Ton job : VÉRIFIER que c'est correct

Ce changement explique pourquoi la planification compte plus, pas moins. Sans direction claire, Claude prendra des décisions qui semblent raisonnables mais ne correspondent pas à ton architecture.

Le paradoxe : plus de planification nécessaire

Voici ce qui surprend les gens : le développement assisté par IA nécessite PLUS de planification en amont, pas moins.

Sans planification, Claude va :

• Créer des patterns incohérents entre les fichiers
• Rater des contraintes architecturales que tu n'as pas énoncées
• Dupliquer des fonctionnalités qui existent déjà
• Prendre des décisions difficiles à inverser

À quoi ressemble une bonne planification

Je construis une feature de dashboard. Voici le plan :

Architecture :
- Composant serveur pour la page
- Composant client pour les graphiques interactifs
- React Query pour le data fetching
- Recharts pour la visualisation

Contraintes :
- Doit fonctionner sur mobile
- Les données se rafraîchissent toutes les 30 secondes
- Suit les patterns de composants existants dans src/components/

Tâches (dans l'ordre) :
1. Créer le composant serveur DashboardPage
2. Construire le composant client StatsCards
3. Ajouter les graphiques avec Recharts
4. Implémenter la logique de rafraîchissement

Commence par la tâche 1.

Claude est incroyablement bon pour l'implémentation. Il est moins bon pour les décisions stratégiques d'architecture. Joue sur les forces : tu architectures, Claude implémente.

Diriger efficacement

La différence entre des sessions IA frustrantes et productives se résume souvent à la façon dont tu diriges.

Trop vague :

"Construis-moi un dashboard"

Pas de contraintes, pas d'architecture, pas de patterns. Recette pour un résultat désaligné.

Trop contrôlant :

"Crée une fonction. Appelle-la handleSubmit. Elle doit prendre un paramètre event.
D'abord, preventDefault. Ensuite, récupère les données du formulaire..."

Tu écris du code avec des étapes en plus. Laisse Claude coder.

Le juste milieu :

"Ajoute un dashboard à la section admin montrant les stats utilisateurs.
Utilise le pattern de composant card existant dans src/components/ui/.
Inclus : total des utilisateurs, inscriptions cette semaine, sessions actives.
Les données viennent de l'endpoint /api/stats."

Objectif clair, contraintes claires, de la place pour que Claude travaille.

Fais confiance mais vérifie

Karpathy peut faire du vibe coding parce qu'il voit immédiatement si le code fonctionne et peut le jeter si ce n'est pas le cas. Pour tout ce qui va au-delà du prototype, ajoute de la vérification.

Pour l'implémentation :

"Implémente la feature, puis explique les décisions clés que tu as prises"

Force Claude à articuler son raisonnement. Attrape les désalignements tôt.

Pour le code sensible en termes de sécurité :

"Implémente ça, mais signale toute considération de sécurité que je devrais réviser"

Fait de Claude ton premier réviseur de sécurité.

Pour la logique complexe :

"Avant d'implémenter, explique ton approche en 2-3 phrases"

Attrape les mauvaises approches avant qu'elles ne deviennent du mauvais code.

L'état d'esprit itératif

Le vibe coding est intrinsèquement itératif. Le premier passage ne sera pas parfait. C'est normal.

"Ça fonctionne, mais les messages d'erreur sont génériques. Rends-les plus utiles."

"Bien, maintenant ajoute des états de chargement."

"Le layout mobile est cassé, corrige-le."

Des itérations rapides battent les tentatives parfaites du premier coup. Claude est bon marché et rapide. Utilise ça.

Les anti-patterns

Le non-vérificateur

❌ *Livre le code de Claude sans le lire*

Du vibe coding pur pour la production. C'est comme ça que tu obtiens des vulnérabilités de sécurité et des cas limites cassés.

Le micromanager

❌ "Crée une fonction. Appelle-la handleSubmit. Elle doit prendre un event..."

Tu écris du code avec des étapes en plus. Soit tu fais confiance à Claude pour implémenter, soit tu l'écris toi-même.

L'accumulateur de contexte

❌ *N'utilise jamais /clear, garde un contexte de 50 messages*

Le contexte obsolète dégrade la qualité des réponses. Efface souvent, surtout entre les tâches.

Le rêveur vague

❌ "Construis-moi Twitter"

Trop ambitieux, pas de contraintes, pas d'architecture. Tu obtiendras quelque chose, mais pas ce que tu voulais.

Trouver ton flow

Les développeurs qui tirent le maximum de Claude Code partagent certains patterns :

Ils effacent souvent. Contexte frais pour chaque tâche. Voir la Partie 2.

Ils planifient d'abord. Décisions d'architecture avant l'implémentation. Voir la Partie 3.

Ils utilisent des commandes pour la répétition. Workflows codifiés, pas des prompts répétés. Voir la Partie 4.

Ils vérifient la sécurité. Toujours réviser l'auth, les paiements, le traitement des données manuellement.

Ils itèrent rapidement. Boucles de feedback rapides, petits ajustements, pas de tentative parfaite du premier coup.

Ils savent quand prendre du recul. Quand Claude tourne en rond, ils ajoutent du contexte ou utilisent ultrathink.

L'état d'esprit de la vitesse

Une fois que tu as internalisé le rôle de chef d'orchestre, quelque chose change. Tu commences à penser en termes de quoi construire plutôt que comment le construire.

Un vibe coder expérimenté penserait :

"J'ai besoin d'un moyen d'exporter les données utilisateur"
→ "Formats CSV et JSON"
→ "Utiliser le pattern d'export existant des rapports"
→ "L'ajouter dans les paramètres utilisateur"

Puis dit exactement ça à Claude. L'implémentation devient un détail — important, mais pas là où va ta charge cognitive.

C'est ça le gain de productivité. Pas que Claude écrit du code à ta place, mais que tu peux opérer à un niveau d'abstraction plus élevé tout en livrant du logiciel fonctionnel.

Série terminée

Tu as maintenant couvert la boîte à outils complète de Claude Code :

1. Premiers pas — Installation, premières commandes, l'état d'esprit
2. Modèle mental — Comment Claude pense, gestion du contexte
3. Configuration projet — CLAUDE.md et paramètres
4. Commandes personnalisées — Commandes slash pour les workflows
5. Skills — Modules de connaissances auto-chargés
6. Subagents — Workers spécialisés en parallèle
7. Serveurs MCP — Intégration de services externes
8. Workflows de production — GitHub Actions, patterns d'équipe
9. Secrets de power user — ultrathink, mode headless, fonctionnalités cachées
10. Philosophie du Vibe Coding — L'état d'esprit qui relie tout

Les outils ne sont que des outils. L'état d'esprit — savoir quand vibrer, quand vérifier, quand planifier, quand laisser Claude foncer — c'est ça qui fait la différence.

Maintenant va construire quelque chose.