Systèmes documentaires en entreprise : Markdown, schémas et coût réel à 20 personnes

Choisir un système documentaire d’équipe est un exercice pénible parce que toutes les pages de tarification racontent la même histoire : éditeur collaboratif, recherche puissante, intégrations, IA. Les fonctionnalités convergent. Ce qui ne converge pas, c’est ce qu’il y a dans la base de données, ce que ça coûte au bout de trois ans, et ce que ça coûte de partir.

Cet article part d’un cahier des charges précis :

Client macOS natif ou application web, au choix.
Auto-hébergeable, et si oui : avec quelle infrastructure concrètement ?
Coûts réels, licences et infrastructure comprises.
Une équipe de 20 personnes d’horizons variés : développeur·euses, graphiste, UI/UX, CEO, commerciaux, chefs de produit et de projet.
Markdown comme socle, critère non négociable.
Support des schémas, avec Excalidraw comme bonus apprécié.

Les deux derniers critères sont ceux qui font le tri. Et ils sont en tension directe avec le quatrième, pour une raison structurelle qu’il faut poser avant de comparer quoi que ce soit.

1. Pourquoi ce cahier des charges est plus contraignant qu’il n’y paraît

Le Markdown au repos tire vers les fichiers : un dossier, des .md, un dépôt Git. C’est durable, greppable, diffable, et ça survit à la disparition de l’éditeur qui l’a produit.

La collaboration temps réel à 20 personnes tire dans l’autre sens. L’édition concurrente sans conflit repose sur des CRDT (Conflict-free Replicated Data Type — structure de données répliquée qui converge sans arbitrage central), et un CRDT ne s’applique pas à du texte Markdown brut : il s’applique à un arbre de nœuds typés. Concrètement, tous les éditeurs collaboratifs modernes stockent un arbre ProseMirror ou équivalent, sérialisé en JSON, plus un état binaire Yjs pour la convergence. Le Markdown devient alors un format d’import/export, plus un format de stockage.

Ajoutez les schémas et la tension se durcit encore : un diagramme est par nature du contenu binaire ou du JSON. Le Markdown n’a aucune primitive pour ça.

Markdown au repos                          CRDT / JSON au repos
(fichiers, Git)                            (base de données)
        │                                          │
        ├── survit à l'outil                       ├── édition simultanée
        ├── diff et revue par PR                   ├── permissions par page
        ├── grep, scripts, agents IA               ├── UX non-dev correcte
        │                                          │
        └── ✗ pas d'édition simultanée             └── ✗ coût de sortie élevé
        └── ✗ permissions grossières               └── ✗ Markdown = export

Aucun outil ne se place proprement dans les deux colonnes. Le travail consiste donc à choisir de quel côté on paie, et à s’assurer que le prix est celui qu’on avait prévu.

2. Le critère qui décide tout : que contient la base de données ?

« Supporte le Markdown » ne veut rien dire. Il faut distinguer quatre degrés, parce qu’ils n’engagent pas du tout le même avenir.

2.1 Les quatre degrés de support Markdown

Degré 1 — Markdown comme raccourci de frappe. Vous tapez ## Titre, l’éditeur convertit en titre de niveau 2, et le Markdown disparaît. Il ne reste rien de votre syntaxe. C’est le cas de Notion et de Confluence.

Degré 2 — Markdown comme format d’échange. Le stockage est propriétaire, mais l’outil expose un import et un export Markdown de qualité, idéalement via une API (Application Programming Interface — interface de programmation). C’est le cas d’Outline et de Docmost.

Degré 3 — Markdown comme source persistée. L’outil conserve votre source Markdown originale à côté de sa représentation de rendu. C’est le cas de BookStack, qui garde les deux colonnes.

Degré 4 — Markdown comme stockage. Le contenu est un ensemble de fichiers .md sur un système de fichiers ou dans un dépôt Git. C’est le cas d’Obsidian, des Wiki GitHub, de SilverBullet, et de Wiki.js à condition d’activer sa synchronisation Git.

2.2 Pourquoi ça compte : le coût de sortie

Le degré de support Markdown est un mauvais critère esthétique et un excellent critère économique. Il mesure une chose : ce que coûte le départ.

Sur ce point, la documentation de Notion est honnête. L’export Markdown est lossy par construction, et c’est structurel : les bases de données deviennent des fichiers CSV accompagnés d’une page Markdown par ligne, les blocs toggle s’aplatissent, les colonnes et la mise en page disparaissent, les blocs synchronisés se désynchronisent en copies statiques, les commentaires ne partent pas, et les noms de fichiers exportés se voient adjoindre un UUID (Universally Unique Identifier — identifiant unique de 128 bits) de 32 caractères qui casse les liens internes.

Il faut cependant nuancer, parce que la situation a bougé : Notion expose désormais un format « Notion-flavored Markdown » sur trois endpoints (POST /v1/pages, GET /v1/pages/:page_id/markdown, PATCH /v1/pages/:page_id/markdown), décrit comme « an extended Markdown format that supports all Notion block and rich text types ». C’est un vrai progrès pour l’automatisation. Mais ce format ajoute des balises de type XML propriétaires pour représenter callouts, toggles, colonnes, blocs synchronisés et mentions : c’est du Markdown lisible par un humain, pas du Markdown portable vers un autre outil.

Source : Notion Docs — Enhanced markdown format

Confluence est plus radical. Son format de stockage est un XML propriétaire : « Confluence storage format […] Technically, it’s XML, since the storage format doesn’t fully comply with the XHTML definition. For example, Confluence includes custom elements for macros and other features. » Les pages sont truffées d’éléments <ac:link>, <ac:image>, <ac:layout>, <ac:emoticon>. Rien de tout ça n’a d’équivalent Markdown.

Source : Atlassian — Confluence storage format

2.3 Le format au repos, outil par outil

Voici le tableau qui compte. Il ne dit pas ce que l’éditeur affiche, il dit ce que contient le stockage.

Outil	Contenu au repos	Degré	Vérifiable comment
Notion	Blocs propriétaires (cloud)	1	API `enhanced-markdown`
Confluence	XML `<ac:*>` propriétaire	1	« View storage format » dans l’UI
Outline	JSON ProseMirror imbriqué	2	Discussion officielle #7396
Docmost	`content jsonb` + `ydoc bytea`	2	Migration Postgres du dépôt
BookStack	`pages.html` + `pages.markdown`	3	Doc « Content Storage Format »
Wiki.js	Base de données, + export `.md` Git	4 (si Git)	Module de stockage Git
Wiki GitHub	Fichiers `.md` dans un dépôt Git	4	`git clone` du wiki
Obsidian	Fichiers `.md` sur disque	4	`ls` dans le coffre
SilverBullet	Fichiers `.md` sur disque	4	`ls` dans l’espace

Deux lignes de ce tableau méritent d’être justifiées, parce qu’elles contredisent la communication des éditeurs concernés.

Outline. La documentation développeur dit que les documents sont « stored in Markdown formatting ». C’est une simplification. Sur le dépôt officiel, la position assumée est que le format canonique est un JSON imbriqué, et que toute version Markdown est un export potentiellement lossy — au motif que le Markdown ne peut pas représenter tout ce qu’un éditeur moderne doit permettre. L’engagement maintenu est celui d’une sortie Markdown lossy, pas d’un stockage Markdown.

