Construire un knowledge hub Obsidian avec Claude Code : guide pas à pas

Ce guide complète l'article Obsidian et Claude Code : structurer un knowledge hub freelance qui couvre le "pourquoi". Ici, c'est le "comment".

Le lecteur cible : un freelance ou indépendant qui enchaîne les projets clients, qui utilise Claude Code (ou un assistant IA similaire), et qui veut capitaliser sur chaque mission au lieu de repartir de zéro. Pas besoin d'être développeur, mais il faut être à l'aise avec le markdown et un terminal.

1. Ce qu'il faut avant de commencer

Obsidian installé. Gratuit, disponible sur Mac, Windows, Linux. C'est un éditeur markdown qui fonctionne sur un dossier local de fichiers — pas de cloud propriétaire, pas de format fermé. On l'installe depuis obsidian.md.
Claude Code installé. Le CLI d'Anthropic. Installation via npm install -g @anthropic-ai/claude-code, lancement avec claude dans le terminal.
Un terminal. Toutes les commandes ici sont des mkdir, ln -s et des git. Rien de technique.
De la matière à migrer. Notes clients, positionnement, études de cas, schémas techniques — même en vrac, même dans un coin de Google Docs ou un dossier de fichiers éparpillés. S'il n'y a rien à migrer, le système se remplira au fil des projets.
git installé. Optionnel mais recommandé. Le versioning protège contre les erreurs d'écriture — les nôtres et celles de Claude. Un simple git init + commit réguliers suffit.

2. Créer le vault et poser les fondations

Créer le dossier

Créer un dossier n'importe où sur le disque. Le nom n'a pas d'importance — c'est le symlink (étape suivante) qui standardise le chemin.

mkdir -p ~/Documents/mon-vault

Ouvrir Obsidian → "Open folder as vault" → sélectionner le dossier.

La structure PARA numérotée

PARA (Projects, Areas, Resources, Archive), c'est la structure qui revient le plus dans les vaults Obsidian qui tiennent la durée. Les numéros garantissent un tri fixe dans tous les explorateurs de fichiers et dans les chemins CLI.

cd ~/Documents/mon-vault
mkdir -p 00-Inbox \
         10-Projects \
         20-Areas/{Business,Clients,Content,Tech} \
         30-Resources/{Case-Studies,Frameworks,Templates} \
         40-Archive \
         _Meta

Pourquoi PARA et pas du flat ? Le consensus Obsidian converge sur un constat : pure hiérarchie profonde = échec (on ne retrouve rien). Pure flat = échec à l'échelle (tout se mélange). PARA donne un arbre de décision clair ("où va ce fichier ?") sans profondeur excessive — trois niveaux maximum.

Le lien symbolique ~/vault

ln -s ~/Documents/mon-vault ~/vault

Tous les chemins dans les fichiers de configuration (CLAUDE.md, @references) utiliseront ~/vault/.... Si le vault est renommé ou déplacé, il suffit de mettre à jour le lien symbolique — pas les dizaines de références éparpillées dans les projets clients.

Initialiser git

cd ~/vault
git init

Créer un .gitignore minimal :

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

On versionne la config Obsidian (thèmes, plugins) mais pas le workspace (positions de fenêtres, dernier fichier ouvert — ça change à chaque session).

Premier commit

git add -A && git commit -m "Init vault PARA structure"

Vérification

Le vault devrait ressembler à ça :

~/vault/
├── .git/
├── .gitignore
├── 00-Inbox/
├── 10-Projects/
├── 20-Areas/
│   ├── Business/
│   ├── Clients/
│   ├── Content/
│   └── Tech/
├── 30-Resources/
│   ├── Case-Studies/
│   ├── Frameworks/
│   └── Templates/
├── 40-Archive/
└── _Meta/

Obsidian montre les dossiers dans le panneau latéral. Si le tri est correct (00, 10, 20, 30, 40, _Meta), la structure PARA est en place.

3. Définir le schéma de frontmatter

C'est l'étape la plus importante du guide. Le frontmatter YAML, c'est l'API du vault. C'est ce qui fait que Claude Code (et nous dans six mois) sait exactement ce qu'il regarde sans lire le contenu.

