What Claude Code actually does

La semaine dernière j'ai construit une intégration Stripe complète (flow de checkout, handler de webhook, mises à jour de base de données, gestion d'erreurs) en un seul prompt. Quatorze fichiers créés ou modifiés. Deux échecs de build attrapés et corrigés automatiquement. Je n'ai pas écrit une seule ligne de code.

Ce n'est pas de l'autocomplétion. Ce n'est pas un chatbot qui génère des snippets que vous collez. C'est un agent autonome qui lit votre codebase, prend des décisions, exécute des changements, et vérifie son propre travail.

Pour comprendre pourquoi ça marche (et surtout, comment faire en sorte que ça marche bien), il vous faut la réalité mécanique, pas la version marketing. Et la première chose que la version marketing cache, c'est que « Claude Code » n'est pas une seule chose. Ce sont deux, branchées dans une boucle. Mettez ce câblage clairement en tête maintenant, parce que tout le reste de ce cours en découle.

Le modèle et le harness

Il y a deux pièces dans chaque outil d'agentic coding. La plupart des gens les traitent comme une seule. Elles ne le sont pas.

Le modèle tourne sur les serveurs d'Anthropic. Claude Opus, Claude Sonnet : ce sont des modèles de langage. Ils reçoivent du texte, raisonnent sur le code, et produisent du texte. Ils sont exceptionnels pour décider quoi faire. Seuls, ils ne peuvent pas lire vos fichiers, lancer votre build, ou éditer votre projet. Des cerveaux sans mains.

Le harness tourne sur votre machine. Claude Code est un harness, un programme dans votre terminal qui fait le pont entre vous et le modèle. Quand vous tapez un prompt, il ne fait pas que transférer votre message à Anthropic. Il assemble une requête : votre message, le contexte pertinent, et la liste des outils que le modèle est autorisé à appeler. Puis il exécute localement ce que le modèle décide, et renvoie le résultat.

Le modèle ne touche jamais vos fichiers. Il renvoie des instructions structurées. Le harness les exécute.

Le harness dirige ; le modèle joue

Voici le cadrage à garder pour le reste du cours : le harness est un chef d'orchestre, le modèle est l'orchestre. Le modèle a le talent : il sait raisonner, écrire, décider. Mais il ne choisit pas quand entrer, dans quel ordre, ni sur quelle partition. Le harness le fait. Il donne le tempo, montre la prochaine section, et coupe une partie quand elle a assez joué.

Cette métaphore n'est pas de la déco. Elle mappe sur trois travaux concrets que le harness effectue à chaque tour, et qu'aucun n'est contrôlé par le modèle.

Routage des outils. Le modèle n'a pas accès brut à votre disque ou à votre shell. Il émet un appel d'outil, une requête structurée comme Read("src/app.ts") ou Bash("pnpm build"). Le harness possède les outils réels. Il reçoit cette requête, la fait correspondre à une implémentation réelle, l'exécute, capture la sortie, et remet le résultat comme prochaine chose que le modèle voit. Le modèle choisit dans un menu que le harness a écrit, et le harness est celui qui marche à la cuisine. Swappez un outil, restreignez un outil, ajoutez un nouvel outil, et vous avez changé ce que l'agent peut faire sans toucher au modèle.

Flow de permissions. Avant que le harness n'exécute un outil routé, il vérifie s'il y est autorisé. C'est une décision du harness, pas du modèle. Le modèle peut demander à lancer rm -rf, mais le harness est ce qui se tient entre la requête et votre système de fichiers. Chaque appel est checké contre vos réglages de permissions : auto-approuvé, en allowlist, ou mis en attente pour que vous confirmiez. (Au moment de Code with Claude London 2026, le mode Auto est la position par défaut recommandée, avec les allowlists et les hooks qui le rendent sûr, pas le mode Strict que vous desserrez. On couvre le curseur complet au Chapitre 6.) Le point pour l'instant : le modèle propose, le harness dispose. Vous configurez le harness, donc vous fixez la limite.

