Architecture

Client léger Web : attention aux dérives

Publié le : Auteur: Ronan Bernabé Laisser un commentaire
architecture

Les applications Web, très largement utilisées chez les particuliers mais aussi en interne chez les entreprises, reposent sur l’utilisation de clients légers. Dans ce cas d’utilisation de clients légers Web, il convient de respecter certaines bonnes pratiques, sous réserve de rendre obèse son client. Si les applications mises à disposition des particuliers respectent généralement les bonnes pratiques du Web (sous peine de baisser son niveau concurrentiel), ce n’est pas toujours le cas des applications Web déployées en interne dans les entreprises.

Tour d’horizon de mauvaises pratiques constatées…

Client léger ?

Lourd

Un client lourd est une application s’exécutant partiellement ou totalement sur le poste client et utilisant des ressources logicielles voire matérielles de ce dernier. Un binaire exécutable sur un OS donnée est une application client lourd.

Léger

Un client léger peut être un poste physique intégrant des composantes matérielles et logicielles minimales, ou plus simplement un élément logiciel aux besoins en ressources restreints se déployant sur un poste client. Un client léger s’inscrit dans une architecture client-serveur.

L’utilisation de clients légers vise à réduire les contraintes sur les postes clients : peu voire pas de besoin de puissance machine, peu voire pas de contrainte de maintenance logicielle, possible réduction de l’encombrement sur le bureau, réduction des couts matériels…

La partie matérielle d’un client léger peut être minimaliste si le client a pour seule tache de présenter à l’utilisateur les interfaces graphiques en provenance du serveur. Un vieil ordinateur voire un mini terminal dédié font l’affaire.

La partie logicielle d’un client léger se borne le plus souvent à l’affichage des interfaces graphiques des applications. Les interfaces graphiques peuvent être composées sur le serveurs et envoyées sur le client (déport d’affichage). Le serveur peut aussi composer une description de l’interface et l’envoyer au client qui se charge de reconstituer l’interface graphique à partir de cette description.

Ce dernier type de client léger est assurément le plus répandu de nos jours, jusque dans le foyer de Monsieur Toulmonde. En effet les applications Web reposent sur l’utilisation de clients légers : des ordinateurs sur lesquels s’exécutent des navigateurs Web, des serveurs sur lesquels s’exécutent “des applications fournissant” des sites Web.

Et depuis 10 ans, ces clients légers Web sont largement plébiscités par les entreprises, pas seulement pour exposer des sites sur Internet, mais aussi pour facilement mettre à disposition des salariés les applications.

Riche

Un client riche est un client léger doté d’une composante complémentaire permettant aux applications Web de bénéficier des fonctionnalités, sur les IHM, sur les moyens de communication…

Les plus légers des clients riches s’appuient simplement sur des bibliothèques JavaScript qui apportent de composants évolués, des effets graphiques, des comportements complexes, la soumission partielle (AJAX)… Ces clients riches n’ont donc pas de dépendance au navigateur.

Les autres clients riches s’appuient sur des plugins/extensions du navigateur, une dépendance est donc établie, pour accéder à des ressources du poste de travail, pour proposer des applications bâties sur des technologies autres que Web. Les plus connus des clients riches s’appuient sur Oracle Java (Applet), Adobe Flash ou les ActiveX Microsoft. En plus d’une dépendance à une extension devant être installée sur le poste client, il n’est qu’exceptionnelle que cette extension soit disponible pour tous les OS/plateformes.

Client (léger) Web : une seul loi

Pour correspondre à la définition de client léger, une applications Web doit satisfaire une seule contrainte : proposer une interface Web (HTML, CSS, JavaScript) qui ne tienne aucun compte du poste de travail sur lequel elle s’affiche. Navigateur Web compris.

Si au début du Web les éditeurs de navigateurs Web se faisait concurrence, quitte à délaisser la toute relative “normalisation” du HTML/JS/CSS, poussant à tenir compte du navigateur dans le code applicatif, ce n’est plus vrai de nos jours. Et pourtant, il est encore difficile dans certains contextes d’entreprises de proposer des applications Web qui s’abstraient du poste de travail.

Portage d’applications client lourd

Avec l’avènement d’Internet, les applications Web sont devenues un effet de mode et presque toutes les entreprises voulaient concevoir leurs nouvelles applications ou faire évoluer celles existantes en employant les technologies Web. Amorçant la transition depuis les applications client lourd – serveur (2-tiers), vers les applications client web-léger (3-tiers puis n-tiers).

Surmontant le premier obstacle du temps de chargement des pages, la première rupture avec la technologie Web que les entreprises se sont employées à mettre œuvre fut la disparition de la barre d’adresse et des boutons de navigations (précédent / suivant) du navigateur, des menus. Restreints aux concepts de navigations fonctionnelles misent en place dans les applications client lourd, les concepteurs n’ont que rarement défini une nouvelle navigation prenant en compte ces fonctionnalités. S’employant plutôt à les faire disparaitre tant bien que mal.

