L’adoption de NativeClient passera par les jeux… et la bureautique

Lancé à la fin de l’année 2008 en catimini, NativeClient évolue sous le radar depuis un certain nombre d’années. Plusieurs raisons expliquent le peu de moyens déployés par Google pour communiquer sur son produit : une technologie complexe à expliquer (donc des bénéfices difficiles à appréhender pour les non-initiés) et une crainte de voir se reproduire la déroute de Google Wave, qui était pour tant un produit exceptionnel. Bref, NativeClient est la technologie “révolutionnaire” de Google dont personne ne connaît l’existence, mais les choses pourraient bien changer par le biais d’une acquisition récente.

Si j’avais été très sceptique au lancement de NaCl (Native Client, la technologie RIA de Google qui risque de faire long feu), c’est que les conditions de marché n’étaient pas très favorables et que les équipes de Google n’ont pas non plus dévoilé une feuille de route parfaitement claire et cohérente. En résumé : l’intérêt de faire tourner du code natif dans le navigateur en 2008 était plutôt limité. Impression confirmée il y a deux ans lors d’un second lancement officiel (Pourquoi Google a deux ans de retard avec Native Client). Je vous rappelle qu’à cette époque nous étions en pleine montée en puissance des terminaux mobiles et que le gain de performance promît par NaCl pour les processeurs x86 n’était encore une fois pas très vendeur (HTML5 était nettement plus sexy).

Nous sommes maintenant en 2013 et les terminaux mobiles ont envahi le monde (smartphones, tablettes, ultrabook…). Quasiment la totalité des internautes est équipée de terminaux mobiles et les utilisateurs veulent accéder aux mêmes services qu’avec leur ordinateur, ils ont donc besoin de puissance et le récent portage de NaCl sur les processeurs de famille ARM prend tout son sens (Native Client support on ARM). Grâce à NativeClient, les développeurs ont donc la possibilité de créer des applications en code natif qui exploitent directement les ressources de la machine (processeur et puce graphique) sans déperdition de puissance. La promesse est belle, mais elle est difficile à tenir, car la puissance se fait au détriment de la simplicité. En d’autres termes, il faut être talentueux et motivé pour mettre en oeuvre la technologie et profiter de ses bénéfices. D’autres éditeurs ont fait la même promesse, mais il semble que NaCl soit mieux cadré et plus rigoureux (Google Chrome Native Client compared with plugin or extension).

La stratégie de Google a donc été dans un premier temps de mobiliser la communauté des développeurs de jeux pour démontrer l’intérêt de NaCl : Games, apps and runtimes come to Native Client. Un certain nombre de jeux et démonstrations techniques sont donc sortis ces derniers mois, avec des authentiques succès comme AirMech (cf. AirMech Review).

L'interface de AirMech sous Chrome
L’interface de AirMech sous Chrome

Il existe aujourd’hui une petite vingtaine d’applications disponibles dans la galerie et les avis semblent converger : NaCl ouvre de formidables opportunités, mais requiert de gros efforts (The Ins and Outs of Native Client et The trouble with Google Chrome’s Native Client). Qu’à cela ne tienne, ils ont tout prévu : Gaikai ported to Chrome Native Client, which is a bigger deal than it sounds.

Tout ceci est très intéressant, mais les jeux en ligne sont un marché limité, même si on l’étend aux terminaux mobiles. La seconde étape du plan de Google est maintenant de s’attaquer au marché des applications d’entreprise où il y a de bien plus grosses sommes d’argent en jeu : Google Ports Quickoffice To Chrome Using Native Client, Will Get Full Editing Features In About 3 Months. L’arme secrète de Google est donc de proposer un environnement “léger” de création et d’édition de documents bureautiques exploitant la puissance de NaCl et distribué sur iOS, Android et Chrome. Autant des réalisations comme AirMech permettent de crédibiliser NaCl auprès des développeurs d’application, donc une petite audience ; autant QuickOffice est la clé d’entrée ultime de Chrome dans le monde de l’entreprise.

L'interface de QuickOffice sous Android
L’interface de QuickOffice sous Android

