Combien de tokens consomme une session typique Claude Code ?

Une session de 1 heure sur Claude Sonnet 4.6 consomme typiquement 50 000 à 200 000 tokens input et 10 000 à 50 000 tokens output, soit environ 0,5 à 2 USD si API direct, inclus dans Claude Pro pour la majorité des cas modérés.

Comment annuler une opération en cours dans Claude Code ?

Ctrl+C interrompt l'agent. Pour reprendre : claude --resume ou nouvelle session avec contexte conservé selon configuration. La session principale conserve l'historique sauf si /clear est utilisé pour repartir du contexte vierge.

Claude Code tutoriel pratique : installation, workflows

📚 Cet article fait partie de notre cluster IA pour PME francophones. Pour le panorama complet (Claude vs GPT-5 vs Gemini vs Mistral, prompt engineering, RAG, agents, Ollama self-hosté, coûts en F CFA), consultez : IA et LLM pour PME francophones — panorama complet 2026.

Lecture : 16 minutes · Niveau : développeur intermédiaire · Mise à jour : avril 2026

Claude Code est passé en moins d’un an d’outil de niche à standard du développement IA-assisté. Selon les enquêtes 2026, c’est l’outil le plus aimé des développeurs (46 % « most loved ») devant Cursor (19 %) et Copilot (9 %). Sa philosophie : un agent qui vit dans votre terminal, lit votre codebase, modifie des fichiers, lance des tests, gère git — par dialogue en langage naturel. Ce tutoriel couvre toute la chaîne pratique : installation Node.js, premier projet, fichier CLAUDE.md, slash commands custom, sub-agents, hooks, MCP servers, plugins, et workflows réels pour freelance ou PME ouest-africaine.

Pour le contexte stratégique (panorama outils, choix par profil), voir le pillar AI coding développeur. Pour le comparatif outils, voir Cursor vs Copilot vs Claude Code. Pour les serveurs MCP, voir MCP tutoriel.

1. Prérequis et installation

Prérequis.

Système : macOS 13+ (Ventura), Ubuntu 20.04+/Debian 10+, ou Windows 10/11 (WSL2 ou natif PowerShell).
RAM : 4 Go minimum, 8 Go recommandés pour les gros dépôts.
Compte Anthropic sur claude.ai — Pro à 20 USD/mois (Claude Code limité), Max à 100 ou 200 USD/mois pour usage intensif. Alternative : compte API Anthropic avec carte (facturation au token).
Terminal : bash, zsh, fish, ou PowerShell.

Installation — Native Installer (recommandé depuis février 2026). Aucune dépendance (pas de Node.js requis), auto-update intégré, supporté officiellement par Anthropic.

Sur macOS et Linux, le binaire natif s’installe via un script shell signé Anthropic. Le script détecte la plateforme (Intel ou Apple Silicon, glibc ou musl), télécharge l’archive correspondante depuis l’infrastructure Anthropic, vérifie la signature, dépose le binaire dans ~/.local/bin/claude et ajoute un fragment à votre ~/.zshrc ou ~/.bashrc pour mettre à jour PATH :

curl -fsSL https://claude.ai/install.sh | bash

À la fin, le script affiche le chemin d’installation et la version posée. Si vous voyez une erreur command not found: claude dans le terminal courant, c’est que la session shell n’a pas rechargé son PATH — ouvrir un nouveau terminal ou exécuter source ~/.zshrc pour rattraper.

Sous Windows, l’équivalent passe par PowerShell. irm (alias de Invoke-RestMethod) télécharge le script d’installation, et iex (alias de Invoke-Expression) l’évalue directement dans la session. Ouvrir Windows Terminal en tant qu’utilisateur normal (pas administrateur, le binaire s’installe dans le profil utilisateur) :

irm https://claude.ai/install.ps1 | iex

Le script dépose claude.exe dans %LOCALAPPDATA%\Programs\claude et ajoute ce dossier au PATH utilisateur. Comme sous Unix, il faut ouvrir un nouveau Terminal pour que la commande claude soit reconnue. Si vous obtenez execution policy bloquée, lancer une fois Set-ExecutionPolicy -Scope CurrentUser RemoteSigned avant la commande d’installation.

