Patterns à éviter
Section intitulée « Patterns à éviter »Après les bons patterns, voici ce qui les sabote. La plupart de ces erreurs reviennent à négliger l’un des 5 composants vus dans l’anatomie — souvent le contexte ou les contraintes.
❌ Trop vague
Section intitulée « ❌ Trop vague »Avant : "Améliore ce code"
Après : "Refactorise cette fonction pour réduire la duplication — conserve l'interface publique et ne modifie pas les tests."
→ Sans critère précis, Claude choisit lui-même ce qu’il “améliore”. Souvent du reformatage cosmétique ou l’ajout de commentaires non demandés. Précise le critère et la contrainte.
❌ Sur-politesse
Section intitulée « ❌ Sur-politesse »Avant : "Pourrait-tu s'il te plaît éventuellement jeter un œil à ce code si tu as le temps ?"
Après : "Identifie les failles de sécurité dans ce code. Priorité : injection SQL et gestion des erreurs."
→ La politesse excessive dilue la demande et peut induire Claude à répondre de façon vague par symétrie. Va droit au but — Claude n’est pas vexable.
❌ Tout en un
Section intitulée « ❌ Tout en un »Avant : "Analyse ce code, écris les tests, documente les fonctions, propose des améliorations de perf et vérifie la sécurité."
Après : Découpe en 5 prompts distincts, dans l’ordre de priorité. Commence par l’analyse — elle alimentera les suivants.
→ Cinq tâches en un seul prompt = cinq résultats superficiels. Claude arbitre lui-même les priorités et bâcle les dernières. Une tâche par prompt, résultat complet à chaque fois.
❌ Pas de contexte
Section intitulée « ❌ Pas de contexte »Avant : "Pourquoi ce code plante ?" (avec le code collé brut, sans rien d’autre)
Après : "Ce service Node.js plante au démarrage avec cette erreur : [erreur]. Stack : Node 20, Express, PostgreSQL. Ce que j'ai déjà essayé : [tentatives]. Identifie la cause racine."
→ Claude ne sait pas ce que le code est censé faire, ni dans quel contexte il tourne. Sans ça, il diagnostique l’erreur visible mais peut passer à côté de la cause réelle.
❌ Validation vide
Section intitulée « ❌ Validation vide »Avant : "C'est bon ?" ou "Tu en penses quoi ?"
Après : "Est-ce que cette implémentation est thread-safe ? Y a-t-il des cas limites sur les inputs null que je n'ai pas couverts ?"
→ Une question ouverte invite une réponse vague et rassurante. Donne un angle précis à valider — Claude sera beaucoup plus critique si tu lui demandes de l’être sur un point spécifique.
❌ Ignorer le format
Section intitulée « ❌ Ignorer le format »Avant : "Liste les différences entre REST et GraphQL" (tu veux un tableau, tu obtiens 4 paragraphes)
Après : "Compare REST et GraphQL sur 5 critères : performance, flexibilité, complexité d'implémentation, tooling, cas d'usage idéal. Format : tableau Markdown."
→ Sans instruction de format, Claude choisit la prose par défaut — souvent le moins adapté pour une comparaison ou une référence rapide. Spécifie le format dans la demande.