L’histoire de l’informatique est faite de cycle qui ont tendance à se répéter. Nous voici à l’aube d’un nouveau cycle (en fait on y est déjà mais il faut le savoir) client-serveur.

Le mode client-serveur consiste à centraliser la logique métier sur un serveur et de déployer des applications clientes sur les ordinateurs des utilisateurs. Ce mode a été petit à petit abandonné au profit du web car la maintenance de ce genre de système était trop lourde. La simplicité du web a donc conduit les grands penseurs et architectes logiciels à faire autrement et surtout plus simplement. Sauf que la simplicité c’est bien mais le mode connecté du web pose un simple problème: comment faire quand on n’a pas accès au web? Du coup on voit fleurir des solutions de cache côté serveur qui vous permette d’utiliser vos applications web comme si vous étiez connecté (ex: Google Gears , dojo toolkit). Cette brique de base qui permet de se déconnecter du web nous montre le retour du client-serveur ou plutôt la naissance de l’application portée par le web.

Les technologies nous guident vers le développement d’applications

Si vous êtes attentifs aux mouvements technologiques, vous aurez remarqué qu’aujourd’hui on ne parle plus de sites web mais d’applications web. Les technologies qui sont utilisées ne sont plus du HTML, php ou autre mais des frameworks RIA souvent basés sur javascript ainsi que des frameworks RAD côté serveur. Nous voyons pleins de tentative pour fédérer le développement d’applications web: XUL a été lancé dans ce sens (proposer un langage pour développer des applications web), Appcelerator doit être vu aussi dans cette mouvance. L’objectif sous-jacent est de libérer les applications web de leurs liens avec les technologies serveurs. C’est pour cela que j’aime bien l’approche d’Appcelerator (intégration par message). La multiplication de ces initiatives rend le choix d’une technologie côté client de plus en plus difficile: Faut il se lancer dans l’aventure et faire un choix ou attendre que ce secteur murisse et qu’il ne reste plus que 2 ou 3 acteurs.

Afin de répondre à ce besoin, le W3C tente depuis 2 ans de formaliser un standard permettant de développer (/décrire) des applications web (Voir Rich Web Client). Malheureusement les résultats des travaux du W3C se font attendre. Il ne faut donc pas attendre du W3C qu’il nous apporte une solution rapide à ce problème de standardisation des applications web.

Le choix difficile de la technologie

Mais voilà nous avons tous à faire des choix technologiques sans attendre que quelqu’un ait fait le travail nécessaire pour nous simplifier la vie. Du coup il faut savoir appréhender l’évolution des technologies dans le domaine des applications web. A mon avis il faut prendre en compte une donnée importante: les bonnes technologies sont celles qui vont savoir découpler intelligemment le client du serveur. Si l’on prend en compte cela, il faut que la ou les technologies formalisent et stabilisent les échanges entre l’application web et le serveur. Du coup le choix de la technologie côté serveur répondra uniquement à des contraintes serveurs (et non plus web au sens général). Pour moi l’approche orientée service est la bonne actuellement. En ce sens Appcelerator apporte une bonne solution. Le seul soucis devient la dépendance à un langage singulier qu’est celui utilisé par Appcelerator. Un bon compromis serait d’utiliser un framework en javascript comme Dojo afin d’attendre que le formalisme de description d’une application soit partagé par plusieurs projets et technologies.

Pourquoi je n’évoque pas l’utilisation de XUL? XUL est dépendant des produits Mozilla. Cette dépendance au client (navigateur web la plupart du temps) me rappelle l’approche de Microsoft. Cette technologie est à mon avis à utiliser dans des cas très particulier où les clients veulent s’enfermer dans un environnement informatique fermé.