Il n'y a pas de meilleure personnalisation, au final, que celle s'adaptant aux désirs et à la façon de travailler de chaque utilisateur. Cette démarche qui permet à tout un chacun de redéfinir l'interface selon ses propres besoins professionnels s'appelle la "customisation". Dans une fenêtre en haut à droite de son écran, un collaborateur peut avoir opté pour une boîte de dialogue lui permettant d'effectuer ses requêtes dans les bases de données auxquelles il a le droit d'accéder. Dans le bureau voisin, son collègue préfèrera que cette zone lui présente des articles très spécialisés issus de banques de données internationales. Un troisième situé au fond du bâtiment se servira du même portail d'entreprise avec le même choix de fonctions, mais aura dédié la zone en question au suivi des étapes du workflow documentaire auquel il collabore au jour le jour.

Jusqu'à l'année dernière, cette vision du portail d'entreprise traduisait davantage un discours marketing qu'une réalité. Dans leur grande majorité, les écrans de travail des utilisateurs étaient statiques, composés en HTML pur sans possibilité de redéfinir quoi que ce soit. Pour accéder à l'application suivante, il fallait ouvrir une nouvelle fenêtre. Et lorsque les interfaces étaient composées dynamiquement à l'aide de langages comme ASP ou PHP à partir d'éléments contenus dans une base de données, elles n'en restaient pas moins définies à l'avance. L'équipe de conception les agençait une fois pour toutes en fonction des désirs exprimés par les maîtrises d'oeuvre, traduits sous forme de règles. Si ces désirs évoluaient, il fallait redévelopper une partie du portail. Ce qui coûtait du temps, donc de l'argent.

Sybase rachète OnePage et son atelier de portlets
Aujourd'hui, et depuis moins de deux ans, la plupart des éditeurs de solutions de portails d'entreprise travaillent sur un nouveau type de composants. Qu'ils portent le nom de iViews pour SAP, de Gadgets pour Plumtree, ou tout simplement de portlets pour une bonne partie de l'industrie logicielle, ces composants répondent précisément au besoin de customisation. Le portail se divise en portillons, traduction littérale du mot - tout comme les appliquettes sont censées franciser les applets. Chaque éditeur a élaboré ses propres librairies de portlets, les plus simples pour accéder à des bases de données typiques, les plus complexes à des progiciels de gestion comme SAP, Baan ou Siebel. Des collections qui, évidemment, peuvent être complétées de connecteurs front-office développés à la demande de l'entreprise pour disposer dans la même fenêtre d'un accès à des applications spécifiques sur ses systèmes centraux.

Dans cette optique, Sybase a procédé la semaine dernière au rachat de l'éditeur OnePage. L'opération complète son offre de portail d'intégration avec un nouvel environnement de développement de ces portillons. "Grâce à cet outil graphique, nous allons permettre aux entreprises de développer leurs propres portlets à la fois plus rapidement et à moindre coût", déclare Mark Wilson, senior director de la division e-commerce chez Sybase, que nous avons pu joindre en Californie. "En général, si l'utilisateur veut dans son interface des informations en provenance de la base de données, quelques jours de développement suffiront. S'il veut accéder à un progiciel de gestion très particulier, l'intégration peut prendre quelques semaines. Avec les outils OnePage, vous pouvez fabriquer des portlets en une heure." Selon Sybase, la prouesse est rendue possible par une extraction automatique des données utilisateurs à partir de sources HTML, XML, bases de données, classes Java, et Web Services.

Il y a un an, Sybase rachetait NEON, un éditeur spécialisé dans l'EAI (intégration inter-applicative) dont la plate-forme de connecteurs est venue compléter son portail d'entreprise. Parmi ces connecteurs, une série de portlets pour accéder dans la même interface à des applications telles que Siebel, Business Objects, et certains outils Microsoft. "SAP est en cours", précise Mark Wilson. Mais les portlets ne sont pas des connecteurs EAI. "Il s'agit d'une intégration totalement différente, puisque nous agrégeons des données et du contenu à partir d'applications en environnement web." En attendant, les deux se complètent, puisque les portlets développées avec Sybase/OnePage pourront chercher de l'information en sortie de la plate-forme EAI Sybase/NEON. L'intégration des offres est prévue pour la prochaine version du portail de l'éditeur qui devrait être commercialisée vers la fin de l'été ou au début de l'automne 2002.

Vers une spécification Portlet inclue dans J2EE ?
Dit ainsi, tout semble encore assez simple. Mais à l'heure actuelle, la démarche est plus compliquée qu'il n'y paraît car les portlets ne répondent encore à aucune spécification standard. De fait, une portlet élaborée par IBM Software pour étendre les sources accessibles à partir de WebSphere Portal Server n'aura a priori aucune raison de fonctionner dans l'environnement de Sybase. Et pourtant, les deux éditeurs s'appuient quasi-intégralement sur des technologies Java, ce qui n'est pas le cas de tous les éditeurs de portails d'entreprises dont certains fournissent des portlets en ActiveX.

