RAG local avec Paperless, Nextcloud et emails : le guide Ollama 2026
Le besoin qui revient partout : une recherche locale qui comprend vos PDF Paperless, vos fichiers Nextcloud et vos emails, sans envoyer vos archives personnelles à un cloud. Voici l'architecture réaliste pour le faire proprement.
Verdict rapide
Open WebUI est très bien pour discuter avec des documents. Mais si votre besoin principal est une recherche locale transversale dans Paperless, Nextcloud et les emails, il faut penser comme un moteur de recherche : ingestion automatique, extraction propre, index lexical + vectoriel, citations, puis seulement ensuite LLM.
Paperless + fichiers : mini PC 32 Go, Qdrant, Ollama léger.
Nextcloud + emails + droits : PostgreSQL, Qdrant, reranker.
Hybrid search, audit trail, citations, backups, supervision.
Pourquoi ce sujet explose
Les outils RAG grand public partent souvent du chat : vous uploadez quelques fichiers, vous posez une question, ça répond. Le problème apparaît dès que les documents vivent déjà ailleurs : Paperless-ngx renomme et classe les PDF, Nextcloud synchronise des dossiers, les emails arrivent en continu, et personne ne veut réindexer à la main.
Le vrai besoin est moins spectaculaire mais beaucoup plus utile : un indexeur local qui surveille les sources, garde les permissions, évite les doublons, cite les documents, et accepte de répondre “je ne trouve pas” quand la preuve n'existe pas.
Architecture recommandée
Le point clé : ne misez pas tout sur les embeddings. Pour des factures, contrats, emails et tickets, les noms propres, dates, montants et références exactes comptent. Il faut donc une recherche hybride : lexical pour les termes exacts, vectoriel pour le sens, reranking pour classer les meilleurs passages.
Paperless-ngx : ne réinventez pas l'OCR
Paperless fait déjà une grosse partie du travail : ingestion de documents, OCR, tags, correspondants, dates, type documentaire. Le RAG ne doit pas remplacer Paperless, il doit consommer ses exports ou son API.
| À indexer | Pourquoi | Piège |
|---|---|---|
| Texte OCR | Base principale des réponses. | Qualité variable sur scans anciens. |
| Titre + tags | Excellent signal de reranking. | Tags incohérents si saisis vite. |
| Correspondant / date | Filtres utiles avant recherche. | Ne pas les perdre dans le chunking. |
| Lien document | Citation vérifiable. | Le RAG doit renvoyer vers Paperless. |
La bonne approche : stocker les métadonnées Paperless à côté de chaque chunk dans Qdrant ou PostgreSQL, puis afficher la citation avec le lien vers le document source.
Nextcloud : surveiller les fichiers sans tout rescanner
Nextcloud est souvent le vrai vrac : PDF, DOCX, images, notes, exports comptables, dossiers partagés. Le RAG doit travailler en incrémental : nouveau fichier, fichier modifié, fichier supprimé.
Simple
Un job cron scanne les dossiers toutes les heures, compare hash + date de modification, puis indexe uniquement les nouveautés.
Propre
WebDAV ou API Nextcloud, table d'état, suppression des chunks quand un fichier disparaît, respect des dossiers partagés.
Emails : indexer sans créer une machine à halluciner
Les emails sont les plus dangereux : fils de discussion, signatures, citations répétées, pièces jointes, HTML sale. Si vous indexez tout brutalement, votre IA va répéter trois fois le même vieux message.
- Dédupliquer les citations : retirer les anciens messages cités dans les réponses.
- Indexer les pièces jointes séparément : un PDF attaché n'est pas le même document que l'email.
- Garder l'expéditeur et la date : indispensables pour filtrer avant de demander au LLM.
- Limiter par boîte/dossier : commencez par factures, support, projets, pas toute la boîte.
Matériel utile pour un RAG local qui tourne vraiment
Le RAG consomme surtout disque, RAM et stabilité. Le GPU devient important quand vous voulez un modèle local rapide pour répondre.
Liens Amazon affiliés. Vérifiez le vendeur, le prix et la disponibilité sur Amazon avant achat.
Stack Docker minimale
Pour un prototype sérieux, commencez simple : Ollama, Qdrant, PostgreSQL, un indexeur Python, puis une petite interface web. Ajoutez Open WebUI ou n8n si vous voulez une interface déjà prête.
services:
ollama:
image: ollama/ollama
volumes:
- ollama:/root/.ollama
ports: ["11434:11434"]
qdrant:
image: qdrant/qdrant
volumes:
- qdrant:/qdrant/storage
ports: ["6333:6333"]
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: local-rag
volumes:
- pg:/var/lib/postgresql/data
volumes:
ollama:
qdrant:
pg:Ce qu'il faut construire en premier
1. Indexeur incrémental
C'est le cœur du produit : détecter nouveaux fichiers/emails, extraire, chunker, supprimer les vieux chunks.
2. Recherche hybride
BM25 + embeddings + rerank. Sans ça, les références exactes et les dates partent trop souvent dans le décor.
3. Citations cliquables
Une réponse sans source ne vaut rien sur des documents personnels, juridiques ou administratifs.
4. Réponse “non trouvé”
Le meilleur RAG n'est pas celui qui répond toujours. C'est celui qui sait refuser quand l'index ne contient pas la preuve.
Articles liés OutilsIA
FAQ
Open WebUI suffit-il pour Paperless et Nextcloud ?
Pour quelques documents, oui. Pour un flux vivant de fichiers, emails et métadonnées, il faut un indexeur dédié et une logique d'incrémental.
Faut-il un GPU pour un RAG local ?
Pas forcément pour indexer. Un GPU devient utile pour répondre vite avec un modèle local. Les embeddings et Qdrant peuvent démarrer sur CPU.
Qdrant, Chroma ou PostgreSQL ?
Qdrant est un bon choix pour un service dédié. Chroma est simple pour prototyper. PostgreSQL + pgvector est intéressant si vous voulez tout centraliser.