Tips & Tricks (Mis à jour: 06/06/2026)

Vos notes Obsidian « grandissent toutes seules » grâce à l'IA. Se construire un second cerveau

Comment semi-automatiser le maillage, le résumé et le rangement de notes Obsidian éparses en les faisant lire par l'IA.

Vos notes Obsidian « grandissent toutes seules » grâce à l'IA. Se construire un second cerveau

Minuit pile, je tapais dans la barre de recherche d’Obsidian : « cette commande, c’était quoi déjà ? »

Une commande shell de trois lignes notée il y a deux ans. Qu’elle existe, ça, c’est sûr. Mais dans laquelle de mes 500 notes elle est enfouie, aucune idée. Ce soir-là, j’ai fini par renoncer à la chercher et j’ai re-googlé.

Je ne pense pas être le seul.

Obsidian (l’appli de notes), plus on l’utilise, plus c’est pratique. Mais en même temps, à coup sûr, ça part en pagaille. Journaux quotidiens, fiches de lecture, fragments de code, idées d’articles, notes de réunion. Tout s’accumule sous forme de fichiers Markdown, et en six mois on obtient « son propre débarras personnel, impossible à fouiller ».

D’où ce que j’ai commencé à faire : faire lire mon Vault (l’entrepôt des notes) par l’IA, et lui faire porter à peu près la moitié du rangement. Poser des liens, fabriquer des résumés, repêcher les notes égarées. À répéter un peu chaque jour, mes notes éparses se sont mises à se relier toutes seules, et ça a vraiment commencé à ressembler à un « second cerveau ». C’est de ça que je parle aujourd’hui.

« Une note qui grandit », ça veut dire quoi au juste ?

Une note ordinaire atteint son sommet à l’instant où on l’écrit. Ensuite, elle ne fait que tomber dans l’oubli.

Mais Obsidian a une syntaxe [[Nom de note]] qui relie les notes entre elles (on appelle ça un Wikilink), et plus on relie, plus ça devient une seule grande carte. De la note « erreur de typage TypeScript », on saute vers « cette histoire de Docker où j’ai galéré ce jour-là », et de là on rejoint « le post-mortem de l’incident du mois dernier ». Les points deviennent des lignes, les lignes deviennent une surface. C’est cette sensation-là.

Le problème, c’est que ce maillage, quand c’est un humain qui le fait, c’est trop pénible pour tenir dans la durée.

C’est là qu’on s’en remet à l’IA. Concrètement, comme coéquipier, on utilise Claude Code. C’est une IA faite pour écrire du code, mais en pratique on l’emploie comme « le préposé qui lit et écrit en sécurité un dossier rempli de fichiers Markdown ». L’atout local-first d’Obsidian (les fichiers sont sur votre PC) reste intact, et on ne refile que la corvée du rangement. Voilà la stratégie du jour.

Une seule mise en garde d’abord. Donner à l’IA un droit d’édition sur tout le Vault, c’est à éviter absolument.

.obsidian/ (le dossier de configuration), les articles déjà publiés, des notes personnelles comme des contrats, des clés API : il n’y a aucune raison de les faire lire à l’IA. Alors je tiens un principe : « lecture plutôt large, écriture ultra-prudente ». C’est exactement l’idée de comment construire l’« échafaudage » pour confier du travail à l’IA ; en somme, on met les petites roues avant de rouler.

Là où ça fait mouche (trois cas)

L’abstrait ne passe pas, alors voici trois instants où j’ai vraiment senti « ah, ça marche ».

Le premier, le journal du matin. Chaque matin, je fais lire à l’IA la note de la veille : « reporte sur aujourd’hui seulement les tâches non terminées, et compresse en trois lignes ce que j’ai appris hier ». Et les notes que le moi d’hier a laissées en désordre ressortent sous une forme où le moi d’aujourd’hui peut agir. « Ah oui, c’est là-dessus que je coinçais hier », je m’en souviens en un instant. Le destinataire de la passation, c’est mon moi futur.

Le deuxième, le sauvetage de fragments de code. Le problème de la « commande d’il y a deux ans » de tout à l’heure. Si on jette dans le dossier snippets/ les commandes qui ont marché, l’IA leur ajoute toute seule une description « cette commande sert à quoi ? » et des liens vers d’autres notes liées. Une commande toute nue se mue en une « vraie note » qu’on retrouve à la recherche.

Le troisième, la préparation d’idées d’articles. Le jour où j’écris au blog, je montre à l’IA le carnet d’idées du dossier content-ops/ : « cet article, vers quels anciens articles pourrait-il faire un lien interne ? » Il lui arrive de remonter un article d’il y a six mois que j’avais moi-même oublié, et ça, ça paie en sourdine. Le moment où les points se relient.

Mes trois plantages personnels

