Analyse du code source de Claude Code : pourquoi est-il meilleur que les autres outils de programmation IA ?

Titre original : "Comprendre le code source de Claude Code d'Anthropic en un article : pourquoi est-il tout simplement meilleur que les autres ?"

Auteur original : Yuker, chercheur en IA

Le 31 mars 2026, le chercheur en sécurité Chaofan Shou a découvert que dans la version npm d'Anthropic du package Claude Code, le fichier source map n'avait pas été supprimé.

Cela signifie que le code source TypeScript complet de Claude Code, soit 512 000 lignes et 1903 fichiers, a été exposé sur l'internet public.

Bien sûr, il m'était impossible de lire autant de code en quelques heures, j'ai donc abordé ce code source avec trois questions :

1. Quelle est la différence fondamentale entre Claude Code et les autres outils de programmation IA ?

2. Pourquoi l'écriture de code semble-t-elle "meilleure" qu'ailleurs ?

3. Que cachent exactement ces 510 000 lignes de code ?

Après lecture, ma réaction initiale a été : ce n'est pas seulement un assistant de programmation IA ; c'est un système d'exploitation.

I. Commençons par une histoire : si vous deviez embaucher un programmeur à distance

Imaginez que vous ayez embauché un programmeur à distance et que vous lui ayez donné un accès distant à votre ordinateur.

Comment géreriez-vous cela ?

Si vous étiez Cursor : vous le feriez asseoir à côté de vous, et chaque fois qu'il doit taper une commande, vous jetteriez un coup d'œil et cliqueriez sur "autoriser". C'est simple, mais vous devez le surveiller en permanence.

Si vous étiez un agent GitHub Copilot : vous lui donneriez une machine virtuelle toute neuve pour travailler. Une fois terminé, il soumet le code, vous le révisez, puis vous le fusionnez. C'est sécurisé, mais il ne peut pas voir votre environnement local.

Si vous étiez Claude Code :

Vous le laisseriez utiliser votre ordinateur directement, mais vous l'auriez équipé d'un système de sécurité extrêmement sophistiqué. Ce qu'il peut faire, ce qu'il ne peut pas faire, quelles actions nécessitent votre approbation, ce qu'il peut faire seul, et même s'il veut utiliser rm -rf, cela doit passer par 9 niveaux de révision avant exécution.

Voici trois philosophies de sécurité totalement différentes :

Pourquoi Anthropic a-t-il choisi la voie la plus difficile ?

Parce que c'est la seule façon pour que l'IA puisse travailler avec votre terminal, votre environnement et votre configuration - c'est ce que signifie "vraiment vous aider à coder", au lieu de "écrire un morceau de code dans une salle blanche puis le copier".

Mais quel est le coût ? Ils ont écrit 510 000 lignes de code pour cela.

II. Votre perception de Claude Code vs le vrai Claude Code

La plupart des gens pensent que les outils de programmation IA fonctionnent ainsi :

Entrée utilisateur → Appel API LLM → Obtenir le résultat → Montrer à l'utilisateur

Le vrai Claude Code fonctionne ainsi :

Entrée utilisateur
→ Assemblage dynamique de 7 couches de prompts système
→ Injection de l'état Git, des conventions de projet, de la mémoire historique
→ 42 outils avec chacun un manuel
→ Le LLM décide quel outil utiliser
→ 9 couches de révision de sécurité (analyse AST, classificateurs ML, vérifications sandbox...)
→ Résolution de conflit de permissions (clavier local/IDE/hook/classificateur IA en compétition simultanée)
→ Délai anti-fatigue de 200ms
→ Exécution de l'outil
→ Retour des résultats en streaming
→ Le contexte approche-t-il de la limite ? → Compression en trois étapes (micro-compression → auto-compression → compression complète)
→ Besoin de parallélisme ? → Génération d'un essaim de sous-agents
→ Boucle jusqu'à l'achèvement de la tâche

Je pense que tout le monde est très curieux à ce sujet, mais ne vous inquiétez pas, décortiquons-les un par un.

