Techniques de construction Obsidian utilisées uniquement par les génies et les hauts revenus

Gagner de l'argent avec l'IA ne concerne pas le « nombre de notes »

Commençons par une discussion calme.

Aucune étude ne suggère un lien de cause à effet entre un revenu annuel de 100 millions de yens et une configuration Obsidian. Il n'y a pas de « plugins secrets que seuls les riches connaissent ».

Ce que j'entends par « joueur à 100 millions de yens », ce n'est pas quelqu'un qui emmagasine une quantité massive de connaissances.

Cela désigne les personnes capables de convertir les informations qu'elles obtiennent en :

• Prise de décision
• Négociation
• Recrutement
• Jugement d'investissement
• Conception de produits
• Contenu
• Supports de vente
• Systèmes organisationnels
• Actifs intellectuels réutilisables

...à une vitesse extrêmement élevée.

Les utilisateurs ordinaires d'Obsidian pensent à « quoi sauvegarder ».

Les utilisateurs forts réfléchissent d'abord à « dans quelle situation, en utilisant quelle question, vais-je récupérer cette information à l'avenir ? »

Les utilisateurs encore plus forts suivent la trace de la décision ou du résultat dans lequel ces connaissances récupérées se sont finalement converties.

En d'autres termes, ce que vous devriez vraiment concevoir n'est pas un « Second Cerveau ».

C'est un système d'exploitation intellectuel personnel qui compose la prise de décision et la production intellectuelle.

Obsidian enregistre les notes sous forme de fichiers Markdown locaux. Un Vault est juste un dossier, et les modifications apportées depuis des éditeurs externes ou des scripts sont reflétées dans Obsidian. Les paramètres et les informations sur les plugins sont séparés dans le dossier .obsidian. Cela signifie qu'Obsidian n'est pas seulement une application, mais un « référentiel de connaissances » qui peut être manipulé par Git, CLI, Claude et Codex.

Dans cet article, nous traitons les éléments d'Obsidian comme suit :

Une fois que vous avez adopté cette perspective, votre façon d'utiliser Obsidian change complètement.

Chapitre 1 : Étude de cas à l'étranger – La stratégie gagnante était la « recherche », pas l'« organisation »

1. Ce qui a été appris des Vaults de 7 chercheurs

Une étude de cas publiée en 2025 a examiné l'utilisation d'Obsidian par sept chercheurs en informatique d'un institut de recherche brésilien.

L'enseignement le plus important de cette étude n'était pas la manière dont les participants créaient des notes.

C'était la découverte que la manière dont ils prévoyaient de les récupérer à l'avenir influençait fortement la façon dont ils créaient et organisaient les notes. Les participants utilisaient les barres de recherche, les listes d'étiquettes, les étiquettes dans le texte et les liens internes à des fins différentes. Certains utilisateurs plaçaient également les notes créées dans une boîte de réception et les traitaient une fois par semaine.

Les propositions de conception formulées par les chercheurs peuvent être résumées en trois points :

1. N'exigez pas une classification parfaite dès le départ ; préparez une structure initiale minimale.
2. Permettez à la structure d'être modifiée en cours d'utilisation.
3. Connectez la méthode de création/organisation avec la méthode de recherche future dès le début.

En d'autres termes, il ne s'agit pas de « créer les bons dossiers ».

Il s'agit de décider comment votre futur vous-même cherchera et d'enregistrer en fonction de ce chemin de recherche.

Ce seul point montre que la plupart des cours Obsidian courants sont à l'envers.

De nombreux cours vous font d'abord décider des dossiers, des étiquettes, des plugins et de l'apparence.

Cependant, en réalité, la question que vous devriez décider en premier est celle-ci :

Dans trois mois, de quoi vais-je me soucier quand j'aurai besoin de cette information ?

2. Nicole van der Hoeven – Faire des notes un outil d'apprentissage professionnel

Nicole van der Hoeven, qui travaille comme Developer Advocate et Performance Engineer, déclare que prendre des notes continues sur le travail a eu un impact positif non seulement sur la vitesse d'apprentissage, mais aussi sur sa carrière dans l'industrie technologique.

La clé n'est pas qu'elle « a créé une belle base de données de connaissances ».

C'est qu'elle enregistre l'apprentissage pendant le travail et le réutilise pour le partage public, les explications et les présentations.

Elle fait circuler les notes d'apprentissage au-delà des simples enregistrements personnels vers :

• Présentations
• Articles
• Vidéos
• Documents
• Supports pédagogiques
• Le prochain emploi

Cette « conversion de l'entrée vers la sortie » crée la valeur économique de la connaissance.

3. Bruno Paz – Local, Markdown, plugins minimaux

L'ingénieur logiciel Bruno Paz regroupe tout, des extraits de code, réunions et spécifications de projet à la recherche et aux connaissances de la vie, dans Obsidian.

Cependant, plus important que de tout mettre dans Obsidian est sa philosophie de conception.

Il met l'accent sur la portabilité du Markdown et la gestion de l'historique via Git, en adoptant une politique de maintien du nombre de plugins au minimum. Les plugins rendent Obsidian pratique, mais le contenu lui-même ne doit pas trop dépendre de plugins spécifiques.

Il standardise également les Frontmatter comme type avec des modèles, place les Wikilinks vers les notes connexes dans topics, et les liste avec Bases ou Dataview.

La conclusion ici est claire :

Pouvoir récupérer avec juste du Markdown quand les choses cassent est plus important que d'être très fonctionnel.

4. Ian O'Byrne – Faire circuler l'information de « Consommer → Curation → Créer »

Ian O'Byrne, qui utilise Obsidian dans l'éducation et la recherche, structure son Vault à peu près selon ce flux :

• Consommer : Entrées comme articles, livres, articles scientifiques, podcasts
• Curation : Distillation des points clés, mise en relation, création de MOC
• Créer : Sorties comme blogs, newsletters, supports pédagogiques
• Méta : Informations opérationnelles pour le Vault lui-même

Ce qui compte, ce ne sont pas les noms de dossiers.

C'est la structure où l'information passe de l'entrée, par la création de sens, à la sortie. Il explique que le processus est plus important que la plateforme et que le Vault évolue selon les besoins.

En résumant ces cas à l'étranger, les excellents Vaults ont cinq points communs :

1. Priorité à la récupération – Travaillez à rebours à partir des futures recherches
2. Centré sur la sortie – Circulez vers les livrables, pas seulement le stockage
3. Priorité au local – Utilisez Markdown comme source de vérité
4. Schéma minimal – Ne compliquez pas trop les champs d'entrée
5. Évolutif – Changez la structure tout en l'utilisant

Chapitre 2 : Six indicateurs définissant un « Vault à 100 millions de yens »

Le nombre de notes, le nombre de liens et la beauté du Graph ne sont pas des indicateurs de performance essentiels.

Je mesurerais la performance du Vault avec ces six indicateurs :

1. Latence de capture

Le temps entre avoir une idée et la sauvegarder.

L'objectif est de 30 secondes maximum. Une structure qui vous oblige à penser aux étiquettes, aux notes connexes et aux emplacements de sauvegarde au moment de la saisie est faible.

2. Temps de récupération

Le temps nécessaire pour atteindre l'information nécessaire.

Visez 30 secondes maximum pour les informations générales et 60 secondes maximum pour les décisions importantes.

3. Coût de reconstruction du contexte

Le temps nécessaire pour restaurer ce dont parlait une histoire en regardant de vieilles notes.

Une note avec seulement un titre de réunion est faible. Une note qui préserve « Contexte », « Décision », « Raison », « Prémisse » et « Action suivante » est forte.

4. Traçabilité des décisions

Le pourcentage de jugements importants où vous pouvez ultérieurement suivre :

