Wap 2.0 : trop complexe ?

Le 1er août dernier le consortium Wap Forum publiait la version 2.0 des spécifications du Wap. Plus de 2600 pages de spécifications qui dessinent l'infrastructure sur laquelle bâtir les services de données des prochains réseaux de téléphonie mobile. Wap 2.0 apportera-t-il le nouveau souffle tant attendu sur le marché dit de "l'internet Mobile" ? L'analyse qu'en donne Ubicco à travers un libre blanc ne rend pas forcément très optimiste.

En soixante pages, la filiale de Fi System, éditeur d'un serveur multi-terminaux, passe en revue de manière plutôt exhaustive et critique les sous-ensembles de cet environnement - protocoles, langages, passerelles, navigateur, etc. Une lecture fort instructive: si Wap 2.0 marque indiscutablement un saut qualitatif par rapport à la version 1.2.1 publiée en juin 2000, il se caractérise aussi par une complexité croissante, aussi bien en ce qui concerne le terminal que les architectures serveur. "La spécification est complexe, certains sous-ensembles sont prêts-à-l'emploi tandis que d'autres s'apparentent davantage à des lignes de direction, observe Cédric Nicolas, directeur technique d'Ubicco. Du coup, il semble probable que les composants de Wap 2.0 seront mis en oeuvre de façon très progressive. En fait, c'est sans doute ce qui manque le plus à Wap 2.0 : un calendrier qui hiérarchiserait l'implémentation des différentes briques". A défaut, la complexité de Wap 2.0 laisse planer de gros doutes sur la capacité du marché à mettre en oeuvre une telle plate-forme.

Sur le papier, les améliorations pour l'utilisateur sont pourtant nombreuses. On notera entre autres que:

- le terminal devient "auto-configurable" - les serveurs assurent sa configuration à distance
- la sécurité est enfin assurée de bout en bout. Sur le chapitre de la sécurité, précisons aussi que le Wap Forum retient le modèle des infrastructures à clefs publiques.
- ll devient possible de naviguer sur un site XHTML (dialecte de XML qui sert de base au W3C pour la ré-écriture d'un langage de présentation plus "propre" que HTML)
- Un système de messagerie multimédia est décrit
- Un modèle unifié est proposé pour la représentation des pictogrammes
- L'interface pour accéder à des périphériques externes au terminal est standardisée


Bref, des améliorations bienvenues mais qui, dans le détail de leur implémentation, semblent souvent complexes, inachevées ou encore excessivement coûteuses en ressources. Sur plusieurs points, dixit le libre blanc d'Ubicco, le Wap Forum donne aussi l'impression d'avoir chercher à "réinventer la poudre". Trois exemples:

- Si la version 2.0 du langage de présentation WML est conçue autour de XHTML, fondation de la prochaine évolution de HTML, la nécessité d'assurer une compatibilité ascendante avec WML1 rend le langage délicat à manipuler. En tous cas, WML2 reste encore bien loin de la simplicité du cHTML utilisé par l'i-Mode japonais.

- La messagerie multimédia (Multimedia Messaging Service), qui vise à échanger des messages riches en contenu en mode asynchrone, représente une belle intention mais dessine un système parallèle à ceux déjà déployés (qu'il s'agisse des protocoles SMTP/PO3/IMAP4 ou des messageries comme SMS). Raisonnable ?

- Pour gérer les relations entre une application Wap et des périphériques externes au terminal, le Wap Forum propose le standard EFI (External Functional Interfaces). Une initiative intéressante mais qui semble encore inachevée. La manière de télécharger des pilotes de périphériques reste encore très floue. De plus, la manipulation de ces interfaces demande de recourir à des API WML et WMLscript. Pourquoi ne pas avoir tenté de capitaliser sur Java ?


Une architecture serveur de plus en plus complexe
Certes, on peut imaginer que les travaux à venir complèteront des protocoles qui laissent parfois un goût d'inachevé. En revanche, il est plus difficile d'estimer le temps nécessaire pour déployer l'environnement Wap 2.0, tant au niveau des terminaux que des serveurs.

Sur le terminal, la multiplication des couches protocolaires (TCP/IP fait d'ailleurs son apparition) va demander beaucoup plus de puissance processeur et de mémoire qu'aujourd'hui, sans oublier la question de l'autonomie. Du côté des serveurs aussi, l'architecture du Wap 2.0 demande d'empiler les passerelles et proxies: passerelle d'en/décodage entre le terminal Wap et les protocoles du Web, proxy de transmission des profils de terminaux, proxy de cache, serveur dit de provisionning (pour la configuration à distance du terminal), serveur PKI (pour la création de certificats à clef publique)... Et la liste est loin d'être exhaustive. Le déploiement d'une architecture, dont les serveurs seront répartis entre opérateurs, autorités de certification, fournisseurs de contenus et portails divers, va forcément demander beaucoup de temps.

Bref, Wap 2.0 dessine une vaste et complexe infrastructure de services de données dimensionnée pour des réseaux GPRS, voire UMTS. Une haute ambition qui ne semble pas faire l'unanimité puisque qu'un autre organisme, la GSM Association, a lancé cet été l'initiative "m-services" qui s'apparente à un sous-ensemble de Wap 2.0. Une initiative plus modeste donc mais qui pourrait profiter des temps de déploiements de l'environnement Wap 2.0... Il est d'ailleurs probable que, dans l'attente d'une mise en oeuvre réelle de cette infrastructure, certains opérateurs optent pour des technologies intermédiaires. Ubicco cite l'i-mode bien sûr mais aussi Java MIDP de Sun, le système STIP du consortium homonyme ou encore le recours à des navigateurs fondés sur des dérivés de XML. La complexité de Wap 2.0 devrait laisser le temps d'explorer ces voies...