| name | knowledge-management |
| description | Use when designing or maintaining knowledge management systems — wikis, knowledge bases, Zettelkasten, note-taking architectures, and organizational memory. |
| version | 1.0.0 |
| author | EVA |
| license | MIT |
| metadata | {"hermes":{"tags":["knowledge-management","wiki","knowledge-base","zettelkasten","obsidian","notes","second-brain"],"related_skills":["information-architecture","markdown-systems","documentation-systems"]}} |
Knowledge Management
Overview
Le Knowledge Management (KM) est la discipline qui transforme l'information individuelle en mémoire organisationnelle réutilisable. Ce skill fournit les modèles, structures et workflows pour concevoir un système de gestion des connaissances — du wiki d'équipe au second-brain personnel — en maximisant la trouvabilité, la maintenabilité et l'évolutivité.
When to Use
- L'utilisateur demande de structurer un wiki, une base de connaissances ou un vault Obsidian
- Vous devez auditer ou restructurer un référentiel de documentation existant
- Création d'un système de notes interconnectées (Zettelkasten, PARA, etc.)
- Définition de taxonomies, tags et conventions pour un dépôt de connaissances
- Planification d'une migration de connaissances (outil A vers outil B)
Ne pas utiliser pour : la rédaction de contenu spécifique (utiliser technical-writing), la documentation d'API (api-documentation).
Architecture d'un Système de Connaissances
Les 3 Couches d'un KM
1. ATOMIQUE (notes / fragments)
└─ Idéal : notes fugaces, concepts atomiques, sources brutes
2. STRUCTURÉE (pages / articles)
└─ Synthèses, guides, procédures — contenu réutilisable
3. NAVIGATION (index / MOC / tags)
└─ Maps of Content, catégories, taxonomies — portes d'entrée
Principes Fondamentaux
- Atomicité — Une note = un concept. Si une note peut être divisée, divisez-la.
- Connexion explicite — Chaque note a des liens sortants vers au moins 2 autres notes.
- Source de vérité unique — Un concept est défini à un seul endroit ; les autres notes y font référence.
- Gradualité — Commencer petit, laisser la structure émerger de l'usage. Ne pas sur-modéliser au départ.
- Rétro-trouvabilité — Une note doit pouvoir être retrouvée par au moins 3 chemins différents (tag/titre/lien/plein-texte).
Méthodologies de KM
Zettelkasten (Luhmann)
- Notes atomiques (idées uniques) avec identifiant horodaté
- Liens bidirectionnels entre notes
- Notes d'index (hub notes) qui organisent des clusters
- Notes de structure (MOC — Maps of Content) qui remplacent les catégories rigides
PARA (Tiago Forte)
| Type | Contenu | Action |
|---|
| Projects | Résultats avec deadline | Actif / terminé / gelé |
| Areas | Responsabilités continues | Sans deadline, standard à maintenir |
| Resources | Sujets d'intérêt | Référence, veille, apprentissage |
| Archives | Inactif | Tout ce qui n'est plus actif |
DIKW Pyramid
Données → Information → Connaissance → Sagesse
- Chaque niveau ajoute du contexte et de la relation
Taxonomie et Tags
Règles pour un Système de Tags Sain
- Tags hiérarchiques limités —
#devops/kubernetes, #lang/python (max 2 niveaux)
- Pas de tags redondants avec la structure — si le dossier s'appelle
API/, pas besoin de tag #api
- Tags de statut —
#status/draft, #status/approved, #status/stale
- Tags de type —
#type/tutorial, #type/reference, #type/concept, #type/glossary
- Tags de public —
#audience/dev, #audience/ops, #audience/pm
Frontmatter Standard pour Notes de Connaissances
---
title: "Titre de la Note"
created: 2026-07-22
updated: 2026-07-22
tags: [tag1, tag2/ss]
status: draft | approved | stale
type: concept | tutorial | reference | glossary
sources:
- url: https://...
title: "Article source"
related:
- "[[Note liée A]]"
- "[[Note liée B]]"
---
Workflow de Capture → Révision → Publication
- Capture — Note brute (idée, citation, lien). Pas de structure, juste le contenu.
- Clarification — Reformulation personnelle. Ajout de contexte et de liens.
- Classification — Tags, type, status, relations
- Intégration — Liens entrants/sortants, mise à jour des MOC concernés
- Révision — Relecture, cohérence, exactitude (périodique)
- Publication — Si applicable, transformation en documentation publique
Maintenance et Hygiène
- Revue trimestrielle — Identifier les notes orphelines (sans liens entrants ni sortants)
- Linting automatique — Vérifier les liens brisés, les tags inutilisés, les doublons
- Consolidation — Notes trop proches fusionnées ; notes trop larges fractionnées
- Date de péremption — Les notes techniques > 6 mois non révisées reçoivent un flag
#status/stale
Outils Recommandés
| Besoin | Outil |
|---|
| Vault personnel | Obsidian |
| Wiki d'équipe | Wiki.js, Gollum, DokuWiki |
| Base de connaissances | Confluence, BookStack |
| Linting notes | obsidian-linter, markdownlint |
| Graphe navigation | Obsidian Graph View, Foam (VS Code) |
| Backup | Git (toute base textuelle) |
Common Pitfalls
- Sur-structuration précoce. Définir trop de catégories et tags avant d'avoir du contenu mène à un système vide. Laissez la structure émerger des 50 premières notes.
- Notes orphelines. Une note sans lien sortant est un silo. Une note sans lien entrant est une île. Les deux sont à corriger.
- Duplication involontaire. Sans recherche avant d'écrire, on recrée des notes qui existent déjà. Toujours chercher d'abord.
- Collectionnite. Capturer sans réviser crée un cimetière de notes. Le ratio capture/révision devrait être ~3:1.
- Absence de standards. Sans frontmatter et conventions de tags, le système devient chaotique au-delà de 200 notes.
Verification Checklist