Assemblage du contexte. Le modèle est stateless. Il ne se souvient de rien entre les appels. À chaque tour, le harness reconstruit l'image entière et l'envoie à neuf : votre prompt, la conversation jusqu'ici, votre CLAUDE.md, les définitions d'outils, et les résultats des appels d'outils précédents. Le modèle ne connaît jamais que ce que le harness a choisi de mettre devant lui à ce tour. C'est pourquoi le contexte est la ressource autour de laquelle tout le cours s'articule (Chapitre 4) : vous ne gérez pas la mémoire du modèle, parce qu'il n'en a pas. Vous gérez ce que le chef d'orchestre lui remet chaque fois qu'il joue.

Les outils

Le harness expose cinq catégories d'outils. Chacune joue un rôle différent dans la boucle.

Une distinction à mettre de côté maintenant : Edit trouve une string spécifique et la remplace ; Write spécifie le fichier entier. Sur un fichier de 500 lignes où vous changez deux lignes, Edit utilise à peu près 1% du contexte que Write aurait utilisé. Ce fait précis revient fort à la Leçon 4, quand le contexte devient la contrainte derrière tout.

Pourquoi un outil terminal

Il y a plein d'outils d'agentic coding : Cursor, Windsurf, Cline, Copilot Workspace. Ce cours se concentre sur Claude Code parce qu'il tourne dans votre terminal, et ça compte plus que ça en a l'air.

Vous possédez le système d'outils. Le modèle obtient exactement les outils que le harness lui donne. Vous pouvez ajouter des outils : votre base de données, votre navigateur, votre doc. Vous pouvez les restreindre pour qu'un agent de revue lise mais n'édite jamais. Vous pouvez automatiser autour, déclencher un script à chaque fois que Claude touche un fichier. Les agents d'IDE vous filent leur set d'outils. Un harness terminal vous laisse construire le vôtre.

C'est composable. Un programme CLI peut être scripté, bouclé, pipé, et automatisé. claude -p "review this file" tourne en one-shot. Mettez-le dans un script bash. Chaînez trois appels dans un pipeline. Lancez-le en CI. Rien de tout ça n'est possible quand votre agent vit dans une fenêtre d'éditeur. (Ça a aussi une conséquence de billing qu'on voit au Chapitre 4 : les runs scriptés sont mesurés différemment des interactifs.)

La boucle par défaut, et pourquoi elle n'avance pas en ligne droite

La documentation d'Anthropic elle-même décrit la boucle agentic comme trois phases qui se mêlent : rassembler le contexte, agir, vérifier les résultats. Le mot qui fait le travail dans cette phrase, c'est se mêlent. Les phases sont réelles, mais ce n'est pas une checklist que vous cochez de haut en bas.

Si vous le lisez comme un 1 → 2 → 3 → fini propre, vous allez mal lire ce que Claude fait réellement. Les phases s'entrelacent, et la forme de cet entrelacement dépend de la tâche :

