L'état de l'art des embeddings en 2026 : le moteur du RAG

Un embedding est la représentation vectorielle d'un texte : une liste de nombres, par exemple [0.23, -0.87, 0.45, …], qui encode le sens d'une phrase dans un espace mathématique à plusieurs centaines de dimensions. La propriété fondamentale : deux textes sémantiquement proches produisent des vecteurs proches.

L'analogie la plus parlante que j'utilise en réunion de cadrage reste géographique. Imaginez que chaque phrase est une ville sur une carte. « L'intelligence artificielle transforme l'industrie » et « L'IA révolutionne le secteur économique » se situent à deux kilomètres l'une de l'autre ; « Les pandas mangent du bambou » se trouve à 800 kilomètres. L'embedding, c'est le GPS qui assigne des coordonnées à chaque phrase. La recherche de pertinence devient alors une navigation géométrique : on mesure la similarité cosinus entre le vecteur de la question et ceux des documents.

C'est le socle de toute architecture RAG. Le principe : on encode l'intégralité de la base documentaire en vecteurs, stockés dans une base vectorielle (pgvector, Qdrant, Milvus). À chaque question de l'utilisateur, on encode la requête, on retrouve les passages géométriquement les plus proches, et on les injecte dans le contexte du modèle génératif. Si l'embedding place mal les documents, le modèle génératif reçoit des passages hors-sujet et invente sa réponse. Le maillon faible du RAG n'est presque jamais le LLM final : c'est la qualité de la représentation vectorielle en amont.

Pour une PME, cela change la hiérarchie des priorités. Avant d'investir dans un modèle génératif plus gros, il faut sécuriser l'étage de récupération. Ce comparatif s'inscrit dans cette logique : un embedding médiocre ne se rattrape pas en aval.

Comprendre le benchmark MTEB pour arbitrer ses choix

Le MTEB (Massive Text Embedding Benchmark) est le standard industriel pour évaluer les embeddings. Il couvre 56 jeux de données et 8 types de tâches distinctes. L'erreur classique, que je vois répétée dans quasiment tous les cahiers des charges mal construits, consiste à choisir un modèle sur son score global. Or ce score agrège des tâches sans rapport avec un RAG.

Voici les tâches à connaître et leur pertinence réelle :

Tâche MTEB Description Pertinent pour
Retrieval Retrouver le passage pertinent à une requête RAG, moteur de recherche
STS (Semantic Textual Similarity) Mesurer la similarité entre deux phrases Déduplication, clustering
Classification Classer des textes Modération, analyse de sentiment
Clustering Regrouper des documents similaires Organisation de contenu
Reranking Réordonner des résultats de recherche Pipeline RAG avancé

Pour un RAG, deux sous-tâches priment : Retrieval (votre cœur de métier) et STS. Le reste est du bruit décisionnel. Second réflexe indispensable : vérifier que l'évaluation porte sur des jeux de données dans votre langue. Un modèle brillant sur des benchmarks anglophones peut s'effondrer sur des requêtes françaises, car les datasets MTEB par défaut sont majoritairement anglocentrés. Le leaderboard MTEB, maintenu sur Hugging Face, permet de filtrer par langue et par tâche : c'est cette vue qu'il faut consulter, jamais le classement généraliste. Pour comprendre le vocabulaire sous-jacent (vecteur, similarité cosinus, tokenisation), notre glossaire de l'IA détaille chaque terme.

Nomic-embed-text : la référence de l'open-source performant

Nomic-embed-text occupe une place particulière dans le paysage 2026 : c'est le modèle du puriste de la reproductibilité. Publié par Nomic AI sous licence Apache 2.0, il est entièrement ouvert — poids, code d'entraînement et données. Pour une entreprise soumise à des exigences d'auditabilité, cette transparence intégrale a une valeur réelle : on peut documenter exactement d'où vient le modèle, une exigence que je retrouve systématiquement dans les audits de conformité.

