fabernovel loader

13 déc. 2016 | 5 min de lecture

Tech

Application hybride ou native ?

Julien Mession

Head of Innovation


FABERNOVEL CODE
Cette question revient de plus en plus souvent quand nous discutons avec nos clients de leur roadmap produit. Tous sont confrontés à cet arbitrage technique au moment d’aborder la réalisation de leurs applications mobiles. Je vous partage ici mon point de vue.

Directions métiers, startups, institutions, vous souhaitez proposer à vos utilisateurs une application mobile ou tablette qui corresponde à leurs usages. Vous avez cerné leurs besoins, détaillé les User stories associées à ces personae, défini un backlog produit fourni… Mais quelle plateforme technique choisir ? Hybride ou native ?

Applications natives

C’est le standard d’excellence historique. Les applications natives sont développées avec le langage natif de la plateforme de l’appareil. Chaque grande plateforme utilise son propre langage :

  • Objective C ou Swift pour iOS ;
  • Java pour Androïd ;
  • C# pour Microsoft.

Ces langages sont différents, et font le plus souvent appel à des expertises spécifiques. C’est pour cette raison que pour adresser toutes les plateformes, il faut multiplier les développements natifs par autant de langages. L’impact sur les équipes de dev est significatif : vous trouverez des développeurs spécialisés dans chacun de ces langages, mais plus difficilement dans plusieurs.
Le coût peut être élevé, mais le produit final épouse parfaitement les possibilités de chaque plateforme.

L’application myCanal développée par nos camarades d’Applidium en natif est à ce titre un très bel exemple de ce que le natif peut apporter à vos clients : interfaces impeccables, lecture vidéo performante, respect des spécificités de chaque plateforme.

Applications hybrides

Pour comprendre les applications hybrides, vous devez d’abord cerner le concept de webapp. Une webapp est un site web qui propose un fonctionnement « applicatif ». Quand vous naviguez sur ce type de site, vous vivez une expérience à mi-chemin entre le site web et l’application :

  • Site web, car vous êtes dans votre navigateur ;
  • Application car le site propose un comportement applicatif.

En effet, une webapp dispose d’interfaces adaptées (grâce au responsive design) et surtout interactives et dynamiques (grâce à un framework type React ou Angular) qui évitent le rechargement des pages. Gmail, AirBnB, Booking.com… Tous proposent ce type de comportement sur leurs sites web. Comme tout site web, ces webapps sont développées une seule fois avec de l’open web HTML5, Javascript et CSS. Elles tournent sur tous les appareils grâce au navigateur qui interprète le même code, de la même manière, sur n’importe quelle machine.
Une application hybride pousse ce principe plus loin. Il s’agit de développer une application pour toutes les plateformes, avec la même technologie web (une webapp),  puis l’encapsuler dans une « coquille » qui en fera une application mobile, que l’on peut installer via les stores plutôt que via son navigateur mobile.

C’est cette coquille qui fait la différence entre une application hybride et une webapp. Cette couche de code natif permet au code web d’accéder aux fonctionnalités natives de l’appareil. Les comportements attendus d’une véritable application sont donc possibles :

  • fonctionnement hors-ligne ;
  • lancement comme une application, avec son icône dédiée ;
  • exploitation des capacités du système telles que la webcam, le GPS, les notifications, l’accéléromètre
  • stockage local des informations du compte utilisateur, accès aux fichiers…

Phonegap est par exemple l’une des encapsulations les plus utilisées pour les smartphones et tablettes. Phonegap est constitué pour chaque système iOS, Andoïd ou Microsoft d’une couche de plugins natifs (Objectif C, Java, C#) qui rendent disponible en Javascript la manipulation des fonctions natives. Le développeur d’application hybride ne développe ainsi qu’en Javascript pour attaquer toutes les fonctionnalités des différentes plateformes. Idem pour Electron, une encapsulation dédiée aux applications desktop, utilisée par les applications desktop Atom, Slack ou Visual Studio Code.

Time-to-market : avantage HYBRIDE

En permettant de développer une seule fois le code pour adresser de nombreux appareils, l’avantage en temps et budget est évident pour l’hybride.

Attention cependant, car cela reste un développement délicat : le responsive design doit être impeccable et testé sous toutes les coutures. Les interfaces doivent aussi être testées sur de vrais appareils, au risque de grosses déconvenues si les tests se sont contenté de l’émulateur Chrome sur un PC puissant… La logique de déploiement sur les stores est la même que pour du natif : on ne peut pas corriger et mettre à jour le code web à chaud dans l’appli. De ce côté les mécaniques d’intégration continue sont similaires.

Performance : avantage NATIF

Une application native utilise le langage compilé de la machine cible. Elle accède directement aux ressources de l’appareil et est donc plus performant. C’est particulièrement sensible pour les applications qui sollicitent beaucoup la plateforme, comme les applications très graphiques type Jeux, 3D, Temps réel. Pour des applications plus « utilitaires », la perte de performance des applications hybrides est moins sensible. En particulier si le code web repose sur des frameworks web performants comme React ou Angular2.

Ergonomie : (presque) match nul

Pendant longtemps les applications hybrides avaient leur propre style qui dénotait avec le style des composants natifs (date picker, listes déroulantes…), qu’elles essayaient avec plus ou moins de bonheur de mimer. À la clé, un UX tiraillé entre l’une ou l’autre plateforme et plutôt insatisfaisante.

Par contre, pour des applications un peu plus ambitieuses que la présentation de quelques composants de formulaire natifs, il est intéressant de développer une expérience utilisateur spécifique, avec des parcours et une charte sur mesure. Dans ce cas, on peut se permettre de pousser un style propre à l’application, pour peu qu’il repose sur un UX respectant les standards de navigation. L’hybride n’est dans ce cas n’est pas un problème, il favorise même une réflexion sur les interfaces qui s’adaptent aux usages, et non l’inverse. L’amélioration des performances des technologies hybrides les rapproche également des temps de réponses natifs. L’écart a donc tendance à se réduire.

La suite

Si votre touch point mobile est critique dans votre business modèle, le natif reste le standard d’excellence. Le revirement de Facebook il y a quelques années, qui avait tenté l’hybride pour au final revenir au natif est caractéristique et justifié.

Cependant la poussée des applications hybrides est constante. La puissance des appareils, couplée à des frameworks web de plus en plus performants ouvrent de nombreuses possibilités.

Une autre tendance va elle aussi dans les sens de l’hybride : celle de coder en « langage web » une application qui sera compilée en natif, comme le propose React Native. Ici l’application n’exécute plus une webapp branchée sur des plugins natifs, mais véritablement du code compilé pour les machines cibles, tout en permettant de développer avec des standards web. Titanium avait ouvert la voix, mais React Native enfonce puissamment le clou. Une nouvelle frontière est atteinte.

Le monde des technologies web est incroyablement foisonnant, et repose sur des standards partagés. J’ai la conviction que le choix de l’hybride ne sera donc plus toujours lié au budget ou au time-to-market.

logo business unit

FABERNOVEL CODE

Nous réalisons des plateformes Internet en un temps record, en mêlant talents et méthodologies agiles.

à lire