Claude Code est une IA qui vit dans votre terminal et lit et écrit directement dans votre dépôt. Coller du code dans une fenêtre de chat du navigateur, puis recopier la réponse dans votre éditeur : cet aller-retour disparaît.
Ce chapitre construit le modèle mental sur lequel reposent les six chapitres suivants. Si vous le sautez, vous ne comprendrez jamais tout à fait pourquoi les choses sont conçues ainsi dans la suite du cours.
D'abord, situer l'outil : où fonctionne-t-il ?
Les outils qui font écrire du code à une IA se répartissent en trois familles, selon l'endroit où ils s'exécutent. Claude Code appartient à la première.
Fonctionne dans le terminal et touche les fichiers directement. Claude Code, Codex CLI, et les outils du même genre. Doué pour prendre en charge un bloc de travail entier.
Intégré à l'éditeur, il propose des suggestions juste à côté de ce que vous tapez. Cursor, GitHub Copilot, et les outils du même genre. Doué pour écrire sous vos yeux.
Tout se passe dans le navigateur, et vous pouvez publier directement depuis là. v0, Bolt, Lovable, et les outils du même genre. Doué pour n'exiger aucune installation locale.
La comparaison des trois familles elle-même est traitée dans le chapitre 1 du cours de programmation avec l'IA. Ce cours-ci se restreint à la première et va en profondeur.
Claude Code n'est d'ailleurs pas réservé au terminal. La même chose existe en extension VS Code ou JetBrains, en application de bureau, et depuis le navigateur. Mais sa logique de conception part du terminal, et une fois cela compris, aucune des autres portes d'entrée ne vous déroutera.
La différence décisive avec les outils de chat
« Claude dans le navigateur sait aussi écrire du code, alors qu'est-ce qui change vraiment ? » C'est toujours la première question. La différence n'est pas l'intelligence. C'est la portée.
Il ne voit que ce que vous collez. Ce qu'il vous rend est du texte. C'est vous qui l'appliquez. Quand la modification touche 10 fichiers, cela fait 10 copies et 10 retours.
Il cherche et lit tout seul. Ce qu'il vous rend est un diff. Il lance les tests, et quand ils échouent il corrige puis les relance. Ces 10 fichiers, il les trouve lui-même.
La différence mord quand le travail implique d'aller chercher l'information. « Retrouve tous les endroits où cette fonction est appelée et corrige-les tous » : avec un outil de chat, c'est vous qui faites la recherche. Un agent lance la recherche lui-même.
Prenez le problème à l'envers : plus la portée est large, plus les dégâts sont larges quand il se trompe. C'est pour cela que les permissions demandent à être conçues (chapitre 5). Intelligent ne veut pas dire sûr.
La boucle d'agent : collecter, agir, vérifier
Pendant que Claude Code travaille, le même cycle tourne en dessous.
Il cherche des fichiers, les lit, et lance une recherche quand il le faut. Ce que vous lui laissez lire ici décide du résultat.
Il réécrit des fichiers et lance des commandes. C'est ici que se trouve la barrière des permissions.
Il lit la sortie des tests et des vérifications de types. En cas d'échec, il revient au STEP 1.
Ce qui compte, c'est que le STEP 3 existe. Un outil de chat s'arrête à « c'est probablement ça ». Un agent peut exécuter sa propre production et le vérifier. Sa capacité à corriger jusqu'à ce que les tests passent vient de cette boucle.
Ce qui veut dire aussi que l'avantage disparaît sur les tâches que vous ne pouvez pas vérifier. « Nettoie ce code » n'a aucune définition de la réussite, alors la boucle tourne à vide. Le schéma abordé au chapitre 3, lui donner d'emblée un moyen de vérifier, vient directement de là.
Outils et permissions : ce qu'il peut faire, ce que vous pouvez arrêter
Ce que Claude Code peut faire est fixé par l'ensemble des « outils » qui lui ont été confiés. Lire un fichier, écrire un fichier, exécuter une commande, chercher : chacun est un outil à part entière.
Et chaque appel d'outil passe par une vérification de permission. Par défaut, il demande votre accord chaque fois qu'il réécrit un fichier ou lance une commande. Il existe des réglages qui sautent cette validation, et le chapitre 5 traite de ce à quoi il faut y faire attention.
Vous : « Corrige les tests autour de l'authentification »
↓
[RECHERCHE] trouver les fichiers liés à l'auth ← lecture. pas de confirmation par défaut
↓
[LECTURE] lire auth.test.ts ← lecture
↓
[ÉDITION] réécrire auth.test.ts ← écriture. la demande arrive ici
↓
[EXÉCUTION] lancer npm test ← exécution. nouvelle demande ici
↓
lire l'échec, retour à [ÉDITION]
Une fois ce cheminement visible, vous savez pourquoi il s'est arrêté là où il s'est arrêté. Il n'a pas buté sur un obstacle. Il a rencontré une barrière de permission.
La fenêtre de contexte comme contrainte
Il y a un plafond à ce que Claude Code peut « garder en tête » d'un coup. Ce plafond, c'est la fenêtre de contexte. Plus la conversation dure et plus il lit de fichiers, plus elle se remplit.
À mesure qu'elle se remplit, deux choses se produisent.
Il relit un énorme historique à chaque tour, donc il ralentit et coûte plus cher. Cela rejoint directement la question du coût au chapitre 7.
Les prémisses que vous aviez posées au départ sont poussées dehors. « Mais je te l'avais déjà dit », c'est généralement cela.
Le remède, c'est de replier la conversation : soit la résumer et la compresser, soit la couper et en démarrer une neuve. Savoir quand replier demande du jugement, alors Faut-il lancer /compact à la main ? passe les critères en revue. Les manipulations concrètes sont au chapitre 3.
Ce à quoi il convient, et ce à quoi il ne convient pas
On saisit la forme d'un outil en apprenant ce à quoi il est mauvais.
Corrections qui traversent plusieurs fichiers / exploration de code existant / itération jusqu'à ce que les tests passent / travail de migration répétitif / remontée d'un message d'erreur vers sa cause
Travail sans définition du correct / terrain que vous ne pouvez pas exécuter et vérifier / décisions métier que vous êtes seul à connaître / corrections d'une ligne (l'aller-retour de validation coûte plus cher)
Le versant « mauvais terrain » n'est pas une question de capacité. Il est structurel : la boucle de vérification ne peut pas tourner. C'est pour cela que passer à un modèle plus intelligent ne règle rien.
La carte de ce cours
Voici où se situent les six chapitres restants. Lire dans l'ordre est la voie par défaut, mais si vous êtes déjà bloqué, commencer au chapitre 4 convient très bien.
L'installer, le connecter, et faire passer votre première instruction.
Poser le travail sur les rails explorer, planifier, implémenter, valider.
Une procédure pour descendre du symptôme vers la cause.
Concevoir jusqu'où déléguer et où l'arrêter.
Quand recourir à CLAUDE.md, aux hooks, aux sous-agents et à MCP.
Le savoir-faire opérationnel pour l'utiliser sur la durée.
Il existe aussi un site d'apprentissage officiel. Anthropic met à disposition une plateforme d'apprentissage gratuite, Claude Academy, qui comprend un cours sur Claude Code. Ce cours-ci ne le remplace pas. Il penche vers des explications en français, reconstruites à rebours à partir de cas où des gens se sont réellement bloqués. Utiliser les deux devrait être la voie la plus rapide.
Résumé
- Claude Code est un outil de type agent qui fonctionne dans le terminal et lit et écrit directement dans votre dépôt
- L'écart avec les outils de chat n'est pas l'intelligence mais la portée. Il cherche tout seul, rend des diffs, et exécute pour vérifier
- En dessous tourne une boucle collecter, agir, vérifier. Parce que le STEP 3 existe, il peut corriger jusqu'à ce que les tests passent
- Ce qu'il peut faire est fixé par l'ensemble de ses outils, et chaque appel d'outil passe une barrière de permission
- Quand la fenêtre de contexte se remplit, il devient poussif et perd le début. Décider quand replier demande du jugement
- Le mauvais terrain, ce sont les tâches où la boucle de vérification ne peut pas tourner. Changer de modèle ne règle rien
À ce stade, vous devriez avoir une prise sur le type d'outil qu'est Claude Code. Ensuite, nous allons vraiment le faire tourner. Passez au chapitre 2, « Installation et la première heure ».