# Second Cerveau SilverBullet — Document de référence

  

Ce document rassemble l'architecture, les principes, les templates, les dashboards et les workflows du système d'organisation basé sur Silverbullet. C'est la référence à consulter quand un doute apparaît.

---
Sur cette question précise, j'ai un avis tranché — et il ne colle à aucune des 4 options telles quelles. Je vais d'abord expliquer pourquoi, puis proposer une architecture hybride.

## Le vrai critère de décision : la nature de l'objet, pas le principe

La question à se poser n'est pas "domaine ou type" en bloc, mais **objet par objet** : est-ce que le domaine (PRO/PERSO/ASSO) est une propriété *structurante* de cet objet, ou juste un *attribut de filtrage* ?

- **Projets** : le domaine est structurant. Un projet appartient à un seul domaine, quasiment jamais de doute, et le volume est très asymétrique (50-60 vs 5-10). Le séparer physiquement a un vrai bénéfice : naviguer dans une liste de 55 projets pro sans les 8 perso mélangés dedans, c'est confortable au quotidien.
- **Contacts, Places** : le domaine est souvent flou ou multiple. Un contact rencontré en PRO peut devenir un ami (PERSO), un bénévole ASSO peut être aussi un client PRO. Forcer un classement en dur dans une arborescence, c'est se créer des cas limites en permanence et des doublons/déplacements de fichiers.
- **Notes, Meetings, Reviews** : idem, le type d'objet (réunion, réflexion) est plus stable dans le temps que son rattachement domaine, et beaucoup de notes sont transverses.

Résultat : Option A et D dupliquent une distinction (domaine) qui n'a de sens fort que pour **une seule** catégorie (Projets), et l'imposent partout, y compris là où elle est ambiguë. Option B/C évitent ça mais perdent la possibilité de naviguer vite dans "mes projets pro" sans filtrer.

## Le point sur les préfixes vs frontmatter

Dans SilverBullet, deux mécanismes de filtrage existent et n'ont pas le même rôle :
- **Le frontmatter/tags** (`domain: pro`) — c'est l'outil fait pour les requêtes (`query`), les templates, les filtres croisés (ex: "tous les objets PRO tous types confondus"). C'est plus puissant, plus propre, et **ne pollue pas le nom** de la page.
- **Le préfixe dans le nom** (`PRO-ClientX`) — n'aide qu'à une chose : le *quick switcher* (Ctrl+K), qui matche sur le nom/chemin de page, pas sur le frontmatter. Si tu tapes souvent "pro" pour retrouver vite une page, le préfixe a un intérêt réel que le tag n'a pas.

Donc ce n'est pas un choix binaire : **utilise le frontmatter comme mécanisme principal de filtrage/requête, et n'ajoute un préfixe que là où le dossier ne suffit déjà pas à désambiguïser au quick switch.**

## Architecture recommandée

```
00_Inbox
01_Journal              (daily notes, déjà stable)
02_Projets
├── PRO/
├── PERSO/
└── ASSO/
03_Contacts             (unifié, pas de sous-dossier domaine)
04_Places               (unifié)
05_Organizations        (ASSO structurée, clients PRO, etc. si besoin distinct de Contacts)
06_Notes                (unifié — réflexions, checklists, tuto)
07_Meetings             (unifié, lié aux projets via frontmatter/liens)
08_Reviews
80_Config
90_Archives
```

Points clés :

