Titre original：《Un aperçu du code source de Claude Code d’Anthropic : pourquoi c’est tout simplement plus pratique que les autres ?》

Auteur original : Yuker, analyste IA

Le 31 mars 2026, le chercheur en sécurité Chaofan Shou a découvert que le paquet Claude Code publié par Anthropic sur npm ne débarrassait pas ses fichiers source map.

Cela signifie : le code source TypeScript complet de Claude Code, 512 000 lignes, 1 903 fichiers, est exposé tel quel sur Internet.

Je ne peux évidemment pas lire autant de code en seulement quelques heures, alors je l’aborde avec trois questions :

1. Quelle différence fondamentale Claude Code a-t-il avec les autres outils de programmation IA ?

2. Pourquoi la « sensation » d’écriture est-elle meilleure que chez les autres ?

3. Dans les 510 000 lignes de code, qu’est-ce qui est caché exactement ?

Après l’avoir lu, ma première réaction a été : ce n’est pas un assistant de programmation IA, c’est un système d’exploitation.

I. D’abord, une histoire : si vous devez embaucher un développeur distant

Imaginez que vous embauchiez un développeur distant, et que vous lui donniez l’accès à distance à votre ordinateur.

Que feriez-vous ?

Si vous suivez l’approche de Cursor : vous le faites s’asseoir à côté de vous, et à chaque fois qu’il doit taper une commande, vous jetez un coup d’œil, vous cliquez sur « Autoriser ». C’est simple et brutal, mais vous devez rester à l’affût en permanence.

Si vous suivez l’approche de GitHub Copilot Agent : vous lui fournissez une toute nouvelle machine virtuelle, pour qu’il s’y débrouille librement. Une fois terminé, il envoie le code, puis vous l’examinez et le fusionnez. C’est sûr, mais il ne voit pas votre environnement local.

Si vous suivez l’approche de Claude Code :

Vous lui faites utiliser directement votre ordinateur — mais vous lui mettez en place un système de contrôle des accès extrêmement précis. Ce qu’il peut faire, ce qu’il ne peut pas faire, quelles actions nécessitent votre accord, lesquelles peut-il faire seul, et même s’il veut utiliser rm -rf, il doit passer par 9 niveaux d’inspection avant d’exécuter.

Voilà les trois philosophies de sécurité totalement différentes :

Pourquoi Anthropic a-t-il choisi le chemin le plus difficile ?

Parce que seule cette approche permet à l’IA de travailler avec votre terminal, votre environnement et votre configuration — c’est ça, « vous aider réellement à écrire du code », et pas « générer un morceau de code dans une pièce propre, puis vous le copier/coller ».

Mais quel est le prix à payer ? Pour cela, ils ont écrit 512 000 lignes de code.

II. Claude Code : ce que vous pensez, et Claude Code : ce que c’est réellement

La plupart des gens pensent que les outils de programmation IA sont comme ceci :

Saisie de l’utilisateur → appel de l’API LLM → renvoi du résultat → affichage à l’utilisateur

Claude Code est en réalité comme ceci :

Saisie de l’utilisateur
→ assemblage dynamique de 7 couches d’instructions système
→ injection de l’état Git, des conventions du projet, et de la mémoire d’historique
→ 42 outils, chacun accompagné de son propre manuel d’utilisation
→ le LLM décide quel outil utiliser
→ 9 niveaux d’examen de sécurité (parsing AST, classifieur ML, vérifications en sandbox…)
→ parsing de la compétition des autorisations (clavier local / IDE / Hook / classifieur IA en compétition simultanée)
→ délai anti-fausse manœuvre de 200 ms
→ exécution de l’outil
→ retour en streaming du résultat
→ contexte proche de la limite ? → compression en trois couches (micro-compression → compression automatique → compression totale)
→ besoin de parallélisme ? → génération de ruches de sous Agents
→ boucle jusqu’à ce que la tâche soit terminée

Beaucoup se demandent ce que c’est, mais pas de panique : décomposons tout, point par point.

III. Premier secret : ce ne sont pas des instructions écrites, c’est une « fabrication » assemblée

Ouvrez src/constants/prompts.ts et vous verrez cette fonction :

