Claude Code : comment un setup minimaliste booste la productivité

Après plusieurs mois d'expérimentation avec Claude Code sur différents projets, j'ai progressivement affiné un setup minimaliste qui améliore significativement ma productivité. Ce guide partage cette approche : configuration, choix techniques, et patterns d'usage concrets. C'est une approche parmi d'autres, particulièrement adaptée aux débutants ou à ceux qui cherchent un point de départ simple.

Note : Ce workflow reflète mes besoins et contraintes. Il existe de nombreuses autres approches valides selon votre contexte. J'utilise moi-même d'autres setups selon les projets. D'autres articles viendront explorer ces alternatives.

Le Constat de Départ

Quand j'ai découvert Claude Code, j'ai naturellement activé de nombreuses features : MCP servers multiples, agents spécialisés, modes d'orchestration... L'outil propose tellement de possibilités qu'il est tentant de tout essayer.

Ce que j'ai observé avec cette configuration maximale :

• Latence notable : C'est lent

• Context fragmenté : Beaucoup de tools actifs consomment de l'espace

• Complexité de choix : Quel outil utiliser pour quelle tâche ?

• Configuration chronophage : Temps passé à optimiser plutôt qu'à développer (Similaire au syndrome du Notion Hell, pour les connaisseurs)

Après plusieurs itérations, j'ai progressivement simplifié mon setup. Aujourd'hui, il tient en quelques fichiers de configuration et scripts. Cette approche minimaliste s'est révélée très efficace pour mes besoins quotidiens.

Approche : Minimalisme Pragmatique

Le Principe des 80/20 Appliqué aux Outils IA

En analysant mon usage quotidien, j'ai identifié ce qui m'apportait le plus de valeur :

Composants conservés :

• Context7 (un seul MCP server)

• 3 customs commands ciblés

• Hooks pour sécurité et notifications

• Aliases pour accélérer les commandes courantes

Composants désactivés dans ce setup :

• Autres MCP servers (utilisés dans d'autres contextes)

• Agents spécialisés (réservés aux cas complexes)

• Modes avancés d'orchestration

Pourquoi cette simplification ? L'essentiel de mon développement quotidien se concentre sur :

1. Lecture de code existant

2. Écriture de nouveau code

3. Consultation de documentation

4. Création de commits

Pour ces besoins-là, un setup simple s'avère suffisant et plus rapide.

Contextes d'Usage

Ce setup convient particulièrement au développement quotidien classique : features, bug fixes, refactos. D'autres configurations peuvent être préférables selon votre contexte :

• Automatisation browser intensive → Playwright MCP apporte une vraie valeur

• Transformations de code massives → Morphllm optimise ces opérations

• Analyses architecturales complexes → Sequential aide à structurer le raisonnement

Je recommande cette approche minimaliste comme point de départ, surtout si vous débutez avec Claude Code. Vous pourrez ensuite ajouter des outils spécialisés selon vos besoins réels, en gardant toujours un œil sur le ratio coût/bénéfice.

Comprendre le Coût des MCP : La Pollution du Contexte

Un aspect souvent sous-estimé de l'écosystème MCP : le ratio entre créateurs et utilisateurs actifs. Il existe de nombreux MCP, mais dans la pratique, combien en utilisez-vous quotidiennement ? Dans mon cas : Context7 principalement. Les autres interviennent rarement.

Cette observation rejoint un pattern intéressant : beaucoup d'énergie est investie dans la création de nouveaux MCP, tandis que les utilisateurs font face à un enjeu pratique important : la gestion du contexte.

Le Coût Caché des MCP

Chaque MCP activé injecte ses "tools" dans le contexte de Claude. Ces tokens sont consommés à chaque requête, que vous utilisiez effectivement ces tools ou non.

Exemple mesuré : Avec 3 MCP actifs (Things3, Playwright, Context7), on observe une consommation de 20.7K tokens, soit 10.3% du contexte total. C'est une part significative qui n'est pas disponible pour le raisonnement ou le code.

Avec davantage de MCP actifs (GitHub, Vercel, Linear, Notion...), cette proportion augmente proportionnellement. Il devient alors pertinent de se demander : est-ce que j'utilise réellement tous ces outils assez souvent pour justifier ce coût permanent ?

Alternative : Privilégier les CLI Quand C'est Possible

Pour de nombreux cas d'usage, les CLI standards offrent une alternative intéressante :

• GitHub MCP → gh CLI (outil officiel GitHub)

• Vercel MCP → vercel CLI

Avantages de cette approche :

• Pas de consommation de tokens de contexte

• Flexibilité complète (accès à toutes les options)

• Pas d'overhead de communication MCP

• Documentation officielle exhaustive

Claude Code utilise les CLI via l'outil Bash. Cette approche permet d'économiser du contexte tout en gardant une bonne intégration. C'est particulièrement pertinent pour les outils que vous n'utilisez qu'occasionnellement.

Context7 : Un Cas d'Usage Qui Justifie le Coût

Dans mon setup, Context7 reste actif car il apporte une valeur que les CLI ne fournissent pas : accès unifié à la documentation officielle des frameworks en constante évolution.

Ce que Context7 fait bien :

• Lookup instantané de docs React, Next.js, Vue, Express...

• Patterns recommandés par les mainteneurs

• Code d'exemple validé

• Support des versions spécifiques

Pattern d'usage concret :

$ c "comment implémenter React Server Components avec Next.js 14 App Router"
→ Context7 fetch la doc officielle Next.js
→ Claude génère du code avec les bons patterns

$ c "setup Auth.js (NextAuth v5) avec GitHub provider"
→ Context7 fournit les conventions à jour
→ Pas de code deprecated

Context7 ne remplace pas un CLI mais complète les capacités natives de Claude en apportant une connaissance à jour des frameworks. Pour mon usage, le ratio coût/bénéfice est favorable.

Configuration minimale :

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    }
  }
}

