---
tags: note
type: "note"
nature: info             # Options : portrait, lieu, info, concept, script, process, tuto, none
ressource: false
univers: PRO
projects:
  - "PROJET"
date: "2026-09-05"
priority: 10
---
# Arborescence

Placer les dossiers ARCHIVES et JOURNAL à la racine et non au niveau d’un domaine. Ce sont des projets transversaux. #arborescence

Organisation et classification des contenus. #arborescence
* Utiliser les sous-répertoires avec parcimonie.
* Utiliser les préfixes en complément.
* Prioriser le FrontMatter pour les infos modifiables.

---

---
La création de dossiers sous-dossiers dans un PKM représente des coûts cachés en matière de noms classements de clics. #arborescence


---
Dans SB : l’arborescence sert à distinguer la nature des pages et les métadonnées servent à organiser.

---
**Ne pas créer de sous-dossiers `Meetings`, `Books`, `Processes`, `Concepts`, etc. par défaut**. #arborescence

---
Privilégier des répertoires par type de contenu. #arborescence
Pas de sous-dossier dans les projets.
Une note peut appartenir à plusieurs projets (géré dans les métadonnées)


----
SB n'exploite pas l'arborescence de fichiers. Il est optimisé pour les relations et liens bidirectionnels, les requêtes et l'utilisation des métadonnées.
Les éléments-clés d'une page sont : Les métadonnées, les liens explicites et les requêtes. #arborescence

---
L'arborescence doit être fonctionnelle et non thématique. #arborescence

---
Organisation par « Type de contenu » vs « usage » #arborescence #hub

L'approche par actionnabilité est intéressante, mais elle est souvent présentée de façon trop dogmatique.

Par exemple :

*   `Notes/Concepts/` → contient des idées à comprendre
*   `Notes/Process/` → contient des procédures à appliquer
*   `Notes/Lieux/` → contient des informations à consulter
*   `Projects/` → contient des résultats à produire
*   `Meetings/` → contient des traces d'événements passés

Ces contenus ont effectivement des **modes d'utilisation différents**.
Ce découpage permet de créer des **hubs très puissants**.
C'est particulièrement pertinent dans SilverBullet.

Par exemple `pro/Projects/` peut devenir un dashboard qui affiche :
*   projets actifs
*   projets en attente
*   projets terminés
*   prochaines échéances
*   dernières notes liées
*   derniers meetings
*   projets sans prochaine action

Et `pro/Meetings/` peut devenir :
*   meetings récents
*   meetings par projet
*   meetings nécessitant un suivi
*   décisions prises récemment

**Je conserverais absolument cette propriété.**
Le risque d'une organisation entièrement basée sur l'actionnabilité est justement de perdre cette capacité à construire des vues cohérentes.

==**Là où je modifierais ton système**==
Je ne toucherais pas tellement à **l'arborescence physique**.
Je changerais plutôt **la manière dont tu qualifies tes pages**.
Autrement dit ajouter par exemple le frontmatter:
```
type: project
status: active
domain: pro
next_action: "Valider la maquette"
review: 2026-08-15
```

ou une note pourrait avoir :
```
type: process
status: active
domain: pro
```

et un compte rendu
pourrait avoir :

```
type: meeting
project: "[[Refonte-site-web]]"
follow_up: true
```

Distinction importante entre information vs action
Pour les notes le vrai piège que j'éviterais : multiplier les catégories
Si tu hésites régulièrement où ranger une note, le dossier n'est probablement pas une bonne dimension de classement.

Notes : Concepts, Process, Infos, Références, Ressources, Guides, Checklists, Méthodes, Idées, etc

Ne pas négliger l'importance de l'inbox, catégoriser les notes à ce niveau avant de les classer dans notes (Soit dans un dossier, soit via les tags.)


**Folder = contexte / nature relativement stable**  
**Metadata = état / actionnabilité**

C'est à mon avis beaucoup plus robuste.

Utilisez des tags et frontmatter:
```
type: project | meeting | note | contact | book | review
status: inbox | active | waiting | someday | completed | archived
domain: pro | perso | asso
project: [[...]]
```


Avec selon les types 
```
next_action:
due:
review_date:
tags:
```


Construis tes dashboards autour de l'actionnabilité
Ex.: projet par statut
Ex.: Projets sans prochaine action