C’est entendu, la refonte des applications ou le développement de nouvelles est certainement l’approche la plus profitable à moyen terme. Mais il existe quelques avantages à opter pour l’alternative, qui se résume à greffer une prothèse mobile sur une application existante. En effet, une telle démarche présente le mérite de ne pas être intrusive, et elle permet de démarrer rapidement un intranet mobile. Elle ne sera pas très pérenne, mais elle restera en harmonie avec les investissements modestes consentis. En somme, c’est une solution tactique, qui permet de justifier de futurs développements. En contrepartie, l’ergonomie se révélera moyenne, et les ressources système consommées en phase d’exploitation seront importantes.
Conversion du flux à la volée
La principale méthode peut être assimilée au rhabillage d’applications. Il s’agit de récupérer un flux existant et de le convertir à la volée, dans un format HTML bridé (mini-HTML) ou WML (Wireless Markup Language), respectivement pour les assistants numériques et les terminaux WAP. Ce flux sera, par exemple, de type 3270 (grands systèmes IBM), ou constitué de simples messages électroniques. La plate-forme MIB (Mobile Internet for Business) de France Télécom transforme ainsi à la volée des messages formatés en applications WML. Mais, le plus souvent, l’application existante générera du HTML. L’entreprise aura d’ailleurs intérêt, si c’est possible à moindre coût, à pratiquer de cette manière avant de cibler les terminaux mobiles. La méthode fonctionne assez bien si l’application initiale est peu interactive et qu’elle se contente de diffuser des informations. Sinon, il peut être intéressant de la retravailler un peu. Dans les deux cas, de toute façon, la phase de transformation du flux doit absolument être intelligente.
Les portails multiterminaux ou la réécriture des applications
lle pourrait être prise en charge par des développements spécifiques. Mais la démarche apparaît quelque peu “légère”. Et mieux vaudra mettre en ?”uvre des portails multiterminaux, dont les fournisseurs – Oracle, Nextenso, ou IBM – se multiplient. Même si le rôle de ces produits ne se réduit pas à cela, l’une de leur fonction consiste à prendre en charge la transformation à la volée. Ce processus consiste notamment à sélectionner, pour chaque type de terminal, des URL, puis les champs fixes et variables que l’on veut convertir, et, enfin, les règles de transformation. En phase d’exploitation, le moteur exécute ces règles et applique des feuilles de style fournies par les éditeurs, et qui cibleront chaque modèle de terminal, actuel ou futur.La solution de rechange à de tels moteurs, qui ont un coût, réside dans une très légère réécriture des applications intranet. Il est alors possible d’écrire un deuxième code calqué sur le premier, qui permettra de générer des pages WML. Défaut de cette option : on se fige totalement sur un type de terminal, voire sur un modèle particulier.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
