Articles A Lire

Les logiciels de Wikis tentent de percer en entreprises Par Laurent Dupin ZDNet France Lundi 24 avril 2006

Stratégie - Les projets se multiplient pour faciliter la mise en place de Wikis dans l’environnement professionnel. Tour d’horizon des outils de gestion et de partage des connaissances dans cette seconde partie de notre introduction aux Wikis "pros".

Le Wiki est un support collaboratif de plus en plus utilisé en entreprise car il propose une communication plus posée et plus constructive que les e-mails et les messageries instantanées. Mais il n'est pas aisé d'accès: CraoWiki, communauté sur l'usage de ces plates-formes, le confie sur son site: «Le monde du Wiki n'est pas toujours facile à appréhender.»

Cela n'empêche pas les projets de voir le jour en environnement professionnel comme Splunk, dont nous parlions dernièrement. Il exsite même désormais une catégorie à part entière: les «CorporateWikis», qui redonnent corps à la famille des outils de knowledge management (partage des connaissances).

De grands acteurs s'y sont lancés tôt, à l'instar de Microsoft avec son FlexWiki. Et des petits nouveaux les rejoignent: la société américaine JotSpot - cofondée par l'ancien président d'Excite, Joe Kraus - a ainsi bâti un logiciel qui vise petites et moyennes entreprises. Il comprend des fonctionnalités pour professionnels, comme la recherche sur des pièces attachées. JotSpot entend convaincre les entreprises par des versions hébergées et préparamétrées de sa solution, dans l'année qui vient.

Les deux premières versions sont Class Reunion (outil de gestion de réunion) et Bug Reporter (outil de gestion des rapports de bugs informatiques), qui se rapproche de Splunk. On a là visuellement des «boîtes», plus simples à appréhender que des informations éparpillées entre forums, blogs, tutoriaux, etc.

Des projets européens

Ces logiciels hébergés peuvent bien sûr contenir du texte, comme tous les Wikis. Mais ils intègrent aussi des codes et templates réutilisables, ce qui permet à des développeurs de créer par-dessus des applications personnalisées ou de simples extensions. «La plupart des gens nous perçoivent comme une simple application wiki hébergée. Mais nous sommes une plate-forme pour construire des applications collaboratives», indique Joe Kraus. «Le Wiki est un peu le hub idéal pour les applications hébergées.»

D'autres acteurs se positionnent. Tel Twiki qui affiche comme entreprises utilisatrices Michelin Chine (depuis... 2001), ou l'éditeur de progiciel SAP. On compte aussi Pbwiki, qui se définit ainsi: «Fabriquer un Wiki gratuit, et protégé par mot de passe aussi simplement qu'un sandwich au beurre de cacahuètes».

En France, CaféWiki promeut le même type d'outils. Mais les sociétés ne sont pas encore légion. Habitudes et peurs de l'inconnu amènent les employés, s'ils ne sont pas guidés, à passer par les outils et méthodes bien assimilés: simples dossiers partagés sur le réseau interne, intranet, portail RH, etc. Les éditeurs vont donc devoir évangéliser et (dé)montrer l'intérêt de leurs solutions pour faire en sorte que les projets Wikis ne soient pas portés dans les entreprises que par quelques rares et zélés convertis, regardés un peu bizarrement...

Avec Martin LaMonica, pour CNET News.com.

Source : http://www.zdnet.fr/entreprise/managementrh/collaboratif/0,50007183,39341858,00.htm

----------------

Communautés de pratique: mettre les connaissances en action Par Jérôme Delacroix ZDNet France Jeudi 31 mars 2005 Capter et faire circuler l’information sont des facteurs clés de compétitivité. Mais comment tirer le meilleur parti du capital de connaissances de l’entreprise ? C’est tout l’enjeu des communautés de pratique.

Les entreprises, quelle que soit leur taille, ont pris l'habitude de travailler en réseaux : réseau de communication, réseau de partenaires externes, réseau relationnels des salariés...

Dès lors, pour faire face à un problème, la question n'est plus tellement « que faire ? » mais plutôt « qui a la solution ? ».