Créer le fichier Schema.md

touch ~/vault/_Meta/Schema.md

Puis, dans Claude Code ou directement dans Obsidian, rédiger le schéma. Un bon point de départ :

---
type: moc
tags: [meta, schema]
---

# Schema du vault

Contrat de format pour les notes du vault. Chaque note a un frontmatter YAML
avec un champ `type` obligatoire.

## Types et champs requis

### client
Fiche client dans `20-Areas/Clients/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `client` |
| status | oui | `active`, `past`, `prospect` |
| sector | oui | texte libre |
| contact | non | nom de l'interlocuteur principal |
| start-date | non | YYYY-MM-DD |
| tags | oui | `[client]` + tags libres |

### project
Index de projet dans `10-Projects/{slug}/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `project` |
| client | oui | `[[slug-client]]` |
| status | oui | `active`, `paused`, `done` |
| start-date | oui | YYYY-MM-DD |
| end-date | non | YYYY-MM-DD |
| tags | oui | `[project]` + tags libres |

### pattern
Pattern technique réutilisable dans `20-Areas/Tech/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `pattern` |
| tech | oui | `weweb`, `supabase`, `n8n`, `claude-code`, etc. |
| source-project | non | `[[slug-projet]]` d'origine |
| tags | oui | `[pattern]` + tags libres |

### case-study
Étude de cas dans `30-Resources/Case-Studies/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `case-study` |
| client | oui | `[[slug-client]]` |
| status | oui | `draft`, `published` |
| result | non | métrique clé (ex: "-40% temps de traitement") |
| tags | oui | `[case-study]` + tags libres |

### business
Fichier Business dans `20-Areas/Business/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `business` |
| tags | oui | `[business]` + tags libres |

### content
Contenu éditorial dans `20-Areas/Content/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `content` |
| format | non | `blog`, `linkedin`, `newsletter` |
| status | non | `draft`, `published` |
| tags | oui | `[content]` + tags libres |

### moc
Map of Content (index) dans `_Meta/`.
| Champ | Obligatoire | Valeurs |
|-------|-------------|---------|
| type | oui | `moc` |
| tags | oui | `[moc]` + tags libres |

Pourquoi un schéma

Un vault sans schéma, c'est une base de données sans structure. Ça marche quand il y a 10 notes. À 50, on ne sait plus ce qui est une fiche client, un schéma technique, ou une note de réunion. Le frontmatter est le contrat : type: client + status: active = pas d'ambiguïté.

Le schéma va bouger. C'est normal. Les premières semaines, on ajoute des champs, on en supprime, on change des noms. L'important : stabiliser avant de migrer en masse. Créer 3-4 fiches tests, ajuster le schéma, puis migrer le reste. Refactorer 4 fiches, c'est 10 minutes. Refactorer 40 fiches, c'est une après-midi.

Exemple de fiche client complète

---
type: client
status: active
sector: "Économie circulaire"
contact: Marie Dupont
start-date: 2026-01-15
tags: [client, b2b, saas]
---

# Goodloop Pro

## Contexte
PME économie circulaire, 15 collaborateurs. Besoin d'un portail partenaires B2B
pour gérer les flux de matières entre collecteurs et recycleurs.

## Interlocuteurs
- **Marie Dupont** — CEO, décisionnaire
- **Thomas** — opérations, utilisateur principal

## Livré
- Portail partenaires Weweb + Supabase
- 3 workflows n8n (synchro stock, notifications, reporting)
- RLS multi-tenant

## Apprentissages
- Le multi-tenant Supabase nécessite des policies RLS par organisation, pas par user
- Les composants Weweb custom sont plus maintenables que les natifs pour les tableaux complexes

## Liens
- Projet : [[goodloop-pro]]
- Case study : [[goodloop-case-study]]

Conventions de nommage

Dossiers en majuscule : Business/, Clients/, Tech/
Fichiers en kebab-case : goodloop-pro.md, rls-multi-tenant.md
Pourquoi : les dossiers en majuscule ressortent mieux dans le panneau Obsidian. Le kebab-case pour les fichiers évite les espaces dans les chemins CLI.

4. Remplir le socle Business