1. **Seul `02_Projets` est sous-foldérisé par domaine.** C'est le seul endroit où le volume (50-60 vs 5-10) justifie une séparation physique, et où l'appartenance au domaine ne pose jamais question.
2. **Contacts/Places/Notes/Meetings restent plats**, avec un champ frontmatter `domain: pro` / `perso` / `asso` (ou multi-valeur `domain: [pro, asso]` pour les cas mixtes — ex. un contact ASSO qui est aussi client PRO). Ça te permet de faire des requêtes du type "tous les contacts liés à ASSO" sans avoir dupliqué la fiche ni dû trancher un classement arbitraire.
3. **Pas de préfixe systématique.** Le dossier suffit déjà pour Projets. Pour Contacts/Notes, essaie sans préfixe d'abord — le frontmatter + la recherche full-text de SilverBullet couvrent la plupart des besoins. N'ajoute un préfixe ponctuel que si tu constates, en usage réel, que le quick switcher te fait hésiter entre deux pages homonymes (rare si les noms sont bien choisis).
4. Les projets PRO étant nombreux, tu peux enrichir `02_Projets/PRO` avec des sous-dossiers ou des tags de statut (actif/standby/clos) plutôt que de complexifier le domaine — c'est un problème de volume, pas de domaine.

## Pourquoi pas Option A/D telles quelles

Elles semblent rassurantes ("tout est bien rangé"), mais en pratique elles créent une charge de maintenance invisible : chaque nouveau contact, chaque nouvelle note te force à trancher un domaine parfois arbitraire, et si tu changes d'avis plus tard il faut déplacer physiquement la page (ce qui casse les liens internes dans certains cas). Un attribut de frontmatter se change en un clic, sans bouger le fichier.

Si tu veux, je peux te proposer un exemple concret de frontmatter + une requête SilverBullet type pour lister "tous les objets ASSO tous types confondus", pour valider que le système de filtre fonctionne comme prévu avant de migrer tes contenus existants.

Même logique que précédemment : **le dossier reflète une différence de comportement structurel** (volume, workflow, requêtes dédiées), **le frontmatter reflète une différence de nature du contenu**. Les types que tu listes (réflexion, concept, film, livre, tuto) sont tous des variations d'un même comportement — une note qu'on écrit, tague, relit, relie à d'autres. Créer un dossier par type serait reproduire l'erreur qu'on vient d'éviter avec les domaines : multiplier les arborescences pour un problème qui se résout avec un attribut.

## Principe : `type` en frontmatter, pas en dossier

```
06_Notes/
  Le mythe du multitâche.md
  Dune (roman).md
  Parasite (film).md
  Sevrage numérique - concept.md
  Tuto - configurer Syncthing.md
```

```yaml
---
type: reflexion
tags: [productivite, attention]
domain: perso
créé: 2026-09-13
---
```

```yaml
---
type: film
titre: Parasite
réalisateur: Bong Joon-ho
année: 2019
note: 9/10
statut: vu
tags: [cinema, coreen]
domain: perso
---
```

```yaml
---
type: livre
titre: Dune
auteur: Frank Herbert
statut: en cours
tags: [scifi]
domain: perso
---
```

Le nom de fichier reste le titre naturel de la note — pas de préfixe `FILM-` ou `LIVRE-`, le champ `type` fait ce travail proprement et invisible à l'œil.

## Pourquoi ça tient à l'échelle

- **Ajouter un nouveau type** (podcast, expo, série) ne coûte rien structurellement : une valeur `type:` de plus, éventuellement un template. Pas de dossier à créer, pas de page à déplacer si tu changes d'avis sur la catégorisation.
- **Les requêtes deviennent le vrai outil de navigation.** Dans SilverBullet, une page "Films" peut afficher automatiquement toutes les notes `type: film`, triées par note ou année, sans que tu aies à les ranger physiquement. Idem pour une page "Tutos", une page "Concepts", etc. Ce sont des *vues*, pas des *dossiers* — tu peux en avoir autant que tu veux, elles se recalculent seules.

Exemple de requête simple (adapter à la version de SilverBullet, ici avec `query`) :

```query
page where type = "film"
order by année desc
render "templates/liste-films"
```

- **Le croisement domaine × type devient trivial.** "Tous mes concepts liés au PRO" = `type = concept and domain = pro`. Avec une arborescence par type, ce croisement demanderait soit des dossiers imbriqués, soit une gymnastique de tags en plus des dossiers — inutilement lourd.