Une réponse à cette problématique peut être la communauté de pratique (CoP), théorisée notamment par les travaux d'Etienne Wenger. Celui-ci la définit comme «un groupe qui interagit, apprend ensemble, construit des relations et à travers cela développe un sentiment d'appartenance et de mutuel engagement ». Ces attitudes coopératives peuvent préexister, et il convient alors de les optimiser, ou elles peuvent n'être qu'en puissance, et c'est alors aux managers de les développer.

Les enjeux managériaux

Un programme de développement de CoP nécessite la mise en place d'un groupe de travail qui aura trois missions principales, par degré de difficulté croissant.

Identifier les communautés informelles et les canaux de communication existants

Il est en effet important de s'appuyer sur eux. Des questionnaires, interviews et enquêtes sur le terrain permettront de les découvrir.

Les observer pour détecter de nouvelles opportunités

La phase d'observation permet de comprendre quelles sont les informations échangées et de déceler des mines, peut-être ignorées, de savoir-faire et d'expériences.

Les mobiliser au service des objectifs de l'entreprise

On ne peut parler de CoP, par opposition à un simple groupe informel, que si le réseau humain constitué applique tous ses efforts à un projet au service de l'entreprise.

Il peut arriver également que les communautés n'existent pas encore, par exemple dans le cas d'une fusion entre sociétés. Il va falloir alors créer les synergies et apprendre aux salariés à travailler ensemble, en tenant compte des différentes cultures.

Pour Joël Frigière, University Manager chez Arcelor, «le vrai challenge, c'est de créer la culture du partage. Or dans l'entreprise, chacun partage s'il comprend que c'est son intérêt. D'où l'importance d'ancrer le partage d'informations dans l'intérêt individuel du salarié, en l'évaluant et le récompensant en ce qu'il contribue à la performance collective. »

Source : http://www.zdnet.fr/entreprise/managementrh/collaboratif/0,50007183,39213037,00.htm

-----------------------

Portail d'entreprise: la démarche de choix Par Frederic Bon Clever Age Mercredi 1 septembre 2004

Le choix d’une solution portail est rendu complexe par la multitude des offres disponibles sur le marché. Un travail sur l’expression des besoins permet néanmoins de restreindre fortement la liste des prétendants. La notion de portail est suremployée aujourd'hui. Tant et si bien qu'elle ne qualifie plus rien de précis. Remarquez que notre secteur est coutumier du fait : prenez le terme middleware, il englobe des « logiciels du milieu » aussi différents que SQL*Net (accès à Oracle), MQSeries (communications inter-applicatives par message), Tuxedo (moniteur transactionnel), SOAP (appel de Web Services à distance), etc. Pour le terme portail, c'est pareil. Afin d'éviter toute confusion, nous avons donc choisi de prendre une définition très fonctionnelle : un portail devient une porte d'accès Internet public et/ou privée à un agrégat de contenus et d'applications.

Une fois cette définition prise, il est possible de « descendre d'un cran ». On commence alors à pouvoir faire le lien entre le besoin et la technique. Rapidement, on constate que derrière le besoin portail se cachent trois briques techniques : La gestion de contenu : nécessaire dans quasiment tous les projets Les outils collaboratifs : de plus en plus demandés Le portail d'intégration : envisagé pour des projets avancés Etant donné que chacune de ces briques nécessite de mettre en œuvre des solutions techniques complètement différentes, on comprend mieux l'importance de définir ses besoins suivant ces axes. Il faut également conserver à l'esprit que si le besoin couvre au minimum 2 briques, il faudra s'assurer de la bonne intégration des 2 solutions techniques retenues. Essayons maintenant de décrire la couverture fonctionnelle de ces briques.

