L’année dernière, j’ai accompagné une PME textile qui perdait environ trois heures par semaine à renommer et classer manuellement des centaines de fichiers de commandes reçus de ses fournisseurs, chacun avec un format de nom différent. La solution n’a pas nécessité de logiciel coûteux, seulement un script bash de trente lignes et une explication claire de comment l’exécuter, ce qui manquait cruellement à l’équipe.
Voici donc, sans prérequis technique préalable, comment lancer un script bash sur un poste de travail, ce qu’il faut vérifier avant, et les erreurs qui bloquent le plus souvent les débutants.
Ce qu’est un script bash, en une phrase
Un script bash est un fichier texte contenant une suite de commandes que le terminal exécute automatiquement, dans l’ordre, comme si vous les tapiez vous-même une par une. Bash est le langage de commande utilisé par défaut sur la plupart des distributions Linux et sur macOS jusqu’à une période récente (remplacé par zsh par défaut depuis macOS Catalina, mais bash reste installé et utilisable).
Étape 1 : localiser ou créer le fichier
Un script bash porte généralement l’extension .sh, bien que ce ne soit pas obligatoire techniquement. Pour créer un script simple, ouvrez un éditeur de texte brut (jamais Word ou un traitement de texte qui ajoute du formatage invisible), et écrivez votre première ligne : #!/bin/bash. Cette ligne, appelée shebang, indique au système quel interpréteur utiliser pour exécuter le fichier.
Étape 2 : rendre le script exécutable
C’est l’étape que j’ai vue bloquer le plus de collaborateurs non techniques. Par défaut, un fichier texte n’a pas la permission d’être exécuté comme un programme. Dans le terminal, en étant positionné dans le dossier contenant le script, la commande est :
chmod +x nom_du_script.sh
Cette commande modifie les permissions du fichier pour autoriser son exécution. Sans cette étape, vous obtiendrez un message « Permission denied » en tentant de lancer le script.
Étape 3 : lancer le script
Deux méthodes principales, avec une nuance importante entre les deux. La première, la plus courante :
./nom_du_script.sh
Le ./ précise qu’il faut exécuter le fichier situé dans le dossier courant, ce qui est nécessaire car, pour des raisons de sécurité, le dossier courant n’est pas automatiquement inclus dans le chemin de recherche des commandes.
La seconde méthode, utile si le fichier n’a pas été rendu exécutable ou si vous voulez forcer l’interpréteur bash spécifiquement (utile sur macOS où le terminal utilise zsh par défaut) :
bash nom_du_script.sh
Ce qui a réellement résolu le problème du client textile
Pour ce client, le script final lisait chaque fichier reçu dans un dossier de commandes, extrayait la date et le nom du fournisseur depuis le nom du fichier original (souvent mal formaté), puis renommait et déplaçait le fichier vers un dossier classé par mois et par fournisseur. Le script complet tenait en trente-deux lignes, s’exécutait en moins de dix secondes sur plusieurs centaines de fichiers, et j’ai formé une collaboratrice à le lancer elle-même en quinze minutes.
Le gain mesuré après un mois : environ trois heures par semaine récupérées, soit l’équivalent d’une demi-journée de travail administratif redirigée vers des tâches à plus forte valeur.
Mais attention à ce piège fréquent
Un script mal testé peut faire des dégâts rapidement, surtout s’il manipule ou supprime des fichiers. Avant de lancer un script sur des données réelles, je teste systématiquement sur une copie du dossier concerné, jamais sur les fichiers originaux directement. J’ai vu un client perdre une après-midi entière de travail parce qu’un script de renommage en masse, mal testé, avait écrasé plusieurs fichiers portant accidentellement le même nom cible.
Deuxième piège classique : oublier de vérifier les droits d’exécution sur le serveur ou l’environnement de production, qui peuvent différer de ceux du poste de développement. Un script qui fonctionne parfaitement en local peut échouer silencieusement ailleurs si les permissions ne sont pas identiques.
Les messages d’erreur les plus fréquents chez les débutants
Trois messages reviennent systématiquement chez les personnes qui découvrent le terminal pour la première fois, et je les explique désormais dès la première formation pour éviter le découragement inutile qu’ils provoquent souvent.
command not found signifie généralement une erreur de chemin ou de nom de fichier, pas un problème plus profond. Vérifiez que vous êtes bien positionné dans le bon dossier avec la commande pwd, qui affiche le chemin courant.
Permission denied, déjà évoqué plus haut, se corrige avec chmod +x. C’est de loin le message le plus fréquent chez les nouveaux utilisateurs, et il n’indique aucun problème avec le contenu du script lui-même.
No such file or directory indique le plus souvent une faute de frappe dans le nom du fichier, ou un script lancé depuis le mauvais dossier. La complétion automatique du terminal (touche Tab) évite une grande partie de ces erreurs de frappe en complétant automatiquement les noms de fichiers existants.
Automatiser le lancement, pour aller plus loin
Une fois le script fiable et testé, il devient possible de l’automatiser complètement via une tâche planifiée (cron sur Linux et macOS), pour qu’il s’exécute à intervalle régulier sans intervention humaine. C’est une étape que je recommande seulement après plusieurs semaines d’utilisation manuelle réussie, jamais dès la première version d’un script.
Pour une référence externe, consultez le guide d’Apple sur le Terminal de macOS.
Si vous êtes dans cette situation, avec des tâches répétitives sur des fichiers ou des données structurées, je vous recommande de tester d’abord un script simple sur un cas limité avant d’envisager une automatisation complète. C’est souvent la voie la plus rapide pour une PME sans budget de développement dédié.
Pour d’autres retours techniques testés en mission, voir ma rubrique programmation et développement, et mon parcours complet.