--- tags: - note type: "note" univers: PERSO projects: - "[[02_DOMAINES/PERSO-PKM]]" date: "2026-07-21" priority: 10 --- # Réflexion sur la réorganisation de Silverbullet ## Question initiale J'utilise Silverbullet comme application de gestion de la connaissance, notamment pour mes projets, notes, tâches, événements. J'ai distingué 3 grands domaines : PERSO, PRO et ASSO. Au niveau PRO, je suis directeur de projets et je supervice 50 à 60 projets en parallèles. Pour certains je suis dans l'opérationnel, tandis que pour d'autres je suis dans le suivi, le conseil et le pilotage. Au niveau ASSO je suis investi assez fortement dans 2 associations. J'ai déjà testé plusieurs systèmes d'organisation de fichiers en me basant notamment sur le système PARA et le système IPCRA d'Eliott Meunier. Cependant j'ai une réelle difficulté à trouver une arborescence qui réponde à mon besoin et que j'arrive à utiliser et maintenir dans le temps. Mon système actuel se base sur l'arborescence de premier niveau suivante: * 00_Inbox * 01_Journal * 02_Domains * 80_Config * 90_Archives Pour chaque domaine, dans le dossier "02_Domains", la sous-arborescence suivante: * Contacts = 1 fichier *.md par contact * Projets = 1 fichier *.md par projet * Notes = 1 fichier *.md par note * Weekly reviews = 1 fichier *.md par semaine * Meeting = 1 fichier *.md par réunion * Ressources = non utilisé Chaque dossier correspond à un type de fichier markdown spécifique avec un template dédié. Pour le domaine PRO j'ai beaucoup de projets (50 à 60 actifs). Chacun est lié via un attribut dans le frontmatter à un axe : Pilotage, Animation, Outils, Données, etc. J'ai également dans chaque dossier "PROJETS" un sous-dossier "_INCUBATION" où je place les idées de projets que je fait grandir avant de les rendre réellement actifs. La gestion des tâches se fait de la façon suivante: * Lors d'une réunion je note "* #TODO: une tache à faire". Ainsi, le tag "#TODO" en couleur orange me permet de visiualiser ce que j'ai à faire. * J'ai mis en place une formule LUA dans la page "MEETINGS" qui liste tous les éléments "* #TODO:". * Une fois par jour ou semaine, je renomme "#TODO" en "TODO" pour ne pas perdre d'information et je copie/colle les tâches dans le fichier du projet correspondant sous la forme "* [ ] une tâche à faire". Ainsi, après saisie, je gère mes tâches dans les pages projets. Une des difficultés est notamment de distinguer une "note" d'une "ressource". J'ai par exemple, dans mes notes PRO un fichier qui liste tous les logiciels que j'installe sur mon PC. Cela est utile si je dois renouveler mon ordinateur. Est-ce une note ou une ressource ? De même, j'ai regardé une vidéo sur l''usage de l'IA. J'ai pris des notes dans un fichier, mais est-ce une note ou une ressource ? Une autre question est de savoir si je dois placer mes fichiers de NOTES et de MEETINGS dans un dossier dédié ou directement dans le dossier de chaque projet. J'évite d'avoir une arborescence avec trop de niveaux, mais ce n'est pas réellement évident. Je souhaite conserver une système simple et efficace et je ne sais pas si cette arborescence est optimale pour mon usage... De même, j'ai dupliqué l'arborescence de "02_DOMAINS" dans "90_ARCHIVES". Cependnat, mes fichiers retsent dans Silverbullet et ralentissent progressivement la recherche et l'indexation globale de mon espace de travail. Dois-je vider le dossier archive ? Avec quelle fréquence ? Quels conseils et recommandations peux tu me donner pour améliorer l'efficacité de cette organisation et son fonctionnement ? ## Réponse de Claude AI Votre système est déjà solide dans ses fondations — le vrai problème n'est pas l'arborescence en tant que telle, c'est que vous essayez de résoudre par des **dossiers** des problèmes qui se résolvent mieux par des **métadonnées et des requêtes**, alors que Silverbullet est justement un outil taillé pour ça (frontmatter, tags, live queries). Voici mes recommandations, point par point. ### 1\. Note vs Ressource : le vrai critère est temporel, pas thématique Le flou vient du fait que "Notes" et "Ressources" sont pensés comme deux thèmes différents alors que la distinction pertinente est **la durée de vie et la nature de l'information** : * **Note** = une trace d'un moment précis (une réflexion, une lecture, une idée qui a une date de naissance et qui ne sera probablement pas mise à jour). Elle a du sens *dans son contexte temporel*. * **Ressource** = une référence évolutive, atemporelle, que vous consultez et mettez à jour dans la durée (checklist, procédure, base de connaissance sur un sujet). Avec ce critère : * La liste des logiciels à réinstaller → **Ressource** (vous la mettrez à jour, elle n'a pas de date de péremption, c'est un document de référence). * Les notes prises pendant la vidéo sur l'IA → **Note** au moment de la capture, mais si vous en extrayez des principes que vous allez réutiliser/enrichir → ça devient (ou ça alimente) une **Ressource** sur le sujet "IA". Une note peut donner naissance à une ressource. **Suggestion concrète** : arrêtez de séparer ça en deux *dossiers*. Un seul dossier `Notes/` avec un champ frontmatter `type: note` ou `type: ressource`. Le tri se fait par métadonnée, pas par emplacement physique — vous évitez ainsi la question "où est-ce que je range ça" à chaque création de fichier, qui est justement ce qui vous bloque. ### 2\. Notes et Meetings : dossier dédié ou dans le projet ? À 50-60 projets actifs, **ne dupliquez pas Notes/Meetings dans chaque dossier projet**. Ça crée une arborescence profonde et pénible à maintenir (60 sous-dossiers Meetings, 60 sous-dossiers Notes...). Gardez votre structure actuelle (dossiers centralisés par type : `Meetings/`, `Notes/`) et reliez chaque fichier au projet via le frontmatter (`projet: [[Projet X]]`). Ensuite, dans la page de chaque projet, une **live query Silverbullet** affiche automatiquement les meetings et notes liés à ce projet. Vous avez déjà ce réflexe avec votre requête LUA sur les `#TODO` — appliquez le même principe ici. C'est exactement le point fort de l'outil : la vue "tout ce qui concerne le projet X" n'a pas besoin d'exister physiquement, elle peut être générée. ### 3\. Le sous-dossier `_INCUBATION` Remplacez-le par un champ `statut: incubation | actif | pause | clos` dans le frontmatter du projet. Avantages : * Faire "grandir" un projet ne nécessite plus de déplacer physiquement le fichier (ce qui casse potentiellement des liens et demande un geste manuel) — juste changer une valeur. * Une query "Projets actifs par axe" ou "Projets en incubation" devient triviale et vous donne un vrai tableau de bord PRO, bien plus utile à 60 projets qu'une navigation par dossiers. Je vous recommande d'ailleurs de construire 2-3 pages "tableau de bord" par domaine (ex. `PRO - Vue d'ensemble`) avec des queries groupées par axe/statut. À votre échelle, la navigation par arborescence atteint ses limites quel que soit le système choisi (PARA, IPCRA...) — c'est la requête qui doit faire le tri, pas l'œil humain qui parcourt des dossiers. ### 4\. Gestion des tâches Votre flux actuel fonctionne mais a une étape 100% manuelle (renommer `#TODO`→`TODO` puis copier-coller dans le fichier projet). C'est une duplication d'information : la tâche existe une fois dans le compte-rendu de réunion, une fois dans le fichier projet. Alternative : si vous liez déjà le compte-rendu au projet (`projet: [[Projet X]]`), une requête dans la page projet peut afficher en direct toutes les tâches non cochées provenant des meetings liés, sans copier-coller. Vous ne perdez rien (le compte-rendu reste la source), et vous gagnez l'étape manuelle. Si vous tenez à avoir les tâches "physiquement" dans le fichier projet (pour pouvoir les réorganiser, les prioriser à la main), gardez votre méthode actuelle — ce n'est pas absurde, juste plus coûteux en temps. À vous de trancher selon ce qui compte le plus : l'automatisation ou le contrôle manuel de la liste finale. ### 5\. Archives et performance Silverbullet Deux options, selon votre besoin réel de recherche dans l'archive : * **Si vous consultez rarement l'archive** : sortez-la complètement de l'espace Silverbullet actif. Silverbullet indexe *tout* ce qui est dans le dossier de l'espace ouvert — un fichier archivé ralentit donc la recherche même s'il ne vous intéresse plus. Créez un espace Silverbullet séparé (ou simplement un dossier hors de l'espace synchronisé) pour l'archive froide, que vous n'ouvrez qu'en cas de besoin ponctuel. * **Fréquence** : archivez au fil de l'eau (dès qu'un projet passe en statut `clos`, il part vers l'archive — pas besoin d'attendre une session dédiée), mais migrez vers l'archive *froide* (hors espace actif) à intervalle plus large, par exemple une fois par an, ou dès que vous sentez un ralentissement notable. Vider complètement l'archive n'est pas nécessaire ni souhaitable (vous perdriez l'historique) — c'est la séparer de l'espace actif qui règle le problème de performance, pas la supprimer. ### En résumé | Problème | Cause | Solution | | --- | --- | --- | | Note vs Ressource flou | Critère thématique au lieu de temporel | Un seul dossier, distinction par frontmatter `type:` | | Notes/Meetings dupliqués par projet | Structure physique répétée 60x | Dossiers centralisés + liaison par frontmatter + queries | | `_INCUBATION` comme dossier | Le statut devrait être une métadonnée, pas un emplacement | Champ `statut:` + query | | Copier-coller des tâches | Duplication manuelle | Query agrégeant les tâches liées au projet | | Archive qui ralentit tout | Fichiers archivés toujours indexés dans l'espace actif | Espace séparé pour l'archive froide | L'idée directrice : à votre échelle (50-60 projets), continuez de simplifier l'arborescence de premier niveau (elle est déjà bien pensée), mais transférez la charge de "classement fin" vers le frontmatter et les requêtes plutôt que vers de nouveaux niveaux de dossiers. C'est plus robuste dans la durée, car ça ne casse rien quand un projet change de statut, et ça exploite ce que Silverbullet fait mieux qu'un simple explorateur de fichiers. ## Question 2 Je n'utilise pas les approches PARA ou IPCRA qui font généralement référence. Mon système de "domaines" est visiblement différent de la notion d'AREA ou CASQUETTE de ces systèmes. Penses-tu qu'une évolution de mon arborescence soit nécessaire ici ? Quelles sont tes recommandation pour simplifier ou optimiser l'arborescence actuelle ? ## Réponse 2 de Claude AI Non, je ne pense pas qu'il faille faire évoluer radicalement votre arborescence — au contraire, votre choix de "Domaines" en tête de structure est une réponse pertinente à un besoin que ni PARA ni IPCRA ne couvrent nativement. Laissez-moi expliquer pourquoi, puis vous donner des pistes de simplification concrètes. ## Pourquoi votre approche "Domaines" est légitime et différente PARA et IPCRA sont conçus comme des **espaces plats et uniques**, triés d'abord par *actionabilité* (Projets vs Areas/Casquettes vs Ressources vs Archives), sans séparation de sphères de vie en tête de structure. Les "Areas" de PARA ou les "Casquettes" d'IPCRA sont des responsabilités continues (ex : "Santé", "Blogueur", "Trésorier association X") qui cohabitent toutes au même niveau, mélangeant perso et pro. Votre besoin est différent : vous avez trois sphères de vie qui ont des logiques, des rythmes et probablement des niveaux de confidentialité distincts (PRO professionnel avec 50-60 projets, ASSO bénévole, PERSO privé). Faire cohabiter tout ça dans un espace non cloisonné serait plus confus, pas moins. Le fait d'avoir ajouté un niveau "Domaine" au-dessus n'est donc pas un écart maladroit par rapport à la méthode de référence — c'est une adaptation nécessaire à votre échelle et à votre contexte (un directeur de projets qui gère 50-60 dossiers n'a tout simplement pas le même problème qu'un individu qui organise sa vie perso). Gardez ce niveau. ## Où se situe le vrai gisement de simplification Le point à corriger n'est pas la présence du niveau Domaine, c'est **ce que vous mettez dans des dossiers alors que ce sont en réalité des attributs**. Trois exemples dans votre propre système : * L'attribut `axe` (Pilotage, Animation, Outils, Données) sur vos projets PRO joue déjà exactement le rôle d'une "Area/Casquette" — une catégorie de responsabilité transversale aux projets. Vous l'avez fait en frontmatter, pas en dossier. **C'est la bonne approche, gardez-la comme modèle** pour le reste. * `_INCUBATION` est un dossier alors que c'est un statut (cf. ma réponse précédente). * Notes vs Ressources est un dossier alors que c'est une nature de contenu (temporel vs référentiel). Le principe à appliquer partout, comme grille de décision durable pour vos futurs doutes de classement : > **Un dossier pour ce qui structure rarement et sert à cloisonner (confidentialité, contexte, type de fichier lié à un template). Un attribut frontmatter pour tout ce qui change dans le temps ou sert à filtrer transversalement.** ## Application à ASSO Vous avez 2 associations sous le domaine ASSO. Ne créez pas un sous-dossier par association (ça reproduirait la même logique de sur-dossiers que `_INCUBATION`). Ajoutez plutôt un champ `association: [[Asso X]]` dans le frontmatter de vos projets/notes/contacts ASSO, exactement comme `axe` pour PRO. Une page-index avec query fait la vue par association si besoin. ## Un point à clarifier : Journal vs Weekly Reviews Une redondance potentielle que je note : vous avez `01_Journal` en racine **et** un dossier "Weekly reviews" par domaine. Si le Journal est une capture quotidienne transversale et les Weekly reviews un rituel de synthèse propre à chaque domaine, la distinction est saine. Mais si les deux finissent par contenir le même type de réflexion à des fréquences différentes, c'est un point de friction qui mérite d'être tranché clairement (par exemple : Journal = capture brute au fil de l'eau, Weekly review PRO/ASSO = synthèse structurée orientée pilotage). Vaut le coup d'écrire cette règle noir sur blanc quelque part (dans `80_Config`) pour ne pas hésiter à chaque fois. ## Arborescence simplifiée résultante ``` 00_Inbox 01_Journal 02_Domains ├── PERSO/ │ ├── Contacts/ │ ├── Projets/ │ ├── Notes/ (type: note | ressource en frontmatter) │ ├── Weekly_Reviews/ │ └── Meetings/ ├── PRO/ │ ├── Contacts/ │ ├── Projets/ (statut: actif|incubation|pause|clos ; axe: ... en frontmatter) │ ├── Notes/ │ ├── Weekly_Reviews/ │ └── Meetings/ └── ASSO/ ├── Contacts/ ├── Projets/ (association: ... en frontmatter) ├── Notes/ ├── Weekly_Reviews/ └── Meetings/ 80_Config 90_Archives (→ à sortir de l'espace actif, cf. réponse précédente) ``` Résultat : même nombre de niveaux qu'aujourd'hui, aucun nouveau dossier, mais deux dossiers en moins par domaine (plus de `_INCUBATION`, plus de dossier `Ressources` séparé) et un mécanisme unique et réutilisable (attribut + query) pour tout ce qui bougeait auparavant physiquement. C'est ce qui devrait vous permettre de tenir la structure dans la durée : moins de décisions "où est-ce que je range ça" à chaque création de fichier, et plus de robustesse quand un projet change de statut ou qu'un contenu change de nature. ## Synthèse # 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`) ``` Contacts/ 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 Flux actuel : 1. En réunion, capture sous forme `* #TODO: tâche à faire` (tag orange visible). 2. Une requête Silverbullet dans la page `MEETINGS` liste tous les `#TODO`. 3. À fréquence quotidienne/hebdomadaire, renommage `#TODO` → `TODO` (conservation de l'historique) et copie de la tâche dans le fichier projet correspondant sous forme `* [ ] tâche`. **Point de friction identifié** : l'étape 3 duplique manuellement l'information (la tâche existe à la fois dans le compte-rendu et dans le fichier projet). **Alternative possible** (non tranchée, à évaluer selon préférence) : si le compte-rendu est déjà lié au projet via frontmatter, une requête sur la page projet peut afficher directement les tâches non cochées des meetings liés, sans copier-coller. Le choix entre automatisation complète et contrôle manuel de la liste finale (réorganisation, priorisation à la main) reste à l'appréciation de l'usage réel constaté dans le temps. ## 9\. 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) ``` ## 10\. Points ouverts / à surveiller dans le temps * Vérifier que la distinction Journal / Weekly Review reste tenue en pratique (§6). * Décider si l'automatisation des tâches via requête remplace le copier-coller manuel, ou si les deux coexistent (§8). * 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. ## Compléments ### Question: Je suis d'accord que le traitement des tâches peut être simplifié via une requête dans la page du projet. Autre sujet : comment nommer efficacement mes dossiers et fichiers ? Quel usage faire des majuscules et minuscules, du tiret et underscore, faut il utiliser des espaces et accents, faut-il ajouter systématiquement un numéro ou une date ? Enfin, peux tu me proposer la structure des tableaux de bord a mettre en place pour le suivi, la revue et gestion du système ? ### Réponse ## Conventions de nommage Le principe à garder en tête : un nom de fichier a deux rôles différents selon le contexte — **lisibilité humaine** (ce qui s'affiche comme lien dans Silverbullet) et **robustesse technique** (scripts, requêtes LUA, synchronisation, git). Les règles ci-dessous distinguent les deux. ### Majuscules / minuscules * **Dossiers système** (premier niveau, `80_Config`, etc.) : gardez votre convention actuelle (initiale en majuscule après le préfixe numérique). Ce qui compte n'est pas le choix en soi mais la **cohérence totale** — ne jamais mélanger deux styles de casse dans la structure fixe. * **Fichiers de contenu** (projets, contacts, notes) : casse naturelle du titre (`Refonte SI Client X.md`), car c'est ce texte qui s'affiche tel quel dans vos liens `[[...]]` — la lisibilité du lien prime ici sur toute contrainte technique. ### Tiret vs underscore Réservez-leur des rôles distincts plutôt que de choisir "l'un ou l'autre" globalement : * **Underscore `_`** : uniquement pour les éléments structurels (préfixes numériques de tri : `00_Inbox`, `02_Domains`). Il signale visuellement "ceci organise le système", pas "ceci est un contenu". * **Tiret `-`** : à l'intérieur des noms de fichiers de contenu composés de plusieurs mots, si vous préférez éviter les espaces (utile pour les fichiers Meetings/Journal datés, voir plus bas). Plus lisible qu'un underscore dans une chaîne de mots. ### Espaces et accents * **Espaces** : Silverbullet les gère très bien dans les noms de page, aucune raison technique de les bannir pour les fichiers de contenu (projets, contacts). Ils ne posent problème que si vous exportez/scriptez en dehors de SB. * **Accents** : à éviter dans les **noms de fichiers** (pas dans le contenu ni le frontmatter) si vous synchronisez entre systèmes différents (macOS normalise les accents différemment de Windows/Linux — source classique de duplication silencieuse de fichiers lors d'une synchronisation). Gardez l'accent dans le titre affiché (première ligne du fichier ou frontmatter), mais évitez-le dans le nom physique : `Reunion Client X.md` plutôt que `Réunion Client X.md`. C'est une précaution, pas une urgence, si vous ne synchronisez que sur un seul OS. ### Numéro ou date systématique ? Pas systématiquement — seulement là où ça a une vraie utilité : | Type de fichier | Convention | Pourquoi | | --- | --- | --- | | Dossiers système (premier niveau) | Préfixe numérique (`00_`, `01_`...) | Tri visuel voulu, structure fixe et rare | | Meetings, Journal | Préfixe date ISO `AAAA-MM-JJ-` | Le tri alphabétique = tri chronologique, lisible même sans requête | | Projets, Contacts, Notes, Ressources | Titre seul, aucun préfixe | La date de création existe déjà en métadonnée/frontmatter ; un numéro ou une date sur ces fichiers n'apporte rien et complique le renommage | Règle simple : **date en préfixe uniquement pour ce qui est intrinsèquement un événement daté** (une réunion, une entrée de journal). Pour tout le reste, le nom doit être le sujet, point. ## Tableaux de bord Je vous propose 4 pages de requêtes, à des fréquences différentes, plutôt qu'un seul tableau fourre-tout — chacun répond à une question différente. **1\. `PRO - Vue d'ensemble`** (consultation fréquente, pilotage courant) * Projets `statut: actif`, groupés par `axe` * Projets `statut: incubation` (à examiner : go/no-go) * Projets `statut: pause` (à relancer ou clore explicitement) * Alerte : projets actifs sans modification depuis X semaines (staleness) **2\. `Revue hebdomadaire`** (rituel hebdo, par domaine ou globale) * Tâches ouvertes agrégées depuis les meetings/projets liés * Meetings de la semaine écoulée et à venir * Notes créées dans les 7 derniers jours (à retraiter : note → ressource ?) * Lien vers la Weekly Review précédente **3\. `ASSO - Vue d'ensemble`** (même logique que PRO, plus légère vu le volume) * Projets par association, groupés par statut **4\. `Maintenance du système`** (mensuelle ou trimestrielle — c'est le tableau de bord qui répond à vos questions sur l'archive et la dérive du système) * Projets `statut: clos` non encore déplacés vers l'archive froide * Notes sans aucun lien vers un projet (orphelines — candidates à requalifier ou supprimer) * Compteur de fichiers par dossier, pour suivre la croissance et anticiper le moment de purger l'archive active Le tableau **4** est important dans votre cas précis : c'est lui qui vous évitera de vous reposer la question "dois-je vider l'archive" — la requête vous dira objectivement quand c'est le bon moment, plutôt que de fixer une fréquence arbitraire à l'avance. Voulez-vous que j'intègre ces éléments (nommage + tableaux de bord) dans le document de référence déjà créé ? ## Autre problème : la gestion des tâches ### Question : J'ai une difficulté dans la gestion des tâches: lors d'une réunion on répète parfois des tâches à faire que j'ai déjà noté. Ex.: lors d'un point le 03/03/2026, je note que sur le projet P1, je dois contacter M. A pour organiser un comité de pilotage avant la fin de la prestation en septembre. Lors du point de suivi avec mon responsable le 10/03/2026 je renote ce point. Lors du point de suivi du 21/03/2026, pendant la réunion on me dit : attention tu n'as toujours pas pris contact avec M. A... et je note une nouvelle fois cette tâche. Comment optimiser cela ? Dois-je revenir à mon principe d'utiliser #todo dans mes réunions et traiter les tâches ensuite dans la page projet ? Dois-je lors des réunions, reprendre à chaque fois la page projet et jongler entre ma page projet, la page de la réunion où j'ai noté initialement la tâche et les notes de la réunion en cours, avec le risque de me perdre et surtout de perdre du temps ? Il y a-t-il une autre façon de faire ? ### Réponse C'est un problème très courant, et la bonne nouvelle est que la répétition observée est en réalité un **signal utile** (une tâche mentionnée 3 fois est une tâche qui patine) — l'enjeu n'est pas de l'empêcher à tout prix, mais d'éviter qu'elle se transforme en **3 tâches indépendantes** au lieu d'une seule tâche enrichie de 3 mentions. ## Le vrai problème n'est pas la capture, c'est l'absence de visibilité au moment de la réunion Vous ne recréez pas la tâche par erreur — vous la recréez parce qu'au moment de noter, vous n'avez pas sous les yeux la liste des tâches déjà ouvertes sur le projet. Le cerveau humain est mauvais pour se rappeler "est-ce que j'ai déjà noté ça" en pleine réunion, mais très bon pour reconnaître visuellement une liste déjà affichée. La solution n'est donc pas comportementale ("faire plus attention"), elle est structurelle : **faire apparaître automatiquement les tâches ouvertes du projet concerné directement dans la page de la réunion en cours**, sans que vous ayez à aller les chercher. C'est exactement ce que vous redoutiez ("jongler entre pages") — la réponse est de ne plus jongler du tout, en laissant une requête le faire pour vous. ### Mise en œuvre concrète Gardez `#TODO` comme mécanisme de capture rapide pendant la réunion — il fonctionne bien et ne change pas. Modifiez en revanche votre **template de réunion** : dès que vous renseignez le(s) projet(s) concerné(s) en frontmatter (`projet: [[P1]]`), le template insère automatiquement en haut de la page une requête affichant les tâches non cochées existantes de ce(s) projet(s). Concrètement, en ouvrant la page du point du 21/03, vous voyez immédiatement en haut : ``` Tâches ouvertes — P1 : - [ ] Contacter M. A pour organiser un COPIL avant fin septembre ``` Vous reconnaissez instantanément que c'est déjà tracé — plus besoin de rouvrir la page projet ni de vous souvenir de la réunion du 3 ou du 10 mars. ## Ce qu'on fait quand la tâche est déjà là Au lieu de recréer une ligne `#TODO` indépendante, deux options selon le cas : **Si c'est une simple confirmation** ("toujours d'actualité") → rien à faire, ou une relance courte en sous-ligne de la tâche existante dans le fichier projet plutôt qu'une nouvelle tâche au même niveau : ``` - [ ] Contacter M. A pour organiser un COPIL avant fin septembre (créée 03/03) - relance 10/03 (point responsable) - relance 21/03 — signalée en retard ``` **Si l'information change réellement** (nouvelle échéance, nouveau contexte) → mettre à jour la tâche existante elle-même (modifier la date cible, ajouter un commentaire), toujours sans dupliquer la ligne. Cette structure a un avantage supplémentaire : le nombre de relances devient une donnée exploitable. ## Transformer la répétition en signal d'alerte Une fois les relances tracées ainsi, une requête de type **"tâches avec ≥ 2 relances"** vous donne automatiquement la liste des tâches qui patinent — exactement ce que votre responsable a fait manuellement le 21/03 en vous le rappelant à l'oral. Je vous suggère de l'ajouter au tableau de bord `PRO - Vue d'ensemble` évoqué précédemment, sous une section "Tâches en surplace" (ou "à relancer en priorité"). Cela transforme un problème vécu comme une perte de temps en un mécanisme de vigilance actif. ## Réponse directe à vos trois questions * **Revenir à `#TODO` en réunion** : oui, gardez-le, ce n'est pas le maillon faible. * **Jongler entre les pages** : non, plus besoin — c'est le rôle de la requête auto-intégrée au template de réunion. * **Autre façon de faire** : oui — ne pas empêcher la répétition mais la canaliser sous forme de relances nichées sous la tâche d'origine, et exploiter ce comptage comme signal d'alerte plutôt que comme un défaut à corriger. Voulez-vous que j'intègre cette section (nommage, tableaux de bord, gestion des tâches et relances) dans le document de synthèse déjà créé ? ## Autre approche pour les tâches : statuts personnalisés ### Question Silverbullet permet de gérer des statuts personnalisés pour les tâches. Par exemple d'avoir les statuts "\* \[TODO\]", "\* \[URGENT\]", "\* \[WAITING\]", "\* \[DUPLICATE\]", "\* \[DONE\]". Utiliser ces statuts directement dans mes notes en abandonnant la notion de tag "#todo" et la reprise, est-ce une bonne approche ? ### Réponse Oui, c'est une bonne évolution — et elle va plus loin que ce qu'on avait envisagé avec `#doublon` : les statuts personnalisés de Silverbullet indexent nativement l'état de chaque tâche comme un objet interrogeable (`state`, `tags`, attributs `[clé: valeur]`, échéance), directement requêtable via `query task where ...`. Ça permet de supprimer complètement l'étape de renommage/copier-coller, pas seulement de mieux nommer les doublons. ## Ce que ça change concrètement Le flux se simplifie en un seul mécanisme au lieu de deux (capture par tag + reprise manuelle) : 1. **En réunion**, vous capturez directement avec l'attribut projet en ligne, sans passer par le fichier projet : ``` * [TODO] Contacter M. A pour organiser un COPIL avant fin septembre [projet: P1] ``` 2. **Dans la page projet**, une requête affiche en direct toutes les tâches liées, où qu'elles vivent physiquement : ``` query task where projet = "P1" and done = false ``` 3. La tâche continue à cycler d'état (`TODO → WAITING → DONE`, etc.) au clic, directement à sa source — plus besoin de la déplacer ni de la retranscrire. Résultat : la case "recopier dans le fichier projet" disparaît purement et simplement. C'est cohérent avec le principe qu'on a posé depuis le début (attribut + requête plutôt que déplacement manuel de contenu). ## Un point d'attention : ne pas forcer un choix de statut trop tôt Le risque, c'est qu'en réunion vous soyez tenté d'hésiter entre `TODO`, `URGENT`, `WAITING` au moment même de la capture — ce qui réintroduit de la friction cognitive à un moment où vous en avez justement le moins besoin. Je recommande de garder un **geste de capture unique et rapide** (`[TODO]` par défaut, toujours) et de réserver l'affinage du statut (`URGENT`, `WAITING`) au moment de la revue hebdomadaire, où vous avez le recul pour trancher. La revue hebdo garde donc un rôle, mais un rôle de *raffinement*, plus de *retranscription*. ## Un point de conception à trancher : le statut mélange plusieurs axes différents `TODO / URGENT / WAITING / DUPLICATE / DONE` répond en réalité à **trois questions distinctes** : * Est-ce terminé ? (`TODO` vs `DONE`) * Est-ce bloqué par quelqu'un d'autre ? (`WAITING`) * Est-ce prioritaire ? (`URGENT`) * Est-ce une redite d'une tâche existante ? (`DUPLICATE`) Un champ unique à valeur unique ne peut pas représenter une tâche qui serait *à la fois* urgente et en attente d'une réponse — ce qui est pourtant votre cas exact (contacter M. A est urgent **et** dépend de sa disponibilité). Deux options : * Accepter la limite et choisir l'état "dominant" à un instant donné (pragmatique, simple). * Séparer les axes : garder le `state` pour le cycle de vie (`TODO/WAITING/DUPLICATE/DONE`) et ajouter un attribut séparé pour la priorité (`[priorite: haute]` ou un tag `#urgent`), interrogeable indépendamment. Ça évite d'avoir à choisir entre deux informations vraies en même temps. Pour `DUPLICATE` spécifiquement, pensez à toujours l'accompagner d'un lien vers la tâche d'origine (via wikilink dans le texte de la tâche), sinon vous perdez la traçabilité qu'on avait justement identifiée comme utile pour repérer les tâches qui patinent. Voulez-vous que j'intègre cette évolution (nommage, tableaux de bord, gestion des tâches via statuts natifs Silverbullet) dans le document de synthèse ? ## Notion de processus et de tableaux de bord ### Question Un point central dans mes réflexions concerne les tableau de bord et de pilotage de mon système. Je pense nécessaire d'établir des modèles transposables sur les différents domaines. Ils doivent, selon moi, faciliter la revue régulière et la gestion des tâches, des notes et des projets, à la fois de façon quotidienne, hebdomadaire et mensuelle. Ils doivent donc être en lien et le miroir des processus de gestion du système, par exemple pour la revue hebdomadaire des projets => identifier les projets par axe de façon à les parcourir de façon logique ou par statut pour gérer les urgences sans perdre de vue les projets inactifs depuis longtemps. Quelles sont les propositions que tu peux me faire et les recommandations utiles sur ce point? ### Réponse Vous touchez le point le plus stratégique de tout ce qu'on a construit : les tableaux de bord ne doivent pas être pensés à partir des données disponibles, mais **à partir des rituels eux-mêmes** — chaque section d'un tableau de bord devrait correspondre à une étape que vous suivez réellement dans votre revue, dans le même ordre. C'est ce principe qui va résoudre votre tension "parcourir par axe" vs "ne pas perdre de vue les urgences" : ce ne sont pas deux logiques concurrentes entre lesquelles choisir, ce sont deux zones différentes d'un même tableau de bord. ## Principe directeur : le tableau de bord comme miroir du processus, pas comme vue des données Pour chaque rituel récurrent (quotidien, hebdo, mensuel), écrivez d'abord la liste des étapes que vous suivez réellement (même sommairement, dans `80_Config`), puis faites correspondre une section de requête à chaque étape, dans le même ordre. Si le processus évolue, vous mettez à jour les deux ensemble — le tableau de bord ne peut jamais dériver silencieusement du rituel réel, contrairement à un tableau de bord conçu uniquement "parce que la donnée existe". ## Résoudre la tension axe / urgence : deux zones, pas un choix Une revue hebdomadaire de projets a en réalité deux objectifs différents, qui ne se lisent pas dans le même ordre : * **Objectif de vigilance** : ne rien laisser filer (urgences, projets en sommeil depuis trop longtemps) — lecture transversale, indépendante de l'axe. * **Objectif d'exhaustivité** : parcourir méthodiquement tous les projets actifs pour ne rien oublier — lecture structurée par axe. **Recommandation** : sur une même page, une zone **Radar** en tête (urgences + projets inactifs depuis X semaines, tous axes confondus), suivie d'une zone **Parcours systématique** groupée par axe en dessous. Vous consultez le Radar en 30 secondes tous les jours si besoin, et vous ne descendez au parcours complet que lors de la revue hebdo elle-même. ``` ## Radar — à traiter en priorité query task where tags = "URGENT" and done = false query project where statut = "actif" and lastmodified < {{7 jours}} ## Parcours systématique — par axe query project where statut = "actif" and axe = "Pilotage" query project where statut = "actif" and axe = "Animation" query project where statut = "actif" and axe = "Outils" query project where statut = "actif" and axe = "Données" ``` ## Des modèles transposables : un template unique paramétré par domaine Plutôt que de construire 3 tableaux de bord hebdomadaires distincts (PRO, ASSO, PERSO) avec chacun sa propre logique, construisez **un seul template** avec le domaine en paramètre. Bénéfice concret : si vous améliorez une requête ou corrigez un défaut de structure, vous le faites une fois, pas trois. La logique de gestion de PRO à 50-60 projets et d'ASSO à 2 associations n'est pas différente dans sa structure — seul le volume change. Structure commune du template, quel que soit le domaine : | Zone | Rôle | Fréquence de lecture | | --- | --- | --- | | **Radar** | Urgences, tâches en attente échues, projets inactifs | Quotidien (facultatif) ou en ouverture de la revue hebdo | | **File REVIEW** | Tâches saisies non triées | Hebdomadaire | | **Parcours par axe / association** | Vue exhaustive des projets actifs | Hebdomadaire | | **Notes récentes** | À requalifier note/ressource | Hebdomadaire | | **Meetings** | Semaine écoulée / à venir | Hebdomadaire | ## Un niveau quotidien, léger et distinct du hebdo Le quotidien n'a pas vocation à reproduire la revue hebdo en miniature — juste à répondre à "qu'est-ce qui me tombe dessus aujourd'hui" : * Tâches `WAITING` dont le rappel journal tombe aujourd'hui (déjà automatique via les liens entrants, pas besoin de requête). * Tâches `#URGENT` non terminées, tous domaines confondus (seule vue qui a du sens à décloisonner, puisque l'urgence ne connaît pas les frontières PRO/PERSO/ASSO). ## Un niveau mensuel, orienté tendance plutôt que liste Le mensuel ne doit pas redire le hebdo en plus long — il doit repérer des **signaux que la fréquence hebdo ne peut pas voir** : * Nombre de tâches passées en `DUPLICATE` sur le mois (signal que certains sujets patinent structurellement). * Projets `statut: actif` inchangés depuis plus de 4 semaines (staleness que le radar hebdo, ciblé sur les urgences, ne capture pas forcément). * Idées en incubation à trancher (go/no-go), projets clos à faire basculer en archive froide. ## Recommandation de sobriété Résistez à la tentation de multiplier les tableaux de bord au-delà de ceux-ci (un daily léger, un weekly par domaine issu d'un même template, un monthly transversal) : chaque tableau de bord supplémentaire est lui-même un objet à maintenir, exactement comme un dossier ou un tag surnuméraire qu'on a évité plus tôt dans nos échanges. Le test à appliquer est le même que pour un dossier : *ce tableau de bord correspond-il à un rituel que je tiens réellement dans la durée* ? Sinon, il devient du bruit indexé de plus. Souhaitez-vous que j'intègre cette section (principe miroir, zones Radar/Parcours, modèle transposable par domaine, niveaux quotidien/hebdo/mensuel) dans le document de synthèse ? ### Question Peux-tu m'aider à rédiger sur cette base et en considérant l'ensemble de notre échange les process simples et efficaces à mettre en oeuvre de façon quotidienne, hebdomadaire ou mensuelle pour bien gérer ce système, garder une vision claire et ne pas m'éparpiller ? ### Réponse Voici les trois rituels, écrits comme des check-lists concrètes — volontairement courts pour rester tenables dans la durée, chaque étape correspondant directement à un mécanisme qu'on a posé dans la conversation (statuts, requêtes, radar, tableaux de bord). ## Rituel quotidien (2-5 min, pas de page dédiée nécessaire) 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. Rien à chercher pour les rappels `WAITING` liés au Journal — ils apparaissent automatiquement en liens entrants sur la page du jour. 3. Si une réunion a lieu : capture en `[REVIEW]` avec lien projet si possible sur le moment (sinon, tant pis, ce sera rattrapé en hebdo — ne pas casser le rythme de la réunion pour ça). 4. `00_Inbox` : uniquement si un élément vous saute aux yeux et prend 10 secondes à ranger. Sinon, on laisse pour le hebdo — l'Inbox n'est pas censé être vide en permanence. Aucune page de tableau de bord dédiée n'est nécessaire ici : c'est la vue Radar déjà construite pour le hebdo, simplement consultée plus souvent. ## Rituel hebdomadaire (30-45 min, page `Revue hebdomadaire`) L'ordre suit le pipeline des tâches et respecte la distinction Journal (brut) / Weekly Review (synthèse) posée précédemment : 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. C'est l'étape qui remplace l'ancien copier-coller — ici, on ne fait que changer un statut et ajouter un lien, jamais dupliquer. 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 — c'est la garantie de ne rien sauter, indépendamment des urgences déjà traitées au point 1. 4. **Notes récentes de la semaine** : chacune requalifiée `note` ou `ressource` selon le critère temporel/atemporel posé précédemment. Ne pas laisser cette qualification traîner plus d'une semaine, sinon le flou revient. 5. **Meetings à venir** : vérifier que les prochains rendez-vous ont bien un lien projet en frontmatter, pour que les tâches qui y seront saisies soient immédiatement rattachables. 6. **Écrire la synthèse** dans `Weekly_Reviews/` : quelques lignes de bilan structuré (jamais de capture brute, ça, c'est le rôle du Journal). Ce rituel se répète à l'identique pour chaque domaine (PRO, ASSO, PERSO), via le même template paramétré — seule la charge diffère selon le volume. ## Rituel mensuel (45-60 min, page `Maintenance du système`) Ici, 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 peut pas capter : 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 est un sujet qui patine structurellement — à remonter explicitement, pas juste à re-router. 3. **Projets actifs sans modification depuis 4+ semaines** : décision explicite (relancer, mettre en pause, clore) — ne jamais laisser un projet "actif" mais 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 (pas de fréquence fixe imposée — le signal de ralentissement suffit). 6. **Les tags** (`#URGENT`, `#next`, etc.) : toujours 3 à 5 ? Si un nouveau cas particulier revient chaque mois, c'est le signe qu'il mérite son propre tag plutôt que d'être forcé dans un existant. ## Une règle de sobriété transversale aux trois rituels Si une étape d'un de ces rituels n'est pas suivie pendant un mois complet, ne la maintenez pas par principe : soit vous la simplifiez, soit vous l'abandonnez et vous ajustez le document. Un rituel qu'on ne tient pas dans la durée est pire qu'un rituel absent, car il donne une fausse impression de couverture. Souhaitez-vous que j'ajoute cette section "Processus quotidien / hebdomadaire / mensuel" à la synthèse déjà constituée ? Dernière version suite à cet échange : [[04_NOTES/ORGANISATION/SB_Reorganisation_20260722]]