Qu’est-ce qu’une base de données vectorielle ? (Guide 2026)

Une base de données vectorielle stocke les données sous forme de listes de nombres appelées « embeddings », puis identifie les entrées dont le sens est le plus proche de votre requête. Voilà tout le principe. Là où une base de données traditionnelle effectue des correspondances exactes (« rechercher les lignes où pays = « France » »), une base de données vectorielle rapproche des concepts — « trouver les paragraphes traitant du même sujet que cette question », même si aucun mot ne se chevauche.

Cette capacité constitue le cœur de presque toutes les fonctionnalités IA sérieuses lancées en 2026 : chatbots citant vos documents, recherche sémantique, systèmes de recommandation, et surtout la génération augmentée par recherche (RAG). Ce guide explique concrètement ce qu’est une base de données vectorielle, comment fonctionnent les embeddings et la recherche de similarité en arrière-plan, les six solutions les plus couramment évaluées par les équipes, et — tout aussi important — dans quels cas vous n’en avez pas besoin du tout.

Ce qu’est réellement une base de données vectorielle

Pour un ordinateur, la phrase « le chat s’assit sur le tapis » n’est qu’un texte dépourvu de sens. Un modèle d’embedding — un réseau de neurones spécifiquement entraîné à cette tâche — convertit cette phrase en une liste de nombres de longueur fixe, souvent 768, 1 024 ou 1 536. Chaque nombre capture une dimension apprise du sens. Le résultat est un point dans un espace à très haute dimension, et la propriété utile est la suivante : les phrases exprimant des idées similaires se retrouvent proches les unes des autres, tandis que les phrases sans lien s’éloignent. Ainsi, « Le chaton s’est reposé sur le tapis » aboutit près de notre phrase initiale, bien qu’elles partagent presque aucun mot.

Une base de données vectorielle est conçue spécifiquement pour stocker des millions, voire des milliards, de ces points et répondre rapidement à une seule question : quels vecteurs stockés sont les plus proches de ce vecteur-requête ? Elle intègre l’index rendant cette recherche efficace, le filtrage par métadonnées (afin de pouvoir préciser « les résultats les plus proches, mais uniquement ceux datant de 2025 ») ainsi que les mécanismes de stockage et de montée en charge nécessaires à son bon fonctionnement. Si vous souhaitez comprendre le contexte plus large dans lequel ces composants s’intègrent aux systèmes d’IA, consultez notre guide débutant pour l’apprentissage automatique qui traite des modèles d’embedding qui alimentent la base de données dès le départ.

Embeddings et similarité, brièvement

« Le plus proche » exige une définition. La métrique la plus courante pour le texte est la similarité cosinus, qui mesure l’angle entre deux vecteurs, sans tenir compte de leur longueur. Elle varie de -1 (sens opposé) à 1 (direction identique), et comme la plupart des modèles d’embedding modernes produisent des vecteurs normalisés de longueur unitaire, la similarité cosinus devient mathématiquement équivalente au produit scalaire, plus rapide à calculer. produit scalaire. La distance euclidienne constitue l’autre option courante, utile lorsque la magnitude porte effectivement une information pertinente. Pour les applications typiques de RAG et de recherche sémantique, la similarité cosinus reste le choix par défaut le plus pertinent, et c’est celle que la plupart des bases de données utilisent nativement.

Comment la recherche de similarité fonctionne à grande échelle

Voici la difficulté : comparer votre requête à chaque vecteur stocké — une recherche exhaustive — fournit des résultats parfaits, mais devient inopérante sous charge. Avec 10 millions de vecteurs, vérifier chacun d’eux à chaque requête est bien trop lent pour une application interactive. Les bases de données vectorielles utilisent donc la recherche approximative des voisins les plus proches (ANN) : elles acceptent une précision de 95 à 99 % en échange d’une accélération de plusieurs ordres de grandeur.

