Claude Code : le gouffre des ressources – de 11,3 Mo d’un fichier unique à 1,2 To d’absorption disque

Claude Code est un client Node.js monofichier sans gestion du cycle de vie des ressources : il charge un fichier empaqueté de 11,3 Mo au démarrage, écrit sans limite sur le disque pendant l’exécution, et le processus continue de consommer de la mémoire même après la fermeture du terminal, jusqu’à l’effondrement du système. En s’appuyant sur des rapports d’utilisateurs réels dans GitHub Issues et des analyses inverses communautaires, cet article passe en revue les défauts de gestion des ressources (mémoire, CPU, disque) de Claude Code, et expose les problèmes structurels de son architecture d’empaquetage, de son modèle de stockage et de la gestion du cycle de vie des processus. Ce ne sont pas des cas marginaux, mais des défauts d’architecture systématiques signalés de août 2025 à avril 2026, et fermés en masse par le robot stale.

Architecture d’empaquetage : le coût d’un fichier unique de 11,3 Mo

Le cœur de Claude Code est un artefact monofichier nommé cli.js, d’environ 11,3 Mo. L’utilisateur de la communauté paultendo a réalisé une analyse statique détaillée dans Issue #29481, révélant de nombreux problèmes d’architecture graves.

Temps de démarrage V8 : 32 % du temps consacré à l’analyse

Le profilage CPU montre que compileSourceTextModule consomme 31,7 % du temps d’échantillonnage pendant la phase de démarrage. Le moteur V8 met environ 300 ms à analyser ce fichier monofichier de 11,3 Mo, contre seulement 23 ms pour un script Node.js brut. 7,3 % supplémentaires sont dépensés dans l’appel spawnSync, 3,5 % dans le ramassage des ordures. Cela signifie que plus de 40 % du temps de démarrage est gaspillé en pure surcharge d’analyse avant même que l’utilisateur ne saisisse une commande.

Chargement complet : seulement 20 imports dynamiques

Le fichier empaqueté est entièrement analysé et exécuté au démarrage, avec seulement 20 expressions import(). Chaque utilisateur paie le prix de toutes les fonctionnalités, qu’il les utilise ou non. Voici les composants qui devraient être chargés à la demande mais qui sont empaquetés en totalité :

pie title Composition du fichier empaqueté (≈ 13,5 Mo)
    "Logique centrale de l’application" : 7540
    "SDK AWS Bedrock" : 1100
    "highlight.js (182 langages)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "Autres (Ink, Zod, Ajv, Axios, etc.)" : 1807

Un assistant de codage doit mettre en évidence Brainfuck, MIPS assembly, Flix, Zephir, Inform7, Lasso, etc., soit 182 langages ; cela montre déjà la grossièreté de la stratégie d’empaquetage. Conserver seulement environ 40 langages courants permettrait d’économiser environ 786 Ko d’analyse.

Redondance des dépendances : quatre clients HTTP, trois bibliothèques de validation

Chaque SDK introduit ses propres dépendances, ce qui conduit à la présence simultanée de quatre clients HTTP (Axios, Undici, Got, fetch natif) et de trois bibliothèques de validation (Zod, Ajv, JSON Schema). Dans un environnement Node 18+, fetch natif est déjà pleinement fonctionnel, rendant les clients supplémentaires inutiles.

413 appels synchrones au système de fichiers

Le fichier empaqueté contient 196 existsSync, 109 statSync, 108 readFileSync, 58 mkdirSync, soit un total de 413 appels synchrones. Chacun bloque la boucle d’événements. De nombreux appels suivent le modèle existsSync(path) && readFileSync(path), qui pourrait être remplacé par un seul try { await readFile(path) } catch {}.

1087 wrappers d’interop CJS/ESM

Chaque module CommonJS empaqueté dans l’ESM génère des shim __toESM/__commonJS/__require, pour un total de 1087. Ces shim augmentent le poids d’analyse et introduisent un léger coût d’exécution par module.