Configuration simple : un seul MCP actif. Le reste passe par des CLI standards selon les besoins.

Setup Terminal : Fondations Pratiques

Aliases pour Accélérer les Commandes

Dans mon .zshrc :

# Claude Code avec permissions by default
alias c='claude --dangerously-skip-permissions'
alias cc='claude --continue --dangerously-skip-permissions'

⚠️ Note sur --dangerously-skip-permissions : Ce flag désactive les confirmations de permission. Son nom inquiétant est justifié : il nécessite des précautions. Dans mon cas, je le combine avec des hooks de sécurité (détaillés plus bas) qui valident les commandes en amont. Cela évite les popups répétitives tout en gardant un contrôle.

Cette approche n'est pas universelle. Si vous travaillez sur des projets sensibles, ou si vous préférez valider manuellement, les permissions standards restent le choix le plus sûr. C'est une question de trade-off personnel entre fluidité et sécurité explicite.

Pattern d'usage :

# Démarrer une session
$ c "implémente la validation du formulaire user"

# Continuer sans répéter le contexte
$ cc "ajoute les tests unitaires"

# Re-continuer
$ cc "fix les edge cases"

Économie estimée : 5-10 secondes par interaction. Sur une journée active, cela représente un gain de temps cumulatif non négligeable.

Multi-window avec Hyper Terminal

J'utilise Hyper sur Mac pour gérer plusieurs sessions Claude simultanément. Configuration clé :

module.exports = {
  config: {
    shell: '/bin/zsh',
    keymaps: {
      'cmd+d': 'pane:splitRight',
      'cmd+shift+d': 'pane:splitDown',
      'cmd+w': 'pane:close',
      'cmd+[': 'pane:previous',
      'cmd+]': 'pane:next',
    }
  }
}

Pattern organisationnel :

• Une fenêtre = une feature ou sous-tâche

• Entre 1 et 5 Claude actifs simultanément

• Split rapide avec Cmd+D

Exemple de layout :

Les fenêtres restent ouvertes tant que la feature n'est pas mergée. Ça fait office de TODO visuel.

Le Compromis : Pas de Diff Visuel

Le point faible du terminal versus un IDE : pas de visualisation facile des fichiers modifiés. Ma solution actuelle repose sur des git status réguliers et des hooks audio (voir section suivante).

Note : Je teste les git worktrees pour mieux isoler les contextes. Ça fera l'objet d'un article dédié.

Hooks Intelligents : Sécurité Sans Friction

Configuration Complète

~/.claude/settings.json :

{
  "permissions": {
    "allow": [
      "Bash", "Read", "Edit", "Write", "Glob", "Grep",
      "TodoWrite", "Task", "WebSearch", "WebFetch"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bun .claude/scripts/validate-command.js"
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "afplay -v 0.5 .claude/song/finish.mp3"
          }
        ]
      }
    ],
    "Notification": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "afplay -v 0.5 .claude/song/need-human.aiff"
          }
        ]
      }
    ]
  }
}

