Un wiki avec un accès en écriture limité fonctionnerait bien. Limité dans le sens où seules quelques personnes à travers l'organisation / l'entreprise pourraient mettre à jour la page principale du portail, puis chaque équipe ou sous-organisation pourrait avoir des personnes qui maintiennent leur section du site. Cela encouragerait la collaboration et impliquerait plus de personnes, de sorte qu'elles pourraient réellement se soucier de ce qui se trouve sur la page principale interne de l'entreprise, plutôt que de prendre ce qu'elles ont et s'en plaindre.
J'ai travaillé pour une organisation de gestion de systèmes de taille moyenne chez IBM, et nous avons utilisé un portail basé sur un Wiki pour accéder à la documentation de l'équipe et mettre en place les meilleures pratiques. Il a été mis en place il y a quatre ans lorsque j'y étais et, d'après un ami qui y est toujours, il est toujours utilisé et apprécié au sein de cette organisation. D'autres équipes avec lesquelles nous avons travaillé ont adopté des solutions similaires pour leur propre usage.
Nous avons déployé le site d'origine sur un Sun E450 avec 2 CPUs et environ 1G de mémoire. Le site lui-même fonctionnait avec tikiwiki, qui est un package wiki de gestion de contenu basé sur php. De nos jours, je regarderais vers un package wiki qui est aussi un système de gestion de tickets, afin que les utilisateurs puissent ouvrir un ticket directement pour résoudre les problèmes avec le portail. Redmine ou Trac sont d'excellents outils pour cela.
Je devrais ajouter que le site qui tournait sur un E450 hébergeait également un wiki pour une autre organisation, et au total servait du contenu pour un total d'environ 300 utilisateurs, répartis à travers les États-Unis. Le type de matériel nécessaire dépendra bien sûr de la taille de l'organisation et du volume de trafic.
