Silverlight est mort : que faire de vos applications
Microsoft a arrêté Silverlight le 12 octobre 2021 et plus aucun navigateur moderne ne l'exécute. Si vos applications métier en dépendent encore, ce guide compare les 3 voies de migration : OpenSilver, réécriture web moderne ou Blazor.
Sommaire · Silverlight
Un peu d'histoire
Microsoft Silverlight, c'était quoi ?
Silverlight est un plugin de navigateur lancé par Microsoft en 2007 pour créer des applications internet riches (RIA): interfaces fluides, vidéo en streaming, graphiques interactifs. Son concurrent direct s'appelait Adobe Flash, et la bataille a fait rage jusqu'au début des années 2010.
Sa promesse séduisait les DSI : l'interface se décrivait en XAML et la logique s'écrivait en C# ou VB.NET, avec les mêmes compétences que les applications Windows classiques. Résultat : des milliers d'entreprises ont bâti leurs applications métier sur Silverlight entre 2008 et 2015 : ERP internes, outils de production, portails de gestion, tableaux de bord industriels.
Puis l'iPhone a refusé les plugins, HTML5 a comblé l'écart et les navigateurs ont abandonné la technologie NPAPI dont Silverlight dépendait. Microsoft a acté la fin : la dernière version majeure, Silverlight 5, date de 2011.
2007-2021
14 ans de vie, dont 10 sans version majeure
Plugin NPAPI
Une technologie bannie des navigateurs
Apps métier
Son principal héritage en entreprise
Fin de vie
La fin officielle de Silverlight en 2021
La mort de Silverlight n'est pas une rumeur : c'est une décision officielle et définitive de Microsoft. Le 12 octobre 2021, le support s'est arrêté totalement : plus aucune mise à jour, plus aucun correctif de sécurité, plus aucune assistance.
En pratique, la technologie était déjà inutilisable dans les navigateurs grand public bien avant cette date. Voici la chronologie complète de l'abandon :
2015 : Chrome bloque le plugin
Google retire le support de la technologie NPAPI de Chrome en septembre 2015. Silverlight cesse de fonctionner du jour au lendemain pour la majorité des internautes.
2017 : Firefox suit le mouvement
Mozilla supprime à son tour les plugins NPAPI de Firefox. Edge, le nouveau navigateur de Microsoft, n’a jamais supporté Silverlight.
12 octobre 2021 : fin du support Microsoft
Date officielle de fin de vie. Plus aucune mise à jour n’est publiée, y compris les correctifs de sécurité critiques. Le téléchargement du plugin est retiré.
Juin 2022 : IE11, dernier refuge, est retiré
Microsoft désactive Internet Explorer 11 sur Windows 10. Le dernier navigateur capable d’exécuter Silverlight disparaît à son tour.
Aucun successeur direct
Microsoft ne propose aucune conversion automatique. La recommandation officielle est de migrer vers des technologies web modernes ou vers Blazor.
Le vrai problème
Pourquoi des apps Silverlight tournent encore en 2026
Si vous lisez ce guide, vous le savez déjà : des applications Silverlight tournent encore dans de nombreuses entreprises. Ce sont rarement des gadgets. Ce sont des applications métier critiques : suivi de production, gestion de stocks, planification, supervision industrielle. Les réécrire a un coût, alors la décision a été repoussée, année après année.
Pour continuer à les faire fonctionner, les équipes IT maintiennent des machines virtuelles IE11 figées ou activent le mode IE d'Edge. Ces contournements fonctionnent techniquement, mais ils reposent sur un socle sans aucun correctif de sécurité depuis 2021 : c'est un sursis, pas une solution.
0
Correctif de sécurité publié depuis le 12 octobre 2021 : chaque faille découverte reste ouverte
2011
Année de sortie de Silverlight 5, la dernière version : 15 ans de retard technologique accumulé
VM
Des postes figés sous IE11 pour exécuter l'app : une porte d'entrée idéale pour les attaquants
Au-delà de la sécurité, le risque est aussi réglementaire et assurantiel : un système non maintenu peut compromettre une conformité RGPD ou ISO 27001, et les cyber-assurances excluent de plus en plus les logiciels en fin de vie. Ajoutez l'impossibilité de recruter des développeurs Silverlight en 2026, et le statu quo devient la stratégie la plus coûteuse. C'est un cas d'école de dette technique arrivée à échéance.
Voie n°1
OpenSilver : réutiliser votre code XAML et C#
OpenSilver est une réimplémentation open source de Silverlight. Le principe : votre code XAML et C# existant est recompilé en WebAssembly, un format exécuté nativement par tous les navigateurs modernes, sans aucun plugin. L'application redevient accessible dans Chrome, Edge, Firefox ou Safari.
C'est la voie de migration la plus rapide quand le code source est disponible et que l'application donne satisfaction fonctionnellement. Mais soyons honnêtes : ce n'est pas une baguette magique, et il faut en connaître les limites avant de s'engager.
Les forces d'OpenSilver
Code réutilisé
La majorité du XAML et du C# existant est conservée : pas de redéveloppement complet des fonctionnalités.
Délais courts
Une migration OpenSilver se compte en semaines ou en mois, là où une réécriture complète se compte en trimestres.
Équipe .NET conservée
Vos développeurs C# gardent leurs repères : même langage, mêmes patterns, même logique métier.
Les limites à connaître avant de choisir
Fidélité partielle
L’API Silverlight n’est pas couverte à 100 %. Les composants tiers (Telerik, DevExpress) doivent être remplacés ou adaptés, ce qui rallonge le chantier.
UX d’origine conservée
L’application migrée ressemble à celle de 2012. Ergonomie datée, pas de responsive natif : la dette d’expérience utilisateur reste entière.
Écosystème de niche
Vous restez dépendant d’une technologie de compatibilité portée par une communauté restreinte, loin de la vitalité de l’écosystème web standard.
En résumé : OpenSilver est pertinent quand l'application doit simplement continuer à fonctionner telle quelle, avec un budget et des délais serrés. Si l'application doit évoluer, la réécriture web moderne est généralement un meilleur investissement.
Voie n°2
Réécrire en React ou Next.js : la voie pérenne
La deuxième voie consiste à considérer la fin de Silverlight comme une opportunité : reconstruire l'application sur un socle web standard (React, Next.js, TypeScript), celui qui fait tourner la majorité des applications web modernes. C'est l'approche que nous recommandons dès que l'application doit évoluer, et c'est le cœur de notre offre de refonte d'application web.
Une UX repensée pour les usages actuels
La réécriture permet de simplifier les parcours, supprimer les écrans inutiles et rendre l’application accessible sur tablette et mobile. On ne reproduit pas l’existant : on le modernise.
Un socle recrutable et maintenu
React et Next.js dominent l’écosystème web : les développeurs sont nombreux, les bibliothèques abondantes et les mises à jour régulières. Fini la dépendance à une technologie orpheline.
Des performances et une sécurité modernes
Chargement rapide, authentification SSO, API sécurisées, correctifs continus : l’application respecte enfin les standards de sécurité et de conformité attendus en 2026.
Une capacité d’évolution illimitée
Intégrations API, modules mobiles, tableaux de bord, IA : le socle web standard ouvre toutes les portes que Silverlight fermait.
La preuve par les projets
C'est l'approche que nous appliquons aux logiciels métier sur-mesure. Pour Dassault Aviation, notre application React et Node.js fait gagner 1 heure par processus à plus de 90 utilisateurs, avec 100+ fonctionnalités livrées. Pour SNEF, notre application technique Next.js fait gagner 1h30 tous les 2 jours aux équipes R&D.
Votre application Silverlight ne s'ouvre plus ?
Chaque mois de statu quo augmente le risque et le coût. Parlons de votre application : nous chiffrons la migration la plus adaptée, sans engagement.
Obtenir un chiffrage gratuitVoie n°3
Blazor : rester dans l'écosystème .NET
Blazor est le framework web officiel de Microsoft : il permet d'écrire des applications web en C# et .NET, exécutées dans le navigateur via WebAssembly ou côté serveur. C'est la voie recommandée par Microsoft pour les anciens projets Silverlight, et elle a du sens pour les équipes profondément ancrées dans l'univers Microsoft.
Attention toutefois à une idée reçue : Blazor ne permet pas de réutiliser le XAML de votre application Silverlight. L'interface se réécrit en composants Razor : la migration reste donc une réécriture, seule la logique métier C# peut être partiellement conservée.
Pour qui ?
Les entreprises dont l’équipe de développement est 100 % .NET et dont l’infrastructure repose sur Azure et Active Directory.
Ce qui est conservé
La logique métier C# (calculs, règles, modèles de données) peut être reprise en grande partie. L’interface XAML, elle, doit être réécrite en Razor.
Les points de vigilance
Écosystème de composants plus restreint que React, temps de chargement initial plus lourd en mode WebAssembly, et vivier de développeurs plus limité.
Notre position
Blazor est un choix rationnel pour une application interne portée par une DSI Microsoft. Pour une application amenée à s’ouvrir (clients, partenaires, mobile), le socle React / Next.js reste plus polyvalent.
Comparatif
Grille de décision : OpenSilver, React ou Blazor ?
Il n'y a pas de réponse universelle : la bonne voie dépend de l'avenir que vous projetez pour l'application, de votre équipe et de votre budget. Cochez la colonne où vous vous reconnaissez le plus :
- L’application doit juste continuer à fonctionner telle quelle
- Le code XAML / C# est disponible, propre et maîtrisé
- Budget et délais serrés, peu d’évolutions prévues
- Les utilisateurs sont formés à l’interface actuelle
- L’application doit évoluer dans les prochaines années
- L’ergonomie d’origine est dépassée (mobile, accessibilité)
- Besoin d’intégrations modernes : API, SSO, mobile, IA
- Vous voulez un socle pérenne et facile à recruter
- Équipe de développement interne 100 % .NET
- Infrastructure Microsoft imposée (Azure, Active Directory)
- Application interne sans enjeu d’ouverture au public
- Réécriture de l’interface acceptée et budgétée
Le piège à éviter
Ne choisissez pas une voie de migration sur le papier. La décision fiable repose sur un audit du code existant : disponibilité des sources, composants tiers utilisés, couverture fonctionnelle réelle. Un audit de quelques jours évite des mois d'erreur de trajectoire.
Notre méthode
La méthode ONDEV pour migrer votre app Silverlight
Migrer une application métier critique ne s'improvise pas : les utilisateurs doivent continuer à travailler pendant toute la transition. Notre méthode s'appuie sur 4 étapes éprouvées sur des applications métier de grands comptes comme de PME.
1. Audit de l’application Silverlight
Inventaire du code source, des composants tiers, des dépendances serveur et des flux de données. C’est cette étape qui détermine la voie de migration réaliste et son coût.
2. Cartographie fonctionnelle
Entretiens avec les utilisateurs pour distinguer les fonctionnalités vitales des écrans morts. En moyenne, 30 à 40 % des fonctionnalités d’une application ancienne ne sont plus utilisées : inutile de les migrer.
3. Migration progressive
Reconstruction module par module : chaque périmètre migré est mis en production pendant que l’existant continue de tourner. Pas d’effet tunnel, pas de bascule brutale.
4. Tests, reprise de données et bascule
Recette avec les utilisateurs clés, migration des données historiques, formation des équipes, puis extinction définitive de l’application Silverlight et de ses VM.
Conseil ONDEV : profitez de la migration pour solder l'ensemble de votre dette : base de données, hébergement, intégrations. Notre guide sur la dette technique détaille comment prioriser ces chantiers, et notre offre de logiciel métier sur-mesure couvre la reconstruction de bout en bout.
Pages liées · Silverlight
FAQ
Questions fréquentes sur Silverlight
Prêt à sortir de Silverlight ?
Ne laissez pas une application critique reposer sur une technologie morte. Audit, chiffrage et plan de migration : nous sécurisons votre application métier pour les 10 prochaines années.