Ses caractéristiques techniques : 768 dimensions, un excellent rapport coût-qualité, un déploiement local via Ollama en quelques minutes, et des capacités multimodales émergentes. Sur la tâche Retrieval du MTEB, il se situe autour de 52,8, un score honorable qui le place devant les petits modèles mono-langue tout en restant en deçà des champions multilingues.

Son positionnement idéal :

  • Équipes techniques cherchant la reproductibilité totale sans dépendance à une API tierce et sans frais d'inférence récurrents, ce qui simplifie considérablement le budget d'un POC.
  • Corpus majoritairement anglophones ou techniques (documentation informatique, dépôts de code), domaine où Nomic excelle et où sa dimension modeste accélère la recherche vectorielle.
  • Projets nécessitant un déploiement léger sur des serveurs contraints, ses 768 dimensions limitant l'empreinte mémoire de la base vectorielle par rapport aux modèles 1024 ou 3072.

La limite à connaître : sur des requêtes purement françaises avec des nuances métier fortes (juridique, comptable), Nomic reste moins fin que BGE-M3. Il rend d'énormes services, mais je ne le recommande pas en première intention pour un RAG francophone à forte charge sémantique.

BGE-M3 de BAAI : le champion du multilingue hybride

BGE-M3, développé par la Beijing Academy of Artificial Intelligence (BAAI), est le modèle que je recommande le plus souvent pour un RAG français souverain. Gratuit, local, il a été entraîné sur plus de 100 langues, dont un français substantiel. Sur la tâche Retrieval du MTEB, il affiche environ 54,8 — au-dessus de Nomic et proche des modèles propriétaires payants.

Sa singularité technique justifie le sigle « M3 » : il produit simultanément trois types de représentations à partir d'un seul passage encodé.

  • Dense : le vecteur classique de 1024 dimensions pour la similarité sémantique, le mode de recherche standard d'un RAG.
  • Sparse (creux) : une représentation façon BM25 qui capture la correspondance lexicale exacte, précieuse pour les termes rares, références réglementaires ou noms propres qu'un vecteur dense a tendance à lisser.
  • ColBERT (multi-vecteurs) : une représentation fine token par token, permettant un ré-ordonnancement de haute précision en fin de pipeline.

Cette capacité de recherche hybride native est décisive en contexte métier français. Prenons un cabinet comptable de douze salariés qui interroge sa base sur « l'article 39 du CGI » : la représentation dense comprend l'intention sémantique, tandis que la représentation creuse garantit que la référence exacte « article 39 » remonte en tête. On combine les deux et le rappel grimpe nettement par rapport à une recherche purement dense.

Autre atout pratique : le téléchargement pèse environ 400 Mo depuis Hugging Face, l'installation se résume à pip install sentence-transformers puis un appel à BAAI/bge-m3. Pour une PME qui veut rester 100 % local, gratuite et conforme, c'est le meilleur point d'équilibre du marché en 2026. C'est aussi un modèle éligible aux plateformes souveraines : l'administration met à disposition des modèles open source hébergés en France via Albert API, sans transfert de données aux fournisseurs.

Cohere mxbai : l'excellence propriétaire pour l'entreprise

Face aux modèles ouverts, les solutions propriétaires accessibles par API — Cohere embed-v4 en tête, aux côtés des variantes mxbai — jouent la carte de la qualité prête à l'emploi. Sur la tâche Retrieval du MTEB, embed-v4 atteint environ 56,9, le meilleur score de notre panel, avec un multilingue qualifié d'excellent sans configuration particulière.

Trois arguments pèsent en faveur de cette voie en entreprise :

  • Qualité multilingue « out-of-the-box » : aucune sélection de checkpoint, aucune bataille de fine-tuning. On appelle l'API, le français est traité au niveau des meilleurs modèles du marché, ce qui raccourcit drastiquement le temps de mise en production.
  • Options de quantification (int8, binaire) : Cohere permet de compresser les vecteurs pour réduire massivement le coût de stockage d'une base de plusieurs millions de documents, tout en préservant l'essentiel de la qualité de rappel.
  • Robustesse sur requêtes complexes : sur des formulations longues, ambiguës ou multi-critères typiques des utilisateurs en entreprise, ces modèles se montrent plus stables que les alternatives locales légères.

