Siri + Gemini : impact concret sur la visibilité SEO

Apple vient de transformer un partenariat commercial en produit livré à 1,5 milliard d'appareils. L'intégration de Gemini dans Siri, annoncée à la WWDC 2025 et désormais déployée, redirige une partie significative des requêtes informationnelles vers un pipeline LLM qui ne passe plus par la page de résultats Google. Pour les équipes SEO, ce n'est pas un signal faible — c'est un changement d'architecture dans la distribution du trafic.

Le pipeline technique : comment Siri consomme le web via Gemini

Pour comprendre l'impact sur la visibilité, il faut d'abord comprendre le mécanisme. Siri ne "cherche" plus sur Google au sens classique. Le flux est désormais hybride :

L'utilisateur pose une question à Siri (voix ou texte).
Siri évalue si la requête relève d'une action locale (timer, appel, rappel) ou d'une requête informationnelle/transactionnelle.
Pour les requêtes informationnelles, Siri délègue à Gemini via l'API Apple Intelligence.
Gemini génère une réponse synthétisée, potentiellement enrichie par un appel au Google Search API (grounding), puis la renvoie à Siri.
Siri affiche une réponse conversationnelle, avec éventuellement un lien source — mais sans SERP.

Le point critique : l'étape 4. Le grounding de Gemini utilise les résultats de recherche Google comme contexte pour la génération, mais la réponse finale est une synthèse. L'utilisateur ne voit jamais la SERP. Il ne voit jamais vos meta descriptions. Il ne voit souvent même pas votre URL.

Ce que Gemini "voit" réellement de votre page

Quand Gemini effectue du grounding, il ne rend pas votre page comme un navigateur. Il consomme une version simplifiée — probablement le contenu extrait par le système de featured snippets / passages de Google, enrichi par le structured data disponible.

Concrètement, voici ce que Gemini reçoit pour générer sa réponse :

// Représentation simplifiée du contexte de grounding
{
  "query": "meilleur framework JavaScript SSR 2026",
  "grounding_sources": [
    {
      "url": "https://engineering.votre-site.com/comparatif-ssr-2026",
      "title": "Comparatif SSR 2026 : Next.js vs Nuxt vs Astro",
      "extracted_passage": "Next.js 15 domine pour les applications full-stack grâce au Server Components...",
      "structured_data": {
        "@type": "Article",
        "datePublished": "2026-05-20",
        "author": { "@type": "Person", "name": "Marie Dupont" }
      },
      "domain_authority_signal": 0.72
    },
    // ... 4-6 autres sources
  ]
}

Deux implications directes :

Votre contenu est consommé, pas visité. Le trafic organique classique diminue mécaniquement sur les requêtes informationnelles traitées par Siri.
Le structured data devient votre carte de visite. C'est la seule métadonnée exploitable par le LLM pour évaluer la fiabilité et la fraîcheur de votre contenu.

Ce mécanisme rappelle directement les enjeux soulevés par les démos de Google I/O sur la visibilité des entreprises — la synthèse LLM remplace la SERP, et les règles du jeu changent.

L'impact quantifiable : scénario d'un média tech à 12 000 pages

Prenons un cas concret. TechRecap.fr est un média tech avec 12 000 articles indexés, 450K sessions organiques mensuelles. 62% de leur trafic provient de requêtes informationnelles ("comment configurer X", "différence entre Y et Z", "meilleur outil pour W").

Avant Siri + Gemini

62% × 450K = 279K sessions/mois sur des requêtes informationnelles
Ces requêtes génèrent des clics depuis la SERP Google (position 1-3 capte ~40% du CTR)
Le site monétise via display ads : ~15€ RPM → ~4 185€/mois sur ce segment

Après déploiement massif (estimation conservatrice)

Apple détient environ 27% du marché mobile en France (Statcounter, données Q1 2026). Si 30% des requêtes informationnelles des utilisateurs iOS passent par Siri au lieu de Safari/Google :

