Automatisation PowerShell : quatre scripts idempotents en production

Le contexte

Sur une infrastructure d'une dizaine de machines, presque toutes les tâches répétitives peuvent être faites à la main. C'est justement le problème : on ne mesure l'intérêt d'un script qu'à partir du moment où le nombre de machines rend la tâche pénible — et à ce moment-là, il est trop tard pour l'écrire proprement.

J'ai donc choisi d'automatiser dès le lab, en me donnant une contrainte : aucun script isolé fait pour la démonstration. Chacun devait résoudre un vrai besoin, dans un contexte d'exécution différent.

Le principe directeur : l'idempotence

C'est la seule propriété non négociable que je me suis imposée. Un script idempotent produit le même résultat qu'il soit exécuté une fois ou vingt fois.

Concrètement, cela signifie qu'avant chaque action, le script vérifie si l'état cible est déjà atteint. S'il l'est, il n'agit pas et le signale. S'il ne l'est pas, il agit.

Pourquoi c'est central ? Parce qu'un script de démarrage s'exécute à chaque démarrage. Un script de post-déploiement peut être relancé après un échec partiel. Un script d'administration est souvent rejoué après correction d'une erreur de saisie. Sans idempotence, la seconde exécution crée des doublons, écrase une configuration ou provoque une erreur bloquante.

Trois autres règles appliquées partout : journalisation horodatée dans un fichier, gestion d'erreur explicite par bloc try/catch plutôt que par arrêt brutal, et aucune valeur d'environnement codée en dur lorsqu'elle peut être découverte à l'exécution.

Les quatre scripts

1. Installation de l'agent de supervision

Contexte d'exécution : script de démarrage déclenché par stratégie de groupe, déposé sur le partage NETLOGON du contrôleur de domaine. S'exécute avec les droits système, sans utilisateur connecté.

Le script teste la présence de l'agent. S'il est déjà installé, il s'arrête immédiatement — ce qui est le cas à 99 % des démarrages. Sinon il installe le paquet MSI en mode silencieux, en désactivant explicitement la création de règle de pare-feu par l'installeur.

Ce dernier point est le plus intéressant du script : le pare-feu est géré par la stratégie de groupe, avec une règle qui n'ouvre le port de l'agent qu'à la seule adresse du serveur de supervision. Laisser l'installeur créer sa propre règle, plus permissive, aurait annulé cette restriction.

Résultat : une machine jointe au domaine est supervisée dès son premier démarrage, sans aucune intervention.

2. Post-déploiement de poste

Contexte d'exécution : snapin FOG, exécuté après un déploiement d'image, sur une machine fraîchement installée qui n'est pas encore dans le domaine.

C'est le script le plus dense, parce que son environnement d'exécution est le moins prévisible.

• Détection de l'interface réseau active par la route par défaut, plutôt que par un nom d'interface codé en dur. Le nom d'une carte réseau dépend du matériel ; la route par défaut désigne toujours celle qui porte le trafic.
• Désactivation de DHCPv6 et bascule du DNS vers le contrôleur de domaine.
• Vérification de la présence des enregistrements de service du domaine avant de tenter la jonction. On ne lance pas une opération dont on peut savoir à l'avance qu'elle échouera — et en cas d'échec, le journal indique pourquoi plutôt que de renvoyer un code d'erreur générique.
• Activation du Bureau à distance par référence à la règle système plutôt que par son nom affiché, pour rester indépendant de la langue de l'installation. Un script qui cherche « Bureau à distance » échoue sur un Windows anglais.
• Synchronisation horaire conditionnée à l'appartenance effective au domaine — inutile et contre-productif de la lancer sur une machine encore en groupe de travail.
• Réglages d'alimentation.

Trois versions successives ont été nécessaires. Les deux premières fonctionnaient sur ma machine de test et échouaient en déploiement réel, pour des raisons d'environnement que je n'avais pas anticipées.

3. Création de comptes en masse depuis un fichier CSV

Contexte d'exécution : administration manuelle, lancé ponctuellement par un administrateur.

Le script lit un référentiel CSV à séparateur point-virgule — le format que produit Excel en configuration française, choisi pour que le fichier soit modifiable par une personne non technique. Pour chaque ligne : création du compte dans l'unité d'organisation appropriée, affectation au groupe global correspondant au service, journalisation.

L'idempotence prend ici tout son sens : relancé après ajout de trois lignes au fichier, le script crée les trois nouveaux comptes et signale simplement les existants. On ne maintient pas deux fichiers, un pour la création initiale et un pour les ajouts — le CSV est le référentiel, point.

Validé sur huit utilisateurs répartis sur trois services.

4. Provisionnement d'utilisateurs de test

Variante du précédent, dédiée à la génération de comptes de démonstration pour valider l'isolation des droits sur le serveur de fichiers.

Pourquoi ils ne font pas la même chose

Le point que je considère comme le plus démonstratif de cet ensemble : ces scripts ne sont pas quatre variantes du même exercice. Ils s'exécutent dans trois contextes techniquement différents, avec des contraintes opposées.

	Agent de supervision	Post-déploiement	Comptes AD
Déclencheur	Démarrage machine (GPO)	Fin de déploiement (snapin)	Manuel
Utilisateur connecté	Aucun	Session automatique en cours	Administrateur
Machine dans le domaine	Oui	Non — il l'y met	Oui
Fréquence	À chaque démarrage	Une fois par poste	Ponctuelle
Enjeu principal	Ne rien faire la plupart du temps	Survivre à un environnement inconnu	Ne pas créer de doublons

Un script de démarrage doit être silencieux et rapide : il s'exécute des centaines de fois et ne doit rien faire dans la quasi-totalité des cas. Un script de post-déploiement doit être défensif : il tourne sur une machine dont il ne connaît ni le nom d'interface, ni la langue, ni l'état réseau. Un script d'administration doit être lisible et rejouable : quelqu'un d'autre doit pouvoir le relire et comprendre ce qu'il fait avant de le lancer en production.

Le résultat

Quatre scripts en fonctionnement réel sur l'infrastructure, tous idempotents, journalisés et validés par exécutions répétées. Aucun n'a été écrit pour l'exercice : chacun a remplacé une tâche que j'aurais dû faire à la main sur chaque machine.

Ce que j'en retiens

Écrire un script qui fonctionne prend une heure. Écrire un script qui fonctionne la deuxième fois, sur une autre machine, dans un environnement qu'on ne contrôle pas, prend beaucoup plus.

Les trois versions du script de post-déploiement l'illustrent bien : ce n'est pas la logique métier qui a posé problème, mais les hypothèses implicites sur l'environnement — un nom d'interface, une langue d'installation, une session ouverte. Ce sont ces hypothèses, jamais écrites nulle part, qui font échouer un script en production.