---
title: "Mon second cerveau, pour moi et pour mes agents : Obsidian alimenté par Claude Code"
excerpt: "Je n'écris plus mes notes, je les dicte. Claude les range dans Obsidian, les retrouve dans n'importe quelle session, depuis mon téléphone comme depuis mon ordinateur. Retour sur un second cerveau alimenté par l'IA, sans usine à gaz."
publishDate: 2026-09-29T00:00:00.000Z
tags: ["ia", "claude-code", "obsidian", "second-cerveau", "productivite", "agents", "vps"]
canonical: "https://yoandev.co/second-cerveau-ia-obsidian-claude"
---

Vous êtes sur le canapé. Une idée vous traverse l'esprit : un outil à tester, une piste pour un projet, un truc à ne surtout pas oublier pour la maison. Vous savez très bien ce qui va se passer. Vous vous direz « je le noterai plus tard », et plus tard n'arrivera jamais.

Moi, désormais, je prends mon téléphone, j'ouvre une conversation avec Claude, et je lui raconte. Deux phrases, en vrac, sans me soucier de la forme. Quelques secondes plus tard, la note existe dans mon Obsidian : au bon endroit, avec un titre clair, les bons tags, reliée au projet qu'elle concerne.

Le lendemain, devant mon ordinateur, en pleine session de travail avec Claude Code, je n'ai pas besoin d'aller la chercher. Je demande, et elle revient.

C'est ça, mon second cerveau aujourd'hui : **une base de connaissances que je n'alimente plus à la main, et que je partage avec mes agents.**

Cet article se lit en trois temps : d'abord ce qu'est un second cerveau et pourquoi il est si précieux quand on travaille dans la tech, ensuite comment l'IA règle le problème qui les fait presque tous mourir, et enfin, pour celles et ceux qui voudraient reproduire le montage, les détails techniques.

## Un second cerveau, c'est quoi ?

L'idée est bien plus ancienne que nos applications de notes. En 1945, dans son essai *As We May Think*, l'ingénieur Vannevar Bush imaginait déjà le *Memex* : un bureau capable de stocker tous les livres, notes et échanges d'une personne, et de les relier entre eux par des « pistes ». À partir des années 1950, le sociologue allemand Niklas Luhmann bâtissait son *Zettelkasten* : des dizaines de milliers de fiches cartonnées, numérotées et reliées les unes aux autres, qu'il décrivait comme un véritable partenaire de réflexion. C'est avec elles qu'il a écrit l'essentiel de son œuvre, des dizaines de livres et des centaines d'articles.

L'expression « second cerveau » (*second brain*) a été popularisée plus récemment par Tiago Forte : d'abord avec une formation en ligne lancée en 2017, puis avec son livre *Building a Second Brain* (2022). L'idée tient en une phrase, que l'on doit à David Allen, l'auteur de la méthode GTD : **« Votre esprit est fait pour avoir des idées, pas pour les stocker. »**

Un second cerveau, c'est donc un système extérieur à votre tête, dans lequel vous déposez ce que vous apprenez, décidez et imaginez, pour pouvoir le retrouver au bon moment. Ce n'est pas une archive : c'est un ensemble de notes **reliées**, qui s'enrichit avec le temps et vous ressert quand vous en avez besoin.

Tiago Forte le résume en quatre étapes, la méthode CODE :

1. **Capturer** : garder ce qui résonne, au moment où ça passe.
2. **Organiser** : ranger selon ce à quoi ça va servir (un projet en cours, un domaine de responsabilité…), plutôt que par sujet.
3. **Distiller** : extraire l'essentiel, pour que la note se relise en quelques secondes.
4. **Exprimer** : réutiliser ce savoir pour produire quelque chose.

Gardez ces quatre étapes en tête : on va y revenir.

## Pourquoi c'est vital quand on travaille dans la tech

Notre métier est une machine à produire de la connaissance jetable.

On jongle avec plusieurs projets, parfois plusieurs clients, chacun avec sa stack, ses conventions, ses décisions passées et ses pièges. On apprend en permanence : un nouveau framework, un nouvel outil, une nouvelle façon de déployer. Et on oublie presque tout aussi vite.