## Un template par type, pour la cohérence

Là où le dossier ne sert à rien, le **template SilverBullet** sert à tout : il garantit que chaque note "film" a bien réalisateur/année/note, chaque "livre" a auteur/statut, etc., sans que tu aies à t'en souvenir à chaque création. C'est l'équivalent structurant du dossier, mais au niveau du contenu plutôt que du classement — exactement ce qu'il faut puisque le besoin réel est "une structure de champs cohérente par type", pas "un endroit physique différent".

Concrètement : un dossier `80_Config/Templates/` avec `tpl-film.md`, `tpl-livre.md`, `tpl-reflexion.md`, `tpl-tuto.md`, `tpl-concept.md`, invoqués via le slash-command ou le page-picker de SilverBullet à la création.

## Et Places, alors ?

Tu as bien fait de le garder en dossier séparé (`04_Places`), et ça reste cohérent avec le principe : Places a un besoin structurel différent — coordonnées géo, affichage carte potentiel, requêtes spatiales — qui justifie un traitement à part, contrairement à "film" ou "concept" qui n'ont aucune spécificité de ce genre. Si un jour tu ajoutes un plugin carte, tu seras content que Places soit isolé plutôt que noyé dans Notes avec un `type: place`.

## Un seul vrai risque à surveiller

Le champ `type` doit rester une **liste fermée et disciplinée** (tu la documentes dans `80_Config`), sinon tu retombes dans le désordre inverse : des variantes orthographiques (`tuto`/`tutoriel`/`Tuto`) qui cassent tes requêtes silencieusement. Un tableau de référence des types valides, avec le template associé, résout ça une fois pour toutes.

---
Utiliser le terme de GESTION plutôt que AREA ici



---
## 1. Principes fondamentaux

Ces principes gouvernent toutes les décisions de structure et d'organisation.


### 1.1 — Deux couches séparées : action et pensée

Le système combine deux logiques distinctes, chacune à sa place :

\- **Couche pilotage** (projets, tâches, réunions, issues) → structure planifiée à l'avance, champs standardisés, parce qu'à ton volume (50-60 projets) l'improvisation coûte plus cher que la rigidité

\- **Couche réflexion** (Resources, notes de fond) → structure émergente, les liens et regroupements se forment naturellement à l'usage, sans forcer un plan a priori


### 1.2 — Le dossier organise pour l'humain, le frontmatter organise pour la machine

Un dossier est un confort de navigation visuelle. Une requête ne dépend jamais de l'emplacement physique d'un fichier, seulement de ses champs frontmatter (`type`, `domain`, `urgence`, `parent`...). 
Il est possible de garder des habitudes de rangement par dossiers sans jamais casser un dashboard, à condition que le frontmatter reste correct.


### 1.3 — Le domaine (pro/perso/asso) est un filtre, pas une hiérarchie

Un seul arbre pour tout (journal, contacts, notes, etc.), avec un attribut `domain` qui permet de filtrer une vue quand nécessaire. Cela évite de dupliquer la structure trois fois : un projet à cheval sur deux domaines resterait ambigu, et la logique de requête serait à écrire trois fois.
Seul le dossier `PROJETS` est sous divisé par domaine pour faciliter la gestion et les filtres (cf. infra).


### 1.4 — Projet vs Area : le test de la ligne d'arrivée

\- **Area** = standard à maintenir indéfiniment, pas de fin prévue (ex: "Entretenir la maison")

\- **Projet** = résultat final défini, plusieurs étapes dépendantes, se termine et s'archive (ex: "Installer une prise dans le garage")

\- Une tâche isolée sans étapes dépendantes n'est ni l'un ni l'autre : c'est une simple tâche rattachée à une Area.

  

**1.5 — Type vs subtype : ne multiplie pas les types**

