Agentic AI Optimization (AAIO) : préparer votre site au web agentique

Un agent IA vient de parcourir votre catalogue de 12 000 produits en 4 secondes, a comparé vos prix avec trois concurrents, et a passé commande — sans qu'aucun humain n'ait vu une seule de vos pages. Ce scénario n'est plus théorique. Avec la montée des agentic browsers (le projet Mariner de Google, l'Operator d'OpenAI, le Computer Use de Claude) et des protocoles comme le Model Context Protocol (MCP), la question n'est plus si les agents vont interagir avec votre site, mais comment ils le font déjà — et ce que vous ratez si votre architecture n'est pas prête.

Du SEO au CRO à l'AAIO : une troisième couche d'optimisation

Le SEO optimise la découvrabilité par les crawlers de moteurs de recherche. Le CRO optimise la conversion pour des humains qui naviguent avec un navigateur. L'Agentic AI Optimization (AAIO) optimise l'interactabilité pour des agents autonomes qui exécutent des tâches complexes — comparaison, sélection, transaction — sans interface visuelle.

La différence fondamentale : un crawler Googlebot lit votre page pour l'indexer. Un agent IA lit votre page pour agir. Il doit comprendre la structure de vos données, interpréter vos conditions commerciales, interagir avec vos APIs ou formulaires, et valider une transaction. Le niveau d'exigence en termes de données structurées, d'accessibilité programmatique et de cohérence sémantique est radicalement supérieur.

Slobodan Manic, dans son article sur Search Engine Journal, pose le cadre conceptuel. Ici, nous allons creuser la couche technique : qu'est-ce que cela implique concrètement sur votre stack, vos schemas, votre architecture serveur, et comment vous pouvez commencer à instrumenter votre site dès maintenant.

Pour comprendre pourquoi les tactiques SEO superficielles ne suffisent plus face à cette évolution, l'article Why Surface-Level SEO Tactics Won't Build Lasting AI Search Visibility pose des bases complémentaires.

Les agents IA ne sont pas des crawlers : anatomie d'une interaction agentique

Ce qu'un agent fait réellement sur votre site

Un crawler traditionnel (Googlebot, Bingbot) suit un schéma prévisible : fetch HTML → parse → extract links → follow → index. Un agent IA suit un schéma orienté tâche :

Réception d'un intent utilisateur : "Trouve-moi un canapé 3 places en velours côtelé, livrable avant le 15 avril, budget max 1 200 €"
Découverte des sources : l'agent identifie 5-8 sites e-commerce pertinents
Extraction structurée : il parse chaque fiche produit pour en extraire prix, disponibilité, délai de livraison, caractéristiques techniques
Comparaison et scoring : il applique les critères de l'utilisateur
Action : ajout au panier, remplissage de formulaire, déclenchement du paiement via une API

Chaque étape peut échouer si votre site n'expose pas les bonnes données de la bonne manière. Et contrairement à un humain, l'agent ne va pas "chercher" l'information dans un menu déroulant ou interpréter un visuel — il abandonne et passe au concurrent.

Le problème du JavaScript-rendered content

Si votre catalogue produit repose sur un SPA React qui charge les données via des appels API côté client, un agent IA se retrouve face à une coquille vide. C'est le même problème que pour le SEO des single-page applications, mais amplifié : là où Googlebot dispose d'un moteur de rendering (WRS basé sur Chromium) et d'un budget de rendering, la plupart des agents IA travaillent d'abord sur le HTML brut ou via des protocoles structurés.

Voici ce que voit un agent sur un SPA mal configuré :

<!-- Ce que l'agent reçoit en fetch initial -->
<html>
<head>
  <title>MonShop - Canapés</title>
</head>
<body>
  <div id="root"></div>
  <script src="/static/js/bundle.a3f2e.js"></script>
</body>
</html>
<!-- Aucune donnée produit. Aucun schema. Rien d'actionable. -->

Versus ce qu'il devrait recevoir :