J’ai toujours été sceptique quant au succès de NaCl, mais son portage sur les processeurs de famille ARM (qui équipent l’ensemble des terminaux mobiles) et cette future nouvelle version de QuickOffice changent carrément la donne. Je suis persuadé que la prochaine conférence Google I/O le mois prochain sera l’occasion de donner un second souffle à NativeClient et surtout de déployer un levier de différenciation imparable. L’enjeu étant bien plus important que des jeux en ligne plus rapides (un autre article en préparation sur ce sujet).

De l’intérêt d’optimiser les applications mobiles HTML5

Souvenez-vous, en septembre dernier, le patron de Facebook jetait un pavé dans la marre en déclarant qu’ils avaient fait fausse route en choisissant HTML5 pour leur version mobile et qu’ils allaient corriger le tir avec une application mobile native : Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5. Un terrible coup pour tous les supporters de HTML5, qui a été enfoncé quelque mois plus tard avec la livraison de la version Android (Facebook Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively Just Like The iOS Version). Suite à cette “défection” d’un des plus gros sites de la toile, le débat était relancé sur la supériorité des applications natives par rapport à leur version utilisant HTML5 (Don’t Make The Same Mistake As Facebook: Why Brands Cannot Rely On HTML5).

Pour vous la faire simple, les discussions tournaient encore et toujours autour des mêmes arguments : les applications natives coûtent plus cher, mais sont plus performantes que leur équivalent en HTML5 qui facilite le déploiement, mais proposent une expérience bien moins riche. La performance et l’expérience utilisateur étaient donc au coeur de ce débat qui semblait pencher en faveur des très exigeants adorateurs de la marque à la pomme. Pourtant, les dernières statistiques ne donnent pas raison aux ayatollahs des applications natives (Android régnera sur le marché des smartphones en 2013, mais ne sera pas seul). D’autant plus que, comme le fait très justement remarqué Ryan Stewart, “it never pays to bet against the web” (Don’t Settle for a Mediocre HTML5 App Experience).

Nous en étions là dans ce débat complexe à appréhender, quand les équipes de Sencha nous ont livré un argument mettant définitivement fin aux discussions : une application HTML5 parfaitement optimisée peut être plus performante qu’une application native et délivrer une expérience similaire (The Making of Fastbook: An HTML5 Love Story). Le résultat est une application HTML5 disponible en ligne ici : Fastbook.

Comparison de l’application native Facebook et de Fastbook

Les explications sont assez techniques (l’astuce consiste à filtrer le flux pour éviter de gâcher la bande passante), mais le résultat est très convainquant comme en témoigne la vidéo ci-dessous :

À partir du moment où l’adoption de HTML5 pour les applications mobile ne se fait pas au détriment de la performance, le choix est beaucoup plus simple à faire, d’autant plus avec les frameworks hybrides : How Hybrid Apps Are Accelerating HTML5 Adoption. Entendons-nous bien : le choix de HTML5 n’est pertinent que si vous devez étendre la présence d’une marque ou d’un service sur les terminaux mobiles. Si votre objectif est de lancer un service uniquement accessible sur smartphones Apple (comme l’était Instagram à l’époque), le contexte est très différent. Dans tous les cas de figure, le débat est enfin apaisé et nous sommes revenus à un niveau de discussion beaucoup plus sain où les arguments rationnels l’emportent : Why HTML5 Should Replace Native Apps for Ecommerce.

Moralité : Si nous sommes tous d’accord pour dire que l’idéal est que tous vos clients soient verrouillés au travers d’une application mobile native, il faut savoir revenir à la réalité du marché et reconnaitre que toutes les marques ou services en ligne ne peuvent imposer l’installation d’une application, car le temps, la motivation, les connaissances et la capacité de stockage des smartphones des utilisateurs sont limités. À partir de là, la meilleure approche est de commencer par servir le plus grand nombre d’utilisateurs avec une solution hybride qui comblera aisément les usages ponctuels. C’est votre priorité, car le développement et le déploiement de x applications mobiles natives vont devenir des tâches de plus en plus complexes et coûteuses.