• Une question (« où est gérée l'auth ? ») est presque du gather pur. Pas d'action, pas de vérification. Une phase, fini.
• Une correction de typo collapse gather et act en un seul temps : Claude connaît déjà le fichier, l'édite, et peut ne pas vérifier du tout si vous ne lui aviez rien donné pour vérifier.
• Une correction de bug spirale à travers les trois, plusieurs fois. Gather (lire le test qui échoue) → act (patch) → verify (le lancer) → il échoue encore → gather again (lire la dépendance que vous aviez manquée) → act → verify → green. La boucle s'est resserrée autour du problème ; elle n'a pas marché en ligne droite.
• Un refactor met le gather en avant (cartographier chaque call site) et le verify en arrière (le build est le juge), avec l'action sandwichée au milieu, et un seul build qui échoue la renvoie direct au gather.

Cet entrelacement n'est pas de la négligence ; c'est le modèle qui décide, après chaque résultat, de ce que doit être la prochaine étape. Un build qui échoue est du nouveau contexte, donc verify nourrit gather. Une lecture de fichier surprenante change le plan, donc gather nourrit action en plein courant. La boucle se plie à la tâche.

Voici un run de correction de bug, avec les phases marquées pour que vous puissiez les voir se chevaucher plutôt que se mettre en queue :

Bash("pnpm test")                         [verify]  → 1 test red: null user
Read("src/auth/session.ts")               [gather]  → finds the getter
Edit("src/auth/session.ts")               [act]     → guards the null case
Bash("pnpm test")                         [verify]  → still red: different line
Read("src/auth/middleware.ts")            [gather]  → the real caller, missed first pass
Edit("src/auth/middleware.ts")            [act]     → fixes the actual bug
Bash("pnpm test")                         [verify]  → green

Trois verifies, deux gathers, deux acts, et l'ordre est dicté par ce que chaque résultat a révélé, pas par une séquence fixe. Le premier fix était mauvais, la vérification l'a dit, et cet échec est devenu le contexte du deuxième passage. C'est la boucle qui marche comme prévu.

Ce que la boucle ne fait pas toute seule

Deux choses que la boucle par défaut ne fera pas tant que vous ne les demandez pas :

Elle ne planifie pas explicitement. Le Plan Mode (Shift+Tab) sépare l'exploration de l'exécution : Claude lit, réfléchit, et vous montre un plan avant de changer quoi que ce soit. Mais c'est opt-in. Laissé par défaut, Claude peut sauter d'un gather léger direct à l'action. Quand y recourir, c'est le Chapitre 3.

Elle ne vérifie pas toujours. La vérification dépend de critères. Claude vérifie son travail quand vous lui donnez quelque chose à vérifier : « lance les tests », « le build doit passer », « matche ce screenshot ». Sans critères, elle peut sauter la phase verify entièrement et vous livrer quelque chose de non testé. Fournir des critères de vérification est l'habitude au plus fort levier de toute cette pratique ; c'est la colonne vertébrale de la prochaine leçon.

Un système, pas juste un modèle

Reculez, parce que c'est le cadre sur lequel le reste du cours est bâti. Les gens disent « Claude a écrit l'intégration », et ils imaginent le modèle en train de le faire, la partie maligne, celle avec la réputation. Mais le modèle seul n'aurait pas pu ouvrir un fichier, lancer un test, ou s'empêcher de supprimer votre repo. Ce qui a livré cette intégration Stripe, c'est le modèle et le harness, travaillant comme un seul système : le modèle décidant, le harness routant chaque action, appliquant chaque permission, et assemblant le contexte qui rendait la prochaine décision possible.

Cette distinction, c'est là que vit votre levier. Vous ne pouvez pas réentraîner le modèle. Vous pouvez modeler le harness complètement : les outils qu'il offre, les permissions qu'il applique, le contexte qu'il assemble, la boucle qu'il fait tourner. Quand ce cours enseigne CLAUDE.md, skills, hooks, subagents et modes de permission, chacun est vous qui plongez la main du côté harness du système pour le tuner. « De meilleurs résultats de Claude Code » ne signifie presque jamais un meilleur modèle. Ça signifie un harness mieux configuré autour du même modèle.

Le tradeoff que vous ne pouvez pas ignorer

Plus de pouvoir, plus de risque. L'agent lit, édite, et exécute à travers tout votre projet. Un malentendu n'est pas une mauvaise suggestion que vous effacez. C'est une mauvaise décision architecturale exécutée à travers une douzaine de fichiers avant que vous leviez les yeux.

C'est exactement pourquoi le harness possède le flow de permissions. Vous tunez ce qui tourne sans demander, du tout-confirmé à la pleine autonomie, au Chapitre 6. Le curseur existe parce que le tradeoff est réel.

Le reste de ce cours porte sur la gestion de ce tradeoff : structurer votre codebase pour que l'agent gather bien, configurer le harness pour qu'il agisse sûrement, et bâtir un système où plus d'autonomie achète de meilleurs résultats au lieu d'un blast radius plus gros.

Ce qui vient ensuite

Vous comprenez maintenant la machine : le modèle raisonne, le harness dirige, la boucle se plie à la tâche jusqu'à ce qu'elle soit finie. Comprendre la machine et en tirer le maximum sont des compétences différentes. Prochaine leçon, huit choses que vous pouvez faire aujourd'hui qui soulèvent immédiatement vos résultats, puis un coup d'œil à ce qui s'ouvre quand vous poussez plus loin.