Si vous gérez déjà votre poste avec Homebrew, WinGet ou Scoop, vous pouvez passer par votre gestionnaire de paquets habituel. L’avantage : la mise à jour de Claude Code suit le rythme de brew upgrade ou winget upgrade, sans bin secondaire à entretenir. L’inconvénient : il y a souvent un décalage d’un à trois jours par rapport à la sortie officielle Anthropic.

# macOS / Linux (Homebrew)
brew install --cask claude-code

# Windows (WinGet)
winget install Anthropic.ClaudeCode

Installation — méthode npm (dépréciée). Encore documentée pour transition mais Anthropic conseille de migrer. Si vous l’aviez via npm, exécutez claude install pour basculer sur le binaire natif.

# Déconseillé en 2026
npm install -g @anthropic-ai/claude-code

Une fois l’installation terminée, on confirme que le binaire est bien dans le PATH et qu’il répond. La commande renvoie une ligne unique du type claude version 1.x.y (build YYYY-MM-DD) et rend la main immédiatement :

claude --version

Si la commande se bloque, affiche une erreur réseau ou renvoie un numéro de version antérieur à 1.0, c’est qu’un ancien binaire npm cohabite dans le PATH avant le natif — désinstaller le paquet npm (npm uninstall -g @anthropic-ai/claude-code) et rouvrir un terminal.

Au premier lancement, Claude Code n’a aucune clé. On démarre simplement la commande dans n’importe quel dossier : l’agent détecte qu’aucune authentification n’est en place et déclenche le flux d’enrôlement.

claude

L’écran affiche deux choix, à sélectionner avec les flèches du clavier puis Entrée :

Au premier lancement, choisir :

Login Claude Pro/Max (recommandé pour démarrer) : ouvre un navigateur pour OAuth.
API Key Anthropic : coller la clé depuis console.anthropic.com.

Mise à jour. Le Native Installer s’auto-update en arrière-plan toutes les 24 heures, sans relancer le shell. Pour forcer une mise à jour immédiate (utile après une annonce de release Anthropic ou pour récupérer un fix de sécurité) :

claude update

La commande affiche la version installée et la dernière disponible, télécharge le delta si différent, et signale Already up to date sinon. Aucun redémarrage du shell n’est nécessaire — la session en cours continue d’utiliser l’ancien binaire, les sessions suivantes basculent automatiquement.

Pour retirer complètement Claude Code (changement de poste, nettoyage d’un environnement de test), supprimer le binaire ne suffit pas : le dossier ~/.claude contient l’historique, les sessions, les configurations MCP et les éventuelles clés API. Voici la séquence complète à exécuter dans l’ordre :

# Native Installer
claude uninstall
rm -rf ~/.claude

# Ancienne installation npm
npm uninstall -g @anthropic-ai/claude-code

2. Premier lancement et permissions

Une fois authentifié, Claude Code travaille toujours dans un dossier — il lit, écrit et lance des commandes dans le répertoire courant. La règle d’or : se positionner dans la racine du projet (là où vivent package.json, composer.json, pyproject.toml ou équivalent) avant de lancer la commande. L’agent en hérite, ce qui lui donne automatiquement la bonne portée d’exploration.

cd ~/projets/mon-app
claude

Au lancement, l’invite affiche le dossier courant (avec un raccourci ~ pour le home), la branche Git, le modèle actif (Sonnet ou Opus) et un prompt vide >. C’est là que tout démarre. Pour valider que l’installation comprend bien votre projet sans modifier un seul fichier, on commence par une lecture-seule :

> Décris-moi ce projet en 5 lignes

Claude Code ouvre package.json ou son équivalent, parcourt README, regarde la structure des dossiers (src, tests, docs), puis produit un résumé en quelques lignes : stack technique, type d’application, points d’entrée. C’est aussi le moment où il demande la permission de lire chaque fichier — premiers prompts Allow read on README.md?. Répondre y pour autoriser, ou a pour autoriser pour toute la session.

Il lit les fichiers clés (package.json, README, structure), produit une synthèse. Test simple pour valider la fluidité.

Permissions. Claude Code demande confirmation avant chaque opération potentiellement risquée (modification fichier, exécution commande shell). Trois modes :
– Default (recommandé débutant) : confirmation à chaque tool sensible.
– Allow rules : whitelist par patterns (ex. Bash(git status) toujours autorisé).
– --dangerously-skip-permissions : autonomie totale, à réserver à sandbox/CI ou prompt très précis.

Configurer les permissions persistantes.
Fichier ~/.claude/settings.json (global) ou .claude/settings.json (projet) :

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git log:*)",
      "Bash(npm test:*)",
      "Read",
      "Grep",
      "Glob"
    ]
  }
}

Une fois ce fichier en place, Claude Code charge les patterns au lancement et ne demande plus confirmation pour les commandes listées. La liste s’enrichit naturellement au fil des sessions — quand vous validez une commande deux ou trois fois, ajoutez-la ici pour la session suivante. Attention à ne pas pré-approuver d’opérations destructives comme Bash(rm -rf *) ou Bash(git push --force), qui restent à confirmer manuellement.

Modes utiles.
– Plan mode (/plan) : Claude propose un plan d’exécution sans modifier les fichiers, on valide ou ajuste avant exécution.
– Fast mode (/fast) : modèle plus rapide pour tâches simples.
– Default mode : équilibre qualité/vitesse, modèle Sonnet 4.6 typiquement.

3. Fichier CLAUDE.md : le contexte projet

C’est la clé du succès avec Claude Code. À la racine du projet, créer CLAUDE.md qui documente :
– Stack technique (langages, frameworks, versions).
– Conventions de code (tests, linting, naming).
– Architecture générale (structure dossiers, patterns).
– Contraintes (à éviter, à privilégier).
– Contexte métier minimal.

Concrètement, CLAUDE.md est lu une fois par l’agent au démarrage de chaque session et reste dans son contexte pour toute la conversation. C’est donc le point unique où vous concentrez les informations qui orientent ses choix : la stack et ses versions exactes, les conventions de code spécifiques au projet, les contraintes business à respecter (RGPD, paiement mobile, langue de l’UI), et les commandes que vous lancez vraiment au quotidien. Sans ce fichier, l’agent doit deviner — avec des inférences souvent justes mais parfois coûteuses (mauvaise version de framework détectée, conventions ignorées, lib réinstallée alors qu’elle existe déjà). Exemple CLAUDE.md PME ouest-africaine WordPress + WooCommerce :

# Projet : boutique-dakar.sn

## Stack
- WordPress 6.7 + WooCommerce 9.x
- PHP 8.2, MariaDB 10.11
- Hébergement Hetzner CX23 (Allemagne)
- Tests : PHPUnit pour code custom, browser tests via Playwright

## Conventions
- Plugins custom dans `wp-content/plugins/dakar-*`
- Pas de modification core WordPress.
- Hooks et filters préférés à override.
- Code commenté en français, identifiers en anglais.
- Toutes les nouvelles fonctions doivent avoir un test PHPUnit.

## Patterns à éviter
- Pas de jQuery (vanilla JS uniquement).
- Pas de `eval()`, pas de `dynamic SQL` sans préparation.
- Pas de plugin payant inutile.

