Googlebot n'est plus le seul robot qui compte. Depuis 2025, des agents IA autonomes — capables de naviguer entre des services, de passer des commandes, de comparer des offres — frappent à la porte de vos serveurs. Et ils ne lisent pas le HTML comme un crawler classique. Quatre protocoles émergents structurent ce nouveau web agentique : MCP (Model Context Protocol), A2A (Agent-to-Agent), NLWeb (Natural Language Web) et AGENTS.md. Si vous gérez un site de plus de quelques centaines de pages, ces standards vont redéfinir la manière dont votre contenu est consommé — bien au-delà des SERPs traditionnelles.
Le web agentique : un changement de paradigme pour le crawl
Le web tel que les moteurs de recherche le consomment repose sur un modèle vieux de 30 ans : un robot HTTP récupère du HTML, extrait des liens, suit des directives dans robots.txt, et indexe du texte. Ce modèle suppose un consommateur passif qui lit des documents.
Les agents IA ne fonctionnent pas ainsi. Un agent LLM comme ceux propulsés par GPT-4, Claude ou Gemini ne "lit" pas une page produit — il exécute une tâche. "Trouve-moi un vol Paris-Tokyo sous 600€ en mai avec escale maximale d'une heure" implique de requêter des APIs, comparer des résultats structurés, et potentiellement interagir avec des services tiers pour réserver.
Ce glissement a trois conséquences techniques immédiates :
- Le HTML seul ne suffit plus. Un agent a besoin d'interfaces structurées (APIs, schémas, protocoles de communication) pour agir, pas seulement pour lire.
- Le crawl budget prend une nouvelle dimension. Quand des centaines d'agents autonomes interrogent vos endpoints, la gestion de la charge serveur dépasse le cadre de Googlebot et du crawl budget classique.
- Les directives d'accès doivent évoluer.
robots.txta été conçu pour des crawlers web. Il ne couvre pas les cas d'usage d'agents qui veulent interagir avec vos services, pas simplement les indexer.
C'est exactement ce vide que MCP, A2A, NLWeb et AGENTS.md cherchent à combler. Chaque protocole adresse une couche différente du problème.
MCP (Model Context Protocol) : l'interface entre LLM et données
Ce que MCP résout
Développé par Anthropic et publié en open source fin 2024, le Model Context Protocol standardise la manière dont un modèle de langage accède à des sources de données externes. Avant MCP, chaque intégration LLM-outil était ad hoc : un plugin ChatGPT pour Expedia, un autre pour Kayak, chacun avec son propre format de requête et de réponse.
MCP propose une architecture client-serveur simple : le LLM (client) envoie des requêtes structurées à un serveur MCP qui expose des "tools" (fonctions appelables) et des "resources" (données accessibles). Le format est JSON-RPC 2.0 — un choix pragmatique qui s'appuie sur un standard existant plutôt que d'en inventer un nouveau.
Implémentation concrète
Voici à quoi ressemble un serveur MCP minimal exposant un catalogue produit e-commerce :
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "catalog-server",
version: "1.0.0",
});
// Expose un outil de recherche produit
server.tool(
"search_products",
"Recherche dans le catalogue produit par catégorie, prix et disponibilité",
{
category: z.string().describe("Catégorie produit (ex: 'chaussures-running')"),
max_price: z.number().optional().describe("Prix maximum en euros"),
in_stock: z.boolean().default(true).describe("Uniquement les produits en stock"),
},
async ({ category, max_price, in_stock }) => {
// Requête vers votre base de données / API interne
const products = await db.products.search({ category, max_price, in_stock });
return {
content: [
{
type: "text",
text: JSON.stringify(products, null, 2),
},
],
};
}
);
// Expose une ressource statique : les conditions de livraison
server.resource(
"shipping-policy",
"shipping://policy",
async (uri) => ({
contents: [
{
uri: uri.href,
mimeType: "text/plain",
text: "Livraison gratuite dès 50€. Délai : 2-5 jours ouvrés en France métropolitaine.",
},
],
})
);
const transport = new StdioServerTransport();
await server.connect(transport);Ce serveur permet à n'importe quel client MCP (un agent Claude, une intégration custom, un orchestrateur) de rechercher des produits et de consulter la politique de livraison sans jamais parser du HTML.
Les limites à connaître
MCP ne gère pas l'authentification de manière native dans sa version actuelle — c'est volontairement laissé à la couche transport. Pour un catalogue public, ce n'est pas un problème. Pour des données utilisateur (historique de commandes, panier), vous devrez implémenter OAuth 2.0 ou un mécanisme équivalent au-dessus du transport HTTP SSE.
Par ailleurs, MCP est conçu pour l'interaction LLM → service. Il ne couvre pas la communication entre agents — c'est là qu'A2A entre en jeu.
A2A (Agent-to-Agent Protocol) : la communication inter-agents
Le problème de l'orchestration
Imaginez un scénario réaliste : un utilisateur demande à son agent personnel "Organise mon déménagement Paris → Lyon le 15 juin". Cet agent doit coordonner un agent de réservation de camion, un agent de changement d'adresse postale, un agent d'assurance, et potentiellement un agent de comparaison de fournisseurs d'énergie.
Sans protocole standard, chaque paire d'agents doit implémenter sa propre logique d'intégration. Avec N agents, ça fait N×(N-1)/2 intégrations point-à-point — un problème combinatoire classique que l'industrie a déjà rencontré avec les APIs REST avant l'émergence de GraphQL et des API gateways.
Ce qu'A2A standardise
Le protocole A2A, poussé par Google en collaboration avec plus de 50 partenaires technologiques, définit trois mécanismes fondamentaux :
- Agent Cards : des fichiers JSON hébergés à
/.well-known/agent.jsonqui décrivent les capacités d'un agent (ce qu'il sait faire, quels formats il accepte, ses endpoints). - Task management : un cycle de vie standardisé pour les tâches (submitted → working → completed/failed) avec support du streaming et des notifications push.
- Message exchange : un format unifié pour les messages entre agents, supportant texte, fichiers, données structurées et formulaires interactifs.
Voici la structure d'une Agent Card typique :
{
"name": "DeliveryScheduler",
"description": "Agent de planification de livraison pour e-commerce",
"url": "https://logistics.example-store.fr/a2a",
"version": "2.1.0",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{
"id": "schedule-delivery",
"name": "Planifier une livraison",
"description": "Planifie et optimise la livraison d'une commande en fonction de l'adresse, du créneau souhaité et des contraintes logistiques",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
},
{
"id": "track-shipment",
"name": "Suivre un colis",
"description": "Retourne le statut en temps réel d'un envoi",
"inputModes": ["text/plain"],
"outputModes": ["application/json", "text/plain"]
}
],
"authentication": {
"schemes": ["oauth2"],
"credentials": "https://logistics.example-store.fr/oauth/authorize"
}
}L'analogie avec robots.txt et les sitemaps est frappante — et intentionnelle. Là où robots.txt dit aux crawlers ce qu'ils ne doivent pas faire, l'Agent Card dit aux agents ce que le service sait faire.
Impact sur l'architecture technique
Pour un site e-commerce de 15 000 pages, implémenter A2A signifie concrètement :
- Héberger une Agent Card à
/.well-known/agent.json(trivial) - Exposer un endpoint A2A capable de recevoir des tâches, les traiter, et renvoyer des résultats structurés (non trivial — c'est en réalité construire une API orientée tâches)
- Gérer la montée en charge des requêtes agents en parallèle des requêtes humaines et crawlers
Ce dernier point est critique. Si votre configuration robots.txt limite déjà le crawl rate de Googlebot pour protéger vos serveurs, l'ajout d'agents A2A multiplie la surface d'appel.
NLWeb : le Schema.org du web agentique
L'initiative Microsoft
NLWeb, porté par Microsoft et publié en avril 2025, prend le problème par un angle radicalement différent de MCP et A2A. Au lieu de demander aux sites d'implémenter des serveurs de protocoles, NLWeb propose de rendre le contenu web existant directement interrogeable en langage naturel.
Le principe : vous ajoutez un endpoint NLWeb à votre site qui accepte des requêtes en langage naturel et retourne des réponses structurées en Schema.org. L'idée est que si votre site utilise déjà des données structurées JSON-LD, NLWeb peut servir de couche d'interrogation par-dessus.
Pourquoi c'est pertinent pour le SEO technique
NLWeb crée un pont direct entre le travail de balisage structuré que vous faites déjà pour Google (Product schema, FAQ schema, Article schema) et la consommation par des agents IA.
Concrètement, si vous avez correctement implémenté le schema Product pour votre e-commerce, un agent NLWeb peut transformer une requête comme "Quels sont vos sacs à dos de randonnée imperméables entre 80 et 150€ ?" en une réponse structurée sans que l'agent ait à parser votre HTML, interpréter votre JavaScript, ou reverse-engineer votre navigation à facettes.
Architecture type
NLWeb s'appuie sur un pipeline en trois étapes :
- Ingestion : votre contenu (pages HTML avec balisage Schema.org, flux produits) est indexé dans une base vectorielle (FAISS, Qdrant, Azure AI Search).
- Requête NL : l'agent envoie une requête en langage naturel à votre endpoint NLWeb.
- Réponse Schema.org : le système effectue une recherche sémantique, puis utilise un LLM pour formater la réponse en Schema.org.
# Exemple simplifié d'un endpoint NLWeb avec FastAPI
from fastapi import FastAPI
from pydantic import BaseModel
import json
app = FastAPI()
class NLWebQuery(BaseModel):
query: str
max_results: int = 5
schema_type: str = "Product" # Type Schema.org attendu en réponse
class NLWebResponse(BaseModel):
results: list
schema_context: str = "https://schema.org"
@app.post("/nlweb/ask")
async def nlweb_ask(req: NLWebQuery):
# 1. Recherche sémantique dans l'index vectoriel
candidates = await vector_store.similarity_search(
query=req.query,
top_k=req.max_results * 3, # Sur-échantillonner pour le re-ranking
filter={"@type": req.schema_type}
)
# 2. Re-ranking avec un LLM pour pertinence
ranked = await llm.rerank(
query=req.query,
documents=candidates,
top_k=req.max_results
)
# 3. Formatage en Schema.org
results = []
for doc in ranked:
results.append({
"@context": "https://schema.org",
"@type": "Product",
"name": doc.metadata["name"],
"description": doc.metadata["description"],
"offers": {
"@type": "Offer",
"price": doc.metadata["price"],
"priceCurrency": "EUR",
"availability": doc.metadata["availability"],
"url": doc.metadata["canonical_url"]
}
})
return NLWebResponse(results=results)Le trade-off est clair : NLWeb est plus facile à adopter si vous avez déjà un balisage Schema.org solide, mais il nécessite une infrastructure de recherche vectorielle et un accès LLM — ce qui représente un coût d'exploitation non négligeable.
AGENTS.md : le robots.txt pour les agents IA
Le chaînon manquant
Les trois protocoles précédents définissent comment les agents interagissent avec vos services. AGENTS.md définit ce qu'ils ont le droit de faire — et c'est peut-être le standard le plus immédiatement actionable pour les équipes SEO.
AGENTS.md est un fichier texte placé à la racine de votre site (comme robots.txt) qui déclare des permissions et des contraintes spécifiquement pour les agents IA. Là où robots.txt gère les crawlers HTTP, AGENTS.md gère les agents qui veulent agir sur ou avec votre contenu.
Structure et syntaxe
Le format est délibérément simple — markdown structuré avec des sections conventionnelles :
# AGENTS.md
## Identity
Name: ExempleStore
Description: E-commerce de matériel outdoor, 14 500 produits actifs
Contact: [email protected]
## Permissions
- READ: /api/products/*, /api/categories/*
- SEARCH: /nlweb/ask
- ACTION: /api/cart/add (requires authentication)
- DENY: /api/admin/*, /api/users/*
## Rate Limits
- Default: 60 requests/minute per agent
- Authenticated: 300 requests/minute per agent
- Burst: 10 requests/second max
## Data Usage
- Caching: allowed for 3600 seconds
- Training: not permitted
- Attribution: required (link to source URL)
## Preferred Protocols
- MCP: https://exemple-store.fr/mcp
- A2A: https://exemple-store.fr/.well-known/agent.json
- NLWeb: https://exemple-store.fr/nlweb/ask
## Human Escalation
- For orders > 500€, redirect to human support
- Contact: [email protected]Plusieurs points méritent attention :
La directive "Training: not permitted" est la plus débattue. Elle exprime l'intention du site de ne pas voir son contenu utilisé pour l'entraînement de modèles IA. Contrairement à robots.txt dont le respect est quasi universel par les moteurs majeurs, AGENTS.md n'a aujourd'hui aucune force contraignante. Son respect dépend entièrement de la bonne volonté des développeurs d'agents.
Les rate limits sont déclaratifs, pas impératifs. Vous devez toujours implémenter un vrai rate limiting côté serveur (via Nginx, Cloudflare, votre API gateway). AGENTS.md informe les agents bien intentionnés de vos limites pour qu'ils s'auto-régulent — exactement comme Crawl-delay dans robots.txt, que Googlebot ignore d'ailleurs.
La section "Preferred Protocols" crée un point d'entrée centralisé. Un agent qui découvre votre AGENTS.md sait immédiatement quels protocoles vous supportez et où trouver les endpoints correspondants.
Scénario concret : migration d'un e-commerce vers le web agentique
Le contexte
Prenons OutdoorPro, un e-commerce français de matériel outdoor : 14 500 pages produit, 850 pages catégorie, 200 pages de contenu éditorial. Stack technique : Next.js 14 en SSR, PostgreSQL, hébergé sur AWS. Trafic organique : 180 000 sessions/mois. Le site a déjà un balisage Schema.org Product sur toutes les fiches produit et utilise un sitemap XML bien structuré.
L'équipe constate dans ses logs serveur une augmentation de 340% des requêtes provenant de user-agents identifiés comme des agents IA (ClaudeBot, GPTBot, PerplexityBot, etc.) sur les 6 derniers mois. Le crawl budget est sous pression, et certaines pages catégories critiques sont crawlées moins fréquemment par Googlebot — un symptôme d'index bloat combiné à une surcharge de crawl.
Plan d'implémentation en 4 phases
Phase 1 (semaine 1-2) : AGENTS.md et mise à jour robots.txt
Déployer un AGENTS.md qui définit clairement les permissions et les rate limits. En parallèle, mettre à jour robots.txt pour gérer les bots IA spécifiques :
# Extrait de la config Nginx — rate limiting par catégorie de bot
map $http_user_agent $agent_category {
default "human";
"~*googlebot" "search_crawler";
"~*bingbot" "search_crawler";
"~*claudebot" "ai_agent";
"~*gptbot" "ai_agent";
"~*perplexitybot" "ai_agent";
}
limit_req_zone $agent_category zone=ai_agents:10m rate=30r/m;
limit_req_zone $agent_category zone=search_crawlers:10m rate=120r/m;
server {
location /api/ {
limit_req zone=ai_agents burst=10 nodelay;
proxy_pass http://backend;
}
location / {
limit_req zone=search_crawlers burst=20;
proxy_pass http://frontend;
}
}Phase 2 (semaine 3-4) : Endpoint NLWeb
Le balisage Schema.org Product existe déjà. L'équipe indexe les 14 500 fiches produit dans Qdrant (base vectorielle open source) et expose un endpoint NLWeb. Coût d'infrastructure estimé : une instance Qdrant à ~80€/mois + coût LLM pour le re-ranking (~200€/mois pour le volume anticipé).
Phase 3 (semaine 5-8) : Serveur MCP
Implémentation d'un serveur MCP exposant trois outils : search_products, check_availability, get_shipping_estimate. Ce serveur est accessible via HTTP SSE (Server-Sent Events) et nécessite une API key pour les opérations d'écriture (ajout au panier).
Phase 4 (semaine 9-12) : Agent Card A2A
Publication de l'Agent Card à /.well-known/agent.json décrivant les capacités du service. Cette phase est la moins urgente car l'écosystème A2A est encore naissant — peu d'agents consommateurs utilisent le protocole en production à la date de publication de cet article.
Résultats attendus et métriques
Après 3 mois de déploiement, les métriques à surveiller :
- Crawl budget Googlebot : le rate limiting des bots IA devrait libérer de la bande passante pour le crawl organique. Vérifiable dans Google Search Console > Paramètres > Statistiques d'exploration.
- Requêtes agents : volume, taux de succès, latence. Un agent qui reçoit des réponses structurées via MCP/NLWeb ne retente pas — contrairement à un agent qui scrape du HTML et échoue sur du JavaScript non rendu.
- Trafic de référence : les agents qui citent vos produits comme source génèrent potentiellement du trafic qualifié via les liens d'attribution.
Ce qui change pour le SEO technique dès maintenant
Ne vous y trompez pas : ces quatre protocoles sont à des stades de maturité très différents. MCP est le plus avancé en adoption réelle (Anthropic, OpenAI et Google l'ont tous intégré ou annoncé un support). NLWeb et A2A sont fonctionnels mais peu déployés hors des early adopters. AGENTS.md est encore au stade de proposition communautaire.
Pourtant, trois actions sont pertinentes dès aujourd'hui :
Auditer vos logs serveur pour quantifier le trafic agent. Si vous ne distinguez pas les requêtes GPTBot/ClaudeBot/PerplexityBot de votre trafic crawler classique, vous pilotez à l'aveugle. Screaming Frog peut analyser vos log files pour isoler ces user-agents. Un outil de monitoring comme Seogard permet de détecter automatiquement les variations anormales de crawl qui pourraient être causées par l'afflux d'agents IA.
Consolider votre balisage Schema.org. C'est le dénominateur commun entre le SEO classique et le web agentique. Un balisage Product, FAQ, Article ou BreadcrumbList propre aujourd'hui sera directement exploitable par NLWeb demain. L'investissement est le même, le ROI est doublé.
Rédiger un AGENTS.md dès maintenant. Même si aucun agent ne le respecte encore systématiquement, vous posez un cadre. Quand les standards se stabiliseront, vous serez déjà en place. Le coût est littéralement un fichier texte à la racine de votre site.
Le web agentique ne remplace pas le SEO — il le prolonge. Vos données structurées, votre architecture technique, votre gestion des redirections et votre performance serveur restent les fondations. Mais les consommateurs de ces fondations ne sont plus uniquement des crawlers et des navigateurs. Ce sont des agents autonomes, et ils ont besoin de protocoles pour dialoguer avec votre infrastructure. MCP, A2A, NLWeb et AGENTS.md sont les premiers candidats sérieux pour ce rôle — suivez leur évolution dans la documentation officielle MCP, les specs A2A de Google et le repo NLWeb de Microsoft.