Installer Claude Code sur Windows : les deux chemins, et tout ce qui casse en route

Bon. J’ai écrit un tuto d’installation de Claude Code au début du mois de juillet, et il a pris un coup de vieux plus vite que prévu. Pas parce que la commande a changé, elle est toujours la même. Parce qu’entre-temps il y a deux façons d’installer ce truc sur Windows, qu’elles ne donnent pas le même logiciel, et que la moitié des messages d’erreur que tu peux croiser ne sont expliqués nulle part en français. Alors je reprends tout, à jour au 14 août 2026, avec les commandes exactes et la liste de ce qui casse.

Étape 0 : deux chemins, et ils ne donnent pas la même chose

C’est le malentendu qui coûte le plus de temps, donc on le règle tout de suite. Claude Code, ce n’est plus seulement une commande dans un terminal. Anthropic distribue aussi une application de bureau avec des fenêtres et des boutons, qui contient déjà Claude Code. Les deux tournent sur le même moteur et partagent la même configuration, mais tu n’installes pas la même chose.

Le point contre-intuitif est dans la troisième ligne, et je ne l’ai vu écrit nulle part ailleurs : Git est facultatif pour la version terminal, et obligatoire pour l’application de bureau si tu veux travailler sur tes fichiers en local sous Windows. C’est l’inverse de ce qu’on attend d’une application à boutons. La doc de démarrage de l’app le pose en une phrase : sur Windows, Git doit être installé pour que les sessions locales fonctionnent.

Installer l’app ne t’installe pas la commande claude dans ton terminal pour autant. La doc est explicite là-dessus : l’application inclut Claude Code, mais pour utiliser claude depuis un terminal, il faut installer le CLI séparément. Les deux peuvent cohabiter, et c’est même prévu.

La suite de cet article couvre le chemin terminal, parce que c’est celui qui casse.

Étape 1 : ce qu’il te faut vraiment (et ce dont tu n’as pas besoin)

La liste officielle des prérequis tient en quatre lignes, et elle est plus basse que ce que les gens imaginent :

• Windows 10 version 1809 ou plus récent, ou Windows Server 2019 et plus.
• 4 Go de RAM, processeur x64 ou ARM64.
• Un shell : PowerShell, CMD, Bash ou Zsh. Tu as déjà les deux premiers.
• Une connexion internet, et être dans un pays où Anthropic distribue le service.

Ce dont tu n’as pas besoin, et c’est là que les vieux tutos font perdre du temps : ni Node.js, ni npm, ni WSL, ni les droits administrateur. La doc l’écrit noir sur blanc pour le dernier point : « You do not need to run as Administrator ». Le binaire est autonome, il s’installe dans ton profil utilisateur.

En revanche il te faut un abonnement payant. Pro, Max, Team, Enterprise, ou un compte Console avec des crédits. Le plan gratuit de Claude n’inclut pas Claude Code, et c’est la question qui revient le plus souvent, donc autant l’avoir dit avant que tu tapes la commande.

Étape 2 : la commande, et surtout la bonne fenêtre

Ouvre PowerShell (touche Windows, tape « powershell », Entrée) et colle cette ligne :

irm https://claude.ai/install.ps1 | iex

Si tu préfères l’invite de commandes, ce n’est pas la même commande, et c’est là que la moitié des gens se plantent :

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Le repère pour savoir où tu es : l’invite affiche PS C:\Users\TonNom> dans PowerShell, et C:\Users\TonNom> sans le PS dans CMD. Quatre messages d’erreur différents disent en fait la même chose, à savoir que tu as collé la commande d’un autre shell. Je les mets ensemble parce que je n’ai jamais trouvé ce tableau ailleurs :

Le troisième cas est le plus vicieux, parce que curl existe bien dans PowerShell : c’est juste que ce n’est pas le vrai curl. C’est un alias vers Invoke-WebRequest, qui ne connaît pas les drapeaux -fsSL. Quand tu veux le vrai, tu écris curl.exe. J’ai mis un temps déraisonnable à comprendre ça la première fois.

Dernier cas, celui où la commande t’affiche le texte du script au lieu de l’exécuter : tu n’as collé qu’un bout de la ligne. Recolle-la en entier.

Étape 3 : le piège que rien n’annonce, PowerShell x86

Celui-là mérite sa section, parce que le message d’erreur est franchement trompeur :

Claude Code does not support 32-bit Windows

