Aller au contenu

Installer et utiliser Claude Code, l'agent de code d'Anthropic

Installer et utiliser Claude Code, l’agent de code d’Anthropic

Section intitulée « Installer et utiliser Claude Code, l’agent de code d’Anthropic »

Claude Code, l’agent de développement d’Anthropic, lit un dépôt, modifie des fichiers et lance des commandes jusqu’au but fixé ; le mot « agentique » est défini dans une page dédiée. La position défendue : un agent de code est un collègue rapide qui travaille avec les droits complets de la session qui l’héberge ; il se configure comme un compte de service, pas comme un correcteur orthographique. Versions et comportements par défaut : documentation officielle consultée le 2 octobre 2026.

→ Lire l’explication complète de la marmotte

Avant la première commande, il faut réunir :

  • un système pris en charge : macOS 13.0 ou plus récent, Windows 10 version 1809 ou Windows Server 2019 et suivants, Ubuntu 20.04, Debian 10 ou Alpine Linux 3.19 et suivants ;
  • 4 Go de mémoire vive au moins, un processeur x64 ou ARM64, une connexion Internet et un shell Bash, Zsh, PowerShell ou CMD (invite de commandes Windows) ;
  • un compte payant : abonnement Claude Pro, Max, Team ou Enterprise, ou compte Console (accès API, Application Programming Interface, à crédits prépayés). L’offre gratuite de claude.ai n’inclut pas Claude Code. Les entreprises peuvent passer par Amazon Bedrock, Google Cloud (Agent Platform) ou Microsoft Foundry ;
  • un dépôt Git propre, pour annuler ce que l’agent aura fait.

Le compromis : on gagne un exécutant infatigable ; on paie un programme qui agit avec l’identité du développeur et obéit parfois à du texte qu’il a simplement lu.

Étapes 1 à 3 : installation, vérification et connexion

Section intitulée « Étapes 1 à 3 : installation, vérification et connexion »

Étape 1. Installer le binaire. La méthode recommandée par l’éditeur consiste à télécharger un script et l’exécuter d’un seul geste, exactement ce que l’agent refuse par défaut de faire. Sur un poste sensible, préférer le dépôt de paquets signé.

Fenêtre de terminal
# Installateur natif (macOS, Linux, WSL, Windows Subsystem for Linux) :
# mise à jour automatique en arrière-plan
curl -fsSL https://claude.ai/install.sh | bash
# Variante : canal "stable", en général une semaine de retard
# et sans les versions à régression majeure
curl -fsSL https://claude.ai/install.sh | bash -s stable
# Debian ou Ubuntu : dépôt apt signé, clé à vérifier avant usage
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://downloads.claude.ai/keys/claude-code.asc \
-o /etc/apt/keyrings/claude-code.asc
gpg --show-keys /etc/apt/keyrings/claude-code.asc
# Empreinte attendue : 31DDDE24DDFAB679F42D7BD2BAA929FF1A7ECACE
echo "deb [signed-by=/etc/apt/keyrings/claude-code.asc] https://downloads.claude.ai/claude-code/apt/stable stable main" \
| sudo tee /etc/apt/sources.list.d/claude-code.list
sudo apt update && sudo apt install claude-code
# Autres voies : Homebrew (pas de mise à jour automatique)
brew install --cask claude-code
# WinGet sous Windows (pas de mise à jour automatique)
winget install Anthropic.ClaudeCode
# npm : Node.js 22 ou plus ; jamais avec sudo
npm install -g @anthropic-ai/claude-code

Le bac à sable décrit plus bas n’existe que sous macOS, Linux et WSL (Windows Subsystem for Linux) 2 (Windows Subsystem for Linux) : sous Windows, travailler dans WSL 2 si l’isolement compte.

Étape 2. Vérifier l’installation dans un nouveau terminal :

Fenêtre de terminal
# Affiche un numéro de version suivi de "(Claude Code)"
claude --version
# Diagnostic en lecture seule : installation, fichiers de réglages, mises à jour
claude doctor

