Osez le client lourd !

Si on établit une liste des avantages des applications utilisant des clients lourds par rapport à celles utilisant des clients web, on en vient à se demander ce qui nous a poussé à généraliser à l’extrême l'utilisation des applications web pour les besoins back office.

Il y a une quinzaine d'années, la plupart des applications back office n'étaient pas des applications web. Ces applications, pour la plupart, ne se présentaient pas sous la forme de sites intranets, elles disposaient certes de serveurs pour centraliser les données (voir même prendre en charge une partie des traitements métiers), mais elles étaient aussi dotées de ce que l'on appelle encore aujourd'hui des clients « lourds ». Entendons-nous bien, les clients « lourds » que j'évoque, n'embarquent pas nécessairement toute la logique métier des applications, ces clients peuvent très bien se contenter de jouer le rôle d'interface homme-machine.
Il se trouve que par la suite on s'est rendu compte, que l'ergonomie des applications web n'étaient pas aussi bonne que celle des applications basées sur des clients lourds, donc on a crée les RIA, l'AJAX etc. Certains se sont rendu compte que contrairement aux applications basées sur des clients lourds, les applications web (celles qui sont basées sur HTML4) n'étaient pas adaptées au fonctionnement hors-ligne (sic!), donc HTML5 a du prendre en charge cette fonctionnalité. Je n'ai pas l'intention d'écrire une diatribe contre les applications web, mais si on établit une liste des avantages des applications utilisant des clients lourds par rapport à celles utilisant des clients web, on en vient à se demander ce qui nous a poussé à généraliser à l’extrême l'utilisation des applications web pour les besoins back office.
À titre personnel, je note que les applications utilisant des clients dits «lourds», possèdent au moins les deux avantages suivants par rapport aux applications web:

Dans une application web il faut maîtriser plusieurs langages pour la partie cliente

Comme HTML, JavaScript (et subséquemment des librairies comme JQuery, Dojo, AngularJS etc.) voire même CSS. Bien souvent, cela implique de rajouter des briques applicatives supplémentaires coté serveur (Struts, ASP.NET MVC, JSF, Tiles etc.). Pour faire communiquer le client web et son serveur, il n'est pas rare de devoir générer du XML (pour faire de l'AJAX), ou du JSON. Et parfois, on va même jusqu'à adopter des styles d'architecture comme REST.
Dans une application utilisant des clients lourds, on utilise bien souvent le même langage que sur la partie serveur (Java, VB.NET, C#, voir même C++) et pour les plus fantaisistes du XML et du CSS.
Pour communiquer avec le serveur, on utilise des protocoles comme RMI, WCF ou SOAP. Et c'est tout !
Sur le papier, on se rend compte qu'il y a beaucoup moins de notions techniques à maîtriser lorsque l'on fait des applications utilisant des clients lourds que lorsque l'on fait des applications web.
Il faut bien comprendre que si une application web nécessite nettement plus de notions techniques qu'une application utilisant des clients lourds pour être développée, cela implique les contraintes suivantes :
  • En ressources humaines. En effet, il faudra former (au sens de créer) une équipe à même de maîtriser l'intégralité de la pile technique de l'application, et plus l'application utilise de notions techniques différentes, plus il sera difficile de trouver (et de conserver) les individus compétents pour former ce collectif.
  • Plus, il y a de notions techniques, plus l'application est complexe. Et plus elle est complexe, plus la montée en compétence est longue, elle peut atteindre des années pour certaines applications. Et tant que la montée en compétence n'est pas finie, la productivité n'est pas optimale et la qualité du travail n'est pas garantie. Si les applications web sont plus complexes, leurs coûts de développement et de maintenance ne sont pas significativement plus bas (c'est un euphémisme...) que ceux des applications utilisant des clients lourds, on peut donc s'interroger sur la nécessité d'une telle complexité...

Dans une application web, le client est bien souvent un navigateur web

Le problème, c'est que les navigateurs web évoluent, et il faut faire évoluer en conséquence les applications web, et ça, c'est très coûteux, parce que cela implique des développements et surtout des longs tests de recette sur la quasi-totalité de l'application. Pour éviter ces dépenses, bon nombre d'entreprises rechignent à mettre à jour leurs navigateurs web, s'exposant ainsi à des failles de sécurité... De surcroît, les navigateurs obsolètes ont bien souvent des performances nettement inférieurs aux navigateurs derniers cris, ce qui impacte la productivité des utilisateurs... Celles et ceux qui ont eu l'occasion d'utiliser des applications web utilisant de l'AJAX sous internet explorer 8 (voir 6...) savent de quoi je parle... Mais le pire, concerne les entreprises utilisant plusieurs applications web ; ces applications utilisent toutes le même navigateur (souvent Internet Explorer) et dans la même version. Si on souhaite faire évoluer significativement une application web, il va bien souvent falloir se passer du navigateur obsolète et passer sur une version plus récente. Supposons qu'on ait assez de budgets pour faire cela sur une seule application, en changeant de version de navigateur, on risque de créer des tas de régressions sur toutes les autres applications web qui avaient étés conçues pour fonctionner avec l'ancienne version du navigateur...
Cela implique donc de faire évoluer toutes les applications web de l'entreprise simultanément, et là, le budget risque fort d'être insuffisant. En dehors même de l'aspect purement financier, cela représente aussi un coût en temps.
La dépendance qu'il y a entre une application web et le navigateur web peut donc être pénalisante.
Dans une application utilisant des clients lourds, on n'est pas dépendant du navigateur. Vous me direz que ces mêmes applications dépendent souvent de plates-formes d'exécution (JVM, CLR etc.), je vous répondrais que ces plates-formes sont bien souvent rétrocompatibles. Et mieux, dans le cas de Java, on peut faire en sorte à ce que chaque application utilise sa propre JVM (machine virtuelle Java) , afin que les évolutions d'une application n'aient aucun impact sur les autres applications installées sur le même ordinateur.

Mais les applications web ont malgré tout, quelques avantages sur les applications utilisant des clients lourds :
  • Lorsque l'on installe une application utilisant des clients lourds, il faut installer la partie serveur, mais aussi installer la partie client sur chaque poste de travail.
  • Dans une application web, il suffit juste d'installer la partie serveur. À noter qu'aujourd'hui, ce n'est pas si compliqué d'installer des applications sur les ordinateurs des utilisateurs. Nombre d'entreprises ont des procédures d'installation automatisées.
  • Lorsque l'on met à jour (en production) une application utilisant des clients lourds, il faut mettre à jour la partie serveur, mais il faut aussi mettre à jour tous les clients.
  • Dans une application web, il suffit juste de mettre à jour la partie serveur. À noter, que là encore, des outils permettent d'automatiser ces mises à jour.
Je ne dis pas qu'il faut arrêter de développer des applications web, il y a probablement des cas où ces applications sont plus pertinentes que celles basées sur des clients lourds, mais c'est quand même dommage de faire exploser les coûts de développements des applications back office juste pour économiser des déploiements qui peuvent êtres automatisés...