<!-- HTML pré-rendu côté serveur (SSR/SSG) -->
<html>
<head>
  <title>Canapé Velours Stockholm 3 places - MonShop</title>
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "Canapé Velours Stockholm 3 places",
    "description": "Canapé 3 places en velours côtelé, structure bouleau massif",
    "sku": "STCK-VLR-3P-BLU",
    "brand": { "@type": "Brand", "name": "Stockholm Living" },
    "offers": {
      "@type": "Offer",
      "price": "1089.00",
      "priceCurrency": "EUR",
      "availability": "https://schema.org/InStock",
      "deliveryLeadTime": {
        "@type": "QuantitativeValue",
        "minValue": 3,
        "maxValue": 5,
        "unitCode": "DAY"
      },
      "shippingDetails": {
        "@type": "OfferShippingDetails",
        "shippingRate": {
          "@type": "MonetaryAmount",
          "value": "0",
          "currency": "EUR"
        },
        "deliveryTime": {
          "@type": "ShippingDeliveryTime",
          "handlingTime": {
            "@type": "QuantitativeValue",
            "minValue": 1,
            "maxValue": 2,
            "unitCode": "DAY"
          },
          "transitTime": {
            "@type": "QuantitativeValue",
            "minValue": 2,
            "maxValue": 3,
            "unitCode": "DAY"
          }
        }
      }
    },
    "additionalProperty": [
      {
        "@type": "PropertyValue",
        "name": "Matière",
        "value": "Velours côtelé"
      },
      {
        "@type": "PropertyValue",
        "name": "Nombre de places",
        "value": "3"
      },
      {
        "@type": "PropertyValue",
        "name": "Coloris",
        "value": "Bleu canard"
      }
    ]
  }
  </script>
</head>
<body>
  <!-- Contenu HTML complet pré-rendu -->
</body>
</html>

La différence est existentielle. Dans le second cas, l'agent dispose de tout ce qu'il faut pour répondre à la requête utilisateur sans exécuter une seule ligne de JavaScript. Les pièges classiques du JavaScript SEO deviennent des murs infranchissables pour les agents.

Schema.org comme API implicite : aller au-delà du markup SEO classique

Le schema n'est plus un bonus SERP, c'est une interface machine

Jusqu'ici, la plupart des implémentations schema.org visaient un objectif : déclencher des rich snippets dans les SERP. Le markup Product, FAQ, HowTo était pensé pour Google, avec la récompense d'un affichage enrichi.

Dans un contexte agentique, le schema devient l'interface de lecture principale de votre site pour les machines. Un agent IA qui cherche un produit va parser le JSON-LD avant même de lire le contenu HTML visible. La qualité, l'exhaustivité et la précision de votre schema deviennent directement corrélées à votre capacité à être sélectionné par un agent.

Les champs que personne ne remplit (et qui deviennent critiques)

La documentation schema.org/Product liste des dizaines de propriétés. En pratique, 90% des sites e-commerce se limitent à name, price, availability, image. Pour l'AAIO, les propriétés suivantes deviennent déterminantes :

deliveryLeadTime : un agent qui doit respecter une contrainte de date ne peut pas deviner votre délai de livraison s'il n'est pas structuré
returnPolicy (via hasMerchantReturnPolicy) : les agents vont scorer les vendeurs sur la flexibilité de retour
additionalProperty : c'est ici que vous structurez les attributs produit non standard (matière, dimensions, compatibilité)
shippingDetails : coût et délai d'expédition structurés, pas enfouis dans une page "Conditions de livraison"
aggregateRating et review : les agents utilisent les avis comme signal de confiance, exactement comme un humain

Travailler sur la profondeur des schemas rejoint les bonnes pratiques décrites dans notre guide sur le schema Article pour les blogs et médias, mais appliquées au commerce.

Les BreadcrumbList comme signal de navigation agentique

Un agent qui explore votre catalogue utilise le BreadcrumbList pour comprendre la hiérarchie de votre taxonomie produit. Si votre breadcrumb structuré indique Maison > Salon > Canapés > Canapés 3 places, l'agent peut naviguer dans votre arborescence de manière programmatique, sans parser votre menu de navigation en HTML.

Le Model Context Protocol (MCP) et les APIs agentiques

MCP : le protocole qui change la donne

Anthropic a publié le Model Context Protocol (MCP) comme standard ouvert pour connecter les LLMs à des sources de données externes. En pratique, MCP permet à un agent IA de :

Découvrir les capacités d'un service (quels "tools" sont exposés)
Appeler des fonctions structurées (recherche produit, vérification de stock, création de panier)
Recevoir des réponses typées et fiables

Pour un site e-commerce, exposer un serveur MCP revient à créer une API dédiée aux agents. Voici un exemple minimaliste en TypeScript d'un serveur MCP pour un catalogue produit :

