Pour écrire une condition PowerShell fiable, placez le test entre parenthèses après if, puis l’action entre accolades : le script exécute ce bloc uniquement si le résultat est vrai. Les blocs elseif permettent d’examiner d’autres cas et else prévoit une réponse par défaut.
- if lance une action lorsque son test est vrai.
- elseif examine un autre scénario si les tests précédents échouent.
- else traite les cas qui restent.
- Les opérateurs comme -eq, -lt et -and précisent les règles de décision.
- À partir de PowerShell 7.0, l’opérateur ternaire condense certains choix simples sur une ligne.
Nous allons partir d’un cas concret : un petit script d’administration qui surveille l’espace disque et l’état de services. Les mêmes principes vous serviront à valider un fichier, filtrer une saisie ou automatiser une tâche répétitive.
Comprendre la syntaxe conditionnelle PowerShell
Une condition permet à PowerShell de choisir les commandes à exécuter selon une situation donnée. Sans ce mécanisme, un script suit toujours la même séquence, même lorsqu’un fichier manque ou qu’un service est arrêté. Avec une condition if, nous pouvons adapter son comportement à ce que le système nous renvoie.
La forme la plus simple s’écrit ainsi : if ($condition) { commandes }. Les parenthèses encadrent le test et les accolades délimitent le bloc associé. Cette ponctuation fait partie de la syntaxe, et une accolade manquante peut empêcher l’exécution du script.
Exemple : $espaceLibre = 15 ; if ($espaceLibre -lt 20) { Write-Warning “Espace disque faible : $espaceLibre Go restants” }. Ici, l’opérateur -lt signifie « inférieur à ». Comme 15 est inférieur à 20, PowerShell affiche l’avertissement.
La condition peut évaluer une variable booléenne, un résultat de commande ou une comparaison. Les valeurs $true et $false sont utiles lorsque le résultat a déjà été calculé ailleurs : if ($sauvegardeTerminee) { Write-Output “Sauvegarde prête” }. Si la variable contient $false, le bloc est simplement ignoré.
On peut aussi tester directement une commande. Par exemple, Test-Path “C:Rapportsquotidien.csv” renvoie $true si le chemin existe et $false dans le cas contraire. Nous pouvons donc écrire : if (Test-Path “C:Rapportsquotidien.csv”) { Write-Output “Le rapport est présent” }.
Lire les blocs sans hésiter
Pour une lecture confortable, chaque niveau de code doit être décalé de manière régulière. Cette indentation montre immédiatement quelles commandes appartiennent à un test et lesquelles se trouvent à l’extérieur. Elle ne change généralement pas le résultat, mais elle réduit les erreurs lorsque le script évolue.
Dans notre exemple d’inventaire, nous pouvons vérifier la présence d’un fichier avant d’en extraire les données. Si le chemin est absent, le script peut afficher un message compréhensible plutôt que de lancer une commande qui échouera. Cette première décision évite qu’une petite anomalie se transforme en arrêt brutal de l’automatisation.
Gardez aussi les noms de variables explicites, comme $espaceLibre ou $rapportExiste, plutôt que $x ou $v. Lorsque nous relisons le script plusieurs semaines après sa création, le nom révèle rapidement la nature du test. Une condition bien nommée constitue déjà une partie de sa documentation.
Enchaîner if, elseif et else
Un seul test ne suffit pas toujours. Pour distinguer plusieurs niveaux de risque, nous pouvons ajouter un bloc elseif après le premier if, puis terminer par un bloc else qui couvre les cas non prévus. Cette structure convient, par exemple, à un script de surveillance qui classe l’espace disque selon plusieurs seuils.
Exemple : $espaceLibre = 35 ; if ($espaceLibre -lt 20) { Write-Warning “Espace faible” } elseif ($espaceLibre -lt 50) { Write-Output “Espace à surveiller” } else { Write-Output “Espace confortable” }. Avec 35 Go, le premier test échoue, le second réussit et le troisième n’est pas exécuté.
PowerShell examine les blocs dans leur ordre d’apparition et s’arrête au premier test vrai. L’ordre est donc déterminant : avec un seuil général placé avant un seuil plus précis, le script peut prendre une décision trop tôt. Dans l’exemple du disque, nous commençons par le niveau le plus préoccupant, puis nous élargissons progressivement les seuils.
Le bloc instruction else ne possède pas de condition entre parenthèses, car il représente tous les scénarios qui n’ont pas satisfait les tests précédents. Il n’est pas obligatoire : si aucune action par défaut n’est utile, nous pouvons arrêter la structure après if ou après elseif. Dans un script d’exploitation, une réponse de repli explicite reste souvent pratique pour repérer une valeur inattendue.
Combiner plusieurs critères
Les opérateurs de comparaison permettent d’évaluer des nombres, des chaînes ou des états. Parmi les plus courants, -eq vérifie l’égalité, -ne l’inégalité, -gt une valeur supérieure, -ge une valeur supérieure ou égale, -lt une valeur inférieure et -le une valeur inférieure ou égale.
PowerShell utilise ces opérateurs pour différents types de valeurs : nous n’avons pas besoin de remplacer -eq par un symbole distinct selon que nous comparons un nombre ou du texte. Pour les chaînes, les variantes habituelles comme -eq ne distinguent pas la casse ; -ceq effectue une comparaison sensible aux majuscules et minuscules. Choisissez le comportement adapté à vos données.
Pour exiger deux conditions, utilisez -and ; pour accepter l’une ou l’autre, choisissez -or. Par exemple : if (($service.Status -eq “Stopped”) -and ($service.StartType -eq “Automatic”)) { Write-Warning “Service automatique arrêté” }. Les parenthèses autour de chaque test rendent le raisonnement plus facile à suivre.
Nous pouvons également inverser un résultat avec -not, ou employer le point d’exclamation dans certains contextes. Une condition comme if (-not (Test-Path $chemin)) traite l’absence d’un fichier. Pour un script destiné à une équipe, privilégiez la forme la plus lisible pour vos collègues plutôt que la version la plus compacte.
Une règle utile consiste à écrire les exceptions avant les cas ordinaires. Si un service peut être « Stopped », « Running » ou dans un état inattendu, définissez d’abord les conséquences de l’arrêt et du fonctionnement normal, puis prévoyez une réponse pour le reste. Le script devient ainsi plus prévisible lorsque le système rencontre une situation inhabituelle.
Tester fichiers, services et données
Les conditions prennent toute leur valeur lorsqu’elles répondent à des besoins d’administration concrets. Une vérification de chemin, un contrôle de service ou une mesure d’espace disponible transforme une suite de commandes en outil capable de réagir à l’état réel de la machine. Nous pouvons illustrer ce principe avec une tâche fictive de maintenance sur un serveur de fichiers.
Vérifier un fichier : if (Test-Path “C:Sauvegardesserveur.zip”) { Write-Output “Archive disponible” } else { Write-Warning “Archive manquante” }. La commande Test-Path fournit le résultat logique attendu par if. Le script peut ensuite lancer une copie ou signaler clairement l’absence de l’archive.
Pour un service Windows, récupérez d’abord son objet avec Get-Service, puis testez sa propriété Status. Par exemple : $service = Get-Service -Name “Spooler” ; if ($service.Status -eq “Running”) { Write-Output “Service actif” } else { Write-Warning “Service arrêté ou indisponible” }. Ce contrôle distingue l’état connu du service d’une erreur de recherche, que nous devons aussi gérer si le nom est erroné.
Dans un script de production, évitez de supposer que chaque commande renvoie forcément un objet exploitable. Une faute dans le nom du service ou un droit insuffisant peut provoquer une erreur avant même que la condition soit évaluée. Nous pouvons encadrer les opérations susceptibles d’échouer avec une gestion d’erreur adaptée, puis fournir un message qui indique la cause et l’action attendue.
Valider les entrées utilisateur
Les données fournies par une personne ou un fichier externe méritent une vérification avant utilisation. Si un script demande un nombre de jours, contrôlez que la valeur est bien numérique et qu’elle se situe dans une plage raisonnable. Une entrée vide, négative ou très élevée ne doit pas déclencher silencieusement une opération surprenante.
Un exemple de règle peut être : if ($jours -lt 1) { Write-Warning “Saisissez au moins un jour” } elseif ($jours -gt 365) { Write-Warning “La période dépasse un an” } else { Write-Output “Période acceptée” }. Les seuils dépendent du besoin, mais les cas limites doivent être décidés avant le déploiement.
Pour vérifier l’espace disque, nous pouvons comparer une valeur mesurée à deux seuils, comme dans le premier exemple. Si 15 Go déclenchent une alerte et 35 Go un avertissement de surveillance, l’équipe dispose d’une indication graduée plutôt que d’un simple message « tout va bien » ou « tout va mal ». Les seuils doivent correspondre au volume traité et à la fréquence des sauvegardes.
Gardez les actions sensibles séparées de leurs tests. Avant de supprimer des fichiers ou de redémarrer un service, affichez l’état détecté et vérifiez que la règle couvre bien le cas visé. En pratique, tester d’abord sur un environnement de démonstration permet de confirmer qu’un seuil de 20 Go ne déclenche pas une opération à 200 Go par erreur.
Lorsque plusieurs contrôles se suivent, écrivez une phrase claire pour chaque résultat. « Rapport présent », « service arrêté » et « espace inférieur au seuil » sont des messages plus utiles qu’un simple « erreur ». Un bon test prend une décision ; un bon message aide ensuite à comprendre pourquoi elle a été prise.
Choisir entre elseif, switch et ternaire
La chaîne if et elseif convient lorsque les tests portent sur des critères différents, par exemple une valeur inférieure à un seuil, une date dépassée ou un service arrêté. Quand nous comparons une même variable à de nombreuses valeurs fixes, le bloc switch rend souvent la logique plus facile à parcourir. Le meilleur choix dépend de la forme des règles, pas d’une recherche systématique de la syntaxe la plus courte.
Exemple : $codeErreur = 3 ; 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 de son propre bloc, tandis que default couvre celles qui ne sont pas répertoriées.
Pour un menu ou un traitement de plusieurs codes, switch évite une longue succession de tests portant tous sur la même variable. PowerShell propose aussi des modes de correspondance par caractère générique ou expression régulière, utiles pour classer des noms de fichiers. Utilisez ces options lorsque leur motif est réellement nécessaire : une égalité simple reste plus directe à comprendre.
Employer le ternaire avec mesure
L’opérateur ternaire est disponible depuis PowerShell 7.0. Il adopte la forme condition ? valeur_si_vrai : valeur_si_faux et convient à une décision courte qui produit deux résultats simples. Par exemple : $etat = ($espaceLibre -lt 20) ? “Alerte” : “Normal”. Nous pouvons alors réutiliser $etat dans un message ou un rapport.
Cette écriture ne remplace pas tous les blocs conditionnels. Si chaque branche doit exécuter plusieurs commandes, ouvrir un fichier ou gérer des erreurs, un if et un else restent généralement plus lisibles. Une ligne compacte peut sembler élégante au premier regard, puis compliquer le débogage lorsque les expressions s’allongent.
Les commandes utilisées dans les branches ternaires peuvent nécessiter des parenthèses afin que leur résultat soit interprété correctement. Testez la syntaxe dans la version de PowerShell ciblée : un poste qui utilise encore Windows PowerShell 5.1 ne prend pas en charge l’opérateur introduit dans PowerShell 7.0. La compatibilité doit faire partie de votre choix, surtout si le script circule entre plusieurs machines.
| Structure | Usage adapté | Point à surveiller |
| if / elseif / else | Tests distincts et décisions graduées | Ordre des conditions |
| switch | Nombreux choix pour une même valeur | Prévoir default |
| Opérateur ternaire | Choix simple entre deux résultats | Compatibilité et clarté |
Par exemple, un traitement de codes d’erreur se prête bien à switch, tandis qu’une alerte fondée sur plusieurs seuils est plus naturelle avec elseif. Pour affecter une étiquette selon un simple test vrai ou faux, le ternaire peut être efficace. Sélectionner la forme qui reflète directement le problème facilite la maintenance et évite de transformer une règle simple en puzzle.
Appliquer les bonnes pratiques PowerShell
Un script fiable ne dépend pas uniquement de la bonne condition : sa présentation et sa méthode de test comptent aussi. La lisibilité du code facilite les relectures, les corrections et la transmission à une autre personne. Une indentation régulière, des noms explicites et des blocs de taille raisonnable rendent le flux de décision visible dès le premier regard.
Écrivez une action par ligne lorsque cela clarifie le résultat. Par exemple, placez le message d’avertissement dans son propre bloc plutôt que de condenser test, commande et commentaire sur une ligne difficile à relire. Les commentaires doivent expliquer une règle métier ou un choix non évident, sans répéter mot pour mot le code situé juste dessous.
Les conditions imbriquées peuvent être utiles lorsqu’un second test n’a de sens que si le premier est réussi. Imaginons que nous vérifiions d’abord si un dossier existe, puis que nous contrôlions sa taille. Nous pouvons placer le second if dans le premier bloc, mais une chaîne elseif ou une validation précoce peut parfois exprimer la même logique avec moins de niveaux.
Tester les cas limites
Avant de lancer un script sur un système important, testez au minimum un cas normal, un cas d’échec et une valeur limite. Pour un seuil de 20 Go, essayez par exemple 19, 20 et 21 Go. Cette vérification montre si l’usage de -lt ou -le correspond bien à la règle attendue.
Vérifiez aussi les données inattendues : variable vide, fichier absent, service introuvable ou code d’erreur non répertorié. Le bloc else ou default doit produire une réponse utile plutôt que masquer la situation. Un script qui explique pourquoi il n’a pas agi est plus simple à diagnostiquer qu’un script silencieux.
Pour les conditions combinées, parenthéser chaque comparaison réduit les ambiguïtés de lecture. Par exemple : if (($service.Status -eq “Stopped”) -and ($service.StartType -eq “Automatic”)) { … }. Cette présentation sépare visuellement les deux critères et aide à vérifier leur relation logique avant exécution.
Utilisez des sorties adaptées à l’objectif. Write-Output convient à une valeur que d’autres commandes peuvent récupérer, tandis que Write-Warning signale un problème à la personne qui exécute le script. Write-Host peut servir à afficher une information destinée à l’écran, mais ne remplace pas une sortie structurée si vous prévoyez de réutiliser le résultat dans un pipeline.
Enfin, consultez l’aide intégrée avec Get-Help about_If et Get-Help about_Switch pour explorer les variantes disponibles dans votre environnement. La documentation locale permet de vérifier une syntaxe sans dépendre d’un onglet ouvert au hasard, et elle précise les comportements propres à chaque version. Des essais sur une machine de test complètent cette lecture : une bonne condition est celle dont le résultat reste compréhensible avant, pendant et après son exécution.
Lorsque vos blocs restent courts, que chaque seuil a une raison claire et que les cas inattendus sont prévus, vos automatisations gagnent en fiabilité. C’est cette discipline, plus que la quantité de syntaxe, qui transforme un simple test en script réellement utile.