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.
Pour ne rater aucun bon plan, rejoignez notre nouveau channel WhatsApp Frandroid Bons Plans, garanti sans spam !
HTML 5 supportera les caméras ? apn ? GPS ? synthèse vocale, autre spécificités hardware des téléphones , enregistrer des trucs (vidéo) sur la sdcard,... dans tout les OS ? On pourra lire l'accéléromètre en JavaScript ? Je ne pense pas que HTML 5 puisse faire disparaitre les applies 'lourdes' et propriétaires à chaque OS. Continuer avec le SDK Android me semble encore une bonne idée.
Salut a tous, Juste une petite remarque concernant les sites web inappropriés pour les mobiles. J'aime beaucoup votre site et je consulte tous les jours les news sur mon Magic mais pourquoi ne pas adaper Frandroid aux pages mobiles?(comme d'autres sites d'Android). PS: je ne suis pas développeur et je ne connais donc pas la difficulté de la chose ;-)
@allho openGL débarquera prochainement dans les navigateurs.
En même temps HTML5 est super (si personne n'avait IE, ou si IE = Firefox niveau respect des standards, ça serait la fête) mais a ses limites...je vois mal un jeu 3D avec. Par contre la rumeur comme quoi l'Unreal engine pour arriver sur Android (et QUE sur Android apparemment, na) est une bonne nouvelle : c'est le moteur préféré de beaucoup d'éditeurs. Perso dès qu'un ami a sur que l'Unreal pouvvait arriver, il a préféré le Milestone à un iPhone ^^
Pas mal cette intro ! Mais où est l'article ? ;-)
Firefox dispose de composants XPCOM pour accéder aux ressources de la machine. Existe-il un équivalent avec Android Chrome ?
Est ce qu'au contraire les problématiques soulevées par les smartphones ne sont pas une occasion pour mieux repenser son application web en terme d'API métier. (exemple Twitter , application web construite autour d'API REST qui a permis l'emergence d'application heterogenes exploitant ses API) Le souci du portage pour des raisons économique est louable, mais cette question s'est aussi posée pour le portage des applications client/serveur en web. La problématique va bien au delà du HTML5.
mais une application dédié est normalement plus rapide (voir performante) qu'une appli web et surtout économe en bande passante et en data (les forfaits 3G illimités sont tous limité en data...) sinon l'HTML5 va falloir attendre encore quelques années pour qu'il devient le standard...
"The browser is the platform" dixit google ( GWT + gears, ce dernier étant amené à être remplacer par le HTML5 ) Redevlopper un appli pour chaque famille de smartphone est une hérési à mon avis, beaucoup trop couteux et j'imagine même pas la maintenance. Le HTML 5 est l'avenir si ce dernier est suffisamment supporter par les mobiles, reste à voir le model économique car dans ce cas plus de marcket! Le dev spécifique étant réserver à quelque application bien spécifique aynat besoin d'une optimisation...
Par rapport à HTML5, je pense aussi que c'est le future (au moins pour les applis autre que les jeux), mais attention, comme pour java, c'est aussi write once, test every where. Même si la majorité des plateformes utilisent maintenant webkit dans leur navigateur (iPhone, Android, Palm, Symbian, de nombreuses différences sont présente, car chaque constructeur personnalise sa version, ou n'utilise pas la dernière version. Cf article : http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html Mais bon, c'est déjà mieux que sur le web où on doit tester sur IE6...
Petite erreur dans l'article, l'API Windows réécrite s'appelle pas Wime mais Wine. L'ensemble reste cependant très intéressant.
Il est vrai que la pérennité des applis sur mobile semble pas très assurée :s Mais on a toujours l'ergonomie d'une appli dédiée (bien que HTML 5 soit en train de révolutionner ça) qui n'est aussi pô dépendante du réseau !
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix