Reprise du message précédent :
Peut-être que BookStack permet de faire du multi-entreprise.
Comme cela on peut gérer l'interne et les clients depuis la même console.

 
Pour moi, BookStack est uniquement valable pour de la doc interne, mais je peux me tromper. Déjà, sur un plan purement graphique, il n'est pas très customisable, même si bien sûr, du fait qu'il est open-source, absolument tout est possible.
Ceci-dit, il existe un role "public" dedans qui permet à des personnes de voir les docs de l'extérieur, mais disons que je trouve BookStack vraiment parfait pour de la doc interne.
Le plus gros point fort est aussi sa faiblesse :
 
Il y a très peu de niveaux hiérarchiques :
 
Shelves (sur lesquels tu mets des books) -> pour le département par exemple
Book (qui contient des chapters et/ou des pages) -> pour le sujet global
Chapter (qui contient des pages) -> pour la catégorie
Page -> l'info
 
Et la page peut aussi donc se passer de chapter et être directement présente dans un "Book".
 
Et c'est tout. Et c'est totalement volontaire et assumé : ils assument que les gens pour participer ont besoin d'une structure simplissible pour savoir à la fois où chercher et surtout où contribuer.
Et dans ma boite, c'est exactement ce dont j'ai besoin : simplicité maximum.
La recherche est également très bien faite et le "search field" est placé en haut, au centre : c'est le premier truc que tu vois en entrant.  
Ce truc est vraiment fait pour les mous du bulbe, pour les gens qui n'ont absolument pas envie de réfléchir. On sent que c'est conçu pour les idiots du village à qui il faut normalement tout expliquer. En un mot, c'est parfait.  

Non, le stockage et la mise à disposition sont dans le même outil (c'est l'outil de GED). C'est la mise à la connaissance des gens qui va être faite dans l'outil de la gestion de la connaissance.
 
Imaginons une entreprise qui fabrique un produit et que sa GED est découpée par service (i.e. découpage = un répertoire par service, ces répertoires étant organisés en arborescence). Les documents produits par chaque service seront stockés dans la GED (on se fiche des destinataires).
Donc, pour ton produit, tu vas avoir les documents de R&D dans le répertoire relatif au service de la R&D, les docs du service de la conception dans le répertoire relatif au service de la conception... et ainsi de suite pour tout le cycle de vie du produit.
Du coup, pour voir tous les docs du produits, ça va être chiant car répartis dans différents répertoires.
 
Dans ton outil de gestion de la connaissance, tu veux avoir un article sur ledit produit. A l'endroit où tu vas faire référence à la doc, tu vas mettre les urls pointant vers les différents documents intéressants de tout le cycle de vie. Du coup, là, tu va voir facilement les différents documents du produits, sans avoir à te préoccuper où ils sont stockés.

+1 pour la structure simple. Dans les wiki, tu retrouves ce principe même si certains autorisent de faire de la hiérarchie. Perso, je trouve qu'il faut éviter car trop tentant de mapper la structure de l'outil de gestion de la connaissance sur celle de l'organisation de l'entreprise.
 
Dans mon wiki, y'a que des catégories de premier niveau et des espaces de noms pour gérer les droits d'écriture. Par contre, l'outil est accessible en lecture seule à tous (qui sont là où je bosse).