BookStack, Wiki.js ou Outline : quel wiki auto-héberger ?

Quel wiki auto-hébergé devriez-vous utiliser

Un wiki auto-hébergé regroupe les documents de votre équipe dans un emplacement consultable sur un serveur que vous contrôlez. BookStack, Wiki.js et Outline remplissent tous cette fonction. Ils se distinguent surtout par la quantité de composants à configurer avant l’affichage de la première page et par les personnes autorisées à se connecter.

BookStack est le plus simple à déployer et impose la structure la plus stricte. Wiki.js offre le plus grand choix d’éditeurs dans une même arborescence de pages. Outline propose la meilleure expérience de rédaction des trois. En revanche, personne ne peut s’y connecter tant que vous n’avez pas configuré un fournisseur d’identité externe.

Tout ce qui suit provient de la documentation officielle des projets et de leurs fichiers de configuration publiés. Il s’agit d’une comparaison des fonctionnalités, pas d’un benchmark. Les numéros de version et les exigences sont associés à une date, car les trois projets évoluent.

La structure est le véritable choix

BookStack impose la structure de votre contenu. Une page se trouve dans un livre, un livre peut contenir des chapitres et les étagères regroupent les livres. Vous ne pouvez pas inventer un cinquième niveau. Cette limite fait partie du produit : un nouvel auteur sait où placer une page, car elle ne peut aller qu’à un seul endroit. En contrepartie, le contenu qui ne correspond pas à cette structure doit y être forcé.

Wiki.js utilise une arborescence de chemins, comme les dossiers sur un disque. Une page à ops/backup/restic se trouve à l’endroit où vous la placez, et vous choisissez la profondeur. Rien n’empêche deux personnes de classer le même sujet dans deux branches différentes. Une instance Wiki.js a donc besoin d’une personne responsable de l’arborescence.

Outline utilise des collections contenant des documents imbriqués dans d’autres documents. Pour déplacer un document, il suffit de le faire glisser avec la souris. C’est la solution la plus flexible des trois, mais aussi celle qui dérive le plus facilement.

BookStack : l’installation minimale

BookStack est une application PHP qui utilise MySQL. En juillet 2026, la documentation indique comme prérequis PHP 8.2 ou une version ultérieure, ainsi que MySQL 8.0 ou MariaDB 10.6 ou une version ultérieure. Composer 2.2 ou une version ultérieure est également requis pour une installation depuis les sources. La branche de versions actuelle est la 26.05.

Le projet publie un script d’installation pour chaque version d’Ubuntu. Le script pour 24.04 installe Apache, MySQL 8.0 et PHP 8.3.

wget https://codeberg.org/bookstack/devops/raw/branch/main/scripts/installation-ubuntu-24.04.sh
chmod a+x installation-ubuntu-24.04.sh
sudo ./installation-ubuntu-24.04.sh

Lisez l’avertissement de ce script avant de l’exécuter. La documentation précise qu’il est « UNIQUEMENT DESTINÉ À UN SYSTÈME D’EXPLOITATION NEUF : il installera Apache, MySQL 8.0 et PHP 8.3 et pourrait ÉCRASER toute configuration web existante sur la machine ». Sur un serveur qui répond déjà sur le port 80, le script s’approprie ce port et réécrit la configuration Apache. Utilisez plutôt des conteneurs dans ce cas, ou installez BookStack manuellement par-dessus une stack LAMP existante sur Ubuntu 24.04.

La solution avec conteneur utilise l’image LinuxServer.io, recommandée par la documentation de BookStack. BookStack a besoin d’une clé de chiffrement des sessions et ne servira aucune page sans cette clé. Générez-la donc au préalable.

docker run -it --rm --entrypoint /bin/bash lscr.io/linuxserver/bookstack:latest appkey

Copiez la valeur affichée dans APP_KEY, puis écrivez le service :

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - APP_URL=https://wiki.example.com
      - APP_KEY=paste_the_generated_key_here
      - DB_HOST=bookstack_db
      - DB_PORT=3306
      - DB_USERNAME=bookstack
      - DB_PASSWORD=change_me
      - DB_DATABASE=bookstackapp
    volumes:
      - ./config:/config
    ports:
      - 6875:80
    restart: unless-stopped

APP_URL doit correspondre à l’adresse que les lecteurs saisissent réellement, avec le schéma et l’éventuel port. Définissez-la sur http://localhost, puis servez le site en HTTPS. Sinon, les liens générés et les redirections pointeront vers le mauvais hôte, ce que les lecteurs verront comme une page de connexion qui revient en boucle sur elle-même. Si les fichiers Compose ne vous sont pas familiers, commencez par les bases de Docker Compose sur un VPS avant de suivre ce guide.

