Claude Code : le tutoriel complet, de l'installation aux sous-agents

Claude Code est l'agent de programmation d'Anthropic : il lit un projet, modifie des fichiers et exécute des commandes à votre place, depuis un terminal, un éditeur (VS Code ou JetBrains), l'application de bureau ou le navigateur. Ce tutoriel couvre tout le parcours, de l'installation aux automatisations, avec des commandes vérifiées dans la documentation officielle le 13 septembre 2026.

L'outil change souvent. Si une commande ne se comporte pas comme décrit ici, la documentation fait foi, et claude doctor aide à comprendre ce qui cloche.

De quoi a-t-on besoin pour utiliser Claude Code ?

• Un compte : un abonnement Claude Pro, Max, Team ou Enterprise, un compte Claude Console facturé à l'usage, ou un accès par un fournisseur cloud (Amazon Bedrock, Google Cloud, Microsoft Foundry).

• Un système récent : macOS 13 ou plus, Windows 10 version 1809 ou Windows Server 2019 et plus, Ubuntu 20.04, Debian 10 ou Alpine Linux 3.19 et plus.

• Une machine modeste : 4 Go de mémoire vive, un processeur x64 ou ARM64 et une connexion Internet suffisent, car les modèles tournent chez Anthropic et non sur votre ordinateur.

• Un projet sous Git, fortement conseillé : c'est votre filet de sécurité si une modification tourne mal.

Comment installer Claude Code ?

Sur macOS, Linux et WSL, l'installateur officiel tient en une ligne :

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

Sous Windows, dans PowerShell :

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

Deux autres voies existent. Avec Homebrew, brew install --cask claude-code : cette version ne se met pas à jour seule, il faut lancer brew upgrade claude-code. Avec npm, npm install -g @anthropic-ai/claude-code demande Node.js 22 ou plus récent depuis la version 2.1.198, et installe en réalité le même binaire natif.

L'installation native se met à jour automatiquement en arrière-plan. En cas de doute, claude doctor affiche l'état de l'installation et les erreurs de configuration, sans ouvrir de session.

Première session : se connecter et commencer par lire

cd ~/projets/mon-application
claude

Au premier lancement, Claude Code ouvre le navigateur pour vous connecter ; la commande /login permet de changer de compte plus tard. Si la variable d'environnement ANTHROPIC_API_KEY est définie, l'outil propose de l'utiliser à la place.

Faites d'abord lire le projet avant de le modifier. Une question comme « explique-moi l'architecture de ce dépôt et comment lancer les tests » ne touche à aucun fichier. Pour désigner un fichier précis, préfixez son chemin par @ : Claude le lit avant de répondre.

Quelques commandes servent en permanence :

• Échap : interrompt Claude en pleine action, sans perdre le contexte, pour le réorienter.

• Échap deux fois, ou /rewind : ouvre le menu des points de restauration, pour revenir à un état antérieur de la conversation, du code, ou des deux.

• /clear : repart d'un contexte vide entre deux tâches sans rapport.

• /compact : résume l'historique pour libérer de la place, avec une consigne si besoin (« /compact garde les décisions sur l'API »).

• /model : change de modèle en cours de session.

• /usage : affiche la consommation de la session et, pour les abonnés, l'état des limites du forfait.

Le fichier CLAUDE.md : la mémoire du projet

Chaque session repart d'un contexte neuf. Deux mécanismes font le lien : les fichiers CLAUDE.md, que vous écrivez et qui sont chargés au début de chaque session, et la mémoire automatique, activée par défaut, où Claude note lui-même ce qu'il retient de vos corrections.

La commande /init génère un premier CLAUDE.md en analysant le code : commandes de build, lancement des tests, conventions repérées. S'il en existe déjà un, elle propose des améliorations au lieu de l'écraser.

Trois emplacements se complètent :

• ~/.claude/CLAUDE.md : vos préférences personnelles, valables pour tous vos projets.

