Bataille rangée autour des interfaces d’accès

Autour de ce que l’on pourrait nommer de manière générique les interfaces riches il y a profusion d’acronymes : Silverlight, Apollo, WPF, WPF/e, FLEX, AIR, JavaFX, GWT, SWING, etc.

Le but de toutes ces démarches : contrôler l’accès aux ressources web.
Le levier qu’elles utilisent toutes, ou l’argument qu’elles mettent en avant : une meilleure interface utilisateur et une meilleure ergonomie (user experience).

Une bonne manière d’éclairer les enjeux autour des interfaces riches – pour lesquelles j’utiliserai l’acronyme RIA – est de les présenter en parallèle des enjeux autour du SaaS (software as a service).

Les offres RIA sont clairement une menace pour les pure-players du SaaS. En effet, ceux-ci offrent leurs services via le navigateur : enlevez le navigateur à Google et il s’effondre immédiatement. C’est ce qui explique le soutien financier qu’apporte Google à Firefox. En effet, le partenariat de la barre de recherche Google dans Firefox permet d’alimenter financièrement la fondation Mozilla. Il n’est pas là pour inciter à utiliser Google – il n’en a pas besoin – mais pour s’assurer de la disponibilité d’un navigateur standard et indépendant, permettant d’accéder aux services de Google.

Ainsi, pour les acteurs traditionnels de l’industrie du logiciel, et on pense bien évidemment à Microsoft, le navigateur est le talon d’Achille des pure-players du SaaS. Ils s’y attaquent donc, mais comment ?
Cela se fait sous, au moins, trois angles d’attaque :

  1. Montrer de belles interfaces : donner envie.
  2. Démontrer la nécessité de continuer à utiliser les applications en mode déconnecté.
  3. Insister sur l’avantage de capitaliser sur des applications de bureau qui ont accès aux fonctionnalités du système d’exploitation et aux tierces applications.

Forcément, comme l’assaut sur navigateurs traditionnels se déroule selon plusieurs axes, cela apporte une certaine confusion (sans compter avec la multiplication d’acronymes et de noms de code qui disparaissent au gré de la maturité des équipes marketing des uns et des autres.).

Pour débroussailler le terrain, il faut faire une première distinction entre les RIA : les RWA (Rich Web Application) et les RDA (Rich Desktop Application ) :

  • Les RWA se servent du navigateur comme conteneur : c’est par exemple un plugin/module qui va enrichir les capacités natives de l’interface graphique du navigateur. Dans cette catégorie des RWA On retrouve Silverlight de Microsoft (ex WPF-e) et Flex de Adobe. Mais aussi Google, avec son GWT (Google Web Toolkit), qui est partie prenante dans l’évolution du navigateur. Une des particularités des RWA est qu’elles n’accèdent pas aux ressources du Desktop ou de l’OS sur lesquelles elles tournent.
  • Autre version des RIA, les RDA. Contrairement au RWA elles sont totalement indépendantes du navigateur Web et ont la capacité d’accéder aux ressources du Desktop /OS. AIR est la déclinaison d’Adobe (en gros c’est du Flash dans une application de bureau) et WPF (Windows Presentation Foundation) celle de Microsoft. [Petite remarque en passant, seul WPF propose de faire du 3D en natif, mais c’est un détail pour ce qui nous occupe à présent].

Le salut des offres SaaS natives passe donc par des RIA en mode RWA (Rich Web Application). Et c’est tout logiquement que Google va mettre le paquet sur GWT. En passant, si vous développez avec GWT essayez GWT Designer, c’est ce que conseille Didier Girard (et il faut toujours écouter ce que dit Didier Girard). Salesforces, autre pure player historique du SaaS, a déjà annoncé via son offre VisualForce, qu’il permettait à ses clients de basculer les interfaces web traditionnelles en RWA (en l’occurrence on peut utiliser Flex). Sur ce dernier point, on peut trouver ici une galerie photo expliquant VisualForce en image.

Enfin, pour éviter l’hémorragie vers les RDA, les pure players du SaaS doivent répondre à la question du mode déconnecté : c’est la vocation de Google Gears (déjà utilisé par Zoho, un concurrent de Google Apps). Mais Google Gears n’est pas parfait car il laisse en suspend une question plus qu’épineuse qu’est la synchronisation des données lorsqu’on se re-connecte. Travailler en mode déconnecté est une chose : synchroniser les données lors de la re-connexion en est une autre.

