Les avantages et inconvénients du client riche

1. Un peu d’histoire

1.1 Les mainframes

Dans les années 80, dans l’informatique de gestion l’ensemble des applications était localisé sur un mainframe. Chaque utilisateur avait alors accès à des écrans de saisie calculés par le mainframe et affiché à l’utilisateur à travers un terminal passif. Celui-ci ne couvre que l’interaction minimale avec l’utilisateur (affichage de l’écran et récupération des instructions clavier et souris). De nombreuses applications dans le monde de la banque et de l’assurance mais également dans d’autres secteurs sont toujours maintenues sur ces mainframes (dans le monde on estime que 60% des applications bancaires sont développées en COBOL).

1.2 Le client lourd

A l’époque du client serveur, les plateformes de programmation implémentant le principe du client lourd ont été très rapidement adoptées par les entreprises. Ainsi le C++, le VB et plus tard le C# ou bien côté JavaLangage de développement très populaire ! le Swing ont permis de développer facilement grâce aux studios de développement intégrés (IDEEnvironnement de développement permettant de faciliter le développement d'applications. : Integrated Development Environment) et à leur éditeur graphique intégré des applications offrant de nombreux avantages :

• Ergonomie : étant exécutée sur le poste client le développeur a accès à l’ensemble des fonctionnalités de l’OS ainsi que toutes les ressources et évènements matériels.
• Performance : pour le C++ par exemple, l’application étant compilée pour génération d’un code assembleur adapté à l’architecture processeur (x86 par exemple) les instructions sont optimisées. Ceci n’est plus vrai sur les technologies client lourd actuelles comme le Java Swing ou le C# en client lourd où le principe de machine virtuelle a fait son apparition.
• Répartition : en mode client serveur, le code d’affichage côté IHM et de gestion de l’interaction utilisateur est exécuté au niveau du poste client ce qui offre l’avantage de solliciter les ressources serveurs uniquement pour la restitution des données et/ou traitements centralisés.
• Interconnecté : ayant accès aux ressources matérielles les solutions de type client lourd permettent le pilotage et/ou la réception d’informations de périphériques matériels connectés au poste client. Ces périphériques peuvent être des produits grands publics comme une douchette à code barre ou bien un scanner mais également des périphériques conçu sur mesure comme une chaîne de production, un réseau ferroviaire ou bien un ensemble pyrotechnique. Ces besoins sont d’ailleurs toujours couverts par des solutions de type client lourd avec si besoin des systèmes d’exploitation temps réel (on parle alors selon les cas d’informatique industrielle et non d’informatique de gestion).
• Connectivité : même lorsqu’elle est implémentée en architecture client / serveur, une solution de type client lourd peut facilement disposer d’un mécanisme de base temporaire permettant de fonctionné en mode déconnecter. A l’inverse, ce mode de fonctionnement est très difficile à mettre en œuvre sur une architecture client léger.

Malgré ces nombreux avantages les solutions client lourd ont perdues progressivement de leur intérêt au yeux des décideurs informatiques dès le début des années 2000 en raison de quelques inconvénients complexifiant la phase de maintenance :

• Déploiement et montée de version : étant installée sur chacun des postes clients, le déploiement d’une solution de type client lourd est un projet en soi qui peut devenir très complexe lorsque l’on fait face à un parc informatique hétérogène. Par la suite, à chaque montée de version il est nécessaire de ré-déployer la nouvelle version sur chacun des postes.
• Compatibilité : étant compilé pour une architecture processeur et faisant appel à des fonctionnalités au niveau OS, une solution de type client lourd offre une compatibilité restreinte à une configuration matérielle et un système d’exploitation donné. Cette problématique a été résolu notamment avec Java et C# par la mise en place de la notion de machine virtuelle. Le code Java par exemple n’est pas compilé en assembleur mais dans un code intermédiaire (bytecode) compréhensible par la machine virtuelle Java installée sur le poste et qui va alors faire la traduction en code assembleur : ce principe permet la compatibilité du code à tout système d’exploitation et processeur permettant l’installation d’une machine virtuelle Java. Cependant ce nouveau mode de fonctionne limite les performances des applications compilée en bytecode de part la mise en place d’une couche intermédiaire, de plus il devient très difficile de dialoguer avec des périphériques extérieurs car la machine virtuelle Java n’a qu’un nombre très limité d’interactions possible avec l’OS et ses périphériques.

1.3 Le client léger

Ainsi pour faciliter le déploiement et la maintenance des applications de gestion, la majorité des entreprises se sont tournée vers les architectures client léger. Un client léger est une application dont les écrans sont calculés côté serveur puis transmis au poste client à travers un navigateur Web. Ce mode de fonctionnement permet de résoudre les inconvénients vus précédement sur les clients lourds. En effet, le passage par un navigateur Web évite la phase de déploiement de l’application sur l’ensemble des postes clients. Ainsi lors des montées de version seul l’applicatif côté serveur a besoin d’être mise à jour. Quant à la compatibilité, une application en client léger est compatible avec tous les OS et processeurs permettant l’exécution d’un navigateur Web supportant l’application.

