Obsidian + LLM local : vos notes comme mémoire externe du modèle

La fenêtre de contexte est la mémoire la plus petite et la plus coûteuse qu'un ordinateur ait connue depuis des décennies. Une fenêtre de 32k tokens contient environ 25 000 mots — une cinquantaine de pages. Tout ce que le modèle savait avant et tout ce dont il aura besoin ensuite, doit vivre ailleurs.

Cet ailleurs est d'ordinaire une base de données que vous ne pouvez pas lire. Ça n'a rien d'obligatoire. Ce peut être un dossier de fichiers Markdown qui vous appartiennent, que vous éditez à la main et que vous versionnez dans git.

Andrej Karpathy a posé l'analogie de la manière la plus nette possible en décrivant l'usage des LLM pour construire des bases de connaissances personnelles :

« Obsidian est l'IDE, le LLM est le programmeur, le wiki est le codebase. »

Le cadre est juste et il se traduit très concrètement : la fenêtre de contexte est la RAM, votre vault est le disque et décider quoi y écrire relève de la pagination. Ce guide pousse cette idée jusqu'à sa limite pratique sur du matériel qui vous appartient — ce qui fonctionne en local aujourd'hui, ce qui fonctionne bien et la couche où un modèle de tête garde l'avantage.

Pourquoi le Markdown est le format qu'un modèle digère le mieux

C'en est presque trop commode. Le format sur lequel les puristes de l'éditeur de texte se sont fixés il y a vingt ans se révèle être le substrat idéal pour un modèle de langage :

• C'est du texte brut. Aucune étape d'extraction, aucun parseur, aucune conversion avec perte. Les octets sur le disque sont les tokens que lit le modèle.
• Les titres offrent un plan gratuit. Une frontière ## est une frontière sémantique : vous pouvez découper un document sans deviner où s'arrêtent les idées.
• Les wikilinks forment un graphe écrit par un humain. [[une-note]] affirme explicitement que deux idées sont liées — un signal qu'aucun modèle d'embedding ne reconstruit de façon fiable.
• Le frontmatter porte des métadonnées structurées juste à côté du texte : filtrer par date, tag ou projet ne demande aucun index séparé.
• Ça se diffe. Quand un modèle réécrit une note, git diff montre exactement ce qu'il a changé. Essayez d'auditer ça dans une base vectorielle.

Un vault n'est donc pas « des documents que vous donnez à manger à une IA ». C'est une base de connaissances que vous êtes deux à savoir lire.

Les trois couches, de la plus simple à la plus dure

Le cadre de Karpathy décrit un agent qui entretient un wiki. C'est le haut d'une échelle, pas le premier barreau. Les modèles locaux tiennent aisément les barreaux du bas ; sur celui du haut, mieux vaut être lucide.

Couche 1 — La recherche sémantique dans vos propres notes

L'objectif : poser une question avec vos mots et retrouver la bonne note, même quand vous avez oublié son titre et les termes que vous y aviez employés.

Tout tourne sur votre machine et c'est rapide. Mesuré sur un vault réel de 383 notes / 2,4 Mo de Markdown, avec nomic-embed-text sur Ollama :

Étape	Résultat
Chunks produits	2 218
Indexation complète	18,7 s (119 chunks/s)
Requête, modèle chaud	~150 ms
Requête, premier appel (modèle froid)	~4 s
Taille de l'index sur disque	quelques Mo de vecteurs

Dix-huit secondes pour rendre trois ans de notes interrogeables par le sens. La réindexation après édition est incrémentale : en pratique, vous ne payez ce coût qu'une fois.

L'honnêteté oblige à une nuance : la qualité de récupération est correcte, pas magique. Dans ce même test, la question « quel modèle local choisir selon ma RAM ? » a ramené une note sur les budgets RAM d'un firmware embarqué — thématiquement voisine, totalement inutile comme réponse. Les embeddings apparient des sujets, pas des vérités. Quand votre vault ne contient pas la réponse, une recherche par similarité vous tend quand même ses trois meilleures approximations, sans le moindre signal d'échec. Traitez les résultats comme des candidats à lire, pas comme des réponses.

Couche 2 — Lire, résumer, rédiger

