C'est quoi un script ? PowerShell ou Bash

Un script est un fichier texte qui contient une suite de commandes, exécutées l'une après l'autre par un interpréteur de commandes (le shell) comme si tu les tapais toi-même. Ce chapitre explique pourquoi un administrateur écrit des scripts, ce qui distingue PowerShell de Bash, puis te fait écrire et lancer ton premier script dans chaque langage, en évitant les trois erreurs qui bloquent tous les débutants.

Pourquoi écrire un script

Lundi matin chez Sorbier Logistique, Chloé Lambert reçoit la liste des douze saisonniers qui arrivent à l'entrepôt : il faut un compte dans l'annuaire pour chacun, dans la bonne unité d'organisation, membre du bon groupe, avec un mot de passe initial à changer. À la souris, c'est une heure de clics et au moins une faute de frappe. Avec un script qui lit la liste, c'est dix secondes, et le même script resservira en janvier, à la fin de leurs contrats, pour les désactiver.

Un script apporte quatre choses que le travail à la main n'apporte pas.

• La vitesse. Ce qui se répète (créer des comptes, vérifier vingt serveurs, archiver des journaux) se fait en une commande.
• La fiabilité. Le script fait exactement la même chose à chaque exécution. Il ne saute pas une étape un vendredi soir.
• La traçabilité. Un script bien écrit note ce qu'il a fait dans un journal : qui, quoi, quand, avec quel résultat.
• La documentation. Le script est la procédure : un collègue qui le lit sait comment la tâche se fait, et peut la refaire.

Shell, interpréteur et langage de commande

Le shell est le programme qui lit tes commandes, les interprète et lance les programmes demandés. Tu le croises dans une fenêtre de terminal, en mode interactif : tu tapes, il répond. Un script, c'est le même shell qui lit ses commandes dans un fichier au lieu de les lire au clavier.

Bash (Bourne Again Shell) est le shell par défaut des comptes utilisateurs sur Debian et Ubuntu. Debian 13 fournit Bash 5.2. Attention, /bin/sh n'est pas Bash sur Debian : c'est dash, un shell plus léger qui ne connaît pas les extensions de Bash comme [[ ]] ou les tableaux. Un script Bash doit donc être lancé par Bash, ce que garantit sa première ligne.

PowerShell ou Bash : des objets ou du texte

La vraie différence entre les deux langages n'est pas la syntaxe, c'est ce qui circule entre les commandes.

En Bash, chaque commande produit du texte. Pour récupérer une information, tu découpes ce texte : la cinquième colonne, la ligne qui contient tel mot. Voici les services en échec sur un serveur Debian :

systemctl list-units --type=service --state=failed --no-legend | awk '{print $2}'

Si l'affichage de la commande change d'une version à l'autre, le découpage casse.

En PowerShell, chaque commande produit des objets, avec des propriétés nommées. Pour récupérer une information, tu demandes la propriété par son nom. Voici les services arrêtés alors qu'ils devraient démarrer automatiquement, sur un serveur Windows :

Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } |
    Select-Object Name, DisplayName

Rien n'est découpé : Status et StartType sont des propriétés de chaque service. Le chapitre 3 détaille ce fonctionnement.

On choisit selon la cible : un script qui administre l'annuaire Active Directory s'écrit en PowerShell, un script qui sauvegarde un serveur web Debian s'écrit en Bash. PowerShell 7 tourne aussi sous Linux, mais sur un serveur Debian, Bash est déjà là, partout, et tous les collègues le lisent.

Ton premier script PowerShell

Ouvre un terminal PowerShell, crée un dossier de travail et un premier fichier. Avec Visual Studio Code, ou même le Bloc-notes, écris Bonjour.ps1 :

# Bonjour.ps1 : mon premier script
$poste = $env:COMPUTERNAME
$date  = Get-Date -Format 'dd/MM/yyyy HH:mm'
Write-Output "Bonjour $env:USERNAME, tu es sur $poste. Nous sommes le $date."

Lance-le depuis le dossier où il se trouve :

.\Bonjour.ps1

Bonjour clambert, tu es sur PC-ADMIN01. Nous sommes le 03/11/2026 09:14.

Le .\ veut dire « dans le dossier courant ». Il est obligatoire : PowerShell ne lance jamais un script du dossier courant sans lui, pour éviter qu'un fichier piégé nommé comme une commande courante soit exécuté par erreur.

Deux messages arrêtent presque tous les débutants :

Ces messages sont ceux de Windows PowerShell 5.1 sur un Windows en français. PowerShell 7 les affiche en anglais (« The term 'Bonjour.ps1' is not recognized… », « …cannot be loaded because running scripts is disabled on this system »).

