Silverlight est un framework de Microsoft conçu pour exécuter des applications web riches directement dans le navigateur, via un plugin dédié. Son support a officiellement pris fin le 12 octobre 2021, sans aucun correctif de sécurité depuis. En 2026, la question de son utilité se pose avec une réponse technique sans ambiguïté.
Silverlight en 2026 : un runtime sans navigateur compatible
Le plugin Silverlight reposait sur l’architecture NPAPI, abandonnée par Chrome dès 2015, puis par Firefox. Edge ne l’a jamais prise en charge. Le seul navigateur capable de faire tourner Silverlight de façon fiable était Internet Explorer, lui-même arrivé en fin de vie en juin 2022.
A lire en complément : Melanie web en 2026 : évolutions, nouveautés et changements à prévoir
Pour maintenir une application Silverlight opérationnelle aujourd’hui, les équipes techniques doivent recourir à des configurations sur mesure : instances IE11 verrouillées via le mode de compatibilité d’Edge, stratégies de groupe (Group Policy) ou environnements de navigateur virtualisés. Chaque contournement génère une dette de maintenance qui s’alourdit à chaque mise à jour du système d’exploitation Windows.
Les vulnérabilités connues (CVE) référencées dans la base publique, dont certaines permettent l’exécution de code à distance, restent non corrigées depuis plus de quatre ans. Un audit de sécurité standard signale ces failles comme des risques critiques.
Lire également : Comment optimiser le contenu de vos notifications push web pour un meilleur impact
Règlement DORA et applications legacy : la contrainte réglementaire européenne
Depuis le 17 janvier 2025, le règlement DORA (Digital Operational Resilience Act) s’applique aux établissements financiers de l’Union européenne. Ce texte impose un inventaire exhaustif de tous les actifs TIC, y compris les applications web héritées, accompagné d’une évaluation annuelle du risque associé aux systèmes legacy.
Une application Silverlight encore en production dans une banque ou une compagnie d’assurance déclenche automatiquement un signalement dans cet inventaire. Le risque ne se limite pas à la technique : il devient un sujet de conformité réglementaire, avec des obligations de documentation et de remédiation.
Cette pression ne concerne pas uniquement la finance. Elle reflète une tendance plus large où les régulateurs européens scrutent les dépendances technologiques obsolètes. Maintenir Silverlight en production expose donc à un double risque, technique et juridique.
Migration depuis Silverlight : les stratégies concrètes en 2026
La tentation de réécrire entièrement une application Silverlight en partant de zéro reste forte. Les retours d’expérience documentés entre 2024 et 2026 montrent une approche différente : la modernisation incrémentale l’emporte sur la réécriture complète.
Le principe consiste à containeriser le monolithe .NET existant, puis à moderniser progressivement les composants, plutôt que de lancer un projet de refonte globale. Cette méthode réduit le risque d’échec du projet et permet de maintenir la continuité de service.
WebAssembly comme cible de portage
Plusieurs éditeurs et entreprises ont documenté des cas de portage de front-ends « rich client » hérités (dont Silverlight) vers WebAssembly. Cette technologie permet d’exécuter du code compilé directement dans le navigateur, sans plugin, avec des performances proches du natif.
Des frameworks comme Uno Platform proposent un chemin de migration explicite depuis Silverlight vers WebAssembly, en réutilisant une partie du code XAML et C# existant. Blazor, le framework web de Microsoft basé sur .NET, offre également un mode WebAssembly qui conserve la logique métier écrite en C#.
- Uno Platform permet de réutiliser le code XAML/C# existant et de cibler WebAssembly, iOS, Android et desktop depuis une base de code unique.
- Blazor WebAssembly exécute du code .NET directement dans le navigateur, ce qui facilite la transition pour les développeurs familiers de l’écosystème Microsoft.
- La containerisation du back-end .NET existant sert de première étape avant le remplacement progressif du front-end Silverlight.
Ce que la migration préserve et ce qu’elle casse
Le code métier en C# se transfère avec un effort modéré vers Blazor ou Uno Platform. Les animations et interactions riches spécifiques à Silverlight, en revanche, nécessitent une réécriture. Les composants tiers développés exclusivement pour Silverlight n’ont généralement pas d’équivalent direct.
L’effort de migration dépend du volume de logique d’interface spécifique à Silverlight, pas du volume total de code. Une application dont la complexité réside dans le back-end migre plus vite qu’une application à interface graphique lourde.
Silverlight face aux alternatives web modernes : ce qui a changé
Silverlight répondait à un besoin réel au milieu des années 2000 : les navigateurs ne savaient pas afficher de contenu multimédia riche ni exécuter des applications complexes côté client. HTML5, CSS3 et JavaScript étaient alors trop limités.
En 2026, le paysage technique n’a plus rien à voir. Les API web natives couvrent la lecture vidéo, l’audio, le dessin vectoriel (Canvas, SVG), les animations fluides et le stockage local. WebAssembly ajoute la possibilité d’exécuter du code compilé performant. Les navigateurs modernes rendent le concept même de plugin obsolète.
Les développeurs qui maintenaient des applications Silverlight pour des cas d’usage spécifiques (streaming interne, tableaux de bord interactifs, outils métier riches) trouvent aujourd’hui des solutions standards sans dépendance à un runtime propriétaire. Les données et les services web sous-jacents restent exploitables, seule la couche de présentation doit changer.
Faut-il encore maintenir une application Silverlight en production ?
La réponse tient en quelques critères concrets :
- Si l’application est exposée sur Internet, le risque de sécurité est immédiat et documenté (CVE non corrigées, absence de support navigateur natif).
- Si l’application tourne sur un réseau interne isolé, le risque est moindre mais la dette technique s’accumule, et le coût de maintenance des environnements IE11 virtualisés augmente.
- Si l’organisation opère dans un secteur régulé (finance, santé, services publics), le maintien de Silverlight crée un problème de conformité qui va au-delà de la seule obsolescence technique.
- Si le code métier est principalement en C#/.NET, les chemins de migration vers Blazor ou Uno Platform limitent l’effort de portage.
Silverlight a rendu des services réels pendant une décennie. En 2026, aucun argument technique, sécuritaire ou réglementaire ne justifie son maintien en production. La seule variable qui reste à arbitrer, c’est le calendrier de migration.
