Développement mobile : serez-vous plutôt Natif ou Hybride ?

Par Cédric Belmont, Responsable Avant-Vente & Consultant Offres Digitalisation et Mobilité, Hardis Group

Tout a déjà été dit sur Internet sur le sujet. Comme d’habitude, il y a les pour et les contre pour chacune des solutions. Difficile de prévoir une tendance et de prédire l’avenir. Il y a 2 ans nous pensions tous que les WebApps (Application Web orienté mobile) allaient remplacer les Apps (Application mobile). Mozilla avait même déjà préparé son store… et puis non, les apps continuent de prospérer et se développer, hybrides ou natives.

Mais au fait, le développement natif, c’est quoi

Commençons par un petit rappel sur ce qu’est le développement natif. Disons pour faire simple que les éditeurs de solutions mobiles que sont Apple, Google ou Microsoft ont doté leur solution d’outils (un SDK, voilà c’est dit) permettant de créer des applications propres à leur solution, et leur Store (appstore, Google Play, Windows Store).

Pour développer une application pour un iPad ou un iPhone, il faut utiliser les outils Apple (un Mac, le compilateur xcode) et développer avec le langage Objective C. Chez Android (Google), le langage est Java et l’outil est principalement Eclipse…. Et le discours est le même chez Microsoft pour Windows Phone : l’outil est Visual Studio, le langage C#.

Les outils sont donc spécifiques à chaque type de terminal, et les capacités d’intégration très proches du matériel.

Le développement hybride, c’est quoi

Si nous écartons les solutions basées sur les générateurs (pas vraiment de l’hybride, détaillées plus bas dans ce texte), les solutions hybrides reposent essentiellement sur la solution PhoneGap / Cordova (déclinaison Open Source de PhoneGap, propriété de Adobe).

Cordova est une capsule embarquant les technologies standards du développement Web actuel : HTML5, CSS3, et Javascript pour transformer tout cela comme une application native. Cette capsule contient des plugins, véritable passerelle entre le monde web, et le monde natif, seul monde connu par le mobile.

Cette solution nous permet d’utiliser un seul et même outil pour le développement (Eclipse par exemple) et les langages issus du développement Web pour tous les mobiles (iOS, Android et Windows). Le développement est ainsi mutualisé.

Alors, l’hybride, c’est mieux ?

Oui, si on prend en compte essentiellement les 2 axes que sont le budget (mutualisation du code) et l’accessibilité pure Web (via un navigateur) de l’application.

Non, si on prend en compte la richesse ergonomique et la gestion des ressources du téléphone (NFC, iBeacon, Carnet d’adresses, fonction de téléphonie…), accessibles qu’en natif.

Les puristes du développement natif s’appuieront sur ces arguments d’ergonomie (gestion de tous les évènements possibles comme l’appui long etc..) comme sur ceux de la performance. Ce dernier aspect était vrai il y a 1 ou 2 ans, avec certains mobiles peu performants, bon marché, principalement sous Android, et avec des versions de Webkit anciennes (webkit = moteur hybride). Mais les mobiles actuels (iOS depuis longtemps, Android depuis les versions 4) ont corrigé cela. Les objets Javascript sont eux aussi devenus mieux finis (certains jeux comme Angry Birds peuvent facilement intégrer des frameworks Javascript pour jeux), Webkit est très performant.

On parle beaucoup d’UX, UI design… il n’y a pas d’impact en hybride ?

Non, ou presque. Les fondamentaux de l’expérience utilisateur ne sont pas toujours dépendants de la solution de développement, et les bibliothèques Javascript actuelles (JQueryUI, JS Gaming) permettent de proposer des applications très ergonomiques, très proches des possibilités des solutions natives (slider, appui, …), et de reposer sur des concepts d’architecture très propre (DoJo, Angular…). Le Responsive Design (intelligence du design en fonction de la taille du mobile) est aussi possible dans les 2 cas.

Et les générateurs ?

Une autre solution pour mutualiser le développement entre toutes les plateformes mobiles seraient les générateurs. Ils permettent avec des outils propriétaires de développer une application dans un langage commun (C#, Java, Javascript), puis de générer ce développement en une solution native. Elles présentent 2 avantages : elles sont souvent performantes (c’est du natif) et n’utilisent qu’un seul langage de développement pour toutes les cibles (mutualisation du code, comme l’hybride).

C’est gagné alors ?

Non, ces solutions étant propriétaires, elles dépendent d’éditeurs qui ne maitrisent pas toujours le marché (le moteur Hybride est Webkit, développé par Google… et Apple), et posent le problème de la pérennité de la solution, avec des compétences rares.

La bonne recette

Comme toujours en cuisine, la bonne recette est une affaire donc de savoir-faire, de goût, de moyens, et de temps.

Et dans les moyens, la véritable solution pourrait être un savoureux mélange d’hybride (pour l’affichage notamment), et de natif (pour les fonctionnalités très complexes, ou trop proches du mobile). La capsule hybride permet d’utiliser des fonctionnalités natives (lecture du carnet d’adresses) depuis du code Javascript (oui, on retrouve ici le plugin, qui peut être développé si besoin).

L’état de l’art, pour résumer…

Si l’état de l’art se tournerait encore vers le natif, les solutions hybrides gagnent de plus en plus de terrain sur le marché des solutions d’entreprise (B2B, B2C, B2B2C…). Mais la crise est passée par là ! Aussi, la Digitalisation est devenue stratégique pour s’en sortir, emportant avec elle les développements mobiles. Le coût de la mutualisation du développement des applications est devenu aujourd’hui un argument trop fort pour le négliger.

Les technologies natives restent encore la cible privilégiée pour les jeux, les animations et les solutions de gamification… ce qui, dans la conception d’un UX Design pertinent et d’un usage valorisant, peut s’avérer déterminant.

Publicités

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 )

Photo Google+

Vous commentez à l'aide de votre compte Google+. 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 )

w

Connexion à %s