Shells sous Windows : CMD, PowerShell, Windows Terminal et WSL

Sous Windows, le mot shell peut désigner plusieurs choses très différentes : l’ancien environnement DOS, l’invite de commandes cmd.exe, PowerShell, le shell graphique de Windows ou encore Bash exécuté grâce à WSL.

Pour comprendre l’écosystème actuel, il faut surtout distinguer trois concepts : le shell, qui interprète les commandes ; le terminal, qui fournit l’interface dans laquelle le shell s’affiche ; et la console, qui désigne historiquement une partie de l’infrastructure permettant les interactions en mode texte.

Windows Terminal, CMD et PowerShell ne sont donc pas trois versions successives du même logiciel : Windows Terminal affiche des shells, tandis que CMD et PowerShell sont eux-mêmes des interpréteurs de commandes.

De MS-DOS à CMD : même air de famille, autre système

MS-DOS utilisait principalement COMMAND.COM comme interpréteur de commandes. On y exécutait déjà des commandes devenues familières :

DIR
CD
COPY
DEL
TYPE

Les scripts batch utilisaient les extensions .BAT et permettaient déjà d’automatiser certaines opérations. L’environnement était rudimentaire comparé aux shells modernes, mais il ne faut pas le confondre avec l’actuel Windows.

Les versions modernes de Windows appartiennent à la famille Windows NT. Leur interpréteur historique en ligne de commande est :

cmd.exe

CMD a volontairement conservé énormément de syntaxe et de commandes familières aux utilisateurs DOS. D’où l’impression qu’il s’agit simplement de « DOS dans une fenêtre ». Techniquement, ce n’est pourtant pas MS-DOS qui tourne sous Windows 11.

CMD sait faire plus que lancer ping

L’invite de commandes possède notamment :

• des variables d’environnement avec SET ;
• des conditions avec IF ;
• des boucles avec FOR ;
• des sous-programmes avec CALL ;
• des branchements avec GOTO ;
• des redirections avec > et >> ;
• des pipelines avec | ;
• une gestion de codes de retour via ERRORLEVEL.

Par exemple :

@echo off

if exist rapport.txt (
    echo Le fichier existe
) else (
    echo Fichier absent
)

for %%F in (*.log) do (
    echo %%F
)

CMD possède donc bel et bien des structures de contrôle. Le problème est plutôt leur syntaxe parfois déroutante et l’accumulation de particularités historiques.

L’expansion des variables dans les blocs en est un bon exemple. Pour certains scripts, il faut activer l’expansion différée :

setlocal EnableDelayedExpansion

À partir d’un certain niveau de complexité, l’administrateur découvre que le script batch fonctionne parfaitement, à condition de ne plus jamais le regarder directement dans les yeux.

Le shell graphique et Windows Terminal : deux notions différentes

Windows possède également un shell graphique. L’Explorateur Windows, la barre des tâches, le bureau et différentes composantes de l’interface constituent l’environnement interactif utilisé quotidiennement par la majorité des utilisateurs.

Le shell graphique est excellent pour des tâches ponctuelles : parcourir des fichiers, ouvrir une application, modifier quelques paramètres. Il devient moins efficace lorsqu’il faut répéter exactement la même opération sur 500 machines ou traiter 30 000 fichiers selon des critères précis.

Windows Terminal

Windows Terminal répond à un autre besoin. C’est une application terminal moderne capable d’héberger plusieurs environnements :

PowerShell
Windows PowerShell
Command Prompt
WSL
Azure Cloud Shell
SSH
autres profils personnalisés

Il apporte notamment :

• onglets ;
• volets ;
• profils multiples ;
• personnalisation de l’affichage ;
• raccourcis configurables ;
• rendu moderne du texte et des caractères Unicode.

Ouvrir CMD dans Windows Terminal ne transforme donc pas CMD en PowerShell. Cela revient simplement à afficher le même shell dans une meilleure fenêtre.

De la même manière, ouvrir Debian WSL dans Windows Terminal ne transforme pas Bash en application Windows native. Terminal s’occupe de l’interface ; le shell reste celui de l’environnement sélectionné.

PowerShell : un shell conçu pour l’administration

Microsoft a lancé PowerShell en 2006 avec une idée très différente de celle des shells traditionnels : au lieu de faire circuler uniquement du texte entre les commandes, les cmdlets PowerShell peuvent transmettre des objets structurés.

La différence apparaît très vite.

Avec PowerShell :

Get-Process

ne renvoie pas seulement un joli tableau destiné à l’écran. Il produit des objets représentant réellement les processus, avec des propriétés et méthodes exploitables.

On peut donc écrire :

Get-Process |
    Where-Object CPU -gt 10 |
    Sort-Object CPU -Descending |
    Select-Object Name, CPU, Id

Le pipeline transporte ici des objets processus. Chaque commande peut travailler directement sur leurs propriétés au lieu de devoir découper des colonnes de texte.

Quelques exemples courants

# Lister les services actifs
Get-Service |
    Where-Object Status -eq 'Running'

# Lister les fichiers .log
Get-ChildItem C:\Logs -Filter *.log

# Rechercher une chaîne
Select-String -Path C:\Logs\*.log -Pattern 'erreur'

# Afficher quelques propriétés système
Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, CsTotalPhysicalMemory

PowerShell possède également des fonctions, modules, classes, exceptions, commandes de gestion à distance et un système d’aide intégré.

Pour obtenir l’aide d’une commande :

Get-Help Get-Process

Pour rechercher les commandes liées à un sujet :

Get-Command *service*

