Qdrant self-hosted : moteur vectoriel — déploiement 2026

Introduction

Quand on parle de base de données vectorielle en 2026, Qdrant s’impose systématiquement en tête des benchmarks de performance et de richesse fonctionnelle. La raison est structurelle : Qdrant est écrit entièrement en Rust, un langage qui offre une gestion mémoire sans garbage collector, des latences prévisibles et une densité de traitement que les moteurs Python ou Java peinent à égaler à charge équivalente. Qdrant publie régulièrement ses propres benchmarks sur qdrant.tech/benchmarks, comparant recall, QPS et latence p99 face à Weaviate, Milvus et Elasticsearch — et les résultats sont constants : Qdrant domine sur les charges mixtes lecture/écriture avec filtrage payload.

Ce qui distingue Qdrant des autres moteurs n’est pas seulement la vitesse brute. C’est l’ensemble cohérent de fonctionnalités : index HNSW configurable, filtrage payload intégré (vous pouvez combiner une recherche cosine avec un filtre SQL-like en une seule requête), snapshots natifs, mode cluster distribué avec réplication Raft, et une API REST + gRPC bien documentée. Pour un développeur ou une PME en Afrique de l’Ouest qui construit un système RAG (Retrieval-Augmented Generation), un moteur de recherche sémantique ou une recommandation produit, Qdrant self-hosted est la solution la plus solide disponible sans abonnement cloud.

Dans ce tutoriel, nous allons déployer Qdrant sur un VPS standard via Docker, créer une collection avec un schéma typé, insérer des vecteurs produits par Ollama en local, exécuter des recherches cosine avec filtres, configurer les snapshots vers MinIO, et enfin activer le mode cluster haute disponibilité. Temps estimé : environ 25 minutes pour un environnement de développement fonctionnel, une heure supplémentaire pour la configuration HA.

Prérequis

• Docker ≥ 24.x et Docker Compose ≥ 2.x installés sur votre VPS ou machine locale
• 2 Go de RAM minimum dédiés à Qdrant (4 Go recommandés pour collections larges)
• Ollama installé et fonctionnel si vous souhaitez générer les embeddings localement (voir notre tutoriel Ollama avancé)
• Python 3.10+ ou curl pour interagir avec l’API REST
• ~25 minutes pour les étapes 1 à 6, ~45 minutes supplémentaires pour l’étape 7 (cluster HA)
• Niveau : intermédiaire — vous savez lire un fichier YAML Docker Compose et exécuter des requêtes HTTP

Étape 1 — Qdrant vs Pinecone vs pgvector

Avant de mettre les mains dans Docker, il est utile de comprendre pourquoi on choisit Qdrant plutôt que les alternatives les plus citées. Ce n’est pas une question dogmatique : chaque outil a ses forces, et le choix dépend de votre contexte.

Pinecone est un service cloud managé, sans installation, avec une API simple. C’est l’option zéro-friction pour un prototype rapide. Mais en 2026, Pinecone reste un service américain avec des prix en dollars, une latence réseau depuis Dakar ou Abidjan non négligeable (plusieurs centaines de millisecondes), aucune option de résidence des données sur le continent, et une dépendance totale à la disponibilité du service. Pour une PME qui traite des documents OHADA confidentiels ou des données clients sensibles, Pinecone n’est pas un choix souverain.

pgvector est l’extension vectorielle de PostgreSQL. Elle est remarquable pour sa simplicité d’intégration dans un stack déjà PostgreSQL, et elle couvre très bien les cas d’usage modestes : quelques dizaines de milliers de vecteurs, recherches occasionnelles, pas de filtrage complexe haute fréquence. Mais pgvector souffre structurellement d’un problème de performance à l’échelle : l’index HNSW de pgvector est moins optimisé que celui de Qdrant, et surtout, PostgreSQL partage ses ressources CPU/mémoire entre les requêtes SQL classiques et les recherches vectorielles — ce qui crée de la contention sous charge. Nous avons un tutoriel dédié à pgvector si votre stack est déjà tout-PostgreSQL.

