Microsoft a mis fin au support de Silverlight le 12 octobre 2021. Les navigateurs modernes, Chrome, Firefox et Edge dans sa version standard, ne chargent plus le plugin. Des milliers d’applications métiers développées entre 2007 et 2015 tournaient sur cette technologie, et certaines sont encore en production dans des entreprises qui n’ont pas achevé leur migration. Le problème n’est plus théorique : sans action, ces outils deviennent inaccessibles.
Mode Internet Explorer dans Edge : la seule option recommandée par Microsoft
Microsoft recommande désormais le mode Internet Explorer intégré à Microsoft Edge pour les organisations qui doivent encore faire tourner des applications Silverlight. Ce mode n’est pas activé par défaut. Il nécessite une configuration via les stratégies de groupe (GPO) ou les paramètres d’entreprise d’Edge.
A lire en complément : Un smartphone facile à utiliser pour les seniors
L’administrateur définit une liste de sites autorisés à s’ouvrir en mode IE. Quand un utilisateur accède à l’une de ces URL, Edge bascule automatiquement sur le moteur de rendu d’Internet Explorer 11, qui prend en charge Silverlight. Le reste de la navigation reste sur le moteur Chromium d’Edge.
Cette approche a une date de péremption. Le mode IE d’Edge dépend du cycle de support de Windows, et Microsoft n’a pas garanti son maintien indéfini. Certaines entreprises signalent des régressions de stabilité après des mises à jour cumulatives ou des patchs mensuels, selon la version de Windows utilisée.
A lire en complément : Comment regarder la télévision française à l’étranger ?
Silverlight en entreprise : arbitrer entre migration, encapsulation et extinction
Toutes les applications Silverlight ne méritent pas le même traitement. La logique documentée par des retours d’expérience récents repose sur un croisement entre impact métier et complexité technique.
- Les applications à fort impact métier et faible complexité technique sont candidates à une migration prioritaire vers des technologies web actuelles (HTML5, Blazor, ou frameworks JavaScript).
- Les applications à faible impact et forte complexité basculent vers une encapsulation temporaire ou une extinction contrôlée, avec archivage des données.
- Les applications critiques mais très complexes justifient parfois le maintien de postes verrouillés, des machines dédiées sous Windows 10 avec IE11, isolées du réseau principal.
Ce tri suppose un inventaire exhaustif du parc applicatif Silverlight. Beaucoup d’organisations découvrent à ce stade des applications oubliées, développées par des prestataires qui n’interviennent plus, sans documentation ni code source disponible.
OpenSilver et XAML.io : réécrire sans repartir de zéro
OpenSilver est un projet open source qui permet de réutiliser du code XAML et C# existant pour produire des applications web fonctionnant sans plugin. Le principe : le code Silverlight est compilé vers WebAssembly et s’exécute dans le navigateur via le runtime .NET (Blazor). L’interface XAML est convertie en HTML et CSS.
XAML.io, développé par l’éditeur Userware (à l’origine d’OpenSilver), propose un outillage complémentaire qui cible aussi les applications WPF. L’objectif est de réduire le volume de réécriture manuelle en automatisant la conversion des composants d’interface.
Limites concrètes de la migration via OpenSilver
La compatibilité n’est pas totale. Les applications qui utilisaient des fonctionnalités spécifiques du plugin Silverlight (accès au système de fichiers local, intégration COM, certains contrôles tiers) nécessitent une réécriture partielle. Le gain se situe surtout sur la couche d’interface XAML, pas sur la logique métier liée aux API propriétaires.
Le temps réel de migration varie fortement selon la complexité du projet. Une application simple avec peu de dépendances externes peut être portée en quelques semaines. Une application métier complexe avec des contrôles tiers (Telerik, DevExpress en version Silverlight) demande un travail d’adaptation qui peut s’étendre sur plusieurs mois.
Pourquoi Silverlight a disparu des navigateurs modernes
Silverlight reposait sur un modèle de plugin NPAPI, le même que Flash. Les navigateurs ont abandonné ce modèle pour des raisons de sécurité et de performance. Chrome a supprimé le support NPAPI dès 2015. Firefox a suivi. Edge, construit sur Chromium depuis 2020, n’a jamais intégré le support des plugins classiques dans son moteur principal.
Le secteur des médias, qui représentait une part significative des usages Silverlight (streaming DRM via PlayReady), a migré vers les spécifications HTML5 : Encrypted Media Extensions et Media Source Extensions. Ces standards, développés par le W3C, permettent la diffusion en continu protégée sans plugin. Le format DASH et le chiffrement CENC (Common Encryption) ont remplacé les solutions propriétaires.
Cette transition a été rapide pour les services grand public. Elle reste incomplète dans les systèmes d’information internes, où des applications Silverlight remplissent des fonctions de saisie, de reporting ou de visualisation de données que personne n’a budgété pour réécrire.
Silverlight software : planifier la sortie plutôt que le maintien
Maintenir Silverlight en production revient à accumuler de la dette technique sur un socle que plus personne ne corrige. Aucun correctif de sécurité n’est publié depuis la fin du support. Les postes verrouillés sous IE11 deviennent des points de vulnérabilité dans le réseau. Le mode IE d’Edge apporte un sursis, pas une solution pérenne.
La stratégie la plus documentée combine trois volets : identifier le parc, classer les applications par criticité, et lancer les migrations par ordre de risque décroissant. Les applications à faible usage peuvent être éteintes après extraction et archivage des données. Les applications critiques passent par OpenSilver ou par une réécriture complète en Blazor, Angular ou React selon l’écosystème technique de l’organisation.
Le coût de la migration augmente avec le temps. Les compétences Silverlight se raréfient, les éditeurs de composants tiers ont cessé de maintenir leurs versions Silverlight, et chaque mise à jour de Windows réduit la fiabilité des solutions de contournement. Reporter la migration expose à des coûts plus élevés et à des compétences de plus en plus difficiles à mobiliser.