• Pourquoi cela a été décidé
• Qu'est-ce qui a été rejeté
• Quelles prémisses existaient
• Quelles conditions déclencheraient un renversement

5. Taux de conversion en sortie

Le pourcentage de notes sources ou de notes persistantes stockées qui ont été réutilisées pour des articles, propositions, produits, décisions, réunions ou activités de vente.

6. Exécutabilité par agent

Le pourcentage de temps où Claude ou Codex peuvent rechercher, proposer et vérifier sans mal comprendre les règles du Vault.

En résumé, le ROI d'un système de connaissances peut être pensé comme suit :

ROI de la connaissance = (Connaissances réutilisées + Décisions améliorées + Échecs évités) / Temps passé à enregistrer, organiser et maintenir

Même si le nombre de notes augmente, si elles ne sont pas réutilisées, seul le dénominateur croît.

Chapitre 3 : Une structure de Vault adaptée aux utilisateurs japonais

Si je construisais à partir de zéro, j'utiliserais cette structure de premier niveau :

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

Entrées non classifiées. N'organisez pas ici. Les étiquettes sont généralement inutiles. C'est un endroit « juste pour sauvegarder ».

10_Daily

Journaux de travail chronologiques. Laissez les mémos, conversations, découvertes et progrès qui ne valent pas la peine de créer des notes indépendantes.

20_Projects

Activités avec une condition d'achèvement. « Augmenter les ventes » est un Domaine ou un Objectif, mais « Réviser la tarification du plan d'entreprise d'ici septembre 2026 » est un Projet. Les projets doivent toujours avoir une next_action.

30_Areas

Domaines de responsabilité continus. Gestion, ventes, recrutement, finances, santé, famille, apprentissage, etc. Les Domaines restent même après la fin d'un Projet.

40_Notes

Connaissances pour une réutilisation à long terme. Placez ici du contenu que vous pouvez expliquer avec vos propres mots, pas seulement des extraits. Pas besoin de suivre strictement « une note, un concept ». En japonais, les sujets et les prémisses sont facilement omis, donc une fragmentation excessive brise le contexte. La norme est :

1 Note = Contenu que vous souhaitez réutiliser comme une unité unique à l'avenir

50_Sources

Enregistrements d'informations externes. Livres, articles scientifiques, articles, vidéos, documents de réunion, données de recherche, etc. Séparez « ce que l'autre partie a dit » de « comment je l'ai interprété ».

60_Entities

Entités comme les personnes, entreprises, produits, clients, concurrents et technologies. Même si la même personne ou entreprise apparaît dans plusieurs projets, ne conservez qu'une seule Note d'Entité.

70_Outputs

Articles, documents de planification, propositions, scripts vidéo, présentations, supports de vente, spécifications produits, etc. Il est crucial de placer les Sorties dans un dossier de premier niveau indépendant. Un Vault axé uniquement sur le stockage devient un cimetière de connaissances.

90_System

Mécanismes qui font fonctionner le Vault lui-même, tels que les modèles, les schémas, les bases, les règles IA et les compétences. En construisant cela, vous devenez capable d'expliquer vos propres opérations.

Faut-il un seul Vault ?

En principe, oui. Les liens internes dans Obsidian sont résolus au sein d'un Vault ; diviser les Vaults déconnecte les relations entre les connaissances. Dans l'étude mentionnée, les participants qui ont divisé leur Vault en trois ont signalé une confusion dans la recherche.

Cependant, séparez physiquement ce qui suit :

• Informations pour lesquelles l'entrée d'IA externe est interdite par contrat.
• Données médicales, numéros d'identification personnelle, identifiants.
• Informations RH très sensibles.
• Données réglementées.
• Informations qui ne peuvent pas être transmises à des modèles externes conformément à la politique de l'organisation.

Pensez à séparer un « Vault personnel » et un « Vault réglementé ».

Chapitre 4 : Ne mélangez pas les rôles des dossiers, propriétés, liens et étiquettes

