Après l'ère des mainframes, du client-serveur et du web, voici celle de l'architecture orientée services (SOA), qui s'impose peu à peu comme la quatrième vague informatique. Mais, « cette architecture ne possède pas de couche de présentation », note Laura Ramos, analyste chez Forrester Research. Restait donc à lui trouver une interface utilisateur.

Trop chers à maintenir, les clients lourds de première génération ne séduisent plus. Et les clients légers web déçoivent par leur ergonomie. Avec son déploiement en un clic, sa capacité à gérer le mode déconnecté et une ergonomie identique au client lourd, « le client riche est l'interface graphique utilisateur de prédilection des architectures orientées services », conclut Christophe Raymond, directeur technique de Cegid. Forrester Research estime que le client riche pourrait représenter 30 % des interfaces graphiques utilisateurs dès 2005.

En France, l'engouement commence à se faire sentir chez les éditeurs, qui vont contribuer à démocratiser cette architecture. « Le premier facteur d'adoption de ce type de technologie est la richesse du portefeuille d'applications disponibles. Les éditeurs sont donc fondamentaux pour la réussite de notre client riche Java », confirme Michel Granger, directeur marketing région Ouest d'IBM.

Les ISV (distributeurs de logiciels indépendants) se concentrent généralement sur un socle Java propriétaire et.Net de Microsoft. Cegid et VCSTimeless, deux éditeurs de progiciels de gestion, ont privilégié.Net. « La fusion des applications de gestion dans les outils bureautiques est une demande très nette de nos clients, explique Eric Quivy, directeur R&D et développement chez VCSTimeless. Nous avons retenu.Net, car, au premier semestre 2003, aucun éditeur Java ne possédait de technologie client riche du niveau de celle de Microsoft »

D'Altio à xWidgets, la communauté Java compte plus de quinze technologies différentes de client riche. En attendant qu'un standard Java se dégage, certains éditeurs développent leur propre client riche Java. Ils s'appuient, pour cela, sur le Java Runtime Environment (JRE) de Sun et sur un framework propriétaire, comme le fait l'éditeur d'outils de gestion Lefebvre Software. « Seul Java répondait à l'hétérogénéité de notre base installée iSeries et à nos 46 % de nouveaux clients sous Unix et Windows », commente Philippe Périer, directeur technique de la société.

D'autres adoptent les technologies Java open source Eclipse Rich Client Platform (RCP) ou Workplace Client Technology Rich Edition (WCTRE) d'IBM (basé sur Eclipse RCP). Et cela même si elles s'éloignent des standards définis par Sun. « IBM [à l'origine d'Eclipse ­ NDLR] a compris que si la plate-forme Eclipse était choisie par une large communauté d'utilisateurs, l'adoption du framework graphique SWT d'Eclipse et, plus généralement, de RCP s'en trouverait facilitée », analyse Sami Jaber, architecte chez Valtech. Les entreprises suivent aussi ce raisonnement. « Plusieurs de nos clients développent des applications basées sur Eclipse RCP », confirme Didier Girard, directeur technique d'Improve. IBM, lui, a déjà rallié des poids lourds comme Adobe ou Siebel.

Au final, « la cohabitation de deux ou trois technologies distinctes est inévitable », estime Frédéric Bon, fondateur du cabinet de conseil Clever Age. A côté des socles d'exécution d'Eclipse, d'IBM et de Microsoft, « XUL de Mozilla pourrait bien conquérir quelques parts de marché », prédit Laura Ramos. Il suffit, en effet, de posséder le navigateur Mozilla pour déployer des applications en un clic là où les technologies Java et Microsoft requièrent le déploiement préalable d'un socle d'exécution de plusieurs mégaoctets.