Pour inspecter les propriétés d’un objet :

Get-Process | Get-Member

Windows PowerShell 5.1 et PowerShell 7.x

Deux environnements doivent aujourd’hui être distingués.

	Windows PowerShell 5.1	PowerShell 7.x
Exécutable	powershell.exe	pwsh.exe
Plateforme	Windows	Windows, Linux, macOS
Base .NET	.NET Framework	.NET moderne
Positionnement	Compatibilité historique Windows	Développement actuel de PowerShell

En 2026, PowerShell 7.6 LTS constitue une branche moderne supportée à long terme. Windows PowerShell 5.1 reste néanmoins important parce que certains modules et produits Windows historiques en dépendent encore.

Il est donc parfaitement normal de posséder les deux sur la même machine.

Le pipeline PowerShell n’est pas toujours composé d’objets

Dire « PowerShell transmet des objets, contrairement à CMD » est globalement juste lorsque l’on parle de ses cmdlets. Il faut toutefois ajouter une nuance : PowerShell sait également lancer des programmes natifs classiques.

Par exemple :

ping.exe 1.1.1.1
git.exe status
ipconfig.exe

Ces programmes ne deviennent pas magiquement des cmdlets .NET. Leur sortie reste généralement textuelle.

En revanche :

Get-Process |
    Sort-Object CPU

travaille réellement sur les objets retournés par Get-Process.

C’est précisément cette coexistence qui rend PowerShell pratique : il peut utiliser l’écosystème Windows existant tout en proposant un modèle beaucoup plus structuré pour ses propres commandes.

WSL : quand Bash s’installe réellement sous Windows

Windows Subsystem for Linux, ou WSL, permet d’installer et d’utiliser un environnement Linux directement sur une machine Windows.

Selon la distribution installée, on peut alors disposer de :

bash
grep
sed
awk
ssh
find
apt
python
gcc

et de nombreux autres programmes Linux habituels.

L’installation de WSL peut aujourd’hui commencer très simplement depuis un terminal administrateur :

wsl --install

Pour voir les distributions installées :

wsl --list --verbose

On peut également installer une distribution particulière parmi celles disponibles :

wsl --list --online
wsl --install -d Debian

Une fois dans Debian WSL, on se retrouve avec un véritable environnement utilisateur Linux :

uname -a
ls -la
grep -R "erreur" /var/log
sudo apt update

WSL permet également une interopérabilité intéressante. Depuis Linux, les disques Windows sont accessibles par exemple sous :

/mnt/c/

et l’on peut lancer certaines applications Windows depuis le shell Linux.

PowerShell ou WSL ?

Les deux ne remplissent pas exactement le même rôle. Pour administrer Windows, Active Directory, Hyper-V, Microsoft 365 ou les API de nombreux produits Microsoft, PowerShell est généralement le choix naturel.

Pour reproduire un environnement Linux, utiliser les outils GNU, développer pour un serveur Linux ou travailler avec des scripts Bash, WSL est souvent beaucoup plus adapté.

Il n’existe aucune obligation morale de choisir un camp. Un administrateur peut parfaitement utiliser PowerShell à 10 h, Bash à 10 h 05 et CMD à 10 h 07 parce qu’un vieux script de 2004 refuse obstinément d’évoluer.

CMD, PowerShell, Terminal ou WSL : lequel choisir ?

Outil	Nature	À privilégier pour
CMD	Shell Windows historique	Commandes classiques, vieux scripts batch, dépannage rapide
Windows PowerShell 5.1	Shell et langage .NET Framework	Modules Windows historiques et compatibilité
PowerShell 7.x	Shell et langage moderne multiplateforme	Automatisation, administration, scripting moderne
Windows Terminal	Émulateur / application terminal	Héberger CMD, PowerShell, WSL et autres profils
WSL	Environnement Linux sous Windows	Bash, outils GNU/Linux, développement Linux
Explorateur Windows	Shell graphique	Interaction graphique quotidienne

CMD n’a donc pas besoin d’être « mis à la retraite ». Il reste présent dans Windows 11 et Windows Server actuels, de nombreuses commandes historiques sont encore supportées et d’innombrables scripts batch continuent de fonctionner.

Pour un nouveau projet d’automatisation conséquent, PowerShell sera néanmoins généralement beaucoup plus agréable et maintenable.

Une commande batch simple reste parfaitement raisonnable :

ipconfig /all

Un système d’automatisation contenant 1 800 lignes de batch, quinze GOTO et une variable nommée FINAL_FINAL2 constitue en revanche un appel discret à envisager PowerShell.

Conclusion : Windows possède désormais plusieurs mondes en ligne de commande

L’histoire des shells Windows n’est pas simplement :

DOS → CMD → PowerShell

La réalité actuelle ressemble davantage à :

CMD + PowerShell + Windows Terminal + WSL + shell graphique

Chaque composant joue un rôle différent. CMD assure une compatibilité remarquable avec plusieurs décennies d’administration Windows. PowerShell apporte un langage d’automatisation moderne et un pipeline orienté objets. WSL offre directement les outils et shells de l’écosystème Linux. Windows Terminal rassemble tout cela dans une interface commune.

La règle pratique est donc simple : utilisez CMD quand une commande classique suffit, PowerShell pour administrer et automatiser Windows, WSL lorsque vous avez besoin d’un environnement Linux, et Windows Terminal pour éviter d’ouvrir quatre fenêtres différentes comme en 2003.

Le vieux prompt C:\> n’est donc pas mort.

Il partage simplement désormais son bureau avec beaucoup plus de colocataires.