La principale raison pour laquelle les systèmes Obsidian s'effondrent est d'exprimer la même classification en utilisant à la fois dossiers, étiquettes, propriétés et liens. Fixez leurs rôles comme suit :

Les dossiers sont pour le « cycle de vie »

Inbox, Project, Source, Output, Archive, etc. Ils représentent à quelle étape du processus se trouve actuellement une note.

Les propriétés sont pour les « types et états gérés par machine »

type, status, created, project, revisit, etc. Les propriétés Obsidian sont enregistrées en YAML et peuvent avoir des types comme text, list, number, checkbox, date, datetime et tags.

Les liens sont pour les « relations sémantiques »

[[Stratégie de tarification]], [[ABC Corp]], [[Réversibilité des décisions]], etc. Faire d'un sujet une note plutôt qu'une étiquette permet à ce sujet lui-même de contenir des explications, des contre-preuves, des documents de référence et des MOC.

Les étiquettes sont pour les « états transversaux temporaires »

Limitez les étiquettes à des choses comme #review, #waiting, #question, #contradiction, #publish.

Les concepts comme « Marketing » ou « IA » devraient être des liens autant que possible. Utiliser les étiquettes comme dictionnaire conceptuel conduit à une prolifération d'étiquettes (par exemple, #IA, #IntelligenceArtificielle, #IA_générative). Utilisez plutôt les alias dans les notes conceptuelles.

Chapitre 5 : Schéma de propriétés minimal

N'essayez pas de remplir 20 éléments dès le départ. Divisez le schéma en trois étapes :

Étape de capture

Seulement l'essentiel :
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Étape de promotion

Ajoutez quand cela gagne en valeur pour le stockage à long terme :
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Stratégie de tarification]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Recherche tarification concurrents 2026-07]]"
confidence: medium
sensitivity: internal
``

Étape opérationnelle

Ajoutez les éléments nécessaires pour les projets ou les décisions :
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Gestion]]"
due: 2026-09-30
next_action: Comparer les plans annuels de 5 concurrents
``

Chapitre 6 : Règles pour les noms de fichiers en japonais

Il n'est pas nécessaire de forcer le texte du corps ou les titres en japonais vers l'anglais. Cependant, conservez les noms de propriétés et les noms de dossiers utilisés pour le traitement machine en ASCII. J'utilise ces conventions de nommage :

• Projet : PJT Refonte de la tarification d'entreprise
• Décision : DEC 2026-07-24 Faire du plan annuel la proposition standard
• Note persistante : Le prix est déterminé par le risque d'échec de mise en œuvre plutôt que par le nombre de fonctionnalités

Faites des titres de notes persistantes des « affirmations » plutôt que des « noms de catégories ». Les titres affirmatifs vous aident à vous souvenir du contenu rien qu'à partir des résultats de recherche.

Chapitre 7 : Modèles à inclure réellement

Note quotidienne

Incluez un « journal des frictions ». Enregistrer « ce que j'ai cherché mais n'ai pas trouvé » vous permet d'améliorer le Vault en fonction des échecs de recherche réels. Faites évoluer la structure à partir des recherches infructueuses, pas des préférences esthétiques.

Note de projet

Une note de projet n'est pas un entrepôt de tâches. C'est le centre de commandement du projet où n'importe qui peut comprendre l'état actuel en 30 secondes.

Note de décision

Dans un travail à forte marge, la qualité des décisions est plus importante que l'information. Ainsi, les notes de décision sont le type de note le plus précieux. Le champ le plus important est le déclencheur de renversement. Un excellent décideur est quelqu'un qui peut écrire au moment de la décision dans quelles conditions il changerait d'avis.

Chapitre 8 : Les MOC sont des « modèles de pensée édités », pas des listes de liens

Un bon MOC (Map of Content) contient le jugement de l'éditeur. C'est un modèle cognitif édité qui comprime votre compréhension actuelle de tout un domaine, plutôt qu'une simple liste de notes connexes.

