L’internet mobile est né sur fond de malentendu. Nombre de fournisseurs et d’observateurs trop enthousiastes ont fait croire aux entreprises qu’elles accéderaient facilement à leurs anciennes applications à partir d’un téléphone portable. Le grand public, lui, s’est imaginé surfer sur le web. La greffe d’une prothèse Wap sur une application ou un site internet existant est certes possible, mais présente d’énormes inconvénients. Finalement, la formule gagnante consiste presque toujours à développer une application entièrement nouvelle, même si elle s’appuie sur des sources de données ou des composants métiers existants.
DE NOMBREUSES CONTRAINTES SPÉCIFIQUES
Les applications horizontales constituent peut-être la seule exception au phénomène de rejet constaté lorsque l’on opte pour la greffe. Les Lotus, Microsoft, Openwave et autres Nextenso fournissent en effet des passerelles qui facilitent l’ouverture d’une porte d’entrée nomade sur une messagerie, un annuaire ou un agenda de groupe. Dans le cas d’un site web, la greffe consiste à traduire un flux HTML à la volée. De nombreux produits du marché (Oracle, IBM ou Nextenso), offrent ainsi des outils de programmation visuelle spécifiant des règles de transformation de pages HTML en WML ou en HTML simplifié. Quelques applications intranet se satisferont peut-être d’une telle démarche. Dans les autres cas, notamment lorsque le grand public est ciblé, l’ergonomie serait déficiente. Avec le coût et la faiblesse des débits, ce fut d’ailleurs l’une des causes du relatif échec du Wap dans l’Hexagone.“En général, le portage d’une application vers la technologie Wap n’a pas de sens. Il faut la reconcevoir d’un point de vue technique et fonctionne l”, résume Cédric Nicolas, directeur général d’Ubicco. Mais il ne s’agit pas de la construire comme un site web traditionnel, dont la technologie et les navigateurs s’avèrent aujourd’hui relativement stables et uniformes. La mobilité comporte en effet ses propres contraintes, liées à l’ergonomie, à la spécificité des fonctions, à la multiplicité et à l’évolution rapide des terminaux, à l’instabilité des standards, ainsi qu’à l’ouverture prochaine des vannes des réseaux.Ces contraintes réservent le codage en dur, c’est-à-dire en WML, aux maquettes ou à de modestes et éphémères intranets ciblant un parc de téléphones parfaitement homogène. Dans l’immense majorité des autres cas, il est souhaitable d’opter pour une conception en couches afin de générer un flux XML adapté à chaque catégorie de terminal. Typiquement, différents composants décriront des interfaces utilisateurs et une navigation respectivement spécifiques aux téléphones Wap, aux Palm, aux Psion ou aux PocketPC. Presque tous les acteurs du marché préconisent alors le recours à Java. Toutefois, l’éditeur Wokup rencontre un certain succès avec un langage propriétaire qui s’appuie sur XML. Sur chaque flux XML seront ensuite appliquées des feuilles de style XSL, de façon à créer le format adapté à chaque modèle d’appareil. De nombreux serveurs d’application multiterminaux reconnaissent le type d’équipement connecté et automatisent cette tâche. D’autre part, dans le cas d’applications embarquées (bases de données ou cartographie) nécessitant des mises à jour ponctuelles, les requêtes seront orientées vers un serveur de synchronisation. L’approche en couches offre également l’avantage de l’évolutivité. De nouveaux composants et feuilles de style seront ainsi développés ou achetés au fur et à mesure de l’émergence de standards, ou de la disponibilité de terminaux plus sophistiqués et de débits plus importants.
LE RESPECT DE RÈGLES ERGONOMIQUES
Parallèlement à ces techniques de développement et de déploiement, le respect de règles d’ergonomie spécifiques représente un point d’autant plus critique que nombre d’utilisateurs de l’internet mobile ne sont pas familiarisés avec le web. “Plutôt que d’afficher d’emblée un texte complet, mieux vaut d’abord proposer un résumé”, conseille par exemple Pascal Thomas, directeur général de Cosmobilis. Plus généralement, il s’agit de simplifier au maximum la navigation et d’adapter le contenu, après avoir analysé avec soin les besoins réels des utilisateurs et le contexte dans lequel ils utiliseront leur terminal. Pour s’en convaincre, il suffit d’imaginer un technicien de maintenance vérifiant sous les yeux de son client la disponibilité d’une pièce détachée.Certaines applications mobiles imposent une démarche d’autant plus spécifique qu’elles mettent en ?”uvre des fonctions entièrement nouvelles, qui s’appuient sur la géolocalisation. Qu’il s’agisse d’un service grand public ou d’une application destinée aux forces de vente itinérantes, il ne faut alors pas hésiter à s’appuyer sur des offres comme celles de Webraska ou Air Flash. Ces éditeurs fournissent des outils de développement ou des plates-formes hébergées accessibles via des API (bibliothèques de fonctions), qui permettent, dynamiquement, de générer des cartes, de calculer des itinéraires ou de répondre à des questions telles que : “Quelle est la station service la plus proche de telle position ? “.Les nouveaux développements ne signifient pas pour autant table rase. Tout d’abord, les applications mobiles iront au minimum attaquer les bases de données et les contenus existants, éventuellement remis en forme. Ensuite, on s’appuiera autant que possible sur des services existants. Cela n’est toutefois envisageable que si l’entreprise a auparavant adopté une démarche modulaire, laquelle consiste à bien distinguer les composants décrivant l’interface utilisateurs des processus métiers ; ces derniers prennent typiquement la forme d’EJB (Enterprise JavaBeans), avec lesquels il est aisé de dialoguer.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