• ./CLAUDE.md (ou ./.claude/CLAUDE.md) : les consignes du projet, versionnées dans Git et partagées avec l'équipe.

• ./CLAUDE.local.md : vos réglages propres à ce projet, à ajouter au .gitignore.

Un CLAUDE.md peut importer d'autres fichiers avec la syntaxe @chemin/du/fichier. La documentation sur la mémoire recommande de rester sous 200 lignes par fichier : au-delà, les consignes occupent du contexte et sont moins bien suivies. Exemple minimal :

# Mon application

## Commandes
- Installer : npm install
- Tests : npm test (à lancer après chaque modification)
- Types : npm run typecheck

## Conventions
- TypeScript strict, pas de `any`
- Tous les appels réseau passent par src/lib/api.ts

## Pièges
- Ne jamais modifier une migration déjà appliquée dans drizzle/

Ce qu'il ne faut pas y mettre : ce que Claude peut déduire en lisant le code, les conventions standard du langage, les longues explications. Chaque ligne coûte du contexte, à chaque session.

Modes de permission : qui valide chaque action ?

Claude Code peut lire, écrire et exécuter. Le mode de permission décide de ce qu'il fait sans vous demander. On passe de l'un à l'autre avec Maj+Tab, et la barre d'état affiche le mode actif.

• Manuel (default) : seules les lectures sont libres ; chaque modification de fichier, commande ou accès réseau demande votre accord.

• acceptEdits : les modifications de fichiers et les commandes courantes de manipulation de fichiers (mkdir, touch, mv, cp…) passent sans demander.

• plan : Claude explore et propose un plan, mais ne modifie rien tant que vous ne l'avez pas approuvé.

• auto : les actions passent, mais un second modèle, le classifieur, les examine en arrière-plan et bloque celles qui semblent risquées. C'est le mode de départ des abonnements Pro, Max et Team.

• dontAsk : seuls les outils préautorisés fonctionnent, tout ce qui demanderait une validation est refusé. Pensé pour l'intégration continue.

• bypassPermissions : plus aucune vérification. La documentation des modes le réserve aux conteneurs et aux machines virtuelles isolés.

Préautoriser et interdire des commandes

Les règles se déclarent dans un fichier settings.json : ~/.claude/settings.json pour vous, .claude/settings.json pour le projet, et .claude/settings.local.json pour vos réglages locaux. Cet exemple laisse passer les scripts npm et les commits, mais bloque les push et la lecture du fichier .env :

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

Les règles d'interdiction s'appliquent dans tous les modes, bypassPermissions compris. Mais elles comparent la commande telle qu'elle est écrite : la documentation des permissions précise qu'un « git -C . push » échappe à la règle ci-dessus. Pour une restriction qui doit vraiment tenir, il faut le bac à sable (/sandbox), qui isole le système de fichiers et le réseau.

La méthode qui marche : explorer, planifier, coder, vérifier

Les bonnes pratiques publiées par Anthropic recommandent de séparer la réflexion de l'exécution :

• Explorer en mode plan (Maj+Tab, un message préfixé par /plan, ou claude --permission-mode plan) : Claude lit les fichiers concernés sans rien toucher.

• Planifier : demandez un plan détaillé, corrigez-le, puis approuvez-le ; Claude sort alors du mode plan.

• Coder en le laissant suivre le plan approuvé.

• Vérifier : l'étape qu'on oublie. Donnez-lui un moyen de savoir s'il a réussi (une suite de tests, un build, un linter) et demandez-lui de montrer la sortie plutôt que d'affirmer que tout fonctionne.

Pour une correction d'une ligne, le plan est superflu : la documentation suggère de s'en passer quand on peut décrire la modification en une phrase.

La précision de la demande change tout. « Accélère la page des factures » laisse Claude deviner. « La page /factures met huit secondes à charger en production ; mesure d'abord les requêtes SQL lancées par src/billing/list.ts, propose une correction, puis prouve le gain avec le script bench/factures.ts » lui dit où chercher et à quoi ressemble la réussite.