Avant les fiches clients, on pose les fondations : les fichiers Business que tous les projets clients référenceront. C'est le socle. Dans mon cas, c'est ce qui a pris le plus de temps à écrire (et le moins de temps à rentabiliser).

Les fichiers à créer

Trois fichiers minimum dans 20-Areas/Business/ :

Fichier	Contenu
`positionnement.md`	Cible, proposition de valeur, différenciation
`offre.md`	Ce qu'on fait, format, process, tarification
`stack.md`	Outils utilisés, pourquoi ceux-là

Un quatrième optionnel : objectifs.md (objectifs de l'année, métriques clés).

Exemple : positionnement.md

---
type: business
tags: [business, positionnement]
---

# Positionnement

## Cible
Dirigeants de PME (500k-5M€ CA) sans équipe technique interne.

## Proposition de valeur
Livraison clé en main d'outils digitaux métier — portails clients, apps B2B,
outils partenaires. Forfait fixe, 6-8 semaines, build & exit.

## Différenciation
- Stack moderne (Weweb + Supabase + n8n) = pas de dette technique
- Produit fini, pas un prototype — documentation, tests, formation inclus
- Profil hybride business (HEC + VC) et technique

Avec Claude Code

Si les infos existent en vrac (site web, notes, propositions commerciales), Claude peut dégrossir une V1 :

Lis les fichiers suivants et crée une fiche positionnement structurée
dans ~/vault/20-Areas/Business/positionnement.md avec le frontmatter
type: business, tags: [business, positionnement].

- ~/Documents/mon-site/about.md
- ~/Documents/notes/positioning-draft.md

Ajuster le résultat manuellement. Claude donne la structure, on apporte la nuance.

Pourquoi en premier

Tout le reste référence ces fichiers. Le CLAUDE.md de chaque projet client importera @~/vault/20-Areas/Business/positionnement.md. Si ces fichiers n'existent pas au moment de connecter Claude Code (étape 8), le système démarre avec un trou au milieu.

5. Migrer les fiches clients

Le modèle

Chaque client a une fiche dans 20-Areas/Clients/{slug}.md. Le slug (l'identifiant court du client) est en kebab-case : goodloop-pro.md, belza-ai.md, acme-corp.md.

Structure type :

---
type: client
status: active
sector: "Industrie papier-carton"
contact: Jean Martin
start-date: 2026-02-01
tags: [client, b2b]
---

# Belza AI

## Contexte
[Qui est le client, quel problème, quel secteur]

## Interlocuteurs
- **Jean Martin** — CEO

## Livré
[Ce qui a été construit, les livrables]

## Stack utilisée
[Les technos spécifiques à ce projet]

## Apprentissages
[Ce qu'on a appris — les schémas réutilisables, les pièges]

## Liens
- Projet : [[belza-ai-project]]
- Case study : [[belza-ai-case-study]] (si applicable)

Avec Claude Code

Si on a des notes client existantes (emails, briefs, proposals), Claude peut faire le gros du travail :

J'ai des notes sur mes clients dans ~/Documents/Missions/. Chaque sous-dossier
est un client. Lis les fichiers de ~/Documents/Missions/Goodloop/ et crée une
fiche client dans ~/vault/20-Areas/Clients/goodloop-pro.md conforme au schéma
défini dans ~/vault/_Meta/Schema.md.

Ne pas migrer tout d'un coup. Commencer par les 3-4 clients les plus récents — ceux dont le contexte est encore frais. Les anciens clients se migreront au fil du temps, quand et si le besoin se présente. Un vault vivant vaut mieux qu'un vault complet mais jamais rouvert.

Vérification

Après 3 fiches clients :

~/vault/
├── 00-Inbox/
├── 10-Projects/
├── 20-Areas/
│   ├── Business/
│   │   ├── positionnement.md
│   │   ├── offre.md
│   │   └── stack.md
│   ├── Clients/
│   │   ├── goodloop-pro.md
│   │   ├── belza-ai.md
│   │   └── izuba-mobile.md
│   ├── Content/
│   └── Tech/
├── 30-Resources/
│   ├── Case-Studies/
│   ├── Frameworks/
│   └── Templates/
├── 40-Archive/
└── _Meta/
    └── Schema.md

Le vault commence à avoir de la matière. Les fiches sont conformes au schéma, les wikilinks connectent les notes entre elles.

6. Études de cas et schémas techniques réutilisables

C'est ici que le vault passe d'un annuaire à une base de connaissances.

Les études de cas

Elles vivent dans 30-Resources/Case-Studies/. Une par projet publiable.

---
type: case-study
client: "[[goodloop-pro]]"
status: draft
result: "-40% temps de traitement des commandes partenaires"
tags: [case-study, portail-b2b, weweb, supabase]
---

# Goodloop Pro — Portail partenaires B2B

## Résumé
[2-3 phrases. Le pitch de l'étude de cas.]

## Le problème
[Qu'est-ce que le client vivait avant l'intervention ?]

## La solution
[Qu'est-ce qui a été construit et comment ?]

## Les résultats
[Métriques, témoignage client si disponible]

## Stack et patterns
- Weweb : composants custom pour tableaux avec filtres dynamiques
- Supabase : RLS multi-tenant par organisation
- n8n : workflows de notification et synchro stock

Fusion version courte/longue : Si des études de cas existent déjà en double (version courte marketing + version longue détaillée), la version longue devient la fiche vault. La version courte devient la section "Résumé" en haut. Un seul fichier par étude de cas.

Les schémas techniques réutilisables

Ils vivent dans 20-Areas/Tech/{techno}/. Un fichier par schéma, classé par technologie.

---
type: pattern
tech: supabase
source-project: "[[goodloop-pro]]"
tags: [pattern, supabase, rls, multi-tenant]
---

# RLS multi-tenant par organisation

## Le problème
Isoler les données par organisation dans une app multi-tenant Supabase.

## La solution
Policies RLS basées sur un champ `org_id` lié au JWT via
`auth.jwt() ->> 'org_id'`.

## Le code
[Exemple SQL des policies]

## Les pièges
- Ne pas baser l'isolation sur `auth.uid()` seul — un user peut appartenir
  à plusieurs orgs
- Tester avec plusieurs users de différentes orgs avant de passer en prod

La règle de classement

Ranger par usage futur, pas par origine. Un schéma RLS découvert sur le projet Goodloop va dans 20-Areas/Tech/supabase/, pas dans 10-Projects/goodloop/. La prochaine fois qu'on a besoin de RLS multi-tenant, on cherche dans Tech/supabase/, pas dans le dossier d'un ancien client.

7. Créer les MOCs (Maps of Content)

Les MOCs sont des index manuels dans _Meta/. Ils ont une double utilité que la plupart des guides Obsidian ne mentionnent pas :

Pour l'humain dans Obsidian : point d'entrée rapide sans fouiller dans les dossiers
Pour Claude Code : table des matières importable via @reference. Claude voit l'index des schémas techniques disponibles et va lire ceux pertinents au projet en cours.

Exemple : MOC-Clients.md

---
type: moc
tags: [moc, clients]
---

# MOC Clients

## Actifs
- [[goodloop-pro]] — Portail partenaires B2B, économie circulaire
- [[belza-ai]] — Agents IA secteur papier-carton

## Passés
- [[izuba-mobile]] — App terrain PWA, transition énergétique

## Prospects
(aucun en cours)

Les MOCs à créer

MOC	Contenu
`MOC-Clients.md`	Index des fiches clients par statut
`MOC-Patterns.md`	Index des schémas techniques par techno
`MOC-Content.md`	Index du contenu éditorial (posts, articles, stratégies)

D'autres viendront avec le temps. Ne pas en créer plus que nécessaire au démarrage — les MOCs vides, c'est du bruit.

Avec Claude Code

Claude peut générer les MOCs automatiquement en scannant le vault :

Scanne ~/vault/20-Areas/Clients/ — lis le frontmatter de chaque fichier .md,
et génère un MOC dans ~/vault/_Meta/MOC-Clients.md qui liste les clients
groupés par statut (active, past, prospect) avec des wikilinks.
Utilise le frontmatter type: moc, tags: [moc, clients].

Claude génère le fichier en quelques secondes. On ajuste l'ordre ou les descriptions si besoin.

8. Connecter Claude Code au vault

C'est le moment où le système prend vie. Jusqu'ici, le vault est un dossier de fichiers bien rangés. Maintenant, on câble Claude Code dessus.

Le CLAUDE.md global

Le fichier ~/.claude/CLAUDE.md est lu par toutes les sessions Claude Code, pas seulement les projets clients. C'est là qu'on met la carte du vault.

Ajouter une section Knowledge Hub :

## Knowledge Hub — Vault Obsidian

Le vault Obsidian à `~/vault/` est le cerveau central de l'activité freelance.

### Structure PARA
- `00-Inbox/` — capture rapide
- `10-Projects/{slug}/` — notes de suivi mission active
- `20-Areas/Business/` — positionnement, offre, stack, objectifs
- `20-Areas/Clients/` — une fiche par client (frontmatter `type: client`)
- `20-Areas/Content/` — stratégie de contenu
- `20-Areas/Tech/` — schémas techniques réutilisables
- `30-Resources/` — études de cas, frameworks, modèles
- `40-Archive/` — projets terminés
- `_Meta/` — MOCs (index), Schema.md (contrat frontmatter)

### Conventions
- Fichiers en kebab-case, dossiers en majuscule
- Frontmatter YAML strict par type (voir `~/vault/_Meta/Schema.md`)
- Wikilinks `[[]]` pour les relations entre notes

### Accès
- **Lire** : `Read` directement sur `~/vault/...`
- **Écrire** : `Write`/`Edit` directement — Obsidian voit les changements
  instantanément

Le CLAUDE.md par projet client

Chaque dossier projet client (~/Documents/Clients/{slug}/) a son propre CLAUDE.md avec des @references vers le vault :

# CLAUDE.md — Projet Goodloop Pro

## Contexte
@~/vault/20-Areas/Business/positionnement.md
@~/vault/20-Areas/Clients/goodloop-pro.md
@~/vault/10-Projects/goodloop-pro/index.md
@~/vault/_Meta/MOC-Patterns.md

Les @ imports chargent automatiquement le contenu dans le contexte de Claude Code. Quand on ouvre une session dans ce dossier, Claude sait déjà qui on est, qui est le client, où en est le projet, et quels schémas techniques existent. Pas de briefing à refaire.

Les couches de contexte

Couche	Source	Chargement
Identité business	`20-Areas/Business/`	Toujours (via @reference)
Fiche client	`20-Areas/Clients/{slug}.md`	Toujours (via @reference)
Fiche projet	`10-Projects/{slug}/index.md`	Toujours (via @reference)
Index schémas techniques	`_Meta/MOC-Patterns.md`	Toujours (via @reference)
Schémas détaillés	`20-Areas/Tech/`	À la demande (Claude lit ceux pertinents)
Études de cas	`30-Resources/Case-Studies/`	À la demande

L'essentiel est toujours là. Le détail, Claude va le chercher quand il en a besoin.

Le test

Ouvrir Claude Code dans un dossier projet client :

cd ~/Documents/Clients/goodloop-pro
claude

Puis tester :

Qui est mon client actuel et quel est mon positionnement ?

Claude devrait répondre avec les infos du vault sans qu'on ait rien à lui fournir. Si ça répond, c'est câblé.

Attention à la taille des @references. Chaque @reference charge l'intégralité du fichier dans le contexte. Un fichier de positionnement de 50 lignes, c'est parfait. Un fichier de 500 lignes, c'est du contexte brûlé pour rien. Les fichiers importés via @ doivent rester concis. Le détail vit dans des fichiers que Claude lira à la demande.

9. Automatiser avec les skills

L'architecture ne vaut rien si personne ne la maintient. J'ai essayé Notion, Coda, Airtable — à chaque fois, on crée les fiches avec enthousiasme, et on oublie de les alimenter trois semaines plus tard. Le problème n'est jamais l'outil, c'est la maintenance. Les skills Claude Code résolvent ça en automatisant les moments clés du cycle de vie.

Où vivent les skills

Les skills sont des fichiers markdown dans ~/.claude/skills/. Claude Code les détecte automatiquement et les exécute quand on tape /nom-du-skill dans le terminal.

/kickstart-client — Démarrer un projet en 30 secondes

Ce que le skill fait quand on tape /kickstart-client "Acme Corp" "PME logistique, portail partenaires" :

Crée la fiche client dans le vault (20-Areas/Clients/acme-corp.md)
Crée le dossier projet avec index.md (10-Projects/acme-corp/)
Crée le dossier de travail (~/Documents/Clients/acme-corp/)
Crée le CLAUDE.md du projet avec les @references pré-câblées
Met à jour le MOC Clients

Résultat :

~/vault/20-Areas/Clients/acme-corp.md          ← fiche client
~/vault/10-Projects/acme-corp/index.md         ← fiche projet
~/Documents/Clients/acme-corp/CLAUDE.md        ← dossier prêt
~/vault/_Meta/MOC-Clients.md                   ← mis à jour

Le projet est prêt. Sans le skill, ces 5 étapes prennent 15 minutes et on en oublie une sur deux.

/retex-client — Capitaliser en fin de mission

Le retex est ce qui rend le tout cumulatif. Quand on tape /retex-client en fin de projet, Claude pose quelques questions :

Satisfaction globale (1-5)
Ce qui s'est bien passé
Ce qui a posé problème
Résultat mesurable
Publiable en case study ?

Puis il automatise :

Met à jour la fiche client (statut → past, ajout des apprentissages)
Extrait les schémas techniques réutilisables → 20-Areas/Tech/
Crée la case study si publiable → 30-Resources/Case-Studies/
Archive le projet (10-Projects/ → 40-Archive/)
Met à jour les MOCs

Pourquoi les skills comptent : Sans eux, la capitalisation dépend de la bonne volonté. On se dit "je ferai le retex ce weekend" et on ne le fait jamais. Avec un skill, c'est 2 minutes en fin de projet. La différence entre un système qui s'enrichit et un système qui stagne, c'est l'effort requis pour l'alimenter. Si l'effort tend vers zéro, le système vit.

Co-écrire un skill avec Claude

Pour créer un nouveau skill, on peut demander à Claude de le co-écrire :

Je veux créer un skill /kickstart-client qui :
1. Prend un nom de client et un brief en paramètres
2. Crée la fiche client dans ~/vault/20-Areas/Clients/{slug}.md
   avec le frontmatter conforme à ~/vault/_Meta/Schema.md
3. Crée le dossier projet ~/vault/10-Projects/{slug}/index.md
4. Crée le dossier ~/Documents/Clients/{slug}/ avec un CLAUDE.md
   qui @reference le positionnement, la fiche client, le projet,
   et le MOC patterns
5. Met à jour ~/vault/_Meta/MOC-Clients.md

Écris le skill dans ~/.claude/skills/kickstart-client.md

Claude produit le fichier. On teste, on ajuste, on itère. Le skill est un document vivant — il s'améliore à chaque utilisation.

10. Faire vivre le vault sur la durée

Le gros du travail est fait. À partir de là, le vault grandit tout seul à chaque projet — si les skills sont en place.

Le cycle vertueux

Nouveau client
    → /kickstart-client
    → Projet avec contexte complet dès J1
    → Travail normal (le vault est consulté, pas alimenté manuellement)
    → Fin de mission
    → /retex-client
    → Schémas extraits, étude de cas créée, fiche archivée
    → Le vault est plus riche qu'avant
    → Prochain client démarre avec plus de contexte

Avant / Après (6 mois, 5 clients)

Jour 1 :

~/vault/
├── 00-Inbox/
├── 10-Projects/
├── 20-Areas/
│   ├── Business/          (3 fichiers)
│   ├── Clients/           (vide)
│   ├── Content/           (vide)
│   └── Tech/              (vide)
├── 30-Resources/          (vide)
├── 40-Archive/            (vide)
└── _Meta/
    └── Schema.md

6 mois plus tard :

~/vault/
├── 00-Inbox/
├── 10-Projects/
│   └── client-actif/
│       └── index.md
├── 20-Areas/
│   ├── Business/          (4 fichiers)
│   ├── Clients/           (6 fiches)
│   ├── Content/
│   │   ├── Posts/         (15 posts LinkedIn importés)
│   │   └── Blog/          (3 articles)
│   └── Tech/
│       ├── weweb/         (2 schémas)
│       ├── supabase/      (3 schémas)
│       └── n8n/           (2 schémas + apprentissages)
├── 30-Resources/
│   ├── Case-Studies/      (3 études de cas)
│   ├── Frameworks/        (2 frameworks)
│   └── Templates/         (4 modèles)
├── 40-Archive/
│   ├── goodloop-pro/
│   ├── izuba-mobile/
│   ├── belza-ai/
│   └── bulq/
└── _Meta/
    ├── Schema.md
    ├── MOC-Clients.md
    ├── MOC-Patterns.md
    └── MOC-Content.md

Le vault s'est rempli sans effort dédié. Chaque /retex-client a poussé des schémas techniques dans Tech/, des études de cas dans Resources/, des fiches dans Archive/. Le tout sans ouvrir Obsidian manuellement.

Ce qui ne migre PAS (et c'est volontaire)

Ce qui reste hors du vault	Pourquoi
Facturation et contrats	Pas de la connaissance — de l'admin
Repos de code	Restent en place, leurs `CLAUDE.md` pointent vers le vault
Fichiers binaires (vidéos, PDFs, images)	Pas de place dans un vault markdown
Anciens dossiers clients (en vrac)	Conservés en lecture seule pour tri manuel, les fiches sont dans le vault

Le vault stocke la connaissance. Le reste vit ailleurs. Le lien se fait par les @references et les wikilinks, pas par la colocation.

Le ratio 80/20

Claude capitalise automatiquement (extraction de schémas, création de fiches, mise à jour des MOCs). L'humain affine les nuances métier et la pertinence des schémas extraits. Le système ne demande pas de perfection. Un retex fait en 2 minutes vaut mieux qu'un retex parfait jamais fait.

Le vault comme livrable implicite

À chaque fin de mission, le vault contient un peu plus de matériel réutilisable. Le prochain prospect qui pose une question similaire à un projet passé trouvera la réponse dans le vault, via Claude Code qui l'aura déjà dans son contexte.

Le vault n'est pas un projet séparé. C'est un effet de bord du travail quotidien.

Ressources

Obsidian et Claude Code : structurer un knowledge hub freelance — le document méthodologique complet (pourquoi ces choix)
Obsidian — l'éditeur markdown local
Claude Code — le CLI d'Anthropic
PARA method — Tiago Forte (le cadre d'organisation derrière la structure)

Cet article fait partie de la série "Stack moderne pour builder indépendant". Voir aussi : Obsidian et Claude Code : structurer un knowledge hub freelance.

Un projet digital à lancer ? Discutons de votre projet.

1. Ce qu'il faut avant de commencer

2. Créer le vault et poser les fondations

Créer le dossier

La structure PARA numérotée

Le lien symbolique ~/vault

Initialiser git

Premier commit

Vérification

3. Définir le schéma de frontmatter

Créer le fichier Schema.md

Pourquoi un schéma

Exemple de fiche client complète

Conventions de nommage

4. Remplir le socle Business

Les fichiers à créer

Exemple : positionnement.md

Avec Claude Code

Pourquoi en premier

5. Migrer les fiches clients

Le modèle

Avec Claude Code

Vérification

6. Études de cas et schémas techniques réutilisables

Les études de cas

Les schémas techniques réutilisables

La règle de classement

7. Créer les MOCs (Maps of Content)

Exemple : MOC-Clients.md

Les MOCs à créer

Avec Claude Code

8. Connecter Claude Code au vault

Le CLAUDE.md global

Le CLAUDE.md par projet client

Les couches de contexte

Le test

9. Automatiser avec les skills

Où vivent les skills

/kickstart-client — Démarrer un projet en 30 secondes

/retex-client — Capitaliser en fin de mission

Co-écrire un skill avec Claude

10. Faire vivre le vault sur la durée

Le cycle vertueux

Avant / Après (6 mois, 5 clients)

Ce qui ne migre PAS (et c'est volontaire)

Le ratio 80/20

Le vault comme livrable implicite

Ressources

Un projet en tête ?