Après la défection de Flash sur les plateformes mobiles, les partisans du HTML5 ont en ligne de mire le champ de bataille suivant : les ordinateurs (lire Occupy Flash : pour un web meilleur… et inversement). Cependant les choses sont loin d'être gagnées d'avances, car Flash conserve quelques avantages auxquels le HTML5 ne peut encore prétendre.
Ubiquité du moteur d'exécution
Si Flash a bénéficié d'une adoption aussi rapide sur les navigateurs et les sites web, c'est qu'il offrait une solution à un véritable casse-tête pour les développeurs web : il offrait un moteur d'exécution unique et universel sur tous les navigateurs, alors que le HTML nécessite souvent une adaptation à chaque navigateur. C'est le fameux "write once, run anywhere" (écrivez une seule fois, exécutez n'importe où) qui fut autrefois la promesse de Java, pleinement remplie par Flash, du moins jusqu'à l'apparition des plateformes mobiles.
Précisément, l'adoption massive de WebKit comme moteur de rendu sur les plateformes mobiles a rendu le même service pour les développeurs web. Pour peu que la version mobile d'un site s'affiche correctement sur un OS mobile donné, celle-ci fonctionnera à peu près de la même manière sur toutes. Et comme précisément Flash manquait à l'appel sur iOS, c'est donc le HTML5 qui fit œuvre de passerelle par le biais de WebKit.
La donne est cependant bien différente sur ordinateurs, dont les différents navigateurs se partagent entre plusieurs moteurs de rendu : WebKit pour Safari et Chrome, Gecko pour Firefox et nombre de ses déclinaisons, et Trident pour Internet Explorer. Il ne s'agit là cependant que d'un moteur de rendu, auquel il faut également ajouter le moteur d'exécution JavaScript qui diffère encore de navigateur en navigateur, tant en fonctionnalités qu'en rapidité d'exécution, y compris parmi ceux qui partagent le même moteur de rendu. Sans oublier que les navigateurs ne supportent le HTML5 que de manière encore parcellaire (Safari 5.1.2 s'en tire avec un score de 308 sur 450, contre 342 pour Chrome sur le haut du podium)
En somme, Flash a encore de nombreux services à rendre, ne serait-ce que pour simplifier la tâche des développeurs web.
Cauchemar audiovisuel
Les choses ne s'en tiennent pas là malgré tout. Bien que le HTML5 ajoute le support de la vidéo et du son, ceux-ci ne font pour l'heure qu'augmenter le casse-tête.
En effet, le W3C n'est pour l'heure pas parvenu à imposer un standard de format de fichier, les entreprises comme Apple et Microsoft pesant de tout leur poids pour soutenir le couple H.264/AAC qui sont propriétaires, et les partisans des formats libres, de la fondation Mozilla jusqu'à Google, soutiennent Ogg Theora, Ogg Vorbis, et WebM.
Chaque navigateur, selon les prises de position de ses instigateurs, ne soutiendra qu'un seul des deux camps, et compliquent la tâche des éditeurs de sites web. Ainsi, pour qu'une vidéo soit lisible nativement en HTML5 tant par Chrome que par Internet Explorer, il faudra l'encoder dans les deux formats. Là encore Flash fait œuvre de solution universelle, puisqu'il permet à n'importe quel navigateur de lire les vidéos, qu'elles soient encodée en H.264 ou en WebM.
Si le HTML permet de basculer sur une solution de repli pour l'affichage d'une vidéo en cas d'absence de la technologie visée par défaut (ou "fallback"), dans les faits cette capacité est encore peu mise en pratique, et dans la majorité des cas c'est Flash qui conserve la priorité. Ainsi, la version d'une page compatible iOS ne sera chargée que sur détection de l'agent utilisateur correspondant, et non sur le test de la présence du plugin Flash. Ainsi, YouTube comme DailyMotion permettent d'afficher leurs vidéos en HTML5, mais seulement sur demande explicite de l'utilisateur, et non en cas d'absence de Flash. Un petit nombre d'utilisateurs de Mac a choisi de retirer Flash (dont la version Mac est très décriée pour ses lourdeurs), en s'appuyant de manière occasionnelle sur le moteur Flash embarqué dans Chrome lorsque le besoin s'en fait sentir, mais nombre de sites qui disposent pourtant d'un contenu compatible HTML5 ne le présenteront que sur iOS, à moins de modifier l'agent utilisateur dans le menu développeur.
D'autre part, Flash intègre une fonctionnalité cruciale pour les éditeurs de contenus et les ayants-droits qui manque toujours à l'appel pour le HTML5 : le support de mesures techniques de protection (DRM). En effet, la diffusion de certaines œuvres audiovisuelles sur le web ne peut se faire contractuellement que si elles sont protégées par de telles mesures, et sans elles les services de télévision de rattrapage n'auraient tout simplement pas pu voir le jour par exemple.
Mais d'autres services en ligne dépendent d'autres fonction exclusives de Flash pour la vidéo, notamment la possibilité de faire de la vidéoconférence. Le support de Skype dans Facebook, la version web d'AIM, ou encore Chatroulette ne peuvent exister que grâce à Flash. Si HTML5 permet de diffuser de la vidéo en direct côté serveur par le biais notamment du HTTP Live Streaming (qui repose sur le H.264 et qui se limite pour l'heure à Safari sur Mac et iOS), il ne peut cependant pas accéder à une webcam ni au microphone côté client. Le W3C travaille actuellement à ce problème avec les Media Capture API, encore à l'état de brouillon.
Enfin, le support du son est également encore incomplet dans le HTML5 : s'il est possible de lancer la lecture d'un son sur un événement utilisateur (clic de la souris ou pression d'une touche du clavier), il est encore difficile d'en faire autant de manière purement programmatique. Le mixage en temps réel de plusieurs pistes sonores consomme beaucoup trop de ressources, à tel point qu'Apple a désactivé le son dynamique sur iOS (officiellement pour éviter les abus de bande passante en 3G). Ainsi, nombre d'applications web réalisées en HTML s'appuient encore sur un module Flash pour gérer le son, par le biais d'une communication avec JavaScript. La performance tient donc plus de la démonstration technique que d'une réelle mise en application, car quitte à ce que Flash soit indispensable pour réaliser une application web, autant qu'elle soit intégralement développée en Flash. Au prix de lourds efforts, il reste possible de réaliser un jeu tout à fait correct entièrement en HTML, c'est en tous cas ce qu'Opera Software a démontré avec Emberwind, un jeu originellement sorti sur Windows, Mac OS X et iOS, dont les 100 000 lignes de code en C ont été portées entièrement en JavaScript.
D'autre part, s'il existe des API de bas niveau permettant de réaliser toute une panoplie d'effets sur le son en temps réel directement en JavaScript, celles-ci sont plus ou moins bien supportées (Web Audio API ne fonctionne que sur Chrome et les Nightly Builds de WebKit, tandis que Firefox supporte son propre système, bien évidemment incompatible, nommé Audio Data API).
La bataille de la 3D
Avec Flash 11, Adobe attaque le marché de la 3D en ligne, qui était jusqu'ici la chasse gardée de Shockwave dans son catalogue. L'annonce est de taille car Flash bénéficie toujours d'une base installée conséquente, à tel point que Unity, qui disposait jusqu'ici de son propre plugin, a décidé d'intégrer une sortie vers Flash à son IDE. Plus significatif encore, Epic Games a annoncé le portage du moteur Unreal Engine 3 en Flash.
Si HTML5 n'intègre pas de gestion de la 3D, un autre standard, WebGL, géré par le Khronos Group, permet d'exploiter les cartes 3D dans une page HTML. Depuis la finalisation de la version 1 en mars dernier, seuls Firefox (depuis la version 4) et Chrome (depuis la version 9) intègrent le support de WebGL en standard. Safari 5.1 n'en est qu'à un support expérimental qui est désactivé par défaut, Opera ne supporte WebGL que dans la beta de la version 12, et Microsoft n'a pas pour l'heure prévu de supporter cette technologie dans son navigateur. En cause, une sérieuse faille de sécurité (lire WebGL, maillon faible de la sécurité), suffisamment préoccupante pour que Microsoft n'envisage pas de s'y mettre (lire Apple et Microsoft jettent le doute sur la sécurisation de WebGL).
D'autre part, Flash propose d'ores et déjà une fonction appréciable qui manque toujours au HTML : le basculement en plein écran. Par ailleurs Adobe a également annoncé l'arrivée prochaine de la capture du curseur, une fonction indispensable pour nombre de contenus en 3D.
Protection des éléments
Le propre d'une page HTML c'est de contenir le lien HTTP vers chacun des éléments qu'elle contient : images, sons, vidéos, textes, code javascript et autres. Cela rend la protection des données et du code plus complexe, puisque par défaut il suffit d'afficher le code source de la page dans le navigateur pour retrouver ces éléments et les télécharger (lire Pas à pas : télécharger du contenu web).
JavaScript, le langage de programmation du HTML, et ActionScript, le langage de programmation de Flash, ont en commun de devoir être exécutables sur n'importe quelle famille de processeurs : le code ne peut donc être distribué sous forme compilée. C'est le moteur d'exécution (dans un cas le navigateur lui-même et dans l'autre le plugin Flash) qui interprétera le code pour envoyer les commandes nécessaires aux API du système et au processeur. L'inconvénient c'est que le code source doit être accessible au moteur d'exécution, ce qui l'expose potentiellement aux regards indiscrets.
Les développeurs JavaScript qui ne tiennent pas à dilapider leur savoir-faire ne peuvent recourir qu'à l'obfuscation du code. Ce procédé rend la lecture du code difficile pour un humain tout en étant exécutable par le navigateur, par le biais d'outils dédiés. Difficile, mais pas impossible, d'autant moins qu'il existe des "deobfuscateurs". Quant aux ressources tierces telles que les images, il est possible d'en empêcher le chargement en dehors de la page pour laquelle elles sont prévues, mais là encore au prix d'un développement supplémentaire côté serveur, et d'une exposition potentielle du secret partagé côté client.
Les choses sont plus simples concernant Flash, puisque le format SWF ne permet pas d'inspecter son contenu, du moins en théorie. Le code et les médias que les fichiers Flash recèlent sont relativement à l'abris des regards indiscrets, à ceci près qu'il existe également des outils permettant la "décompilation" des SWF. Il s'agit d'un abus de langage puisque le SWF n'est pas à proprement parlé compilé : le code est converti en langage intermédiaire (ou bytecode). Il est possible de convertir ce bytecode en ActionScript qui soit lisible, mais il ne sortira pas pour autant sous sa forme originale et sera plus ou moins exploitable tel quel.
En tout état de cause, rien n'empêche un concurrent indélicat de copier-coller votre code JavaScript dans sa propre page pour bénéficier de vos développements sans bourse délier, alors que la gestion cross-domain de Flash permet d'éviter ce problème. De manière générale Flash offre plus de latitudes pour protéger les investissements des développeurs et des ayants droits, puisqu'il permet d'ajouter une couche de protection supplémentaire par rapport au JavaScript : qu'on bloque les requêtes HTTP directes au fichier SWF, et tous les éléments seront hors d'accès. Il est également possible d'empêcher le stockage du fichier SWF dans le cache du navigateur.
En somme, les développements qui nécessitent de lourds investissements seront protégés avec Flash, et ouverts aux quatre vents en HTML. Une différence suffisante pour dissuader certains développeurs d'abandonner Flash.
Eco-systèmes
Les outils de développement dédiés au HTML5 sont encore relativement confidentiels. On peut citer notamment Hype, Sensha Animator, ou encore Adobe Edge actuellement en cours de développement. Du côté des jeux certains moteurs facilitent leur mise en œuvre comme par exemple Impact Engine. Mais nul ne rivalise encore avec le confort et la souplesse de Flash, d'autant moins qu'une quantité d'outils supplémentaires a vu le jour avec l'ouverture du format de fichier SWF.
D'autre part, les développeurs web eux-mêmes ont un savoir-faire incomparable avec Flash pour créer des contenus dynamiques et interactifs, alors qu'encore peu de développeurs ont eu l'occasion d'obtenir une réelle expérience en HTML5 au delà de la simple démo technique, sans oublier que chaque implémentation dans chaque navigateur fait figurer un certain nombre de bugs qu'il faut apprivoiser. Si l'on ajoute à cela le fait que c'est bien l'absence de Flash qui a motivé les investissements dans le HTML5 pour le mobile, il n'en va pas de même pour les ordinateurs : Flash reste le chemin de moindre résistance sur cette plateforme. Un jour prochain, la part des OS mobile, et la maturité du HTML5, pousseront sans doute certains sites à reconsidérer le double développement entre Flash et le HTML, mais il y a encore loin d'ici là.
