Ce chapitre te présente les 11 erreurs les plus coûteuses que font les débutants avec Claude Code, et comment les éviter. Chacune est tirée d'une expérience réelle. Temps de lecture : 10 minutes.
Erreur 1, ne pas créer de CLAUDE.md
Le coût : chaque session est incohérente. Claude utilise des conventions différentes, range les fichiers n'importe où, utilise des couleurs aléatoires, oublie les règles métier.
La solution : crée le CLAUDE.md dès le début du projet (voir chapitre 3). C'est littéralement ton investissement n°1, 30 minutes qui en économisent des dizaines.
Signe d'alerte : si tu te retrouves à répéter "utilise la palette du projet" ou "les fichiers vont dans src/components/", ton CLAUDE.md est incomplet.
Erreur 2, demander tout d'un coup
Le coût : "Construis-moi une app complète de gestion de projets avec auth, dashboard, facturation, analytics, et un assistant IA" → catastrophe garantie. Claude va produire un résultat superficiel, plein de raccourcis, et impossible à maintenir.
La solution : découpe en features, une par une, avec un plan pour chacune. Chaque feature doit être livrée, testée, et commitée avant de passer à la suivante.
Règle : si ta demande contient plus de 3 "et", elle est trop grosse. Découpe.
Erreur 3, foncer sans planifier
Le coût : Claude fait des choix techniques sans te consulter. Tu découvres après 30 minutes de code qu'il a choisi la mauvaise approche. Tout est à refaire.
La solution : 10 minutes de brainstorm + plan = 2 heures de retravail évitées. Le ratio est imbattable. Voir chapitre 5.
Exception : les bug fixes simples et les ajustements cosmétiques n'ont pas besoin de plan.
Erreur 4, accepter aveuglément le résultat
Le coût : Claude peut faire des erreurs subtiles, une condition inversée, un cas limite non géré, un problème de sécurité. Si tu ne testes pas, ces bugs arrivent en production.
La solution : teste TOUJOURS visuellement sur localhost. Toi seul sais si l'UX correspond à ta vision. Claude ne voit pas ton écran.
Vérifie au minimum :
- Le comportement normal fonctionne
- Les cas d'erreur sont gérés (mauvaise saisie, données vides)
- Le responsive (mobile) fonctionne
- Les textes sont corrects (accents, grammaire)
Erreur 5, ne pas itérer
Le coût : tu te contentes d'un premier jet "qui marche" au lieu d'un résultat excellent. La qualité perçue de ton app en souffre.
La solution : 2-3 itérations = résultat excellent. Le premier jet est la structure, les itérations sont le polish.
Exemples d'itérations typiques :
- "Augmente l'espacement, c'est trop tassé"
- "Ajoute une animation quand les données se chargent"
- "Le message d'erreur est trop technique, reformule-le pour un non-développeur"
Erreur 6, sauter les vérifications
Le coût : tu accumules des erreurs invisibles qui explosent plus tard. Un type incorrect ici, un import cassé là, et soudain ton build ne compile plus avec 47 erreurs.
La solution : typecheck + lint après chaque modification. C'est non négociable. Ça prend 5 secondes et ça évite des heures de debugging.
Astuce : avec le fichier de permissions bien configuré (chapitre 9), Claude lance ces vérifications automatiquement sans te demander.
Erreur 7, écrire des prompts vagues
Le coût : résultat aléatoire → frustration → 3-4 aller-retours pour obtenir ce que tu voulais.
La solution : voir chapitre 4. En résumé : contexte + quoi + critères + contraintes. 30 secondes de formulation économisent 10 minutes de corrections.
Erreur 8, ne pas sauvegarder la mémoire
Le coût : demain, Claude a tout oublié. Il repropose des approches que tu as écartées. Il refait des erreurs déjà corrigées. Il perd du temps à redécouvrir le contexte.
La solution : en fin de session productive, dis "Mets à jour la mémoire projet." 30 secondes qui font la différence. Voir chapitre 10.
Erreur 9, tout faire en séquence
Le coût : tu perds du temps en attendant que chaque tâche finisse alors que certaines pourraient tourner en parallèle.
La solution : identifie les tâches indépendantes et dis-le explicitement :
"Lance en parallèle : la migration SQL, le composant UI, et les tests unitaires. Ces 3 tâches sont indépendantes."
Claude lance 3 agents simultanément au lieu de faire l'un après l'autre. Gain : 3x plus rapide.
Quand NE PAS paralléliser : quand une tâche dépend du résultat d'une autre (ex: les types TypeScript dépendent de la migration SQL).
Erreur 10, ignorer la gestion du contexte
Le coût : ta conversation avec Claude devient longue, il dépasse 70-80% de contexte. Soudain, il oublie tes conventions, répète des erreurs déjà corrigées, fait des choix incohérents. Tu perds 20 minutes avant de comprendre que c'est un problème de contexte, pas de logique.
La solution : surveille le contexte (via /context ou la status line). /compact dès 60%. /clear si tu changes de sujet. /rewind (Esc Esc) si Claude part en vrille au lieu d'essayer de corriger dans le même contexte pollué.
Signe d'alerte : Claude commence à "oublier" des règles qu'il respectait en début de session. C'est le signal qu'il faut compacter.
Erreur 11, ne jamais faire de /review
Le coût : "Ça marche" ne veut pas dire "c'est solide". La review attrape des vrais bugs : des failles de sécurité (données utilisateur exposées), des cas limites non gérés (que se passe-t-il si la liste est vide ?), du code mort qui alourdit l'app.
La solution : /review avant chaque commit important. C'est comme demander à un collègue de relire ton travail, un regard neuf attrape ce que l'auteur ne voit plus.
Exemple réel : sur Panettone, une review a détecté que des données sensibles étaient logées en console. Sans la review, ces données auraient été visibles en production.
À retenir : ces 11 erreurs sont classées par impact. Corrige-les dans
l'ordre : le CLAUDE.md est le plus critique, la gestion du contexte et la
review sont les plus sous-estimés. Chacune est facile à éviter une fois que tu
la connais.