Le Web riche arrive avec ses dépendances

J’ai regardé quelques démonstrations d’interfaces Web riches et je vais être honnête : elles sont dangereusement efficaces. Une vidéo démarre sans rechargement, les éléments glissent et l’écran réagit comme une application de bureau. Le bon vieux HTML paraît soudainement très vieux.

La différence ne tient pas seulement à l’animation. Dans une page Web classique, le navigateur analyse HTML, applique CSS, construit son arbre de documents et exécute JavaScript. Avec Flash ou le jeune WPF/E, une balise de la page charge plutôt un module d’exécution. Ce plugin télécharge son propre paquet, dessine dans une surface réservée et interprète les événements de souris ou de clavier à l’intérieur de cette surface.

page HTML
  |-- DOM, liens et formulaires gérés par le navigateur
  `-- zone du plugin
        |-- runtime Flash ou WPF/E
        |-- graphisme vectoriel et média
        `-- appels HTTP vers les services du serveur

Cette couche donne au fournisseur un environnement plus prévisible entre les fureteurs. Flash possède déjà une diffusion impressionnante. WPF/E attire mon côté .NET avec XAML, une description XML de l’interface qui peut séparer les formes et animations du code de comportement.

Le prix est une frontière supplémentaire. Le navigateur connaît mal ce qui se passe dans la zone du plugin. Le lecteur d’écran, la navigation au clavier, l’impression, le bouton Précédent et les moteurs de recherche peuvent perdre une partie du contenu. Il faut les tester un par un au lieu de supposer qu’une belle surface est une bonne page Web.

Une animation appelle quand même un serveur

Prenons un catalogue qui charge des produits sans rafraîchir la page. Le plugin appelle un service HTTP, reçoit du XML, le transforme en objets, puis met l’écran à jour. Il faut encore gérer le délai, une réponse invalide, la session expirée et un appel répété. Une animation de chargement ne doit pas masquer une commande envoyée deux fois.

clic -> désactiver la commande -> requête HTTP
     -> réponse XML validée -> mise à jour de l'écran
     -> erreur ou timeout -> message + possibilité de reprendre

Les appels vers un autre domaine soulèvent aussi des règles de sécurité. Autoriser librement un plugin à lire n’importe quel site avec les droits de l’utilisateur serait dangereux; les runtimes imposent donc des restrictions et des mécanismes d’autorisation. L’architecture doit garder les secrets et les validations sur le serveur, même si l’interface paraît être une petite application autonome.

Le déploiement devient un projet en soi. Quelle version minimale du plugin? Les postes gérés peuvent-ils l’installer? Que voit une personne sans droits administrateur? Quelle page de rechange reste utilisable si l’installation échoue? Pour un intranet contrôlé, on peut pousser et tester une version précise. Sur un site public, chaque demande d’installation perd une partie des visiteurs.

JavaScript et Ajax proposent une autre voie. Ils gardent l’application plus près du navigateur, au prix de différences pénibles entre implémentations en 2006. Je comparerais donc les approches sur une exigence concrète : média protégé, dessin vectoriel complexe, accessibilité, portée des navigateurs, mode dégradé et coût du plugin.

J’ai envie de construire un prototype, justement pour mesurer ces frontières. Je garderais le contenu essentiel accessible en HTML et je réserverais le runtime à ce qu’il apporte réellement. Une transition dure une seconde; la dépendance au plugin, aux outils et au calendrier d’un fournisseur peut durer des années.

Mise à jour de 2026

Avec le recul de 2026, la réponse est assez brutale : les deux plugins ont fini par disparaître. Adobe a arrêté le support de Flash Player le 31 décembre 2020, puis en a bloqué l’exécution le 12 janvier 2021. WPF/E est devenu Silverlight en avril 2007; son support a pris fin le 12 octobre 2021.

Aujourd’hui, une application Web moderne repose sur HTML, CSS, JavaScript et les API normalisées du navigateur. Adobe recommande même de retirer Flash. Les pages officielles expliquent la fin de vie de Flash Player et la fin de support de Silverlight. Le risque de dépendance était bien réel.