Requêtes informationnelles impactées : 279K × 27% (part iOS) × 30% (adoption Siri) = ~22 600 sessions/mois potentiellement perdues
Impact revenus : ~339€/mois — pas catastrophique sur ce volume, mais la tendance est exponentielle avec l'adoption.

Le vrai danger n'est pas la perte immédiate. C'est l'absence de visibilité dans la réponse Siri. Si votre contenu est utilisé pour le grounding mais que l'utilisateur ne voit jamais votre marque, vous perdez à la fois le clic ET la notoriété.

Vérification dans Search Console

Google a commencé à tester des rapports dédiés pour le trafic AI. Surveillez ces métriques dans Search Console :

# Export des données Search Console via l'API pour détecter la baisse
# sur les requêtes informationnelles

curl -X POST \
  'https://www.googleapis.com/webmasters/v3/sites/https%3A%2F%2Ftechrecap.fr/searchAnalytics/query' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "startDate": "2026-05-01",
    "endDate": "2026-06-14",
    "dimensions": ["query", "device"],
    "dimensionFilterGroups": [{
      "filters": [{
        "dimension": "device",
        "expression": "MOBILE"
      }]
    }],
    "rowLimit": 5000,
    "dataState": "final"
  }'

# Comparer les impressions mobile vs desktop sur les requêtes "comment", 
# "quel", "meilleur", "différence" — une baisse asymétrique mobile 
# signale un transfert vers Siri

Les rapports AI dédiés en test dans Search Console devraient à terme permettre de distinguer le trafic issu du grounding Gemini. En attendant, la corrélation mobile/desktop est votre meilleur proxy.

Optimiser pour le grounding : le structured data comme levier principal

Si votre contenu va être consommé par un LLM plutôt que lu par un humain sur une SERP, la question devient : comment maximiser votre présence dans la réponse synthétisée ET obtenir l'attribution (le lien source) ?

Structured data : au-delà du basique

Le schema.org basique (Article, Product, FAQ) ne suffit plus. Les LLMs exploitent des signaux de fiabilité que le markup structuré peut fournir explicitement :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Configurer le SSR incrémental avec Next.js 15 et Vercel",
  "datePublished": "2026-06-10",
  "dateModified": "2026-06-13",
  "author": {
    "@type": "Person",
    "name": "Marie Dupont",
    "url": "https://techrecap.fr/auteurs/marie-dupont",
    "jobTitle": "Lead Frontend Engineer",
    "worksFor": {
      "@type": "Organization",
      "name": "TechRecap"
    },
    "sameAs": [
      "https://github.com/mariedupont",
      "https://linkedin.com/in/mariedupont"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "TechRecap",
    "url": "https://techrecap.fr",
    "logo": {
      "@type": "ImageObject",
      "url": "https://techrecap.fr/logo.png"
    }
  },
  "about": {
    "@type": "SoftwareApplication",
    "name": "Next.js",
    "applicationCategory": "DeveloperApplication",
    "softwareVersion": "15"
  },
  "proficiencyLevel": "Expert",
  "dependencies": "Node.js 20+, Vercel CLI 35+",
  "wordCount": 2847,
  "inLanguage": "fr",
  "isAccessibleForFree": true,
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": ["article h1", "article h2", "article > p:first-of-type"]
  }
}
</script>

Trois éléments critiques dans ce markup :

speakable — Cette propriété, documentée par Google, indique explicitement quelles sections de votre page sont adaptées à la lecture vocale. Siri est un assistant vocal. Le lien est direct. Le SpeakableSpecification permet de pointer les LLMs vers les passages les plus pertinents pour une synthèse orale.

proficiencyLevel et dependencies — Ces propriétés de TechArticle (schema.org) donnent au LLM un signal de spécialisation. Un article marqué "Expert" avec des dépendances techniques spécifiques sera préféré pour des requêtes techniques pointues.

