Silverlight software n’a plus reçu de correctif de sécurité ni de mise à jour de compatibilité depuis le 12 octobre 2021, date de fin de support officielle. Supprimer le plugin d’un parc de machines ne se résume pas à lancer une commande de désinstallation. Plusieurs dépendances, registres et mécanismes de réinstallation automatique peuvent transformer l’opération en faux départ.
Inventaire des dépendances Silverlight avant désinstallation
La première étape, souvent négligée, consiste à dresser la liste exacte des applications internes qui appellent encore le runtime Silverlight. Un scan rapide des postes ne suffit pas : certaines applications web métier chargent le plugin uniquement dans des scénarios précis (génération de rapports, modules vidéo embarqués, interfaces de supervision).
Trois points méritent une vérification systématique :
- Les applications intranet hébergées sur IIS qui référencent des fichiers
.xapdans leur code source ou leurs balises<object>. - Les tâches planifiées liées à Configuration Manager, notamment la tâche Configuration Manager Health Evaluation, qui peut réinstaller Silverlight automatiquement après chaque suppression.
- Les dépendances côté navigateur : le mode IE d’Edge peut encore charger le plugin sur certaines pages, mais Microsoft ne maintient ce mode que jusqu’en 2029, ce qui en fait un sursis, pas une solution.
Sans cet inventaire, chaque désinstallation risque d’être annulée par un mécanisme de remédiation automatique ou de provoquer un dysfonctionnement applicatif non anticipé.
Registre Windows et Silverlight : clés à vérifier sur 32 et 64 bits
La détection de Silverlight passe par la lecture des ruches de registre standard. Sur un système 64 bits, deux chemins coexistent :
| Architecture | Chemin de registre |
|---|---|
| 64 bits (vue native) | HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall |
| 32 bits (Wow6432Node) | HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall |
| Système 32 bits | HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall |
Un poste peut héberger simultanément une version 32 bits et une version 64 bits du plugin. Vérifier les deux ruches est nécessaire pour éviter qu’une installation résiduelle persiste après la suppression de l’autre.
La valeur UninstallString de la clé correspondante contient soit un appel msiexec avec un GUID produit, soit un chemin vers un exécutable. Cette distinction conditionne la méthode de désinstallation silencieuse.
Désinstallation silencieuse via msiexec ou WMIC
Quand la chaîne de désinstallation pointe vers msiexec, la commande à exécuter en mode silencieux prend la forme msiexec /x {GUID} /qn /norestart. Le GUID se lit directement dans le champ PSChildName de la clé de registre.
L’alternative WMIC reste fonctionnelle : wmic product where name="Microsoft Silverlight" call uninstall /nointeractive. En revanche, si la chaîne de désinstallation pointe vers un exécutable autonome, c’est le flag /S qui déclenche le mode silencieux.
Tester la commande sur un poste isolé avant tout déploiement à grande échelle permet de valider le code de sortie et de repérer d’éventuels verrous (fichier en cours d’utilisation, service bloquant).
Durée de vie de l’OS hôte : un paramètre souvent oublié
Retirer Silverlight software d’un serveur Windows Server ne règle qu’une partie du problème si l’OS lui-même approche sa fin de support. Windows 10 LTSC 2021, par exemple, arrive en fin de cycle de mises à jour standard en 2027. Maintenir un plugin obsolète sur un système bientôt obsolète double l’exposition aux vulnérabilités.
La check-list technique doit donc inclure un croisement entre la date de fin de support de Silverlight et celle de l’OS. Migrer l’application vers une stack web moderne sur un OS en fin de vie revient à déplacer le risque sans le supprimer.
Conserver, virtualiser ou migrer : trois scénarios distincts
La conservation temporaire du plugin ne se justifie que si une application critique ne peut pas être portée avant plusieurs mois. Dans ce cas, isoler le poste concerné du réseau principal réduit la surface d’attaque.
La virtualisation (machine virtuelle dédiée, snapshot figé) offre un environnement cloisonné pour faire tourner l’application Silverlight le temps de la migration. C’est un contournement, pas une sortie durable.
Seule la migration applicative vers HTML5, Blazor ou une autre technologie web maintenue constitue une solution pérenne. Les trois options ne s’excluent pas : elles correspondent à des horizons de temps différents dans un plan de retrait progressif.
Check-list de validation post-désinstallation de Silverlight
Une fois la suppression effectuée, plusieurs contrôles confirment que le retrait est complet et stable :
- Vérifier l’absence de la clé
Microsoft Silverlightdans les deux ruches de registre (32 et 64 bits). - Contrôler que la tâche planifiée Configuration Manager Health Evaluation est désactivée ou que le fichier
ccmeval.xmlne référence plus Silverlight comme prérequis. - Ouvrir les applications web identifiées lors de l’inventaire initial pour confirmer qu’aucune page ne renvoie d’erreur liée à un plugin manquant.
- Scanner le parc avec un outil de gestion des vulnérabilités (type Nessus, plugin 58134) pour valider la disparition de l’alerte Silverlight.
- Documenter la date de retrait et l’état de chaque application dépendante pour traçabilité lors d’audits de sécurité.
Le point le plus fréquemment raté concerne la réinstallation automatique par Configuration Manager. Sans désactivation explicite de la tâche d’évaluation, Silverlight peut réapparaître sur un serveur quelques heures après sa suppression.
Retirer un plugin en fin de vie semble trivial. Dans le cas de Silverlight software, c’est l’inventaire applicatif préalable et le contrôle des mécanismes de remédiation automatique qui déterminent si la suppression tient dans le temps.