Source : outline/outline — Discussion #7396, « What storage format does/will Outline use? »

Docmost. Le site se présente comme une alternative open source à Confluence et Notion, orientée Markdown. La migration de création de la table pages est sans ambiguïté :

// apps/server/src/database/migrations/20240324T086300-pages.ts
await db.schema
  .createTable("pages")
  // …
  .addColumn("content", "jsonb", (col) => col) // arbre ProseMirror
  .addColumn("ydoc", "bytea", (col) => col) // état CRDT Yjs
  .addColumn("text_content", "text", (col) => col) // texte plat, pour la recherche
  .addColumn("tsv", sql`tsvector`, (col) => col); // index full-text Postgres
// …

Il n’y a aucune colonne Markdown. Le contenu vit en JSON ProseMirror, avec un état Yjs binaire pour l’édition concurrente et une projection en texte plat pour l’indexation. Docmost importe et exporte du Markdown ; il ne le stocke pas.

Source : docmost/docmost — migration 20240324T086300-pages.ts

Ce n’est pas un reproche : c’est le prix de l’édition collaborative temps réel, et Docmost le paie comme tout le monde. Mais si votre critère est « Markdown comme socle » au sens strict, il faut savoir que Docmost est au degré 2, pas au degré 4.

3. Le second critère : 20 personnes d’horizons variés

La composition de l’équipe est au moins aussi discriminante que le format de stockage, et pour une raison qui n’apparaît sur aucune grille de comparaison.

Une équipe de 20 personnes mêlant développeur·euses, graphiste, UI/UX, CEO, commerciaux et chefs de produit n’a pas un profil de contribution uniforme. Elle a typiquement trois populations :

Les contributeur·rices réguliers (souvent 3 à 6 personnes) : celles et ceux qui écrivent des specs, des comptes rendus, de la documentation technique. Leur confort d’écriture détermine le volume produit.
Les contributeur·rices occasionnels (le gros de l’équipe) : ils écrivent quand on le leur demande, dans un contexte précis. Le moindre frottement — une syntaxe à apprendre, un workflow Git, un formulaire de pull request — les fait renoncer et retourner à Slack ou au mail.
Les lecteur·rices : leur seul besoin est de trouver. La qualité de la recherche compte plus pour eux que toutes les fonctionnalités d’édition.

Cette répartition a une conséquence brutale : un système documentaire optimisé pour les contributeur·rices réguliers (docs-as-code, dépôt Git, revue par PR) va perdre les occasionnels, et une base documentaire sans les occasionnels perd précisément la connaissance qui n’existe nulle part ailleurs — le contexte commercial, les arbitrages produit, les conventions graphiques.

Trois exigences en découlent, et elles sont rarement énoncées :

Écriture sans apprentissage préalable. Un éditeur WYSIWYG (What You See Is What You Get) est un prérequis pour les non-techniques, même si le stockage est du Markdown.
Permissions par espace au minimum. Les grilles tarifaires commerciales, les entretiens de recrutement et les documents RH n’ont pas à être visibles par toute l’équipe. Les permissions par page sont un bonus ; les permissions par espace sont un plancher.
Une recherche qui marche vraiment. À 20 personnes et quelques centaines de pages, une recherche médiocre transforme la base documentaire en cimetière. C’est le mode de mort le plus courant d’un wiki d’entreprise.

Ces trois exigences éliminent silencieusement une bonne partie des solutions « pures Markdown ». On y revient en section 12.

4. Notion

Client : application web, applications macOS, Windows, iOS et Android. Auto-hébergement : impossible, à aucun tarif. Markdown : degré 1 (raccourcis de frappe), plus une API Markdown étendue.

Notion est la référence de l’expérience non-technique. C’est son avantage décisif sur une équipe hétérogène : un commercial ou un CEO écrit dans Notion sans formation, et les bases de données servent aussi bien de CRM léger que de suivi de recrutement ou de roadmap produit.

Tarifs

Prix affichés en euros, avec 20 % de remise en facturation annuelle :

Plan	Mensuel	Annuel	Historique	Points clés
Free	0 €	0 €	7 jours	Fichiers ≤ 5 Mo, max 10 invités
Plus	9,50 €/u	7,60 €/u	30 jours	Uploads illimités, invités illimités
Business	19,50 €/u	15,60 €/u	90 jours	SSO SAML, permissions granulaires sur bases
Enterprise	sur devis	sur devis	Illimité	Journaux d’audit, SCIM, rétention nulle côté LLM

Source : Notion — Pricing

À 20 personnes, cela donne 1 824 €/an en Plus annuel et 3 744 €/an en Business annuel. Le SSO (Single Sign-On — authentification unique) via SAML n’arrive qu’au plan Business, ce qui est le point de bascule habituel pour une entreprise qui gère déjà ses identités ailleurs.

Schémas

Notion supporte Mermaid nativement : il suffit de sélectionner Mermaid dans le sélecteur de langage d’un bloc de code, avec prévisualisation ou affichage scindé code/rendu. Pas d’Excalidraw natif — il faut passer par une intégration en iframe, ce qui signifie que le diagramme vit ailleurs que dans Notion et que son export ne suivra pas.

Source : Notion Help — Code blocks

Verdict au regard du cahier des charges

Notion échoue sur deux critères sur six : pas d’auto-hébergement, et Markdown au degré 1. Si « Markdown comme socle » est non négociable, Notion sort ici, et c’est dommage parce que c’est le meilleur outil du lot pour la population « contributeur·rices occasionnels ».

5. Confluence

Client : application web, applications de bureau et mobiles. Auto-hébergement : techniquement oui, économiquement non (voir plus bas). Markdown : degré 1, et le plus fermé du comparatif.

Vous connaissez déjà Confluence, donc allons directement aux deux points qui comptent pour cette décision.

Le mur du Data Center

Atlassian a arrêté de vendre les licences Server en 2021, et le support Server s’est éteint en février 2024. Le seul auto-hébergement possible aujourd’hui est Confluence Data Center — dont le palier de licence le plus bas est de 500 utilisateurs.

Source : Atlassian — Data Center Licensing

Pour une équipe de 20 personnes, c’est un non catégorique : vous payeriez 25 fois le nombre de sièges dont vous avez besoin. Confluence auto-hébergé n’existe pas à cette échelle. Il ne reste que le Cloud.

Tarifs Cloud

Le tarif est dégressif par palier. À 20 utilisateurs :

Plan	Prix mensuel/utilisateur	Coût annuel à 20
Free (≤ 10 utilisateurs)	0 $	hors-jeu à 20
Standard	6,05 $	~1 452 $
Premium	11,55 $	~2 772 $

La facturation annuelle fait économiser environ 17 % par rapport au mensuel.

Source : Atlassian — Confluence pricing

Markdown et schémas

Le Markdown est converti à la volée au collage dans le nouvel éditeur, mais la conversion est à sens unique : une fois collé, le contenu est en format Confluence et n’est plus éditable en Markdown. La macro Markup n’est pas supportée par le nouvel éditeur. Les tickets publics CONFCLOUD-68137 (« Full markdown support for the new editor ») et CONFCLOUD-65756 restent ouverts.

Source : Atlassian Support — Available markdown commands

Côté schémas, Confluence a des whiteboards natifs, mais avec une limite qui mérite d’être connue : 3 whiteboards actifs par utilisateur sur les plans Free et Standard, illimités seulement en Premium et Enterprise. Un whiteboard qui dépasse le quota passe en lecture seule.

