De l’intérêt d’un Portail d’Entreprise

Dans tout projet d’intégration d’entreprise visant à agréger des services provenant de différents silos applicatifs, le serveur d’application centralisé semble être une évidence, et l’on parle alors de Portail d’Entreprise.

On écoutera patiemment les arguments des éditeurs de telles solutions ainsi que ceux des DSI qui vantent les qualités du portail d’entreprise comme point d’entrée centralisé (maîtrisé, personnalisable, sécurisé, etc.) pour l’ensemble d’un porte-feuille applicatif.

Allons donc !

  • Un point d’accès centralisé ? Pas besoin, j’ai des bookmarks dans n’importe quel navigateur qui me permettent d’accéder aux applications (web ou « webisées ») avec lesquelles je travaille.
  • Plusieurs écrans d’application en même temps ? A quoi bon puisque de toute manière je peux ouvrir une nouvelle fenêtre de navigateur ou un nouvel onglet pour avoir plusieurs interfaces d’applications.
  • Un seul point d’authentification ? Un Active Directory ou n’importe quel LDAP fait cela tout aussi bien.
  • Le portail offre des vues personnalisées ? Mais qui se sert de çà et qui en a besoin ?
  • Une intégration applicative de haut niveau dans une seule page ? Mais qui *travaille* dans un portail ! Une simple page web personnalisée avec des widgets me donnera un bon petit tableau de bord personnalisé pour gérer mon activité, avant de basculer sur de pleines pages si nécessaire.

Un grand portail d’infrastructure d’entreprise n’a aujourd’hui plus aucun intérêt (s’il en a jamais eu) si les services applicatifs qu’il centralise sont des services web  : la mise en place de flux RSS et ATOM, plus quelques widgets ont beaucoup plus de valeur que ces projets de centralisation de l’accès à l’information et aux applications.

Ici avec le portail, mais comme avec l’ensemble des démarches d’intégration (SOA, MDM, ESB), il faut se poser la question : mais pourquoi vouloir tout centraliser ? Dans les démarches d’architecture des SI en entreprise, trop souvent le choix de centraliser l’architecture est un axiome, donc un a priori, rarement la conséquence d’un choix raisonné, d’une conception.

Je comprend que les grand éditeurs poussent l’idée de centralisation car plus le Système d’information devient centralisé, plus le pactole à ramasser est important (« bingo ! Untel a pris mon ESB, tout son SI repose sur mon produit »). Mais pour les DSI, et derrière eux les utilisateurs du SI, cela n’a aucun sens.

Lorsque je m’occupais des intranets de Saint-Gobain, j’ai été confronté à ceux qui vouaient au projet de portail central une admiration sans borne. Leur thèse était, grosso modo, : « mieux vaut un portail central qu’une multitude d’applications » (j’étais le gars en charge des applications). J’ai essayé de leur expliquer qu’ils se fourvoyaient mais j’ai eu l’impression de me heurter à un portail (fermé).
Bref, 100% d’accord avec ton point de vue sur la question !

[Reply]

Ton captcha se moque de moi ! La chaîne de caractère à saisir pour mon commentaire sur l’inutilité du portail centralisateur était… 1BEA (to rule them all ?). 🙂

[Reply]

Tout est vrai sauf qu’un portail bien fait, c’est à dire construit pour l’utilisateur, apporte les avantages suivants :
-tout poste de travail est banalisé. Il devient « mon » poste de travail après login. Rien sur le poste, l’état de chaque utilisateur+espace de stockage est sauvegardé sur le portail.
-Pour une nouvelle application, je peux « pousser » une page/onglet standard à personnaliser à tous les utilisateurs.
-toutes les données utilisateur restent sous le contrôle de l’entreprise et ne sont pas distribuées sur les postes de travail.
-on peut faire un search global..
-on peut afficher la supervision des systèmes, des alertes, etc..

Bref, non aux portails des éditeurs, oui à celui de l’entreprise..

[Reply]

Hum…il y a du beau monde par ici 🙂
@Sig : sur ce sujet comme sur beaucoup d’autres, je reste toujours impressionné par la pertinence de tes billets de blogs qui datent de plusieurs années et qui n’ont pas pris une seule ride !

@Jean-Paul : c’est une vision intéressante où l’OS devient le Navigateur, c’est clairement la vision de google que tu veux instancier derrière les firewalls ?

[Reply]

Tout à fait d’accord, tant avec Christian qu’avec Jean-Paul 🙂

Quand j’étais encore en SSII, pour des projets de portails intranet qui avaient une forte logique de gestion de contenus, on arrivait à supprimer le portail de l’architecture cible en montrant au client que son besoin était d’avoir un CMS pour la partie gestion de contenus et que le CMS en question pouvait permettre d’avoir des logiques de blocs permettant d’intégrer les qqs widgets ou bien encore que l’on pouvait facilement « animer » la page d’accueil de l’intranet.

Du coup, exit le portail à condition que l’implémentation du CMS et de sa logique d’animation soit bien pensée en amont.

