Application mobile : tout est à revoir

Si vous lisez régulièrement ce blog, alors vous connaissez déjà l’importance des smartphones dans le quotidien des consommateurs. Pour définitivement convaincre les dernier(e)s sceptiques, je vous propose au cas où quelques liens : Mobile is eating the world (updated), Le mobile, un device omniprésent et 6.1B Smartphone Users Globally By 2020. Et si jamais vous vous posez la question : Mobile Isn’t Killing the Desktop Internet. J’enfonce le clou en apportant des chiffres spectaculaires sur l’utilisation des smartphones dans un contexte d’achat : Soldes d’été 2015 : 26% des requêtes à partir d’un smartphone et L’absence de Stratégie mobile coûte 6,6 milliards d’euros aux marchands en France.

previsions-m-commerce

En synthèse : ne pas concentrer ses efforts sur les smartphones est une faute professionnelle grave. Ceci étant dit, « être présent sur les smartphones » est une notion subjective, un peu comme « être présent sur le web ». Il y a en effet différents niveaux d’implications d’un annonceur sur les terminaux mobiles. Le problème est que les marques pensent généralement être équipées en sous-traitant le développement d’une application mobile qui est, dans le meilleur des cas, proposée en deux versions (iPhone et Android). J’ai déjà eu de multiples occasions de m’exprimer sur le sujet, et je pense avoir épuisé tous mes arguments dans mes deux derniers articles : Les applications mobiles sont-elles obsolètes ? et Les applications mobiles de marque sont une utopie.

Pour vous la faire simple :  une, ou deux applications mobiles ne sont pas suffisantes, car elles coûtent cher à développer et ne couvrent qu’une partie des besoins. Il convient dans un premier temps de vous assurer que vous êtes en mesure d’offrir vos contenus et services de la façon la plus simple et rapide possible : à travers la fenêtre d’un navigateur. Au-delà de cette première étape, il convient également de s’intéresser aux autres moyens de diffusion de vos contenus et services sur les smartphones, notamment avec la montée en puissance des assistants personnels et des applications de messagerie : Invisible Apps, le service sera conversationnel.

Les progressive apps pour améliorer l’engagement et la fidélisation

Je suis tombé récemment sur un article très intéressant : Escaping Tabs Without Losing Our Soul. Le principe des progressive apps est de mettre en ligne un site (ou service en ligne) très simple dédié aux smartphones pour que les mobinautes puissent l’utiliser directement sans avoir à la télécharger depuis une app store. Puis de proposer plus de fonctionnalités lors de la seconde visite. Puis de proposer aux utilisateurs d’en télécharger une version locale lors de la troisième visite. Les visiteurs « de passage » se contentent de la version web mobile, alors que les utilisateurs réguliers bénéficient d’une pseudo-application mobile.

En découvrant ce principe de progressive apps, j’ai vraiment eu l’impression que nous tenions enfin le meilleur compromis possible.

Mais ça reste quand même un compromis. Nous en étions donc restés là dans la recherche de la meilleure approche possible pour optimiser sa présence sur les terminaux mobiles quand le dernier rapport de Criteo est venu semer le trouble : Apps and cross device are retailers’ new best friends. En substance : le taux de transformation des applications natives est bien meilleur que celui des sites mobiles. Pire : les transactions à partir d’un navigateur ne représentent que 10% des transactions sur smartphone.

criteo-m-commerce

L’écart de performance entre un site mobile et une application mobile est spectaculaire, mais il y a un biais : les mobinautes ayant fait l’effort de télécharger l’application mobile sont forcément déjà en affinité avec la marque. Du coup, les ventes sont beaucoup plus fluides. Ceci étant dit, les chiffres nous fournissent une indication précieuse : les applications mobiles sont nécessaires pour pouvoir satisfaire le coeur de cible.

Des applications hybrides plus performantes avec ionic

Du coup, cela nous force à réfléchir à une autre approche : celle des applications hybrides. L’idée est de proposer un environnement de développement où un code unique va pouvoir être utilisé pour générer des applications natives. Cette approche n’a jamais vraiment réussi à convaincre, car la courbe d’apprentissage était non-négligeable, et les performances plutôt décevantes (les applications hybrides étaient plus lentes que des applications natives). Mais ça, c’était avant…

