Un binaire de 100 mégas pour un CLI
Anthropic vient d’annoncer que Claude Code est maintenant disponible en native build. Traduction : un exécutable binaire que tu peux installer avec un curl et qui n’a pas besoin de Node.js.
Ça sonne bien, non ? Une commande, sans dépendances, auto-updates en arrière-plan. Le rêve de tout outil CLI.
Mais il y a un détail : le binaire fait 100 Mo.
Pour mettre ça en perspective, le binaire de git fait environ 3 Mo. Celui de curl moins de 1 Mo. Même Go, qui a la réputation de générer des binaires lourds, dépasse rarement les 15-20 Mo.
Qu’est-ce qu’il y a dedans ces 100 mégas ?
C’est pas Rust, c’est Bun déguisé en exécutable
Quand j’ai vu l’annonce, ma première pensée a été : “Ils ont tout réécrit en Rust”. Ça a du sens, non ? Si tu veux un binaire natif, rapide et sans runtime, Rust c’est l’option évidente.
Eh ben non.
Claude Code c’est toujours du TypeScript. Ce qu’ils ont fait, c’est utiliser bun build --compile pour l’empaqueter comme exécutable.
Comment fonctionne bun build --compile
La commande magique c’est ça :
| |
Qu’est-ce que ça fait exactement ? Trois choses :
1. Bundling
D’abord, Bun agit comme bundler. Il prend ton fichier d’entrée (index.ts), résout tous les import, et génère un unique fichier JavaScript avec tout le code concaténé. Il inclut tes dépendances de node_modules, fait du tree-shaking pour éliminer le code mort, et minifie le résultat.
Jusqu’ici, rien de différent de ce que fait esbuild ou webpack.
2. Embedding
C’est là que ça devient intéressant. Bun prend ce bundle de JavaScript et le incruste à l’intérieur d’un exécutable avec le runtime de Bun complet.
L’exécutable résultant a cette structure (simplifiée) :
┌─────────────────────────────────┐
│ Runtime de Bun (~95 Mo) │
│ ├── JavaScriptCore engine │
│ ├── APIs natives (fs, http) │
│ ├── Zig runtime │
│ └── libc statique │
├─────────────────────────────────┤
│ Ton code bundlé (~5 Mo) │
│ └── JavaScript minifié │
└─────────────────────────────────┘
Quand tu exécutes le binaire, le runtime de Bun extrait le code JavaScript de lui-même et l’exécute. C’est comme un fichier ZIP auto-extractible, mais pour du code.
3. Cross-compilation
Bun peut générer des binaires pour d’autres plateformes :
| |
Tu n’as pas besoin d’avoir Linux pour générer un binaire Linux. Bun inclut les runtimes précompilés pour chaque plateforme.
JavaScriptCore vs V8
Node.js utilise V8, le moteur JavaScript de Chrome. Bun utilise JavaScriptCore (JSC), le moteur de Safari.
Pourquoi c’est important ? Parce que ce sont des bêtes différentes :
| Aspect | V8 (Node) | JavaScriptCore (Bun) |
|---|---|---|
| Temps de démarrage | ~50ms | ~5ms |
| Performance de pointe | Très haute | Haute |
| Utilisation mémoire | Plus élevée | Plus faible |
| JIT tiers | 2 (Ignition → TurboFan) | 4 (LLInt → Baseline → DFG → FTL) |
JSC a un démarrage plus rapide parce qu’il a plus de tiers de compilation JIT. Il commence par interpréter le code très rapidement (LLInt) et va optimiser en arrière-plan pendant l’exécution. V8, par contre, a besoin de faire plus de travail initial avant de commencer à exécuter.
Pour un CLI qui démarre, fait quelque chose, et se termine, ces 45ms de différence au démarrage comptent. Pour un serveur qui tourne pendant des heures, ça compte moins.
Pourquoi Zig (et pas Rust, ni C++)
Bun est écrit principalement en Zig, avec un peu de C++ pour les parties qui interagissent avec JavaScriptCore.
Jarred Sumner, le créateur de Bun, a choisi Zig pour plusieurs raisons :
Interopérabilité avec C : Zig peut appeler du code C sans overhead ni FFI. JavaScriptCore est écrit en C++, et Zig peut s’y lier directement.
Contrôle mémoire sans garbage collector : Comme Rust, mais avec une syntaxe plus simple et sans le borrow checker qui t’arrache les mains.
Compilation croisée triviale : Zig peut compiler pour n’importe quelle plateforme depuis n’importe quelle plateforme. Tu n’as pas besoin d’une machine Linux pour compiler pour Linux.
Binaires petits (relativement) : Un “Hello World” en Zig fait ~5KB. En Go, ~2MB. En Rust, ~300KB.
Le résultat c’est un runtime qui démarre vite, utilise peu de mémoire, et peut se distribuer comme un unique binaire statique. Exactement ce qu’il te faut pour ça.
Ce que c’est PAS
Pour que ce soit clair : ce n’est pas de la compilation AOT (Ahead-of-Time) comme fait GraalVM avec Java ou WASM.
Ton code TypeScript ne se transforme pas en instructions CPU. Il est toujours interprété par JavaScriptCore à l’exécution. La seule chose qui change c’est que l’interpréteur vient empaqueté avec le code.
C’est le même truc que fait :
pkgpour Node.jsPyInstallerpour Pythonelectron-builderpour les apps Electron
C’est pas de la magie. C’est mettre le runtime et le code dans le même paquet. C’est pour ça que ça fait 100 Mo — la majeure partie c’est JavaScriptCore et les APIs de Bun, pas le code de Claude Code.
Qu’est-ce qu’Anthropic y gagne ?
Voilà le truc. Parce que ce changement c’est pas pour toi.
Moins de tickets de support
Tu sais combien de problèmes npm ça donne ? Permissions pétées, cache corrompu, conflits de versions de Node, PATH mal configuré, node_modules de 800 Mo qui disparaissent mystérieusement…
Chacun de ces problèmes c’est un ticket de support. Chaque ticket de support c’est de l’argent et du temps. Multiplie par les millions d’utilisateurs de Claude Code et tu comprendras pourquoi Anthropic a décidé d’éliminer npm de l’équation.
Auto-updates sans friction
Avec npm, mettre à jour Claude Code nécessite que l’utilisateur exécute npm update -g @anthropic/claude-code. Certains le font. Beaucoup ne le font pas.
Avec le native build, les mises à jour se font automatiquement en arrière-plan. Anthropic a le contrôle total sur quelle version tu utilises. Pour une entreprise qui itère vite et corrige les bugs constamment, c’est de l’or.
Environnement contrôlé
Quand tu reçois un rapport de bug, la première chose que tu demandes c’est : “Quelle version de Node tu as ? Quelle version de npm ? Quel système d’exploitation ?”. Avec le native build, tout ça disparaît. L’environnement d’exécution est le même pour tous.
Bugs plus reproductibles = bugs plus faciles à corriger.
Et qu’est-ce que l’utilisateur y gagne ?
Si tu n’as pas Node.js installé
Amélioration claire. Avant tu avais besoin de :
- Installer Node.js
- Configurer le PATH (si ça s’est pas fait automatiquement)
- Installer npm (vient avec Node, mais parfois faut le mettre à jour)
- Exécuter
npm install -g @anthropic/claude-code - Prier pour qu’il n’y ait pas de conflits
Maintenant tu as besoin de :
| |
Pour quelqu’un qui n’est pas développeur — un product manager, un rédacteur, un designer — la différence est abyssale.
Si tu as déjà Node.js
Honnêtement, tu gagnes peu. Peut-être que tu évites quelques problèmes occasionnels de npm. Les auto-updates c’est pratique. Le syntax highlighting natif qui vient seulement dans le native build c’est un nice-to-have.
Mais si tu avais déjà Claude Code qui fonctionnait avec npm, le changement est basiquement latéral. Tu vas pas sentir de différence au quotidien.
Les 100 Mo en perspective
Je sais que ça sonne énorme. 100 Mo pour un CLI. Nos grands-parents programmaient avec 4KB de RAM et nous on télécharge 100 mégas pour exécuter des commandes.
Mais soyons réalistes :
- VS Code fait ~300 Mo
- Slack ~500 Mo
- Le SDK d’iOS ~30GB
- Un projet moyen de Node.js a un
node_modulesde 500 Mo+
Et mon favori : macOS Sequoia inclut 45GB de fonds d’écran.
Quarante-cinq gigaoctets. De wallpapers. Vidéos en 4K de méduses flottantes, vagues qui se brisent, et aurores boréales pour que ton Mac ait un économiseur d’écran joli. C’est 450 fois la taille de Claude Code. Pour. Des. Fonds. D’écran.
Claude Code te donne un assistant IA qui peut écrire du code, exécuter des commandes, et gérer des projets entiers. Les fonds d’écran d’Apple te donnent… des méduses.
En 2026, avec la fibre 1Gbps et des SSD de 1TB comme standard, 100 Mo c’est du bruit statistique. Tu le télécharges en quelques secondes, tu le sauvegardes et tu oublies.
C’est élégant ? Non. Ça compte en pratique ? Non plus. Et ça compte certainement moins que les foutues méduses.
Tu devrais migrer ?
Si tu as la version npm et qu’elle fonctionne bien, y a pas le feu. Tu peux migrer en exécutant claude install depuis la version npm.
Si tu installes Claude Code pour la première fois, utilise le native build. C’est l’option recommandée et celle qui te donnera le moins de problèmes.
Si tu fais partie de ceux que ça dérange d’avoir un binaire de 100 Mo qui prend de la place, tu peux continuer avec npm. Anthropic dit qu’ils vont maintenir les deux options, même si c’est clair quelle est la mise de l’avenir.
Le pattern qui se répète
C’est pas nouveau. C’est le même pattern qu’on voit encore et encore en software :
- Tu commences avec des dépendances partagées (DLLs, librairies du système, npm packages)
- Tu rencontres des problèmes de compatibilité, versions, et distribution
- Tu finis par tout empaqueter ensemble dans un blob lourd qui fonctionne simplement
Docker a fait pareil. Electron a fait pareil. Bun fait pareil.
C’est la solution la plus élégante ? Non. C’est celle qui donne le moins de problèmes ? Presque toujours oui.
Parfois l’ingénierie c’est pas de trouver la solution la plus jolie, mais celle qui génère le moins de tickets de support. Et Anthropic, avec ses milliards de chiffre d’affaires et millions d’utilisateurs, le sait mieux que personne.
Connexes :
- Bun : Le runtime qui veut mettre Node à la retraite — Tutorial complet de Bun pour les devs qui viennent de Node, incluant le rachat par Anthropic.
- 10 GB de VM pour un chatbot — Pourquoi Claude Desktop met Ubuntu entier dans ton Mac. Une autre décision d’Anthropic qui priorise “ça marche” sur “élégant”.