Vous voyez ce SYSTEM_PROMPT_DYNAMIC_BOUNDARY ?

C’est une ligne de séparation pour le cache. Le contenu au-dessus est statique : l’API Claude peut le mettre en cache, ce qui économise des coûts en tokens. Le contenu sous la ligne est dynamique : votre branche Git actuelle, la configuration du projet CLAUDE.md, les souvenirs de préférences que vous lui avez déjà donnés… tout change à chaque conversation.

Qu’est-ce que ça implique ?

Anthropic traite les instructions comme la sortie optimisée d’un compilateur. La partie statique, c’est « le binaire compilé », la partie dynamique, ce sont « des paramètres d’exécution ». Les bénéfices sont :

1. Économiser : la partie statique passe par le cache, sans facturation répétée

2. Accélérer : en cas de hit du cache, on saute directement le traitement de ces tokens

3. Être flexible : la partie dynamique permet à chaque conversation de percevoir l’environnement courant

Chaque outil dispose de son propre « manuel d’utilisation »

Ce qui me choque le plus, c’est que dans chaque dossier d’outil, il y a un fichier prompt.ts — c’est un manuel d’utilisation écrit spécialement pour que le LLM le lise.

Regardez le BashTool (src/tools/BashTool/prompt.ts, environ 370 lignes) :

Ce n’est pas une documentation destinée aux humains, c’est un code de conduite destiné à l’IA. À chaque fois que Claude Code démarre, ces règles sont injectées dans les instructions système.

C’est pour ça que Claude Code ne fait jamais git push --force de sa propre initiative, alors que certains outils le font — ce n’est pas que le modèle est plus intelligent ; c’est que les règles sont déjà expliquées dans les instructions.

Et en plus, la version interne d’Anthropic n’est pas la même que celle que vous utilisez

Dans le code, on trouve énormément de branches comme celle-ci :

ant correspond à un employé interne d’Anthropic. Leur version inclut des directives de style de code plus détaillées (« ne pas écrire de commentaires sauf si WHY n’est pas évident »), des stratégies de sortie plus agressives (« méthode d’écriture en pyramide inversée »), ainsi que certaines fonctionnalités expérimentales encore en tests A/B (Verification Agent, Explore & Plan Agent).

Cela montre qu’Anthropic est le plus grand utilisateur de Claude Code : ils l’utilisent pour développer leur propre produit.

IV. Deuxième secret : 42 outils, mais vous n’avez vu qu’un aperçu de l’iceberg

Ouvrez src/tools.ts et vous verrez le centre d’enregistrement des outils :

42 outils, mais la plupart d’entre vous ne les voient jamais directement. Parce que beaucoup d’outils sont chargés avec un retard : seuls quand le LLM en a besoin, ils sont injectés à la demande via ToolSearchTool.

Pourquoi faire ça ?

Parce que chaque outil en plus ajoute une portion de description dans les instructions système, et donc ajoute un coût en tokens. Si vous voulez simplement que Claude Code modifie une ligne de code, il n’a pas besoin de charger « un planificateur de tâches » et « un gestionnaire de collaboration en équipe ».

Il y a aussi une conception encore plus intelligente :

En définissant CLAUDE_CODE_SIMPLE=true, Claude Code ne conserve plus que trois outils : Bash, lire un fichier, modifier un fichier. C’est un backdoor pour les minimalistes.

Tous les outils sortent de la même usine

Notez ces valeurs par défaut : isConcurrencySafe est par défaut false, isReadOnly est par défaut false.

C’est ce qu’on appelle une conception fail-closed — si l’auteur d’un outil oublie de déclarer ses propriétés de sécurité, le système suppose qu’il est « non sûr et qu’il écrit ». Mieux vaut être excessivement prudent, et ne pas laisser passer un risque.

La règle de fer « d’abord lire, puis modifier »

FileEditTool vérifie si vous avez déjà utilisé FileReadTool pour lire ce fichier. Si non, il renvoie directement une erreur, sans autoriser la modification.

C’est pour ça que Claude Code ne vous ressemble pas certains outils qui « écrivent une portion de code à l’improviste pour remplacer votre fichier » : il est obligé de comprendre avant de modifier.

