Chapitre 08
Le problème : une configuration illisible et non rejouable

1. Le constat

Tu as passé sept chapitres à configurer un vault : neuf plugins, leurs réglages, un dossier de notes quotidiennes, un template de dossier, une capture, un raccourci. Cette configuration a de la valeur — elle représente des dizaines de décisions.

Où vit-elle ? Dans .obsidian/, mélangée à trois choses de natures très différentes :

$ du -sh ~/vault/.obsidian/* | sort -rh | head -6
12M     /home/moi/vault/.obsidian/plugins
6,1K    /home/moi/vault/.obsidian/workspace.json
909     /home/moi/vault/.obsidian/types.json
697     /home/moi/vault/.obsidian/core-plugins.json
276     /home/moi/vault/.obsidian/hotkeys.json
208     /home/moi/vault/.obsidian/community-plugins.json

• 12 Mo de code tiers — du JavaScript compilé, réécrit intégralement à chaque mise à jour de plugin ;
• de l'état d'interface — workspace.json, réécrit à chaque fermeture de panneau ;
• quelques kilooctets de décisions, noyés dans le reste.

2. Les trois réponses qui ne marchent pas

Tout versionner

On met .obsidian/ sous git et on n'en parle plus. En pratique : un commit à chaque fermeture d'Obsidian à cause de workspace.json, un conflit systématique dès qu'on travaille sur deux machines, et une mise à jour de plugin qui produit un diff de plusieurs milliers de lignes de JavaScript minifié. L'historique devient inexploitable, ce qui revient à ne pas en avoir.

Ne rien versionner

On met .obsidian/ dans le .gitignore — c'est la pratique la plus répandue, et c'est ce que fait la plupart des tutoriels. L'historique reste propre, et la configuration n'existe nulle part. Machine neuve : tout à refaire de mémoire. Aucune trace des décisions.

La documenter

On écrit un README qui liste les plugins et les réglages importants. Il est juste le jour où on l'écrit. Trois semaines plus tard, quelqu'un — toi — change un réglage à la souris et ne met pas le document à jour. Rien ne le signale.

3. Le renversement

L'idée tient en deux phrases :

Un fichier manifeste, lisible et versionné, décrit la configuration voulue. .obsidian/ n'est plus qu'un produit de ce manifeste, et peut être supprimé et reconstruit à tout moment.

C'est le même renversement qu'entre une machine configurée à la main et une machine décrite par un fichier d'infrastructure. Ce qui fait foi n'est plus l'état, c'est la description.

Trois conséquences immédiates :

1. .obsidian/ est entièrement gitignoré. Sans exception — c'est ce qui rend la promesse vérifiable.
2. Un réglage qui n'est pas dans le manifeste n'existe pas. Il sera écrasé à la prochaine reconstruction. Contrainte forte, et volontaire.
3. L'écart entre le manifeste et la réalité devient une notion de premier plan : la dérive. Il faut savoir la détecter, et savoir la promouvoir en décision.

4. À quoi ressemble un manifeste

obsidian_min: "1.9"

core_plugins:
  enabled: [daily-notes, backlink, graph, global-search, templates,
            file-explorer, command-palette, properties, bookmarks, ...]
  disabled: [publish, sync, slides, footnotes, ...]
  settings:
    daily-notes:
      folder: 10-journal
      format: YYYY/YYYY-MM-DD
      template: 90-meta/templates/daily
    templates:
      folder: 90-meta/templates

appearance:
  theme: obsidian
  base_font_size: 16

plugins:
  - id: dataview
    repo: blacksmithgu/obsidian-dataview
    version: "0.5.70"
    sha256:
      main.js: "3f2a…"
      manifest.json: "9c11…"
      styles.css: "aa47…"
    settings:
      enableDataviewJs: true

  - id: templater-obsidian
    repo: SilentVoid13/Templater
    version: "2.24.3"
    sha256: { ... }
    settings:
      templates_folder: 90-meta/templates
      trigger_on_file_creation: true
      trigger_on_file_creation_mode: folder
      folder_templates:
        - folder: 10-journal
          template: 90-meta/templates/daily.md

  - id: obsidian-kanban
    repo: mgmeyers/obsidian-kanban
    version: "2.0.51"
    sha256: { ... }
    # pas de bloc settings : réglages non gérés

hotkeys:
  quickadd:choice:61a731e5-7663-49b9-8676-ae7024578ed0: "Ctrl+Shift+I"

Chaque bloc a une destination précise dans .obsidian/ :

Les empreintes

Chaque plugin porte sa version et l'empreinte SHA-256 de chacun de ses fichiers. Ce n'est pas de la paranoïa : une release GitHub peut être retirée, re-taguée, ou remplacée. Sans empreinte, « version 0.5.70 » est une promesse ; avec, c'est une vérification.

Corollaire : une empreinte ne s'écrit pas à la main. Le chapitre 9 présente la commande qui les calcule, et qui est le seul chemin autorisé pour changer une version.

5. Le compromis : ce qu'on gère et ce qu'on subit

Regarde à nouveau la dernière entrée ci-dessus : pas de bloc settings. Ce n'est pas un oubli.

Un plugin écrit son data.json tout seul, et le remplit de valeurs par défaut qu'il réécrira à sa prochaine mise à jour. Le cas qui a tranché la question dans le vault de référence était Excalidraw : 26 Ko de JSON à lui seul, faisant passer le manifeste de 361 à 1199 lignes. C'est-à-dire lui faire perdre sa lisibilité, qui était la raison de le préférer à un .obsidian/ versionné.

Le critère de décision : ce réglage est-il une décision que j'ai prise, ou une valeur que le plugin s'est donnée ? Les premières vont au manifeste, les secondes restent où elles sont.

6. Ce que ça donne comme outillage

Le manifeste ne sert à rien sans les commandes qui l'exploitent. Le chapitre 9 les détaille ; voici la carte.

doctor et export forment le couple qui rend le système vivable. Sans eux, la première fois que tu bouges un curseur dans les réglages d'Obsidian, ta modification est condamnée à disparaître au prochain apply, sans prévenir.

Récapitulatif

Exercices