Commandes PowerShell de base avec exemples pratiques : guide pratique pour les opérations quotidiennes

Introduction

Les commandes PowerShell de base avec exemples pratiques aident les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.

Cet article se concentre sur les commandes PowerShell pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les commandes essentielles, des exemples, des références d'aide-mémoire et des procédures opérationnelles aux résultats attendus, aux signaux de défaillance et aux décisions de récupération correspondant à des scénarios réels.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Avant d'exécuter toute commande, sachez avec quoi vous travaillez. Vérifier la version de PowerShell, l'édition et l'environnement hôte évite les surprises de compatibilité. Utilisez les commandes en lecture seule suivantes :

# Version et édition de PowerShell
$PSVersionTable.PSVersion
$PSVersionTable.PSEdition
$PSVersionTable.OS

Sortie attendue sur un système Windows 10/11 ou Server 2019/2022 typique :

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      19041  1320
Desktop
Microsoft Windows 10.0.19044

Sur PowerShell Core 7.x, vous verrez Core au lieu de Desktop et une description du système d'exploitation multiplateforme. Enregistrez toujours la version avant d'écrire un script ; de nombreuses applets de commande et paramètres diffèrent entre Windows PowerShell 5.1 et PowerShell 7+.

Si vous gérez plusieurs machines, collectez les mêmes informations à distance avec Invoke-Command :

Invoke-Command -ComputerName SERVEUR01 -ScriptBlock { $PSVersionTable.PSVersion }

Signal de défaillance : si la commande à distance échoue avec « WinRM ne peut pas terminer l'opération » ou « Accès refusé », vérifiez que WinRM est activé (Enable-PSRemoting -Force) et que votre compte dispose des droits administratifs sur la cible.

Pour vérifier la politique d'exécution, qui contrôle si les scripts peuvent s'exécuter, utilisez :

Get-ExecutionPolicy -List

Une sortie sûre typique affiche Restricted (par défaut) ou RemoteSigned (recommandé pour les scripts locaux). Pour autoriser les scripts créés localement tout en bloquant les scripts distants non signés, définissez :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Rayon d'impact : cela affecte uniquement la politique d'exécution des scripts de l'utilisateur actuel, pas toute la machine. Vérification : exécutez à nouveau Get-ExecutionPolicy et confirmez qu'il renvoie RemoteSigned.

Piège courant : confondre $PSVersionTable.PSVersion avec la version du produit affichée dans la boîte de dialogue Fonctionnalités Windows. PowerShell 5.1 est intégré à Windows, tandis que PowerShell 7+ est installé séparément et peut être référencé comme pwsh au lieu de powershell. Confirmez toujours l'exécutable utilisé avec (Get-Process -Id $PID).ProcessName.

Chemin de configuration sécurisé

La modification de la configuration doit suivre un chemin prévisible : observer l'état actuel, appliquer le plus petit changement, vérifier et disposer d'un plan de restauration.

Exemple : définir une variable d'environnement système

Tout d'abord, observez la valeur actuelle :

[Environment]::GetEnvironmentVariable("MY_APP_HOME", "Machine")

Si la variable n'existe pas, la sortie est vide. Pour la définir pour tous les utilisateurs (nécessite des droits d'administrateur) :

[Environment]::SetEnvironmentVariable("MY_APP_HOME", "C:\Apps\MyApplication", "Machine")

Pour utiliser la nouvelle valeur dans la session actuelle sans se déconnecter, mettez également à jour la portée du processus :

$env:MY_APP_HOME = "C:\Apps\MyApplication"

Rayon d'impact : cela modifie l'environnement pour tous les utilisateurs de la machine, ce qui peut affecter tout service ou application qui lit cette variable. Vérifiez avec :

[Environment]::GetEnvironmentVariable("MY_APP_HOME", "Machine")

Sortie attendue : C:\Apps\MyApplication.

Restauration : si le changement cause des problèmes, supprimez la variable avec :

[Environment]::SetEnvironmentVariable("MY_APP_HOME", $null, "Machine")

Piège courant : tenter de définir une variable à portée machine sans invite élevée. La commande semble réussir mais ne persiste pas, ou lève « L'accès au registre demandé n'est pas autorisé. » Exécutez toujours PowerShell en tant qu'administrateur pour les modifications à portée machine.