En attendant, l'entité logicielle de Big Blue s'est alliée avec Sun Microsystems (communiqué) pour initier une requête de spécification Java (JSR) qui porte le n°168. Celle-ci prend place dans le cadre du JCP, le Java Community Process. L'idée est de permettre l'interopérabilité entre les portillons et les portails. A terme, la spécification Portlet devrait rejoindre le modèle J2EE. A partir de là, JSR 168 a pour but de permettre à n'importe quelle Portlet développée en Java de s'éxécuter dans n'importe quelle architecture distribuée avec un serveur d'application compatible Java 2 Enterprise Edition. Les systèmes d'informations des grandes entreprises étant le plus souvent hétérogènes avec parfois plusieurs solutions de portails selon les pôles d'activité, il apparaît indispensable qu'ils puissent communiquer ensemble.

Selon Thomas Vallot, IT specialist (ingénieur avant-vente) d'IBM Software sur les gammes WebSphere Portal Server et Personalization, "l'intégration à J2EE est en cours de discussion. Apache travaille sur un sous-projet du nom de Jakarta avec lequel l'entreprise peut implémenter un portail d'informations en appui sur des technologies Open Source. Ce sont les premiers à avoir parlé de portlets. Dans ce cadre, IBM a récupéré le code source du sous-projet, l'a enrichi et l'a modifié pour le rendre compatible, puis l'a relivré à la communauté Open Source."

"Une portlet n'est rien d'autre qu'une extension de la servlet", continue Thomas Vallot. "Elle se maintient entre l'utilisateur et la servlet, dont le positionnement est celui d'un aggrégateur de services qui appelle des composants de type portlets. L'intérêt est que vous, utilisateur, n'appelez pas l'application finale. Dix applications apparaîssent dans une même page web, et vous n'avez besoin que d'une unique URL correspondant à la servlet."

Portlets et Web Services : le rôle de WSRP
Et ce n'est pas tout. Compte tenu du fait que l'utilisateur ne doit accéder qu'à ce à quoi il a droit selon sa fonction dans l'entreprise, il faut que la spécification portlet puisse tenir compte d'éléments de sécurité. Oracle, qui déclare près de 800 portlets (Business Objects, Cognos...) dans son offre de portail, participe aussi aux discussions autour de JSR 168. "La sécurité et la customisation sont embarquées et s'appuient sur un annuaire", indique Laurent de Lavarenne, responsable marketing 9iAS d'Oracle France. Confirmation de Thomas Vallot d'IBM Software : "avec l'API for Security, il n'est pas nécessaire de s'authentifier dix fois pour accéder à dix applications différentes. En fournissant un composant de sécurité à la portlet, elle fait confiance à tout le processus d'authentification en amont. L'API est l'interface entre la portlet elle-même et l'aggrégateur. Avec un profil utilisateur, on peut pousser du contenu grâce à de la personnalisation par règles, et le client final peut faire sa customisation."

Or, JSR 168 n'est pas le seul standard prévu concernant les portlets. Ainsi, l'OASIS (Organization for the advancement of structured information standards) qui est derrière plusieurs spécifications de Web Services soutient une norme baptisée WSRP (Web services remote portal). Oracle qui participe à cette norme, comme Sybase, IBM et toute une série d'autres acteurs, apporte une explication. Selon Laurent de Lavarenne, "l'idée est de fournir des technologies de portlets standards pour intégrer facilement des Web Services dans un portail. Le point de jonction est défini à l'aide d'une portlet, de façon à ce que celle-ci puisse mettre en oeuvre un service Web et puisse être installée dans n'importe quelle page. Dans le cadre de l'OASIS qui regroupe beaucoup de monde, les discussions se font autour de Java."

Outre IBM Software, Oracle, Apache, Sybase et Sun, l'on retrouve la quasi-totalité des grands fournisseurs de serveurs d'application J2EE autour de JSR 168. Parmi ceux-ci: SAP, BEA, ATG, HP, Iona et BroadVision, mais aussi des géants comme Fujitsu et Hitachi, les sociétés de services EDS et Accenture, et enfin l'avioneur Boeing. Autour de la norme WSRP en discussion à l'OASIS figurent les mêmes acteurs, entre autres. Dans les deux cas demeure un grand absent : Microsoft. Il faut dire que le dénominateur commun de ces initiatives s'appelle Java, et que la firme de Bill Gates ne semble pas vraiment séduite par l'idée d'un standard qui émergerait hors de son sein.