Déployer et maintenir des postes de travail

Je prépare, teste et déploie des mises à jour Windows à l'aide de WSUS

Les postes clients, dernier maillon de votre mission

Vous intervenez pour le compte de DKTOYS, société familiale de distribution de jouets installée à Dunkerque depuis cinquante ans, qui a ouvert depuis peu une activité de vente en ligne. L'équipe informatique y est réduite à deux personnes — un responsable et un technicien d'assistance — pour une centaine de salariés répartis entre le commercial, l'administration et l'entrepôt. Les serveurs et l'infrastructure réseau viennent d'être remis à niveau ; il reste maintenant le poste le plus visible pour les utilisateurs et le plus consommateur de temps pour une petite équipe : les postes clients.

Sur un parc de cette taille, chaque ordinateur configuré pour aller chercher lui-même ses mises à jour sur Internet pose deux problèmes concrets. D'abord la bande passante : autant de postes, autant de téléchargements individuels des mêmes fichiers. Ensuite, et surtout, le risque métier : une mise à jour Windows appliquée sans contrôle peut redémarrer un poste en pleine journée, modifier un comportement dont dépend une application de gestion commerciale, ou introduire une régression que personne n'a vue venir. Avec une équipe de deux personnes, DKTOYS ne peut pas se permettre de découvrir un incident de ce type sur l'ensemble du parc en même temps.

C'est exactement le rôle de WSUS (Windows Server Update Services) : reprendre la main sur ce qui, par défaut, échappe à l'administrateur.

Ce que WSUS change par rapport à Windows Update seul

Sans WSUS, chaque poste dialogue directement avec les serveurs Microsoft Update sur Internet, télécharge et applique les mises à jour selon son propre calendrier, sans que l'équipe informatique ait un mot à dire sur le moment ni sur le contenu.

WSUS introduit un intermédiaire entre Internet et le parc : c'est un rôle de Windows Server qui se synchronise avec le catalogue Microsoft Update, télécharge les mises à jour une seule fois sur le réseau de l'entreprise, puis les distribue en interne. Cette synchronisation ne récupère pas tout indistinctement : vous choisissez les produits concernés (les versions de Windows réellement présentes sur le parc DKTOYS, pas la totalité du catalogue Microsoft) et les classifications à suivre.

Ce contrôle a une contrepartie : WSUS ne sert à rien si personne ne surveille la synchronisation ni les rapports de conformité. C'est un outil qui remplace le pilotage automatique de Windows Update par un pilotage manuel — précisément ce que demande un contexte où une mise à jour mal absorbée peut immobiliser un poste de vente en ligne.

Trier les mises à jour par classification

Toutes les mises à jour publiées par Microsoft ne présentent pas le même niveau d'urgence. WSUS permet de synchroniser sélectivement par classification, ce qui évite de traiter une correction de sécurité urgente et une nouveauté cosmétique de la même façon :

Cette hiérarchisation évite un écueil fréquent : vouloir tout approuver en une seule fois, au risque de perdre la capacité à identifier précisément quelle mise à jour serait responsable d'un dysfonctionnement constaté après coup.

Un LAB avant la production

Avant de toucher au parc réel de DKTOYS, la démarche recommandée consiste à construire un environnement de test (LAB) séparé de la production : un serveur WSUS et un ou plusieurs postes clients virtualisés, isolés du réseau de l'entreprise. Le déploiement de mise à jour étant une opération critique — une régression touche potentiellement tous les postes en même temps — ce LAB permet de préparer et de répéter la procédure sans aucun risque pour l'activité de l'entreprise.

C'est dans ce LAB que vous installez le rôle WSUS sur un serveur Windows Server, puis lancez une première synchronisation : le serveur contacte Microsoft Update, télécharge la liste des mises à jour disponibles pour les produits sélectionnés, et les stocke localement.

Le poste pilote : tester avant d'approuver

Une fois les mises à jour synchronisées, elles restent dans un état « non approuvées » : WSUS les a téléchargées, mais aucun poste ne les recevra tant qu'un administrateur ne les a pas explicitement validées. C'est ce mécanisme d'approbation qui porte tout l'intérêt de l'outil.

La pratique consiste à préparer un poste modèle, représentatif d'une configuration du parc DKTOYS, et à lui appliquer en premier les mises à jour à valider — en commençant par les mises à jour critiques, celles qui corrigent des failles de sécurité activement exploitées et qui ne doivent jamais être repoussées indéfiniment. Ce poste pilote sert à vérifier plusieurs points avant toute diffusion élargie :

• qu'aucune application métier ne se comporte différemment après l'installation ;
• qu'aucun périphérique ne perd son pilote ou sa configuration ;
• qu'aucun redémarrage inattendu ne vient perturber l'utilisateur en pleine activité ;
• que le temps d'installation reste compatible avec une intervention en dehors des heures de forte activité.