La méthode ANN dominante en 2026 est HNSW (Hierarchical Navigable Small World), introduite par Yury Malkov et Dmitry Yashunin dans un article publié en 2016. Elle construit un graphe hiérarchique — imaginez une liste à saut combinée à un réseau routier. La couche supérieure est clairsemée, avec quelques nœuds reliés par des « autoroutes » à longue portée ; chaque couche inférieure ajoute davantage de nœuds et des routes locales plus courtes, tandis que la couche inférieure contient tous les vecteurs. Une recherche commence au sommet, effectue des sauts longs pour atteindre le voisinage approprié, puis descend progressivement à travers des couches de plus en plus fines afin de localiser précisément les correspondances les plus proches. Pour les données pouvant tenir entièrement en mémoire, HNSW offre systématiquement le meilleur compromis entre rappel et latence, ce qui explique pourquoi presque tous les moteurs présentés ici l’implémentent.

L'autre moitié de l'histoire de l'extensibilité concerne quantification — la compression des vecteurs afin d'en faire tenir davantage dans la mémoire vive (RAM). Les techniques vont de la quantification scalaire et de produit à des méthodes très agressives à 1 bit. Par exemple, l'implémentation RaBitQ de Milvus réduit la consommation mémoire d'environ 72 % (associée à une étape de raffinement SQ8), tout en maintenant le taux de rappel proche de 95 %. Cette compression est ce qui rend la recherche à l'échelle du milliard abordable.

Les principales bases de données vectorielles en 2026

Le marché se divise en trois catégories : les services entièrement gérés, les moteurs open source auto-hébergés, et l'extension Postgres qui, discrètement, a absorbé une part considérable du segment bas de gamme. Voici comment les principales solutions se comparent, avec des détails vérifiés à partir de sources actualisées à la mi-2026.

Géré : Pinecone

Pinecone est la solution « payez quelqu’un d’autre pour l’exécuter ». Son architecture serverless vous permet de stocker des milliards de vecteurs sans avoir à provisionner de serveurs, et vous êtes facturé selon des unités de lecture, d’écriture et de stockage — plutôt que selon des nœuds fixes — ce qui convient particulièrement au trafic RAG intermittent, qui diminue fortement la nuit. En 2026, les tarifs vont d’un niveau gratuit Starter à un forfait Builder fixe de 20 $/mois, puis Standard (environ 50 $/mois minimum) et Enterprise (environ 500 $/mois minimum), avec une facturation serverless approximative de 4 $ par million d’unités d’écriture, 16 $ par million d’unités de lecture et 0,33 $/Go/mois pour le stockage. La plateforme s’est étendue au-delà du simple stockage avec Pinecone Inference (hébergement d’embedding et de reranking) et Assistant (destiné aux applications orientées agents), tandis que la fonctionnalité « Apportez votre propre cloud » (Bring Your Own Cloud) est désormais en version bêta publique pour les clients Enterprise.

Open source : Qdrant, Weaviate, Milvus, Chroma

Si vous préférez maîtriser l’intégralité de la pile technique, le domaine open source est solide. QdrantQdrant, écrit en Rust, est le favori en termes de performances — rapide, sécurisé en mémoire, doté d’options riches en matière de quantification, et enrichi en 2026 de fonctionnalités destinées aux entreprises (indexation accélérée par GPU, clusters multi-zone de disponibilité, journaux d’audit disponibles sur Qdrant Cloud depuis avril). WeaviateWeaviate, écrit en Go, domine la recherche hybride : il combine recherche par mots-clés (BM25) et recherche vectorielle avec des filtres sur métadonnées dans une seule requête, ce qui s’avère véritablement utile lorsque la précision des termes et la signification floue sont toutes deux essentielles. MilvusMilvus, projet combinant Go et C++ développé par Zilliz et diplômé de la fondation LF AI & Data, est la solution à privilégier pour les besoins extrêmes — son architecture cible l’échelle du milliard de vecteurs, et sa quantification RaBitQ en maintient le coût abordable. Chroma sits at the opposite pole: it runs in-process, gets you from zero to a working index in minutes, and is ideal for prototyping, though its sweet spot stays around 5–10 million vectors per node.

Selon les rapports de la mi-2026, les débits approximatifs permettent de les comparer : Qdrant et Weaviate atteignent couramment plusieurs dizaines de milliers de requêtes par seconde, tandis que Milvus peut dépasser les 100 000 requêtes par seconde à grande échelle — toutefois, les chiffres réels dépendent fortement des dimensions des vecteurs, du matériel utilisé et des objectifs de rappel ; il est donc impératif de réaliser des tests de référence sur vos propres données avant de faire confiance à une valeur unique.