Hook 1 : Validation de Sécurité (PreToolUse)

Le problème : Avec --dangerously-skip-permissions, Claude peut théoriquement exécuter n'importe quelle commande Bash.

La solution : Validation automatique AVANT chaque exécution.

Script .claude/scripts/validate-command.js (extrait) :

const SECURITY_RULES = {
  CRITICAL_COMMANDS: [
    "rm", "del", "format", "mkfs", "shred", "dd"
  ],

  DANGEROUS_PATTERNS: [
    /rm\s+.*-rf\s*\/\s*$/i,           // rm -rf /
    /rm\s+.*-rf\s*\/etc/i,            // rm -rf /etc
    />\s*\/dev\/(sda|hda|nvme)/i,     // Écriture sur disque
    /dd\s+.*of=\/dev\//i,             // dd sur device
    /;\s*(rm|dd|mkfs)/i,              // Command chaining
    /\|\s*(sh|bash|zsh)$/i,           // Pipe vers shell
  ],

  PROTECTED_PATHS: [
    "/etc/", "/usr/", "/bin/", "/boot/", "/sys/"
  ]
};

const result = validator.validate(command, toolName);

if (!result.isValid) {
  console.error(`❌ BLOCKED: ${result.violations.join(", ")}`);
  process.exit(2); // Exit code 2 = bloquer
}

Résultat :

• Les commandes safe passent sans friction (git, npm, ls, cat...)

• Les commandes destructives sont bloquées automatiquement

• Log de sécurité dans ~/.claude/security.log

Exemple de blocage :

$ c "supprime tous les fichiers du système"

[SECURITY] BLOCKED: rm -rf / (Dangerous pattern detected)
❌ Command validation failed

Hook 2 : Notification Audio de Fin (Stop)

Le problème : Vous lancez Claude, allez faire une autre tâche ailleurs, et réalisez 5 minutes plus tard qu'il a fini depuis longtemps.

La solution : Son de notification à chaque fin de réponse.

"Stop": [
  {
    "matcher": "*",
    "hooks": [
      {
        "type": "command",
        "command": "afplay -v 0.5 .claude/song/finish.mp3"
      }
    ]
  }
]

Observation :

• Sans notification : Tendance à vérifier fréquemment si Claude a terminé

• Avec notification : Retour naturel quand c'est prêt

• Permet de se concentrer sur d'autres tâches en parallèle

Alternative Linux/Windows :

# Linux
"command": "paplay /path/to/sound.wav"

# Windows (PowerShell)
"command": "powershell -c (New-Object Media.SoundPlayer 'C:\\path\\to\\sound.wav').PlaySync()"

Hook 3 : Notification d'Intervention (Notification)

Quand Claude a besoin de validation humaine, un son différent se déclenche.

"Notification": [
  {
    "matcher": "*",
    "hooks": [
      {
        "type": "command",
        "command": "afplay -v 0.5 .claude/song/needHuman.aiff"
      }
    ]
  }
]

Pattern sonore :

• endTask.mp3 : Son grave = "c'est terminé"

• needHuman.aiff : Son aigu = "je t'attends"

Avec l'habitude, le cerveau apprend à distinguer ces sons, ce qui aide à maintenir un bon flow de travail.

Custom Commands : Les 3 Qui Comptent

Command 1 : /explore-and-plan (EPCT Workflow)

Cas d'usage : Feature complexe dans un codebase que je connais mal.

Ce qu'elle fait :

Explore → Utilise des sub-agents parallèles pour identifier tous les fichiers pertinents, comprendre les patterns existants, analyser l'architecture.

Plan → Produit un plan d'implémentation détaillé : fichiers à créer/modifier, tests nécessaires, points d'attention.

Code → Implémente en respectant rigoureusement le style du projet.

Test → Valide avec tests automatisés et vérification browser si UI.

Exemple d'usage :

$ c "/explore-and-plan implémente l'authentification OAuth avec Google"

# Claude explore le projet (2-3 min)
# Produit un plan structuré
# Demande validation
# Execute après accord

# Résultat : Feature complète + testée en 15-20min

Comparaison avant/après :

Sans /explore-and-plan :

• Instruction vague : "Ajoute OAuth Google"