Et tu es sur une machine 64 bits. Tu le sais, tu l’as achetée. Sauf que le menu Démarrer de Windows propose deux entrées PowerShell : Windows PowerShell et Windows PowerShell (x86). La seconde lance un processus 32 bits, et l’installeur, qui regarde le processus et pas la machine, refuse poliment. Pour trancher, tape ça dans la fenêtre qui a produit l’erreur :

[Environment]::Is64BitOperatingSystem

Si ça répond True, ta machine va bien, ferme cette fenêtre et rouvre Windows PowerShell sans le suffixe x86. Si ça répond False, là c’est vraiment un Windows 32 bits, et Claude Code ne tournera pas dessus.

Étape 4 : vérifier que c’est installé, et savoir où

La commande de contrôle est la même pour tout le monde :

claude --version

Elle répond un numéro suivi du nom, du genre 2.1.202 (Claude Code). C’est ce que j’ai relevé le 14 août 2026 sur ma machine. Si tu as une version différente, c’est normal et c’est plutôt bon signe : les installations natives se mettent à jour toutes seules en arrière-plan.

Il y a une seconde commande, beaucoup moins connue, qui rend un diagnostic complet sans ouvrir de session :

claude doctor

Elle affiche l’état de l’installation, les erreurs de validation de tes fichiers de réglages, le résultat de la dernière tentative de mise à jour, et les avertissements avec une correction proposée. C’est en lecture seule, ça ne touche à rien. Quand quelque chose cloche, commence par là plutôt que par un forum.

Maintenant, où est-ce que ça s’est posé ? L’installeur natif place le programme ici :

%USERPROFILE%\.local\bin\claude.exe

Et si claude --version te répond 'claude' is not recognized alors que l’installation s’est bien passée, c’est que ce dossier n’est pas dans ton PATH, la liste des endroits où Windows cherche les programmes. Le vérifier :

$env:PATH -split ';' | Select-String '\.local\\bin'

Si ça n’affiche rien, tu l’ajoutes à ton PATH utilisateur avec ces deux lignes, puis tu ouvres un nouveau terminal (l’ancien garde son ancien PATH, c’est la cause d’à peu près la moitié des « ça ne marche toujours pas ») :

$currentPath = [Environment]::GetEnvironmentVariable('PATH', 'User')
[Environment]::SetEnvironmentVariable('PATH', "$currentPath;$env:USERPROFILE\.local\bin", 'User')

Cas particulier qui piège les gens de VS Code : l’extension VS Code n’installe pas la commande claude. Elle embarque sa propre copie privée du CLI pour son panneau de discussion, et ne l’ajoute pas au PATH. Si tu n’as installé que l’extension, le fichier ci-dessus n’existe pas, et c’est attendu.

Étape 5 : Git for Windows, optionnel mais pas neutre

Je l’ai dit à l’étape 0, Git n’est pas obligatoire pour la version terminal. Ce qui change sans lui, c’est l’outil que Claude Code utilise pour exécuter des commandes : avec Git for Windows, il passe par Git Bash et dispose de l’outil Bash ; sans, il se rabat sur PowerShell. Les deux marchent. Le second colle mal avec les scripts et les chaînes d’outils écrits pour Bash.

Si Git est installé mais que Claude Code ne le trouve pas, il y a une raison documentée et pas évidente. Quand la variable n’est pas définie, il cherche bash.exe dans un ordre précis, et il ignore volontairement un git qui se trouverait dans le dossier depuis lequel tu l’as lancé, ou en dessous dans un chemin contenant node_modules, .venv ou env. C’est une protection : il refuse d’exécuter un binaire qu’un projet aurait déposé là. Si ton Git vit dans un dossier de ce genre, tu dois le désigner explicitement. Trouve-le d’abord :

where.exe git

Puis pointe le bash.exe de cette installation dans ton fichier settings.json :

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

Note les doubles antislashs : c’est du JSON, un antislash simple y est un caractère d’échappement. Erreur classique, et le fichier est alors ignoré en silence.

Natif ou WSL : le tableau qui tranche vraiment

« Faut-il WSL ? » est la question la plus posée sur ce sujet, et la réponse courte est non. La réponse utile est un tableau, celui de la doc officielle, dont la colonne du milieu ne se trouve dans aucun tuto français que j’aie lu :

Le bac à sable, c’est le mécanisme qui isole les commandes que Claude Code exécute pour qu’elles ne touchent pas au reste de la machine. Il n’existe pas sur Windows natif. Si tu comptes laisser l’agent enchaîner des commandes sans valider chacune, ce n’est pas un détail de confort, c’est le seul argument sérieux en faveur de WSL 2. Sur ce sujet, j’en ai parlé plus longuement ailleurs.

