Silverlight a officiellement perdu tout support de Microsoft, et la majorité des navigateurs modernes refusent d’exécuter ses plug-ins. Pour les entreprises qui exploitent encore des applications métier développées sur cette technologie, la question n’est plus de savoir si un changement s’impose, mais laquelle des trois options (conservation, virtualisation, migration) présente le meilleur rapport coût/risque.
Conservation, virtualisation ou migration de Silverlight : tableau comparatif
Chaque stratégie engage des ressources différentes et expose à des niveaux de risque distincts. Le tableau ci-dessous synthétise les critères décisionnels à partir des données disponibles.
| Critère | Conservation (mode IE) | Virtualisation (poste isolé) | Migration (réécriture) |
|---|---|---|---|
| Durée de viabilité | Jusqu’en 2029 (fin prévue du mode IE dans Edge) | Variable, dépend de l’OS hôte | Pérenne si la cible est maintenue |
| Exposition sécurité | Élevée (pas de correctifs Silverlight) | Moyenne (isolation réseau possible) | Faible (stack corrigée) |
| Coût initial | Quasi nul | Modéré (infrastructure dédiée) | Élevé (développement) |
| Compatibilité navigateur | Edge mode IE uniquement | Navigateur ancien encapsulé | Tous navigateurs actuels |
| Dépendance éditeur | Microsoft (préavis avant retrait) | Aucune (mais dette technique) | Nouvelle stack (.NET, Blazor, OpenSilver) |
La lecture de ce tableau fait ressortir un point net : la conservation ne fait que repousser le problème jusqu’en 2029. La virtualisation achète du temps sans réduire la dette technique. Seule la migration élimine la dépendance à un composant abandonné.
Mode IE dans Edge : une compatibilité Silverlight fragile
Microsoft Edge ne prend pas en charge Silverlight, ActiveX ni les plug-ins hérités en mode normal. Le mode IE intégré à Edge reste la seule voie pour exécuter du contenu Silverlight dans un navigateur récent.
Ce mode est annoncé comme maintenu au moins jusqu’en 2029 sur les systèmes pris en charge, avec un préavis avant tout retrait. C’est un filet de sécurité, pas une solution de migration.
Limites concrètes du mode IE
Le mode IE ne réactive pas automatiquement les anciens réglages de sécurité. Les protocoles TLS obsolètes, désactivés par défaut dans les versions récentes de Windows, peuvent rester incompatibles avec certaines dépendances anciennes de l’application Silverlight.
- Les stratégies de groupe (GPO) doivent être configurées manuellement pour chaque site interne nécessitant le mode IE, ce qui alourdit la gestion du parc.
- Aucun correctif de sécurité ne sera publié pour le plug-in Silverlight lui-même, ce qui laisse la surface d’attaque intacte même si le navigateur est à jour.
- Le mode IE ne corrige pas les failles du plug-in Silverlight, il se contente de l’exécuter dans un conteneur hérité.
Pour une application interne utilisée par quelques dizaines de personnes, ce compromis peut tenir quelques années. Pour une application exposée sur un réseau étendu ou manipulant des données sensibles, le risque résiduel devient difficile à accepter formellement.
Virtualisation d’applications Silverlight : isoler sans résoudre
La virtualisation consiste à encapsuler l’application Silverlight dans une machine virtuelle ou un environnement applicatif isolé (Azure Virtual Desktop, Citrix, poste dédié). L’objectif est de couper l’application du réseau principal tout en maintenant son accès fonctionnel.
Ce que la virtualisation apporte
L’isolation réseau réduit la surface d’attaque. Un serveur virtuel dédié peut tourner sur une version de Windows compatible avec le plug-in, sans compromettre le reste de l’infrastructure. Les équipes de gestion réseau conservent un périmètre contrôlé.
Ce que la virtualisation ne résout pas
La dette technique reste entière. L’application Silverlight ne reçoit aucune mise à jour, et chaque couche d’isolation ajoute un coût d’exploitation récurrent (licences Windows Server, maintenance de la VM, surveillance de la machine). Si l’OS hôte atteint lui aussi sa fin de support, il faut reconstruire l’environnement virtualisé, sans avoir avancé d’un pas vers la migration.
La virtualisation se justifie dans un cas précis : quand l’application Silverlight est critique et que la réécriture prend plus de douze mois. Elle sert alors de pont, pas de destination.
Migration Silverlight vers Blazor ou OpenSilver : les options actuelles
Deux chemins de migration se distinguent pour les applications Silverlight en entreprise.
OpenSilver est une réimplémentation open source de Silverlight qui fonctionne sur les navigateurs actuels via WebAssembly, sans plug-in. Développé par Userware, ce projet permet de reprendre une partie du code XAML existant et de le compiler pour le web moderne. Pour les applications dont le code source est disponible et bien structuré, OpenSilver réduit significativement le volume de réécriture.
Blazor, le framework web de Microsoft intégré à .NET, représente l’alternative native pour les équipes déjà investies dans l’écosystème Visual Studio et Azure. Blazor WebAssembly exécute du C# directement dans le navigateur, ce qui facilite la transition pour des développeurs .NET habitués à Silverlight.
Critères de choix entre OpenSilver et Blazor
- Volume de code XAML existant : OpenSilver conserve une compatibilité directe avec une partie du XAML Silverlight, ce qui accélère la reprise. Blazor impose une réécriture de l’interface en composants Razor.
- Compétences internes : si l’équipe maîtrise déjà ASP.NET Core et les services cloud Azure, Blazor s’intègre plus naturellement dans la chaîne de déploiement.
- Dépendances SQL Server ou services Windows : les deux options se connectent aux mêmes back-ends, mais Blazor bénéficie d’une documentation Microsoft plus fournie pour l’intégration avec SQL Server et Exchange.
- Pérennité : Blazor est maintenu par Microsoft dans le cadre de .NET. OpenSilver dépend de la communauté et de Userware. Le choix engage la maintenance sur plusieurs années.
Gouvernance du risque Silverlight : formaliser la décision
Au-delà du choix technique, la gestion d’un logiciel en fin de vie relève de la gouvernance du risque. Les recommandations convergent vers trois postures formelles : migrer, isoler ou accepter explicitement le risque résiduel.
Accepter le risque signifie documenter la décision, identifier les données exposées, et définir un plan de réponse en cas d’incident. Cette posture n’est viable que si l’application ne traite pas de données personnelles soumises à des obligations réglementaires strictes.
Pour les applications de gestion liées à des outils Microsoft (MIM, BHOLD), la fin de support Silverlight a des impacts directs sur certains modules. Microsoft a publié des correctifs spécifiques pour MIM 2016 afin de traiter l’impact de la fin de support Silverlight sur les modules BHOLD Suite.
La donnée qui structure la décision reste la date. Le mode IE dans Edge est garanti au moins jusqu’en 2029, ce qui fixe une échéance claire. Toute application Silverlight encore active à cette date devra avoir été migrée, virtualisée sur un environnement indépendant, ou retirée du service.