V. Troisième secret : le système de mémoire — pourquoi il peut « vous retenir »

Les personnes qui ont utilisé Claude Code ont toutes ressenti quelque chose : il semble vraiment vous connaître.

Vous lui dites « ne pas simuler (mock) la base de données dans les tests », et la prochaine conversation, il ne simulera plus. Vous lui dites « je suis ingénieur back-end, débutant React », et lorsqu’il expliquera du code front-end, il utilisera des analogies du back-end.

Derrière tout ça, il y a un système de mémoire complet.

Utiliser l’IA pour récupérer la mémoire

Claude Code utilise une autre IA (Claude Sonnet) pour décider « quelles mémoires sont liées à la conversation en cours ».

Ce n’est ni une recherche par mots-clés, ni une recherche vectorielle — c’est faire scanner rapidement à un petit modèle tous les fichiers de mémoire, en utilisant les titres et descriptions, sélectionner jusqu’à 5 des plus pertinents, puis injecter leur contenu intégral dans le contexte de la conversation actuelle.

La stratégie est « la précision avant le rappel » — mieux vaut rater un souvenir potentiellement utile que d’insérer un souvenir non pertinent qui polluerait le contexte.

Mode KAIROS : « rêver » la nuit

C’est la partie la plus science-fiction pour moi.

Le code contient une fonctionnalité appelée KAIROS. Dans ce mode, dans les longues conversations, les souvenirs ne sont pas stockés dans des fichiers structurés, mais dans un journal append-only classé par date. Ensuite, une compétence appelée /dream s’exécute « la nuit » (période de faible activité), et distille ces journaux bruts en fichiers structurés de thèmes.

Pendant que l’IA « dort », elle organise la mémoire. Ce n’est plus de l’ingénierie : c’est de la biomimétique.

VI. Cinquième secret : ce n’est pas un Agent, c’est une meute

Quand vous demandez à Claude Code de faire une tâche complexe, il peut discrètement faire ceci :

Il génère un** sous Agent.**

Et ce sous Agent dispose d’une injection stricte de « conscience de soi » pour l’empêcher de générer récursivement plus de sous Agents :

Ce bout de code dit en substance : « tu es un ouvrier, pas un manager. Ne pense pas à embaucher plus de monde ; fais-le toi-même. »

Mode Coordinator : mode manager

En mode coordinateur, Claude Code devient un simple orchestrateur de tâches : il ne fait pas le travail lui-même, il se contente de répartir :

Les principes clés sont écrits dans les commentaires du code :

« Parallelism is your superpower » : pour les tâches d’étude en lecture seulement, exécuter en parallèle. Pour les tâches d’écriture de fichiers, regrouper par fichier et exécuter en série (pour éviter les conflits).

Optimisation ultime du Prompt Cache

Afin de maximiser les « taux de hit » du cache des sous Agents, tous les résultats d’outils des sous Agents forkés utilisent le même texte de placeholder :

« Fork started—processing in background »

Pourquoi ? Parce que le prompt cache de l’API Claude fonctionne sur une correspondance de préfixe au niveau des octets. Si les préfixes en octets des 10 sous Agents sont exactement identiques, alors seul le premier nécessite un « démarrage à froid », et les 9 suivants rencontrent directement le cache.

C’est une optimisation qui économise quelques centimes à chaque appel, mais à grande échelle, elle permet de réduire énormément les coûts.

VII. Sixième secret : compression en trois couches, pour que la conversation « ne dépasse jamais la limite »

Tous les LLM ont une limite de fenêtre de contexte. Plus la conversation est longue, plus il y a de messages historiques, et au final, on dépassera forcément la limite.

Claude Code a conçu une compression en trois couches :

Première couche : micro-compression — coût minimal

La micro-compression ne modifie que les résultats d’appels d’outils anciens — remplacer le « contenu du fichier de 500 lignes lu il y a 10 minutes » par [Old tool result content cleared].

Les instructions et la ligne principale de la conversation restent totalement conservées.

Deuxième couche : compression automatique — rétrécissement proactif

