Scripts d'automatisation : les règles qui tiennent en production

Un traitement planifié finit toujours par être relancé : après une coupure réseau, un délai dépassé ou une intervention manuelle. S'il crée un doublon ou applique deux fois la même modification à chaque relance, personne n'osera plus y toucher.

Un script idempotent vérifie l'état avant d'agir : il crée la ressource si elle n'existe pas, il la met à jour sinon, et il ne fait rien quand l'état voulu est déjà atteint. La deuxième exécution doit laisser le système exactement dans l'état où la première l'a mis.

Planificateurs et pipelines ne lisent pas les messages, ils lisent le code de sortie : 0 pour un succès, toute autre valeur pour un échec. Un script qui affiche une erreur puis se termine en 0 est considéré comme réussi, et la panne passe inaperçue.

Faites échouer le script à la première erreur — set -euo pipefail en Bash, $ErrorActionPreference = 'Stop' en PowerShell — et écrivez un journal horodaté : ce qui a été lu, ce qui a été modifié, ce qui a été ignoré. Une option de simulation, qui affiche les actions sans les exécuter, rend chaque évolution vérifiable avant de toucher à la production.

Jetons d'API, mots de passe et clés n'ont pas leur place dans le code, même dans un dépôt privé : ils se lisent depuis des variables d'environnement ou le coffre de secrets de la plateforme d'exécution. Un secret committé doit être considéré comme compromis et révoqué, pas seulement effacé de l'historique.

Côté données, la plupart des scripts dialoguent avec des API en JSON. Valider la structure reçue avant de s'en servir, et traiter explicitement les codes de réponse HTTP — une limitation de débit ne se gère pas comme une erreur d'authentification — évite les échecs silencieux.