Quand vous installez un agent de code sous Windows, la première décision est la suivante : WSL ou Windows natif ? Il y a un an, la réponse était presque toujours WSL, car la plupart des agents fonctionnaient mal sous Windows. Aujourd’hui, Claude Code, Codex, Gemini CLI et Copilot CLI tournent nativement dans PowerShell ; la réponse dépend désormais du projet.
La réponse courte
| Situation | Recommandation |
|---|---|
| .NET, C#, Unity, application de bureau Windows | Windows natif |
Code sur le lecteur C:, éditeur sous Windows | Windows natif |
| Outils propres à Linux, scripts shell, Makefiles | WSL 2 |
| Développement centré sur Docker | WSL 2 |
| Vous voulez le bac à sable (sandbox) de Claude Code | WSL 2 |
| Vous allez utiliser un outil qui repose sur tmux | WSL 2 |
| Machine d’entreprise où WSL est interdit | Windows natif |
Les atouts de Windows natif
Installation rapide. Claude Code s’installe avec un script PowerShell d’une ligne, Codex et Gemini CLI avec npm. Toutes les commandes sont dans installer des agents de code sous Windows.
Accès aux fichiers rapide. Le code est sur le lecteur C:, l’agent tourne sous Windows ; aucune passerelle entre systèmes de fichiers ne vient s’intercaler.
La chaîne d’outils Windows. dotnet, MSBuild, les compilateurs de Visual Studio et les SDK propres à Windows sont directement accessibles. Les appeler depuis WSL est possible, mais laborieux.
Le bac à sable Windows de Codex. Codex tourne sous Windows natif avec son propre bac à sable.
Les limites de Windows natif
Pas de bac à sable pour Claude Code. L’isolation du système de fichiers et du réseau de Claude Code n’est pas prise en charge sous Windows natif ; elle l’est dans WSL 2. À la place, vous travaillez avec des règles d’autorisation.
Pas de tmux. tmux n’a pas de version Windows native. Les outils qui en dépendent (comme Claude Squad) ne fonctionnent pas sous Windows natif.
Différences de shell. La plupart des agents ont l’habitude de produire des commandes bash. Claude Code utilise Git Bash si Git for Windows est installé, sinon PowerShell ; les autres agents peuvent utiliser PowerShell ou cmd.exe. Les réflexes bash comme rm -rf, export ou && se comportent différemment dans PowerShell.
Chemins et fins de ligne. Les chemins avec barres obliques inverses, la limite de 260 caractères et les fins de ligne CRLF déroutent parfois les outils d’édition. Les réglages ci-dessous règlent l’essentiel.
Les atouts de WSL 2
Linux, tout simplement. Les commandes bash produites par les agents s’exécutent telles quelles ; make, grep, sed et les paquets Linux sont disponibles.
Le bac à sable de Claude Code. Dans WSL 2, l’isolation de Claude Code fonctionne ; vous pouvez le faire tourner de façon plus sûre avec moins d’approbations.
tmux et les outils de terminal. tmux, Claude Squad et les outils similaires fonctionnent tels quels dans WSL.
Les limites de WSL 2
/mnt/c est lent. Depuis WSL 2, l’accès aux fichiers Windows est nettement plus lent que l’accès aux fichiers du système Linux. La documentation de Microsoft recommande elle aussi de garder les projets côté Linux. Clonez le dépôt sous ~/ et ouvrez-le depuis votre éditeur Windows via le chemin \\wsl$\.
Deux environnements distincts. Node, Python, les identifiants git et les connexions des agents sont séparés des deux côtés. Vous devrez peut-être connecter un agent une fois dans WSL et une fois sous Windows.
La mémoire. La machine virtuelle de WSL 2 consomme de la mémoire ; quand plusieurs agents et une pile Docker tournent en même temps, il peut être nécessaire de fixer une limite avec .wslconfig.
Mélanger les deux : le même dépôt des deux côtés
L’erreur la plus courante consiste à garder le dépôt sous Windows et à lancer un agent depuis WSL et un autre depuis Windows. Résultat : l’un écrit les fichiers en LF, l’autre en CRLF ; les diffs deviennent bruyants, certains outils d’édition répondent « texte introuvable » et les permissions des fichiers semblent avoir changé.
Si vous comptez utiliser les deux environnements :
- Gardez chaque dépôt d’un seul côté et lancez les agents de ce dépôt depuis ce même côté.
- Ajoutez un
.gitattributesau dépôt :
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.ps1 text eol=crlf- Côté Windows, définissez
git config --global core.autocrlf falseetgit config --global core.longpaths true; laissez.gitattributesgérer les fins de ligne.
Agents parallèles : possibles des deux côtés
Pour faire tourner plusieurs agents en même temps, vous utilisez des git worktrees séparés, d’un côté comme de l’autre.
- Dans WSL, il y a tmux et les outils construits dessus, comme Claude Squad.
- Sous Windows natif, les volets de Windows Terminal ou une application de bureau qui affiche les agents dans une grille. AgentVera tourne nativement sous Windows ; il ouvre 18 agents côte à côte par projet et rassemble les demandes d’approbation dans une seule file. Il ne gère pas directement les agents installés dans WSL ; vous pouvez les ouvrir dans un agent Terminal avec une commande comme
wsl claude.
Pour le détail, lisez le guide gérer des agents de code sous Windows, et pour le résumé complet, la page Windows.
Pour conclure
Si vous démarrez un nouveau projet qui ne dépend pas de Windows, WSL 2 reste l’option qui réserve le moins de surprises. Si votre code est déjà sous Windows, si votre éditeur y tourne ou si le projet repose sur la chaîne d’outils Windows, Windows natif suffit désormais largement ; plus aucune raison de déplacer les agents vers WSL. Quel que soit votre choix, gardez chaque dépôt d’un seul côté.