Le support officiel de Silverlight a pris fin le 12 octobre 2021. Aucun correctif de sécurité, aucun patch de compatibilité ne sera plus livré par Microsoft. Pour les équipes IT qui font encore tourner des applicatifs métiers sur ce runtime, la question en 2026 n’est plus de maintenir Silverlight mais de planifier sa sortie, application par application, sans casser la production.
Matrice de décision Silverlight : encapsuler, virtualiser, réécrire ou éteindre
Chaque application Silverlight encore en production mérite une analyse individuelle. Appliquer la même stratégie à un formulaire de saisie interne et à un portail client exposé sur Internet revient à traiter un rhume et une fracture ouverte avec le même protocole.
A lire aussi : Windows 7 A Télécharger en français : guide sûr et légal 2026
Nous recommandons de classer chaque applicatif selon trois axes : la criticité métier (l’application bloque-t-elle un processus de production ou de facturation ?), le périmètre d’exposition (intranet verrouillé ou accès externe multi-navigateur) et la complexité fonctionnelle (nombre d’écrans, intégrations WCF/RIA Services, logique métier côté client).
Quatre scénarios de sortie Silverlight
- Encapsulation via navigateur embarqué : on conserve le binaire Silverlight tel quel, exécuté dans une instance IE11 encapsulée (par exemple via un wrapper Chromium avec le mode IE intégré à Edge). Cette approche fonctionne pour les outils internes à faible trafic, sans contrainte de sécurité réseau. Elle ne protège pas contre les vulnérabilités du plugin.
- Virtualisation du poste de travail : une image Windows avec IE11 et le runtime Silverlight 5.1 est distribuée via une infrastructure de bureaux virtuels. Les utilisateurs accèdent à l’application dans un environnement isolé. Le coût de licences et d’infrastructure grimpe, mais l’applicatif reste fonctionnel sans modification de code.
- Réécriture vers Blazor, Angular ou un framework .NET moderne : la seule option qui supprime la dette technique à la racine. Le coût dépend du volume de logique métier embarquée côté XAML et des services WCF à migrer vers des API REST ou gRPC.
- Extinction pure : si l’application n’a plus d’utilisateurs actifs ou si son processus métier a été absorbé par un autre outil, on coupe. Avant cela, un audit d’usage réel (logs IIS, télémétrie réseau) permet de confirmer que personne ne s’en sert.
A découvrir également : Entreprises, pourquoi recourir aux services d’une équipe d’experts en informatique ?
Contraintes de navigateur et de poste de travail en 2026
Le plugin Silverlight n’est compatible avec aucun navigateur moderne. Chrome l’a abandonné, Firefox également, et même Internet Explorer 11 n’est plus livré en tant que navigateur autonome sur Windows 11. Seul le mode IE intégré à Microsoft Edge maintient une compatibilité résiduelle, et sa pérennité dépend de la politique de Microsoft, qui n’a aucune obligation de le prolonger indéfiniment.
Sur les postes macOS, la situation est encore plus verrouillée. Apple n’autorise plus les plugins NPAPI depuis plusieurs années. Un poste Mac ne peut tout simplement pas exécuter Silverlight sans une couche de virtualisation Windows.
Le vrai risque pour les entreprises ne se limite pas au navigateur. Il concerne aussi la surface d’attaque. Un runtime dont les failles ne sont plus corrigées, exécuté dans un navigateur en fin de vie, représente un vecteur d’intrusion que les équipes sécurité ne peuvent plus accepter en production. Isoler le runtime dans un segment réseau dédié devient un prérequis, pas une option.
Migration Silverlight vers Blazor ou frameworks .NET actuels
Le chemin de migration le plus naturel pour du code Silverlight C#/XAML passe par l’écosystème .NET contemporain. Blazor Server ou Blazor WebAssembly réutilisent une partie des compétences C# de l’équipe existante. Mais la migration n’est pas un portage mécanique.
Ce qui se transfère et ce qui ne se transfère pas
La logique métier écrite en C# dans les ViewModels se récupère souvent avec des ajustements modérés. Les services WCF doivent être remplacés par des endpoints REST ou gRPC, ce qui impose de revoir la couche de communication.
En revanche, tout le code XAML d’interface est à réécrire. Blazor utilise Razor et HTML, pas XAML. Les animations, les contrôles personnalisés, les DataTemplates complexes n’ont pas d’équivalent direct. C’est sur cette couche que la charge de travail explose, surtout si l’application utilise des composants tiers Silverlight (Telerik, ComponentOne) dont les licences sont périmées.
Une approche par module réduit le risque. Nous observons que les projets qui réussissent migrent d’abord les écrans les plus utilisés, laissent le reste en encapsulation temporaire, et itèrent sur plusieurs trimestres.
Gouvernance du patrimoine applicatif Silverlight
Le marché des migrations héritées s’oriente vers des logiques de plateforme et de gouvernance, pas uniquement vers du réusinage ligne par ligne. Un inventaire applicatif précis constitue le point de départ obligatoire.
Cet inventaire doit cartographier pour chaque application Silverlight :
- Le nombre d’utilisateurs actifs sur les 90 derniers jours (extrait des logs serveur, pas des déclarations des chefs de projet)
- Les dépendances techniques : version du runtime Silverlight, version de .NET Framework côté serveur, services WCF ou RIA Services consommés, bases de données connectées
- Le propriétaire métier identifié, capable de valider un scénario d’extinction ou de prioriser une réécriture
- Le niveau d’exposition réseau : intranet isolé, VPN, accès public
Sans cet inventaire, toute feuille de route de migration reste un exercice théorique. Les DSI qui avancent sans données d’usage réelles finissent par réécrire des applications que plus personne n’utilise, et par négliger celles qui tiennent un processus critique.
Priorisation et budget de migration
La priorisation repose sur un croisement simple : impact métier fort et complexité technique faible en premier. Les applications à faible impact et forte complexité passent en encapsulation ou en extinction. Ce tri évite de mobiliser des mois de développement sur un outil marginal.
Traiter Silverlight comme un patrimoine applicatif à remplacer, pas à moderniser, change la posture budgétaire. On ne finance pas une montée de version. On finance la suppression d’un risque opérationnel et sécuritaire, ce qui facilite l’arbitrage avec la direction financière.
Les organisations qui reportent encore cette transition en 2026 accumulent une dette dont le coût augmente chaque trimestre : durcissement des politiques de sécurité, raréfaction des compétences Silverlight sur le marché, restriction progressive du mode IE dans Edge. Le calendrier joue contre l’attentisme.