Sur Windows Server, la stratégie par défaut est déjà RemoteSigned : tes scripts locaux s'exécutent, ceux téléchargés d'Internet doivent être signés. PowerShell 7 installé sous Windows démarre lui aussi en RemoteSigned : son fichier powershell.config.json, dans le dossier d'installation, fixe cette valeur.

Ton premier script Bash

Sur ton serveur ou ta machine virtuelle Debian 13, crée bonjour.sh avec un éditeur (nano bonjour.sh) :

#!/usr/bin/env bash
# bonjour.sh : mon premier script
machine=$(hostname)
date_jour=$(date '+%d/%m/%Y %H:%M')
echo "Bonjour $USER, tu es sur $machine. Nous sommes le $date_jour."

La première ligne, le shebang (#!), dit au système quel interpréteur doit lire le fichier. #!/usr/bin/env bash cherche bash dans le PATH ; #!/bin/bash donne son chemin directement. Les deux fonctionnent sur Debian. Sans shebang, le script lancé par ./bonjour.sh est lu par le shell courant, ce qui marche par hasard dans un terminal Bash et échoue ailleurs.

Rends le fichier exécutable, puis lance-le :

chmod +x bonjour.sh
./bonjour.sh

Bonjour mdiallo, tu es sur srv-web. Nous sommes le 03/11/2026 09:14.

Les messages sont en français si la langue du système est le français, en anglais sinon (Permission denied, command not found). Le cours Linux détaille les droits rwx que modifie chmod.

L'éditeur et l'encodage

Écris tes scripts dans Visual Studio Code, avec deux extensions : PowerShell (de Microsoft : coloration, autocomplétion, débogueur, analyse avec PSScriptAnalyzer) et ShellCheck (qui signale les erreurs classiques des scripts Bash). L'ancien éditeur Windows PowerShell ISE ne gère pas PowerShell 7 et n'évolue plus : Microsoft recommande VS Code.

Pour l'encodage, enregistre en UTF-8. Une seule exception, et elle mord souvent : un script .ps1 qui contient des caractères accentués et qui doit tourner dans Windows PowerShell 5.1 doit être enregistré en UTF-8 avec BOM. Sans BOM, Windows PowerShell 5.1 lit le fichier dans l'ancien jeu de caractères Windows (ANSI) et affiche « Résumé » au lieu de « Résumé ». PowerShell 7 lit correctement les deux.

Commenter et présenter un script

Un script d'administration sera relu, par toi dans six mois ou par un collègue en pleine panne. Donne-lui un en-tête qui dit ce qu'il fait, comment le lancer et ce dont il a besoin.

<#
.SYNOPSIS
    Liste les services automatiques arrêtés sur le serveur.
.DESCRIPTION
    À lancer après un redémarrage, pour vérifier que tout est reparti.
.EXAMPLE
    .\Get-ServicesArretes.ps1
.NOTES
    Auteur : Chloé Lambert, service informatique. Version 1.1, 03/11/2026.
#>

Cet en-tête n'est pas un simple commentaire : c'est l'aide intégrée du script, que Get-Help .\Get-ServicesArretes.ps1 -Full affiche comme celle d'une commande de Microsoft. En Bash, l'usage est un bloc de commentaires après le shebang, et une option -h qui affiche l'aide (chapitre 6).

Les conventions de nommage aident aussi à s'y retrouver :

Écrire un script d'administration : la méthode

Un script ne s'écrit pas d'un seul jet. Les administrateurs suivent toujours le même chemin.

1. Faire la tâche une fois à la main, en notant chaque commande qui marche.
2. Assembler ces commandes dans un fichier et le relancer sur une machine de test.
3. Remplacer les valeurs écrites en dur (nom du serveur, chemin, nombre de jours) par des variables, puis par des paramètres.
4. Gérer les erreurs : que se passe-t-il si le dossier n'existe pas, si le serveur ne répond pas, si le fichier est vide (chapitre 7) ?
5. Journaliser : écrire ce qui a été fait, et renvoyer un code de sortie qui dit si tout s'est bien passé.
6. Tester sans risque (-WhatIf en PowerShell, une option --simulation en Bash) avant de lancer pour de vrai.
7. Versionner le script avec Git (cours Git et GitHub), puis le planifier si la tâche est récurrente (chapitre 14).

Exercices

mdiallo@srv-web:~$ verif.sh
-bash: verif.sh : commande introuvable
mdiallo@srv-web:~$ ./verif.sh
-bash: ./verif.sh: Permission non accordée

/usr/bin/env: « bash\r »: Aucun fichier ou dossier de ce nom