RAG local avec Qdrant et Ollama : étude de cas à Dijon

Ce que cet article présente :

La solution permet de répondre à des questions en langage naturel tout en affichant systématiquement les sources documentaires utilisées, garantissant une traçabilité essentielle pour les procédures techniques ou les contenus critiques.
Les contraintes clés incluaient l’absence de Docker pour Qdrant, la limitation des accès réseau (127.0.0.1), et une validation humaine obligatoire avant toute publication ou action automatisée via WordPress ou d’autres outils.
Bien que performante pour centraliser et sécuriser les connaissances internes, cette approche exige une maintenance accrue (sauvegardes, mises à jour, supervision) et des tests rigoureux sur la qualité des documents indexés.

Les entreprises accumulent des procédures, documentations techniques, contenus éditoriaux et informations métier, mais les retrouver rapidement devient difficile lorsqu’ils sont répartis entre plusieurs dossiers et applications. Dans le cadre de son infrastructure interne à Dijon, Internet Creative Center a conçu un système RAG local capable d’interroger une base documentaire privée avant de produire une réponse avec un modèle d’intelligence artificielle. Le projet associe Ollama, Qdrant, Python, Streamlit et n8n, sans dépendre d’une plateforme publique pour le traitement principal des documents. Cette étude présente le contexte, les contraintes, l’architecture retenue, les étapes de déploiement et les résultats obtenus.

Ce démonstrateur constitue également l’une des briques techniques utilisées par notre agence IA à Dijon pour étudier des projets d’assistants documentaires, d’automatisation et de recherche privée.

Comment déployer un RAG local fiable tout en conservant la maîtrise des données de l’entreprise ?

Contexte et problème : exploiter les connaissances internes sans les exposer

Fiche synthétique de l’étude de cas

Nature du projet : plateforme RAG locale et privée ;
Organisation : Internet Creative Center ;
Localisation : Dijon, Côte-d’Or ;
Environnement : serveur Ubuntu administré en interne ;
Date de mise à jour : 4 août 2026 ;
Auteur : Internet Creative Center — Bureau de Dijon.

Un volume croissant de connaissances difficile à exploiter

Internet Creative Center utilise de nombreux documents liés au développement Web, à WordPress, aux serveurs Linux, à la cybersécurité, à l’intelligence artificielle et aux procédures internes. Ces informations peuvent prendre la forme de fichiers texte, de documents bureautiques, de contenus Markdown, de pages Web ou de documentations techniques.

Une recherche classique par nom de fichier ou par mot-clé atteint rapidement ses limites. Une procédure peut utiliser une formulation différente de la question posée par l’utilisateur. Une information pertinente peut également se trouver au milieu d’un document long, sans apparaître dans son titre.

L’objectif était donc de créer une interface capable de recevoir une question en langage naturel, de retrouver les passages réellement pertinents dans les documents autorisés, puis de demander à un modèle local de produire une réponse à partir de ces seuls éléments.

Éviter les réponses générales ou non vérifiables

Un modèle de langage utilisé seul répond à partir de ses connaissances d’entraînement. Il peut fournir une réponse générale, ancienne ou inadaptée à l’environnement réel de l’entreprise. Il peut également compléter une information absente en produisant une formulation vraisemblable mais incorrecte.

Pour un usage professionnel, la réponse devait donc être reliée à des sources identifiables. Le système devait indiquer les documents et les passages utilisés, afin que l’utilisateur puisse vérifier l’information avant de l’appliquer.

Cette exigence est particulièrement importante pour les procédures techniques. Une commande adaptée à une distribution Linux, à une version de logiciel ou à une architecture donnée peut être incorrecte dans un autre environnement.

Conserver les données dans une infrastructure maîtrisée

Les documents indexés peuvent contenir des configurations, des procédures internes, des informations relatives à des sites Web ou des éléments qui n’ont pas vocation à être transmis à un service public d’intelligence artificielle.

Le traitement principal devait donc être réalisé dans l’infrastructure locale. Cette orientation n’exclut pas l’utilisation ponctuelle de services externes pour des contenus publics, mais elle permet de conserver les documents privés, les embeddings et les recherches vectorielles dans un environnement administré par Internet Creative Center.

