Installation et premier lancement

Pourquoi ce chapitre compte

Installer un outil en ligne de commande semble anodin. Ça ne l'est plus quand cet outil peut lire, modifier et exécuter du code sur votre machine à votre place. Avant le premier promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, il faut comprendre précisément ce que vous installez, dans quel contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire il s'exécute, et quelles permissions vous lui accordez. Ce chapitre couvre l'installation, l'authentification et le premier lancement dans un dépôt de test — l'objectif n'est pas « ça a l'air de marcher », mais un état vérifié : l'agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire voit le bon répertoire, répond correctement, et vous savez comment il demande votre accord avant d'agir.

Claude CodeClaude CodeIAInterface en ligne de commande agentique qui lit, édite et exécute des actions dans un dépôt de code sous contrôle de permissions, par opposition à un simple chat web.Voir dans le glossaire n'est pas un chat web habillé en terminal. C'est un agent qui s'exécute localement, avec accès au système de fichiers du répertoire courant et à un shell. Chaque commande qu'il propose passe, par défaut, par une couche de permissions que vous contrôlez — mais la responsabilité de la revue reste humaine, à chaque étape.

Chat web et agent CLI : une différence structurelle

Dans une interface de chat classique, le modèle répond à partir de ce que vous collez dans la conversation. Il n'a aucun accès à votre disque, ne peut pas exécuter de commande, ne peut pas ouvrir un fichier qu'il n'a pas vu passer dans le prompt. La boucle est : vous copiez du contexte, le modèle répond, vous recopiez la réponse ailleurs.

Claude Code inverse cette logique. Lancé depuis un terminal, dans un répertoire donné, l'agent peut lire les fichiers de ce répertoire, proposer des modifications, exécuter des commandes shell (tests, build, git), et itérer sur le résultat de ces commandes sans que vous ayez à recopier quoi que ce soit. C'est un gain de friction réel, mais c'est aussi un changement de surface de risque : un modèle qui se contente de répondre dans un chat ne peut pas supprimer un fichier par erreur ; un agent avec accès shell, potentiellement.

Cette distinction structure tout le reste du chapitre : chaque étape d'installation et de configuration vise à garder cette surface de risque sous contrôle explicite.

Prérequis

Avant d'installer quoi que ce soit, vérifiez ces points :

• Système d'exploitation : macOS, Linux, ou Windows via WSL (Windows Subsystem for Linux) — un environnement Linux est recommandé pour la cohérence des chemins et des permissions de fichiers.
• Node.js récent si vous installez via un gestionnaire de paquets Node ; une version LTS suffit dans la grande majorité des cas.
• Un terminal que vous savez utiliser sans crainte : navigation de répertoires, variables d'environnement, historique de commandes.
• Un compte avec accès soit à un abonnement donnant droit à Claude Code, soit à une clé API valide.
• Un dépôt de test — un répertoire vide ou peu sensible, idéalement sous contrôle de version, pour ne rien risquer sur du code de production dès le premier essai.

Selon le canal officiel choisi au moment de l'installation, le paquet peut être distribué via un gestionnaire de paquets Node (npm) ou via un binaire natif téléchargé et installé par un script officiel. Les deux canaux aboutissent au même exécutable en ligne de commande ; le choix dépend surtout de votre environnement existant. Référez-vous toujours à la documentation officielle du moment pour la commande exacte, celle-ci pouvant évoluer.

Installation

Deux approches courantes coexistent :

1. Installation via un gestionnaire de paquets Node — le paquet officiel s'installe globalement, ce qui rend la commande disponible dans n'importe quel terminal ouvert ensuite. C'est l'option la plus simple si Node est déjà présent sur la machine.
2. Installation via un script ou binaire natif — utile quand vous ne voulez pas dépendre d'un environnement Node, ou sur des machines où la gestion de paquets Node est contrainte (postes d'entreprise, containers minimalistes).

Dans les deux cas, une fois l'installation terminée, une commande devient disponible dans votre terminal pour lancer l'agent. Vérifiez que l'installation a réussi en interrogeant sa version — une commande qui répond avec un numéro de version cohérent confirme que le binaire est correctement sur le PATH.

Si vous êtes derrière un proxy d'entreprise ou un pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire applicatif, l'installation et l'authentification peuvent échouer silencieusement ou avec des messages peu explicites. Testez d'abord une connexion sortante simple (ex. un accès web classique) avant de conclure à un bug de l'outil.