Dès que la récupération fonctionne, vous pouvez placer les passages retrouvés devant un modèle local et poser de vraies questions : résume cet ensemble de notes, rédige une page de synthèse, trouve les contradictions entre ces deux documents.

C'est là que le choix du modèle commence à compter et le conseil honnête est de l'accorder à la tâche plutôt qu'au classement des benchmarks :

• 8–16 Go de RAM — un modèle 7–8B (Qwen 3 8B, Gemma 12B quantisé). Bon pour résumer un passage que vous lui tendez. N'attendez pas de lui qu'il tienne la structure de tout votre vault en tête.
• 24–32 Go — un modèle 24–32B. C'est le point d'équilibre pour rédiger et réorganiser des notes.
• 48 Go et plus — un modèle de classe 70B, ou les grandes variantes Qwen/Gemma. Les résumés cessent alors de ressembler à des résumés.

Pour le travail sur notes en particulier, privilégiez la longueur de contexte sur le nombre de paramètres. Un modèle 12B avec une fenêtre de 128k est plus utile pour « lis ces neuf notes et réconcilie-les » qu'un 32B plafonné à 8k. Ollama expose cette valeur par modèle : vérifiez-la avant d'accuser l'intelligence du modèle.

Couche 3 — Un agent qui entretient le wiki

C'est la proposition réelle de Karpathy et la tâche est d'une autre nature : ingérer une source, décider quelles pages existantes elle affecte, les réécrire, créer les pages de concept manquantes, réparer les liens croisés — une seule entrée touchant une douzaine de fichiers en une passe.

C'est la couche où les modèles locaux restent en deçà et le nier vous coûtera un après-midi. Ce n'est pas une question de qualité de plume. C'est que la tâche est agentique : de nombreux appels d'outils successifs, chacun dépendant du précédent, sans personne pour rattraper une erreur d'aiguillage à l'étape quatre. Un modèle fiable à 95 % par étape tombe à 54 % sur douze étapes. Les modèles de tête ne sont pas mystérieusement meilleurs rédacteurs ici — ils sont meilleurs à ne pas dérailler.

Vouloir cette couche aujourd'hui implique un modèle de tête avec accès au système de fichiers. C'est un arbitrage réel, pas une note de bas de page : un agent qui réécrit votre vault a tout lu de ce qu'il contient. C'est exactement le raisonnement de local d'abord, cloud en secours — la réponse n'est pas « jamais de cloud », mais de savoir lesquelles de vos notes vous préférez qu'il n'ait jamais vues.

Une voie médiane praticable : confiez au modèle local l'ingestion et les résumés de première passe (le volume, à faible enjeu) et réservez le modèle de tête aux passes de restructuration que vous relisez vraiment.

L'installation, depuis zéro

1. Ollama et les deux modèles nécessaires

curl -fsSL https://ollama.com/install.sh | sh

# Le modèle d'embedding — petit, rapide, il assure la récupération
ollama pull nomic-embed-text

# Le modèle de génération — à choisir selon le tableau de RAM ci-dessus
ollama pull qwen3:8b

Deux modèles distincts, deux métiers distincts. Le modèle d'embedding transforme du texte en vecteurs et on ne lui demande jamais d'écrire quoi que ce soit ; il pèse 270 Mo et tourne sur le processeur. N'essayez pas d'embedder avec un modèle de chat — la plupart refusent et ceux qui acceptent s'en tirent moins bien.

Vérifiez l'endpoint d'embedding avant d'aller plus loin :

curl -s http://localhost:11434/api/embed \
  -d '{"model":"nomic-embed-text","input":"bonjour"}' | head -c 80

Vous devez recevoir un tableau JSON de flottants. Si vous obtenez This server does not support embeddings, votre serveur Ollama a démarré sans les embeddings : relancez-le simplement avec ollama serve.

2. Le brancher dans Obsidian

Deux plugins communautaires font le travail et ils répondent à des besoins différents :

• Copilot for Obsidian — un panneau de discussion à côté de vos notes, avec le vault comme contexte. Pointez-le vers Ollama : choisissez un fournisseur personnalisé compatible OpenAI sur http://localhost:11434/v1, puis désignez votre modèle de chat et nomic-embed-text comme modèle d'embedding. C'est celui à installer en premier.
• Smart Connections — pas de chat, seulement un panneau « notes liées » qui fait remonter des rapprochements que vous n'aviez jamais faits. Moins d'effort et franchement celui qui change le plus les habitudes quotidiennes.