Couverture Fonctionnelle de la brique « gestion de contenu » Les outils de gestion de contenu Web reposent sur une séparation entre contenu et présentation. L'interface Back-Office (accessible uniquement aux contributeurs) permet de créer/modifier un contenu. Ce contenu est saisi sans aucune mise en forme. Ensuite, on décide de restituer ce contenu sous différents formats : version imprimable du contenu, affichage dans un bloc de page Web, version RSS (format permettant l'échange de contenus entre partenaires), etc. Les avantages par rapport à une gestion statique des contenus sont multiples : diffusion d'un même contenu sur plusieurs canaux (page d'accueil Web, version imprimable, newsletter, ...), facilité de modification de la charte graphique, possibilité de contrôler le cycle de vie du contenu (date de mise en ligne, date d'archivage, ...), autonomie des contributeurs (la création d'un nouveau contenu ne nécessite aucune intervention technique), etc. La brique gestion de contenu est à nos yeux indispensable à tout projet portail.

Couverture Fonctionnelle de la brique « outils collaboratifs » Cette brique rassemble à fois des fonctionnalités issues du groupware (forums, agenda partagé, gestion documentaire, ...) mais également des fonctionnalités purement Web (chat, co-browsing, site Web personnel, site Web de groupe de travail, ...). La délégation de l'administration est un des points clés de ces outils. On veut en effet pouvoir laisser une grande autonomie aux équipes pour personnaliser leurs espaces de travail. Cette brique est souhaitable lorsque l'on veut améliorer les outils de travail en équipe. Sa mise en œuvre doit néanmoins être accompagnée par une conduite du changement soignée.

Couverture Fonctionnelle de la brique « portail d'intégration » Le principe des portails d'intégration est de proposer une solution englobant l'ensemble des applications de l'entreprise. La partie « visible » gère la communication avec les utilisateurs et leur permet de personnaliser leurs pages. La partie interne est constituée de connecteurs vers de multiples sources de données et applications. Ces connecteurs offrent la possibilité aux utilisateurs d'avoir accès aux fonctions des applications du système d'information aux travers de « portlets ». Un moteur de recherche est disponible pour effectuer des recherches via le réseau (sites intranet, répertoires réseau, ...). Ceci permet d'atteindre des données réparties sans avoir à les déplacer. La brique de gestion de contenu et la brique outils collaboratifs sont vues comme des applications intégrables par le portail d'intégration. La mise en œuvre de cette brique devient envisageable et bénéfique dès lors que le projet est bien avancé. Lorsque ce besoin apparaît trop tôt dans le projet, il est

souvent la conséquence d'une « sur-spécification » liée à la « peur de manquer », plutôt que le résultat d'une analyse pragmatique du besoin.

Organiser sa démarche de choix

Une des clés assurant un choix adapté est donc d'organiser son analyse des besoins sur ces trois axes. Il est également important de se projeter à moyen terme. En effet, un choix court terme de gestionnaire de contenu peut s'avérer bloquant dans la perspective de mise en place d'un portail d'intégration. Enfin, il est important de faire ce choix de manière transverse. Ces outils ont vocation à être généralisés à de nombreux projets (site Web, site partenaires, intranet, ...). Lier vos choix à un seul projet est souvent préjudiciable. Ces choix doivent également être faits en prenant en compte votre environnement technique, les compétences de vos équipes, votre sensibilité aux différents modèles économiques (éditeurs, logiciels libres, ...), etc. Ces choix doivent être les vôtres et non celui de vos intégrateurs. N'oubliez pas que « les intégrateurs passent et que les produits restent ».

---------------

