Débat: Faut-il tourner définitivement la page du client-serveur ?

La Tribune de Franck Gonzales, directeur technique d'Owendo, intitulée "Pourquoi le client-serveur n'a pas dit son dernier mot" a suscité des réactions. JDNet Solutions ouvre le débat avec une première contribution signée de Marc Muller, pdg de Dreamsoft, SSII spécialisée entre autres dans les problématiques d'intégration.

Là où Franck Gonzales proposait d'examiner les mérites du client-serveur en fonction des applications visées, Marc Muller appelle pour sa part à tourner la page. Voici son point de vue, résumé sous forme de questions-réponses. N'hésitez pas à nous écrire pour nous transmettre vos éventuels commentaires.

Le client-serveur aura-t-il participé à l'évolution des nouvelles technologies ?
L'architecture client-serveur fut une évolution majeure de l'informatique et pour deux raisons :
1. une interface graphique plus conviviale permettant à l'utilisateur un apprentissage plus aisé des applications qui lui sont fournies
2. une amélioration considérable de la productivité des développeurs liés aux outils de développement proposés qui ont permis d'offrir une plus grande réactivité aux entreprises dans la mise en service de ses nouvelles applications. Ce qui demandait des mois, voire des années de développement en Cobol pouvait être mis en service en quelques mois, et de plus avec une interface graphique plus conviviale et donc plus intuitive pour l'utilisateur.

Qu'en reste-t-il aujourd'hui ?
Peu d'acteurs sont encore présents, tous les nouveaux outils de développements sont apparus, à travers des sociétés américaines (fin des années 80 ou début 90) comme Gupta (SQLWindows), Powersoft (PowerBuilder), Microsoft (Visual Basic), Borland (Delphi), pour ne citer que les plus connu et un français Nat System (NSDK). Aujourd'hui Delphi doit posséder encore plus de 2 millions d'utilisateurs dans le monde. Et il est vrai qu'il reste encore un parc installé important d'applications client-serveur en fonctionnement qui remplissent leurs devoirs. Mais elles sont en attente d'une réécriture future...

Pourquoi ces applications client-serveur sont-elles en voie de disparition ?
Ces produits ont rencontré plusieurs obstacles dans leurs évolutions : ils n'était pas multi-plateforme (peu ou pas de versions Unix), le développement du client lourd (le poste utilisateur) a conduit à une course effrénée vers la puissance du poste client (Intel peut dire merci aux applications client-serveur), et les réseaux ont connu une grosse croissance de leur trafic, liée à des accès peu optimisés aux bases de données. Enfin, n'oublions pas le problème le plus rédhibitoire pour les grands comptes, à savoir la difficile mise à jour des postes clients sur lesquels étaient installées toutes ces applications.

Les outils client-serveur n'ont-ils pas évolué ?
Bien avant l'arrivé du navigateur Web sur le poste client, sont apparus des produits dits de "deuxième génération" dont les traitements n'étaient plus positionnés sur le client mais centralisés sur un serveur intermédiaire tel que l'ont peu le voir aujourd'hui avec des serveurs d'applications comme WebLogic de Bea ou WebSphere d'IBM. Le fer de lance de la deuxième génération avait pour nom l'éditeur Forte dont l'offre est aujourd'hui maintenue par Sun. Ces produits ont comblé une partie des lacunes de la première génération, notamment multi-plateforme, architecture distribuée, programmation objet.

Que manquait-il encore à ces logiciels de deuxième génération ?
En fait, même les produits de seconde génération n'ont pas eu le succès auquel ont pouvait s'attendre, en grande partie à cause d'une complexité de mise en œuvre très structurante (notation UML, programmation objet, architecture distribuée). Or les clients étaient habitués à une mise en œuvre rapide d'applications, (d'où l'arrivé de méthodes de type RAD), et c'est ce qu'ils ont retrouvé dans les développements adossés aux technologies Intranet. Des développements qui, eux, répondaient à leurs exigences: moins de contraintes, une plus grande rapidité de mise en œuvre, une centralisation des traitements et un client... enfin léger.

N'avez-vous pas l'impression toutefois que les projets fondées sur des technologies de l'ère Internet comme les EJB ont dû mal à s'épanouir ?
Effectivement, tous les éditeurs ont misé sur les serveurs d'applications Java et surtout sur les composants EJB (Enterprise Java Beans), mais l'ont voit encore que les entreprises ont préféré le développement de Servlets ou de JSP (Java Server Pages) bien plus faciles à mettre en œuvre.