Qdrant occupe le positionnement optimal pour le self-hosting en production : un processus unique dédié, une empreinte mémoire contrôlée grâce à Rust, un index HNSW mature, le filtrage payload sans post-traitement applicatif, les snapshots natifs, et un mode cluster documenté. C’est le choix que nous recommandons pour tout projet qui dépasse le prototype et qui doit tourner de façon autonome sur un VPS Hetzner, DigitalOcean ou un serveur dédié local.

Étape 2 — Déployer via Docker

Qdrant publie son image officielle sur Docker Hub sous qdrant/qdrant. La façon la plus propre de déployer est via un fichier Docker Compose qui monte un volume persistant pour les données et expose les deux ports nécessaires : 6333 (REST et WebUI) et 6334 (gRPC).

Créez un répertoire de travail, par exemple /opt/qdrant, et placez-y ce fichier docker-compose.yml :

# /opt/qdrant/docker-compose.yml
version: "3.9"

services:
  qdrant:
    image: qdrant/qdrant:v1.9.0          # version épinglée — évitez :latest en production
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"   # REST API + WebUI Dashboard
      - "6334:6334"   # gRPC (clients Python, Go, etc.)
    volumes:
      - qdrant_storage:/qdrant/storage   # persistance des collections
    environment:
      - QDRANT__SERVICE__API_KEY=VOTRE_CLE_API_SECRETE   # activer en production

volumes:
  qdrant_storage:
    driver: local

Lancez le service avec docker compose up -d depuis le répertoire /opt/qdrant. Docker téléchargera l’image (environ 80 Mo) et démarrera le conteneur. Pour vérifier que Qdrant répond correctement, exécutez la commande suivante :

curl http://localhost:6333/
# Réponse attendue : {"title":"qdrant - vector search engine","version":"1.9.0"}

Si vous obtenez cette réponse JSON, Qdrant est opérationnel. Vous pouvez aussi ouvrir http://votre-ip:6333/dashboard dans un navigateur pour accéder au WebUI intégré — une interface graphique qui permet de visualiser les collections, d’exécuter des requêtes et de surveiller les métriques sans installer d’outil tiers. En production, il est impératif de configurer la variable QDRANT__SERVICE__API_KEY et de placer Qdrant derrière un reverse proxy Nginx ou Caddy avec TLS, car le port 6333 ne chiffre pas les données en transit par défaut.

Étape 3 — Créer une collection avec schéma

Dans Qdrant, une collection est l’équivalent d’une table dans une base relationnelle, mais dédiée aux vecteurs. Avant d’insérer des données, vous devez déclarer la collection en précisant la taille des vecteurs et la métrique de distance utilisée. Ces deux paramètres sont immuables après création — il faudra recréer la collection si vous changez d’architecture d’embedding.

Nous allons créer une collection documents_ohada pour stocker des vecteurs de 1024 dimensions (taille produite par le modèle bge-m3) avec la distance cosine :

curl -X PUT http://localhost:6333/collections/documents_ohada \
  -H 'Content-Type: application/json' \
  -H 'api-key: VOTRE_CLE_API_SECRETE' \
  -d '{
    "vectors": {
      "size": 1024,
      "distance": "Cosine"
    },
    "hnsw_config": {
      "m": 16,
      "ef_construct": 100
    },
    "optimizers_config": {
      "memmap_threshold": 20000
    }
  }'

Quelques explications sur les paramètres HNSW : m est le nombre de liens par nœud dans le graphe — une valeur de 16 est le bon équilibre entre vitesse de construction et qualité du recall. ef_construct contrôle la qualité de l’index lors de l’insertion : 100 est la valeur par défaut recommandée par Qdrant pour la plupart des cas d’usage. Le paramètre memmap_threshold indique à Qdrant de basculer sur un stockage memory-mapped (fichier sur disque avec accès quasi-mémoire) quand la collection dépasse 20 000 points — utile pour économiser la RAM sur les petits VPS. La réponse attendue de l’API est {"result":true,"status":"ok"}.

