---
term: 'Base de Données Vectorielle et Embeddings'
seoTitle: 'Bases de données vectorielles et embeddings : HNSW, ANN, en avez-vous besoin ?'
headline: 'Que sont les bases de données vectorielles et les embeddings ?'
slug: base-de-donnees-vectorielle
category: ai-modern-stack
shortDefinition: 'Un embedding est un vecteur numérique qui capture le sens ; une base de données vectorielle stocke et recherche ces vecteurs par similarité, pas par égalité.'
relatedTerms:
- retrieval-augmented-generation-rag
- nosql-vs-sql
- database-index
- access-control-lists-acl
contrastsWith:
- nosql-vs-sql
aboutTerms:
- 'Embeddings'
- 'Vector Database'
- 'HNSW / ANN'
- 'Cosine Similarity'
faq:
- question: "Qu'est-ce qu'un embedding, en termes simples ?"
answer: "Une liste de nombres qu'un modèle attribue à une donnée — un texte, une image, un son — de sorte que les choses de sens proche reçoivent des nombres proches. Deux documents sur le même sujet deviennent des points voisins dans un espace de grande dimension, et c'est ce qui permet à un ordinateur de mesurer ce qui est « similaire »."
- question: "Qu'est-ce qu'une base de données vectorielle ?"
answer: "Un système qui stocke des embeddings et répond rapidement à la question « quels éléments stockés ressemblent le plus à celui-ci ? », en utilisant des index de plus proches voisins approximatifs (ANN) plutôt que des recherches par correspondance exacte. La partie « base de données » — durabilité, mises à jour, filtrage par métadonnées — est ce qui la distingue d'une simple bibliothèque d'index en mémoire."
- question: 'Comment fonctionne la recherche par similarité ?'
answer: "La requête est encodée avec le même modèle, puis comparée aux vecteurs stockés via une métrique de distance : cosinus (l'angle seul), produit scalaire (angle et norme) ou euclidienne (distance en ligne droite). Pour des vecteurs normalisés, les trois classent les résultats de façon identique, et les modèles d'embedding de texte sont généralement calibrés pour le cosinus."
- question: 'Quelle est la différence entre recherche exacte et approximative ?'
answer: "La recherche exacte (kNN) compare la requête à chaque vecteur — rappel parfait, mais temps linéaire, acceptable jusqu'à environ un million de vecteurs. La recherche approximative (ANN, généralement HNSW) saute la plupart des comparaisons pour une vitesse quasi logarithmique, en échangeant quelques points de rappel contre des requêtes plus rapides de plusieurs ordres de grandeur. Manquer de temps en temps le véritable plus proche voisin est généralement acceptable."
- question: "Qu'est-ce que HNSW ?"
answer: "Hierarchical Navigable Small World — l'index ANN dominant en production. Il construit un graphe de proximité multicouche : les couches supérieures, clairsemées, offrent des raccourcis à longue portée, la couche inférieure, dense, contient tous les vecteurs, et la recherche descend de façon gloutonne du grossier au fin. Ses paramètres arbitrent entre rappel, vitesse et mémoire, et le graphe vit en RAM."
- question: "Ai-je besoin d'une base de données vectorielle dédiée ?"
answer: "À l'échelle d'une app, généralement pas. Une base de données généraliste avec support d'index vectoriel — Postgres avec pgvector, la recherche vectorielle de MongoDB — gère confortablement jusqu'à environ un million de vecteurs par nœud, juste à côté de vos données applicatives et de leurs permissions. Les moteurs dédiés se justifient à partir de dizaines de millions de vecteurs, de débits de requêtes très élevés ou d'un rappel élevé sous filtrage intensif."
- question: "Qu'est-ce que le filtrage par métadonnées, et pourquoi est-ce important ?"
answer: "Restreindre la recherche par similarité selon des champs — tenant, catégorie, date, permissions. Le pré-filtrage limite les candidats avant la recherche ANN ; le post-filtrage élague après et peut renvoyer silencieusement moins de résultats que demandé. Les requêtes de production sont presque toujours filtrées, et quand le filtre porte sur les permissions, c'est une frontière de sécurité."
- question: 'À quoi servent les bases de données vectorielles, en dehors du RAG ?'
answer: "Recherche sémantique, recommandations, détection de quasi-doublons et détection d'anomalies ou de fraude (les valeurs aberrantes sont des vecteurs éloignés de tout le reste), sans oublier la similarité d'images et de sons et le clustering. Le RAG est l'usage célèbre ; la recherche par similarité est la capacité générale qui se trouve en dessous."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'HNSW — Malkov & Yashunin (arXiv:1603.09320)'
url: 'https://arxiv.org/abs/1603.09320'
- name: 'Efficient Estimation of Word Representations (word2vec, arXiv:1301.3781)'
url: 'https://arxiv.org/abs/1301.3781'
- name: 'pgvector — open-source vector search for Postgres'
url: 'https://github.com/pgvector/pgvector'
- name: 'MongoDB Vector Search — overview'
url: 'https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/'
cta:
title: 'Des vecteurs à côté de vos données'
text: "Sur Back4app, les embeddings sont de simples champs de type tableau sur vos objets — indexés pour la similarité, filtrés par les mêmes ACL qui protègent tout le reste, générés dans Cloud Code avec la clé du modèle côté serveur."
linkText: 'Commencez gratuitement'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-12'
translationKey: vector-database-embeddings
---
**Un embedding est un vecteur numérique qui capture le sens ; une base de données vectorielle stocke et recherche ces vecteurs par similarité, pas par égalité.** Les deux idées forment une seule capacité : un modèle transforme un texte (ou des images, ou du son) en une liste de nombres positionnée de sorte que *les sens proches atterrissent à proximité*, et une base de données vectorielle trouve rapidement les points les plus proches. C'est tout le secret de la recherche sémantique, des recommandations et du [RAG](/glossary/fr/rag/) — et pour un développeur d'applications, le message pratique est que les embeddings ne sont qu'un champ que vous stockez à côté des données qu'ils décrivent.
## Points clés
| Question | Réponse |
| --- | --- |
| Embedding | Un vecteur où sens proche → points voisins |
| Base de données vectorielle | Stocke des vecteurs + répond à « les plus proches de celui-ci » via des index ANN |
| La métrique | Cosinus (l'usage pour le texte) · produit scalaire · euclidienne |
| Exact vs. ANN | Parfait-mais-linéaire vs. ~99 % de rappel, plus rapide de plusieurs ordres de grandeur |
| Faut-il une base dédiée ? | Généralement pas avant ~1 M+ de vecteurs — votre base de données le fait probablement déjà |
## Les embeddings, concrètement
Oubliez un instant les 1 536 dimensions et imaginez-en trois : un modèle jouet qui note chaque mot selon *est-un-animal*, *est-un-véhicule*, *est-petit*.
```text
animal véhicule petit
chaton 0.95 0.02 0.90
chat 0.93 0.01 0.60
camion 0.03 0.96 0.05
moto 0.04 0.94 0.55
"chaton" est proche de "chat" (tous deux très animal) et loin de "camion".
distance(chaton, chat) → petite → similaires
distance(chaton, camion) → grande → sans rapport
Les vrais modèles utilisent des centaines ou des milliers de dimensions au lieu de trois,
apprises à partir des données plutôt qu'étiquetées à la main — mais l'intuition est exactement celle-ci :
le sens devient géométrie, et "similaire" devient "proche".
```
La démonstration célèbre que cela capture une vraie structure, c'est l'arithmétique sur les vecteurs : dans des [word embeddings entraînés](https://arxiv.org/abs/1301.3781), *roi − homme + femme* atterrit près de *reine*. Le sens transformé en coordonnées fait de l'algèbre.
## Comment fonctionne la recherche par similarité
```mermaid
flowchart LR
accTitle: Des données aux embeddings puis à la recherche par similarité
accDescr: Un modèle encode chaque élément en un vecteur stocké dans un index vectoriel. Au moment de la requête, la requête est encodée avec le même modèle, et l'index renvoie les vecteurs les plus proches selon une métrique de distance, éventuellement filtrés par des métadonnées comme les permissions, classés par similarité.
D["Éléments
(texte, images, son)"] -->|"encodage"| VS["Vecteurs dans un index"]
Q["Requête"] -->|"même modèle"| QV["Vecteur de la requête"]
QV --> S{"Plus proches par
cosinus / scalaire / L2"}
VS --> S
S -->|"filtre par métadonnées / ACL"| K["Top-k résultats
similaires"]
```
Trois métriques de distance dominent : le **cosinus** mesure l'angle entre les vecteurs (en ignorant leur longueur), le **produit scalaire** intègre la norme, et la distance **euclidienne** est la distance en ligne droite. L'idée qui évite bien des confusions : pour des vecteurs *normalisés*, les trois classent les résultats de façon identique, et comme les modèles d'embedding de texte produisent généralement des vecteurs normalisés calibrés pour le cosinus, la question « quelle métrique ? » est le plus souvent déjà tranchée pour vous.
## Exact vs. approximatif : le trade-off de l'ANN
| | Exact (kNN) | Approximatif (ANN) |
| --- | --- | --- |
| Compare à | Chaque vecteur | Un sous-ensemble astucieux |
| Rappel | 100 % | ~95–99 %, réglable |
| Vitesse | Linéaire — O(n) | Quasi logarithmique |
| Suffisant jusqu'à | ~1 M de vecteurs | Des dizaines de millions et plus |
| Coût | CPU par requête | RAM pour le graphe |
La recherche exacte compare la requête à chaque vecteur stocké — parfaite, et parfaitement adaptée jusqu'à environ un million de vecteurs. Au-delà, **[HNSW](https://arxiv.org/abs/1603.09320)** — l'index approximatif dominant — construit un graphe de proximité en couches (des couches supérieures clairsemées pour les grands sauts, une couche inférieure dense qui contient tout) et descend de façon gloutonne du grossier au fin, en sautant la plupart des comparaisons. C'est un [cousin sémantique du B-tree](/glossary/fr/index-de-base-de-donnees/) : là où un B-tree indexe « égal à » et « inférieur à », un index ANN indexe « similaire à ». La réserve honnête que les concurrents édulcorent : l'ANN peut *manquer* le véritable plus proche voisin, ses paramètres arbitrent entre rappel, vitesse et mémoire, et le graphe vit en RAM — c'est pourquoi dimensionner une base de données vectorielle est en réalité une affaire de mémoire.
## Index vectoriel vs. base de données vectorielle
Une distinction que la soupe terminologique brouille : une **bibliothèque d'index** en mémoire (comme FAISS) calcule les plus proches voisins mais ne persiste pas, ne met pas à jour et ne filtre pas — il faut ré-indexer à chaque redémarrage, et il n'y a pas de clause `WHERE`. Une **base de données vectorielle** enveloppe l'index avec la durabilité, les mises à jour incrémentales et le filtrage par métadonnées. Cet écart explique précisément pourquoi « utilisez juste une bibliothèque » échoue en production, et pourquoi *votre base de données existante avec un index vectoriel* est souvent la bonne réponse — elle a déjà la durabilité, les transactions et les permissions qui manquent à la bibliothèque.
## Avez-vous vraiment besoin d'une base de données vectorielle dédiée ?
La réponse neutre que les pages des éditeurs ne peuvent pas donner. Une base de données généraliste avec support vectoriel — Postgres via [pgvector](https://github.com/pgvector/pgvector), les [index vectoriels HNSW de MongoDB](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/) sur des champs de type tableau — sert confortablement **jusqu'à environ un million de vecteurs par nœud**, juste à côté de vos données applicatives et de leurs [permissions](/glossary/fr/listes-de-controle-d-acces-acl/). Un moteur dédié rentabilise son coût d'exploitation et sa *taxe de synchronisation entre deux systèmes* (garder le stockage vectoriel cohérent avec la base de données de référence) à une échelle réellement grande : des dizaines de millions de vecteurs, des débits de requêtes très élevés, ou un rappel élevé exigé *sous* un filtrage intensif. En dessous d'environ un million de vecteurs, un stockage spécialisé coûte généralement plus en code de liaison qu'il ne rapporte en performances — le calcul que la plupart des pages « il vous faut une base de données vectorielle » ne peuvent structurellement pas faire, puisqu'elles sont la base de données vectorielle.
## Le filtrage par métadonnées est la frontière de sécurité
La similarité vectorielle classe par sens et ne sait *rien* de qui a le droit de lire quoi — la requête de production n'est donc jamais « les dix plus proches voisins », mais « les dix plus proches voisins **que cet utilisateur a le droit de voir** ». Inversez l'ordre et ce n'est pas un bug de pertinence, c'est une fuite de données : le **pré-filtrage** réduit les candidats à l'ensemble autorisé *avant* la recherche ANN (correct) ; le **post-filtrage** élague après, ce qui divulgue l'existence des éléments interdits et renvoie silencieusement moins de *k* résultats. Quand le filtre porte sur les [ACL](/glossary/fr/listes-de-controle-d-acces-acl/), le pré-filtrage fait la différence entre une recherche sémantique et une brèche — la même leçon que le [RAG](/glossary/fr/rag/) apprend à ses dépens. Stocker les embeddings dans la base de données qui applique déjà vos permissions, c'est obtenir le filtre gratuitement.
## Les embeddings dans du vrai code
**JavaScript:**
```javascript
// JavaScript — Cloud Code (cloud/main.js)
// Embeddings live as a field next to the data they describe
Parse.Cloud.beforeSave('Doc', async (req) => {
if (req.object.dirty('text')) {
// generate server-side; embedding API key stays on the server
req.object.set('embedding', await embed(req.object.get('text')));
req.object.set('embedModel', 'text-embed-v3'); // version it — models differ
}
});
// Similarity search, ACL-filtered: "nearest neighbors this user MAY see"
Parse.Cloud.define('semanticSearch', async (req) => {
const qVec = await embed(req.params.q);
return vectorSearch('Doc', qVec, { limit: 10, aclUser: req.user });
// The pre-filter is the security boundary, not a relevance tweak.
});
```
**Flutter:**
```dart
// Flutter / Dart — Back4app Flutter SDK
// The client searches by meaning — the vector math is server-side
final results = await ParseCloudFunction('semanticSearch')
.execute(parameters: {'q': 'how do refunds work?'});
for (final doc in results.result) print(doc['title']);
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.
```
**Swift:**
```swift
// iOS / Swift — Back4app Swift SDK
// The client searches by meaning — the vector math is server-side
let results: [[String: Any]] = try await Cloud.run(
name: "semanticSearch",
parameters: ["q": "how do refunds work?"])
for doc in results { print(doc["title"] ?? "") }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.
```
**Kotlin:**
```kotlin
// Android / Kotlin — Back4app Android SDK
// The client searches by meaning — the vector math is server-side
val params = mapOf("q" to "how do refunds work?")
val results = ParseCloud.callFunction>>(
"semanticSearch", params)
results.forEach { println(it["title"]) }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.
```
Remarquez le champ `embedModel` : les vecteurs issus de modèles différents — ou de *versions* différentes d'un même modèle — ne sont pas comparables, donc changer de modèle d'embedding implique de ré-encoder tout le corpus. Stockez le nom du modèle avec les vecteurs, sinon une mise à niveau silencieuse transforme votre index en bruit.
## Cas d'usage courants
- **Recherche sémantique** — « je veux être remboursé » trouve « politique de remboursement » alors qu'aucun mot-clé n'est partagé.
- **[Récupération pour le RAG](/glossary/fr/rag/)** — aller chercher les chunks qui ancrent la réponse d'un LLM.
- **Recommandations** — les éléments proches de l'historique d'un utilisateur dans l'espace des embeddings.
- **Déduplication et clustering** — un contenu quasi identique donne des vecteurs quasi identiques.
- **Détection d'anomalies et de fraude** — les valeurs aberrantes sont des vecteurs éloignés de tous les exemples normaux.
## Où vos vecteurs doivent-ils vivre ? Matrice de décision
| Situation | Choisissez |
| --- | --- |
| Corpus à l'échelle d'une app (< ~1 M de vecteurs) | L'index vectoriel de votre base de données — à côté des données |
| Les vecteurs doivent respecter les permissions des utilisateurs | Là où se trouvent déjà les [ACL](/glossary/fr/listes-de-controle-d-acces-acl/) |
| Des dizaines de millions de vecteurs, QPS élevé | Un moteur vectoriel dédié |
| Termes exacts *et* sens comptent tous les deux | Recherche hybride avec fusion de classements |
| Un prototype rapide | pgvector, ou un stockage embarqué — ne sur-construisez pas |
| Un seul processus, aucune persistance nécessaire | Une bibliothèque d'index (FAISS) — en acceptant ses limites |
## Limites et trade-offs
- **Les embeddings encodent la vision du monde du modèle.** Biais, angles morts et date de coupure de l'entraînement suivent le mouvement ; la géométrie ne vaut que ce que vaut le modèle qui l'a tracée.
- **L'ANN est approximatif par conception.** Réglez le rappel selon les enjeux ; « trouve généralement la meilleure correspondance » est le contrat que vous avez signé en échange de la vitesse.
- **La version du modèle est un schéma.** Ré-encoder un grand corpus lors d'un changement de modèle est une vraie migration, pas un simple réglage de configuration.
- **La mémoire est le plafond.** Les graphes HNSW vivent en RAM ; les limites de vecteurs par nœud sont des limites de mémoire sous une autre étiquette.
- **La similarité n'est pas la pertinence.** Être proche dans l'espace vectoriel est un signal fort, pas une garantie — la recherche hybride et le re-ranking existent parce que la recherche vectorielle pure rate les termes exacts.
## Les vecteurs sur Back4app
Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Comme elle repose sur MongoDB, le stockage suit exactement ce que recommande cet article : un embedding est un **champ de type tableau sur l'objet qu'il décrit** — le document et son vecteur dans le même enregistrement — avec l'indexation vectorielle HNSW comme véritable mécanisme sous-jacent. Les conséquences s'enchaînent proprement : les [ACL](/glossary/fr/listes-de-controle-d-acces-acl/) qui gouvernent déjà chaque requête deviennent *gratuitement* le pré-filtre de la recherche par similarité, si bien que la récupération ne peut pas franchir une frontière de permissions ; les embeddings sont générés dans un trigger `beforeSave` de [Cloud Code](/glossary/fr/cloud-code-fonctions-serverless/) qui appelle un modèle d'embedding avec la [clé gardée côté serveur](/glossary/fr/securite-des-cles-d-api/) ; et il n'y a aucun service vectoriel séparé à synchroniser, sécuriser et payer. Pour les corpus à l'échelle d'une app que la plupart des produits ont réellement, la « base de données vectorielle » n'est pas un système à adopter — c'est un champ à ajouter.