[[02_DOMAINES/PERSO-PKM]] [[04_NOTES/ORGANISATION/organisation_silverbullet_chatgpt_20260105/Synthese|SYNTHESE]] ### Ce que Silverbullet fait bien (et qui vous concerne) Silverbullet n’est pas Obsidian. C’est un point important. Pour votre profil, ses atouts clés sont : * **Approche text-first, centralisée** * Un dossier unique (Markdown + métadonnées). * **Données locales, synchronisables** * Parfaitement compatible avec Nextcloud. * **Système programmable** * Queries, scripts, automatisation légère. * **Pas de “plugin hell”** * Plus contrôlé qu’Obsidian. ➡️ Pour quelqu’un qui veut **éviter l’hybride** et garder la maîtrise, Silverbullet est cohérent. ### Points de vigilance Soyons lucides : * **Courbe d’apprentissage** * Silverbullet exige une pensée structurée (frontmatter, conventions). * **Moins “clé en main”** * Vous devrez concevoir votre modèle. * **Moins orienté “tableur”** * Les vues tabulaires sont possibles, mais conceptuellement différentes d’Excel. Silverbullet est un **outil de système**, pas un outil de confort. --- #### Étape 1 — Clarifier vos objets métier Avant tout outil, définissez explicitement : * Projet * Tâche * Note * Contact * Ressource Avec pour chacun : * Attributs * Relations * Cycle de vie (Si vous le souhaitez, je peux vous aider à formaliser ce modèle.) #### Étape 2 — Déployer Silverbullet comme *couche sémantique* * Silverbullet devient : * le **réseau de connaissances** * la **vue transverse** --- ## 4\. Quand Silverbullet devient clairement supérieur Vous devriez basculer pleinement si : * Vous raisonnez de plus en plus en **relations** plutôt qu’en listes. * Vous avez besoin de **requêtes dynamiques** (ex. “toutes les notes liées à des projets actifs cette semaine”). * Vous voulez **réduire la friction quotidienne**. * Vous êtes prêt à investir dans la **conception du système**, pas seulement son usage. Si, au contraire, votre activité reste majoritairement tabulaire, Excel restera difficile à battre. --- ## 1\. Principes structurants (fondations du système) Avant toute structure de dossiers ou de pages, adoptez ces principes. Ils conditionnent la réussite. ### 1.1. Silverbullet = couche sémantique centrale * Silverbullet n’est **ni un gestionnaire de fichiers**, ni un tableur. * Il est votre **réseau de connaissance actif** : * Projets * Notes * Décisions * Tâches contextualisées * Relations ### 1.2. Tout est texte, mais tout n’est pas une note Différenciez clairement : * **Objets structurés** (projet, tâche, contact) * **Connaissance libre** (notes, réflexions) * **Opérationnel** (journal, suivi, décisions) Cette distinction est capitale pour éviter un “wiki amorphe”. ### 1.3. Métadonnées > dossiers * Les dossiers servent à l’orientation humaine. * Les **métadonnées** servent à la logique et aux requêtes. --- ## 2\. Modèle conceptuel (objets métier) Je vous propose un modèle simple, extensible. ### Objets principaux | Objet | Rôle | | --- | --- | | Project | Unité de travail finalisée | | Task | Action concrète | | Note | Connaissance atomique | | Contact | Acteur humain | | Resource | Document, lien, référence | | Journal | Trace temporelle | --- ## 3\. Organisation des fichiers (architecture logique) ### 3.1. Arborescence recommandée ``` ├─ inbox/ ├─ journal/ │ ├─ 2026/ ... ``` **Pourquoi cette structure ?** * Lisible sans outil. * Stable dans le temps. * Compatible avec toute migration future. --- ## 4\. Métadonnées (frontmatter) C’est ici que Silverbullet prend tout son sens. ### 4.1. Projet ``` type: project status: active univers: PERSO start: 2026-01-01 due: 2026-03-31 tags: [web, client] ``` ### 4.2. Tâche ``` type: task status: todo project: p-website-refonte priority: high due: 2026-01-10 ``` ### 4.3. Note ``` type: note status: evergreen related: [p-website-refonte] ``` ### 4.4. Contact ``` type: contact role: client org: ACME ``` --- ## 5\. Architecture d’usage (comment vous travaillez réellement) ### 5.1. Inbox comme point d’entrée unique * Toute capture va dans ```/inbox```. * Aucune réflexion à ce stade. * Traitement quotidien ou hebdomadaire. --- ### 5.2. Journal comme colonne vertébrale Chaque jour : * Journal = **interface humaine** * Références vers projets, tâches, décisions. --- ### 5.3. Projets = pages mères Une page projet contient : * Objectif * Contexte * Liens vers : * tâches * notes * contacts * État synthétique --- ### 5.4. Notes atomiques * Une idée = une note. * Pas de notes fourre-tout. * Liens explicites. --- ## 6\. Dashboards (vues dynamiques) Dans ```/system/dashboards.md``` : * Projets actifs * Tâches à échéance < 7 jours * Notes récentes * Inbox non traitée Silverbullet v2 permet de les générer via requêtes (à implémenter progressivement). --- ## 7\. Gouvernance du système (règles d’or) ### Règles non négociables 1. **Pas de contenu sans type** 2. **Pas de projet sans page** 3. **Pas de tâche orpheline** 4. **Inbox vidée régulièrement** 5. **Templates obligatoires** ### Règles de sobriété * Pas d’automatisation tant que le besoin n’est pas stable. * Pas de complexité avant douleur réelle. --- ## 1\. Principes de pilotage pour un système volumineux Avant d’entrer dans la structuration pratique, il faut fixer les **règles fondamentales**. ### 1.1. Séparation des contextes * **Personnel / Associatif / Professionnel** doivent rester **logiquement distincts**, même si tous les projets sont dans Silverbullet. * Les liens peuvent exister (ex : compétence personnelle utilisée dans un projet associatif), mais **la hiérarchie doit rester claire**. ### 1.2. Tout projet, tâche ou note doit avoir un **objet et un contexte clair** * Projet = entité unique, avec ses objectifs, parties prenantes, deadlines. * Tâche = action atomique, reliée à un projet. * Note = information, liée éventuellement à un projet ou domaine. ### 1.3. Éviter l’amorphie * Pour gérer 80+ projets actifs, **la discipline est obligatoire**. * Tout élément doit être traçable via **métadonnées** : * ```type```, ```status```, ```area```, ```project```, ```tags```, ```priority```, ```due```, etc. ### 1.4. Hiérarchie et granularité * Projet global → Sous-projets → Tâches → Sous-tâches. * Notes et ressources rattachées au niveau adéquat. * Chaque action doit pouvoir être retrouvée via projet, contexte ou tag. --- ## 3\. Workflow centralisé et reproductible Voici un **workflow adapté à votre volume**. ### 3.1. Captures journalières * Inbox + Journal : capturer **idées, problèmes, tâches**, sans structuration. * Marquer le contexte (```area```) si connu. * Exemples : * Journal perso : noter idées, actions à formaliser. * Journal pro : noter problèmes, points à suivre dans projets clients. --- ### 3.2. Revue hebdomadaire (pivot) Pour chaque contexte : 1. Lister **projets actifs**. 2. Vérifier **tâches ouvertes**. 3. Identifier **bloqueurs et actions critiques**. 4. Mettre à jour le **journal / dashboard** avec décisions. 5. Transformer **tâches capturées dans l’inbox** en tâches formelles. 6. Créer ou mettre à jour les **sous-tâches si nécessaire**. > Chaque revue devient le moment clé de **pilotage actif**, pas juste de lecture. --- ### 3.3. Revue mensuelle / stratégique * Pour les projets professionnels, **regrouper par portefeuille client ou par domaine**. * Vérifier : * projets en retard, * projets proches de livraison, * projets prioritaires. * Ajuster la planification. --- ### 3.4. Gestion des tâches * Une **tâche = un fichier unique**. * Sous-tâches pour tout processus multi-étapes. * Liaison via ```depends_on```. * Classement par projet et contexte. * Zéro duplication : chaque action existe **une seule fois**. --- ## 4\. Pilotage par dashboard et requêtes Avec Silverbullet, **la force réside dans les requêtes et tableaux dynamiques**. ### 4.1. Dashboard type * Projets actifs par contexte. * Tâches critiques (```priority: high```, ```due: next 7 days```). * Tâches en retard. * Revues récentes et manquantes. * Notes ou décisions importantes non reliées à projet. ### 4.2. Avantage * Même avec **80+ projets actifs**, la vue humaine reste claire. * Vous pouvez naviguer par **priorité / blocage / contexte**. --- ## 5\. Gestion du volume et prévention de la dispersion ### 5.1. Discipline des métadonnées * Chaque projet/tâche/note doit avoir : * ```type``` * ```status``` * ```area``` * ```project``` (si tâche) * ```priority``` (si tâche) ### 5.2. Limiter les tâches à l’essentiel * Ne pas transformer une idée vague en tâche. * Les sous-tâches permettent de garder la granularité sans alourdir le système. ### 5.3. Hiérarchie claire * Projet parent → sous-projet → tâche → sous-tâche. * Liens bidirectionnels pour retrouver tout contexte. ### 5.4. Revue régulière = filtre cognitif * Chaque semaine : décider ce qui reste, ce qui est clos, ce qui doit être subdivisé. * Les revues deviennent **le cœur du pilotage**, pas un gadget. --- ## 7\. Synthèse opérationnelle 1. **Séparer clairement les contextes** (personnel / associatif / professionnel). 2. **Mettre en place un workflow journal → revue → tâche**, avec sous-tâches pour actions complexes. 3. **Revue hebdomadaire structurée** : piloter les projets actifs, formaliser les tâches, vérifier les blocages. 4. **Tâches uniques, projets hiérarchisés** : éviter les doublons et les tâches orphelines. 5. **Dashboard dynamique et requêtes Silverbullet** pour une vue synthétique. 6. **Python comme outil de contrôle et reporting** pour le volume et la fiabilité. --- # 1\. Workflow “Meeting” (notes de réunion) ### Objectif * Capturer **toutes les informations structurantes d’une réunion** : agenda, participants, décisions, actions. * Générer automatiquement les **tâches correspondantes**. ### 1.1. Frontmatter type ```meeting``` ```type: meeting date: 2026-01-05 project: p-clientX area: professional attendees: [Alice, Bob] status: completed tags: [weekly, clientX]``` ### 1.2. Structure interne de la note ```# Réunion – Client X – 2026-01-05 ## Agenda - Point technique serveur - Suivi tâches en cours ## Notes / Discussion - Blocage identifié sur SMTP - Besoin validation client ## Décisions - Valider la configuration serveur ## Actions / Tâches - [[t-2026-101]] Vérifier logs serveur - [[t-2026-102]] Contacter le client pour infos supplémentaires``` ### 1.3. Règles pratiques 1. **Toutes les actions importantes → tâches** (notes ```task```) 2. Les décisions importantes → note ```decision``` (optionnelle, si vous souhaitez historiser) 3. Les notes non-actionables → restent dans la note ```meeting``` 4. **Lien projet / sous-projet** via frontmatter (```project:```) 5. Backlinks automatiques pour retrouver toutes les actions issues de cette réunion --- # 2\. Workflow “Revue hebdomadaire” ### Objectif * Piloter l’avancement des projets actifs, suivre les tâches ouvertes, identifier les blocages. * Transformer les entrées du journal en tâches ou notes. ### 2.1. Frontmatter type ```review``` ```type: review period: weekly week: 2026-W02 date: 2026-01-12 area: professional scope: active_projects status: completed``` ### 2.2. Structure interne du template ```# Revue hebdomadaire – Semaine 02 / 2026 ## 1. Projets actifs ### [[p-clientX]] - Statut : actif - Avancement réel : 70% - Blocages : validation client - Actions : - [[t-2026-101]] - [[t-2026-102]] ### [[p-clientY]] - Statut : en retard - Blocages : ressources internes - Actions : - [[t-2026-110]] ## 2. Tâches critiques / priorités - [[t-2026-105]] Déploiement serveur urgent - [[t-2026-112]] Relancer client pour approbation ## 3. Décisions prises - [[n-decision-validerSMTP]] Validation serveur SMTP ## 4. Notes / Observations importantes - Ajuster planning association``` ### 2.3. Processus 1. Lire le journal de la semaine 2. Transformer les items actionnables en tâches (```task```) 3. Relier les actions à projets / sous-projets 4. Noter les décisions importantes 5. Vérifier que toutes les revues passées et projets actifs sont à jour 6. Marquer la revue comme ```status: completed``` --- # 3\. Workflow “Ressource / Référence” ### Objectif * Centraliser documents, liens et références importantes pour les projets. * Permettre recherche et liaison avec projets ou tâches. ### 3.1. Frontmatter type ```resource``` ```type: resource project: p-clientX area: professional tags: [documentation, SMTP, serveur] date_added: 2026-01-05 status: available``` ### 3.2. Contenu type ```# Ressource – Configuration SMTP Client X ## Description Guide officiel de configuration du serveur SMTP client X. ## Liens - [[p-clientX]] - [[t-2026-101]] - URL externe : https://docs.clientx.com/smtp ## Notes - Vérifier compatibilité avec serveur interne``` ### 3.3. Règles pratiques * Ne jamais transformer une ressource en tâche * Toujours lier les ressources aux projets/tâches concernées * Mettre à jour les tags et dates pour faciliter le reporting --- # 4\. Workflow “Revue quotidienne” (optionnel mais recommandé) ### Objectif * Traiter **rapidement les captures du journal**, réunions du jour, actions immédiates. * Préparer la revue hebdomadaire avec un backlog structuré. ### 4.1. Quand l’utiliser * Si vous avez beaucoup d’entrées journalières (journal, réunions, notes personnelles) * Si les tâches du jour doivent être priorisées avant revue hebdo ### 4.2. Template type “Revue quotidienne” ```type: review period: daily date: 2026-01-05 area: personal/professional/assoc1 status: completed``` ```# Revue quotidienne – 2026-01-05 ## 1. Notes / captures du jour - [[journal/2026-01-05]] – idées / incidents ## 2. Tâches à traiter - [[t-2026-101]] Vérifier logs serveur - [[t-2026-103]] Relancer client ## 3. Réunions du jour - [[meeting/meeting-clientX-2026-01-05]] - Actions issues des meetings déjà formalisées ## 4. Observations - Ajustements rapides de planning``` * Permet de **transformer ```- [ ]``` en tâches formalisées**. * Permet de filtrer les actions critiques à traiter immédiatement. --- # 5\. Workflow “Revue mensuelle / stratégique” ### Objectif * Vue globale sur **tous les projets actifs** * Identifier les priorités, les projets à risque, ajuster planning ou ressources. ### 5.1. Frontmatter ```type: review period: monthly month: 2026-01 area: professional status: completed scope: all_active_projects``` ### 5.2. Structure ```# Revue mensuelle – Janvier 2026 ## 1. Synthèse projets actifs - Projet X : en avance - Projet Y : retard - Projet Z : critique ## 2. Tâches critiques / blocages - [[t-2026-150]] Déploiement serveur - [[t-2026-151]] Validation client ## 3. Décisions stratégiques - Déprioriser projet interne - Ajouter ressource supplémentaire à projet Y ## 4. Observations / améliorations du système - Ajuster workflow revue hebdo - Vérifier tâches orphelines``` * Permet de **corréler hebdo → mensuel** pour pilotage stratégique --- # 7\. Workflow global consolidé ``` [ Journal quotidien / capture rapide ] │ ▼ [ Meetings / notes réunions ] │ ▼ [ Revue quotidienne (optionnelle) ] - Formalisation tâches issues journal/meetings - Vérification priorités │ ▼ [ Revue hebdomadaire ] - Pilotage projets actifs - Transformation journal en tâches - Décisions et suivi │ ▼ [ Revue mensuelle ] - Synthèse stratégique - Ajustement priorités et ressources │ ▼ [ Dashboard / reporting ] - Vue projets actifs - Tâches critiques - Actions issues meetings - Revues manquantes ``` --- > *“Dans Silverbullet, je classe peu, je relie beaucoup, et je pilote par revue.”* --- --- ## 1\. Pourquoi ```/notes/``` doit rester plat ### 1.1. La fonction réelle de ```/notes/``` Le dossier ```/notes/``` n’est pas : * un espace d’archivage * un équivalent de “Documents” * un classement par thème Il est : **un réservoir de connaissances, d’analyses et d’idées transverses** Or ces éléments : * vivent plus longtemps que les projets * concernent souvent plusieurs domaines * changent de statut dans le temps Une arborescence thématique devient alors **contre-productive**. --- ### 1.2. Le coût caché des sous-dossiers Créer des sous-dossiers implique que **vous sachiez à l’avance** : * le thème dominant * le domaine * la stabilité du sujet Or dans la réalité : * une note “authentification” peut concerner 6 projets * une note “organisation” peut être perso → pro → associatif * une idée peut devenir un standard interne Chaque sous-dossier crée : * une friction au moment de la création * une dette de reclassement future --- ### 1.3. Silverbullet n’exploite pas l’arborescence comme un outil cognitif Silverbullet est optimisé pour : * liens bidirectionnels * requêtes * métadonnées Il **n’exploite pas la hiérarchie de dossiers comme un outil sémantique**. 👉 Utiliser des sous-dossiers pour structurer la connaissance revient à **aller contre l’outil**. --- ## 2\. Comment structurer ```/notes/``` sans sous-dossiers ### 2.1. Par métadonnées (obligatoire) ```type: note area: professional topics: [authentification, architecture] related_projects: [p-clientX, p-clientY] status: evergreen``` * ```topics``` remplace les sous-dossiers thématiques * ```related_projects``` remplace les classements par client * ```area``` remplace les dossiers perso/pro/assoc --- ### 2.2. Par liens explicites Dans les projets : ```## Notes de référence - [[n-architecture-auth]] - [[n-standard-securite]]``` Dans les notes : ```## Utilisé dans - [[p-clientX]] - [[p-clientY]]``` La navigation devient **contextuelle**, pas hiérarchique. --- ### 2.3. Par requêtes et dashboards Exemples : * “Toutes les notes ```topic: authentification```” * “Toutes les notes liées à ```p-clientX```” * “Notes ```status: draft``` non revues depuis 6 mois” C’est **impossible** à faire correctement avec des sous-dossiers. --- ## 3\. Le seul cas où un sous-dossier est acceptable ### 3.1. Notes générées automatiquement ou massivement Exemples : * import automatique * logs structurés * notes temporaires générées par script Dans ce cas : ```/notes/_generated/``` Règles strictes : * préfixe ```_``` explicite * pas de navigation humaine * cycle de vie clair (archivage / purge) 👉 Ce sous-dossier n’est **pas sémantique**, il est **technique**. --- ## 4\. Ce que font les systèmes qui tiennent dans le temps Tous les systèmes robustes (Obsidian avancé, Zettelkasten modernes, systèmes PKM professionnels) convergent vers : * arborescence **fonctionnelle**, pas thématique * métadonnées et liens pour le sens * revues pour maintenir l’ordre Les systèmes qui “s’effondrent” sont presque toujours : * très bien classés au début * impossibles à maintenir après 2–3 ans --- # 1\. Les principes non négociables ### Principe 1 — Le système n’est pas un stockage, c’est un instrument de décision Si une information n’influence **aucune décision future**, elle doit : * soit être archivée sans soin excessif * soit être supprimée Votre objectif n’est pas la complétude, mais la **pertinence active**. --- ### Principe 2 — La dynamique vient du temps, pas de la structure Un système figé meurt. Un système vivant : * revoit * ferme * archive * reformule 👉 **Les revues sont plus importantes que l’arborescence.** --- ### Principe 3 — Toute information doit avoir un “propriétaire” Dans votre cas, ce propriétaire est : * un projet * une revue * une décision Une note sans rattachement est **temporairement acceptable**, durablement toxique. --- # 2\. Les mécanismes de pilotage (le cœur du système) ## 2.1. Le triptyque fondamental ```Capture → Clarification → Pilotage``` | Étape | Outil principal | | --- | --- | | Capture | Journal, Meetings | | Clarification | Revue quotidienne / hebdo | | Pilotage | Revues hebdo / mensuelles | Si une note reste bloquée à l’étape “Capture”, elle devient un déchet informationnel. --- ## 2.2. États explicites (très important) Chaque objet structurant doit avoir un **état clair** : * Projet : ```active / paused / closed``` * Tâche : ```todo / waiting / blocked / done``` * Note : ```draft / evergreen / obsolete``` * Meeting : ```planned / completed / processed``` 👉 Ce sont ces états qui rendent le système **requêtable** et donc pilotable. --- # 3\. Les rituels concrets (ce qui empêche de se perdre) ## 3.1. Revue quotidienne (10–15 min) **Objectif : vider l’entrée** À faire : * Parcourir le journal du jour * Parcourir les réunions du jour * Transformer les actions en tâches * Marquer les meetings comme ```processed``` Question clé : > “Est-ce que tout ce qui est actionnable a été formalisé ?” --- ## 3.2. Revue hebdomadaire (45–60 min) **Objectif : garder le contrôle** À faire systématiquement : * Passer en revue **tous les projets actifs** * Vérifier qu’aucun projet n’a : * zéro tâche active * zéro note récente * zéro réunion traitée * Identifier : * tâches bloquées * décisions à prendre * projets à clôturer ou mettre en pause Question clé : > “Suis-je en train de piloter, ou juste de réagir ?” --- ## 3.3. Revue mensuelle (60–90 min) **Objectif : éviter l’illusion de productivité** À faire : * Lister tous les projets actifs * En fermer volontairement * En mettre certains en pause * Vérifier l’alignement charge / capacité Question clé : > “Si je ne pouvais en garder que 50 %, lesquels mériteraient vraiment mon attention ?” --- # 4\. Garde-fous anti-dérive (très concrets) ## 4.1. Détection automatique (fortement recommandé) Avec requêtes ou scripts Python : * Tâches sans projet * Notes sans lien depuis 30 jours * Meetings ```completed``` mais non ```processed``` * Projets actifs sans revue hebdo récente * Notes ```draft``` non relues depuis 3 mois 👉 Ce sont vos **alertes système**. --- ## 4.2. Règle des “3 clics cognitifs” Si pour répondre à une question vous devez : * ouvrir plus de 3 fichiers * ou parcourir 3 dossiers 👉 le système est mal piloté, pas mal classé. --- ## 4.3. Règle de fermeture Un système dynamique **ferme plus qu’il n’ouvre** : * fermez les projets terminés * archivez les notes obsolètes * marquez les décisions comme prises Un système sans fin est un système anxiogène. --- # 5\. Comment savoir si votre système reste sain Posez-vous chaque semaine : 1. Ai-je une vue claire de mes priorités ? 2. Puis-je dire ce qui est bloqué ? 3. Puis-je dire ce que je ne ferai pas ? 4. Les notes que je consulte influencent-elles mes décisions ? Si une réponse est “non”, le problème n’est **jamais** l’arborescence. --- # 6\. Phrase clé à garder en tête > **Un bon système n’est pas celui qui contient tout, > mais celui qui vous dit clairement quoi faire ensuite.** --- # Système de gestion Silverbullet **Documentation d’usage et de référence** --- ## 1\. Finalité du système Ce système Silverbullet a pour objectif de : * Centraliser **projets, tâches, issues, notes, réunions et revues** * Assurer une **traçabilité complète** (ce qui a été fait, quand, pourquoi) * Supporter une **charge élevée de projets actifs** sans perte de lisibilité * Éviter les outils multiples, plugins excessifs ou modèles trop rigides * Rester **simple à maintenir**, même en croissance Silverbullet est utilisé ici comme : * un **système de pilotage** * un **journal d’activité** * une **base de connaissance vivante** --- ## 2\. Principes fondamentaux ### 2.1. Source de vérité * Les **fichiers Markdown** sont la source de vérité * Pas de duplication de contenu critique * Les liens sont préférés aux copies ### 2.2. Peu de types, bien définis Les objets métier sont limités et clairement identifiés : * Projet * Issue * Task * Note * Meeting * Revue * Ressource * Contact Chaque type a : * un rôle clair * un cycle de vie explicite * des règles d’usage simples ### 2.3. Historique immuable * Les revues sont **datées** * On ne modifie pas le passé * Les décisions restent traçables --- ## 3\. Hiérarchie globale ```Projet ├─ Issue (optionnelle) │ ├─ Task │ └─ Task └─ Task``` * **Projet** : vision globale, long terme * **Issue** : sous-projet ou problème ponctuel * **Task** : action concrète --- ## 4\. Objets métier ### 4.1. Projet **Rôle** Un projet représente un objectif global, sur une période longue, avec plusieurs livrables ou sujets. **Frontmatter standard** ```type: project category: project status: active | paused | closed area: personal | professional | association priority: low | medium | high start_date: YYYY-MM-DD due_date: YYYY-MM-DD tags: []``` **Contenu** * Description du projet * Liste des issues * Tâches directes * Revues datées * Liens vers réunions, ressources, contacts --- ### 4.3. Task **Rôle** Une tâche est une action concrète, exécutable, finie. **Frontmatter** ```type: task status: todo | in_progress | blocked | waiting | done priority: low | medium | high project: estimated_time: 1h actual_time: 0h tags: []``` **Sous-tâches** * Utiliser ```- [ ]``` uniquement pour : * étapes internes * travail exploratoire * actions jetables * Si une sous-tâche devient bloquante ou longue → **task indépendante** --- ### 4.4. Note **Rôle** Capturer de l’information, des idées, des constats. **Règles** * Une note n’est pas une tâche * Une note peut devenir actionnable plus tard ```type: note status: draft | evergreen | obsolete tags: [] related_projects: []``` --- ### 4.5. Meeting **Rôle** Réunion structurante liée à un projet ou une issue. **Contenu type** * Contexte * Participants * Décisions * Actions (liens vers tasks) ```type: meeting date: YYYY-MM-DD project: participants: []``` --- ### 4.6. Revue **Rôle** Moment de pilotage, pas de narration. Il existe plusieurs niveaux : * Revue quotidienne * Revue hebdomadaire * Revue projet / issue * Revue mensuelle (optionnelle) --- ## 5\. Workflow principal ### 5.1. Journal → Action 1. Capture rapide dans le journal 2. Identification : * information → note * action simple → ```- [ ]``` * action structurante → task * problème récurrent → issue --- ### 5.2. Exécution * Les tâches évoluent par statut * Les sous-tâches servent à avancer vite * Le journal trace ce qui a été fait --- ### 5.3. Revue quotidienne (recommandée) **Objectifs** * Traiter le journal * Transformer les notes en actions * Mettre à jour les statuts **Durée cible** : 10–15 minutes --- ### 5.4. Revue hebdomadaire **Objectifs** * Vérifier l’avancement des projets actifs * Identifier blocages et priorités * Créer ou fermer issues et tâches **Structure type** ```# Revue hebdo – Semaine XX ## Projets actifs - [[Projet A#2026-01-05]] - [[Projet B#2026-01-04]] ## Points d’attention - ... ## Actions prioritaires - ...``` --- ### 5.5. Revue projet / issue * Intégrée directement dans le fichier du projet ou de l’issue * Sections datées * Source de vérité pour le pilotage --- ## 6\. Gestion du temps et reporting ### Principe * Le **journal** est la source principale * Les tâches peuvent porter une estimation * Le temps réel est consolidé a posteriori ### Usage de Python (optionnel) Python est utile pour : * consolider le temps par projet * générer des rapports mensuels * vérifier les tâches orphelines * analyser la charge par domaine Python ne pilote pas le système, il **l’exploite**. --- ## 7\. Organisation des fichiers ### Règles * Pas de sous-dossiers complexes pour les notes * Les liens remplacent l’arborescence * Les types sont identifiés par le frontmatter **Exception** * Journaux par date * Revues par période si souhaité --- ## 8\. Règles pour rester efficace 1. Ne pas créer d’objet sans intention claire 2. Si hésitation entre task et issue → commencer par task 3. Toute décision importante passe par une revue 4. Toute complexité doit être justifiée par un gain réel 5. Réviser le système régulièrement --- ## 9\. Évolution du système Ce document est : * vivant * perfectible * adaptable Ajoutez ici : * vos règles personnelles * vos exceptions * vos améliorations --- ## 10\. Journal des ajustements ```## YYYY-MM-DD - Changement : - Raison : - Impact :``` --- ### Conclusion Ce système privilégie : * la clarté * la traçabilité * la sobriété Il est conçu pour **tenir dans la durée**, même avec plusieurs dizaines de projets actifs.