Pour répondre à une intention, un LLM ne lance pas une requête, mais plusieurs. Cet outil envoie votre requête à Gemini avec le Google Search Grounding et affiche les sous-requêtes réellement générées (webSearchQueries) — vos angles de contenu à couvrir. Aucune estimation, la donnée brute du modèle.
toolConfig.retrievalConfig — votre requête reste envoyée brute, sans un mot ajouté. Cache 24 h par couple requête + pays.
Le rapport IA générative (juin 2026) montre les pages vues dans les surfaces IA de Google, mais il n'est pas encore exposé par l'API (impressions, pages, pays, appareils — pas de requêtes ni de clics). Le pont : exportez les URLs de ce rapport et collez-les ci-dessous — l'outil retrouve via l'API Search Analytics les requêtes réelles où chaque page apparaît, puis lancez le fan-out sur ces requêtes. Connexion OAuth en lecture seule, directement dans votre navigateur : le jeton n'est jamais stocké ni transmis à un serveur tiers.
Chaque ligne est une requête que le modèle a envoyée à Google Search pour construire sa réponse. Traitez-les comme des sous-intentions à couvrir en clusters (sections H2/H3, FAQ, paragraphes de vos contenus existants) — pas une page par sous-requête, c'est le piège du hyper long-tail. En multi-passes, le badge classe la stabilité : FORT ≥ 60 % angle récurrent, à couvrir en priorité · MOYEN ≥ 30 % à considérer · BRUIT vu trop rarement, n'agissez pas dessus.
Le texte que Gemini a produit à partir des recherches ci-dessus. Utile pour voir comment il a assemblé l'information.
Les pages que le modèle a effectivement consultées pour répondre. Vos concurrents directs sur cette intention.
À l'ère des AI Overviews et de la recherche générative, Google ne se contente plus de matcher un mot-clé : il décompose l'intention en plusieurs requêtes, va chercher l'information, puis synthétise. Voir ces sous-requêtes, c'est voir la carte des sous-intentions qu'un contenu doit couvrir pour être cité. Un article qui répond à 8 des 10 sous-requêtes générées a une bien meilleure chance d'être repris qu'un article optimisé sur un seul mot-clé.
Il envoie votre requête telle quelle à l'API Gemini avec l'outil Google Search Grounding activé, puis lit le champ officiel groundingMetadata.webSearchQueries de la réponse. Ce sont les requêtes que le modèle a réellement formulées — pas une simulation textuelle, pas une déduction. En option, plusieurs passes agrègent les variations (le fan-out étant non déterministe) et affichent la fréquence de chaque sous-requête.
Un LLM ancré dans Google Search décompose l'intention selon le marché de l'utilisateur : « meilleure assurance auto » ne produit pas les mêmes sous-requêtes vu de France, de Belgique, du Luxembourg ou du Québec — opérateurs locaux, cadre réglementaire, vocabulaire (« assurance auto » vs « assurance automobile »), devise. Le sélecteur transmet la position et la langue de l'utilisateur simulé via le champ officiel toolConfig.retrievalConfig (latLng + languageCode) : c'est la seule façon de géolocaliser sans toucher à la requête. Les coordonnées personnalisées permettent de descendre à la ville pour les intentions locales (« plombier », « notaire »), et la langue se règle indépendamment du pays — indispensable au Luxembourg, en Suisse ou en Belgique, où le marché est le même mais la SERP change avec la langue.
Le bon réflexe : lancez la même requête sur deux pays et comparez les listes. Les sous-requêtes communes forment le socle du contenu ; les sous-requêtes propres à un pays sont vos sections locales — ou l'argument pour une page dédiée à ce marché.
L'API Gemini partage des briques technologiques avec la recherche grand public, mais les deux infrastructures peuvent avoir des couches d'orchestration ou de prompt système distinctes. Ce fan-out est donc un proxy très puissant du comportement de Google Search, pas une copie au caractère près de ce qu'affiche l'interface publique. Pour de l'optimisation de couverture sémantique, c'est nettement plus solide qu'une estimation par prompt.
Pour aller plus loin, croisez ces sous-requêtes avec l'outil Sémantique (ce que Google comprend d'une page) ou le Site Focus Score (couverture thématique du site).
Une clé Gemini gratuite (Google AI Studio) dans les Réglages. À défaut, votre clé Google Cloud si l'API Generative Language y est activée.
L'offre gratuite Gemini couvre un usage normal. Chaque passe = 1 appel avec grounding. La profondeur multiplie les appels.
Deux cas : le modèle a répondu de mémoire (le KPI « Grounding » l'indique — information légitime : la requête est « résolue » sans web), ou une panne temporaire de grounding côté Google. Dans ce dernier cas, changez de modèle dans les Réglages et comparez avant de chercher un bug.
Souvent, oui — sur les intentions à composante locale, réglementaire ou concurrentielle (assurance, banque, santé, e-commerce). Sur une intention purement informationnelle, les deux listes peuvent être quasi identiques : c'est une mesure, pas une promesse. Comparez France et Luxembourg sur la même requête, l'écart est votre réponse.
Non — piège du hyper long-tail. Regroupez les signaux FORTS en clusters thématiques et couvrez-les dans vos contenus existants.
Source des données : champ groundingMetadata.webSearchQueries renvoyé par l'API Google Gemini (generativelanguage.googleapis.com), appelée directement depuis votre navigateur avec votre clé. Aucune donnée ne transite par un serveur tiers. Les requêtes affichées sont générées par le modèle, non inventées par l'outil. La requête est envoyée brute, sans enrobage : un prompt d'habillage contaminerait le fan-out mesuré.
Géolocalisation : le pays choisi est transmis par le champ officiel toolConfig.retrievalConfig (latLng = coordonnées de la principale ville de recherche du pays, languageCode au format BCP 47) — pas en ajoutant « en France » à votre requête. Sans sélection, aucun toolConfig n'est envoyé : Google se cale alors sur l'adresse IP depuis laquelle vous appelez l'API (votre connexion, ou celle de votre VPN). C'est un signal de localisation transmis au modèle, pas une garantie de SERP locale au caractère près. Les liens SERP et le rank check reprennent les mêmes gl/hl pour rester cohérents.
À savoir : le fan-out est non déterministe — deux passes identiques donnent des listes différentes ; c'est le comportement réel du modèle, d'où l'agrégation par fréquence · les métadonnées peuvent revenir vides sur une passe malgré une recherche effectuée (bug connu de l'API, l'outil retente automatiquement) · facturation du grounding : famille 2.5 = par prompt ancré (~35 $/1000 après 1 500/jour gratuits), famille 3.x = par requête de recherche exécutée (~14 $/1000 après 5 000 prompts/mois gratuits — avec ~9 requêtes de fan-out par prompt en moyenne, la note grimpe plus vite qu'il n'y paraît).