Polyfills Node 20 inutiles

Le paquet contient 62 polyfills Promise (pris en charge nativement depuis Node 0.12), 57 polyfills Symbol (Node 4), 57 helpers async (Node 8) et 3 polyfills AbortController (Node 15). Ces dépendances proviennent de bibliothèques ciblant d’anciennes versions de Node ou le navigateur, et sont totalement superflues dans l’environnement cible.

ripgrep empaquette les binaires pour 6 plateformes : 61 Mo

Les six binaires de ripgrep sont tous inclus, totalisant 61 Mo. En comparaison, sharp utilise correctement les dépendances optionnelles et n’installe que le binaire de la plateforme courante. Cela signifie qu’à chaque installation, environ 51 Mo d’espace disque sont gaspillés.

Dégradation des performances d’Ink avec la longueur du dialogue

L’interface terminal utilise Ink (React for Terminal). L’analyse montre 6457 appels createElement, 578 hooks useState, mais seulement 11 wrappers React.memo(), soit un ratio de 1,9 %. Dans Ink, chaque mise à jour d’état déclenche une réconciliation complète du DOM virtuel. Pendant le flux de réponses, chaque token reçu déclenche une mise à jour d’état, entraînant le re‑render inutile des composants non mémoïsés. À mesure que le dialogue s’allonge, la sortie rendue augmente, chaque re‑render nécessitant plus de diff du contenu terminal. Cela correspond au phénomène décrit dans Issue #22265 : « la session devient de plus en plus lente ».

Absorption disque : croissance illimitée de GB à TB

Les problèmes de disque sont le défaut de gestion des ressources le plus grave de Claude Code, avec la portée la plus large et les conséquences les plus sévères.

Fuite du module natif Windows : 20 Go par semaine

Issue #23095 décrit un problème persistant depuis plusieurs mois : le binaire natif Windows de Claude Code (claude.exe) extrait des plugins Node.js natifs dans le répertoire temporaire du système à chaque session, mais ne les nettoie jamais. Chaque fichier fait environ 6,6 Mo ; l’utilisateur SlothKing16 a accumulé 2813 fichiers en 4 jours, soit 18 Go. L’utilisateur kolkov a mesuré environ 20 Go/semaine, avec des utilisateurs intensifs atteignant 100 Go/semaine. Ce problème, signalé depuis début 2025, a été fermé à plusieurs reprises par le robot.

Répertoire ~/.claude : plus de 3 Go sans gestion

L’utilisateur kolkov a audité une machine utilisée quotidiennement pendant 8 mois dans Issue #5024 :

pie title Utilisation du répertoire ~/.claude (≈ 3,1 Go)
    "projects/ (historique des sessions)" : 2500
    "debug/ (journaux de débogage)" : 303
    "file-history/ (instantanés de fichiers)" : 232
    "history.jsonl (historique global)" : 10
    "Autres" : 55

Chiffres clés : fichier JSONL de session unique de 203 Mo, sous‑fichier JSONL d’agent de 72 Mo, history.jsonl contenant plus de 37 000 entrées. Aucun roulement, compression ou nettoyage n’est appliqué. Les instantanés dans file-history/ ne sont pas dédupliqués ; chaque édition d’un même fichier crée une copie complète. Les journaux dans debug/ ne sont jamais nettoyés.

Tâches en arrière‑plan : boucle de rétroaction auto‑référencée de 1,2 To

Issue #32282 révèle un défaut de conception incroyable. Lorsque Claude Code lance plusieurs agents en arrière‑plan et exécute automatiquement une commande bash de suivi de progression, le fichier de sortie de la commande est écrit dans le même répertoire que celui correspondant au glob, créant une boucle de rétroaction infinie :

flowchart LR
    A["bash : for f in tasks/*.output; tail -5 $f"] --> B["Écriture dans tasks/task-A.output"]
    B --> C["Glob retrouve task‑A.output lui‑même"]
    C --> D["tail -5 lit sa propre sortie"]
    D --> E["Ajout à sa propre sortie"]
    E --> C

