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.

4 commentaires sur “De l’intérêt d’optimiser les applications mobiles HTML5

  1. Attention avec l’argumentaire de Sencha, car Fastbook tourne dans le navigateur et non sous forme d’une webview et sur iOS le moteur javascript est à ma connaissance moins performant en mode webview. Il y a aussi le cout de l’optimisation à prendre en compte car l’équipe de Sencha a modifié beaucoup de choses dans son framework pour arrive à cette optimisation.

  2. Certes, mais le coût d’optimisation est à diviser par le nombre de plateformes ciblées : iOS, Android, Windows Phone, BB10, Firefox OS… Je reste fermement convaincu que les deux ne doivent en aucun être opposés, mais complétés. Idéalement, il faut trois approches : une version mobile du site (pour les mobinautes occasionnels), une application hybrides (pour les mobinautes réguliers) et des applications natives pour les fonctions à valeur ajoutée qui ont vocation à être utilisées de façon intensive.

  3. Frederic,

    cela supposerait que le layout des applications soit exactement le meme quelque soit la resolution de l’ecran du terminal mobile, ce qui n’est pas tout a fait le cas. On n’est plus du tout dans une logique « desktop » ou le navigateur se chargeait d’adapter le layout a la taille de la fenetre. On peut aussi penser que chaque plateforme cherche a uniformiser sont UX.

    Lorsque le client devient mobile et personnel, le Web n’apporte vraiment rien d’attrayant aussi bien pour l’utilisateur que le developpeur. En tant qu’utilisateur iPhone, je me fiche pas mal d’avoir la meme UX sur un telephone Android ou Windows. On n’est plus du tout dans la logique qui a fait le succes des Web Apps. Je crois que beaucoup de monde oublie ce petit detail…

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s