Laboratoire PowerShell local : configuration, exemples et vérification

Introduction

Un laboratoire PowerShell local vous offre un environnement sûr pour tester des commandes, explorer des modules et développer l'automatisation sans affecter les systèmes de production. Ce guide vous accompagne dans la mise en place de votre propre laboratoire, la vérification de l'environnement, les modifications de configuration, la validation des résultats, le diagnostic des pannes et la récupération après des problèmes courants. 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 chaque résultat et documenter les étapes de récupération.

Cet article s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui souhaitent améliorer leurs compétences PowerShell. Vous apprendrez à inventorier votre environnement, appliquer des pratiques de configuration sûres, exécuter des diagnostics, gérer les échecs et suivre une liste de contrôle opérationnelle reproductible. Tous les exemples sont concrets et incluent les sorties attendues et les chemins de récupération.

Inventaire de version et d'environnement

Avant d'effectuer toute modification, comprenez exactement avec quoi vous travaillez. La section Inventaire de version et d'environnement vous aide à identifier le composant concerné, sa plage de versions prises en charge, les prérequis et la topologie de déploiement. Capturez l'état actuel avec une commande en lecture seule issue de la documentation officielle, puis définissez le résultat attendu et le signal d'échec avant toute modification.

Vérifier votre version de PowerShell

PowerShell existe en deux éditions : Windows PowerShell 5.1 (intégré à Windows) et PowerShell 7+ (multiplateforme, anciennement PowerShell Core). Pour voir ce qui est installé, exécutez :

$PSVersionTable.PSVersion

Sortie attendue sur un système Windows 11 moderne avec PowerShell 7.4 :

Major  Minor  Patch  PreReleaseLabel BuildLabel
-----  -----  -----  --------------- ----------
7      4      1

Si la sortie indique Major 5 et Minor 1, vous utilisez Windows PowerShell 5.1. Pour un laboratoire local, installez PowerShell 7+ car il reçoit des mises à jour continues et fonctionne sur toutes les plateformes. Téléchargez-le depuis la page officielle des versions GitHub ou utilisez winget :

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

Vérifiez après l'installation :

pwsh -NoProfile -Command '$PSVersionTable.PSVersion'

Sortie attendue : la nouvelle version, par exemple 7.4.1.

Vérifier la politique d'exécution

La politique d'exécution contrôle si les scripts peuvent s'exécuter. Affichez la politique actuelle pour votre utilisateur et la machine :

Get-ExecutionPolicy -List

Sortie attendue (typique pour un poste de travail) :

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine    RemoteSigned

RemoteSigned est un point de départ raisonnable pour un laboratoire local : les scripts locaux s'exécutent et les scripts distants doivent être signés. Vous pourrez la modifier ultérieurement dans la section Configuration sûre.

Vérifier les modules installés

Listez tous les modules disponibles dans votre session :

Get-Module -ListAvailable | Select-Object Name, Version, ModuleType | Sort-Object Name | Format-Table -AutoSize

Sortie attendue (exemple tronqué) :

Name                      Version    ModuleType
----                      -------    ----------
Microsoft.PowerShell.Archive 7.0.0.0     Binary
Microsoft.PowerShell.Management 7.4.0.0     Binary
PSReadLine                 2.3.4        Binary

Cet inventaire vous aide à repérer les prérequis manquants. Par exemple, si vous prévoyez d'utiliser le module Az pour Azure, vous devez d'abord l'installer.

Vérifier la connectivité réseau (facultatif)

Si votre laboratoire nécessite le téléchargement de modules ou de paquets, vérifiez la connectivité :

Test-NetConnection -ComputerName www.powershellgallery.com -Port 443 | Select-Object ComputerName, RemotePort, TcpTestSucceeded

Sortie attendue lorsque la connectivité est bonne :

ComputerName          RemotePort TcpTestSucceeded
------------          ---------- ----------------
www.powershellgallery.com         443              True

Si TcpTestSucceeded est False, vérifiez votre pare-feu, les paramètres de proxy ou la connexion Internet avant de continuer.

Enregistrer l'état et les horodatages

Capturez toujours l'état actuel et un horodatage avant toute modification. Utilisez une simple transcription ou un fichier journal :

$timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$logFile = "$env:USERPROFILE\lab-inventory-$timestamp.txt"
Get-ExecutionPolicy -List | Out-File $logFile
Get-Module -ListAvailable | Out-File $logFile -Append
Write-Output "Inventory saved to $logFile"

Cela crée une base de référence que vous pourrez comparer ultérieurement.

Chemin de configuration sûr

Lorsque vous devez modifier des paramètres dans votre laboratoire, suivez un chemin de configuration sûr : commencez par une observation en lecture seule, apportez le plus petit changement justifié, vérifiez le résultat et ayez un plan de récupération. N'utilisez jamais de véritables informations d'identification, jetons ou clés privées dans vos exemples ou scripts.