C’est peut-être ici le cœur du sujet. Les premières semaines, mon Vault s’est fait saccager par l’IA. Je l’étale sans pudeur.

Le premier. J’ai demandé d’emblée « range tout le Vault ». Le pire de tous. L’IA a voulu « gentiment » ranger jusqu’aux notes incompréhensibles d’il y a deux ans, et a fait pousser en masse des tags et des titres de sa propre initiative. La vue graphe (l’écran qui visualise les liens entre notes) est devenue une jungle de tags inconnus. L’intention d’une vieille note, l’IA ne peut pas la connaître. Et pourtant elle agit à la devinette. Depuis, je restreins toujours la cible à un seul dossier.

Le deuxième. J’ai laissé l’IA renommer des notes de sa propre initiative. « Rends les titres plus clairs. » Et d’un coup, tous les liens [[Ancien nom de note]] ont cassé. Obsidian, si vous renommez vous-même, fait suivre les liens ; mais quand une IA externe réécrit les noms de fichiers en masse, ce suivi ne marche pas. Champ de cadavres de liens morts. Aujourd’hui, « tout renommage passe par une confirmation humaine » est une loi d’airain.

Le troisième. J’ai laissé lire private/. Là, ça a dépassé le simple frisson. Un dossier contenant des notes sur des montants de contrat, je l’avais laissé lisible par l’IA en bâclant les permissions. Pas d’accident, mais c’était comme laisser une recrue toucher à mains nues la base de prod. Si je l’avais bien inscrit dans deny (la liste de refus), l’accident n’aurait même pas pu se produire. La leçon : c’est moi le fautif, à avoir lésiné sur la config.

Comment démarrer : poser seulement trois fichiers

Rien de compliqué. À la racine du Vault, on en prépare trois.

D’abord, on sépare les dossiers. Trop classer dès le départ casse à coup sûr, alors du grossier suffit.

# À exécuter à la racine du Vault. On sépare juste : usage quotidien, projets, travail de publication, zone protégée
mkdir -p inbox daily projects content-ops snippets templates scripts archive private

Le rôle de chaque dossier, et jusqu’où on confie à l’IA, je le répartis ainsi.

DossierRôlePérimètre confié à l’IA
inbox/notes non triées, réceptacle des clips weblecture et création
daily/journaux, notes de travailcréation, ajout, résumé de la veille
projects/tâches en cours, passationscréation, mise à jour, tri des points en suspens
content-ops/idées d’articles, liens internes, contrôle de publicationrangement des brouillons, vérif des liens
snippets/fragments de code et mode d’emploiajout de descriptions, rangement des tags
templates/modèles Obsidianen principe, éditer seulement après confirmation
archive/terminé, archivéédition interdite
private/données perso, contrats, secretslecture interdite aussi

Ensuite, on pose CLAUDE.md à la racine du Vault. C’est la feuille où sont écrites « nos règles » pour l’IA. Plutôt qu’un long laïus de principes, écrire courtement les règles d’entrée/sortie à respecter, ça fait davantage mouche.

# Règles du Vault Obsidian

## Rôle
- Ce Vault accueille journaux quotidiens, passations de projet, fragments de code, idées d'articles.
- Fonctionner de façon utile sans avoir besoin de lire private.

## Politique des dossiers
- `daily/` : créer et mettre à jour les notes du jour en `YYYY-MM-DD.md`.
- `projects/` : maintenir une note de passation par projet actif.
- `snippets/` : conserver les commandes qui marchent, avec leur contexte et leurs ratés.
- `templates/` : libre en lecture. Demander avant d'éditer.
- `archive/` et `private/` : ne pas éditer. Ne pas résumer le contenu de private.

## Règles d'écriture
- Écrire les liens internes au format Wikilink `[[Nom de projet]]`.
- Mettre des propriétés YAML (status, etc.) en tête de note.
- Tenir un paragraphe en cinq lignes maximum.

## Règles de sécurité
- Tout renommage d'une note existante passe d'abord par une confirmation.
- Ne pas réécrire la config de `.obsidian/`.
- Avant une édition en masse, lister les fichiers cibles et attendre l'aval.
- Après édition, exécuter sans faute `node scripts/audit-wikilinks.cjs .`.