III. Le premier secret : les prompts ne sont pas écrits, ils sont "assemblés"

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

Remarquez ce SYSTEM_PROMPT_DYNAMIC_BOUNDARY ?

C'est un délimiteur de cache. Le contenu au-dessus du délimiteur est statique et peut être mis en cache par l'API Claude pour économiser sur les coûts de tokens. Le contenu en dessous est dynamique — votre branche Git actuelle, votre configuration de projet CLAUDE.md, vos préférences mémorisées... chaque interaction est unique.

Qu'est-ce que cela signifie ?

Anthropic traite les mots-clés comme une sortie de compilateur pour optimiser. La partie statique est le "binaire compilé", et la partie dynamique est les "paramètres d'exécution". Les avantages de cette approche sont :

1. Économie de coûts : La partie statique est mise en cache, évitant les frais redondants

2. Vitesse : Les hits de cache sautent directement le traitement de ces tokens

3. Flexibilité : La partie dynamique permet à chaque interaction d'être consciente de l'environnement actuel

Chaque outil a son propre "Manuel d'utilisation"

Ce qui est encore plus stupéfiant, c'est que chaque répertoire d'outil contient un fichier prompt.ts — c'est un manuel d'utilisation spécifiquement conçu pour le LLM.

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

Ce n'est pas un document pour les humains, c'est un code de conduite pour le comportement de l'IA. Chaque fois que Claude Code démarre, ces règles sont injectées dans les prompts système.

C'est pourquoi Claude Code ne fait jamais de git push --force de lui-même, alors que certains outils pourraient le faire — ce n'est pas que le modèle est plus intelligent, c'est que les instructions ont déjà énoncé les règles.

De plus, la version interne d'Anthropic est différente de celle que vous utilisez

Le code a de nombreuses branches comme celle-ci :

ant fait référence au personnel interne d'Anthropic. Leur version a des directives de style de code plus détaillées ("N'écrivez pas de commentaires sauf si le POURQUOI n'est pas évident"), une stratégie de sortie plus agressive ("Écriture en pyramide inversée"), et certaines fonctionnalités expérimentales encore en test A/B (Agent de vérification, Agent d'exploration et de planification).

Cela illustre qu'Anthropic est le plus grand utilisateur de Claude Code. Ils utilisent leur propre produit pour développer leur propre produit.

Quatre. Le deuxième secret : 42 outils, mais vous n'avez vu que la partie émergée de l'iceberg

Ouvrez src/tools.ts, et vous verrez le registre des outils :

42 outils, mais la plupart d'entre eux, vous ne les avez jamais vus directement. C'est parce que beaucoup d'outils sont chargés paresseusement — seulement lorsque le LLM en a besoin, ils sont injectés à la demande via ToolSearchTool.

Pourquoi faire cela ?

Parce que pour chaque outil supplémentaire, le prompt système a besoin d'une description supplémentaire, et le token coûte plus cher. Si vous voulez juste que Claude Code vous aide à changer une ligne de code, il n'a pas besoin de charger le 'Planificateur de tâches Cron' et le 'Gestionnaire de collaboration d'équipe'.

Il existe une conception encore plus intelligente :

Définissez CLAUDE_CODE_SIMPLE=true, et Claude Code ne gardera que trois outils : Bash, Lire le fichier, Modifier le fichier. C'est une porte dérobée pour les minimalistes.

Tous les outils proviennent de la même usine

Faites attention à ces valeurs par défaut : isConcurrencySafe est défini sur false par défaut, isReadOnly est défini sur false par défaut.

C'est ce qu'on appelle une conception "fail-closed" (sécurité par défaut) — si l'auteur d'un outil oublie de déclarer les attributs de sécurité, le système supposera qu'il est 'non sécurisé et inscriptible'. Il vaut mieux être trop prudent que de manquer un seul risque.

La loi de fer de 'Lire avant d'écrire'

Le FileEditTool vérifiera si vous avez déjà lu ce fichier en utilisant le FileReadTool. Sinon, il générera directement une erreur et n'autorisera pas la modification.