Ces nouvelles architectures applicatives (PHPLangage de programmation s’exécutant côté serveur et permettant la création dynamique de pages web ou d'APIs., Java J2E et Microsoft ASP et ASP .NET) ont également des inconvénients majeurs :

• Adhérence au navigateur Web : bien qu’étant basé sur des standards comme l’HTML, le CSS ou bien le JavaScript le code envoyé au navigateur Web peut entrainer des différences de fonctionnement selon le navigateur (IE, Chrome, Mozilla…). Il est alors nécessaire pour les développeurs de s’assurer de la compatibilité de leur application avec les versions majeures des navigateurs disponibles sur le marché.
• Limites ergonomiques : pour des raisons de sécurité, les technologies Web n’ont qu’un accès très limité aux ressources système du poste de travail.
• Performances : le serveur se chargeant de calculer l’ensemble des pages pour tous les utilisateurs, les performances de l’application peuvent être très dégradé lorsqu’un nombre important d’utilisateurs sont connectés. Nous recommandons pour ces architectures des tests de performances systématiques.

C’est ainsi qu’est né le besoin d’une solution alliant les avantages du client lourd avec ceux du client léger.

2. Les solutions de type client riche

2.1 Les avantages des solutions de type client riche

Les Frameworks de développement implémentant le principe du client riche ou RIA (Rich Internet ApplicationC'est un programme conçu pour effectuer une ou plusieurs tâches. Réaliser des applications, c'est notre cœur de métier chez AXOPEN !) offrent les avantages ergonomiques des solutions client lourd avec les avantages de déploiement des solutions client léger. Nous pouvons citer principalement Adobe Flex et Microsoft Silverlight. En effet, l’ensemble du code d’affichage est exécuté sur le poste client avec une expérience utilisateur proche du client lourd, ceci est rendu possible par l’utilisation d’une machine virtuelle embarqué dans le navigateur Web. Ces technologies ne font donc pas appel aux technologies classiques du Web (HTMLHTML (HyperText Markup Language) est un langage permettant de décrire le découpage d'une page web., JavaScriptLangage de scripting orienté objet et CSSFeuilles de style qui permettent de mettre en forme des pages web.). L’application peut ainsi être déployée à travers le Web à l’instar des clients léger. De plus le fait d’exécuter la couche « Présentation » du modèle 3 tiers sur les postes client permet une grande distribution de l’application et ainsi limiter la consommation de ressources au niveau du serveur d’applications mais aussi la limitation des flux réseaux aux données métiers (pour beaucoup de technologies client léger les échanges avec le serveur contiennent l’ensemble du code HTML d’affichage de la page).

Ainsi nous pouvons résumer les avantages du client riche :

• Ergonomie : plus grande expérience utilisateur permise par l’utilisation d’une machine virtuelle et de composants graphique (VS HTML).
• Performance : distributivité et limitation du flux réseau.
• Déploiement : déploiement à travers le navigateur Web.
• Compatibilité : l’application n’est plus adhérente à une plateforme ou à une version de navigateur mais plutôt à une version de la machine virtuelle (Flash par exemple pour Flex).

2.2 Les limites de ces technologies

Après ce tableau idyllique, on se demande alors pourquoi un si faible taux d’adoption du client riche est constaté dans les entreprises.

Pour ma part, je l’explique par plusieurs raisons concomitantes :

• Les Frameworks Web ont fait de grands progrès dans leur offre de composants. Par exemple, avec le Framework Java J2E JSF, de nombreuses librairies de composants sont disponibles. Ces librairies offrent une expérience utilisateur de plus en plus proche du client lourd.
• Les technologies client riche disponibles sur le marché rompent avec les canons de développement des technologies client lourd ou client léger. Ceci est dû principalement au caractère graphique de ces technologies. Ainsi il n’est pas évident pour un développeur Web ou client lourd de développer en client riche.
• Enfin ces solutions étant propriétaires, elles sont plus facilement délaissée par les entreprises au profil des solutions Open Source foisonnantes dans le monde du client léger.

Nous pouvons également rappeler les inconvénients principaux des solutions client riche :

• Indépendance : ces solutions étant propriétaires la maintenance et les évolutions des machines virtuelles correspondantes dépendent des Road Map des éditeurs concernées. Il est possible par exemple, qu’un jour Microsoft décide d’abandonner la plateforme Silverlight.
• Licences : ces solutions étant propriétaires il est nécessaire d’acquérir des licences à minima pour le studio de développement.
• Langages de développement : ces solutions ayant été pensée sur la base de solution graphique (le Flash pour Flex) les langages de développement varient beaucoup des langages pour client lourd ou léger.