PowerShell est largement utilisé pour automatiser des tâches d’administration système, aussi bien en local que sur des serveurs ou dans des environnements cloud (Azure Automation, pipelines CI/CD, tâches planifiées).
Dans ces contextes, un script qui “semble” fonctionner peut pourtant masquer des erreurs critiques, conduisant à des résultats partiels, incohérents, voire dangereux.

La gestion des erreurs devient alors un élément central de la fiabilité des scripts PowerShell.

Problématique rencontrée

Lors de l’exécution de plusieurs scripts automatisés, certaines commandes échouaient sans interrompre le script.
Aucune alerte claire n’était remontée, et l’exécution se terminait avec succès, alors que certaines actions n’avaient jamais été effectuées.

Les symptômes étaient typiques :

• aucune interruption du script
• aucune gestion centralisée des erreurs
• résultats incomplets ou faux positifs
• difficulté à diagnostiquer a posteriori

PowerShell distingue principalement deux catégories d’erreurs, avec des comportements très différents.

Erreurs non bloquantes (Non-terminating errors)

Ce sont les erreurs les plus courantes.
Par défaut, PowerShell affiche l’erreur à l’écran mais continue l’exécution du script.

Exemples :

• objet introuvable
• accès refusé
• commande partiellement invalide

Ces erreurs ne déclenchent pas un Catch.

Erreurs bloquantes (Terminating errors)

Ces erreurs interrompent immédiatement l’exécution du script et déclenchent automatiquement un Catch.

Exemples :

• cmdlet critique en échec
• erreur levée manuellement
• erreur forcée via configuration

Le rôle clé de -ErrorAction

Le paramètre -ErrorAction permet de contrôler le comportement des erreurs.

Valeurs principales de -ErrorAction :

• Continue (par défaut)
  Affiche l’erreur et poursuit l’exécution.
• SilentlyContinue
  Ignore l’erreur sans affichage (dangereux en automatisation).
• Stop
  Transforme une erreur non bloquante en erreur bloquante.
• Ignore
  Ignore totalement l’erreur (rarement recommandé).
• Inquire
  Demande une confirmation interactive (peu adapté à l’automatisation).

Un piège courant consiste à utiliser Try / Catch sans forcer les erreurs à être bloquantes.

Try {
    Get-ADUser -Identity "UserInexistant"
}
Catch {
    Write-Host "Erreur détectée: $($_.Exception.Message)"
}

Dans ce cas :

• l’erreur s’affiche
• le script continue
• le Catch n’est jamais exécuté

Bonne pratique : combiner Try / Catch et -ErrorAction Stop

Try {
    Get-ADUser -Identity "UserInexistant" -ErrorAction Stop
}
Catch {
    Write-Host "Erreur détectée: $($_.Exception.Message)"
}

Toute erreur est :

• interceptée
• traitée
• journalisée proprement