Vous connaissez sans doute ces moments :

- la commande trouvée après une heure de recherche, qu'il faudra rechercher à nouveau dans six mois ;
- le bug étrange que vous avez **déjà** résolu, sur un autre projet, sans vous souvenir comment ;
- la question « mais pourquoi on a choisi cette solution, déjà ? », à laquelle plus personne ne sait répondre ;
- ce qu'un client a dit en réunion il y a trois semaines, et qui change tout aujourd'hui ;
- l'article ou l'outil repéré en veille, « à tester un jour », perdu dans un onglet fermé.

À chaque fois, c'est du temps perdu à reconstruire un contexte qui existait déjà. Et à chaque changement de projet, il faut recharger en mémoire tout ce qui le concerne. Un second cerveau, c'est l'endroit où ce contexte survit.

Il y a un bénéfice plus récent, et c'est tout le sujet de cet article : **ce contexte ne sert plus seulement à nous.** Ce qu'un fichier `CLAUDE.md` est pour un dépôt de code, un second cerveau peut l'être pour toute votre vie professionnelle. Vos décisions, vos conventions, votre historique avec un client deviennent un contexte que vos agents peuvent lire.

Enfin, un second cerveau n'est pas un outil pour produire davantage. J'ai écrit il y a quelques mois sur [le mirage de la productivité IA](/mirage-productivite-ia) : le temps gagné par l'IA est rarement rendu. Ici, l'objectif est inverse : **vider sa tête**, arrêter de tout porter en permanence, et retrouver de la place pour penser.

## Pourquoi la plupart des seconds cerveaux meurent

J'utilise Obsidian depuis longtemps. Et pendant longtemps, je l'ai alimenté à la main, ou de manière épisodique avec l'aide de Claude.

Le problème n'a jamais été l'outil. C'était la friction. Pour noter quelque chose proprement, il faut se poser des questions : dans quel dossier ? Quel titre ? Quels tags ? Est-ce qu'une note existe déjà sur le sujet ? Quand on a une idée sur le canapé, on n'a aucune envie de se poser ces questions. Alors on ne note pas. Ou on note n'importe comment, dans une « Inbox » qui devient un cimetière.

Reprenez la méthode CODE : capturer est facile. Ce qui coûte, c'est organiser et distiller. C'est un travail de bibliothécaire, répétitif et sans gratification immédiate. On le repousse, puis on l'abandonne. Et un second cerveau mal rangé est un second cerveau dans lequel on ne retrouve rien, donc qu'on n'utilise plus. C'est comme ça que la plupart meurent : pas faute de bonnes idées, mais faute d'entretien.

J'avais en réalité trois besoins :

1. **Noter sans friction** : une simple conversation, depuis mon téléphone, sans penser à la forme.
2. **Structurer** ma connaissance : que chaque note soit rangée, nommée, reliée aux autres, sans effort de ma part.
3. **La rappeler n'importe où** : que cette connaissance soit disponible dans toutes mes sessions Claude, pas seulement quand j'ouvre Obsidian.

## Le principe : je dicte, l'IA range

Le renversement est simple : **je n'ouvre (presque) plus Obsidian.** C'est Claude qui crée les notes, les met à jour, les déplace, rédige les comptes rendus de réunion, tient les fiches clients et retrouve les informations.

Si on reprend les quatre étapes de CODE, le partage des rôles devient limpide :

- **Capturer**, c'est moi : deux phrases dictées, sans me soucier de la forme.
- **Organiser** et **distiller**, c'est Claude : le dossier, le titre, les tags, les liens, la reformulation.
- **Exprimer**, c'est nous deux : Claude retrouve la note au moment où j'en ai besoin, dans la session où je travaille.

**L'IA prend exactement la part du travail qui faisait abandonner.**

