RAG signifie Retrieval-Augmented Generation, ou génération augmentée par la recherche. Au lieu de demander au modèle de répondre uniquement à partir des connaissances acquises pendant son entraînement, le système commence par rechercher des informations dans les documents autorisés de l’entreprise.
Les extraits retrouvés sont ensuite ajoutés à la consigne envoyée au modèle. Celui-ci rédige sa réponse à partir de la question de l’utilisateur et du contexte documentaire qui lui a été fourni.
Un RAG privé peut ainsi permettre à une PME de poser des questions sur :
- ses procédures internes ;
- ses notices techniques ;
- ses contrats et modèles de documents ;
- ses catalogues de produits ou de formations ;
- sa documentation commerciale ;
- ses règles de sécurité ;
- ses comptes rendus et archives autorisées.
Dans cette architecture, Ollama et Qdrant remplissent deux fonctions différentes.
Ollama exécute les modèles localement
Ollama permet d’installer et d’interroger des modèles sur un ordinateur ou un serveur local. Après son installation, son API est disponible par défaut à l’adresse http://localhost:11434/api. Elle propose notamment des fonctions de génération de texte et de création d’embeddings.
Deux types de modèles peuvent être utilisés dans un RAG :
- un modèle d’embedding, chargé de transformer les textes en vecteurs numériques ;
- un modèle de langage, chargé de comprendre la consigne et de rédiger la réponse finale.
Les embeddings représentent le sens d’un texte sous la forme d’une série de nombres. Deux passages proches par leur signification doivent produire des vecteurs proches, même s’ils n’utilisent pas exactement les mêmes mots. La documentation d’Ollama présente les embeddings comme une capacité destinée à la recherche sémantique, à la récupération d’informations et aux systèmes RAG.
Ollama propose pour cela le point d’accès /api/embed. Il accepte un texte ou une liste de textes et renvoie les vecteurs correspondants. Parmi les modèles d’embedding présentés dans sa documentation figurent notamment embeddinggemma, qwen3-embedding et all-minilm.
Le modèle de génération reçoit ensuite la question et les passages retrouvés. L’API /api/generate permet de lui transmettre un modèle, une consigne, un message système et différentes options de génération.
Qdrant organise et recherche les connaissances
Qdrant est une base de données vectorielle. Les informations y sont organisées dans des collections. Une collection contient des points, et chaque point associe un vecteur à des métadonnées facultatives appelées payload. Tous les vecteurs d’une même collection doivent respecter la dimension et la métrique définies pour celle-ci.
Dans un RAG, un point Qdrant peut correspondre à un passage extrait d’un document. Son vecteur représente le sens du passage, tandis que son payload conserve les informations nécessaires pour l’identifier.
Un payload peut, par exemple, contenir :
{ "document_id": "procedure-sauvegarde-2026", "title": "Procédure de sauvegarde", "section": "Restauration", "source": "/documents/securite/sauvegarde.pdf", "access_group": "informatique", "updated_at": "2026-07-15", "text": "Texte du passage indexé..." }
Lorsque l’utilisateur pose une question, celle-ci est transformée en vecteur avec le même modèle d’embedding que celui utilisé pour les documents. Qdrant compare ce vecteur à ceux présents dans la collection et renvoie les passages les plus proches.
Le fonctionnement général peut être résumé ainsi :
Documents de l’entreprise ↓ Extraction et nettoyage ↓ Découpage en passages ↓ Embeddings avec Ollama ↓ Vecteurs et métadonnées dans Qdrant ↓ Question de l’utilisateur ↓ Embedding de la question avec Ollama ↓ Recherche des passages dans Qdrant ↓ Question + passages envoyés au modèle Ollama ↓ Réponse accompagnée de ses sources
Le RAG comporte donc deux circuits. Le premier est un circuit d’indexation, exécuté lorsque des documents sont ajoutés ou modifiés. Le second est un circuit de recherche et de génération, exécuté à chaque question.
Cette distinction est importante. Une question ne doit pas entraîner la lecture complète de tous les documents. Le système interroge l’index vectoriel et transmet uniquement quelques passages au modèle.
Ce que signifie réellement « privé »
Le caractère privé ne dépend pas seulement de la présence d’Ollama et de Qdrant sur un serveur local. Tous les composants doivent être examinés : extraction des documents, modèle d’embedding, modèle de génération, interface, historiques, sauvegardes et outil d’automatisation.
Un système présenté comme local peut encore transmettre des données à l’extérieur si un connecteur, une fonction de télémétrie, une API ou une étape du workflow appelle un service distant.
Avant le développement, la PME doit donc établir une cartographie simple :
- où sont stockés les documents d’origine ;
- où sont créés les fichiers temporaires ;
- quel service génère les embeddings ;
- où Qdrant conserve ses données ;
- quel modèle produit la réponse ;
- où sont enregistrées les conversations ;
- quels flux réseau sortants sont autorisés.
Un RAG véritablement privé est une architecture dans laquelle l’entreprise contrôle l’ensemble de ce parcours, et pas seulement le modèle de langage.
L’installation d’Ollama, de Qdrant et de l’interface métier peut s’inscrire
dans une démarche plus globale visant àdéployer une IA locale dans une PME.











