Fermer le menu
 

Flash : pourquoi il faut encore vous y faire

Arnaud de la Gr... | | 19:35 |  82
skitched

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.

skitched

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à.
Catégories: 
Tags : 

Les derniers dossiers

Ailleurs sur le Web


82 Commentaires

avatar Martin_a 12/12/2011 - 19:50

C'est la qu'on réalise l'erreur MASSIVE d'adobe de ne pas avoir changé de cap à la sortie de l'iPhone...

avatar PePeLaJoie 12/12/2011 - 19:52

Oui! Fort bien! Mais pour les animations simples et moyennes et bannières qui forment 98% des animations des sites on pourra utiliser un outil comme Adobe Edge. Flash restera très présent dans les jeux et des applications spécifiques. J'en suis convaincu après avoir assisté à une présentation lors du User Group InDesign de Genève par Branislav Millic

avatar PePeLaJoie 12/12/2011 - 19:55

Il avait dit: "les stats sont indéniables: les gens consomment de plus en plus sur leur appareil mobile et plus sur l'ordinateur de bureau. Et si l'ipad et l'iphone sont tellement présents et interdisent Flash, alors les développeurs vont d'emblée créer des anims en HTML5 et seront donc lisibles sur toutes les machines." Car c'est bien vrai, 98% de Flash c'est pour les anims et banners sur des pages web.


avatar PePeLaJoie 12/12/2011 - 20:02

"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." Pourtant on peut brouiller un code JavaScript non?

avatar wizardkillyou 12/12/2011 - 20:03

@ Martin_A +100

avatar jbwawa 12/12/2011 - 20:04

En gros, plus de html5 = moins de branlettes sur chatroulette... L'évolution a du bon, non?

avatar PePeLaJoie 12/12/2011 - 20:20

Chatroulette, c'est là que sévissent les flasheurs !

avatar oonu 12/12/2011 - 20:22

[quote=PePeLaJoie]Pourtant on peut brouiller un code JavaScript non?[/quote] Et... ? "brouiller" ou non, le code source reste "copie-collable".

avatar aleios 12/12/2011 - 20:48

Ah on va encore avoir droit au commentaires basiques du style: steeve avait raison, le flash c'est tout pourri. Bah quand on pourra ne serait-ce que lire une video en html 5 sans attendre 10sec qu'elle se charge vous me rappellerez! En attendant flash a encore de beaux jours devant lui a condition qu'adobe ne lache rien et continue son travail d'optimisation.

avatar Jiminy Panoz 12/12/2011 - 20:49

N'empêche que quand on voit ce genre de choses : http://tympanus.net/codrops/category/tutorials/ Niveau code, c'est quand même très loin d'être compliqué. Chemin de la moindre résistance ou pas, y'a quand même tout intérêt à voir dégager les sites full-flash par exemple.

avatar mediapress 12/12/2011 - 21:16

il y a un bandeau de pub epson qui cache une partie du texte, c'est surtout gonflant quand il n'y a même pas une case pour fermer ce bandeau...

avatar BioSS 12/12/2011 - 21:26

Jiminy, la plupart des exemples BASIQUES en CSS animé que tu montres sur ton site rament sur mon iMac 3ghz 4 cœurs… En revanche des sites flash super fluide avec des effets complexes, j'en connais à la pelle.

avatar BenUp 12/12/2011 - 21:33

Cette histoire de flash c'est quand même à cause d'Apple qui a tout fait pour bloquer Adobe.

avatar BenUp 12/12/2011 - 21:34

Mais Adobe c'est aussi reposé sur leurs lauriers ;-)

avatar Almux 12/12/2011 - 21:44

Très bel article. J'ai été un grand admirateur de Flash, par le simple fait que je suis arrivé au web APRES mon amour de l'imagerie. Flash offre (offrait) cette possibilité de présenter ses oeuvres de manière parfaitement visuelle, avec des effets et tout, et tout... Mais le web est sillonné d'un nombre de plus en plus énorme de surfeurs et il faut alléger tout ça!

avatar nicolas 12/12/2011 - 22:55

@BioSS Moi ça marche très bien sur mon iPad2 Vérifie que t'es pas resté bloqué sur Firefox 2...;-)

avatar jean_claude_duss 12/12/2011 - 22:58

"En attendant flash a encore de beaux jours devant lui a condition qu'adobe ne lache rien et continue son travail d'optimisation." ----> ils,ont déjà commencé à laisser tomber ! Pas flash mais flash plugin, pour les sites web. En 2011 il est chaud de faire un site incompatible smartphones et tablettes... Mais en 2012 et 2013, ça sera impensable ! Flash va se ressentrer : sites de jeux, formation, applications spécifiques... Mais plus "sites web" Flash va devenir rapidement une plateforme crédible pour le dev ios et android ... Y'a 6'mois cétiat de la merde, et maintenant ça marche plutôt,très bien !!

