Silverlight est un plugin navigateur développé par Microsoft, conçu pour exécuter des applications web riches intégrant vidéo, animations et interfaces interactives. Son cycle de vie est aujourd’hui entièrement fermé : Microsoft a mis fin à son support le 12 octobre 2021.
Toute application d’entreprise encore dépendante de Silverlight fonctionne donc sans correctifs de sécurité, ce qui la place dans la même catégorie qu’une dépendance logicielle abandonnée. La question n’est plus de savoir si migrer, mais comment arbitrer entre les applications encore en production.
Comprendre pourquoi Silverlight pose un problème de sécurité actif
Silverlight repose sur un modèle de plugin navigateur devenu incompatible avec l’architecture web moderne. Les navigateurs actuels – Chrome, Firefox, Edge – ont tous supprimé le support des plugins NPAPI et ActiveX, qui étaient les seules interfaces permettant à Silverlight de s’exécuter.
Le mode IE de Microsoft Edge est souvent présenté comme une solution de contournement. Ce n’en est pas une. Microsoft indique explicitement que Silverlight n’est pas pris en charge dans ce mode. Utiliser le mode IE Edge ne constitue ni une migration ni une remise en conformité : c’est un contournement temporaire qui n’élimine pas le risque associé à une dépendance sans maintenance.
Les applications Silverlight encore actives en entreprise représentent une surface d’attaque non corrigée. Sans correctifs depuis octobre 2021, toute vulnérabilité découverte dans le runtime reste ouverte.
Inventaire des applications Silverlight : point de départ obligatoire
Avant toute décision, il faut savoir ce qui tourne encore. Un inventaire rigoureux ne se limite pas à lister les applications par nom : il descend au niveau des composants.
Microsoft distingue notamment les ressources web XAP (les fichiers compilés Silverlight) et les méthodes d’API associées comme getData et setData. Ces méthodes sont elles aussi devenues indisponibles. L’inventaire doit donc couvrir trois niveaux :
- Les applications qui chargent un fichier XAP directement dans le navigateur, qu’elles soient hébergées en interne ou via un prestataire.
- Les composants Silverlight intégrés dans des solutions Microsoft, notamment Dynamics 365 : les ressources web XAP sont dépréciées dans l’interface unifiée Unified Interface et ne sont plus prises en charge sur le client web.
- Les parcours utilisateurs qui dépendent de méthodes d’API Silverlight, même si l’interface visible semble fonctionner par ailleurs.
Cet inventaire produit une cartographie des dépendances, pas seulement une liste d’applications. C’est ce niveau de détail qui permet d’arbitrer correctement l’étape suivante.
Arbitrage entre remplacement, contrôle transitoire et retrait
Une fois l’inventaire établi, chaque application ou composant identifié doit être classé selon deux axes : le risque de sécurité qu’il fait peser, et la dépendance métier qu’il génère. Ces deux dimensions ne se recoupent pas toujours.
Remplacement immédiat
Un composant Silverlight qui gère un processus métier critique – validation de données, accès à un outil de production, interface d’un ERP – et qui est exposé à des utilisateurs externes ou accessibles depuis le réseau sans contrôle d’accès fort entre dans cette catégorie. Le risque combiné (exposition + criticité métier) justifie une priorité haute et un budget de remplacement immédiat.
Pour les composants liés à Dynamics 365 ou Power Platform, Microsoft documente une voie directe : remplacer les ressources XAP par des composants HTML utilisant HTML5. C’est le cas le plus balisé et souvent le plus rapide à traiter.
Mise sous contrôle transitoire
Certaines applications Silverlight restent en production parce qu’elles servent un usage ponctuel, peu fréquent, ou parce que leur remplacement nécessite un projet de plusieurs mois. Dans ce cas, une mise sous contrôle transitoire est préférable à l’inaction.
Cela implique concrètement : isoler l’application sur un poste ou un environnement dédié sans accès à Internet, restreindre l’accès aux seuls utilisateurs qui en ont besoin, documenter la dépendance dans le registre des risques de l’entreprise avec une date limite de sortie. Ce n’est pas une solution, c’est une gestion du risque dans l’attente d’une solution.
Retrait sans remplacement
Toutes les applications Silverlight inventoriées ne méritent pas un projet de migration. Certaines couvrent des besoins aujourd’hui satisfaits par d’autres outils, ou des usages qui ont disparu. Le retrait sans remplacement est souvent la décision la plus rapide et la moins coûteuse, à condition de confirmer qu’aucun processus actif ne repose encore sur l’application concernée.
Technologies de remplacement pour les applications Silverlight
Le choix de la technologie de remplacement dépend du type d’application Silverlight concernée. Il n’existe pas de migration universelle.
Pour les interfaces riches avec animations et visualisations de données, les frameworks JavaScript modernes (React, Vue, Angular) couvrent la quasi-totalité des cas d’usage que Silverlight adressait. Pour les applications de streaming ou de lecture vidéo, HTML5 avec l’élément natif <video> remplace directement les fonctions médias de Silverlight.
Pour les applications d’entreprise hébergées dans l’écosystème Microsoft, deux directions sont documentées. Les composants Silverlight dans Dynamics 365 se remplacent par des composants PCF (Power Apps Component Framework), qui s’intègrent dans Unified Interface. Les applications standalone développées en Silverlight/XAML peuvent être réécrites en Blazor (WebAssembly) si l’équipe de développement maîtrise l’environnement .NET, ce qui préserve une partie de la logique métier existante.
Prioriser la sortie de Silverlight selon le profil de l’entreprise
Le plan d’action ne dépend pas seulement de la technologie : il dépend du contexte de chaque organisation. Une PME avec deux applications internes héritées n’a pas le même chemin qu’une grande entreprise avec des dizaines de composants Silverlight intégrés dans un CRM.
Quelques repères pratiques pour calibrer le plan :
- Si l’application Silverlight est accessible depuis l’extérieur du réseau d’entreprise, le remplacement doit figurer dans les projets prioritaires de l’exercice en cours.
- Si l’application est uniquement accessible en interne mais sans contrôle d’accès fort, une isolation réseau s’impose en attendant la migration.
- Si l’application n’a pas été utilisée depuis plusieurs mois, le retrait sans remplacement doit être évalué avant de lancer un projet de migration.
- Si des composants Silverlight sont intégrés dans Dynamics 365 ou une solution Power Platform, la documentation Microsoft fournit une voie de migration concrète vers HTML5.
La date de fin de support d’octobre 2021 place mécaniquement chaque application Silverlight encore active dans une catégorie à risque. L’arbitrage entre remplacement, contrôle et retrait ne modifie pas ce constat : il permet de concentrer les ressources là où l’exposition est la plus forte, plutôt que de traiter toutes les dépendances au même niveau d’urgence.
