Écrire un script PowerShell d'administration propre et fiable

Un script PowerShell n'est qu'un fichier .ps1, mais quatre choix en font un outil qu'un collègue peut relancer sans vous : la stratégie d'exécution, les paramètres, l'aide intégrée et la gestion des erreurs.

Par la rédaction de Pixelabs · 12 octobre 2026

Un script PowerShell est un fichier texte d'extension .ps1 qui enchaîne des commandes. Le premier script naît souvent d'une commande tapée trois fois dans la semaine. Le problème arrive ensuite : valeurs codées en dur, erreurs silencieuses, aucune explication pour la personne qui le reprendra. Cette page pose les bases d'un script d'administration que l'on peut partager et planifier.

Windows PowerShell 5.1 ou PowerShell 7 ?

Deux moteurs cohabitent sur un Windows récent. Microsoft précise que PowerShell 7 ne remplace pas Windows PowerShell 5.1 : il s'installe dans un autre répertoire et fonctionne côte à côte. Le premier se lance avec powershell.exe, le second avec pwsh.

Sur un poste client, Microsoft recommande winget pour installer PowerShell 7. La documentation précise que winget n'existe pas sur Windows Server 2022 ou antérieur, et que Windows Server 2025 ne l'inclut qu'avec l'Expérience de bureau ; sur un serveur, le paquet MSI reste le choix conseillé pour un déploiement.

winget install --id Microsoft.PowerShell --source winget

Les commandes du gestionnaire de paquets sont détaillées dans la page sur winget sous Windows. Pour un script destiné à tourner partout, visez ce qui existe des deux côtés, ou déclarez la version requise (voir plus bas).

Lancer un script : la stratégie d'exécution

Testez vos scripts sur une machine de lab avant de les lancer sur un serveur de production, et gardez une sauvegarde de ce qu'ils modifient.

La stratégie d'exécution (execution policy) décide si PowerShell charge des scripts. Microsoft insiste sur un point souvent mal compris : ce n'est pas une barrière de sécurité, c'est une défense en profondeur, que l'on contourne facilement en collant le contenu du script dans la console.

Sur Windows Server, la stratégie effective par défaut est RemoteSigned. Un script téléchargé et non signé ne s'exécute alors qu'une fois débloqué, par exemple avec Unblock-File. Pour vérifier et régler la stratégie de l'utilisateur courant :

Get-ExecutionPolicy -List
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

L'étendue Process ne vaut que pour la session ouverte ; MachinePolicy et UserPolicy viennent de la stratégie de groupe et priment sur tout le reste.

Pour lancer un script du répertoire courant, PowerShell exige le préfixe .\ :

.\Test-Serveurs.ps1 -Port 443

Les paramètres plutôt que les valeurs en dur

Un script réutilisable reçoit ses données en paramètres. Le bloc param doit être la première instruction du script, seuls les commentaires et les lignes #Requires pouvant le précéder. Les paramètres d'un script se comportent exactement comme ceux d'une fonction.

#Requires -Version 5.1
param(
    [Parameter(Mandatory)]
    [string[]] $ComputerName,

    [int] $Port = 443
)

#Requires -Version refuse de lancer le script sur un moteur trop ancien, avec un message clair au lieu d'une erreur obscure à la ligne quarante.

L'aide intégrée : le script s'explique lui-même

PowerShell lit un bloc de commentaires structuré et le transforme en aide, consultable avec Get-Help comme pour une cmdlet. Les mots clés les plus utiles :

• .SYNOPSIS : une phrase sur ce que fait le script ;
• .DESCRIPTION : le détail ;
• .PARAMETER : un par paramètre, suivi de son nom ;
• .EXAMPLE : un ou plusieurs exemples d'appel.

<#
.SYNOPSIS
Teste un port TCP sur une liste de serveurs.
.PARAMETER ComputerName
Noms ou adresses des serveurs à tester.
.PARAMETER Port
Port TCP à tester (443 par défaut).
.EXAMPLE
.\Test-Serveurs.ps1 -ComputerName srv-web01, srv-sql01 -Port 1433
#>

Ce bloc se place en tête du fichier. Ensuite, Get-Help -Name .\Test-Serveurs.ps1 -Full affiche l'aide complète.

Gérer les erreurs pour de vrai

C'est là que la plupart des scripts échouent sans le dire. PowerShell distingue deux familles d'erreurs :

• les erreurs sans fin (non-terminating) signalent un problème mais laissent la commande continuer ;
• les erreurs de fin arrêtent l'instruction, voire le script entier.

Un bloc try/catch n'intercepte que les erreurs de fin. Microsoft documente le moyen de promouvoir une erreur sans fin : -ErrorAction Stop sur la commande, ou $ErrorActionPreference = 'Stop' pour toute la portée. Le bloc finally s'exécute dans tous les cas, même après Ctrl+C : c'est l'endroit pour fermer une session ou un fichier.

foreach ($c in $ComputerName) {
    try {
        if (Test-NetConnection -ComputerName $c -Port $Port -InformationLevel Quiet -ErrorAction Stop) {
            "$c : port $Port joignable"
        } else {
            "$c : port $Port injoignable"
        }
    }
    catch {
        "$c : échec du test ($($_.Exception.Message))"
    }
}

Le test de port utilisé ici est expliqué en détail dans la page sur Test-NetConnection pour tester un port.

Exécuter à distance

Pour lancer un script sur plusieurs serveurs, Microsoft documente Invoke-Command avec le paramètre FilePath : le fichier reste sur votre poste, et c'est son contenu qui part vers les machines distantes.

Invoke-Command -ComputerName srv-web01, srv-sql01 -FilePath C:\Scripts\Test-Serveurs.ps1

Cela suppose la gestion à distance PowerShell (WinRM) active sur les cibles.

Des idées de scripts d'administration

Quelques tâches qui se prêtent bien à un premier script, et la page qui détaille la commande de base :

Le reste des tutoriels se trouve dans la rubrique Windows Server et PowerShell.

Questions fréquentes