La voie Postgres : pgvector

pgvector est l’entrée la plus importante de cette liste, simplement parce qu’il ne s’agit pas d’une base de données distincte — c’est une extension qui ajoute des colonnes vectorielles et des index ANN à PostgreSQL. Vos embeddings résident dans la même table que vos données relationnelles, interrogeables via une seule instruction SQL et une seule transaction. La version 0.8 a comblé la plupart des lacunes restantes, notamment en introduisant des analyses itératives d’index qui résolvent l’ancien problème de sur-filtrage, où une clause WHERE pouvait priver la recherche vectorielle de résultats. Elle prend en charge à la fois les index HNSW et IVFFlat, et est utilisée en production par de grandes équipes. L’argument principal est opérationnel : un seul système à déployer, sauvegarder et surveiller, plutôt que deux.

Quand vous avez réellement besoin d’une base de données vectorielle (et quand vous n’en avez pas besoin)

C’est là une question que trop d’équipes négligent. Une base de données vectorielle spécialisée constitue une infrastructure réelle — un autre service à déployer, sécuriser, faire évoluer et payer. Vous devriez y recourir uniquement lorsque vous avez réellement besoin de ses atouts.

Vous avez probablement s’adaptent besoin d’un moteur spécialisé dès lors que vous dépassez environ 5 à 10 millions de vecteurs, que vous exigez une latence p99 inférieure à 10 ms sous fort volume de requêtes, que vous comptez sur une recherche hybride avancée, ou encore que vous développez un produit multilocataire où l’isolation et l’extensibilité horizontale sont critiques. À cette échelle, les solutions spécialisées prennent clairement l’avantage.

Vous avez probablement ne pas lorsque vous traitez moins d’un million de vecteurs, utilisez déjà PostgreSQL, et que vos besoins en latence se mesurent en dizaines de millisecondes plutôt qu’en chiffres simples. Le consensus de 2026 est sans équivoque : en dessous d’environ 10 millions de vecteurs, pgvector égale ou dépasse les solutions dédiées sur les métriques qui comptent le plus pour la plupart des applications, et l’emporte nettement sur la simplicité opérationnelle. Commencez par là, et passez à une base de données spécialisée uniquement lorsque vous atteignez un goulot d’étranglement mesurable. Ce même raisonnement s’applique à un choix architectural plus fondamental — avant de déployer toute pile de récupération (retrieval), il vaut la peine d’évaluer le réglage fin (fine-tuning) par rapport à la génération augmentée par récupération (RAG) pour confirmer que la récupération est bien l’outil adapté à votre problème.

Comment les bases de données vectorielles alimentent le RAG

La raison pour laquelle tout ceci importe à la plupart des développeurs est la génération augmentée par récupération (RAG). Un modèle de langage (LLM) ne connaît que ce sur quoi il a été entraîné, et il ne peut pas accéder à vos documents internes, aux tickets de la semaine dernière ou à votre catalogue produit. La RAG corrige cela : vous intégrez (« embed ») vos documents dans une base de données vectorielle à l’avance, puis, au moment de la requête, vous intégrez la question de l’utilisateur, récupérez les quelques extraits les plus similaires, et les fournissez au modèle comme contexte. L’LLM répond alors à partir de matériel réel, à jour et ancré dans des sources fiables, plutôt que de deviner.

La base de données vectorielle constitue la couche de récupération dans cette boucle, et sa qualité fixe un plafond à l’ensemble du système — une mauvaise récupération entraîne de mauvaises réponses, quelle que soit la qualité du modèle. Si vous souhaitez voir l’intégralité de cette boucle assemblée de bout en bout, notre tutoriel sur la construction d’un pipeline RAG place correctement la base de données aux côtés des étapes de segmentation (chunking), d’intégration (embedding) et de génération.

FAQ

Une base de données vectorielle est-elle identique à une base de données classique ?

Non. Une base de données relationnelle ou documentaire est conçue pour exécuter des requêtes exactes et structurées — correspondance d’identifiants, de plages ou de valeurs de champs. Une base de données vectorielle, quant à elle, est conçue pour rechercher des éléments selon leur similarité sémantique, à l’aide d’encodages vectoriels en haute dimension. De nombreux systèmes, comme pgvector, intègrent désormais la recherche vectorielle à une base de données traditionnelle afin de combiner les deux fonctionnalités en un seul lieu.