Le dernier point est le plus important. Avec .claude/settings.json, on bride physiquement les droits. CLAUDE.md, c’est une « prière » ; ceci, c’est un « verrou physique ». Le portier pour ne jamais répéter le troisième de mes ratés. Lecture large, écriture seulement dans les dossiers de travail, opérations dangereuses verrouillées par deny. Pour le détail de la config, voyez la documentation officielle des permissions.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read(./CLAUDE.md)",
      "Read(./daily/**)",
      "Read(./projects/**)",
      "Read(./content-ops/**)",
      "Read(./snippets/**)",
      "Read(./templates/**)",
      "Read(./scripts/**)",
      "Edit(./daily/**)",
      "Edit(./projects/**)",
      "Edit(./content-ops/**)",
      "Edit(./snippets/**)",
      "Write(./inbox/**)",
      "Write(./daily/**)",
      "Write(./projects/**)",
      "Write(./content-ops/**)",
      "Write(./snippets/**)",
      "Bash(node scripts/audit-wikilinks.cjs .)"
    ],
    "ask": [
      "Edit(./templates/**)",
      "Bash(git *)"
    ],
    "deny": [
      "Read(./private/**)",
      "Read(./**/.env)",
      "Read(./**/.env.*)",
      "Edit(./.obsidian/**)",
      "Edit(./archive/**)",
      "Write(./archive/**)",
      "Bash(rm *)",
      "Bash(del *)"
    ]
  }
}

Une fois ces trois feuilles posées, il ne reste qu’à demander. L’astuce : ne pas dire « range au mieux ». Périmètre, livrable, interdits, vérification : on précise tout, à chaque fois.

Lis daily/2026-06-04.md et projects/site-refresh.md.
À partir de templates/daily.md, crée daily/2026-06-05.md.
Pour les tâches non terminées, ne reporte que celles dont je suis encore le responsable.
Ne touche pas à .obsidian/, archive/ ni private/.
Une fois l'édition finie, exécute node scripts/audit-wikilinks.cjs . et rapporte le résultat.

C’est court, mais entrée, sortie, périmètre interdit et commande de vérification y sont tous. Bien plus reproductible que « au mieux ».

Le portier final : vérifier les liens morts à la machine

Quand on laisse une IA externe éditer des fichiers, il arrive que des Wikilinks cassent. À l’œil humain, ça passe. Alors en dernier, on intercale un script qui débusque mécaniquement les liens cassés. À enregistrer sous scripts/audit-wikilinks.cjs.

#!/usr/bin/env node
// Script-portier qui débusque les liens internes ([[...]]) cassés ou ambigus dans le Vault
const fs = require("node:fs");
const path = require("node:path");

const vaultRoot = path.resolve(process.argv[2] || ".");
const ignoredDirs = new Set([".git", ".obsidian", ".trash", "node_modules"]);
const allFiles = [];
const markdownFiles = [];

function walk(dir) {
  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
    if (ignoredDirs.has(entry.name)) continue;
    const full = path.join(dir, entry.name);
    if (entry.isDirectory()) {
      walk(full);
    } else if (entry.isFile()) {
      allFiles.push(full);
      if (entry.name.toLowerCase().endsWith(".md")) markdownFiles.push(full);
    }
  }
}

function toPosix(filePath) {
  return filePath.split(path.sep).join("/");
}

function withoutMd(value) {
  return value.replace(/\.md$/i, "");
}

function stripTarget(raw) {
  return raw.split("|")[0].split("#")[0].split("^")[0].trim();
}

function safeDecode(value) {
  try {
    return decodeURIComponent(value);
  } catch {
    return value;
  }
}

function isExternal(target) {
  return /^(https?:|mailto:|obsidian:|#|\/)/i.test(target);
}

function candidateKeys(target, fromFile) {
  const clean = safeDecode(stripTarget(target));
  if (!clean) return [];
  const keys = new Set();
  const normalized = toPosix(path.normalize(clean));
  keys.add(normalized);
  keys.add(withoutMd(normalized));

  if (clean.includes("/") || clean.includes("\\")) {
    const fromDir = path.dirname(toPosix(path.relative(vaultRoot, fromFile)));
    const relative = toPosix(path.normalize(path.join(fromDir, clean)));
    keys.add(relative);
    keys.add(withoutMd(relative));
  } else {
    keys.add(withoutMd(path.posix.basename(normalized)));
    keys.add(path.posix.basename(normalized));
  }

  return [...keys].filter(Boolean);
}

walk(vaultRoot);

const byPath = new Map();
const byBase = new Map();

for (const file of allFiles) {
  const rel = toPosix(path.relative(vaultRoot, file));
  const lowerRel = rel.toLowerCase();
  byPath.set(lowerRel, file);
  if (rel.toLowerCase().endsWith(".md")) byPath.set(withoutMd(lowerRel), file);

  const base = rel.toLowerCase().endsWith(".md")
    ? withoutMd(path.posix.basename(rel)).toLowerCase()
    : path.posix.basename(rel).toLowerCase();
  const list = byBase.get(base) || [];
  list.push(file);
  byBase.set(base, list);
}

const problems = [];
const wikilink = /!?\[\[([^\]]+)\]\]/g;
const markdownLink = /!?\[[^\]]*\]\(([^)]+)\)/g;