Le choix entre une plateforme hébergée et une architecture privée dépend toujours de la nature des informations. Notre article consacré à
l’IA locale et à ChatGPT pour les données confidentielles
présente plus précisément ces différences.

Respecter plusieurs contraintes techniques

L’architecture devait s’intégrer à un serveur Ubuntu déjà utilisé pour différents services d’intelligence artificielle. Plusieurs contraintes ont été retenues dès le départ :

ne pas utiliser Docker pour le serveur Qdrant ;
installer Qdrant comme un service natif indépendant ;
isoler l’application Python dans un environnement virtuel ;
utiliser l’instance Ollama déjà opérationnelle ;
limiter l’exposition des services techniques au réseau ;
permettre la création de plusieurs collections documentaires ;
conserver les sources utilisées dans les réponses ;
prévoir une validation humaine avant toute publication WordPress ;
rendre l’architecture évolutive sans remplacer les composants existants.

Le projet ne devait pas se limiter à une démonstration. Il devait pouvoir être redémarré automatiquement, supervisé, sauvegardé et intégré progressivement à d’autres workflows.

Architecture et actions : construire le pipeline RAG local

Installer Qdrant comme service natif

Qdrant a été installé directement sur le serveur Ubuntu et configuré comme un service systemd. Ce choix permet de gérer son démarrage, son arrêt et son redémarrage avec les outils habituels du système.

L’API HTTP de Qdrant écoute sur le port 6333 et son interface gRPC sur le port 6334. Les services ont été limités à l’adresse locale 127.0.0.1, afin de ne pas exposer directement la base vectorielle sur Internet.

Les données persistantes sont conservées dans :

/var/lib/qdrant/storage

Le mode cluster n’était pas nécessaire pour ce projet et a été désactivé. Cette configuration correspond à un serveur unique, administré localement, avec un volume de documents compatible avec les ressources disponibles.

Isoler l’application Python

Le moteur d’indexation et l’application ont été placés dans un environnement virtuel Python. Cette isolation évite de mélanger leurs bibliothèques avec les paquets du système Ubuntu ou avec d’autres projets présents sur le serveur.

Le code Python prend en charge plusieurs étapes :

lecture des fichiers autorisés ;
nettoyage du contenu ;
découpage des documents en passages ;
création des embeddings avec Ollama ;
enregistrement des vecteurs et métadonnées dans Qdrant ;
recherche des passages proches de la question ;
construction du contexte transmis au modèle ;
production de la réponse et affichage des sources.

Créer les embeddings avec Ollama

Ollama était déjà installé et fonctionnel sur le serveur. Il permet d’exécuter localement le modèle de langage utilisé pour la rédaction des réponses, ainsi que le modèle chargé de produire les embeddings.

Le modèle de génération retenu dans l’environnement de test était notamment gemma4:12b-it-qat. Un modèle d’embedding dédié a été prévu afin de transformer les passages documentaires et les questions en vecteurs comparables.

Il est essentiel d’utiliser le même modèle d’embedding lors de l’indexation et lors des recherches. Un changement de modèle impose généralement de recalculer les vecteurs de la collection concernée.

Structurer les collections Qdrant

Une première collection, nommée documentation_locale, a servi de base au projet. L’architecture permet ensuite de créer plusieurs collections selon les sources ou les usages.

Cette séparation évite de mélanger des documents sans rapport et facilite l’application de règles différentes. Une collection peut être consacrée à la documentation technique, une autre à des connaissances Web contrôlées, une autre aux contenus d’un site WordPress ou à un domaine métier particulier.

Chaque passage enregistré dans Qdrant contient son vecteur et des métadonnées utiles, par exemple :

le nom du fichier ou l’URL d’origine ;
le type de document ;
la collection d’appartenance ;
la date d’indexation ou de modification ;
le titre du contenu ;
le numéro ou l’identifiant du passage ;
les informations nécessaires au contrôle des accès.

Mettre en place l’interface Streamlit

Une interface Streamlit accessible sur le port 8501 permet de piloter la plateforme sans utiliser directement les API techniques.