## Patterns privilégiés
- Caching via Redis (déjà configuré).
- Lazy loading images via attribut natif.
- Optimisation pour 3G mobile (cluster #4).

## Contexte métier
- E-commerce artisanat sénégalais avec paiements Wave / Orange Money / carte CB.
- Cibles : diaspora + clients locaux Dakar.
- Multilingue FR (principal) + EN (secondaire).

## Workflows habituels
- Pull request via GitHub Actions, déploiement automatisé.
- Backup quotidien via WP-CLI cron.

Avec ce contexte, Claude Code génère du code aligné dès la première itération. Ne pas négliger ce fichier — c’est l’investissement à plus haut ROI.

Hiérarchie multi-fichiers. Possible d’avoir CLAUDE.md à plusieurs niveaux :
– Racine projet : contexte général.
– Sous-dossier (ex. app/api/CLAUDE.md) : contexte spécifique backend.
– ~/.claude/CLAUDE.md : préférences globales utilisateur (ton, langue, format).

Claude Code lit hiérarchiquement (le plus spécifique gagne).

4. Workflows quotidiens

Premier réflexe quand vous arrivez sur un projet inconnu (audit, repas, mission ponctuelle) : faire lire la codebase par l’agent et lui demander une cartographie. C’est plus rapide qu’une lecture séquentielle, et l’agent restera ensuite contextuellement informé pour les questions suivantes.

Workflow 1 : exploration de codebase (5 à 15 minutes selon la taille).

> Lis tout le dossier src/auth et explique-moi le flow d'authentification
> Quels middlewares sont appliqués sur les routes /admin/* ?
> Trouve où est géré le rate limiting

L’agent ouvre les fichiers concernés un par un, montre les extraits pertinents avec numéros de ligne, et synthétise. Vous repartez avec un schéma mental précis sans avoir lu une seule ligne vous-même — utile en revue d’architecture ou en passation.

Workflow 2 : ajout d’une feature simple (15 à 45 minutes). Pour une feature isolée — endpoint REST, validation de formulaire, écran d’admin — l’agent gère le cycle complet : lecture des conventions du projet via CLAUDE.md, génération du code, ajout des tests, exécution de la suite. La condition de succès : être assez précis sur les contraintes (route, méthode HTTP, format de retour) pour éviter les itérations correctives.

> Ajoute un endpoint POST /api/users/avatar qui accepte un upload image, le stocke sur S3, met à jour le profil utilisateur. Génère le test PHPUnit correspondant.

Claude Code propose d’abord un plan textuel (fichiers à créer ou modifier, librairies à ajouter), attend confirmation, puis exécute. Chaque écriture passe par un diff visible avant validation. À la fin, la suite de tests tourne automatiquement et le rapport pass/fail est affiché. En cas d’échec, l’agent propose un correctif sans repartir de zéro.

Cette boucle propose un plan, demande confirmation, modifie les fichiers, lance les tests, présente le diff. Reviewer puis commit.

Workflow 3 : refactoring multi-fichiers (30 à 90 minutes). Renommage massif, extraction de module, mise à jour d’API interne — ce sont les tâches où la cohérence transversale compte plus que la créativité. L’agent y excelle à condition d’avoir un objectif net et des tests qui couvrent les usages.

> Renomme la fonction calculateTotal en computeOrderTotal partout dans le projet, mets à jour les tests, et vérifie qu'il n'y a pas de régression.

L’agent identifie tous les appels (déclaration + imports + usages + commentaires + docstrings), modifie chaque fichier dans un commit logique, et relance la suite de tests. Si un appel échappe à la détection (chaîne dans un YAML de config, template Twig, ressource de traduction), il sera révélé par l’échec d’un test ou par une vérification statique. Astuce : commencer par un git status propre pour pouvoir git diff tranquillement à la fin.

Workflow 4 : debug ciblé (5 à 30 minutes). Quand un test échoue ou qu’un comportement diverge, fournissez à l’agent le pointeur précis (fichier + ligne + message d’erreur). Sa force est de lire en arrière à partir de la stack trace, pas de deviner.

> Ce test échoue : tests/checkout.test.js:45. Lis le code testé, identifie la cause, propose un fix.

L’agent suit l’enchaînement : lecture du test, identification de la fonction sous test, lecture de cette fonction, hypothèse sur la cause, proposition d’un correctif minimal accompagné d’un test supplémentaire pour couvrir le cas. Vous validez le diff, le test repasse au vert.

Workflow 5 : générer des tests sur du code legacy (20 à 60 minutes). Sur une base sans aucun test, l’agent peut couvrir un module isolé en quelques itérations. Il lit le code, devine les contrats, écrit les cas nominaux puis les cas limites. Vous gardez la main pour valider les comportements ambigus.

> Lis lib/legacy/payment.php (300 lignes sans test) et génère un set de tests PHPUnit qui couvre les cas critiques.

Output type : un fichier PaymentTest.php avec une vingtaine de cas (montants nuls, devises non supportées, échec gateway, double charge). L’agent stub les dépendances réseau et signale dans son rapport final les zones du code qui restent suspectes ou non couvrables sans refactor.

Workflow 6 : DevOps et CI (15 à 45 minutes). Génération de workflows GitHub Actions, GitLab CI, Bitbucket Pipelines à partir d’une spec en langage naturel. L’agent connaît la syntaxe des principales plateformes et adapte selon les indices détectés dans le repo (présence de composer.json, package.json, Dockerfile).

> Crée un workflow GitHub Actions qui lance les tests PHPUnit + Playwright sur PR ouverte, et notifie sur Slack si échec.

L’agent produit le YAML dans .github/workflows/, ajoute les secrets nécessaires (avec un commentaire indiquant lesquels créer dans GitHub Settings), et propose une matrice de versions si pertinent. Toujours relire le fichier avant push — c’est le seul endroit où une mauvaise indentation casse silencieusement la pipeline.

Workflow 7 : documentation (10 à 30 minutes). Génération de README, ADR, docs API. L’agent compose à partir du code et des commentaires existants — la qualité dépend directement de celle de ces deux sources.

> Génère le README.md de ce projet en français en lisant package.json, structure, et les commentaires existants.

Résultat type : README structuré (badges, install, usage, scripts npm, contributing, license) en français. L’agent évite les hallucinations : si un script est inconnu, il pose la question avant de l’inventer dans la doc. Pratique pour démarrer une documentation utile en quelques minutes plutôt que de la repousser éternellement.

Workflow 8 : migration de framework (2 à 8 heures, à découper en sessions). Mise à jour majeure de framework, passage Vue 2 → Vue 3, Laravel 10 → 11, Symfony 6 → 7. L’agent suit le changelog officiel, applique les breaking changes par paquets, lance les tests entre chaque batch. À éviter sans suite de tests ou sans branche dédiée.

> Migre ce projet de Laravel 10 vers Laravel 11. Identifie les breaking changes, applique-les un par un, lance les tests après chaque batch.

L’agent ouvre l’upgrade guide Laravel officiel, dresse la liste des changements applicables au projet, et exécute par groupes logiques (changements de signature, déprécations, structure de config). Chaque groupe est suivi d’un php artisan test automatique. À la fin, vous recevez un récap avec les groupes appliqués et ceux laissés en suspens (typiquement les changements qui touchent du code custom à arbitrer manuellement).

Mode plan recommandé sur tâches longues : claude /plan pour faire valider la stratégie avant action.

5. Slash commands custom

Slash commands = templates de prompts réutilisables, accessibles via /<nom>.

Slash commands built-in.
– /help : aide.
– /clear : reset contexte session.
– /plan : mode plan.
– /fast : mode rapide.
– /compact : compresser l’historique.

Créer un slash command custom.
Un slash command custom est simplement un fichier Markdown placé dans .claude/commands/ (au niveau projet, partagé via git) ou ~/.claude/commands/ (global, personnel). Le nom du fichier devient le nom du slash command : test-coverage.md donne /test-coverage. La structure d’un fichier comporte un front-matter YAML pour la description et un corps Markdown qui sert de prompt — la variable $ARGUMENTS est remplacée au moment de l’invocation par ce que tape l’utilisateur après le slash command. Exemple — fichier .claude/commands/test-coverage.md au niveau projet :

---
description: Génère ou met à jour les tests PHPUnit pour atteindre 80% de couverture sur le module ciblé.
---

Lis le module suivant : $ARGUMENTS

Étapes :
1. Identifie les fonctions publiques sans test ou avec couverture < 80 %.
2. Génère les tests PHPUnit correspondants en respectant les conventions du projet (voir CLAUDE.md).
3. Lance la suite de tests pour valider.
4. Présente un rapport de couverture.

À l’usage, on tape simplement le slash command suivi de l’argument. Claude Code lit le fichier test-coverage.md, substitue $ARGUMENTS et exécute le prompt comme s’il avait été tapé. Aucun reload du contexte n’est nécessaire entre deux invocations. Exemple :

/test-coverage src/payment/processor.php

Slash commands utiles à créer.
– /review : review de la dernière commit.
– /security-audit : audit sécurité du module ciblé.
– /migrate-to : migration framework guidée.
– /docstring : ajout docstrings sur fonctions publiques.
– /translate-comments : traduire commentaires anglais → français.

Slash commands globaux.
Mettre les fichiers .md dans ~/.claude/commands/ pour disponibilité tous projets.

6. Sub-agents pour parallélisation

Concept. Sub-agent = mini-Claude lancé en parallèle pour une tâche isolée, avec son propre contexte. Permet de paralléliser et de protéger le contexte principal.

Sub-agents built-in.
– Explore : recherche dans codebase, isolé.
– Plan : architecture / planning sans modifier fichiers.

Créer un sub-agent custom.
Un sub-agent est un agent secondaire avec son propre périmètre, ses propres outils autorisés et son propre prompt système. Utile pour isoler une tâche bien définie (lancer les tests, générer un rapport, valider une migration) et la déléguer en parallèle pendant que l’agent principal continue sur autre chose. Les sub-agents vivent dans .claude/agents/ (projet) ou ~/.claude/agents/ (global). Le front-matter YAML déclare le nom, le modèle (Sonnet rapide ou Opus pour les tâches complexes) et la liste des outils auxquels il a accès. Exemple — fichier .claude/agents/test-runner.md :

---
name: test-runner
description: Spécialiste lancement et debug de tests
tools: Bash, Read, Grep
---

Tu es un agent spécialisé dans :
- Lancer la suite de tests appropriée selon le projet (npm test, pytest, phpunit, go test, cargo test).
- Identifier les tests qui échouent.
- Lire le code testé pour diagnostiquer.
- Proposer un fix ciblé.

Tu n'écris jamais de feature : uniquement tests et fixes liés.

Lancement depuis Claude Code principal :

> Lance test-runner sur ce projet, identifie les échecs, propose des fixes

Le sub-agent s’exécute, retourne un rapport.

Sub-agents utiles à créer.
– code-reviewer : review code style, sécurité.
– performance-auditor : profile et propose optimisations.
– doc-generator : génère docs API.
– migration-helper : migration framework spécifique.

Limites. Les plugins-subagents (de plugins partagés) ont des restrictions sécurité (pas de hooks, pas de mcpServers configurables).

7. Hooks pour qualité et automatisation

Concept. Hooks = scripts shell déclenchés sur événements (pre-tool, post-tool, on-stop).

Configuration. Fichier ~/.claude/settings.json ou .claude/settings.json. Les hooks Claude Code se déclenchent à des moments précis du cycle de vie d’une session : PreToolUse avant chaque appel d’outil (utile pour bloquer une commande dangereuse), PostToolUse après (utile pour relancer des tests ou des linters automatiquement), UserPromptSubmit à chaque nouveau prompt utilisateur, Stop à la fin de la session. Chaque hook exécute une commande shell — son code de retour décide si l’opération de Claude Code se poursuit ou s’interrompt :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'About to modify file'"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/run-linter.sh"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/notify-done.sh"
          }
        ]
      }
    ]
  }
}

Cas d’usage hooks.
– PostToolUse Edit/Write → lancer prettier/eslint, refuser commit si non conforme.
– PreToolUse Bash → bloquer commandes dangereuses (rm -rf /).
– Stop → notification desktop, Slack, ou email quand l’agent finit.

Exemple hook bloquant.
Le hook ci-dessus appelle un script shell check-tests.sh qui reçoit en stdin le contexte JSON (outil utilisé, fichier modifié) et doit renvoyer un code 0 pour continuer ou non-nul pour bloquer. Pour relancer la suite de tests dès qu’un fichier source change — fichier .claude/hooks/check-tests.sh :

#!/bin/bash
if [ -f "package.json" ]; then
  npm test --silent
  if [ $? -ne 0 ]; then
    echo "Tests failed, blocking commit"
    exit 2
  fi
fi
exit 0

Exit code 2 = bloquant, le message va à Claude qui peut réagir.

8. MCP servers : intégrations clés

Les serveurs MCP (Model Context Protocol) sont des processus externes que Claude Code lance au démarrage et qui exposent des outils supplémentaires — interroger une base PostgreSQL, lire des issues GitHub, consulter Notion, déclencher un workflow Linear. Chaque serveur déclare ses propres outils, Claude Code les voit comme des extensions natives au même titre que Bash ou Read. La configuration vit dans .mcp.json au niveau projet (partage les serveurs avec l’équipe via git, recommandé pour les sources de données du projet) ou dans ~/.claude.json en global (pour vos serveurs personnels). Chaque entrée précise la commande de lancement, ses arguments et les variables d’environnement nécessaires.

MCP (Model Context Protocol) connecte Claude Code à des outils externes : bases de données, GitHub, Slack, navigateurs, etc.

Configuration. Fichier .mcp.json à la racine du projet :

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://user:pass@localhost/mydb"]
    }
  }
}

Après modification du fichier, Claude Code charge les serveurs déclarés au prochain démarrage. La vérification se fait directement dans une session : on demande à l’agent la liste des outils disponibles, qui comprend désormais les outils exposés par chaque serveur MCP (préfixés par leur nom de serveur). Exemple :

> Quels outils MCP sont disponibles ?

Serveurs MCP utiles.
– filesystem : navigation fichiers.
– github : issues, PR, branches.
– postgres / sqlite : bases de données.
– puppeteer : automation navigateur.
– slack : messaging équipe.
– brave-search : recherche web.

Voir tutoriel détaillé MCP servers.

9. Plugins partagés

Concept. Plugin = bundle réutilisable contenant slash commands, sub-agents, hooks, MCP servers, configs.

Installation. Via marketplace Anthropic ou repos GitHub partagés (awesome-claude-code-plugins).

Plugins utiles 2026.
– php-wordpress : commands PHPUnit, WP-CLI, conventions.
– nextjs-vercel : déploiements, optimisations.
– python-django : migrations, tests, Django Admin.
– devops-kubernetes : kubectl, helm, monitoring.
– freelance-toolkit : facturation, tracking temps.

Créer un plugin.
1. Créer dossier mon-plugin/ avec structure : commands/, agents/, hooks/, plugin.json.
2. Documenter dans README.md.
3. Pousser sur GitHub.
4. Partager : autres devs ajoutent via claude plugins install <repo>.

10. Gestion des coûts et plans

Plans Anthropic 2026.
– Claude Free : usage limité, pas adapté Claude Code régulier.
– Claude Pro ($20/mo) : Claude Code inclus avec quota suffisant pour usage modéré.
– Claude Max ($100-200/mo) : usage intensif, modèles plus rapides, priorité.
– API Direct : facturation au token (Sonnet $3/MTok input, $15 output ; Opus $15/MTok input, $75 output environ — vérifier prix actuels).

Comparaison usages réels.
– 10 h/semaine, modèle Sonnet : ~5-15 USD/mois si API direct, couvert par Claude Pro.
– 30 h/semaine, modèle Sonnet : ~30-80 USD/mois API, ou plan Max.
– Power user (Opus + Sonnet, 40+ h/semaine) : 100-300 USD/mois API direct ou Max.

Conseils économie tokens.
– /clear régulier pour limiter contexte historique.
– /compact pour résumer.
– Sub-agents pour isoler tâches lourdes (contexte propre).
– Mode /fast quand simple suffit.
– --max-tokens flag pour limiter output.

Monitoring.
– Dashboard Anthropic console.anthropic.com (si API direct).
– Stats quotidien/mensuel.
– Alertes spending limit recommandé (50 USD/mo, 200 USD/mo selon profil).

11. Pièges fréquents

Quelques erreurs reviennent systématiquement sur les premières semaines d’usage de Claude Code. Les connaître évite de perdre une demi-journée à débugger un comportement qui n’est pas un bug mais une mauvaise configuration. Check-list à parcourir mentalement quand quelque chose part de travers :

Lancer Claude Code dans /home ou /. Permission immense, contexte énorme. Toujours cd dans le projet précis avant claude.

Pas de CLAUDE.md. L’agent reproduit les anti-patterns du code existant ou invente des conventions. Investir 30 min pour rédiger CLAUDE.md = ROI immédiat.

Accepter chaque diff sans lire. Bugs production garantis sur logique métier. Toujours lire les changements avant commit.

Skip permissions sans sandbox. --dangerously-skip-permissions en prod ou sur projet réel = potentiellement destructif. Réserver à CI/sandbox.

Sub-agents en spam. Ouvrir 10 sub-agents pour 1 tâche = facturation explose. Utiliser quand vraiment justifié.

Hooks mal écrits. Un hook bloquant qui crash empêche tout. Tester hooks isolément avant déploiement.

Secrets en plain. Tokens GitHub, API keys dans .mcp.json versionné = leak garanti. Utiliser .env + .gitignore.

Ignorer les MCP servers. Ne pas connecter Claude Code à votre DB / GitHub = sous-utiliser massivement l’outil.

Pas de slash commands custom. Re-typer le même prompt 50 fois = perte de temps. Slashifier ce qui se répète.

Mises à jour ignorées. Claude Code évolue vite. claude update mensuel pour rester à jour.

FAQ

Les questions les plus fréquentes reçues en formation et en mission, avec des réponses courtes alignées sur la pratique réelle de l’outil en 2026 :

Claude Code fonctionne-t-il sous Windows ?

Oui depuis 2025. Soit en natif PowerShell ou bash, soit via WSL2 (recommandé pour fluidité Unix). Installation identique : npm install -g @anthropic-ai/claude-code.

Faut-il connaître le terminal pour utiliser Claude Code ?

Niveau basique requis : cd, ls, git. Pas besoin d’être expert sysadmin. La courbe d’apprentissage est de 1-2 semaines pour fluidité.

Combien de tokens consomme une session typique ?

Une session de 1h sur Claude Sonnet 4.6 consomme typiquement 50 000-200 000 tokens input, 10 000-50 000 output, soit environ 0,5-2 USD si API direct, inclus dans Claude Pro pour la majorité des cas.

CLAUDE.md doit-il être committé ?

Oui, dans le repo du projet. C’est partie intégrante de la doc projet. Il bénéficie à toute l’équipe utilisant Claude Code.

Peut-on utiliser plusieurs comptes Anthropic en parallèle ?

Oui via variables d’environnement ANTHROPIC_API_KEY ou commande claude login pour switcher. Utile pour séparer comptes perso/pro.

Claude Code fonctionne-t-il offline ?

Non, l’inférence est cloud. Pour usage offline : modèles locaux via Ollama + outils comme Aider ou Continue.dev avec backends locaux.

Comment annuler une opération en cours ?

Ctrl+C interrompt l’agent. Pour reprendre : claude --resume ou nouvelle session avec contexte conservé selon configuration.

Où trouver des plugins Claude Code ?

GitHub repos awesome-claude-code et awesome-claude-code-plugins maintenus par la communauté. Marketplace officiel Anthropic en construction en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer).

Articles liés (cluster AI coding)

Voir aussi : Devenir freelance développeur AO, DevOps moderne PME guide, GitHub Actions CI/CD tutoriel PME.

Article mis à jour le 26 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.

Claude Code tutoriel pratique : installation, workflows, sub-agents