Exemple : modifier une clé de registre en toute sécurité

La modification du registre nécessite de la prudence. Tout d'abord, sauvegardez la clé :

$backupPath = "C:\RegBackups\MyKey.reg"
reg export HKLM\Software\MyApp $backupPath

Vérifiez que la sauvegarde existe :

Test-Path $backupPath

S'il renvoie True, vous pouvez continuer. Pour modifier une valeur :

Set-ItemProperty -Path "HKLM:\Software\MyApp" -Name "LogLevel" -Value "Debug"

Vérifiez :

Get-ItemProperty -Path "HKLM:\Software\MyApp" -Name "LogLevel"

Sortie attendue :

LogLevel : Debug
PSPath   : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\MyApp
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software
PSChildName  : MyApp
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

Restauration : si quelque chose se casse, restaurez la sauvegarde :

reg import $backupPath

Piège courant : utiliser Set-ItemProperty sur une clé de registre qui n'existe pas. La commande lève « La propriété LogLevel n'existe pas au chemin... » à moins que la clé et la propriété ne soient déjà présentes. Pour créer une nouvelle propriété, utilisez d'abord New-ItemProperty.

Vérification et diagnostics

Après tout changement, vérifiez l'état du système. Utilisez des applets de commande intégrées pour récupérer des informations et les comparer aux valeurs attendues.

Contrôle de l'état d'un service

Supposons que vous ayez redémarré un service et que vous deviez confirmer qu'il est en cours d'exécution et accepte les requêtes. Utilisez :

Get-Service -Name "Spooler" | Select-Object Name, Status, StartType

Sortie attendue :

Name    Status StartType
----    ------ ---------
Spooler Running Automatic

Pour des diagnostics plus approfondis, consultez les événements récents du service :

Get-WinEvent -LogName System -MaxEvents 20 | Where-Object { $_.ProviderName -like "*Spooler*" -or $_.Message -like "*Spooler*" } | Select-Object TimeCreated, Id, LevelDisplayName, Message

Si le service ne démarre pas, recherchez des événements d'erreur comme l'ID d'événement 7034 (service terminé de manière inattendue) ou 7000 (échec du démarrage du service).

Piège courant : supposer qu'un service est sain parce que son état est « En cours d'exécution ». Un service peut être en cours d'exécution mais bloqué ou ne pas répondre aux requêtes. Testez toujours la fonctionnalité, par exemple en envoyant un travail d'impression de test (pour le spouleur) ou en appelant un point de terminaison d'API.

Test de connectivité réseau

Utilisez Test-NetConnection pour vérifier la connectivité et la disponibilité des ports :

Test-NetConnection -ComputerName "db.example.com" -Port 1433

Sortie attendue en cas de succès :

ComputerName     : db.example.com
RemoteAddress    : 10.0.0.15
RemotePort       : 1433
InterfaceAlias   : Ethernet
SourceAddress    : 10.0.0.100
TcpTestSucceeded : True

Si TcpTestSucceeded est False, vérifiez la résolution DNS, les règles de pare-feu et si le service est en écoute :

Resolve-DnsName "db.example.com"
Get-NetFirewallRule -DisplayName "*SQL*" | Select-Object DisplayName, Enabled, Action

Piège courant : utiliser Test-Connection (ping ICMP) pour tester un port. Le ping vérifie uniquement la disponibilité de l'hôte, pas un service spécifique. De nombreux pare-feu bloquent ICMP même lorsque le port cible est ouvert.

Modes de défaillance et récupération

Chaque opération peut échouer. Disposer d'un chemin de récupération documenté réduit les temps d'arrêt et le stress.

Épuisement de l'espace disque

Une défaillance courante est un disque plein. Détectez avec :

Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{Name="UsedGB";Expression={[math]::Round($_.Used/1GB,2)}}, @{Name="FreeGB";Expression={[math]::Round($_.Free/1GB,2)}}

Sortie pour un lecteur C: presque plein :

Name UsedGB FreeGB
---- ------ ------
C    236.10  10.50
D    500.00 250.00