L’utilisateur peut sélectionner une collection, poser une question, consulter la réponse et vérifier les sources retrouvées. Cette interface a ensuite été étendue à d’autres fonctions : indexation de documents, choix du modèle Ollama, suivi des traitements et préparation de contenus structurés.

L’interface ne publie pas automatiquement les résultats. Elle sert également de point de contrôle avant l’exécution d’une action ou l’envoi d’un contenu vers WordPress.

Utiliser n8n comme orchestrateur

n8n a été retenu pour planifier et déclencher certains scénarios. L’orchestrateur peut détecter l’arrivée de nouveaux documents, lancer une route de l’application RAG, récupérer un résultat ou exécuter une tâche à intervalle défini.

Le pipeline principal reste réalisé en Python. n8n joue le rôle de coordinateur : il déclenche les traitements validés, sans dupliquer toute la logique d’indexation et de génération dans chaque workflow.

Cette organisation facilite la maintenance. Une correction apportée au moteur Python bénéficie à l’ensemble des scénarios qui l’utilisent.

Préparer l’intégration WordPress

La plateforme a ensuite été reliée à un flux éditorial WordPress. Les informations retrouvées dans Qdrant peuvent alimenter la préparation d’un article, structuré selon les dix champs utilisés sur le site :

problematique ;
introduction ;
titre1 ;
texte1 ;
titre2 ;
texte2 ;
titre3 ;
texte3 ;
conclusion ;
extrait.

La création dans WordPress est réalisée exclusivement sous la forme d’un brouillon. Une personne vérifie les sources, la cohérence des différentes parties, les liens, les images et la mise en forme avant publication.

Le même environnement peut être relié à ComfyUI pour préparer des visuels, mais la génération d’images reste une étape distincte du fonctionnement du RAG.

Le coût d’une telle plateforme dépend du volume documentaire, des interfaces et du niveau d’automatisation. Ces postes sont détaillés dans notre analyse du budget nécessaire pour automatiser une entreprise avec l’IA.

Résultats, sécurité et enseignements du déploiement

Une recherche documentaire unifiée

Le premier résultat du projet est la création d’un point d’accès commun à des documents qui étaient auparavant consultés séparément. L’utilisateur n’a plus besoin de connaître exactement le nom du fichier ni le dossier dans lequel l’information est enregistrée.

La recherche vectorielle permet de rapprocher une question d’un passage exprimant la même idée avec des termes différents. Cette méthode améliore la découverte d’informations, à condition que les documents soient correctement nettoyés, découpés et décrits.

Des réponses accompagnées de leurs sources

La réponse du modèle est construite à partir des passages récupérés dans Qdrant. L’interface affiche les sources utilisées afin que l’utilisateur puisse contrôler le résultat.

Cette traçabilité ne supprime pas le risque d’erreur. Le modèle peut encore mal interpréter un extrait ou rapprocher des passages contradictoires. Elle rend toutefois la vérification beaucoup plus rapide qu’avec une réponse produite sans référence documentaire.

Une meilleure maîtrise des données

Les documents, les vecteurs et les requêtes principales restent dans l’environnement local. Qdrant n’est pas exposé directement au Web et l’application communique avec lui depuis le serveur.

Cette architecture réduit la dépendance à une plateforme publique, mais elle transfère également davantage de responsabilités à l’organisation :

administration du serveur ;
gestion des comptes et des droits ;
application des mises à jour ;
sauvegarde des collections et des documents originaux ;
surveillance de l’espace disque et de la mémoire ;
protection des interfaces ;
journalisation des erreurs et des opérations importantes.

Une architecture réutilisable

Le découpage entre Ollama, Qdrant, Python, Streamlit et n8n permet de faire évoluer une partie sans reconstruire l’ensemble.

Le modèle de langage peut être remplacé selon les performances attendues. Une nouvelle collection Qdrant peut être créée pour un autre domaine. L’interface peut proposer de nouveaux scénarios et n8n peut déclencher des traitements supplémentaires.

Cette modularité permet de commencer par un assistant documentaire limité, puis d’étendre progressivement le projet à la préparation de brouillons, à l’analyse de pages Web ou à l’alimentation d’une base de connaissances.