Étape 3. Se connecter. Lancer claude dans un dossier de projet ouvre une authentification par navigateur ; la commande /login change de compte plus tard. Si la variable ANTHROPIC_API_KEY est définie, l’outil propose d’utiliser cette clé au lieu d’ouvrir le navigateur. Cette clé est un secret de plus à protéger ; voir les clés d’API des fournisseurs d’IA.

L’extension Visual Studio Code affiche les modifications en diff dans l’éditeur ; le greffon JetBrains exige la CLI (Command Line Interface, interface en ligne de commande) installée à part. L’application de bureau (macOS, Windows, bêta sur Ubuntu et Debian) embarque Claude Code. claude.ai/code exécute l’agent dans une machine virtuelle hébergée par Anthropic : le code quitte alors le poste, ce qui se décide avec le responsable des données, pas avec l’enthousiasme du moment. CLAUDE.md, réglages et serveurs MCP (Model Context Protocol) valent pour toutes ces surfaces.

Dans le dossier du projet, claude ouvre une session. Commencer par des questions sans effet (« que fait ce projet ? »), puis confier une tâche bornée et vérifiable : « ajouter une validation au formulaire d’inscription et lancer les tests ». Commandes utiles :

  • claude -p "requête" exécute une requête unique puis rend la main, pour les scripts ;
  • claude -c reprend la dernière conversation du dossier, claude -r en choisit une ancienne ;
  • dans la session, /help liste les commandes, /clear vide l’historique, /init génère un premier CLAUDE.md ;
  • Maj+Tab fait défiler les modes de permission.

Chaque action passe par un mode de permission. Six existent :

  • Manual (valeur default) : seules les lectures passent sans demander ;
  • acceptEdits : modifications de fichiers et commandes mkdir, mv, cp acceptées dans le répertoire de travail ;
  • plan : l’agent explore et propose un plan, sans modifier le code avant approbation ;
  • auto : un second modèle, le classifieur, juge les actions à la place de l’humain et bloque par défaut notamment curl | bash, l’envoi de données sensibles vers l’extérieur, les déploiements en production et les poussées forcées ;
  • dontAsk : seuls les outils explicitement autorisés passent, le reste est refusé ;
  • bypassPermissions (--dangerously-skip-permissions) : aucune vérification. Réservé aux conteneurs ou machines virtuelles sans Internet ; refusé en root sous Linux et macOS.

Point qui surprend : depuis la version 2.1.283, auto est le mode de départ des sessions interactives en terminal et dans Visual Studio Code. Après installation, l’agent agit donc sans rien demander, sous la seule surveillance d’un autre modèle ; Anthropic prévient que ce mode ne garantit pas la sécurité. Pour un dépôt sensible ou un code inconnu, fixer "defaultMode": "default".

Les règles affinent le mode. Elles s’écrivent Outil ou Outil(précision) dans permissions.allow, ask et deny, et s’évaluent dans cet ordre : refus, puis demande, puis autorisation, la première correspondance l’emportant. Un refus posé à n’importe quel niveau ne peut être levé par aucun autre. Les niveaux de réglages, du plus fort au plus faible : réglages gérés par l’organisation, ligne de commande, .claude/settings.local.json (personnel, hors Git), .claude/settings.json (partagé dans le dépôt), ~/.claude/settings.json (utilisateur).

Limite à connaître : une règle Bash compare le texte de la commande, pas le programme. Bash(git push *) en refus n’arrête pas git -C . push, et Bash(curl *) n’arrête pas un curl appelé par son chemin complet ou dans sh -c. Ces règles guident ; seul le bac à sable impose une frontière au niveau du système.

CLAUDE.md (à la racine ou dans .claude/, versionné) est chargé à chaque session : commandes de test, conventions, architecture. Variantes personnelles : ~/.claude/CLAUDE.md et CLAUDE.local.md, hors Git. La documentation conseille moins de 200 lignes, et précise que ces fichiers sont du contexte, non une configuration imposée : écrire « ne jamais lire .env » dans CLAUDE.md revient à poser un écriteau « Défense d’entrer » sur une porte ouverte. Pour interdire, il faut une règle de refus ou un hook.

