Points clés
- Choisissez l'une des trois architectures de référence plutôt que de partir de zéro. Obsidian-centré (orienté notes, ~50K éléments), AnythingLLM-centré (orienté documents, ~100K éléments) ou stack Python + ChromaDB sur mesure (orienté ingénieurs, 1M+ éléments). Mélanger les architectures est rarement rentable — le coût d'intégration domine.
- Une PKB IA locale comporte cinq couches : capture, stockage, embeddings, récupération, interface. La plupart des erreurs de débutant se produisent au niveau de la capture, pas du LLM. Si les éléments ne circulent pas depuis le mobile et l'e-mail, aucune récupération ingénieuse ne sauvera le projet.
- Seuil matériel : 16 Go de RAM. En dessous, vous choisissez entre exécuter un modèle d'embedding ou un modèle de chat — pas les deux. À 16 Go, vous pouvez exécuter Llama 3.2 3B + nomic-embed-text simultanément. À 32 Go, vous pouvez passer à Qwen3 7B ou exécuter plusieurs sessions de chat. Au-delà de 100 000 éléments, déplacez les embeddings vers un serveur domestique.
- Modèles recommandés en 2026 : chat — Llama 3.2 3B (par défaut), Phi-4 Mini (systèmes 8 Go), Qwen3 7B (qualité au-delà de 32 Go) ; embeddings — nomic-embed-text (768-dim, rapide), mxbai-embed-large (1024-dim, plus précis), bge-m3 (multilingue).
- La capture est le goulot d'étranglement, pas la récupération. La plupart des éléments arrivent sur mobile (captures web, captures d'écran, notes vocales, e-mails transférés). Concevez le chemin partage mobile → vault avant de régler le LLM. iOS Shortcuts → Obsidian / Working Copy / a-Shell sont les trois chemins iOS viables.
- La méthode de synchronisation détermine ce qui fonctionne sur mobile. Obsidian Sync gère proprement les index binaires d'embeddings ; iCloud Drive les corrompt entre plateformes ; Git nécessite une discipline .gitignore et une réindexation par appareil. Choisissez la sync d'abord, les plugins ensuite.
- La sauvegarde n'est pas optionnelle. Trois couches : snapshot du vault (Time Machine, Backblaze, restic), historique Git du contenu en clair et un export trimestriel des embeddings + métadonnées comme chemin de reconstruction propre. Les embeddings sont régénérables, mais coûteux — sauvegardez-les aussi au-delà de 10 000 éléments.
Faits rapides
- Architectures couvertes : Obsidian-centré, AnythingLLM-centré, stack Python + ChromaDB sur mesure.
- Backend LLM : Ollama (recommandé) — exécute les modèles de chat et d'embedding derrière un endpoint local à
http://localhost:11434. - Modèles de chat recommandés en 2026 : Llama 3.2 3B (systèmes 16 Go), Phi-4 Mini (8 Go), Qwen3 7B (32 Go+).
- Modèles d'embedding recommandés en 2026 : nomic-embed-text (768-dim, rapide), mxbai-embed-large (1024-dim, précis), bge-m3 (multilingue).
- Cibles en nombre d'éléments : Obsidian ~50 000 notes, AnythingLLM ~100 000 documents, stack Python + ChromaDB sur mesure 1 M+.
- Seuil matériel : portable 16 Go de RAM. Au-delà de 10 000 éléments : 32 Go recommandés. Au-delà de 100 000 : serveur domestique 64 Go.
- Chemins de capture mobile (iOS) : Shortcuts → Obsidian, Shortcuts → Working Copy (Git), Shortcuts → a-Shell. Android : Tasker ou HTTP Shortcuts.
Quelle architecture construire ?
Choisissez l'architecture adaptée à la façon dont vos connaissances arrivent déjà — pas celle qui paraît la plus puissante. Si vous écrivez déjà des notes au quotidien, optez pour Obsidian-centré. Si vos connaissances sont surtout des documents (PDF, exports, captures web), optez pour AnythingLLM-centré. Construisez un stack Python + ChromaDB sur mesure uniquement si vous avez véritablement 100 000+ éléments ou un besoin multi-utilisateurs — le coût de maintenance est réel et rarement justifié en deçà.
📍 En une phrase
Les workflows orientés notes choisissent Obsidian + Smart Connections + Copilot + Ollama ; les archives orientées documents choisissent AnythingLLM + Ollama ; les ingénieurs avec 100K+ éléments choisissent un stack Python + ChromaDB sur mesure.
💬 En termes simples
Trois voies, une destination. Si vous vivez déjà dans une application de notes, Obsidian habille votre routine existante de fonctionnalités IA. Si vous accumulez surtout des PDF et des pages web, AnythingLLM est une seule application qui ingère, indexe et chatte. Si vous codez et voulez un contrôle total, Python + ChromaDB vous laisse construire exactement ce que vous voulez — mais vous le maintenez. Choisissez la voie qui correspond à votre workflow existant ; ne changez pas vos habitudes pour vous adapter à l'architecture.
Décision : quelle architecture PKB ?
Use a local LLM if:
- •Vous utilisez déjà Obsidian ou souhaitez un workflow orienté notes en Markdown → Obsidian-centré
- •Vos connaissances sont surtout des PDF, exports, captures web et archives e-mail → AnythingLLM-centré
- •Vous avez 100 000+ éléments, des besoins de schéma sur mesure ou un accès multi-utilisateurs → stack Python + ChromaDB sur mesure
- •Vous voulez une application qui couvre capture, stockage, RAG et chat → AnythingLLM-centré
- •Vous voulez un contrôle total sur le chunking, la récupération et le re-ranking → stack Python + ChromaDB sur mesure
Use a cloud model if:
- •Vous avez besoin d'un raisonnement de classe GPT-4o à chaque requête et votre archive est petite → Notion AI ou ChatGPT avec GPT personnalisés (le stack local est ~70 % aussi capable en synthèse)
- •Vous n'avez pas de machine avec 16 Go+ de RAM ni de serveur domestique → PKB SaaS cloud (Mem, Reflect)
- •Votre équipe a besoin d'un accès multi-utilisateurs concurrent et vous ne voulez pas héberger de services → équivalent cloud
Quick decision:
- →Par défaut pour les utilisateurs orientés notes : Obsidian + Smart Connections + Copilot + Ollama
- →Par défaut pour les utilisateurs orientés documents : AnythingLLM + Ollama
- →Ingénieur avec 100K+ éléments : stack Python + ChromaDB + Llama 3.2 3B sur mesure
💡Tip: Ne commencez pas par le stack Python sur mesure simplement parce qu'il paraît plus puissant. Construisez d'abord en Obsidian-centré ou AnythingLLM-centré, faites tourner pendant deux mois, identifiez la couche qui ne convient pas à votre workflow, et ne remplacez qu'ensuite cette couche par un composant sur mesure. Tous les projets PKB démarrés « from scratch en Python » et tournant plus de six mois ont fini par converger vers une forme Obsidian ou AnythingLLM.
Tableau comparatif des architectures
Les trois architectures de référence diffèrent sur cinq axes pertinents pour la plupart des projets : complexité d'installation, plafond en nombre d'éléments, sync mobile, flexibilité de capture et coût de maintenance. La complexité d'installation croît à peu près linéairement avec le contrôle — et le coût de maintenance aussi.
📍 En une phrase
Obsidian a une complexité moyenne à ~50K éléments, AnythingLLM une faible complexité à ~100K éléments, et un stack Python + ChromaDB sur mesure une complexité élevée mais monte au-delà de 1 M d'éléments.
💬 En termes simples
AnythingLLM est le plus simple à installer et monte le plus haut des deux options « clé en main » — mais il est strict sur l'organisation des documents. Obsidian offre la couche de prise de notes la plus expressive et un écosystème de plugins actif, au prix d'une installation un peu plus longue. Python sur mesure est sans plafond, mais vous maintenez tout : chunking, re-ranking, déduplication, sync, sauvegardes. Choisissez selon votre tolérance à la maintenance, pas seulement selon le nombre d'éléments.
| Architecture | Complexité | Éléments max | Sync mobile | Idéal pour |
|---|---|---|---|---|
| Obsidian-centré | Moyenne | ~50 000 | Oui (Obsidian Sync ; iCloud / Git avec restrictions) | Utilisateurs orientés notes avec routine d'écriture quotidienne |
| AnythingLLM-centré | Faible | ~100 000 | Limitée (web UI depuis le mobile via LAN / Tailscale) | PKB orientées documents (PDF, exports, captures web) |
| Python + ChromaDB sur mesure | Élevée | 1 M+ | Manuelle (API + client mobile à construire) | Ingénieurs voulant un contrôle total + multi-utilisateurs |
💡Tip: La sync mobile est l'axe de comparaison le plus sous-estimé. AnythingLLM est techniquement plus simple à installer qu'Obsidian, mais sur mobile cela signifie « ouvrir l'UI web LAN dans Safari » — ce n'est pas une expérience native. Obsidian Mobile, associé à Obsidian Sync, vous offre une application iOS / Android quasi native avec lecture hors ligne. Si la capture et la lecture mobiles comptent, pondérez Obsidian plus haut que ne le suggère le tableau.
Les cinq couches d'une PKB IA locale
Toute PKB IA locale comporte les mêmes cinq couches, quelle que soit l'architecture : capture, stockage, embeddings, récupération, interface. Les échecs viennent généralement d'un décalage entre couches — le plus souvent une récupération sophistiquée associée à un pipeline de capture cassé que personne n'utilise.
- 1Capture
Why it matters: Comment les éléments entrent dans le système. Web clipper, redirection e-mail, partage mobile, note vocale, copier-coller manuel. La couche la plus souvent négligée dans les projets de débutants — et celle qui détermine la survie du système au quotidien. Si la capture mobile prend plus de 5 secondes, le système reste inutilisé. - 2Stockage
Why it matters: Où vivent les éléments sur le disque. Vault Markdown (Obsidian, Logseq), dossier de documents + base de données (AnythingLLM) ou système de fichiers + manifeste (Python sur mesure). Choisissez un format de stockage qui survit à un changement d'outil — le Markdown en clair est le plus portable ; les bases binaires le moins. - 3Embeddings
Why it matters: Représentations vectorielles des éléments pour la recherche sémantique. Générées par un modèle local (nomic-embed-text ou mxbai-embed-large via Ollama). Le modèle d'embedding peut être changé plus tard, mais le coût de migration vaut « tout réembedder » — choisissez une fois, tenez-vous-y. - 4Récupération
Why it matters: Comment les éléments sont retrouvés à la requête. Recherche vectorielle top-k, re-ranking optionnel, filtres de métadonnées (tags, dates, sources). L'écart de qualité entre un top-5 naïf et un top-20-avec-re-ranker bien réglé est l'écart entre « utile » et « magique ». - 5Interface
Why it matters: Comment vous interrogez et lisez. Sidebar (Smart Connections), chat (Copilot, AnythingLLM), CLI (Python sur mesure) ou API. La plupart des utilisateurs prennent le chat par défaut — mais une sidebar « notes liées » fait remonter du matériel oublié que le chat ne trouve pas, parce que vous ne savez pas quoi demander.
⚠️Warning: Un schéma de projet courant qui échoue : choisir la récupération la plus puissante (recherche hybride sur mesure avec re-ranking), le modèle de chat le plus intelligent (Qwen3 7B), et ignorer la capture. Trois semaines plus tard, le vault contient 47 éléments parce que rien ne circule depuis le mobile. La correction est toujours la même : simplifier la récupération, simplifier le chat, réparer la capture, et accepter que 80 % de la valeur vienne du fait que les éléments sont simplement présents dans le système.
Architecture A : Obsidian-centré
Obsidian + Smart Connections + Copilot for Obsidian + Ollama est l'architecture par défaut pour les workflows orientés notes en 2026. Elle monte proprement jusqu'à ~50 000 notes sur un Mac M3 Pro 16 Go ou un PC équivalent, supporte la lecture mobile via Obsidian Mobile, et garde tout en Markdown en clair que vous pourrez emporter vers n'importe quel outil futur.
- Stockage : fichiers Markdown dans un dossier (« vault »). Texte clair, dossiers simples, pas de base de données. Survit aux migrations d'outils.
- Capture : Obsidian Web Clipper (extension navigateur), partage mobile Obsidian (iOS / Android), e-mail vers Obsidian via Mailspike ou une recette IFTTT sur mesure, copier-coller manuel.
- Embeddings : plugin Smart Connections → Ollama à
http://localhost:11434/api/embeddings→ nomic-embed-text (par défaut) ou mxbai-embed-large (plus précis). L'index vit dans.smart-env/à l'intérieur du vault. - Récupération : sidebar Smart Connections (vue notes liées) + mode Vault QA de Copilot for Obsidian (RAG sur le vault pour les requêtes chat). Les deux exploitent l'index d'embeddings.
- Interface : sidebar Smart Connections (découverte passive) + panneau chat Copilot (requêtes actives) + templates Text Generator (workflows répétables comme les résumés quotidiens).
- Temps d'installation : ~30 min (installer Ollama, télécharger les modèles, installer trois plugins, configurer les endpoints, laisser construire l'index initial).
- Matériel : 16 Go de RAM minimum (Llama 3.2 3B + nomic-embed-text simultanément). 32 Go recommandés au-delà de 10 000 notes. SSD fortement recommandé — la reconstruction d'index est I/O-limitée sur HDD.
- Plafond d'éléments : ~50 000 notes en pratique ; testé jusqu'à 20 000 avec ré-indexation incrémentale sub-seconde. Au-delà de 50K notes, l'index initial tourne 4–8 heures et vous devriez envisager des sous-vaults.
- Idéal pour : utilisateurs avec routine d'écriture quotidienne, préférences Markdown-first, et désir d'une sidebar « partenaire de pensée » qui fait remonter les notes oubliées.
- Pas pour : utilisateurs dont les connaissances sont surtout des PDF et captures web (choisir AnythingLLM-centré) ; utilisateurs voulant une seule application tout-en-un (Obsidian-centré, c'est « Obsidian + 3 plugins + Ollama »).
💡Tip: Pour un approfondissement de la couche plugin de cette architecture (quels 5 plugins, étapes de configuration, valeurs d'échelle de vault), voir le guide des plugins Obsidian + LLM local. Cette page couvre l'architecture ; le guide des plugins couvre la configuration.
Architecture B : AnythingLLM-centré
AnythingLLM + Ollama est l'option tout-en-un : capture, stockage, RAG et chat sont regroupés dans une seule application bureau ou auto-hébergée. Elle monte jusqu'à ~100 000 documents (mélange de PDF, captures web, exports) et c'est le bon choix quand vos connaissances arrivent surtout sous forme de documents plutôt que de notes.
- Stockage : base de données interne AnythingLLM (SQLite par défaut ; Postgres pour l'auto-hébergement multi-utilisateurs). Les documents sont ingérés via l'UI ; les originaux peuvent rester dans un dossier que vous mirroirisez.
- Capture : upload in-app (glisser des PDF / fichiers dans un workspace), extension navigateur pour les pages web, API publique pour l'ingestion programmatique (
POST /api/v1/document/upload), redirection e-mail via l'intégration officielle ou un relais sur mesure. - Embeddings : AnythingLLM utilise le fournisseur d'embeddings que vous configurez — choisissez « Ollama » → endpoint
http://localhost:11434→ modèlenomic-embed-text. Embeddings stockés dans le vector store intégré (LanceDB par défaut ; ChromaDB / Pinecone optionnels). - Récupération : RAG sur le workspace. Taille de chunk configurable, récupération top-k, re-ranking optionnel. Plusieurs workspaces permettent de partitionner par sujet (ex. « Travail », « Lecture », « Projets »).
- Interface : UI web AnythingLLM (fonctionne dans les navigateurs bureau et mobiles), API publique pour des front-ends sur mesure, endpoint compatible OpenAI pour brancher d'autres outils sur votre PKB.
- Temps d'installation : ~15 min (installer AnythingLLM Desktop ou Docker, le pointer sur Ollama, glisser les documents).
- Matériel : 16 Go de RAM minimum. 32 Go recommandés au-delà de 10 000 documents. AnythingLLM est plus économe en mémoire qu'Obsidian + plugins à nombre d'éléments égal, parce qu'il y a un seul processus au lieu de deux.
- Plafond d'éléments : ~100 000 documents dans un seul workspace ; partitionnez en plusieurs workspaces au-delà de 50K pour garder la latence de récupération sous ~1 sec.
- Idéal pour : utilisateurs avec archives riches en PDF, capture orientée web clipping, et préférence pour une seule application plutôt qu'un stack de plugins. Aussi le bon choix pour les petites équipes auto-hébergeant une PKB partagée.
- Pas pour : utilisateurs voulant une surface d'écriture orientée notes (Obsidian) ; utilisateurs voulant posséder leur stockage en Markdown clair (le vector store d'AnythingLLM est interne).
💡Tip: Pour la mise en place pas-à-pas de la couche RAG utilisée ici (Ollama + AnythingLLM, ingestion, réglage du chunking), voir le tutoriel RAG local sur vos PDF en 30 minutes. Pour mettre à l'échelle au-delà des exemples jouets jusqu'à 1 000+ PDF, voir Chatter avec 1000+ PDF localement.
Architecture C : Python + ChromaDB sur mesure
Un stack Python + ChromaDB + Ollama sur mesure n'est le bon choix que si vous avez véritablement 100 000+ éléments, des besoins multi-utilisateurs ou des contraintes de schéma que les outils prêts à l'emploi ne peuvent modéliser. Le coût de maintenance est réel : chunking, déduplication, re-ranking, sync, sauvegarde — vous portez tout.
Ingestion ChromaDB (esquisse Python)
“import chromadb, ollama, pathlib client = chromadb.PersistentClient(path="./chroma") coll = client.get_or_create_collection("kb") for p in pathlib.Path("vault").rglob("*.md"): text = p.read_text() emb = ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"] coll.upsert(ids=[str(p)], embeddings=[emb], documents=[text], metadatas=[{"source": str(p)}])”
Requête avec re-ranking (esquisse)
“q = "What did I write about local RAG sync?" q_emb = ollama.embeddings(model="nomic-embed-text", prompt=q)["embedding"] hits = coll.query(query_embeddings=[q_emb], n_results=20) # pass hits["documents"] through a re-ranker, keep top 5 # send top 5 + question to Llama 3.2 3B via Ollama chat endpoint”
- Stockage : système de fichiers (un dossier par source :
notes/,pdfs/,web/,email/) + un manifeste de métadonnées (SQLite ou JSONL). Les fichiers source restent dans des formats ouverts pour pouvoir changer la couche de récupération sans tout réingérer. - Capture : scripts déclenchés par webhooks (web clipper → endpoint HTTP → écriture fichier), redirection e-mail → poller IMAP → écriture fichier, partage mobile → endpoint Tailscale → écriture fichier. Chaque chemin de capture est un petit service Python.
- Embeddings : ChromaDB (mode local, persistant sur disque) + embeddings Ollama via l'endpoint compatible OpenAI. Réembedding au changement de fichier via un processus watchdog. ChromaDB monte jusqu'à des millions de vecteurs sur une seule machine avec indexation HNSW.
- Récupération : similarité top-k ChromaDB + un re-ranker (BGE Re-ranker ou équivalent Cohere local) + filtres de métadonnées (intervalle de dates, tags, source). Recherche hybride optionnelle avec BM25 sur les chunks pour le matching de termes exacts.
- Interface : au choix : un petit service FastAPI exposant un endpoint
/v1/chat/completionscompatible OpenAI, une UI Streamlit / Gradio, un CLI, ou les trois. Mettez Open WebUI en façade pour une expérience chat soignée sans écrire de code UI. - Temps d'installation : ~1 jour pour une v1 fonctionnelle ; ~2 semaines d'itération pour régler chunking, qualité de récupération et pipelines de capture sur vos données.
- Matériel : portable 32 Go de RAM pour le développement ; serveur domestique 64 Go de RAM au-delà de 100 000 éléments pour que le service d'embedding ne concurrence pas votre portable. GPU dédié (RTX 4060 ou mieux) au-delà de 500K éléments pour le débit chat.
- Plafond d'éléments : 1 M+ éléments en pratique avec HNSW + sharding ; le goulot d'étranglement passe de la récupération à la fiabilité du pipeline de capture et au coût de réembedding lors des changements de schéma.
- Idéal pour : ingénieurs voulant posséder le stack, équipes avec un schéma sur mesure (ex. « chaque élément a un score de confiance, une source et un auteur ») ou utilisateurs qui atteignent les limites dures d'Obsidian ou AnythingLLM (50K et 100K respectivement).
- Pas pour : non-ingénieurs ; toute personne sous-estimant le coût de maintenance ; utilisateurs dont le cas d'usage est déjà couvert par une option clé en main.
⚠️Warning: Le mode d'échec le plus courant des projets sur mesure : réembedder toute l'archive à chaque changement de code parce que le schéma n'est pas stable. Verrouillez le modèle d'embedding et la taille de chunk avant d'ingérer plus de ~5 000 éléments. Migrer de nomic-embed-text 768-dim vers mxbai-embed-large 1024-dim à 100K éléments coûte des heures de calcul et casse la collection ChromaDB — vous ne pouvez pas mélanger les dimensions.
Pipeline de capture : web, e-mail, mobile, vocal
La couche de capture détermine la survie de votre PKB au quotidien. La plupart des connaissances arrivent en dehors du bureau — sur mobile, en e-mail, en notes vocales — et un pipeline de capture qui exige d'ouvrir d'abord une application bureau est un pipeline contourné. Construisez pour les quatre flux principaux et acceptez que 80 % des éléments arrivent sur mobile.
- Web clipper (bureau + mobile) : Obsidian Web Clipper, extension navigateur AnythingLLM, ou un bookmarklet sur mesure qui POSTe la page courante vers votre endpoint de capture. Partage mobile → extension web clipper → vault.
- Redirection e-mail : adresse dédiée (ex.
kb@votre-domaine.fr) + poller IMAP → écriture fichier. Transférez les e-mails que vous voulez garder ; le poller gère l'ingestion. Utilisez un préfixe par source dans le nom de fichier pour permettre le filtrage par source à la récupération. - Partage mobile : le chemin de capture le plus utilisé. Partage iOS → Obsidian (écrit un fichier Markdown), Partage iOS → Working Copy (commit Git), Partage iOS → Shortcut sur mesure (POST vers votre API de capture). Android : HTTP Shortcuts ou Tasker.
- Notes vocales : la capture style AudioPen devient courante en 2026. Enregistrer sur le téléphone → transcrire localement avec Whisper.cpp ou via un service Whisper auto-hébergé → écrire la transcription en Markdown → embedder.
- Copier-coller manuel : le repli. Marche toujours, ne monte jamais. À utiliser pour la traîne longue.
- OCR de captures d'écran : les captures d'écran sont un format de capture lossy. Utilisez Apple Live Text sur iOS ou un pipeline OCR local (Tesseract, Apple Vision, EasyOCR) pour extraire le texte + écrire un fichier Markdown contenant l'image et le texte OCR.
💡Tip: Auditez vos habitudes de capture existantes avant de concevoir le pipeline. Regardez ce que vous sauvegardez déjà : signets navigateur, captures d'écran, e-mails transférés, notes vocales. La couche de capture PKB doit refléter ces flux existants — si vous prenez déjà des captures d'écran constamment, construisez le chemin OCR ; si vous transférez déjà des e-mails à vous-même, construisez la redirection e-mail. Ajouter de nouvelles habitudes (« désormais je copie-colle manuellement chaque article dans la KB ») ne marche jamais.
Capture mobile : iOS Shortcuts, Working Copy, a-Shell
iOS dispose de trois chemins de capture viables vers une PKB IA locale en 2026 : Shortcuts → Obsidian, Shortcuts → Working Copy (Git) ou Shortcuts → a-Shell (piloté par script). Chacun correspond naturellement à l'une des trois architectures de référence. Choisissez le chemin dont le modèle de sync correspond à votre architecture globale.
- Shortcuts → Obsidian (Obsidian-centré) : le Shortcut Obsidian « Ajouter à la note » écrit le contenu capturé directement dans le vault. Sync via Obsidian Sync (payant, recommandé) ou iCloud Drive (gratuit, avec restrictions). Idéal pour les workflows orientés notes.
- Shortcuts → Working Copy (Git) : le contenu capturé est écrit dans un dépôt Working Copy sur l'iPhone, puis automatiquement committé et poussé. Le bureau pull. Gratuit, robuste, fonctionne avec n'importe quel vault Markdown. Note : Working Copy est payant (env. 22 € en achat unique). Idéal pour les vaults sync via Git.
- Shortcuts → a-Shell : a-Shell est un terminal iOS gratuit qui exécute des scripts. Construisez un Shortcut qui passe le texte capturé à un script a-Shell, qui écrit un fichier puis soit committe via
git, soit synchronise viarsyncsur Tailscale, soit upload vers votre endpoint de capture. Idéal pour les architectures sur mesure construites par des ingénieurs. - Équivalents Android : Tasker + Termux + Git en pendant du chemin Working Copy iOS. HTTP Shortcuts pour le chemin endpoint sur mesure. Partage mobile Obsidian pour le chemin Obsidian.
- Budget de latence : la capture mobile doit s'achever de bout en bout en moins de 5 secondes (partage → fichier écrit / committé / uploadé). Plus lent et l'utilisateur ouvre l'application une fois et plus jamais.
- Capture hors ligne : les trois chemins iOS bufferisent hors ligne (Shortcuts bufferise, Working Copy bufferise les commits, les scripts a-Shell peuvent écrire localement et synchroniser plus tard). Essentiel pour la capture en avion, dans les transports et en zones rurales.
⚠️Warning: Ne construisez pas un chemin de capture mobile qui exige que le bureau soit en ligne (ex. POST vers un endpoint protégé Tailscale, joignable seulement quand votre portable est éveillé). Vous perdrez des captures pendant les réunions, le veille du portable et la nuit. Faites tourner l'endpoint de capture soit sur un serveur domestique / NAS toujours actif, soit écrivez vers un store eventually-consistent (Obsidian Sync, Git, iCloud) qui bufferise hors ligne.
Mise à l'échelle : 1K, 10K, 100K éléments
La mise à l'échelle d'une PKB IA locale a trois régimes : sous 1 000 éléments, tout est rapide sur n'importe quel portable moderne ; entre 1 000 et 10 000, l'index d'embeddings devient un artefact réel à gérer ; au-delà de 10 000 éléments, le matériel devient le goulot d'étranglement et la fiabilité du pipeline de capture domine les résultats. Les valeurs réalistes ci-dessous supposent un Mac M3 Pro / PC RTX 4060 avec nomic-embed-text et Llama 3.2 3B.
| Nombre d'éléments | Architecture recommandée | Embedding initial | Matériel | Notes |
|---|---|---|---|---|
| 1 000 éléments | L'une des trois | ~2 min | Portable 16 Go de RAM | Tout paraît instantané. Le choix d'architecture dépend purement de l'adéquation au workflow. |
| 10 000 éléments | Obsidian ou AnythingLLM | ~25 min | Portable 16 Go (32 Go recommandés) | Index d'embeddings ~150–250 Mo. Réembedding sub-seconde aux modifications. Sweet spot pour la plupart des travailleurs du savoir. |
| 50 000 éléments | AnythingLLM ou Python sur mesure | ~3 heures | Portable 32 Go ou serveur domestique | L'index initial tourne la nuit. Prévoir des sous-vaults / workspaces au-delà. ~1.5–2 Go pour les embeddings. |
| 100 000 éléments | AnythingLLM (multi-workspace) ou Python sur mesure | 6–8 heures | Minimum 32 Go ; serveur domestique préféré | Déplacer les embeddings vers un serveur domestique dédié. La fiabilité du pipeline de capture devient le mode d'échec primaire, pas la récupération. |
| 500 000+ éléments | Python + ChromaDB sur mesure | 24+ heures | Serveur domestique 64 Go + GPU dédié | Sharding, déduplication et pipelines de réembedding incrémental deviennent nécessaires. Les outils clé en main ne suffisent plus. |
💡Tip: Le coût d'embedding initial est une facture unique. Après le premier index, seuls les éléments modifiés sont réembeddés — généralement sous une seconde par sauvegarde, même à 100K éléments. La lenteur de la première fois est réelle mais non récurrente. Faites tourner l'index initial la nuit sur une machine branchée et oubliez-le.
Sauvegarde, versioning, sync multi-appareils
Une PKB IA locale a besoin de trois couches de sauvegarde : snapshots du vault (Time Machine, Backblaze, restic), historique Git du contenu en clair et un export trimestriel des embeddings et métadonnées comme chemin de reconstruction propre. Les embeddings sont techniquement régénérables, mais à 100K+ éléments la régénération coûte des heures — sauvegardez-les aussi.
- Snapshots du vault (système de fichiers) : Time Machine (macOS) ou restic (Linux) toutes les 24 heures. Backblaze ou rsync.net pour le hors-site. Capture tout, embeddings inclus.
- Historique Git (contenu uniquement) : fichiers Markdown clairs committés vers un dépôt Git (local + GitHub / Gitea privé). Ajoutez
.smart-env/,vector_store/et tout autre dossier d'index binaire à.gitignore. Git vous donne l'historique par note ; les snapshots du vault donnent le rollback global. - Export d'embeddings (trimestriel) : exportez le vector store dans un format portable (ChromaDB → parquet, Smart Connections → JSON dump, AnythingLLM → export intégré). Gardez les deux derniers exports hors-site. Si un snapshot du vault échoue ou si l'index d'embeddings se corrompt, c'est votre chemin de reconstruction rapide.
- Sync multi-appareils — Obsidian-centré : Obsidian Sync gère proprement texte clair + index binaires (chiffré de bout en bout). iCloud Drive marche pour le clair mais corrompt les index binaires entre plateformes. Git via Working Copy / Termux marche pour le clair seulement — réindexer par appareil.
- Sync multi-appareils — AnythingLLM-centré : faites tourner AnythingLLM en conteneur Docker auto-hébergé sur un serveur domestique. Tous les appareils se connectent à la même instance via LAN ou Tailscale. Pas de sync côté client.
- Sync multi-appareils — Python sur mesure : l'architecture que vous construisez le détermine. La plupart des projets utilisent un service API central (FastAPI sur un serveur domestique) + clients qui POSTent les captures et GETent les requêtes. Tailscale fournit la couche réseau.
- Migration vers une nouvelle machine : restaurer le snapshot du vault → restaurer le dépôt Git → relancer Ollama → relancer l'indexeur d'embeddings. La régénération d'embeddings est automatique si vous avez sauté l'export ; réindexation manuelle si vous l'avez sauvegardé mais que le format est spécifique à la plateforme.
- Partage sélectif : pour partager des parties d'un vault (ex. un projet de recherche avec des co-auteurs), utilisez des sous-vaults ou un script d'export par tags. Ne partagez pas tout le vault — la plupart des PKB IA locales accumulent des éléments sensibles (médicaux, financiers, personnels) qui ne doivent jamais quitter le stack local.
💡Tip: Testez votre restauration une fois par trimestre. La plupart des affirmations « j'ai des sauvegardes » sont des vœux pieux — le test est « puis-je restaurer mon vault sur un portable neuf en moins de 2 heures ? » Faites le test. La première fois, vous découvrirez qu'une des trois couches (snapshot, Git, export d'embeddings) était mal configurée depuis six mois.
Erreurs courantes
- Concevoir la couche de récupération avant la couche de capture. Une recherche hybride sur mesure avec re-ranking est gaspillée sur un vault de 47 éléments. Construisez d'abord la capture, acceptez le top-5 naïf, et n'optimisez la récupération que lorsque le vault dépasse 1 000 éléments et que vous pouvez mesurer la qualité sur de vraies requêtes.
- Mélanger les architectures. « Obsidian pour les notes + AnythingLLM pour les PDF + Python sur mesure pour les e-mails » paraît propre mais le coût d'intégration domine. Choisissez une architecture, acceptez ses limites, et n'ajoutez qu'un seul connecteur si vraiment nécessaire (ex. AnythingLLM ingérant en lecture seule un dossier de vault Obsidian).
- Changer de modèle d'embedding sans réembedder l'archive. Mélanger des vecteurs nomic-embed-text 768-dim et mxbai-embed-large 1024-dim dans le même store casse silencieusement la récupération. Choisissez un modèle d'embedding + dimension, verrouillez-le, et ne changez qu'avec un réembedding complet de l'archive.
- Ignorer la sauvegarde de l'index d'embeddings au-delà de 10 000 éléments. « Je peux le régénérer » est vrai mais la régénération prend des heures. Intégrez le store d'embeddings à votre stratégie de sauvegarde au-delà de 10K éléments.
- Concevoir pour le bureau alors que 80 % de la capture se fait sur mobile. Une PKB sans chemin de capture mobile reste inutilisée. Testez le flux de capture mobile dès le premier jour — le partage vers le vault doit s'achever en moins de 5 secondes.
- Compter sur iCloud Drive pour les index d'embeddings binaires. iCloud gère le clair correctement ; les index binaires (Smart Connections
.smart-env/, vector store AnythingLLM) se corrompent entre plateformes. Utilisez Obsidian Sync, une instance auto-hébergée, ou acceptez la réindexation par appareil. - Ne pas partitionner à 100K éléments. Un seul workspace / vault au-delà de 100K éléments a une latence de récupération de l'ordre de la seconde. Partitionnez par sujet (Travail, Lecture, Projets) en plusieurs workspaces ou sous-vaults ; interrogez chacun séparément ou via un routeur.
- Sous-estimer les enjeux de conformité. Les bases personnelles accumulent inévitablement des données sensibles (correspondances de clients, patients, collègues, notes financières et médicales). La CNIL recommande explicitement les solutions IA locales pour le traitement de données professionnelles sensibles (médical, financier, juridique) — l'inférence locale élimine le besoin de contractualiser un sous-traitant tiers, simplifiant la conformité.
Sources
- Obsidian — obsidian.md et help.obsidian.md (structure des vaults, architecture de sync mobile, documentation des plugins).
- AnythingLLM — github.com/Mintplex-Labs/anything-llm (application RAG open-source auto-hébergée).
- Ollama — ollama.com et github.com/ollama/ollama (runtime LLM local ; endpoints chat + embedding).
- ChromaDB — trychroma.com et github.com/chroma-core/chroma (base vectorielle locale open-source).
- Working Copy — workingcopy.app (client Git iOS pour les pipelines de capture mobile).
- a-Shell — holzschu.github.io/a-Shell_iOS/ (terminal iOS gratuit pour la capture mobile pilotée par script).
FAQ
Comment capturer des pages web dans ma base de connaissances ?
Trois options classées par friction. (1) Web clipper en extension navigateur — Obsidian Web Clipper ou extension AnythingLLM écrit la page courante directement dans votre vault / workspace. (2) Partage mobile — partager Safari / Chrome → Obsidian (écrit un fichier Markdown) ou → Working Copy (commit Git) ou → Shortcut sur mesure (POST vers votre API de capture). (3) Bookmarklet — pour les navigateurs sans extension ; POSTe l'URL courante + sélection vers votre endpoint de capture. Le partage mobile est en pratique le chemin le plus utilisé — concevez-le en premier.
Puis-je transférer des e-mails dans le système ?
Oui. Configurez une adresse dédiée (ex. un alias Fastmail / Migadu kb@votre-domaine.fr) et faites tourner sur votre serveur domestique ou portable un poller IMAP qui télécharge les nouveaux e-mails et écrit un fichier Markdown par e-mail dans votre vault. Utilisez un préfixe d'adresse expéditrice dans le nom de fichier pour permettre le filtrage par expéditeur. AnythingLLM a une intégration e-mail native ; les utilisateurs Obsidian construisent typiquement le poller IMAP eux-mêmes ou utilisent des alternatives à IFTTT / Zapier comme n8n.
Comment synchroniser bureau et mobile ?
Cela dépend de l'architecture. Obsidian-centré : Obsidian Sync (payant, gère proprement les index binaires), iCloud Drive (gratuit, clair seulement — réindexer par appareil) ou Git via Working Copy (gratuit + paiement unique Working Copy, clair seulement — réindexer par appareil). AnythingLLM-centré : faites tourner AnythingLLM en Docker sur un serveur domestique, tous les appareils se connectent via LAN ou Tailscale — pas de sync côté client. Python sur mesure : construisez un service API central sur un serveur domestique ; les clients POSTent les captures et GETent les requêtes.
Faut-il un grand vault ou plusieurs par sujet ?
Un seul vault jusqu'à ~50 000 éléments. Au-delà de 50K, séparez par sujet (Travail, Lecture, Projets, Personnel) pour deux raisons : la latence de récupération reste sous ~1 sec, et les fuites involontaires entre contextes (ex. notes personnelles apparaissant dans des requêtes pro) deviennent possibles à grande échelle. Séparer plus tôt que 50K est prématuré — vous perdez les connexions cross-domaine fortuites qui sont une valeur principale d'une PKB.
À quelle fréquence faut-il réembedder pour la précision ?
Jamais pour cause de « dérive de précision » — les embeddings ne se dégradent pas. Réembeddez seulement quand vous changez de modèle d'embedding (ex. mise à niveau de nomic-embed-text vers mxbai-embed-large pour une meilleure récupération sur du contenu technique). Les trois architectures gèrent automatiquement le réembedding incrémental aux changements de fichiers ; vous ne le planifiez pas. L'exception : les stacks Python sur mesure où vous contrôlez l'indexeur — là, le réembedding incrémental piloté par watchdog à la sauvegarde est la norme.
Puis-je mettre ma base de connaissances sous contrôle de version ?
Oui pour le contenu en clair (vault Markdown → dépôt Git, local + GitHub / Gitea privé). Ajoutez les dossiers d'index binaires (.smart-env/, vector_store/, répertoire de persistance ChromaDB) à .gitignore — ils gonflent l'historique et provoquent des conflits de merge. Git donne l'historique par note ; les snapshots du vault (Time Machine, restic) donnent le rollback global. Les deux couches, pas l'une ou l'autre.
Comment gérer les PDF dans ce système ?
Obsidian-centré : stockez les PDF à côté des notes Markdown ; Smart Connections n'embedde pas le contenu PDF directement — extrayez d'abord le texte (ex. via le plugin PDF++ ou un script de prétraitement écrivant un résumé Markdown à côté de chaque PDF). AnythingLLM-centré : glissez les PDF directement dans un workspace ; AnythingLLM gère parsing PDF et chunking automatiquement. Python sur mesure : utilisez pypdf ou pdfplumber pour extraire le texte dans votre pipeline d'ingestion, puis embeddez le texte extrait. AnythingLLM est l'option avec le moins de friction pour les archives riches en PDF.
Puis-je partager des parties de ma KB de manière sélective ?
Oui, mais concevez-le dès le premier jour. Utilisez des sous-vaults (Obsidian) ou des workspaces (AnythingLLM) pour garder les contenus « partageables » et « privés » dans des stores séparés. Pour un partage ponctuel, construisez un script d'export par tags qui extrait les éléments par tag (ex. #shareable) dans un bundle Markdown portable. Ne partagez pas tout le vault — la plupart des PKB IA locales accumulent des éléments sensibles (médicaux, financiers, correspondance personnelle) qui ne doivent jamais quitter le stack local.
Quelle est la meilleure stratégie de sauvegarde ?
Trois couches : (1) snapshot système de fichiers toutes les 24 heures (Time Machine / restic) avec copie hors-site (Backblaze / rsync.net) ; (2) historique Git du contenu en clair pour la récupération par note ; (3) export trimestriel des embeddings + métadonnées comme chemin de reconstruction rapide. Testez la restauration une fois par trimestre — « puis-je reconstruire mon vault sur un portable neuf en moins de 2 heures ? » Le premier test révèle généralement qu'une des trois couches était mal configurée.
Comment migrer vers un nouvel ordinateur ?
Restaurer le snapshot du vault → installer Ollama et télécharger les mêmes modèles → installer Obsidian / AnythingLLM / votre stack Python sur mesure → relancer l'indexeur d'embeddings. Avec Obsidian Sync ou un AnythingLLM auto-hébergé, la migration se résume à « installer le client et se connecter » — pas de restauration manuelle. Sans cela, prévoyez ~30 min pour un vault de 10K éléments, ~2 heures pour 50K, et la nuit au-delà de 100K si vous avez sauté l'étape d'export d'embeddings.