Voilà donc le tableau de la situation des forces en présence en ne mettant en avant que les initiatives de Adobe (Flex en RWA et AIR en RDA), de Microsoft (Silvelight en RWA et WPF en RDA), et Google (GWT en RWA et Google Gears en palliatif aux RDA). A ces initiatives, on pourrait en rajouter d’autres comme celle de Sun avec JavaFX, mais cela reste secondaire dans le cadre de cette note.

Ce tableau rapidement dressé, esquissons quelques hypothèses sur les tendances à venir :

  • tout d’abord le navigateur web classique ne va pas disparaître, les pages en html sont là pour durer ne serait-ce que pour la consultation (et pour ne pas décevoir ceux qui qui veulent continuer à surfer).
  • les RWA sont la clef de voûte des acteurs pure player du SaaS, elles vont connaître une forte croissance dans les mois à venir. D’autant plus que c’est le champ de bataille actuel sur lesquel les acteurs offrant par ailleurs des RDA ont une déclinaison.
  • côté RDA, il y aura peu d’élus. Car autant on peut accepter d’avoir plusieurs pages web ouvertes sur son bureau (ou dans des onglets), autant il devient lourd d’avoir plusieurs RDA en même temps. Les premiers à s’engouffrer sur les RDA sont ceux qui proposent des actes d’achat en ligne (l’expérience utilisateur favorisant l’acte d’achat), et l’on retrouve tout naturellement des vendeurs disposant d’un catalogue : FNAC et eBay dès à présent, et certainement les grands acteurs du retail (mais aussi, par analogie avec la notion de catalogue, peut être des institutions comme les bibliothèques tiens, en passant). Toujours côté RDA, vont émerger les applications en entreprise à la mode « software + service » (dénomination qui va certainement changer) pour les entreprises qui voudront construire sur, et autour, de leur patrimoine applicatif.

Une remarque pour finir, les RDA ne sont pas des pures fictions qui n’arriveront que dans plusieurs mois, certains en ont déjà fait leur fer de lance : vous connaissez iTunes ?

Plusieurs remarques pour compléter ton billet :

– Tout d’abord, tu oublies une techno non négligeable : XUL créé par la fondation Mozilla, entre autres pour Firefox et le framework indépendant Xul Runner qui permet de faire fonctionner une appli XUL sans firefox. Évidemment, la fondation Mozilla ne souhaite pas investir massivement sur XUL en tant que tel et souhaite s’appuyer sur la communauté du logiciel libre. On targuera comme l’a fait récemment Clever Age (http://www.clever-age.com/veille/clever-link/xulrunner-a-suivre-ou-a-eviter.html) que Xul pose des problèmes en terme de doc et d’environnement de développement, mais je ne sous-estimerai pas la force de la communauté du libre d’une part et, d’autre part, XUL est le langage qui a le plus démontré : firefox et thunderbird en premier lieu, mais aussi Miro, Songbird (http://www.songbirdnest.com/) ou Joost (http://www.joost.com/)…

– Google Web toolikit, quant à lui, s’appuie entièrement de façon native sur les navigateurs, puisqu’il permet de créer des appli en AJAX (donc javascript) en s’appuyant côté serveur sur JAVA. La différence est donc de taille avec Silverlight qui réclame l’installation d’un plugin (cf tafiti : http://www.tafiti.com/)

– Enfin, sur l’utilisation en mode déconnecté des applis en ligne, il existe la solution proposée par Google (google gears), mais il existe aussi actuellement une autre solution en cours de normalisation au sein du consortium WHATWG et qui finira par être transposé au W3C (dans HTML 5 ?). Cette solution sera implémentée dans Firefox 3 (déjà implémenté dans Zimbra : différents billets de Tristan Nitot : http://standblog.org/blog/tag/offline) et il est à parier que Opera et Safari suivront, en tant que participant au WHATWG. Quand on voit l’impact qu’ont eu Firefox et la communauté Mozilla dans la bonne utilisation des standards CSS et HTML, je ne doute pas que cette implémentation indépendante, ouverte et libre aura forcément une répercussion.

[Reply]

Merci pour ces biens bonnes précisions.
WHATTWG traite-t-il les problèmes de synchro et Google participe-t-il au consortium (j’ai la flemme de chercher 🙂 )

[Reply]

1- Oui

2- Non

Google a tendance à faire le jeu du libre et des standards quand ça l’arrange…

[Reply]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.