[Editoid]Porter ou ne pas porter telle est la question !
Depuis l'arrivée des smartphones, se pose de façon régulière la question du portage des applications web existantes sur plateforme mobile.
Le portage a pour lui la facilité, la rapidité et donc le coût.
Un smartphone n'a rien à voir avec un PC ...
Aussi séduisante soit-elle, cette solution rencontre de sérieuses limitations : un smartphone n'a rien à voir avec un PC.
Autre différence évidente : le clavier.
Pour rester dans les différences frappantes, les capacités des réseaux n'ont rien de comparable, ni en terme de bande passante, ni en terme de fiabilité !
La fiabilité des réseaux a des conséquences encore plus importantes : la grande majorité des sites ne fonctionnent pas quand la ligne est coupée.
Dans les différences un peu moins évidentes, on peut citer la consommation excessive d'énergie générée par une application utilisant le réseau de façon intensive …
Bref, les différences sont nombreuses … et au delà de ces différences fondamentalement techniques, une différence structurelle doit également être prise en compte : l'utilisateur est en situation de mobilité !
Il est impératif de présenter à l'utilisateur une information filtrée et pertinente compte tenu de sa situation de mobilité.
Dans le même registre, une application de CRM ne devrait proposer par défaut que les informations liées au clients présents dans l'agenda de la journée en évitant les affichages surchargés, illisibles sur un smartphone.
L'ergonomie des applications doit donc être adaptée aux smartphones ...
Nos smartphones disposent de plus en plus de capteurs évolués qui facilitent l'usage en mobilité : synthèse vocale, reconnaissance vocale, détecteur de mouvements, … sans parler du classique appareil photo.
Le portage est-il pour autant condamné ?
Ceci présente un coût évidemment rédhibitoire : outre le coût direct, la réécriture impose de disposer d'équipes spécialisées sur chaque plateforme et d'accepter d'attendre les délais nécessaires à la réécriture.
La fragmentation des plateformes rend pénible la réécriture sur chaque cible
Pour cette raison, un certain nombre d'outils propriétaires ont émergé pour permettre le portage d'une application vers plusieurs plateformes cibles.
On connait bien cette problématique qui existe depuis des années : Mac vs Windows, Unix vs Windows, … Cela a donné naissance à des générations de L4G qui tentaient de s'abstraire de la plateforme, ou à des librairies croisées apportant l'API d'une plateforme sur une autre (Wime par exemple), ou encore à une API nouvelle, commune sur l'ensemble des plateformes cibles (Qt par exemple).
C'est également cette même problématique que Java cherche à résoudre avec le fameux slogan : « Write once, run everywhere ! » L'expérience montre que toutes ces approches présentent des limites, on a souvent parodié le slogan de Java en « Write once, debug everywhere ! »
HTML 5 : la solution ?
Cependant, une alternative est en train d'émerger : HTML 5.
Evidemment, cette approche séduisante a elle même des limitations : par exemple, la prise en compte et la normalisation de nouvelles interfaces permettant de piloter des périphériques spécifiques.
Cette approche prometteuse est supportée par des sociétés comme Google ou même Apple qui semblent croire en cette voie pour rationaliser le développement Web 2.0 y compris sur plateformes mobiles.
Cette approche, sous les réserves émises précédemment quant à la spécificité de l'ergonomie et du fonctionnement d'une application mobile, permet de faciliter la migration sur plateformes mobiles d'applications web 2.0 existantes et réciproquement de retrouver sur le « web fixe » des applications développées pour des mobiles.