3.4 : Communiquer avec l'utilisateur : Write-Host, Write-Output et Read-Host

Sophie s’arrête devant un poste où un script vient de planter. “Regarde cette ligne : le développeur a utilisé Write-Host pour afficher un résultat, puis a essayé de le récupérer dans une variable plus loin. Ça n’a jamais fonctionné, et il a mis une heure à comprendre pourquoi.” C’est l’un des pièges les plus classiques de PowerShell, et il mérite qu’on s’y arrête.

Write-Output : reposer une pièce sur le tapis roulant

Write-Output envoie un objet dans le pipeline. Ce que vous “écrivez” peut donc être capturé, redirigé, transformé par la cmdlet suivante :

function Get-Salutation {
    Write-Output "Bonjour depuis Nordika"
}

$message = Get-Salutation   # $message contient bien le texte

En réalité, dans une fonction ou un script, Write-Output est même souvent implicite : écrire juste "Bonjour depuis Nordika" sans la cmdlet produit exactement le même résultat, car PowerShell renvoie automatiquement tout ce qui n’est pas explicitement capturé ou redirigé ailleurs.

Write-Host : afficher à l’écran, et rien d’autre

Write-Host affiche directement dans la console, avec parfois des options de couleur — mais ne renvoie jamais rien dans le pipeline :

function Get-Salutation {
    Write-Host "Bonjour depuis Nordika" -ForegroundColor Green
}

$message = Get-Salutation   # $message est vide ($null) !

C’est exactement le piège rencontré par le développeur du script en panne : Write-Host est parfait pour un message purement visuel destiné à un humain (une progression, une couleur d’alerte), mais catastrophique si vous comptez réutiliser cette valeur ensuite dans le script.

Règle simple à retenir : si le résultat doit pouvoir être réutilisé (stocké, transmis, transformé), utilisez Write-Output (ou rien du tout). Si le message est uniquement destiné à l’œil de l’utilisateur à l’écran, Write-Host convient.

Les autres niveaux de message

Pour structurer les messages d’un script un peu sérieux, PowerShell propose plusieurs cmdlets dédiées, chacune avec son propre flux :

Write-Verbose "Connexion au serveur SRV-01 en cours..."
Write-Warning "Le service Spooler est arrêté sur SRV-02"
Write-Error "Impossible de joindre SRV-03"
  • Write-Verbose : n’affiche rien par défaut, sauf si le script est lancé avec le paramètre -Verbose — pratique pour du détail optionnel sans polluer une exécution normale
  • Write-Warning : toujours affiché, en jaune, pour signaler un point d’attention sans bloquer le script
  • Write-Error : signale une erreur (on détaille la gestion complète des erreurs en section 5)

Read-Host : demander une information à l’utilisateur

À l’inverse, Read-Host met le script en pause et attend une saisie au clavier :

$nomServeur = Read-Host "Sur quel serveur voulez-vous intervenir ?"
Write-Output "Intervention prévue sur : $nomServeur"

Pour un mot de passe ou une donnée sensible, l’option -AsSecureString masque la saisie à l’écran et la stocke sous une forme sécurisée :

$motDePasse = Read-Host "Mot de passe du compte de service" -AsSecureString

Un exemple concret Nordika

$serveur = Read-Host "Quel serveur souhaitez-vous redémarrer ?"
Write-Warning "Vous êtes sur le point de redémarrer $serveur"
$confirmation = Read-Host "Confirmer ? (O/N)"

if ($confirmation -eq "O") {
    Write-Verbose "Redémarrage de $serveur en cours..." -Verbose
    Write-Output "Redémarrage confirmé pour $serveur"
} else {
    Write-Output "Opération annulée"
}

(Le if sera détaillé en profondeur en section 5 — vous pouvez déjà en deviner la logique.)

Retenez la distinction centrale de cette leçon : Write-Output (ou rien) alimente le tapis roulant et peut être réutilisé, Write-Host s’adresse uniquement à l’œil de l’utilisateur, et Read-Host fait l’inverse en récupérant une information depuis le clavier. Confondre ces rôles est l’une des toutes premières causes de scripts PowerShell qui “ne marchent pas comme prévu”.

Dans la prochaine leçon, place au quiz de fin de section, pour valider variables, tableaux, hashtables et communication utilisateur.