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/management-
rh/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/management-
rh/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 front-
office

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/management-
rh/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.