Une automatisation conservant la validation humaine

La plateforme ne prend pas seule une décision importante et ne publie pas automatiquement un contenu. Elle prépare, classe, recherche et propose. L’utilisateur conserve la validation finale.

Ce choix réduit le risque de publier une information inexacte, de dupliquer un article ou d’exécuter une action à partir d’une réponse mal interprétée.

Pour les PME qui souhaitent identifier un premier projet, plusieurs exemples sont présentés dans notre article consacré aux cas d’usage de l’IA en Bourgogne-Franche-Comté.

Les limites observées

Le RAG ne corrige pas automatiquement une documentation de mauvaise qualité. Les documents obsolètes, les menus copiés dans les pages Web, les doublons ou les textes trop courts peuvent dégrader les recherches.

La pertinence dépend également du découpage des documents, du modèle d’embedding, du nombre de passages récupérés et de la formulation du prompt. Ces paramètres doivent être testés avec des questions représentatives du travail réel.

Les performances du modèle local dépendent des ressources disponibles. Un modèle plus lourd peut produire de meilleures réponses dans certains cas, mais augmenter les temps de traitement et la consommation de mémoire. Le modèle le plus volumineux n’est donc pas systématiquement le meilleur choix.

Les enseignements à retenir

Le projet a permis de dégager plusieurs principes réutilisables :

commencer par une collection documentaire limitée et bien maîtrisée ;
conserver le document original et ses métadonnées ;
afficher les sources dans l’interface ;
tester les questions auxquelles la documentation ne répond pas ;
séparer l’indexation, la recherche et la génération ;
ne pas exposer directement Qdrant ou Ollama sur Internet ;
prévoir la réindexation lors d’un changement de modèle d’embedding ;
placer la validation humaine avant les actions sensibles ;
documenter les services, ports, chemins et procédures de redémarrage ;
mesurer les résultats avant d’élargir le périmètre.

Des résultats qualitatifs plutôt que des chiffres artificiels

À ce stade, les résultats publiables sont principalement qualitatifs : centralisation de la recherche, meilleure visibilité des sources, possibilité de séparer les connaissances par collection et réutilisation du moteur dans plusieurs workflows.

Aucun pourcentage de gain de temps ou de précision n’est avancé dans cette étude, car une mesure crédible demanderait un protocole stable : série de questions identiques, comparaison avec la méthode précédente, chronométrage et validation par plusieurs utilisateurs.

Cette phase de mesure peut être ajoutée lors du déploiement chez un client, avec des indicateurs définis avant le prototype.

Pour conclure sur : " Étude de cas : déploiement d’un RAG local avec Qdrant et Ollama "

Le déploiement de ce RAG local a permis de réunir plusieurs composants libres dans une architecture cohérente : Ollama pour l’exécution des modèles, Qdrant pour la recherche vectorielle, Python pour le pipeline, Streamlit pour l’interface et n8n pour l’orchestration.

Le choix d’une installation native sans Docker répondait aux contraintes de l’environnement existant. Qdrant fonctionne comme un service systemd indépendant, tandis que l’application Python reste isolée dans son propre environnement virtuel.

La principale valeur du système ne réside pas uniquement dans la génération d’une réponse. Elle repose sur la capacité à retrouver les passages pertinents, à afficher les sources et à conserver une validation humaine avant toute utilisation sensible ou publication WordPress.

Cette architecture peut être adaptée à une documentation technique, à des procédures internes, à un catalogue, à des supports de formation ou à une base de connaissances métier. Le périmètre, les droits d’accès et les indicateurs doivent toutefois être définis pour chaque organisation.

Internet Creative Center accompagne les PME et organisations de Dijon et de Bourgogne-Franche-Comté dans la conception de RAG privés, d’IA locales et de workflows d’automatisation.

Vous pouvez présenter votre projet depuis le formulaire de contact ou consulter notre page consacrée à l’ accompagnement IA à Dijon.

Étude de cas mise à jour le 4 août 2026 — Auteur : Internet Creative Center, bureau de Dijon.