Source : Atlassian Support — How whiteboards work under different Confluence plans

Pour du diagramme structuré, la voie normale reste l’app draw.io du Marketplace, facturée séparément par utilisateur — un surcoût de l’ordre de 1 à 2 $/utilisateur/mois sur la tranche 11-100 utilisateurs, à vérifier sur la fiche Marketplace au moment de l’achat car cette tarification a bougé plusieurs fois.

Verdict

Confluence Cloud Standard est l’option « personne ne se fera engueuler » : elle marche, elle est administrable, elle s’intègre à Jira. Mais elle échoue sur l’auto-hébergement à cette échelle et sur le Markdown, avec le coût de sortie le plus élevé du comparatif. Si vous en venez et que le Markdown est devenu un critère, c’est précisément le signal qu’il ne faut pas y retourner.

6. Obsidian

Client : application macOS native (plus Windows, Linux, iOS, Android). Auto-hébergement : oui, de plusieurs façons, avec des compromis distincts. Markdown : degré 4, le meilleur du comparatif.

Obsidian est le seul outil de cette liste où le contenu est littéralement un dossier de fichiers .md que vous pouvez ouvrir, grepper, versionner et scripter sans passer par personne.

La bonne nouvelle : c’est gratuit, y compris en entreprise

Le point le plus important pour un usage professionnel, et le moins connu : l’application est gratuite pour tous les usages, y compris commerciaux. « Obsidian is free for all purposes, including personal, commercial, and non-profit use. » La licence commerciale à 50 $/utilisateur/an existe toujours mais elle est optionnelle : elle sert à soutenir le développement indépendant et à figurer parmi les sponsors.

Source : Obsidian — License · Obsidian — Pricing

À 20 personnes, votre coût de licence Obsidian est donc 0 €. Ce qui se paie, c’est la synchronisation et la collaboration.

La mauvaise nouvelle : la collaboration

C’est là que ça se joue, et le détail est saisissant pour votre cas précis. Obsidian Sync permet de collaborer sur un coffre partagé, avec un maximum de 20 collaborateurs. Vous êtes exactement à la limite, ce qui veut dire qu’à la 21ᵉ embauche, ce n’est plus une question d’optimisation mais de plafond dur.

Les autres contraintes documentées :

« All collaborators must have an active Sync subscription to access a shared vault. » Chaque personne doit payer son abonnement Sync.
« Fine-grained permissions are not supported yet. All collaborators receive the same permissions as the vault owner » — seul le propriétaire peut inviter. Il n’y a donc aucun moyen de cacher les grilles tarifaires aux stagiaires ou les documents RH à l’équipe technique dans un même coffre.
Pas d’édition collaborative temps réel : pas de curseurs partagés, les modifications n’apparaissent qu’après synchronisation, et les éditions concurrentes sur un même fichier sont fusionnées au moment de la synchro.
Taille maximale de pièce jointe : 5 Mo en Standard, 200 Mo en Plus.

Source : Obsidian Help — Collaborate on a shared vault

Les tarifs Sync :

Plan	Annuel	Mensuel	Stockage	Historique	Coffres	Pièces jointes
Standard	4 $/u/mois	5 $/u/mois	1 Go	1 mois	1	5 Mo
Plus	8 $/u/mois	10 $/u/mois	10 Go (→ 100 Go)	12 mois	10	200 Mo

Source : Obsidian Sync

À 20 personnes, Sync Standard coûte 960 $/an, Sync Plus 1 920 $/an. Un Go de stockage partagé pour 20 personnes qui joignent des captures d’écran et des maquettes, c’est optimiste : prévoyez Plus.

Publish coûte à part : 8 $/site/mois en annuel, 10 $ en mensuel. C’est l’option à retenir si vous voulez exposer une partie de la base en lecture seule à un public plus large que les 20 personnes qui éditent.

Combler le trou collaboratif

Trois voies existent pour dépasser les limites de Sync, et il faut les distinguer nettement.

Relay ajoute le multijoueur temps réel à Obsidian, avec curseurs partagés, CRDT, et fonctionnement hors ligne. Le plan gratuit couvre 3 utilisateurs et 2 appareils par utilisateur. Starter à 6 $/u/mois débloque le SSO et le RBAC (Role-Based Access Control — contrôle d’accès par rôles), Premium à 18 $/u/mois va plus loin. Et surtout : le serveur Relay est auto-hébergeable, avec possibilité de fournir votre propre stockage compatible S3.

Source : Relay — Pricing · Relay Docs

C’est la combinaison la plus intéressante du comparatif pour qui veut du Markdown au degré 4 et de la collaboration : Obsidian gratuit + Relay auto-hébergé, ce qui donne 0 € de licence et le contrôle du serveur.

Self-hosted LiveSync parle directement le protocole de réplication CouchDB. C’est gratuit et robuste pour du multi-appareils, mais la pratique recommandée est une base par utilisateur (obsidiandb_alice, obsidiandb_bob), ce qui en dit long : c’est un outil de synchronisation personnelle multi-appareils, pas un outil de collaboration d’équipe. Il est par ailleurs incompatible avec Obsidian Sync officiel — il faut choisir.

Source : vrtmrz/obsidian-livesync

Git, enfin. Techniquement irréprochable, socialement irréaliste : demander à un commercial de résoudre un conflit de rebase est un plan qui échoue à la première occurrence.

Schémas : le meilleur du comparatif

Le plugin Excalidraw d’Obsidian est le seul cas où un schéma Excalidraw reste dans votre système Markdown. Depuis la version 1.2.0, les dessins sont stockés en .excalidraw.md : du JSON Excalidraw compressé en LZ-String, encapsulé dans un bloc de code Markdown. La compression sert à réduire la taille du fichier et à éviter que le JSON pollue les résultats de recherche d’Obsidian.

Source : zsviczian/obsidian-excalidraw-plugin

Vous avez donc, dans un seul dossier de fichiers texte : vos notes en Markdown, vos diagrammes Mermaid en blocs de code, vos schémas Excalidraw en .excalidraw.md, et le Canvas natif d’Obsidian au format JSON Canvas. C’est ce qu’on peut obtenir de plus proche de « tout mon savoir dans un dossier ».

Verdict

Obsidian coche Markdown (degré 4), client macOS, schémas et Excalidraw, coût de licence nul et auto-hébergement. Il échoue sur les permissions par espace, qui sont un plancher pour une équipe où tout le monde ne doit pas tout voir, et il bute exactement sur votre effectif avec la limite de 20 collaborateurs.

C’est un excellent outil pour la strate des contributeur·rices réguliers, et un mauvais outil pour être le système documentaire d’une entreprise de 20 personnes aux profils mélangés. Cette distinction est la clé de la recommandation finale.

7. Les Wiki GitHub

Client : web uniquement (plus git clone en local). Auto-hébergement : seulement via GitHub Enterprise Server. Markdown : degré 4.

Vous ne les avez jamais utilisés, donc voici l’essentiel sans détour : c’est gratuit si vous êtes déjà sur GitHub, c’est du Markdown dans un dépôt Git, et ça ne convient pas à votre équipe. Les raisons sont documentées.

Permissions au niveau du dépôt, point final. Par défaut, seules les personnes ayant un accès en écriture peuvent éditer. Sur un dépôt public, on peut ouvrir l’édition à tout GitHub. Entre les deux, rien : pas de permission par page, pas d’espace privé pour les documents RH.

Wikis privés = plan payant. Les wikis sur dépôts privés nécessitent GitHub Pro, Team, Enterprise Cloud ou Enterprise Server. GitHub Team est à 4 $/utilisateur/mois, soit 960 $/an à 20 personnes — mais si vous avez déjà GitHub Team pour le code, le wiki est inclus, à coût marginal nul.

Source : GitHub Docs — GitHub’s plans · GitHub Pricing

Limite souple de 5 000 fichiers par wiki, au-delà de laquelle des pages peuvent devenir inaccessibles.

Non indexé par les moteurs de recherche, sauf pour les wikis ayant 500 étoiles ou plus et dont l’édition publique est désactivée. GitHub recommande GitHub Pages si l’indexation compte. Ce point n’a été documenté qu’à partir d’avril 2021, alors que le blocage par robots.txt existait depuis 2012.

Source : GitHub Docs — About wikis

À quoi cela s’ajoute, sans être documenté comme une limitation : pas d’éditeur WYSIWYG digne de ce nom, pas d’édition temps réel, et une recherche interne faible. Les trois exigences de la section 3 sont manquées, dans l’ordre.

Verdict : parfait pour documenter un projet à destination de gens qui vivent déjà dans GitHub. Inadapté comme base de connaissances transverse d’une entreprise incluant des commerciaux et un CEO. À noter que Mermaid est rendu nativement dans le Markdown GitHub, ce qui reste un vrai atout pour la documentation technique.

8. Docmost

Client : web (auto-hébergé ou cloud). Auto-hébergement : oui, c’est le mode principal. Markdown : degré 2 (import/export), voir section 2.3. Licence : AGPL-3.0.

Docmost est le candidat le plus récent et, sur le papier, le plus proche de ce que vous cherchez : une alternative auto-hébergeable à Confluence et Notion, avec édition collaborative temps réel et des schémas natifs.

Les métriques de santé du projet sont solides : AGPL-3.0, environ 21 600 étoiles sur GitHub, version v0.96.0 publiée le 8 septembre 2026, avec des commits quotidiens. Le numéro de version reste sous 1.0, ce qui est à prendre pour ce que c’est : le projet est jeune (2024) et assume encore des évolutions.

Source : docmost/docmost

Les schémas, son point fort

Docmost intègre trois outils de diagramme, ce qui en fait le mieux équipé du comparatif :

draw.io pour les organigrammes, UML et diagrammes réseau ;
Excalidraw pour le croquis à main levée et le whiteboarding rapide ;
Mermaid pour les diagrammes en syntaxe texte.

Aucune app payante, aucun service externe à câbler.

Source : Docmost

Ce qui est gratuit et ce qui ne l’est pas

C’est le point à regarder de près, parce que la frontière tombe pile sur une de vos exigences.

Édition	Prix	Inclus
Community	0 €	Édition temps réel, espaces, recherche, diagrammes
Business	6 $/siège/mois annuel, min. 10 sièges	SSO (SAML 2.0 / OIDC / LDAP), permissions granulaires par page, IA & MCP, importeur Confluence
Enterprise	sur devis	SCIM, journaux d’audit, SIEM

Source : Docmost — Pricing

Les permissions par page et le SSO sont derrière le plan Business. Les espaces avec contrôle d’accès par groupes existent bien dans l’édition Community, ce qui satisfait le plancher de la section 3 — mais si vous voulez verrouiller une page précise, il faut payer. À 20 sièges, Business coûte 1 440 $/an.

L’importeur Confluence, également en Business, est à considérer sérieusement si vous migrez depuis un Confluence existant : c’est probablement le poste de dépense le mieux justifié du lot, ne serait-ce que pour un an.

Verdict : le meilleur compromis fonctionnel du comparatif. Sa seule faiblesse au regard de votre cahier des charges est le degré 2 sur le Markdown — un fait vérifiable dans sa migration Postgres, pas une opinion.

9. Outline

Client : web (cloud ou auto-hébergé). Auto-hébergement : oui, mais avec une licence à lire. Markdown : degré 2. Licence : BSL 1.1 — attention.

Outline a la meilleure expérience d’édition du lot open source : environ 40 500 étoiles, v1.10.0 en septembre 2026, et un éditeur ProseMirror très abouti.

La licence, avant tout le reste

Outline n’est pas open source au sens de l’OSI (Open Source Initiative). C’est une BSL 1.1 (Business Source License) :

Change Date : 2030-09-01, après quoi la version concernée passe sous Apache License 2.0.
Restriction d’usage : « you may not use the Licensed Work for a Document Service », un Document Service étant défini comme une offre commerciale donnant à des tiers accès aux fonctionnalités via des équipes et des documents qu’ils contrôlent.

Source : outline/outline — LICENSE

Traduction pour votre cas : héberger Outline pour votre propre équipe de 20 personnes est parfaitement autorisé. La restriction ne vise que la revente du service à d’autres organisations. Il faut simplement savoir que le curseur peut bouger sur les versions futures, ce qu’une licence OSI vous garantirait.

Le tarif Cloud est le plus agressif du comparatif

Outline Cloud est facturé au forfait par tranche, pas par siège :

Plan	Prix	Taille d’équipe
Starter	10 $/mois	1-10 membres
Team	79 $/mois	11-100 membres
Business	249 $/mois	101-200 membres

Source : Outline — Pricing

À 20 personnes, vous êtes sur Team : 79 $/mois, soit 948 $/an — environ 3,95 $/utilisateur/mois. C’est moins cher que Confluence Standard, avec un meilleur éditeur, et le coût par utilisateur s’effondre si l’équipe grandit (à 50 personnes, on tombe à 1,58 $/u/mois). Trente jours d’essai, tarif annuel sur demande.

L’infra d’auto-hébergement, plus lourde qu’annoncé

C’est le point à ne pas sous-estimer. La documentation officielle liste comme minimum une URL, un DATABASE_URL, un REDIS_URL et un SECRET_KEY, ce qui implique concrètement :

PostgreSQL (version 18 dans la configuration d’exemple) ;
Redis ;
un stockage compatible S3 pour les pièces jointes — ce n’est pas optionnel, contrairement à Docmost qui accepte un stockage local ;
un fournisseur d’authentification externe : Outline n’a pas de connexion par mot de passe intégrée. Il faut un OIDC (OpenID Connect), Google Workspace, ou équivalent.

Les images Docker sont publiées mensuellement sur base Alpine, et la documentation recommande d’épingler les versions plutôt que de suivre latest.

Source : Outline Docs — Docker hosting

L’absence de login mot de passe est le vrai point de friction : ça veut dire qu’aucun déploiement Outline auto-hébergé n’est « juste un docker-compose ». Il faut d’abord régler la question de l’identité.

Les schémas dans Outline, en détail

Outline documente officiellement deux outils de diagramme, et il faut être précis parce que les deux ne fonctionnent pas du tout de la même façon.

Mermaid, en natif. Insertion par la commande slash /diagram ou en réglant le langage d’un bloc de code sur « Mermaid Diagram ». Le rendu est temps réel pendant la frappe, et on bascule entre vue code source et vue diagramme. Les types couverts sont larges : flowchart, séquence, Gantt, classe, Git, entité-relation, parcours utilisateur, quadrant, graphe XY. Détail appréciable : les packs d’icônes FontAwesome (fa-solid, fa-brands) sont utilisables dans les diagrammes.

Comme c’est un bloc de code, le diagramme est du texte. C’est le seul schéma d’Outline qui survivra proprement à un export Markdown.

Diagrams.net (draw.io), en intégration native. Insertion par le menu de bloc ou /diagram. L’éditeur diagrams.net s’ouvre, et « every time the diagram is saved it will be updated in Outline in realtime ». On rouvre un schéma existant en le sélectionnant puis en cliquant l’icône crayon — donc édition en place, pas un lien vers un service externe.

Le point qui compte pour l’archivage : « Diagrams are stored in Outline as PNGs with embedded data ». C’est exactement l’approche de BookStack — un PNG affichable partout, avec le XML draw.io embarqué pour rester ré-éditable. Vos schémas restent donc récupérables même après un export, contrairement à un diagramme qui ne vivrait que dans un service tiers.

Et l’instance diagrams.net est configurable : le plugin diagrams du dépôt existe précisément pour ça — « Configure a custom Diagrams.net installation URL for embedding diagrams », réglable dans Settings → Integrations → Diagrams.net. Si vous auto-hébergez Outline pour des raisons de confidentialité, c’est le réglage à ne pas oublier : par défaut vos schémas transitent par le diagrams.net public.

Source : Outline Docs — Diagramming · Changelog — Mermaid diagrams · plugins/diagrams/plugin.json

PlantUML, en embed non documenté. Le dépôt contient un composant shared/editor/embeds/PlantUml.tsx qui reconnaît les URL plantuml.com/.../uml/ et les réaffiche en SVG, avec même une variante dsvg pour le thème sombre. Ça marche, mais ce n’est mentionné nulle part dans la documentation de diagrammation, et surtout : le rendu est délégué à plantuml.com. Le source de votre diagramme part chez un tiers à chaque affichage. À éviter sur du contenu sensible.

Source : outline/outline — shared/editor/embeds/PlantUml.tsx

Excalidraw : non supporté. Il faut corriger une impression répandue. Il n’y a pas d’intégration Excalidraw dans Outline : aucun composant dans le registre d’embeds (Berrycast, Diagrams, Dropbox, Gist, GitLabSnippet, InVision, JSFiddle, Linkedin, Pinterest, PlantUml, Spotify, Trello, Vimeo, YouTube), aucune occurrence dans le code, et rien dans la documentation. Si Excalidraw est un critère, Outline ne le remplit pas.

Source : outline/outline — shared/editor/embeds/

