PowerShell scripting : par où commencer

PowerShell n'est pas un `cmd.exe` amélioré. C'est une autre bête.

Là où les shells Unix et `cmd.exe` font circuler du texte d'un programme à l'autre, PowerShell fait circuler des objets .NET. Quand tu demandes la liste des services, tu ne reçois pas une colonne de caractères alignés à la va-vite. Tu reçois des objets `ServiceController` avec des propriétés nommées — `Name`, `Status`, `DisplayName` — et des méthodes que tu peux appeler. Tu filtres sur une propriété, pas sur une position de colonne. Ça change tout le reste.

Ce basculement texte-vers-objets a un coût. Il faut apprendre à penser en termes de propriétés, pas en lignes. Une fois ce réflexe pris, tu ne reviens plus en arrière. Avant, tu regardes `Get-Help` comme un dictionnaire pendant deux semaines.

Les cmdlets, et pourquoi leur nom est presque toujours suffisant

Une cmdlet, c'est une commande minuscule qui fait une seule chose. La convention de nommage est `Verbe-Nom` : `Get-Process`, `Stop-Service`, `New-Item`, `Set-ExecutionPolicy`. Le verbe te dit ce que la commande fait à la ressource ; le nom te dit sur quoi elle agit.

Cette convention n'est pas cosmétique. Elle permet de deviner une commande que tu ne connais pas. Tu veux supprimer un fichier ? `Remove-Item`. Tu veux copier une entrée de registre ? `Copy-Item`. Tu veux lister les modules installés ? `Get-Module`. Tu te trompes parfois, mais rarement deux fois.

`Get-Help` est la seule cmdlet que tu dois vraiment maîtriser avant les autres. `Get-Help Get-Process -Examples` te sort des cas concrets. `Get-Help Get-Process -Full` te sort la signature complète, les types d'entrée, les types de sortie. Tu n'as pas besoin d'un livre pour apprendre PowerShell ; tu as besoin de `Get-Help` et de la patience de le lire.

La pipeline, c'est là que tout se joue

Le symbole `|` relie deux cmdlets. La sortie de la première devient l'entrée de la seconde. Jusque-là, rien de neuf.

La différence, c'est ce qui circule dans le tube. Pas du texte : des objets. Donc quand tu écris `Get-Service | Where-Object { $_.Status -eq 'Running' }`, tu ne filtres pas des lignes qui contiennent le mot « Running ». Tu filtres des objets dont la propriété `Status` vaut exactement `Running`. La nuance paraît théorique jusqu'au jour où un service s'appelle `RunningLate` et que ton filtre texte le laisse passer.

Tu peux enchaîner : `Get-Service | Where-Object { $_.Status -eq 'Running' } | Sort-Object DisplayName | Select-Object -First 10`. Chaque maillon fait une chose. La ligne reste lisible. C'est un des rares endroits en informatique où la lisibilité ne se paie pas en performance.

Un script, c'est un fichier `.ps1` et rien de plus

Un script PowerShell est un fichier texte avec l'extension `.ps1`. Il contient une suite de commandes, exécutées dans l'ordre. Tu y mets des variables (`$nom = "valeur"`), des conditions (`if`, `else`, `switch`), des boucles (`foreach`, `while`, `for`) et des fonctions.

Rien de tout ça n'est exotique. Si tu as déjà écrit du Python ou du Bash, tu reconnaîtras la syntaxe en une heure. La différence tient à ce que tu manipules : des objets .NET, avec leurs propriétés et leurs méthodes. Un `Get-ChildItem` ne te renvoie pas des noms de fichiers, mais des objets `FileInfo` sur lesquels tu peux lire `.Length`, `.LastWriteTime`, `.Extension`.

Un script utile fait rarement plus de trente lignes. Au-delà, tu devrais le découper en fonctions.

L'execution policy, ou la première chose qui va te bloquer

Par défaut, PowerShell refuse d'exécuter un script. Pas par bug : par choix de conception. La politique d'exécution (`execution policy`) est réglée sur `Restricted` sur la plupart des installations Windows fraîches. Tu tapes `.\monscript.ps1`, et tu obtiens une erreur rouge qui ne dit pas grand-chose.

Tu changes le réglage avec `Set-ExecutionPolicy RemoteSigned -Scope CurrentUser`. `RemoteSigned` autorise les scripts locaux et exige une signature pour ceux téléchargés depuis Internet. C'est un compromis raisonnable. `Unrestricted` enlève toute barrière, ce qui revient à dire que tu fais confiance à tout ce que tu exécutes. Réfléchis avant de choisir.

Le `-Scope CurrentUser` t'évite de modifier la politique pour toute la machine. Sur un serveur partagé, c'est la différence entre ta session et une plainte de ton responsable sécurité.