Si l'espace libre tombe en dessous de 10 %, recherchez les fichiers volumineux :

Get-ChildItem -Path C:\ -Recurse -File -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 10 FullName, Length

Récupération : supprimez ou archivez les fichiers inutiles, videz les dossiers temporaires et étendez le volume si possible.

Piège courant : ignorer -ErrorAction SilentlyContinue lors de l'analyse du lecteur entier ; sans cela, les erreurs d'accès refusé encombrent la sortie. Évitez également de supprimer des fichiers sans confirmer qu'ils ne sont pas utilisés ; utilisez Get-Process | Where-Object { $_.Path -like 'C:\LargeFile*' } pour voir si un processus détient le fichier.

Fichier ou processus verrouillé

Parfois, un fichier ne peut pas être supprimé car un processus le verrouille. Identifiez le processus :

Get-Process | Where-Object { $_.Modules.FileName -contains "C:\Path\To\File.txt" }

Si cela est lent, utilisez handle.exe de Sysinternals (s'il est installé) pour une recherche plus rapide :

handle.exe "C:\Path\To\File.txt"

Récupération : arrêtez le processus proprement avec Stop-Process -Name NomProcessus -Force si c'est sûr, puis réessayez la suppression.

Piège courant : forcer l'arrêt d'un processus système critique. Vérifiez toujours le nom du processus et son objectif avant de l'arrêter. Sur un serveur de production, planifiez une fenêtre de maintenance ou coordonnez-vous avec d'autres équipes.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après toute opération PowerShell. Chaque élément inclut le rôle responsable et la fréquence de révision pour maintenir la responsabilité.

Piège courant : traiter la liste de contrôle comme une activité ponctuelle. Les environnements opérationnels évoluent ; révisez et mettez à jour la liste de contrôle mensuellement ou chaque fois qu'une défaillance révèle une lacune.

Pièges courants et comment les éviter

1. Exécuter des commandes sans les comprendre

Copier-coller des scripts depuis Internet peut introduire des risques de sécurité ou des modifications non intentionnelles. Lisez toujours la commande, remplacez les espaces réservés et testez d'abord sur un système non productif. Utilisez les paramètres -WhatIf et -Confirm lorsqu'ils sont disponibles :

Remove-Item C:\Temp\* -WhatIf

Cela montre ce qui se passerait sans réellement supprimer des fichiers.

2. Utiliser des informations d'identification en texte brut

Coder en dur des mots de passe dans les scripts est une faille de sécurité majeure. Utilisez des chaînes sécurisées et des objets d'informations d'identification :

$cred = Get-Credential
Invoke-Command -ComputerName SERVEUR01 -Credential $cred -ScriptBlock { Get-Service }

Alternativement, utilisez le Gestionnaire d'informations d'identification Windows ou Azure Key Vault pour les scripts automatisés.

3. Ignorer la gestion des erreurs

Un script qui échoue silencieusement peut laisser les systèmes dans un état incohérent. Définissez toujours $ErrorActionPreference = "Stop" dans les scripts critiques et utilisez des blocs try/catch :

try {
    Get-Item C:\ImportantFile.txt -ErrorAction Stop
} catch {
    Write-Host "Fichier introuvable : $($_.Exception.Message)" -ForegroundColor Red
    # déclencher une alerte ou une récupération
}

4. Ne pas tester la restauration

Avoir une sauvegarde ne suffit pas ; vous devez savoir comment la restaurer. Testez régulièrement les procédures de restauration dans un environnement de test. Simulez un déploiement échoué et mesurez le temps nécessaire pour récupérer.

5. Utiliser d'anciennes applets de commande dans les nouvelles versions de PowerShell

Certaines applets de commande ont été remplacées ou renommées. Par exemple, Get-WMIObject est déconseillé dans PowerShell 6+ ; utilisez plutôt Get-CimInstance. Vérifiez toujours la compatibilité avec votre version cible de PowerShell.

Conclusion

Les commandes PowerShell de base avec exemples pratiques ne deviennent précieuses que lorsque chaque recommandation est versionnée, observable et réversible là où la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une technique de vérification à faible risque de ce guide, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles que l'automatisation Windows, Docker et les pipelines CI/CD GitLab.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.