Le piège des embeds génériques en auto-hébergé. Ce registre d’une quinzaine de composants est tout ce dont vous disposez nativement. Les « 20+ intégrations » annoncées passent en réalité par Iframely, un service tiers d’unfurling : le plugin iframely lit IFRAMELY_URL (par défaut https://iframe.ly) et une IFRAMELY_API_KEY optionnelle. Autrement dit, sur une instance auto-hébergée sans clé Iframely, vous n’avez que les embeds codés en dur — et pas de moyen d’embarquer un Excalidraw ou un Figma par simple collage d’URL. Iframely est auto-hébergeable, mais c’est un service de plus à opérer.

Source : outline/outline — plugins/iframely/server/env.ts

En résumé sur les schémas : Outline couvre très bien le diagramme structuré — Mermaid pour ce qui doit rester en texte, draw.io avec édition en place et stockage PNG+données pour ce qui doit être précis. Il ne couvre pas du tout le croquis à main levée. Face à Docmost, qui a les trois formats en natif, c’est le seul écart fonctionnel significatif sur ce critère.

Verdict : en cloud, c’est le meilleur rapport qualité/prix du comparatif à 20 personnes. En auto-hébergé, c’est le plus exigeant en prérequis, et la BSL demande une décision consciente. Sur les schémas, il est très bon en structuré et absent en croquis.

10. BookStack

Client : web. Auto-hébergement : oui, le plus simple du comparatif. Markdown : degré 3 — le meilleur des outils serveur. Licence : MIT.

BookStack est le candidat le plus sous-estimé de cette liste, et il mérite une attention particulière parce qu’il est le seul outil serveur à atteindre le degré 3.

Le stockage à double colonne

« Page content is primarily stored as HTML, with the html column of the pages database table. » Mais pour les pages écrites en Markdown, « the original input markdown will be stored within the markdown column of the pages table ».

Votre source Markdown est conservée telle quelle, à côté du HTML de rendu. Et le HTML produit est délibérément simple : « common basic HTML with little depth/structure complexity where possible », avec un minimum de classes personnalisées. Le standard Markdown retenu est CommonMark, avec tableaux, listes de tâches et support HTML.

Source : BookStack Docs — Content Storage Format

C’est une philosophie assumée de non-enfermement, et elle se vérifie dans le schéma — exactement le contraire du cas Docmost de la section 2.3.

Les schémas

BookStack intègre diagrams.net (draw.io). Par défaut il appelle la version en ligne, mais l’URL est configurable par un administrateur, ce qui permet de pointer vers votre propre instance diagrams.net — un point important si vous auto-hébergez pour des raisons de confidentialité, car sinon vos schémas transitent par un service tiers.

Les dessins sont enregistrés dans votre système au format PNG avec les données draw.io embarquées, ce qui les rend à la fois affichables partout et ré-éditables.

Source : BookStack Docs — Drawings & Diagrams

Pas d’Excalidraw. C’est le compromis de BookStack sur ce critère.

Ce qu’il faut savoir d’autre

Le modèle d’organisation est étagères → livres → chapitres → pages. C’est plus rigide qu’une arborescence libre, et c’est précisément pourquoi ça marche avec des non-techniques : la structure est évidente, personne ne se demande où ranger sa page.

La pile est PHP/MySQL, ce qui en fait de loin le plus léger à opérer : pas de Redis, pas de S3 obligatoire, pas de fournisseur d’identité externe requis. Licence MIT, environ 19 000 étoiles. Le développement a migré sur Codeberg, le dépôt GitHub servant désormais de miroir — un point à noter pour qui suit les releases.

Ce qui manque : l’édition collaborative temps réel. À 20 personnes, c’est une gêne réelle mais pas rédhibitoire, à condition que la granularité des pages soit fine.

Verdict : le choix rationnel si votre priorité absolue est « du Markdown conservé, une infra que je peux opérer seul, zéro coût de licence ». Le prix à payer est l’absence de temps réel et d’Excalidraw.

11. Wiki.js — et le piège de la version 3

Client : web. Auto-hébergement : oui. Markdown : degré 4 si et seulement si la synchronisation Git est activée. Licence : AGPL-3.0.

Wiki.js mérite une section parce que c’est le seul outil serveur du comparatif qui peut atteindre le degré 4, grâce à son module de stockage Git : il synchronise les pages en fichiers .md vers GitHub, GitLab, Bitbucket, Azure DevOps ou n’importe quel remote Git, avec une direction configurable, y compris bidirectionnelle, et une périodicité de synchronisation réglable (5 minutes par exemple). Les modifications faites dans le dépôt remontent dans le wiki. On peut aussi router les contenus séparément : les pages vers Git, les médias vers un bucket S3.

Source : Wiki.js Docs — Git storage

C’est la meilleure réponse technique à « je veux un wiki utilisable par tous et mes fichiers Markdown dans Git ». Il faut donc parler de ce qui coince.

L’état réel du projet

Voici ce que disent les releases du dépôt officiel, au 9 septembre 2026 :

Dernière version stable : v2.5.314, publiée le 1er mai 2026.
Dernière version publiée : 3.0.0-beta.554, le 8 septembre 2026 — une préversion.

Source : requarks/wiki — Releases

La version 3 est en développement actif — plus de 550 betas, des publications quasi quotidiennes — mais elle n’est toujours pas stable. Et la version 2, celle que vous déploieriez en production, reçoit des mises à jour espacées.

Le piège est là : si vous déployez Wiki.js aujourd’hui, vous déployez une v2 en fin de cycle, et vous vous engagez à une migration majeure vers une v3 dont la date de sortie n’est pas connue. Sur un système documentaire censé durer dix ans, c’est une dette planifiée.

À noter : l’annonce parfois lue selon laquelle « le dépôt Wiki.js n’a plus de commits depuis des mois » est factuellement fausse — l’activité est quotidienne. Le problème n’est pas l’abandon, c’est la durée du cycle de stabilisation.

Verdict : techniquement la plus élégante réponse au critère Markdown pour un outil serveur. À réserver à qui accepte consciemment le risque de migration v2 → v3.

12. Les purs Markdown : docs-as-code et SilverBullet

Pour être complet, il faut examiner l’option qui séduit toujours les équipes techniques, et expliquer pourquoi elle échoue généralement sur ce cahier des charges précis.

Le docs-as-code

Le principe : un générateur de site statique — Astro Starlight, Docusaurus, MkDocs — alimenté par un dépôt de fichiers .md, publié en CI/CD (Continuous Integration / Continuous Delivery). Degré 4 par construction, coût de licence nul, Mermaid natif, revue par pull request, et une lisibilité parfaite pour les agents IA.

Pour les non-techniques, on ajoute un CMS (Content Management System) adossé à Git : Decap CMS, son successeur moderne Sveltia CMS (réécriture légère, environ 300 Ko, éditeur riche basé sur Lexical, compatible en remplacement direct de Decap), ou un équivalent. L’interface web masque Git : on édite dans un navigateur, un commit part en arrière-plan.

Source : sveltia/sveltia-cms

Ça fonctionne. Mais trois choses manquent, et ce sont exactement les trois de la section 3 :

Pas d’édition temps réel. Deux personnes sur la même page produisent un conflit Git, qu’il faut résoudre dans une interface qui n’a pas été conçue pour ça.
Permissions grossières. Les droits sont ceux du dépôt Git. Cacher les grilles tarifaires suppose un second dépôt, donc un second site, donc deux recherches distinctes.
Recherche à construire. Il faut câbler Pagefind, Algolia ou équivalent soi-même, et le résultat est rarement au niveau d’un moteur intégré.

À quoi s’ajoute un point non technique mais décisif : la latence perçue. Écrire puis attendre un déploiement CI pour voir sa page en ligne est un frottement que les contributeur·rices occasionnels ne tolèrent pas longtemps.

Verdict : excellent pour de la documentation produit ou technique publique. Mauvais candidat comme base de connaissances interne transverse. Le bon usage est en complément, pas en remplacement.

SilverBullet

Mention pour l’honnêteté du comparatif : MIT, environ 6 000 étoiles, activité soutenue, plateforme de productivité personnelle bâtie sur du Markdown pur sur disque et scriptable en Lua. Degré 4, auto-hébergeable, et une vraie interface web d’édition — donc moins de frottement que le docs-as-code.

Source : silverbulletmd/silverbullet

Mais le positionnement affiché est la productivité personnelle. À 20 personnes avec des besoins de permissions par espace, ce n’est pas ce pour quoi l’outil est conçu. À garder en tête pour un usage individuel ou une petite équipe technique homogène.

Et les outils qui ne sont pas Markdown du tout

AFFiNE (environ 72 400 étoiles, canvas infini et documents unifiés) et Anytype sont des produits impressionnants, auto-hébergeables pour le premier. Mais leur modèle de données est fondé sur des blocs propriétaires, pas sur du Markdown. Votre critère les élimine avant même l’évaluation fonctionnelle. Même remarque pour Trilium (environ 37 800 étoiles), dont le stockage est orienté HTML.

13. Schémas : Mermaid, draw.io, Excalidraw

Ce critère mérite d’être décomposé, parce que « supporte les schémas » cache trois besoins distincts qui ne se satisfont pas avec le même outil.

Mermaid est le seul format de diagramme réellement Markdown-natif : c’est du texte dans un bloc de code. Il se diffe, se relit en pull request, se génère par un agent IA, et survit à n’importe quelle migration. Sa limite est qu’il ne fait bien que les diagrammes structurés : séquences, flux, état, ERD, Gantt.

draw.io / diagrams.net couvre le diagramme précis et durable : architecture, réseau, UML, organigramme. Le stockage est du XML, en général encapsulé dans un PNG ou un SVG pour rester affichable. C’est portable, mais ce n’est plus du Markdown.

Excalidraw ne sert pas au même usage : c’est du croquis à main levée, pour penser en réunion et documenter une intention. Son style « esquisse » est une fonctionnalité, pas un défaut — un schéma qui a l’air fini invite moins à la critique qu’un schéma qui a l’air d’un brouillon.

La règle pratique qui en découle : Mermaid par défaut pour tout ce qui doit survivre, draw.io pour ce qui doit être précis, Excalidraw pour ce qui doit être discuté. Un outil qui n’a que l’un des trois vous forcera à en sortir.

Outil	Mermaid	draw.io	Excalidraw	Stockage du schéma
Obsidian	✅ natif	via plugin	✅ plugin, `.excalidraw.md`	Dans le coffre Markdown
Docmost	✅ natif	✅ natif	✅ natif	Attaché à la page (JSON)
BookStack	✗	✅ natif, instance configurable	✗	PNG + données drawio
Notion	✅ bloc de code	✗	iframe externe	Bloc propriétaire / hors Notion
Confluence	via app	via app payante	✗	Pièce jointe / whiteboard
Confluence Premium	via app	via app payante	Whiteboards natifs (illimités)	Format whiteboard propriétaire
Wiki GitHub	✅ natif	✗	✗	Bloc de code Markdown
Outline	✅ natif	✅ natif, instance configurable	✗ non supporté	PNG + données drawio
Docs-as-code	✅ natif	fichier committé	fichier committé	Fichiers dans Git

Outline mérite une précision, parce que sa page tarifaire annonce « 20+ integrations » et que ça induit en erreur sur ce critère : il a Mermaid et draw.io en natif, avec édition en place et stockage en PNG à données embarquées, mais aucune intégration Excalidraw — ni composant dans le registre d’embeds, ni mention dans la documentation. Voir la section 9 pour le détail.

Deux lignes se détachent : Obsidian est le seul où un schéma Excalidraw reste dans le système Markdown, et Docmost est le seul serveur à couvrir les trois formats sans app tierce ni service externe.

À noter qu’Excalidraw lui-même est sous licence MIT et auto-hébergeable, et qu’une offre Excalidraw+ auto-hébergée existe pour les organisations à contraintes de conformité. Vous pouvez donc l’utiliser à côté de n’importe quel outil de cette liste, au prix d’un système de plus à opérer et d’une recherche qui ne couvrira pas vos schémas.

Source : Excalidraw+ — Self-hosting

14. Coût total à 20 personnes

Voici la comparaison sur trois ans, licences comprises. Les montants sont convertis à titre indicatif ; les devises d’origine sont celles des pages de tarification citées.

Solution	Licence/an à 20	Infra/an	Total 3 ans	Markdown
Obsidian + Relay auto-hébergé	0 €	~200 €	~600 €	Degré 4
BookStack auto-hébergé	0 €	~150 €	~450 €	Degré 3
Docmost Community auto-hébergé	0 €	~250 €	~750 €	Degré 2
Wiki.js v2 auto-hébergé	0 €	~200 €	~600 €	Degré 4 (Git)
Wiki GitHub (si GitHub Team déjà payé)	0 € marginal	0 €	0 €	Degré 4
Wiki GitHub (GitHub Team dédié)	960 $	0 €	~2 880 $	Degré 4
Obsidian Sync Standard	960 $	0 €	~2 880 $	Degré 4
Outline Cloud Team	948 $	0 €	~2 844 $	Degré 2
Obsidian Sync Plus	1 920 $	0 €	~5 760 $	Degré 4
Docmost Business auto-hébergé	1 440 $	~250 €	~5 070 $	Degré 2
Confluence Cloud Standard	~1 452 $	0 €	~4 356 $	Degré 1
Notion Plus (annuel)	1 824 €	0 €	~5 472 €	Degré 1
Confluence Cloud Premium	~2 772 $	0 €	~8 316 $	Degré 1
Notion Business (annuel)	3 744 €	0 €	~11 232 €	Degré 1
Confluence Data Center	palier 500 users	—	hors-jeu	Degré 1

Le poste « infra/an » est un ordre de grandeur assumé : un VPS (Virtual Private Server) de 2 vCPU et 4 Go de RAM chez un hébergeur européen se situe dans une fourchette de quelques euros à une vingtaine d’euros par mois selon le fournisseur et la génération, à quoi s’ajoutent le stockage objet et les sauvegardes. Je ne donne pas de chiffre au centime parce que ces grilles changent plusieurs fois par an — vérifiez au moment de l’achat.

Trois observations sur ce tableau :

L’écart va de 1 à 25. Entre BookStack auto-hébergé (~450 € sur trois ans) et Notion Business (~11 200 €), il y a un facteur 25. Sur trois ans et 20 personnes, le choix du système documentaire est une décision budgétaire sérieuse, pas un détail d’outillage.

Outline Cloud est l’anomalie tarifaire du comparatif. À 79 $/mois quel que soit l’effectif entre 11 et 100 personnes, il coûte moins que Confluence Standard tout en offrant un meilleur éditeur, et son coût par tête baisse à chaque embauche. Si l’auto-hébergement n’était pas un critère, ce serait le choix par défaut évident.

Le coût de licence n’est pas le coût total. Une ligne à 0 € de licence suppose que quelqu’un opère le service : mises à jour, sauvegardes, restauration, TLS, surveillance. Ce n’est pas gratuit, c’est juste payé en temps plutôt qu’en facture. Comptez de quelques heures par an pour BookStack à un demi-jour par trimestre pour une pile Postgres + Redis + S3.

15. Auto-hébergement : l’infrastructure concrète

Puisque c’est un critère explicite, voici ce que chaque option demande réellement. Les trois profils d’infrastructure sont très différents.

Profil léger — BookStack

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Reverse     │────▶│  BookStack   │────▶│    MySQL     │
│  proxy (TLS) │     │  (PHP-FPM)   │     │  / MariaDB   │
└──────────────┘     └──────────────┘     └──────────────┘
                            │
                            ▼
                     ┌──────────────┐
                     │  Volume      │
                     │  (uploads)   │
                     └──────────────┘

Deux services, un volume. Pas de Redis, pas de S3 obligatoire, pas de fournisseur d’identité externe. C’est le seul de la liste qu’on peut raisonnablement opérer sans être à l’aise avec Docker.

Profil standard — Docmost

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Reverse     │────▶│   Docmost    │────▶│  PostgreSQL  │
│  proxy (TLS) │     │  (Node.js)   │     └──────────────┘
└──────────────┘     └──────┬───────┘
                            │            ┌──────────────┐
                            ├───────────▶│    Redis     │
                            │            └──────────────┘
                            │            ┌──────────────┐
                            └───────────▶│ Local ou S3  │
                                         └──────────────┘

PostgreSQL pour les données persistantes, Redis pour la collaboration temps réel, le cache et les tâches de fond — les deux sont requis dans le docker-compose standard. Le stockage est local par défaut (STORAGE_DRIVER=local) et peut basculer sur S3 via les variables AWS_S3_*. C’est ce qui rend Docmost plus accessible qu’Outline : on peut démarrer sans bucket.

Le APP_SECRET doit impérativement être remplacé par une valeur aléatoire avant le premier démarrage. Comptez 2 vCPU et 4 Go de RAM pour une équipe de 20 avec de l’édition concurrente ; 512 Mo suffisent techniquement mais pas confortablement.

Source : Docmost — Self-hosting

Profil exigeant — Outline

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Reverse     │────▶│   Outline    │────▶│ PostgreSQL18 │
│  proxy (TLS) │     │              │     └──────────────┘
└──────────────┘     └──────┬───────┘
                            │            ┌──────────────┐
                            ├───────────▶│    Redis     │
                            │            └──────────────┘
                            │            ┌──────────────┐
                            ├───────────▶│  S3 (REQUIS) │
                            │            └──────────────┘
                            │            ┌──────────────┐
                            └───────────▶│  OIDC / SSO  │
                                         │   (REQUIS)   │
                                         └──────────────┘

Les deux cases marquées REQUIS font toute la différence : le stockage compatible S3 n’est pas optionnel, et Outline n’a pas de connexion par mot de passe intégrée — il faut un fournisseur d’authentification externe. Si vous n’avez pas déjà un OIDC en place, l’installation d’Outline commence par l’installation d’un serveur d’identité.

Ce que personne ne met dans le docker-compose

Trois points valent d’être posés explicitement, parce que c’est là que les auto-hébergements échouent :

La sauvegarde doit être testée, pas seulement configurée. Un pg_dump quotidien n’est une sauvegarde qu’à partir du moment où vous avez restauré une fois sur une instance vierge. Pour Docmost et Outline, la sauvegarde a deux moitiés : le dump PostgreSQL et le bucket de pièces jointes. Restaurer l’une sans l’autre donne une base documentaire pleine d’images cassées.

Redis n’est pas qu’un cache pour Docmost et Outline. Il porte la collaboration temps réel. Perdre Redis en cours de session, c’est perdre les modifications non encore persistées.

L’accès distant. Un wiki interne doit être joignable par un commercial en déplacement. Cela veut dire soit une exposition publique avec TLS et authentification solide, soit un VPN que 20 personnes devront réellement utiliser. La seconde option coûte moins en sécurité et beaucoup plus en adoption.

16. Pièges et limitations connues

Le plafond de 20 collaborateurs d’Obsidian Sync

Symptôme : impossible d’ajouter un 21ᵉ membre à un coffre partagé. Cause : limite documentée du produit, pas un quota commercial négociable. Solution : partitionner en plusieurs coffres — ce qui casse les liens inter-notes, la recherche globale et le graphe, c’est-à-dire tout l’intérêt d’Obsidian. Ou passer par Relay, qui n’a pas cette limite.

Vous êtes pile sur la limite. Ce n’est pas un problème aujourd’hui, c’en sera un à la prochaine embauche.

Source : Obsidian Help — Collaborate on a shared vault

L’absence de permissions fines dans un coffre Obsidian partagé

Symptôme : tout le monde voit tout, et tout le monde peut tout modifier. Cause : « All collaborators receive the same permissions as the vault owner ». Conséquence concrète : les grilles tarifaires, les documents RH et les retours d’entretien ne peuvent pas cohabiter avec la documentation technique. Solution : un second coffre pour le confidentiel, avec la fragmentation que cela implique.

Le palier 500 utilisateurs de Confluence Data Center

Symptôme : un devis d’auto-hébergement disproportionné. Cause : Data Center est facturé par tranches d’utilisateurs à plat, et la plus basse est 500. Solution : aucune. Confluence auto-hébergé n’existe pas à 20 personnes. Server est mort en février 2024.

La conversion Markdown à sens unique de Confluence

Symptôme : vous collez du Markdown, ça marche ; vous rouvrez la page, vous ne pouvez plus l’éditer en Markdown. Cause : la conversion au collage écrit du format Confluence, et le nouvel éditeur ne supporte plus la macro Markup. Solution : une app Marketplace dédiée, ou renoncer.

Les 5 000 fichiers des Wiki GitHub

Symptôme : des pages deviennent inaccessibles sur un gros wiki. Cause : limite souple de 5 000 fichiers par wiki. Solution : GitHub Pages, comme le recommande GitHub lui-même.

La migration v2 → v3 de Wiki.js

Symptôme : vous déployez la v2.5.314 en production alors que la v3 est en beta depuis des années. Cause : cycle de stabilisation très long — plus de 550 betas publiées. Solution : activer la synchronisation Git dès le premier jour. Vos fichiers .md seront dans un dépôt, ce qui transforme une migration risquée en simple réimport. C’est aussi, accessoirement, la meilleure raison d’activer ce module.

Le stockage JSON de Docmost, quand on croyait acheter du Markdown

Symptôme : vous choisissez Docmost pour son positionnement Markdown, puis vous découvrez que la base contient du JSON ProseMirror. Cause : l’édition collaborative temps réel impose un arbre de nœuds typés et un état CRDT. Solution : accepter le degré 2 et automatiser un export Markdown périodique vers un dépôt Git. Ça ne remplace pas un stockage Markdown, mais ça vous garantit une sortie de secours toujours fraîche, sans dépendre de la bonne volonté de l’éditeur au moment où vous voudrez partir.

Cette dernière solution vaut pour Outline aussi, et elle est le meilleur compromis disponible si vous voulez à la fois le temps réel et une assurance sur la portabilité.

17. Recommandation

Le cahier des charges contient une contradiction — Markdown au repos et collaboration confortable pour 20 personnes non techniques — donc il n’y a pas de réponse unique. Il y a trois réponses cohérentes, selon ce que vous décidez de sacrifier.

Si le Markdown au repos est vraiment non négociable

Obsidian pour l’équipe technique, Relay auto-hébergé pour la collaboration, BookStack ou Docmost pour la base transverse.

Ce n’est pas une esquive : c’est la reconnaissance que vos trois populations de la section 3 n’ont pas le même besoin. Les contributeur·rices réguliers gardent Obsidian, avec le degré 4, Excalidraw en .excalidraw.md, et leurs fichiers sur disque. Le reste de l’équipe a un wiki avec un WYSIWYG, des espaces cloisonnés et une recherche correcte.

Coût : 0 € de licence, un VPS, et la discipline d’un export périodique dans un sens ou dans l’autre. C’est la seule configuration qui satisfait littéralement tous vos critères, au prix d’avoir deux systèmes.

Si vous voulez un seul système auto-hébergé

Docmost Community, avec un export Markdown automatisé vers Git.

C’est le meilleur compromis fonctionnel du comparatif : édition temps réel, espaces avec permissions par groupes, et surtout les trois formats de schéma — draw.io, Excalidraw, Mermaid — nativement, sans app tierce. Une infra standard Postgres + Redis, avec stockage local acceptable pour démarrer.

Vous descendez au degré 2 sur le Markdown. L’export automatisé vers Git est la mesure qui rend ce compromis acceptable, et je la considérerais comme obligatoire, pas optionnelle.

Passez en Business (1 440 $/an) uniquement si vous avez besoin du SSO ou des permissions par page — ou pour un an si vous migrez depuis Confluence, pour l’importeur.

L’alternative sérieuse à considérer en parallèle est BookStack : degré 3 plutôt que 2, l’infra la plus simple à opérer, licence MIT plutôt qu’AGPL. Vous perdez l’édition temps réel et Excalidraw. Si votre équipe écrit surtout des pages distinctes plutôt que de co-rédiger, ce compromis est meilleur qu’il n’y paraît, et c’est le seul outil serveur qui conserve votre source Markdown telle quelle.

Si l’auto-hébergement était en fait négociable

Outline Cloud Team, à 79 $/mois.

Il faut le dire clairement parce que les chiffres sont sans appel : à 20 personnes, Outline Cloud coûte moins cher que Confluence Standard, offre un meilleur éditeur, et vous n’opérez rien. Le tarif au forfait par tranche signifie que vous pouvez recruter jusqu’à 100 personnes sans que la facture bouge.

Vous acceptez le degré 2 et une licence BSL. Vous économisez tout le temps d’exploitation de la section 15 — qui est le coût que les comparatifs sous-estiment systématiquement.

Ce que je ne recommanderais pas

Notion, malgré sa qualité, parce qu’il échoue sur deux critères explicites (pas d’auto-hébergement, degré 1) et qu’il a le coût de sortie le plus élevé avec Confluence.

Retourner sur Confluence, parce que l’auto-hébergement y est inaccessible à votre échelle et que le format XML <ac:*> est l’antithèse exacte de votre critère principal.

Les Wiki GitHub comme base transverse : les permissions au niveau du dépôt et l’absence de WYSIWYG perdront vos commerciaux et votre CEO en trois semaines. Excellents, en revanche, pour la documentation d’un projet.

Wiki.js, sauf si vous acceptez sciemment la migration v2 → v3.

Ce que je vérifierais avant de signer

Trois tests concrets, à faire avant de décider — ils coûtent une journée et évitent trois ans de regret :

Le test de sortie. Exportez 20 pages représentatives, avec un tableau, un schéma, une image et un lien interne. Réimportez-les ailleurs. Ce qui casse à ce moment-là cassera aussi le jour de la migration.
Le test du contributeur occasionnel. Demandez à un commercial d’écrire une page sans aide et sans documentation préalable. Chronométrez. Si ça dépasse dix minutes, l’outil ne sera pas adopté par les deux tiers de votre équipe.
Le test de recherche. Chargez la base avec un corpus réaliste — pas trois pages de démonstration — et cherchez un terme que vous savez présent dans une page dont vous avez oublié le titre. C’est le cas d’usage réel d’un wiki, et celui sur lequel ils meurent.