J’aimerai que le wiki puisse être utilisable aussi par des non tech. Donc je pense que le côté doc versionné avec build auto c’est pas génial.
Les besoins que je vois :
éditable en WYSIWYG ou en Markdown
gestion des droits
avec des parties privés du wiki pour les Compagnons et des parties publiques
avec l’interdiction des modification par les visiteurs
historique des versions
moderation à postériori (pas besoin de valider les publication)
modération à priorie (si jamais certains sujets dérive)
ergonomique
plugable à un SSO
J’aimerai aussi laisser la possibilité à l’utilisateur de choisir sont éditeur, soit wysiwyg soit markdown.
Il y a deux ans on avais étudié pas mal de Wiki pour un client.
Voilà le comparatif qu’on en a sorti :
Gestion de tickets
Knowledge Base
Wiki
Markdown
Intéressant ?
BookStack
Dokit (MediaWiki)
dokuWiki
GLPI
Helpy
Mantis
dokuWiki intégré
plugin
MediaWiki
OpenSupports
Redmine
Wiki.js
xWiki
extension
YesWiki
extension
Zammad
Pour le moment le Wiki qui m’attire le plus c’est BookStack qui permet d’organisé le Wiki comme une bibliothèque. Il y a aussi un historique des modifications.
Après je ne suis pas très wiki de base car je trouve leur ergonomies souvent limité.
De base, je fonctionne plus sur des solutions statique pour une question de collaboration et de gestion d’hébergement. MkDocs est juste top, tout mon wiki perso est dessus.
Après, je peux comprendre que ça soit un frein pour certaines personnes. Je connais pas spécialement les autres solutions donc personnellement je suis ouvert. BookStack a l’air sympa à tester
Hello,
Perso j’ai mis en place du WikiJS, qui me parait vraiment pas mal. Pourquoi ?:
On peux mettre de l’authentification externe
Tu as de la gestion de groupe (tu peux faire du ABAC avec des tags sur les pages)
l’ergonomie semble plus simple que BookStack
On peux créer des pages en markdown, en WYSIWYG ou en HTML.
Il est automatisable via une API GraphQL
On peut syncrhoniser les fichiers sur un git (dans les deux sens : pull et push) ou sur un bucket s3 (pour des backups)
Les choses que je n’aime pas sur WikiJS
une fois l’éditeur d’une page choisi, impossible de le changer
la configuration de l’outil n’est pas “automatisable”, il n’existe pas de fichier de config pouvant contenir la config ldap, la config des groupes etc…, tout se fait via l’interface et est stocké dans la bdd
J’aime bien la doc Ansible, elle est faite avec Sphynx. Il y a un bouton “Edit on github”, on clique et ça ouvre le source sphynx et ça gére la pull request directement. Peut être existe-t-il quelque chose du genre avec gitlab ?
Pour ceux qui veulent voir, ça se passe ici : https://docs.ansible.com/ansible/latest/index.html
Je proposais juste une solution pas si éloignée du wiki qui je trouve à un super rendu pour un coût technique accessible à une personne dégourdie.
Question wiki, pour ma part je reste fidèle au bon vieux dokuwiki, il a l’avantage de ne pas utiliser de base de donnée et d’être bourré de plug-in.
Mais celui que tu propose semble très bien aussi pas d’avis particulier sur les autres moteurs vu que doku me convient parfaitement depuis plus de 10 ans
Le besoin étant de d’abord servir des utilisateurs “non initiés”, je pense vraiment que WikiJS est une excellente solution tout en ayant un certain potentiel d’automatisation / génération automatique de document via des synchronisation avec git.
Je l’ai déployé sur du kubernetes avec le chart Helm officiel (il est pas ouf, mais a le mérite d’exister) et des backups Velero quotidiennes (qui envoit tout ça sur du S3). C’est très pratique et rapide à mettre en place. A la différence de Bookstack il me semble qu’il n’y a pas d’instance de démo par contre.
Pour moi les deux solutions à évaluer c’est bookstack ou wikijs
On avais essayé WikiJS il y a 2 ans pour le mettre en place pour un client mais on l’avais ecarté à l’époque car il ne gerrai pas l’historique des modifications ou les droits utilisateurs.
Pour avoir une interface utilisable par n’importe qui, en effet je trouve dokuwiki bien fait.
Avantage de dokuwiki, il écrit une forme de markdown, gère l’historique et dispose d’un bon éditeur wysiwyg.
Je ne sais pas ce que rendrait l’usage de dokuwiki avec git ? Cela permettrait de conserver l’éditeur dans l’interface web, et permettrait à ceux qui le souhaitent de rédiger en markdown localement, avant de pousser leurs changements.
Enfin je veux dire on est très loin en terme d’ergonomie de WikiJS ou Bookstack.
On est vraiment dans un wiki à l’ancienne.
Perso ce genre de wiki je les fuis.
Mon humble avis: commencer par les bonnes questions: quel est le but ? Et reposez-vous la même question plusieurs fois (je commence toujours par ça avec mes clients ).
Vous êtes déjà arrivé à la solution du Wiki, mais quel est l’objectif ?
Personnellement, et avec tous mes clients, que ce soit pour de la doc technique, ou des bases de connaissances, je n’utilise plus que markdown + mkdocs sur GitHub ou GitLab.
Mes objectifs sont les suivants:
Créer une base documentaire (ça, c’est évident)
Pouvoir gérer le cycle de vie de la documentation de la même façon que tout le reste (le code, l’infra, …) avec une ouverture pour la contribution, mais une revue stricte sur le contenu avec discussion possible (Pull / Merge Requests)
S’assurer que la doc est toujours “fraîche” (pas d’hyperliens qui expirent, pas de fautes d’orthographe ou de syntaxe, discipline sur les acronymes (DevOps et pas devops ou DevOPS ou …). Et donc: avoir des tests automatiques sur la doc
Maintenir les liens hypertextes externes, même si le contenu bouge
DRY - Don’t Repeat Yourself: utiliser des macros/includes pour du contenu qui doit être dupliqué (et donc factorisable)
Montrer l’exemple. La doc a justement l’avantage d’être un exemple concret d’implémentation de chaîne CI et CD simple, de pouvoir mettre les mains dedans - même si on est pas développeur Java certifié (!), et de montrer l’exemple.
).