Michael Chaize (Adobe) "HTML5 ne va pas remplacer Flash"

Arrêt de Flash sur le mobile, commercialisation d'une offre pour HTML5, développement d'une culture Open Source... Adobe s'oriente vers une mutation profonde de sa stratégie.

JDN Solutions. Pourquoi avoir arrêté le Flash sur mobile ?

Michael Chaize. Nous avons en effet décidé de mettre un terme à la R&D du lecteur Flash dans sa version pour smartphones et tablettes. Jusqu'ici, les applications Flash pouvaient s'exécuter de deux façons sur les terminaux mobiles : directement en Flash, comme c'est le cas sur Android ou Playbook, ou par le biais d'une application native compilée en fonction de l'environnement du terminal. Même si nous ne maintenons plus le lecteur Flash pour le mobile, la deuxième possibilité restera cependant toujours possible.

Nous avons pris cette décision pour deux raisons. En premier lieu, parce qu'Apple a toujours refusé d'exécuter du Flash en natif sur iOS. Ensuite, parce que Microsoft a annoncé qu'il n'accepterai aucun plugin au sein de l'interface Windows 8 Metro.

Mais, le lecteur Flash pourra néanmoins toujours être porté par les éditeurs de systèmes d'exploitation mobiles. Il est présent dans sa version 11.1 sur plusieurs d'entre eux, notamment Android et RIM Playbook. Par le biais de notre programme Open Screen Project qui donne accès aux sources du player, les éditeurs qui le souhaitent pourront toujours continuer à optimiser le lecteur Flash pour telle ou telle plate-forme mobile. RIM fait notamment partie de ce programme, et va poursuivre cette démarche.

Sans doute pour les raisons évoquées plus haut, nous avons aussi constaté que les agences ne choisissez pas le format Flash pour adapter un contenu riche aux terminaux mobiles, mais préféraient s'orienter vers les applications natives. Nous avons donc décidé de nous centrer sur la possibilité de compiler des applications Flash développées sous Adobe AIR en applications natives pour chaque OS mobile [iOS, Android, Blackberry / Playbook NDLR]. Nous positionnons donc Adobe AIR comme un outil de développement multiplate-forme mobile d'applications. 


"Flash et HTML5 ne s'opposent pas, mais sont complémentaires."

Le retour d'expérience de Machinarium par exemple valide ce choix. Ce jeu en Flash qui avait été un gros succès sur PC et Mac a été converti en application native pour iPhone et iPad. En quelques jours, il s'est retrouvé en tête des applications payantes les plus téléchargées dans l'AppStore dans 14 pays.


Mais, votre choix ne s'explique-t-il pas non plus par des problèmes de performance du Flash sur les mobiles ?

Non. Sur Android comme sur Playbook, les applications Flash ne posent pas de problèmes de performance particuliers. La problématique porte plutôt sur l'adaptation des contenus aux caractéristiques du terminal mobile. Mais, notez que la question est exactement la même pour HTML5.


Justement, comment positionnez-vous HTML5 vis-à-vis de Flash ? On a parfois du mal à comprendre la posture d'Adobe en la matière ?

C'est la question qui suscite le plus d'émotion. Nos concurrents soutiennent que HTML5 va remplacer Flash. Pour nous, les deux technologies sont complémentaires. Avec Flash, nous avons historiquement poussé l'innovation sur le Web, en proposant une technologie d'applications Internet riches qui a toujours été en avance. HTML5 prend une direction similaire, ce qui est une excellente nouvelle, mais avec une mise en œuvre beaucoup plus lente du fait du processus de standardisation du W3C. Avec Flash, nous intégrons désormais un moteur 3D, et bientôt le multithread. Quand, nous le décidons, nous pouvons intégrer immédiatement une innovation, là où HTML5 mettra plusieurs années à le faire.

HTML5 représente une opportunité supplémentaire pour les créatifs, il a l'avantage d'être standard. C'est dans cette optique que nous avons lancé Edge. Cet outil de création graphique d'animations HTML5 sortira en version finale courant 2012.

Nous accompagnons d'ailleurs aussi les développements des standards HTML5 et CSS. Adobe a notamment soumis une quinzaine de spécifications au W3C : CSS Region qui permet de gérer un flot de texte sur trois colonnes comme on peut le faire dans InDesign, ou encore CSS Shaders pour gérer des effets de flou ou d'ombre portée.

Pourquoi avoir transmis Flex à la fondation Apache ?

Notre culture d'éditeur propriétaire ne correspondait plus aux besoins de nos clients Flex. Cet environnement de développement est utilisé pour créer des applications métier souvent critiques, notamment dans le domaine bancaire et du trading. Avec à la clé des intégrations avec les plus grands progiciels de gestion intégrée, comme SAP par exemple. Il est par conséquent important que nos clients puissent participer directement au développement du framework.


Notre culture propriétaire ne correspondait plus aux besoins de nos clients Flex

D'où l'idée de l'ouvrir. Cette démarche a été réalisée par étape. Avec Flex 2, nous sommes d'abord passés à un modèle gratuit. A partir de la version 3, l'infrastructure est passée en Open Source, sous la Mozilla Public License. Cette phase a permis aux développeurs de mieux comprendre les dessous du framework en ayant accès aux sources, mais aussi d'opérer un premier niveau d'adaptation.

Mais, nous gardions la main sur la feuille de route, et les clients et partenaires n'avaient pas la possibilité d'intervenir sur la gouvernance principale. Notre posture était celle d'un éditeur Open Source, avec des nouveautés contrôlées par nous et utilisées pour réaliser des effets d'annonce. Ce qui a été le cas par exemple avec Flex 4.5 et les possibilités que nous avons dévoilées en matière d'exportation d'applications vers iOS ou Android.

Il y a environ un an nous avons estimé que Flex était suffisamment mûr et sa communauté suffisamment puissante pour passer un nouveau cap avec le lancement de la fondation Spoon. Cette structure d'Open Gouvernance avait pour vocation d'organiser le travail et les contributions de la communauté, sans néanmoins donner la possibilité de faire un fork, le dispositif de gouvernance défini impliquant des mises au point régulières avec Adobe pour arrêter les évolutions. Le passage de Flex sous l'égide d'Apache est donc la dernière étape de la démarche.


Pourquoi Apache, et comment allez-vous collaborer avec la fondation ?

Nous avons acquis en 2010 Day, et son CMS CQ5 qui s'adosse à des briques Apache. Nous sommes depuis devenus de fait l'un des principaux contributeurs de la fondation. Plus récemment, nous avons acquis PhoneGap et son framework de développement multiplate-forme mobile que nous avons donné à Apache. Cette collaboration avec Apache s'inscrit donc dans une démarche cohérente.

Avec Flex, nous avons aussi fait don à la fondation du middleware Java orienté messages BlazeDS, du compilateur MXML et ActionScript Falcon, ainsi que des développements secrets de Flex 5 qui étaient en cours au sein de notre R&D.

Désormais, c'est Apache qui va chapoter le projet Flex. Trois forces vives seront amenées à intervenir : Adobe, la communauté des développeurs au travers de Spoon, et enfin les clients entreprises. Une réunion va être organisée en décembre pour préciser cette organisation.


Michael Chaize est consultant Flash chez Adobe Systems pour la région Europe, Moyen-Orient et Afrique.

Framework / Flash