La vocation d’un outil de portail est d’agréger des ressources de différentes sources. C’est-à-dire que le portail permet de construire des pages Web composée de bribes d’informations issues de différentes sources.
Certaines de ces informations relèvent de la gestion de contenus, et effectivement rares sont les portails qui n’intègrent pas un outil de gestion de contenus (CMS). Mais s’il n’était question que de contenus, le portail serait inutile : les outils CMS savent tout à fait composer des pages en agençant des contenus comme on le désire.
Un véritable portail agrège également des informations issues d’applications, qu’elles soient progicielles ou bien applications spécifiques.
| |
|
"Pour une intégration faible' entre portail et applications"
|
| |
Le développement d’une application Web a ses propres exigences : il s’agit en particulier de faire le choix de composants framework, tels que Struts, Hibernate ou encore JavaServer Faces, dans le monde J2EE.
Ces choix sont extrêmement structurants : ils dictent tous les principes de développement et impactent aussi bien la productivité du développement que la pérennité de l’application.
Ce que nous disons ici, c’est que ces choix de framework sont trop importants pour prendre en compte, ou même être influencés par la perspective de l’intégration au portail.
Une application métier d’entreprise a une finalité propre, indépendante du portail. On peut considérer que le portail est le catalogue des ressources de l’entreprise, et l’application est l’un des produits présentés au catalogue.
Imaginerait-on un produit qui ne puisse exister autrement que dans son catalogue ? Le produit n’est pas conçu pour le catalogue, et la conception du produit ne doit se préoccuper que de sa propre vocation : offrir le service auquel il est destiné.
| |
|
"Concevez une application autonome plutôt qu'un portlet"
|
| |
Si l’on ajoute les contraintes du portail dans les principes de conception d’une application, on crée un lien de dépendance inutile du point de vue du service rendu, et néfaste pour ce qui est de l’architecture et de la pérennité.
De manière concrète, cela signifie : ne concevez pas votre application en forme de portlet, même si vous avez l’intention de l’intégrer à un portail. Concevez une application autonome, c’est-à-dire disposant de sa propre interface Web. Et quand elle sera finie, intégrez-là au portail. Bien sûr, on parle ici d'applications d'envergure, de petites applications pourront faire exception à la règle.
La vision de l’utilisateur
Nous avons évoqué jusqu’ici des raisons qui relèvent de l’architecture logicielle. Mais parlons également de l’ergonomie. Le portail permet d’offrir aux utilisateurs des pages agrégées, des pages tableau de bord, personnalisées, réunissant en forme synthétique tout ce que l’utilisateur doit savoir.
C’est la grande valeur ajoutée du portail. Dans un petit module portlet, le directeur commercial a directement un aperçu des chiffres du mois de Mars. "Quoi ?! Les chiffres ne sont pas aussi bons que prévu ? Allons voir cela de plus près..."
Il clique sur le chiffre de mars pour plonger dans une vision plus détaillée. A partir de cet instant, pratiquement au premier clic, il ne veut plus avoir une page agrégée, avec à gauche les actualités société, en haut la météo, et à droite les tâches en attente. Il veut les résultats détaillés du mois de mars.
| |
|
"Deux phases distinctes dans le travail : la phase de synthèse et la phase d'analyse"
|
| |
En somme, il y a deux phases distinctes dans le travail : la phase de synthèse et la phase d’analyse. Dans la première, on veut avoir sous les yeux une diversité d’informations brèves, dans la seconde on veut au contraire se concentrer sur une information ciblée.
Du point de vue de l’intégration portail / applications, cela milite également pour le principe de l’intégration faible : l’utilisateur ne veut pas que l’application s’insère dans sa totalité comme module du portail. Lorsqu’il zoome sur une application, il veut que celle-ci monopolise l’écran, comme elle monopolise son attention.
Bien sûr, une intégration forte ne rend pas cela impossible : une portlet peut tout à fait occuper la page entière. Mais du moins dans cette phase de travail - qui est la plus importante, tant en durée qu’en nombre de transactions - le portail n’a plus la moindre valeur ajoutée. Il est donc stupide qu’il continue de contraindre le mode de développement de l’application.
Notre conclusion
Pour mettre en place un portail d’entreprise, notre préconisation est :
-
de développer les applications sans la contrainte de l’intégration au portail,
- de réaliser des modules portlets qui viennent interroger l’application en Web service afin de collecter quelques bribes d’information de synthèse, le plus souvent personnalisées,
- de mettre en place bien sûr une authentification unique (SSO) entre le portail et les applications de manière à rendre totalement transparent le passage de l’un à l’autre.
|
Patrice Bertrand