Chapitre 9 : Créer un « tableau de bord de gestion » avec les Bases

Obsidian Bases est une fonctionnalité centrale qui permet d'afficher, filtrer et trier les propriétés des notes comme une base de données. Utilisez-la pour créer une « Base des projets actifs » ou une « Base de révision des décisions » afin de récupérer les jugements qui ont été laissés en suspens.

Chapitre 10 : Plugins hiérarchisés

• Niveau 0 (Core uniquement) : Properties, Templates, Daily Notes, Bases, Search, Canvas, etc.
• Niveau 1 (Quand une friction apparaît) : QuickAdd, Templater, Tasks.
• Niveau 2 (Seulement si Bases ne suffit pas) : Dataview.

Gardez les plugins communautaires actifs à 12 ou moins. Enregistrez le but, l'alternative et les conditions de suppression pour chacun.

Chapitre 11 : Le changement décisif en 2026 – CLI officielle d'Obsidian

Depuis juillet 2026, Obsidian dispose d'une CLI officielle. Elle permet d'utiliser la version desktop depuis le terminal : rechercher, lire, créer, mettre à jour les propriétés et vérifier les tâches. Cela permet à Claude et Codex d'utiliser la logique de résolution propre à Obsidian plutôt que de simplement éditer du Markdown directement.

Chapitre 12 : La structure correcte pour un Vault natif IA

Laisser l'IA éditer librement toutes les notes n'est pas « utiliser l'IA ». C'est comme remettre tous les documents de l'entreprise à un stagiaire non vérifié. La bonne répartition des tâches est :

• Humain : Objectifs, jugements de valeur, approbation finale, édition des MOC.
• Obsidian : Source de vérité, relations, historique, vues.
• Claude : Distillation du sens, comparaison, contre-arguments, rédaction de brouillons.
• Codex : Changements structurels, scripts, validation, révisions de diffs.
• Git : Récupération, audit, isolation des expériences.
• Validateur : Détection des violations de schéma et des anomalies de lien.

Chapitre 13 : Placer CLAUDE.md et AGENTS.md

Claude Code lit CLAUDE.md comme des instructions continues. Codex cherche AGENTS.md. Placez un « contrat d'exploitation du Vault » dans ces fichiers pour définir la langue (texte en japonais, propriétés en ASCII), les règles de sécurité (dry-run par défaut) et les règles de schéma.

Chapitre 14 : Transformer les tâches Obsidian en compétences via Claude

Définissez des « compétences d'agent » pour les tâches que vous effectuez plus de trois fois ou pour une qualité standardisée. Par exemple, une compétence obsidian-distill peut convertir des notes de réunion brutes en décisions, tâches et notes persistantes. Une bonne compétence est une norme de travail réexécutable avec des entrées, procédures, interdictions et conditions d'achèvement explicites.

Chapitre 17 : Modèles de collaboration pour Claude, Codex et la CLI Obsidian

• Modèle 1 : Distillation des notes de réunion (Claude extrait les décisions/tâches).
• Modèle 2 : Revue de gestion hebdomadaire (Claude résume les progrès de la semaine et les projets bloqués).
• Modèle 3 : Audit de dérive du schéma (Codex détecte les incohérences de propriétés).
• Modèle 4 : Audit des prémisses de décision (Claude vérifie si les hypothèses derrière les décisions passées sont toujours valables).

C'est une utilisation qui va au-delà de « résumer des notes avec l'IA ». Vous utilisez l'IA comme un contrôleur intellectuel qui audite vos jugements passés.

Chapitre 18 : Inclure un validateur de Vault

Si l'IA édite votre Vault, ne vous contentez pas de « ça a l'air correct ». Implémentez des tests statiques minimum via des scripts (par exemple, vault_check.py) pour vérifier les types autorisés, les statuts et les propriétés obligatoires.