Chapitre 10
Les conventions : arborescence plate et front-matter normé

1. L'arborescence

vault/
├── 00-inbox/          # capture brute, sans front-matter
├── 10-journal/2026/   # notes quotidiennes, un sous-dossier par année
├── 20-notes/          # fiches de connaissance, à plat
├── 30-projets/        # une note par project, à plat
├── 80-assets/         # images, PDF
├── 90-meta/           # manifeste, conventions, templates, vues, outillage
└── 99-archive/

Les préfixes numériques ne servent qu'à l'ordre d'affichage. Aucun dossier n'a de sous-dossier, sauf 10-journal/ découpé par année pour ne pas atteindre mille fichiers dans un même répertoire.

Pourquoi si peu

Une hiérarchie profonde impose de répondre à « où ça va ? » à chaque note, et cette question n'a souvent pas de bonne réponse. Une fiche sur les temps de cycle PROFINET appartient-elle au réseau, à la performance, ou au projet en cours ? Les trois. Un dossier n'en garde qu'un.

Le modèle plat déplace la question : on ne demande plus où ranger, mais ce que c'est. Le classement se reconstruit ensuite à volonté par requête — et une note peut apparaître dans autant de vues qu'elle concerne, sans jamais être dupliquée ni déplacée.

Ce que porte chaque dossier

2. Le contrat, rappelé

Le chapitre 3 l'a introduit ; le voici comme règle exécutable. Cinq champs obligatoires partout :

type: daily | project | concept
title: …
created: 2026-08-02       # ISO, jamais modifié
updated: 2026-08-02       # touché à chaque édition
scope: work | personal

Plus, selon le type : status obligatoire sur un projet (active, dormant, closed), repo et milestones optionnels ; sources et see_also sur un concept ; projects sur une note quotidienne.

Ce contrat est documenté dans 90-meta/conventions.md — une note ordinaire, lisible dans Obsidian, à côté des vues qu'elle rend possibles.

3. Le validateur

$ uv run --project 90-meta/tooling 90-meta/tooling/vault.py doctor
0 probleme(s)

Il parcourt les notes du périmètre et vérifie cinq choses : le front-matter est présent et lisible, les champs obligatoires sont là, type et scope sont dans leur énumération, un projet a un status valide, et chaque lien de projects vise une note qui existe dans 30-projets/.

La précédence des problèmes

Le validateur s'arrête au premier problème d'une note plutôt que de tout accumuler :

# La précédence est délibérée : un champ manquant rend les contrôles
# suivants ininterprétables, on ne les tente pas.
for champ in CHAMPS_OBLIGATOIRES:
    if champ not in entete:
        problemes.append(...)
if problemes:
    return problemes
if entete["type"] not in TYPES:
    return [Probleme(relatif, f"type invalide : {entete['type']}")]

Signaler « type invalide » sur une note où type est absent n'aide personne. Le comportement est fixé par deux tests, pour qu'un remaniement ne le change pas par accident.

Une note illisible n'arrête pas le reste

4. Le périmètre : liste blanche

DOSSIERS_VALIDES = ("10-journal", "20-notes", "30-projets", "90-meta")
DOSSIERS_EXCLUS = ("90-meta/templates", "90-meta/tooling")

Le validateur ne regarde que ces dossiers, moins ces exclusions. La formulation inverse — une liste noire de ce qu'on ignore — paraît plus naturelle et se révèle fausse.

Ce qui doit rester dehors, et pourquoi :

• 00-inbox/ — pas de front-matter, par conception (chapitre 6) ;
• 90-meta/templates/ — les templates contiennent <% tp.date.now() %>, qui n'est pas une date valide ;
• 90-meta/tooling/ — du code, et surtout des artefacts générés ;
• README.md, docs/, 99-archive/ — pas des notes normées.

5. Les vues comme notes

Les trois vues du vault vivent dans 90-meta/vues/ et sont des notes ordinaires, avec leur front-matter type: concept. Elles sont donc versionnées, liables, et validées comme les autres.

Ce n'est pas anodin. Une vue rangée dans la configuration serait invisible dans le vault, non liable, et perdue à la reconstruction. Comme note, elle se cite, se modifie, s'améliore au fil de l'usage.

6. Comment les pièces se tiennent

Chaque élément de ce chapitre dépend des autres, et c'est ce qui rend l'ensemble stable :

Retire une pièce et l'édifice penche. Sans templates, le front-matter dérive et les vues se vident. Sans validateur, la dérive ne se voit qu'au moment où une vue devient fausse — trop tard. Sans vues, plus rien ne justifie l'effort du front-matter, et on retourne aux dossiers.

Récapitulatif

Exercices