author.sameAs — Les profils liés (GitHub, LinkedIn) servent de signal d'existence et de crédibilité de l'auteur. Google utilise déjà ces signaux pour l'E-E-A-T ; les LLMs en grounding font probablement de même.

L'initiative EntityMap pour fournir une vue structurée aux systèmes AI va exactement dans cette direction — structurer l'identité de votre entité pour les machines, pas pour les humains.

Le rendering SSR devient non-négociable

Siri + Gemini ne rend pas votre JavaScript. Si votre contenu dépend d'un hydratation côté client pour être lisible, il est invisible au grounding.

Ce n'est pas nouveau — Googlebot a le même problème, mais avec un rendering budget plus généreux. Le pipeline Gemini est plus restrictif : il consomme ce que Google a déjà extrait et indexé. Si votre page n'est pas correctement indexée à cause d'un problème SSR, elle n'entre même pas dans le pool de grounding.

Vérification du rendering pour le grounding

# Test 1 : Vérifier ce que Google voit réellement (contenu indexé)
# Utiliser l'inspection d'URL dans Search Console, puis comparer avec un fetch brut

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://techrecap.fr/articles/configurer-ssr-nextjs-15 \
  | pup 'article text{}' | head -50

# Test 2 : Comparer avec la version JS-rendered
# Dans Chrome DevTools : Ctrl+Shift+P → "Disable JavaScript" → recharger
# Si le contenu principal disparaît, votre page est invisible au grounding

# Test 3 : Vérification automatisée avec Screaming Frog
# Configuration > Spider > Rendering > JavaScript
# Puis comparer le crawl JS vs HTML brut
# Filtrer les pages où le H1 diffère entre les deux modes

Les régressions SSR sont les plus dangereuses car elles sont silencieuses. Un déploiement qui casse le server-side rendering — comme un passage de Vercel vers Railway qui multiplie le TTFB par 4 — peut faire disparaître votre contenu du pool de grounding sans aucune alerte dans Search Console avant le prochain recrawl.

Les frameworks modernes ajoutent des couches de complexité. Un composant heading mal configuré qui rend un div au lieu d'un h1, un useHead Nuxt dont les meta sont silencieusement écrasées par un layout enfant, un metadata async Next.js qui throw et sert les meta par défaut — chacun de ces bugs réduit la qualité du signal que Google transmet à Gemini pour le grounding.

Identifier et protéger le trafic à risque

Toutes vos pages ne sont pas également exposées au transfert vers Siri. Le risque est concentré sur un profil de requêtes très spécifique.

Requêtes à haut risque de cannibabilisation par Siri

Définitionnelles : "qu'est-ce que le SSR", "différence entre SSG et ISR"
How-to courtes : "comment activer le mode sombre CSS", "commande pour vider le cache DNS"
Comparatifs simples : "Next.js vs Nuxt 2026"
Factuelles : "dernière version de Node.js", "date de sortie iPhone 17"

