Architecture d'Obsidian Canvas

Obsidian repose sur une philosophie local‑first : le coffre de connaissances est un répertoire de fichiers texte Markdown. Le canevas n’est qu’un fichier supplémentaire, nommé .canvas, qui se sauvegarde sur le disque au format JSON ouvert. Chaque carte créée directement sur le canevas vit uniquement dans ce fichier ; elle n’apparaît pas comme note autonome dans le vault tant qu’elle n’est pas convertie manuellement en fichier .md. Les notes existantes peuvent être glissées sur le canevas, mais le canevas ne fait qu’une référence de chemin vers le fichier source.

Les flèches dessinées entre deux cartes sont enregistrées comme des coordonnées visuelles dans le même fichier .canvas. Elles ne génèrent aucun lien Markdown ni [[wikilink]] et, par conséquent, n’apparaissent pas dans la vue globale du graphe d’Obsidian. Même l’ajout d’un plugin de visualisation ne transforme pas ces lignes en relations indexées : elles restent des données locales au canevas.

Le contexte spatial reste donc confiné au fichier .canvas. Un même fichier Markdown embarqué sur plusieurs canevas ne conserve aucune métadonnée indiquant où il est positionné, quels voisins il a, ou quelles flèches le ciblent. En ouvrant la note hors du canevas, l’utilisateur ne retrouve aucune trace de son placement ou de ses connexions visuelles.

Architecture de Heptabase

Heptabase adopte une approche inverse : l’unité atomique est la carte, stockée dans une bibliothèque centrale. Les tableaux blancs (whiteboards) ne possèdent pas les cartes ; ils offrent des vues non‑possédantes sur la bibliothèque. Ainsi, la même carte peut être placée simultanément sur plusieurs tableaux sans duplication de contenu. Toute modification d’une carte se répercute immédiatement sur tous les tableaux où elle apparaît.

Lorsqu’une ligne relie deux cartes sur un tableau, la relation est enregistrée dans le panneau d’information de chaque carte. Le panneau indique les cartes connectées ainsi que le tableau d’origine de la connexion. Cliquer sur l’entrée de connexion ramène l’utilisateur à la position exacte de la ligne sur le tableau concerné. Cette information est donc indexée dans le système et visible depuis n’importe quel contexte, même hors tableau.

Chaque carte conserve son historique relationnel : le panneau d’information répertorie tous les tableaux qui la contiennent, toutes les cartes qui y sont reliées, et fournit des liens directs vers les coordonnées spatiales correspondantes. Le modèle garantit que le contexte visuel n’est jamais perdu, quel que soit l’endroit où la carte est consultée.

Analyse comparative et implications

La différence fondamentale réside dans la localisation du graphe de connaissances. Obsidian externalise le graphe dans les liens Markdown, tandis que les lignes du canevas restent confinées à un fichier autonome. Heptabase, à l’inverse, intègre les lignes dans le graphe de cartes, rendant chaque connexion indexée et interrogeable par le moteur interne.

Cette architecture affecte la portabilité. Le format JSON ouvert d’Obsidian permet à tout script externe de parser, exporter ou transformer les canevas. En revanche, Heptabase stocke cartes, connexions et coordonnées dans un format propriétaire, limitant l’accès aux données aux outils fournis par la plateforme.

En termes de durabilité, le modèle file‑centric d’Obsidian assure que chaque note reste accessible même si le canevas est perdu : les cartes sont de simples fichiers Markdown. Heptabase dépend d’une base de données centralisée ; la perte d’accès à la plateforme implique la perte du contexte visuel, même si le texte de la carte subsiste.

Le choix entre les deux outils doit donc se fonder sur le besoin d’indexation des relations (favorisant Heptabase) ou sur la priorité donnée à la portabilité et à la simplicité de sauvegarde (favorisant Obsidian Canvas).