Claude Code, guide de référence : installation, abonnements et API, commandes, CLAUDE.md, MCP, sous-agents, bonnes pratiques

Claude Code est l’agent de développement d’Anthropic : il travaille sur un projet avec des fichiers et des outils, et peut enchaîner analyse, modifications et vérifications. Pour l’utiliser correctement, choisissez votre mode de facturation, installez le client, cadrez les instructions et les permissions, puis contrôlez les changements avant de les intégrer. Ce guide présente cette configuration et une méthode de travail reproductible, avec des informations vérifiées le 24 octobre 2026.

Comprendre ce que vous installez

Claude Code peut lire du code, proposer des changements et utiliser un terminal pour les vérifier. Il faut distinguer le client installé sur votre ordinateur du service de modèles auquel il accède : disposer du programme ne signifie pas disposer d’un modèle exécuté localement.

L’intérêt pratique réside dans la continuité entre compréhension du projet et actions. Vous pouvez demander une correction, obtenir une modification de fichiers et faire exécuter les vérifications pertinentes dans la même session. Cela exige de savoir reconnaître une commande risquée, un changement hors sujet ou un test insuffisant.

L’article Comment travaillent les agents de code explique cette boucle et ses limites. Ici, l’objectif est de préparer un environnement dont vous pouvez examiner les résultats, reprendre le travail et expliquer les coûts.

Avant de commencer, réunissez ces prérequis :

• un terminal et un système pris en charge ;
• une connexion Internet et un compte autorisé à utiliser le service ;
• un projet dont vous avez le droit de transmettre les contenus nécessaires ;
• une sauvegarde ou un historique permettant de retrouver l’état précédent ;
• les outils de compilation et de test propres au projet.

Le dernier point mérite une vérification préalable. Si votre application échoue déjà sans intervention de l’agent, conservez ce résultat initial : il permettra de distinguer les problèmes existants des régressions introduites.

Choisir entre abonnement et API

L’accès individuel par abonnement passe notamment par Claude. Au 24 octobre 2026, la page tarifaire officielle affiche Pro à 20 dollars par mois en paiement mensuel, ou 200 dollars facturés annuellement, avec Claude Code inclus. Max commence à 100 dollars par mois. Ces montants sont affichés hors taxes applicables et restent soumis aux conditions et limites de l’offre.

Ne transformez pas un abonnement en estimation de capacité garantie : votre charge de travail dépend des tâches, du contexte et des modèles accessibles. La présence de Claude Code dans une formule ne signifie pas un usage illimité.

Critère	Abonnement individuel	Facturation API
Accès	Compte disposant d’une formule compatible	Accès Claude Console configuré
Budget	Montant récurrent, avec limites d’usage	Consommation facturée selon les conditions API
Vérification préalable	Formule et usage disponibles	Organisation, facturation et accès
Suivi	Usage de l’abonnement et éventuels suppléments	Dépenses et limites du compte API
Choix pratique	Travail interactif dans une enveloppe d’abonnement	Besoin d’un suivi de consommation distinct

Pour comparer économiquement les voies d’accès, mesurez des tâches représentatives. Relevez le temps de traitement, les reprises nécessaires et la consommation affichée. Un tarif par token ne suffit pas à prédire le coût d’une correction complète.

Les crédits API, suppléments et avantages associés à certaines offres ont leurs propres conditions. Vérifiez ce qui est effectivement activé dans votre compte avant d’assimiler une réserve API au quota de votre abonnement.

1. Installer le client et vérifier son fonctionnement

Les commandes suivantes proviennent de la documentation officielle d’installation, consultée le 24 octobre 2026. Elle indique notamment une connexion Internet obligatoire et au moins 4 Go de mémoire vive. Consultez sa liste de systèmes compatibles avant une installation sur un poste ancien ou une distribution particulière.

Sur macOS, Linux ou dans WSL :

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

Dans Windows PowerShell :

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

Ces commandes téléchargent et exécutent un programme d’installation. Utilisez l’adresse officielle et respectez les règles de votre organisation concernant l’exécution de scripts téléchargés.

Ouvrez ensuite une nouvelle fenêtre de terminal et vérifiez le client :

claude --version

La version affichée décrit votre installation réelle. Évitez de recopier un numéro trouvé dans un ancien tutoriel pour résoudre un problème : consignez celui que vous obtenez.

L’installation native se met à jour automatiquement selon la documentation. Pour une équipe, convenez d’une politique de mise à jour et notez la version lors d’un incident reproductible. Une différence de comportement peut venir du client, mais aussi des instructions du dépôt, des permissions ou du service distant.