Le besoin aujourd’hui est plus de pouvoir se créer sa page d’accueil (à la Netvibes, iGoogle, etc – parce que bon, sa liste d’applications disséminées, faut bien la mettre quelque part…) dans laquelle on peut mettre toute une série d’info et services différents (favoris, RSS, Widgets, etc) que d’avoir un portail qui ne fait que conplexifier l’architecture et donc l’intérêt est minime.

C’est d’ailleurs une de mes occupations du moment à titre perso, afin ne plus dépendre du poste & navigateur que j’utilise…

[Reply]

google.com me suffit comme portail + bookmark del.icio.us d’entreprise (firefox permet en plus de créer un menu dans firefox bas » sur un fil atom comme ceux de del.icio.us + ouverture automatique des sites d’un répertoire dans des onglets). Un vrai portail a lui tout seul ce firefox.

le moteur de recherche est indépendant du portail, google.com existe en dehors de igoogle…

[Reply]

Great post, funnily enough many corporates are still aiming for the portal…just calling it knowledge management (101)

[Reply]

En plein dans le sujet de l’entreprise où je travaille. Le portail nouveau est arrivé, ses futurs aléas aussi.
Evidement tous ces arguments sont intéressants : centralisation, simplification, indépendance de l’outil et de son support.
Et de me poser la question de l’ETRE HUMAIN dans tout ça… on dépersonnalise le poste de travail, dématérialise les applications… alors que 90% des DSI que je côtoie aime LEUR iPhxxx, LEUR iPoxx, LEUR matériel et LEURS petites choses qu’ils prêtent rarement… j’ai vu des gens désinfecter des claviers avant de les utiliser, d’autre coller des petits coeurs de la St-Valentin sur le coin de leur écran… et ça, ça rentre comment justement dans ces portails d’entreprise super-standardisés ?
J’ai pas de réponse et que des questions, merci beaucoup en tout cas de ces billets qui me font bien réfléchir et… si on faisait des applications pour l’homme, faites par l’homme 😉 ?

[Reply]

Je vois que je ne suis pas le seul à ne pas aimer les portails (en tout cas, autant que certains vendeurs souhaiteraient qu’on les aime).

J’ai par écrit – dans les commentaires de http://www.touilleur-express.fr/2009/10/10/seminaire-sur-les-portails-open-source-chez-ippon-technologies/ – que « choisir un portail ressemble un peu à choisir de construire sa maison en bois uniquement parce que… la porte d’entrée est en bois. De fait, seule la page d’accueil d’un portail contient des portlets [éléments] customisables, pourquoi vouloir utiliser la technologie portlet pour toute une appli web sachant que seule la page d’accueil doit être customisable ? C’est pour le moins étonnant, non ? »

En fait, de portail, quand on y regarde bien, il est essentiellement question d’une page d’accueil intégrant plusieurs flux, une page éventuellement customisable. Une page d’accueil et pas grand chose de plus; et c’est cela que l’on appelle portail. C’est d’ailleurs en cela que l’on a vu émerger des technos pour construire des pages « à la portail », i.e. des technos pour construire des pages d’intégration, sans s’embarrasser de la techno dite de portail.

Je crois que toutes les évolutions de la techno portail, tous ses avatars ces dernières années, cela vient du fait que les portails sont souvent définies au niveau API, et au niveau framework, alors qu’ils sont aussi définis (en premier lieu ?) au niveau architecture (niveau auquel appartient REST par ex). Les vendeurs souhaitent vendre des portails en liant les clients au niveau API et/ou framework, par rapport à une implémentation particulière, alors que les clients devraient plutôt s’attacher à respecter un design portail, sans forcément se limiter rigidement à telle ou telle techno, pour l’implémentation; bref, c’est le jeu – continuel – de l’esprit et de la lettre.

Ainsi, le terme portail est, pour le moins, source de confusion: http://www.jroller.com/dmdevito/entry/the_term_portal_is_at

Le fait qu’un portail soit défini (en premier lieu ?) au niveau architecture, le pb de certaines implémentations, la montée d’autres technos, a entrainé l’apparition de technologies/implémentations alternatives, comme les suivantes:
– Snowl: voir http://www.jroller.com/dmdevito/entry/snowl_a_portal_concurrent_solution
– OSGi: voir http://www.jroller.com/dmdevito/entry/portlets_in_the_light_of
– GWT: voir http://www.jroller.com/dmdevito/entry/portlet_life_looks_like_ejb et http://www.jroller.com/dmdevito/entry/the_portlet_gwt_comparison_is

Comme, pour ma part, je ne souhaite pas choisir la porte d’entrée de ma maison et ensuite, construire ma maison, en accord, tout autour de cette porte d’entrée, comme je suis plutôt dans la démarche opposée, ces nouvelles options – dérivées de la vision portail comme principe d’architecture – ces nouvelles options m’intéressent fortement, car elles apportent un bol d’air nouveau.

[Reply]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.