Le fichier suivant, versionné dans .claude/settings.json, combine mode manuel, règles, bac à sable et hook. Le JSON (JavaScript Object Notation) n’accepte pas de commentaires : les explications suivent le bloc.

{
"permissions": {
"defaultMode": "default",
"allow": ["Bash(npm run lint)", "Bash(npm run test *)"],
"ask": ["Bash(git push *)"],
"deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)",
"Bash(curl *)", "Bash(wget *)"]
},
"sandbox": {
"enabled": true,
"network": { "allowedDomains": ["registry.npmjs.org"] },
"credentials": {
"files": [
{ "path": "~/.ssh", "mode": "deny" },
{ "path": "~/.aws/credentials", "mode": "deny" }
]
}
},
"hooks": {
"PreToolUse": [
{ "matcher": "Bash",
"hooks": [ { "type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/bloquer-commandes.sh" } ] }
]
}
}

Les règles Read empêchent les outils de fichiers de l’agent de lire les secrets ; les entrées credentials du bac à sable font de même pour les commandes shell, et le réseau de ces commandes passe par un mandataire local limité aux domaines listés. Sous Linux, le bac à sable exige bubblewrap et socat (/sandbox signale ce qui manque). Interdire ~/.ssh bloque aussi un git push par SSH (Secure Shell). L’extension Visual Studio Code ignore le defaultMode du projet : le poser dans les réglages utilisateur.

Le hook s’exécute avant chaque commande Bash. Un code de sortie 2 bloque l’appel, avant même l’évaluation des règles d’autorisation, et le texte écrit sur la sortie d’erreur sert de motif au blocage :

#!/bin/bash
# .claude/hooks/bloquer-commandes.sh (chmod +x)
# L'appel d'outil arrive en JSON sur l'entrée standard
CMD=$(jq -r '.tool_input.command // empty')
# Poussée forcée et suppression récursive : refus systématique
if echo "$CMD" | grep -Eq 'git push.*(--force|-f\b)|rm -rf'; then
echo "Bloqué par le hook de sécurité : $CMD" >&2
exit 2
fi
exit 0

Ce filtre textuel se contourne comme les règles Bash ; il complète le bac à sable sans le remplacer. Les hooks et les serveurs MCP s’exécutent hors du bac à sable, avec tous les droits de l’utilisateur : un hook ou un .mcp.json ajouté à un dépôt cloné se relit avant d’accepter la boîte de dialogue de confiance du dossier. En mode -p, cette boîte de dialogue n’apparaît pas du tout.

  • Secrets. Par défaut, les commandes du bac à sable héritent des variables d’environnement et lisent la majeure partie de la machine : aucun identifiant de production sur le poste ; voir le coffre-fort de secrets et les secrets dans les prompts.
  • Moindre privilège. Lancer l’agent depuis le dossier du projet, jamais depuis le répertoire personnel ; restreindre les outils des sous-agents (.claude/agents/, champs tools ou disallowedTools).
  • Revue des diffs. Branche dédiée et demande de fusion relue par un humain ; voir la revue de sécurité du code généré par IA et le slopsquatting.
  • Réseau. Liste blanche courte : un domaine large comme github.com ouvre une voie d’exfiltration, et le mandataire n’inspecte pas le TLS (Transport Layer Security), ce qui laisse passer le « domain fronting », selon la documentation elle-même.
  • Contenu non fiable. Un ticket ou une page web peut porter des instructions malveillantes : pas de contenu inconnu pour un agent doté d’écriture et de réseau ; voir la sécurité des agents outillés.

Utilité réelle : quand s’en servir, quand s’abstenir

Section intitulée « Utilité réelle : quand s’en servir, quand s’abstenir »

L’agent apporte vraiment sur les tâches qu’une machine sait vérifier : écrire des tests et les faire passer, corriger des erreurs de linter, migrer une API dépréciée sur cent fichiers, résoudre des conflits de fusion, explorer un dépôt inconnu en mode plan. Les connecteurs MCP lui ouvrent tickets et documentation, et autant de surface d’injection.