À lire ensuite : Claude Code passe en mode auto par défaut, ce que l’étude d’Anthropic mesure vraiment.

Dans l’autre sens, WSL a un coût mesuré et documenté : quand ton projet vit côté Windows (/mnt/c/) et que Claude Code tourne côté Linux, la recherche de fichiers rend moins de résultats qu’attendu. Elle fonctionne, elle est juste incomplète, et le diagnostic claude doctor affiche quand même « OK ». La doc donne trois sorties : demander des recherches plus ciblées, déplacer le projet dans le système de fichiers Linux (/home/), ou repasser en Windows natif.

Et si tu es en WSL 1 avec l’installeur Linux, tu tomberas sur Exec format error. La conversion se fait depuis PowerShell, avec le nom de ta distribution.

Les emmerdes déjà documentées

Celles-là, je ne les ai pas toutes rencontrées, elles sont dans la page de dépannage officielle. Je les rassemble parce que cette page est en anglais et que personne ne la traduit.

• Taper claude ouvre l’application de bureau au lieu du terminal. Une ancienne version de Claude Desktop enregistre un Claude.exe dans le dossier WindowsApps, qui passe devant dans le PATH. Mets à jour l’application de bureau.
• SecurityError au lancement, avec un fichier claude.ps1 dans le message. Ça ne concerne que les installations par npm : la stratégie d’exécution de PowerShell bloque les lanceurs .ps1 que npm fabrique. Détail savoureux : cette stratégie ne gêne pas l’installeur irm | iex, qui exécute du texte téléchargé et non un fichier de script. C’est un argument de plus pour l’installeur natif.
• The process cannot access the file ... because it is being used by another process. L’installeur n’a pas pu écrire dans %USERPROFILE%\.claude\downloads. En général un antivirus en train de scanner le binaire à moitié téléchargé, ou une autre fenêtre d’installation restée ouverte. Ferme tout, supprime le dossier, relance.
• syntax error near unexpected token '<' ou une erreur d’analyse pleine de balises HTML. Le serveur t’a renvoyé une page web au lieu du script, et iex essaie d’exécuter du HTML. Même cause qu’un 403 nu : filtrage réseau, proxy d’entreprise, ou pays non desservi.
• Erreurs TLS, CRYPT_E_NO_REVOCATION_CHECK, schannel. Classique en entreprise : le réseau bloque la vérification de révocation des certificats. Il existe un contournement côté curl, mais la vraie solution passe par l’équipe informatique et le certificat du proxy.
• Plusieurs claude installés en même temps. Le symptôme est un numéro de version qui ne bouge pas après une mise à jour. La doc recommande de n’en garder qu’un, l’installation native. Pour la petite histoire, ma machine est exactement dans ce cas : la commande y résout encore un claude.ps1 hérité d’une installation npm, et le dossier .local\bin n’existe même pas. Ça marche, et c’est précisément le genre de configuration qui produit l’erreur d’execution policy plus haut.

Mettre à jour, épingler, désinstaller

Les installations natives se mettent à jour seules, en arrière-plan, et la nouvelle version prend effet au démarrage suivant. Les autres non : Homebrew, WinGet et les gestionnaires de paquets Linux demandent une mise à jour manuelle. Pour forcer tout de suite :

claude update

Il y a deux canaux de publication. latest, celui par défaut, te donne chaque version dès sa sortie. stable te tient environ une semaine en arrière et saute les versions qui ont des régressions majeures. Ça se règle dans /config, rubrique du canal de mise à jour, ou dans settings.json :

{
  "autoUpdatesChannel": "stable"
}

Le détail qui évite une mauvaise surprise : passer de latest à stable peut te faire redescendre de version. Le réglage minimumVersion pose un plancher que ni la mise à jour automatique ni claude update ne franchissent vers le bas.

Pour désinstaller une installation native, il n’y a rien dans « Ajout et suppression de programmes », puisque rien n’a été installé au sens Windows du terme. Deux commandes :

Remove-Item -Path "$env:USERPROFILE\.local\bin\claude.exe" -Force
Remove-Item -Path "$env:USERPROFILE\.local\share\claude" -Recurse -Force

Ça laisse tes réglages et ton historique de sessions dans %USERPROFILE%\.claude. Si tu veux vraiment tout enlever, supprime aussi ce dossier et le fichier .claude.json, en sachant que tu perds au passage tes autorisations, tes serveurs MCP et ton historique. Et si l’extension VS Code, le greffon JetBrains ou l’application de bureau sont encore installés, ils recréeront le dossier au prochain lancement.

