Déployez un wiki open source auto hébergé en 3 scénarios

Pour un wiki open source auto hébergé, la première décision n’est pas le nom du logiciel, mais le mode de stockage. Un système à fichiers plats comme DokuWiki convient à un usage personnel ou à une petite équipe qui veut une sauvegarde simple. Une base de données comme celle de MediaWiki devient nécessaire dès que le volume de contenu ou le nombre de contributeurs grandit. Le reste, DokuWiki, Wiki.js, XWiki, BookStack et les autres, se choisit ensuite selon votre cas d’usage précis.

En bref:

• Un wiki auto hébergé à faible volume, comme DokuWiki ou LeafWiki, nécessite peu de dépendances et se déploie rapidement, idéal pour l’usage personnel ou un homelab.
• Les solutions basées sur une base SQL, comme MediaWiki ou XWiki, demandent une configuration initiale plus complexe mais sont adaptées aux contenus massifs et aux grands publics.
• La sauvegarde d’un wiki à fichiers plats se résume à une simple copie de dossier, tandis que celles basées sur une base SQL exigent des dumps réguliers pour garantir la sécurité des données.
• La gestion en auto hébergement implique une maintenance régulière, avec des risques accrus en cas de mises à jour ou de gestion des vulnérabilités, sauf si une solution managée est choisie.
• L’exportabilité facile en Markdown ou dump SQL est essentielle pour conserver le contrôle total sur ses données, surtout lors d’une migration ou d’un changement d’outil.

Table des matières

• Quelle solution de wiki d’entreprise auto hébergé choisir selon votre usage ?
• Comment choisir un logiciel wiki gratuit adapté à votre situation ?
• Comment déployer un wiki auto hébergé en trois scénarios types ?
• Sur quels critères repose cette comparaison de wikis open source ?
• Faut il gérer son wiki soi même ou passer par une offre managée ?
• Quel wiki open source choisir selon votre profil d’utilisateur ?
• Ce que cette comparaison nous a appris chez Yundera
• Yundera : le serveur privé géré pour garder vos apps open source sans la charge technique
• Où trouver la documentation officielle de ces wikis open source ?
• Sources

Quelle solution de wiki d’entreprise auto hébergé choisir selon votre usage ?

Chaque outil de cette liste répond à un profil différent. Certains privilégient la légèreté, d’autres la structure collaborative, d’autres encore la compatibilité avec des workflows techniques existants. Voici les fiches synthétiques des principaux solutions wiki open source disponibles aujourd’hui.

DokuWiki stocke chaque page en texte brut, sans base de données. Vous sauvegardez tout le wiki avec une simple copie de dossier, ce qui explique pourquoi il reste le choix par défaut pour la documentation interne, un wiki personnel ou un homelab. Son système de contrôle d’accès (ACL) intégré et ses connecteurs d’authentification en font aussi une option sérieuse pour des équipes qui veulent restreindre certaines pages sans monter une infrastructure lourde.

MediaWiki est le moteur qui fait tourner Wikipédia. Il est pensé pour la scalabilité massive et pour des bases de connaissances publiques qui comptent des millions de pages, mais il exige une base SQL et une administration plus exigeante que DokuWiki. Si votre projet vise un public large avec des besoins d’indexation poussés, c’est une référence naturelle.

Wiki.js mise sur une expérience moderne : éditeur Markdown natif, API ouverte, et une architecture qui s’appuie sur Node.js avec PostgreSQL ou MySQL en option. C’est le compromis qui parle le plus aux équipes techniques qui veulent connecter leur wiki à d’autres outils internes.

XWiki vise l’entreprise structurée : extensions poussées, fonctionnalités collaboratives avancées, gestion fine des espaces. Il demande davantage de configuration au départ, mais récompense les organisations qui ont un vrai besoin de personnalisation.

BookStack organise le contenu en livres, chapitres et pages plutôt qu’en arborescence libre. Son interface, avec un éditeur qui bascule entre Markdown et WYSIWYG, plaît aux équipes qui documentent des processus métiers de façon linéaire.

LeafWiki, écrit en Go, se distingue par un binaire unique et un stockage Markdown sur disque, sans dépendance externe à installer. C’est l’option la plus minimaliste pour un homelab ou un utilisateur qui refuse la complexité d’un serveur d’applications.

Gollum repose entièrement sur Git : chaque modification devient un commit, chaque page reste un fichier Markdown versionné. Les équipes déjà habituées à Git y trouvent un historique natif sans outil de versioning supplémentaire.

Pour démarrer vite, DokuWiki et LeafWiki se lancent en quelques minutes sans base de données à provisionner. MediaWiki et XWiki demandent de préparer une base SQL en amont, ce qui rallonge la première installation mais paie sur la durée si votre volume grossit.

Comment choisir un logiciel wiki gratuit adapté à votre situation ?