Obsidian est l'outil idéal pour ça, pour une raison toute bête : un *vault* Obsidian (le dossier qui contient toutes les notes) **n'est qu'un ensemble de fichiers Markdown.** Pas de base de données propriétaire, pas d'API à apprivoiser. Un agent comme Claude Code sait lire et écrire des fichiers texte mieux que personne. Et moi, je garde la possibilité de tout lire, tout modifier, tout emporter.

Concrètement, voici ce que je dis à Claude depuis mon téléphone :

> « Note que je dois tester Bruno pour remplacer Postman sur le projet Atlas, un collègue m'en a dit du bien. »

Et voici la note qu'il crée, dans le dossier du projet :

```markdown
---
liens:
  - "[[Atlas]]"
tags:
  - tech/api
  - tech/outils
  - projet/atlas
---
# Atlas - Tester Bruno à la place de Postman

- Piste : remplacer Postman par Bruno (client d'API open source,
  collections versionnables dans Git).
- Recommandé par un collègue.
- À tester sur [[Atlas]].
```

Je n'ai choisi ni le dossier, ni le titre, ni les tags. Et la note apparaît automatiquement dans la fiche du projet Atlas, grâce au lien.

Mais confier son second cerveau à une IA pose une question évidente : **comment éviter que ça devienne le chaos ?** Une IA qui range « à sa façon » à chaque fois, c'est un vault qui se dégrade note après note : des tags qui se multiplient, des doublons, des titres incohérents.

## Ce qui fait tenir le vault : des règles écrites pour l'IA

La réponse tient en une idée : **le vault contient ses propres règles.**

À la racine, un fichier `CLAUDE.md` sert de point d'entrée. Il renvoie vers quelques éléments qui constituent le vrai « cerveau » du système :

