Embeddings et recherche sémantique : les fondations de l'IA moderne

Quand un dirigeant nous demande "comment fonctionne la recherche intelligente dans votre système RAG ?", la réponse tient en un mot : embeddings. Cette technologie, invisible pour l'utilisateur final, est pourtant la brique fondamentale derrière les systèmes de recherche sémantique, les assistants IA, la recommandation de produits et le matching automatique.

Le problème, c'est que la plupart des contenus disponibles sur le sujet sont soit trop académiques (des papiers de recherche illisibles), soit trop vagues ("les embeddings transforment le texte en nombres"). Cet article prend l'angle terrain : comprendre ce que sont réellement les embeddings, pourquoi ils comptent pour votre entreprise, et comment choisir les bons modèles et les bonnes bases de données vectorielles en 2026.

Les embeddings en 5 minutes : de l'intuition à la compréhension

Partons d'un constat simple. Quand vous tapez "résiliation de bail" dans un moteur de recherche classique, il cherche les documents contenant exactement ces mots. Si un document dit "fin de contrat de location", il ne remonte pas. C'est un problème majeur pour toute entreprise qui cherche dans ses propres données : les gens expriment la même idée avec des mots différents.

Les embeddings résolvent ce problème d'une façon élégante. Un modèle d'embedding transforme un texte (mot, phrase, paragraphe) en une liste de nombres, un vecteur. Cette liste n'est pas aléatoire : elle encode le sens du texte. Deux textes au sens proche produisent des vecteurs proches dans l'espace mathématique, même s'ils utilisent des mots totalement différents.

L'analogie de la carte géographique

Imaginez une carte où chaque concept du langage est un point. Sur cette carte, "chien" et "chat" sont proches (les deux sont des animaux domestiques), mais "chien" et "avion" sont loin. Plus intéressant : les relations entre concepts sont préservées. La distance entre "roi" et "reine" est la même qu'entre "homme" et "femme" : c'est la même direction dans l'espace, celle du genre.

C'est l'exemple classique de l'arithmétique des vecteurs :

En pratique, un embedding moderne ne se limite pas à un mot. Les modèles actuels transforment des phrases entières, voire des paragraphes complets, en vecteurs de 768 à 3 072 dimensions. Ces dimensions ne correspondent pas à des caractéristiques identifiables par un humain : ce sont des axes abstraits que le modèle a appris à construire en analysant des milliards de textes.

Ce que capturent réellement les embeddings

Un bon modèle d'embedding capture bien plus que la synonymie. Il encode :

• Le sens sémantique : "le serveur est tombé" (informatique) vs. "le serveur est tombé" (restaurant) sont distingués par le contexte
• Les relations logiques : cause/conséquence, partie/tout, spécifique/général
• Le registre et le domaine : un texte juridique et un email informel sur le même sujet produisent des vecteurs différents
• La structure argumentative : une question et sa réponse peuvent être proches dans l'espace vectoriel, même si elles n'ont aucun mot en commun

Pourquoi les embeddings sont partout : RAG, recherche, recommandation

Les embeddings ne sont pas un gadget de laboratoire. Ils sont la couche fondamentale sur laquelle reposent la quasi-totalité des applications d'IA modernes en entreprise. Voici les quatre familles d'usage les plus courantes.

Le RAG (Retrieval-Augmented Generation)

Le RAG est l'application la plus directe des embeddings en entreprise. Le principe : vos documents internes sont découpés en passages, chaque passage est transformé en embedding et stocké dans une base vectorielle. Quand un utilisateur pose une question, celle-ci est aussi convertie en embedding, puis le système recherche les passages dont les vecteurs sont les plus proches. Ces passages sont ensuite envoyés à un LLM qui génère une réponse contextualisée.

Sans embeddings, pas de RAG. C'est aussi simple que ça. Et quand nous construisons un système RAG, le choix du modèle d'embedding est souvent plus déterminant que le choix du LLM. Un modèle de génération excellent ne peut rien faire si les passages récupérés en amont ne sont pas pertinents.

Le matching sémantique

Comparer deux textes pour déterminer s'ils parlent de la même chose est un problème classique en entreprise. Les embeddings le résolvent naturellement : il suffit de calculer la similarité cosinus entre deux vecteurs. Nous utilisons cette approche pour le matching CV-missions dans les ESN, le rapprochement de fiches produits, ou la détection de doublons dans une base documentaire.