Ai-je besoin d’une base de données vectorielle pour la RAG ?

Vous avez besoin de recherche vectorielle pour la RAG, mais pas nécessairement une dédiée Pour des corpus de petite à moyenne taille, pgvector intégré à votre instance PostgreSQL existante gère très bien la récupération. Un moteur autonome tel que Pinecone ou Qdrant justifie son existence dès lors que vous dépassez le million de documents ou que vous exigez une latence très faible.

Qu’est-ce que HNSW et pourquoi est-ce important ?

HNSW (Hierarchical Navigable Small World, ou « petit monde hiérarchique navigable ») est l’index approximatif des plus proches voisins le plus répandu. Il construit un graphe hiérarchique permettant à une recherche de « sauter » rapidement vers la bonne région de l’espace vectoriel, puis d’affiner le résultat, retournant des réponses quasi parfaites en quelques millisecondes. Il est essentiel car il rend la recherche par similarité assez rapide pour être utilisée en temps réel.

La similarité cosinus est-elle meilleure que la distance euclidienne ?

Pour les encodages textuels (text embeddings), la similarité cosinus est généralement le choix par défaut le plus pertinent, car elle compare la direction (le sens) plutôt que la magnitude. Lorsque les vecteurs sont normalisés à une longueur unitaire — comme le font la plupart des modèles modernes — la similarité cosinus, le produit scalaire et la distance euclidienne produisent le même classement des résultats ; le choix dépend donc souvent de l’efficacité computationnelle.

Quelle base de données vectorielle convient le mieux aux débutants ?

Chroma et pgvector constituent les points de départ les plus accessibles. Chroma s’exécute en processus avec presque aucune configuration, ce qui en fait un choix idéal pour un premier prototype. pgvector est préférable si vous utilisez déjà PostgreSQL, car il ajoute la recherche vectorielle sans introduire un nouveau système à apprendre.

Quel est le coût d’une base de données vectorielle en 2026 ?

Les moteurs open source — Qdrant, Weaviate, Milvus, Chroma, pgvector — sont gratuits à auto-héberger ; vous ne payez que le matériel. Les offres gérées commencent gratuitement, puis progressent par paliers (le plan Builder de Pinecone coûte un forfait fixe de 20 $/mois, le plan Standard environ 50 $/mois, le plan Entreprise environ 500 $/mois), jusqu’à des contrats entreprise destinés aux déploiements à grande échelle, où la facturation à l’usage peut varier considérablement selon votre volume de lectures et d’écritures.

Puis-je utiliser une base de données vectorielle pour des images ou de l’audio, et pas seulement pour du texte ?

Oui. Toute donnée pouvant être encodée par un modèle d’intégration — images, audio, vidéo, code — devient un vecteur que vous pouvez stocker et interroger selon sa similarité. La base de données ne se soucie pas de ce que représentent les vecteurs ; elle effectue uniquement les calculs requis. La récupération multimodale (recherche combinée de texte et d’images) est de plus en plus courante en 2026.

Conclusion

Une base de données vectorielle est la composante d’une pile IA chargée de récupérer des informations selon leur sens, et en 2026, elle n’a plus rien d’exotique — elle fait partie intégrante et standard de la RAG, de la recherche sémantique et des systèmes de recommandation. Le conseil honnête est de résister à la sur-ingénierie. Si vous utilisez déjà PostgreSQL et que vous gérez moins de 10 millions de vecteurs, commencez par pgvector : vous n’aurez probablement jamais besoin de plus. Lorsque vous dépasserez ses limites — milliards de vecteurs, latence inférieure à la dizaine de millisecondes, recherche hybride intensive — les spécialistes open source (Qdrant, Weaviate, Milvus) ainsi que la solution entièrement gérée Pinecone sont tous matures, solidement financés et prêts à l’emploi. Choisissez en fonction de votre échelle réelle et de votre appétence opérationnelle, et non en fonction de la hype, et effectuez des tests de performance (benchmarks) sur vos propres données avant de vous engager.