Qdrant supporte aussi les payload schemas pour valider les métadonnées attachées à chaque point. Pour notre collection OHADA, nous pouvons créer des index sur les champs fréquemment filtrés :

# Créer un index sur le champ "pays" (keyword) pour filtrage rapide
curl -X PUT http://localhost:6333/collections/documents_ohada/index \
  -H 'Content-Type: application/json' \
  -H 'api-key: VOTRE_CLE_API_SECRETE' \
  -d '{"field_name": "pays", "field_schema": "keyword"}'

# Créer un index sur le champ "annee" (integer) pour filtrage par date
curl -X PUT http://localhost:6333/collections/documents_ohada/index \
  -H 'Content-Type: application/json' \
  -H 'api-key: VOTRE_CLE_API_SECRETE' \
  -d '{"field_name": "annee", "field_schema": "integer"}'

Ces index de payload permettront à Qdrant d’appliquer les filtres directement dans l’index vectoriel (filtrage pre-fetch), ce qui est bien plus efficace qu’un filtrage post-recherche. La documentation complète sur les types de payload et les index est disponible sur qdrant.tech/documentation/concepts/payload.

Étape 4 — Insérer des points avec embeddings Ollama

Un point dans Qdrant est la combinaison d’un identifiant unique, d’un vecteur d’embedding et d’un payload JSON libre qui contient vos métadonnées. Pour générer les vecteurs, nous allons utiliser Ollama avec le modèle bge-m3, qui produit des embeddings de 1024 dimensions, supporte le français, l’anglais et une cinquantaine d’autres langues — parfait pour des documents juridiques OHADA rédigés en français avec des termes techniques anglais.

Assurez-vous d’abord qu’Ollama tourne et que le modèle est téléchargé :

ollama pull bge-m3
# Téléchargement de ~570 Mo — à faire une seule fois

Voici un script Python minimal qui lit un texte, génère son embedding via Ollama, puis l’insère dans Qdrant :

import requests
import uuid

QDRANT_URL = "http://localhost:6333"
API_KEY = "VOTRE_CLE_API_SECRETE"
OLLAMA_URL = "http://localhost:11434"
COLLECTION = "documents_ohada"

def get_embedding(text: str) -> list[float]:
    """Appelle Ollama pour générer un embedding bge-m3."""
    resp = requests.post(
        f"{OLLAMA_URL}/api/embeddings",
        json={"model": "bge-m3", "prompt": text}
    )
    resp.raise_for_status()
    return resp.json()["embedding"]

def insert_point(text: str, metadata: dict) -> str:
    """Insère un point dans Qdrant avec son embedding et son payload."""
    point_id = str(uuid.uuid4())          # ID unique au format UUID
    vector = get_embedding(text)
    payload = {"texte": text, **metadata}  # on stocke aussi le texte brut pour restitution RAG

    resp = requests.put(
        f"{QDRANT_URL}/collections/{COLLECTION}/points",
        headers={"api-key": API_KEY, "Content-Type": "application/json"},
        json={
            "points": [{
                "id": point_id,
                "vector": vector,
                "payload": payload
            }]
        }
    )
    resp.raise_for_status()
    print(f"Inséré : {point_id} — status : {resp.json()['status']}")
    return point_id

# Exemple d'utilisation
insert_point(
    text="L'Acte Uniforme OHADA relatif au droit commercial général dispose que "
         "tout commerçant doit tenir une comptabilité régulière.",
    metadata={
        "source": "OHADA-AUDCG-2010",
        "pays": "senegal",
        "annee": 2010,
        "type_doc": "acte_uniforme"
    }
)

Chaque appel à insert_point() effectue deux opérations réseau : une vers Ollama pour générer l’embedding (~50–200 ms selon votre matériel) et une vers Qdrant pour persister le point (~5 ms). Pour des insertions en masse, utilisez l’endpoint /collections/{name}/points avec un tableau de plusieurs centaines de points par requête — Qdrant gère le batching internement via son mécanisme d’optimisation asynchrone. La documentation sur l’insertion en batch est disponible sur qdrant.tech/documentation/concepts/points.

