Pour maîtriser les conditions PowerShell, retenons une règle simple : if teste une situation, elseif examine d’autres possibilités et else traite le cas restant. En plaçant une expression entre parenthèses et les actions associées entre accolades, nous construisons des scripts capables de réagir à l’état réel d’un ordinateur, d’un service ou d’un fichier.
Cette logique intervient aussi bien dans une vérification de sauvegarde que dans la surveillance d’un serveur. Nous allons suivre le fil d’une petite équipe informatique chargée de contrôler des postes et des disques : ses exemples montrent comment choisir les opérateurs de comparaison, éviter les erreurs courantes et rendre les décisions compréhensibles pour la personne qui exécutera le script.
- Écrire une syntaxe conditionnelle lisible avec if, elseif et else.
- Combiner des tests numériques, textuels et logiques de façon cohérente.
- Vérifier chemins, données et codes de sortie avant d’automatiser une action.
Écrire une condition PowerShell lisible
Une instruction if permet d’exécuter un bloc de code uniquement lorsque son test produit un résultat vrai. Sa forme de base est if ($condition) { commandes } : les parenthèses encadrent le test et les accolades délimitent les actions. PowerShell n’emploie ni then ni fi, contrairement à certaines syntaxes de shell.
Prenons une valeur d’espace libre exprimée en gigaoctets. Avec $espaceLibre = 15, l’instruction if ($espaceLibre -lt 20) { Write-Warning "Espace disque faible" } affiche un avertissement, car 15 est inférieur à 20. Si la valeur passe à 28, le test devient faux et le bloc ne s’exécute pas.
Repérer les blocs d’action
Les accolades rendent les limites des actions explicites, même lorsqu’un bloc ne contient qu’une seule commande. Nous gagnons à placer chaque action sur sa propre ligne et à indenter les commandes appartenant au test. Cette présentation aide à repérer rapidement une accolade manquante ou une commande placée au mauvais niveau.
Imaginons que l’équipe informatique vérifie un fichier de sauvegarde avant de lancer un transfert. Elle peut écrire if (Test-Path -Path "C:Sauvegardesserveur.zip") { Write-Output "Archive disponible" }. La commande Test-Path renvoie une valeur logique : le bloc s’exécute si le chemin existe, sans qu’il soit nécessaire de stocker le résultat dans une variable intermédiaire.
Des noms descriptifs comme $archiveExiste, $serviceActif ou $espaceLibre facilitent aussi la lecture. Une variable appelée $x peut sembler acceptable dans un essai de quelques lignes, mais elle rend un script d’administration difficile à relire après plusieurs semaines. La clarté du nom évite de devoir reconstituer le sens de chaque test à partir du contexte.
Comprendre le résultat vrai
La condition peut être une comparaison, une variable booléenne ou le résultat d’une commande. Si une étape précédente a déterminé que la sauvegarde est prête, nous pouvons tester directement if ($sauvegardeTerminee) { ... }. Avec $true, le bloc s’exécute ; avec $false, il est ignoré.
PowerShell considère aussi comme fausses certaines valeurs vides ou nulles, notamment $null, $false, le nombre zéro, une chaîne vide et un tableau vide. Cette conversion implicite peut rendre un test concis, mais elle mérite d’être utilisée avec discernement : if ($nombre) ne distingue pas forcément « valeur absente » de « valeur égale à zéro ».
Pour une règle métier, un test explicite communique mieux l’intention. if ($nombre -eq 0) indique clairement que nous cherchons zéro, tandis que if ($null -eq $chemin) vérifie l’absence de valeur. Cette dernière écriture place volontairement $null à gauche : avec une collection, le placer à droite de -eq peut déclencher une comparaison élément par élément et produire un résultat différent d’un test global.
Une fois le premier test maîtrisé, nous pouvons décrire plusieurs situations sans transformer le script en succession de commandes rigides. C’est le rôle de elseif et de else, qui organisent les branches de la décision.
Enchaîner if elseif et else
Une chaîne if / elseif / else permet de choisir une seule action parmi plusieurs scénarios. PowerShell évalue les tests dans leur ordre d’apparition : dès qu’un test est vrai, le bloc correspondant est exécuté et les branches suivantes sont ignorées. L’ordre des conditions fait donc partie de la logique, et non d’un simple choix de mise en page.
Pour surveiller un volume, l’équipe peut définir trois niveaux : moins de 20 % d’espace libre signale une alerte, moins de 40 % indique une situation à suivre et toute valeur supérieure ou égale à 40 % correspond à un état normal. Le script commence par le seuil le plus sévère, puis examine le niveau intermédiaire, avant de traiter le reste avec else.
Classer les seuils correctement
Voici une décision graduée : if ($pourcentLibre -lt 20) { Write-Warning "Alerte : espace critique" } elseif ($pourcentLibre -lt 40) { Write-Output "Espace à surveiller" } else { Write-Output "Espace confortable" }. Avec 15 %, le premier bloc s’applique ; avec 32 %, le second ; avec 65 %, le dernier.
Si nous inversions les deux tests, la condition -lt 40 accepterait déjà une valeur de 15 et la branche d’alerte ne serait jamais atteinte. Il faut donc examiner d’abord les cas les plus spécifiques ou les plus urgents. Pour éviter les erreurs de bord, testons aussi les valeurs exactement égales aux seuils : à 20 %, l’opérateur -lt ne déclenche pas l’alerte, alors que -le la déclencherait.
Le bloc else ne possède pas de test, car il représente tous les cas qui n’ont satisfait aucune condition précédente. Il est facultatif : une instruction composée seulement de if et d’un ou plusieurs elseif reste valide. Dans un script d’exploitation, une branche par défaut peut néanmoins donner un retour utile et rendre la décision plus facile à diagnostiquer.
Traiter les erreurs en premier
Une pratique efficace consiste à vérifier les prérequis au début du script et à quitter immédiatement si l’un d’eux manque. Supposons qu’un rapport doive être enregistré dans C:Rapports. Si le dossier de destination n’existe pas et que le script ne sait pas le créer, nous pouvons afficher un message précis puis arrêter le traitement, au lieu d’imbriquer toutes les opérations dans un grand bloc conditionnel.
Ce principe de sortie anticipée garde le chemin normal du script au premier plan. Par exemple, une vérification du chemin, un message d’erreur et exit 1 peuvent précéder les commandes de génération du rapport. Le lecteur comprend alors rapidement que le traitement ne continue que lorsque ses conditions de départ sont réunies.
Dans un autre scénario, la création du dossier est préférable à l’arrêt. Nous pouvons tester son existence avec Test-Path -Path $dossier -PathType Container, puis exécuter New-Item -ItemType Directory -Path $dossier | Out-Null si le résultat est faux. Le script devient rejouable : une première exécution crée le dossier, et les suivantes le réutilisent sans afficher un objet inutile.
Cette décision dépend du besoin. Refuser un chemin invalide protège un processus qui exige une destination choisie par l’administrateur ; créer un dossier attendu simplifie une tâche automatisée. Dans les deux cas, nous formulons d’abord la règle, puis nous choisissons la branche qui l’exprime le plus directement.
Pour les situations qui ne se résument pas à des seuils, les opérateurs permettent de combiner plusieurs critères au sein d’un même test. Il devient alors possible d’exprimer une règle plus précise qu’une simple comparaison isolée.
Choisir les opérateurs de comparaison
Les opérateurs de comparaison indiquent à PowerShell comment confronter deux valeurs. Les principaux sont -eq pour l’égalité, -ne pour l’inégalité, -lt pour « inférieur à », -le pour « inférieur ou égal à », -gt pour « supérieur à » et -ge pour « supérieur ou égal à ».
| Besoin | Opérateur | Exemple |
|---|---|---|
| Égalité | -eq |
$code -eq 5 |
| Différence | -ne |
$etat -ne "Running" |
| Valeur inférieure | -lt |
$libre -lt 20 |
| Valeur supérieure ou égale | -ge |
$age -ge 18 |
Comparer nombres et chaînes
À la différence des habitudes courantes en Bash, PowerShell utilise ces opérateurs avec des nombres comme avec du texte. Nous écrivons if ($n -eq 5) et non if [ $n -eq 5 ]. Pour comparer deux chaînes, -eq reste l’opérateur d’égalité, alors que le signe = sert à affecter une valeur à une variable.
Le symbole == n’est pas l’opérateur d’égalité PowerShell. Écrire if ($a == $b) provoque une erreur de syntaxe ; la forme attendue est if ($a -eq $b). Cette différence surprend parfois les personnes qui passent d’un autre langage, d’où l’intérêt de vérifier les opérateurs lors de la relecture d’un script.
Les comparaisons de chaînes sont insensibles à la casse par défaut : "serveur" -eq "SERVEUR" est vrai. Si la casse doit compter, nous pouvons employer -ceq. Les variantes préfixées par c, comme -clike, imposent également une comparaison sensible à la casse ; les variantes en i, comme -ieq, expriment explicitement l’insensibilité.
Filtrer et reconnaître du texte
Pour rechercher un motif simple dans une chaîne, -like accepte les caractères génériques. Le test $nom -like "SRV-*" repère par exemple des noms qui commencent par SRV-, tandis que -notlike vérifie l’absence de correspondance. Cette méthode convient à des conventions de nommage, comme une série de serveurs identifiés par préfixe.
Quand le motif est plus strict, -match permet d’utiliser une expression régulière. Ainsi, $texte -match "^d+$" vérifie que le texte ne contient que des chiffres, du début à la fin. Nous pouvons nous en servir pour valider un numéro reçu sous forme de chaîne avant de le convertir en entier.
Les opérateurs -contains et -in servent à tester l’appartenance à une collection. Avec $environnements = @("web", "base", "fichiers"), l’expression $environnements -contains "web" renvoie vrai ; l’expression inverse "web" -in $environnements présente le même test dans un ordre plus naturel lorsque nous formulons la question à partir de la valeur recherchée.
Combiner plusieurs critères
Les opérateurs logiques permettent de relier des comparaisons : -and exige que les deux côtés soient vrais, tandis que -or accepte qu’au moins l’un le soit. -not inverse un résultat. Par exemple, if ($libre -lt 20 -and $Detail) affiche des informations détaillées seulement si l’espace passe sous le seuil et si l’option de détail a été activée.
Pour contrôler un service, une règle peut combiner son état et son mode de démarrage : if (($service.Status -eq "Stopped") -and ($service.StartType -eq "Automatic")) { Write-Warning "Service automatique arrêté" }. Les parenthèses autour de chaque comparaison ne sont pas toujours indispensables, mais elles rendent les critères visibles et simplifient la vérification de la logique.
Un test court n’est utile que si nous savons quelles données il compare. Pour un fichier ou un dossier, Test-Path apporte une vérification adaptée au système de fichiers, ce qui évite de construire une comparaison de chaîne à partir d’un chemin.
Vérifier fichiers et espace disque
Les conditions deviennent particulièrement utiles lorsqu’elles s’appuient sur des données réelles. Un script peut vérifier la présence d’un fichier, l’état d’un service ou la capacité disponible sur un volume avant de poursuivre. Nous allons reprendre le cas de l’équipe informatique et construire une surveillance de disque qui distingue une erreur de collecte d’une alerte de stockage.
Test-Path -Path $chemin renvoie vrai si le chemin existe. Pour préciser le type attendu, nous ajoutons -PathType Leaf pour un fichier ou -PathType Container pour un dossier. Ce détail évite de considérer comme archive valide un répertoire portant par hasard le nom d’un fichier attendu.
Contrôler un chemin attendu
Une vérification de fichier peut s’écrire ainsi : if (Test-Path -Path $archive -PathType Leaf) { Write-Output "Archive disponible" } else { Write-Warning "Archive manquante" }. Le bloc else ne se contente pas de gérer une erreur : il décrit clairement ce qui doit se passer lorsque le prérequis fait défaut.
Si le dossier de sortie peut être créé automatiquement, nous testons son existence avec Test-Path -Path $dossier -PathType Container. Lorsqu’il n’existe pas, New-Item -ItemType Directory -Path $dossier | Out-Null le crée sans afficher son objet de retour. Cette approche rend l’opération idempotente : la relancer ne change pas le résultat attendu une fois le dossier en place.
Pour examiner un service Windows, nous pouvons récupérer son objet avec Get-Service -Name "Spooler", puis comparer sa propriété Status à "Running". Il faut aussi prévoir le cas où le nom est erroné ou le service inaccessible : une comparaison ne protège pas contre l’échec d’une commande qui ne produit pas l’objet attendu. Le contrôle des erreurs de collecte vient donc avant celui de l’état du service.
Calculer un seuil fiable
Pour surveiller un volume, Get-CimInstance permet d’interroger les informations de disque. Le script suivant reçoit un lecteur et un seuil en paramètres, vérifie que le lecteur existe, calcule son pourcentage d’espace libre, puis choisit un message selon le résultat.
param([string]$Lettre = "C:", [int]$SeuilPourcent = 20) définit des valeurs par défaut que l’appelant peut remplacer. Un administrateur peut ainsi lancer le script avec un seuil adapté à un volume de données sans modifier le code source à chaque fois.
$disque = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DeviceID='$Lettre'" récupère le volume visé. La condition if ($null -eq $disque) traite d’abord le cas où aucun disque ne correspond ; le script peut alors afficher une erreur compréhensible et terminer par exit 1.
Une fois l’objet obtenu, le calcul $pourcentLibre = [math]::Round(($disque.FreeSpace / $disque.Size) * 100, 1) exprime l’espace disponible en pourcentage, arrondi à une décimale. Il faut éviter de calculer ce ratio si la taille est nulle ou si la collecte n’a pas fourni les valeurs attendues : les contrôles en amont protègent le script contre des résultats trompeurs.
Rendre l’alerte exploitable
Le seuil devient paramétrable, puis la chaîne de décision distingue trois niveaux : if ($pourcentLibre -lt $SeuilPourcent) { Write-Host "ALERTE : $Lettre n'a plus que $pourcentLibre % libre" -ForegroundColor Red; exit 1 } elseif ($pourcentLibre -lt 40) { Write-Host "Attention : $Lettre est à $pourcentLibre % libre" -ForegroundColor Yellow } else { Write-Host "$Lettre est en bonne santé ($pourcentLibre % libre)" -ForegroundColor Green }. La première branche signale un problème sous le seuil configuré ; la deuxième annonce une marge réduite ; la dernière confirme un état acceptable.
La valeur de 40 % n’est pas une vérité universelle. Un volume de sauvegarde très sollicité peut nécessiter un avertissement plus précoce, alors qu’un lecteur temporaire peut tolérer une occupation plus forte. Le seuil doit refléter le rythme de croissance des données, la fréquence des sauvegardes et le délai disponible pour intervenir.
Les tâches planifiées ne lisent pas nécessairement les messages affichés à l’écran. Un code de sortie explicite permet à un ordonnanceur ou à un outil de supervision de distinguer une exécution réussie d’une alerte ; prévoyons donc exit 0 pour un traitement normal et un code différent lorsqu’une règle impose un échec.
Une condition de surveillance utile se termine par une décision que les outils et les humains peuvent interpréter. Pour rendre ce comportement durable, il reste à choisir la bonne structure et à tester les frontières avant de déployer le script.
Fiabiliser les scripts PowerShell
Un script fiable ne dépend pas seulement de la justesse de ses conditions. Il doit rester compréhensible pour la personne qui le modifie, fonctionner sur les versions PowerShell visées et produire des résultats exploitables par les outils d’automatisation. Nous pouvons améliorer ces trois aspects en choisissant une structure adaptée, en testant les limites et en séparant les messages destinés à l’écran des valeurs destinées aux autres commandes.
Choisir elseif ou switch
La chaîne if / elseif / else est adaptée lorsque les tests portent sur des critères différents : un pourcentage inférieur à un seuil, un fichier absent ou un service arrêté. Si plusieurs branches comparent la même variable à une série de valeurs fixes, switch rend souvent la logique plus facile à parcourir.
Par exemple, un script qui traite des codes d’erreur peut associer le code 1 à une erreur réseau, le code 2 à un refus d’authentification et le code 3 à un service indisponible. Dans switch ($codeErreur) { 1 { Write-Output "Erreur réseau" } 2 { Write-Output "Authentification refusée" } 3 { Write-Output "Service indisponible" } default { Write-Output "Code inconnu" } }, chaque valeur dispose d’une branche identifiée et default prend en charge les cas non répertoriés.
Une longue suite d’elseif n’est pas nécessairement mauvaise, mais elle peut masquer le fait que toutes les branches interrogent la même variable. À l’inverse, un switch n’est pas un raccourci automatique pour toute décision : une règle fondée sur des plages numériques ou plusieurs propriétés reste souvent plus naturelle dans un if.
Utiliser le ternaire avec mesure
À partir de PowerShell 7.0, l’opérateur ternaire permet d’exprimer un choix simple sous la forme condition ? résultatSiVrai : résultatSiFaux. Pour affecter une étiquette, nous pouvons écrire $etat = ($pourcentLibre -lt 20) ? "Alerte" : "Normal". Cette expression convient à deux résultats courts et faciles à lire.
Si chaque branche doit lancer plusieurs commandes, gérer une erreur ou modifier plusieurs variables, les blocs if et else restent plus clairs. Une expression compacte peut accélérer la lecture d’un cas simple, mais elle complique le débogage lorsqu’on y ajoute des opérations longues.
La compatibilité compte aussi. Windows PowerShell 5.1 ne prend pas en charge le ternaire introduit dans PowerShell 7.0 ; un script destiné à plusieurs générations de machines doit employer la syntaxe disponible partout ou documenter clairement la version requise. Vérifier l’environnement cible fait partie de la conception, au même titre que le choix des opérateurs.
Tester les limites et les échecs
Pour un seuil fixé à 20, nous pouvons tester les valeurs 19, 20 et 21. Si la règle signifie « inférieur à 20 », seul 19 doit déclencher l’alerte ; si elle signifie « 20 ou moins », il faut employer -le. Ces essais ciblés vérifient que le code traduit précisément la règle décidée par l’équipe.
Ajoutons également des scénarios d’échec : variable vide, lecteur absent, fichier manquant, service introuvable et code non reconnu. Le test d’un cas normal confirme le chemin attendu, tandis que ces cas limites révèlent les hypothèses cachées. Un bloc else explicite évite qu’une situation inattendue soit confondue avec un succès silencieux.
Les variables issues d’une saisie ou d’un fichier doivent être validées avant de servir à une opération sensible. Pour un nombre de jours, nous pouvons refuser une valeur inférieure à 1 et signaler une période supérieure à 365 ; les limites exactes dépendront de l’usage, mais elles doivent être définies avant le lancement d’une suppression ou d’une modification à grande échelle.
Soigner les sorties du script
Write-Output produit une valeur qui peut être récupérée dans un pipeline. Write-Warning signale un problème à la personne qui exécute le script, tandis que Write-Host affiche directement un texte destiné à l’écran. Choisir la bonne commande évite de mélanger une information de présentation avec une donnée destinée à un autre traitement.
Pour savoir si une commande précédente a réussi, $? contient un booléen qui indique le succès de la dernière commande PowerShell. Il ne correspond pas au code numérique de Bash. Pour récupérer le code de sortie du dernier programme externe appelé, PowerShell utilise $LASTEXITCODE, qui est généralement la valeur à transmettre à un ordonnanceur ou à un outil de supervision.
Dans un script administratif, nous terminons les chemins importants par un code explicite : exit 0 pour un déroulement normal et, par exemple, exit 1 lorsqu’une erreur empêche le traitement. Un message affiché peut aider un humain, mais le code de sortie permet à une tâche planifiée de prendre une décision sans interpréter une phrase.
Enfin, la documentation locale aide à vérifier une syntaxe dans l’environnement utilisé : Get-Help about_If décrit les conditions, et Get-Help about_Switch détaille l’alternative correspondante. Une indentation régulière, des noms explicites, des tests sur les seuils et des sorties cohérentes transforment la logique de décision en scripts efficaces que l’équipe peut maintenir et relancer sereinement.