[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. Par portage, il est entendu ici l’utilisation d’un moyen technique pour transformer une application existante pour la rendre accessible sur un smartphone ou sur une autre plateforme mobile.

Le portage a pour lui la facilité, la rapidité et donc le coût. Autant d’éléments importants, en particulier dans cette période de crise que nous traversons actuellement. De plus, la course à la visibilité, amène les entreprises à développer le plus rapidement possible un service mobile pour occuper le marché au plus vite. Le portage est donc une solution très attrayante.

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. Certaines différences sont évidentes : taille et résolution de l’écran, qui imposent un scrolling permanent à l’utilisateur d’une application non adaptée aux mobiles.

Autre différence évidente : le clavier. Physiques ou virtuels, ils sont d’un usage pénible et leur utilisation doit être réduite au maximum.

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é ! Qui n’a pas été déçu en surfant sur des sites inadaptés via internet mobile ? Les sites d’aujourd’hui sont chargés d’images lourdes et d’animations flash qui ne donnent pas satisfaction aux utilisateurs mobiles. Compte tenu de la bande passante généralement disponible, il faudrait presque revenir aux heures héroïques dont la page d’accueil de Google est un vestige !

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. Même si la couverture 3G est satisfaisante aujourd’hui, des zones blanches subsistent. Là encore, une application mobile bien conçue se doit de prendre en compte cette contingence.

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é ! Pourquoi lui proposer, voire imposer, le même service que celui qu’il pourrait confortablement utiliser sur un PC disposant d’un grand écran, d’un vrai clavier et d’un réseau puissant ?

Il est impératif de présenter à l’utilisateur une information filtrée et pertinente compte tenu de sa situation de mobilité. Par exemple : utiliser des informations de géolocalisation pour ne présenter que les informations localisées à proximité.

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. Autant de périphériques inexistants sur un PC. Pourquoi se priver de ces nouvelles possibilités dans les interfaces des applications ? Un nouveau service mobile doit donner un confort d’utilisation au moins à la hauteur de ses concurrents.

Le portage est-il pour autant condamné ? Si effectivement tous les éléments précédents plaident en faveur d’applications spécifiques, un élément supplémentaire est à prendre en considération : la fragmentation des plateformes mobiles. La bataille fait rage entre les acteurs historiques (Windows Mobile, Symbian, RIM) et les nouveaux entrants (Apple, Android). Cette situation impose aux fournisseurs de services ayant fait le choix d’une application spécifique de réécrire cette dernière sur les différentes plateformes cibles.

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. Proposant le navigateur comme interface entre l’utilisateur et la plateforme sous sous-jacente, HTML 5 devrait permettre de développer une application sur une plateforme unique et normalisée.

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. Conformément aux promesses du web 2.0, l’expérience utilisateur sera alors identique ou du moins similaire quelque soit la localisation de l’utilisateur ou le périphérique qu’il utilise.