Il faut s’en abstenir, ou le cantonner au mode plan, quand :

  • rien ne vérifie le résultat : l’agent produit alors du code plausible, ce qui n’est pas du code juste ;
  • le code touche cryptographie ou authentification sans relecteur compétent ;
  • la session atteint la production ou des données personnelles ;
  • la confidentialité interdit d’envoyer le code à un tiers : tout ce que l’agent lit part au modèle ;
  • le développeur ne comprend pas le domaine : il ne saura pas relire ce qu’il n’aurait pas su écrire.

Enfin, un compte API se facture à la consommation, et le classifieur du mode auto consomme lui aussi des jetons sur les comptes API et Enterprise.

Installé tel quel, l’agent démarre en mode auto avec tous les droits du développeur : clés SSH, jetons cloud et variables d’environnement sont à portée de commande. Une instruction cachée dans un ticket suffit à lui faire lire un .env puis l’envoyer ailleurs, et seul le jugement d’un second modèle s’interpose. Sans règle de refus ni hook, une mauvaise interprétation supprime des fichiers ou réécrit l’historique Git, et sans branche dédiée ni revue, le code fautif part en production avec un message de commit impeccable. Un .claude/settings.json ou un .mcp.json piégé dans un dépôt cloné, accepté d’un clic distrait comme dossier de confiance, exécute en outre ses commandes avec les droits du poste. L’incident se constate ensuite sur l’état final, et l’enquête commence par demander à l’agent ce qu’il a fait.

Claude Code est un programme d’intelligence artificielle qui aide à écrire des logiciels. Contrairement à un assistant de discussion, il agit : il ouvre les fichiers d’un projet, écrit du code, lance des commandes et vérifie le résultat. On l’installe avec une commande dans le terminal, avec un abonnement payant.

Le problème, c’est qu’il agit avec les mêmes droits que la personne qui l’utilise. S’il se trompe, ou si un texte piégé lu sur Internet lui donne de mauvaises instructions, il peut effacer des fichiers ou envoyer des mots de passe ailleurs. C’est pourquoi on règle ses permissions : ce qu’il peut faire seul, ce qui demande une confirmation, ce qui est interdit. On peut aussi l’enfermer dans une sorte de cage, le bac à sable, qui l’empêche de sortir du dossier du projet et de contacter n’importe quel site.

Il est très utile pour les tâches répétitives qu’un ordinateur peut vérifier, beaucoup moins quand personne ne peut contrôler son travail. La règle reste celle du stagiaire : des tâches claires, une relecture avant envoi, et jamais les clés de la maison.

À lire aussi

  • Installer et utiliser Codex, l'agent de code d'OpenAIGuide pas à pas pour installer Codex CLI, s'authentifier sans exposer de jeton, régler le bac à sable et les approbations, écrire un fichier AGENTS.md, et savoir quand confier une tâche à l'agent ou s'en abstenir.
  • Installer et utiliser GitHub Copilot en mode agentGuide pas à pas pour activer les trois visages agentiques de GitHub Copilot (mode agent de Visual Studio Code, agent cloud qui ouvre des pull requests, Copilot CLI dans le terminal), régler les approbations, écrire les instructions de dépôt et garder la main sur les secrets, le réseau et la fusion.
  • L'IA actuelle : assistants conversationnels et agentsÉtat des lieux en octobre 2026 des assistants d'IA générative (ChatGPT, Claude, Gemini, Copilot, Vibe, Meta AI, DeepSeek, Grok, modèles ouverts) et des agents qui agissent à leur place, avec ce que cela change pour la sécurité et la manière de les encadrer.
  • Le moindre privilège pour une machine qui improviseUn agent IA doté d'un shell, d'un accès aux fichiers et de clés d'API est un acteur du système d'information, pas un outil. Le moindre privilège classique suppose qu'on sait d'avance ce que le programme va faire ; l'agent ne le sait pas lui-même, et c'est son environnement qu'il faut borner, pas ses intentions.

Pages voisines

: les deux pages se citent l’une l’autre.