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
Ce qui se passe : chaque session est incohérente. Claude utilise des conventions différentes, range les fichiers n'importe où, pioche des couleurs au hasard, oublie les règles métier.
Ce qu'il faut faire : crée le CLAUDE.md dès la première heure du projet (voir chapitre 3). 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
Ce qui se passe : "Construis-moi une app complète de gestion de projets avec auth, dashboard, facturation, analytics, et un assistant IA" produit un résultat superficiel, plein de raccourcis, impossible à maintenir.
Ce qu'il faut faire : 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
Ce qui se passe : Claude fait des choix techniques sans te consulter. Tu découvres après 30 minutes de code qu'il a pris la mauvaise approche. Tout est à refaire.
Ce qu'il faut faire : 10 minutes de brainstorm + plan évitent 2 heures de retravail. 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
Ce qui se passe : Claude peut faire des erreurs subtiles : une condition inversée, un cas limite non géré, un problème de sécurité. Sans test, ces bugs arrivent en production.
Ce qu'il faut faire : 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
Ce qui se passe : 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.
Ce qu'il faut faire : 2-3 itérations donnent un 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
Ce qui se passe : 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.
Ce qu'il faut faire : lance typecheck + lint après chaque modification. Non négociable. 5 secondes qui évitent 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
Ce qui se passe : résultat aléatoire, frustration, 3-4 allers-retours pour obtenir ce que tu voulais.
Ce qu'il faut faire : 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
Ce qui se passe : 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.
Ce qu'il faut faire : 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
Ce qui se passe : tu perds du temps en attendant que chaque tâche finisse alors que certaines pourraient tourner en parallèle.
Ce qu'il faut faire : 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
Ce qui se passe : ta conversation avec Claude devient longue, il dépasse 70-80% de contexte. 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.
Ce qu'il faut faire : 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
Ce qui se passe : "Ça marche" ne veut pas dire "c'est solide". Sans review tu laisses passer 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.
Ce qu'il faut faire : lance /review avant chaque commit important. 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 loggé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.