Par Eric Choppe (Magic Software) : Développer et déployer en RIA et SaaS sans peser sur les coûts

Client léger, Ajax, Silverlight... Pour formaliser son choix, le point sur les avantages et contraintes des modèles d'application cliente de nouvelle génération.

La plupart des analystes pensent que, dans les quelques années à venir, 60% des projets de développement porteront sur des applications RIA (Rich Client Applications). Plus nous avançons, plus nos applications métier deviennent complexes et chères à déployer, maintenir et faire évoluer. L'essentiel, pour les fournisseurs est de conserver leur avance technologique et concurrentielle.

Client passif, client lourd, client léger, client juste : la spirale de l'évolution
Lorsqu'on parle de l'évolution des technologies de l'information, de ces allers-retours qui jalonnent le temps et les nouvelles demandes des consommateurs, l'image d'une spirale s'impose, une spirale jalonnée par les grandes étapes de l'évolution technologique : mainframe, terminaux passifs et traitement centralisé, PCs, mise en réseaux, clients lourds et traitement déporté sur le poste de travail, Internet, clients léger et retour au traitement centralisé sur le serveur. La boucle est bouclée. Nous sommes revenus à une topologie née il y a une quarantaine d'années. Mais infiniment plus performante et riche en fonctions. La différence est de taille.

Le client léger n'est cependant pas exempt de contraintes et donc de limites. Ce sont ces limites qui conduisent aujourd'hui l'industrie vers un nouveau mode de développement, RIA et le "client juste", qui conjugue le meilleur des deux mondes : la richesse bureautique du client lourd et les coûts opérationnels bien plus faibles du client léger. Il s'agit d'applications métier totalement interactives (comme le client bureautique), installées dans un lieu unique (le serveur) et accédées via Internet.

Ces applications ont des avantages nombreux et extrêmement attractives, par l'augmentation de leur potentiel d'usage - clients fixes et mobiles, par leur interactivité et leur richesse fonctionnelle, leur architecture centralisée plus facile et économique à déployer et maintenir, leur architecture multi-niveaux, garantes de sécurité et de "scalabilité".

Adopter les solutions RIA et SaaS sans alourdir les coûts d'infrastructure
La complexité et la richesse fonctionnelle croissantes des applications ont favorisé l'émergence d'un nouveau métier : opérateur de logiciels. A l'heure actuelle, les applications sont beaucoup plus traitées par un opérateur qu'elles sont produites, voire consommées. Ces applications s'appuient sur deux types d'infrastructure : ASP avec les clients Web, le cloud computing et un modèle économique par abonnement, et le SaaS, avec des applications RIA (client juste), et un modèle économique par multi-locations et abonnement.

Le choix doit être fait en termes de coûts, d'adaptation à la problématique, de scalabilité et de flexibilité, de cycle de vie, de niveaux de contrôle, et d'un SLA qui garantit que la mise à disposition de l'application correspond à la demande des utilisateurs. Pour résumer, les applications en local sont très personnalisables, mais très chères. Les applications SaaS sont beaucoup plus économiques, mais leur personnalisation pointue est difficile à réaliser.

L'entreprise aujourd'hui : un mix d'applications
La spirale de l'évolution ne doit pas nous faire perdre de vue que l'industrie n'évolue pas à coup de révolutions, car les entreprises et leurs utilisateurs finaux utilisent encore, et pour longtemps encore, tous les modes de déploiement, en local ou externalisé, mainframe, client/serveur ou Web. Comment alors peut-on rendre ce portefeuille hétérogène moins complexe à gérer pour l'ensemble des fournisseurs, opérateurs ou utilisateurs ?

Ces allers-retours entre à la demande et en local poussent les entreprises à réaliser un "mix" d'applications hétérogènes, pour servir des populations différentes dont les besoins se recouvrent parfois. Elles doivent aussi posséder l'éventail des performances nécessaires pour les servir toutes. Combien d'entreprises peuvent-elles s'offrir autant de compétences aussi différentes, pour garantir le fonctionnement optimal de toutes leurs applications ?

