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.