File-first : les fichiers sont la source de vérité

L'unité de données dans Notarium est un simple fichier Markdown sur votre disque. Pas une ligne dans la base de données d'un tiers, pas un bloc dans un stockage propriétaire, mais un fichier que vous pouvez ouvrir avec n'importe quel éditeur — et qui reste complet sans Notarium. C'est le principe file-first, dont découle tout le reste.

Ce qui relève de la « vérité » et ce qui est dérivé

La source de vérité, ce sont les fichiers .md eux-mêmes. Tout ce qui peut se calculer à partir de leur contenu est dérivé, donc reconstituable :

• dérivé (reconstruit de zéro par une nouvelle analyse des fichiers) : l'index de recherche, le graphe des [[wikilinks]], l'arborescence, les extraits. Supprimer l'index n'a rien d'inquiétant — le moteur réindexe les fichiers au démarrage suivant ;
• non dérivable (réside dans une base de métadonnées distincte) : l'historique des versions, les utilisateurs, l'appartenance et les accès. Voilà ce qui ne peut pas être reconstitué à partir du texte des fichiers : c'est pourquoi tout cela est regroupé dans un unique emplacement clairement à part.

L'identité, à l'inverse, est ancrée dans les fichiers eux-mêmes : le notarium-id d'une note figure dans son frontmatter, et les identifiants d'espace et de projet dans des fichiers marqueurs (.notariummeta). C'est pourquoi les tables des espaces et des projets de la base de métadonnées ne sont qu'un cache reconstituable par analyse, et non le dépositaire unique de l'identité : celle-ci survit même si l'on déplace le dossier hors de Notarium.

Une modification externe est prise en compte même quand le fichier a conservé sa taille et sa date de modification — ce qui est précisément le cas après un git checkout, une synchronisation ou une restauration depuis une archive. Notarium ne croit pas les métadonnées du fichier sur parole : c'est le contenu qui a le dernier mot, si bien que les surfaces dérivées (la liste, la recherche, le graphe) s'alignent sur ce qui se trouve réellement sur le disque, au lieu de rester bloquées sur une version périmée.

Une note-fichier, et non un bloc

La limite est ici tracée délibérément : l'unité de données est la note-fichier entière, et non un paragraphe ou un bloc à l'intérieur. Notarium n'introduit aucune entité distincte plus petite que le fichier — la note dans son ensemble reste l'unité minimale ; c'est précisément là que les applications de prise de notes fondées sur des fichiers basculent d'ordinaire vers une base de données comme source de vérité et y perdent leur portabilité. Une note reste un fichier, et sa structure interne n'est que du Markdown.

Le rendu des notes suit GitHub Flavored Markdown ; les champs de métadonnées sont stockés dans le frontmatter, en tête de fichier.

L'identité survit au déplacement

Chaque note possède un identifiant interne stable, le notarium-id — une clé URL-safe de 12 caractères, placée dans le frontmatter du fichier :

---
notarium-id: aB3kR7xQ_2mv
title: Ma note
---

Le texte de la note, en Markdown simple.

L'identité réside dans le fichier lui-même, et pas seulement dans une base de données. C'est pourquoi ni un renommage, ni un déplacement entre dossiers, ni même un déplacement hors de Notarium ne laisseront orphelins l'historique des versions et les connexions : le journal et les liens sont rattachés au notarium-id, et non au chemin. Le nom de fichier, lui, est dérivé (kebab-case par translittération, slug(title).md) et ne constitue pas l'identité.

Aucun lock-in

Vous pouvez emporter le dossier de fichiers et partir à tout moment — sans Notarium, les notes restent lisibles et complètes. Nul besoin d'une opération d'export dédiée : vous n'êtes de toute façon jamais « à l'intérieur » — vos données se présentent toujours comme de simples fichiers sur votre disque. git peut faire office de source de vérité : versionnez le dossier, synchronisez-le, consultez l'historique avec les outils que vous utilisez déjà.

C'est aussi le fondement de la confidentialité de Notarium : elle ne repose pas sur un chiffrement de bout en bout (le serveur intelligent voit délibérément le contenu — sans quoi il n'y aurait ni recherche, ni sémantique, ni agents), mais sur le fait que le serveur et les fichiers, c'est vous qui les hébergez. Pour en savoir plus, voir Espaces et projets et Modèle d'accès.