Dans un de ses derniers articles, MG Siegler fait une état des lieux assez intéressant sur les technologies HTML5 vs. application natives et leur adoption par les développeurs. Voici une résumé de son propos.
C’est un vieux débat qui agite depuis longtemps la communauté des développeurs sur mobile : faut-il créer une application native ou plus simplement un site web mobile basé sur les technologies HTML5 (appelée communément application web). Une application native est une application développée à partir d’un SDK (plateforme de développement) à destination d’un type d’OS mobile (iOS, Android etc…). Ce type d’application peut accéder à de nombreuses ressources du téléphone et sont disponibles sur les différents “App Store”.
HTML5 est aujourd’hui la technologie web qui est sur toutes les lèvres mais qui est surtout bien implémentée sur la plupart des navigateurs web mobile. Plus simple à utiliser, multiplateforme, “ouvert”, intégrant de nombreuses API, on pourrait penser que l’intérêt apporté à cette nouvelle version boostée d’HTML pourrait vite écraser les applications natives.
Il y a pourtant de grosses différences techniques entre le HTML5 et applications natives. Regardez par exemple les applications les plus vendues sur les “App Stores” : les jeux. Nous sommes encore loin de pouvoir offrir le même rendu et la même expérience utilisateur sur une application web.
Mais ceci n’est bien sûr possible qu’à travers des développements longs, difficiles et donc coûteux. L’hétérogénéité des plateformes : iOS, Android, Windows Phone, BlackBerry démultiplie ce coût pour peu que l’on souhaite déployer sur une large gamme de téléphones. HTML5 pourrait donc être la solution pour un déploiement multiplateforme unique. Il est malheureusement souvent employé comme solution alternative à une application développée sur un OS particulier.
Si l’on regarde les géants comme Apple, Google ou Facebook, on se rend compte que leur positionnement respectif est différent. Apple joue bien évidemment aujourd’hui la carte du “tout application native”. Pourtant lors du lancement de l’iPhone, l’App Store n’existait pas et Apple suggérait de développer des applications web en HTML. En complément de son écosystème fermé d’application, Apple joue l’ouverture via son navigateur Safari sur mobile en intégrant toutes les dernières fonctionnalités HTML5 : Si votre application n’est pas acceptée pour l’App Store, Apple vous proposera de développer une web app en HTML5.
Pour Google, la situation est plus en demi-teinte. Google prêche le HTML5 auprès de la communauté des développeurs et fait beaucoup pour son adoption notamment grâce à son navigateur Chrome et son futur système Chrome OS.
Mais pour déployer ses services, Google n’hésite pas à créer de nombreuses applications natives que ce soit bien évidemment sur Android, qui a le vent en poupe, mais aussi sur iPhone ou BlackBerry, tout en recrutant de nombreux ingénieurs spécialisés dans le développement natif.
Concernant Facebook, comme nous l’avons vu précédemment, HTML5 est le support de l’écosystème de développement du réseau social sur mobile. Bien que l’application Facebook soit l’application la plus téléchargées sur iOS, l’expérience de développement des employés de Facebook sur iPhone ou Android n’est pas des plus concluantes. Facebook souhaite au final utiliser la meilleure solution adaptée à l’expérience utilisateur, n’excluant ainsi aucune des solutions.
Le débat, application native contre application web, n’est donc pas de savoir quelle est la meilleure plateforme, mais quelle est la plus adaptée pour l’utilisateur. Même si aujourd’hui HTML5 est une belle évolution de HTML au niveau technologique, tout le monde s’accorde sur le fait que les applications natives apportent une meilleure expérience utilisateur. En 2-3 ans les possibilités offertes par les environnements iOS ou Android ont considérablement fonctionnellement évolués, et ce n’est pas terminé. Il va falloir attendre encore de nombreuses années avant que cela puisse évoluer d’une telle manière pour HTML5.
Crédit photo : Yutaka Tsutano
Pour moi ce n’est pas “HTML5″ qui va remplacer les applications natives, mais l’ensemble des technologies du web.
J’ai écrit à ce propos l’année dernière dessus:
http://blog.steren.fr/2010/02/14/native-applications-are-doomed/
Beaucoup d’hyperboles faciles et d’inexactitudes dans cet article. L’auteur n’a jamais “mis les mains ” dans les aspects techniques et élabore sa thèse sur des affirmations qui vont à l’inverse de la réalité.
“Apple joue l’ouverture via son navigateur Safari sur mobile en intégrant toutes les dernières fonctionnalités HTML5″
C’est faux. En réalité le HTML5 sur l’iPhone est un mythe. Prenons l’exemple de la balise canvas, qui est celle qui permet l’affichage de sprites et leur animation. Cette balise est donc indispensable pour développer un jeu. A l’heure actuelle, elle est très probablement bridée, en tout cas inutilisable, puisque incapable d’afficher des sprites à un framerate correct.
Pourtant le hardware de l’iPhone le permettrait tout à fait.
La situation côté Google est conforme à celle décrite dans l’article : le framerate de canvas est légérement supérieur, il peut être utilisé, mais bien en-deçà du natif évidemment. Là aussi, le hardware permettrait pourtant sans problème un framerate correct.
La position réelle des 2 grands constructeurs est très simple : nos plate-formes sont vérrouillées, si vous voulez des performances normales, vous passez par du natif, et par nos app-stores.
Rappelons aussi un fait technique fondamental : il n’y a pas d’audio en HTML5. Aucun browser, aucune plate-forme, n’implémente encore de fonctionnalités audio. Si à l’heure actuelle les fonctionnalités graphiques commencent à être exploitables, l’absence de couche audio interdit de toute façon la conception d’une vraie “Web app”. Là encore, le hardware le permettrait sans aucun problème.
Le développement mobile, c’est le développement natif. Les “web-app” ne seront envisageables que quand les constructeurs les “autoriseront” en débridant leurs implémentations respectives de HTML5. Et tant que les appstores tourneront, il n’y a pas de raison qu’ils le fassent…
Je ne connaissais pas cette histoire de “bridage”, merci pour les précisions.
Quand tu dis pas d’audio, tu parles en fond sonore ? Parce que j’ai déjà vu des players audio / vidéo
Sauf que Google parallèlement a déjà commencé à déployé son Chrome Web Store ce qui va encourager le développements de webapps. L’implementation de WEBgl dans chrome a aussi été pensée pour le browser et spécialement pour les jeux.
Google travaille fort sur le sujet et a tout intérêt à développer les webapps et a tout le poids nécessaire pour imposer des ouvertures au constructeurs.
L’audio html5 ? Il est déjà implémenté sur Firefox 4 et chrome 9 et le sera dans IE9. un exemple sympa ici : http://code.gregjopa.com/html5/audio/tabplayer/
@julien : Il me semble que le sujet de la discussion est le mobile.
La balise HTML5 audio est bien implémentée sur android gingerbread (2.3)
Très bon article, j’avais lu un truc pas mal à ce sujet ici : http://ser-info-02.ec-nantes.fr/users/info3/weblog/0a27c/
Le HTML5 permet déjà d’avoir une expérience utilisateur assez sympa, avec des transitions, intégration d’API,etc. Et forcément une cible plus large.
Ma conclusion est à peu près la même que la tienne : quelle est la plateforme la plus adaptée pour l’utilisateur en fonction de l’application.
De notre côté nous avons choisi de ne pas vraiment choisir : une app iPhone, un site web mobile (sans réalité augmentée du coup) et une app Android en développement.
Merci pour ce lien très interessant
Il est évident qu’on ne fera jamais mieux en terme d’interface qu’une application native, pour peu qu’on la travaille et qu’on ait des gens spécialisés
sauf que très peu d’entreprises peuvent se payer le luxe de développer et maintenir plusieurs plate-formes différentes, et développer uniquement une application iPhone aujourd’hui en france, c’est se couper de 20% du marché des smartphones, chiffre en augmentation depuis qu’android commence à séduire et que les concurrents se réveillent.
la bonne stratégie aujourd’hui, ça serait de tirer parti des équipes Web internes pour développer une application Web qui tournerait sur 100% des smartphones.
Puis si il reste du budget, de capitaliser (choix ergonomiques déjà faits, APIs de récupération des données déjà développés …) sur cette appli web HTML5 pour éventuellement outsourcer une adaptation iPhone et autre pour pouvoir être visible sur le tout-puissant appstore. La plupart du temps on se rend compte qu’on a seulement besoin d’un webkit déguisé qui affiche la version mobile du site …
Je crois qu’il est largement temps que cesse le gâchis de création d’applications dédiées à telle ou telle plateforme.
Hormis les cas particuliers comme les jeux cités dans l’article.
Bonjour,
A mon sens, ce n’est pas forcement les technologie les plus adaptée à l’utilisateur qui marche.
C’est simplement le rapport qualité/prix qu’on envie d’investir les entreprises pour leurs applications.
Pour le moment le prix est là donc les applications natives également, mais petit à petit avec l’HTML5 les entreprise vont se rendre compte qu’ils peuvent investir beaucoup moins d’argent pour avoir une application peut être moins large sur le spectre fonctionnalité.
Il ne restera donc sur les application native que les entreprises qui ont les moyens et qui veulent une qualité certaines pour leur application.
Reste les jeux, où là c’est différent et où les applications natives vont rester un bon bout de temps.
Quand pensez-vous ?
Le remplacement d’une application native par une application Web, HTML5 ou pas, c’est une vaste blague.
La version web c’est pratique si on a pas son smartphone avec soi, ou pour les utilisateurs occasionnels. La meilleure preuve sont les powers user de Twitter qui n’utilisent que les versions natives.
Le web est un complément au natif.
J’ai écris un article proche de ce sujet :
http://frederic.logier.org/2010/06/25/desktop-2-0/
Tout dépend de ce que l’on veut faire comme appli. Et je ne parle pas forcément des jeux.
Mais par exemple, si l’on veut utiliser certaines parties matérielles du device, comme la puce GPS (ok, il ya une API pour le web qui est en train de voir le jour je crois), ou le micro de l’iphone, ou encore l’accéléromètre.
L’intérêt aussi de créer une application native, c’est que l’on peut monétiser directement son appli via l’app store ou l’android market.
Après, si c’est pour faire une appli qui ne sera qu’une reprise du site web : non. Il vaut mieux faire en sorte que ce soit le site qui s’adapte aux devices, et que les css mettent en forme le contenu.
One web.
Je ne connais pas les détails du développement mais nous utilisons déjà la fonctionnalité GPS sur geoquestour.mobi il me semble.
Mais c’est clair que l’on a pas accès à toutes les fonctionnalités internes et que ça réduit les possibilités.
Sylvain Gauchet, ou comment citer sa boite pour faire sa pub à chaque article de TC! Un peu pathétique… :/
Sinon, oui, en effet un des principaux obstacles est d’appeler les fonctionnalités hardware (camera, etc.) depuis un browser. Affaire à suivre!
Enchanté Corinne. Quelle belle façon de rentrer en contact
Je ne commente que les articles qui me parlent, et celui là me parle tout particulièrement puisqu’on est en plein dedans. Tu y vois de la pub, je comprend, moi j’y vois aussi un moyen d’échanger et d’avoir un retour dessus : votre web app est très loin d’une appli, telle fonctionnalité pourrait être dispo, etc.
J’essaye aussi de ne pas faire que ça (cf. mon 1er commentaire) et de fournir de l’info pertinente (quand j’en ai !).
@jpvincent : “sauf que très peu d’entreprises peuvent se payer le luxe de développer et maintenir plusieurs plate-formes différentes”
Aujourd’hui, une boite qui n’est pas capable de produire des applis natives est out. A mes yeux, se rassurer en espérant l’arrivée prochaine d’un HTML5 exploitable constituant une alternative au natif c’est nier la réalité. Cet HTML5-là n’arrivera jamais, les constructeurs ont clairement décidé l’inverse.
HTML5: ça bouge mais c’est pas encore ça.
Quelques chiffres et cas pratiques:
http://nicolas.cynober.fr/blog/738,html5-vs-flash-janvier-2011.html
C’est déjà entrain de bouger de ce côté là: http://www.application-mobile.ch/content/navara-mobility-suite-une-alternative-au-d%C3%A9veloppement-multiplateforme
Je rajouteraisau débat aussi un point sur tout ce qui est à venir côté nouvelles APIs device (groupe de travail DAP au W3C) et qui donneront accès aux contact, calendrier, infos sur le réseau, la batterie…
En attendant, pour montrer qu’on peut faire des choses sympas avec une webapp: http://www.oxxone.com (à voir depuis son iPhone ou son iPad. Il y a aussi une version avec un carousel pour android et les autres smartphones).
Tout ça aussi grâce à la montée en puissance des frameworks de développement JavaScript comme le Wink toolkit (http://www.winktoolkit.org)
Et une fois votre application prête, ajoutez là au Web Store http://www.freemobapp.com , App Store pour HTML5 web app