Embeddings : comment choisir le bon modèle pour votre cas d'usage
En bref
Embeddings en 2026 : comparatif OpenAI, Voyage, Cohere, Mistral, BGE M3, E5. Critères dimension, MTEB, multilingue, coût, latence par cas d'usage.
Le choix du modèle d’embeddings est souvent l’angle mort des projets RAG, search ou classification IA. Beaucoup d’équipes prennent par défaut text-embedding-3-small d’OpenAI sans benchmarker, et découvrent six mois plus tard que leur recall stagne à 60 % alors qu’un Voyage AI ou un BGE M3 aurait livré 85 % sur le même corpus français. À l’inverse, certaines équipes choisissent un gros modèle 3072 dimensions « pour être tranquilles » et explosent leur facture vector DB inutilement. Cet article fait le tour des critères de choix (dimension, performance MTEB, multilingue, coût, latence, taille de contexte) et propose un comparatif des modèles dominants en 2026 (OpenAI text-embedding-3, Voyage AI, Cohere Embed v3, Mistral Embed, BGE M3, E5 multilingue) avec des recommandations par cas d’usage : RAG corporate français, search produit e-commerce, dédoublonnage et classification.
1. Comprendre ce qu’est vraiment un bon embedding
Un embedding est une représentation vectorielle d’un texte (mot, phrase, document) dans un espace de quelques centaines à quelques milliers de dimensions. Deux textes sémantiquement proches y sont proches au sens de la similarité cosinus.
Mais « proches au sens de la similarité » n’est pas une qualité absolue : c’est un alignement avec ce que vous voulez retrouver. Un embedding excellent pour du clustering peut être médiocre pour du retrieval, et inversement. D’où l’importance d’évaluer sur votre cas d’usage, pas seulement de regarder un benchmark agrégé.
2. Les six critères de choix
Critère 1 : performance — benchmark MTEB et alternatives
MTEB (Massive Text Embedding Benchmark) est le standard de fait : 56 datasets couvrant retrieval, clustering, classification, reranking, semantic textual similarity. Le classement des modèles est tenu à jour publiquement selon le MTEB Leaderboard sur Hugging Face. Pour le français, MTEB-fr existe depuis 2024 et est plus représentatif si votre corpus est francophone.
Attention : un score MTEB élevé global ne garantit pas la performance sur votre domaine (médical, juridique, code, technique industriel). Mesurez sur 200-500 paires positives/négatives extraites de votre corpus avant de figer un choix.
Critère 2 : dimension du vecteur
| Dimension | Impact |
|---|---|
| 384 | Très léger, rapide, faible coût stockage |
| 768 | Standard, bon compromis |
| 1024 | Confortable, recall typiquement >+5 % vs 768 |
| 1536-3072 | Premium, gain marginal vs coût stockage important |
Un index 1M vecteurs en 3072 dim coûte ~12 Go RAM, contre ~3 Go en 768 dim. Sur Pinecone, Qdrant Cloud ou Weaviate Cloud, la facture suit.
Bonne nouvelle : les modèles modernes (OpenAI text-embedding-3, Mistral Embed, Nomic Embed) supportent Matryoshka Representation Learning — vous pouvez tronquer la dimension sans réentraîner avec une perte minime jusqu’à un certain seuil.
Critère 3 : multilingue ou non
Si votre corpus mélange français + anglais (cas typique d’une entreprise française qui consomme aussi de la doc EN), un modèle nativement multilingue comme BGE M3, E5 multilingual, Cohere multilingual ou Voyage sera nettement supérieur à un modèle anglo-centré. Les embeddings d’OpenAI sont corrects en français mais clairement entraînés majoritairement en anglais.
Critère 4 : coût
| Modèle | Tarif input ($/M tokens) | Notes |
|---|---|---|
| OpenAI text-embedding-3-small | 0,02 | Très bon rapport qualité/prix |
| OpenAI text-embedding-3-large | 0,13 | Premium |
| Voyage voyage-3 | 0,06 | Top MTEB-fr |
| Voyage voyage-3-large | 0,18 | Premium retrieval |
| Cohere Embed v3 | 0,10 | Multilingue solide |
| Mistral Embed | 0,10 | EU, souverain |
| BGE M3 (self-host) | ~0,005 (coût GPU) | Open source |
| E5-mistral-7b (self-host) | ~0,01 | Open source heavy |
À partir de ~50 millions de tokens embedés par mois, le self-hosting (BGE M3 sur L4 ou A10G) devient rentable.
Critère 5 : latence et taille de contexte
| Modèle | Context max | Latence typique (1k tokens) |
|---|---|---|
| OpenAI text-embedding-3 | 8 192 | 100-200 ms |
| Voyage voyage-3 | 32 000 | 200-300 ms |
| Cohere Embed v3 | 512 | 80-150 ms |
| Mistral Embed | 8 192 | 100-200 ms |
| BGE M3 | 8 192 | 50-100 ms (self-host GPU) |
Cohere Embed v3 a une fenêtre courte (512 tokens), ce qui force un chunking plus agressif. Voyage 3 supporte 32k tokens, utile pour des documents longs sans découpage complexe.
Critère 6 : souveraineté et conformité
Si vous opérez sur données sensibles (santé, défense, finance régulée), Mistral Embed (Paris, hébergement EU) et les modèles open source self-hostés sur cloud souverain (OVH, Outscale, Scaleway) sont des choix structurants au-delà de la performance brute.
3. Tableau comparatif synthétique
| Modèle | Dim | Perfo MTEB-fr | Multilingue | Coût | Souverain | Force |
|---|---|---|---|---|---|---|
| OpenAI 3-small | 1536 (truncable) | Bonne | Oui (limité) | Bas | Non | Référence rapport qualité/prix |
| OpenAI 3-large | 3072 (truncable) | Très bonne | Oui (limité) | Moyen | Non | Précision, écosystème |
| Voyage 3 | 1024 | Très bonne | Oui | Bas | Non | Top FR, contexte 32k |
| Voyage 3-large | 1024 | Excellente | Oui | Moyen | Non | Retrieval premium |
| Cohere Embed v3 | 1024 | Bonne | Oui (excellent) | Moyen | Non | Multilingue, reranker associé |
| Mistral Embed | 1024 | Très bonne | Oui (FR fort) | Moyen | EU | Souveraineté, qualité FR |
| BGE M3 | 1024 | Excellente | Oui (100+) | Très bas (self-host) | Oui (self-host) | Open source, multi-fonction |
| E5 multilingual | 1024 | Bonne | Oui | Très bas (self-host) | Oui (self-host) | Open source, léger |
4. Recommandations par cas d’usage
RAG corporate français (intranet, doc métier, support)
Recommandation principale : Voyage 3 ou Mistral Embed si souveraineté requise.
- Voyage 3 obtient les meilleurs scores MTEB-fr en API, contexte 32k pour limiter le chunking complexe.
- Mistral Embed pour les acteurs régulés (banque, assurance, secteur public, santé).
- Couplez systématiquement avec un reranker (Cohere Rerank v3 ou BGE Reranker) sur le top-30 → top-3.
Pour le déploiement complet, voir notre guide RAG entreprise 2026.
Search produit e-commerce (catalogue, descriptions FR/EN)
Recommandation principale : Cohere Embed v3 multilingual ou OpenAI text-embedding-3-small.
- Catalogue produit = textes courts (titre + description) → la limite 512 tokens de Cohere n’est pas pénalisante.
- Cohere Rerank v3 directement intégrable pour la phase de reranking.
- OpenAI 3-small en 768 ou 1024 tronqué = excellent rapport qualité/prix sur des volumes massifs.
Dédoublonnage / clustering / déduplication CRM
Recommandation principale : BGE M3 self-host ou OpenAI 3-small tronqué à 384.
- Vous embedez probablement des millions de records → coût primordial.
- La performance absolue compte moins que la séparabilité des clusters.
- BGE M3 multi-fonction (dense + sparse + ColBERT) particulièrement utile pour matching de noms / adresses.
Classification (intent, sentiment, topic)
Recommandation principale : embeddings + classifieur léger avec BGE M3, E5 ou OpenAI 3-small.
- Pas besoin du top du top en retrieval : la couche classifier (logreg, XGBoost, MLP léger) compense.
- Self-host pertinent dès que volume > 5M docs/mois.
- Avantage : indépendance modèle (vous changez la couche classifier sans réembedder).
Code search / documentation technique
Recommandation principale : Voyage code-3 ou OpenAI text-embedding-3-large sur 3072 dim.
- Voyage propose un modèle dédié au code, gros gain sur retrieval de fonctions.
- À défaut, OpenAI large en pleine dimension performe bien sur du code commenté.
5. Stack pratique : index et infra
Choisir un modèle d’embedding est indissociable du choix d’index vectoriel : la dimension impacte directement coût et latence.
| Vector DB | Force | Quand |
|---|---|---|
| Postgres + pgvector | Simple, transactionnel | <10M vecteurs, projet single source-of-truth |
| Qdrant | Performant, open source | scale-up, on-prem possible |
| Weaviate | Hybrid search natif | besoin BM25 + vector |
| Pinecone | Managé, scale | gros volumes, peu d’ops |
| Milvus | Open source haute échelle | >100M vecteurs |
Pour le détail de la couche infra, lisez notre fiche bases vectorielles : choix techniques 2026.
6. Méthodologie d’évaluation rapide (1 journée)
- Échantillon : 200-500 requêtes utilisateurs réelles + ground truth (doc attendu).
- Embedder chaque requête et chaque doc avec 3 candidats (typiquement Voyage 3, OpenAI 3-small, Mistral Embed).
- Indexer dans Qdrant local en 3 collections.
- Mesurer : Recall@5, Recall@10, MRR.
- Coupler avec un reranker pour mesurer le gain.
- Décider sur la combinaison
coût × Recall@10qui dépasse votre seuil métier.
Trois jours-homme pour économiser 6 mois de frustration produit : c’est probablement le meilleur ROI d’ingénierie sur un projet RAG.
Le cas du français : ce que les classements ne disent pas
La plupart des classements agrègent de nombreuses tâches et restent fortement influencés par l’anglais. Un modèle peut donc gagner quelques places grâce à ses résultats sur des corpus anglophones sans mieux retrouver une procédure, un contrat ou un courrier administratif rédigé en français. Le score global est utile pour établir une liste de candidats ; il ne tranche pas le choix d’un système destiné à votre organisation.
Sur un corpus français, les difficultés sont concrètes. Le vocabulaire métier contient des sigles ambigus, des noms de produits et des formulations propres à une profession. Les accords, les formes conjuguées et les négations modifient le sens d’une demande. Les documents administratifs ajoutent des références, des intitulés longs et des expressions proches qui ne sont pourtant pas interchangeables. Un moteur doit par exemple distinguer une pièce « à fournir » d’une pièce « déjà fournie », ou une règle générale de son exception.
Un modèle multilingue généraliste peut alors battre un modèle mieux classé au niveau global, parce que son espace vectoriel aligne mieux les variantes françaises et les passages bilingues. L’avantage n’est pas garanti : il doit être mesuré. Constituez un échantillon de requêtes réelles, incluant fautes, abréviations et questions indirectes, puis associez à chacune les documents attendus. Ajoutez des négatifs difficiles, c’est-à-dire des textes proches mais incorrects.
Comparez ensuite plusieurs modèles avec le même découpage, le même index et les mêmes paramètres. Regardez les documents retrouvés dans les premiers résultats, mais aussi les échecs par catégorie : vocabulaire métier, négation, date, référence ou mélange français-anglais. Faites enfin relire les cas litigieux par une personne du métier. Cette évaluation locale, même sur quelques centaines de demandes, renseigne davantage qu’un écart minime dans un classement général.
Quand faut-il réindexer, et ce que ça coûte
Changer de modèle d’embeddings oblige à recalculer les vecteurs de tous les documents et de toutes les requêtes indexées. Deux modèles ne placent pas les textes dans le même espace, même lorsqu’ils produisent des vecteurs de dimension identique. Mélanger anciens et nouveaux vecteurs dans une collection rend donc les distances incohérentes. Une modification de dimension, de découpage des documents ou de normalisation impose la même prudence.
Le coût comprend les appels au modèle ou le temps GPU, mais aussi la lecture du corpus, le nettoyage, l’écriture dans la base vectorielle et les contrôles. Pour quelques centaines de milliers de passages, l’opération peut tenir en quelques heures et représenter un budget limité. Sur plusieurs dizaines de millions de passages, elle peut durer plusieurs jours, mobiliser une infrastructure parallèle et coûter de l’ordre de plusieurs milliers à quelques dizaines de milliers d’euros selon le modèle, le débit et les reprises nécessaires. Ces montants sont des ordres de grandeur à recalculer sur un échantillon réel.
Une réindexation ne doit pas créer de coupure. Construisez une nouvelle collection versionnée à côté de l’ancienne, alimentez-la depuis une copie figée, puis rejouez les documents arrivés pendant le calcul. Vérifiez le nombre d’objets, les métadonnées et la qualité de recherche avant de basculer progressivement le trafic. Le retour arrière consiste alors à repointer vers l’ancien index, qui reste intact jusqu’à validation.
Ce coût futur doit peser dans le choix initial. Il favorise un modèle évalué sur la langue et le domaine, une pipeline reproductible, des documents sources conservés et une base capable de gérer deux index temporairement. Choisir uniquement le tarif d’embedding du jour peut créer une économie minime, puis une migration coûteuse lorsque les limites apparaissent en production.
Conclusion : ne déléguez pas le choix au défaut
Le bon embedding est rarement le plus vendu, et presque jamais celui que votre stagiaire a câblé en premier dans le tutoriel LangChain. C’est le résultat d’une évaluation sur votre corpus, votre langue, votre dimension de contrainte (coût, souveraineté, latence). En 2026, l’écosystème offre des options excellentes en API et open source : prenez une journée pour benchmarker, vous gagnerez 10 à 30 points de recall et la moitié de votre facture vector DB.
Notre équipe accompagne la conception et le déploiement de moteurs RAG et search dans le cadre de projets SaaS IA — du choix d’embedding à la mise en production.
Vous avez un projet IA ? → Parlons-en