Installez séparément les dépendances du projet. Le fait que Claude Code démarre ne prouve pas que votre compilateur, votre base de test ou votre environnement de développement fonctionnent.

2. Se connecter et cadrer la première tâche

Placez-vous dans le répertoire du projet avant de lancer le client. La référence officielle de la ligne de commande documente le démarrage interactif :

claude

Suivez le parcours de connexion proposé. Pour choisir explicitement une connexion à Claude Console avec facturation API, la documentation fournit cette commande :

claude auth login --console

Contrôlez le compte choisi avant une tâche longue. Sur une machine utilisée pour plusieurs organisations, une connexion techniquement réussie peut encore correspondre au mauvais environnement de facturation.

Commencez par une demande d’observation, sans modification. Par exemple :

Repérez le point d’entrée de l’application et les vérifications existantes.
Expliquez comment reproduire le problème décrit.
Ne modifiez aucun fichier.
Signalez les informations qui vous manquent.

Cette étape teste surtout votre compréhension commune du projet. Vérifiez les chemins cités et demandez sur quels fichiers repose chaque conclusion importante.

Définissez ensuite un résultat observable : comportement corrigé, périmètre autorisé, vérifications attendues et actions soumises à validation. Le guide Bien travailler avec un agent de code développe cette méthode.

Pour une première intervention, choisissez une correction limitée. Une migration générale combine trop d’incertitudes pour distinguer rapidement un problème de configuration d’une mauvaise interprétation de la demande.

3. Utiliser les commandes au bon endroit

Les commandes du terminal lancent le programme ou reprennent une session. Les commandes commençant par une barre oblique se saisissent dans Claude Code. La liste officielle des commandes interactives reste la référence pour leur disponibilité dans votre environnement.

Commande interactive	Usage	Vérification utile
/plan	Passer en mode plan avant un changement	Hypothèses et périmètre proposés
/init	Préparer les instructions du projet	Exactitude des conventions repérées
/memory	Consulter et affiner les instructions	Fichiers réellement pris en compte
/permissions	Examiner les autorisations	Portée des permissions conservées
/context	Examiner l’occupation du contexte	Informations devenues inutiles
/compact	Résumer la conversation	Contraintes à conserver explicitement
/usage	Consulter l’usage	Enveloppe disponible avant de continuer
/mcp	Examiner les connexions MCP	Serveurs, authentification et état

Pour continuer la conversation la plus récente du répertoire courant, utilisez au terminal :

claude -c

Une reprise conserve le fil d’un travail ; elle ne dispense pas de vérifier ce qui a changé entre-temps. Un collègue peut avoir modifié les fichiers ou une dépendance distante peut avoir évolué.

Pour une nouvelle tâche sans rapport, préférez une session neuve accompagnée d’un bref état des lieux. Accumuler des demandes différentes rend plus difficile l’identification des décisions encore valables.

Avant une compression du contexte, formulez un point de reprise : objectif, fichiers concernés, décisions acceptées, vérifications effectuées et problèmes ouverts. Ce document vous servira aussi si vous devez changer de session.

4. Écrire un CLAUDE.md court et vérifiable

CLAUDE.md contient des instructions persistantes destinées à l’agent. La documentation sur la mémoire et les instructions distingue notamment les règles partagées du projet, dans ./CLAUDE.md ou ./.claude/CLAUDE.md, des préférences personnelles dans ~/.claude/CLAUDE.md.

Faites préparer une base avec /init, puis relisez-la. Une convention déduite du code peut être ancienne, accidentelle ou limitée à un sous-répertoire.

Voici un exemple éditorial à adapter :

# Règles de travail

- Avant de modifier, identifier le comportement attendu et son emplacement.
- Préserver les changements déjà présents dans le répertoire de travail.
- Utiliser les vérifications définies par le projet.
- Signaler une vérification impossible et sa cause.
- Demander une validation avant publication ou modification distante.
- Terminer par les fichiers modifiés, les tests et les limites restantes.

Ajoutez les commandes propres au dépôt après les avoir vérifiées. Une instruction précise, comme le chemin d’une suite de tests pertinente, aide davantage qu’une demande générale de qualité.

Évitez les secrets, les copies de documentation et les règles contradictoires. Les fichiers d’instructions apportent du contexte ; ils ne constituent pas une barrière d’accès. Une interdiction sensible doit aussi être appliquée par les permissions ou l’environnement.