- **Des conventions** : la structure des dossiers, la façon de nommer une note, les propriétés à mettre en tête de note, les règles de liens. Tout ce qu'un humain rigoureux appliquerait, écrit noir sur blanc pour l'IA.
- **Un vocabulaire contrôlé** : la liste des tags autorisés et des « entités » (organisations, projets, clients). Claude n'invente pas de tags : il pioche dans ce vocabulaire. Et quand un concept durable apparaît (un nouveau client, un nouveau projet), il fait évoluer le vocabulaire lui-même, en respectant des règles précises. Le vocabulaire suit ma réalité sans dériver.
- **Un petit outil de vérification** : après chaque écriture, Claude lance une vérification qui contrôle la note (tags connus, liens valides, propriétés présentes). Tant qu'il reste un problème bloquant, il corrige. C'est le garde-fou qui fait la différence entre « l'IA fait de son mieux » et « l'IA respecte les règles ».
- **Quelques règles de sécurité** : aucun secret dans le vault (mot de passe, clé d'API…), un renommage qui met à jour tous les liens, et jamais de suppression sans mon accord.

Le point important : **tout ça est versionné avec les notes.** Quand j'affine une règle, elle s'applique partout, immédiatement, sur toutes les machines.

## Les skills : un savoir-faire par intention

Les conventions disent *à quoi* doit ressembler le vault. Les **skills** disent à Claude *comment faire* selon ce que je lui demande.

### Les skills du vault

Ils vivent dans le vault, et se déclenchent quand Claude est lancé depuis celui-ci :

- **Créer une note** : « note ça », « garde ça quelque part », une idée, une astuce, un lien.
- **Compte rendu de réunion** : date, participants, projet concerné, décisions.
- **Mettre à jour** une note existante : compléter, renommer, déplacer, archiver.
- **Gérer une entité** : un nouveau client, un partenaire, un projet, avec sa fiche.
- **Idée de vidéo** : pour ma chaîne YouTube, avec son statut (idée, script, tournée, publiée).
- **Rechercher** : retrouver et résumer ce que j'ai noté sur un sujet.
- **Revue du vault** : un peu de ménage régulier.

Je n'ai pas à les appeler par leur nom. Je dis « fais le CR de la réunion de ce matin » ou « tu te souviens de ce que j'avais noté sur ce client ? », et le bon skill s'active.

### Le skill « général » : le vault depuis n'importe où

C'est la pièce qui a tout changé. Les skills du vault ne sont actifs que quand Claude travaille *dans* le vault. Or la plupart du temps, je travaille ailleurs : sur un projet pro, sur un article, sur une vidéo.

J'ai donc ajouté un skill global, installé au niveau de Claude Code et disponible dans **toutes** mes sessions. Il ne contient aucune règle : il sait simplement où se trouve le vault, et vers quel skill du vault aiguiller la demande.

En plein développement, je peux dire « garde une trace de cette décision dans mon Obsidian », et la décision atterrit au bon endroit, reliée au bon projet. À l'inverse, je peux demander « qu'est-ce que j'ai dans mes notes sur ce sujet ? » depuis n'importe quel dossier.

Et parce qu'il se contente d'aiguiller, les règles restent **à un seul endroit** : dans le vault. Rien n'est dupliqué, rien ne diverge.

## Partout : quatre briques, un tout petit serveur

Reste la question de l'accès : comment parler à ce second cerveau depuis mon téléphone, quand mon ordinateur est éteint ?

```mermaid
flowchart LR
    Tel["📱 Téléphone<br/>(app Claude)"] -->|Remote Control| VPS["🖥️ Petit VPS<br/>Claude Code + vault"]
    Mac["💻 Ordinateur<br/>Claude Code + vault"]
    VPS <-->|Obsidian Sync| Mac
    VPS <-->|Obsidian Sync| TelObs["📱 Obsidian mobile"]
    Mac -->|sauvegarde| Git[("Dépôt Git privé")]
    VPS -->|sauvegarde| Git
```

### Obsidian Sync

C'est l'abonnement cloud proposé par Obsidian. Je l'utilisais déjà pour avoir mon vault synchronisé sur mon téléphone, et je ne regrette pas une seconde de payer pour ça : c'est un vrai *game changer*.

Il fait circuler les notes entre mon ordinateur, mon téléphone… et un serveur. Car Obsidian Sync existe désormais en version *headless* : sans interface graphique, sur une machine Linux, il garde un dossier synchronisé en continu. Une note écrite sur mon ordinateur apparaît sur le serveur en quelques secondes, et inversement.

### Claude Code en Remote Control

[Remote Control](https://code.claude.com/docs/en/remote-control) relie l'application Claude (iOS, Android ou claude.ai/code dans le navigateur) à un Claude Code qui tourne sur ma propre machine. Sur le serveur, je le lance en mode serveur : il reste allumé en permanence et apparaît dans l'app sous le nom que je lui ai donné.

Son principal intérêt : je peux y **démarrer une nouvelle session** à tout moment, sans qu'aucune session n'ait été ouverte au préalable. J'ouvre l'app, je choisis mon serveur, je parle. Claude écrit dans le vault du serveur… et Obsidian Sync fait le reste.

Le code s'exécute sur le serveur, avec accès à ses fichiers ; la conversation, elle, transite par Anthropic. Remote Control nécessite un abonnement Claude Pro, Max, Team ou Enterprise.

### Git

Git sert à la fois de sauvegarde et de versioning : toutes les trente minutes, chaque machine enregistre l'état du vault dans un dépôt privé. J'ai ainsi l'historique complet de mon second cerveau, note par note. Si une information disparaît (une note supprimée, un passage réécrit un peu trop vite par l'IA), je peux la retrouver plus tard dans l'historique. C'est ce filet de sécurité qui me permet de laisser Claude manipuler mes notes l'esprit tranquille.

Git a un autre rôle, plus discret : Obsidian Sync ne transporte pas les dossiers cachés, et c'est justement là que vivent les skills et les conventions. C'est Git qui les amène sur le serveur.

### Un tout petit VPS

2 cœurs, 1 Go de mémoire, et l'ensemble tient dans moins de 2 Go de disque. La machine s'ennuie la plupart du temps. Inutile d'imaginer une infrastructure lourde : tout se monte en une après-midi, et ne demande ensuite aucune maintenance.

## Deux scènes du quotidien

**En plein dev.** Je travaille sur un projet, dans une session Claude Code qui n'a rien à voir avec Obsidian. On vient de trancher une question d'architecture. « Garde une trace de cette décision dans mon Obsidian. » Le skill général prend le relais : la décision est rédigée, rangée dans le dossier du projet, reliée à sa fiche. Je n'ai pas quitté mon terminal.

**La *deep research*.** Je lance une recherche approfondie depuis mon téléphone : comparer des solutions, faire le point sur un sujet. Claude travaille, puis dépose le résultat au propre dans Obsidian. Je le lis quand je veux. Et le lendemain, depuis mon ordinateur, en pleine session de travail, je demande à Claude de s'appuyer dessus. **Sans me poser de question** sur l'endroit où il est rangé ni sur la façon de le retrouver.

C'est cette boucle complète (capturer, structurer, rappeler) qui fait passer un simple dossier de notes au statut de second cerveau.

## Mes « agents », ce sont mes sessions Claude Code

Quand je parle d'un second cerveau « pour moi et pour mes agents », je ne parle pas d'une armée d'agents autonomes qui tournent en tâche de fond. Mes agents, ce sont mes sessions Claude Code : celle de mon ordinateur, celle de mon serveur, celles que j'ouvre sur chacun de mes projets.

Et je n'ai **aucun besoin** d'un framework d'agent personnel, avec sa propre mémoire et sa propre plateforme, comme Hermes ou OpenClaw. Pas de base vectorielle, rien de plus à installer. Des fichiers Markdown, des conventions claires, quelques skills, et un outil que j'utilise déjà toute la journée.

C'est peut-être le vrai message de cet article : **la mémoire de vos agents peut être un simple dossier que vous pouvez lire vous-même.**

---

## Pour reproduire : les coulisses techniques

Cette partie s'adresse à celles et ceux qui veulent monter quelque chose de similaire. Ce n'est pas un tutoriel pas à pas, plutôt les points clés et les petites astuces qui m'ont servi.

Tous les fichiers évoqués ici sont réunis, en version générique, dans [ce gist](https://gist.github.com/yoanbernabeu/c8b17b989c2bebe22fa106fac20ed196) : l'outil `vault.py`, un vocabulaire et des conventions d'exemple, les sept skills du vault, le skill général, les services systemd et les scripts de sauvegarde.

### L'organisation du vault

```text
mon-vault/
├── CLAUDE.md                  # Point d'entrée pour Claude
├── .claude/
│   ├── kit/
│   │   ├── conventions.md     # Structure, nommage, frontmatter, règles
│   │   ├── vocab.json         # Tags autorisés et entités
│   │   └── scripts/vault.py   # Outil : vérifier, chercher, déplacer
│   └── skills/
│       ├── note/SKILL.md
│       ├── reunion/SKILL.md
│       ├── recherche/SKILL.md
│       └── ...
├── 00 Inbox/
├── Pro/
├── Perso/
└── _Archives/
```

Le `CLAUDE.md` reste court : il décrit le vault en deux lignes et renvoie vers les conventions. Le vocabulaire est un simple fichier JSON, que Claude lit (et enrichit) :

```json
{
  "tags": {
    "tech": ["api", "outils", "ia", "devops"],
    "projet": ["atlas"],
    "perso": ["maison", "santé"]
  },
  "entities": {
    "projet/atlas": "Atlas"
  }
}
```

La règle qui fait tout : un tag `projet/atlas` va **toujours** avec un lien `[[Atlas]]` vers la note de l'entité. Ce sont ces liens qui construisent l'historique de chaque projet.

L'outil de vérification n'a rien de sophistiqué : un script Python d'environ 350 lignes, sans dépendance, écrit avec Claude ([disponible dans le gist](https://gist.github.com/yoanbernabeu/c8b17b989c2bebe22fa106fac20ed196)), qui contrôle le frontmatter, les tags et les liens. Sa force, c'est que les conventions imposent de le lancer après chaque écriture.

### Le skill général

Il vit dans `~/.claude/skills/obsidian/SKILL.md` (le dossier des skills personnels de Claude Code). Il indique le chemin du vault et une table « intention → skill du vault à lire ». Sur le serveur, j'en ai une variante avec le chemin local, qui précise aussi que « noter » veut dire écrire dans le vault, et pas dans une mémoire ou un document claude.ai.

### Obsidian Sync sur le serveur

Le client s'installe avec npm :

```bash
npm install -g obsidian-headless
ob login
cd ~/vaults/mon-vault
ob sync-setup --vault "Mon vault" --device-name vps
ob sync --continuous
```

La dernière commande tourne en continu : je l'ai placée dans un service systemd avec `Restart=always`.

### Remote Control en service systemd

Après avoir installé Claude Code et s'être connecté avec son compte claude.ai (les clés d'API ne sont pas acceptées), le mode serveur se lance ainsi :

```bash
claude remote-control --name VPS-RC --capacity 2 --no-create-session-in-dir
```

- `--name` : le nom affiché dans l'app ;
- `--capacity` : le nombre de sessions simultanées ;
- `--no-create-session-in-dir` : ne pas créer de session au démarrage, je les crée depuis l'app quand j'en ai besoin.

Petit piège pour le faire tourner en service systemd : Claude Code attend un terminal. L'astuce est de l'envelopper dans `script`, qui lui en fournit un :

```ini
[Service]
WorkingDirectory=%h/workspace
ExecStart=/usr/bin/script -qfc "claude remote-control --name VPS-RC --capacity 2 --no-create-session-in-dir" /dev/null
StandardOutput=null
Restart=always
```

Le dossier de travail (`~/workspace`) est volontairement distinct du vault : les sessions y déposent leurs brouillons et fichiers de travail, et seul le résultat final est écrit dans le vault.

### Sécurité

- Le serveur n'accepte que les connexions SSH par clé, derrière un pare-feu fermé par défaut.
- Aucun secret dans le vault : c'est une règle des conventions, que Claude applique en remplaçant tout mot de passe dicté par un renvoi vers le gestionnaire de mots de passe.
- Le dépôt Git est privé, avec une clé de déploiement propre au serveur.

---

## Et la suite ?

La question qui reste ouverte, c'est celle du volume. Aujourd'hui, Claude retrouve facilement ce qu'il cherche grâce à la structure, aux tags et aux liens entre notes. Mais que se passera-t-il quand le vault aura doublé, triplé ? Comment aider les agents à bien chercher dans une base de connaissances qui grossit ? C'est le prochain chantier.

Autre chose : les fichiers du [gist](https://gist.github.com/yoanbernabeu/c8b17b989c2bebe22fa106fac20ed196) sont des exemples, pas mon vault. Mes vraies conventions et mes vrais skills sont taillés pour ma vie, mes projets et ma façon de penser, et c'est justement ce qui les rend utiles. Un second cerveau ne se copie pas, il se construit. Le plus simple : partez de ces exemples, et demandez à Claude de vous aider à les adapter à votre propre façon de travailler. Il est très bon pour ça.

En attendant, si vous deviez retenir une seule chose : **ne demandez pas à l'IA de prendre des notes. Donnez-lui des règles pour les tenir.**

---

## Sources et pour aller plus loin

- Vannevar Bush, [*As We May Think*](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/), *The Atlantic Monthly*, juillet 1945.
- [Le Zettelkasten numérisé de Niklas Luhmann](https://niklas-luhmann-archiv.de/bestand/zettelkasten/), sur le Niklas Luhmann-Archiv (université de Bielefeld).
- Tiago Forte, [*Building a Second Brain*](https://www.buildingasecondbrain.com/) (2022), et son [guide d'introduction à la méthode](https://fortelabs.com/blog/basboverview/).
- David Allen, [*Getting Things Done*](https://gettingthingsdone.com/about/).
- [Documentation de Remote Control](https://code.claude.com/docs/en/remote-control), Claude Code.
- [Les fichiers d'exemple de cet article](https://gist.github.com/yoanbernabeu/c8b17b989c2bebe22fa106fac20ed196) (gist).

<small>*Article écrit avec l'aide de Claude Opus 5.5.*</small>
