Un binaire de 100 mégas pour un CLI

Anthropic vient d’annoncer que Claude Code est désormais disponible en native build. Traduction : un exécutable binaire que vous pouvez installer avec un curl et qui n’a pas besoin de Node.js.

Ça sonne bien, non ? Une commande, aucune dépendance, des mises à jour automatiques en arrière-plan. Le rêve de tout outil CLI.

Mais il y a un détail : le binaire pèse 100 Mo.

Pour mettre en perspective, le binaire de git pèse environ 3 Mo. Celui de curl moins d'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 peut bien y avoir dans ces 100 mégas ?

Ce n’est pas Rust, c’est Bun déguisé en exécutable

Quand j’ai vu l’annonce, ma première pensée fut : “Ils ont tout réécrit en Rust”. C’est logique, non ? Si vous voulez un binaire natif, rapide et sans runtime, Rust est l’option évidente.

Eh bien, pas du tout.

Claude Code reste 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 est celle-ci :

bun build ./src/index.ts --compile --outfile claude

Que fait-elle exactement ? Trois choses :

1. Bundling

D’abord, Bun agit comme bundler. Il prend votre 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 vos dépendances de node_modules, résout le 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

Voici où ça devient intéressant. Bun prend ce bundle JavaScript et l’incruste à l’intérieur d’un exécutable avec le runtime complet de Bun.

L’exécutable résultant a cette structure (simplifiée) :

┌─────────────────────────────────┐
│   Runtime de Bun (~95 Mo)       │
│   ├── Moteur JavaScriptCore     │
│   ├── APIs natives (fs, http)   │
│   ├── Runtime Zig               │
│   └── libc statique             │
├─────────────────────────────────┤
│   Votre code bundlé (~5 Mo)     │
│   └── JavaScript minifié        │
└─────────────────────────────────┘

Quand vous exécutez 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 :

bun build ./src/index.ts --compile --target=bun-linux-x64 --outfile claude-linux
bun build ./src/index.ts --compile --target=bun-darwin-arm64 --outfile claude-mac
bun build ./src/index.ts --compile --target=bun-windows-x64 --outfile claude.exe

Vous n’avez pas besoin de 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 :

AspectV8 (Node)JavaScriptCore (Bun)
Temps de démarrage~50ms~5ms
Performance de pointeTrès élevéeÉlevée
Utilisation mémoirePlus élevéePlus faible
Niveaux JIT2 (Ignition → TurboFan)4 (LLInt → Baseline → DFG → FTL)

JSC a un démarrage plus rapide parce qu’il a plus de niveaux de compilation JIT. Il commence par interpréter le code très rapidement (LLInt) et optimise en arrière-plan pendant l’exécution. V8, en revanche, doit 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 :

  1. 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.

  2. Contrôle de la mémoire sans garbage collector : Comme Rust, mais avec une syntaxe plus simple et sans le borrow checker qui vous fait souffrir.

  3. Compilation croisée triviale : Zig peut compiler pour n’importe quelle plateforme depuis n’importe quelle plateforme. Vous n’avez pas besoin d’une machine Linux pour compiler pour Linux.

  4. Binaires petits (relativement) : Un “Hello World” en Zig pèse ~5 Ko. En Go, ~2 Mo. En Rust, ~300 Ko.

Le résultat est un runtime qui démarre vite, utilise peu de mémoire, et peut être distribué comme un unique binaire statique. Exactement ce qu’il faut pour cela.

Ce que ce N’EST PAS

Pour que ce soit clair : ce n’est pas de la compilation AOT (Ahead-of-Time) comme le fait GraalVM avec Java ou WASM.

Votre code TypeScript ne se transforme pas en instructions CPU. Il reste interprété par JavaScriptCore à l’exécution. La seule chose qui change, c’est que l’interpréteur est empaqueté avec le code.

C’est le même truc que font :

  • pkg pour Node.js
  • PyInstaller pour Python
  • electron-builder pour les apps Electron

Ce n’est pas magique. C’est mettre le runtime et le code dans le même paquet. C’est pourquoi ça pèse 100 Mo — la majeure partie est JavaScriptCore et les APIs de Bun, pas le code de Claude Code.

Que gagne Anthropic ?

Voici le point crucial. Parce que ce changement n’est pas pour vous.

Moins de tickets de support

