--- tags: - note type: "note" univers: PERSO projects: - "[[02_DOMAINES/PERSO-PKM]]" date: "2026-07-22" priority: 10 --- # Note d’organisation du 22/07/2026 Projet : [[02_DOMAINES/PERSO-PKM]] Dernière version suite à l’échange avec Claude AI : cf. https://claude.ai/chat/162b229e-f330-4b59-8c0e-5d0b9928115d Ce système à été élaboré à partir de nombreuses lectures et s’appuie pour sa mise en oeuvre sur de nombreuses méthodes comme GTD, Auto Focus, etc. Il ne s’agit pas ici tant de décrire les méthode 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. # Système d'organisation personnelle — Silverbullet > Documentation de référence : structure, choix, justifications. À conserver dans `80_Config` et à relire lors de tout doute de classement. ## 1. Principe directeur Ce système repose sur une règle simple, appliquée systématiquement pour trancher les cas ambigus : > **Un dossier sert à cloisonner ce qui structure rarement** (une sphère de vie, un type de fichier lié à un template). **Un attribut de 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 oui → 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. Arborescence de premier niveau ``` 00_Inbox 01_Journal 02_Domains 80_Config 90_Archives ``` | Dossier | Rôle | Pourquoi un dossier (et pas un attribut) | | --- | --- | --- | | `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 | ## 3. Structure d'un Domaine (`PERSO`, `PRO`, `ASSO`) ``` Books/ Contacts/ Mots-de-passe/ Projets/ Notes/ Weekly_Reviews/ Meetings/ ``` 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. ## 4. Le cas PRO : gestion de 50-60 projets ### 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 `statut` (remplace l'ancien dossier `_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. ## 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] terminée ``` **Pipeline** : ``` REVIEW → TODO / WAITING / DUPLICATE → DONE (capture) (clarifié) (terminé) ``` **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. ### Retravailler une tâche à une date précise : échéance vs date de traitement Deux besoins différents, à ne pas confondre : * **Échéance réelle** : la tâche doit être faite *au plus tard* à cette date. Utiliser l'attribut natif de deadline, interrogeable spécifiquement comme telle (alertes de retard, tri par échéance) : ``` * [TODO] [[Projet A]] - Rédiger la note de synthèse 📅 [[2026-03-12]] ``` * **Date de traitement souhaitée**, sans contrainte dure (simplement y repenser/y travailler ce jour-là) : wikilink simple dans le texte de la tâche, comme pour les rappels `WAITING` (§ Liens ci-dessus) : ``` * [TODO] [[Projet A]] - Rédiger la note de synthèse [[2026-03-12]] ``` Ne pas mélanger les deux syntaxes sur une même tâche évite qu'une future requête "tâches en retard" (basée sur l'attribut de deadline) ne déclenche de fausses alertes sur de simples reports de confort. **Report au jour suivant** : modifier directement le lien sur la ligne existante (remplacer l'ancienne date par la nouvelle), sans dupliquer ni déplacer la tâche — cohérent avec le principe "la tâche reste où elle est créée". Si une même tâche est reportée trois fois ou plus, traiter le cas comme une relance récurrente (§ Le cas des doublons) : ajouter une mention courte plutôt qu'un mécanisme automatique. ``` * [TODO] [[Projet A]] - Rédiger la note de synthèse 📅 [[2026-03-12]] (reportée 2x) ``` ### 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. ## 13. Arborescence de référence (vue synthétique) ``` 00_Inbox 01_Journal 02_Domains ├── PERSO/ │ ├── Contacts/ │ ├── Projets/ │ ├── Notes/ (type: note | ressource) │ ├── Weekly_Reviews/ │ └── Meetings/ ├── PRO/ │ ├── Contacts/ │ ├── Projets/ (statut: incubation|actif|pause|clos ; axe: ...) │ ├── Notes/ (type: note | ressource) │ ├── Weekly_Reviews/ │ └── Meetings/ └── ASSO/ ├── Contacts/ ├── Projets/ (association: ...) ├── Notes/ (type: note | ressource) ├── Weekly_Reviews/ └── Meetings/ 80_Config 90_Archives (hors espace Silverbullet actif, cf. §7) ``` ## 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.