Le chapitre 1 portait sur le modèle mental. Ce chapitre-ci porte sur la pratique. Il y a un seul objectif : faire passer votre première instruction, sur votre propre dépôt.
Les commandes à taper tiennent en quelques lignes. Le reste du temps sert à comprendre ce que vous êtes en train d'approuver. Si vous sautez cette partie, vous devrez y revenir plus tard.
Il y a cinq portes d'entrée : par laquelle passer ?
On présente généralement Claude Code comme « un outil de terminal », mais il y a cinq portes d'entrée. Ce qu'il y a dedans est identique. Seul l'emballage change.
L'original. Tapez claude, c'est tout. C'est ce que ce cours suppose.
Il cohabite avec l'éditeur. Vous lisez les diffs dans l'affichage que vous connaissez déjà.
S'installe dans la famille IntelliJ. Si vous développez là, vous n'avez plus à en sortir.
S'utilise sans ouvrir de terminal. Le mode se choisit dans le sélecteur à côté du champ de saisie.
Accessible même sans environnement de développement sous la main. Là aussi, on change de mode avec le sélecteur.
Pour la première heure, nous conseillons le terminal. La raison n'est pas le confort mais la quantité d'information. Quand vous êtes bloqué, les messages apparaissent bruts, et les solutions publiées supposent le terminal. La répartition des rôles avec les outils intégrés à l'éditeur (Cursor ou GitHub Copilot) se trouve dans le chapitre 1 du cours de programmation avec l'IA.
L'installer
La voie standard passe par npm. Si Node.js est déjà là, une ligne suffit (si node -v affiche une version, tout est prêt). Le -g signifie « installer de façon à pouvoir l'appeler depuis n'importe quel dossier ».
npm install -g @anthropic-ai/claude-code
claude
Dans les environnements où un proxy ou une restriction régionale bloque npm, vous pouvez passer par un gestionnaire de paquets.
brew install --cask claude-code # macOS / Homebrew
winget install Anthropic.ClaudeCode # Windows / WinGet
Choisissez une seule méthode d'installation. Si vous ajoutez Homebrew après npm, vous verrez apparaître Multiple claude installations found. Ne pas savoir laquelle tourne rend tout le travail de diagnostic qui suit beaucoup plus difficile. Les prérequis varient selon l'environnement, alors en cas de doute, allez voir la documentation officielle.
Se connecter : compte ou clé API
Au premier lancement, vous choisissez le mode de connexion. Avec un compte Claude, le navigateur s'ouvre, et une fois connecté et l'accès autorisé, l'authentification passe. Ce qui est utilisé, c'est le quota de votre formule, et la consommation se manifeste sous forme de plafonds et d'heures de réinitialisation. Une clé API, elle, ne fonctionne pas sur un quota mais sur un solde, et s'arrête quand il est épuisé. Pour un usage personnel, la première option ; pour l'intégration continue et l'automatisation, la seconde.
Ce qui vous est accessible dépend de votre contrat, nous ne trancherons donc pas. Il n'y a qu'un seul point à retenir.
Une clé API dans les variables d'environnement l'emporte sur la connexion par abonnement. Si vous avez écrit ANTHROPIC_API_KEY dans la configuration de votre shell lors d'un vieux test et que vous l'avez oublié, votre connexion, même correcte, sera ignorée au profit de la clé. La plupart des « j'ai un abonnement et on me dit que mon solde est insuffisant » viennent de là.
Pour savoir avec quels identifiants vous tournez en ce moment, /status répond. Regardez avant de soupçonner.
/status # avec quels identifiants je tourne maintenant
env | grep ANTHROPIC # reste-t-il une clé dans les variables d'environnement
unset ANTHROPIC_API_KEY # si oui, la retirer. et l'effacer du fichier de config
/login # se reconnecter, puis revérifier avec /status
Ce qui se passe au premier lancement
Une fois authentifié, lancez-le après vous être déplacé dans le dossier où vous voulez travailler. Claude Code considère « le dossier où vous êtes » comme sa cible de travail, alors si vous vous trompez, il se met à lire un endroit sans rapport.
cd my-project
claude
L'invite qui attend votre saisie est la porte d'entrée du dialogue. Là, nous vous conseillons de ne pas demander tout de suite une réécriture. Faites de votre premier geste une demande qui s'arrête à de la lecture : « Lis le README et les principaux répertoires, puis explique-moi ce que fait ce projet. »
Trois raisons. La lecture n'exige pas de confirmation, même par défaut, donc elle passe avant que vous connaissiez les usages de la validation. Vous connaissez déjà ce projet, donc vous pouvez corriger la copie. Et cela teste d'un coup la connexion, l'authentification et le dossier de travail, sans rien casser. Si quelque chose cloche, vous pouvez le régler avant de passer aux écritures.
La boucle instruction, diff, validation
Une fois la lecture passée, demandez une petite réécriture. À partir de là, ce sont les mêmes quatre temps à chaque fois.
Dites-le en français, tout simplement. Si vous pouvez nommer l'endroit à corriger, nommez-le.
Il cherche et lit les fichiers qui semblent liés. C'est le STEP 1 du chapitre 1.
« Voilà ce que je vais changer » sort ligne par ligne, et il s'arrête là.
Laissez passer et c'est appliqué. Si c'est faux, refusez et mettez l'écart en mots.
Vous : « Ajoute une section Windows au README »
↓
[RECHERCHE] chercher le README ← lecture. pas d'arrêt
↓
[LECTURE] lire README.md ← lecture. pas d'arrêt
↓
[ÉDITION] ajouter 3 lignes au README.md ← un diff apparaît, et il s'arrête
↓
Vous : approuver / refuser et dire la correction
Refuser n'est pas un échec. Comme vous pouvez être précis après avoir vu le diff, vous n'avez pas à viser la perfection dès la première instruction : c'est ce qui fait la qualité de cette forme de travail.
Gardez chaque demande à la taille d'« un diff que vous pouvez lire en entier ». Plus la demande est grosse, plus le diff est long, et les longs diffs sont approuvés sans être lus. Une validation que vous avez pressée sans lire n'est pas une validation, c'est une validation automatique. Comment découper le travail, c'est le chapitre 3.
Par quel mode commencer
Ce qui décide de l'endroit où il s'arrête, c'est le mode de permission. Dans le terminal, on change avec Shift+Tab ; dans VS Code, l'application de bureau et le navigateur, avec le sélecteur à côté du champ de saisie.
Les lectures sont automatiques. Les éditions et les commandes sont confirmées à chaque fois. C'est celui du premier jour.
Les éditions à l'intérieur du dossier de travail passent automatiquement. Pour ceux qui lisent les diffs tous ensemble après coup.
Il enquête mais ne modifie pas les sources. Approuvez le plan et il passe à l'exécution.
Un modèle de jugement distinct n'arrête que les opérations dangereuses et laisse le reste passer sans confirmation. Sous conditions.
Confirmations et contrôles de sécurité sont tous deux désactivés. Réservé aux environnements isolés. Ce n'est pas une chose à toucher le premier jour.
Ce que Shift+Tab fait défiler, ce sont les trois premiers. Le mode automatique rejoint le cycle une fois les conditions remplies, et la première fois une confirmation d'adhésion apparaît. Contourner les permissions n'est actif que si vous lancez avec son option dédiée. Pour figer un mode dès le lancement, passez claude --permission-mode plan. Il existe aussi dontAsk, qui n'apparaît jamais dans le sélecteur : il n'exécute que ce que vous avez autorisé, et n'existe que dans les réglages et la ligne de commande.
La réponse du premier jour, c'est « laissez le mode par défaut ». Chaque confirmation est un exercice pour distinguer une lecture d'une écriture d'une exécution. Desserrez une fois que vous savez les distinguer : dans l'autre sens, vous desserrez quelque chose sans savoir quoi. Le deuxième mode vers lequel se tourner, c'est le mode plan.
Certains endroits restent protégés dans tous les modes. Les écritures sur des chemins sensibles comme .git, .claude et les fichiers de configuration du shell ne sont jamais approuvées automatiquement, dans aucun mode sauf contourner les permissions. Desserrer une chose ne desserre pas tout.
Les modes sont détaillés dans l'article sur les modes de permission, et l'écriture de règles d'autorisation et de refus par outil dans l'article sur les règles de permission et les réglages. Notez que le contournement n'est pas la réponse à « les confirmations sont pénibles ». Il ne protège ni contre une fausse manipulation de votre part, ni contre une instruction glissée dans ce qu'il a lu. Pour réduire les demandes, commencez par écrire des règles qui n'autorisent que les opérations en lesquelles vous avez confiance. Le travail de conception, c'est le chapitre 5.
CLAUDE.md : arrêter de se répéter
Au bout de deux jours, vous remarquez que vous donnez les mêmes consignes encore et encore. « Ne touche pas à ce dossier », « fais passer le lint avant de committer » : les taper à chaque fois gaspille votre temps et votre contexte. Alors posez un CLAUDE.md à la racine du projet. Claude Code le lit automatiquement au lancement et travaille sur la base de ce qui y est écrit.
# Ce projet
- TypeScript / Next.js. Gestionnaire de paquets : npm
- Réponses et commentaires dans le code en français
## Ne pas toucher
- Tout ce qui est sous src/legacy/ (une autre équipe en est propriétaire)
- .env et tout ce qui en dérive
## Vérification
- Après modification, faire passer npm run lint et npm test
- Ne pas annoncer que c'est fini s'il reste des erreurs de types
Ce qu'il faut y écrire se décide par « ce que l'IA n'a aucun moyen de savoir ».
Avec quelle commande on contrôle. C'est ce qui rend possible le STEP 3 du chapitre 1, donc l'effet est maximal.
Fichiers générés, territoire d'une autre équipe, fichiers contenant des secrets. Et les conventions qu'on ne devine pas en lisant le code, comme « les nouvelles pages vont ici ».
Le genre « écris du code lisible ». On ne peut pas juger si c'est respecté, et cela ne fait que diluer les lignes que vous voulez vraiment voir respectées.
La façon de le faire grandir est arrêtée elle aussi. Quelques lignes au début. Dès que vous donnez deux fois la même consigne, ajoutez une ligne. Chercher à être exhaustif produit un fichier long et vague, qui cesse d'être respecté. Quand « ce n'est pas respecté », la cause est presque toujours l'une des trois : trop de lignes, trop d'abstraction, ou des contradictions.
Les règles de permission et le choix du modèle peuvent être répartis entre .claude/settings.json (le projet) et ~/.claude/settings.json (vous), mais le premier jour, quelques lignes de CLAUDE.md suffisent. La répartition, c'est le chapitre 6.
Les trois choses qui cassent le plus le premier jour
Les blocages ne sont pas répartis au hasard, et le premier jour ce sont presque toujours ces trois-là.
Il est bien installé, mais pas à un endroit d'où on peut l'appeler. Ajoutez ~/.local/bin (sous Windows, %USERPROFILE%\.local\bin) au PATH. Une installation en double peut aussi être en cause.
Le classique : une vieille ANTHROPIC_API_KEY qui écrase l'abonnement. Vérifiez avec /status, puis retirez la variable d'environnement avant de vous reconnecter.
Claude Code consomme 10 à 100 fois plus de tokens qu'un chat. Les allers-retours et les lectures de fichiers s'accumulent.
Le troisième point donne lieu à un malentendu. Le message disant en substance que « le serveur limite temporairement les requêtes » ne concerne pas le quota de votre formule mais un bridage temporaire côté serveur, et il passe si vous attendez un peu. Pour distinguer si vous avez touché le quota, /usage vous le dit.
claude doctor # diagnostic global : installation, config, MCP, contexte
/status # avec quelle authentification je tourne maintenant
/context # le détail de ce qui mange le contexte
claude update # dans le doute, passer à la dernière version (beaucoup de bugs partent ainsi)
La dernière, claude update, est discrètement efficace. Un nombre appréciable de bugs disparaissent rien qu'en montant de version, alors la passer avant de commencer à enquêter vous évite de courir après un problème qui n'existe pas. Les remèdes par symptôme sont dans l'article sur les erreurs fréquentes et leurs solutions. La procédure de diagnostic, c'est le chapitre 4.
Résumé
- Cinq portes d'entrée. Le contenu est le même, mais pour la première heure le terminal a l'avantage de l'information
- La voie standard est
npm install -g @anthropic-ai/claude-code. Si elle ne passe pas, Homebrew ou WinGet. Tenez-vous-en à une seule méthode - La connexion se fait par compte (quota) ou clé API (solde). Une clé dans les variables d'environnement écrase l'abonnement : dans le doute,
/status - Le premier geste est une demande en lecture seule. Elle teste d'un coup la connexion, l'authentification et le dossier de travail, sans rien casser
- Ce qui tourne, c'est instruction, diff, validation. Découpez les demandes à la taille d'un diff lisible en entier. Une validation sans lecture équivaut à une validation automatique
- Le mode du premier jour, c'est le mode par défaut (demander la permission), le deuxième, le mode plan. Les chemins protégés comme
.gitle restent dans tous les modes sauf le contournement CLAUDE.mdse met à la racine, à partir de quelques lignes. Écrivez-y la procédure de vérification, les zones interdites et les usages du lieu, et pas de généralités- Les blocages du premier jour sont le PATH, la clé dans les variables d'environnement, et la consommation. Les premiers gestes sont
claude doctor,/status,/context
Une fois la première instruction passée, il est temps de poser tout cela sur le travail quotidien. Passez au chapitre 3, « Le travail au quotidien ».