Remoting : la vraie raison pour laquelle PowerShell existe en entreprise

`Enter-PSSession` ouvre une session interactive sur une machine distante. `Invoke-Command` exécute un bloc de code sur une ou plusieurs machines et te renvoie les résultats. Les deux reposent sur la norme WS-Management, et exigent que le service WinRM soit actif des deux côtés.

C'est là que PowerShell cesse d'être un outil pour utilisateur isolé et devient un outil d'administration de parc. Tu lances une commande sur trente serveurs, tu récupères trente objets, tu les tries. En Bash, tu ferais une boucle `ssh` et tu prierais pour que la sortie reste parsable. Ici, la sortie est déjà structurée.

Le prix, c'est la configuration. WinRM, les certificats, les pare-feu, les droits. Sur un domaine Active Directory bien tenu, tout est déjà en place. Sur un réseau hétérogène, tu vas y passer une après-midi.

Versions : ce qui est supporté, et jusqu'à quand

PowerShell a longtemps été un composant Windows uniquement. Depuis PowerShell Core, puis PowerShell 7, il tourne aussi sur Linux et macOS, et il est open source. Si tu administres un mélange de Windows et de Linux, c'est la version que tu veux.

Les dates de support actuelles, telles que publiées par Microsoft :

• PowerShell 7.4 (LTS) — sorti le 16 novembre 2023, supporté jusqu'au 10 novembre 2026.
• PowerShell 7.5 — sorti le 23 janvier 2025, supporté jusqu'au 10 novembre 2026.
• PowerShell 7.6 (LTS) — sorti le 18 mars 2026, supporté jusqu'au 14 novembre 2028.

Si tu écris des scripts destinés à durer, vise une LTS. Les versions intermédiaires apportent des fonctionnalités, mais tu les réinstalles plus souvent. Sur un poste de travail, peu importe. Sur un parc de serveurs, la LTS est le seul choix raisonnable.

Les modules : là où PowerShell devient une plateforme

Une cmdlet seule ne fait pas grand-chose. Un module regroupe des cmdlets, des fonctions, des variables et de l'aide autour d'un même sujet. `Az` pour Azure, `AWS.Tools` pour Amazon, `VMware.PowerCLI` pour VMware, `ActiveDirectory` pour les contrôleurs de domaine. Il en existe des centaines.

Tu les installes via la PowerShell Gallery, avec `Install-Module -Name Az -Scope CurrentUser`. La Gallery est le dépôt central. Elle contient aussi bien des modules signés par Microsoft que des modules communautaires de qualité variable. `Install-Module` ne te protège pas de toi-même.

Un mot sur les modules communautaires : ils rendent parfois des services que rien d'autre ne rend. Ils introduisent aussi une dépendance que personne ne maintiendra quand l'auteur initial aura changé de travail. Pèse ça avant de baser ta production dessus.

Ce que tu apprends en premier, et ce que tu apprends après

Trois choses à maîtriser avant tout le reste : `Get-Help`, la pipeline, et l'écriture d'un script `.ps1` de dix lignes qui tourne. C'est tout. Le reste vient par accumulation.

Ne commence pas par les modules Azure. Ne commence pas par le remoting. Ne commence pas par les classes PowerShell, qui sont un sujet à part et rarement nécessaires. Commence par un script qui liste les fichiers de plus de 100 Mo dans `C:\Temp` et te les affiche triés par taille. C'est trivial. C'est aussi exactement ce que tu feras dans ton premier vrai besoin, un lundi matin, quand quelqu'un te demandera pourquoi le disque est plein.

Ce que PowerShell n'est pas

PowerShell n'est pas Bash. La syntaxe est différente, la philosophie aussi. Un script Bash traduit ligne par ligne en PowerShell donne quelque chose de laid et de fragile.

PowerShell n'est pas un langage de programmation généraliste. Tu peux écrire des applications avec, mais personne ne le fait. Ce n'est pas fait pour ça.

PowerShell n'est pas non plus la réponse à tout. Pour un script de dix lignes qui déplace des fichiers sur un serveur Linux, Bash reste plus court et plus lisible. Pour parser du JSON en ligne de commande, `jq` reste imbattable. PowerShell brille quand tu administres un parc hétérogène, quand tu manipules des objets structurés, ou quand tu dois intéragir avec des API Microsoft. En dehors de ces cas, il est parfois le mauvais outil — et c'est très bien de le reconnaître.

La vraie question n'est pas « PowerShell ou Bash ». Elle est : est-ce que ce que je manipule est un objet ou du texte ? Si c'est du texte, reste sur ton shell habituel. Si c'est un objet — un service, un utilisateur Active Directory, une ressource Azure, une entrée de registre — PowerShell te fera gagner du temps que tu ne récupéreras pas autrement.

Le reste dépend de ce que tu administres.