Démarrez le service et vérifiez que l’application répond, pas seulement que le conteneur est en cours d’exécution :

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:6875/login

Un 200 OK signifie que l’application PHP a démarré et a atteint la base de données. Un 500 signifie presque toujours que APP_KEY est vide ou que les identifiants de la base de données ne correspondent pas. docker compose logs bookstack indique lequel de ces deux cas se produit.

Wiki.js : une arborescence, plusieurs éditeurs

Wiki.js est une application Node.js. La configuration Docker documentée l’associe à PostgreSQL, mais le logiciel accepte également MySQL, MariaDB, MSSQL et SQLite. Voici le fichier Compose de la page Docker du projet :

services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    logging:
      driver: none
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    init: true
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "80:3000"
volumes:
  db-data:

Modifiez POSTGRES_PASSWORD et DB_PASS ensemble avant de l’exécuter, car ils forment un seul identifiant et la valeur d’exemple est publique. Le tag est épinglé sur ghcr.io/requarks/wiki:2 à dessein. La documentation déconseille latest, car un saut de version majeure modifie le schéma de la base de données pendant qu’une instance est en fonctionnement.

La version 2 est la branche à utiliser. En juillet 2026, la version 2 la plus récente est 2.5.314, publiée en mai 2026. La version 3 existe, et sa propre documentation indique : « Ce site concerne la version bêta instable de Wiki.js 3.0. Vous ne devez PAS l’installer en production. » Considérez le tag :3 comme une version de prévisualisation.

Au premier chargement, Wiki.js vous guide dans une configuration accessible depuis le navigateur, qui crée le compte administrateur. Tant que vous ne l’avez pas terminée, toute personne qui atteint le port voit cet assistant. Placez donc le service derrière votre reverse proxy et TLS (transport layer security) avant d’ouvrir le firewall. Un wiki sur son propre nom d’hôte se place naturellement derrière Traefik devant plusieurs applications Docker lorsque le serveur héberge plus que ce seul service.

Le choix de l’éditeur explique pourquoi Wiki.js est utilisé. Une même instance peut héberger côte à côte des pages Markdown, des pages de l’éditeur visuel, des pages HTML brutes et des pages AsciiDoc. Cela facilite l’importation d’anciens contenus dans un format que vous préférez ne pas convertir. C’est aussi un moyen de se retrouver avec quatre styles éditoriaux dans un même wiki. Choisissez donc l’éditeur par défaut dès le premier jour et consignez cette décision.

Plan : le meilleur éditeur, les prérequis les plus lourds

Outline est généralement ce que les utilisateurs veulent dire lorsqu’ils recherchent un outil de notes qui ressemble à un produit commercial. C’est une application Node.js. La version actuelle en juillet 2026 est 1.9.2. Son fichier d’environnement d’exemple indique ses prérequis : PostgreSQL via DATABASE_URL, Redis via REDIS_URL, deux secrets aléatoires et un URL accessible publiquement.

openssl rand -hex 32
openssl rand -hex 32

Exécutez cette commande deux fois et conservez les deux valeurs. La première devient SECRET_KEY et la seconde UTILS_SECRET. La partie principale du fichier d’environnement ressemble alors à ceci :

NODE_ENV=production
URL=https://docs.example.com
PORT=3000
SECRET_KEY=<first openssl value>
UTILS_SECRET=<second openssl value>
DATABASE_URL=postgres://outline:change_me@postgres:5432/outline
PGSSLMODE=disable
REDIS_URL=redis://redis:6379
FILE_STORAGE=local
FILE_STORAGE_LOCAL_ROOT_DIR=/var/lib/outline/data

PGSSLMODE=disable est correct uniquement si la base de données se trouve sur la même machine ou sur le même réseau Docker. Ne le renseignez pas si la base est accessible via le réseau, sinon la connexion circule en clair. Les pièces jointes ne vous obligent plus à utiliser un stockage objet : FILE_STORAGE=local enregistre les fichiers importés dans le répertoire indiqué plus haut. Celui-ci doit correspondre à un volume dans lequel le conteneur peut écrire et que vos sauvegardes incluent. Définissez plutôt FILE_STORAGE=s3 avec les valeurs AWS_* si vous voulez stocker ces fichiers dans un bucket compatible S3.

Voici le point qui surprend souvent. Outline ne possède pas de connexion intégrée par nom d’utilisateur et mot de passe. Sa configuration d’exemple indique que les identifiants d’un fournisseur de connexion tiers sont obligatoires : « au moins UN de ces éléments est requis pour une installation fonctionnelle, sinon aucune option de connexion ne sera disponible ». Les fournisseurs documentés incluent Google, Slack, Microsoft Entra, Discord et tout serveur OpenID Connect (OIDC) générique via OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, OIDC_AUTH_URI, OIDC_TOKEN_URI et OIDC_USERINFO_URI.