Le tableau de synthèse ci-dessous récapitule le panel élargi, scores Retrieval MTEB à l'appui :

Modèle Éditeur Dimensions Coût/1M tokens Multilingue MTEB Retrieval Accès
embed-v4 Cohere 1024 ~0,10 $ Excellent 56,9 API
text-embedding-3-large OpenAI 3072 ~0,13 $ Moyen 55,4 API
BGE-M3 BAAI 1024 Gratuit Excellent 54,8 Local
Nomic-embed-text Nomic AI 768 Gratuit Moyen 52,8 Local/API
E5-large-v2 Microsoft 1024 Gratuit Bon 50,6 Local
all-MiniLM-L6-v2 sentence-transformers 384 Gratuit Faible 41,0 Local

Le revers de la médaille est structurel : appeler une API propriétaire signifie faire transiter vos textes hors de votre système d'information. C'est précisément le point d'arbitrage souverain que nous traitons plus loin.

Le défi du français : tokenisation et déséquilibres de données

Pourquoi certains modèles s'effondrent-ils sur le français ? Trois facteurs techniques, que je documente systématiquement en phase d'audit, l'expliquent.

1. Tokenisation défavorable. Le français multiplie accents, apostrophes et élisions (« l'entreprise », « aujourd'hui »). Les tokeniseurs entraînés majoritairement sur l'anglais découpent mal ces séquences, fragmentant des mots en sous-unités peu porteuses de sens. Résultat : la représentation vectorielle perd en finesse, et deux formulations françaises équivalentes se retrouvent artificiellement éloignées.

2. Déséquilibre des corpus d'entraînement. La majorité des données d'entraînement des embeddings sont anglophones. Un modèle comme all-MiniLM-L6-v2 a été entraîné sur des corpus essentiellement anglais : son score Retrieval de 41,0 s'effondre en pratique sur des requêtes françaises réelles. Ce n'est pas un défaut du modèle, c'est un défaut d'usage — l'employer sur du français relève de l'erreur de casting.

3. Nuances syntaxiques manquées. Des constructions propres au français — la négation discontinue « ne… pas », la concordance des temps, les tournures impersonnelles — sont mal capturées par un modèle mono-langue. « Le contrat n'est pas résilié » et « Le contrat est résilié » doivent produire des vecteurs éloignés ; un modèle anglocentré les rapproche dangereusement, avec des conséquences directes sur la fiabilité d'un RAG juridique.

Une expérimentation simple objective ces écarts. En comparant la similarité cosinus entre « L'intelligence artificielle transforme l'industrie » et « L'IA révolutionne le secteur économique », un bon modèle multilingue (BGE-M3, paraphrase-multilingual-MiniLM) renvoie un score d'environ 0,72, tandis qu'un modèle anglais chute nettement. Sur la paire hors-sujet avec les pandas, tous descendent autour de 0,18 : la discrimination sémantique du français est bien le point de rupture. Conclusion opérationnelle : pour un corpus majoritairement francophone, BGE-M3 ou embed-v4 sont des choix par défaut ; les modèles mono-langue anglais sont à écarter.

Arbitrage technique : dimensions, latence et coûts de stockage

« Prenons le modèle avec le plus de dimensions » : cette phrase, entendue en réunion, cache un piège budgétaire. Plus de dimensions signifie des vecteurs plus expressifs, donc une meilleure séparation sémantique potentielle — mais aussi davantage de stockage, plus de RAM et des calculs de similarité plus lents.