La classification automatique

Classifier des emails, des tickets de support, des retours clients : les embeddings transforment ce qui était un problème de NLP complexe en un problème géométrique simple. Dans l'espace vectoriel, les textes d'une même catégorie forment des clusters naturels. Un classifieur entraîné sur les embeddings de quelques centaines d'exemples peut atteindre des précisions supérieures à 90 %.

Les systèmes de recommandation

Recommander un article, un produit ou un contenu similaire à ce qu'un utilisateur a consulté revient à chercher les vecteurs proches dans l'espace des embeddings. C'est plus robuste que les recommandations basées sur les tags ou les catégories, parce que les embeddings capturent des nuances sémantiques que les métadonnées ne reflètent pas.

De Word2Vec aux Transformers : comment fonctionnent les modèles d'embedding

Comprendre les grandes étapes de l'évolution des modèles d'embedding permet de mieux choisir celui qui convient à votre cas d'usage. Voici les trois générations principales.

Première génération : Word2Vec et les embeddings de mots (2013)

Word2Vec, développé chez Google, a été le premier modèle à démontrer qu'on pouvait capturer le sens des mots dans des vecteurs. Le principe : entraîner un réseau de neurones simple à prédire un mot à partir de son contexte (ou inversement). Le résultat est un vecteur par mot, de 100 à 300 dimensions.

La limite : un mot a un seul vecteur, quel que soit le contexte. "Banque" a le même embedding qu'on parle d'une banque financière ou d'un banc de poissons. C'est insuffisant pour des applications professionnelles.

Deuxième génération : les Transformers et les embeddings contextuels (2018)

L'architecture Transformer, introduite par Google avec BERT en 2018, a changé la donne. Contrairement à Word2Vec, un Transformer produit un embedding différent pour le même mot selon son contexte. "Banque" dans "ouvrir un compte en banque" et "banque" dans "banque de données" reçoivent des vecteurs distincts.

Mais BERT seul n'est pas idéal pour la recherche sémantique. Comparer deux phrases avec BERT nécessite de les passer ensemble dans le modèle, ce qui est trop lent pour chercher dans des millions de documents.

