Avancé ⏱ 30 min de mise en œuvre Mis à jour le 11 août 2026

Héberger Qdrant : une base de données vectorielle pour vos RAG et agents IA

Le RAG et les agents IA ont besoin d'une mémoire : une base vectorielle. Qdrant stocke vos embeddings et retrouve les passages pertinents. Voici comment l'héberger et l'intégrer.

Une base de données vectorielle stocke des représentations numériques appelées embeddings. Ces vecteurs décrivent le sens d’un texte, d’une image ou d’un autre contenu. Contrairement à une base classique, la recherche ne repose pas seulement sur des mots identiques : elle retrouve les éléments sémantiquement proches d’une requête.

Qdrant est une base de données vectorielle open source adaptée aux applications de RAG, aux assistants documentaires et aux agents IA dotés d’une mémoire. Elle stocke les embeddings, recherche les vecteurs similaires et filtre les résultats à partir de métadonnées. L’auto-hébergement permet de garder la maîtrise des documents, des journaux et de la politique de conservation, un enjeu important pour les projets soumis au RGPD.

Comment Qdrant intervient dans un flux RAG ?

Un système RAG, ou génération augmentée par la recherche, combine une base documentaire et un grand modèle de langage. Son fonctionnement peut être résumé ainsi :

  1. Les documents sont collectés et nettoyés.
  2. Leur contenu est découpé en passages, souvent appelés chunks.
  3. Un modèle d’embeddings transforme chaque passage en vecteur.
  4. Les vecteurs, les textes et leurs métadonnées sont stockés dans Qdrant.
  5. Lorsqu’un utilisateur pose une question, celle-ci est vectorisée avec le même modèle.
  6. Qdrant recherche les top-k passages les plus proches.
  7. Ces passages sont ajoutés au contexte transmis au LLM.
  8. Le modèle génère une réponse fondée sur les informations retrouvées.

Dans un agent IA, Qdrant peut aussi servir de mémoire à long terme. L’agent enregistre des observations, des décisions ou des résumés de conversations, puis récupère les souvenirs pertinents avant d’exécuter une nouvelle tâche.

Qdrant ne produit pas les embeddings et ne génère pas les réponses. Il constitue la couche de stockage et de recherche vectorielle entre le modèle d’embeddings et le LLM.

Pourquoi auto-héberger Qdrant ?

Un déploiement auto-hébergé donne davantage de contrôle sur l’emplacement des données, les sauvegardes, les versions et les règles d’accès. Il évite également d’envoyer automatiquement les contenus indexés vers une plateforme vectorielle tierce.

Pour un projet français, héberger Qdrant sur des serveurs situés en France facilite la construction d’une architecture cohérente avec les exigences du RGPD. TalCloud propose une infrastructure française avec stockage NVMe, protection Anti-DDoS Netrix et support humain. Ses offres VPS démarrent à 4,99 € par mois et peuvent accueillir ce type de service.

L’auto-hébergement ne dispense toutefois pas de définir une durée de conservation, de limiter les données personnelles indexées et de documenter les sous-traitants éventuellement utilisés pour produire les embeddings.

Prérequis pour déployer Qdrant

Il faut disposer des éléments suivants :

  • Un VPS Linux avec une adresse IP fixe
  • Docker et le plugin Docker Compose (voir installer Docker sur un VPS)
  • Un accès SSH administrateur
  • Un pare-feu correctement configuré
  • Un espace disque persistant, de préférence sur stockage NVMe
  • Une stratégie de sauvegarde externe au serveur

Qdrant fonctionne sans GPU. Les besoins en mémoire, en processeur et en stockage dépendent principalement du nombre de vecteurs, de leur dimension, des index utilisés et du volume de requêtes.

Créez un répertoire de déploiement, puis ajoutez un fichier compose.yaml contenant :

services:
  qdrant:
    image: qdrant/qdrant:latest
    restart: unless-stopped
    environment:
      QDRANT__SERVICE__API_KEY: "${QDRANT_API_KEY}"
    ports:
      - "127.0.0.1:6333:6333"
      - "127.0.0.1:6334:6334"
    volumes:
      - qdrant_storage:/qdrant/storage

volumes:
  qdrant_storage:

Placez la clé API dans un fichier .env protégé :

QDRANT_API_KEY=remplacez-par-une-cle-longue-et-aleatoire

Démarrez ensuite le service :

docker compose pull
docker compose up -d
docker compose ps

Le port 6333 correspond à l’API REST et le port 6334 à gRPC. Leur liaison à 127.0.0.1 empêche une exposition directe sur l’interface publique du serveur.

Évitez le tag latest en production. Après un premier test, épinglez une version précise de l’image afin de rendre les mises à jour reproductibles.

Sécuriser l’accès à Qdrant

Les ports 6333 et 6334 ne doivent pas être publiés directement sur Internet. Pour une application installée sur le même VPS, conservez l’écoute locale et communiquez avec Qdrant via 127.0.0.1. Gardez ces ports fermés au niveau du pare-feu.

Si plusieurs conteneurs partagent un réseau Docker privé, vous pouvez retirer entièrement la section ports et joindre Qdrant par son nom de service. Cette configuration réduit encore la surface d’exposition.

Un accès distant doit passer par un réseau privé, un VPN ou un reverse proxy configuré avec TLS. Le proxy peut aussi appliquer une liste d’adresses autorisées, une limitation de débit et une journalisation contrôlée.

La clé API reste nécessaire, y compris derrière un reverse proxy. Ne l’intégrez jamais dans une image Docker, un dépôt Git ou du code exécuté dans le navigateur. Utilisez un gestionnaire de secrets lorsque l’environnement de production le permet.