avatar mediapress 12/12/2011 - 22:58

pour infos, j'ai plus la pub qui me bloquait la lecture... ça doit être aléatoire... bon article sinon...

avatar Goldevil 12/12/2011 - 23:37

Mon plus grand problème avec HTML (4 ou 5) ce n'est plus trop les problèmes de compatibilité entre navigateurs qui s'amenuisent peu à peu mais plutôt les grandes différences de performances. Dans les applications sur lesquelles nous travaillons, nous utilisons massivement des datagrid c'est-à-dire un tableau de données. Il y a pas mal de démonstrations avec différentes librairies AJAX (ExtJS ou JQuery par exemple) et elles sont convaincantes. Néanmoins dans le monde réel, on ne met pas 30 ou même 100 lignes dans un tableau mais des milliers. Et alors on a des différences de performances énormes qui vont de lent (avec Chrome par exemple) à inutilisable (avec IE8 par exmple). La seule solution est l'applet Java (très lourd à programmer) ou Flash, plus précisément le framework Flex (Flash Builder anciennement Flex Builder). De plus, une fois l'application écrite il est trivial de la compiler pour le navigateur ou en tant qu'application native (Adobe Air). De plus, Flex recèle un petit bijou qui s'appelle le protocole AMF3 qui est binaire et plus performant que JSon qui vient du monde Javascript. En résumé, si pour la vidéo ou les bannières de pub je ne vois plus l'intérêt de Flash (même s'il a rendu de bons et loyaux services dans le passé), il reste quand même très intéressant pour les domaines plus professionnels.

avatar momo-fr 13/12/2011 - 00:58

@Alios "Ah on va encore avoir droit au commentaires basiques du style: steeve avait raison" Je n'irais pas jusqu'à dire que Steve avait raison, mais sa vision était la bonne… Lol

avatar Macleone 13/12/2011 - 01:31

[quote]le couple H.264/AAC qui sont propriétaires[/quote] Ce sont des standards ouvert. Payant certe, mais ouvert quand même. [edit]Au temps pour moi. Apparemment, la définition de "standard ouvert" diffère entre les US et l'Europe, ou en Europe elle inclus la notion de gratuité[/edit]

avatar Kinky 13/12/2011 - 01:40

@ Arnauld : Excellente analyse une fois de plus. Merci à toi. ;') Le HTML et Flash sont complémentaires avant tout, et pour un bon moment encore, même si les smartphones et l'iPad peuvent présenter certaines limites.

avatar Anonyme (non vérifié) 13/12/2011 - 01:46

Trois cases qui résument à peu près tout : http://imgs.xkcd.com/comics/standards.png

avatar Gueven 13/12/2011 - 02:52

@BioSS Comment est ce possible ? C'est super fluide sur mon iPad ...

avatar Kinky 13/12/2011 - 04:15

[quote=Jiminy Panoz] N'empêche que quand on voit ce genre de choses : http://tympanus.net/codrops/category/tutorials/ Niveau code, c'est quand même très loin d'être compliqué. [/quote] Erreur, ça peut paraître simple à coder si on prends en compte l'intégration de bibliothèques comme jQuery. Mais c'est de l'intégration, pas du développement, beaucoup confondent. Dans la réalité, un site fait sur mesure demandera qu'on mette les mains dans le cambouis avec de la vraie programmation. Et là c'est beaucoup moins simple. Quand arrive le cauchemar d'optimiser le truc pour tous les navigateurs, ça devient une usine à gaz et le truc qu'on croyait pouvoir développer en 3 heures demandera des semaines. Quand Flash gère toutes les plateformes (hors smartphones/iPad), d'un coup. Les exemples que tu montres sont puissants mais limités, des effets de sliders, de couleurs, de carrousels ... C'est très bien pour une interface légère que gèrera moins bien Flash (c'est plus leur propos), mais pour l'interactivité poussée, la vraie animation (ludique, soft, cartoons ...), CSS3 et javascript montrent vite leurs limites, sauf à y passer l'année ! Flash est lourd, c'est vrai. S'il subsiste, ça n'est pas pour rien, il permet de protéger plus efficacement le contenu (c'est primordial pour les créateurs de contenus). Si on peut cracker un site Flash, le résultat est souvent inutilisable, en HTML y a qu'à se servir. Autre exemple, pour les bannières publicitaires, le format encapsulé de Flash est simple, rapide, économique. Qu'on aime ou pas, ça fait vivre des milliers de personnes, et probablement le site que vous lisez actuellement. Flash et HTML5 devront cohabiter, même si Flash a cédé du terrain sur la partie intégration (et c'est tant mieux). Si Flash disparait, il faudra trouver autre chose, le HTML5 n'étant pas la panacée que certains prétendent. La guerre Adobe/Apple n'a fait qu'un perdant : l'utilisateur final qui doit jongler entre des formats devenus incompatibles en fonction du navigateur ou de l'outil.

Pages