Une procédure de vingt-sept clics donne vingt-sept occasions de choisir le mauvais bouton. PowerShell expose des objets .NET dans un pipeline : une commande retourne des objets avec propriétés et méthodes, la suivante les filtre ou les transforme. Le script devient une procédure qu’on peut relire, versionner et tester.

La force est aussi le danger. Un clic mal placé touche un serveur; une boucle mal filtrée peut toucher mille comptes. Je sépare découverte, plan et exécution, avec -WhatIf lorsque la commande le supporte.

Désactiver des comptes expirés sans improviser

Un flux prudent serait :

1. lire les comptes dont la date d’expiration est dépassée;
2. exclure comptes de service et liste d’exception;
3. exporter identifiant, raison et date dans un CSV;
4. faire revoir le plan;
5. exécuter sur cinq comptes avec -WhatIf;
6. désactiver par lots limités;
7. journaliser chaque succès et erreur;
8. relire l’annuaire pour vérifier le résultat.

Le pipeline pourrait ressembler conceptuellement à Get-ADUser | Where-Object | Select-Object. Je ne mets pas Disable-ADAccount avant d’avoir inspecté le résultat. Chaque filtre doit être basé sur une propriété stable, pas sur un nom partiel.

L’idempotence aide : désactiver un compte déjà désactivé ne crée pas un second effet. Pour une opération de création, le script vérifie si l’objet existe et si sa configuration correspond. Les erreurs sont capturées par objet; un échec ne doit pas rendre les 999 autres inconnus.

L’automatisation doit protéger ses privilèges

Le compte d’exécution possède seulement les droits nécessaires. Les mots de passe ne sont pas dans le .ps1 ni dans l’historique de console. Les scripts approuvés sont signés ou exécutés depuis une source contrôlée, avec version et revue. Une politique d’exécution n’est pas une frontière absolue, mais elle réduit les lancements accidentels.

Les dépendances et versions de modules sont fixées. Une commande disponible sur mon poste peut ne pas exister sur le serveur. Les environnements de test utilisent des objets représentatifs et un préfixe clair. Pour un changement destructif, une sauvegarde logique ou un script inverse est préparé.

Les logs structurés indiquent script, version, opérateur, cible, ancien état, nouvel état et corrélation. Ils excluent secrets et sont stockés ailleurs. Une alerte sur une quantité anormale d’objets protège contre le mauvais filtre.

Protéger les scripts contre la dérive d’environnement

Avant d’agir, le script vérifie version de PowerShell, modules, domaine, compte et nombre attendu de cibles. Une précondition qui échoue arrête sans modifier. Les chemins utilisent des paramètres explicites; aucune valeur de production n’est cachée dans le code. Un fichier de configuration est validé par schéma et son empreinte entre dans le log. Les commandes externes retournent un code contrôlé. Je conserverais aussi un test Pester pour les fonctions de sélection et de transformation, avec objets simulés. Cette discipline rend le script portable et empêche une procédure validée hier de prendre un autre sens parce qu’un module ou un contexte a changé.

Je commencerais toute automatisation par un mode lecture qui produit le rapport exact des changements. Une deuxième personne valide le premier gros lot. PowerShell apporte le plus de valeur lorsque le script rend l’intention et le rayon d’action plus visibles que les clics qu’il remplace.