Étape 5 — Recherche cosine avec filtres payload

La recherche vectorielle est le cœur du système. Qdrant permet de combiner en une seule requête la similarité cosine (trouver les vecteurs les plus proches sémantiquement) et des filtres sur le payload (restreindre les résultats à un pays, une année, un type de document). Cette combinaison, appelée filtered nearest neighbor search, est ce qui rend Qdrant supérieur à une simple recherche par similarité naïve.

def search_similar(query_text: str, country_filter: str = None, top_k: int = 5) -> list:
    """Recherche les documents les plus proches sémantiquement avec filtre optionnel."""
    query_vector = get_embedding(query_text)

    # Construction du filtre payload (optionnel)
    search_filter = None
    if country_filter:
        search_filter = {
            "must": [
                {"key": "pays", "match": {"value": country_filter}}
            ]
        }

    body = {
        "vector": query_vector,
        "limit": top_k,
        "with_payload": True,   # retourner le payload pour afficher le texte source
        "score_threshold": 0.7  # ignorer les résultats trop peu similaires
    }
    if search_filter:
        body["filter"] = search_filter

    resp = requests.post(
        f"{QDRANT_URL}/collections/{COLLECTION}/points/search",
        headers={"api-key": API_KEY, "Content-Type": "application/json"},
        json=body
    )
    resp.raise_for_status()
    return resp.json()["result"]

# Exemple : chercher des textes OHADA sur la comptabilité, uniquement pour le Sénégal
results = search_similar(
    query_text="obligations comptables des commerçants",
    country_filter="senegal",
    top_k=3
)
for r in results:
    print(f"Score : {r['score']:.4f} | Source : {r['payload']['source']}")
    print(f"  Texte : {r['payload']['texte'][:120]}...")
    print()

Le paramètre score_threshold: 0.7 est un seuil de pertinence : tout résultat avec un score cosine inférieur à 0.7 sera ignoré. En pratique pour des embeddings bge-m3, les textes sémantiquement proches obtiennent des scores supérieurs à 0.75, tandis que les faux positifs tombent souvent en dessous de 0.6. Ajustez ce seuil selon votre corpus. Qdrant supporte également les recherches par recommendation (trouver des points similaires à un point existant) et les recherches grouped (regrouper les résultats par valeur de payload) — deux fonctionnalités documentées sur qdrant.tech/documentation/concepts/search.

Étape 6 — Snapshots et backup

Les données dans Qdrant sont précieuses — elles représentent souvent des heures de génération d’embeddings. Qdrant intègre un mécanisme de snapshot natif qui crée une copie cohérente d’une collection à un instant T, sans interruption de service. Le snapshot est un fichier .snapshot que vous pouvez télécharger, archiver ou restaurer sur une autre instance.

Pour créer un snapshot de la collection documents_ohada :

# Déclencher la création d'un snapshot (opération asynchrone)
curl -X POST http://localhost:6333/collections/documents_ohada/snapshots \
  -H 'api-key: VOTRE_CLE_API_SECRETE'

# Réponse : {"result":{"name":"documents_ohada-0-1714000000.snapshot","creation_time":"..."},"status":"ok"}

# Lister les snapshots disponibles
curl http://localhost:6333/collections/documents_ohada/snapshots \
  -H 'api-key: VOTRE_CLE_API_SECRETE'

# Télécharger le snapshot
curl -o backup_ohada.snapshot \
  http://localhost:6333/collections/documents_ohada/snapshots/documents_ohada-0-1714000000.snapshot \
  -H 'api-key: VOTRE_CLE_API_SECRETE'

Pour une stratégie de backup robuste sur un VPS Hetzner, combinez les snapshots Qdrant avec une synchronisation vers MinIO (stockage objet S3-compatible self-hosted). Voici un script shell à planifier en cron :