• Claude code dans le mauvais endroit

• Tests oubliés

• Je corrige manuellement

• Temps : 45 minutes

Avec /explore-and-plan :

• Plan validé en amont

• Code cohérent avec le reste

• Tests inclus par défaut

• Temps : 20 minutes

• Gain : x2.25

Command 2 : /commits (Smart Auto-Commits)

Cas d'usage : Deux heures de travail, 15 fichiers modifiés, besoin de commits atomiques.

Ce qu'elle fait :

1. Analyse git status + git diff en parallèle

2. Groupe les changements par logique : features, fixes, updates, refactor, config, docs

3. Génère des messages concis : "add user profile validation", "fix button redirection"

4. Commit automatiquement dans l'ordre logique

Exemple réel :

$ git status
modified:   src/auth/middleware.ts
modified:   src/users/controller.ts
modified:   src/users/entity.ts
modified:   migrations/20250107-add-nickname.ts
modified:   package.json
modified:   README.md

$ c "/commits"

✅ Created 4 commits:
  1. add nickname field to user entity
  2. update migration script for users
  3. update user controller validation
  4. bump dependencies express and bcrypt

Avantages :

• Commits atomiques et logiques

• Messages clairs (pas de "WIP" ou "fix stuff")

• Ordre respecté (migrations avant code métier)

• Prêt pour review/PR

Temps gagné : De 10 minutes (craft manual) à 30 secondes.

Command 3 : /auto-fix (Build & TypeScript Issues)

Cas d'usage : Build cassé avec 25 erreurs TypeScript après un refacto massif.

Ce qu'elle fait :

1. Lance pnpm build + pnpm tsc en parallèle

2. Parse et catégorise : CRITICAL (build-breaking), HIGH (type errors), MEDIUM (warnings), LOW (style)

3. Fixe en parallèle via sub-agents (1 agent = 1 issue)

4. Re-valide

5. Boucle jusqu'à 0 erreur

Exemple :

$ pnpm build
❌ 14 TypeScript errors, 3 build failures

$ c "/auto-fix"

[CRITICAL] Fixing build errors (3)
  ├─ Missing export in auth.ts
  ├─ Circular dependency users <> posts
  └─ Invalid import path

[HIGH] Fixing type errors (14)
  ├─ Implicit any in validateEmail()
  ├─ Missing property 'id' on User
  └─ ... (parallélisé)

✅ All issues resolved
✅ Build successful
✅ TypeScript clean

Time: 3m 42s

Sans /auto-fix : 30-45 minutes (fix un par un, rebuild à chaque fois) Avec /auto-fix : 3-5 minutes Gain : x9

⚠️ Nuance : Sur d'énormes projets (>500 fichiers), l'approche manuelle ciblée peut être plus appropriée. Comme toujours, adaptez l'outil au contexte.

Patterns d'Usage Concrets

Pattern : Feature Development

# Positionnement
$ cd ~/projects/client-saas
$ git checkout -b feature/user-notifications

# Lancement avec contexte
$ c "implémente le système de notifications in-app. Explore le projet et propose un plan."

# Validation du plan (2-3 min)
# Implémentation (10-15 min)
# Notification sonore 🔔

# Review rapide
$ git diff

# Commits propres
$ cc "/commits"

Temps estimé : ~20 minutes (contre ~1h30 avec une approche manuelle classique)

Pattern : Bug Fix Rapide

# Issue : "Le bouton signup ne redirige pas"
$ c "le bouton signup ne redirige pas vers /dashboard après inscription. Debug et fix."

# Claude identifie (mauvaise route dans router.tsx)
# Fix + tests ajoutés
# Notification 🔔

$ cc "/commits"
→ "fix signup button redirect to dashboard"

$ git push origin fix/signup-redirect

Temps estimé : ~8 minutes (contre 30-45 minutes manuellement)

Pattern : Refacto Multi-Composants

Parfois, une refacto touche plusieurs domaines : API, frontend, base de données. Dans ces cas, j'utilise plusieurs fenêtres Claude en parallèle.

Setup Hyper :

┌──────────────────┬──────────────────┐
│ $ c "refacto    │ $ c "update     │
│  auth API       │  frontend auth  │
│  endpoints"     │  components"    │
│ [working...]    │ [working...]    │
├──────────────────┴──────────────────┤
│ $ c "migrate auth schema"          │
│ [working...]                       │
└────────────────────────────────────┘

