Silverlight software reposait sur le modèle de plug-in NPAPI (Netscape Plugin Application Programming Interface), une architecture héritée des années 1990. Ce choix technique, partagé avec Adobe Flash, a scellé son sort bien avant la fin de support officielle par Microsoft.
NPAPI et le verrouillage architectural de Silverlight dans les navigateurs
Le modèle NPAPI permettait à un plug-in tiers d’exécuter du code natif directement dans le processus du navigateur. Cette promiscuité posait deux problèmes majeurs : une surface d’attaque élargie et une instabilité en cas de crash du plug-in, qui entraînait celui du navigateur entier.
Chrome a supprimé le support NPAPI dès 2015. Firefox a suivi la même trajectoire. Quand Microsoft a lancé Edge sur le moteur Chromium, aucun mécanisme NPAPI n’a été réintégré. Silverlight s’est retrouvé sans point d’ancrage dans les navigateurs actuels.
La question n’était pas de savoir si Silverlight fonctionnait encore sur le plan applicatif. Le runtime existait toujours. Le problème était que plus aucun navigateur maintenu n’acceptait de charger un binaire NPAPI dans son espace mémoire. La technologie était devenue structurellement incompatible avec les navigateurs modernes, pas simplement obsolète.
HTML5 et le remplacement fonctionnel du plug-in Silverlight
Silverlight répondait à trois besoins principaux sur le web : la lecture de médias enrichis, la diffusion de contenus protégés par DRM et l’exécution d’interfaces applicatives riches côté client. HTML5 a couvert ces trois cas avec des API natives du navigateur.
Streaming et DRM sans plug-in
Les Encrypted Media Extensions (EME) ont permis la gestion des DRM directement dans le navigateur, sans couche intermédiaire. Les Media Source Extensions (MSE) ont pris en charge le streaming adaptatif. Le support du format DASH et du chiffrement CENC a rendu possible la diffusion protégée de vidéos sans recourir à Silverlight ou Flash.
Netflix, qui utilisait Silverlight comme lecteur vidéo principal dans les navigateurs desktop, a migré vers HTML5 plusieurs années avant la fin de support officielle. Ce basculement a été un signal fort pour l’ensemble de l’écosystème.
Interfaces riches et applications métier
Côté applicatif, les frameworks JavaScript modernes (React, Angular, Vue) ont remplacé ce que Silverlight proposait avec XAML et C# dans le navigateur. Le modèle Silverlight offrait un environnement de développement cohérent grâce à .NET, mais il imposait un plug-in. Les standards web ont fini par offrir des capacités comparables sans cette dépendance.
Nous observons que la dette technique liée à Silverlight persiste dans certaines applications métier internes. Des entreprises ont maintenu des postes sous Internet Explorer en mode compatibilité pendant des années, faute d’avoir migré leurs interfaces.
Fin de support Microsoft : ce que le 12 octobre 2021 a changé concrètement
Microsoft a mis fin au support de Silverlight le 12 octobre 2021 et a retiré l’installateur après cette date. Depuis, aucun correctif de sécurité n’est publié. Microsoft précise qu’il n’existe aucun remplacement direct fourni pour Silverlight.
Cette décision n’a pas touché uniquement les sites web publics. Certains modules internes de Microsoft, notamment ceux liés à la suite BHOLD dans Microsoft Identity Manager, ont été explicitement signalés comme inutilisables pour les utilisateurs n’ayant pas déjà installé le composant. Des applications métier dépendantes du plug-in se sont retrouvées bloquées, sans chemin de migration proposé par l’éditeur.
La fin de support a aussi rendu caduques les stratégies de contournement. Avant 2021, certaines organisations utilisaient Internet Explorer 11 avec le mode Enterprise pour maintenir Silverlight en production. La fin de support d’IE 11 a fermé cette dernière porte.
Migration depuis Silverlight : les options techniques qui subsistent
Pour les équipes qui gèrent encore du code Silverlight, les chemins de migration dépendent du type d’application concernée.
- Les applications de diffusion vidéo migrent vers des lecteurs HTML5 utilisant EME et MSE, avec un CDN compatible DASH ou HLS. La réécriture est généralement limitée au front-end.
- Les applications métier XAML/C# peuvent être portées vers Blazor WebAssembly, qui conserve l’écosystème .NET côté navigateur sans plug-in. Le portage du code C# est parfois direct, mais le XAML doit être réécrit en Razor.
- Les interfaces legacy critiques peuvent être virtualisées via des solutions tierces qui encapsulent le runtime Silverlight dans un conteneur isolé, sans dépendre du navigateur. Cette approche reste un palliatif, pas une solution pérenne.
Nous recommandons de traiter la migration comme un projet d’architecture, pas comme un simple portage de code. Le modèle de sécurité, la gestion des sessions et l’authentification doivent être repensés pour un contexte full-web.
Silverlight et Flash : deux disparitions, un même mécanisme
La disparition de Silverlight software suit exactement le même schéma que celle d’Adobe Flash. Les deux technologies partageaient le modèle NPAPI, la dépendance à un runtime tiers et une surface d’attaque que les éditeurs de navigateurs ont jugée incompatible avec leurs exigences de sécurité.
La différence tient à l’échelle. Flash était omniprésent sur le web grand public. Silverlight occupait une niche plus restreinte, concentrée sur le streaming vidéo premium et les applications d’entreprise. Sa disparition a été moins médiatisée, mais elle a posé des problèmes de continuité plus aigus dans les environnements professionnels, où les cycles de renouvellement logiciel sont longs.
Les deux cas illustrent une réalité technique : les navigateurs modernes ne tolèrent plus de code tiers exécuté hors sandbox. Le web s’est recentré sur des standards ouverts (HTML5, JavaScript, WebAssembly) qui éliminent le besoin de plug-ins propriétaires. Silverlight n’a pas disparu parce que la technologie était mauvaise. Elle a disparu parce que le modèle d’exécution sur lequel elle reposait a été abandonné par l’ensemble des éditeurs de navigateurs.
Les organisations qui maintiennent encore des dépendances Silverlight en production travaillent contre le sens de l’écosystème. Chaque mois sans migration augmente le risque de sécurité et réduit les options de portage disponibles.
