—

Claude Code : Comment en faire ton meilleur allié (sans te faire avoir)

Tu as déjà passé une nuit blanche à corriger un bug introduit par Claude ? Ou perdu 200 tokens parce qu’il a « oublié » ton fichier de config ? Ça arrive à tout le monde – mais ça ne devrait plus.

Avec Badgetizr 2.0 et d’autres projets, j’ai codé avec Claude pendant des centaines d’heures. Pas pour lui. Voici comment transformer cette IA en un partenaire fiable, sans tomber dans les pièges qui coûtent cher.

—

1️⃣ Traite Claude comme un nouveau dev dans ton équipe

📌 Le problème

Tu lances /init sans préparation, et soudain Claude propose du code qui ressemble à un spaghetti. Pourquoi ? Parce qu’un projet mal organisé donne des résultats mal organisés.

🔧 La solution : forme-le comme un junior

Un dev junior a besoin de règles claires. Claude aussi.

1. Donne-lui le manuel du parfait petit dev :

« Ce projet utilise Clean Architecture avec React Native. Voici les règles : [lien vers CLAUDE.md]. Pas de raccourcis, pas d’exceptions. »

→ Plus tu documentes, moins il hallucine.

1. Prépare le terrain avant de le lancer :

– Linters configurés (ESLint, Prettier, SwiftLint)

– Git hooks en place (Husky, lint-staged)

– Architecture claire (MVC, MVVM, ou Clean Architecture)

1. Structure ton projet pour qu’il comprenne :

   mon-projet/
   ├── .claude/                # Le "manuel" de Claude
   │   ├── auth-context.md     # Règles d’authentification
   │   ├── api-context.md      # Conventions API (REST, GraphQL)
   │   └── commands/           # Slash commands personnalisés
   │       ├── /review.md      # Règles pour les revues de code
   │       └── /test.md        # Stratégie de tests
   ├── src/
   │   ├── domain/             # Logique métier
   │   │   └── CLAUDE.md       # Règles spécifiques au domaine
   │   ├── data/               # Accès aux données
   │   └── ui/                 # Interface utilisateur
   └── CLAUDE.md               # Règles globales du projet

Le truc qui change tout :

Un CLAUDE.md bien rédigé réduit les erreurs de 40 %. Exemple de règle efficace :

« Toujours utiliser fetch avec un timeout de 10s. Pas de axios sans wrapper personnalisé. »

—

2️⃣ Vérifie toujours la liste des fichiers scannés

⚠️ Le piège classique

Claude « oublie » souvent les fichiers de config pendant /init. Résultat ? Il propose des solutions qui ignorent tes règles ESLint ou tes workflows GitHub.

Exemple concret :

« Claude, optimise ce composant React. » Claude : « Je vois que tu utilises des props non typées. Je vais ajouter TypeScript. » → Problème : Il a ignoré ton tsconfig.json et propose une config incompatible.

✅ La parade en 30 secondes

1. Lance /init.
2. Immédiatement après, tape /list-files et vérifie que :

– .eslintrc, prettier.config.js, .swiftlint.yml sont présents.

– .github/workflows/ est inclus (si tu utilises GitHub Actions).

1. Si un fichier manque, ajoute-le avec :

   /add-file .github/workflows/ci.yml

Astuce pro :

Crée un alias Slack ou un snippet VS Code pour /list-files + vérification. Gagne 5 minutes par jour.

—

3️⃣ Donne des chemins complets (et économise des tokens)

💸 Le gaspillage invisible

Quand tu dis « Modifie le fichier UserService », Claude doit :

1. Scanner tout le projet pour le trouver (50-100 tokens gaspillés).
2. Deviner quel UserService tu veux (risque d’erreur).

Coût réel :

• 10 requêtes avec chemins incomplets = 1 000 tokens perdus.
• 10 requêtes avec chemins complets = 200 tokens utilisés.

🎯 La bonne pratique

Toujours donner le chemin relatif complet :

❌ « Modifie le fichier UserRepository. »

✅ « Modifie src/data/repositories/UserRepository.ts pour ajouter une méthode getByEmail. »

Bonus :

• Utilise /add-dir pour étendre l’espace de travail :

  /add-dir /path/to/autre-projet

• Pour les gros projets, crée un CLAUDE_WORKSPACE.md qui liste les chemins critiques.

—

4️⃣ Surveille Claude comme un faucon

🚨 Les dangers qui guettent

