L'avis d'un ergonome sur le débat applications mobiles : web ou natif ?

Introduction

Les applications mobiles ont le vent en poupe. Chaque société veut mettre à disposition son site mobile, question d'image. Ca me rappelle les années 2000 avec la frénésie du web. Là encore, il faut bien disjoindre les applications vitrines destinées à donner une image commerciale de modernité et les véritables applications mobiles prenant en compte l'itinérance de l'utilisateur.

Comme pour les applications classiques, je suis souvent confronté au dilemme sur l'approche à tenir : application web ou application native. Ce choix est devenu est véritable débat, la plupart du temps alimenté par les seuls techniciens. En tant qu'ergonome, je me lance pour parler sous l'angle de l'utilisateur final.  En tant que technicien, c'est le retour d'expérience d'un vieux briscard de l'implémentation d'IHM.

Origine du débat

La montée en puissance des smartphone et des tablettes pose des problèmes majeures aux DSI. En effet, la profusion de device s'accompagne d'une pléthore de système d'exploitation, chacun proposant son ergonomie et son environnement de développement associé (android SDK/Java, Xcode/Objective C...). Les problématiques évoquées le plus souvent sont les suivantes : 

• Comment adresser l'ensemble des plateformes sans exploser les coûts de développement ?
• Comment vais-je trouver des développeurs compétents dans toutes ces technologies ?
• Comment maintenir sur le long terme si le code est redondé sur chacune des plateformes ? 

La réponse est pourtant simple, HTML5 sachant par définition tout faire, je vais résoudre mes problèmes en faisant une application Web : 

• Le code de la couche de présentation étant factorisé, je ne maintiens qu'une seule base de code
• Je n'ai plus besoin de compétences spécifiques, des développeurs Web, plus faciles à trouver et donc moins chers, suffisent. 
• Toutes les plateformes supportant HTML5, je ne gère plus qu’un seul environnement de développement

Sur le papier, la démonstration est imparable et la solution séduisante. Les arguments sont en effet recevables mais doivent être relativisés :

• Les applications webs font elles aussi cohabiter plusieurs langages (CSS, Javascript, html, framework  web) : un bon développeur Javascript n'est pas aussi facile que cela à trouver 
• A l'usage, il peut subsister du code spécifique en fonction du navigateur. Ne déplace-t-on pas le problème, avec une application multi plateforme, certes, mais pas multi navigateurs ?
•  Il n'y a pas tant de code que cela pour la programmation des UI mobiles, ces applications sont souvent très simples. Au delà de 10 écrans, on peut s'interroger sur leur pertinence ergonomique. Rappelons que Apple recommande des applications mono fonctionnelles.
• En terme de part de marché, adresser 2 voir 3 plateformes semble suffisant. Aux USA, Android et IOS occupe 80% du marché. Etant donné la fragmentation de la part de marché restante, quel est l'intérêt économique d'adresser des plateformes supplémentaires ? 

Les considérations techniques

Je n'ai pas connaissance d'autres arguments en faveur du développement web mobile. Voyons maintenant la réalité d'un point de vue technique. On a deux types d'approches pour le web mobile :

• Site web mobile : application web classique dont le rendu est adaptée à la taille réduite de l'écran
• Solution hybride (type phoneGap ou Titanium) : utilisation d'un framework faisant tourner une vue web dans une application native, ce qui permet de déployer l'application sur le market (App Store, Google play…) et de lever certaines limitations techniques (Ex : accès à la plupart des capteurs du device). 

Dans les deux cas, on peut chercher à approcher le rendu natif : cette approche type "canada dry", fait dire aux partisans des applications webs que ces applications n'ont rien à envier aux applications natives. Les applications natives seraient-elles donc promises à une mort certaine ?

Pas si sûr, car, en introduisant une couche d'abstraction supplémentaire, les solutions hybrides posent les problèmes suivants :

• Effet boite noire de la couche d'abstraction : difficultés à customiser le rendu visuel du code natif généré.
• Risque de régression accrue sur un code factorisé entre plate forme : une correction pour une plate forme risque de déstabiliser les autres.
• Le natif a toujours un coup d'avance sur le framework : le décalage fonctionnel est inévitable entre la couche d'abstraction et la dernière version de l'API graphique (Ex: les nouveaux composants Android 4.0 sont-ils supportés ?).
• La couche intermédiaire a fatalement un effet négatif sur les performances et donc la réactivité de l'IHM, qui sera indexé aux performances du navigateur pour le rendu HTML et l'exécution de code javascript.

D'autre part, et c’est un élément souvent ignoré, la productivité des solutions natives est très bonne grâce à une excellente ergonomie de développement :

• Debugage en temps réel sur le device permettant d’identifier rapidement tout problème, y compris ceux liés à l’interface tactile)
• Temps de cycle entre correction dans le code et visualisation du résultat sur le device au plus court (de 1 à 3 mn sur Android)

Ceci est à mettre en perspective avec la productivité des applications Webs qui est loin d'être démontrée. Certains problèmes (liés au comportement de l’IHM) ne se produisant que sur un device, sont très difficilement identifiables, conduisant à des séances de débogage « dans le noir », avec une démarche de type essai/erreur. Or comme, il faut parfois plus de dix minutes entre l’essai et le résultat sur le device (temps de compilation et de déploiement), on peut passer des jours à corriger des bugs d’affichage.

Hormis la courbe d'apprentissage initiale et la réticence aux changements des développeurs habituées à la programmation web, je doute du retour sur investissement concernant les coûts de développement. Au-delà de 20% de code spécifique, on perd l’intérêt de la factorisation. En dessous de 3 plateformes à adresser, les gains liés à la factorisation sont contrebalancés par une perte de productivité. Ainsi, si l'on adresse uniquement les 2 plateformes se taillant la part du lion sur le marché, on est à mon avis en dessous des coûts d'une solution unique web.

