Ce que le leak de Claude Code révèle vraiment : une méthodologie pour construire des agents IA

Le 31 mars 2026, un fichier .map de 59.8 MB a été publié accidentellement dans le package npm de Claude Code. 512 000 lignes de TypeScript, 1 906 fichiers. Tout le harness agentique d'Anthropic exposé au grand jour.

Tout le monde en a parlé, et c'est bien normal. Les codenames de futurs modèles (Capybara, Tengu), l'agent autonome KAIROS, les faux outils anti-distillation. C'est du bon matériel pour les gros titres.

Mais ce qui m'intéresse, c'est autre chose. En étudiant les analyses techniques publiées à partir de ce code, et en regardant le projet claw-code qui a reproduit l'architecture from scratch en Python et Rust pour des raisons légales, j'ai trouvé quelque chose de plus précieux que des codenames : une méthodologie. Sept principes de conception que je confronte à ce que je construis avec herbert-rs, et qui sont applicables par n'importe qui.

Le chiffre qui change tout

Avant d'entrer dans la méthodologie, un seul chiffre :

GPT-4 sur SWE-bench Lite : 2.7% avec un scaffold basique, 28.3% avec CodeR [1]. Même modèle. 10x de différence.

Et un deuxième :

Opus 4.5 avec trois scaffoldings différents (Augment, Cursor, Claude Code) : 17 problèmes d'écart sur 731 issues SWE-bench [2].