Claude peut proposer des actions catastrophiques :

• Supprimer node_modules sans prévenir.
• Modifier un fichier critique (.env, package.json).
• Contourner tes règles de sécurité.

Cas réel :

« Claude, comment nettoyer ce dossier ? » Claude : « Je peux supprimer le dossier dist/ et le régénérer. Je lance rm -rf dist ? » → Heureusement que j’ai vérifié : le dossier contenait des assets manuels.

👀 La méthode infaillible

1. Lis chaque commande avant de l’exécuter.
2. Demande des explications avec /explain :

   /explain "Pourquoi veux-tu supprimer ce fichier ?"

1. Active les confirmations pour les actions sensibles :

   /set confirm_on_delete true
   /set confirm_on_modify package.json

Règle d’or :

Si une commande te semble trop radicale, elle l’est probablement. Demande une alternative.

—

5️⃣ Automatise les revues de PR avec la GitHub App

🤖 Le super-pouvoir méconnu

La Claude GitHub App peut :

• Revoir tes PR en 2 minutes (vs 30 minutes pour un humain).
• Proposer des fixes directement dans les comments.
• Auto-revoir ses propres PR (oui, Claude se relit lui-même).

🔥 Comment l’utiliser à 100 %

1. Installe l’app sur ton repo.
2. Taggue Claude dans une PR ou une issue :

   @claude-app review this PR

1. Configure les règles dans .claude/github-rules.md :

# Règles pour les revues de PR

– Vérifier que les migrations de base de données sont réversibles.

– Refuser les PR qui ajoutent des dépendances non justifiées.

– Exiger des tests pour les nouvelles fonctionnalités.

**Workflow magique** :
1. Tu ouvres une PR avec un bug.
2. Claude analyse le code et crée une **nouvelle PR avec le fix**.
3. Claude **revoit sa propre PR** avant que tu ne la merges.

**Statistique choc** :
Les équipes qui utilisent cette app réduisent leurs bugs en production de **35 %**.

---

## 6️⃣ Ne *jamais* merger sans relecture

### ❌ L’erreur qui coûte cher
Claude propose une solution élégante, tu merges sans vérifier… et **BOOM**, un bug subtil apparaît 3 jours plus tard.

**Exemple réel** :
> *"Claude, optimise cette fonction."*
> **Claude** : *"Voici une version plus performante avec un cache."*
> → **Problème** : Le cache n’était pas invalidé correctement, causant des incohérences de données.

### ✅ La checklist avant merge
1. **Simplifie** les solutions trop complexes.
2. **Vérifie les noms** : Claude adore les noms comme `handleUserDataFetchingWithErrorHandling`. Raccourcis-les.
3. **Teste manuellement** les cas limites.
4. **Documente** le code ajouté (Claude ne le fera pas pour toi).

**Pourquoi c’est crucial** :
- **Tu es responsable** du codebase. Un bug ? C’est toi qui debugges.
- **Claude manque de contexte** : ce qui semblait logique hier peut ne plus l’être aujourd’hui.
- **Les régressions sont sournoises** : un changement anodin peut casser une fonctionnalité critique.

---

## 🚀 En résumé : les 5 commandements pour coder avec Claude

1. **Structure ton projet** comme si tu formais un junior (`CLAUDE.md`, `.claude/`). Un projet bien organisé = un Claude efficace.
2. **Vérifie les fichiers scannés** après `/init`. 30 secondes de vérification = des heures de debug évitées.
3. **Donne des chemins complets**. Économise des tokens et évite les erreurs.
4. **Surveille chaque commande**. Une seconde d’inattention peut coûter cher.
5. **Utilise la GitHub App** pour automatiser les revues… mais **revois toujours le code**.

---

**Et toi, quel est le pire "fail" que tu as évité avec Claude ?**
J’ai failli supprimer mon projet entier (merci les sauvegardes Git). Partage ton histoire en commentaire – on apprend tous des erreurs des autres.

**Pour aller plus loin** :
- [Les bonnes pratiques d’Anthropic](https://www.anthropic.com/engineering/claude-code-best-practices) (en anglais)
- [La doc officielle de la GitHub App](https://github.com/marketplace/claude-app)
- [Mon template de projet optimisé pour Claude](https://github.com/ton-projet-exemple) *(à adapter à ton stack)*

**Rappel** : Claude est un partenaire, pas un remplaçant. **Le code que tu produis ensemble reste ta responsabilité.** 🚀