Avant de trancher entre deux outils qui se ressemblent sur le papier, passez votre projet dans une grille de critères concrets. Voici les points qui font vraiment la différence une fois le wiki en production.

1. Installation : un conteneur Docker isole les dépendances et simplifie les mises à jour, mais demande de gérer le stockage persistant et les permissions de volume pour éviter toute corruption de données. Un package natif ou un binaire unique comme celui de LeafWiki évite cette couche, au prix d’une portabilité moindre entre serveurs.
2. Maintenance : chaque dépendance supplémentaire, PHP, Node, une base MySQL, est une surface d’attaque à surveiller et une mise à jour de sécurité à appliquer.
3. Sauvegardes : une copie de répertoire suffit pour un wiki à fichiers plats, alors qu’un système en base de données réclame un dump SQL régulier en plus du volume de fichiers.
4. Sécurité : TLS via un reverse proxy (Nginx, Caddy) et une authentification correctement configurée restent non négociables, quel que soit l’outil choisi.
5. Coûts cachés : le temps passé à surveiller les CVE, à tester les mises à jour et à documenter la procédure de restauration pèse souvent plus lourd que le coût du serveur lui même.

Conseil de pro : avant de choisir votre outil, listez le nombre de contributeurs prévus dans les douze prochains mois. Un wiki qui reste sous les dix utilisateurs actifs n’a presque jamais besoin de la puissance de MediaWiki.

Comment déployer un wiki auto hébergé en trois scénarios types ?

Le déploiement change peu dans son squelette, que vous montiez un wiki perso, un espace d’équipe ou une base publique. Voici la marche à suivre pour chacun.

Scénario 1, usage personnel (DokuWiki ou LeafWiki) :

1. Réservez un sous-domaine et pointez son enregistrement DNS vers votre serveur.
2. Installez un reverse proxy (Caddy gère Let’s Encrypt automatiquement) pour obtenir le TLS sans configuration manuelle.
3. Lancez le conteneur avec un volume monté sur le dossier de données, par exemple docker run -v /data/dokuwiki:/var/www/html/data.
4. Testez immédiatement une restauration en copiant ce dossier ailleurs et en le rechargeant : c’est le seul moyen de savoir si votre sauvegarde fonctionne vraiment.

Scénario 2, équipe technique (Wiki.js ou XWiki) :

• Préparez une base PostgreSQL ou MySQL dédiée avant le premier lancement.
• Utilisez un fichier docker-compose.yml qui déclare le service applicatif et la base ensemble, avec des volumes séparés pour chacun.
• Configurez l’authentification via LDAP ou SSO si votre équipe utilise déjà un annuaire.

Scénario 3, base publique volumineuse (MediaWiki) :

• Provisionnez une base SQL dimensionnée pour la croissance attendue, pas seulement pour le lancement.
• Activez la mise en cache (Memcached ou Redis) dès le départ pour absorber le trafic.
• Planifiez un dump SQL automatisé quotidien, en plus des sauvegardes de fichiers médias.

Dans les trois cas, un test de restauration mensuel reste la seule preuve fiable que votre stratégie de sauvegarde tient la route le jour où vous en aurez besoin.

Sur quels critères repose cette comparaison de wikis open source ?

Le tableau et les recommandations de cet article s’appuient sur trois types de sources : la documentation officielle de chaque projet, des comparatifs techniques publiés par des communautés d’auto-hébergement, et des pages de benchmarks quand elles existent. Les critères retenus pour comparer les outils sont volontairement simples et reproductibles :

• Le type de stockage (fichiers plats, SQL, SQLite) et son impact direct sur la sauvegarde.
• Le niveau de dépendances système requis (PHP seul, Node, base de données externe).
• La présence d’un export natif en Markdown, XML ou dump SQL.
• Le support d’un éditeur Markdown ou WYSIWYG.

Sur la question spécifique de la performance, des comparatifs entre DokuWiki et MediaWiki montrent que DokuWiki démarre avec un overhead plus faible en configuration standard, un avantage net sur des environnements PHP sans accélération de cache. Ce constat pèse dans la recommandation faite pour les petits déploiements, mais il ne dit rien de la scalabilité au delà de quelques milliers de pages, un terrain où MediaWiki reprend l’avantage.

Cette comparaison a ses limites. Les extensions communautaires évoluent vite, une fonctionnalité absente aujourd’hui peut apparaître dans une future version. Les chiffres de performance dépendent aussi énormément de la configuration serveur, du cache utilisé et du volume réel de contenu, ce qui rend toute mesure absolue difficile à généraliser à votre cas précis.

Faut il gérer son wiki soi même ou passer par une offre managée ?

L’auto-hébergement donne un contrôle total sur vos données, mais il a un coût réel en temps : appliquer les correctifs de sécurité, surveiller les CVE, tester les sauvegardes. Pour réduire cette charge, optez pour un hébergement web infogéré et sécurisé qui externalise la maintenance tout en garantissant la sécurité. Pour une équipe sans administrateur système dédié, ce temps s’accumule vite et devient le vrai coût caché du projet.

