Outils

OpenKnowledge : test terrain d’un wiki Markdown IA

14 juillet 2026 Mehdi 18:10
OpenKnowledge : test terrain d’un wiki Markdown IA

OpenKnowledge est un éditeur Markdown local qui veut transformer un dossier de notes en wiki lisible par les humains et exploitable par des agents IA. Après un vrai essai sur une mini base de connaissances sécu/DevOps, mon verdict est simple : ça vaut le coup d’être essayé si vous vivez déjà dans Markdown, mais ce n’est pas encore l’outil le plus fluide pour tout le monde.

OpenKnowledge, c’est quoi ?

OpenKnowledge se présente comme un mélange entre Notion, VS Code et un wiki pour agents IA. L’idée n’est pas de remplacer Git ou vos fichiers Markdown, mais de poser une interface propre au-dessus d’un dossier existant.

Concrètement, le produit sait :

  • ouvrir un dossier contenant des fichiers Markdown ou MDX,
  • afficher une interface web locale avec explorateur de fichiers,
  • créer des starter packs, par exemple une base de connaissances en trois couches,
  • préparer des intégrations MCP et des skills pour Claude, Codex, Cursor, opencode et d’autres agents,
  • garder les contenus sous forme de fichiers locaux, donc versionnables avec Git.

C’est important : OpenKnowledge n’est pas un SaaS de notes. Dans mon test, tout est resté dans un dossier local. C’est plutôt rassurant pour un usage freelance, client, audit ou documentation d’infra.

Élément Détail testé
Produit OpenKnowledge
Version npm 0.29.1
Dépôt GitHub inkeep/open-knowledge
Commit inspecté bd0757e4
Runtime requis Node.js 24 ou plus
Interface Web locale, plus app macOS annoncée
Données Fichiers Markdown locaux
Licence GPL-3.0-or-later

Installation de OpenKnowledge

J’ai commencé par cloner le dépôt GitHub dans /tmp, lire le README, les manifestes package.json et la structure des packages. Le projet est un monorepo Bun avec des packages pour le CLI, l’app React, le serveur, le coeur et une brique native.

Les commandes de base documentées sont les suivantes :

npm install -g @inkeep/open-knowledge
cd votre-projet
ok init
ok start --open

Dans mon environnement de test, Node.js 20 était installé par défaut, alors que le projet demande Node.js 24. J’ai donc installé Node.js 24 dans un répertoire temporaire, puis installé le paquet npm OpenKnowledge 0.29.1 pour lancer le produit.

J’ai aussi tenté un build depuis le clone source. Le coeur, le serveur et l’app web ont bien compilé avec Bun, une fois Node 24 disponible. Le build complet du CLI depuis le dépôt a bloqué sur packages/native-config, car la brique native demande Rust et cargo n’était pas présent dans le conteneur. Ce n’est pas un bug fonctionnel de l’application, mais c’est une friction réelle pour contribuer ou reconstruire tout le paquet depuis zéro.

Pour respecter le cas IA demandé, j’ai exporté les variables de proxy OpenAI/OpenRouter avant le lancement :

export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy

Dans ce test précis, OpenKnowledge n’a pas eu besoin d’appeler directement un LLM pour afficher le wiki. Son angle IA est surtout dans les intégrations MCP, les skills et le fait de rendre le dossier compréhensible par des agents.

OpenKnowledge à l’usage

Pour éviter un test vide, j’ai créé une mini base de connaissances de freelance sécu/DevOps :

  • un README de wiki SOC,
  • une note d’incident sur des alertes Prometheus trop bruyantes,
  • un runbook de triage Prometheus avec un lien wiki vers l’incident.

Ensuite, j’ai initialisé OpenKnowledge sans écrire de config MCP globale :

ok --cwd /tmp/ok-case init --no-mcp --local-only --json

La sortie JSON a confirmé que le projet avait été détecté, que trois fichiers de contenu existaient déjà et que l’enregistrement MCP avait été sauté :

{
  "projectRoot": "/tmp/ok-case",
  "contentDir": ".",
  "contentFileCount": 3,
  "mcpAction": "skipped-flag"
}

Puis j’ai ajouté le starter pack knowledge-base :

ok --cwd /tmp/ok-case seed --pack knowledge-base --root knowledge -y

Ce que ça a produit : 17 entrées de starter pack, un fichier knowledge/log.md, des dossiers knowledge/articles, knowledge/research, knowledge/external-sources, des fichiers de frontmatter et un skill OpenKnowledge local. Le preview a ensuite vu 5 fichiers Markdown suivis par le watcher, dont mes notes et le starter pack.

ok --cwd /tmp/ok-case preview

Sortie utile :

Content:
  Found 5 markdown files in ./
  Sample: .ok/skills/open-knowledge-pack-knowledge-base/SKILL.md, README.md,
  incidents/2026-07-11-alerting.md, knowledge/log.md,
  runbooks/prometheus-triage.md

J’ai ensuite lancé le serveur local :

ok --cwd /tmp/ok-case start --host 127.0.0.1 --port 5337 --ui-port 5338 --mode browser