#!/bin/bash
# /opt/qdrant/scripts/backup.sh — à lancer via cron tous les jours à 02h00
set -e

DATE=$(date +%Y%m%d-%H%M%S)
COLLECTION="documents_ohada"
QDRANT_URL="http://localhost:6333"
MINIO_BUCKET="qdrant-backups"

# 1. Déclencher le snapshot et récupérer son nom
SNAP_NAME=$(curl -s -X POST "${QDRANT_URL}/collections/${COLLECTION}/snapshots" \
  -H "api-key: ${QDRANT_API_KEY}" | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['name'])")

echo "Snapshot créé : ${SNAP_NAME}"

# 2. Attendre 10s que Qdrant finalise l'écriture (optionnel pour petites collections)
sleep 10

# 3. Uploader vers MinIO via mc (MinIO Client)
mc cp "${QDRANT_URL}/collections/${COLLECTION}/snapshots/${SNAP_NAME}" \
   "minio/${MINIO_BUCKET}/${DATE}-${SNAP_NAME}"

echo "Backup uploadé : minio/${MINIO_BUCKET}/${DATE}-${SNAP_NAME}"

Pour restaurer un snapshot sur une instance Qdrant vierge, utilisez l’endpoint PUT /collections/{name}/snapshots/recover en passant l’URL du fichier snapshot. Qdrant reconstruit l’index HNSW complet à partir du snapshot — cette opération prend quelques minutes pour des collections de plusieurs millions de points.

Étape 7 — Cluster mode haute disponibilité

Pour une production critique où la disponibilité ne peut pas être interrompue, Qdrant offre un mode cluster distribué basé sur le protocole de consensus Raft. Dans ce mode, plusieurs nœuds Qdrant se synchronisent : les collections peuvent être shardées (réparties sur plusieurs nœuds) et/ou répliquées (copiées sur plusieurs nœuds pour la redondance). La documentation officielle du mode distribué est disponible sur qdrant.tech/documentation/guides/distributed_deployment.

Voici la configuration minimale pour un cluster de 3 nœuds. Sur chaque nœud, modifiez le fichier de configuration Qdrant config/config.yaml (monté dans le conteneur Docker) :

# config/config.yaml — même fichier sur chaque nœud, avec peer_uri adapté
service:
  api_key: "VOTRE_CLE_API_SECRETE"

cluster:
  enabled: true
  p2p:
    port: 6335             # port de communication inter-nœuds
  consensus:
    tick_period_ms: 100    # intervalle de consensus Raft

Démarrez ensuite le premier nœud normalement avec Docker Compose. Pour les nœuds suivants, passez l’URI du nœud bootstrap via la variable d’environnement :

# Sur le nœud 2 (IP: 10.0.0.2)
docker run -d --name qdrant-node2 \
  -p 6333:6333 -p 6334:6334 -p 6335:6335 \
  -v qdrant_storage:/qdrant/storage \
  -v $(pwd)/config:/qdrant/config \
  -e QDRANT__CLUSTER__ENABLED=true \
  qdrant/qdrant:v1.9.0 \
  ./qdrant --bootstrap http://10.0.0.1:6335  # URI du nœud 1

Une fois le cluster formé, créez des collections avec réplication activée pour la haute disponibilité :

curl -X PUT http://localhost:6333/collections/documents_ohada_ha \
  -H 'Content-Type: application/json' \
  -H 'api-key: VOTRE_CLE_API_SECRETE' \
  -d '{
    "vectors": {"size": 1024, "distance": "Cosine"},
    "shard_number": 3,           # 1 shard par nœud
    "replication_factor": 2      # chaque shard copié sur 2 nœuds
  }'

Avec replication_factor: 2 sur 3 nœuds, la collection reste disponible même si un nœud tombe. Qdrant gère automatiquement le rééquilibrage des shards lors de l’ajout ou la suppression de nœuds. Pour la surveillance du cluster, l’endpoint GET /cluster renvoie l’état de chaque nœud en JSON.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Déployer Qdrant en Afrique de l’Ouest en 2026 implique quelques adaptations pratiques qui vont au-delà du simple suivi de la documentation officielle. Voici les points clés à considérer pour une PME ou un développeur indépendant dans la région.