De nombreux utilisateurs ont signalé le même problème : 1,2 To, 460 Go, 303 Go, 235 Go, 480 Go, 36 Go. Les commentateurs ont compté 70 issues liées, regroupées en 15 ensembles, les deux premiers ensembles totalisant environ 9,5 To. Le débit d’écriture peut atteindre 425 Mo/s pendant 18 minutes, jusqu’à l’épuisement du disque.

Défaillance en cascade : plantage irréversible après saturation du disque

Issue #24207 décrit la réaction en chaîne catastrophique lorsqu’un disque plein est atteint :

flowchart TD
    A["Espace disque = 0"] --> B["Échec d’écriture de .claude.json"]
    B --> C["Création d’un fichier de longueur zéro"]
    C --> D["Lecture comme JSON invalide"]
    D --> E["Écrasement de toutes les configurations de projet"]
    E --> F["Corruption du token OAuth/API"]
    F --> G["Nécessité de se ré‑authentifier"]
    G --> H["Arrêt de tous les agents/sessions en cours"]
    H --> I["Impossible de récupérer même après libération d’espace disque"]

Pas d’avertissement, pas de dégradation gracieuse, aucune voie de récupération. L’utilisateur doit arrêter manuellement tous les processus, libérer l’espace, restaurer la configuration, se ré‑authentifier et reconfigurer tout.

Écriture concurrente : pas de verrou, pas de transaction, pas de coordination

Le seul fichier de verrouillage dans ~/.claude/ est .update.lock (5 octets). Tous les autres fichiers sont écrits sans protection. Lorsque plusieurs processus Claude Code s’exécutent simultanément (agents + sous‑agents étant un scénario d’utilisation normal), ils écrivent sur les mêmes fichiers sans aucune coordination :

Sous Windows, les solutions de contournement d’écriture atomique (écrire d’abord .tmp puis rename()) échouent, car rename() renvoie EPERM si le fichier cible est détenu, détruisant l’atomicité.

Mémoire et CPU : de 13 Go RSS à un panic du noyau

Consommation mémoire extrême sous Windows

Issue #24840 rapporte un cas extrême sous Windows : RSS de 13,21 Go, engagement de mémoire virtuelle de 47,17 Go, alors que la machine ne possède que 42,56 Go de RAM. 3,75 M de fautes de page, indiquant un I/O disque constant. Sur 347 s d’exécution, le temps CPU en mode utilisateur n’est que 35 s, soit ~90 % du temps passé à attendre I/O et swap. Cela rend les autres applications (par ex. le navigateur Opera) totalement non réactives.

Panic du noyau macOS

Issue #39253 décrit des conséquences plus graves : sur un MacBook Pro M3 Pro (18 Go RAM), plusieurs instances de Claude Code provoquent un panic du noyau macOS. Deux types de panic ont été observés : Jetsam OOM kill (pression mémoire entraînant la mort du processus watchdogd crucial) et watchdog timeout (watchdogd ne s’est pas enregistré pendant plus de 90 s faute de ressources). Le système redémarre sans avertissement, sans boîte de dialogue d’erreur, sans opportunité de sauvegarder le travail.

Processus orphelin : persistance après fermeture du terminal

Issue #44507 (avril 2026, il y a quelques jours) signale un défaut fondamental de gestion du cycle de vie : le processus Claude Code continue de fonctionner après la fermeture du terminal. Un processus isolé a consommé 35,4 Go RSS en 21 jours, avec 95,5 % d’utilisation CPU. La cause première est l’absence de gestionnaire process.stdin.on("end") dans le point d’entrée CLI principal, tandis que plus de 55 timers setInterval (pour le polling, la télémétrie, le rafraîchissement de la barre d’état, etc.) maintiennent la boucle d’événements Node.js vivante indéfiniment. Le tas V8 croît sans limite, aucune pression GC n’est appliquée, aucune limite --max-old-space-size n’est définie, aucun watchdog d’auto‑arrêt.