Authentification

Au premier lancement, l'agent déclenche un flux d'authentification. Deux cas de figure typiques :

• Authentification via navigateur (OAuth) — l'agent ouvre (ou vous invite à ouvrir) une page de connexion associée à votre compte ; une fois la session validée côté navigateur, le terminal reçoit la confirmation et poursuit.
• Authentification par clé API — vous fournissez une clé associée à un compte de plateforme, généralement via une variable d'environnement ou une invite du terminal.

Ces deux mécanismes ne sont pas interchangeables sur le plan de la facturation et des quotas : un abonnement personnel et un accès API de plateforme n'ont pas la même logique de coût. Si vous travaillez dans un contexte professionnel, clarifiez avec la personne responsable quel type de compte utiliser avant de commencer, pour éviter une facturation inattendue sur un compte personnel.

Après authentification réussie, un lancement typique ressemble à ceci depuis un terminal positionné dans le dépôt de test :

$ cd ~/projets/depot-test
$ claude
Bienvenue. Répertoire courant : ~/projets/depot-test (3 fichiers, dépôt git détecté)
> 

Si l'agent affiche un répertoire différent de celui attendu, ou aucun repère de dépôt git alors qu'il y en a un, arrêtez-vous avant de poser la moindre question — voir la section suivante.

Premier lancement dans un dépôt de test

Ne testez jamais un outil agentique pour la première fois dans un dépôt de production ou dans un répertoire contenant des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles. Créez un petit dépôt de test : quelques fichiers texte, éventuellement un git init, rien de critique. C'est dans ce bac à sable que vous allez valider le comportement de base de l'outil avant de l'utiliser sur du travail réel.

Une fois positionné dans ce répertoire et l'agent lancé, posez une première question simple et vérifiable, par exemple demander de lister les fichiers présents et de résumer le contenu de l'un d'entre eux. La réponse doit correspondre exactement à ce qui se trouve réellement sur le disque à cet endroit.

Vérifier que l'outil voit le bon répertoire courant

C'est l'étape de vérification la plus négligée, et pourtant la plus importante du premier lancement. Le contexte de travail de l'agent est délimité par le répertoire depuis lequel vous l'avez lancé (le cwd, current working directory). Si vous avez ouvert un terminal dans le mauvais dossier, l'agent travaillera sur les mauvais fichiers sans forcément vous alerter — il décrira simplement ce qu'il voit, qui ne correspond pas à ce que vous avez en tête.

Checklist de vérification rapide :

• Demandez à l'agent de lister le contenu du répertoire courant et comparez avec ce que vous attendez.
• Demandez-lui de confirmer s'il détecte un dépôt git, et laquelle en est la branche courante.
• Si un fichier de configuration de projet existe (package.json, pyproject.toml, etc.), demandez-lui d'en citer un champ précis (nom, version) : une réponse exacte confirme une lecture réelle du fichier, pas une réponse générique.

Gardez l'habitude, en début de session, de lancer une commande de vérification banale (lister les fichiers, afficher le statut git) avant de poser une question de fond. Cette étape prend quelques secondes et évite de découvrir, une heure plus tard, que tout le travail a porté sur le mauvais répertoire.

Mode interactif, mode print, et niveaux de confirmation

L'agent peut fonctionner selon deux logiques d'usage principales :

• Mode interactif — une session continue dans le terminal, où vous échangez plusieurs messages avec l'agent, qui garde le fil de la conversation et de ses actions précédentes. C'est le mode par défaut pour explorer, corriger, itérer.
• Mode printMode printIAMode non interactif de Claude Code adapté aux scripts et à l'automatisation : la réponse est émise puis le processus se termine.Voir dans le glossaire (non interactif) — une invocation unique en ligne de commande, avec un prompt fourni directement, qui retourne une sortie puis se termine. Utile pour scripter une tâche ponctuelle ou l'intégrer dans un pipeline automatisé.

Dans les deux modes, avant d'exécuter une action qui modifie un fichier ou lance une commande shell, l'agent peut fonctionner selon différents niveaux de prudence : proposer une action et attendre votre validation explicite (approche de type plan puis exécution), ou exécuter directement dans un cadre de permissions déjà accordé. Au démarrage, privilégiez toujours le mode le plus prudent, où chaque action potentiellement impactante vous est soumise avant exécution.

Permissions et revue humaine

La passerellePasserelleRéseauxÉquipement réseau reliant deux réseaux de couches différentes ou traduisant des protocoles ; en TCP/IP, route les paquets entre sous-réseaux.Voir dans le glossaire de permissions est le mécanisme central qui distingue un agent utilisable en confiance d'un agent dangereux. Concrètement, avant d'écrire un fichier ou de lancer une commande shell, l'agent présente ce qu'il s'apprête à faire, et vous choisissez : autoriser une fois, autoriser pour la session, refuser.

Accorder une autorisation permanente à des commandes larges (par exemple tout accès shell sans restriction) dès la première session revient à annuler l'intérêt même de la couche de permissions. Accordez des autorisations étroites et spécifiques, et élargissez-les progressivement à mesure que vous observez le comportement réel de l'agent sur votre projet.

La revue humaine ne s'arrête pas à cliquer « autoriser ». Lisez réellement le diff proposé avant de valider une modification de fichier, comme vous le feriez pour une pull request soumise par un collègue. Un agent peut produire un correctif syntaxiquement correct mais qui casse une logique métier invisible dans le diff isolé — seule une lecture attentive, dans le contexte du fichier entier, permet de le détecter.

Secrets et informations sensibles

L'agent lit ce qui se trouve dans le répertoire de travail et ce que vous lui donnez en contexte. Si une clé API, un mot de passe ou un jeton d'accès traîne dans un fichier de ce répertoire, il peut être lu, cité, voire recopié dans une réponse ou un journal de session.

Ne collez jamais de secret directement dans un prompt, et assurez-vous que les fichiers contenant des identifiants (.env, fichiers de configuration avec clés) sont exclus du périmètre que vous exposez à l'agent, ou à défaut correctement ignorés par votre gestion de version. Cette règle vaut pour tout outil qui lit votre disque, pas seulement pour Claude Code.

CLAUDE.md : la mémoire de projet

Un fichier nommé CLAUDE.md, placé à la racine d'un dépôt, sert de note de contexte persistante que l'agent lit au démarrage de chaque session dans ce répertoire. On y consigne des informations utiles et stables : conventions de code du projet, commandes de test à utiliser, contraintes particulières, ce qu'il ne faut jamais faire sur ce dépôt précis. Ce n'est pas un espace pour du contenu changeant à chaque tâche — pour cela, la conversation elle-même suffit.

Au premier lancement dans votre dépôt de test, il n'est pas nécessaire d'en créer un tout de suite : observez d'abord le comportement par défaut de l'agent, puis introduisez ce fichier quand des instructions répétitives commencent à apparaître d'une session à l'autre.

MCP, en une phrase

Au-delà du système de fichiers et du shell locaux, l'agent peut se connecter à des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire externes via un protocole standardisé (MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire, Model Context Protocol) — accès à une base de données, à un système de tickets, à une API interne. Ce sujet dépasse le cadre de l'installation ; retenez simplement qu'il existe, et qu'il élargit la surface de permissions à surveiller le jour où vous l'activez.

Checklist post-installation

Pièges fréquents

• Lancer l'agent depuis le mauvais répertoire — le cas le plus courant, souvent invisible tant qu'on ne vérifie pas explicitement le cwd.
• Accorder des permissions larges par réflexe pour aller plus vite, puis découvrir une action non désirée trop tard.
• Tester directement sur un dépôt de production au lieu d'un dépôt de test, ce qui transforme une erreur de configuration en incident réel.
• Confondre compte personnel et compte professionnel lors de l'authentification, avec des conséquences sur la facturation ou l'accès aux données.
• Ignorer les messages de permission en validant machinalement sans lire ce qui est proposé, ce qui annule l'intérêt de la couche de contrôle.

Ce qu'il faut retenir

L'installation de Claude Code n'est terminée que lorsque trois choses sont vérifiées : l'authentification fonctionne, l'agent voit le bon répertoire, et vous savez précisément comment il vous demande la permission avant d'agir. Ces vérifications, faites une fois avec soin dans un dépôt de test, évitent la plupart des surprises des premières semaines d'usage. Les chapitres suivants s'appuient sur cet environnement de base pour aborder des flux de travail plus avancés.