Pour les grands projets, la documentation prévoit des règles dans .claude/rules/. Répartissez-les par sujet lorsque cela facilite leur entretien. Si le dépôt possède déjà AGENTS.md, vérifiez les règles de chargement actuelles avant de dupliquer les consignes : leur coexistence ne signifie pas que tous les fichiers seront automatiquement lus ensemble.

5. Régler les permissions avant d’élargir l’autonomie

Une instruction exprime votre intention ; une permission détermine les actions autorisées par le client. La documentation des permissions décrit des règles par outil et différents modes d’approbation. Certaines autorisations peuvent persister : examinez leur portée avant de choisir une option qui évite les demandes suivantes.

Appliquez le moindre privilège : commencez avec les accès nécessaires à la tâche, puis élargissez-les lorsqu’un besoin précis apparaît. Une correction locale ne justifie pas automatiquement des identifiants de production ou des droits de publication.

Lorsqu’une commande est proposée, vérifiez :

• les fichiers et répertoires concernés ;
• la présence d’un accès réseau ;
• les identifiants ou variables qu’elle peut utiliser ;
• les effets secondaires et leur réversibilité.

Ne confondez pas le mode plan avec un environnement d’isolation complet. Pour exécuter du code inconnu, prévoyez également des protections au niveau du système et des comptes utilisés.

Le guide de sécurisation des agents IA détaille ces protections. Dans votre procédure quotidienne, séparez clairement préparation et diffusion : une modification relue peut être prête à intégrer sans autoriser une publication automatique.

Évaluez aussi les scripts de test. Leur nom ne garantit pas leur innocuité : ils peuvent installer des dépendances, contacter des services ou modifier des données. Une commande habituelle doit rester compréhensible dans le contexte où elle sera exécutée.

6. Ajouter MCP pour un besoin identifié

MCP permet de connecter l’agent à des outils et à des sources externes. La documentation MCP de Claude Code distingue notamment les serveurs distants HTTP et les processus locaux utilisant le transport stdio.

Pour montrer la syntaxe sans imposer un service particulier, voici l’exemple générique officiel :

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

Cette adresse est illustrative : remplacez-la par le point d’accès officiel du serveur choisi. Examinez ensuite la connexion avec /mcp.

La configuration peut être locale à votre usage, personnelle ou partagée avec le projet. La portée projet utilise notamment .mcp.json. Relisez ce fichier avant de l’accepter dans un dépôt reçu d’un tiers.

Choisissez un premier serveur correspondant à une tâche précise, par exemple consulter une source de documentation autorisée. Vérifiez son éditeur, ses permissions, son authentification et les données qu’il reçoit. L’annuaire des serveurs MCP aide à repérer les fiches ; les instructions d’installation doivent venir de l’éditeur concerné.

Un document renvoyé par un serveur reste une donnée externe. Il peut contenir une injection de prompt, même si la connexion fonctionne correctement.

Établissez donc une règle simple : consulter un ticket ou un document n’autorise pas à suivre les instructions qu’il contient pour envoyer des secrets, modifier les permissions ou exécuter une commande sans rapport avec votre demande.

7. Configurer des sous-agents spécialisés

Un sous-agent reçoit une mission distincte et travaille avec son propre contexte. La documentation officielle des sous-agents prévoit des définitions dans .claude/agents/ pour le projet et dans ~/.claude/agents/ pour l’utilisateur.

Vous pouvez demander à Claude de préparer une définition, puis la relire. Décrivez une mission, des outils autorisés et un résultat attendu. Par exemple, un relecteur peut rechercher des régressions sans disposer du droit de modifier les fichiers.

Au 24 octobre 2026, la documentation précise que /agents affiche un rappel orientant vers Claude ou l’édition des fichiers ; les anciens tutoriels présentant systématiquement un assistant interactif ne décrivent donc plus tous les clients actuels.

La délégation est utile pour des tâches séparables : repérage d’une zone du code, analyse d’un échec, recherche de cas limites. Elle complique le travail lorsque plusieurs agents modifient simultanément les mêmes fichiers.

Exigez un rapport exploitable : constat, emplacement, preuve et incertitude. Une opinion générale sur la qualité du code ne permet pas de décider quoi corriger.

Un sous-agent mobilise aussi des ressources. Comparez son apport au travail de coordination supplémentaire : instructions, attente, lecture du rapport et résolution des contradictions. Commencez par une spécialisation claire avant d’organiser plusieurs travaux en parallèle.