Voici la règle pratique que j'applique :

  • 384 dimensions (MiniLM) : adapté aux prototypes et petites bases de moins de 100 000 documents. Recherche ultra-rapide, empreinte minimale, mais plafond de qualité vite atteint.
  • 768 à 1024 dimensions (Nomic, BGE-M3, embed-v4) : le compromis de production. C'est là que se situe la quasi-totalité des projets d'entreprise sérieux.
  • 3072 dimensions (text-embedding-3-large) : réservé aux cas où chaque point de score MTEB est critique, au prix d'un stockage quatre fois supérieur à un modèle 768.

L'impact économique devient tangible à l'échelle. Pour une base de plusieurs millions de documents, passer de 3072 à 1024 dimensions divise par trois l'empreinte de la base vectorielle — donc la RAM nécessaire et la facture d'infrastructure. C'est ici que la quantification (int8, binaire) proposée par Cohere ou applicable localement prend tout son sens : elle réduit encore le stockage sans effondrement de qualité. Avant d'arbitrer, chiffrez le retour sur investissement réel de votre projet : notre calculateur de ROI IA intègre ces coûts d'infrastructure souvent sous-estimés.

Sécurité et souveraineté : conformité RGPD et AI Act

C'est le point où le choix technique devient un choix de conformité. Dès lors que vous encodez des données personnelles ou sensibles, la CNIL rappelle que la sécurité du traitement est une obligation posée par l'article 32 du RGPD, à apprécier selon l'état de l'art et les risques. Sa fiche de janvier 2026 sur la sécurité du développement des systèmes d'IA identifie explicitement les risques de mémorisation, de reconstruction et d'inférence d'appartenance : un modèle entraîné sur des données personnelles peut, dans certaines conditions, laisser fuiter des informations sur les individus. Voir les recommandations de la CNIL et l'ANSSI sur les systèmes d'IA générative.

Deux conséquences architecturales concrètes :

  • Appeler une API propriétaire, c'est faire sortir vos textes de votre SI. Pour des données à caractère personnel, ce transfert doit être encadré (base légale, localisation, sous-traitance article 28). Pour des données sensibles ou stratégiques, l'hébergement local d'un modèle ouvert comme BGE-M3 — ou le recours à une plateforme souveraine française — élimine le problème à la racine.
  • La provenance du modèle est un risque de sécurité en soi. La CNIL et l'ANSSI alertent sur les composants non audités issus de plateformes collaboratives (fichiers corrompus, portes dérobées). Un modèle sous licence claire et audité, déployé dans votre périmètre, réduit cette surface d'attaque.

Côté cadre réglementaire, le Règlement (UE) 2024/1689 — l'AI Act, amendé par l'« omnibus numérique » entré en vigueur le 27 juillet 2026 — encadre les usages selon leur niveau de risque, avec une application générale au 2 août 2026 et des obligations renforcées pour les systèmes à haut risque de l'annexe III à compter du 2 décembre 2027. Un moteur d'embedding n'est pas en soi un système à haut risque, mais il peut être une brique d'un tel système (scoring, RH, biométrie) : pour cartographier vos obligations précises, appuyez-vous sur le guide de mise en conformité des PME françaises. Le cadre européen d'ensemble est présenté par la Commission européenne. Notre hub AI Act et notre page solutions métiers détaillent l'accompagnement IAPRO.

Vers le multimodal : intégrer images et documents complexes

Le RAG de 2026 ne se limite plus au texte. Vos utilisateurs veulent interroger des schémas techniques, des plans, des captures de factures ou des photos de produits. C'est le domaine des embeddings multimodaux, qui alignent des modalités différentes — image et texte — dans un même espace vectoriel. On peut alors chercher une image à partir d'une description textuelle, ou l'inverse : la recherche devient cross-modale.