Créer une collection et indexer des documents

Une collection définit notamment la dimension des vecteurs et la métrique utilisée pour comparer leur proximité. La dimension doit correspondre exactement à celle du modèle d’embeddings.

Cet exemple crée une collection nommée knowledge_base avec des vecteurs de dimension 768 et une distance cosinus :

curl -X PUT "http://127.0.0.1:6333/collections/knowledge_base" \
  -H "api-key: ${QDRANT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "vectors": {
      "size": 768,
      "distance": "Cosine"
    }
  }'

La distance Cosine convient à de nombreux modèles d’embeddings. La distance Dot peut être pertinente lorsque le modèle ou sa documentation recommande le produit scalaire. Le choix doit rester cohérent avec la manière dont les vecteurs ont été entraînés et normalisés.

Insérez ensuite des points avec leurs vecteurs et leur payload :

curl -X PUT "http://127.0.0.1:6333/collections/knowledge_base/points?wait=true" \
  -H "api-key: ${QDRANT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "points": [
      {
        "id": 1,
        "vector": [0.12, -0.08, 0.31, 0.04],
        "payload": {
          "text": "Qdrant stocke et recherche des embeddings.",
          "source": "documentation-interne",
          "date": "2026-08-11"
        }
      }
    ]
  }'

Le vecteur est volontairement raccourci pour rendre l’exemple lisible. Avec une collection de dimension 768, il doit réellement contenir 768 valeurs.

Une recherche de similarité peut être envoyée ainsi :

curl -X POST "http://127.0.0.1:6333/collections/knowledge_base/points/search" \
  -H "api-key: ${QDRANT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "vector": [0.11, -0.07, 0.29, 0.05],
    "limit": 5,
    "with_payload": true,
    "filter": {
      "must": [
        {
          "key": "source",
          "match": {
            "value": "documentation-interne"
          }
        }
      ]
    }
  }'

Le vecteur de recherche doit lui aussi respecter la dimension réelle de la collection.

Intégrer Qdrant à une stack IA

Les embeddings peuvent provenir d’un modèle exécuté localement avec Ollama, à condition d’utiliser un modèle conçu pour cette tâche, ou d’un fournisseur d’API. Pour une architecture locale, notre guide pour héberger un LLM avec Ollama complète ce déploiement. Notre guide Dify montre quant à lui comment assembler visuellement les étapes d’un workflow IA.

Des frameworks comme LangChain et LlamaIndex disposent d’intégrations Qdrant. Ils prennent en charge l’insertion des documents, la recherche de similarité et la conversion des résultats en contexte pour le LLM.

Dans tous les cas, séparez clairement les responsabilités : le chargeur lit les documents, le splitter crée les chunks, le modèle calcule les embeddings, Qdrant les indexe et le LLM génère la réponse.

Bonnes pratiques pour la qualité du RAG

La taille des chunks influence directement la pertinence. Des passages trop courts manquent de contexte, tandis que des passages trop longs mélangent plusieurs sujets. Commencez avec quelques centaines de tokens, ajoutez un chevauchement raisonnable, puis mesurez les résultats sur un jeu de questions représentatif.

Utilisez toujours le même modèle et la même configuration d’embeddings pour l’indexation et les requêtes. Si vous changez de modèle, créez une nouvelle collection ou réindexez tous les documents. Une simple différence de dimension provoquera une erreur, mais deux modèles de même dimension peuvent aussi produire des espaces vectoriels incompatibles.

Enrichissez le payload avec la source, la date, le type de document, la langue, les droits d’accès et un identifiant de version. Ces métadonnées permettent de filtrer les résultats et d’éviter qu’un utilisateur récupère un contenu auquel il ne devrait pas accéder.

Évaluez enfin le taux de récupération des bons passages avant de modifier les prompts. Un LLM ne peut pas exploiter une information que la recherche n’a pas retrouvée.

Sauvegarder les données Qdrant

Le volume /qdrant/storage contient les données persistantes. Sa sauvegarde est indispensable, mais une simple copie à chaud du volume peut manquer de cohérence selon l’activité en cours.

Qdrant propose des snapshots de collection. Vous pouvez en créer un avec :

curl -X POST \
  "http://127.0.0.1:6333/collections/knowledge_base/snapshots" \
  -H "api-key: ${QDRANT_API_KEY}"

Conservez les snapshots sur un stockage distinct du VPS et appliquez une politique de rétention. Sauvegardez également le fichier Compose, la configuration du reverse proxy et les secrets par un mécanisme sécurisé. Notre guide sur la stratégie de sauvegarde d’un serveur complète cette approche. Testez régulièrement la restauration : une sauvegarde non restaurée reste une hypothèse.

Mises à jour et supervision

Avant une mise à jour, consultez les changements de version, créez un snapshot et sauvegardez le volume. Épinglez la nouvelle version dans compose.yaml, puis exécutez :

docker compose pull
docker compose up -d
docker compose logs --tail=100 qdrant

Surveillez l’espace disque, la mémoire, la charge processeur, les temps de réponse et les erreurs applicatives. Ajoutez une alerte lorsque le stockage approche de sa capacité maximale. Contrôlez aussi la croissance des collections, car chaque réindexation ou nouvelle source documentaire augmente l’empreinte disque.

Avec une exposition réseau limitée, des sauvegardes vérifiées et une supervision adaptée, Qdrant fournit une mémoire vectorielle performante et maîtrisée pour les RAG et les agents IA auto-hébergés.