Que reste-t-il du client-serveur ?

Le modèle client-serveur était le grand espoir du début des années 90. Grâce à lui, on allait enfin pouvoir combiner les interfaces graphiques des PC avec des processus solides et des bases de données volumineuses des divers serveurs et autres mainframes.

Les espoirs du client-serveur première génération se fracassent sur le “mur du déploiement”…

Mais, après plusieurs années d’essais/erreurs, d’expérimentations sophistiquées et de projets ambitieux, force était de reconnaître que le modèle peinait à tenir toutes ses promesses. Les ambitions du client-serveur se sont douloureusement fracassées sur les écueils suivants : les applications étaient difficiles à développer (à cause des interfaces graphiques et du fait du caractère “distribué” de l’exécution des requêtes et procédures), elles étaient difficiles à déployer (il fallait les installer une par une sur chaque PC de chaque utilisateurs et, quand il y en avait des centaines, l’expression “le mur du déploiement” prenait tout son sens !) et à maintenir (le mur du déploiement s’opposait aussi aux inévitables mises à jour). Et enfin, le trafic réseau important interdisait d’envisager un fonctionnement “à distance” dans de bonnes conditions (comprendre, avec des performances acceptables à l’époque où même l’ADSL n’existait pas encore, même à l’état de concept…).

Le Web rebat les cartes avec une solution utilisable dans toutes les conditions

On pouvait penser que, avec du temps et beaucoup d’efforts, on allait finir par surmonter tous ces problèmes. Mais le modèle client-serveur mis en œuvre avec un client “lourd” (qu’il soit basé sur Windows ou le Mac, ça n’a fait aucune différence) est resté au fond du sac “de la déception et de l’oubli” depuis son échec au milieu des années 90 (définition des différences entre client lourd, client léger et client riche à https://fr.wikipedia.org/wiki/Client-serveur).

Car oui, on a tendance à l’oublier mais le Web est une déclinaison du modèle client-serveur. HTTP est un protocole en tout point conforme au modèle client-serveur. En un sens, grâce au Web (et à HTTP) le client-serveur n’a jamais été aussi vivant et répandu !

Certes, il s’agit là d’une déclinaison minimum (client-serveur de présentation) du modèle mais peu importe, le fait est là, le client-serveur n’a pas disparu, tout au contraire. Mais quand le Web s’est imposé de façon foudroyante à partir des années 1994/95, il était aussi l’illustration incontestable que la simplicité est la reine de toutes les vertus en matière informatique.

Le Web première génération s’est donc imposé, d’abord pour des pages statiques d’information sur l’Internet et, dans un second temps (mais très vite aussi) sur les intranets. Bien entendu, on ne s’est pas contenté de mettre en place juste des sites statiques, utiles mais limités. Progressivement, le Web s’est avéré être également une plateforme adéquate pour des traitements transactionnels via le Web client-serveur (c’est moi qui l’ai appelé ainsi à cette époque), à la fois simple et robuste, gommant en une seule fois toutes les limites qui avait fait échouer le client-serveur basé sur le client lourd.

Le client léger triomphait et son potentiel paraissait sans limite.

Sun et Oracle tentent un coup d’état

Évidemment, ce triomphe radieux de la simplicité heureuse (!) ne pouvait pas plaire à tout le monde, en particulier à ceux qui voyaient dans l’irruption de l’Internet une possibilité de déloger Microsoft de son sommet. Java est apparu en 1995 au sein de Sun Microsystems et fut aussitôt mis en avant par Sun (beaucoup) et Oracle (un peu) comme LA solution qui allait permettre de profiter pleinement du Web ET de se débarrasser de Microsoft par la même occasion… Les deux promesses se sont avérées être nettement exagérées (voire complètement fausses !), le Web a prospéré sans Java et Microsoft est toujours là (hélas ?).

C’est que la solution de type “client lourd renouvelé” proposé par Sun avait de nombreux défauts et, disons-le, ne fonctionnait pas, tout simplement. Je pourrais expliquer le pourquoi du comment en long et en large mais je l’ai déjà fait amplement dans mes livres parus à l’époque (voir Intranet, client-serveur universel et Web client-serveur, le triomphe du client léger… Ces livres ne sont plus guère disponibles et c’est pourquoi j’ai tout regroupé dans Du client-Serveur au Web qui lui est disponible !).

Bref, la tentative de “putsch” via Java (sans oublier le désastreux CORBA !) s’est terminé par un échec retentissant et mérité (même si certains -peu nombreux désormais- ne veulent toujours pas l’admettre). Dans l’informatique, il y en a toujours pour croire que “plus c’est compliqué et mieux c’est” alors que la réalité du terrain nous prouve tous les jours que ce sont les solutions relativement “rustiques” qui s’en sortent le mieux.

Le client léger devient client riche avec Ajax 

Si l’idée d’un client lourd éventuellement débarrassé de ses tares revenait régulièrement, c’est bien qu’il manquait tout de même quelque chose au client léger : la possibilité d’avoir une interface un peu plus interactive. Le recours à JavaScript (rien à voir avec Java et heureusement !) était un pas dans cette direction mais, bien sûr, on voulait plus et mieux…

Et nous avons fini par l’avoir !

Ce miracle porte un nom et c’est Ajax (Ajax est l’acronyme d’asynchronous JavaScript and XML : JavaScript et XML asynchrones).

C’est Ajax qui a vraiment changé la donne technique du Web et a permis de passer d’un client léger mais limité à un client riche à qui plus rien ne manque. Ajax étend le dialogue client serveur continu au niveau d’une page au lieu de nécessiter le chargement d’une nouvelle page pour chaque échange.

C’est Gmail (en 2004) qui a popularisé ce fonctionnement : grâce à Ajax, Gmail n’était pas qu’un Webmail de plus mais une véritable application Web riche et interactive qui n’avait rien à envier à une application native Mac ou Windows.

Après Gmail, Ajax s’est répandu largement et plus aucune application Web d’envergure ne peut s’en passer. Le client riche est désormais une réalité et son domaine d’application ne cesse de s’étendre. Le ChromeBook de Google (encore un vieux rêve qui a pu trouver sa forme finale) a pu voir le jour et prendre sa place sur le marché grâce à la richesse apportée par Ajax et ce n’est pas fini. 

Un client-serveur dont on ne parle plus car il est omniprésent

Le client-serveur a donc fini par triompher, complètement au point d’être omniprésent. Lorsque je travaillais à sa promotion en publiant le premier livre en français sur le sujet (Architecture client-serveur en 1993), je n’imaginais évidemment pas que cela se passerait ainsi. Le chemin a été long et difficile (c’est toujours ainsi quand une nouvelle technique tente de trouver sa place) mais le résultat dépasse de beaucoup mes espoirs les plus fous que j’osais formuler à cette époque. Le fait qu’on en parle plus de nos jours est le signe le plus sûr de son triomphe total : l’omniprésence se paye par l’invisibilité.