Trois familles structurent le paysage :

  • CLIP (OpenAI), le pionnier qui a démocratisé l'alignement image-texte et reste une base de référence pour de nombreuses implémentations.
  • SigLIP 2 (Google), qui améliore la robustesse de l'alignement grâce à une fonction de perte sigmoïde, avec de meilleurs résultats sur des jeux de données variés.
  • Jina CLIP v2, qui pousse la dimension multilingue du multimodal — un atout direct pour des documents français mêlant texte et visuels.

Pour une PME industrielle qui documente ses pièces par des photos annotées, ou un cabinet qui archive des documents scannés hétérogènes, ces modèles ouvrent une recherche unifiée. Le principe reste identique — encoder puis retrouver par similarité — mais l'espace vectoriel accueille désormais plusieurs modalités. C'est un chantier à traiter dans un second temps : sécurisez d'abord votre RAG textuel avec BGE-M3 ou Cohere avant d'ajouter la couche multimodale.

Guide de déploiement : choisir son stack en production

Traduisons ce comparatif embeddings 2026 en décision. Deux cas d'usage couvrent l'essentiel des besoins que je rencontre.

Cas 1 — RAG français haute performance via API. Objectif : qualité maximale, mise en production rapide, données non sensibles ou transfert encadré. Stack recommandée : Cohere embed-v4 en 1024 dimensions, base vectorielle pgvector ou Qdrant, quantification int8 si le volume dépasse quelques millions de documents. Idéal pour un moteur de recherche interne sur de la documentation non confidentielle.

Cas 2 — Souveraineté totale et gratuité locale. Objectif : données personnelles ou stratégiques, aucun transfert hors du SI, budget d'inférence nul. Stack recommandée : BGE-M3 déployé localement via Ollama ou sentence-transformers, recherche hybride dense + creuse pour exploiter ses trois représentations, base pgvector auto-hébergée. C'est la configuration que je privilégie pour un cabinet comptable ou un cabinet d'avocats de dix à quinze salariés soumis au secret professionnel.

L'intégration reste simple avec un framework comme Agno, qui abstrait le fournisseur d'embedding derrière une classe standardisée : changer de modèle ne coûte qu'une ligne de code. On peut ainsi démarrer sur BGE-M3 en local, mesurer le rappel réel sur son corpus, puis basculer vers Cohere si le gain de qualité justifie l'API — sans réécrire le pipeline. Cette réversibilité est un principe directeur de la méthode IAPRO : ne jamais s'enfermer dans un fournisseur avant d'avoir mesuré sur ses propres données.

FAQ — comparatif embeddings 2026

Pourquoi BGE-M3 est-il souvent recommandé pour les projets en français ?

BGE-M3 a été entraîné sur plus de 100 langues, avec un français substantiel, et affiche un score Retrieval MTEB d'environ 54,8. Surtout, il produit trois représentations (dense, creuse, ColBERT) permettant une recherche hybride qui combine sens sémantique et correspondance lexicale exacte. Gratuit et déployable en local, il concilie qualité francophone et souveraineté sans frais d'API.

Quelle est la différence entre une recherche par similarité cosinus et une recherche hybride ?

La similarité cosinus compare des vecteurs denses pour mesurer la proximité sémantique : elle comprend l'intention mais lisse les termes rares. La recherche hybride ajoute une composante lexicale (type BM25) qui garantit la remontée des mots exacts — références réglementaires, noms propres, codes. Combiner les deux améliore nettement le rappel, notamment sur des corpus juridiques ou comptables français précis.

Est-ce qu'un modèle d'embedding avec plus de dimensions est forcément plus précis ?

Non. Davantage de dimensions offre des vecteurs plus expressifs, mais au prix d'un stockage, d'une RAM et d'une latence accrus. Passer de 768 à 3072 dimensions quadruple l'empreinte sans garantie de gain proportionnel sur un corpus métier. La zone 768-1024 dimensions (Nomic, BGE-M3, embed-v4) constitue le compromis de production optimal pour la grande majorité des projets.

Comment garantir la conformité RGPD lors de l'utilisation d'embeddings propriétaires via API ?

