Passer au contenu

Applications “natives” contre les WebApps : forces et faiblesses

Retour sur la notion de « web-app » et d’applications « natives » Les applications natives correspondent aux applications téléchargeables sur les différents Stores. Elles sont…

Retour sur la notion de « web-app » et d’applications « natives »

Les applications natives correspondent aux applications téléchargeables sur les différents Stores. Elles sont construites sur des langages dits « natifs » (JAVA, Objective-C…).

Les WebApps sont des sites créés et optimisés spécialement pour l’affichage sur mobile. Elles sont accessibles à partir de n’importe quel navigateur mobile et sont construites à partir de technologies web, dont le fameux HTML5.

Quelle est la meilleure alternative ?

L’arrivée du HTML 5 a bouleversé le paysage de la mobilité. Cette nouvelle technologie web a permis aux WebApps de s’étoffer en termes de contenu : les WebApps peuvent désormais accéder à environ 80% des fonctionnalités liées au terminal (accéléromètre, appareil photo…), ce qui réduit l’écart technologique entre les deux solutions.

Certains analystes évoquent même la mort prochaine des applications « natives » au profit des WebApps. Qu’en est-il réellement ? Voici un tour d’horizon (non exhaustif) des forces et faiblesses de chaque solution.

webapp_mobileapp

Les WebApps

– Forces :

Contrairement aux applications « natives », les WebApps disposent d’un code unifié, modifiable, et surtout accepté par tous les navigateurs.

L’intérêt est donc de réduire de façon considérable les temps de développement et donc les coûts globaux du projet.

Par ailleurs, dans le cas de l’iPhone, votre WebApp ne sera pas soumise à l’étape de validation d’Apple, qui est souvent longue et difficile (les cas de rejets étant très fréquents pour les premiers projets).

– Faiblesses :

Comme tout site web, les WebApps ne sont pas accessibles si le terminal n’est pas connecté au web. Cet argument de poids n’est plus forcément vrai avec l’arrivée d’HTML5, qui de par sa gestion du cache très puissante, permet de continuer à accéder à la WebApp après que l’utilisateur se soit connecté une fois.

Le biais vient plutôt des problèmes de performance liés aux technologies web. Les langages « natifs » sont des langages orientés objet qui offrent une puissance capable de faire tourner des applications très lourdes et complexes.

Enfin, il convient de signaler que certaines fonctionnalités du téléphone sont encore inaccessibles aux WebApps (telles que l’annuaire ou le calendrier).

Les Applications Natives

– Forces :

Les défauts des WebApps correspondent aux avantages des applications natives.

Celles-ci sont capables d’afficher du contenu en étant en mode avion, et offrent à l’utilisateur une expérience enrichie, car pouvant utiliser toutes les fonctionnalités de l’appareil.
Dans la même idée, le contenu y est optimisé au maximum pour la mobilité : la plupart des développeurs sur mobile cherchent aujourd’hui à s’affranchir du modèle web pour proposer une navigation complètement adaptée au tactile.

Autre avantage de taille d’un point de vue marketing : les applications natives permettent d’adopter les nouveaux modèles économiques de type « Freemium » (application de démo + contenu téléchargeable) et permettent de disposer d’une plateforme de distribution dédiée (les différents Stores).

– Faiblesses :

Les applications natives ne sont utilisables que pour un type de terminal uniquement. Ainsi, elles sont beaucoup plus longues et chères à faire développer.
De plus, avec la sortie de nouveaux systèmes d’exploitation chaque année, des problèmes de rétrocompatibilité peuvent se poser. Il faut assurer la maintenance de l’application sur la durée, ce qui augmente les coûts de développement.

Conclusion

Certaines études montrent que les utilisateurs de smartphones ont tendance à préférer les applications mobiles : ils passent en moyenne 81 minutes par jour sur des applications contre 74 minutes sur un navigateur.
Les applications offrent une meilleure « user experience » de par leur contenu optimisé et leurs performances qui assurent une qualité d’ensemble supérieure. Les WebApps sont à envisager pour des projets plus légers ou comme versions optimisées de sites web classiques.