// mcp-server.ts — Serveur MCP minimaliste pour catalogue produit
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: "monshop-catalog",
  version: "1.0.0",
});

// Tool : recherche produit avec filtres structurés
server.tool(
  "search_products",
  "Recherche des produits dans le catalogue MonShop",
  {
    query: z.string().describe("Termes de recherche"),
    category: z.string().optional().describe("Catégorie produit"),
    maxPrice: z.number().optional().describe("Prix maximum en EUR"),
    inStockOnly: z.boolean().default(true).describe("Filtrer les produits en stock uniquement"),
    deliveryBefore: z.string().optional().describe("Date limite de livraison (ISO 8601)"),
  },
  async ({ query, category, maxPrice, inStockOnly, deliveryBefore }) => {
    // Appel à votre API interne / base de données
    const results = await catalogService.search({
      query,
      category,
      maxPrice,
      inStockOnly,
      deliveryBefore: deliveryBefore ? new Date(deliveryBefore) : undefined,
    });

    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(
            results.map((p) => ({
              sku: p.sku,
              name: p.name,
              price: p.price,
              currency: "EUR",
              availability: p.stock > 0 ? "InStock" : "OutOfStock",
              estimatedDelivery: p.estimatedDeliveryDate,
              productUrl: `https://monshop.fr/produits/${p.slug}`,
              returnPolicy: "30 jours, retour gratuit",
            })),
            null,
            2
          ),
        },
      ],
    };
  }
);