Le coût réel d’Outline est donc Outline, PostgreSQL, Redis et un fournisseur d’identité. Si votre équipe utilise déjà Google Workspace ou Microsoft Entra pour se connecter, ce dernier élément vous demande dix minutes et Outline devient très intéressant. Dans le cas contraire, vous devez aussi auto-héberger un service comme Keycloak ou Authentik. Il s’agit d’un deuxième service à mettre à jour et à sauvegarder. Prévoyez suffisamment de mémoire : les recommandations d’Outline indiquent environ 512 MB par processus web, défini par WEB_CONCURRENCY, en plus de la base de données et de Redis.

Comment chacun gère les droits de lecture

BookStack propose par défaut des comptes locaux avec adresse e-mail et mot de passe, et prend également en charge LDAP, SAML2 et OIDC. Les permissions se définissent par rôle et peuvent être remplacées pour une étagère, un livre, un chapitre ou une page donnée. Comme la hiérarchie est fixe, les permissions sont héritées selon cette hiérarchie de manière prévisible.

Wiki.js propose également des comptes locaux et ajoute une longue liste de stratégies à activer dans l’interface d’administration. Ses règles de page autorisent ou refusent l’accès selon un motif de chemin. Cette méthode est puissante, mais il est facile de se tromper, car une règle écrite pour ops/* couvre automatiquement toutes les pages que vous placerez ensuite sous ce chemin.

Outline délègue entièrement cette gestion. L’appartenance suit votre fournisseur d’identité, et vous contrôlez les accès dans Outline par collection et par groupe. Aucun compte local ne reste lorsqu’une personne quitte l’entreprise. C’est un avantage important lorsque le fournisseur d’identité est déjà le système utilisé pour supprimer les accès.

Fonctionnement de la recherche dans chaque solution

La recherche détermine si un wiki trouve réellement sa place ou devient un dossier rempli de fichiers oubliés.

BookStack interroge la base de données et fournit aux lecteurs un langage de requête qui s’apprend en une minute. Mettre une expression entre guillemets, comme dans "london meeting", exige la présence exacte de cette chaîne. Les crochets recherchent les tags : [location=london] effectue la recherche sur le nom du tag, sa valeur ou les deux, avec notamment les comparaisons !=, >= et like. Les accolades filtrent les métadonnées, comme dans {created_after:2016-12-30}. Tout terme exact, de tag ou de filtre peut être exclu en le préfixant avec -. BookStack limite le nombre de termes de chaque type dans une requête. Une requête très longue est donc tronquée au lieu d’être exécutée.

Wiki.js traite la recherche comme un module interchangeable. Les moteurs documentés sont un moteur de base de données, un moteur PostgreSQL, Elasticsearch, Algolia, AWS CloudSearch et Azure Search. Le moteur de base convient à quelques centaines de pages. Si vous utilisez PostgreSQL, sélectionnez le moteur PostgreSQL dans la zone d’administration, car il utilise l’index full text de la base de données au lieu d’une simple recherche par correspondance. Réservez Elasticsearch à un wiki suffisamment volumineux pour justifier l’exécution et la mise à jour d’un second service de recherche.

Outline utilise les index full text de PostgreSQL. Il n’y a aucun moteur à sélectionner ni aucun réglage à effectuer. La recherche porte également sur le texte des documents importés. Pour un wiki d’équipe contenant quelques milliers de documents, c’est la solution qui demande le moins de travail parmi les trois. En revanche, si la recherche devient trop lente, vous ne disposez d’aucun réglage pour y remédier.

Celui qui vous convient

Choisissez BookStack si vous voulez que le wiki soit opérationnel cet après-midi et si vous préférez discuter du contenu plutôt que de la structure. C’est la solution qui comporte le moins d’éléments : une application PHP et une base de données MySQL. Elle convient aux runbooks internes comme à la documentation client, ainsi qu’aux équipes dont la plupart des rédacteurs ne sont pas ingénieurs. C’est aussi la solution la plus facile à sauvegarder, car l’état complet tient dans un dump de base de données et le répertoire des fichiers téléversés.

Choisissez Wiki.js si vous avez besoin d’un éditeur précis ou d’une stratégie d’authentification particulière que les autres ne proposent pas, ou si vous importez un volume important de fichiers Markdown ou AsciiDoc existants et voulez conserver la structure des chemins. Vous devrez accepter d’exécuter une stack plus lourde et figer le tag de version majeure.

Choisissez Outline si la qualité rédactionnelle est votre priorité, si le wiki est destiné à une équipe plutôt qu’au public et si vous disposez déjà d’un fournisseur d’identité. Cette configuration vous donne accès à l’éditeur que les utilisateurs apprécient réellement. N’en faites pas votre première application auto-hébergée.

Si aucune des trois solutions ne convient, le problème vient généralement du type de contenu. Les factures et contrats numérisés doivent être gérés dans un système de gestion documentaire tel que Paperless-ngx, et non dans un wiki. Les y intégrer de force explique pourquoi tant de wikis finissent par être abandonnés. L’autre incompatibilité fréquente consiste à vouloir un workspace plutôt qu’un wiki, avec des documents, des tableaux et un tableau blanc sur un même canvas. Dans ce cas, un workspace AFFiNE auto-hébergé convient mieux que les trois solutions précédentes. Pour avoir une vue plus large des applications qui méritent une place sur votre propre serveur, consultez la sélection d’applications à auto-héberger pour 2026.

Dimensionnement et sauvegardes

Les trois solutions tiennent sur un petit VPS, mais le minimum réaliste varie selon les composants utilisés par chacune. BookStack utilise un processus applicatif et MySQL. Wiki.js utilise un processus Node et PostgreSQL. Outline utilise un processus Node, PostgreSQL et Redis, généralement avec un fournisseur d’identité en plus. C’est pourquoi il faut lui attribuer davantage de mémoire.

Sauvegardez ensemble la base de données et les fichiers téléversés, puis restaurez-les une fois dans une instance temporaire avant de vous fier à cette sauvegarde. Une sauvegarde de wiki qui n’a jamais été restaurée ne constitue qu’une hypothèse. Pour BookStack, cela signifie mysqldump ainsi que le volume /config. Pour Wiki.js et Outline, cela signifie pg_dump ainsi que le volume de données. Pour Outline, cela inclut également tout ce qui se trouve dans FILE_STORAGE_LOCAL_ROOT_DIR.

FAQ

Quel wiki auto-hébergé est le plus facile à installer ?

BookStack. Il s’agit d’une application PHP unique avec une base de données MySQL. Le projet fournit un script d’installation pour Ubuntu 24.04 qui configure Apache, MySQL 8.0 et PHP 8.3 en une seule exécution. L’image de conteneur nécessite uniquement un APP_KEY et les identifiants de la base de données. Wiki.js ajoute un runtime Node et un serveur PostgreSQL. Outline ajoute en plus Redis et un fournisseur d’identité externe.

Puis-je utiliser Outline sans Google ni un autre fournisseur SSO ?

Non. Outline ne propose pas de connexion locale avec un nom d’utilisateur et un mot de passe. Sa configuration d’exemple indique qu’au moins un fournisseur de connexion tiers est requis. Sinon, aucune option de connexion n’est disponible. Vous pouvez utiliser Google, Slack, Microsoft Entra, Discord ou n’importe quel serveur OpenID Connect générique, comme Keycloak ou Authentik auto-hébergé. L’exploitation de ce fournisseur fait partie du coût d’exploitation d’Outline.

Dois-je installer Wiki.js 3 ou Wiki.js 2 ?

La version 2. En juillet 2026, la dernière version 2 est 2.5.314, publiée en mai 2026. La documentation de la version 3 indique clairement qu’il s’agit d’une bêta instable qui ne doit pas être installée en production. Épinglez votre image sur ghcr.io/requarks/wiki:2 plutôt que sur latest, car un changement de version majeure modifie le schéma de la base de données pendant l’exécution de l’instance.

Lequel offre la meilleure recherche ?

Ils sont performants dans des domaines différents. BookStack propose aux lecteurs un langage de requête avec recherche d’expressions exactes, filtres par tags tels que [location=london] et filtres de métadonnées tels que {created_after:2016-12-30}. Chacun de ces termes peut être exclu avec un - placé au début. Outline ne nécessite aucune configuration et recherche dans le texte des fichiers téléversés. Wiki.js est le plus configurable, car vous choisissez le moteur. Le moteur PostgreSQL mérite d’être adopté dès que votre wiki dépasse quelques centaines de pages.

Puis-je transférer mon contenu de l’un à l’autre plus tard ?

Partiellement, et vous devez prévoir un travail manuel. Les trois solutions exportent et importent du Markdown. Le texte des pages est donc généralement conservé. La structure, en revanche, n’est pas transférée proprement. Les livres et chapitres de BookStack n’ont pas d’équivalent dans les documents imbriqués d’Outline. Les chemins de Wiki.js ne correspondent pas à la hiérarchie fixe de BookStack. Les pièces jointes, les permissions et l’historique des pages sont les éléments les plus susceptibles d’être perdus. Exportez donc un échantillon et vérifiez ces éléments avant de lancer une migration.