L’intelligence artificielle transforme fondamentalement la façon dont Google classe et présente les résultats de recherche. Mais comment fonctionne vraiment ce système ? En analysant Google Cloud Discovery Engine, nous pouvons comprendre l’architecture sous-jacente qui alimente AI Mode et révèle les principes d’optimisation critique pour les créateurs de contenu.
Google Vend sa Technologie de Recherche IA
Google Cloud Discovery Engine (également appelé Vertex AI Search) n’est pas un outil confidentiel enfoui dans les documents techniques. C’est un produit d’entreprise disponible dans la console Google Cloud, activement développé et régulièrement mis à jour avec des modèles plus sophistiqués et des options de configuration avancées.
Cet accès public aux configurations de recherche IA révèle quelque chose d’important : Google ne cache pas sa technologie. La première mise en place de Discovery Engine demande de configurer des entrepôts de données, des pipelines de traitement et des contrôles de classement, mais tous ces éléments sont exposés dans l’interface utilisateur.
Le Pipeline en Quatre Étapes : Préparer → Récupérer → Signaler → Servir
Google structure sa recherche IA selon un pipeline cohérent comprenant quatre phases distinctes. Chaque étape joue un rôle crucial dans la détermination du classement final.
Étape 1 : Préparer – Compréhension et Normalisation des Requêtes
Cette première phase transforme la requête utilisateur en un format optimisé pour le traitement suivant. Discovery Engine expose plusieurs capacités clés :
Mappages de Synonymes Temporalisés
Un aspect révélateur : Google permet de configurer des listes de contrôle de synonymes avec des plages temporelles. Cela signifie que les mappages de synonymes peuvent varier selon les périodes. Par exemple, les termes politiques ou culturels évoluent constamment, et Google ajuste activement comment les requêtes sont étendues en fonction du contexte temporel.
Cette découverte implique que l’optimisation sémantique n’est pas statique. La signification des termes se transforme, et Google gère dynamiquement cette dérive sémantique à travers des mappages ajustables dans le temps.
Configuration de l’Autocomplétion
Les paramètres d’autocomplétion révèlent l’approche de Google pour la prédiction de requêtes :
- Suggestions maximum : configurable pour contrôler la diversité des candidats
- Longueur minimum de déclenchement : détermine quand la prédiction s’active
- Ordre de correspondance : deux modes distincts disponibles
- Les suggestions commencent par le terme tapé (appariement de préfixe)
- Les suggestions peuvent correspondre n’importe où dans le terme (appariement de sous-chaîne)
- Sources multiples : automatique, contenu documentaire, historique de recherche, événements utilisateur ou attributs définis par le schéma
Le paramètre “ordre de correspondance” est particulièrement révélateur. Google offre deux options : l’appariement par préfixe classique et l’appariement par sous-chaîne qui permet une interprétation plus flexible. Pour AI Mode, l’appariement par sous-chaîne permettrait de relier des entrées partielles à des correspondances de concepts plus larges.
Configuration du Schéma Structuré
Discovery Engine expose un panneau de configuration de schéma avec des contrôles au niveau des champs qui correspondent à ce que nous avons vu dans les données publiques sur le classement Google. Chaque champ peut être configuré avec plusieurs attributs :
- Nom du champ : l’identifiant de ce champ de données
- Type : texte, nombres, dates ou booléen
- Array : le champ contient-il plusieurs valeurs ou une seule
- Searchable (Recherchable) : améliore la récupération pour ce champ
- Indexable (Indexable) : active le filtrage et la facettisation
- Retrievable (Récupérable) : retourne ce champ dans les résultats
Cette séparation à trois niveaux des propriétés (Searchable, Indexable, Retrievable) révèle comment Google conçoit le traitement des données structurées :
- Un champ peut être recherchable mais pas récupérable : il influence le classement mais n’est pas montré aux utilisateurs
- Un champ peut être indexable mais pas recherchable : il peut être filtré mais ne contribue pas à la correspondance textuelle
- Un champ peut être récupérable mais pas indexable : il est retourné dans les résultats mais ne peut pas être utilisé pour le filtrage
Étape 2 : Récupérer – Sélection et Traitement des Documents
Cette phase trouve les documents les plus pertinents de l’entrepôt de données en fonction de la requête traitée, puis applique le traitement au niveau du document.
Le Pipeline de Chunking : Comment Google Divise le Contenu
La configuration de traitement de Discovery Engine révèle des indices importants sur la segmentation des documents par Google :
Options d’Analyseur
- Analyseur de document par défaut
- Analyseur de mise en page avec annotation de table et d’image
- Amélioration Gemini (prévisualisation) : utilisation du LLM pour améliorer la compréhension des documents
Configuration du Chunking
- Le chunking avancé peut être activé
- Limite de taille de chunk : 500 tokens maximum (non fixe, mais plafond)
- Option pour inclure les en-têtes ancêtres dans les chunks
Cette limite de 500 tokens nous dit quelque chose d’essentiel : Google Discovery Engine plafonne les segments de récupération à environ 375 mots maximum. Les chunks peuvent être plus petits, mais ne dépasseront jamais cette limite. Cela signifie que le contenu doit être structuré de manière que les informations clés soient auto-contenues dans des sections d’environ 500 tokens.
L’option “inclure les en-têtes ancêtres dans les chunks” est significative. Quand elle est activée, la hiérarchie des en-têtes voyage avec chaque chunk. Si un chunk provient de contenu sous H1 > H2 > H3, ces en-têtes sont préservés comme contexte. Cela signifie que votre structure d’en-têtes ne sert pas seulement à vos lecteurs ; elle fournit un contexte topique à chaque segment récupéré.
L’option amélioration Gemini suggère que Google utilise déjà le traitement par LLM pendant l’indexation, pas seulement au stade de la présentation. Cela améliore la compréhension documentaire au moment où le contenu est ingéré.
Étape 3 : Signaler – Les Sept Signaux de Classement Révélés
Cette phase est le cœur du système. Les documents récupérés sont traités à travers plusieurs couches de signaux pour produire une liste classée finale. Discovery Engine expose sept signaux distincts dans son Signal Viewer.
Les Sept Signaux de Classement
| Signal | Description | Mesure |
|---|---|---|
| Base Ranking | Score de pertinence initiale | Pertinence avant ajustements |
| Gecko (Embedding Adjustment) | Similarité sémantique query-document | Score du modèle d’embedding Google |
| Jetstream (Semantic Relevance) | Score du modèle de cross-attention | Comprend le contexte et la négation |
| Keyword Matching | Fréquence et pertinence des mots-clés | Algorithme BM25 |
| Predicted Conversion (PCTR) | Probabilité d’engagement utilisateur | Système à trois niveaux |
| Freshness | Score de récence | Ajustement pour requêtes sensibles au temps |
| Boost/Bury | Ajustement manuel par règles métier | Promotion/rétrogradation explicite |
Signal 1 : Base Ranking
Le score de pertinence initiale avant tous les ajustements. C’est probablement la sortie de l’algorithme de classement traditionnel de Google, la fondation que tout le reste modifie. Cela confirme que le classement n’est pas basé sur un seul réseau de neurones opaque, mais sur une pile de signaux distincts et interprétables.
Signal 2 : Gecko (Embedding Adjustment)
Le modèle Gecko de Google mesure la similarité sémantique entre les embeddings de requête et de document. C’est le score de similarité vectorielle. L’implication d’optimisation est claire : l’appariement pur de mots-clés n’est pas suffisant. Votre contenu doit être aligné sémantiquement avec l’intention de la requête au niveau de l’embedding.
Signal 3 : Jetstream (Semantic Relevance)
C’est un signal majeur. Google utilise un modèle de cross-attention appelé Jetstream qui “comprend mieux le contexte et la négation comparé aux embeddings seuls.”
Les modèles de cross-attention traitent la requête et le document ensemble, permettant une compréhension nuancée que la similarité d’embedding seule ne peut pas capturer. La mention explicite de la gestion de la négation suggère que Jetstream peut comprendre les patterns “pas X” et “sans Y” que les embeddings classiques peinent à capturer.
L’implication d’optimisation est directe : écrivez du contenu qui aborde explicitement ce qu’une chose est ET ce qu’elle n’est pas. Un classement conscient de la négation signifie que clarifier les distinctions compte vraiment.
Signal 4 : Keyword Matching (BM25)
Le classement classique de fréquence et pertinence des mots-clés, probablement BM25 ou une variante. Cela confirme que l’optimisation traditionnelle des mots-clés n’est pas morte. C’est l’un des sept signaux dans la pile de classement.
Signal 5 : Predicted Conversion (PCTR/PCVR)
C’est le signal d’engagement. PCTR (Predicted Click-Through Rate) et PCVR (Predicted Conversion Rate) sont calculés à partir des données historiques d’interaction utilisateur.
La section Data Quality de Discovery Engine révèle que ce n’est pas un signal unique, mais un système à trois niveaux avec des seuils de qualité :
TIER 1 : Popularité
- Dérivée des interactions utilisateur sur les documents
- Plus les utilisateurs interagissent avec un document, plus le boost est fort
- Agrégée sur tous les entrepôts de données du projet Google Cloud
- Si un entrepôt a suffisamment d’événements, le signal s’active au niveau du projet
TIER 2 : Modèle PCTR (Predicted Click-Through Rate)
- Prédit la probabilité qu’un utilisateur clique sur un document donné le contexte
- Google affirme explicitement que c’est “un facteur important considéré dans le classement”
- Spécifique à l’application (lié à une application de recherche particulière)
- Compte uniquement les événements d’entrepôts de données liés à l’app actuelle
- A des seuils minimum et optimal pour la qualité des données
TIER 3 : Modèle PCTR Personnalisé
- Incorpore les signaux spécifiques à l’utilisateur : métadonnées utilisateur, historique de recherche individuel, patterns comportementaux
- S’active uniquement après 100 000+ requêtes traitées
- Utilisateur-spécifique, pas seulement document-spécifique
- Représente le plus haut niveau de sophistication du signal d’engagement
Chaque tier affiche des statuts Optimal, Suboptimal et Bloqué, ce qui signifie qu’il y a des seuils durs où le signal fonctionne bien, fonctionne partiellement, ou est complètement désactivé en raison de données insuffisantes.
Signal 6 : Freshness (Fraîcheur)
Le score de récence s’ajuste en fonction du type de requête. Discovery Engine note que cela est “particulièrement important pour les requêtes sensibles au temps.”
Signal 7 : Boost/Bury
Ajustement manuel de -1 à +1 basé sur des règles métier. L’interface de configuration permet :
- Sélectionner un entrepôt de données
- Appliquer des filtres utilisant les opérateurs AND/OR/NOT
- Correspondance de phrase exacte avec guillemets
- Ajustement par curseur de Bury (-1) à Boost (+1)
C’est probablement comment les catégories E-E-A-T et l’autorité de source sont implémentées, comme des règles de boost/bury sur les attributs de source.
Comment Ces Signaux Se Combinent
Le Signal Viewer affiche tous les sept signaux comme colonnes séparées, avec Position comme résultat final. Cela signifie que Google utilise une fusion multi-signaux, probablement une combinaison apprise de tous les sept signaux pour produire le classement final.
Étape 4 : Servir – Génération de Réponses et Contrôles de Contenu
Cette phase génère et formate la réponse finale, en appliquant la synthèse LLM et le filtrage de sécurité.
Configuration du Type de Recherche
Discovery Engine offre trois types de recherche qui correspondent conceptuellement aux produits de consommation de Google :
| Configuration Discovery Engine | Équivalent Google Consumer Probable |
|---|---|
| Search – list with results | Recherche Google traditionnelle |
| Search with an answer | Vue d’ensemble IA (AI Overviews) |
| Search with follow-ups | AI Mode |
L’alignement des noms et fonctionnalités est trop proche pour être une coïncidence. “Search with follow-ups” décrit exactement ce que AI Mode fait : une expérience de recherche conversationnelle avec contexte multi-tours.
Configuration du LLM
La couche de service permet la sélection et la personnalisation du modèle :
- Sélection de modèle : Gemini 2.5 Flash est le défaut, mais n’importe quel modèle peut être sélectionné
- Personnalisation de réponse :
- Instructions personnalisées pour le ton, style et longueur
- Détection automatique de langue ou sélection manuelle
- Bascule de questions associées
- Sélection de source d’image pour les images de réponse
Le champ “instructions personnalisées” est significatif. Il suggère que le style de réponse d’AI Mode est optimisé par prompt, pas codé en dur. Google peut ajuster la génération de réponses à travers l’ajustement d’instructions.
Portes de Qualité et Sécurité
Plusieurs filtres agissent comme des portes finales avant la présentation :
- Ignorer pas de résumé : Sauter les messages “aucun résumé disponible”
- Ignorer requêtes adversariales : Bloquer les réponses LLM sur les requêtes adversariales détectées
- Ignorer contenu peu pertinent : Empêcher les réponses LLM quand la pertinence du contenu est trop faible
Le filtre “contenu peu pertinent” est important. Même si le contenu franchit l’étape Signal, il peut être bloqué à Serve si le LLM détermine qu’il n’est pas assez pertinent pour fonder une réponse.
Architecture Complète : Le Pipeline Unifié de Google
Voici le flux complet basé sur l’architecture de Discovery Engine :
Étape 1 – Préparer
- Requête utilisateur → Expansion de synonymes temporalisée → Modèle de prédiction d’autocomplétion → Requête transformée avec contexte
Étape 2 – Récupérer
- Requête transformée → Consultation d’entrepôt de données → Récupération segmentée (jusqu’à 500 tokens par chunk, optionnellement avec en-têtes ancêtres) → Analyse de mise en page de tables/images → Compréhension de document améliorée par Gemini → Ensemble candidat
Étape 3 – Signaler
- Ensemble candidat → Notation à sept signaux :
- Base Ranking (algorithme central)
- Similarité Gecko embedding
- Pertinence cross-attention Jetstream
- Correspondance de mots-clés BM25
- Signaux d’engagement (Popularité → PCTR → PCTR personnalisé à trois niveaux)
- Score de fraîcheur
- Règles métier Boost/Bury
- → Fusion multi-signaux → Liste classée final
Étape 4 – Servir
- Résultats Top N → Gemini 2.5 Flash (ou modèle sélectionné) → Application d’instructions personnalisées → Filtrage adversarial/basse-pertinence → Génération de réponse ancrée → Questions associées → Réponse AI Mode rendue
Implications pour l’Optimisation de Recherche IA
Cette architecture révèle comment Google conçoit le classement de recherche alimenté par IA. Bien que nous ne puissions pas affirmer avec certitude que AI Mode utilise un code identique, les principes sous-jacents sont probablement similaires.
Recommandations d’Optimisation Pratiques
1. Structurer le Contenu en Sections de ~500 Tokens
Chaque point majeur devrait être auto-contenu dans environ 500 tokens (environ 375 mots). C’est l’unité de récupération maximale. Divisez votre contenu en blocs informatifs distincts plutôt que de longs articles amorphes.
2. Utiliser une Hiérarchie d’En-têtes Claire
Quand les en-têtes ancêtres sont inclus avec les chunks, les segments portent leur contexte H1/H2/H3. Une hiérarchie d’en-têtes bien structurée signifie que vos chunks sont étiquetés topiquement. Cela améliore significativement la récupération contextuelle.
3. Optimiser le Contenu Sémantiquement
Au-delà de la correspondance de mots-clés purs, votre contenu doit s’aligner sémantiquement avec l’intention de requête. Utilisez une terminologie variée et contextuelle qui couvre le champ sémantique complet de votre sujet. Les synonymes temporalisés de Google signifient que la terminologie historique et actuelle comptent toutes les deux.
4. Adresser Explicitement Positif et Négatif
Puisque Jetstream gère la négation mieux que les embeddings classiques, écrivez du contenu qui clarifie non seulement ce qu’une chose EST, mais aussi ce qu’elle N’EST PAS. Cela améliore la compréhension nuancée du système.
5. Cibler l’Engagement Utilisateur
L’engagement n’est pas un signal unique mais un système à trois niveaux. Des sites avec plus de données d’interaction utilisateur déverrouillent des niveaux de signal de classement plus sophistiqués. La personnalisation ne s’active qu’après 100 000+ requêtes.
6. Optimiser la Fraîcheur de Manière Appropriée
La fraîcheur est dépendante de la requête. Pour les sujets sensibles au temps, le contenu récent reçoit un boost. Pour les sujets intemporels, la fraîcheur peut compter moins. Analysez le type de requête de votre audience cible.
7. Maintenir une Densité de Pertinence Élevée
Les contenus peu pertinents sont filtrés même s’ils se classent bien. Chaque section devrait contribuer à la pertinence de la requête. Évitez le contenu de remplissage ou les diversions tangentielles.
8. Écrire pour la Synthèse Ancrée
Le LLM est limité à ancrer les réponses dans le contenu récupéré. Votre contenu doit avoir des déclarations claires et extractibles. Utilisez une formulation explicite plutôt qu’implicite. Évitez les patterns de manipulation qui déclenchent la détection adversariale.
Conclusion : L’Importance de Comprendre Discovery Engine
Discovery Engine n’est pas l’exact architecture d’AI Mode. Mais c’est un aperçu inestimable de comment l’équipe d’ingénierie de Google conçoit la recherche alimentée par IA. Les sept signaux sont nommés. La limite de taille de chunk est définie. Les étapes du pipeline sont visibles.
Cette transparence accidentelle donne aux créateurs de contenu et aux professionnels SEO une compréhension sans précédent de ce qui compte vraiment dans la recherche de nouvelle génération. Pour les sites qui adaptent leur contenu à ces principes—segmentation intelligente, hiérarchies d’en-têtes, optimisation sémantique, engagement utilisateur—les avantages de classement devraient s’accumuler à mesure que AI Mode devient plus omniprésent.
La question n’est pas si vous connaissez cette architecture. La question est si vous allez l’utiliser pour optimiser votre contenu.
L'auteur du blog
Je suis Nicolas Dayez, consultant SEO/GEO basé à Lille, et je transforme la visibilité en ligne de mes clients en résultats commerciaux concrets. Avec plus de 6 années d'expertise dans le référencement naturel, j'aide les entreprises à attirer plus de trafic qualifié et à convertir leurs visiteurs en clients fidèles.