C'est pourquoi Claude Code ne va pas "écrire magiquement un extrait de code pour écraser votre fichier" comme certains outils — **il est tenu de comprendre avant de modifier**.

5. Le troisième secret : système de mémoire — pourquoi il peut "se souvenir de vous"

Quiconque a utilisé Claude Code a un sentiment : il semble vraiment vous connaître.

Vous lui dites "ne simule pas la base de données dans les tests", et il ne simulera pas lors de la prochaine interaction. Vous lui dites "je suis ingénieur backend, débutant en React", et il expliquera le code front-end en utilisant des analogies backend.

Derrière cela se trouve un système de mémoire complet.

Utiliser l'IA pour récupérer des souvenirs

Claude Code utilise une autre IA (Claude Sonnet) pour déterminer "quels souvenirs sont pertinents pour la conversation actuelle"

Pas de correspondance de mots-clés, pas de recherche vectorielle — il laisse un petit modèle scanner rapidement tous les titres et descriptions des fichiers de mémoire, en sélectionnant jusqu'aux 5 plus pertinents, puis en injectant leur contenu complet dans le contexte de la conversation actuelle.

La stratégie est "la précision plutôt que le rappel" — mieux vaut manquer un souvenir potentiellement utile qu'en injecter un non pertinent polluant le contexte.

Mode KAIROS : "Rêver" la nuit

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

Il y a un indicateur de fonctionnalité dans le code appelé KAIROS. Dans ce mode, les souvenirs des longues conversations ne sont pas stockés dans des fichiers structurés mais dans des entrées de type journal ajoutées par date. Ensuite, il y a une compétence /dream qui s'exécute pendant la "nuit" (faible activité), distillant ces journaux bruts en fichiers thématiques structurés.

L'IA organise les souvenirs pendant qu'elle "dort". Ce n'est plus de l'ingénierie ; c'est de la bionique.

6. Le cinquième secret : ce n'est pas un agent, c'est un groupe

Lorsque vous demandez à Claude Code d'effectuer une tâche complexe, il pourrait faire ceci discrètement :

Il génère un sous-agent.

Et le sous-agent a une injection stricte de "conscience de soi" pour l'empêcher de générer récursivement plus de sous-agents :

Ce morceau de code dit : "Tu es un travailleur, pas un manager. Ne pense pas à embaucher plus de gens, fais le travail toi-même."

Modèle de coordinateur : Modèle de manager

Dans le modèle de coordinateur, Claude Code devient un pur orchestrateur de tâches, ne faisant pas le travail lui-même, juste en déléguant :

Principes fondamentaux écrits dans les commentaires du code :

"Le parallélisme est votre super-pouvoir" pour les tâches de recherche en lecture seule : exécutez en parallèle. Pour les tâches d'écriture de fichiers : exécutez en série par groupe de fichiers (évitant les conflits).

Optimisation du cache de prompt à l'extrême

Pour maximiser le taux de réussite du cache des sous-agents, tous les résultats utilitaires des sous-agents dérivés utilisent le même texte de remplacement :

"Fork démarré — traitement en arrière-plan"

Pourquoi ? Parce que le cache de prompt de l'API de Claude est basé sur une correspondance de préfixe au niveau des octets. Si les octets de préfixe de 10 sous-agents sont identiques, alors seul le premier a besoin d'un "démarrage à froid", les 9 restants atteignent directement le cache.

C'est une optimisation qui économise quelques centimes par appel, mais à grande échelle, cela peut économiser une quantité significative de coûts.

Sept, le sixième secret : compression triple couche pour garantir des dialogues qui "ne dépassent jamais les limites"

Tous les LLM ont une limite de fenêtre de contexte. Plus la conversation est longue, plus il y a de messages historiques, et cela finira par dépasser la limite.

Claude Code a conçu une compression triple couche pour cela :

Couche 1 : Micro-compression — Coût minimal

