Silverlight repose sur un plugin NPAPI que plus aucun navigateur moderne ne prend en charge. Le support Microsoft a pris fin en octobre 2021, sans correctif de sécurité depuis. Migrer un logiciel Silverlight vers HTML5 ou Blazor suppose de comprendre ce que le code source contient réellement avant de choisir une cible technique.
Audit du code XAML et C# avant toute migration Silverlight
La première étape ne consiste pas à choisir entre Blazor et HTML5. Elle consiste à cartographier le périmètre applicatif existant. Un logiciel Silverlight combine du XAML pour l’interface, du C# pour la logique métier, et souvent des appels à des services WCF ou REST côté serveur.
A lire également : Internet professionnel : trouver l'offre adaptée pour une PME en croissance
L’audit doit répondre à trois questions concrètes :
- Quelle proportion du code C# relève de la logique métier pure (réutilisable) et quelle proportion est liée au runtime Silverlight (non réutilisable) ?
- Les composants XAML utilisent-ils des contrôles tiers (Telerik, DevExpress, ComponentOne) dont les équivalents n’existent pas forcément sur la cible choisie ?
- L’application consomme-t-elle des services WCF classiques qu’il faudra convertir en API REST ou gRPC pour fonctionner dans un environnement cloud moderne ?
Sans cette cartographie, toute estimation de charge est fictive. Un logiciel Silverlight avec une couche métier bien isolée du XAML se migre beaucoup plus vite qu’une application où la logique est dispersée dans les code-behind des vues.
A lire en complément : Faut-il encore passer par Webmail Orléans Tours ou utiliser une appli dédiée ?
Blazor ou HTML5 avec Angular : critères techniques de choix
Le choix de la cible dépend de l’écosystème dans lequel l’équipe de développement évolue, pas d’une préférence abstraite.
Blazor pour les équipes C# et .NET
Blazor WebAssembly exécute du C# directement dans le navigateur, ce qui permet de réutiliser une partie significative de la logique métier écrite pour Silverlight. Le modèle de composants Razor remplace le XAML, mais la syntaxe reste familière pour des développeurs .NET.
Blazor Server, l’autre variante, exécute le code côté serveur et envoie les mises à jour d’interface via SignalR. Ce mode convient aux applications internes avec peu d’utilisateurs simultanés, mais introduit une dépendance réseau permanente.
Microsoft intègre Blazor dans sa stratégie .NET à long terme, avec un support LTS sur .NET 8 et .NET 10. Ce n’est pas un projet satellite comparable à ce que Silverlight était devenu en fin de vie.
HTML5 avec Angular ou React pour sortir de .NET
Si l’organisation souhaite quitter l’écosystème Microsoft côté front-end, une réécriture en Angular ou React est la voie classique. Le code C# métier ne se réutilise pas directement (il faut le porter en TypeScript ou l’exposer via des API), mais le vivier de développeurs front-end JavaScript est plus large.
Ce choix implique une réécriture plus profonde. La migration vers HTML5/Angular est une reconstruction, pas une conversion. Le coût et le délai augmentent proportionnellement à la complexité de l’interface Silverlight d’origine.
Conformité et sécurité : la pression réglementaire sur les environnements Silverlight
Maintenir un logiciel Silverlight en production ne pose pas qu’un problème technique. Les politiques de sécurité internes des DSI et les référentiels réglementaires rendent ce maintien de plus en plus difficile à justifier.
Le cadre SecNumCloud de l’ANSSI exige la maîtrise des vulnérabilités sur les composants non maintenus. Un runtime sans correctif depuis plusieurs années, accessible uniquement via un navigateur lui-même en fin de vie, ne satisfait pas ces exigences. Les secteurs régulés (banque, santé, secteur public) sont les premiers concernés.
Microsoft a par ailleurs durci sa politique de support sur les environnements legacy. Maintenir des postes verrouillés sur IE11 via des stratégies de groupe ou des machines virtuelles dédiées génère un coût d’exploitation croissant, en plus d’élargir la surface d’attaque.
Certaines organisations utilisent une approche intermédiaire : encapsuler l’application Silverlight dans un environnement VDI (infrastructure de bureau virtuel) le temps de mener la migration. Cette mise sous cloche via VDI achète du temps sans régler le problème. Elle reste un palliatif, pas une stratégie de sortie.
Stratégie de migration Silverlight : découpage par modules
Une erreur fréquente consiste à vouloir migrer l’ensemble du logiciel Silverlight en une seule itération. Les projets de migration les plus maîtrisés procèdent par modules fonctionnels.
Le principe : identifier les modules les moins couplés au reste de l’application, les migrer en premier vers la cible choisie (Blazor ou HTML5), puis les mettre en production pendant que le reste du logiciel continue de tourner dans son environnement legacy (éventuellement en VDI).
Cette approche progressive permet de valider les choix d’architecture sur un périmètre restreint avant d’engager l’ensemble de l’équipe de développement. Elle réduit aussi le risque métier, puisque l’application reste opérationnelle à chaque étape.
Trois éléments conditionnent la faisabilité de ce découpage :
- Le degré de couplage entre modules dans le code Silverlight existant (un monolithe fortement couplé se découpe mal)
- La capacité à faire coexister l’ancien et le nouveau front-end derrière un même back-end, via des API partagées
- La disponibilité d’outils DevOps pour automatiser les tests de non-régression sur chaque module migré
Rôle de l’architecte technique dans le choix Blazor ou HTML5
La décision finale entre Blazor et HTML5/Angular ne revient pas à un développeur isolé. Elle engage l’architecture du système d’information sur plusieurs années.
Un architecte technique évalue la compatibilité avec l’infrastructure cloud existante (Azure, AWS, environnement hybride), la cohérence avec les autres applications du SI, et la capacité de l’équipe à monter en compétence sur la cible retenue. Si l’organisation exploite déjà ASP.NET Core côté serveur et Azure pour l’hébergement, Blazor s’intègre dans une pile technique homogène. Si le front-end repose déjà sur Angular pour d’autres applications, dupliquer les technologies n’a pas de sens.
La gestion des données mérite aussi une attention particulière. Les applications Silverlight utilisent parfois des mécanismes de stockage local (Isolated Storage) que ni Blazor ni Angular ne reproduisent à l’identique. L’architecte doit arbitrer entre stockage navigateur, cache côté serveur ou refonte du flux de données.
Le choix entre Blazor et HTML5 se tranche sur des critères d’écosystème, de compétences disponibles et de cohérence SI, pas sur une comparaison abstraite de frameworks. Un audit sérieux du code Silverlight existant, une évaluation réaliste de la charge de migration par module et une validation de conformité réglementaire forment le socle minimum avant de lancer le projet.
