Écrire des scripts d'administration idempotents : vérifier avant de modifier, fichiers drop-in et commentaires de repère

Objectif

Rendre un script d'administration sûr à relancer : l'appliquer deux fois produit le même état final que l'appliquer une seule fois, sans ligne dupliquée, sans réinstallation répétée de paquets et sans erreur à la seconde exécution.

Prérequis

Un accès en lecture à l'état actuel de tout ce que le script modifie (fichier, paquet, clé de registre, service) ; un moyen d'écrire des fichiers de façon atomique (écriture dans un chemin temporaire, puis déplacement/renommage).

Étapes

1. Vérifier avant de modifier. Avant d'ajouter une ligne, de créer un utilisateur ou d'installer un paquet, déterminer s'il existe déjà et comparer à la valeur souhaitée. En bash : grep -qxF -- "$line" "$file" || printf '%s\n' "$line" >> "$file". En PowerShell : if (-not (Get-LocalUser -Name $name -ErrorAction SilentlyContinue)) { New-LocalUser $name ... }. Ne rien changer du tout lorsque la vérification correspond déjà ; ne pas compter sur le fait que la commande sous-jacente échoue proprement en cas de répétition.
2. Préférer un fichier drop-in à l'édition d'un fichier partagé. Lorsque la cible le permet (les unités systemd lisent un répertoire drop-in <name>.d/*.conf et fusionnent ces fichiers, selon les termes du manuel, "in the alphanumeric order" après l'unité principale ; sudoers lit /etc/sudoers.d/* ; de nombreux démons lisent un répertoire include), écrire ou remplacer son propre fichier complet au lieu de rechercher et modifier celui de quelqu'un d'autre. Relancer le script n'écrase alors que ce fichier, sans jamais accumuler de modifications en double dans un fichier dont on n'est pas propriétaire. Un drop-in systemd ne prend effet qu'après systemctl daemon-reload ; un drop-in sudoers doit passer visudo -cf <file> avant d'être placé à son emplacement définitif, car une erreur de syntaxe peut empêcher tout le monde d'utiliser sudo, et les fichiers dont le nom contient un point sont ignorés.
3. Lorsqu'il faut éditer un fichier partagé, délimiter la modification par des commentaires de repère. Encadrer le bloc dont on est propriétaire par des repères reconnaissables, par exemple # BEGIN managed-by-agent-x / # END managed-by-agent-x, et à chaque exécution remplacer tout ce qui se trouve entre les repères au lieu d'ajouter à la suite. La modification reste ainsi idempotente et peut être retirée proprement.
4. Écrire le nouveau contenu dans un fichier temporaire, puis le renommer à sa place (mv sous POSIX ; Move-Item -Force après Set-Content -Path $tmp sous Windows, où l'atomicité n'est pas garantie) plutôt que d'éditer sur place, afin qu'une exécution interrompue en cours d'écriture ne laisse pas une configuration à moitié écrite. Créer le fichier temporaire dans le répertoire de la cible (un renommage n'est atomique qu'au sein d'un même système de fichiers) et définir le propriétaire et les permissions avant le renommage : mktemp crée les fichiers avec le mode 0600.
5. Conditionner les étapes destructrices au résultat de la vérification, et non à une « première exécution ». Un marqueur de première exécution peut diverger de l'état réel (modification manuelle, exécution partiellement échouée) ; c'est la cible elle-même qu'il faut tester.
6. Journaliser ce qui a changé et ce qui était déjà correct, afin que le journal d'une nouvelle exécution indique clairement « 0 changes made » au lieu d'avoir le même aspect que celui d'une première exécution réussie.

Résultat attendu

Exécuter le script N fois laisse le même état final qu'une seule exécution ; le journal d'une exécution répétée montre des vérifications sans effet plutôt que des écritures répétées ; une exécution partiellement échouée peut simplement être relancée.

Limites et base de vérification

L'idempotence couvre les écritures du script lui-même ; elle ne protège pas contre un autre processus ou un autre administrateur qui modifierait simultanément le même fichier — il faut l'associer au pattern de verrouillage pour les exécutions concurrentes. L'édition par commentaires de repère ne fonctionne que pour les formats texte où l'ajout de commentaires est sans risque ; pour les formats binaires ou de configuration à schéma strict, c'est l'approche drop-in qu'il faut utiliser.