Pourquoi j'ai choisi de me passer de l'App Store et de l'Android Store
Réaliser une application mobile et la diffuser sans proposer le téléchargement via l'un des principaux Stores ne va pas de soi, mais comporte plusieurs avantages et finalement peu d'inconvénients. Mes arguments en faveur de la “web-app”.
Mi-avril, LinkedIn faisait marche arrière : après avoir adopté l'HTML 5 pour ses applications mobiles, le site revenait à des applications dites “natives”, c'est à dire propres à chaque système mobile (iOs, Android, etc.).Cette annonce est venu contredire une tendance de plus en plus forte, à laquelle je souscris, qui consiste à mettre en avant les atouts des “web-app”, ces applications écrites en HTML5, et donc indépendantes du système mobile, aux fameuses applications natives distribuées par des Stores. Pourtant, à lire les raisons invoquées par LinkedIn, ma position reste la même et j'irai jusqu'à dire que, paradoxalement, elle se renforce.
Mais commençons par rappeler les principaux avantages de la “web-app” :
1) écrite en HTML 5, technologie parfaitement supportée par tous les terminaux mobiles (depuis 2009 pour Android, 2010 pour iOS, 2012 pour Windows Phone), elle couvre donc la quasi totalité du marché aujourd'hui.2) ne dépendant pas des spécificités d'un système mobile particulier, elle fonctionnera à l'identique (à de très mineurs détails près, facilement traitables) sur tous, et réduit donc d'autant les coûts de développement.
3) mieux encore, l'HTML5 étant le langage du Web, et les technologies dites de “responsive design” (interface adaptative) étant aujourd'hui parfaitement mûres, un site ou service Web bien conçu pourra être développé avec un seul code pour PC/Mac, tablettes, et smartphones : quel gain de temps et d'argent par rapport à la configuration où il faut maintenir une version “desktop”, une version iOS, une version Android, etc., toutes dans des langages différents !
4) ne pas dépendre d'un Store élimine également le risque de ne pas être approuvé quand, comme dans l'App Store d'Apple, ce processus existe. Même s'il y a n'a pas de risque de ne pas l'être, c'est du temps gagné.
5) Et que dire des mises à jour ? Plus besoin d'espérer que l'utilisateur effectue le téléchargement de la nouvelle version : l'utilisateur d'une web-app verra les changements appliqués exactement comme il voit la nouvelle version d'un site Web quand il s'y connecte.Jusqu'ici, ce sont des arguments que vous avez peut-être déjà entendus, mais il est possible que vous vous disiez : tout ceci ne serait-il pas une profession de foi plutôt qu'une véritable conclusion issue de l'expérience pratique ? Je vais donc vous raconter ma propre expérience, et en profiter pour évoquer les inconvénients apparents de la web-app, mais aussi aussi les possibilités de les contourner. Et je n'oublie pas le cas LinkedIn, vous allez voir.Quand il s'agit de créer une nouvelle activité, ou lancer un nouveau service, en contexte de crise, il est évident que chaque dépense compte : s'agissant d'une application Web comme la mienne (elle s'appelle Iperiago, et propose des parcours touristiques interactifs et ludiques), le coût et la barrière technologique que représentent les développements spécifiques d'applications dites “natives” amène très vite à regarder les possibilités de l'HTML5, du responsive design, et des web-apps. Et là, quelques (bonnes) surprises qui viennent s'ajouter aux arguments évoqués plus haut. Pour les évoquer, imaginons un contradicteur et les questions qu'il poserait :
Mais comment les utilisateurs vont-il installer l'application ?
Le procédé est très simple - on peut le voir en action, par exemple sur l'excellente application météo Forecast.io, ou sur l'application Iperiago. L'utilisateur se rend sur votre site Web via le navigateur de votre mobile, et un écran dédié apparaît lui expliquant comment ajouter l'application à son écran d'accueil. En 15 secondes, la web-app est prête.Les utilisateurs doivent d'abord connaître l'URL alors ? Oui, effectivement, il y a un travail de notoriété et de marketing à accomplir, mais ce travail n'est pas différent de celui qu'il faudra accomplir pour émerger dans les Stores, où les applications se noient dans l'abondance.Un seul code vraiment ? Ne faut-il pas gérer des cas particuliers à la pelle ?
Honnêtement non, côté serveur, évidemment il vous faut un seul code, côté client il vous faut des feuilles de styles adaptées pour chaque type d'écran bien sûr, mais si vous partez sur un squelette de page adoptant les principes du responsive design, le travail sera minime. Un bon intégrateur Web réalisera ceci sans problème et dans un délai très court. Attention toutefois à bien penser l'ergonomie mobile, souvent radicalement différente de l'ergonomie “desktop”. Mais de ce point vue, HTML5 ou pas, il faudra le faire de toute façon.
Et le Javascript ?
L'avantage du Javascript, c'est qu'il fonctionne partout. Oui il vous en faudra, oui il vous faudra deux ou trois classes Javascript spécifiques pour la version mobile, mais c'est bien tout, et là encore, un bon développeur Javascript vous fera ça sans problème. Pour être franc, si vos développeurs vous disent que tout cela est compliqué, vous avez un autre problème bien plus important à résoudre. “Et si les utilisateurs ont désactivé le Javascript ?”, ajoute notre contradicteur. Sur leur mobile ? En 2013 ? Avouez que c'est difficilement imaginable à une échelle où cela deviendrait un problème.Ok, mais, en mobilité, la connexion peut être instable, ou absente. Dans ce cas l'utilisateur est coincé ?Pas si vous prévoyez le coup ! L'HTML5 vous permet de disposer d'un stockage local côté client (sur le terminal de l'utilisateur) et donc court-circuite la base de données côté serveur quand cela est nécessaire. En pratique, on propose à l'utilisateur, quand il est connecté, de sauvegarder certaines pages ou parties de l'application pour un accès hors-ligne, et si la connexion se coupe, l'application bascule en mode hors-ligne et l'utilisateur accède aux pages ou parties de l'application sauvegardées, comme si il était en ligne.Tout ceci marche très bien, je vous assure. De fait, l'application Iperiago utilise cette approche pour stocker hors ligne le contenu d'un parcours et des ses étapes, et recréer les fonctionnalités interactives liées au parcours.Alors oui, le volume de stockage local est limité (5 Mo la plupart du temps), mais si vous pensez bien votre application, vous arriverez à proposer un service tout à fait cohérent et attractif à l'utilisateur avec seulement 5 Mo. D'autant qu'à ce quota s'ajoute le cache du navigateur du terminal de l'utilisateur, que l'on va utiliser pour stocker les feuilles de styles, les fichiers Javascript et les images nécessaires pour un accès hors-ligne.Alors oui, ça demande un peu de conception et de remue-méninges, mais là encore, je vous renvoie aux réponses aux deux précédentes questions de mon contradicteur imaginaire : il en faut toujours de toute façon !Enfin j'ajouterai qu'une application native peut aussi ne pas fonctionner hors ligne. Son seul atout est qu'elle dispose d'une plus grande capacité de stockage sur le terminal de l'utilisateur.
Ok, ok, mais est ce qu'une web-app peut accéder aux fonctions clés du terminal mobile (le GPS, les photos, les notifications…) ?
La réponse est… oui pour le GPS et les photos, sans aucune difficulté et sans aucun problème. D'autant que, même hors ligne, on peut le faire. En revanche, vous n'accéderez pas aux notifications. Mais… vous pouvez en envoyer vous-mêmes depuis votre application. La seule contrainte est que la notification ne pourra être envoyée que si son destinataire utilise votre application au même moment. Dans le cas de l'application Iperiago, destinée à être active tout au long d'un parcours, ce n'était pas un problème. Dans d'autres cas, examinez-bien votre besoin - je ne vois guère que ce paramètre qui puisse constituer un véritable frein.
J'ajouterai qu'il est parfaitement possible de récréer, en Javascript et en CSS, le “look & feel” d'une application native, mais je ne le recommande pas : mieux vaut recréer les bons principes ergonomiques que chercher à coller au pixel près aux standards graphiques des terminaux.
Bon, mais est-ce que les performances seront les mêmes qu'en natif ?
Si l'on lit les arguments de LinkedIn pour leur “retour au natif”, on s'aperçoit que ce sont des problèmes de mémoire vive qui sont derrière leur choix, ainsi que le manque d'outils tiers pour faciliter notamment le déboguage et les monitoring. Point barre. Eux-mêmes reconnaissent que la vitesse et la qualité de rendu ne sont pas un problème. Alors examinons cela.
Le déboguage et le monitoring ? importants c'est vrai, mais perdre du temps avec ça, c'est une problématique de développeur non ? Pas de l'utilisateur final. Le temps perdu n'est-il pas largement gagné par ailleurs.
La mémoire vive ? Dans le cas d'une application aussi complexe que celle de LinkedIn, je peux concevoir que ce soit un problème. En pratique, pour la majorité des applications, il est raisonnable de penser, sans excès d'optimisme, que l'évolution des technologies absorbera le problème avant qu'il ne se pose véritablement comme un frein.
Conclusion, une web-app offre non seulement l'indépendance à son éditeur, mais encore permet de réaliser d'importantes économies et ne représente pas de difficulté technologique majeure (très peu de moyens et de ressources sont nécessaires). Elle demande sans doute un peu plus de réflexion et de recherches en amont, mais l'essentiel du travail consiste, comme dans l'approche “native”, à réaliser un bon service et une bonne interface utilisateur. Be web-(h)app-y !