Applications Mobiles : NativeApp, HybrideApp ou WebApp?
Lorsque vous êtes prêt à lancer votre plateforme dans le monde du mobile, vous entendrez sûrement parler d’application native, de WebApp ou encore d’application hybride. Le choix du type d’application à utiliser est une décision importante, et dépend de votre stratégie en matière de contenu et de fonctionnalités.
Mais en quoi ces types d’applications sont-ils différents les uns des autres ?
- Les applications natives sont accessibles directement depuis une icône sur l’écran d’accueil d’un téléphone et sont installées depuis les différents AppStore. Elles sont développées de manière spécifique pour une plateforme et permettent d’utiliser toutes les fonctionnalités d’un téléphone, qu’il s’agisse de l’appareil photo, du GPS ou encore de l’accéléromètre. Elles prennent en charge les commandes tactiles, et répondent au mouvement du doigt sur l’écran. Enfin les applications natives peuvent utiliser le système de notification du téléphone et fonctionner hors ligne.
- Les WebApps ne sont pas des applications au sens propre du terme. Elles correspondent à des sites web reproduisant les fonctionnalités, le feeling et le design d’une application native. Elles sont interprétées par un navigateur et sont, la plupart du temps, réalisées en HTML5. Pour accéder au contenu, un utilisateur devra saisir une URL depuis un navigateur, et pourra les “installer” en créant un favori de cette page. Les WebApps ont pris de l’importance avec l’arrivée du HTML5, permettant de mimer les fonctionnalités des applications natives. De plus en plus de sites web incorporent ce mode de fonctionnement, la barrière entre les WebApps et les sites web classiques s’est amincie.
- Les applications Hybrides sont moitié natives, moitié WebApp. Comme les applications natives, elles sont uploadées sur un App Store et permettent d’accéder aux fonctionnalités du téléphone. Comme les WebApps, elles utilisent une page web pour afficher du contenu, cette page étant intégrée dans un cadre d’application traditionnelle. La plupart du temps, les applications hybrides sont des emballages pour des pages web, elles offrent une présence sur l’App store sans pour autant procéder à un développement complet d’une application. Elles sont également populaires par le fait qu’elles sont cross plateformes, le même code HTML pouvant être utilisé sur l’ensemble des OS mobiles.
Voyons en détail les facteurs permettant de comparer ces différentes solutions entre-elles.
De manière générale, il est moins coûteux de développer une application hybride ou une WebApp, les connaissances techniques étant partagées avec le domaine du web. Le développement d’une application native est souvent perçu comme beaucoup plus cher, nécessitant le recours à des spécialistes du domaine.
Il est également à noter que ces coûts peuvent être multipliés s’il est nécessaire que votre application soit disponible sur plusieurs plateformes. Cependant, le coût d’une application mobile dépend également d’autres facteurs, et une application native ne sera pas toujours la solution nécessitant le plus de fonds.
Tout d’abord bien que partageant la même base technique que le web, le HTML5 est encore relativement nouveau, et une bonne connaissance de son application dans les WebApps ou les hybrides est également une compétence avancée. Réaliser une application de qualité nécessitera toujours des développeurs ayant un haut degré d’expertise, quel que soit le type d’application, la qualité sera toujours onéreuse.
En définitive le coût va être modulé par deux facteurs.
- Le nombre de plateformes (iOs, Android, WindowsPhone, …)
- Le type d’appareils (tablette, smartphones, …)
Dès que vous avez décidé de supporter plus de 2 plateformes et plus d’un type d’appareil, le coût d’une application native devient plus important qu’une WebApp ou qu’une hybride. Cependant, même en choisissant ces deux dernières, il ne faut pas sous-estimer le coût associé à l’optimisation pour les différentes versions de navigateurs, associé à l’appareil et au fabricant.
Une des faiblesses majeures des applications natives est très certainement le manque de portabilité sur les autres plateformes, une application native est développée pour un système d’exploitation donné. C’est dans cette faille que les WebApps et les applications Hybrides se sont engouffrées, avoir une seule base de code et être capable de la faire fonctionner sur n’importe quelle plateforme mobile majeure pour les WebApps, et dans le cadre des hybrides, réutiliser la majorité du code sur chaque plateforme, et modifier ce qui peut être amené à fonctionner différemment.
Cependant, les WebApps ne sont pas réutilisables à 100%. Avec l’évolution des standards du web, des évolutions apportées au fil du temps, les navigateurs peuvent ne pas supporter certaines fonctionnalités sur tous les appareils. Le problème de compatibilité n’est donc pas l’apanage des applications natives. De même, les webviews présentent dans des applications natives sont un cas particulier et ne doivent pas être traitées comme des navigateurs, ce qui amène également d’autres problèmes de fragmentations.
Les applications natives, ainsi que les composants natifs d’une application hybride, sont entièrement compatibles avec le matériel de l’appareil. Elles peuvent donc avoir accès aux fonctionnalités d’un appareil tel que l’accéléromètre, l’appareil photo, le GPS ou encore les notifications. Les WebApps, en revanche, ne peuvent avoir accès qu’à un nombre limité de ces fonctionnalités.
En effet, les WebApps ne peuvent utiliser que les APIs les plus basiques, par exemple le GPS pour des utilisations de géolocalisation. Pour le reste elles restent très limitées dans leur accès à la partie matérielle d’un appareil. Il est par exemple impossible pour une WebApp de faire du traitement en tâche de fond ou de créer une zone de stockage sécurisée au sein du téléphone.
Cependant, de nouveaux standards sont en cours d’élaboration par le W3C dans le but de fournir plus de possibilités d’accès aux APIs. Pour le moment, les applications natives et hybrides restent les seules ayant un accès privilégié aux APIs. Dans le cas des hybrides, selon le framework utilisé, toutes n’ont pas accès à l’ensemble des APIs. Mais l’évolution de ces frameworks étant déjà enclenchée, l’accès à des fonctionnalités de base comme le gyroscope ou l’accéléromètre est d’ores et déjà possible.
En résumé, bien que les technologies du web rattrapent rapidement leur retard, les applications natives auront toujours une longueur d’avance. Certaines fonctionnalités ne fonctionnant que sous certains navigateurs sont également un problème majeur. Une seule chose restera immuable, lorsqu’une nouvelle fonctionnalité sera disponible en natif, elle ne le sera que bien plus tard via un navigateur.
Du point de vue de l’utilisateur, la majorité des WebApps et des applications natives se ressemblent et fonctionnent de la même manière, avec peu de différences. Cependant si vous souhaitez fournir un service consistant avec le système d’exploitation, ainsi qu’avoir une application dont le design ressemble à ceux des applications phares, il est bien plus simple de réaliser cet aspect via une application native.
Il ne faut pas pour autant ranger les WebApps au placard. Elles peuvent fournir une expérience utilisateur tout autant satisfaisante qu’une application native ou hybride. Mais il est à noter que des différences d’ordre graphique existeront et ne correspondront pas tout à fait au cadre auquel un utilisateur est habitué
Les frameworks de design pour des WebApps et ceux des applications hybrides s’efforcent à créer des composants proches de l’esprit de ceux des applications natives. Cependant ces frameworks doivent rester constamment à jour, les nouvelles versions d’Android ou iOS s’accompagnent souvent d’une refonte graphique importante. Ainsi il n’est pas rare de voir des WebApps conservant un style iOs 6.
Parfois c’est également la façon dont les composants sont interprétés par un navigateur qui va permettre de différencier une WebApp. Par exemple, sur iOs7, lorsque le composant UIWebView est utilisé, la génération du bitmap aura un rendu différent du même composant utilisé dans une application native. De plus, certaines fonctionnalités purement graphiques sont complexes à réaliser en JavaScript, ainsi l’effet de “rebondissement” une fois arrivé à la fin d’une page sur iOs ne peut être reproduit. Ces différences poussent certains développeurs à prôner la réalisation d’un design original pour les WebApps, plutôt que d’essayer de recréer une interface native qui pourrait sembler mal réalisée pour un utilisateur lambda.
Une application réalisée avec le langage natif d’un système d’exploitation sera toujours la voie la plus rapide et sûre pour atteindre un certain niveau de performances. Facebook ou encore Wikipédia l’ont bien compris en transformant leurs applications hybrides en natives, en 2012 Mark Zuckerberg a notamment avoué que Facebook avait commis une grave erreur en pariant sur le web mobile et de ne pas prendre la route du natif.
Cependant les applications hybrides et les WebApps ne sont pas pour autant des usines à gaz incapables de fournir une expérience fluide à un utilisateur. Facebook et Wikipédia étant des cas à part si l’on considère le volume de données brassé sur leurs serveurs ne serait-ce que pendant une journée.
Les hybrides ne sont donc pas des modèles de lenteur, bien qu’elles puissent souffrir de ralentissements selon la manière dont le code va être interprété par l’OS. Les WebApps, quant à elles, ne sont pas non plus désuètes. Avec une approche moderne du développement web, tels que appcache, des moteurs JavaScript de plus en plus puissants au sein des navigateurs, ainsi que la démocratisation de la 4G permettant l’accès à du contenu plus important, les performances de ces applications sont en constante évolution.
On pourrait penser que publier une application native ou hybride sur un “App Store” est un processus facile et permet une meilleure visibilité qu’une simple WebApp. Cela n’est pas tout à fait vrai, en effet le référencement d’une application est un problème tout aussi important que le référencement d’une page web.
Une application présente sur un store va également être confrontée aux notes d’utilisateurs et aux commentaires visibles directement sur la page de téléchargement. Cela est à la fois une force et une faiblesse, une application mal notée dès le départ aura peu de chance de décoller par la suite. La publication d’une application doit également suivre un processus plus ou moins strict selon les plateformes, ralentissant sa disponibilité immédiate. (La publication d’une application sur l’AppStore d’Apple peut prendre plusieurs semaines).
Une WebApp ne pourra donc pas profiter de tout l’aspect marketing généré par un App Store. Il faut également rappeler que contrairement à une application installée sur un téléphone, l’utilisateur doit prendre l’initiative de créer un marque page sur son téléphone pour revenir rapidement sur la WebApp.
En définitive ce qui va réellement importer est votre stratégie marketing et comment vous allez faire en sorte que des personnes découvrent votre application. Qu’il s’agisse de publicité payante, ou encore d’une campagne de pub via les réseaux sociaux, il s’agit de la pièce la plus importante du puzzle pour des applications cherchant à drainer des utilisateurs. C’est donc votre stratégie marketing qui imposera souvent une voix plutôt qu’une autre.
Une WebApp sera toujours plus dynamique qu’une application en terme de mise à jour de contenu et de flexibilité. Cela s’explique tout simplement par le fait que les mises à jour d’applications ne sont pas forcément automatiques, alors qu’une WebApp peut être redéployée ou modifiée comme n’importe quel site web. Les applications hybrides peuvent cependant être modifiées sur certains points sans devoir repasser par une mise à jour via le store, mais d’une manière générale les applications natives et hybrides doivent toujours passer par le système de publication du store.
Une mise à jour de l’application signifie également que les utilisateurs doivent la télécharger, il est alors possible que certains utilisateurs décident d’ignorer la mise à jour et par conséquent avoir plusieurs versions différentes de votre application au même moment.
Enfin, dernier aspect non négligeable, la monétisation de votre application / WebApp. Tout comme un site web, vous pouvez ajouter des publicités ou encore un mode d’abonnement sur votre WebApp, cependant, cela sous-entend mettre en place votre propre système de paiement ou d’abonnement.
Les applications natives et hybrides fonctionnent sous un modèle bien défini. Les méthodes sont définies par les AppStore eux mêmes, avec généralement la possibilité de créer des achats au sein de l’application, la gestion des pubs intégrées ou encore l’achat de l’application en tant que tel. Cependant sur chaque vente réalisée, un pourcentage doit être reversé à la plateforme (généralement autour des 30%). Il est également à préciser que pour déposer son application sur le store, il est nécessaire de payer une licence.
Décider de créer une application native, hybride ou une WebApp dépend de nombreux facteurs. Allant des objectifs financiers, au public cible en passant par des spécificités techniques.
Si vos objectifs sont plus axés sur du marketing, ou si votre but est de mettre en place du contenu et d’établir une présence sur le mobile pouvant être facilement partagée entre utilisateurs et répertoriée sur les moteurs de recherche, une WebApp semble être le choix logique.
Si, en revanche, vos objectifs sont d’offrir une expérience interactive avec vos utilisateurs, ainsi que de mettre en place une application dont le fonctionnement ressemble davantage à un logiciel d’ordinateur qu’à un site internet, alors une application native ou hybride est probablement le bon choix.
Toutefois rien ne vous empêche de faire les deux: application native et la WebApp. Certaines sociétés, tel que Facebook, ont ce choix, de manière à drainer le plus d’utilisateurs possible. Cependant, pour la majorité, les contraintes de ressources et de budget imposeront le choix d’une seule voix ou de prioriser la solution à développer en premier.