Test SiYuan : alternative block-based à Obsidian pour devs

Examen SiYuan : une alternative Obsidian basée sur des blocs pour les développeurs

J'ai cassé mon coffre-fort Obsidian un mercredi après-midi, et la façon dont il s'est cassé est la raison pour laquelle je suis allé chercher autre chose.

J'étais en train de refactoriser deux années de notes. Un dossier appelé bug-logs/ comptait désormais 312 fichiers et je souhaitais le diviser par projet : bug-logs/laravel/, bug-logs/react/, bug-logs/infra/. Nettoyage standard. Le genre de chose que fait tout développeur lorsqu'un dossier plat se transforme en marécage.

J'ai déplacé 47 fichiers en un seul lot, j'ai regardé Obsidian les renommer et je suis allé préparer du café. À mon retour, j'ai ouvert un runbook que j'avais écrit six mois plus tôt : un document de récupération étape par étape pour un incident de production que je ne voulais jamais répéter. La troisième étape était liée à un journal de bugs appelé redis-eviction-storm-debug.md. Le lien rendu sous forme de texte brut. Le clic n'a rien fait.

J'ai vérifié le fichier. Cela existait. C'était dans le nouveau dossier bug-logs/infra/. Le bloc auquel j'avais fait référence – la section spécifique expliquant la configuration d'expulsion qui a déclenché la cascade – était là, intact. Mais le lien était mort car le chemin avait changé et la référence de bloc était ancrée à une combinaison chemin plus en-tête qui ne correspondait plus.

C’est à ce moment-là que j’ai réalisé que mon deuxième cerveau avait un problème structurel. Ce n'est pas exactement la faute de Obsidian. Fichiers Markdown plus chemins du système de fichiers plus liens de bloc ancrés dans un titre - tel est le contrat. Lorsque vous déplacez des choses, vous acceptez que certaines références se brisent. Pour un journal personnel, très bien. Pour la documentation sur laquelle je compte à 2 heures du matin lors d'un incident, ce n'est pas bien.

J'ai donc commencé à regarder au-delà de Obsidian. La chose que j'ai testée ensuite était SiYuan, un outil de gestion des connaissances open source et local qui exécute la version 3.6.5 à compter du 21 avril 2026. Il bloque les références différemment : chaque bloc a un identifiant permanent qui survit aux déplacements, aux renommages, aux refactorisations, jusqu'à la suppression. Cela ressemblait exactement à ce dont mon runbook cassé avait besoin.

C’est l’écriture honnête. Ce qui a fonctionné. Ce qui m'a poussé à appuyer sur le bouton de retour. Qu'il mérite un emplacement permanent dans la pile d'un développeur en 2026, ou si la comparaison SiYuan vs Obsidian revient toujours à Obsidian pour la plupart des gens. Spoiler : la réponse dépend du type de notes que vous conservez réellement.

Pourquoi j'ai dépassé Obsidian en premier lieu

Obsidian m'a servi pendant quatre ans. Je ne suis pas là pour l'enterrer. Les plus de 230 publications sur ce site font constamment référence à Obsidian, car pour le cas d'utilisation pour lequel il a été conçu - un deuxième cerveau rapide, en texte brut et extensible par plugin - presque rien ne le bat.

Mais mes notes ont évolué. Ils ont cessé de « penser à voix haute » et se sont transformés en artefacts structurés :

• Journaux de bogues avec étapes reproductibles, analyse des causes profondes et vérification des correctifs
• Enregistrements de décisions d'architecture (ADR) avec contexte, décision et conséquences explicites
• Runbooks pour les incidents de production avec des étapes de récupération séquencées
• Notes d'engagement client avec journaux de bogues, décisions et runbooks liés
• Documentation de projet de longue durée avec plusieurs contributeurs (moi + sous-agents écrivant des fichiers mémoire)

Une fois que vos notes ressemblent plus à un système de documentation qu'à un journal, trois limitations Obsidian commencent à se faire sentir :