Troisième génération : Sentence-BERT et les modèles spécialisés (2019 à aujourd'hui)

Sentence-BERT a résolu le problème en entraînant des modèles à produire directement des embeddings de phrases comparables. Chaque phrase est encodée indépendamment en un seul passage dans le modèle, puis la similarité se calcule par un simple produit scalaire. C'est rapide, scalable, et c'est cette architecture qui est à la base de tous les modèles d'embedding modernes.

Les modèles actuels (text-embedding-3-large d'OpenAI, e5-mistral, BGE-m3) sont des descendants directs de cette approche, entraînés sur des corpus massifs avec des techniques de contrastive learning : le modèle apprend à rapprocher les vecteurs des textes sémantiquement similaires et à éloigner ceux qui ne le sont pas.

Choisir son modèle d'embedding : critères et comparatif 2026

Le choix du modèle d'embedding n'est pas anodin. Deux modèles différents sur les mêmes données peuvent donner des performances de retrieval qui varient de 15 à 30 points de rappel. Voici les critères qui comptent vraiment.

Les critères de sélection

• Performance sur votre langue et votre domaine : un modèle excellent en anglais peut être médiocre en français technique. Vérifiez les benchmarks MTEB (Massive Text Embedding Benchmark) sur les sous-ensembles français.
• Dimension des vecteurs : de 384 à 3 072 dimensions. Plus de dimensions capture plus de nuances, mais coûte plus cher en stockage et en latence. Pour la plupart des cas d'usage, 1 024 dimensions sont un bon compromis.
• Longueur de contexte : combien de tokens le modèle peut encoder en une seule passe. De 512 tokens (limité) à 8 192 tokens (confortable pour des paragraphes longs).
• Souveraineté des données : hébergé chez OpenAI (US), Mistral (France), ou déployable on-premise ?
• Coût par appel API : de 0,02 $ à 0,13 $ par million de tokens. Sur un corpus de 100 000 documents, la différence se compte en centaines d'euros.

Comparatif des modèles d'embedding en 2026

Modèle	Dimensions	Contexte max	Français	Hébergement	Usage recommandé
text-embedding-3-large (OpenAI)	3 072	8 191 tokens	Très bon	API (US)	Polyvalent, meilleur ratio qualité/simplicité
Mistral Embed	1 024	8 192 tokens	Excellent	API (France)	Souveraineté + performance en français
e5-mistral-7b-instruct	4 096	32 768 tokens	Très bon	On-premise	RGPD strict, documents longs
BGE-m3 (BAAI)	1 024	8 192 tokens	Bon	On-premise	Multilingue, open source, léger
Cohere Embed v3	1 024	512 tokens	Bon	API (Canada)	Recherche sémantique avec re-ranking intégré
text-embedding-3-small (OpenAI)	1 536	8 191 tokens	Bon	API (US)	Budget serré, prototypage rapide

Notre recommandation terrain : pour la majorité des projets que nous menons chez Tensoria, nous démarrons avec text-embedding-3-large d'OpenAI pour le prototypage (simplicité d'intégration, excellentes performances), puis nous migrons vers Mistral Embed ou un modèle on-premise si le client a des contraintes de souveraineté. L'important est de benchmarker sur vos données, pas sur les benchmarks publics : un modèle moyen sur MTEB peut être excellent sur votre domaine spécifique.

Les embeddings en français : spécificités et modèles recommandés

Le français pose des défis spécifiques aux modèles d'embedding. Les conjugaisons, les accords, les tournures passives et les expressions idiomatiques rendent la tâche plus complexe qu'en anglais. Deux exemples concrets :

• "L'entreprise a été mise en demeure" et "la société a reçu une sommation" doivent produire des vecteurs proches. Un modèle entraîné principalement sur l'anglais peut rater cette équivalence.
• "Clause de non-concurrence" et "non-compete clause" doivent être rapprochées dans un contexte bilingue.

En pratique, les modèles multilingues modernes (text-embedding-3-large, e5-mistral, BGE-m3) gèrent bien le français généraliste. Là où les écarts apparaissent, c'est sur le français technique et professionnel : terminologie juridique, normes BTP, jargon médical. Sur ces niches, un modèle non spécialisé peut confondre des termes qui ont un sens très précis dans le domaine.

Pour les cas critiques, nous combinons deux approches : un modèle d'embedding généraliste performant pour le recall, suivi d'un cross-encoder de re-ranking entraîné ou fine-tuné sur le domaine. C'est cette architecture en deux étapes qui nous a permis, sur un projet pour un éditeur médical, de passer la précision de 67 % à 89 % simplement en ajoutant un re-ranker spécialisé sur la terminologie médicale.

Bases de données vectorielles : Pinecone, Qdrant, pgvector, ChromaDB

Une fois vos embeddings calculés, il faut les stocker et les interroger efficacement. C'est le rôle des bases de données vectorielles. Elles utilisent des algorithmes d'indexation spécialisés (HNSW, IVF) pour effectuer des recherches de similarité en quelques millisecondes, même sur des millions de vecteurs.

Voici notre retour terrain sur les quatre solutions que nous utilisons en production.

Solution	Type	Points forts	Limites	Notre usage
pgvector	Extension PostgreSQL	Pas de nouvelle infra, SQL classique, filtrage métadonnées natif	Performances limitées au-delà de 1M de vecteurs, pas de recherche hybride native	Projets simples, MVP, PME avec PostgreSQL existant
Qdrant	Base vectorielle dédiée	Performant, filtrage avancé, payload riche, API bien pensée	Infrastructure à gérer (auto-hébergé) ou cloud payant	Projets complexes, multi-tenant, production à forte charge
Pinecone	SaaS managé	Zéro ops, scalable, namespace natif	Données hébergées aux US, coût élevé au volume, vendor lock-in	Prototypage rapide, clients sans contrainte de souveraineté
ChromaDB	Base légère (Python)	Simple, open source, parfait pour le développement et les tests	Non conçu pour la production à grande échelle	Développement local, PoC, projets R&D

Recherche hybride : combiner BM25 et recherche sémantique

C'est l'un des enseignements les plus importants de nos projets en production : la recherche sémantique seule ne suffit presque jamais. Nous utilisons systématiquement la recherche hybride combinant BM25 (recherche lexicale classique) et recherche vectorielle par embeddings.

Pourquoi ? Parce que chaque méthode a ses angles morts.

Ce que la recherche sémantique rate

• Les codes et références techniques : "SKU-42789", "Article L. 1234-9", "norme NF EN 1991-1-3". Ces chaînes ont un sens précis que les embeddings diluent dans un espace sémantique trop large.
• Les acronymes métier : "DPEF", "BAEL", "DCE". Le modèle d'embedding n'a souvent vu ces acronymes que dans un contexte limité.
• Les correspondances exactes attendues : quand un utilisateur cherche exactement le mot "amortissement" dans un document comptable, il veut ce mot, pas un synonyme.

Ce que le BM25 rate

• Les reformulations : "comment réduire les coûts de production" ne matche pas avec un document sur "l'optimisation des charges industrielles".
• Les questions/réponses : "le bâtiment est-il aux normes parasismiques ?" ne partage aucun mot avec la réponse "la structure respecte les exigences de l'Eurocode 8".

Sur les requêtes techniques avec des codes ou des acronymes, le BM25 seul est souvent meilleur que la recherche sémantique seule. Mais sur les requêtes en langage naturel, la recherche sémantique l'emporte largement. La recherche hybride capture le meilleur des deux mondes.

En pratique, nous fusionnons les résultats avec le Reciprocal Rank Fusion (RRF) : chaque méthode produit un classement, et le RRF combine les deux en pondérant les positions. Un document bien classé par les deux méthodes remonte en tête. Un document qui n'est capté que par l'une des deux a quand même sa chance. Cette technique est détaillée dans notre article sur l'optimisation des systèmes RAG.

Cas d'usage concrets en entreprise

Au-delà de la théorie, voici les applications les plus fréquentes que nous déployons avec des embeddings.

Recherche documentaire intelligente

Le cas le plus courant. Une entreprise a des milliers de documents (procédures, contrats, normes, manuels) et veut permettre à ses équipes de poser des questions en langage naturel plutôt que de fouiller dans des dossiers. L'architecture est un assistant IA interne basé sur le RAG, et les embeddings en sont le moteur de recherche.

Sur un projet pour un éditeur de logiciel médical, nous avons indexé toute la documentation technique, les guides utilisateurs et l'historique des tickets de support. Le temps de résolution des demandes de niveau 1 a été réduit de 50 %.

Matching CV et missions

Les ESN et cabinets de recrutement utilisent les embeddings pour matcher automatiquement des profils de consultants avec des fiches de mission. Chaque CV et chaque cahier des charges sont transformés en embedding, et le matching se fait par similarité vectorielle. Cela permet de couvrir l'intégralité de la base de consultants, pas seulement les 50 profils que le commercial connaît de mémoire.

Détection de doublons et de contenus similaires

Dans les bases de connaissances, les wikis d'entreprise ou les systèmes de tickets de support, les doublons sont fréquents. Deux articles qui expliquent la même procédure avec des mots différents, deux tickets qui décrivent le même bug. Les embeddings identifient ces redondances en calculant la similarité entre tous les éléments de la base.

Classification automatique de documents

Classifier automatiquement des emails entrants (demande commerciale, réclamation, demande de devis, spam), trier des retours clients par thème, catégoriser des pièces comptables : ces tâches reposent sur les embeddings. Le texte est transformé en vecteur, puis un classifieur (aussi simple qu'un KNN ou une régression logistique) opère dans l'espace vectoriel.

Les pièges courants avec les embeddings

Après avoir déployé des dizaines de systèmes basés sur les embeddings, voici les erreurs que nous voyons le plus souvent.

Piège 1 : négliger la qualité du chunking

Le chunking (le découpage de vos documents en passages avant l'embedding) est souvent le facteur le plus déterminant de la qualité du retrieval. Un découpage trop fin (200 tokens) perd le contexte. Un découpage trop large (2 000 tokens) dilue l'information pertinente dans du bruit. Les bonnes pratiques sont détaillées dans notre article sur les erreurs courantes en projet RAG.

Notre recommandation : le semantic chunking (découper sur les ruptures de sens plutôt qu'à un nombre fixe de caractères) ou, a minima, un chunking par paragraphes avec overlap de 10 à 15 %.

Piège 2 : ignorer la dimension des vecteurs

Un vecteur de 3 072 dimensions (text-embedding-3-large) occupe 12 ko en float32. Sur un million de documents, cela représente 12 Go de stockage rien que pour les vecteurs, sans compter les index. OpenAI propose une option de réduction de dimensions (Matryoshka embeddings) qui permet de tronquer les vecteurs à 1 024 ou 256 dimensions avec une perte de qualité mesurée. Pensez-y dès la conception.

Piège 3 : oublier le re-ranking

Les embeddings et la recherche vectorielle utilisent des bi-encodeurs : rapides mais approximatifs. Un cross-encoder de re-ranking analyse la question et chaque document ensemble pour un score de pertinence beaucoup plus précis. Ce second passage est plus lent, mais sur les top 20 à 50 résultats, il améliore significativement la précision. C'est une technique systématique dans nos pipelines RAG en production.

Piège 4 : utiliser le même modèle d'embedding pour tout

Un modèle performant pour la recherche sémantique de documents longs n'est pas forcément optimal pour le matching de phrases courtes ou la classification. Évaluez sur votre cas d'usage réel. Nous avons vu des projets où le passage de text-embedding-ada-002 à text-embedding-3-large a amélioré le recall de 22 points sur des documents techniques en français, sans aucune autre modification.

Retour d'expérience Tensoria

Après plus de trente projets impliquant des embeddings en production, voici les principes que nous appliquons systématiquement :

1. Toujours benchmarker sur les données du client. Les benchmarks publics (MTEB, BEIR) donnent une direction, mais la performance réelle sur un corpus juridique français ou des manuels techniques industriels peut être très différente du classement général. Nous testons toujours 2 à 3 modèles sur un échantillon représentatif avant de choisir.
2. Toujours commencer par la recherche hybride. Sur 100 % de nos projets en production, la combinaison BM25 + sémantique surpasse l'une ou l'autre méthode utilisée seule. Ce n'est plus une option, c'est un standard.
3. Investir dans le chunking avant de changer de modèle. Quand un RAG donne de mauvais résultats, la première hypothèse n'est pas "le modèle d'embedding est mauvais", mais "les documents sont mal découpés". Dans 60 % des cas, retravailler le chunking résout le problème sans changer de modèle.
4. Mesurer avec des métriques objectives. Recall@10, MRR (Mean Reciprocal Rank), NDCG. Pas de "ça a l'air de mieux marcher". Un pipeline d'évaluation automatisé permet d'itérer rapidement et de justifier les décisions techniques auprès du client.
5. Penser souveraineté dès le début. Si le client a des contraintes RGPD ou des données sensibles, le choix du modèle d'embedding doit être compatible avec un hébergement européen ou on-premise. Changer de modèle d'embedding en cours de projet signifie recalculer tous les vecteurs, ce qui est coûteux. Mieux vaut anticiper dès l'audit IA initial.

Conclusion

Les embeddings et la recherche sémantique ne sont pas des technologies de pointe réservées aux géants de la tech. Ce sont des briques matures, éprouvées en production, accessibles à toute entreprise qui manipule du texte (c'est-à-dire toutes). Que vous construisiez un système RAG, un outil de matching, un classifieur automatique ou un moteur de recommandation, les embeddings en sont le socle.

Les choix qui comptent ne sont pas les plus visibles. Le modèle d'embedding, la stratégie de chunking, l'architecture de recherche hybride et la base vectorielle déterminent la qualité du résultat final bien plus que le LLM de génération. C'est sur ces fondations que se construit (ou s'effondre) un projet d'IA documentaire.

Si vous envisagez un projet de recherche sémantique ou d'IA générative sur vos données, commencez par comprendre vos données, benchmarker vos modèles d'embedding et définir une architecture de recherche hybride. C'est la base. Tout le reste en découle.

Questions fréquentes sur les embeddings et la recherche sémantique

Pour aller plus loin

• Notre expertise LLM et NLP : de la conception du pipeline d'embeddings au déploiement en production.
• RAG en entreprise : tout comprendre : le système complet dans lequel s'intègrent les embeddings.
• Optimiser un système RAG : chunking, re-ranking et réglages fins pour améliorer la pertinence.
• RAG vs fine-tuning : comment choisir : quand l'architecture RAG + embeddings suffit, quand le fine-tuning est nécessaire.
• Évaluer un LLM en entreprise : métriques et golden dataset pour mesurer la qualité de votre pipeline.
• Déployer un LLM en production : infrastructure, coûts et monitoring pour la mise en production.
• Prompt engineering avancé : les techniques de prompting qui complètent la recherche sémantique.
• Les erreurs qui font échouer les projets RAG : dont plusieurs sont liées au choix des embeddings.
• RAG multimodal : étendre les embeddings aux images, PDF et tableaux.