Avantages :

• Trois Claude bossent simultanément

• Pas de context switching mental

• Temps divisé par 3-4

Risque géré : Conflits Git potentiels. Je les évite en définissant des scopes clairs ("toi tu touches QUE le frontend") et en mergeant dans l'ordre logique (DB → API → Frontend).

Pattern : Pre-Push Quality Check

# Avant de push, vérification
$ pnpm build
❌ 8 TypeScript errors

# Auto-fix
$ c "/auto-fix"
# 3 minutes ⏱️

# Tests
$ pnpm test
✅ All pass

# Push
$ git push origin feature/user-notifications

Routine de fin : ~10 minutes (contre 30-45 minutes en approche manuelle)

Anti-Patterns à Éviter

❌ Anti-pattern 1 : Agent Overuse

Erreur : Tout déléguer aux agents spécialisés.

# Mauvais
$ c "lance un agent pour analyser le code"
$ c "lance un agent pour écrire les tests"
$ c "lance un agent pour review la PR"

Pourquoi ça pose problème :

• Overhead de lancement (10-20 secondes)

• Context dilué

• Perte de contrôle

Approche recommandée :

# 90% des cas : prompt direct
$ c "analyse le code et propose des améliorations"

# 10% des cas : agent si vraiment complexe
$ c "utilise l'agent root-cause-analyst pour cette memory leak"

Le prompt system de Claude Code fonctionne bien pour la plupart des besoins. Les agents restent utiles pour des analyses très spécialisées.

❌ Anti-pattern 2 : MCP Server Overload

Rappel de la section MCP : chaque MCP consomme du contexte de manière permanente, qu'il soit utilisé ou non.

L'accumulation peut devenir significative : trois MCP = ~10% de contexte, cinq MCP = 15-20%+. Cette proportion réduit l'espace disponible pour le raisonnement et le code.

Approche suggérée : Évaluez la fréquence d'usage de chaque MCP. Si un outil n'est utilisé qu'occasionnellement, le CLI peut être une alternative plus économe en contexte.

❌ Anti-pattern 3 : Permissions Granulaires

⚠️ Ceci reflète une préférence personnelle. Les deux approches ont leurs mérites.

Approche granulaire : Configurer les permissions tool par tool.

{
  "permissions": {
    "allow": ["Read(src/**)", "Write(src/**)"],
    "deny": ["Bash(rm *)", "Bash(git push)"]
  }
}

Points d'attention observés :

• Configuration détaillée à maintenir

• Validations fréquentes nécessaires

• Évolution avec le projet

Mon choix alternatif :

• --dangerously-skip-permissions + hooks de validation

• Contrôle en amont via scripts

• Compromis entre fluidité et sécurité

Les deux approches sont légitimes. Le choix granulaire privilégie la validation explicite, tandis que mon approche mise sur la validation automatisée. C'est une question de préférence personnelle et de contexte projet.

❌ Anti-pattern 4 : Commits en Vrac

Pattern problématique (assez universel) : Travailler plusieurs heures, accumuler de nombreux changements, puis tout commit d'un coup.

Résultat :

• Historique illisible

• Impossible de revert proprement

• Review de PR difficile

Approche recommandée :

• Commits fréquents sur des unités logiques

• Utiliser /commits pour faciliter le groupement

• Fréquence suggérée : toutes les 20-30 minutes

Résultats Observés

Mesures sur 1 Mois d'Usage

Projet référence : SaaS client, stack Next.js 14 + Prisma + PostgreSQL

Feature development :

• Approche classique : 3-4 heures

• Avec ce setup : ~45 minutes

• Amélioration observée : ~4x

Bug fix :

• Approche classique : 30-45 minutes

• Avec ce setup : ~10 minutes

• Amélioration observée : ~4x

Refacto complexe :

• Approche classique : ~1 journée

• Avec ce setup : 2-3 heures

• Amélioration observée : ~3x

Setup nouveau projet :

• Approche classique : 2-3 heures

• Avec ce setup : ~30 minutes

• Amélioration observée : ~5x

Debug production :

• Approche classique : 1-2 heures

• Avec ce setup : 15-20 minutes

• Amélioration observée : ~5x

Note : Ces chiffres reflètent mon expérience personnelle sur des projets spécifiques. Vos résultats peuvent varier selon le type de projet, votre familiarité avec les outils, et votre workflow existant.