Modifier la politique d'exécution en toute sécurité

Si vous devez exécuter des scripts non signés, vous pouvez définir la politique d'exécution pour l'utilisateur actuel uniquement afin de ne pas affecter l'ensemble du système :

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force

Comportement attendu : aucune sortie. Vérifiez :

Get-ExecutionPolicy -Scope CurrentUser

Sortie attendue : RemoteSigned.

Récupération : pour revenir à la valeur par défaut, exécutez Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined -Force.

Configurer un profil spécifique au laboratoire

Créez un profil qui se charge uniquement pour vos sessions de laboratoire, pas pour toutes les sessions PowerShell. Vous pouvez utiliser un script séparé et le dot-sourcer au besoin. Créez un fichier LabProfile.ps1 dans un emplacement sûr :

$labProfilePath = "$env:USERPROFILE\Documents\PowerShellLab\LabProfile.ps1"
New-Item -Path (Split-Path $labProfilePath) -ItemType Directory -Force
@'
# Lab profile
Set-Location C:\Lab
$env:LAB_ENV = 'development'
Write-Host 'Lab profile loaded.'
'@ | Set-Content -Path $labProfilePath

Pour le charger dans une session :

. $labProfilePath

Sortie attendue : Lab profile loaded. et le répertoire de travail passe à C:\Lab (créez d'abord ce répertoire s'il n'existe pas).

Récupération : démarrez simplement une nouvelle session PowerShell sans dot-sourcer le profil.

Installer un module depuis PowerShell Gallery

Utilisez Install-Module avec la portée CurrentUser pour éviter d'avoir besoin de droits administrateur et limiter l'impact. Par exemple, installez le framework de test Pester :

Install-Module -Name Pester -Scope CurrentUser -Force

Vérifiez :

Get-Module -Name Pester -ListAvailable | Select-Object Name, Version, ModuleType

Sortie attendue (la version peut varier) :

Name   Version  ModuleType
----   -------  ----------
Pester 5.5.0    Script

Récupération : désinstallez avec Uninstall-Module -Name Pester si nécessaire.

Configurer un dépôt Git local pour les scripts

Le contrôle de version est essentiel pour la récupération. Si Git est installé, initialisez un dépôt pour vos scripts de laboratoire :

git init C:\Lab\Scripts

Ensuite, ajoutez et validez :

Set-Location C:\Lab\Scripts
git add .
git commit -m 'Initial lab scripts'

Sortie attendue : un hachage de commit et un résumé. Si Git n'est pas installé, installez-le via winget install --id Git.Git -e --source winget ou depuis https://git-scm.com/.

Vérification et diagnostics

Après toute modification, vérifiez que le système se comporte comme prévu. Cette section présente des commandes de diagnostic concrètes et ce qu'il faut rechercher.

Vérifier la fonctionnalité d'un module

Après avoir installé un module, testez qu'il peut être importé et utilisé. Pour Pester :

Import-Module Pester
Get-Command -Module Pester | Select-Object -First 5 Name, CommandType

Sortie attendue :

Name          CommandType
----          -----------
AfterAll      Function
AfterEach     Function
Assert-MockCalled Function
BeforeAll     Function
BeforeEach    Function

Si l'importation du module échoue, vérifiez le chemin du module et la portée de l'installation.

Tester une fonction simple

Créez un fichier Greet.ps1 avec :

function Get-Greeting {
    param([string]$Name = 'World')
    "Hello, $Name!"
}

Dot-sourcez-le et exécutez :

. .\Greet.ps1
Get-Greeting -Name 'Lab'

Sortie attendue : Hello, Lab!

Si vous obtenez une erreur concernant la politique d'exécution, reportez-vous à la section Chemin de configuration sûr.

Exécuter un test Pester

Créez un fichier de test Greet.Tests.ps1 :

BeforeAll {
    . $PSScriptRoot\Greet.ps1
}

Describe 'Get-Greeting' {
    It 'Returns hello with name' {
        Get-Greeting -Name 'Test' | Should -Be 'Hello, Test!'
    }
    It 'Returns hello with default' {
        Get-Greeting | Should -Be 'Hello, World!'
    }
}

Exécutez les tests :

Invoke-Pester -Path .\Greet.Tests.ps1

Sortie attendue (réussite) :

Tests completed in 0.5s
Tests Passed: 2, Failed: 0, Skipped: 0

Si un test échoue, Pester affiche les valeurs attendues et réelles.

Diagnostic : vérifier les erreurs dans les journaux d'événements (Windows)

Si vous soupçonnez des problèmes plus profonds, consultez le journal d'événements Windows PowerShell :

Get-WinEvent -LogName 'Windows PowerShell' -MaxEvents 10 | Format-List TimeCreated, Id, LevelDisplayName, Message

Recherchez les erreurs qui correspondent à l'heure de votre commande échouée.

Modes de défaillance et récupération

Même dans un laboratoire, les choses tournent mal. Cette section décrit les modes de défaillance courants et comment récupérer.

Défaillance : la politique d'exécution bloque le script

Symptôme : l'exécution d'un script renvoie File cannot be loaded because running scripts is disabled on this system.

Diagnostic : vérifiez la politique actuelle :

Get-ExecutionPolicy -List

Récupération : définissez la politique pour l'utilisateur actuel sur RemoteSigned comme indiqué dans Chemin de configuration sûr, ou exécutez le script avec contournement pour une seule fois :

powershell -ExecutionPolicy Bypass -File .\script.ps1

Défaillance : l'installation du module échoue en raison de la confiance

Symptôme : Install-Module demande un dépôt non approuvé ou échoue avec Unable to resolve package source.

Diagnostic : vérifiez les dépôts enregistrés :

Get-PSRepository

Sortie attendue :

Name                      InstallationPolicy   SourceLocation
----                      ------------------   --------------
PSGallery                 Untrusted            https://www.powershellgallery.com/api/v2

Récupération : définissez la politique d'installation sur approuvé pour la galerie ou utilisez -Force pour accepter les invites :

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
Install-Module -Name Pester -Scope CurrentUser -Force

N'oubliez pas de la remettre sur Untrusted si la sécurité est une préoccupation :

Set-PSRepository -Name PSGallery -InstallationPolicy Untrusted

Défaillance : commande non reconnue après l'installation du module

Symptôme : après l'installation d'un module, Get-Command ne trouve pas ses applets de commande.

Diagnostic : vérifiez si le module est disponible :

Get-Module -ListAvailable -Name ModuleName

S'il n'est pas répertorié, le module peut être installé dans un chemin non inclus dans $env:PSModulePath. Affichez la variable :

$env:PSModulePath -split ';'

Récupération : assurez-vous que le chemin d'installation est inclus, ou réinstallez avec -Scope CurrentUser et redémarrez PowerShell. Vous pouvez également importer manuellement depuis le chemin spécifique :

Import-Module "C:\Users\YourUser\Documents\PowerShell\Modules\ModuleName"

Remplacez YourUser et ModuleName en conséquence.

Défaillance : le script produit une sortie inattendue

Symptôme : votre script s'exécute mais la sortie diffère de celle attendue.

Diagnostic : utilisez Set-PSDebug -Trace 1 pour tracer l'exécution, ou ajoutez des lignes Write-Debug. Par exemple :

Set-PSDebug -Trace 1
.\Greet.ps1
Get-Greeting -Name 'Test'
Set-PSDebug -Trace 0

Cela affiche chaque ligne au fur et à mesure de son exécution. Vérifiez les valeurs des variables avec Write-Host ou Write-Verbose -Verbose.

Récupération : corrigez la logique, puis relancez les tests Pester pour vérifier.

Défaillance : problèmes de port ou de connexion dans les laboratoires distants

Si votre laboratoire implique la communication à distance, testez WinRM :

Test-WSMan -ComputerName localhost

Sortie attendue : un message de type XML avec ProductVersion et ProtocolVersion. En cas d'échec, assurez-vous que le service Windows Remote Management est en cours d'exécution :

Get-Service WinRM

Si le statut n'est pas Running, démarrez-le :

Start-Service WinRM

Récupération : pour les problèmes persistants, exécutez Enable-PSRemoting -Force (nécessite des droits administrateur) pour configurer la communication à distance.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après toute modification dans votre laboratoire PowerShell local pour garantir la cohérence et la sécurité.

Conservez cette liste de contrôle dans un fichier ou dans vos notes de laboratoire. Avant chaque session, exécutez les étapes 1 à 5. Après les modifications, exécutez les étapes 6 à 10.

Conclusion

Un laboratoire PowerShell local n'est utile que si vous y appliquez de la rigueur. En suivant les pratiques de ce guide — inventorier votre environnement, apporter des modifications de configuration sûres, vérifier avec des commandes concrètes, diagnostiquer les défaillances et utiliser une liste de contrôle reproductible — vous pouvez développer et tester en toute confiance. N'oubliez pas que chaque commande doit être limitée en version, observable et réversible lorsque c'est possible.

Comme prochaine étape, choisissez une vérification à faible risque de cet article, comme la vérification de votre politique d'exécution ou l'exécution d'un simple test Pester. Enregistrez l'état actuel, exécutez la vérification, comparez le résultat avec la sortie attendue et examinez les dépendances telles que l'automatisation Windows, Docker ou GitLab CI/CD qui peuvent affecter votre laboratoire.

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. Construisez votre laboratoire avec ces principes et vous disposerez d'une base solide pour l'automatisation PowerShell.