for (const file of markdownFiles) {
  const text = fs.readFileSync(file, "utf8");
  const rel = toPosix(path.relative(vaultRoot, file));
  const targets = [];
  let match;

  while ((match = wikilink.exec(text))) targets.push(match[1]);
  while ((match = markdownLink.exec(text))) {
    const target = match[1].replace(/^<|>$/g, "").trim();
    if (!isExternal(target)) targets.push(target);
  }

  for (const target of targets) {
    const clean = stripTarget(target);
    if (!clean || isExternal(clean)) continue;
    const keys = candidateKeys(clean, file);
    const pathHit = keys.some((key) => byPath.has(key.toLowerCase()));
    const baseHits = keys.flatMap((key) => byBase.get(path.posix.basename(key).toLowerCase()) || []);

    if (!pathHit && baseHits.length === 0) {
      problems.push(`${rel} -> missing [[${clean}]]`);
    } else if (!pathHit && baseHits.length > 1) {
      problems.push(`${rel} -> ambiguous [[${clean}]] (${baseHits.length} matches)`);
    }
  }
}

if (problems.length) {
  console.error("Liens internes cassés ou ambigus trouvés :");
  for (const problem of problems) console.error(`- ${problem}`);
  process.exit(1);
}

console.log(`OK : ${markdownFiles.length} fichiers Markdown vérifiés dans ${vaultRoot}`);

Pour lancer, c’est tout.

node scripts/audit-wikilinks.cjs .

Si tous les liens sont vivants, OK s’affiche. S’il y en a de cassés, il vous dit dans la liste quel lien de quel fichier est mort. Le lancer juste après que l’IA a rangé, c’est ma conclusion de chaque journée.

À noter : pour les mécanismes côté Obsidian (Daily notes, Templates, Properties, liens internes), reportez-vous à l’aide officielle d’Obsidian pour les spécifications exactes. Comprendre soi-même le vaisseau-mère avant de déléguer à l’IA évite de donner des consignes bancales.

Ce que j’ai testé, concrètement

Trois mois que je fais tourner mon Vault avec ce dispositif.

Ce qui a le plus payé, finalement, c’est la « passation du journal quotidien » et l’« audit des liens avant publication ». Faire résumer la veille par l’IA dès le matin, et le démarrage est nettement plus rapide. « Ah, le moi d’hier, c’est là qu’il s’était arrêté », je le vois d’un coup d’œil, et le temps d’un café, ma tête bascule en mode du jour. Depuis que j’intercale l’audit des liens, les nuits où je blêmis après publication d’un « ah, un lien interne cassé » sont tombées à zéro. En chiffres : avant l’audit, je publiais des liens morts deux à trois fois par mois ; aujourd’hui, zéro.

Autre chose, un effet secondaire inattendu. Le fait de partir du principe que l’IA touche aux notes chaque jour a changé ma propre façon d’écrire. En me disant qu’une machine les relira ensuite, j’ajoute naturellement un status:, ou une seule ligne de contexte même sur une note griffonnée. Je croyais mettre en ordre pour l’IA ; au final, celui pour qui c’est devenu le plus lisible, c’est l’humain que je suis.

À l’inverse, la fois où j’ai fait ranger tout le Vault d’un coup au départ fut un échec net. L’IA a trop deviné le sens des vieilles notes, et tags et titres ont au contraire proliféré et embrouillé. La conclusion est simple : plus on respecte les trois points « périmètre étroit, modèles légers, audit Node à la fin », mieux ça marche.

Le plus amusant, c’est qu’à cette commande d’il y a deux ans, que je n’aurais jamais retrouvée il y a six mois, j’accède aujourd’hui en cinq secondes. Je n’ai qu’à suivre les liens que l’IA a patiemment posés. Mes notes sont vraiment devenues un cerveau.

En résumé

Le vrai visage de « la note qui grandit toute seule », ce n’est pas de la magie. Lecture large, écriture étroite, et revérification à la machine à la fin. J’ai juste fait de cette évidence un dispositif.

Trois choses à faire. Séparer les dossiers, écrire les règles dans CLAUDE.md, et boucher physiquement les opérations dangereuses avec .claude/settings.json. Ensuite, sans dire « au mieux », demander en restreignant le périmètre. Aujourd’hui, commencez par daily/, un seul. Le moi de demain s’en trouvera un peu soulagé.

Pour creuser la logique des permissions et du sandbox, voyez aussi la conception validation / sandbox de Claude Code. Les modèles à mettre en pratique et les contacts pour l’adoption en équipe sont réunis dans la liste des supports.

#obsidian #claude-code #second-cerveau #pkm #markdown #automatisation
Gratuit

PDF gratuit: cheatsheet Claude Code

Saisissez votre email et téléchargez une page avec commandes, habitudes de review et workflow sûr.

Nous protégeons vos données et n'envoyons pas de spam.

Masa

À propos de l'auteur

Masa

Ingénieur spécialisé dans les workflows pratiques avec Claude Code.