RAG sur corpus OHADA et documents juridiques francophones. L’un des cas d’usage les plus pertinents pour Qdrant dans notre contexte est la construction d’un système RAG sur les textes juridiques OHADA (Organisation pour l’Harmonisation en Afrique du Droit des Affaires). Ces textes sont disponibles publiquement en PDF et couvrent le droit commercial, comptable, des sociétés et du travail pour 17 pays africains. Avec Qdrant, vous pouvez indexer l’intégralité des Actes Uniformes OHADA (~2 000 pages), permettre à vos clients ou collaborateurs d’interroger ces textes en langage naturel, et obtenir des extraits précis avec source exacte. C’est une valeur ajoutée considérable pour les cabinets d’avocats, les DAF de PME et les services juridiques d’entreprise en Côte d’Ivoire, au Sénégal, au Cameroun ou au Mali.

Embeddings bge-m3 multilingues pour le français et les langues locales. Le modèle BAAI/bge-m3 est un choix excellent pour notre région : il supporte nativement le français et l’anglais, mais aussi l’arabe (utile pour les communautés islamisées du Sahel), et produit des embeddings stables pour les textes mélangés (francais + wolof translittéré, par exemple). Sa taille de 570 Mo est raisonnable pour un VPS à 4 Go de RAM. Via Ollama, il tourne en CPU sans nécessiter de GPU — un avantage majeur quand les machines avec GPU restent rares et coûteuses dans la région.

Infrastructure : Hetzner + MinIO pour les snapshots. Hetzner Cloud propose des VPS en Allemagne (datacenter Falkenstein ou Helsinki) à des prix très compétitifs en euros, accepte les paiements par carte bancaire internationale, et offre une bande passante généreuse. Un VPS CX32 (4 vCPU, 8 Go RAM, 80 Go SSD) à environ 11 €/mois est suffisant pour un Qdrant single-node avec 2 à 5 millions de vecteurs. Pour les snapshots, déployer MinIO sur la même machine (ou un VPS séparé) permet d’avoir un stockage objet S3-compatible sans dépendre d’AWS S3, dont les coûts de transfert de données sortants peuvent surprendre. Notre tutoriel Gitea LFS + MinIO couvre l’installation de MinIO en détail.

Gestion des coupures électriques. Dans plusieurs villes d’Afrique de l’Ouest, les coupures de courant fréquentes représentent un risque pour les données. Qdrant écrit ses données via des fichiers memmap qui sont synchronisés sur disque périodiquement. Pour réduire le risque de corruption, configurez le paramètre QDRANT__STORAGE__WAL__WAL_CAPACITY_MB=32 (Write-Ahead Log) dans vos variables d’environnement Docker — cela garantit que chaque écriture est d’abord journalisée avant d’être appliquée, permettant une récupération propre après un arrêt brutal.

Tutoriels frères

• pgvector + PostgreSQL : recherche sémantique intégrée — Quand votre stack est déjà tout-PostgreSQL et que vous voulez éviter un service supplémentaire
• Ollama avancé : servir plusieurs modèles LLM en self-hosted — Pour maîtriser la génération d’embeddings et de réponses LLM qui s’articule avec Qdrant dans un pipeline RAG

Pour aller plus loin

• Retour au pilier : Vector DB self-hosted 2026 : Qdrant, Weaviate, Chroma, Milvus
• Documentation officielle Qdrant : qdrant.tech/documentation — concepts, API reference, guides de déploiement
• Benchmarks officiels Qdrant : qdrant.tech/benchmarks — comparaison Qdrant vs Weaviate vs Milvus vs Elasticsearch
• Client Python qdrant-client : github.com/qdrant/qdrant-client — bibliothèque officielle avec support async
• Prochaine étape suggérée : une fois Qdrant déployé, construire un pipeline RAG complet en combinant Qdrant + Ollama + LangChain ou LlamaIndex pour interroger vos documents en langage naturel.

FAQ

Q : Quelle est la différence entre Qdrant Cloud et Qdrant self-hosted ?

Qdrant Cloud est le service managé proposé par la société Qdrant GmbH — zéro infrastructure à gérer, paiement à l’usage, mais données hébergées sur des serveurs cloud américains ou européens. Qdrant self-hosted (ce tutoriel) tourne sur votre propre VPS ou serveur dédié, vous contrôlez intégralement les données, il n’y a pas de coût de licence (la licence Apache 2.0 est gratuite), et vous êtes limité seulement par votre matériel. Pour les PME africaines qui traitent des données sensibles ou qui veulent maîtriser leurs coûts à long terme, le self-hosting est presque toujours préférable.

Q : Combien de vecteurs peut gérer Qdrant sur un VPS standard ?

Sur un VPS avec 8 Go de RAM et un SSD de 80 Go, Qdrant peut gérer confortablement entre 5 et 20 millions de vecteurs de 1024 dimensions, selon la configuration memmap et le nombre de collections. Au-delà, il faut soit augmenter la RAM, soit activer le mode memmap agressif (qui décharge les segments sur disque), soit passer au mode cluster. La documentation de Qdrant sur le sizing matériel est disponible sur qdrant.tech/documentation/guides/capacity-planning.

Q : Puis-je utiliser Qdrant sans générer les embeddings avec Ollama ?

Absolument. Qdrant est agnostique sur la source des vecteurs — il stocke et recherche des tableaux de flottants, peu importe d’où ils viennent. Vous pouvez utiliser l’API OpenAI embeddings (text-embedding-3-small ou large), les modèles HuggingFace via sentence-transformers, les APIs Cohere ou Mistral, ou tout autre fournisseur. Ollama est simplement l’option 100% locale et gratuite que nous recommandons pour le contexte africain. Notez que si vous changez de modèle d’embedding, vous devrez réindexer toute votre collection (les vecteurs produits par des modèles différents ne sont pas comparables).

Q : Qdrant supporte-t-il les recherches hybrides (vectorielle + plein texte) ?

Depuis la version 1.7, Qdrant supporte les sparse vectors (vecteurs creux, typiquement BM25 ou SPLADE) en plus des vecteurs denses habituels. Cela permet de faire de la recherche hybride en combinant un score vectoriel dense (sémantique) et un score sparse (lexical), puis en les fusionnant via la formule RRF (Reciprocal Rank Fusion). Cette fonctionnalité est documentée sur qdrant.tech/documentation/concepts/hybrid-queries.

Q : Comment sécuriser l’accès à Qdrant en production ?

Trois couches de sécurité sont recommandées : (1) configurer une clé API forte via QDRANT__SERVICE__API_KEY dans les variables d’environnement Docker ; (2) placer Qdrant derrière un reverse proxy Nginx ou Caddy avec TLS (Let’s Encrypt) — exposer le port 6333 directement sur internet sans TLS envoie les vecteurs et payloads en clair ; (3) restreindre l’accès au port 6333 via le firewall (ufw ou iptables) à votre IP ou réseau interne uniquement, et ne l’ouvrir vers l’extérieur que via le reverse proxy HTTPS.

Q : Est-il possible de migrer des données de pgvector vers Qdrant ?

Oui, la migration est faisable mais manuelle. Il n’existe pas d’outil officiel de migration directe. La procédure consiste à : (1) exporter vos vecteurs et métadonnées depuis pgvector via une requête SQL (SELECT id, embedding, payload FROM votre_table) ; (2) les transformer au format JSON attendu par l’API Qdrant ; (3) les insérer par batch via PUT /collections/{name}/points. Un script Python de quelques dizaines de lignes suffit. L’avantage est que vous réutilisez exactement les mêmes vecteurs — pas besoin de réencoder vos textes si le modèle d’embedding n’a pas changé.