Dix critères pour choisir son système de gestion de contenu Par Stéphane Bordage - leprojetweb.com Jeudi 27 mai 2004 La capacité des entreprises à communiquer sur le web dépend en partie de leur système de gestion de contenus. Les critères de choix doivent être correctement pondérés en fonction de la nature de chaque projet. On distingue généralement deux grandes catégories de projets web. D'une part les projets tactiques qui consistent à mettre en oeuvre, rapidement et à moindre coût, des sites répondant à des besoins précis et relativement standard: intranet de projet, site institutionnel ou événementiel, etc. D'autre part les projets dits "d'infrastructure", visant à construire un socle technique commun à l'ensemble des projets de gestion de contenu de l'entreprise. Les premiers sont ciblés par une multitude de progiciels clés en mains qui possèdent tous une philosophie propre et une couverture fonctionnelle très variable. Dans le cas des nombreux CMS open source, leur coût est réduit et leur mise en oeuvre souvent accessible aux non informaticiens. Les seconds requièrent en revanche des compétences techniques pointues pour développer des solutions sur mesure à partir de frameworks techniques spécialisés. Quelle que soit la typologie du projet, au moins dix critères doivent être pris en compte pour ne pas se tromper dans le choix du système de gestion de contenu (CMS pour Content Management System). Au premier rang desquels la couverture fonctionnelle, la simplicité d'utilisation et la capacité d'intégration au système d'information de l'entreprise. Ces critères devront bien sûr être pondérés en fonction de la nature de chaque projet. Une expression du besoin très précise et une grande objectivité sont donc incontournables à ce stade.

1. Personnalisation éditoriale et fonctionnelle du frontoffice

La personnalisation du front-office consiste à créer la structure éditoriale et ajouter des modules fonctionnels spécifiques (sondages, annuaires, etc.). Ce critère ne doit pas être négligé, certaines offres étant très limitées. Ainsi, l'entreprise qui souhaite offrir une marge de manoeuvre à chaque entité (direction régionale, fonctionnelle, etc.) tout en conservant la maîtrise du graphisme et des fonctionnalités, appréciera les solutions modulaires comme Typo3 ou eZ publish.

Au contraire, les organisations souhaitant mettre en oeuvre rapidement une solution simple se tourneront plus volontiers vers des outils comme Spip ou Mambo Open Source. Pour valider ce critère, il suffit de comparer la liste des besoins exprimés avec les fonctionnalités proposées par les solutions étudiées.

2. Personnalisation graphique du front-office

L'architecture des templates graphiques est un point sensible car elle détermine une part importante des coûts de maintenance et d'évolution. Si ce critère est prépondérant, les solutions comme SPIP - qui s'appuient sur des langages propriétaires et de vieux standards techniques - sont à éviter, au profit d'offres comme XULit! basées sur les standards actuels (XHTML + CSS2).

http://www.zdnet.fr/entreprise/managementrh/collaboratif/0,50007183,39169572,00.htm

A COMPLETER

Comprendre les solutions de gestion de contenus en entreprise Par Xavier Fournier-Morel* Techmetrix.net - Mercredi 15 janvier 2003

Derrière le terme de "gestion de contenu", on trouve une grande variété de fonctionnalités et de domaines applicatifs, qui sont définis dans le concept de Enterprise Content Management (ECM). Explications.

Introduction

Dans le contexte très actif de la réalisation et des mises à jour quasi exponentielles des sites Web (Intranet, Extranet, Internet), les outils de gestion de contenus Content Management System (CMS)-, font partie des solutions incontournables pour de nombreuses entreprises. Derrière le terme de "gestion de contenu", on trouve une grande variété de fonctionnalités et de domaines applicatifs, qui sont définis dans le concept de Enterprise Content Management (ECM).

Figure 1: Le déploiement exponentiel du contenu !

Définition d'un outil de CMS

Pour simplifier, on distingue dans un outil de CMS deux volets : le "back-office" et le "front-office".

Le "back-office" Une arrière boutique (le "back-office") permettant la gestion homogène et centralisée de l'ensemble des types de contenus d'informations d'une entreprise. Par "gestion" il faut entendre toute le cycle de vie d'une information : Depuis la création ou la capture du contenu, son stockage et maintien en versions, sa structuration et son classement, jusqu'à sa publication et son déploiement sur un ou plusieurs sites. Par "contenus" on retiendra ici aussi bien des fichiers (ex : documents, images etc.), des données structurées ou semi-structurées (ex : articles éditoriaux, catalogues etc.), que des informations à caractère multi-media (ex : présentations vidéo, sons etc.). Suivant les solutions, un référentiel de stockage (typiquement un file-system et/ou un SGBDR) pourra venir compléter le back-office ainsi qu'une palette d'outil d'édition et d'administration.