Les deux indexent en local et parlent à Ollama sans clé d'API. Installation depuis Paramètres → Plugins communautaires, en comptant une à deux minutes pour la première indexation d'un gros vault.

3. Donner au vault une forme que le modèle sait parcourir

Ce point compte davantage que le choix du plugin. Un modèle qui lit un tas plat de 400 notes s'en sort à peu près aussi bien que vous.

La structure qui tient à l'usage compte trois niveaux, à l'image de celle que décrit Karpathy :

sources/     matière brute captée — jamais éditée à la main
notes/       vos propres écrits, une idée par fichier
index.md     le point d'entrée : qui vit où et pourquoi

Puis deux règles qui font l'essentiel du travail :

Écrivez l'index à la main. Un modèle sait lire 400 fichiers, mais cela lui coûte — et vous coûte — bien plus que de lire un seul fichier qui dit où chercher. C'est l'élément au meilleur rendement de tout le dispositif : une note d'entrée qui recense ce que contient chaque domaine, tenue par vous.

Notez le pourquoi, jamais le quoi. Si un fait est retrouvable dans la source, ne le recopiez pas dans une note : la source fait référence et votre copie dérivera. Les contraintes, les raisons, ce que vous avez écarté et pourquoi, la chose qui vous a mordu en mars dernier — rien de tout cela n'est déductible d'ailleurs et c'est précisément ce que le vous futur cherchera.

Le contre-intuitif : moins de contexte, de meilleures réponses

Voici le résultat qui m'a le plus surpris à l'usage quotidien de ce dispositif.

L'instinct, avec une base de connaissances, est de la charger : injecter un résumé de l'activité récente à chaque démarrage de session, entretenir un récapitulatif courant, précharger tout ce dont le modèle pourrait avoir besoin. On a l'impression d'aider.

C'est faux. Sur le vault mesuré plus haut, un récapitulatif chronologique automatique était injecté à chaque session — quelques milliers de tokens de « voilà ce qui s'est passé récemment », chaque fois. Le supprimer purement et simplement a amélioré le dispositif et pas à la marge. Deux effets se sont cumulés :

1. L'évident. Des milliers de tokens par session, libérés pour le travail réel.
2. Celui que je n'avais pas prévu. Le récapitulatif automatique disparu, le réflexe a changé — vers la lecture de l'index puis de la note pertinente, à la demande. Le récap passif était une béquille : il répondait assez correctement à « où en étions-nous ? » pour que personne n'aille solliciter la source bâtie pour y répondre vraiment.

Supprimer une solution médiocre a battu l'ajout d'une bonne. Nul besoin d'entraîner le bon réflexe si l'on cesse de le contourner.

La règle générale que cela désigne : récupéré à la demande vaut mieux qu'injecté en permanence. Du contexte dépensé avant de connaître la question est du contexte dépensé sur une supposition. Un vault doté d'un bon index est un dispositif pour le dépenser après.

Ce que vous y gagnez vraiment

Une fois l'outillage mis de côté, le changement est celui-ci : vos notes cessent d'être un endroit où vous classez pour devenir un endroit où vous interrogez.

Non pas parce que le modèle serait devenu intelligent au sujet de votre vie — il ne l'est pas et la récupération vous tendra une note de firmware quand vous l'interrogerez sur la RAM. Mais parce que trouver ne dépend plus de se souvenir. Une note écrite en 2024 et complètement oubliée remonte parce qu'elle traite de ce que vous demandez, non parce que vous vous rappeliez son titre.

Les parties qui tournent en local — recherche, résumé, rédaction — tournent sur du matériel qui vous appartient, sur des fichiers qui vous appartiennent, sans abonnement et sans que rien ne quitte la machine. Celle qui n'y tourne pas encore est le bibliothécaire pleinement autonome et cet écart se refermera. En attendant, le vault que vous bâtissez aujourd'hui pour un modèle de tête est celui qu'un modèle local lira demain, parce que ce n'est que du Markdown dans un dossier. C'est l'avantage discret d'un format ennuyeux : il survit à l'outil que vous avez choisi cette année.