Investissement Initial

• Configuration initiale : ~2 jours (hooks, commands, ajustements)

• Maintenance : ~1 heure/mois

Le temps investi a été récupéré relativement rapidement dans mon cas.

Qualité du Code : Une Question Légitime

"Coder plus vite = coder moins bien ?"

Mon observation après plusieurs mois :

Ce qui s'améliore dans mon expérience :

• ✅ Conventions respectées (Claude suit les patterns existants)

• ✅ Tests inclus (quand explicitement demandés)

• ✅ Moins d'erreurs de typo/syntax

• ✅ Refactoring plus systématique

Ce qui demande attention :

• ⚠️ Parfois trop d'abstraction

• ⚠️ Edge cases à spécifier explicitement

• ⚠️ Optimisations prématurées possibles

Mon approche personnelle : Code review systématique. Je lis tout ce que Claude produit. Le workflow change :

• Avant : Je codais 80%, reviewais 20%

• Maintenant : Je review 80%, j'ajuste 20%

Le ratio est inversé, et dans mon cas, le temps total est réduit d'environ 75%.

Patterns Avancés

Contexte Persistant avec CLAUDE.md

Je place un fichier CLAUDE.md à la racine de chaque projet :

# Project: Client SaaS Platform

## Stack
- Next.js 14 (App Router)
- Prisma ORM
- PostgreSQL
- TailwindCSS + shadcn/ui
- Auth: NextAuth.js v5

## Conventions
- Composants : PascalCase dans src/components/
- API routes : kebab-case dans src/app/api/
- Types : types/ avec suffix .types.ts
- Tests : colocalisés avec .test.tsx

## Architecture
- Server Components par défaut
- Client Components uniquement si interactivité
- tRPC pour API type-safe
- Zod pour validation

## Points de vigilance
- Ne JAMAIS exposer les API keys
- Toujours valider inputs avec Zod
- Préférer Server Actions aux API routes

Bénéfice observé : Claude respecte généralement les conventions. Réduit la répétition des instructions.

Statusline Custom avec Coût en Temps Réel

Mon statusline affiche :

➜ marketing git:(main) ✗ model:(sonnet-4-5) 💰$0.23 ⏱2h

Informations affichées :

• Repo Git + branche + status

• Modèle actif

• Coût de la session (via ccusage)

• Temps restant estimé

Configuration complète disponible en annexe.

Ce que ça m'apporte : Conscience en temps réel du budget consommé.

Rewind pour Expérimentation

Une feature que je trouve utile : Rewind. Permet d'annuler toute une session.

Exemple d'usage : Tester deux approches différentes.

# Approche 1 : Microservices
$ c "refacto vers microservices"
# Claude bosse 10 minutes
# Test : pas convaincu

# Annule tout
$ claude --rewind

# Approche 2 : Monolith modulaire
$ c "refacto vers modules découplés dans le monolith"
# Claude bosse 10 minutes
# Test : meilleur ✅

Permet d'expérimenter sans multiplier les branches Git.

Ce Que Je Teste Actuellement

Git Worktrees :

• 1 worktree = 1 feature

• 1 Claude par worktree

• Isolation du contexte

Premiers tests intéressants pour les gros projets. Article dédié à venir.

Prompt Templates :

• Bibliothèque de prompts réutilisables

• Exemple : template "CRUD with validation + tests"

• Gain potentiel observé : ~1.5-2x sur tâches répétitives

Ressources

Documentation officielle :

• Claude Code Hooks Reference

• Claude Code Best Practices

Communauté :

• Reddit r/ClaudeAI

• GitHub: Awesome Claude Code

Outils :

• ccusage - Track token usage

• Hyper Terminal - Terminal multiplexé

• Context7 MCP - Official docs

Conclusion : L'Approche Minimaliste

Mon observation : En simplifiant le setup, j'ai souvent gagné en productivité.

Mon setup actuel :

• 1 MCP server (Context7)

• 3 customs commands (explore-and-plan, commits, auto-fix)

• 3 hooks (security, stop, notification)

• 2 aliases (c, cc)

C'est le résultat de plusieurs itérations, et ça fonctionne bien pour mon usage.

Principe que j'applique : Ne garder que ce qui réduit vraiment la friction au quotidien.

Ce que j'observe comme bénéfices :