Quand la consommation de tokens approche 87% de la fenêtre de contexte (taille de la fenêtre - 13,000 buffer), le déclenchement automatique se produit. Il y a un coupe-circuit : après 3 échecs consécutifs de compression, on arrête d’essayer pour éviter une boucle infinie.

Troisième couche : compression totale — résumé par l’IA

Faire produire à l’IA un résumé de toute la conversation, puis remplacer tous les messages historiques par le résumé. Lors de la génération du résumé, une instruction préalable sévère est incluse :

Pourquoi autant de sévérité ? Parce que si l’IA, pendant qu’elle résume, réutilise des outils, elle générerait davantage de tokens — ce qui irait à l’encontre du but. Cette partie du prompt dit en substance : « ta mission est de résumer, ne fais rien d’autre ».

Budget de tokens après compression :

· Restauration des fichiers : 50,000 tokens

· Limite par fichier : 5,000 tokens

· Contenu des compétences : 25,000 tokens

Ces chiffres ne sont pas sortis de nulle part — ils sont le point d’équilibre entre « conserver suffisamment de contexte pour continuer à travailler » et « libérer assez d’espace pour recevoir de nouveaux messages ».

VIII. Après avoir lu ce code source, qu’est-ce que j’ai appris

90% du travail d’un Agent IA se fait en dehors de « l’IA »

Sur 512 000 lignes de code, la partie qui appelle vraiment l’API LLM est probablement inférieure à 5%. Les 95% restants, c’est quoi ?

· Vérifications de sécurité (18 fichiers uniquement pour un BashTool)

· Système d’autorisations (décision à quatre états allow/deny/ask/passthrough)

· Gestion du contexte (compression en trois couches + récupération de mémoire par IA)

· Reprise après erreur (coupe-circuit, backoff exponentiel, persistance du Transcript)

· Coordination multi Agent (orchestration en essaim + communication par e-mail)

· Interaction UI (140 composants React + IDE Bridge)

· Optimisations de performance (stabilité du prompt cache + préchargement en parallèle au démarrage)

Si vous construisez un produit d’Agent IA, c’est ce que vous devez vraiment résoudre : ce n’est pas de savoir si le modèle est assez intelligent, c’est si votre échafaudage est assez solide.

Un bon ingénierie de prompts, c’est un travail d’ingénierie

Ce n’est pas « écrire un prompt joli » puis s’arrêter là. Le prompt de Claude Code, c’est :

· assemblage dynamique en 7 couches

· chaque outil avec son manuel d’utilisation indépendant

· délimitation précise des frontières de cache

· ensembles d’instructions différents entre version interne et version externe

· un ordre fixe des outils pour maintenir la stabilité du cache

C’est de la gestion de prompts industrialisée, pas de l’artisanat.

Conçu pour l’échec

Chaque dépendance externe a sa stratégie d’échec correspondante :

Anthropic traite Claude Code comme un système d’exploitation

42 outils = appels système + système de permissions = gestion des autorisations
compétences = système de boutique d’applications
protocole MCP = pilotes de périphériques
Agent en essaim = gestion des processus
compression du contexte = gestion de la mémoire
persistance du Transcript = système de fichiers

Ce n’est pas « un chatbot avec quelques outils » : c’est un système d’exploitation dont le noyau est le LLM.

Résumé

512 000 lignes de code. 1 903 fichiers. 18 fichiers de sécurité uniquement pour un outil Bash.

9 couches d’examen, uniquement pour permettre à l’IA de t’aider à exécuter une commande en toute sécurité.

C’est la réponse d’Anthropic : pour que l’IA soit vraiment utile, vous ne pouvez pas la fermer dans une cage, ni la laisser en liberté totale. Vous devez lui construire toute une structure de confiance.

Et le prix de cette structure de confiance, c’est 512 000 lignes de code.

Lien de l’original

Cliquez pour découvrir Law Ding BlockBeats recrute

Bienvenue à rejoindre le groupe officiel Law Ding BlockBeats :

Telegram abonnement au groupe : https://t.me/theblockbeats

Telegram groupe de discussion : https://t.me/BlockBeats_App

Compte Twitter officiel : https://twitter.com/BlockBeatsAsia