Le temps des Hybrides
Pour ceux qui croient que je passe mon temps autour du rugby, je tiens à préciser que ce n’est pas le cas. Je le passe surtout entre Digidust, Labotec et APICube, principalement à travailler sur des questions de stratégie mobile, d’applications iOS ou Android et de Marketing Communautaire.
Quand je rencontre un de nos clients pour un projet d’App Mobile, généralement, une question revient presque à chaque fois : Application Native ou HTML5 ?
Je ne vais pas trop entrer dans la technique pour deux raisons : la note serait vraiment longue le temps que je fasse le tour de tout et je n’en suis pas capable sans passer pour un noob devant quelques barbus poilus qui viennent me lire de temps en temps ; Mon égo ne va pas le supporter 
En termes « pour tout le monde », voici le problème : HTML5 est extrêmement puissant, prometteur et… immature.
En gros, on sait que ce sera génial, on voit que ce sera génial, parfois c’est même déjà génial là tout de suite mais on ne peut pas encore rivaliser avec une application iPhone ou Android un peu complexe pour ce qui est de la qualité, de l’exploitation du hardware et de la fluidité.
Du coup, conseiller nos clients – et essayer de vous expliquer dans un même temps – est un vrai dilemme.
Déployer une application mobile en HTML5 est forcément moins couteux, au moins dans la durée. Elle est généralement accessible à la majorité des téléphones civilisés. On peut plus ou moins l’embarquer dans une application native ou jouer avec le cache des navigateurs mobiles pour en avoir un usage sans connexion. Toutefois, certaines fonctions qu’une application native pourrait offrir sont encore impossibles à développer ainsi.
Pas de doute : HTML5 est l’avenir de l’App comme la Femme est l’avenir de l’Homme, mais son avènement est ralenti (celui d’HTML5, pas de l’Homme) par Apple et Google qui ajoutent des fonctionnalités à, respectivement, iOS et Android, ce qui a pour effet mécanique de redonner un petit coup d’avance au natif à chaque fois.
Il faut bien avouer que lorsque l’on monte en gamme sur une application, en particulier pour iPhone ou iPad, le natif s’impose naturellement, et cela risque de durer encore un bout de temps. On peut le regretter mais c’est ainsi. D’ailleurs, j’ai le sentiment que c’est un peu moins le cas sur iPad où finalement, les applications sont bien plus proches des WebApps que ce n’est le cas sur les iPhones… mais bon, sur un plan général, le postulat reste vrai.
Alors, le résultat de toutes ces tergiversations, finalement, ne va pas vous plaire comme il ne plait généralement pas à un client qui se demande comment utiliser au mieux les quelques dizaines de milliers d’euros qu’il a dans la poche.
Mais bon, je vais me jeter à l’eau comme Richie McCaw se jette dans les rucks c’est à dire sans appréhension mais sachant que je flirte avec la ligne jaune…
A ce stade, je préfère privilégier les applications compilées au format natif, en particulier pour les applications iPhone où la question en se pose quasiment pas. Nous travaillons principalement avec de grandes entreprises et les budgets engagés restent modestes par rapport à leurs budgets globaux, que ce soit sous l’angle marketing ou IT. Penser à un investissement à 3 ou 5 ans sur ce type de « petits » projets ne se justifie pas totalement à mon sens. En gros, l’idée sera de basculer sur une App en HTML5 le moment venu, même si cela demande de remettre un budget dans le projet.
Toutefois, pour des applications simples ou pour les applications professionelles qui sont volumiques mais ne demandent pas de technologies trop lourdes – une application type Assistance à la vente pour les forces commerciales, par exemple – l’alternative HTML5 est, à mon sens, envisageable dès à présent. C’est d’autant plus vrai dans l’univers professionnel qu’arrive un moment où l’on doit limiter les possibilités de l’application car certaines fonctions un peu trop « shiny » demanderaient un effort financier supplémentaire dont le retour sur investissement serait vraiment trop aléatoire…
HTML5 ou application native, c’est finalement toujours une affaire de concessions mais cela changera… un jour
28 septembre 2011 à 19:27
pou rmoi le minimum c’est site mobile (et parfois le plus « utile » ou visible tant il y a d’applications) et une application si besoin de vraiment utiliser quelques fonctions clés (poster une image, push par ex).
28 septembre 2011 à 20:37
Et bien je dirai les deux.
Je crois que si j’avais un projet avec une app mobile, je ferai en priorité une version HTML 5 mobile : plus rapide à déployer, universel.
Mais dans un deuxième temps, j’investirai dans l’app native. Parce que ça va vraiment plus loin, parce qu’on peut exploiter les détails de l’OS, parce qu’on peut coller aux spécificités de chaque ergonomie, de chaque IHM. Et entre iOS et Windows 7 mobile, j’imagine qu’il y a un gouffre.
28 septembre 2011 à 21:32
[...] Choisir entre Application Mobile Native ou #HTML5 | Pierre-Olivier Carles C'est une question récurrente qui se pose chez nos clients : doivent-ils aller vers une application mobile native ou plutôt vers une WebApp en HTML5 ? Source: http://www.pocarles.com [...]
28 septembre 2011 à 21:38
D’un point de vue de développeur, c’est une techno à apprendre (HTML 5) contre plusieurs (Android, Windows Phone, Objective C…).
C’est un argument qui n’est pas négligeable suivant la taille du prestataire aussi.
29 septembre 2011 à 8:14
Il y a aussi des frameworks comme Phonegap ou appcelerator par ex qui permettent de développer en html 5, js, css3 puis de directement compiler pour en faire une application « pseudo native » pour android, iOS, blackberry, symbian, webos, et maintenant mango.
C’est vraiment intéressant car l’API permet d’utiliser les fonctionnalités du tel. Un builder est même dispo sur Phonegap pour compiler directement en ligne sans meme le SDK de chaque plateforme (on peut meme développer une appli iPhone sans Mac !).
29 septembre 2011 à 9:43
Je pense comme toi Pierre-Olivier qu’il n’y a pas de réponse tout faite et universelle à cette question.
Il faut prendre en compte le contexte du client, la stratégie de « déploiement » envisagée, les fonctionnalités clés de l’app (car le HTML 5 ne permet pas encore de tout faire), etc..
Dans certains cas une app full HTML 5 se révélera être la solution, dans d’autres se sera une app full native, dans d’autres encore du HTML 5 encapsulé dans du natif ou encore un app compilée en natif mais développée dans d’autres langages (comme l’a indiqué Bastien), …
Le principe de développer sur des frameworks type appcelerator me semble être un des meilleurs compromis actuels, à condition qu’il soit adapté au besoin et contexte du client comme précisé plus haut car c’est là le point le plus important.
29 septembre 2011 à 10:15
Une harmonisation des langages nous faciliterez bien la vie.
Par contre je ne connaissais pas Phonegap qui a l’air très pratique, je vais donc l’essayer de ce pas.
29 septembre 2011 à 10:16
Pour avoir un avis un peu plus technique sur ce débat, je vous invite à lire ce post très intéressant http://blog.octo.com/debat-web-apps-vs-natif/, qui fait une suite à une conférence à Brighton et notamment à une table ronde sur le thème « Web Apps VS natif ».
29 septembre 2011 à 10:26
Merci pour ce lien Christophe. Effectivement très intéressant.
18 octobre 2011 à 11:13
Bonjour.
Je ne suis pas trop d’accord avec votre article. Les frameworks récents, innocemment jquery mobile, permettent de faire des choses semblables aux appli natives. Regardez http://m.onsedoit.fr depuis un iphone ou un android.
Je suis pro-webapps
28 novembre 2011 à 17:04
Bonjour,
Je pense que c’est possible de trouver une harmonie. Je suis d’accord avec Aurélien ils existent certains frameworks HTML5 qui peuvent aider à améliorer le rendu des applications hybrides sans oublier qu’il y a quelques uns qui fournissent même des coquilles natives pour faciliter le travail. J’ai trouvé sur le net un exemple de ceci : http://bkrender.com .
Les applications hybrides sont en pleine croissance.