Application mobile : Natif vs Hybride vs Web Responsive

6 mai 2016 / Développement / Stratégie / 0 commentaire

Lorsque le besoin de développer une solution pour du mobile se présente, une des grandes questions réside dans le choix de la technologie : privilégie-t-on une technologie native, hybride ou un site web responsive ? Quels sont les facteurs de choix ? Quelles sont les différences ?

1. Un choix qui dépend du besoin

Le choix de la technologie sera déterminé en fonction du besoin. Pour cela, quelques questions précises sont à se poser :

  • L’application doit-elle se lancer via un lanceur ou un navigateur web ? Doit-elle être téléchargeable sur les stores ?
  • L’application possédera-t-elle un mode hors-ligne ?
  • Combien cible-t-on de plateformes (OS mobile) ?
  • Quelles spécificités au niveau du hardware du Smartphone ou de la tablette seront utilisées ? Géolocalisation, appareil photo, scan de codes, etc.
  • Quelle expérience utilisateur l’application requiert ? Nécessite-t-elle des interactions tactiles poussées, et une expérience utilisateur optimale ?

2. Quand choisir une technologie native ou hybride par rapport à un site web responsive ?

Note : un site web responsive reste un site web accessible depuis un navigateur. Ce n'est pas au sens propre une application mobile.

Lorsque :

  • L’application doit être téléchargeable sur les stores
  • L’application doit se lancer depuis un lanceur sur le téléphone (hors raccourci navigateur web)
  • L’expérience utilisateur (UX) est une priorité
  • L’application a accès au hardware (hors GPS, téléphone ou stockage temporaire)
  • L’application requiert un mode hors-ligne
  • L’aspect maintenance est plus important que l’aspect portabilité de l’application
  • L’application nécessite une gestion des mises-à-jours

Le choix s’orientera vers une technologie hybride ou native. Dans les autres cas, on s’orientera vers une technologie web.

3. Quand choisir une technologie native plutôt qu'une technologie hybride ?

Je recommande le choix de la technologie hybride pour du crash test d'application, pour une application statique (peu ou pas d'interactions utilisateur) ou pour une application dédiée à un événement particulier / récurrent. Pour le reste, je recommande fortement l'utilisation de la technologie Native.

D'autre part, chaque OS a sa propre approche en termes d'ergonomie et de design. De fait l'expérience utilisateur s'avère parfois très différente, selon que l'on soit sous Android, iOS, Windows Phone, ou d'autres. Selon le besoin, par exemple dans le cadre d'une application mobile destinée au grand public où l'aspect ergonomique prédomine, on préférera l'utilisation de la technologie native. Cela permet une expérience utilisateur optimale pour chaque OS ciblé, et donc de meilleures chances de réussites de l'application.

On notera quelques subtilités sur ce choix :

En termes de maintenabilité, le choix de l’hybride implique de maintenir une seule application, alors que le nombre d’applications natives à maintenir dépendra du nombre d’OS ciblés. Cependant, la maintenance d'une application hybride peut être plus coûteuse (voir l'article Comment industrialiser les applications mobiles hybrides).

En termes de réutilisabilité du code, pour l‘hybride, selon le Framework utilisé, 70 à 95 % du code de l’application est réutilisable. Le pourcentage restant correspond aux adaptations spécifiques pour chaque OS ciblé. Pour le natif, chaque OS a sa propre application, le code n’est pas réutilisable d’une application à une autre.

Enfin, il faut savoir tout de même qu’une application hybride prend en moyenne 30% de temps de développement en plus par rapport à une application native.


Qu'avez vous pensé de cet article ?

FacebookTwitterLinkedInPinterestViadeo

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

*

François Colin

Co-fondateur chez huco

Catégories Développement Stratégie.

Même catégorie

Application WeWay : 1 an après
L’innovation dans le coworking
Technologie native, technologie hybride
#GoogleIO2016 : les points clés