Quand vous posez une question à ChatGPT ou à AI Mode et qu’il cite trois pages, il n’a pas cherché vos mots dans un index. Il a comparé des listes de nombres. Votre page en est une, votre question en est une autre, et un calcul de deux lignes décide si elles sont voisines.
Ces listes de nombres s’appellent des embeddings. C’est la brique qui permet à un moteur de rapprocher « comment accélérer mon site » de « réduire le poids des images », sans un seul mot en commun.
La réponse en cinq lignes
- Un embedding est la traduction d’un texte en une liste de nombres — par exemple 3 072 nombres chez Google — dont la position dans l’espace résume le sujet du texte.
- Deux textes qui parlent de la même chose se retrouvent au même endroit de cet espace, même s’ils n’emploient pas les mêmes mots.
- Le moteur mesure la proximité avec le cosinus : un seul calcul, que vous pouvez faire au crayon.
- Conséquence pratique : ce qui compte n’est plus le mot-clé exact, c’est qu’un passage isolé de votre page suffise à se rattacher tout seul au bon sujet.
- Ce que le cosinus ne mesure pas : si votre passage répond à la question. C’est le travail d’une étape suivante, le reclassement.
Un embedding, c’est une position sur une carte
Imaginez une carte de France. Deux nombres suffisent à désigner une ville : latitude et longitude. Lille et Roubaix ont des coordonnées presque identiques, Lille et Marseille non. Vous n’avez pas besoin de connaître le nom des villes pour savoir lesquelles sont voisines : il suffit de comparer les nombres.
Un embedding fait exactement ça avec du texte, sur une carte à beaucoup plus de deux dimensions. Chaque texte reçoit des coordonnées. Les textes qui parlent de la même chose atterrissent dans le même quartier.
D’où viennent ces coordonnées ? D’un modèle entraîné à une tâche apparemment idiote : deviner les mots qui entourent un mot. L’article fondateur de cette approche, Efficient Estimation of Word Representations in Vector Space (Tomas Mikolov, Kai Chen, Greg Corrado, Jeffrey Dean, 16 janvier 2013), montre qu’on peut ainsi apprendre des vecteurs de qualité sur 1,6 milliard de mots en moins d’une journée. Le modèle ne « comprend » rien. Il constate que voiture et automobile apparaissent dans les mêmes contextes, et leur attribue des coordonnées voisines. La proximité de sens sort du calcul comme un effet de bord de la statistique d’usage.
Un deuxième saut a eu lieu en 2019 avec Sentence-BERT (Nils Reimers, Iryna Gurevych, 27 août 2019), qui produit un vecteur par phrase et non par mot. Son intérêt était d’abord industriel, et les auteurs le chiffrent sur un cas précis : trouver la paire la plus proche dans « une collection de 10 000 phrases demande environ 50 millions de calculs d’inférence (~65 heures) avec BERT ». Leur méthode « réduit l’effort nécessaire pour trouver la paire la plus similaire de 65 heures avec BERT / RoBERTa à environ 5 secondes avec SBERT, tout en conservant la précision de BERT ». C’est ce facteur-là qui a rendu la recherche vectorielle utilisable à grande échelle : les vecteurs sont calculés une fois pour toutes, et la comparaison se réduit à une multiplication.
Vocabulaire. Embedding (ou plongement) : la liste de nombres associée à un texte. Vecteur : la même chose, vue comme une flèche partant de l’origine. Dimension : chaque case de la liste. Un modèle « à 768 dimensions » produit des listes de 768 nombres.
Le cosinus : la seule opération à retenir
Pour savoir si deux vecteurs sont voisins, on ne mesure pas la distance entre les pointes des flèches. On mesure l’angle entre elles. Le cosinus de cet angle vaut 1 quand les flèches pointent exactement dans la même direction, 0 quand elles sont perpendiculaires, −1 quand elles sont opposées.
Pourquoi l’angle et pas la distance ? Parce que la longueur d’un vecteur dépend surtout de la longueur du texte, et qu’on ne veut pas qu’un paragraphe de 300 mots soit jugé « loin » d’une question de 8 mots juste parce qu’il est plus long.
La formule tient sur une ligne : on multiplie les deux listes case par case, on additionne, et on divise par le produit des longueurs. Voici trois vecteurs à deux dimensions, calculés jusqu’au bout pour que vous puissiez refaire l’opération sur un coin de table :
| Paire | Produit case par case | Longueurs | Cosinus | Angle |
|---|---|---|---|---|
| A (3 ; 1) vs B (2 ; 2) | 3×2 + 1×2 = 8 | 3,1623 × 2,8284 | 0,8944 | 26,6° |
| A (3 ; 1) vs C (0 ; 4) | 3×0 + 1×4 = 4 | 3,1623 × 4,0000 | 0,3162 | 71,6° |
| B (2 ; 2) vs C (0 ; 4) | 2×0 + 2×4 = 8 | 2,8284 × 4,0000 | 0,7071 | 45,0° |
Trois choses à en retenir. A et B sont très proches sans être identiques. C est le point le plus éloigné de A. Et B, qui est « entre » les deux, obtient un score élevé avec A et moyen avec C — c’est exactement le comportement d’un passage qui mélange deux sujets : il ne gagne franchement sur aucun des deux.
Ce que les moteurs font vraiment : documenté contre déduit
C’est le tableau que cette série tient à jour d’un article à l’autre. Une case « documenté » signifie qu’une phrase existe, dans une source officielle ou judiciaire, qui l’affirme.
| Affirmation | Statut | Source |
|---|---|---|
| Pour « ancrer ses modèles Gemini, Google utilise une technologie propriétaire appelée FastSearch », qui « repose sur des signaux RankEmbed — un ensemble de signaux de classement de recherche — et produit des résultats web abrégés et classés qu’un modèle peut utiliser pour produire une réponse fondée » | Documenté | United States v. Google LLC, n° 20-cv-3010 (APM), décision du 2 septembre 2025, constatations de fait § 44 |
| FastSearch « livre des résultats plus rapidement que Search parce qu’il récupère moins de documents, mais la qualité obtenue est inférieure aux résultats web entièrement classés de Search » | Documenté | Idem, § 44, phrase suivante |
| AI Overviews et AI Mode peuvent utiliser une technique de « query fan-out », en émettant plusieurs recherches liées | Documenté | Google Search Central, documentation « AI features », mise à jour du 10 décembre 2025 |
| Le modèle d’embedding de Google accepte jusqu’à 8 192 tokens en entrée et produit 3 072 dimensions par défaut, réductibles à 1 536 ou 768 | Documenté | Google, documentation Gemini API « Embeddings », mise à jour du 26 août 2026 |
Il faut encoder différemment la question et le document : RETRIEVAL_QUERY pour la première, RETRIEVAL_DOCUMENT pour le second | Documenté (pour l’API Gemini) | Idem : « Utilisez RETRIEVAL_QUERY pour les requêtes ; RETRIEVAL_DOCUMENT pour les documents à récupérer » |
| Un index vectoriel de production repose sur une recherche approchée du plus proche voisin — on accepte de rater parfois le meilleur candidat pour aller mille fois plus vite | Documenté (pour Elasticsearch) | Elastic, référence dense_vector : les vecteurs float « sont toujours indexés en int8_hnsw » depuis Elastic Stack 9.0. hnsw renvoie à l’algorithme publié par Yu. A. Malkov et D. A. Yashunin le 30 mars 2016 ; int8 signifie que chaque nombre est arrondi pour diviser la mémoire par quatre, « au prix d’un peu de précision » |
| RankEmbed est un modèle bi-encodeur — la question et la page sont converties chacune de son côté, puis comparées — qui projette requêtes et documents dans un même espace vectoriel | Déduit | Le nom le suggère et des analyses secondaires l’affirment ; la décision de justice, elle, ne dit pas ce qu’est RankEmbed, elle ne parle que de « signaux RankEmbed » |
| Google découpe les pages en passages avant de les vectoriser, avec telle taille de bloc | Non documenté | Aucune source officielle sur la taille des blocs ni sur la méthode |
| Une similarité cosinus supérieure à tel seuil garantit une citation | Faux | Aucun seuil publié ; voir la mesure 2 — le plancher varie selon le modèle |
Reste la position officielle de Google, qu’on cite partout amputée de ce qui l’encadre. Voici le paragraphe entier :
Les bonnes pratiques du SEO restent pertinentes pour les fonctionnalités IA de Google Search (comme AI Overviews et AI Mode). Il n’y a aucune exigence supplémentaire pour apparaître dans AI Overviews ou AI Mode, ni aucune optimisation spéciale nécessaire. Cela dit, il est toujours bon de revoir les bonnes pratiques fondamentales du SEO.
Lue en entier, la phrase est moins tranchée qu’on ne la rapporte : elle est prise en sandwich entre deux rappels aux fondamentaux. La même page ajoute : « Vous n’avez pas besoin de créer de nouveaux fichiers lisibles par machine, de fichiers texte pour l’IA, ou de balisage pour apparaître dans ces fonctionnalités. » En France, AI Overviews et AI Mode ont été déployés le 22 juillet 2026.
Cette position n’est donc pas contradictoire avec tout ce qui précède. Google dit qu’il n’y a pas de nouveau levier technique à activer, et qu’il faut revoir les fondamentaux. Il ne dit pas que la façon dont vous découpez vos paragraphes est indifférente — et le fonctionnement même de la recherche vectorielle montre qu’elle ne l’est pas.
Sept décisions d’écriture qui découlent de ces mesures
Classées par rapport effort/effet, du meilleur au moins bon.
- Rendez chaque section autonome. Nommez le sujet, la période et le périmètre à l’intérieur du paragraphe, pas dans le titre au-dessus. Mesure 3 : +0,081 pour quatre mots de contexte.
- Chassez les pronoms de reprise en début de paragraphe. « Cette technique », « il », « comme vu plus haut » : remplacez par le nom de la chose. C’est la même correction que le point 1, mais c’est celle que personne ne fait.
- Donnez à chaque réponse son propre bloc. Un intertitre, un paragraphe, une réponse. Justification : le mécanisme de la moyenne, pas un chiffre — un vecteur unique pour une page longue mélange votre meilleur passage et vos digressions.
- Ne noyez pas la réponse dans du remplissage. Sommaire, encarts, appels à l’action, « lire aussi » : chaque phrase hors sujet dans le bloc tire son vecteur ailleurs. Mesure 4 : −0,050 entre le paragraphe seul et le paragraphe noyé sous six phrases de garniture, avec une courbe bruitée sur les premières phrases.
- Employez les mots de votre lecteur, en plus de répondre. Les deux, pas l’un contre l’autre. Mesure 1 : le candidat qui fait les deux gagne.
- Écrivez les négations en clair. « ne dépend pas » a exactement le même vecteur que « dépend » dès que les mots vides sont retirés. Préférez « Ce dispositif exclut… » à « n’ouvre pas droit à… » : l’information passe alors dans le choix du verbe, pas dans deux mots que la chaîne de traitement peut jeter.
Ce que ces six points ne sont pas : une garantie de citation. Ils augmentent la probabilité que votre passage entre dans la liste des candidats. Ce qui se passe ensuite — le reclassement, le choix du passage cité — relève d’une autre étape, que cette série traitera à part.
Questions fréquentes
Combien de dimensions font les embeddings utilisés aujourd’hui ?
Cela dépend du modèle. Le modèle de Google produit 3 072 dimensions par défaut, avec 1 536 et 768 comme réductions recommandées. Chez OpenAI, text-embedding-3-small en produit 1 536 et text-embedding-3-large 3 072, avec 8 192 tokens d’entrée maximum dans les deux cas. Elasticsearch accepte jusqu’à 4 096 dimensions par champ vectoriel.
Peut-on réduire un embedding sans perdre sa qualité ?
En partie, et c’est documenté — mais la phrase d’OpenAI comporte une condition qu’il ne faut pas couper : « les développeurs peuvent raccourcir les embeddings — c’est-à-dire retirer des nombres à la fin — sans que l’embedding perde ses propriétés de représentation, en passant le paramètre dimensions de l’API ». La condition compte, parce qu’OpenAI indique par ailleurs que ses embeddings « sont normalisés à une longueur de 1 » : tronquer le vecteur à la main côté client casse cette normalisation. Même avertissement chez Google, en clair cette fois : pour gemini-embedding-001, il faut renormaliser manuellement tout vecteur ramené à une autre taille que 3 072.
Le point de comparaison, lui, est spectaculaire : un vecteur text-embedding-3-large ramené à 256 dimensions reste meilleur qu’un text-embedding-ada-002 complet à 1 536.
Faut-il ajouter des données structurées ou un fichier spécial pour les moteurs IA ? Non, selon Google : « vous n’avez pas besoin de créer de nouveaux fichiers lisibles par machine, de fichiers texte pour l’IA, ou de balisage pour apparaître dans ces fonctionnalités ».
Comment tester la proximité vectorielle de mes propres pages ? Le protocole de cet article suffit à démarrer et ne coûte rien : installez spaCy et le modèle français, calculez la moyenne des vecteurs de chaque paragraphe, comparez au vecteur de la question visée, puis classez vos paragraphes. Ne regardez pas les valeurs, regardez l’ordre. Pour des chiffres plus proches de ce que font les moteurs, il faut passer par une API d’embedding contextuelle, facturée au token — 0,00002 $ pour 1 000 tokens chez OpenAI sur le petit modèle, tarif du 25 janvier 2024.
Mon site a peu de contenu. La recherche vectorielle m’avantage-t-elle ? Elle rend possible d’être trouvé sans avoir la formulation exacte de la question, ce qui aide les petits sites bien écrits. Elle ne compense ni l’absence de contenu, ni l’absence de réputation : ce sont d’autres signaux, appliqués plus loin dans la chaîne.
Sources
- Tomas Mikolov, Kai Chen, Greg Corrado, Jeffrey Dean, Efficient Estimation of Word Representations in Vector Space, 16 janvier 2013 — arxiv.org/abs/1301.3781
- Yu. A. Malkov, D. A. Yashunin, Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs, 30 mars 2016 — arxiv.org/abs/1603.09320
- Nils Reimers, Iryna Gurevych, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks, 27 août 2019 — arxiv.org/abs/1908.10084
- Vladimir Karpukhin, Barlas Oğuz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, Wen-tau Yih, Dense Passage Retrieval for Open-Domain Question Answering, 10 avril 2020 — arxiv.org/abs/2004.04906
- Niklas Muennighoff, Nouamane Tazi, Loïc Magne, Nils Reimers, MTEB: Massive Text Embedding Benchmark, 13 octobre 2022 — arxiv.org/abs/2210.07316
- OpenAI, New embedding models and API updates, 25 janvier 2024 — openai.com
- OpenAI, Embeddings (documentation API), consultée le 27 août 2026 — developers.openai.com
- Anthropic, Contextual Retrieval in AI Systems, 19 septembre 2024 — anthropic.com
- United States v. Google LLC, n° 20-cv-3010 (APM) et 20-cv-3715 (APM), décision du 2 septembre 2025, constatations de fait § 44 — caselaw.findlaw.com
- Google Search Central, AI features and your website, mise à jour du 10 décembre 2025 — developers.google.com
- Google, Embeddings (Gemini API), mise à jour du 26 août 2026 — ai.google.dev
- Elastic, dense_vector field type, consultée le 27 août 2026 — elastic.co
- spaCy, modèle
fr_core_news_md3.8.0 — spacy.io/models/fr
Mesures : réalisées le 27 août 2026, spaCy 3.8.16, fr_core_news_md 3.8.0 (20 000 vecteurs uniques de 300 dimensions pour 500 000 clés), NumPy 2.4.4. Protocole décrit dans la section « Ce que j’ai mesuré », script complet dans la section « Le code ».