Crée un nouveau `type` seulement si le contenu a des champs structurels différents, un cycle de vie propre (statuts), ou mérite un dashboard réellement isolé. Sinon, un `subtype` à l'intérieur d'un type générique (`resource`, `project`) suffit. Ça évite d'avoir à maintenir un dashboard par nature de contenu.

  

**1.6 — Le tier découple l'attention du statut**

`tier` (1/2/3) indique le niveau d'attention actuel, indépendamment du domaine ou de l'avancement. Un projet `tier: 1` est suivi quotidiennement, `tier: 3` n'est consulté qu'en revue périodique. Ça permet de piloter 60 projets sans que la simple lecture du système devienne une charge.

  

**1.7 — Le lien explicite n'est nécessaire que hors contexte**

Une tâche écrite à l'intérieur de sa page projet hérite automatiquement du contexte, sans attribut. Un attribut `\[project: "..."\]` n'est nécessaire que pour une capture faite hors contexte (Inbox, Daily Note, discussion sur un autre sujet).

  

**1.8 — Structure figée dès le départ, contenu libre ensuite**

Les types, champs frontmatter et arborescence de dossiers sont décidés maintenant et ne bougent plus (migrer 60 fichiers a posteriori coûte cher). Le contenu réel des notes, les liens de réflexion et l'organisation fine de Resources peuvent en revanche émerger sans plan rigide.

  

\---

  

## 2. Architecture des dossiers

  

```

🗄️ SecondBrain/
│
├── 📥 Inbox/                        (capture brute, vidé chaque semaine)
│
├── 📁 Projects/
│   ├── Campagne Q4.md                        \[tier: 1, domain: pro\]
│   ├── Transformation Digitale Client Y/      (sous-dossier de confort pour un programme)
│   │   ├── Vue d'ensemble.md                  \[type: program\]
│   │   ├── Phase 1 - Cadrage.md               \[type: project, parent: ...\]
│   │   └── Phase 2 - Déploiement.md           \[type: project, parent: ...\]
│   ├── Installer prise garage.md              \[tier: 3, domain: perso\]
│   └── Réparer voiture.md                     \[tier: 2, domain: perso\]
│
├── 🗂️ Areas/
│   ├── Management Équipe.md          \[domain: pro\]
│   ├── Finances Entreprise.md        \[domain: pro\]
│   ├── Maison.md                     \[domain: perso\]
│   ├── Santé.md                      \[domain: perso\]
│   ├── Voiture.md                    \[domain: perso\]
│   └── Trésorerie.md                 \[domain: asso\]
│
├── 📚 Resources/
│   ├── Normes électriques NFC 15-100.md   \[subtype: process\]
│   ├── Méthodes second cerveau.md         \[subtype: concept\]
│   └── ...
│
├── 👤 People/
│   └── Marie Dupont.md
│
├── 🗓️ Meetings/
│   └── 2026-09-08 Kickoff Q4.md
│
├── 🐞 Issues/                        (optionnel, si tu adoptes le suivi façon GitHub)
│   └── Bug calcul TVA.md
│
├── 📅 Journal/
│   └── 2026-09-08.md   (timeline du jour, pointe vers les pages créées)
│
├── 🗄️ Archives/                      (projets/areas terminés)
│
└── 🧩 Templates/
    ├── template-projet.md
    ├── template-programme.md
    ├── template-area.md
    ├── template-reunion.md
    ├── template-contact.md
    ├── template-ressource.md
    ├── template-issue.md
    └── template-journal.md
```

  

**Points clés de cette arborescence :**

\- Un seul `Projects/`, un seul `Areas/` pour tous les domaines — le tri se fait par `domain:`, jamais par emplacement

\- Sous-dossiers autorisés pour un programme et ses phases, par confort de navigation — le lien logique reste porté par `parent:` en frontmatter, pas par le chemin

\- `Meetings/` est séparé du Journal : à 5-6 réunions/jour, il faut pouvoir les lister et les filtrer par projet sans dépendre de la date. Le Journal ne fait que pointer vers elles chronologiquement

\- Pas de dossier "Tasks" : les tâches vivent toujours dans la page qui les contextualise, remontées par requête

  

\---

  

## 3. Modèle de données : types et champs standards

  

### 3.1 — Types de contenu

  

| Type | Usage | Cycle de vie propre ? |

|---|---|---|

| `project` | Résultat fini, étapes dépendantes | statut actif/attente/terminé |

| `program` | Initiative pluriannuelle à phases multiples | regroupe des projets enfants |

| `area` | Responsabilité continue, sans fin | non — permanent |

| `meeting` | Compte-rendu de réunion | non |

| `contact` | Fiche personne | non |

| `resource` | Référence à consulter (note, tutoriel, process, concept, checklist, lieu...) | non — varie par `subtype` |

| `issue` | Problème à suivre façon ticket | oui — open/in-progress/resolved |

  

### 3.2 — Champs frontmatter standards

  

| Champ | Valeurs | Usage |

|---|---|---|

| `type` | project / program / area / meeting / contact / resource / issue | fonction de la page dans le système |

| `subtype` | libre (tutoriel, checklist, lieu...) | nature du contenu, uniquement pour `resource` |

| `domain` | pro / perso / asso | filtre transversal |

| `tier` | 1 / 2 / 3 | niveau d'attention actuel |

| `status` | active / waiting / done / open / resolved | avancement |

| `parent` | nom exact de la page parente | rattache une phase à un programme, ou un sous-projet |

| `client` | nom exact de la page contact | vue transversale par client |

| `project` | nom exact de la page projet | rattache une réunion, tâche ou issue capturée hors contexte |

| `priority` | low / medium / high / critical | utilisé surtout pour les issues |

  

**Règle de nommage des valeurs texte** : toujours la correspondance exacte avec le titre de la page ciblée (respecte majuscules et accents), car les requêtes filtrent sur correspondance de chaîne.

  

\---

  

## 4. Conventions d'écriture

  

### 4.1 — Tâches

  

```

* \[STATUT\] \[\[03\_PROJETS/Nom-Du-Projet\]\] #domaine - Verbe d'action + objet précis 📅 2026-09-15

```

\- Le lien seul suffit pour rattacher la tâche à son projet : SilverBullet indexe automatiquement les liens d'une tâche dans un champ interne `ilinks`, ce qui alimente aussi le widget natif *Linked Tasks* (affichage automatique en haut de la page projet des tâches ouvertes qui la mentionnent). **Pas besoin d'un attribut `\[project: "..."\]` en plus du lien** — c'est redondant.

\- `#domaine` (`#pro` / `#perso` / `#asso`) : un hashtag simple, avec sa propre autocomplétion, indexé nativement dans le champ `tags`. C'est ce qui permet de filtrer par domaine en requête (le lien seul ne donne accès qu'au nom du projet, pas à son `domain`, donc le tag est nécessaire pour ce filtre précis)

\- `📅 date` = échéance réelle, syntaxe native indexée automatiquement dans le champ `deadline` (compatible avec la commande *Task: Postpone*) — à préférer à un attribut `\[date: ...\]` texte

\- Toujours un verbe explicite ("Envoyer le devis à Marie", jamais "Devis Marie")

  

**Requêtes que ce format permet directement :**

```query

task where tags = "pro" and done = false

```

```query

task where tags = "perso" and done = false

```

  

### 4.2 — Événements (repères temporels planifiés à une heure et une date)

  

Un événement est traité comme une tâche avec un état dédié et un tag `#event` — même moteur, mêmes bénéfices d'indexation :

  

```

* \[PLANNED\] \[\[03\_PROJETS/Nom-Du-Projet\]\] - Réunion avec Pierre 11:00-12:30 📅 2026-09-12 #event

```

\- `\[PLANNED\]` : état personnalisé distinct de `\[TODO\]`, pour ne pas mélanger "à planifier/planifié" et "à faire"

\- La plage horaire en texte libre (`11:00-12:30`) est suffisante si tu consultes toujours l'événement dans sa note du jour (ordre chronologique naturel) ; si tu veux un jour un dashboard agrégé trié par heure, ajoute un attribut léger `\[time: "11:00"\]` en complément — non nécessaire sinon

\- Combine `#event` avec `#pro`/`#perso` pour croiser nature et domaine en requête :

```query

task where tags = "event" and tags = "pro"

order by deadline

```

  

### 4.3 — Jalons simples sans case à cocher (repère informatif, pas une action à traiter)

  

Pour un jalon qu'on ne "coche" jamais (ex: une date de livraison purement informative) :

```

📌 Livraison client \[\[Campagne Q4\]\] 📅 2026-10-15

```

Ou en frontmatter de la page projet concernée : `event: 2026-10-15`

  

### 4.4 — Nommage des pages

  

\- Le titre décrit **le contenu**, jamais les métadonnées (pas de préfixe "Pro-" ou "Perso-" — c'est le rôle de `domain:`)

\- Titre unique et stable dans le temps, pour éviter les ruptures de correspondance texte dans les attributs

\- Un sous-dossier par programme est acceptable pour le confort, mais n'est jamais requis pour que le système fonctionne

  

\---

  

## 5. Templates de contenu

  

Copie chaque bloc ci-dessous dans son fichier `Templates/` correspondant.

  

### `Templates/template-projet.md`

```

\---

type: project

domain: pro

tier: 2

status: active

parent:

client:

deadline:

\---

# {{Titre du projet}}

  

## Objectif

Résultat final attendu, en une phrase.

  

## Contexte

Pourquoi ce projet existe, lien avec l'area ou le programme parent.

  

## Décisions

\- {{date}}:

  

## Ressources liées

  
  

## Réunions

  

​```query

page where type = "meeting" and project = "{{Titre du projet}}"

order by date desc

​```

  

## Tâches ouvertes

  

\_Pas de requête nécessaire ici : le widget natif **Linked Tasks** affiche automatiquement en haut de cette page toutes les tâches ouvertes ailleurs dans l'espace qui la mentionnent via `\[\[{{Titre du projet}}\]\]`.\_

  

## Issues liées

  

​```query

page where type = "issue" and project = "{{Titre du projet}}"

order by priority desc

​```

```

  

### `Templates/template-programme.md`

```

\---

type: program

domain: pro

tier: 1

status: active

client:

horizon:

\---

# {{Nom du programme}}

  

## Vue d'ensemble

Objectif global, budget, jalons majeurs.

  

## Phases

  

​```query

page where type = "project" and parent = "{{Nom du programme}}"

order by phase

​```

  

## Réunions de gouvernance

  

​```query

page where type = "meeting" and project = "{{Nom du programme}}"

order by date desc

​```

```

  

### `Templates/template-area.md`

```

\---

type: area

domain: perso

status: active

\---

# {{Nom de l'area}}

  

## Standard à maintenir

Ce que "bien géré" signifie pour cette area.

  

## Projets liés

  

​```query

page where type = "project" and area = "{{Nom de l'area}}"

​```

  

## Tâches récurrentes

  

​```query

task where page.area = "{{Nom de l'area}}" and done = false

​```

  

## Notes de référence

  

```

  

### `Templates/template-reunion.md`

```

\---

type: meeting

project:

date: {{date du jour}}

domain:

\---

# {{Titre réunion}}

  

## Présents

  
  

## Points abordés

  
  

## Décisions

\-

  

## Tâches

\- \[ \] Verbe d'action + objet précis #domaine 📅 {{echeance}}

  

## Prochaine étape

  

```

Crée cette page via une commande `/reunion`, en renseignant `project:` **dès la création** — c'est ce champ qui alimente automatiquement le Hub du projet concerné.

  

### `Templates/template-contact.md`

```

\---

type: contact

domain:

organisation:

role:

\---

# {{Nom Prénom}}

  

## Coordonnées

  
  

## Contexte relationnel

  
  

## Projets communs

  

​```query

page where type = "project" and client = "{{Nom Prénom}}"

​```

  

## Notes libres

  

```

**Point de vigilance** : pour lister les réunions communes automatiquement par nom de participant, la syntaxe `contains()` n'est pas garantie en v2.10 — teste-la, ou appuie-toi simplement sur les rétroliens natifs affichés en bas de la page contact.

  

### `Templates/template-ressource.md`

Template générique pour toute référence à consulter — note, tutoriel, process, concept, checklist, fiche-lieu, etc.

```

\---

type: resource

subtype:

domain:

tags: \[\]

\---

# {{Titre}}

  

## Source

  
  

## Idée principale (reformulée dans tes mots)

  
  

## Notes détaillées

  
  

## Notes liées

  

```

Valeurs courantes de `subtype` (liste ouverte) : `note`, `tutoriel`, `process`, `concept`, `checklist`, `lieu`, `recette`. Pour un `subtype: lieu`, ajoute librement `adresse:` / `coordonnees:` en frontmatter de cette page précise, sans dupliquer le template.

  

### `Templates/template-issue.md`

Pour un problème complexe qui vit plusieurs jours avec historique de résolution.

```

\---

type: issue

project:

status: open

priority: medium

labels: \[\]

reporter:

assignee:

created: {{date}}

\---

# {{Titre de l'issue}}

  

## Description

Comportement observé vs attendu.

  

## Contexte / Reproduction

  
  

## Journal de résolution

\- {{date}}: ouverture, première analyse

  

## Résolution / Clôture

  

```

Pour une issue légère et rapide à résoudre, inutile de créer une page : utilise une tâche à statut personnalisé directement dans le projet concerné :

```

\- \[TODO\] \[\[Campagne Q4\]\] Bug affichage facture #issue \[priority: high\]

```

Cycle l'état (TODO → IN PROGRESS → RESOLVED) via la commande *Task: Cycle State*.

  

### `Templates/template-journal.md`

Auto-généré chaque jour — sert de timeline, pas de stockage.

```

# {{date}}

  

## Aujourd'hui

  
  

## Pages créées aujourd'hui

  

​```query

page where lastModified >= "{{date}} 00:00" and lastModified <= "{{date}} 23:59"

​```

```

  

\---

  

## 6. Dashboards

  

### `Dashboard-Principal.md` — consulté chaque matin

```

# Dashboard Principal

  

## Projets Tier 1 (suivi quotidien)

  

​```query

page where type = "project" and tier = 1 and status = "active"

​```

  

## Programmes actifs

  

​```query

page where type = "program" and status = "active"

​```

  

## Tâches urgentes

  

​```query

task where done = false and deadline <= "{{date+3j}}"

​```

  

## Réunions de la semaine

  

​```query

page where type = "meeting" and date >= "{{debut semaine}}"

order by date asc

​```

```

  

### `Dashboard-Perso.md` (dupliquer pour Pro / Asso)

```

# Dashboard Perso

  

​```query

page where type = "project" and domain = "perso" and status = "active"

order by tier

​```

  

​```query

page where type = "area" and domain = "perso"

​```

```

  

### `Dashboard-Coherence.md` — revue hebdomadaire, 10-15 min

```

# Dashboard Cohérence

  

## Projets sans tier défini

  

​```query

page where type = "project" and tier = null

​```

  

## Projets sans domaine défini

  

​```query

page where type = "project" and domain = null

​```

  

## Réunions sans projet associé

  

​```query

page where type = "meeting" and project = null

​```

  

## Inbox non traité depuis plus de 7 jours

  

​```query

page where parentPage = "Inbox" and lastModified <= "{{date-7j}}"

​```

```

  

### `Dashboard-Client-{{nom}}.md` — vue transversale par client

```

# Dashboard {{Client}}

  

​```query

page where client = "{{Client}}"

order by type

​```

```

  

### `Dashboard-Ressources.md`

```

# Ressources

  

​```query

page where type = "resource"

order by subtype

​```

  

## Tutoriels uniquement

  

​```query

page where type = "resource" and subtype = "tutoriel"

​```

  

## Checklists uniquement

  

​```query

page where type = "resource" and subtype = "checklist"

​```

```

  

### `Dashboard-Issues.md`

```

# Issues ouvertes

  

​```query

page where type = "issue" and status = "open"

order by priority desc

​```

  

## Issues critiques tous projets

  

​```query

page where type = "issue" and priority = "critical" and status != "resolved"

​```

```

  

\---

  

## 7. Workflows d'usage

  

### 7.1 — Chaque matin (10-15 min)

1. Ouvrir `Dashboard-Principal` → ne regarder que les projets `tier 1` et les tâches urgentes

2. Choisir 3 à 5 tâches prioritaires du jour, liées à leur projet

3. Vérifier les réunions du jour, caler les créneaux libres

  

### 7.2 — Pendant une réunion

1. Créer la page via `/reunion`, renseigner `project:` **immédiatement**

2. Capturer décisions et actions en direct, pas après coup

3. Transformer chaque suivi en tâche datée dans la page — le contexte est hérité automatiquement

  

### 7.3 — Fin de journée (5 min)

\- Vérifier que chaque réunion du jour a bien sa page (le Journal les liste automatiquement)

\- Ranger l'Inbox si évident, sinon laisser pour la revue hebdo

  

### 7.4 — Revue hebdomadaire (15-20 min)

1. `Dashboard-Coherence` → rattraper les projets/tâches mal taggés

2. Reclasser les `tier` selon l'urgence réelle de la semaine à venir

3. Vider l'Inbox restant

  

### 7.5 — Création d'un nouveau projet

1. Dupliquer `template-projet.md`, renommer avec un titre descriptif et stable

2. Renseigner `domain`, `tier`, `deadline` si connue

3. Si c'est une phase d'un programme existant, renseigner `parent:`

4. Si un client est concerné, renseigner `client:`

  

### 7.6 — Décider Area vs Projet vs simple tâche

| Situation | Choix |

|---|---|

| Action unique, sans étapes dépendantes | Tâche simple dans l'Area |

| Plusieurs étapes, résultat final, se termine | Projet (mini ou classique), lié à l'Area |

| Pas de fin prévue, standard à maintenir | Area elle-même |

  

### 7.7 — Décider Type vs Subtype pour une nouvelle nature de contenu

Poser la question : ce contenu a-t-il des champs structurels différents, un cycle de vie propre, ou mérite-t-il un dashboard isolé ?

\- Oui → nouveau `type`

\- Non → `subtype` dans `resource` (ou le type générique concerné)

  

\---

  

## 8. Limites connues du système

  

\- Pas de notifications ni d'alertes — garde un agenda externe pour les rappels avec notification

\- Pas de collaboration temps réel multi-utilisateurs — pour un tracker d'équipe, garde un vrai outil (GitHub Issues, Jira) et lie l'URL depuis la page projet

\- La syntaxe exacte des requêtes (opérateurs de date, fonctions comme `contains()`) doit être vérifiée sur ta version 2.10 installée ; SilverBullet propose aussi un langage de requêtes plus avancé basé sur Space Lua si la syntaxe classique `page where ...` montre ses limites sur un cas précis

  

\---

  

*Ce document est lui-même une ressource : range-le dans `Resources/` avec `subtype: process`, tier non applicable, et mets-le à jour à chaque évolution structurelle du système.*