La maturité

Le développement natif permet l'accès à toutes les ressources matérielles et logiciels du device, de façon mature :

• Accès aux capteurs (GPS, accéléromètre....)
• Accès aux données du téléphone
• Accès aux autres applications (Agenda, Contacts....)

Si cela n’est pas impossible en Web, c’est à la fois plus difficile et moins mature. En outre,  le support de HTML5 sur navigateur mobile demeure problématique et l’on se retrouve avec une situation similaire avec celles des navigateurs desktop du milieu des années 2000 ;

• Support inégal de HTML 5 entre les navigateurs mobiles : le pire étant celui d'Android, (véritable Internet Explorer de la mobilité)
• Risque de code spécifique en fonction du navigateur
• Même les solutions hybrides ne parviennent pas à se connecter aux autres logiciels du système (agenda, contacts..).

Les considérations ergonomiques

Comme pour les applications web classiques, le choix web conduit, selon moi, à une expérience utilisateur dégradée

•  Le choix des composants graphiques limité à ce qui fonctionne partout : notion de plus petit dénominateur commun ergonomique
•  Gestion approximative de la taille des écrans : la difficulté à réaliser une application web plein écran (sans barre de défilement), fait tellement exploser les coûts qu'on en arrive à faire des IHMs en taille fixe, soit trop grandes (sur les petits écrans), soit trop petites (sur les gros écrans)
• Gestion approximative des interactions tactiles : l'ergonomie web n'est pas conçue pour le tactile, les gestures sont à recoder en HTML5 (avec le risque d'incohérence avec le gesture natif).
• On peut se poser la question sur la prise en charge d'autres fonctionnalités en web : basculement portrait/paysage, retaillage des ressources graphiques sans effets d'étirement (type nine patch en Android)...
• Le surcout des améliorations ergonomiques est tellement élevé (Ex : faire une IHM web redimensionnable sur plusieurs navigateurs), qu'au mieux il compromet gravement les gains sur les coûts de développement. Plus souvent, il conduit à faire de graves concessions sur l'ergonomie (Ex : IHM en taille fixe)  

L'ergonomie des applications dépend de la plate forme

• Les variations entre plateforme dépassent le simple rendu visuel des composants graphiques (skin)
• Les composants graphiques ne sont pas les mêmes entre plateforme (Ex : equivalent du splitView iOS en android, équivalent des tile Windows Phone)
• L'imitation du rendu natif en web est une mauvaise pratique : on perd la factorisation si on reproduit l'ergonomie de chaque plateforme, on pénalise les utilisateurs des autres plateformes si on choisit l'une des ergonomies.
• A moins d'enfreindre la règle de cohérence avec le système d'exploitation, la seule ergonomie possible est une ergonomie web dont les normes semblent très mal connues en situation de mobilité.

Conclusion

D'un point de vue technique, le développement Web est loin d'avoir démontré sa productivité. A niveau de compétence égal, il est à mon avis au moins deux fois moins productif qu’un développement natif pour une expérience utilisateur très inférieure. La réduction des coûts de développement est un leurre : ce qu'on gagne en factorisation on le perd en tests et en code spécifique pour gérer les différences entre navigateurs et maintenir une ergonomie acceptable.

Plus grave, à mes yeux d'ergonome, le choix du web conduit selon moi, immanquablement à une expérience utilisateur dégradée. Ainsi, choisir l'application web revient à arbitrer en faveur de la technique au détriment de l’utilisateur. C’est à mon sens, ce qui s’est passé avec la venue des applications web dans les années 2000, avec un recul ergonomique des applications webs par rapport à leurs ancêtres en client/serveur, certes plus difficiles à déployer, mais tellement plus adaptées. Cependant, les exigences ergonomiques des applications mobiles sont bien plus importantes : l’utilisation en situation de mobilité impose une ergonomie optimisée, la taille des écrans et les nouveaux modes d’interactions changent la donne, les utilisateurs mobiles sont également très exigeants. Bref, ceci ne me semble pas compatible avec les contraintes des applications webs.

Le choix de l'application web peut néanmoins se justifier pour des équipes expérimentées en html/css/javascript et pour des applications à forte diffusion, sous réserve d'une utilisation occasionnelle avec peu de saisie (applications orientées document et non interactions). Pour les autres, la solution me semble évidente. Le développement en natif offre une meilleure flexibilité pour s'adapter aux fluctuations du marché : au lieu d'adresser d'emblée toutes les plateformes, on commence par la plateforme avec le plus de part de marché. N’est-ce pas une manière de ne pas se complexifier inutilement le problème ?

Ce type de débat, illustre selon moi, d’une part, l’approche techno centrée des architectes logiciels (qui ont souvent un angle mort sur les aspects IHM), et d’autre part, la vision strictement comptable des chefs de projets. Tout est résumé dans la phrase de Phil Libin (CEO d’Evernote) :  

« We could probably save 70% of our development budget by switching to a single, cross-platform client, but we would probably lose 80% of our users. ».

Ainsi, si ces débats sont sains, il ne faudrait pas qu’ils cachent d’autres problématiques, tout aussi importantes, lorsqu’on aborde un projet mobile :

• Comment adapter mon application à une utilisation en mouvement ?
• Comment adapter mon application à l'interaction tactile ?
• Comment adapter mon application à un écran si petit ?
• Comment mon application va-t-elle exploiter les fonctionnalités spécifiques à la mobilité (géo localisation, appareil photo...) ?