Gel à 100 % CPU

Issue #27415 signale un gel à 100 % CPU déclenché par TaskStop, la cause étant une boucle incontrôlée de posix_spawn dans le runtime Bun. Issue #26224 rapporte que Claude Code se bloque pendant 5‑20 minutes lorsqu’il traite un grand nombre d’instructions.

Échec systémique d’une architecture à fichiers plats

Allocation sans nettoyage : un schéma architectural récurrent

Le membre de la communauté kolkov a souligné à plusieurs reprises que la cause profonde de tous ces problèmes est identique :

Cette fuite .node n’est pas un bug isolé — c’est le symptôme d’un schéma architectural récurrent où Claude Code alloue des ressources sans les nettoyer.

De 2025 à 2026, le problème est passé d’un unique fichier .claude.json gonflé à une prolifération de fichiers JSONL, mais l’architecture de base n’a pas changé : fichiers plats, aucun verrou, aucune transaction, aucun nettoyage, aucune compression.

SQLite et daemon local : alternatives proposées par la communauté

La communauté a plusieurs fois suggéré d’utiliser SQLite à la place du stockage à fichiers plats. Une base SQLite pourrait résoudre tous les problèmes : le mode WAL fournit une lecture concurrente + écriture atomique, les transactions garantissent l’intégrité « tout ou rien », la compression intégrée, le nettoyage TTL, la déduplication du contenu et la cohérence multiplateforme.

Une autre proposition est d’introduire un daemon local (similaire à un serveur LSP, à l’architecture Docker), où tous les processus Claude Code communiquent via IPC, offrant coordination sans changer le backend de stockage.

Analyse inverse communautaire vs robot stale

Le commentaire de gebeer résume parfaitement la situation :

Merci pour votre analyse détaillée. Cela aurait dû être résolu par les mainteneurs il y a longtemps.

kolkov ajoute :

Ironiquement, la communauté fait le débogage à leur place — analyse inverse du code, suivi des chemins d’erreur, propositions de correctifs avec extraits de code — et le robot stale ferme tout après 60 jours.

Comparaison avec d’autres outils de gestion des ressources

GitHub Copilot, en tant qu’extension VS Code, est soumis aux limites de mémoire et aux contraintes de cycle de vie de l’hôte d’extension ; Cursor, fork de VS Code, hérite du même cadre de gestion des ressources ; leurs stockages utilisent SQLite ou des bases similaires, offrant naturellement la concurrence et les transactions. Claude Code a choisi un processus autonome + stockage à fichiers plats, mais n’a pas implémenté les responsabilités de gestion des ressources attendues — pas de plafond mémoire, pas de quota disque, pas de watchdog de processus, pas de sortie gracieuse. Son comportement ressemble davantage à une démonstration de prototype qu’à un outil destiné à la production.

Paradoxe entre capacité du modèle et qualité d’ingénierie

Un fichier monofichier de 11,3 Mo, 413 appels synchrones au système de fichiers, 1087 wrappers CJS/ESM, aucune libération de ressources, aucune régulation de concurrence, aucune surveillance d’espace disque — ce ne sont pas des cas marginaux, mais des défauts d’architecture systémiques. De Issue #5024 (août 2025) à Issue #44507 (avril 2026), la communauté a continuellement signalé les mêmes catégories de problèmes, fourni des analyses détaillées et des suggestions de correctifs, tandis que de nombreuses issues ont été marquées « not planned » ou fermées automatiquement par le robot stale. Un outil d’IA pour le codage dont la qualité du code dépend de l’audit et de la correction par la communauté constitue un paradoxe digne de réflexion.

Si vous utilisez Claude Code, il est recommandé de vérifier régulièrement la taille du répertoire ~/.claude, de nettoyer les fichiers .node temporaires, et de vous assurer de quitter correctement avec Ctrl + C avant de fermer le terminal. Si l’espace disque disparaît soudainement, vous savez maintenant où chercher la cause.

• ←Précédent
• Suivant→