Vous savez combien de problèmes npm peut causer ? Permissions cassé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 est un ticket de support. Chaque ticket de support coûte de l’argent et du temps. Multipliez par les millions d’utilisateurs de Claude Code et vous comprendrez pourquoi Anthropic a décidé d’éliminer npm de l’équation.

Mises à jour automatiques 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 un contrôle total sur la version que vous utilisez. Pour une entreprise qui itère rapidement et corrige des bugs constamment, c’est de l’or.

Environnement contrôlé

Quand vous recevez un rapport de bug, la première chose que vous demandez c’est : “Quelle version de Node avez-vous ? 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 que gagne l’utilisateur ?

Si vous n’avez pas Node.js installé

Amélioration claire. Avant vous aviez besoin de :

  1. Installer Node.js
  2. Configurer le PATH (si ça ne s’est pas fait automatiquement)
  3. Installer npm (livré avec Node, mais parfois il faut le mettre à jour)
  4. Exécuter npm install -g @anthropic/claude-code
  5. Prier pour qu’il n’y ait pas de conflits

Maintenant vous avez besoin de :

curl -fsSL https://claude.ai/install.sh | sh

Pour quelqu’un qui n’est pas développeur — un product manager, un rédacteur, un designer — la différence est énorme.

Si vous avez déjà Node.js

Honnêtement, vous gagnez peu. Peut-être vous évitez quelques problèmes occasionnels de npm. Les mises à jour automatiques sont pratiques. La syntax highlighting native qui ne vient qu’avec le native build est un bonus.

Mais si vous aviez déjà Claude Code qui fonctionnait avec npm, le changement est basiquement latéral. Vous ne remarquerez pas 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 4 Ko de RAM et nous voilà en train de télécharger 100 mégas pour exécuter des commandes.

Mais soyons réalistes :

  • VS Code pèse ~300 Mo
  • Slack ~500 Mo
  • Le SDK iOS ~30 Go
  • Un projet Node.js moyen a un node_modules de 500 Mo+

Et mon préféré : macOS Sequoia inclut 45 Go de fonds d’écran.

Quarante-cinq gigaoctets. De wallpapers. Des vidéos en 4K de méduses flottantes, de vagues qui déferlent, et d’aurores boréales pour que votre Mac ait un bel économiseur d’écran. C’est 450 fois la taille de Claude Code. Pour. Des. Fonds. D’écran.

Claude Code vous 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 vous donnent… des méduses.

En 2026, avec la fibre à 1 Gbps et des SSD de 1 To comme standard, 100 Mo c’est du bruit statistique. Vous le téléchargez en quelques secondes, vous le sauvegardez et vous oubliez.

Est-ce élégant ? Non. Est-ce que ça importe en pratique ? Non plus. Et ça importe certainement moins que ces fichues méduses.

Devriez-vous migrer ?

Si vous avez la version npm et qu’elle fonctionne bien, pas d’urgence. Vous pouvez migrer en exécutant claude install depuis la version npm.

Si vous installez Claude Code pour la première fois, utilisez le native build. C’est l’option recommandée et celle qui vous causera le moins de problèmes.

Si vous êtes de ceux que ça dérange d’avoir un binaire de 100 Mo qui occupe de l’espace, vous pouvez continuer avec npm. Anthropic dit qu’ils vont maintenir les deux options, même s’il est clair laquelle est le pari d’avenir.

Le motif qui se répète

Ce n’est pas nouveau. C’est le même motif qu’on voit encore et encore en informatique :

  1. Vous commencez avec des dépendances partagées (DLL, bibliothèques système, packages npm)
  2. Vous rencontrez des problèmes de compatibilité, de versions, et de distribution
  3. Vous finissez par empaqueter tout ensemble dans un gros blob qui fonctionne simplement

Docker a fait pareil. Electron a fait pareil. Bun fait pareil.

Est-ce la solution la plus élégante ? Non. Est-ce celle qui cause le moins de problèmes ? Presque toujours oui.

Parfois l’ingénierie ne consiste pas à trouver la solution la plus belle, mais celle qui génère le moins de tickets de support. Et Anthropic, avec son milliard de revenus et ses millions d’utilisateurs, le sait mieux que personne.

Articles liés :

Cet article a été rédigé en espagnol et traduit avec l’aide de l’IA.