SUP-01 — Automatisation des interventions et diagnostics Windows avec PowerShell

Résumé

SUP-01 transpose en une trousse PowerShell de démonstration les activités de support et d’administration Windows que j’ai exercées au Ministère de la Cybersécurité et du Numérique du Québec et à La Poste du Burkina Faso : installations silencieuses, vérification de versions applicatives, inventaire des logiciels, application de correctifs et développement de scripts de remédiation. La trousse automatise les contrôles de premier niveau N2/N3 — connectivité, services, journaux, SCCM/MECM et Windows Update — et restitue des résultats structurés dans un rapport HTML. Elle est volontairement en lecture seule : elle diagnostique et recommande, mais n’applique jamais de correction sans validation humaine.

Contexte métier et technique

Dans un parc Windows administré avec Active Directory et SCCM/MECM, un incident poste n’est presque jamais une seule question. Un utilisateur peut signaler qu’une application ne se déploie pas, qu’un correctif manque ou qu’un poste ne répond plus. Derrière ce symptôme peuvent se cacher une perte de connectivité, WinRM fermé, un service arrêté, un client SCCM non assigné à son point de gestion, une stratégie Windows Update injoignable ou une version applicative non conforme.

Le problème du support N2/N3 n’est donc pas l’absence de commandes : c’est leur dispersion et l’absence de trace homogène. SUP-01 organise les vérifications dans un ordre de diagnostic, retourne le même format de résultat pour chaque contrôle et produit un rapport joignable à un billet.

Objectifs d’automatisation

• Réduire les contrôles manuels répétés à une séquence lisible et reproductible.
• Distinguer un poste injoignable d’un contrôle réellement en échec grâce au statut Ignore.
• Vérifier les prérequis d’accès avant d’interroger un poste distant.
• Inventorier les logiciels et comparer leurs versions à une version minimale attendue.
• Diagnostiquer les éléments qui empêchent un client SCCM/MECM de recevoir ses politiques ou ses déploiements.
• Produire une restitution exploitable par le support, sans divulguer de mots de passe ni déclencher de remédiation destructive.

Problématiques de support N2/N3 couvertes

Responsabilités réellement exercées

• Installations silencieuses d’applications.
• Vérification des versions applicatives.
• Inventaire des logiciels.
• Application de correctifs.
• Développement de scripts de remédiation.

Ces réalisations constituent le socle métier de SUP-01. La trousse de démonstration ne prétend pas être le script de production utilisé chez ces organisations ; elle rend visible la méthode : prérequis, collecte contrôlée, résultats lisibles, recommandations et traçabilité.

Architecture logique

Conditions d’accès et sécurité

1. L’opérateur ouvre une session PowerShell élevée avec un compte autorisé.
2. Active Directory authentifie ce compte ; aucun mot de passe n’est inscrit dans le code ou dans un fichier de journal.
3. Le compte doit être administrateur local du poste cible — idéalement par un groupe AD dédié, plutôt que par une attribution individuelle.
4. WinRM / PowerShell Remoting doit être activé et autorisé par pare-feu. Le port 5985 est le cas courant dans un réseau interne de confiance ; le port 5986 est à privilégier lorsqu’une configuration HTTPS est exigée.
5. La trousse lit les informations ; elle ne modifie ni les services, ni les stratégies, ni les règles de pare-feu.

Processus de diagnostic

Démonstration technique : Windows-Support-Toolkit

Le dépôt local est prêt à être publié : C:\Users\Utilisateur\Documents\Windows-Support-Toolkit.

Lien GitHub à compléter après publication : Windows-Support-Toolkit

# Menu interactif, poste local
.\Invoke-SupportToolkit.ps1

# Diagnostic ciblé et rapport associé à un billet
.\Invoke-SupportToolkit.ps1 -ComputerName PC-0042 `
  -Check Connectivite,Services,SCCM `
  -Context 'INC0012345'

# Campagne en lecture seule, sur des postes autorisés
.\Invoke-SupportToolkit.ps1 `
  -ComputerName (Get-Content .\postes.txt) `
  -Check Tous `
  -Credential (Get-Credential)

Fonctions incluses

Capture d’exécution et rapport d’exemple

Le rapport d’exemple est généré à partir de données de laboratoire fictives : postes PC-0042 et PC-0043, domaine LABO, adresses 192.0.2.0/24 réservées à la documentation. Aucun nom de poste, compte ou adresse de mon environnement réel n’est publié.

Réalisations techniques de la démonstration

• Module compatible PowerShell 5.1 et PowerShell 7, sans dépendance externe.
• Dix fonctions documentées, commentées et organisées une par fichier.
• Vérification systématique des prérequis ; un poste inaccessible retourne un état exploitable au lieu d’une exception brute.
• Format Wst.Resultat commun à tous les contrôles : ordinateur, contrôle, statut, résumé, détails, recommandations et horodatage.
• Inventaire applicatif fondé sur le registre — et non Win32_Product, dont l’interrogation peut déclencher une reconfiguration MSI.
• Rapport HTML autonome avec échappement des contenus, pour éviter qu’un message de journal ne casse le rendu.
• Journalisation des opérations, sans mot de passe ni donnée de démonstration réelle dans le dépôt.
• Exécution réelle validée localement : import du module, les dix fonctions, génération du rapport fictif et vérification de sa reproductibilité.

Compétences démontrées

Résultats vérifiables

• Dépôt Git local indépendant créé avec un commit initial : Windows-Support-Toolkit.
• 10 fonctions PowerShell exportées ; syntaxe de tous les scripts validée par le parseur PowerShell.
• Contrôles exécutés en lecture seule sur le poste local de laboratoire : connectivité, services, journaux, inventaire, client SCCM, journaux SCCM, Windows Update et comparaison de version.
• Rapport HTML fictif généré deux fois avec le même hachage SHA-256 : résultat reproductible.
• Aucun gain de productivité chiffré n’est revendiqué : il dépendrait du parc, des droits, du niveau de maturité SCCM et du processus de support.

Captures et documentation technique

Les schémas, le README et le rapport HTML d’exemple constituent la documentation de démonstration. Avant une publication GitHub, remplacer l’URL [À-COMPLÉTER] par votre identifiant GitHub ; aucune donnée d’organisation ne doit être ajoutée au dépôt.