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

Qu'est-ce qu'Obsidian ?

Obsidian est une application de prise de notes. La plupart des applications de notes enferment vos écrits dans une base de données privée ; Obsidian, lui, stocke chaque note comme un fichier texte brut, formaté en Markdown, dans un dossier qui vous appartient. Vous pouvez ouvrir ces fichiers dans n'importe quel éditeur, les sauvegarder avec git et les déplacer librement.

Pourquoi l'associer à un modèle local ?

Parce qu'un modèle de langage lit le texte nativement. Quand vos notes sont des fichiers bruts, un modèle local peut les rechercher, les résumer et répondre à des questions à leur sujet — le tout sur votre machine, sans que rien ne quitte votre ordinateur.

C'est cette combinaison qu'explore ce guide. Andrej Karpathy l'a décrite en une seule formule :

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

En clair : Obsidian est l'endroit où vous écrivez et gardez vos notes, le modèle est votre assistant et vos notes sont la matière sur laquelle il travaille. Voici jusqu'où on peut pousser cette idée sur du matériel qui vous appartient — ce qui fonctionne en local aujourd'hui et où un modèle cloud garde encore l'avantage.

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

C'est un heureux hasard : le format simple que les applications de notes utilisent depuis vingt ans est aussi celui qu'un modèle de langage comprend le mieux.

• C'est du texte brut. Le modèle lit directement ce qui est écrit, sans conversion ni logiciel spécial. Une note est un simple fichier texte que le modèle lit tel quel.
• Les titres montrent le plan. Un titre ## marque le début d'une nouvelle idée. Le modèle découpe facilement le document en sections, sans avoir à deviner où elles commencent et où elles finissent.
• Les liens sont écrits par vous. Quand vous écrivez [[recette-pancakes]] dans une note, vous indiquez vous-même que ces deux idées sont liées. Le modèle le sait tout de suite, au lieu d'avoir à le deviner.
• Les infos utiles sont en haut de la note. La date, le tag ou le projet sont notés en début de fichier. Filtrer les notes devient simple : on regarde le début du fichier, pas besoin d'un index séparé.
• On voit tout ce qui change. Si le modèle réécrit une note, vous pouvez comparer l'avant et l'après pour vérifier exactement ce qui a été modifié. Dans une base de données classique, c'est plus difficile.

Les 3 étapes progressives

L'idée de Karpathy décrit un agent qui entretient tout seul votre wiki. C'est l'objectif final, pas le point de départ. Vous pouvez commencer par une étape plus simple, qui fonctionne déjà très bien en local.

Étape 1 — Retrouver une note avec vos propres mots

L'objectif : poser une question comme vous en parleriez à un ami et retrouver la bonne note, même si vous avez oublié son titre ou les mots que vous aviez utilisés.

Exemple : vous demandez « quand a eu lieu ma dernière visite chez le dentiste ? » sans vous souvenir d'avoir une note là-dessus. La recherche sémantique retrouve la bonne note quand même.

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

Dix-huit secondes pour rendre trois ans de notes interrogeables. Ensuite, chaque modification est réindexée automatiquement : vous ne payez ce coût qu'une fois.

Attention, ce n'est pas magique. Dans le même test, la question « quel modèle local choisir selon ma RAM ? » a ramené une note sur la mémoire d'un firmware embarqué — le sujet était proche, la réponse inutile. La recherche rapproche des sujets, pas des vérités. Quand votre coffre fort ne contient pas la réponse, elle vous tend quand même ses trois meilleures approximations, sans vous dire qu'elle a échoué. Prenez les résultats comme des pistes à lire, pas comme des réponses.

Étape 2 — Lire, résumer et rédiger

Une fois la bonne note retrouvée, vous pouvez la confier à un modèle local pour qu'il la travaille : résumez cet ensemble de notes, rédigez une page de synthèse, cherchez les contradictions entre deux documents.

Exemple : vous lui donnez dix notes de réunion et il vous sort une page « décisions prises en 2026 » que vous n'avez plus qu'à relire.

Le choix du modèle compte ici. Accordez-le à la tâche, pas 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. Ne lui demandez pas de garder en tête toute la structure de votre coffre fort.
• 24–32 Go — un modèle 24–32B. Le bon compromis 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 les notes en particulier, privilégiez la longueur de contexte à la taille du modèle. Un modèle qui lit neuf notes d'un coup est plus utile qu'un modèle plus gros qui n'en lit qu'une seule. Vérifiez ce réglage dans Ollama avant de juger le modèle bête.

Étape 3 — Un agent qui entretient tout seul le wiki

C'est l'étape complète : vous donnez une source au modèle, il décide quelles notes existantes elle concerne, les réécrit, crée les pages manquantes et répare les liens. Une seule demande peut modifier une douzaine de fichiers.

C'est l'étape où les modèles locaux échouent encore. Le problème n'est pas la qualité de l'écriture, c'est le nombre d'étapes : chaque étape dépend de la précédente et personne n'est là pour corriger une erreur en cours de route. Un modèle fiable à 95 % par étape tombe à 54 % sur douze étapes.

Pour réussir cette étape aujourd'hui, il faut un modèle cloud avec accès à vos fichiers. Le compromis est réel : un agent qui réécrit votre coffre fort 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 quelles notes vous préférez qu'il ne voie jamais.

Une voie médiane : laissez le modèle local faire le travail à volume (l'ingestion et les premiers résumés) et gardez le modèle cloud pour les restructurations que vous relisez vraiment.

Configurer Obsidian avec Ollama

1. Les deux modèles nécessaires

Il faut télécharger deux modèles, car ils font deux métiers différents : l'un retrouve vos notes, l'autre écrit. Voici les deux commandes :

# Le modèle de recherche — petit et rapide, il retrouve les notes pertinentes
ollama pull nomic-embed-text

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

Deux modèles distincts, deux métiers distincts. Le modèle de recherche transforme le texte en vecteurs pour comparer les notes entre elles ; on ne lui demande jamais d'écrire quoi que ce soit. Il pèse 270 Mo et tourne sur le processeur. N'essayez pas de faire la recherche avec le modèle de langage — la plupart refusent et ceux qui acceptent s'en tirent moins bien.

Vérifiez que la recherche fonctionne 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 coffre fort comme contexte. Pointez-le vers Ollama : choisissez un fournisseur personnalisé compatible OpenAI sur http://localhost:11434/v1, puis désignez votre modèle de langage et nomic-embed-text comme modèle de recherche. 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 coffre fort.

3. Donner au coffre fort 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 coffre fort 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 coffre fort 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 coffre fort que vous bâtissez aujourd'hui pour un modèle cloud 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.