Rédigé par Robin

Pièges & limites

On a vu comment construire la stack : setup, permissions, skills, hooks, agents, CLAUDE.md. Voici ce qui peut dérailler à chaque étape — et comment le détecter tôt.

Claude Code est un outil puissant — mais pas infaillible. Connaître ses angles morts, c’est ce qui fait la différence entre un utilisateur qui produit vite et un utilisateur qui répare vite.

Les pièges courants

Hallucinations sur le filesystem

Claude peut affirmer avoir créé ou modifié un fichier alors que ce n’est pas le cas — ou l’inverse. Il ne “voit” pas le filesystem en temps réel : il raisonne sur ce qu’il a écrit dans la conversation.

Ce qu’il faut faire : toujours vérifier avec un ls, cat, ou en ouvrant le fichier. Ne pas supposer que parce que Claude dit “c’est fait”, c’est fait.

✍️ Un mot de Robin Écrit par un humain

Raconte un cas où Claude t'a dit qu'un fichier existait ou avait été modifié, et en réalité non. Qu'est-ce que ça t'a coûté ?

💡 Ce bloc attend ta plume — remplace ce texte par ton vécu.

---

Confiance aveugle dans les sorties de commandes

Claude exécute une commande, lit la sortie, et en tire une conclusion — mais il peut mal interpréter une erreur, ignorer un warning, ou considérer un exit code non-zéro comme un succès si le contexte l’induit en erreur.

Ce qu’il faut faire : lire toi-même les sorties de commandes importantes. Ne pas déléguer l’interprétation sur des commandes critiques (migrations, déploiements, tests).

✍️ Un mot de Robin Écrit par un humain

Est-ce que tu as un exemple de commande où Claude a mal interprété la sortie ? Qu'est-ce qui s'est passé ?

💡 Ce bloc attend ta plume — remplace ce texte par ton vécu.

---

Boucles sur des erreurs non résolues

Quand Claude rencontre une erreur qu’il ne sait pas corriger, il peut entrer dans une boucle : tenter une correction, échouer, retenter une variante, échouer encore. Sans garde-fou, il peut itérer indéfiniment en consommant des tokens sans résoudre le problème.

Ce qu’il faut faire : si Claude tourne en rond après 2-3 tentatives, interrompre et reprendre avec un contexte plus précis ou une approche différente. Le mode plan est utile ici — il planifie avant d’agir.

✍️ Un mot de Robin Écrit par un humain

Décris une session où Claude a loopé. À quel moment tu as réalisé ce qui se passait ? Comment tu l'as sorti de là ?

💡 Ce bloc attend ta plume — remplace ce texte par ton vécu.

---

Context window saturé silencieusement

Quand le context window approche de sa limite, la qualité des réponses se dégrade — Claude commence à “oublier” des instructions données plus tôt dans la session, à répéter des erreurs déjà corrigées, à perdre le fil de l’architecture.

Le problème : il ne te le dit pas forcément.

Ce qu’il faut faire : utiliser /cost pour surveiller la consommation. Utiliser /compact pour compresser l’historique avant saturation. Sur les sessions longues, préférer de nouvelles sessions ciblées plutôt qu’une session marathon.

✍️ Un mot de Robin Écrit par un humain

Est-ce que tu as remarqué ce phénomène ? Comment tu détectes que Claude commence à dégrader ?

💡 Ce bloc attend ta plume — remplace ce texte par ton vécu.

---

Mode auto mal compris

--dangerously-skip-permissions (mode auto) approuve toutes les actions sans confirmation. C’est pratique pour les tâches répétitives bien délimitées — c’est dangereux sur un projet complexe ou une session non supervisée.

Ce qu’il faut faire : réserver le mode auto aux tâches que tu as déjà validées manuellement une fois. Ne jamais le lancer sur un contexte inconnu ou une tâche ambitieuse.

✍️ Un mot de Robin Écrit par un humain

Tu l'utilises ? Dans quels cas ? Est-ce que ça t'a déjà posé un problème ?

💡 Ce bloc attend ta plume — remplace ce texte par ton vécu.

---

Mauvaise décomposition des tâches

Donner une tâche trop large à Claude en une seule fois produit souvent un résultat partiel ou incohérent. Il va tenter de tout faire, prendre des raccourcis sur les parties qu’il gère moins bien, et livrer quelque chose qui “ressemble” à ce que tu voulais sans l’être vraiment.

Ce qu’il faut faire : décomposer. Une tâche = un objectif clair, un périmètre délimité, un résultat vérifiable. Plus la tâche est atomique, plus la sortie est fiable.

✍️ Un mot de Robin Écrit par un humain

Donne un exemple de tâche trop large que tu lui as donnée. Qu'est-ce qui s'est passé ? Comment tu l'as redécoupée ensuite ?

💡 Ce bloc attend ta plume — remplace ce texte par ton vécu.

---

Quand ne pas lui faire confiance sans supervision

Certains contextes nécessitent une vigilance accrue, quelle que soit la qualité de la session :

Contexte	Pourquoi c’est risqué
Migrations de base de données	Irréversible — une erreur coûte cher
Infra critique (CI/CD, DNS, permissions)	Impact global, difficile à rollback
Merge conflicts complexes	Claude peut “résoudre” sans comprendre l’intention métier
Code de sécurité (auth, crypto)	Les erreurs sont invisibles jusqu’au problème
Suppression de fichiers / données	Pas de retour arrière facile

---

En résumé

Claude Code fait gagner du temps — à condition de rester le pilote. Vérifier, décomposer, surveiller le contexte : ces réflexes ne ralentissent pas, ils évitent les régressions qui font perdre bien plus de temps.

→ Voir aussi : Coûts & tokens pour comprendre comment le context window affecte la qualité.