Requêtes à faible risque (pour l'instant)

Transactionnelles : "acheter chaussures running homme" — Siri redirige vers Safari/une app
Navigationnelles : "site SNCF" — Siri ouvre l'app ou le site
Requêtes longue traîne complexes : "comment migrer un e-commerce Magento 2 vers Shopify avec redirection des 15K URL produits sans perdre le PageRank" — trop complexe pour une réponse synthétisée fiable

Vous pouvez segmenter votre trafic Search Console pour identifier l'exposition :

import pandas as pd

# Charger l'export Search Console (Performance > Pages > Export)
df = pd.read_csv('search_console_queries.csv')

# Patterns de requêtes informationnelles à risque Siri
risk_patterns = [
    r'^(qu est ce que|what is|comment|how to|différence entre|vs |comparatif)',
    r'^(meilleur|best|top \d)',
    r'^(définition|meaning of)',
    r'(c est quoi|pourquoi|when did)'
]

import re
pattern = '|'.join(risk_patterns)
df['siri_risk'] = df['query'].str.lower().str.contains(pattern, regex=True)

# Calculer l'exposition
risk_traffic = df[df['siri_risk'] == True]
total_clicks = df['clicks'].sum()
risk_clicks = risk_traffic['clicks'].sum()

print(f"Trafic total : {total_clicks:,} clics")
print(f"Trafic à risque Siri : {risk_clicks:,} clics ({risk_clicks/total_clicks*100:.1f}%)")
print(f"\nTop 20 requêtes à risque :")
print(risk_traffic.nlargest(20, 'clicks')[['query', 'clicks', 'impressions', 'position']])

# Identifier les pages les plus exposées
risk_pages = risk_traffic.groupby('page').agg({
    'clicks': 'sum',
    'impressions': 'sum'
}).sort_values('clicks', ascending=False)

print(f"\nTop 10 pages exposées :")
print(risk_pages.head(10))

Ce script vous donne une vue claire de votre surface d'exposition. Sur le cas TechRecap, cette analyse a révélé que 34% des clics provenaient de requêtes à risque — concentrées sur seulement 8% des pages (les guides "comment faire" et les pages de glossaire).

Stratégie d'adaptation : ne pas subir, architecturer

La réaction instinctive serait de se dire "il faut bloquer les LLMs". C'est contre-productif. Si vous bloquez le grounding, vous disparaissez de la réponse Siri ET vous perdez le lien d'attribution qui reste votre seule porte d'entrée.

1. Maximiser l'attribution dans les réponses LLM

Le grounding Gemini attribue des sources. Votre objectif est d'être la source citée, pas juste une source consommée silencieusement.

Pour cela :

Produisez des données originales. Les LLMs préfèrent citer la source primaire. Un benchmark que vous avez conduit vous-même, une étude avec des chiffres originaux — c'est ce qui génère des citations.
Structurez vos conclusions en passages autonomes. Gemini extrait des passages. Si votre conclusion clé est noyée dans un paragraphe de 300 mots, elle sera paraphrasée sans attribution. Si elle est dans un paragraphe court, clairement formulé, après un H2 explicite, elle sera citée verbatim avec lien source.

2. Déplacer la valeur vers le transactionnel

Les requêtes informationnelles pures vont être progressivement captées par les LLMs. La stratégie durable est de transformer vos pages informationnelles en passerelles vers des actions que Siri ne peut pas accomplir :

Un article "Comment optimiser les Core Web Vitals" → intégrer un outil d'audit interactif
Un comparatif "Next.js vs Nuxt" → intégrer un quiz de recommandation personnalisé
Un guide technique → intégrer un playground de code exécutable

3. Surveiller les changements de comportement utilisateur

Les données de clic sur les AI Overviews montrent déjà des patterns inattendus. Les utilisateurs qui reçoivent une réponse synthétisée cliquent moins, mais ceux qui cliquent ont un engagement significativement plus élevé (temps sur page, pages par session). Le trafic diminue en volume mais augmente en qualité.

Surveillez aussi le layout de la SERP Google elle-même — les positions organiques classiques sont repoussées de plus en plus bas, amplifiant l'effet de la synthèse LLM en haut de page.

4. Monitorer les user-agents AI

Les crawlers AI commencent à s'identifier. Vérifiez vos logs serveur :

# Identifier les crawlers AI dans vos access logs
grep -iE "(GPTBot|ChatGPT|Google-Extended|Applebot|anthropic-ai|ClaudeBot|PerplexityBot)" \
  /var/log/nginx/access.log \
  | awk '{print $1, $14}' \
  | sort | uniq -c | sort -rn | head -20

# Applebot est le crawler d'Apple — son activité croissante 
# sur vos pages informationnelles est un signal direct
# que votre contenu est candidat au grounding Siri

# Configurer un monitoring spécifique dans votre robots.txt
# ATTENTION : bloquer ≠ bonne stratégie (voir section précédente)
# Mais vous devez au minimum mesurer l'activité

# Ajout dans la config Nginx pour logger séparément les bots AI
map $http_user_agent $is_ai_bot {
    default 0;
    "~*Applebot" 1;
    "~*GPTBot" 1;
    "~*Google-Extended" 1;
    "~*ClaudeBot" 1;
    "~*PerplexityBot" 1;
}

# Dans le bloc server
access_log /var/log/nginx/ai_bots.log combined if=$is_ai_bot;

La montée en puissance d'Applebot dans vos logs est le signal avancé le plus fiable que vos pages entrent dans le pipeline Siri/Gemini. Les données récentes montrent que les bots représentent déjà 57% des requêtes web — et la part des bots AI dans ce chiffre croît chaque trimestre.

Le paradoxe Apple-Google et ses conséquences structurelles

L'aspect le plus sous-analysé de cette intégration est le paradoxe business qu'elle crée.

Apple paie Google environ 20 milliards de dollars par an pour que Google soit le moteur de recherche par défaut sur iOS et Safari. Ce deal est le cœur du modèle économique de Google Search sur mobile. Mais en intégrant Gemini dans Siri, Apple crée un canal qui contourne la SERP — c'est-à-dire le produit même pour lequel elle paie.

Le résultat est un conflit d'intérêts structurel :

Google veut que les requêtes passent par la SERP (c'est là que les ads génèrent du revenu).
Apple veut que les requêtes soient résolues dans Siri (c'est là que l'expérience utilisateur est la meilleure).
Gemini sert les deux : il fournit les réponses à Siri, mais il a besoin de l'index Google pour le grounding.

Pour les éditeurs de sites, ce conflit signifie une chose : le trafic organique sur iOS va se fragmenter entre la SERP classique (Safari) et Siri (réponse directe). Et vous n'avez aucune visibilité sur la répartition — pour l'instant.

C'est précisément le type de changement invisible que les outils de monitoring doivent détecter. Une baisse de 15% du trafic mobile organique sur vos pages informationnelles pourrait être un changement d'algorithme, un problème technique, ou un transfert vers Siri. Sans monitoring continu capable de corréler les signaux (baisse mobile asymétrique + hausse Applebot + stabilité desktop), vous pilotez à l'aveugle. Un outil comme Seogard qui surveille en continu les régressions SEO techniques et les variations de signaux permet de distinguer un vrai problème technique d'un shift structurel de distribution.

Les actions à lancer cette semaine

L'intégration Siri + Gemini n'est pas un événement futur — elle est déployée. Voici la checklist technique immédiate :

Audit structured data : passez toutes vos pages informationnelles au validateur schema.org. Ajoutez speakable, author.sameAs, dateModified. Le nombre de sites utilisant chaque type de schema montre que TechArticle et speakable restent largement sous-utilisés — c'est un avantage concurrentiel.

Audit SSR : vérifiez que 100% de vos pages servent le contenu critique en HTML initial. Un hero H1 dans un v-if invisible au fetch HTTP brut vous exclut du grounding.

Segmentation trafic : identifiez vos pages à risque avec le script Python ci-dessus. Priorisez la transformation de ces pages (ajout de valeur interactive, déplacement vers le transactionnel).

Monitoring Applebot : configurez le logging séparé dans Nginx. Établissez une baseline de crawl Applebot sur 30 jours.

Veille Search Console : suivez les rapports AI en test et activez-les dès qu'ils sont disponibles.

Le shift vers les réponses LLM est structurel, pas conjoncturel. Le May Core Update de Google qui favorise les pages matchant l'intent renforce cette logique : Google optimise son index pour que Gemini puisse y puiser des réponses de qualité. Votre visibilité future dépend de votre capacité à être la source que le LLM cite — pas celle qu'il paraphrase.