Vérifier le résultat et maîtriser le coût réel

Demandez une modification cohérente et limitée, puis examinez le diff avant d’ajouter une autre demande. Vous devez pouvoir expliquer le lien entre chaque fichier modifié et le résultat attendu.

Organisez la validation autour du comportement :

1. constater ou reproduire le problème initial ;
2. vérifier le résultat après modification ;
3. contrôler les comportements voisins exposés à une régression ;
4. examiner les dépendances, permissions et données éventuellement affectées.

Un test réussi apporte une preuve sur ce qu’il couvre. Il ne prouve pas que l’ensemble du changement est correct. Inversement, une vérification impossible doit être signalée avec sa cause et son effet sur la confiance dans le résultat.

Pour maîtriser les coûts, réduisez surtout les reprises évitables. Fournissez un exemple d’entrée, le résultat attendu et les contraintes essentielles dès le départ. Demandez une recherche ciblée avant une exploration générale du dépôt.

Consignez aussi les tentatives abandonnées. Une session qui répète la même hypothèse sans nouvelle preuve doit être recadrée : résumez l’échec, demandez une autre explication et fixez une condition d’arrêt. Comparez les solutions avec la même tâche ; notre annuaire des agents IA fournit les fiches nécessaires pour élargir cette comparaison.

Problèmes fréquents

La commande n’est pas reconnue. Ouvrez un nouveau terminal, puis vérifiez l’installation et le chemin de recherche des exécutables selon la documentation. Réinstaller plusieurs fois sans identifier le problème peut rendre le diagnostic plus confus.

La connexion aboutit au mauvais compte. Vérifiez l’organisation et le mode de facturation avant de reprendre. Ne partagez jamais une clé ou un code de connexion dans un rapport de dépannage public.

Les instructions semblent ignorées. Consultez les fichiers pris en compte, cherchez les contradictions et simplifiez les règles. Remplacez une consigne vague par un résultat vérifiable.

Un serveur MCP reste indisponible. Séparez les causes possibles : point d’accès incorrect, authentification, réseau ou processus local manquant. Testez une connexion à la fois.

Les changements s’étendent trop. Interrompez la tâche, examinez le diff et reformulez le périmètre. Demandez une justification pour les fichiers inattendus avant de poursuivre.

Les tests échouent toujours. Comparez avec l’état initial. Un environnement incomplet, un service absent ou des données de test manquantes demandent un diagnostic différent d’une régression du code.

Checklist avant de conserver les changements

• Le compte, l’organisation et la facturation sont identifiés.
• L’état initial du projet peut être retrouvé.
• Les instructions décrivent des règles vérifiables.
• Les permissions correspondent à la tâche.
• Les connexions externes ont un besoin explicite.
• Chaque fichier modifié a été relu.
• Les vérifications couvrent le comportement attendu.
• Les tests impossibles et les incertitudes sont consignés.
• La consommation et les reprises ont été examinées.
• Toute publication distante fait l’objet d’une décision explicite.

Pages liées

• Claude Code
• Claude
• Codex
• GitHub

Questions fréquentes

Claude Code fonctionne-t-il sans abonnement ?

Vous pouvez passer par une facturation API avec Claude Console plutôt que par un abonnement individuel. Cette voie demande un accès et une facturation configurés ; installer le logiciel ne fournit pas une réserve gratuite de calcul.

Peut-on utiliser Claude Code sans connaître le terminal ?

La documentation propose également une interface de bureau. Pour intervenir sur un projet logiciel, vous devez néanmoins pouvoir examiner les changements, comprendre les erreurs et vérifier le résultat, ou confier cette validation à une personne compétente.

Faut-il mettre toute la documentation dans CLAUDE.md ?

Gardez surtout les règles qui changent les décisions de l’agent : contraintes, pièges connus et vérifications attendues. Une documentation volumineuse se consulte selon les besoins ; sa présence dans les instructions générales ne garantit pas qu’elle sera correctement appliquée.

Un sous-agent peut-il garantir une relecture indépendante ?

Il apporte un contexte de travail distinct, mais peut conserver les mêmes angles morts que l’agent principal. Utilisez son rapport pour orienter la vérification humaine et les tests, sans en faire une certification du changement.

MCP est-il nécessaire pour commencer ?

Non. Commencez avec les fichiers et les outils du projet, puis ajoutez une connexion lorsqu’un besoin précis apparaît. Chaque serveur supplémentaire introduit des accès, une configuration et des défaillances possibles.