La micro-compression ne touche qu'aux résultats des anciens appels d'outils — remplaçant "Contenu du fichier de 500 lignes lu il y a 10 minutes" par [Contenu du résultat de l'ancien outil effacé].

Les mots de prompt et le fil de dialogue sont entièrement conservés.

Couche 2 : Auto-compression — Réduction proactive

Lorsque la consommation de tokens approche 87 % de la fenêtre de contexte (taille de la fenêtre - 13 000 tampons), déclenchement automatique. Il y a un disjoncteur : arrêter les tentatives après 3 échecs de compression consécutifs pour éviter une boucle.

Couche 3 : Compression complète — Résumé par IA

Demander à l'IA de générer un résumé de toute la conversation, puis remplacer tous les messages historiques par le résumé. Il y a un précepte strict lors de la génération du résumé :

Pourquoi si strict ? Parce que si l'IA fait des appels d'outils supplémentaires pendant le processus de résumé, cela entraînerait une consommation de tokens supplémentaire, ce qui serait contre-productif. Ce prompt dit essentiellement : "Ta tâche est de résumer, ne fais rien d'autre."

Budget de tokens compressés :

· Récupération de fichier : 50 000 tokens

· Plafond par fichier : 5 000 tokens

· Contenu de compétence : 25 000 tokens

Ces chiffres ne sont pas arbitraires — ils représentent un point d'équilibre entre "conserver suffisamment de contexte pour continuer à travailler" et "libérer suffisamment d'espace pour recevoir de nouveaux messages."

8. Ce que j'ai appris après avoir lu ce code source

90 % du travail de l'agent IA est en dehors de l'"IA"

Dans les 510 000 lignes de code, la partie appelant réellement l'API LLM représente probablement moins de 5 %. Qu'en est-il des 95 % restants ?

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

· Système de permissions (décision quadratique autoriser/refuser/demander/passer)

· Gestion du contexte (compression triple couche + récupération de mémoire par IA)

· Récupération d'erreurs (disjoncteur, backoff exponentiel, persistance de la transcription)

· Coordination multi-agents (orchestration d'essaim + communication par boîte aux lettres)

· Interaction UI (140 composants React + pont IDE)

· Optimisation des performances (stabilité du cache de prompt + préchargement parallèle au démarrage)

Si vous construisez un produit d'agent IA, ce sont les vrais problèmes que vous devez résoudre. Il ne s'agit pas de savoir à quel point votre modèle est intelligent ; il s'agit de savoir à quel point votre échafaudage est robuste.

Une bonne ingénierie de prompt est une ingénierie système

Il ne s'agit pas seulement de créer un joli prompt. Les prompts de Claude Code incluent :

· Assemblage dynamique à 7 couches

· Chaque outil est livré avec un manuel d'utilisation autonome

· Les limites de cache sont précisément délimitées

· Les versions internes et externes ont des ensembles d'instructions différents

· L'ordre des outils est fixe pour maintenir la stabilité du cache

C'est une gestion de prompt ingéniérée, pas de l'artisanat.

Concevoir pour l'échec

Chaque dépendance externe a une politique d'échec correspondante :

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

42 outils = Système d'appel système Système de permissions = Gestion des permissions utilisateur Système de compétences = App Store Protocole MCP Protocol = Pilote de périphérique Essaim d'agents = Gestion des processus Compression de contexte = Gestion de la mémoire Persistance de la transcription = Système de fichiers

Ce n'est pas un "chatbot plus quelques outils" ; c'est un système d'exploitation avec un LLM en son cœur.

Résumé

510 000 lignes de code. 1903 fichiers. 18 fichiers sécurisés juste pour un seul outil Bash.

9 niveaux de contrôle juste pour avoir en toute sécurité une IA qui vous aide à taper une commande.

C'est la réponse d'Anthropic : Pour rendre l'IA vraiment utile, vous ne pouvez pas l'enfermer dans une cage ou la laisser courir librement. Vous devez construire un cadre de confiance complet autour d'elle.

Et le coût de ce système de confiance est de 510 000 lignes de code.

Post original