Il existe un certain nombre de frameworks pour développer des applications hybrides (une comparaison rapide est disponible ici : PropertyCross), mais il y en a un qui sort très clairement du lot : ionic. Lancée il y a moins de deux ans, cette bibliothèque de composants s’appuie sur deux autres frameworks très à la mode (Node.js et AngularJS) et a rapidement su fédérer de nombreux fans : Building Mobile Apps with AngularJS and Ionic, Switching from native iOS to Ionic: Why Hybrid doesn’t suck anymore et Why Ionic is Reigniting the Native vs HTML5 Debate. Pour des explications plus techniques, c’est ici : Présentation de Ionic Framework et Creating a hybrid mobile Application with Ionic, Cordova and AngularJS. Nous avons donc avec ionic une très excellente solution pour développer des applications hybrides, sauf que… ionic s’appuie en grande partie sur le framework javascript de Google qui est en train d’être entièrement refondu (AngularJS 2.0 changements notables). Une nouvelle version qui laisse la communauté très partagée : AngularJS, les développeurs dans le trouble au sujet de la version 2.0. Les équipes de ionic ont beau essayer de rassurer la communauté, le doute plane : Ionic and Angular 2.

Vous pouvez sans doute penser que toutes ces considérations techniques ne vous concernent pas (après tout c’est le problème des développeurs), mais les dernières évolutions des technologies de développement d’applications sont pourtant extrêmement structurantes sur les choix que vous pouvez faire. Toute mon argumentation sur le débat « application mobile vs. site mobile » repose sur le postulat que les applications natives sont trop chères à développer et à maintenir, mais ces frameworks permettent d’abaisser les coûts de développement et de raccourcir la courbe d’apprentissage… il faut donc entièrement revoir votre road map mobile.

Facebook change la donne avec ReactNative

D’autant plus que Facebook vient de frapper un grand coup avec la mise à disposition de sa librairie ReactNative lors de la conférence ReactJS à Paris. En résumé, ReactNative est un framework révolutionnaire qui permet de développer en javascript et de compiler en code natif : Bringing modern web techniques to mobile et How Facebook’s React Native Will Change Mobile Apps. La révolution vient du fait que contrairement aux autres frameworks d’applications hybrides, ReactNative permet de générer des applications natives, 100% natives.

La promesse de ReactNative est de transformer des développeurs web en développeurs d’applications mobiles natives,ce qui représente un énorme gain de temps (de développement et d’apprentissage). Les premiers utilisateurs sont dithyrambiques au sujet de ce nouveau framework : Diary of Building an iOS App with React Native et Retrospective on developing an application with React Native. ReactNative est-elle LA solution ultime que tout le monde cherche ? Oui, mais pas tout à fait, car pour le moment ce framework ne génère que des applications iPhone, les utilisateurs Android, qui représentent 75% des mobinautes, sont donc laissés de côté. L’équipe de développement en charge de ce projet chez Facebook promet une compatibilité Android d’ici à quelque mois (React v0.14 Beta 1), mais de nombreux doutes subsistent.

Conclusion

J’ai bien conscience de vous avoir embrouillé avec toutes ces explications techniques, et s’il y a bien une chose que vous devez retenir, c’est la suivante : les arguments utilisés l’année dernière pour trancher en faveur de telle ou telle approche (native, hybride, web) ne sont plus valables.

Le plus perturbant dans cette histoire, c’est que si les solutions évoquées dans cet article (notamment ionic et ReactNative) changent réellement la donne, il est pour le moment très compliqué de se projeter dans 1 ou 2 ans, car elles vont fortement évoluer d’ici à la fin de l’année.

Au cas où vous ne l’auriez pas compris, la mobilité est un domaine ultra-concurrentiel où les géants du web s’affrontent (Google vs. Facebook, avec Apple en embuscade). Dans cet environnement en perpétuelle évolution, il convient de faire preuve d’une grande agilité et de remettre régulièrement en question les choix précédents.

