Comparatif

BAT, SH, PS1 : quel langage de script choisir pour automatiser une tâche

Portabilité, richesse du langage, disponibilité par défaut : ce qui distingue le script batch Windows, le shell Unix et PowerShell, et dans quel cas privilégier chacun.

Ces trois formats de script s’opposent moins sur leurs qualités intrinsèques que sur l’environnement pour lequel chacun a été conçu : le choix découle presque toujours du système cible, avant toute considération de confort d’écriture.

FormatSystème natifRichesse du langageGestion d'erreursMeilleur usage
BATWindows (tous, sans installation)MinimaleSommaireAutomatisation Windows très simple, compatibilité maximale
SHUnix/Linux/macOS (tous, sans installation)Riche (avec les utilitaires GNU)Correcte (set -e, trap)Serveurs Linux, scripts de build, CI/CD
PS1Windows (natif depuis Windows 7), Linux/macOS via PowerShell 7Très riche (objets .NET)Structurée (try/catch)Administration Windows moderne, traitement de données structurées

Le BAT est disponible sur toutes les versions de Windows sans rien installer, ce qui en fait le choix le plus universellement portable pour une tâche Windows très simple (lancer un programme, copier des fichiers, définir des variables d’environnement). Son langage reste cependant minimal : pas de structures de données au-delà de variables texte, une gestion d’erreurs sommaire, et une syntaxe réputée peu lisible dès que la logique se complexifie : un script BAT de plus d’une trentaine de lignes devient vite difficile à maintenir.

Le SH est l’équivalent Unix/Linux/macOS du BAT côté disponibilité par défaut, mais avec un langage nettement plus expressif une fois combiné aux utilitaires GNU standards (grep, sed, awk, find) : c’est le choix par défaut pour scripter un serveur Linux, un pipeline d’intégration continue, ou toute tâche qui doit tourner dans un conteneur ou une image système minimale sans dépendance supplémentaire à installer. Sa syntaxe reste cependant sensible aux variations entre interpréteurs (bash, dash, zsh), ce qui peut introduire des surprises si le shebang en tête de script n’est pas explicite.

Le PS1 de PowerShell manipule des objets structurés (pas seulement du texte), avec un accès direct aux API .NET et une gestion d’erreurs proche des langages de programmation modernes (try/catch, types typés) : c’est le choix le plus robuste pour de l’administration Windows au-delà de la simple ligne de commande : gestion d’Active Directory, traitement de fichiers CSV/JSON, appels à des API web. PowerShell 7, multiplateforme, réduit l’écart de disponibilité avec le SH, mais reste moins universellement préinstallé que bash sur un serveur Linux typique, et son exécution est bridée par défaut sur Windows (politique d’exécution à ajuster pour lancer un script non signé).

Choisir BAT pour une tâche Windows minimaliste sans aucune dépendance, SH pour tout ce qui tourne sous Unix/Linux/macOS ou dans un pipeline CI/CD, PS1 dès qu’une tâche Windows dépasse la simple séquence de commandes et gagne à manipuler des données structurées plutôt que du texte brut.

Voir les fiches techniques complètes →

Formats concernés

Catégories concernées

Voir aussi

Questions fréquentes

Un script .sh fonctionne-t-il tel quel sous Windows ?

Non, pas nativement : il faut un environnement compatible (WSL, Git Bash, Cygwin) pour l'exécuter, l'interpréteur shell natif de Windows n'étant ni l'Invite de commandes ni PowerShell.

Peut-on faire la même chose en BAT qu'en PowerShell ?

En théorie souvent oui pour des tâches simples, mais le BAT manque de structures de données modernes (objets, tableaux), d'une gestion d'erreurs fine et de l'accès direct aux API .NET que PowerShell offre nativement ; au-delà de quelques commandes, un script BAT devient vite plus fragile et plus verbeux.

Sources

Dernière mise à jour :