Ensuite, nombre d’entreprises se sont heurtées à la simplicité des interfaces graphique que proposent les applications Web. De nouveaux composants complexes ont ainsi vu le jour, moyennant force JavaScript, nombre d’heures de conception et surtout d’incidents et de debug. Depuis des frameworks de composants éprouvés, souvent librement utilisables, sont apparus, minimisant cette “limitation” de la technologie.

Ne faisant que rarement évoluer les habitudes de positionnement absolu des composants dans les interfaces graphiques des clients lourds, ces comportements ont été reportés dans les applications Web internes. Allant jusqu’à reproduire les fenêtre modales, inexistantes en HTML. Illusion d’un environnement maitrisé (écran, bureau, applications), apportant des contraintes supplémentaires lors de l’acquisition d’écrans aux résolutions différentes…

Une application (client léger) Web a aussi des inconvénients qui ne rendent pas toujours éligible cette technologie pour porter des applications client lourd ou réaliser des applications complexes.

Le client léger Web, portail d’entreprise unifié

Seule technologie d’avenir pour les entreprises, l’application Web est devenu portail d’entreprise. Pour cet idéal de portail unifié unique, certains ne se sont pas contenté des technologies portail Web et de leurs limitations. L’agrégation d’applications Web diverses, y compris non maitrisées (progiciels), voire client lourd (si, si…) fut de mise. Des mécanismes de communication inter-applicatif complexes furent mis en place, contournant tant bien que mal l’incapacité d’HTML 4 à permettre au serveur de notifier le client. Des moyens techniques permettant des logiques de navigation inter-applicatives minimisant autant que possible le nombre de clics de l’utilisateur furent conçus.

Quels couts engagés, pour quelle pérennité ?

Un portail basé sur la technologie Web ne sera réellement maintenable et évolutif que si les composantes qu’il agrège et lui même n’outrepassent pas les capacités offertes par la technologie. Dorénavant, l’utilisation de HTML 5 devrait solutionner certains besoins en communication et présentation fréquemment sans solutions simple / viables avec HTML 4.

Progiciels, attention

Les entreprises se “progiciellisent” de plus en plus, recherchant les standards du marché, évitant les développements spécifiques chers à maintenir et faire évoluer.

Les progiciels sont assurément les éléments sur lesquels il faut porter une attention toute particulière. En effet, nombre de progiciels ne sont pas des clients légers mais des clients riches, vous vendra-t-on… Sous-entendez qui nécessitent parfois des extensions au navigateur (Flash, ActiveX, Plugin Java, .Net ou propriétaire…).

La chute peut être vertigineuse. Au mieux, plusieurs navigateurs d’éditeurs différents sont compatibles. Au pire, seules certaines versions du navigateur d’un même éditeur sont admissibles. Entrainant aussi une dépendance à l’OS ! Sachant que dans cette configuration seule une instance du navigateur peut être présente sur l’OS. Que se passe-t-il alors si on souhaite intégrer un autre progiciel imposant une autre version du navigateur ? Ou si on souhaite mettre à niveau l’OS ? Comme client léger, on repassera.

Une dépendance au poste de travail, pire à l’OS, est un élément technique tout aussi important que les capacités fonctionnelles, devant être pris en compte pour un choix d’acquisition et pouvant motiver un refus.

Application mobile à moindre frais

Autre envie qui passe souvent très vite : porter une application sur une cible mobile. Mais à moindre cout, sans refonte de l’application.

Très rapidement, on prend conscience du contraste élevé entre PC (écran, clavier, souris) et périphériques mobiles (écrans tactiles et petits, limitations des capacités de saisie, capteurs matériels…). Il apparait alors qu’une refonte complète de l’application est nécessaire, pour satisfaire un usage très différents, avec une ergonomie adaptée.

La conception d’une application mobile, indépendamment de la technologie mise en œuvre, nécessite toujours une réflexion distincte de celle de la conception d’une application client léger ou lourd. Pour mixer les deux mondes, mobile et « fixe », la mise en œuvre de Responsive Design permettant d’adapter la présentation, les fonctionnalités ou l’ergonomie au périphérique client est indispensable.

Un seul commandement

Le client léger n’est donc pas la solution miracle à la création de toutes applications. Les entreprises, maitrisant leur parc matériel et logiciel, se leurrent souvent en ajoutant des contraintes supposées maitrisées à des applications client léger. Cibler un navigateur particulier est souvent la première erreur. S’ensuit alors une gestions complexe et couteuse de dépendances entre applicatifs, navigateurs voire OS pour maintenir et faire évoluer son parc applicatif.

Le client léger ne répond pas à tous les usages. Le client lourd à encore de beaux jours devant lui pour gérer les applications devant être très réactives, aux IHM complexes ou aux besoins de communications avancés.

Pour les autres types d’applications, le client léger peut être une solution. Mais il convient impérativement de ne pas tordre ou contourner les concepts du Web, même dans un environnement d’exécution totalement maitrisé. Et de respecter l’unique règle : une bonne application Web ne tolère aucune dépendance au poste client.