Un script bash qui tourne sans encombre depuis cinq ans mérite-t-il vraiment d’être réécrit simplement parce qu’il est vieux ? Cette question revient régulièrement quand une nouvelle personne rejoint une équipe et découvre un fichier deploy.sh de deux cents lignes, sans commentaire, écrit par quelqu’un qui n’est plus dans l’entreprise. L’instinct pousse souvent à tout réécrire proprement. Ce n’est pourtant pas toujours la bonne réponse.
Ce qui suit ne traite pas de la réécriture elle-même, mais des signaux qui aident à décider si elle est réellement nécessaire, ou si le script mérite simplement d’être documenté et laissé tel quel.
L’ancienneté seule ne dit rien
Un script bash n’est pas soumis à des cycles de dépréciation comme une bibliothèque JavaScript ou une extension WordPress. Tant que la version de bash installée sur le serveur reste compatible avec sa syntaxe, un script de 2020 fonctionne aujourd’hui exactement comme il fonctionnait alors. L’âge d’un script, à lui seul, ne constitue donc pas un argument suffisant pour justifier une réécriture. Ce raisonnement, valable pour du code applicatif qui doit suivre l’évolution d’un langage ou d’un framework, s’applique mal à un script d’infrastructure isolé qui accomplit une tâche stable dans le temps.
La vraie question à poser n’est pas « depuis quand ce script existe-t-il ? » mais « à quelle fréquence échoue-t-il, et que se passe-t-il quand il échoue ? ».
Premier signal : les échecs silencieux
Un script bash écrit sans set -euo pipefail continue son exécution même après l’échec d’une commande intermédiaire. C’est le signal le plus sérieux à rechercher en priorité, bien avant la propreté générale du code. Un script de sauvegarde qui échoue à copier un fichier mais continue jusqu’au bout en affichant « Sauvegarde terminée » représente un risque bien plus grand qu’un script mal indenté qui s’arrête proprement dès la première erreur.
#!/usr/bin/env bash
# Version à risque : aucune erreur ne stoppe le script
cp /var/www/site/wp-content ./backup/
tar czf backup.tar.gz ./backup/
echo "Sauvegarde terminée"
# Version corrigée
#!/usr/bin/env bash
set -euo pipefail
cp /var/www/site/wp-content ./backup/
tar czf backup.tar.gz ./backup/
echo "Sauvegarde terminée"
Ce premier signal justifie à lui seul une intervention rapide, même minimale : ajouter set -euo pipefail en tête de fichier corrige souvent l’essentiel du problème sans nécessiter une réécriture complète.
Deuxième signal : la fréquence d’usage et le nombre de mains qui le touchent
Un script exécuté une fois par trimestre par une seule personne qui en connaît chaque ligne représente un risque limité, même s’il est mal écrit. À l’inverse, un script exécuté plusieurs fois par jour par toute une équipe, dont la moitié ignore ce qu’il fait exactement, mérite d’être clarifié en priorité, indépendamment de son ancienneté. La fréquence d’usage multiplie l’impact d’un défaut, là où la rareté d’exécution le dilue.
- Script rarement exécuté, une seule personne concernée : réécriture non prioritaire
- Script fréquemment exécuté par toute l’équipe : documentation ou réécriture à envisager
- Script quel qu’il soit, sans gestion d’erreur : correctif immédiat recommandé
Troisième signal : l’absence totale de documentation
Un script non commenté qui fait exactement ce que son nom indique ne pose pas de problème réel. Un script nommé fix.sh qui effectue une dizaine d’opérations sans rapport apparent entre elles en pose un beaucoup plus grand, non pas à cause de son âge, mais parce que personne ne peut prédire son comportement sans le lire intégralement ligne par ligne. Ce signal se corrige souvent par l’ajout de commentaires et d’un message d’aide, sans nécessiter de tout réécrire dans un autre langage.
Un script qu’on comprend en le lisant vaut mieux qu’un script réécrit qu’on ne comprend pas encore.
Ce qui justifie réellement une réécriture complète
La réécriture complète devient justifiée quand plusieurs signaux se cumulent : échecs silencieux, usage fréquent par plusieurs personnes, absence de documentation, et surtout un besoin fonctionnel nouveau que le script actuel ne peut pas satisfaire sans être dénaturé, par exemple gérer plusieurs environnements alors qu’il n’en gérait qu’un seul à l’origine. Réécrire un script uniquement par souci esthétique, sans que ces signaux soient présents, consomme du temps sans réduire de risque réel.
En résumé
Un script bash ancien n’est pas un problème en soi ; c’est l’absence de gestion d’erreur, la fréquence d’usage non maîtrisée et le manque de documentation qui en font un risque. Avant de planifier une réécriture, mieux vaut vérifier ces trois signaux précisément plutôt que de se fier à la seule impression d’ancienneté du fichier.
