Passer au contenu

1. Abandonner le modèle client-serveur : L’intranet, base du système d’information

Initialement synonyme d’IP, de HTTP et de HTML, l’intranet relève désormais de projets d’infrastructures. L’utilisation d’interfaces web par les applications est un préalable.

Les briques essentielles d’un intranet sont identifiées depuis longtemps : applications dotées d’une interface HTML, serveur web, postes de travail équipés de navigateurs, le tout fédéré par un réseau IP véhiculant des flux HTTP. Bien que tous ces ingrédients relèvent de notions ressassées depuis des années, leur disponibilité ou leur maturité n’est pas toujours au rendez-vous. Et surtout, ils ne sont plus suffisants. Car désormais, il ne s’agit pas seulement de faire fonctionner des applications intranet en marge de l’existant, ni même de les accumuler. Le but est de les inscrire dans une infrastructure technique commune, tout en les fédérant par un portail qui personnalise et sécurise les accès.

Les applications métier souvent en marge

La prise en compte du client universel qu’est le navigateur web est le préalable à cette démarche globale. Elle coule de source, dans le cas d’un intranet informationnel consistant à publier des pages HTML statiques ou générées dynamiquement par des programmes ASP ou PHP. Elle est généralement acquise dans le cas d’applications de travail de groupe. Les services émergents comme l’e-procurement (la gestion des achats) s’appuient aussi d’emblée sur les technologies du web.Mais il en va tout autrement pour les applications métier, généralement traitées par des progiciels de gestion intégrés (PGI) ou des progiciels de gestion de la relation client (GRC). En effet, les éditeurs privilégient encore souvent le traditionnel mode client-serveur.En guise d’exemple, SAP, numéro un dans le domaine des PGI, n’a pas achevé sa mutation. Certes, dès 1996, certaines fonctions du module RH (Ressources Humaines) étaient accessibles en intranet. Début 2001, ce mode a été systématisé à tous les modules du PGI, grâce à un serveur intermédiaire réalisant une conversion en HTML. Mais les performances et l’ergonomie étaient décevantes. C’est seulement fin 2001 que fut lancée une plate-forme ciblant nativement les navigateurs ?” le Web Application Server (WAS). “C’est la fin annoncée de SAP GUI, notre interface en mode client-serveur, excepté pour les utilisateurs nomades travaillant en mode déconnecté”, estime Jean-Michel Franco, responsable du marketing solutions chez SAP. Mais seul le module de GRC gère le WAS, tandis que R/3 ne le fera que dans quelques mois.

Les réseaux et les systèmes doivent être à la hauteur

De plus, la migration de la base installée imposera un remaniement des développements spécifiques. La situation est similaire chez Intentia. Pourtant l’éditeur avait su se montrer précurseur en proposant, dès 1996, avec Movex, un PGI entièrement écrit en Java. “Notre base installée est en mode client lourd, le support des navigateurs web n’interviendra que courant 2002”, lâche Philippe Michel, en charge des solutions e-business. Quant à un éditeur de logiciels de gestion comme Sage, qui cible essentiellement les PME, il en reste pratiquement au mode client-serveur. En théorie, toutes les fonctions de son offre sont accessibles à partir d’un navigateur. “Mais c’est au prix d’un gros travail de paramétrage, par le biais d’une boîte à outils”, explique Romain Hugot, directeur du marketing produits chez Sage. Finalement, cet effort n’est réalisé que pour des utilisateurs situés sur des sites isolés. Il reste que la tendance est bien là. Et si elle a mis si longtemps à se dessiner, c’est qu’il est difficile de conférer à une application intranet le même niveau d’ergonomie et de performances que son homologue client-serveur. Alors, lorsque l’éditeur n’est pas prêt, ou dans le cas d’applications spécifiques, la solution peut résider dans l’utilisation, par exemple, de solutions de type Web to Host et en procédant à un réhabillage. Mais il faut alors limiter les ambitions, en terme d’ergonomie.

Centraliser les accès, partager les ressources

Une fois toutes les applications accessibles en mode intranet, l’étape suivante consiste à les fédérer et à en partager les ressources, tant au niveau du front office que du back office. Pour le front office, il s’agit d’authentifier l’utilisateur puis de lui fournir un accès centralisé, sécurisé et personnalisé, à toutes les données et applications. Telle est la vocation des portails d’entreprise, qui peuvent être construits à partir de progiciels ou de boîtes à outils dont l’offre est extrêmement disparate. Les uns ne visent qu’à chapeauter des intranets existants. Les autres réalisent une véritable intégration entre les applications, ce qui implique des échanges de données par les serveurs.Pour le back office, l’aboutissement de la notion d’intranet exige une architecture commune à toutes les applications. Serveurs J2EE et architecture.NET de Microsoft sont alors les deux principaux prétendants. Mais il faut plutôt parler de tendance, car le développement des briques de cette artillerie lourde est loin d’être achevé. De plus, nombre de progiciels conservent encore leur propre infra-structure. Le back office à la mode intranet, c’est aussi la tuyauterie, dont les EAI orientés XML ?” et peut-être demain, les services web ?” représentent la forme la plus complète, permettant aux différentes applications de dialoguer entre elles.Parallèlement, cette migration du front office et du back office a un impact important sur les systèmes et les réseaux. “La disparition du client lourd engendrera un déport des traitements côté serveur, ce qui amènera souvent les entreprises à opter pour des machines plus puissantes”, fait ainsi remarquer Marc Fayard, directeur avant-vente chez Baan.En ce qui concerne les infrastructures réseau, le protocole IP, fondation première de l’intranet, est désormais presque systématiquement adopté. Mais lorsque l’intranet englobe peu à peu toutes les applications, de nouvelles catégories d’utilisateurs sont touchées et par conséquent, le trafic explose. Il faut alors interconnecter la totalité des sites et différencier les flux applicatifs. Les offres de réseau IP basées sur une dorsale relais de trame ont dispensé les entreprises de construire leurs réseaux étendus à coup de liaisons louées, voire de connexions RNIS. Mais, en pratique, leur coût et la lourdeur de leur mise en ?”uvre les ont réservées aux entreprises d’une certaine taille.

Des infrastructures IP privées mais partagées pour les PME

Pour les petites et moyennes entreprises, la véritable réponse n’existe que depuis quelques mois, avec les réseaux privés virtuels IP de Worldcom, Colt, KPNQwest, Cegetel, Equant/Transpac, Easynet ou Siris, bâtis sur des infrastructures IP privées mais partagées. “N’ayant pas souvent déployé de véritables réseaux étendus, les PME se montrent les plus ouvertes à ces nouvelles offres”, constate François Demeyer, directeur du marketing des services réseaux et données chez Cegetel. Ces infrastructures IP privées permettent en effet de connecter facilement de nouveaux sites et de les faire dialoguer entre eux sans passer par le siège de l’entreprise. De plus, elles assurent la gestion des priorités des flux, en distinguant applications critiques, messagerie ou voix sur IP.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Claire Chevrier et Thierry Lévy-Abégnoli