Le script qu’on exécute à l’aveugle

Parlons de la chose que tout le monde fait sans y penser, moi le premier. irm ... | iex télécharge du code sur un serveur distant et l’exécute immédiatement, avec tes droits, sans que rien ne s’écrive sur ton disque entre les deux. C’est commode et c’est un acte de confiance pur.

La bonne nouvelle, c’est qu’il existe de quoi vérifier, et que c’est très peu documenté côté français. Chaque version publie un fichier manifest.json contenant les sommes de contrôle SHA256 de tous les binaires, et ce manifeste est signé avec une clé GPG d’Anthropic. Vérifier la signature du manifeste vérifie donc, de proche en proche, chaque binaire qu’il liste. L’empreinte à retrouver :

31DD DE24 DDFA B679 F42D  7BD2 BAA9 29FF 1A7E CACE

Plus simple sur Windows, et suffisant pour la plupart des gens : le binaire porte une signature Authenticode au nom d’« Anthropic, PBC », et Windows sait la vérifier tout seul.

Get-AuthenticodeSignature .\claude.exe

Pour comparer une somme de contrôle à celle du manifeste, la commande est native aussi :

(Get-FileHash claude.exe -Algorithm SHA256).Hash.ToLower()

Une réserve honnête : les signatures détachées du manifeste n’existent que pour les versions à partir de la 2.1.89. Avant, il y a bien des sommes de contrôle, mais pas de signature pour les authentifier.

Alors, tu installes quoi ?

Si tu ne veux pas voir un terminal de ta vie, prends l’application de bureau, et installe Git avant, sinon les sessions locales ne démarreront pas. Si tu veux scripter, lancer des tâches sans session interactive, ou juste comprendre ce qui se passe sous le capot, prends la version terminal avec l’installeur natif : il se met à jour tout seul, il ne demande pas l’administrateur, et il se désinstalle en supprimant deux dossiers.

Ce que je ne recommande plus : l’installation par npm. Elle exige désormais Node.js 22 ou plus récent, elle fabrique un lanceur .ps1 que la stratégie d’exécution de PowerShell peut bloquer, et elle n’apporte rien de plus, puisqu’elle télécharge exactement le même binaire natif. J’y suis encore par flemme, pas par choix.

Et si tu te demandes surtout ce que ce truc fait réellement, et combien il coûte par mois, la fiche complète est à côté.

Les questions qui reviennent

Faut-il WSL pour installer Claude Code sur Windows ?

Non. Claude Code s’installe et tourne nativement sur Windows 10 version 1809 et plus récent, avec une seule commande PowerShell et sans droits administrateur. WSL 2 reste utile pour une seule raison sérieuse : c’est la seule configuration Windows où le bac à sable d’exécution des commandes est supporté.

Claude Code est-il gratuit ?

Non. Il faut un abonnement Pro, Max, Team ou Enterprise, ou un compte Console avec des crédits. Le plan gratuit de Claude n’y donne pas accès, ce qui est la source de confusion la plus fréquente. Deux voies permettent tout de même de ne rien payer, un programme réservé aux mainteneurs open source et un modèle local qui n’est pas Claude : elles sont testées et chronométrées dans notre banc d’essai de Claude Code gratuit.

Faut-il installer Node.js ?

Non. L’installeur natif pose un binaire autonome qui n’utilise pas Node à l’exécution. Node n’est nécessaire que si tu passes par npm, et il faut alors la version 22 ou plus récente.

Faut-il être administrateur ?

Non. La doc le précise explicitement, l’installation se fait dans ton profil utilisateur.

Où Claude Code s’installe-t-il sur Windows ?

Le programme va dans %USERPROFILE%\.local\bin\claude.exe, les versions dans %USERPROFILE%\.local\share\claude, et tes réglages et sessions dans %USERPROFILE%\.claude.

Pourquoi claude n’est pas reconnu alors que l’installation a réussi ?

Neuf fois sur dix, le dossier d’installation n’est pas dans le PATH, ou tu es resté dans le terminal depuis lequel tu as lancé l’installation, qui garde son ancien PATH. Ouvre une nouvelle fenêtre, et si ça persiste, ajoute %USERPROFILE%\.local\bin à ton PATH utilisateur.

Comment mettre à jour Claude Code ?

Les installations natives se mettent à jour seules en arrière-plan. Pour forcer, claude update. Les installations par WinGet, Homebrew ou gestionnaire de paquets Linux ne se mettent pas à jour toutes seules.