// Tool : vérification de stock en temps réel
server.tool(
  "check_stock",
  "Vérifie la disponibilité d'un produit par SKU",
  {
    sku: z.string().describe("Référence produit (SKU)"),
  },
  async ({ sku }) => {
    const stock = await inventoryService.getStock(sku);
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({
            sku,
            available: stock.quantity > 0,
            quantity: stock.quantity,
            nextRestockDate: stock.nextRestock,
            warehouseLocation: stock.warehouse,
          }),
        },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Ce serveur expose deux "tools" que n'importe quel agent compatible MCP peut découvrir et utiliser. L'agent n'a plus besoin de scraper votre HTML, de deviner la structure de votre formulaire de recherche, ou d'interpréter vos filtres à facettes (un sujet déjà complexe pour les crawlers humains, comme le décrit notre article sur la navigation à facettes).

Faut-il tout miser sur MCP dès maintenant ?

Non. MCP est encore jeune, et la majorité des agents IA en production fonctionnent aujourd'hui par scraping intelligent du HTML + parsing de schema.org. Mais la tendance est claire : les agents vont progressivement migrer vers des protocoles structurés. La stratégie raisonnable :

Court terme (maintenant) : schema.org exhaustif, SSR irréprochable, HTML sémantique
Moyen terme (6-12 mois) : exposer une API REST ou GraphQL documentée, expérimenter avec un serveur MCP
Long terme : protocoles de commerce agentique standardisés (les spécifications émergent)

Scénario concret : migration AAIO d'un e-commerce de 15 000 fiches produit

Le contexte

FashionStore.fr — e-commerce mode, 15 200 fiches produit, stack Next.js 14 avec App Router, base Shopify headless. Trafic organique : 280K sessions/mois. Le site a un bon SEO technique : SSR fonctionnel, sitemaps à jour, Core Web Vitals dans le vert.

Problème identifié : les analyses de logs montrent une augmentation de 340% des requêtes provenant d'user-agents identifiés comme des agents IA (GPTBot, ClaudeBot, PerplexityBot, et des user-agents inconnus avec des patterns de navigation non-humains) sur les 6 derniers mois. Mais le taux de conversion attribué à ces visites est de 0% — les agents consultent, ne convertissent pas.

L'audit

L'équipe lance un audit en trois volets :

1. Complétude du schema Product : Screaming Frog, configuré en extraction custom JSON-LD, révèle que sur 15 200 fiches :

14 800 ont un schema Product (97%) ✅
2 100 ont deliveryLeadTime (14%) ❌
340 ont hasMerchantReturnPolicy (2%) ❌
0 ont shippingDetails structuré ❌
Les additionalProperty couvrent en moyenne 2 attributs sur 8 disponibles

2. Accessibilité des données sans JS : Un curl sur une fiche produit retourne le HTML complet (SSR fonctionne). Mais les variantes (taille, coloris) et la disponibilité en temps réel sont chargées via un appel API client-side après hydratation React. Un agent qui lit le HTML initial voit "Taille : Sélectionner" au lieu de la liste des tailles disponibles.

3. Gestion des bots agentiques : Le robots.txt autorise tous les bots. Aucun agents.json (proposition de standard émergent). Pas d'API publique documentée. Le rate limiting Cloudflare bloque agressivement les requêtes non-browser (un problème courant quand on configure Cloudflare pour le SEO sans penser aux agents IA).

Le plan d'action

Phase 1 — Schema enrichment (2 semaines) : Script batch pour enrichir les 15 200 schemas Product. Les données existent dans Shopify, elles ne sont simplement pas projetées dans le JSON-LD.

Phase 2 — SSR des variantes (1 semaine) : Modification du composant ProductVariants pour inclure toutes les variantes disponibles dans le HTML initial, avec un schema hasVariant pour chaque combinaison taille/coloris :

<!-- Variantes exposées dans le JSON-LD initial (pas après hydratation) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Robe Lin Été Provençale",
  "productGroupID": "ROBE-LIN-ETE",
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "ROBE-LIN-ETE-XS-BLA",
      "size": "XS",
      "color": "Blanc",
      "offers": {
        "@type": "Offer",
        "price": "89.00",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock",
        "inventoryLevel": {
          "@type": "QuantitativeValue",
          "value": 23
        }
      }
    },
    {
      "@type": "Product",
      "sku": "ROBE-LIN-ETE-S-BLA",
      "size": "S",
      "color": "Blanc",
      "offers": {
        "@type": "Offer",
        "price": "89.00",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}
</script>

Phase 3 — Configuration Cloudflare (3 jours) : Création d'une règle WAF custom qui whiteliste les user-agents agentiques connus tout en maintenant le rate limiting à un niveau raisonnable (60 req/min au lieu de 10 req/min pour les bots inconnus).

Phase 4 — Prototype MCP (en parallèle, 4 semaines) : Exposition d'un serveur MCP connecté à l'API Shopify, avec trois tools : search_products, get_product_details, check_availability.

Les résultats attendus

L'équipe mesure via l'analyse de logs l'évolution du comportement des agents sur le site. Les métriques cibles à 3 mois :

Temps moyen de session agent : de 0.3s à 2.5s (l'agent trouve les données, reste plus longtemps car il explore les variantes)
Pages crawlées par session agent : de 1.2 à 4.8
Première conversion via agent IA : objectif T+8 semaines

Le suivi de ces métriques de façon continue est exactement le type de monitoring que Seogard permet d'automatiser — détecter quand un schema Product perd ses propriétés critiques après un déploiement, ou quand le SSR casse sur un subset de pages.

Robots.txt, agents.json et la gouvernance du trafic agentique

Le robots.txt ne suffit plus

Le robots.txt a été conçu pour des crawlers qui indexent. Les agents IA qui exécutent des actions posent de nouvelles questions :

Voulez-vous qu'un agent puisse passer commande sur votre site ?
Quels agents autorisez-vous à accéder à vos prix en temps réel ?
Un agent concurrent peut-il scraper votre catalogue pour alimenter un comparateur ?

Google a des centaines de crawlers non documentés. Les agents IA vont multiplier cette complexité par dix. Le robots.txt binaire (allow/disallow) n'a pas la granularité nécessaire.

Le fichier agents.json (proposition émergente)

Plusieurs initiatives proposent un fichier de déclaration des capacités d'interaction agentique, à la racine du site. Le format n'est pas encore standardisé, mais le concept :

// /agents.json — Déclaration des capacités agentiques (format expérimental)
{
  "schema_version": "0.1",
  "identity": {
    "name": "MonShop",
    "url": "https://monshop.fr",
    "contact": "[email protected]"
  },
  "capabilities": {
    "product_search": {
      "enabled": true,
      "endpoint": "https://monshop.fr/api/v1/products/search",
      "authentication": "api_key",
      "rate_limit": "120/min",
      "documentation": "https://monshop.fr/developers/api-docs"
    },
    "checkout": {
      "enabled": false,
      "note": "Checkout requires human verification via 3D Secure"
    },
    "price_comparison": {
      "enabled": true,
      "freshness": "real-time",
      "conditions": "Attribution required — link back to product page"
    }
  },
  "mcp_server": {
    "enabled": true,
    "transport": "streamable-http",
    "url": "https://monshop.fr/mcp"
  },
  "preferred_formats": ["json-ld", "application/json"],
  "human_verification_required": ["checkout", "account_creation"]
}

Ce fichier est l'équivalent du robots.txt pour l'ère agentique : il déclare ce que les agents peuvent faire, comment y accéder, et où sont les limites. Même si le standard n'est pas finalisé, documenter vos capacités machine-readable est un investissement qui ne sera jamais perdu.

Entity authority : le signal de confiance pour les agents IA

Les agents IA ne se contentent pas de lire vos données — ils évaluent votre fiabilité. Exactement comme les LLMs qui génèrent des AI Overviews sélectionnent leurs sources en fonction de signaux d'autorité, les agents commerciaux vont scorer les vendeurs.

Les signaux qui comptent pour un agent :

Cohérence des données : le prix dans le schema correspond-il au prix affiché dans le HTML ? Le stock déclaré est-il synchronisé avec la réalité ?
Fraîcheur : vos données sont-elles mises à jour en temps réel ou datent-elles du dernier build statique il y a 6 heures ?
Réputation structurée : aggregateRating, avis tiers, mention dans des sources de confiance
Politique de retour et garantie : structurées dans le schema, pas enterrées dans un PDF de CGV

L'entity authority comme fondation de la visibilité dans la recherche IA devient un pilier de l'AAIO : si un agent ne fait pas confiance à vos données, il ne vous sélectionne pas.

Ce point rejoint directement le constat que seulement 15% des pages récupérées par ChatGPT apparaissent dans les réponses finales. La sélection est brutale, et elle le sera encore plus quand l'enjeu est une transaction financière.

Mesurer la visibilité agentique : les nouvelles métriques

Le SEO classique mesure des rankings, du trafic organique, des CTR. L'AAIO nécessite de nouvelles métriques :

Agent crawl volume : combien de requêtes viennent d'agents IA identifiés ? L'analyse de logs est votre meilleur allié ici.
Schema completeness score : quel pourcentage de vos propriétés schema recommandées sont effectivement remplies ? Screaming Frog + extraction custom peut le calculer.
Réponse API / temps de réponse MCP : si vous exposez un endpoint, quel est le P95 de latence ? Un agent qui attend 3 secondes passe au concurrent.
Agent conversion rate : combien de sessions initiées par un agent aboutissent à une transaction ? Cela nécessite d'identifier les agents dans vos analytics, ce qui est possible via les user-agents ou les patterns de navigation (pas de mouse events, pas de scroll, séquence de pages déterministe).
Citation rate dans les réponses IA : votre site est-il cité quand un utilisateur demande à un LLM une recommandation produit dans votre niche ? Les méthodes de tracking de la visibilité IA s'appliquent directement.

La prédiction du CEO de Cloudflare selon laquelle les bots pourraient dépasser le trafic humain d'ici 2027 prend tout son sens dans ce contexte. Si plus de la moitié de vos visiteurs sont des machines, optimiser uniquement pour les humains revient à ignorer la majorité de votre audience.

Ce qui ne change pas (et pourquoi le SEO technique reste la fondation)

L'AAIO n'est pas un remplacement du SEO technique — c'est une extension. Un site qui a un SSR cassé, des erreurs 404 mal gérées, des codes HTTP incohérents, ou un caching serveur mal configuré ne sera pas meilleur pour les agents que pour les crawlers classiques.

Les fondamentaux restent non négociables :

SSR ou pre-rendering pour tout contenu critique (React, Vue/Nuxt, Web Components)
HTTP/2 ou HTTP/3 pour la performance de livraison
HTTPS irréprochable (les agents vont refuser d'interagir avec des sites non sécurisés)
Architecture d'URL propre et priorisation technique quand les ressources sont limitées

La différence : ces fondamentaux sont désormais le minimum. L'AAIO ajoute une couche de lisibilité machine qui va au-delà de l'indexation — vers l'interaction et la transaction.

L'AAIO est la prochaine frontière du SEO technique. Les sites qui exposent des données structurées exhaustives, qui maintiennent un SSR irréprochable, et qui commencent à expérimenter avec des interfaces programmatiques (API, MCP) seront ceux que les agents sélectionnent. Le moment pour instrumenter votre site, c'est maintenant — et un outil comme Seogard vous permet de vérifier en continu que votre couche machine-readable ne se dégrade pas silencieusement après chaque déploiement.