Le débat entre applications mobiles (natives) et application en ligne HTML5 est semble-t-il sans fin. J’en parlais déjà il y a 1 an 1/2 (Vous êtes plutôt application mobile ou site web optimisé pour les smartphones ?) et même plus récemment, car mes convictions penchaient en faveur de l’universalité (HTML5 s’impose petit à petit comme LA référence pour les applications mobiles). Oui mais voilà, le marché évolue et le dossier se complexifie avec de nouveaux facteurs à prendre en compte :
Bref, ça se complique, car les deux « clans » ont de solides arguments. Idéalement il faudrait pouvoir tout faire (comme la SCNF) avec des applications natives pour toutes les plateformes mobiles (iOS, Android, Blackberry, Windows Phone, Symbian, Bada) et un site mobile. Le problème c’est que cela représente un gros investissement et que les compétences sont dures à trouver. Nous sommes donc revenu au pont mort : HTML5 will kill mobile apps. No, it won’t.
Vous pourriez me dire que la solution réside peut-être dans les approches hybrides :
- Il existe de nombreux framework pour développer des applications mobiles universelles comme PhoneGap, Sencha, Titanium, Rhomobile, ParticleCode, Corona, Mosync, Worklight, BkRender… mais vous vous empêchez ainsi de pouvoir faire des notifications (qui sont quand même très pratiques, voilà pourquoi des acteurs comme Amazon ou Walmart se concentrent sur les applis) ;
- Les techniques de Responsive Design permettent de coder des interfaces modulaires qui s’adaptent à tous les écrans (sauf que dans la mise en oeuvre, ces techniques sont tout de même limitatives : Nouveau thème graphique en HTML5 et responsive design).
Nous voilà donc à nouveau au point de départ… Pour vous aider dans votre réflexion, j’ai réalisé un rapide benchmark de ce qui se fait de mieux entre applications HTML5 et applications natives.
Commençons avec la crème des applications HTML5 « sociales » comme celles proposées par Twitter ou LinkedIn :
Gmail et LinkedIn sur le navigateur de votre smartphone grâce à HTML5
Ces applications HTML5 sont rapides à charger, réactives et parfaitement adaptées à un usage centré sur la consommation de contenus en ligne. De même pour des applications de productivité comme Gmail ou Basecamp :
Gmail et Basecamp dans le navigateur de votre smartphone grâce à HTML5
Là encore, les versions HTML5 sont parfaitement adaptées, car il est avant tout question d’interactions autour de contenus « frais » et de collaboration. Le seul point noir que je puisse émettre est celui de l’authentification qui reste laborieuse (la saisie des identifiants / mots de passe est très pénible).
Du côté des applications natives, il faut bien reconnaitre qu’elles offrent un confort d’usage inégalé, comme le tout récent Flipboard :
L’application Flipboard pour iPhone
De même pour la dernière version de Path qui propose une interface de toute beauté, réellement différenciante :
La V.2 de Path sur l’iPhone
De même, je ne mentionne pas les jeux qui pour le moment sont quasi exclusivement développés en tant qu’applications natives, malgré l’enthousiasme de la profession pour une alternative (les mauvaises langues disent qu’il y a plus de conférences sur les jeux en HTML5 que de jeux en HTML5 !).
Comme précisé en début d’article, je n’ai plus de certitudes, si ce n’est qu’il n’existe pas de solution miracle : pour avoir une présence mobile performante, il faut investir (budget, ressources, énergie…) et se donner les moyens de réussir, car les utilisateurs ne se contenteront pas de compromis.
Ceci étant dit, je me dois d’élargir le débat et de préciser que de toute façon, le réel enjeu n’est pas de conquérir l’audience des utilisateurs en situation de mobilité, mais d’assurer une transition vers l’ère post-PC (Quel va être l’impact de la fin de l’ordinateur individuel ?). Ceci nécessite forcément une approche plus ambitieuse où vous allez être amené à repenser entièrement la diffusion de vos contenus et services. Un vaste chantier, mais ce n’est pas comme si vous aviez le choix.
Voir les 18 commentaires