L’interface web a bien démarré avec un éditeur sur http://127.0.0.1:5338 et une API sur http://127.0.0.1:5337. Dans le navigateur headless, OpenKnowledge a affiché le workspace ok-case, les templates du starter pack, le dossier incidents, mon incident Prometheus et la recherche globale.

Le point le plus convaincant du test : la recherche a retrouvé mes fichiers Markdown et affiché des extraits lisibles. Le runbook et l’incident sont restés de simples fichiers, mais l’interface les rend navigables sans imposer une base de données externe.

Ce que j’aime dans OpenKnowledge

D’abord, le produit respecte le réflexe Git. Les contenus restent en Markdown, avec une structure compréhensible. Pour de la documentation d’infra, des procédures client, des runbooks ou des notes de veille, c’est un vrai plus.

Ensuite, le starter pack knowledge-base donne un cadre intéressant. Il pousse à séparer les sources brutes, les recherches et les articles finalisés. C’est exactement le genre de discipline qui manque dans beaucoup de wikis internes.

J’aime aussi le positionnement agent-friendly. Les fichiers .ok, les skills et le MCP donnent une direction claire : un humain écrit et relit dans une interface propre, un agent peut chercher, créer, consolider ou manipuler les notes avec des conventions explicites.

Enfin, l’interface est agréable. Le premier écran n’est pas une usine à gaz, la recherche est rapide dans mon petit cas, et les templates sont visibles dès l’accueil.

Les limites de OpenKnowledge

La première limite, c’est l’installation pour les profils non développeurs. Le README annonce Node.js 24, Git et un CLI. Pour le grand public, c’est déjà une marche. Sur macOS, l’app desktop peut réduire cette friction, mais je ne l’ai pas testée dans ce conteneur Linux.

La deuxième limite, c’est le build source complet. Le monorepo se comprend bien, mais reconstruire tout le paquet demande Bun, Node 24 et, pour la partie native, Rust. En environnement CI ou conteneur minimal, il faut préparer le terrain.

Troisième limite : l’IA n’est pas magique au premier lancement. OpenKnowledge prépare très bien le terrain pour les agents, mais si vous cherchez un bouton qui génère automatiquement toute votre documentation, ce n’est pas ce que j’ai observé ici. Le produit est plutôt une bonne couche d’orchestration documentaire.

Dernier point : l’initialisation sans MCP a bien sauté l’enregistrement MCP, mais le seed a quand même installé des skills dans le projet pour plusieurs agents. Ce n’est pas dangereux dans mon test, mais j’aimerais des options encore plus explicites pour les environnements verrouillés.

Est-ce que OpenKnowledge marche vraiment ?

Oui, pour le coeur de sa promesse : ouvrir un dossier Markdown local, l’initialiser, ajouter une structure de knowledge base, lancer une UI web et naviguer dans les notes.

Ce que j’ai vérifié réellement :

  • installation du paquet npm 0.29.1 sous Node 24,
  • inspection et build partiel du dépôt source,
  • initialisation d’un projet Markdown local,
  • génération du starter pack knowledge-base,
  • lancement du serveur web local,
  • affichage du workspace dans Chromium headless,
  • recherche d’un terme métier, ici Prometheus, avec résultats pertinents.

Ce que je n’ai pas validé de bout en bout : l’app macOS, le partage d’équipe via GitHub, l’édition collaborative multi-utilisateur et une boucle complète avec un agent externe qui appelle les outils MCP pour réécrire le wiki.

Faut-il adopter OpenKnowledge ?

Mon verdict : essayer, surtout si vous avez déjà une culture Markdown et Git.

Pour un freelance sécu/DevOps, OpenKnowledge peut servir à structurer des runbooks, des notes d’audit, des décisions d’architecture, des journaux d’incident et de la veille technique. Le format local est un vrai avantage quand les contenus sont sensibles.

Je ne le recommanderais pas encore comme remplacement immédiat de Notion pour une équipe non technique. En revanche, pour une équipe d’ingénieurs ou un indépendant qui veut un wiki local, lisible par des agents, et versionnable, c’est prometteur.

Verdict final : adopter en labo ou sur un projet perso, essayer sur un petit wiki client, attendre encore avant de basculer toute une base documentaire critique.

FAQ

OpenKnowledge remplace-t-il Obsidian ?

Pas exactement. OpenKnowledge vise davantage les wikis techniques et les workflows avec agents IA, alors qu’Obsidian reste très fort pour la prise de notes personnelle et les plugins.

OpenKnowledge nécessite-t-il une clé OpenAI ?

Pas pour ouvrir et naviguer dans un wiki Markdown local. Les fonctions orientées agents peuvent dépendre d’un outil externe et d’un modèle, mais le coeur testé ici fonctionne sans appel LLM direct.

OpenKnowledge est-il prêt pour une équipe DevOps ?

Oui pour un essai contrôlé sur des runbooks ou une base de connaissances projet. Pour un déploiement large, je vérifierais d’abord les règles Git, les droits d’accès, les sauvegardes et les workflows MCP utilisés par les agents.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *