NotariumDocumentation
Version de la documentation: latest
FR

Historique des versions

Chaque note tient son propre journal des révisions — l'historique de tous les états par lesquels elle est passée. Il s'agit d'un versionnage au niveau de l'application, et non d'une couche git posée sur un dossier : le journal réside dans la base de métadonnées (metadata DB) et accumule les états ayant transité par Notarium ou repérés par la synchronisation des fichiers. Le fichier .md lui-même reste la source de vérité — le journal le complète, sans le remplacer.

Une révision est un instantané

Chaque révision conserve l'état complet de la note au moment de la modification : titre, tags, slug et corps normalisé — et non un diff ligne par ligne. Les diffs servant à comparer les versions sont calculés à la volée, car ils sont reconstituables à partir des instantanés.

Les corps des révisions sont adressés par contenu (content-addressed, sha-256), si bien qu'un contenu identique n'est stocké qu'une seule fois. La restauration d'une version, les boucles de modification d'un agent et les états récurrents ne créent pas de copies supplémentaires — la déduplication repose sur le contenu lui-même.

Le journal est indexé par l'identifiant interne de la note (notarium-id), et non par son chemin de fichier. C'est pourquoi l'historique survit au déplacement entre dossiers et au renommage : il s'agit toujours de la même note, avec le même historique.

Provenance : qui a modifié, et comment

Chaque révision est signée — on voit d'où provient une modification. Une révision possède un type et un principal auteur :

Type de révisionSignification
writeUn enregistrement via Notarium (humain ou agent)
externalUn état repéré par la synchronisation des fichiers directement sur le disque
restoreUn retour à une version antérieure (conserve une référence vers la source)
deleteTombstone : le dernier état d'une note supprimée

L'auteur est enregistré comme un utilisateur précis, le token personnel d'un agent ou l'interface ; les modifications externes n'ont pas d'auteur — personne ne peut les signer. Ainsi, l'historique montre exactement ce qu'un humain a modifié et ce qu'un agent IA a fait. Pour en savoir plus sur la distinction entre les modifications humaines et celles des agents, voir Humains et agents.

Granularité des modifications externes

Les modifications faites directement dans le fichier (en contournant Notarium) sont vues par le journal à la précision d'un cycle de synchronisation : plusieurs changements entre deux relevés se fondent en un seul état observé. Les modifications passant par Notarium lui-même sont enregistrées précisément.

Une révision porte aussi les compteurs de caractères ajoutés et supprimés — le « coût » de la modification par rapport à la version précédente.

Consulter, comparer et restaurer

L'historique d'une note est accessible depuis le mode lecture — l'onglet History du panneau latéral affiche une frise chronologique des versions : qui a fait la modification, les compteurs +N −M et la date. Sélectionner une révision l'ouvre à la place du texte courant, avec une bascule entre Changes (un diff au niveau du mot, avec insertions et suppressions surlignées) et Content (le contenu lui-même).

L'onglet History : les révisions avec leur auteur et leurs compteurs ; la v3 vient d'un agent

Pour revenir en arrière, utilisez le bouton Restore this version. La restauration reprend le corps depuis le journal et l'écrit comme une nouvelle modification, protégée par une vérification de version optimiste : si la note a été modifiée entre-temps, vous obtenez un conflit (409), et rien n'est écrasé silencieusement.

Stockage et suppression

Par défaut, l'historique est conservé intégralement — Notarium n'élague pas les révisions automatiquement. Vous pouvez effacer entièrement l'historique d'une note à la main, en la vidant depuis la Corbeille : supprimer une note crée un tombstone avec son dernier état (qui peut être restauré), et une purge définitive efface aussi l'historique.

Limites du journal

L'historique des versions nécessite la base de métadonnées. Sans la base de métadonnées, l'historique ne vit que le temps d'exécution du processus. Il n'existe pas d'élagage automatique programmé des anciennes révisions — nous conservons l'historique dans son intégralité.

Sujets connexes : File-first — le fichier comme source de vérité, Corbeille — suppression et restauration, Modèle d'accès — qui peut revenir à des versions antérieures.