Appeler une API fait transiter vos textes hors du SI, ce qui constitue un traitement à encadrer : base légale, contrat de sous-traitance conforme à l'article 28 du RGPD, localisation des données et information des personnes. Pour des données sensibles, la CNIL recommande de privilégier un hébergement local. Un modèle ouvert comme BGE-M3 auto-hébergé supprime le transfert et simplifie la conformité.

Quels sont les risques liés à la mémorisation des données personnelles dans un modèle d'embedding ?

La CNIL identifie trois risques : la mémorisation de données d'entraînement, leur reconstruction et l'inférence d'appartenance, qui permet de déduire qu'une donnée figurait dans le corpus. Un modèle exposé publiquement, avec scores de confiance visibles, augmente cette surface d'attaque. Pour des données sensibles, un déploiement local restreint, sans exposition web des sorties, réduit fortement le risque.

Pourquoi certains modèles perdent-ils en précision sur les phrases contenant beaucoup d'accents ?

Parce que leur tokeniseur, entraîné majoritairement sur l'anglais, découpe mal les accents, apostrophes et élisions français (« l'entreprise », « aujourd'hui »). Cette fragmentation dégrade la représentation vectorielle : deux formulations équivalentes s'éloignent artificiellement. Les modèles multilingues comme BGE-M3 ou embed-v4, dont le vocabulaire couvre correctement le français, ne souffrent pas de ce biais de tokenisation.

Quelle est la différence entre les embeddings « denses », « creux » et « ColBERT » ?

Un embedding dense est un vecteur unique capturant le sens global, idéal pour la similarité sémantique. Un embedding creux (sparse) façon BM25 encode la correspondance lexicale exacte, utile pour les termes rares. ColBERT produit un vecteur par token, autorisant un ré-ordonnancement très fin en fin de pipeline. BGE-M3 génère les trois simultanément, ce qui permet une recherche hybride particulièrement robuste.

Comment réduire les coûts de stockage d'une base vectorielle massive sans perdre en qualité ?

Trois leviers : réduire les dimensions (privilégier 768-1024 plutôt que 3072), appliquer une quantification (int8 ou binaire) qui compresse les vecteurs en préservant l'essentiel du rappel, et n'indexer que les passages réellement utiles après découpage. Cohere propose la quantification nativement ; en local, des bibliothèques comme FAISS l'implémentent. Le gain de stockage peut atteindre un facteur trois à quatre.

Peut-on utiliser des modèles d'embedding open-source pour du multimodal (image + texte) ?

Oui. Des modèles ouverts comme CLIP, SigLIP 2 ou Jina CLIP v2 alignent image et texte dans un même espace vectoriel, permettant des recherches cross-modales : retrouver une image à partir d'une description, ou l'inverse. Jina CLIP v2 ajoute une dimension multilingue précieuse pour des documents français. On les déploie localement, dans la même logique de souveraineté qu'un embedding textuel.

Quels sont les critères clés pour choisir entre Nomic, BGE et Cohere en 2026 ?

Quatre critères : le mode de déploiement (local vs API), la langue du corpus (le français impose du multilingue), le budget d'inférence et le niveau de sensibilité des données. Nomic convient aux corpus techniques anglophones reproductibles ; BGE-M3 au RAG français souverain et gratuit ; Cohere embed-v4 à la qualité maximale via API quand le transfert de données est acceptable et encadré.

Pour aller plus loin avec IAPRO

Choisir un modèle d'embedding est une décision d'architecture qui engage votre conformité et vos coûts d'infrastructure pour des années. Chez IAPRO, nous installons des RAG souverains on-premise à Roubaix et dans toute la France, avec BGE-M3 ou Cohere selon votre niveau de sensibilité des données, et nous mesurons le rappel réel sur votre propre corpus avant tout déploiement. Contactez-nous pour un audit de votre projet RAG, ou explorez nos solutions par métier pour cadrer votre cas d'usage.

Liens utiles