Les démos de Google I/O 2026 ne montrent plus des résultats de recherche. Elles montrent des transactions finalisées. Un utilisateur demande à l'agent AI de réserver un vol, un restaurant, un plombier — et l'agent exécute. Le site web du prestataire n'apparaît à aucun moment dans la démonstration. C'est le nouveau problème de visibilité business que Matt Southern a documenté pour Search Engine Journal : le consumer path fonctionne, mais le business n'a aucune idée de pourquoi il a été choisi — ni même s'il était dans la liste.
L'architecture des démos I/O : ce que Google a montré (et caché)
Chaque démo majeure de Google I/O 2026 suivait le même schéma. L'utilisateur formule une intention complexe en langage naturel. L'agent AI (Project Astra, Gemini, ou une variante) décompose l'intention en sous-tâches. Il interroge des sources structurées (Google Business Profile, APIs partenaires, données de réservation). Il propose une option — parfois une seule — et exécute l'action.
Le détail qui change tout : aucune de ces démos ne montrait de SERP classique. Pas de liste de 10 liens bleus. Pas d'AI Overview avec des citations cliquables. L'agent agit comme un intermédiaire opaque entre la demande et la transaction.
Ce que ça signifie pour le modèle mental SEO
Le SEO classique repose sur un modèle où la visibilité = présence dans les résultats de recherche. Vous optimisez pour apparaître, l'utilisateur clique, vous convertissez sur votre site. Dans le modèle démontré à I/O, la visibilité devient : être sélectionné par l'agent comme fournisseur de la transaction, sans que l'utilisateur ne visite jamais votre propriété web.
Ce n'est pas une spéculation. C'est ce que Sundar Pichai a confirmé sur scène : search, agents et tools convergent vers une interface unique. Le site web devient un fournisseur de données structurées pour l'agent, pas une destination pour l'utilisateur.
La boîte noire de la sélection
Le problème business fondamental : comment l'agent choisit-il quel restaurant recommander, quel hôtel réserver, quel prestataire contacter ? Google n'a fourni aucune documentation sur les critères de ranking de l'agent. Contrairement au Search organique où des années de reverse engineering ont permis de comprendre les facteurs de classement, le mécanisme de sélection agentique est entièrement opaque.
Ce qu'on peut déduire de l'architecture visible : l'agent s'appuie sur des données structurées (Google Business Profile, schema.org, APIs commerciales), sur des signaux de confiance (avis, certification, historique de transaction), et probablement sur des accords commerciaux (partenariats API comme ceux avec OpenTable ou Booking déjà en place).
Les données structurées ne suffisent plus : il faut être machine-readable à tous les niveaux
La réponse instinctive de la communauté SEO face à ce type de changement est : « ajoutez plus de schema.org ». C'est nécessaire mais insuffisant. Le problème révélé par les démos I/O est plus profond : votre business doit être compréhensible par une machine à chaque couche de son identité numérique.
Schema.org : le minimum requis, pas le différenciateur
Votre markup structured data doit être irréprochable. Pas parce que ça garantit la sélection par l'agent, mais parce que son absence vous disqualifie. Voici un exemple concret pour un service local — le type de business directement ciblé par les démos I/O :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://www.plomberie-martin-lyon.fr/#business",
"name": "Plomberie Martin Lyon",
"description": "Dépannage plomberie urgence et rénovation sanitaire à Lyon et agglomération. Intervention sous 2h, devis gratuit.",
"url": "https://www.plomberie-martin-lyon.fr",
"telephone": "+33472123456",
"email": "[email protected]",
"address": {
"@type": "PostalAddress",
"streetAddress": "45 rue de la République",
"addressLocality": "Lyon",
"postalCode": "69002",
"addressRegion": "Auvergne-Rhône-Alpes",
"addressCountry": "FR"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 45.7578,
"longitude": 4.8320
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "07:00",
"closes": "20:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "08:00",
"closes": "17:00"
}
],
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "234"
},
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Services de plomberie",
"itemListElement": [
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Dépannage urgence plomberie",
"description": "Intervention en moins de 2h pour fuites, canalisations bouchées, chauffe-eau en panne"
},
"priceSpecification": {
"@type": "PriceSpecification",
"price": "89",
"priceCurrency": "EUR",
"description": "Forfait déplacement + diagnostic"
}
}
]
},
"sameAs": [
"https://www.google.com/maps/place/?q=place_id:ChIJ...",
"https://www.pagesjaunes.fr/pros/plomberie-martin-lyon"
]
}
</script>Les points critiques dans ce markup : hasOfferCatalog avec des prix explicites (l'agent a besoin de comparer), openingHoursSpecification détaillé (l'agent filtre par disponibilité), et sameAs qui établit le lien entre vos propriétés numériques. Sans ces éléments, un agent qui cherche « plombier disponible maintenant à Lyon, pas trop cher » n'a aucune donnée pour vous évaluer.
Pour approfondir la question de la lisibilité machine de votre marque, l'article sur ce qui rend une marque machine-readable en AI search détaille les couches supplémentaires au-delà du schema.org.
Google Business Profile : votre API de facto pour l'agent
Les démos I/O montraient des résultats provenant de sources structurées, et Google Business Profile (GBP) est la source structurée la plus directe pour les business locaux. Le problème : la majorité des GBP sont remplis au minimum — nom, adresse, téléphone — sans les attributs riches que l'agent pourrait exploiter.
Vérifiez systématiquement dans la Search Console et dans le GBP Manager :
- Les catégories secondaires (un plombier qui fait aussi de la climatisation doit le déclarer)
- Les attributs de service (devis gratuit, intervention d'urgence, paiement en ligne)
- Les produits/services avec prix
- Les Q&A pré-remplis (les agents AI consomment cette donnée)
- Les posts Google réguliers (signal de fraîcheur et d'activité)
Scénario concret : un réseau de 120 agences immobilières face au shift agentique
Prenons un cas réaliste. Un réseau immobilier français gère 120 agences physiques, un site central de 18 000 pages (annonces + pages agences + contenu éditorial), et 120 fiches Google Business Profile.
L'état actuel
Le site génère 340 000 sessions organiques/mois. Les fiches GBP génèrent environ 45 000 actions/mois (appels, itinéraires, visites site). Le trafic organique représente 60% des leads qualifiés.
Le scénario I/O appliqué
Un utilisateur dit à Gemini : « Je cherche un appartement 3 pièces à Bordeaux, budget 250K, proche transports, avec un agent qui parle anglais ». L'agent doit :
- Filtrer les annonces par critères (localisation, prix, surface)
- Matcher avec une agence locale
- Identifier les compétences spécifiques de l'agent (langue)
- Proposer une prise de rendez-vous
Si le site du réseau sert ses annonces en client-side rendering React sans structured data complète, l'agent ne peut pas parser les critères. Si les fiches GBP des 120 agences ne mentionnent pas les langues parlées, l'agent ne peut pas filtrer. Si aucune API de prise de rendez-vous n'est exposée, l'agent ne peut pas finaliser la transaction.
Le plan d'action technique
Première étape : auditer la couverture structured data sur les 18 000 pages. Un crawl Screaming Frog avec extraction custom des JSON-LD révèle la réalité :
# Crawl ciblé avec extraction structured data
screaming-frog-cli --headless \
--url "https://www.reseau-immo-exemple.fr" \
--max-uri 20000 \
--extract-json-ld \
--export-tabs "Internal:All,Structured Data:All" \
--output-folder ./audit-sd/ \
--config custom-extraction.seospider
# Extraction custom dans Screaming Frog :
# Regex pour détecter les pages annonces sans schema RealEstateListing
# XPath: //script[@type='application/ld+json'][not(contains(.,'RealEstateListing'))]Résultat typique sur ce type de site : 30 à 40% des pages annonces ont du structured data Product (hérité d'un template e-commerce) au lieu de RealEstateListing. Les pages agences ont du LocalBusiness mais sans makesOffer, sans areaServed, sans knowsLanguage.
Deuxième étape : enrichir les fiches GBP via l'API Google Business Profile. Un script automatisé peut mettre à jour les 120 fiches en une passe :
import { google } from 'googleapis';
interface AgencyData {
locationId: string;
languages: string[];
services: string[];
attributes: { name: string; values: string[] }[];
}
async function updateGBPAttributes(agencies: AgencyData[]) {
const mybusiness = google.mybusinessbusinessinformation('v1');
for (const agency of agencies) {
try {
// Mise à jour des attributs structurés
await mybusiness.locations.patch({
name: `locations/${agency.locationId}`,
updateMask: 'attributes,serviceItems',
requestBody: {
attributes: agency.attributes.map(attr => ({
name: attr.name,
values: attr.values,
})),
serviceItems: agency.services.map(service => ({
structuredServiceItem: {
serviceTypeId: service,
},
})),
},
});
console.log(`Updated: ${agency.locationId}`);
} catch (error) {
// Log pour audit — chaque fiche non mise à jour
// est une agence invisible pour l'agent
console.error(`Failed: ${agency.locationId}`, error.message);
}
}
}
// Données enrichies par agence
const agencies: AgencyData[] = [
{
locationId: 'abc123',
languages: ['fr', 'en', 'es'],
services: ['residential_sales', 'property_management', 'rental'],
attributes: [
{ name: 'has_wheelchair_accessible_entrance', values: ['true'] },
{ name: 'requires_appointments', values: ['false'] },
],
},
// ... 119 autres agences
];
updateGBPAttributes(agencies);Troisième étape : exposer une capacité transactionnelle. Google a démontré à I/O que les agents finalisent des transactions. Si votre business ne propose aucun endpoint transactionnel, l'agent passera au concurrent qui en a un. Pour un réseau immobilier, ça signifie au minimum une prise de rendez-vous via un calendrier structuré (Cal.com, Calendly avec API, ou solution custom) dont l'URL est référencée dans le schema.org :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "RealEstateAgent",
"name": "Agence Bordeaux Centre",
"potentialAction": {
"@type": "ReserveAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://www.reseau-immo-exemple.fr/agences/bordeaux-centre/rdv?date={date}&service={service}",
"actionPlatform": [
"http://schema.org/DesktopWebPlatform",
"http://schema.org/MobileWebPlatform"
]
},
"result": {
"@type": "Reservation",
"name": "Rendez-vous estimation immobilière"
}
},
"knowsLanguage": ["fr", "en"],
"areaServed": {
"@type": "City",
"name": "Bordeaux",
"sameAs": "https://www.wikidata.org/wiki/Q1479"
}
}
</script>L'utilisation de potentialAction avec ReserveAction est documentée par Google comme un signal exploitable par les agents. Le urlTemplate avec des variables permet à l'agent de construire dynamiquement l'URL de réservation.
Le paradoxe de l'attribution : vous convertissez sans le savoir
Les démos I/O révèlent un problème business fondamental : l'attribution disparaît. Quand un agent AI réserve un restaurant pour un utilisateur, le restaurateur voit une réservation arriver — mais d'où ? Le referrer HTTP sera probablement google.com ou une variante, indifférenciable d'un clic Search classique. Ou pire, la transaction passera par une API partenaire sans aucun referrer lié au site du restaurateur.
Ce que vous pouvez mesurer aujourd'hui
Search Console reste votre meilleure source pour détecter les signaux précoces de ce shift. Surveillez spécifiquement :
- Impressions stables ou en hausse, clics en baisse : signe que votre contenu est consommé par l'AI sans générer de visite. Les AI Overviews modifient déjà la position effective de vos résultats.
- Requêtes conversationnelles en croissance dans le rapport de performances : « meilleur plombier urgence Lyon samedi » au lieu de « plombier Lyon ».
- Trafic direct en hausse inexpliquée : quand l'agent fournit votre numéro de téléphone ou votre adresse sans clic, l'utilisateur arrive en « direct » si jamais il visite votre site ensuite.
La difficulté, c'est que ces signaux sont faibles et ambigus pris individuellement. C'est leur combinaison sur plusieurs semaines qui révèle la tendance. Un monitoring automatisé avec un outil comme Seogard, qui détecte les variations d'impressions et de comportement de crawl, permet de capter ces dérives avant qu'elles n'impactent le business.
Le SSR comme prérequis de lisibilité agentique
Un point technique absent des analyses business de ce sujet : les agents AI de Google crawlent et parsent votre site différemment d'un navigateur humain. Et probablement différemment de Googlebot classique.
Si vos pages critiques (fiches produit, pages service, pages agences) dépendent de JavaScript client-side pour afficher le contenu et le structured data, vous êtes vulnérable. Le rendering JavaScript par Googlebot est documenté comme fonctionnel mais retardé. Pour un agent qui a besoin d'une réponse en temps réel, le délai est inacceptable.
Le test que vous devriez faire maintenant
Vérifiez ce que vos pages critiques exposent sans JavaScript :
# Récupérer le HTML brut (sans exécution JS)
# de vos pages transactionnelles
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
"https://www.votre-site.fr/services/depannage-urgence" \
| grep -c "application/ld+json"
# Si le résultat est 0, votre structured data est injecté côté client
# L'agent AI ne le verra probablement pas en temps réel
# Vérifier aussi le contenu textuel visible
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
"https://www.votre-site.fr/services/depannage-urgence" \
| python3 -c "
import sys
from html.parser import HTMLParser
class TextExtractor(HTMLParser):
def __init__(self):
super().__init__()
self.text = []
self.skip = False
def handle_starttag(self, tag, attrs):
if tag in ('script', 'style', 'noscript'):
self.skip = True
def handle_endtag(self, tag):
if tag in ('script', 'style', 'noscript'):
self.skip = False
def handle_data(self, data):
if not self.skip and data.strip():
self.text.append(data.strip())
p = TextExtractor()
p.feed(sys.stdin.read())
content = ' '.join(p.text)
print(f'Content length: {len(content)} chars')
print(f'First 500 chars: {content[:500]}')
"Si le contenu visible sans JS est vide ou squelettique, vous avez un problème critique. Les articles sur les migrations SSR — notamment les risques avec Next.js App Router et les metadata ignorées sur les pages client ou Angular SSR mal configuré — documentent en détail les pièges techniques.
Préparer l'ère agentique : au-delà du SEO classique
Le shift démontré à Google I/O n'est pas un ajustement marginal. C'est un changement de paradigme comparable au passage du desktop au mobile. Les business qui s'adapteront en premier capteront un avantage disproportionné, comme ceux qui ont adopté le responsive design avant le mobile-first indexing.
Quatre actions concrètes, par ordre de priorité
1. Audit de lisibilité machine complète. Pas seulement le schema.org, mais l'ensemble de votre empreinte numérique : GBP, APIs exposées, contenu SSR, cohérence des données entre sources. Screaming Frog pour le crawl technique, l'outil de test des résultats enrichis de Google pour la validation schema, et un diff automatisé entre vos données GBP et votre site pour détecter les incohérences (adresses différentes, horaires contradictoires, services manquants).
2. Adoption des types schema.org transactionnels. ReserveAction, OrderAction, BuyAction — ces types existent dans la spec depuis des années mais sont largement sous-utilisés. Google les a explicitement mentionnés dans la documentation Structured Data pour les actions et les démos I/O montrent qu'ils deviennent fonctionnels, pas juste déclaratifs.
3. Stratégie de contenu pour les requêtes agentiques. Les agents décomposent les requêtes complexes en sous-requêtes factuelles. « Meilleur restaurant italien à Marseille pour un anniversaire, budget 50€/personne, terrasse, accessible PMR » devient cinq filtres distincts. Votre contenu et vos données structurées doivent répondre à chaque filtre individuellement. L'article sur les tendances AEO pour 2026 approfondit cette stratégie de contenu.
4. Monitoring des signaux de transition. Le passage d'un modèle SERP à un modèle agentique ne se fera pas en un jour. Il se fait progressivement, requête par requête, vertical par vertical. Le core update de mai 2026 coïncide avec les annonces I/O — ce n'est pas un hasard. Surveillez vos impressions Search Console par catégorie de requête, votre taux de clic par position (un CTR qui chute en position 1-3 signale une interception agentique), et le comportement de crawl sur vos pages transactionnelles.
Le trade-off à anticiper
Ce shift vers l'agentique comporte un risque structurel : la dépendance accrue envers Google comme intermédiaire. Aujourd'hui, même si Google domine le search, l'utilisateur arrive sur votre site et vous contrôlez l'expérience. Dans le modèle agentique, Google contrôle aussi la transaction. Le restaurateur qui reçoit une réservation via l'agent Google n'a pas capté l'email du client, n'a pas présenté sa carte de fidélité, n'a pas eu l'opportunité de faire de l'upsell.
C'est un arbitrage : accepter de jouer dans l'écosystème agentique pour ne pas disparaître, tout en maintenant des canaux directs (email, app, fidélité) pour les clients existants. La guidance de Google sur l'AI search, qualifiée de naïve par certains, ne mentionne évidemment pas ce trade-off.
Ce que les Googlers ont dit off-stage
Les démos sur scène sont calibrées pour impressionner. Ce qui se dit dans les sessions techniques et les couloirs est souvent plus révélateur. Comme documenté dans les échanges avec les Googlers hors scène à I/O 2026, plusieurs ingénieurs ont confirmé que le Merchant Center et Google Business Profile deviennent les « sources de vérité » pour les agents. Le site web reste un signal, mais un signal parmi d'autres — pas le signal principal.
Cette hiérarchie est cohérente avec l'architecture technique : un agent qui doit répondre en temps réel ne peut pas crawler, renderer et parser un site web à chaque requête. Il s'appuie sur des données pré-indexées, structurées, et accessibles via API. Si vos données business les plus critiques (prix, disponibilité, localisation, services) ne sont pas dans ces sources structurées, elles n'existent pas pour l'agent.
Le Cloudflare Agent Readiness Score est un indicateur émergent de cette tendance : l'infrastructure elle-même commence à se noter sur sa capacité à servir des agents AI, pas seulement des navigateurs.
L'enjeu réel derrière les démos
Les démos Google I/O 2026 ne montrent pas un futur hypothétique. Elles montrent un présent en déploiement progressif. Le problème de visibilité business qu'elles révèlent est technique avant d'être stratégique : si votre empreinte numérique n'est pas structurée, cohérente et transactionnelle à chaque couche, vous serez invisible pour le prochain canal d'acquisition dominant. Un outil de monitoring comme Seogard qui vérifie en continu la cohérence de vos structured data, la disponibilité de votre SSR et la stabilité de vos signaux techniques est le filet de sécurité minimal dans cette transition. Le SEO ne meurt pas — il mute en ingénierie de la lisibilité machine.