Oui je sais, ça va bientôt faire 3 ans que je vous annonce l’hégémonie d’HTML5 par rapport aux applications natives (HTML5 s’impose petit à petit comme LA référence pour les applications mobiles). Il n’empêche que certains signes du marché me font dire que 2014 sera bel et bien l’année où les applications web sur terminaux mobiles vont enfin reprendre leur place. Mais d’abord, un petit peu d’histoire.
En 2007, Apple présentait au monde entier son tout nouveau smartphone, l’iPhone. Puis l’année suivante, Apple a introduit la notion d’application mobile avec la première app store. Depuis, les utilisateurs se sont passionnés pour les smartphones et les annonceurs et éditeurs pour les applications mobiles. Nous sommes maintenant en 2014, et les smartphones ont envahi le monde : Global Smartphone Shipments Top 1 Billion For The First Time Thanks To Cheap Android Devices, Says IDC. Comme le titre de l’article l’indique, Apple n’est plus du tout leader sur ce créneau, puisque les smartphones tournant sous Android sont maintenant largement dominants, une tendance confirmée par d’autres sources : Android overtakes iOS on US sales, extends lead in Europe, Latin America and China.
Avec plus d’1 milliard d’unités vendues en 2013, le marché des smartphones est maintenant complètement atomisé, ce qui pose de gros problèmes pour les éditeurs d’applications mobiles :
- Les coûts de développement augmentent avec le nombre de systèmes d’exploitation à cibler (iOS, Android, Windows Phone…) et les changements majeurs de version (ex : de iOS 6 vers iOS 7) ;
- Les coûts de maintenance et de compatibilité augmentent avec la disparité du matériel (formats et types d’écrans, processeurs…) ;
- Les places de marché d’applications officielles subissent la concurrence d’app stores indépendantes (mPlayIt, Appolicious…), notamment en Chine où la croissance est la plus forte (Wandoujia, One Of China’s Leading App Stores, Lands $120M In New Funding).
Ces nouvelles conditions de marché font que la distribution de contenus et services sur terminaux mobiles à travers des applications natives est beaucoup plus complexe à maitriser et à rentabiliser. À partir de ce constat, il y a deux cas de figure possibles : soit vous vous spécialisez sur un domaine et un environnement (ex : les jeux mobiles sur iPhone), soit vous vous adaptez à ce nouveau contexte et abandonnez les dogmes pour adopter une démarche plus pragmatique.
La (nouvelle) réalité que les éditeurs de contenus et services vont devoir assimiler rapidement est que le seul moyen de palier à l’évolution trop rapide du marché est de faire passer les applications natives au second plan pour investir à nouveau sur le web, mais dans un contexte mobile. Entendons-nous bien : je m’adresse avant tout aux éditeurs de contenus et services multi-canaux, ceux pour qui les terminaux mobiles sont un canal de distribution parmi d’autres. Pour ceux qui ont fait le choix de la sur-spécialisation (ex : une application de gestion de calendrier sous iOS), la situation est à aborder selon d’autres critères.
Donc à l’exception des éditeurs de jeux mobiles, la diversification du marché augmente mécaniquement les coûts liés aux développements et à l’évolution d’applications natives, donc rend les applications web mobiles plus intéressantes pour toucher une population cible plus large (potentiellement tous les possesseurs de smartphones, quelque soit la marque ou le système d’exploitation), s’affranchir des contraintes de référencement dans les app stores, et gagner en flexibilité / rapidité d’évolution. En résumé : investir sur le web, c’est faire le pari de l’avenir. A contrario, développer une application mobile, c’est se rendre dépendant d’une technologie propriétaire, d’un circuit de distribution fermé et d’un environnement de déploiement qui est condamné à évoluer à moyen terme.
Vous noterez que la discussion entre native app et web app n’est pas neuve (En finir avec le débat application vs. site mobile), mais de nouveaux arguments nous font voir ce dilemme sous un autre angle, à commencer par les éditeurs de contenu. Deux portails d’information US ont récemment communiqué sur le fait que près de la moitié de leur trafic provenait des terminaux mobiles : As CNN mobile traffic hits 40%, editor calls web vs. apps debate ‘red herring’. De même, Yahoo a décidé de réorienter toute sa stratégie autour des terminaux mobiles : Yahoo Now a Mobile First Company. Dans ce contexte, est-il encore pertinent de s’obstiner à proposer une application native, et d’en subir implicitement les contraintes ? Il est logiquement beaucoup plus prudent de miser sur le navigateur que sur l’app store pour toucher des lecteurs en situation de mobilité (version mobile de votre site vs. application native).
Pour les commerçants, c’est la même chose : est-il bien raisonnable de placer tous vos espoirs dans une application native plutôt que de proposer une version mobile de votre boutique en ligne ? Là encore, c’est une simple question de bon sens : il faut dépenser beaucoup d’argent et d’énergie pour inciter les clients à installer une application mobile, surtout pour ne réaliser qu’une ou deux ventes dans l’année. Il y a bien sûr le cas particulier des ventes flash, mais c’est une exception. Dans la très large majorité des cas, votre site web doit rester votre priorité, pour les internautes ET les mobinautes.
Précision importante : privilégier la version mobile de votre site ou boutique en ligne, ne veut pas dire que vous devez abandonner vos applications natives, simplement qu’il vous faut allouer vos ressources en conséquence et faire les bons arbitrages. Rien ne vous empêche ainsi de déployer des applications natives conçues autour d’une fonction en particulier, c’est d’ailleurs ce que fait Facebook (Facebook’s Plot To Conquer Mobile: Shatter Itself Into Pieces).
Seconde précision importante : il est tout à fait possible de monétiser une application mobile réalisée en HTML5, c’est d’ailleurs ce que commence à faire Amazon (Amazon Appstore Now Allows Developers To Charge For HTML5 Web Apps, Promote Them Through “Free App Of The Day”), et c’est très certainement ce que va faire Google très prochainement (That was fast: Chrome Apps ready to go mobile).
Bien évidemment vous trouverez toujours quelqu’un pour vous dire qu’une application native est plus performante, ce qui est tout à fait juste. Mais le problème n’est pas là, car nous parlons plutôt de coûts de développement, de rapidité / facilité d’évolution et surtout de rentabilité. La courbe d’apprentissage pour un développeur HTML qui souhaite réaliser une application web mobile est en effet beaucoup plus courte que pour un développeur lambda qui doit apprendre à maitriser les environnements de développement des applications natives. Il est, de plus, beaucoup plus simple de capitaliser de l’expérience sur des technologies et une architecture standards (reposant sur HTML) que de bricoler pour faire communiquer une application native avec votre CMS ou votre système d’information.
Moralité : est-ce la fin des applications web ? Non, bien sûr que non. Par contre, ce qui va changer, c’est que les éditeurs de contenus et services en ligne vont se réapproprier HTML dans un contexte de mobilité, et laisser les applications natives à ceux qui en ont réellement besoin. Nous retrouverons alors la dichotomie “classique” que nous connaissons dans le monde des ordinateurs entre éditeurs de contenus / services sur le web et éditeurs de logiciels.
La bonne nouvelle dans cette histoire est que vous avez déjà des développeurs HTML dans vos équipes, et qu’ils peuvent s’autoformer très rapidement. Je leur recommande d’ailleurs de commencer par là : Standards for Web Applications on Mobile: Current State and Roadmap.
Ça c’est le point de vue – que je partage – des éditeurs. Mais côté utilisateurs il y a une réelle préférence pour les applications mobiles. Alors, doit on ne pas écouter les utilisateurs ?
Attention à ne pas faire de généralité : Oui, je préfère largement la version web d’Allocine que de télécharger l’appli (donc inutile de me proposer le téléchargement de façon… insistante), par contre, pourquoi empêcher les utilisateurs intensifs de le faire ? L’idée que je défends dans mon article est de donner la priorité aux applications web, pas de remplacer les appli. natives.
Je ne suis pas vraiment d’accord.
D’un point de vue contenu web, il est évident qu’il n’existe pas deux webs différents (fixe et mobile) et qu’un contenu proposé par un site se doit d’être accessible dans de bonnes conditions sur mobile compte tenu des % d’internautes surfant sur le web à partir de leur mobile (ou tablette).
Donc oui, si vous avez un site web il est plus que recommandé de disposer d’une version mobile friendly que ce soit en responsive ou via un site dédié.
Pour autant, la question des Apps ne doit pas se poser de la manière dont tu la poses, en tout cas ça ne me paraît pas pertinent d’opposer App et version mobile ou responsive d’un site car ce sont deux contextes d’usages différents.
Tu dis préférer la version mobile d’allociné, bien. Mais pour y accéder tu dois lancer ton navigateur puis taper l’adresse d’allociné puis enfin faire ce que tu as envie d’y faire (avec éventuellement un passage par la connexion si jamais ta session a expiré). Pour l’App, tu la lances et hop, tu peux immédiatement faire ta recherche avec tes cinémas favoris déjà présents etc..
En faisant une analyse biaisée, on pourrait dire qu’allociné n’a pas besoin de site mobile car l’App est plus pratique à utiliser, sauf que bien sur ça serait laisser de coté tous les visiteurs qui arrivent sur allociné par une recherche google (ou bing & cie) sur leur smartphone. A l’inverse on pourrait dire que finalement avec une version bien pensée du site mobile l’App ne sert à rien, sauf que le site mobile ne gère ni le push, ni le mode déconnecté (en tout cas pas aussi bien que l’App) etc.
Je pourrais prendre plein d’autres exemples du type vente privée dont 33% du CA provient des utilisateurs de l’App… probablement parce que celle ci apporte une grande valeur ajoutée avec la notification pile au moment ou la vente commence..
Au final, App et site web ce sont deux contextes et objectifs d’usages différents.
C’est une erreur d’entretenir cette espèce de gueguerre stérile App vs web (natif vs HTML5) car dans tous les cas la fréquentation du web est multi terminal (fixe, tablette, mobile) et la tendance ne va pas s’arrêter… et pour autant aujourd’hui les Apps ont de gros avantages par rapport aux sites web (même responsive ou dédiés mobile).
Le seul conseil que je donne à mes clients :
– vous avez un site web ? faites en sorte qu’il soit accessible en mobilité (si bien sur ça a du sens hein faut pas non plus y aller à l’emporte pièce).
– il y a une récurrence d’usage, une dimension intime et personnalisée par rapport à vos contenus, vos utilisateurs réalisent des taches ? réflechissez à l’ajout d’une App dans votre stratégie multi-canal
@Fabien Grenet : Ton argumentation sur la difficulté à accéder à une application Web mobile n’est pas fondée.
Premièrement parce que rien n’empêche à un utilisateur de se créer un raccourci pour lancer un navigateur et accéder directement à une URL spécifique = 1 touche comme une application mobile. D’ailleurs, c’est déjà ce que l’on fait régulièrement sur les ordinateurs de bureaux. Pourquoi n’est ce pas fait par les utilisateurs sur les terminaux mobiles alors ? Tout simplement parce que les plateformes de distribution d’applications natives ont été mises en avant pour faire rentrer l’argent et que les utilisateurs “lambda” n’ont pas été sensibilisés à cette possibilité.
Deuxièmement, prenons l’exemple inverse du cas qui fait mal avec une application native. Tu es sur ton réseau social préféré, sur un message on t’indique un article intéressant avec un lien associé, tu veux accéder au lien en question. Enfer et damnation tu ne peux pas y accéder directement (cad via le Web), il te faut y accéder par le biais d’une application qui n’est pas installée chez toi … Ce mécanisme est rare et pour cause, il est rarement bien implementé car couteux en développement, et douloureux car tu obliges l’utilisateur à installer une application (merci la bande passante au passage) dont il se serait bien passé. A ton avis quel est le pourcentage d’utilisateurs qui vont installer cette application ? Parmi ceux qui l’ont fait combien vont vouloir rediffuser le message via le réseau social pour propager cette douloureuse ?
Voilà pourquoi tu dois toujours mettre tes efforts en premier sur la version Web mobile si tu ne te considères pas comme un éditeur de logiciel. J’abonde donc à 100% avec l’article.
Conseils très utiles ! A mettre en pratique maintenant !
On ne peut pas tout faire avec une application HTML5, mais indiscutablement cela permet d’avoir des coûts plus attractifs pour une fluidité proche d’une application native.
Ceci dit, s’il y a besoin de démarrer la connexion Wifi (par exemple) sur une appli HTML5, rien n’empêche de simuler une API javascript HTML5 déclenchant le wifi dans la partie “native” de l’application.
@ Fabien > Attention je n’oppose pas native et web app, ou alors non intentionnellement. J’ai toujours eu la même opinion à ce sujet : les deux sont complémentaires. Par contre, mon propos dans cet article est de dire que la priorité doit être donné à la version mobile du site ou du service, puis de voir si une appli est pertinente par rapport aux coûts et contraintes.
@ Berthelot > Je crois que nous oublions ici une quatrième alternative (native vs. web vs. responsive) qui est l’application hybride. Sans oublier non plus la Chrome App ! Ceci ne va pas faciliter la compréhension, car le choix technique se complique…
J’approuve!
Déjà eu l’expérience de clients qui voulaient à tout prix une app et ne se rendait pas compte des implications en termes de coûts de développement et de maintenance pour une app vs. un site mobile. Comme tu le soulignes, il faut donner la priorité au site mobile avant de considérer l’app!