Le choix ne se résume pas à « open source contre propriétaire ». Il se résume à la question suivante : qui, chez vous, va appliquer la prochaine mise à jour de sécurité dans six mois, et avec quel niveau de vigilance ?

Une offre managée ne change rien au logiciel installé, elle change qui porte la charge opérationnelle. Pour une petite structure, cela réduit le risque de laisser un serveur non patché pendant des mois.

Conseil de pro : gardez toujours la possibilité d’exporter vos pages en Markdown ou en dump SQL, même chez un hébergeur managé. C’est ce qui vous évite de rester prisonnier d’une plateforme le jour où vous voulez migrer.

Quel wiki open source choisir selon votre profil d’utilisateur ?

• Profil personnel ou homelab : privilégiez un outil à fichiers plats comme DokuWiki ou LeafWiki. La sauvegarde tient en une commande, et l’empreinte serveur reste minimale.
• Équipe technique : Wiki.js ou XWiki apportent l’API et les intégrations qui manquent aux outils plus anciens.
• Base publique à forte volumétrie : MediaWiki reste la référence, conçu dès l’origine pour des millions de pages et un trafic massif.
• Vous préférez déléguer l’infrastructure : une solution managée élimine la charge de maintenance sans vous priver de l’écosystème open source.

Le point commun entre ces quatre profils : aucun n’a besoin de la même solution, et c’est justement ce qui rend la question « quel est le meilleur wiki open source » mal posée sans préciser d’abord votre cas d’usage.

Ce que cette comparaison nous a appris chez Yundera

Nous avons remarqué, en observant les choix des équipes qui nous contactent, un biais récurrent : beaucoup partent sur MediaWiki par réflexe, parce que c’est le nom qu’ils connaissent, alors que leur usage réel ressemble davantage à un DokuWiki ou un BookStack. Le nom le plus connu n’est presque jamais le bon critère de choix.

Ce qui compte réellement, à nos yeux, c’est l’exportabilité. Un wiki que vous ne pouvez pas faire sortir facilement en Markdown ou en dump SQL vous enferme, même si le logiciel de départ est open source. C’est pour cette raison que nous accompagnons les équipes qui veulent profiter d’un wiki open source self hosted sans porter seules la charge de la maintenance serveur, tout en gardant la garantie de pouvoir repartir avec leurs données à tout moment.

Notre conseil reste constant : testez votre outil en environnement fermé, avec de fausses données, avant toute migration réelle. C’est la seule façon de valider que la sauvegarde et la restauration fonctionnent comme annoncé, avant que ça compte.

— Yundera

Yundera : le serveur privé géré pour garder vos apps open source sans la charge technique

Vous avez repéré l’outil qui correspond à votre besoin, DokuWiki, Wiki.js, MediaWiki ou un autre. Reste la question de qui va l’installer, le sécuriser et le maintenir dans six mois. Yundera est l’alternative à l’auto-hébergement bricolé : un serveur privé géré, hébergé en France, sur lequel vous installez votre wiki (ou n’importe laquelle des plus de 100 applications open source disponibles) sans jamais toucher à un terminal.

Vous gardez la propriété totale de vos données, avec export garanti à tout moment, et un accès sécurisé depuis n’importe où via votre propre nom de domaine. Aucune donnée n’est collectée ni revendue : l’infrastructure reste éthique de bout en bout. Pour les petites équipes ou les indépendants qui veulent créer un wiki privé sans recruter un administrateur système, c’est le compromis qui évite le choix binaire entre bricoler seul et perdre le contrôle chez un géant du cloud.

Consultez la page serveur privé Yundera pour voir comment démarrer votre propre instance et quelles applications open source l’accompagnent dès l’installation.

Où trouver la documentation officielle de ces wikis open source ?

Pour approfondir chaque outil mentionné, les sources officielles restent la meilleure porte d’entrée : elles documentent les extensions disponibles, les procédures de mise à jour et les limites connues de chaque version.

• La documentation officielle de DokuWiki détaille l’installation, les ACL et le système de plugins.
• Le wiki de MediaWiki couvre l’architecture, les extensions et les guides de montée en charge.
• La documentation de Wiki.js explique la configuration Node/PostgreSQL et l’usage de l’API.
• Le comparatif de benchmarks DokuWiki contre MediaWiki sur Meta-Wiki donne des repères de performance utiles avant de trancher.
• Le dépôt GitHub de LeafWiki reste la référence pour les instructions d’installation du binaire unique.

Pour aller plus loin sur les alternatives collaboratives proches des wikis, notre article sur les meilleures alternatives à Confluence complète utilement cette comparaison.

Recommandations

• CMS open source auto hébergé : le guide pour garder le contrôle
• Meilleures alternatives à Confluence pour équipes françaises
• Suite collaborative open source : maîtrisez vos données en 2026