La conclusion est brutale : le choix du modèle n'est pas le facteur déterminant. L'infrastructure autour du modèle (le scaffold [3], le harness, l'outillage) compte autant, voire plus. C'est exactement ce que le code de Claude Code confirme dans chaque fichier.

Sebastian Raschka arrive à la même conclusion. Le jour même du leak, il publie Claude Code's Real Secret Sauce (Probably) Isn't the Model [4] où il identifie les mêmes patterns : repo context, prompt cache, outils structurés, réduction de contexte, mémoire, sous-agents. Il développe ensuite l'analyse dans Components of a Coding Agent avec un mini coding agent en Python. Sa formulation : "the surrounding system plays as much of a role as the model itself". Les principes qui suivent sont une lecture du code de Claude Code à travers cette même grille.

Principe 1. Le scaffold compte plus que le modèle

Le code leaké révèle un système de 50+ outils organisés en registre plugin. Le modèle ne "code" pas. Il orchestre des appels structurés (lire un fichier, lancer une commande, chercher un pattern) et le scaffold exécute.

Chaque outil a un niveau de risque (LOW, MEDIUM, HIGH). Le scaffold décide si l'action passe directement, demande une confirmation, ou est bloquée. Le modèle propose, le scaffold dispose.

Ce design a une conséquence directe : on peut changer de modèle sans changer le système. Opus, Sonnet, ou un modèle tiers, le scaffold reste identique. Le code confirme d'ailleurs l'existence de feature flags pour basculer entre modèles.

La leçon : si vous construisez un agent IA, commencez par le scaffold, pas par le choix du modèle. Le modèle est un composant remplaçable. Le scaffold est votre produit.

C'est la même approche dans herbert-rs : le moteur d'inférence est découplé du modèle. Le format des poids, l'architecture du transformer, les opérateurs, tout est modulaire. Le modèle passe, le moteur reste.

Principe 2. Le prompt est l'architecture

Le system prompt [3] de Claude Code fait environ 38 000 à 50 000 tokens [3]. C'est un document structuré, pas une instruction vague.

Mais le plus remarquable, c'est que l'orchestration multi-agent est définie dans le prompt, pas dans le code. Le mode Coordinator, qui répartit le travail entre sous-agents, est une directive textuelle. Pas du code TypeScript. Pas du branching. Du texte.

L'avantage est évident : changer le comportement de l'orchestration, c'est changer un texte. Pas de compilation, pas de release, pas de déploiement. Un A/B test de stratégies d'orchestration se fait en modifiant une section du prompt et en activant un feature flag [3] GrowthBook.

Le prompt contient aussi des directives comportementales précises. Pas d'emojis sauf demande explicite. Réponses concises. Action d'abord, raisonnement ensuite. Et surtout : évaluer la réversibilité et le blast radius de chaque action avant de l'exécuter.

La leçon : dans un système agentique, le prompt n'est pas une configuration, c'est l'architecture. Investissez dans sa structure autant que dans votre code.

Principe 3. La mémoire est un hint, pas une vérité

Claude Code implémente un système mémoire à 3 couches :

L'index est limité à 200 lignes. Chaque entrée est un pointeur, pas du contenu. Quand le modèle a besoin de détails, il charge le topic file correspondant. L'historique brut n'est accessible qu'en recherche.

La consolidation se fait en arrière-plan via un sous-agent forké (autoDream) qui fusionne les observations, supprime les contradictions, et met à jour l'index. Trois conditions doivent être remplies : 24h depuis la dernière consolidation, 5+ sessions accumulées, et un verrou acquis.

Mais le principe de design le plus important est celui-ci :

"La mémoire dit que X existe" ≠ "X existe maintenant."

Le modèle est instruit de toujours vérifier contre le code réel avant d'agir sur un souvenir. Si la mémoire contredit la réalité, c'est la réalité qui gagne, et la mémoire est mise à jour.

Ce pattern n'est pas un choix arbitraire d'Anthropic. Andrej Karpathy décrit indépendamment la même architecture dans un thread récent sur la mémoire personnalisée des agents IA. Ses quatre principes : mémoire explicite et inspectable (pas une boîte noire), fichiers markdown plutôt qu'une base de données ("file over app"), données sous le contrôle de l'utilisateur, et modèle interchangeable ("BYOAI"). C'est exactement ce que fait MEMORY.md : des fichiers markdown, vérifiables, locaux, indépendants du modèle.

Plus frappant encore : dans les réponses au thread, un utilisateur décrit son propre système avec "cron jobs and a dream cron to clean up stale memories/contradictions", de la mémoire partagée entre providers, et de la synchronisation en temps réel. C'est autoDream et KAIROS, réinventés par un praticien qui n'a jamais vu le code de Claude Code.

Quand le même pattern émerge indépendamment chez Anthropic, chez Karpathy, et chez des utilisateurs individuels, ce n'est plus un choix d'implémentation. C'est un principe.

La leçon : la mémoire d'un agent est un cache, pas une base de données. Elle accélère, mais elle ne fait pas autorité. Concevoir votre système de mémoire avec cette distinction change tout : vous évitez les hallucinations basées sur des souvenirs périmés.

Principe 4. La sécurité en profondeur, pas en largeur

Le fichier bashSecurity.ts contient 23 vérifications numérotées appliquées à chaque commande avant exécution. 18 builtins Zsh bloqués (eval, exec, source, trap...). Détection d'injection Unicode (zero-width spaces). Vérification de traversée de chemin avec normalisation Unicode.

Mais les 23 checks ne sont que la première couche. L'architecture complète en compte cinq :

Le système de permissions a 5 modes : Default (confirmations fréquentes), Allow Edits (fichiers OK, bash confirmé), Auto (classification ML), Bypass, et YOLO (tout passe, pour le développement). Un classifieur ML détermine le risque des commandes en mode Auto.

Et 5 CVEs [3] publiques documentent des bypasses trouvés et corrigés via HackerOne, preuve que la surface d'attaque est réelle et activement testée.

La leçon : la sécurité d'un agent IA n'est pas un firewall unique, c'est un oignon. Chaque couche suppose que la précédente a échoué. Et le fait qu'Anthropic ait un bug bounty actif montre que la sécurité n'est jamais "terminée".

Principe 5. Read parallèle, Write sériel

Le système multi-agent de Claude Code définit trois types de sous-agents :

L'orchestration suit quatre phases : Research (parallèle, lecture seule) → Synthesis (coordinateur fusionne) → Implementation (sérielle, un seul agent écrit) → Verification (parallèle, tests et reviews).

La règle de concurrence est simple : les opérations de lecture (Glob, Grep, Read) s'exécutent en parallèle. Les opérations d'écriture (Edit, Write, Bash) s'exécutent en série. Un seul agent modifie les fichiers à un instant donné.

Le coordinateur a des directives explicites dans son prompt : "Do not rubber-stamp weak work" et "You must understand findings". Ces directives empêchent le pattern du coordinateur passif qui relaie sans valeur ajoutée.

La leçon : l'orchestration multi-agent suit les mêmes règles que la programmation concurrente. Les lectures sont parallélisables, les écritures sont exclusives. Et le coordinateur doit comprendre ce qu'il coordonne, sinon il est un goulot d'étranglement sans valeur ajoutée.

Principe 6. Concevoir pour le coût dès le départ

Le system prompt de Claude Code est divisé en deux par un marqueur SYSTEM_PROMPT_DYNAMIC_BOUNDARY :

• Section statique : outils, règles de base, instructions. Identique pour tous les utilisateurs d'une organisation. Cacheable.
• Section dynamique : MEMORY.md, CLAUDE.md, contexte projet. Spécifique à chaque session.

Le prompt caching [3] facture les tokens cachés à 1/10e du prix. Cette division réduit le coût du system prompt d'environ 90%, soit la différence entre ~$0.75 et ~$0.075 par requête avec Opus 4.6.

Le fichier promptCacheBreakDetection.ts surveille 14 vecteurs qui peuvent invalider ce cache : changement de MEMORY.md, toggle de mode, ajout d'outil, changement de modèle... Chaque vecteur a sa mitigation. Les "sticky latches" empêchent les oscillations de mode (plan → normal → plan) de casser le cache à chaque toggle.

Et un commentaire dans autoCompact.ts révèle un bug historique :

"1,279 sessions had 50+ consecutive failures wasting ~250K API calls/day globally"

Le fix : un circuit breaker [3] à 3 échecs consécutifs maximum. Simple, efficace, et probablement économiquement significatif à l'échelle d'Anthropic.

La leçon : dans un système IA en production, le coût n'est pas un problème d'optimisation, c'est une contrainte architecturale. Concevoir la structure du prompt pour le cache, surveiller les vecteurs d'invalidation, et mettre des circuit breakers partout. Chaque appel API qui ne produit rien est de l'argent brûlé.

C'est une préoccupation que je retrouve dans herbert-rs : l'inférence locale élimine le coût par token, mais le coût en compute reste. Chaque opération matricielle inutile est du temps perdu. L'obsession du coût se traduit différemment (API vs compute), mais le principe est le même.

Principe 7. Du réactif au proactif : KAIROS

KAIROS est référencé 150+ fois dans le codebase. C'est un agent daemon [3], un processus persistant qui tourne en continu, compilé à false dans les builds publics mais entièrement présent dans le code.

L'architecture : un cron toutes les 5 minutes, des webhooks GitHub, des daemon workers, et un budget de 15 secondes par cycle d'action proactive. L'agent vérifie l'état des PRs, exécute des tâches planifiées, consolide sa mémoire via le skill /dream.

Des outils exclusifs lui sont réservés : envoi de fichiers à l'utilisateur, notifications push, abonnement aux événements de PR. Le mode Brief est activé par défaut, avec des réponses minimales et un focus sur l'action.

Aucun concurrent connu n'a d'équivalent. Cursor, OpenHands, Copilot sont réactifs. Devin est autonome mais sans la persistence daemon ni la consolidation mémoire. KAIROS représente le passage de l'outil qui répond à l'agent qui anticipe.

La leçon : l'avenir des agents IA n'est pas le chat interactif. C'est le daemon intelligent qui travaille en arrière-plan, priorise, et n'interrompt l'humain que quand c'est nécessaire. Le budget de 15 secondes est un détail de design brillant : il empêche l'agent de monopoliser les ressources tout en restant utile.

Bonus. L'anti-distillation, ou comment protéger sa valeur

Un aspect inattendu du code : les mécanismes anti-distillation. La distillation [3] comportementale (entraîner un petit modèle sur les outputs d'un gros) est la menace existentielle des agents propriétaires.

Claude Code implémente quatre contre-mesures :

Les faux outils sont activés par quatre conditions simultanées : flag compile-time, lancement via CLI, provider Anthropic first-party, et flag GrowthBook actif. Si un distilleur entraîne sur ces données, son modèle apprend des outils qui n'existent pas.

C'est une stratégie pragmatique : elle ne bloque pas les attaquants déterminés (un proxy MITM suffit à contourner les fake tools), mais elle augmente le coût de la distillation au-dessus du seuil de rentabilité pour la majorité des acteurs.

La leçon : dans l'économie de l'IA, la valeur n'est plus dans le modèle (ils sont de plus en plus ouverts) mais dans le scaffold. Et le scaffold se protège par des mécanismes d'empoisonnement de données, pas par l'obscurité du code, puisque, comme ce leak le prouve, le code finit toujours par fuiter. D'ailleurs, le projet claw-code a démontré qu'on peut reproduire l'architecture entière from scratch en Python et Rust, à partir des seules analyses publiques. Preuve que la méthodologie, elle, n'est pas un secret.

Ce que j'en retiens pour herbert-rs

Ces sept principes ne sont pas théoriques. En construisant herbert-rs, un moteur d'inférence LLM en Rust et assembleur, je retrouve les mêmes arbitrages :

1. Le scaffold > le modèle : herbert-rs est conçu pour être agnostique au modèle. Le moteur d'inférence est un composant dans une chaîne plus large.
2. L'architecture modulaire : chaque opérateur (matmul, attention, RoPE) est un module remplaçable, optimisable indépendamment.
3. Le coût comme contrainte : en inférence locale, le "coût" est en cycles CPU/GPU. Chaque opération est profilée. Le même principe que les 14 vecteurs de cache-break, appliqué au compute.
4. La sécurité en couches : Rust élimine toute une classe de bugs mémoire par construction. C'est une couche de sécurité structurelle, pas un check à l'exécution.

Le leak de Claude Code confirme ce que les praticiens savent déjà : le modèle est nécessaire, le scaffold est suffisant. La méthodologie pour construire le scaffold, voilà ce qui fait la différence.

Sources

Les analyses sur lesquelles cet article s'appuie :

• Alex Kim, Claude Code Source Leak : analyse technique détaillée
• Kuber Studio, 512K Lines Analysis : l'analyse la plus complète
• WaveSpeedAI, Architecture Analysis : architecture du harness
• Marc Bara, What the Leak Actually Reveals : prompt as architecture
• Anthropic Engineering, Infrastructure Noise : source officielle
• Penligent, Security Analysis : CVEs et sécurité

[3] Glossaire

• Scaffold (ou harness) : l'infrastructure logicielle qui entoure le modèle IA. C'est le code qui reçoit les demandes du modèle, exécute les actions (lire un fichier, lancer une commande), gère les permissions, et retourne les résultats. Le modèle "pense", le scaffold "fait".
• System prompt : le texte d'instruction envoyé au modèle au début de chaque conversation. Il définit son comportement, ses outils, ses règles. Dans Claude Code, il fait ~50 000 tokens.
• Tool call : un appel structuré du modèle vers un outil. Le modèle émet du JSON ("je veux lire tel fichier"), le scaffold l'exécute et retourne le résultat.
• Prompt caching : technique qui évite de retransmettre les parties invariantes du prompt à chaque requête. Les tokens cachés coûtent 10x moins cher.
• Circuit breaker : pattern qui coupe une opération après N échecs consécutifs, pour éviter de gaspiller des ressources en boucle.
• MoE (Mixture of Experts) : architecture de modèle où seule une fraction des paramètres est activée par requête. Permet d'avoir un gros modèle (120B) avec un coût d'inférence d'un petit (5B actifs).
• Distillation : technique qui entraîne un petit modèle à reproduire le comportement d'un gros. "Anti-distillation" désigne les mécanismes pour empêcher ce clonage.
• Feature flag : interrupteur dans le code qui active ou désactive une fonctionnalité sans redéployer. GrowthBook est un outil de feature flags.
• Daemon : processus qui tourne en arrière-plan en continu, par opposition à un programme lancé puis terminé.
• SWE-bench : benchmark qui mesure la capacité d'un agent IA à résoudre de vraies issues GitHub. 2 294 problèmes issus de projets Python open-source.
• Token : unité de texte utilisée par les modèles de langage. Un mot courant = 1 token, un mot rare ou technique = 2-3 tokens. Les coûts API sont facturés au token.
• CVE (Common Vulnerabilities and Exposures) : identifiant unique pour une faille de sécurité connue. CVE-2025-XXXXX = une vulnérabilité documentée publiquement.
• Webhook : mécanisme où un service externe (GitHub, Slack...) envoie automatiquement une notification HTTP quand un événement se produit (nouvelle PR, commentaire...).
• MITM (Man-In-The-Middle) : attaque où un intermédiaire intercepte les communications entre deux parties. Un proxy MITM peut modifier les requêtes API en transit.
• RAG (Retrieval-Augmented Generation) : technique qui enrichit le prompt d'un modèle avec des documents retrouvés par recherche, plutôt que de compter uniquement sur ce que le modèle a mémorisé.
• Blast radius : terme emprunté à la sécurité militaire. En ingénierie logicielle, désigne l'étendue des dégâts potentiels si une action tourne mal.

[1] CodeR: Issue Resolving with Multi-Agent and Task Graphs (arXiv 2406.01304). CodeR utilise un framework multi-agent avec des graphes de tâches prédéfinis pour résoudre des issues GitHub. Le même GPT-4 passe de 2.7% (scaffold RAG basique) à 28.3% avec cette orchestration. Code source : NL2Code/CodeR.

[2] Terminal-Bench 2.0 : 6 points d'écart entre la configuration d'infrastructure la plus riche et la plus pauvre, avec le même modèle.

[4] Sebastian Raschka. Le jour du leak : Claude Code's Real Secret Sauce (Probably) Isn't the Model (31 mars 2026, 2 830 likes). Puis l'analyse développée : Components of a Coding Agent, avec un mini coding agent en Python. Raschka est l'auteur de Build a Large Language Model (From Scratch) et Build a Reasoning Model (From Scratch).

Reproduction indépendante :

• claw-code : port clean-room de l'architecture en Python/Rust, maintenu par des agents IA

Mon travail connexe :

• herbert-rs : moteur d'inférence LLM en Rust et assembleur
• Panorama LLM open-source 2026 : l'article compagnon sur les modèles
• Répertoire de benchmarks (71 benchmarks) : référence des benchmarks utilisés dans cet article

Des questions sur cet article ou votre propre projet ? Réserver une consultation