8 réflexions sur “Application mobile : tout est à revoir

  1. Nan Ionic est hyper lent et buggé. Angular est PAS FAIT pour du mobile (du moins pas avant la version 2). Cordova avec du natif sans framework ça passe. Je viens de passer 3 mois à faire des tests sur toutes les technos possible sur Cordova pour tester un max d’animations/effets. Au final dans l’ordre de la meilleure perf à la pire : Canvas / Animations par JS natif / CSS3. Du coup Ionic qui fait une énooooorme surcouche en Angular + des animations CSS3 c’est hyper hyper lourd.

    J'aime

  2. @ Xavier > Ce qui est dit dans l’article est que ionic permet de réduire le temps de développement, et que les applications hybrides ont longtemps soufferts de problèmes de performances. Tout ceci devrait (normalement) s’améliorer avec ionic 2, il faudra donc revoir nos jugements sur telle ou telle techno. D’où le titre de l’article : « Tout est à revoir ».

    Sinon je ne pense pas que le positionnement de ionic (ou des autres environnements pour faire des applications hybrides) soit de promettre les meilleures performances, mais plutôt de proposer un bon compromis entre performances et temps de développement (en prenant même en compte la courbe d’apprentissage).

    J'aime

  3. Pour améliorer les performances d’un site mobile, il ne faut pas négliger l’AppCache qui permet à l’utilisateur de continuer à naviguer même déconnecté et de gérer la reprise sur erreur en cas de déconnexion.

    Les sites devraient aujourd’hui être développés comme des applications consommant des APIs.

    J'aime

  4. L’article ne mentionne pas des technos telles que Appcelerator ou Xamarin. Ces approches « hybride-natives » ne doivent pas être écartés à mon avis. Qu’en pensez-vous?

    J'aime

  5. @ Emilien > Non, ces deux frameworks ne sont pas à écarter, ils fonctionnent (de ce que j’en sais) à peut près de la même façon que ReactNative (le code générique permet de générer des éléments d’interface natifs). Mais visiblement ReactNative est plus simple d’accès, car le développement se fait en javascript. Ceci étant dit, je ne me risquerais pas à rentrer dans un débat d’expert sur les vertus de tel ou tel language…

    J'aime

  6. Le passage de AngularJS 1 vers AngularJS 2 est aujourd’hui un vrai problème, qui ne touche pas seulement Ionic, mais tous les frameworks mobile basés sur AngularJS : Onsen UI, Framework7… C’est d’autant plus rageant que ces mêmes frameworks ont fait d’énormes progrès en terme de performance, et, s’ils sont correctement mis en oeuvre (ce qui n’est pas si évident qu’il n’y parait), ils offrent aujourd’hui des performances très proche du natif.

    Nous développons aujourd’hui sur Sencha Touch 2.4, un excellent framework qui lui n’est pas basé sur AngularJS. Nous sommes extrèmement satisfait de ce framework, qui, une fois pris en main (gros effort d’apprentissage au départ), nous apporte tout ce que nous souhaitons en terme de fonctionalités et de performance, avec en plus l’énorme avantage que ce framework s’adapte automatiquement à la plateforme sur laquelle il est installé. En effet, le design des interfaces est pré-conçu pour s’adapter à iOS, Android, Windows Phone, Blackberry OS, Tizen… Ce qui nous offre un énorme gain de temps à la conception.

    Hélas, Sencha Touch est aujourd’hui touché par la même incertitude que les frameworks basés sur AngularJS. En effet, Sencha a décidé de fusionner ses deux frameworks ExtJS (web) et Sencha Touch (mobile) pour produire une pateforme unique ExtJS 6. Et là, le problème ne vient pas d’un gap technique majeur, mais d’un changement radical de politique commerciale. Sencha Touch était jusqu’ici gratuit, même pour une utilisation commerciale, alors que ExtJS est payant (très cher !), avec un package minimum de 5 licences développeurs à plus de 4000$ pour la version standard minimum !

    Nous avons envisagé de basculer sur l’un des frameworks basés sur AngularJS, notamment Onsen UI, mais là, franchement, face aux incertitudes, on ne sait plus trop… Le marché des frameworks hybrides mobiles est actuellement en pleine transition…
    Alors nous continuons pour l’instant à développer sur Sencha Touch, qui reste pur l’instant gratuit dans sa version 2.4, mais qui n’évoluera plus techniquement…

    J'aime

  7. Concernant le retard sur la stratége mobile, les e-commercant ne sont pas les seuls responsables. Dans leur stratégie, certains outils utilisés ne sont pas encore passé au 100% mobile. En effet, certains outils de tracking des ventes ne prennent pas encore en compte par exemple la provenance de la vente (site mobile ou site web) et ne permet donc pas de mettre en place une véritable stratégie d’achat de trafic spécialement mobile.
    C’est tous les acteurs marketing qui doivent se tourner désormais 100% mobile.

    J'aime

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s