Article écrit par Guillaume Lanthier, chargé de web marketing chez Qualia Systèmes.
Qualia Systèmes est spécialisé dans le développement d’applications iPhone, iPad et Android et de solutions professionnelles pour les grands comptes.

🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.

29 commentaires
  1. Code unifié pour les webapps il faut voir. Certaines propritétés de l’HTML5/Css3 ne marchent pas sur tous les OS (oui, WP7-8 je te pointe du doigt) ce qui oblige à faire des “hacks” voir même des concessions qui vont limiter l’attrai de ce type d’application.
    De plus, les composants webview (pour les webapp embarquées, qui elles peuvent fonctionner offline) des différents OS sont beaucoup plus limités et lents que le navigateur (essayez une application phonegapp pour voir).
    Enfin, les différentes guidelines metro/android/ios poussent à penser les applications différemment selon les plateformes ciblées car l’utilisation et la logique ne sont pas les mêmes.
    Donc le natif reste définitivement le meilleur choix.

  2. @throrin: C’est un très bon raisonnement mais c’est pour aujourd’hui. Dans quelques mois déjà, on aura 2 voir 3 OS de plus pour smartphone avec ce que ça peut amener comme morcèlement. Certaines boites pourraient choisir de passer au html5 pour la plupart de leurs apps.
    Dans le futur, j’imagine que le html5 va être de plus en plus adopté et ça lui permettrait de passer devant d’un point de vue business. D’un point de vue performance je vois mal comment ça pourrait être mieux en language web…

    En fait cette comparaison est un peu foireuse parce que les utilisations d’app natives ou web ne sont simplement pas les mêmes suivant le produit ^^

  3. 1) Java c’est pas du natif
    2) Les webapps, c’est pas que pour mobile.. ca marche aussi sur PC, console etc etc. Sisi.
    3) Croire que les webapps c’est “unifié”.. HAHAHAHA. N’importe quel dev web te dira que oui, il faut coder le machin pour tout les browsers qui implémentent “à leurs sauces” le standard (voir ne l’implémente pas..)
    4) On peut utiliser les webapps sans internet, cf HTML5

    C’est vrai qu’un apps native est plus chere à produire, elle est aussi de bien meilleurs qualité (97% des cas..). C’est pour ca qu’on voit de plus en plus de soft web/émulé: parcque c’est rapide à produire. Une merde vite fait, bien fait, dirait certains.

    Franchement, ca fait beaucoup de lacunes dans cet article..

  4. 😮 Il y a un point de comparaison qui est oublié et pourtant crucial. La rapidité d’execution des app. natives face aux WebApp.

    Exemple: on n’a vu ce que c’était Facebook avant (web app) et après.

  5. Ou les vrai choix (hors jdn style avec un article tourné promotion de ce que fais une boite) : avoir un code cross plateforme grâce a des outils comme Mono…

  6. Article rédigé par un “chargé de web marketing”…. nan mais sérieux … feraient mieux d’interroger un dev..

    En tt cas l’actionscript marche bien pour faire la plupart des appli sur android aussi bien que sur ios (un seul code).

    En se renseignant un peu on est vite surpris du nombre de grosses boites qui ont opté pour cette solution 🙂

    En tt cas, ce qui est sur c que l’ami Jobs c bien foutu de notre gueule, ilo n’a aucun interet a voir venir le html5…

    Mais bon les moutons ont courus. “ué flash ca rame trop”, “ué c trop lourd”…. pssss

  7. @titi : c’est pas le fait que l’application soit codé de manière native qui la rend plus fluide, c’est le fait qu’elle ait été bien codé cette fois-ci. La société Sencha a recréé la même application en HTML5 tout aussi fluide que l’application native, ça s’appelle Fastbook et c’est dispo ici : http://fb.html5isready.com/

  8. D’un point de vue économique le développement d’une web app coûte moins cher que de faire une application native pour chaque système. Après, le développement d’une application native reste logiquement le meilleur choix. Tout dépend de l’application a développer, les deux méthodes se complètent.

  9. qeb: quelque part si, car le code est entièrement adapté et surtout optimisé pour le téléphone en question. Facebook l’a bien reconnu.
    Et faire de la pub c’est pas bien.

  10. Pour ma part l’arrivée de firefox os va booster les webApps. Steve jobs a crée l’iPhone et le système fermé qui suit avec; google a fait le suiveur alors qu’il fallait se concentrer sur le développement des WebApps pour parer à iOS. De mon point de vue, la plupart des applications qui se trouvent dans les smartphones ne servent que peu.
    Dans un smartphone/tablette, hormis les apps, Mail, Navigateur, Agenda, Alarme, SMS,Lecteur vidéo, Google map,(+1 ou 2 jeux) tout le reste c’est pas la peine…pour rester productif.
    +1 pour les WebApps et +100 pour FireFox OS.

  11. @iboueur : sauf que, a l origine iOS ne devait accepter QUE des applis HTML5. L’AppStore et la possibilitée de créé des app natives ne sont apparus qu’en 2008. C’est d’ailleurs pour qu’il y a eut les premiers “jailbreak”.

  12. Perso je n’utilise quasi jamais les webapp je les trouve mal faites et tees limites puis l’expérience user est grandement réduite ! Il y a désormais une application pour tout sur presque tout les store ! J’utilise même Google Now pour mes recherches

  13. Pour FaceBook j’utilise la version mobile de leur site et ça fonctionne très bien. Il n’y a que deux applis mobile qui m’ont bluffé : iGag (pour lire 9gag) avec les récentes améliorations et G+.
    Un autre aspect est que je suis toujours suspicieux sur les applis du store, on peut facilement planquer des trucs désagréables dedans : Facebook par exemple m’avait piqué tous mon répertoire téléphonique sans que je le sache.

  14. A ajouter
    Pour les appli natives
    -maj à faire pour l’utilisateur
    +plus réactive avec des effets candy eyes propre à l’os

    inverse sur appweb.

    Dans les 2 cas gérer la taille de l’écran.

    Sachant que l’on peut exécuter du code natif dans un navigateur (chrome par exemple), je pense que la différence entre les 2 va se rétrécir.

    (et il y a des app native qui ne marchent pas en mode avion…)

  15. Ce n’est pas ton première article sur la présentation d’alternatives au natif pour le développement mobile, et déjà dans ton premier article tu ne mentionnais pas la technologie Flash (Flash ou Flex).
    Et malgré pas mal de commentaires qui mettaient en avant cette techno (une vrai alternative hybrid au natif), tu n’en parles toujours pas… décidément tes articles sont incomplets et pas très objectifs…

  16. Agenda et annuaire non supportés par les webapps ? Ça m’étonnerai: voir Firefox OS qui gère toutes ses apps système en HTML5

  17. “Par ailleurs, dans le cas de l’iPhone, votre WebApp ne sera pas soumise à l’étape de validation d’Apple”

    Je sais pas, mais ça sent la mise à jour ios… non ? Quel manque à gagner pour apple, beaucoup trop pour eux.

  18. Cet article ne fait que survoler le sujet et enfoncer quelques portes ouvertes qui le sont depuis des années.

    Il existe de nombreuses alternatives au développement natif, des outils qui permettent le développement multi-plateforme à partir d’un seul code source (PhoneGap, Titanium, Adobe AIR, …) et qui permettent de réduire les coûts de développement pour au final obtenir un équivalent du natif.

    Pour travailler au quotidien avec la technologie AIR, je peux assurer que les performances s’améliorent grandement de versions en versions et qu’on a maintenant quelque chose de très proche du natif en terme de fluidité.

    Et pour ce qui est du HTML5, cela me fait toujours bien rigoler de lire que l’on peut accéder à 80% des fonctionnalités du téléphone. Cela est peut être vrai pour certaines plateformes, mais c’est loin d’être le cas générique selon l’OS et le navigateur utilisé.

    Et surtout par pitié, arrêtez d’écrire des articles incomplets et désinformateurs sur des sujets que vous ne maîtrisez pas car vous ne rendez pas service au gens.

    A bon entendeur, salut !

  19. @qeb je n’avais pas entendu parlé de fastbook, je viens de le tester sur mon Galaxy S3 et vraiment j’ai trouvé ça impressionnant !!! Comme quoi on peut vraiment faire des trucs efficace en HTML5 !!!

  20. Je suis developpeur sur ios entre autre, j’ai une longue et malhereuse experience avec le HTML5 (le combo jquerymobile+phonegap), pour vous donner un example, il m’a fallu 12 jours pour faire en native et en mieux se qu’une equipe de 3personnes a faite en 1 moi, pourtant l’app etait relativement simple.
    Tous sa pour dire qu’a un moment donné il a fallu que je choisisse entre commecer à developper sur android en native ou en HTML 5 et mon choix etait claire —> native.
    Sa n’engage qye moi biensur 😉

  21. Les applis native c’est tellement mieux. Ça permet de retourner au bon vieux temps des premiers micro, chacun ses applis, pas de compatibilité… Ça permettra également à l’OS le plus diffusé [pas forcément le meilleur] d’être chaque fois plus un monopole au détriment des autres (vous avez dit windows ?).
    Non mais sans rire, à part quelques applis qui ont un besoin crucial de vitesse ou d’accès à des caractéristiques très particulières du mobile, une webapp convient très bien (soit 90% des cas).

  22. Dommage que l’article soit incomplet. C’est le genre de sujet où il faut aller en profondeur et pas seulement sortir quelques avantages et inconvénients… Enfin bon venant d’un non-développeur cela ne m’étonne pas.

    Il faut prendre en compte plusieurs aspects.
    D’abord qu’une webapp tourne aussi sur d’autres plateformes que android/iOS (cfr. Commentaires précedents)

    Ensuite, il faut voir d’où l’on vient et l’évolution qu’il y a eu en terme de technologies web : avancées de l’html5, nombre de frameworks web dispos, etc. Il suffit de voir l’évolution des possibilités de l’html5 ces 2 dernières années… Enorme!
    A l’heure actuelle, on ne peut pas faire autant en webapp qu’en natif, il est vrai. Et même si on est loin de l’égalité, on y tend. Et on y arrivera plus vite que certains ne le pense…

    Redmarks : la vitesse de développement n’est pas que question de technologie mais aussi d’expertise…j’ai plus de 10 ans d’expérience Dev web. il me faudrait beaucoup de temps pour développer à même vitesse en natif…

    Il faut également considérer L’aspect maintenance des applis Ainsi que les rétrocompatibilités

    Le besoin de la connexion devient de moins en moins un critère. Dans 5 ans, nos enfants auront tous a 14 ans un smartphone avec data (peut être même illimité). Qui pensait il y a 10 ans que toutes les consoles d’aujourd’hui auraient une connection?
    De plus, on l’a dit, l’html 5 gère bcp mieux le hors connexion.

    Pour ce qui est du point de vue de steve jobs sur la question, il a beau ne pas avoir que des bons cotés, il s’est quand même rarement gouré sur l’avenir 🙂

    bref, cet article est sujet a troll 🙂

  23. Même si l’article est effectivement incomplet, sa conclusion est à retenir. Je suis un peu surpris que l’on ne prenne pas ou si peu en compte l’usage que font les utilisateurs de leur smarpthone lorsque l’on compare les Applications natives avec les webapps. Lorsqu’on lance un tel projet, l’objectif n’est-il pas de répondre à un besoin d’utilisateur ? Or comme le montre de nombreuses études, les mobinautes plébiscitent majoritairement les applications mobiles par rapport aux webapps. Prenons l’exemple de l’Etude Mobile Marketing Attitude conduite par l’atelier Mobilité du Syndicat National de la Communication Directe datant de 07/2012, les utilisateurs d’iPhone préfèrent les applications 3.5 fois plus que les webapps, 2.5 fois plus chez les autres smartphones. De plus, pour une marque donnée, 47% des mobinautes préfèrent consulter l’application mobile contre 17% pour la webapp. Enfin, en se passant des apps natives, je trouve dommage de ne pas profiter la puissance marketing des Push-Notifications, d’autant plus qu’ils sont assez peu considérés comme du spam et sont même attendus dans certains cas, mais c’est un autre sujet.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *