--- tags: - note - ressource - silverbullet - organisation type: "ressource" univers: PERSO projects: - "[[02_DOMAINES/PERSO-PKM]]" date: "2026-07-29" priority: 10 --- # Système d'organisation personnelle — Silverbullet Ce document est basé sur l’échange suivant avec Claude AI : cf. https://claude.ai/chat/162b229e-f330-4b59-8c0e-5d0b9928115d Documents à intégrer: * [[03_NOTES/Ressources/SB_Organisation]] * [[04_NOTES/ORGANISATION/SB_Organisation_02]] * [[03_NOTES/ORGANISATION/SB_Organisation/SYNTHESE]] * [[03_NOTES/SB_Organisation2026]] * [[04_NOTES/ORGANISATION/SB_Reorganisation_20260722]] * [[04_NOTES/ORGANISATION/SB_Reorganisation_20260721]] * [[04_NOTES/ORGANISATION/organisation-silverbullet-chatgpt-2/SYNTHESE]] * [[04_NOTES/ORGANISATION/organisation_silverbullet_chatgpt_20260105/Synthese]] Ce système à été élaboré à partir de nombreuses lectures et s’appuie pour sa mise en oeuvre sur de différentes méthodes comme GTD, Auto Focus, Podomoro, PARA, etc. Il ne s’agit pas ici tant de décrire les méthodes de gestion de l’information et des projets que de définir une implémentation dans le cadre de l’utilisation de l’application Silverbullet. ## Pourquoi utiliser Silverbullet ? Au delà des conditions techniques et idéologiques (ex.: Silverbullet est open source), il s’agit de construire un système répondant à des enjeux précis. Ce dernier vise notamment **la simplicité** et **l’efficacité**. Pour cela il est nécessaire d’apporter : * De la lisibilité * De la clarté * De la cohérence * De la centralisation * De la routine dans les process * De l’automatisation dans les processus Silverbullet permet de construire une couche sémantique et relationnelle offrant une vue transverse e la connaissance. L’utilisation de fichier markdown garantit la pérennité de l’information et facilite l’automatisation des traitements. ## Les principes directeurs Ce système repose sur des règles simples : ### 1. Dossiers et Attributs, 2 outils d’organisation complémentaires **Un dossier sert à cloisonner ce qui évolue rarement** (une sphère de vie, un type de fichier lié à un template). **Un attribut du frontmatter sert à qualifier ce qui change** dans le temps ou doit être filtré transversalement (statut, catégorie, nature du contenu). En cas de doute sur "dossier ou attribut ?", la question à se poser est : *est-ce que cette information va changer au cours de la vie du fichier, ou sert-elle à le retrouver parmi d'autres ?* * Si l’information va évoluer → attribut. * Si c'est stable et sert à isoler un espace de travail → dossier. Ce système ne suit pas une méthode existante (PARA, IPCRA) de façon stricte. Il s'en inspire mais introduit un niveau de séparation par **Domaines de vie**, absent de ces méthodes de référence, car adapté à un contexte spécifique : trois sphères (PRO, PERSO, ASSO) aux logiques, rythmes et niveaux de confidentialité différents, avec un volume de projets PRO (50-60 actifs) largement supérieur à l'usage individuel classique visé par PARA/IPCRA. ### 2. Source de vérité et optimisation Le système doit reposer sur **une seule source de vérité et zéro duplication**. De même, éviter de manipuler les information (ex.: copier/coller d’une page à l’autre). C’est la combinaison entre la gestion de attributs des pages (ou tags pour les items) et les requêtes qui doivent permettre d’identifier les informations importantes du moment. ## L’arborescence des dossiers ### Vue générale synthétique Arborescence construite dans un vision pragmatique et opérationnelle. Dois faciliter la création et la recherche des informations. Reste volontairement simple en limitant les niveaux (4 au maximum), le nombre de clics et les risques de redondances de classement. Les dossier de la structure de base sont en majuscule. ``` 00_INBOX 01_JOURNAL 02_DOMAINS ├── PERSO/ │ ├── CONTACTS/ │ ├── PROJETS/ │ ├── NOTES/ (type: note | ressource) │ ├── WK_REVIEWS/ │ └── MEETINGS/ ├── PRO/ │ ├── CONTACTS/ │ ├── PROJETS/ (statut: incubation|actif|pause|clos ; axe: ...) │ ├── NOTES/ (type: note | ressource) │ ├── WK_REVIEWS/ │ └── MEETINGS/ └── ASSO/ ├── CONTACTS/ ├── PROJETS/ ├── NOTES/ (type: note | ressource) ├── WK_REVIEWS/ └── MEETINGS/ 80_CONFIG 90_ARCHIVES (hors espace Silverbullet actif, cf. §7) ``` ### Détail du niveau 1 (racine) Numéroté pour faciliter la recherche et stabiliser la structure. Tous les noms de dossiers en majuscule. Les dossiers `00_INBOX` et `01_JOURNAL` sont situés directement à la racine car ils constituent des éléments transversaux de l’organisation. Le dossier `01_JOURNAL` joue notamment le rôle d’agenda et de référence temporelle pour organiser et piloter l’action. Une journée n’est pas spécifique à un domaine. Elle peut par contre rassembler des informations et éléments de plusieurs domaines (projets, notes, réunions, etc.). > **tip** Tip > Dans Silverbullet, chaque dossier est également une page (et fichier markdown). Il sert de point d’entrée et peut servir de tableau de bord pour réaliser des requêtes et disposer d’une vision transversale sur le contenu du dossier. ``` 00_INBOX/ 01_JOURNAL/ 02_DOMAINS/ 80_CONFIG/ 90_ARCHIVES/ ``` | Dossier | Rôle | Usage | | --- | --- | --- | | `00_INBOX` | Capture rapide, non triée | Zone de transit par nature, sans lien avec
un contenu qualifié | | `01_JOURNAL` | Capture quotidienne brute, au fil de l'eau | Rythme et nature d'écriture distincts
des Weekly Reviews (synthèse
structurée) — voir §6 | | `02_DOMAINS` | Les trois sphères de vie | Cloisonnement stable, avec enjeux de
confidentialité différents | | `80_CONFIG` | Templates, requêtes, documentation du système | Configuration technique, jamais un
contenu de connaissance | | `90_ARCHIVES` | Contenu clos, non actif | Voir §7 — à sortir de l'espace actif
Silverbullet | ### Structure du niveau 2 (domaine) ``` CONTACTS/ PROJETS/ NOTES/ WK-REVIEWS/ MEETINGS/ BOOKS/ ``` Chaque dossier correspond à **un type de fichier et un template dédié** — c'est le seul critère qui justifie ces sous-dossiers : ils ne varient pas dans le temps, contrairement au statut ou à la catégorie d'un projet. #### Pourquoi pas un dossier par projet contenant ses propres Notes/Meetings ? **Contre-exemple rejeté** : créer `Projets/Projet_X/Meetings/` et `Projets/Projet_X/Notes/` pour chacun des 50-60 projets PRO. * Ça multiplie les niveaux d'arborescence (60 × 2 sous-dossiers). * Ça rend impossible une vue transversale rapide ("tous les meetings de la semaine", "toutes les notes récentes"). **Solution retenue** : dossiers centralisés par type + liaison via frontmatter (`projet: [[Projet X]]`) + live query Silverbullet affichant, sur la page du projet, tous les meetings et notes liés. La vue "par projet" est reconstituée par requête, pas par arborescence physique. ## Les types de pages et de contenu Les informations sont gérées par type de contenu. Chaque type est isolé dans un dossier spécifique. Il se caractériqe notamment par les propriétés définies dans le frontmatter du fichier et les process associés. Les types de contenus sont: * inbox * journal * contact * projet * note * meeting * book ## Gestion des `PROJETS` ### Définition plusieurs niveau de projet => globaux (3 à 10) => projet => action (micro) ### Template d’une page projet Une page de type PROJET répond à la structure suivante. ``` --- priority: 10 type: "project" tags: * "project" univers: PERSO axe: "" # Renseigné principalement pour le domaine "PRO" title: "" # Correspond au nom de la page du projet status: "active" # Options: active, closed, in progress, someday urgence: "haute" # Options: haute, normale, basse start: "2026-01-25" due: "2026-01-25" end: "2026-01-25" date: "2026-01-25" --- # TITLE ## URGENT ## NEXT ## TODO ## EVENTS ## HISTORIQUE ``` ### Propriétés et attributs d’une page projet Certains attributs sont réservés au domaine “PRO” car il apporte une certaine complexité de gestion avec parfois de 50 à 60 projets actifs simultanément. #### Attribut `type` #### Attribut `tags` #### Attribut `area` Option : PERSO, PRO, AMM #### Attribut `axe` Chaque projet PRO est lié à un axe (Pilotage, Animation, Outils, Données, etc.) via le frontmatter, et non via un sous-dossier par axe. * **Pourquoi** : un projet peut évoluer d'axe, et le classement par axe doit permettre des vues croisées (ex. "tous les projets Pilotage, tous statuts confondus") sans dupliquer ou déplacer de fichiers. #### Attribut `title` #### Attribut `status` Options: active, closed, in progress, someday, incubation **Ancien choix (à faire évoluer)** : un sous-dossier `Projets/_INCUBATION/` pour les idées de projet en maturation. **Contre-exemple du problème** : faire "grandir" un projet nécessite de déplacer physiquement le fichier hors de `_INCUBATION`, ce qui peut casser des liens internes et demande un geste manuel à chaque changement de statut. **Nouveau choix recommandé** : un champ `statut: incubation | actif | pause | clos` dans le frontmatter. * **Exemple** : passer un projet d'incubation à actif = modifier une seule ligne de frontmatter, aucun déplacement de fichier. * Une page tableau de bord (`PRO - Vue d'ensemble`) affiche les projets filtrés par statut et par axe via une requête, servant de substitut à la navigation par dossiers. #### Attribut `urgence` Options: haute, normale, basse #### Attributs `start`, `due`, `end` et `date` ### Cycle de vie d’un projet Décrire l’usage et le worflow * Création d’un projet * utiliser slash ou template... * ajouter lien dans une autre page * Gestion (cf. woorkflows) * Fermeture ## Gestion des tâches ## Gestion des notes et ressources ### Gestion des événements ## Gestion des contacts **Revue de projet** > **tip** Revue de projet > Ne pas créer de type spécifique pour les revues de projet. > Gérer les revues de projet directement dans la page projet, dans une section dédiée, organisée date par date avec les points-clés. > Ne pas reprendre les tâches dans la partie revue de projet. > **info** Gestion des tâches > Indiquer toujours dans les tâches le lien vers le projet concerné. > Indiquez également le lien vers la date si elle est significative. > Utiliser les tags #next et #URGENT pour faciliter la recherche et le tri des tâches. > Laisser les tâches dans leur contexte de saisie. Ne pas faire de copier-coller. La récupération des tâches dans la page projet se fait via des requêtes. > Le statut `REVIEW` d'une tâche devient inutile dans ce cas. > **info** Gestion des événements > Les événements sont renseignés sous forme d'items dans la page du jour concerné. Un tag #event spécifique permet d’identifier et de filtrer rapidement les événements. > Un lien vers la page projet de l'événement et la date est ajouté systématiquement pour faciliter le requêtage à partir de la page projet. > La création d'une page du type “MEETING” n'est réalisée qu'en cas de prise de notes. ## 4. Le cas PRO : gestion de 50-60 projets ## 5. Notes vs Ressources : critère de distinction **Problème initial** : incertitude récurrente sur le rangement (ex. liste des logiciels installés, notes prises sur une vidéo). **Critère retenu** : la distinction n'est pas thématique mais **temporelle**. * **Note** : trace d'un moment précis, non destinée à être mise à jour, qui a du sens dans son contexte temporel (une réflexion, une lecture ponctuelle). * **Ressource** : contenu de référence, évolutif, consulté et mis à jour dans la durée, sans lien fort avec sa date de création. | Exemple | Nature | Justification | | --- | --- | --- | | Liste des logiciels à réinstaller sur un PC | Ressource | Destinée à être mise à jour, consultée occasionnellement sans lien avec sa date de création | | Notes prises pendant le visionnage d'une vidéo sur l'IA | Note (par défaut) | Capture ponctuelle datée ; devient une Ressource si son contenu est extrait et enrichi dans un document de référence sur le sujet | **Choix d'implémentation** : un seul dossier `Notes/` par domaine, avec un champ `type: note | ressource` en frontmatter, plutôt que deux dossiers séparés (`Notes/` et `Ressources/`, ce dernier resté inutilisé jusqu'ici). Le tri se fait par métadonnée et requête, pas par emplacement. ## 6. Journal vs Weekly Reviews Ces deux éléments coexistent et doivent rester distincts par leur fonction : * **Journal** (`01_Journal`, transversal, hors domaines) : capture brute et quotidienne, au fil de l'eau. * **Weekly Reviews** (par domaine) : synthèse structurée, orientée bilan et pilotage, à fréquence hebdomadaire. **Point de vigilance** : si les deux finissent par contenir le même type de contenu à des fréquences différentes, la distinction perd son sens. La règle à appliquer : le Journal ne contient jamais de bilan structuré ; la Weekly Review ne contient jamais de capture brute non retravaillée. ## 7. Archives (`90_Archives`) **Problème constaté** : les fichiers archivés restent indexés par Silverbullet, ce qui ralentit progressivement la recherche et l'indexation globale de l'espace de travail. **Choix retenu** : séparer l'archive *froide* de l'espace actif plutôt que la vider. * Un projet passe en archive dès qu'il est marqué `statut: clos` (au fil de l'eau, sans attendre une session dédiée). * Une fois par an (ou dès qu'un ralentissement est perceptible), les archives sont déplacées hors de l'espace Silverbullet actif — vers un espace Silverbullet distinct ou un simple dossier non synchronisé — consultable ponctuellement mais non indexé en continu. **Contre-exemple** : supprimer le contenu de l'archive pour gagner en performance. Rejeté, car cela fait perdre l'historique ; le problème réel est l'indexation continue, pas l'existence du contenu. ## 8. Gestion des tâches (méthode finalisée) ### Principe général Les tâches restent **à l'endroit où elles sont créées** (ex. dans les notes de la réunion), pour bénéficier du contexte de saisie. On ne les déplace ni ne les recopie jamais physiquement : c'est la requête qui les fait apparaître là où on en a besoin (page projet, tableau de bord), pas un copier-coller manuel. C'est l'application directe du principe directeur du §1 (attribut/statut plutôt que déplacement de fichier), appliqué cette fois à l'intérieur même d'un fichier. ### Statuts personnalisés : le cycle de vie de la tâche ``` * [REVIEW] tâche saisie, pas encore triée/clarifiée * [TODO] tâche clarifiée, lien projet vérifié, prête à l'exécution * [WAITING] tâche en attente d'un tiers (délégation, réponse externe) * [DUPLICATE] redite d'une tâche déjà existante ailleurs (done = true) * [ABORTED] tâche annulée (done = true) * [DONE] terminée (done = true) ``` **Pipeline** : ``` REVIEW → TODO / WAITING / DUPLICATE → DONE → ABORTED (capture) (clarifié) (terminé) (annulé) ``` **Différence entre `STATUT` et `ETAT` :** le statut indique le parcours de la tâche dans son cycle de vie. L’état indique simplement si la tâche reste à réaliser ou non (`done=true`). Cela facilite l’identification des tâches sur lesquelles porter son attention quelque soit leur statut. **Pourquoi un statut `REVIEW`** : une tâche saisie en réunion n'est pas toujours "propre" (lien projet oublié dans le feu de l'action, formulation trop vague, pas toujours une vraie tâche actionnable). `REVIEW` devient le statut de capture par défaut — il remplace l'ancien tag `#TODO` — et évite que des captures brutes non vérifiées polluent les requêtes de projet, qui doivent rester fiables. La revue hebdomadaire a pour rôle précis de vider la file `REVIEW` (`query task where state = "REVIEW"`), pas de scruter l'ensemble des réunions à la recherche d'oublis. **Pourquoi séparer `state` (cycle de vie) et priorité** : un statut à valeur unique ne peut pas représenter une tâche à la fois urgente et en attente d'un tiers (cas fréquent, ex. relancer quelqu'un en urgence). La priorité et les cas particuliers sont donc gérés par un axe distinct — les tags — plutôt que noyés dans le statut. ### Tags : les cas particuliers (3 à 5 maximum) Exemples retenus : `#URGENT`, `#next`. Un nombre volontairement limité, pour ne pas recréer la complexité qu'on cherche à éviter. Les tags couvrent l'axe "priorité / traitement particulier", indépendant du cycle de vie porté par le statut. ### Liens : project et journal comme mécanisme de rappel natif **Lien vers une page projet, de façon systématique** : ``` * [TODO] [[PROJET-A]] - Envoyer le compte rendu de la réunion du 03/03/2026 à Pierre ``` Double bénéfice : la tâche apparaît automatiquement dans les *liens entrants* (linked mentions) de la page projet — sans requête à écrire — **et** reste filtrable explicitement par une requête ciblée (ex. ne montrer que les tâches non terminées). **Lien vers une page du Journal, quand c'est pertinent** (rappel à une date précise) : ``` * [WAITING] Envoyer le [[2026-03-15]] les documents à Pierre en vue de notre prochaine rencontre ``` Même mécanisme : la tâche apparaît automatiquement ce jour-là dans le journal, comme rappel gratuit — pas seulement comme traçabilité. ### Le cas des doublons ``` * [DUPLICATE] Contacter M. A pour organiser un COPIL → voir tâche du 03/03 dans [[PROJET-A]] ``` Le statut `DUPLICATE` (plutôt qu'un `[x]` coché ou un tag ad hoc) évite l'ambiguïté "fait vs redite" identifiée précédemment : une tâche marquée `DONE` doit toujours signifier un travail réellement accompli, jamais une simple redondance résolue. Le lien vers la tâche d'origine permet, si besoin, de compter les relances et de repérer les tâches qui patinent. ### Requêtes types ``` query task where state = "REVIEW" -- file d'attente à trier (revue hebdo) query task where state = "TODO" and page links to PROJET-A -- tâches d'un projet query task where state = "WAITING" -- tout ce qui est en attente d'un tiers ``` ## 9. Gestion des événements Un événement (réunion, rendez-vous) est de nature différente d'une tâche : c'est un créneau qui s'écoule, pas une action à accomplir. Il partage cependant un mécanisme de notation commun avec les tâches (lien vers le Journal), pour ne pas multiplier les conventions d'écriture. ### Notation systématique de la date Contrairement aux tâches (§8), où le lien vers le Journal n'est utile qu'en cas de notation anticipée depuis une autre page, la date est **systématiquement** liée pour un événement, quel que soit l'endroit où il est noté (y compris dans la page du jour elle-même). Ce choix privilégie une écriture standardisée, indépendante du contexte de saisie, au prix d'une légère redondance quand l'événement est noté le jour même. ``` * [PLANNED] [[2026-03-10]] 10:00-12:00 [[Projet A]] - Point de suivi mensuel #event ``` ### Statuts dédiés aux événements ``` PLANNED événement à venir (par défaut à la création) DONE événement passé. Présence confirmée (done = true) MISSING événement passé. Absence constatée (done = true) ABORTED événement annulé (done = true) ``` Vocabulaire volontairement distinct du cycle de vie des tâches (`TODO / WAITING / DUPLICATE / DONE`, §8) : un événement n'est jamais "à faire", il est "à venir". Réutiliser le même vocabulaire mélangerait deux natures d'objets différentes dans les mêmes requêtes et casserait la fiabilité des vues construites sur les tâches. On retrouve ici la distinction entre `STATUT` et `ETAT` que permet de savoir si l’événement a eu lieu ou non, indépendamment du statut. ### Tag `#event` Isole le registre "événement" du registre "tâche" au niveau des requêtes, indépendamment du vocabulaire de statut : ``` query task where tags = "event" -- agenda (tous les événements) query task where state = "TODO" and tags != "event" -- vraies tâches uniquement ``` Ce tag ne compte pas dans le plafond des 3-5 tags de cas particuliers de tâches (`#URGENT`, `#next`, §8) — il relève d'un registre différent (nature de la ligne, pas priorité d'une tâche). ### Coexistence tâche / événement Un événement nécessitant une préparation garde une tâche liée distincte plutôt que de fusionner les deux objets dans une seule ligne : ``` * [TODO] [[Projet A]] - Préparer le support pour le [[2026-03-10]] * [PLANNED] [[2026-03-10]] 10:00-12:00 [[Projet A]] - Point de suivi mensuel #event ``` ### Note dédiée dans `Events/` Créer une note séparée uniquement si le contenu dépasse la simple date/heure/projet (ordre du jour à préparer, documents à apporter, décisions attendues, participants externes), avec un lien depuis la ligne événement. Si l'événement se limite à un créneau à honorer sans préparation, la ligne seule suffit. ### Format de l'heure Format constant `HH:MM-HH:MM`, pour permettre l'extraction fiable de l'heure si une requête d'agenda en a besoin un jour. ## 10. Conventions de nommage Principe : un nom de fichier a deux rôles différents — **lisibilité humaine** (affichage dans les liens `[[...]]`) et **robustesse technique** (synchronisation, scripts). Les règles ci-dessous distinguent les deux plutôt que d'imposer une convention unique partout. | Élément | Convention | Justification | | --- | --- | --- | | Dossiers système (premier niveau) | Casse initiale majuscule, préfixe numérique + underscore (`00_Inbox`) | Cohérence stricte requise sur une structure fixe et rare | | Fichiers de contenu (projets, contacts, notes) | Casse naturelle du titre, espaces et accents autorisés (`Refonte SI Client X.md`) | C'est ce texte qui s'affiche tel quel dans les liens ; la lisibilité prime | | Meetings, Journal | Préfixe date ISO (`2026-03-21-Point-suivi.md`) | Le tri alphabétique = tri chronologique, lisible sans requête | | Projets, Contacts, Notes, Ressources | Titre seul, aucun préfixe numérique ni date | La date de création existe déjà en métadonnée ; un préfixe n'apporte rien et complique le renommage | Règles transversales : * **Tiret (`-`)** : à l'intérieur des noms de fichiers de contenu composés de plusieurs mots (lisibilité). * **Underscore (`_`)** : réservé aux éléments structurels du système (préfixes de tri des dossiers). * **Accents dans les noms de fichiers** : à éviter par précaution en cas de synchronisation multi-OS (source classique de duplication silencieuse) — garder l'accent dans le titre affiché, pas dans le nom physique. ## 11. Tableaux de bord Quatre pages de requêtes, à des fréquences différentes, plutôt qu'un tableau unique fourre-tout : 1. **`PRO - Vue d'ensemble`** (consultation fréquente) : projets `statut: actif` groupés par `axe`, projets en incubation à examiner, projets en pause, alerte sur les projets actifs sans activité récente. 2. **`Revue hebdomadaire`** : file d'attente `REVIEW` à trier, tâches `WAITING` à relancer, meetings de la semaine écoulée/à venir, notes créées dans les 7 derniers jours (à requalifier note → ressource si besoin). 3. **`ASSO - Vue d'ensemble`** : projets par association, groupés par statut. 4. **`Maintenance du système`** (mensuelle/trimestrielle) : projets `statut: clos` non encore déplacés vers l'archive froide, notes orphelines (sans lien vers un projet), volumétrie par dossier pour anticiper le moment de purger l'archive active. ## 12. Processus quotidien / hebdomadaire / mensuel Principe directeur : chaque tableau de bord est le **miroir** d'un rituel réellement suivi — les sections d'une page de requêtes doivent correspondre, dans le même ordre, aux étapes du rituel. Si le rituel change, le tableau de bord change avec lui ; il ne doit jamais dériver silencieusement de la donnée disponible. ### Quotidien (2-5 min, aucune page dédiée) Objectif unique : ne rien laisser filer entre deux revues hebdomadaires, sans reproduire le hebdo en miniature. 1. Coup d'œil au **Radar** : tâches `#URGENT` non terminées, tous domaines confondus. 2. Aucune action requise pour les rappels `WAITING` liés au Journal — ils apparaissent automatiquement en liens entrants sur la page du jour. 3. En réunion : capture en `[REVIEW]`, avec lien projet si possible sur le moment (sinon, rattrapage en hebdo — ne pas casser le rythme de la réunion pour ça). 4. `00_Inbox` : rangement uniquement si un élément saute aux yeux et prend 10 secondes. Le reste attend le hebdo — l'Inbox n'est pas censé être vide en permanence. ### Hebdomadaire (30-45 min, page `Revue hebdomadaire`, un template par domaine) L'ordre suit le pipeline des tâches et respecte la distinction Journal (brut) / Weekly Review (synthèse, §6) : on **traite** ici, on ne recapture pas. 1. **Vider la file `REVIEW`** : chaque tâche passe en `TODO`, `WAITING` ou `DUPLICATE`, avec lien projet vérifié/ajouté si manquant. 2. **Relancer les `WAITING`** échues ou approchant de leur date : mettre à jour la relance imbriquée si le sujet patine encore. 3. **Parcours systématique par axe** (PRO) ou par association (ASSO) : dérouler les projets actifs un par un, dans un ordre stable, indépendamment des urgences déjà traitées au point 1. 4. **Notes récentes de la semaine** : requalifier chacune en `note` ou `ressource` (critère temporel/atemporel, §5) — ne pas laisser cette qualification traîner plus d'une semaine. 5. **Meetings à venir** : vérifier que les prochains rendez-vous ont bien un lien projet en frontmatter. 6. **Écrire la synthèse** dans `Weekly_Reviews/` : bilan structuré, jamais de capture brute. Ce rituel se répète à l'identique pour chaque domaine via le même template paramétré (§11) — seule la charge diffère selon le volume. ### Mensuel (45-60 min, page `Maintenance du système`) On ne relit pas ce que le hebdo a déjà vu — on cherche des signaux de dérive que la fréquence hebdo ne capte pas : 1. **Projets clos non archivés** : bascule effective vers `90_Archives`. 2. **Fréquence des `DUPLICATE`** sur le mois écoulé : un sujet qui revient souvent en doublon patine structurellement — à remonter explicitement. 3. **Projets actifs sans modification depuis 4+ semaines** : décision explicite (relancer, mettre en pause, clore) — jamais de statut "actif" mort en silence. 4. **Projets en incubation** : décision go/no-go, pas de maturation infinie sans échéance. 5. **Volumétrie et performance** : si l'espace actif ralentit, c'est le moment de migrer l'archive froide hors de Silverbullet (aucune fréquence fixe imposée — le signal de ralentissement suffit, §7). 6. **Les tags** : toujours 3 à 5 ? Un nouveau cas particulier récurrent chaque mois signale qu'il mérite son propre tag plutôt que d'être forcé dans un existant. ### Règle de sobriété transversale Si une étape d'un de ces rituels n'est pas suivie pendant un mois complet, ne la maintenez pas par principe : simplifiez-la ou abandonnez-la, et ajustez ce document en conséquence. Un rituel non tenu dans la durée est pire qu'un rituel absent, car il donne une fausse impression de couverture. ## 14. Points ouverts / à surveiller dans le temps * Vérifier que la distinction Journal / Weekly Review reste tenue en pratique (§6). * Vérifier dans l'usage réel que le statut `REVIEW` est bien vidé à chaque revue hebdomadaire et ne s'accumule pas silencieusement (§8). * Évaluer après quelques semaines si 2 tags suffisent (`#URGENT`, `#next`) ou si un 3e cas particulier récurrent justifie d'en ajouter un (§8, plafond fixé à 3-5). * Réévaluer périodiquement (ex. tous les 6 mois) si le volume de projets PRO nécessite des tableaux de bord supplémentaires par axe ou par statut. ## Workflows ### Revue et gestion quotidienne 1. Traiter les points en suspend de la veille (cf. page du jour correspondant) 2. Aller sur la page du jour et la créer si besoin * Mettre à jour les événement de la journée * Lister les tâches à faire 3. Aller sur la page des tâches par statut : URGENT, NEXT, TODO ### Revue hébdomadaire ### Revue mensuelle ### Revue annuelle