Ce n'est qu'après cette vérification que l'approbation est étendue au reste du groupe concerné.

Le module PowerShell UpdateServices, installé avec le rôle, permet d'automatiser cette approbation plutôt que de cliquer une à une les mises à jour dans la console WSUS :

# Récupérer les mises à jour critiques encore non approuvées
$maj = Get-WsusUpdate -Approval Unapproved -Classification Critical

# Les approuver pour installation sur le seul groupe pilote
Approve-WsusUpdate -Updates $maj -Action Install -TargetGroupName "Postes-Pilotes"

Get-WsusUpdate filtre les mises à jour selon leur état d'approbation et leur classification ; Approve-WsusUpdate déclenche l'installation, mais uniquement pour le groupe ciblé — ici Postes-Pilotes — pour ne jamais approuver directement sur l'ensemble du parc DKTOYS. Une fois la validation confirmée sur ce groupe, la même commande, pointée vers un groupe de production, étend l'approbation au reste du parc.

Cette logique répond directement à la contrainte de DKTOYS : avec deux personnes seulement pour tout le parc informatique, un incident généralisé causé par une mise à jour non testée représenterait une charge de travail que l'équipe ne pourrait pas absorber dans l'urgence.

Cibler les postes avec une stratégie de groupe

Reste une question pratique : comment chaque poste sait-il qu'il doit s'adresser au serveur WSUS plutôt qu'à Internet, et comment sait-il à quel groupe de test ou de production il appartient ? C'est le rôle de la stratégie de groupe (GPO), le même mécanisme que celui utilisé pour distribuer des configurations à l'ensemble d'un domaine Active Directory.

Une GPO appliquée aux postes du domaine DKTOYS indique l'adresse du serveur WSUS interne comme source de mises à jour, et rattache chaque poste à un groupe WSUS correspondant à sa fonction :

• un groupe pilote restreint, composé du ou des postes modèles utilisés pour valider chaque nouvelle mise à jour ;
• un ou plusieurs groupes de production, correspondant aux différents services de l'entreprise (commercial, administration, entrepôt), qui ne reçoivent une mise à jour qu'une fois celle-ci validée sur le groupe pilote.

C'est cette combinaison qui permet d'approuver une mise à jour pour le seul groupe pilote, de vérifier son comportement, puis d'étendre l'approbation aux autres groupes en toute confiance, sans jamais revenir à une situation où les postes se mettent à jour chacun de leur côté.

Suivre la conformité du parc dans la durée

L'approbation d'une mise à jour n'est pas la fin de la démarche : encore faut-il vérifier qu'elle a bien été installée sur chaque poste du groupe visé, et non simplement approuvée côté serveur. WSUS remonte, pour chaque poste et chaque mise à jour, un état d'installation consultable par l'administrateur : installée avec succès, en attente, ou en échec. C'est cette remontée qui permet de détecter un poste qui n'aurait pas redémarré depuis plusieurs jours, ou une mise à jour qui échouerait systématiquement sur un modèle de matériel particulier — deux situations qu'aucune approbation, à elle seule, ne permet de repérer.

Un serveur WSUS demande également un minimum d'entretien : les mises à jour synchronisées s'accumulent avec le temps, y compris des versions devenues obsolètes une fois remplacées par une version plus récente. Sans nettoyage périodique, l'espace disque occupé par ces mises à jour superflues finit par croître inutilement — une tâche de maintenance simple, mais à ne pas oublier une fois l'infrastructure en place.

Ce que les sources ne couvrent pas : l'ensemble de ce chapitre

Les sources déclarées pour ce chapitre (3 - MAINTENANCE, EVOLUTION & SECURISATION.docx et data_module_3_maintenance_evolution_securisation.md) sont le brief de mission de DKTOYS : elles fixent l'objectif (contrôler les mises à jour avec WSUS, tester sur un poste pilote, déployer par GPO) sous forme de scénario, sans fournir la moindre procédure technique, capture d'écran ou commande. L'ensemble du contenu technique de ce chapitre — installation du rôle, classifications, mécanisme d'approbation, ciblage par GPO, suivi de conformité, cmdlets PowerShell — provient donc de connaissances professionnelles générales sur WSUS, au-delà du brief.

Ce qu'il faut retenir

WSUS ne remplace pas Windows Update : il en reprend le pilotage. Synchroniser les produits et classifications utiles au parc, hiérarchiser les mises à jour selon leur urgence, tester sur un poste pilote avant toute diffusion large, approuver par groupe via une GPO qui rattache chaque poste au bon périmètre, puis suivre la conformité réelle de l'installation — cette séquence transforme une mise à jour Windows, potentiellement risquée sur un parc géré par une équipe réduite, en une opération maîtrisée et réversible. C'est la première brique du sous-module « Services de déploiement » chez DKTOYS ; le chapitre suivant s'attaque à un autre irritant du quotidien : l'installation elle-même des postes, avec WDS et MDT.