Informatique Client Léger, Riche ou Lourd?

A qui s'adresse cet article? Aux débutants en programmation ou ceux qui se posent la question de ce qu'est ce charabia à propos des clients léger, lourd ou je ne sais quoi...

L'informatique évolue constamment les pratiques qui en découlent aussi. Hier l'informatique ne passait que par les lignes de commandes, puis sont apparues les première interfaces graphiques qui ont décuplés le potentiel de l'outil  l'informatique. Sont apparuent avec les nouveaux usages de cet outil les notions d'ergonomie et d'esthétique. Des notions sur lesquelles je ne m'attarderai pas. En effet pour ce billet je vais plutôt aborder le coté fonctionnel de l'informatique. Au cours de la conception d'un projet informatique plusieurs notions reviennent fréquemment. Les technologies employées, les langages, et les infrastructures. C'est sur cette dernière notion que je vais m'attarder. 

On peut distinguer 3 types d'infrastructures, les clients dit "Lourds" qui sont des logiciels dont tous les services s'exécutent sur le poste client. Les clients "Riches" qui, eux s'exécutent sur le poste client mais dont une partie du fonctionnement est déporté sur un serveur distant. Et enfin les clients "Légers" qui sont eux entièrement déporté sur le serveur, l'interface n'est pas stockée sur le poste client et le rendu de l'application est généré en fonction des données qu'envoi le serveur.

Voici brièvement les 3 grands types d'infrastructures possibles. Alors, pour mon application, quel type d'infrastructure dois-je adopter? Comme vous avez pu le constater, il n'y a pas d'infrastructure surclassant les autres. Tous est affaire de besoins, et ce sont ces besoins que nous allons étudier en détails.

Le Client Lourd 

Si votre application ne nécessite pas de connexion à un serveur distant, c'est qu'à priori elle se suffit à elle même. Contrairement à un lecteur de flux RSS votre application ne nécessite pas de mise a jour fréquentes. Dans ce cas là le Client Lourd est tout indiqué. Avec le client Lourd vous aurez l'avantage de pouvoir faire une application mieux intégrée à l'OS, à condition de bien choisir son framework. Bien souvent il vous faudra choisir entre portabilité et intégration au système/ performances. Les application natives tirent mieux parti de la puissance de calcul de la machine. Qu'est ce que cela signifie? Si votre application nécessite une puissance de calcul importante, pour lire ou encoder une vidéo par exemple, ou afficher des modèles 3D, vous vous tournerez plutôt vers les librairies de votre OS. Le langage le plus utilisé dans ce cas est le C/C++. Si la puissance vous importe peu, et que la portabilité de votre application est primordiale ce sera dans ce cas peut être vers JAVA que vous vous orienteriez, quoique le couple Qt/C++ soit aussi une solution intéressante.

Autodesk Maya,  developpé en Qt/C++

Si votre application nécessite une connexion à un serveur, pour afficher du contenu en ligne, les données d'un compte bancaire, ou tout autres action qui nécessite que l'information soit centralisé sur des serveurs. Dans ce cas 2 choix s'offrent à vous : Le Client Riche et le Client Léger.

Le Client Riche

Le Client Riche est en fait un client lourd, auquel on à greffé des capacités à se connecter, à chercher de l'information sur un réseau. Cela permet d'une part de rendre l'affichage des informations dynamique, mais aussi, dans certains cas d'alléger le traitement fait sur le poste client. En effet le serveur peut exécuter des traitements à la place du poste client. Dans le traitement des données par exemple, on aura tendance à déporter des calculs sur le serveur et à n'envoyer que le résultat au poste client. Cette infrastructure à l'avantage de repousser l'obsolescence du matériel des postes client, vu qu'on leur demande moins de puissance, tout en conservant un look & feel en accord avec le système d'exploitation de la machine. De plus cela permet toujours de demander au poste client d'exécuter des calculs lourds, comme des rendus 3D, ou des animations. Le client Riche s'impose donc lorsque l'on a un besoin de connectivité et de puissance et que l'on souhaite stocker des données sur le poste client.

Reeder pour mac

Le Client Léger

Enfin le Client Léger quand à lui dispose de l'extreme avantage ( pour le concepteur et le mainteneur ) de ne rien stocker sur le poste client. Concrètement quels avantages cela apporte t'il ? Simplement dans la question des mises à jours de l'application cela est un énorme avantage. En effet la mise a jour se fait de manière totalement transparente, vu que l'interface est téléchargée depuis le serveur à chaque lancement. Le client léger s'impose donc lorsque l'on a la nécessité de mettre à jours fréquemment l'application, tant dans son fond, que dans sa forme. Le désavantage de cette solution est que pour l'instant les composants de l'application ne permettent pas d'obtenir les mêmes rendus que les composants natifs du poste client. Du moins on est limité aux capacité du web ou des frameworks RIA. Le plus souvent, l'application est isolée dans une fenêtre de navigateur, mais certaines solution, comme Adobe Air permettent d'obtenir une application indépendante du navigateur et plus ou moins "maquillée" comme une application native.

De nombreux frameworks existent pour faire du client léger, je ne vous citerai que GWT (Google Web Toolkit, permet de créer des interfaces renduent en HTML en codant en JAVA) et Adobe Flex ( Détournement de la technologie Flash pour faire des interfaces en ligne avec une intégration de la vidéo et des animations que le HTML ne permet pas ). Vu que le client léger n'a pas accès aux données du poste client par mesure de sécurité ( ce que l'on appelle "sandbox" ), il n'est pas possible de stocker directement ou de lire des informations en local. Tous est déporté sur le serveur. Il existe grâce à Air un moyen de porter des applications créées avec les technologies du web sur le poste client. On peut ainsi repousser ces limites du clients léger en stockant en local, mais au final on perd l'intérêt du client léger pour revenir vers du client riche. Enfin il vous reste l'option de passer par la méthode traditionnelle, à savoir le HTML + CSS + Javascript, qui permet elle aussi de créer des applications (certes de moindre importance, car le type de code ne permet pas une bonne maintenance sur les gros projets),  à la manière d'un site web.

Application faite avec Ext-GWT

Pour faire le point voici une infographie très parlante de Camille Roux permettant de faire le point sur les différentes technologies en matière d'interfaces selon l'axe que nous avons abordé.

J'espère qu'au final ce billet aura éclairé vos lanternes. Je pense dans un futur plus ou moins certain me pencher sur la création d'un article ou je détaillerai les différentes technologies pour chacune de ces infrastructures. N'hésitez pas à laisser vos avis si vous pensez que je me suis lamentablement gouré sur un point ^^ Bonne continuation.