Problèmes d'usage
Il existe actuellement quatre possibilités principales de développement RIA :
- Les clients terminaux, de type Citrix,
- Le RIA s'appuyant sur un navigateur, de type Ajax,
- Le RIA sans navigateur,
- Les plates-formes d'applications fondées sur des métadonnées.

Les clients de type Citrix installent une application complète distante. Leurs capacités d'évolution étant limitées, l'infrastructure applicative est chère, et les applications n'ont aucune conscience du poste client sur lequel elles fonctionnent. Il faut alors faire face à de nombreux problèmes relatifs à l'usage des écrans RIA et des fonctions du poste local.

A l'étage au-dessus, les RIA de type HTML dynamique et Ajax sont des tentatives d'insertion d'éléments dynamiques dans la page Web, y compris les rafraichissements partiels de la page et autres interactions particulières au niveau des champs. Il faut pourtant se souvenir que le navigateur n'a pas été conçu pour ce niveau d'usage, et qu'il n'est pas l'environnement idéal pour les opérations 'Rich'.

Les applications de type Ajax posent de nombreux problèmes aux "power users", ceux qui utilisent des applications comme par exemple SAP ou Salesforce.com, qui contiennent des écrans affichant simultanément des dizaines de champs de données différents. L'implémentation d'Ajax rend ces écrans très lourds et lents, et le développement devient difficile. Lorsque les besoins d'usage augmentent, il devient plus raisonnable de quitter les clients navigateurs pour se diriger vers ce que l'on appelle le Client "Juste".

Ce client "juste" a été inventé pour tenter de contourner les limitations de l'environnement navigateur, en implémentant un client Internet hors du cadre de ce navigateur. Les clients sans navigateur, dont Microsoft Silverlight et Adobe Air, suivent le principe du client "juste". Ils ne sont pas orienté page et, dans cette optique, ils se comportent à la manière d'une station de travail. Ils sont légers, ne travaillent pas de manière indépendante et sont plutôt une extension des capacités du serveur, en apportant un meilleur partitionnement entre ce dernier et le client. Donc, seule la juste quantité des capacités de calcul passent du serveur vers le client, pour activer des fonctions complexes d'interaction tout en maintenant les opérations de back-end (qui ne sont pas interactives) sur ce serveur.

Mais les "rich" clients utilisant un navigateur, et les clients "justes" sans navigateur suivent les uns comme les autres les mêmes principes et exigent de manière implicite la planification et la programmation  de serveurs et de clients distincts, ce qui, comme nous allons le voir, n'est pas sans poser un certain nombre de questions complexes.

Un développement jalonné d'obstacles
Les applications RIA représentent aujourd'hui un des processus de développement les plus complexes jamais rencontrés. En premier, le développement du client utilise une technologie différente de celui du serveur. Ce client, ensuite, consommera sur le serveur des services développés en C# ou en Java. Ensuite, la couche de communication entre client et serveur a ses propres particularités.

 Donc, un effort normal de développement exige la constitution et la maintenance de plusieurs équipes qui travaillent sur les différents aspects de l'application. Ce qui fait courir des risques sur la conception, la planification et la gestion d'un projet plus complexe donc plus cher. Comme pour tout système, plus il y a d'éléments mouvants, plus on rencontre des chances de panne.

Un client RIA ajoute une autre difficulté : vous devez programmer de manière explicite les réponses au sein de l'application, puisque ce client est désormais une entité fonctionnant de manière indépendante et qui doit être gérée à un niveau champ par champ.Aussi, lorsqu'elles se lancent dans le développement et le déploiement d'une solution RIA ou SaaS, les entreprises doivent d'abord acheter puis intégrer plusieurs plateformes, avec plusieurs paradigmes serveur et client.

Le temps du choix
Il existe, à propos de ce qui précède, un consensus croissant parmi les analystes de l'industrie, stipulant que les plates-formes technologiques traditionnelles, comme par exemple les serveurs d'applications standard, suffisent pour une utilisation simple de RIA et SaaS, mais que des offres plus complexes et vastes s'appuieront sur une technologie SEAP (SaaS Enabled Application Platform) spécialisée ou élargie.

Tribune réalisée par Eric Choppe de Magic Software.