Le "front-office" Via un site frontal ou un portail (le "front-office"), ces contenus d'informations pourront ensuite être présentés, adaptés par utilisateur et contrôlés suivant qu'il s'agit d'employés, de clients ou de partenaires. On voit donc que tout l'enjeu d'une solution CMS se situe ici dans l'implémentation de mécanismes réalisant la glue entre 2 mondes : la masse d'information de l'entreprise d'une part, et la diversité des canaux de diffusion qui devront véhiculer cette information. Par ailleurs, les problématiques de globalisation (internationalisation, localisation et régionalisation) et de la vraie séparation du fond d'une information en regard de sa mise en forme seront aussi au coeur de la pérennité d'un système CMS déployé à l'échelle de toute l'entreprise.

Figure 2: Le cycle de vie des contenus (Cliquez ici pour agrandir l'image)

Portail d'entreprise: 7 étapes pour réussir son projet Par Stéphane Bordage leprojetweb.com Mardi 7 septembre 2004 La création d’un portail d’entreprise est l’occasion de redéfinir les prises de parole, refondre certains processus et formaliser des profils de collaborateurs. Autant de défis qui nécessitent une démarche rigoureuse et objective. Qu'il s'agisse de Pechiney qui rationalise sa base de 36.000 fournisseurs (1), de Weilin + Göös qui optimise son processus de commande pour sa force de vente nomade (2), ou de Dell qui réalise plus de 90% de ses achats de composants en ligne (3), les objectifs d'un portail d'entreprise sont toujours identiques. Participer à une plus grande rentabilité de l'entreprise, en facilitant le travail et diffusant la bonne information au bon moment. Derrière ces objectifs simples se cachent des projets complexes qui remettent souvent en cause le travail engagé depuis plusieurs années, par des dizaines voire des centaines de collaborateurs. Autant dire que l'enjeu technologique, s'il est important (il faut que l'outil fonctionne et soit pérenne), n'est que rarement décisif. Pour réussir, le chef de projet doit non seulement piloter sa mission avec objectivité et rigueur, mais aussi fédérer par son charisme et la qualité de son écoute. Pragmatique, il enchaîne les étapes en fonction de ses besoins sans jamais perdre de vue que le facteur clef de succès est l'adhésion.

1. Réaliser un état des lieux objectif La première étape consiste à prendre la mesure de la situation en étudiant les sites existants. Ce travail d'archéologue aboutit souvent à reconstituer les empilements d'applications, comme autant de strates géologiques accumulées au fil du temps! À ce stade, sous-évaluer la charge de travail est le principal danger. «Pour rentrer dans le budget, les entreprises rognent trop souvent la charge allouée à l'étude de l'existant, au profit de la conception ou du développement jugés plus séduisants», résume Frank Gonzales, P-DG du cabinet d'architecture technique Osaxis. C'est l'occasion de répertorier les contenus et les fonctionnalités existantes, et de mesurer la charge de travail dépensée dans la mise à jour. La liste des outils jugés obsolètes ou indispensables permet aussi d'interpréter plus justement les attentes qui seront exposées lors de l'expression des besoins. Sur la base de ce travail, le chef de projet s'attache à valider l'opportunité du projet.

2. Valider l'opportunité Avant de se lancer dans un projet long, coûteux et risqué, il est indispensable d'en valider l'opportunité. Il "suffit" pour cela de répondre à des questions simples comme: Qu'est-ce qui ne va pas aujourd'hui? Quel est le manque à gagner? Quelles économies potentielles pourraient être réalisées? Combien de temps doit être économisé, à l'avenir, pour telle ou telle action? Et de fixer des objectifs: réduire de 25% la charge de mise à jour, augmenter de 2 minutes le temps utile de connexion, multiplier par deux le nombre d'articles lus, multiplier par 10 le nombre de modèles téléchargés, Cette étude - pas plus d'une quinzaine de jours de travail - doit suffire pour identifier la nature du problème (productivité, communication interne, accès à l'informatique, etc.) et amener la maîtrise d'ouvrage à positionner le projet. Ce faisant, elle réalise un premier choix important, favorisant soit un support à dominante "communication", soit un outil de travail à dominante fonctionnelle (accès aux applications, information métier, etc.). De ce premier choix fondamental découlent tous les autres, y compris celui consistant à étudier telle ou telle solution technique. Le chef de projet ne peut pas s'arrêter là. Il doit impérativement convaincre la direction en la faisant adhérer à sa vision. Sources: (1) Accenture, Outlook magazine volume XV-1, juin 2003 (2) Accenture, Outlook magazine volume XIII-2, juin - septembre 2001 (3) Accenture, 2e trimestre 2002

3. Convaincre la direction Pour aller plus loin, le chef de projet doit faire adhérer les décideurs à sa vision. Cette étape est fondamentale, dans la mesure où seuls les scénarios listés dans la vision ont une chance d'être étudiés lors de l'étude de faisabilité. Autant dire qu'à ce stade, une erreur ou une omission auront des répercussions très importantes. Paradoxalement, le chef de projet ne peut compter que sur son expérience, sur l'analyse d'étude de cas plus ou moins comparables, et parfois quelques chiffres clés (fiables). Autant d'éléments empiriques pas vraiment rassurants pour une direction! D'où l'intérêt de l'étude d'opportunité réalisée en amont: elle crédibilise la vision sans nécessiter un investissement trop important. Parmi les différents aspects à formaliser, l'organisation interne est particulièrement importante: la rationalisation de la prise de parole se traduisant souvent par une

refonte des processus de publication donc par la redéfinition des rôles des contributeurs. Dans le cas d'une refonte des processus, c'est l'organisation de services entiers qui peut être touchée. La direction générale ne s'impliquera que si elle est convaincue de la viabilité du projet sur ce dernier point. Une fois la direction convaincue et le budget alloué, le projet peut réellement débuter. En commençant par fédérer les publics impliqués: utilisateurs finaux, managers, partenaires, etc. Suivent alors l'expression des besoins et l'étude de faisabilité.

4. Fédérer Les utilisateurs n'aiment pas changer leurs habitudes. Encore moins quand il s'agit "d'informatique". La première étape clef du projet consiste donc à les convaincre du bien-fondé de la démarche. Il faut les amener à identifier puis comprendre les dysfonctionnement, pour enfin leur laisser entrevoir les apports de la nouvelle solution. En clair, il s'agit de réaliser une conduite du changement fondée sur le dialogue et la concertation. L'objectif final étant de créer un cadre favorable au projet et à l'appropriation de la nouvelle solution. Mais attention, cette action implique fortement la direction. Car une fois les collaborateurs informés, il est extrêmement périlleux de faire marche arrière et de remettre à plus tard la réalisation de l'intranet ou du portail. C'est pourtant l'un des principaux écueils constatés sur le terrain: le projet ambitieux s'enlise et n'aboutit pas ou se transforme en site sans valeur ajoutée. L'impression laissée sur les utilisateurs est catastrophique: non seulement le projet ne sert à rien, mais il monopolise en plus des ressources qui seraient bien utiles au quotidien! Attention donc à bien mesurer l'engagement réel de la direction. S'il n'est pas total, mieux vaut reporter le projet et entreprendre une action de sensibilisation des décideurs.

5. Créer des profils réalistes La mise en place d'un portail est l'aboutissement d'une démarche stratégique beaucoup plus vaste, qui consiste à clarifier l'organisation et les processus de l'entreprise. Toute l'architecture fonctionnelle et éditoriale du portail repose sur la définition de profils d'utilisateurs, auxquels sont associés des contenus et des applications. La définition de ces profils peut avoir un tel impact sur l'organisation de l'entreprise qu'elle constitue un projet à part entière. Pour réussir, mieux vaut commencer avec un minimum de profils et proposer une personnalisation explicite (le collaborateur peut puiser dans une liste de sources d'informations et d'applications et les ajouter à son profil). Ensuite, en fonction des statistiques d'utilisation et en interrogeant les utilisateurs, il sera possible d'affiner les profils et la segmentation de l'information.

De bons profils reposent sur des besoins communs (contenus et applications) et des habilitations de même niveau. Essayer de coller à l'organisation de l'entreprise est donc inutile même si des similitudes peuvent apparaître: commerciaux, production, cadres stratégiques, etc.

6. Limiter l'expression des besoins au portail Par définition, un portail d'entreprise rassemble toutes les informations et tous les contenus utiles aux différents profils de l'entreprise. Si l'on n'y prend pas garde, l'expression des besoins glisse vite vers celle de chaque application. La tâche est alors gigantesque! Or, l'expression des besoins d'un portail se limite... au périmètre fonctionnel du portail. Cela paraît évident, mais ce n'est pas si simple face aux utilisateurs finaux. Prévoir une dizaines de minutes avant chaque entretien pour rappeler l'objectif de la réunion et situer la mission dans son contexte n'est jamais inutile. Le chef de projet se limite donc à lister: les contenus, les fréquences de mise à jour, les applications, les modes d'accès, la fréquence d'utilisation, le contexte d'utilisation (équipement, temps disponible, etc.). Les fonctions d'une solution de portail d'entreprise les plus demandées Fonction Taux de demande Collaboration 74% Moteur de recherche interne 73% Single Sign On (SSO) 73% Gestion de contenu 72% Taxonomie 63% Services d'annuaire 55% Messagerie instantanée 55% Business Process Management (BPM) 55% Source Delphi Group 2002, échantillon de 500 entreprises

L'exhaustivité et la rigueur de la démarche sont aussi fondamentales que la représentativité des utilisateurs interrogés. Le chef de projet doit en effet réaliser une première hiérarchie des besoins, en fonction de leur fréquence et de l'importance qui leur sont données par chaque utilisateur.

A l'issue de cette étape, le chef de projet est en mesure d'aider la maîtrise d'ouvrage à caractériser définitivement le projet en répondant à des questions telles que: S'agit-il d'un projet d'intranet ou de portail? Quels sont les trois principaux besoins? L'étude de faisabilité peut commencer.

7. Valider la faisabilité en s'appuyant sur un prototype Le chef de projet peut valider 3 points essentiels au travers de l'étude de faisabilité: le réalisme des profils, la faisabilité technique, la faisabilité organisationnelle. Le réalisme des profils est évalué en comparant la répartition des contenus et fonctionnalités entre les différents profils, et en évaluant l'effort demandé par chaque profil par rapport aux enjeux qui lui sont liés. Si le principal objectif du portail est de réduire de 2 jours le temps nécessaire au reporting commercial, mais que le profil qui demande le plus d'efforts est celui des agents de production, on peut supposer que la hiérarchisation des besoins doit être revue. Le portail repose en général sur: - un annuaire LDAP et/ou une solution de SSO (Single Sign-On), - un référentiel d'applications, - un system de gestion de contenu, - des outils de travail collaboratif. Au-delà de la plate-forme technique, tous les aspects cités ci-dessus doivent être validés en gardant à l'esprit la cohérence de l'ensemble. Quand l'annuaire d'entreprise n'existe pas, il devient un projet à part entière qui doit être lancé avant la création du portail: l'expérience montre en effet que plusieurs mois - parfois plusieurs années ! - sont nécessaires pour l'alimenter. Quand le projet est important, il est préférable de réaliser un ou plusieurs prototypes en s'appuyant sur les consultant avant-vente des éditeurs proposant les solutions pressenties, ou sur un prestataire spécialisé, dans le cas des solutions open source. C'est le seul moyen de travailler sérieusement sur les problématiques de reprise de l'existant et de mise en œuvre.

En conclusion La méthode à suivre pour réussir un projet de portail s'apparente à celle utilisée pour un projet informatique classique plus que pour un projet de site internet. Le chef de projet doit en permanence rechercher le consensus entre des objectifs économiques établis par la maîtrise d'ouvrage (MOA) et les besoins des utilisateurs finaux. Impliquer ces derniers en amont du projet est un atout à double tranchant qui peut se retourner contre le projet si les promesses ne sont pas tenues.