• Vitesse : Features développées environ 4-5x plus rapidement dans mon cas

• Qualité : Code plus cohérent grâce aux conventions

• Focus : Moins de distractions

• Contrôle : Meilleure visibilité sur les opérations

Les compromis :

• Moins de features "intéressantes" à tester

• Configuration initiale qui prend du temps

Rappel important : C'est une approche parmi d'autres, pas la seule valide. Ce qui fonctionne pour moi ne conviendra pas forcément à votre contexte. Je vous encourage à expérimenter, ajuster, et trouver votre propre équilibre.

D'autres articles viendront explorer des approches complémentaires : git worktrees, prompt templates, workflows pour équipes, etc.

Notre Approche Chez Cod'Hash

Chez Cod'Hash, on a adapté ce type de workflow, et plein d’autres, à notre process de production. Notre approche :

• Livraison rapide grâce à l'automatisation et aux outils modernes

• Qualité senior (devs expérimentés + méthodologie éprouvée)

• Tarifs optimisés grâce à l'efficacité du process

Stack d’un Saas client type : Next.js, React, Node.js, Prisma, PostgreSQL, Fastify, Langchain.

Spécialités : MVP, SaaS, Apps mobiles, Blockchain, Intégration IA.

Si vous avez un projet web ou tech à développer :

👉 Réserver un call gratuit (30min)

📎 Annexes : Configuration Complète

A1 : settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "cleanupPeriodDays": 29,
  "permissions": {
    "allow": [
      "Bash", "Read", "Edit", "Write", "Glob", "Grep",
      "TodoWrite", "Task", "WebSearch", "WebFetch"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bun .claude/scripts/validateCommand.js"
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "afplay -v 0.5 .claude/song/endTask.mp3"
          }
        ]
      }
    ],
    "Notification": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "afplay -v 0.5 .claude/song/needHuman.mp3"
          }
        ]
      }
    ]
  },
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    }
  }
}

A2 : Aliases .zshrc

# Claude Code avec skip permissions
alias c='claude --dangerously-skip-permissions'
alias cc='claude --continue --dangerously-skip-permissions'

# Check usage restant
alias claudeleft='bunx ccusage blocks --json | jq -r ".blocks[] | select(.isActive == true) | \"Temps restant : \(.projection.remainingMinutes) min\nCoût actuel : \$\(.costUSD)\""'

A3 : Custom Command /explore-and-plan

~/.claude/commands/explore-and-plan.md :

---
description: Explore, plan, code, test following EPCT workflow
---

# Explore, Plan, Code, Test Workflow

Follow the EPCT workflow for the task at the end of this message.

## Explore
Use parallel subagents to find all relevant files, patterns, and architecture info.

## Plan
Write detailed implementation plan including tests and documentation.
If uncertain, use web research. Ask clarifying questions before proceeding.

## Code
Implement following existing codebase style.
Run autoformatting and fix reasonable linter warnings.

## Test
Run tests via parallel subagents. Ensure everything passes.
For UI changes, verify in browser.

## Write Up
Create PR description: what was done, key decisions, useful commands for future devs.

A4 : Custom Command /commits

~/.claude/commands/commits.md :

---
description: Analyze changes and create smart commits
---

# Smart Auto-Commits

## Workflow
1. Run `git status`, `git diff`, `git diff --cached` in parallel
2. Group changes: features, fixes, updates, refactor, config, docs
3. Generate concise messages: "add user validation", "fix redirect"
4. Execute commits in logical order (migrations first, then code, then docs)

## Message Style
Format: `action subject` (lowercase, no period)
Examples: "fix button redirect", "add oauth provider", "update api handler"

## Success Criteria
- All changes committed
- Atomic, logical commits
- Clear messages (no "WIP")
- Ready for push/PR

A5 : Custom Command /auto-fix

~/.claude/commands/auto-fix.md :

---
description: Auto-fix build and TypeScript issues with parallel processing
---

# Auto-Fix Build & TypeScript

## Workflow
1. Run `pnpm build` + `pnpm tsc` in parallel
2. Categorize: CRITICAL (build), HIGH (types), MEDIUM (warnings), LOW (style)
3. Launch parallel sub-agents (1 per issue)
4. Validate after each batch
5. Loop until zero errors

## Success Criteria
- `pnpm build` succeeds
- `pnpm tsc` shows no errors
- No regressions introduced