1. Les références de bloc sont rompues lors de la refactorisation. La syntaxe de référence de bloc de Obsidian ([[file#^block-id]]) s'ancre à un ID de bloc spécifique dans un fichier spécifique. Lorsque vous déplacez le fichier, Obsidian tente de mettre à jour le chemin automatiquement. La plupart du temps, cela fonctionne. Parfois, ce n'est pas le cas, en particulier avec les déplacements par lots, la syntaxe introduite par le plugin ou la synchronisation d'un éditeur externe. Et quand il échoue silencieusement, vous ne le remarquez que lorsque vous cliquez sur un lien six mois plus tard.

2. Les requêtes de style base de données nécessitent des plugins. Dataview est génial. Il s'agit également d'un plugin communautaire géré par un développeur qui diffuse les versions majeures de Obsidian environ deux fois par an. Si votre runbook dépend du rendu correct d’une requête Dataview, votre runbook dépend de l’intégrité de Dataview. Il s'agit d'une chaîne de dépendance fragile pour les documents critiques pour la production.

3. L'édition multi-utilisateurs n'est pas le modèle. Obsidian Sync existe et est solide pour un usage personnel. Mais Obsidian a été conçu comme un outil mono-utilisateur. Dès que vous souhaitez qu’une équipe ou des sous-agents écrivent simultanément dans le même coffre-fort, vous combattez le modèle.

L’incident du lien fissuré n’était que la surface. En dessous se trouvait une réalisation plus profonde : mes notes étaient devenues trop grandes pour un modèle de fichier en tant que document. J'avais besoin d'un système dans lequel l'unité atomique était le bloc et non le fichier. Où les références ont survécu aux changements de structure. Où les requêtes étaient natives, non intégrées.

C’est le créneau pour lequel SiYuan vs Obsidian se bat réellement.

Ce que Block IDs fait réellement – un exemple réel

Le pitch : chaque bloc de SiYuan obtient un identifiant permanent de 22 caractères au moment où vous le créez. L'ID reste avec le bloc pour toujours - lors des déplacements, des renommages, des fractionnements de documents et des fusions de documents. Les références pointent vers l'ID, pas vers le chemin. Déplacez le bloc ; la référence fonctionne toujours.

Cela semble bien en théorie. Voici à quoi cela ressemble réellement en pratique.

J'ai créé un document appelé redis-eviction-storm.md et écrit trois blocs :

- Symptom: Redis CPU spikes to 100% for 90 seconds, then recovers.
- Root cause: maxmemory-policy set to allkeys-lru with eviction batch
  size of 10. Under high write load, eviction cycle blocks the event loop.
- Fix: Switch to allkeys-lfu, raise hz to 50, set maxmemory-eviction-tenacity to 5.

SiYuan a stocké chaque puce dans un bloc distinct. Lorsque j'ai cliqué sur la deuxième puce, l'éditeur m'a montré son identifiant de bloc – quelque chose comme 20260418142733-x7k9j2m. Il s'agit d'un horodatage à 14 chiffres (20260418142733 = 18 avril 2026, 14:27:33) plus 7 caractères aléatoires. Chaque bloc de votre espace de travail en reçoit un.

J'ai copié la référence du bloc et l'ai collée dans un autre document : un runbook appelé incident-recovery-redis.md. La référence rendue sous forme d'intégration cliquable montrant le texte de la cause première en ligne. Ensuite, j'ai fait la chose destructrice qui a cassé Obsidian : j'ai déplacé le document source dans un dossier profondément imbriqué, je l'ai renommé infra/databases/redis/eviction-storm-2026.md et je l'ai divisé en deux documents distincts.

La référence dans mon runbook fonctionnait toujours. Pas « travaillé après la réindexation ». Pas "travaillé après que le plugin ait réconcilié les chemins". A fonctionné instantanément, car la référence était liée à l'ID du bloc, pas au chemin du fichier. Le stockage sous-jacent est un fichier .sy JSON contenant une arborescence de nœuds AST et l'ID de bloc est l'ID de nœud AST. Déplacez le document, le fichier se déplace ; les ID de nœud JSON restent inchangés. SQLite réindexe le chemin du fichier, la couche de résolution de référence recherche le bloc par ID, le trouve dans le nouveau fichier, le restitue.

C'est la seule fonctionnalité qui justifie pour moi l'existence de SiYuan. Si vous avez déjà perdu une référence de bloc à un refactor, vous savez exactement à quel point cela compte.

Le compromis réside au niveau de la couche de format de fichier, et nous y reviendrons, car .sy JSON n'est pas Markdown, et cela a des conséquences.

La fonctionnalité qui tue : requêtes natives SQL dans les notes

Les utilisateurs de Obsidian accèdent à Dataview. Les utilisateurs de Notion créent manuellement des bases de données relationnelles. SiYuan est livré avec une base de données SQLite qui indexe chaque bloc de votre espace de travail et vous écrivez SQL directement dans les notes.

Pas un plugin. Pas un outil de barre latérale. La requête est intégrée en tant que bloc intégré, s'exécute lors du rendu du document et est mise à jour chaque fois que les données sous-jacentes changent.

Voici une vraie requête que je garde en haut de mon document bug-tracker.md. Il extrait chaque bloc étiqueté #bug-open sur l'ensemble de mon espace de travail, trié par date de création :

SELECT
  '[' || b.content || '](siyuan://blocks/' || b.id || ')' AS bug,
  b.hpath AS document,
  datetime(substr(b.created, 1, 4) || '-' ||
           substr(b.created, 5, 2) || '-' ||
           substr(b.created, 7, 2)) AS opened
FROM blocks AS b
WHERE b.tag LIKE '%#bug-open%'
ORDER BY b.created DESC
LIMIT 50

Trois choses que Dataview n'a jamais faites pour moi sont correctes :

C'est le vrai SQL. Ce n'est pas un DSL qui enveloppe SQL avec ses propres bizarreries. Si vous avez écrit un SELECT au cours de votre carrière, vous pouvez écrire des requêtes SiYuan dès le premier jour. Rejoint le travail. Les sous-requêtes fonctionnent. Les CTE fonctionnent. Le schéma est documenté et stable — blocks est la table principale, avec des colonnes comme id, content, type, path, hpath, root_id, tag, created, updated, markdown, et quelques autres.

Le schéma est exposé. La documentation API de SiYuan répertorie explicitement le schéma de la table blocks. Il existe également un point de terminaison HTTP /api/query/sql qui prend un corps JSON comme {"stmt": "SELECT * FROM blocks WHERE content LIKE '%redis%' LIMIT 7"} et renvoie des lignes. Cela signifie que des scripts externes, des agents ou même Claude Code lui-même peuvent interroger votre base de connaissances directement sans analyser les fichiers de démarque.

Les blocs intégrés sont de première classe. Chaque bloc intégré dans SiYuan commence par select * from blocks — c'est la convention car le moteur de rendu intégré a besoin du schéma de bloc pour savoir comment restituer les résultats. La requête est mise à jour lors du chargement du document, lors de la modification des données et lors de l'actualisation manuelle.

J'ai désormais des requêtes intégrées dans tout mon espace de travail :

• Un tableau de bord en haut de mon document de projet qui répertorie chaque bloc TODO dans le sous-arbre du projet
• Une requête "notes périmées" qui fait apparaître tout document que je n'ai pas mis à jour depuis plus de 90 jours
• Une requête bug par gravité qui regroupe les bugs ouverts par balises #sev1, #sev2, #sev3
• Une requête "aujourd'hui" dans ma note quotidienne qui extrait chaque bloc que j'ai créé ou modifié ce jour-là

Dataview peut faire la plupart de cela. La différence est que la couche de requête de SiYuan fait partie du produit principal et non d'un plugin communautaire maintenu par un développeur héroïque. Le schéma est stable. Le moteur de requête est SQLite, qui est le logiciel de base de données le plus ennuyeux qui soit. Je lui fais confiance pour les documents critiques pour la production, d'une manière à laquelle je n'ai jamais vraiment fait confiance à Dataview.

Docker Procédure pas à pas pour l'auto-hébergement — La configuration 2026

SiYuan fonctionne comme une application de bureau sur macOS, Windows et Linux. Il fonctionne également comme un conteneur Docker, et c'est ainsi que j'héberge mon espace de travail principal : sur un petit VPS, accessible depuis n'importe quel appareil, entièrement sous mon contrôle.

L'image officielle Docker est b3log/siyuan sur le hub Docker. Le port par défaut est 6806. La commande minimale pour faire fonctionner un espace de travail :

docker run -d \
  --name siyuan \
  -p 6806:6806 \
  -v /opt/siyuan/workspace:/siyuan/workspace \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Dhaka \
  b3log/siyuan \
  --workspace=/siyuan/workspace/ \
  --accessAuthCode=replace-with-a-strong-password

Trois choses dans cette commande sont importantes et ne sont pas évidentes d'après la documentation :

L'indicateur --workspace doit correspondre au chemin de montage côté conteneur. SiYuan stocke tout ce qui se trouve dans le dossier de l'espace de travail : vos blocs-notes, l'index SQLite, les pièces jointes, les données du plug-in et les métadonnées de synchronisation. Si l'indicateur et le montage du volume ne sont pas d'accord, le conteneur démarre mais n'écrit rien d'utile sur le disque et au redémarrage, vous perdez l'état.

--accessAuthCode est votre mot de passe. C'est la seule chose qui se trouve entre le port 6806 et toute personne pouvant accéder à votre VPS. Utilisez une longue chaîne aléatoire. Traitez-le comme une clé SSH. Si vous l'oubliez, vous devez arrêter le conteneur, modifier la configuration dans le dossier de l'espace de travail et redémarrer.

PUID/PGID correspond à votre utilisateur hôte. Sans ceux-ci, le conteneur écrit les fichiers en tant que root, et lorsque vous vous connectez via SSH pour sauvegarder l'espace de travail, vous ne pouvez pas lire vos propres données sans sudo. Exécutez id -u et id -g sur votre hôte et transmettez ces valeurs.

Version Docker Compose, qui est celle que j'exécute réellement :

version: "3.9"
services:
  siyuan:
    image: b3log/siyuan
    container_name: siyuan
    restart: unless-stopped
    ports:
      - "127.0.0.1:6806:6806"
    volumes:
      - /opt/siyuan/workspace:/siyuan/workspace
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Dhaka
    command:
      - --workspace=/siyuan/workspace/
      - --accessAuthCode=${SIYUAN_AUTH_CODE}

Notez la liaison sur 127.0.0.1:6806 — Je n'expose jamais le port 6806 directement à l'Internet public. NGINX est en tête avec TLS, l'authentification de base comme deuxième couche et une liste autorisée stricte pour les adresses IP pouvant atteindre l'amont. C'est la même posture que j'adopterais avec n'importe quel outil de productivité auto-hébergé, et c'est le genre de chose que ma liste de contrôle d'examen de la sécurité pour les applications auto-hébergées signalerait si je l'ignorais.

Bloc serveur NGINX, abrégé :

server {
  listen 443 ssl http2;
  server_name notes.example.com;

  ssl_certificate     /etc/letsencrypt/live/notes.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/notes.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:6806;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
  }
}

Les en-têtes Upgrade de style WebSocket sont importants : SiYuan utilise une connexion persistante entre le client du navigateur et le backend. Sans eux, vous obtenez des toasts aléatoires de « connexion perdue » toutes les minutes ou deux.

Une fois le conteneur opérationnel, appuyez sur https://notes.example.com, entrez votre code d'accès et vous y êtes. Le client de navigateur offre l'expérience SiYuan complète : même interface utilisateur que l'application de bureau, même prise en charge des plugins, même moteur de requête. La seule chose qui manque, ce sont les intégrations au niveau du système d'exploitation comme la barre d'état système.

C'est une configuration de 10 minutes si vous possédez déjà un VPS. Comparez avec Obsidian, où la synchronisation multi-appareils auto-hébergée implique des services tiers, des compartiments S3 ou l'abonnement payant Obsidian Sync. SiYuan étant nativement auto-hébergable est un avantage structurel, pas un avantage.

Vue graphique – Outil utile ou régal pour les yeux ?

La vue graphique de Obsidian est devenue un mème pour une raison. C'est beau. C'est aussi, pour la plupart des gens, un économiseur d'écran. Vous regardez la constellation de vos notes, vous vous sentez brièvement impressionné par votre propre profondeur apparente de pensée, puis fermez l'onglet.

SiYuan propose sa propre vue graphique, et je tiens à vous dire que c'est différent. Ce n’est généralement pas le cas.

Même visualisation nœud et bord. Même simulation physique qui vous permet de faire glisser des clusters. Même codage couleur par tag ou type de document. L'interactivité est bonne. Vous pouvez cliquer sur un nœud et accéder au document. Vous pouvez filtrer par balise, profondeur, type de document ou plage horaire.

Ce que SiYuan ajoute, ce sont des nœuds graphiques au niveau du bloc. Le graphique de Obsidian traite les fichiers comme des nœuds. SiYuan peut restituer des blocs individuels sous forme de nœuds, ce qui signifie que le graphique reflète la structure de référence réelle : un bloc du document A référencé par un bloc du document B apparaît comme un bord entre les blocs et non entre les fichiers.

Est-ce vraiment utile ? Deux fois en trois mois, oui. Une fois, lorsque je cherchais des blocs orphelins (des blocs que j'avais écrits mais jamais référencés de nulle part) et une fois, lorsque je traçais comment une décision architecturale spécifique s'était propagée à travers plusieurs ADR. Les deux fois, le graphique au niveau du bloc m'a montré quelque chose qu'un graphique au niveau du fichier aurait caché.

Les 90 % restants du temps, la vue graphique reste fermée. Je ne pense pas qu'il s'agisse d'un échec spécifique à SiYuan. Je pense que les vues graphiques sont survendues en tant qu'outil de connaissances en général. Ils sont utiles pour une inspection structurelle occasionnelle, pas pour le travail quotidien.

Si vous choisissez entre SiYuan et Obsidian uniquement sur la qualité de l'affichage graphique, ne le faites pas. Ils sont équivalents. L'option au niveau du bloc dans SiYuan est une victoire marginale pour un petit ensemble de cas d'utilisation.

Vérification de la réalité du format de fichier — .sy JSON, pas Markdown

C'est ici que SiYuan demande le plus grand engagement et que la plupart des avis dépassent le coût.

Obsidian stocke les notes sous forme de fichiers .md. Plaine Markdown. Vous pouvez les ouvrir dans Vim, dans VS Code, dans le Bloc-notes, dans n'importe quel éditeur ayant existé au cours des 30 dernières années. Si Obsidian disparaît demain, vos notes sont toujours lisibles pour toujours.

SiYuan ne stocke pas Markdown. Il stocke les fichiers .sy, qui sont des documents JSON contenant l'arbre de syntaxe abstraite (AST) de chaque note. Les noms de fichiers sont des horodatages à 14 chiffres plus 7 caractères aléatoires – quelque chose comme 20260418142733-x7k9j2m.sy. La structure des répertoires reflète la hiérarchie de votre bloc-notes. Le contenu réside dans le JSON, indexé au moment de l'exécution par SQLite.

C'est le compromis que vous payez pour des identifiants de bloc stables. L'ID de bloc est l'ID du nœud AST. L'AST doit être conservé dans un format structuré pour maintenir la stabilité des identifiants lors des modifications. Markdown, de par sa conception, ne porte pas d'identité au niveau du bloc : il n'existe aucun moyen conforme aux spécifications d'ancrer un identifiant à un paragraphe dans CommonMark. Si vous souhaitez bénéficier des garanties d'ID de bloc, vous ne pouvez pas utiliser Markdown comme format de stockage. Choisissez-en un.

Ce que cela signifie réellement pour la portabilité :

Vous pouvez exporter vers Markdown. SiYuan intègre l'exportation Markdown : un seul document, un dossier ou un espace de travail entier. L'exportation est bonne. Les références de blocs deviennent des références standard de style lien wiki, les blocs de code survivent, les tables sont converties proprement. Vous ne serez pas enfermé.

Vous ne pouvez pas modifier le stockage directement. Si vous souhaitez modifier en masse vos notes avec un script sed comme vous le feriez avec un coffre-fort Obsidian, vous allez analyser les nœuds AST JSON, et non Markdown correspondant aux expressions régulières. C'est faisable - le schéma AST est documenté - mais cela représente un ordre de grandeur plus de travail qu'une seule ligne contre les fichiers .md.

L'intégration des outils externes est plus difficile. Des outils tels que Pandoc, Marksman, Markdownlint ou l'un des dizaines d'utilitaires CLI qui fonctionnent sur les fichiers Markdown ne fonctionnent pas directement sur .sy JSON. Vous pouvez exporter, exécuter l'outil, réimporter, mais c'est un flux de travail, pas un réflexe.

Les conflits de synchronisation sont différents. Si vous synchronisez un espace de travail via Syncthing ou rsync entre deux machines, les conflits dans les fichiers .sy JSON sont plus difficiles à résoudre manuellement que les conflits dans Markdown simple. La synchronisation officielle de SiYuan (une fonctionnalité d'abonnement payante) gère cela avec une synchronisation incrémentielle cryptée de bout en bout, mais si vous lancez votre propre synchronisation, vous le ressentirez.

Pour moi, le compromis en vaut la peine. Mes notes sont désormais de l'infrastructure, pas de la littérature. Je les veux interrogeables, stables en référence et structurellement explicites. Le stockage JSON-AST est le prix de ces propriétés, et l'exportation Markdown me donne une issue de secours si jamais je change d'avis. Mais si vos notes sont principalement en prose (journaux, fiction, réflexions quotidiennes) et que l'attrait de .md réside dans la possibilité de modification dans n'importe quel outil, SiYuan n'est pas le bon choix et vous devriez rester avec Obsidian. Ce n'est pas un défaut. C'est une taxe de conception pour un objectif différent.

SiYuan vs Obsidian vs Notion — Comparaison honnête

Chaque article « X vs Y » se transforme finalement en une matrice de fonctionnalités. Voici le mien, avec la particularité que les lignes qui comptent le plus sont celles où les trois outils sont véritablement en désaccord.

centre commercial, principalement chinois | Grand format, en anglais d'abord | Aucun — plateforme fermée | | Collaboration en temps réel | Limité | Limité | Excellent | | Hors ligne d'abord | Complet | Complet | Partiel (cache uniquement) | | Courbe d'apprentissage | Raide au début | Modéré | Peu profond | | Applications mobiles | iOS, Android, HarmonyOS | iOS, Android | iOS, Android | | Coût | Gratuit (synchronisation payante en option) | Gratuit (synchronisation payante en option) | Niveaux gratuits → payants |

Mon avis, ligne par ligne, sur les lignes qui comptent vraiment :

Stabilité de référence. SiYuan l'emporte carrément. C’est la fonctionnalité qui m’a attiré et celle que je n’ai cessé d’apprécier. Si vous refactorisez régulièrement vos notes, cela compte plus que toute autre chose.

Requête native. SiYuan gagne à nouveau, par marge. SQL > Dataview DSL > Interface utilisateur de filtre de Notion. Le fait que le moteur de requête fasse partie du produit principal, et non d’un plugin, fait une réelle différence pour les documents critiques en production.

Portabilité du format de fichier. Obsidian gagne, point final. Plain Markdown est le format de note le plus portable jamais inventé. Vous abandonnez cela pour obtenir les identifiants de bloc.

Écosystème de plugins. Obsidian gagne d'un mile. Le marché de SiYuan existe, le référentiel du bazar communautaire se met automatiquement à jour toutes les heures et le développement est actif, mais l'écosystème est plus petit et penche vers les plugins en langue chinoise. La sélection de plugins en anglais est rare et la documentation en anglais pour le développement de plugins est ouvertement reconnue comme un domaine nécessitant du travail. Si vous vivez et mourez grâce aux plugins communautaires, cela compte.

Collaboration en temps réel. Notion gagne. Rien dans l'espace local d'abord n'est comparable à l'expérience "dix personnes éditant la même page simultanément" de Notion. Si vos notes sont un artefact d'équipe, Notion est la réponse et SiYuan vs Obsidian est complètement la mauvaise image.

Auto-hébergement et propriété. SiYuan gagne. Obsidian est d'abord local, mais la synchronisation officielle est un SaaS payant. Notion est un pur cloud. SiYuan avec Docker vous offre les premiers avantages locaux ainsi que la commodité multi-appareils sans dépendre des serveurs de quelqu'un d'autre qui restent en ligne.

La comparaison du titre SiYuan vs Obsidian se résout comme suit : SiYuan si vos notes sont une documentation structurée ; Obsidian si vos notes sont en prose et en plugins. La comparaison Notion vs SiYuan est encore plus simple : Notion si vous avez besoin d'une collaboration d'équipe en temps réel ; SiYuan si vous avez besoin de confidentialité, de propriété et d'un moteur de requête que vous contrôlez.

Où SiYuan perd

J'ai été généreux jusqu'à présent. Voici les aspérités que j’ai rencontrées, par ordre de priorité.

L'écosystème de plugins est petit et difficile à naviguer en anglais. La communauté de développeurs de SiYuan est en grande partie de langue chinoise, ce qui est excellent pour la profondeur et la cohérence du projet, mais moins pour les utilisateurs anglophones uniquement. L'interface utilisateur du marché est bilingue, mais les descriptions et la documentation des plugins sont souvent orientées vers le chinois. Il existe un problème ouvert GitHub (#12878) concernant explicitement l'amélioration de la prise en charge de l'anglais. Si votre idée d'un outil de note parfait implique des plugins communautaires triés sur le volet pour chaque micro-workflow, SiYuan vous frustrera.

L'interface utilisateur semble démodée pour certains utilisateurs. C'est subjectif et j'essaie d'être juste. Le langage de conception de SiYuan est plus proche d'un IDE riche en fonctionnalités de 2018 que d'une application minimaliste de 2026. Il y a beaucoup de boutons. Le jeu d'icônes est occupé. Le thème par défaut est bien mais pas joli. Si vous venez de l'esthétique CSS simple et épurée de Obsidian ou du design aéré de Notion, la première heure dans SiYuan va vous sembler encombrée. Après une semaine, vous ne le remarquez plus, mais la première impression compte.

Les performances diminuent sur de vastes espaces de travail. Le modèle indexé SQLite est rapide, jusqu'à ce qu'il ne le soit plus. Mon espace de travail principal comprend environ 1 800 documents avec peut-être 40 000 blocs au total, et SiYuan le gère sans se plaindre. Les personnes qui ont déclaré avoir utilisé plus de 10 000 espaces de travail de documents décrivent un retard notable dans la recherche en texte intégral et le rendu des graphiques. Il existe un fil d'ingénierie actif pour optimiser cela, mais si votre coffre-fort Obsidian existant est véritablement massif, validez les performances avant de vous engager.

Le coût de migration depuis Notion est réel. L'exportation de Notion est HTML ou Markdown avec une structure de dossiers qui ne correspond pas clairement au concept de bloc-notes de SiYuan. Vous pouvez obtenir la plupart du contenu, mais vous perdrez des éléments spécifiques à Notion : liens de base de données relationnelles, propriétés de page, intégrations et tout type de bloc Notion uniquement. Planifiez un week-end, pas un après-midi.

L'expérience mobile est fonctionnelle, pas agréable. Les applications Android et iOS fonctionnent. Ils se synchronisent. Ils rendent correctement. Mais l’éditeur sur mobile est clairement un citoyen de seconde zone par rapport au bureau. La manipulation des blocs sur un téléphone est délicate et les blocs complexes (intégrations SQL, graphiques, mathématiques) sont souvent rendus mais ne sont pas bien modifiés. Si vous avez besoin d’une capture de notes sur mobile, c’est une vraie contrainte.

Fonctionnalités de niveau adhésion pour une synchronisation avancée. La synchronisation cryptée de bout en bout est une fonctionnalité d'adhésion payante à SiYuan. Le niveau gratuit est entièrement fonctionnel : vous pouvez vous auto-héberger avec Docker, synchroniser via Syncthing ou un autre outil et ne rien perdre de matériel. Mais l’expérience de synchronisation la plus raffinée se trouve derrière un paywall. C'est juste et les développeurs méritent d'être payés, mais cela vaut la peine de le savoir avant de supposer que l'expérience gratuite correspond aux captures d'écran marketing.

Rien de tout cela n’est un facteur décisif pour moi. Ensemble, ils sont la raison pour laquelle SiYuan vs Obsidian n'a pas de gagnant universel.

Qui devrait changer, qui ne devrait pas

Oubliez les conseils génériques. Voici des profils concrets.

Passez à SiYuan si vous êtes :

• Un développeur gérant un système de documentation personnel (journaux de bogues, runbooks, ADR, post-mortems d'incidents) où la stabilité des références entre les refactors compte plus que la flexibilité de l'éditeur.
• Toute personne ayant perdu une référence de bloc suite à un changement de nom Obsidian et souhaitant que cela cesse de se produire
• Un auto-hébergeur qui souhaite des documents structurés de style Notion mais refuse de mettre des données propriétaires sur les serveurs de quelqu'un d'autre
• Quelqu'un qui crée une base de connaissances que les agents AI interrogeront : l'index SQLite plus HTTP API plus les ID de bloc stables rendent l'intégration des agents véritablement réalisable.
• Un grand utilisateur de la pensée relationnelle qui combat actuellement Dataview et souhaite que la couche de requête soit une véritable base de données

Restez avec Obsidian si vous êtes :

• Un écrivain ou essayiste quotidien dont les notes sont principalement en prose
• Profondément investi dans l'écosystème de plugins Obsidian (Excalidraw, Obsidian Tasks, Smart Connections, Templater) — aucun d'entre eux n'a d'équivalent direct SiYuan
• Quelqu'un qui a besoin de la portabilité de .md entre outils (Pandoc, générateurs de sites statiques, éditeurs externes)
• Un utilisateur solo pour lequel le problème du lien fissuré ne vaut pas la peine de changer d'outil

Restez avec Notion si vous êtes :

• Travailler sur des documents partagés avec une équipe qui a besoin d'édition multijoueur en temps réel
• Un utilisateur non technique qui apprécie le langage de conception et l'écosystème de modèles Notion
• Construire un wiki pour une entreprise où la propriété est « l'entreprise », et non « moi personnellement »

Exécutez les deux si vous êtes :

• Un développeur avec un coffre-fort Obsidian existant mais un problème croissant de documents structurés. C'est ce que je fais. Obsidian pour une capture et une prose rapides ; SiYuan pour la couche de documentation structurée ; les deux interagissent via l'exportation Markdown lorsque j'ai besoin de déplacer des éléments entre eux.

L’erreur à éviter est de considérer cela comme un choix entre l’un ou l’autre. Le coût de fonctionnement de deux outils est réel mais faible. Le coût de forcer des notes en prose dans SiYuan ou des documents structurés dans Obsidian est beaucoup plus élevé.

Ma configuration actuelle – Ce que j'ai conservé, ce que j'ai migré

Trois mois après la première installation de SiYuan, voici la répartition réelle des tâches sur mon système.

J'ai séjourné dans Obsidian : notes quotidiennes, entrées de journal, capture éphémère, tout ce que j'écris pour réfléchir plutôt que pour documenter. Environ 1 200 dossiers. L'écosystème de plugins (en particulier Templater, Dataview-for-prose et le plugin Local Images Plus de ma configuration RAG de style Karpathy) est trop précieux pour être abandonné. Je construis toujours mon deuxième cerveau sur Obsidian, que j'ai couvert dans mon approfondissement sur Obsidian et Claude Code pour la couche de prose et de réflexion.

Migré vers SiYuan : journaux de bogues (312 fichiers), runbooks (84 fichiers), ADR (47 fichiers), documents d'engagement client (environ 200 fichiers) et documentation de projet pour les engagements actifs (variable). Environ 700 documents et ce chiffre ne cesse de croître. Tout ce où la stabilité des références et la possibilité d'interrogation de SQL sont plus importantes que la portabilité de Markdown.

La couche d'intégration : un petit script Node.js qui s'exécute tous les soirs, exporte l'espace de travail SiYuan vers Markdown via API et dépose l'exportation dans un dossier d'index Obsidian. En lecture seule, mais cela signifie que ma recherche basée sur Obsidian peut trouver du contenu du côté SiYuan. Le sens inverse (Obsidian → SiYuan) que je n'ai pas construit car je n'en ai pas besoin — le contenu Obsidian ne fait pas référence au contenu SiYuan ; la dépendance va dans un sens.

La couche agent : Claude Code interroge directement ma base de données SiYuan SQLite lorsque j'effectue un travail de graphe de connaissances. J'ai couvert le modèle général de RAG de style Karpathy sur les coffres-forts de démarque - SiYuan est un substrat plus riche pour la même idée car le schéma est structuré. Au lieu de procéder à la démarque, l'agent exécute SQL : "Donnez-moi chaque bloc de bogue étiqueté sév1 au cours des 30 derniers jours dont la cause première mentionne Redis." Cette requête prend 40 ms et renvoie des blocs exacts, pas des morceaux. Pour les flux de travail du développeur secondaire où l'agent a besoin d'un contexte structuré, il s'agit d'une mise à niveau significative.

Pourquoi je n'utilise PAS SiYuan : pour écrire cet article de blog. Le message que vous lisez a été rédigé dans Obsidian, édité dans VS Code et enregistré sous Markdown. Le modèle de texte brut partout reste gagnant pour le contenu qui aboutit sur le Web public. SiYuan est destiné aux documents qui restent privés et bénéficient d'une structure.

C'est l'ensemble du tableau. Deux outils, un flux de travail, des lignes claires sur ce qui se trouve où.

Le verdict

SiYuan n'est pas le nouveau Obsidian. SiYuan n'est pas le nouveau Notion. Quiconque le présente de cette façon manque ce qui est réellement intéressant dans cet outil.

SiYuan est ce qui se produit lorsque vous prenez au sérieux « l'identité au niveau du bloc » en tant que primitive et que vous construisez un système de connaissances autour d'elle. L'ID du bloc survit aux mouvements. Le moteur SQL indexe les blocs. La vue graphique les restitue. Le HTTP API les expose. Chaque fonctionnalité découle du même engagement architectural : les blocs sont réels, les fichiers sont dérivés, les chemins sont modifiables.

Cet engagement est ce qui rend SiYuan idéal pour la documentation structurée. C'est aussi ce qui rend le format de fichier opaque, le coût de migration réel et l'écosystème plus étroit que celui de Obsidian. Les compromis en matière d'ingénierie sont comme ça : choisissez la propriété que vous souhaitez le plus, acceptez les coûts qui l'accompagnent.

Pour le développeur qui a craqué une référence de bloc de trop lors d'un refactor et souhaite que le problème cesse d'exister, SiYuan vaut le week-end nécessaire à sa configuration. Pour tous les autres, la réponse est plus nuancée, et j’ai essayé de tracer honnêtement les lignes ci-dessus.

Vous vous souvenez du runbook dans lequel j'ai perdu le lien, au début ? Je l'ai reconstruit dans SiYuan pendant un week-end de février. Six semaines plus tard, j'ai refactorisé l'intégralité de ma structure bug-logs/ pour la deuxième fois : je l'ai divisée par client, puis par service, puis j'ai archivé deux années d'incidents résolus. Des centaines de fichiers déplacés. Des milliers de blocs réorganisés.

J'ai cliqué sur le lien dans le runbook ce matin. Cela a fonctionné. Six semaines de changements structurels, des dizaines de déménagements, et la référence pointait toujours exactement là où elle devait être.

C'est tout le pitch en une phrase : dans SiYuan, le lien fonctionne toujours. La question de savoir si cette propriété unique vaut la peine de changer d'outil dépend de la fréquence à laquelle vous l'avez vue échouer dans les outils que vous utilisez actuellement.

Questions fréquemment posées

SiYuan est-il vraiment open source ?

Oui. SiYuan est sous licence AGPLv3 et la source se trouve sur GitHub à siyuan-note/siyuan. Vous pouvez vous auto-héberger, créer un fork ou contribuer sans restriction. Le niveau payant (abonnement) couvre le service officiel de synchronisation dans le cloud, les clés de chiffrement de bout en bout et les fonctionnalités assistées par AI, mais aucun d'entre eux n'est requis pour utiliser le produit principal.

Puis-je migrer mon coffre-fort Obsidian vers SiYuan ?

Oui, mais avec des réserves. SiYuan peut importer des fichiers et des structures de dossiers Markdown, qui couvrent la majeure partie d'un coffre-fort Obsidian. Ce que vous perdez : la syntaxe spécifique au plugin (requêtes Dataview, métadonnées du plugin Tasks, modèles Templater), la syntaxe de référence de bloc spécifique à Obsidian et tout CSS personnalisé. Prévoyez d'importer structurellement, puis de reconstruire manuellement tous les flux de travail pilotés par des plugins dans les primitives natives SiYuan.

Le format de fichier .sy présente-t-il un risque de dépendance vis-à-vis du fournisseur ?

C'est une vraie considération mais ce n'est pas un verrouillage strict. SiYuan est livré avec l'exportation Markdown intégrée au niveau du document, du dossier et de l'espace de travail complet. L’export est haute fidélité pour les contenus standards. Vous perdrez les fonctionnalités spécifiques à .sy (ID de bloc, requêtes SQL intégrées, attributs de bloc personnalisés) lors de l'exportation, mais la prose, le code et la structure survivent. Le profil de risque est plus proche de Notion (export disponible, avec perte) que d'un véritable lock-in propriétaire.

Comment SiYuan se compare-t-il à Logseq ?

Les deux sont d’abord locaux et orientés blocs. Logseq est avant tout un aperçu avec une journalisation quotidienne intégrée ; SiYuan est axé sur le document avec des fonctionnalités de présentation disponibles. Logseq stocke les notes sous .md avec une base de données side-car ; SiYuan stocke .sy JSON. Pour les flux de travail de présentation pure et de journalisation quotidienne, Logseq gagne. Pour la documentation structurée et l'interrogation SQL, SiYuan l'emporte.

SiYuan fonctionne-t-il hors ligne ?

Pleinement. L'application de bureau et l'instance Docker auto-hébergée fonctionnent entièrement hors ligne : chaque fonctionnalité, y compris les requêtes SQL, le rendu graphique et la résolution de référence, s'exécute sur l'index SQLite local. La synchronisation nécessite une connexion réseau (soit au cloud officiel de SiYuan, soit à votre propre cible de synchronisation), mais l'édition et la navigation quotidiennes n'ont aucune dépendance en ligne.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io