Quand ça part de travers, Échap arrête l'action et Échap deux fois revient en arrière. Si vous avez déjà corrigé Claude plus de deux fois sur le même point, la documentation conseille de lancer /clear et de reformuler : une session propre avec une meilleure consigne fait presque toujours mieux qu'une longue session encombrée d'essais ratés.

Contexte, modèles et coût : comment garder la main sur la facture ?

Chaque message renvoie l'historique de la session au modèle. Plus la conversation s'allonge, plus elle coûte et moins elle est fiable : Anthropic indique que les performances se dégradent à mesure que la fenêtre de contexte se remplit, Claude pouvant alors oublier des consignes données plus tôt.

• Une tâche, une session : /clear entre deux sujets sans rapport.

• Le bon modèle : /model sonnet pour le quotidien, /model opus pour le raisonnement complexe, /model haiku pour les tâches simples, /model fable pour les tâches les plus longues quand Fable est disponible, et opusplan pour planifier avec Opus puis exécuter avec Sonnet. Par défaut, Max, Team Premium et Enterprise démarrent sur Opus 5, Pro et Team Standard sur Sonnet 5.

• Moins de réflexion quand elle est inutile : le raisonnement étendu est activé par défaut et ses jetons sont facturés comme des jetons de sortie ; /effort permet d'en baisser le niveau pour les tâches simples.

• Des consignes chargées à la demande : ce qui ne sert qu'occasionnellement va dans un skill plutôt que dans CLAUDE.md.

Pour fixer les ordres de grandeur, Anthropic indique sur sa page consacrée aux coûts une moyenne d'environ 13 dollars par développeur et par jour d'activité sur les déploiements en entreprise, soit 150 à 250 dollars par mois, et moins de 30 dollars par jour pour 90 % des utilisateurs. Ce sont des chiffres de l'éditeur, pour un usage facturé à l'API ; avec un abonnement, l'usage est inclus dans le forfait, dans la limite de ses plafonds.

Aller plus loin : skills, sous-agents, hooks et MCP

Les skills, des procédures réutilisables

Un skill est un dossier qui contient un fichier SKILL.md : un en-tête qui dit quand l'utiliser, puis les instructions. Placé dans .claude/skills/<nom>/ pour le projet ou ~/.claude/skills/<nom>/ pour tous vos projets, il se déclenche quand Claude juge la situation pertinente, ou à la main avec /nom. Les anciennes commandes personnalisées de .claude/commands/ ont été fusionnées dans ce système et continuent de fonctionner.

---
description: Prépare une note de version. À utiliser quand on demande ce qui a changé depuis la dernière version.
---
Liste les commits depuis le dernier tag Git, regroupe-les en « Nouveautés »,
« Corrections » et « Technique », puis rédige une note de version de dix
lignes au plus, en français.

L'avantage sur CLAUDE.md : le contenu d'un skill n'entre dans le contexte que lorsqu'il sert.

Les sous-agents, pour déléguer sans encombrer la conversation

Un sous-agent travaille dans son propre contexte, avec ses instructions et ses outils, puis ne renvoie qu'un résumé. C'est utile pour fouiller une grosse base de code ou relire la sécurité d'un changement. Il se définit dans un fichier Markdown de .claude/agents/ (projet) ou ~/.claude/agents/ (personnel) :

---
name: relecteur-securite
description: Relit le code modifié à la recherche de failles de sécurité
tools: Read, Grep, Glob
model: opus
---
Tu es ingénieur sécurité. Examine les changements récents : injections,
authentification, secrets dans le code, validation des entrées. Classe
chaque problème par gravité et cite le fichier et la ligne.

Depuis la version 2.1.198, la commande /agents n'ouvre plus d'assistant de création : on demande directement à Claude de créer le sous-agent, ou on écrit le fichier soi-même. Pour s'en servir, il suffit de le nommer : « fais relire ce changement par le sous-agent relecteur-securite ».

Les hooks, pour ce qui doit arriver à coup sûr

Une consigne dans CLAUDE.md peut être oubliée, un hook non. C'est une commande shell que Claude Code exécute à un moment précis : avant l'utilisation d'un outil (PreToolUse), après (PostToolUse), au démarrage d'une session, quand Claude attend votre réponse. Cet exemple de la documentation des hooks formate avec Prettier chaque fichier modifié ; il se place dans .claude/settings.json :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Le chemin du fichier arrive en JSON sur l'entrée standard, d'où l'usage de jq. Un hook qui se termine avec le code de sortie 2 bloque l'action et renvoie son message d'erreur : c'est ainsi qu'on interdit toute écriture dans un dossier protégé. La commande /hooks liste les hooks actifs.

MCP, pour brancher Claude sur vos outils

Le Model Context Protocol (MCP), un standard ouvert lancé par Anthropic, connecte Claude Code à des services externes : gestionnaire de tickets, base de données, documentation interne. Un serveur distant s'ajoute en une commande :

claude mcp add --transport http notion https://mcp.notion.com/mcp

Un serveur local s'ajoute avec claude mcp add --transport stdio <nom> -- <commande>. Par défaut, la configuration reste privée et limitée au projet courant ; --scope project l'écrit dans un fichier .mcp.json partagé avec l'équipe, --scope user la rend disponible dans tous vos projets. La documentation MCP détaille les autres options, et /mcp affiche l'état des serveurs.

Automatiser : scripts, intégration continue et GitHub

L'option -p exécute une demande sans interface puis rend la main, ce qui permet d'appeler Claude Code depuis un script :

claude -p "Résume les changements de la branche courante" --output-format json

Le format JSON renvoie le résultat avec l'identifiant de session et une estimation du coût (total_cost_usd), calculée côté client et donc indicative. L'option --allowedTools préautorise des outils précis, par exemple --allowedTools "Read,Edit,Bash", comme le montre la documentation du mode non interactif.

Sur GitHub, la commande /install-github-app installe l'application, ajoute le secret d'authentification et prépare le workflow. Il suffit ensuite de mentionner @claude dans une issue ou une pull request pour lui confier une analyse ou une correction. L'intégration GitHub Actions ne fonctionne qu'avec des dépôts github.com ; GitLab a sa propre intégration.

Sécurité : quels réflexes adopter ?

Un agent qui exécute des commandes hérite de vos droits. Le premier risque s'appelle l'injection de prompt : un texte malveillant caché dans une page web, une issue, une dépendance ou un commentaire, que le modèle prend pour une consigne. KLYNLABS a documenté plusieurs attaques de ce type, du piège de configuration Git visant les agents de code au courriel qui retourne un navigateur IA contre son utilisateur.

• Travaillez sous Git et relisez les différences avant de valider un changement.

• Ne faites pas lire de contenu douteux sans surveillance : la page sécurité déconseille de transmettre directement à Claude un contenu non fiable.

• Protégez les secrets avec des règles comme Read(./.env), et ne collez jamais une clé d'API dans la conversation.

• Isolez les tâches autonomes dans un conteneur de développement ou une machine virtuelle. bypassPermissions ne se lance jamais sur votre poste principal, ni en root.

• Méfiez-vous des dépôts inconnus : à la première ouverture d'un projet, Claude Code demande si vous lui faites confiance, parce que ses fichiers de configuration peuvent déclencher des commandes (hooks) ou injecter des consignes. Lisez-les avant d'accepter.

Sources

• Anthropic, documentation de Claude Code : vue d'ensemble, installation, démarrage rapide, mémoire et CLAUDE.md, consultées le 13 septembre 2026.

• Anthropic, modes de permission, règles de permission, sécurité.

• Anthropic, bonnes pratiques, points de restauration, coûts, configuration des modèles.

• Anthropic, skills, sous-agents, hooks, MCP, mode non interactif, GitHub Actions.