Comment vérifier si votre site est compatible avec les agents IA ?

Les internautes ne sont plus les seuls à visiter les sites web. Les moteurs de recherche traditionnels, les robots d’indexation, les assistants conversationnels et, désormais, les agents IA accèdent aux contenus, analysent des pages, interrogent des API et réalisent progressivement des actions pour le compte des utilisateurs.

Un agent IA peut rechercher une information, comparer plusieurs offres, consulter une documentation, vérifier la disponibilité d’un service, préparer une réservation, remplir un formulaire ou appeler une API. Dans un environnement e-commerce, il peut également identifier un produit, analyser ses caractéristiques et initier une transaction.

La question n’est donc plus seulement de savoir si votre site est bien référencé sur Google. Vous devez également déterminer s’il est compréhensible, accessible et exploitable par les agents IA.

Pour effectuer cette vérification, Cloudflare a lancé l’outil Is It Agent Ready?. Celui-ci analyse un site selon plusieurs normes émergentes liées à la découverte des contenus, au contrôle des robots, au Markdown, à l’authentification, aux API, au protocole MCP et au commerce agentique.

L’objectif de ce guide est de vous montrer précisément comment vérifier si votre site est compatible avec les agents IA, comment interpréter les résultats obtenus et quelles améliorations mettre en œuvre en priorité.

Qu’est-ce qu’un site compatible avec les agents IA ?

Un site compatible avec les agents IA, parfois qualifié de site agent-ready, est un site qu’un système autonome peut facilement découvrir, comprendre et utiliser.

Cette compatibilité repose sur plusieurs niveaux.

Un agent doit premièrement pouvoir trouver les pages importantes. Il doit ensuite être capable d’extraire le contenu utile sans gaspiller une grande partie de sa fenêtre de contexte dans des menus, des scripts, des publicités ou du code HTML sans valeur sémantique.

Lorsqu’un site propose des fonctionnalités interactives, l’agent doit également comprendre comment appeler les API, s’authentifier et effectuer une opération de manière sécurisée. Enfin, dans le cas d’une boutique en ligne, il doit pouvoir découvrir les produits et comprendre les protocoles permettant de réaliser une transaction.

La compatibilité peut être résumée par ce parcours :

Découverte du site
        ↓
Lecture des règles robots.txt
        ↓
Identification du sitemap et des ressources importantes
        ↓
Récupération du contenu HTML ou Markdown
        ↓
Compréhension des données structurées
        ↓
Découverte des API, outils ou serveurs MCP
        ↓
Authentification sécurisée
        ↓
Réalisation d’une action ou d’une transaction

Un site peut être parfaitement utilisable par un humain tout en étant difficile à exploiter par un agent. C’est notamment le cas lorsque son contenu dépend entièrement de JavaScript, lorsque ses informations importantes sont masquées derrière des interfaces complexes ou lorsque ses protections antibots bloquent indistinctement tous les systèmes automatisés.

Quelle est la différence entre un robot d’indexation et un agent IA ?

Un robot d’indexation traditionnel explore principalement des URL afin de les ajouter à un index. Googlebot, par exemple, découvre les pages, analyse leur contenu et aide Google à déterminer leur position dans les résultats de recherche.

Un agent IA peut aller plus loin.

Il ne se contente pas nécessairement de lire une page. Il peut poursuivre un objectif, prendre des décisions intermédiaires, utiliser plusieurs outils et effectuer des actions successives.

Prenons l’exemple d’un utilisateur qui demande à son assistant :

Trouve-moi un développeur web capable de créer un site e-commerce, compare les prestations et prépare une demande de devis.

L’agent peut rechercher des prestataires, visiter leurs pages de services, examiner leurs compétences, identifier un formulaire de contact et préparer les informations à transmettre.

Pour réussir ce processus, le site doit être plus que simplement indexable. Son contenu, ses fonctionnalités et ses règles d’accès doivent être interprétables par une machine.

Cette évolution ne remplace pas le SEO. Elle ajoute une nouvelle couche technique située à l’intersection du SEO, du GEO, des données structurées, des API et de la sécurité web.

Pourquoi vérifier dès maintenant la compatibilité de votre site avec les agents IA ?

Les standards du web agentique sont encore jeunes. Leur adoption reste relativement faible, ce qui crée une occasion de prendre de l’avance.

Dans son étude de lancement, Cloudflare a analysé une sélection issue des 200 000 domaines les plus visités. L’entreprise indiquait alors que 78 % des sites analysés possédaient un fichier robots.txt, mais que celui-ci était généralement destiné aux moteurs de recherche traditionnels. Seulement 4 % déclaraient des préférences d’utilisation de l’IA avec les signaux de contenu, tandis que la négociation de contenu Markdown était détectée sur 3,9 % des sites. Certaines normes plus avancées, comme les cartes de serveur MCP et les catalogues d’API, n’apparaissaient que sur une poignée de domaines.

Ces chiffres montrent que la majorité des entreprises ne disposent pas encore d’une véritable stratégie de préparation aux agents.

Adopter les bonnes pratiques aujourd’hui permet de faciliter l’accès aux contenus, de mieux contrôler les robots, de réduire les coûts de traitement pour les modèles et de préparer les futures interactions automatisées.

Cela ne signifie toutefois pas que chaque site doit immédiatement déployer un serveur MCP, un protocole de paiement agentique et plusieurs fichiers .well-known. Les optimisations doivent correspondre à la nature du projet.

Un blog, une boutique Shopify, un site vitrine et une application SaaS n’ont pas les mêmes besoins.

Is It Agent Ready : l’outil principal pour tester votre site

Le moyen le plus simple de commencer consiste à utiliser l’outil Is It Agent Ready?.

Développé par Cloudflare, cet outil fonctionne comme un audit technique consacré à la préparation aux agents IA. Vous saisissez l’adresse de votre site, puis le service envoie différentes requêtes afin de détecter les normes prises en charge.

L’approche rappelle celle de Google Lighthouse, mais les critères examinés ne concernent pas directement les Core Web Vitals ou l’accessibilité humaine. Ils portent sur la capacité des agents à découvrir, lire, authentifier et utiliser le site.

L’interface actuelle permet de sélectionner plusieurs profils :

• tous les contrôles ;

• site de contenu ;

• API ou application.

Elle permet également de personnaliser les vérifications.

Au moment de la rédaction de cet article, Is It Agent Ready regroupe ses contrôles dans cinq grandes catégories : la découvrabilité, l’accessibilité du contenu, le contrôle d’accès des bots, la découverte des protocoles et le commerce agentique. (Is Your Site Agent-Ready?)

Les principaux contrôles réalisés par Is It Agent Ready

Cloudflare recommande de commencer par les améliorations les plus simples : publier un fichier robots.txt valide, ajouter la directive du sitemap et exposer les métadonnées ou en-têtes de découverte utiles. (Is Your Site Agent-Ready?)

Comment utiliser Is It Agent Ready étape par étape ?

La procédure est simple, mais l’interprétation du rapport demande davantage de discernement.

1. Saisissez l’URL canonique du site

Utilisez de préférence l’adresse principale en HTTPS :

https://www.exemple.com

Évitez de commencer par une URL redirigée, une page de test, une adresse de préproduction ou un domaine qui ne correspond pas à la version canonique du site.

2. Sélectionnez le type de site

Pour un blog, un média ou un site vitrine, choisissez le profil destiné aux sites de contenu.

Pour une application SaaS, un outil en ligne ou une plateforme disposant d’une API, sélectionnez le profil API/Application.

Pour obtenir un diagnostic complet, exécutez ensuite tous les contrôles. Certaines normes ne seront pas pertinentes pour votre activité, mais vous pourrez au moins identifier les possibilités disponibles.

3. Lancez l’analyse

L’outil adresse différentes requêtes à votre domaine. Il cherche notamment les ressources situées à la racine, les fichiers .well-known, les en-têtes HTTP, les règles d’exploration et les mécanismes de négociation de contenu.

4. Consultez les tests réussis et échoués

Un contrôle réussi signifie que le mécanisme attendu a été détecté. Un échec peut indiquer qu’une ressource est absente, mal configurée, inaccessible ou renvoyée avec un mauvais type de contenu.

Il ne faut cependant pas appliquer automatiquement toutes les recommandations. Is It Agent Ready précise que les instructions correctives générées par IA peuvent contenir des erreurs et qu’elles doivent être validées avant leur mise en production. (Is Your Site Agent-Ready?)

5. Classez les corrections par importance

Commencez par les fondations :

1. accessibilité HTTP ;

2. robots.txt ;

3. sitemap XML ;

4. contenu rendu et lisible ;

5. métadonnées ;

6. données structurées ;

7. négociation Markdown ;

8. contrôle précis des robots ;

9. protocoles d’API et d’authentification ;

10. commerce agentique si nécessaire.

Premier contrôle : vérifier la découvrabilité du site

Un agent ne peut pas exploiter une ressource qu’il ne parvient pas à trouver.

La découvrabilité correspond à la capacité du site à indiquer clairement ses pages, ses fichiers, ses API et ses points d’entrée.

Vérifier le fichier robots.txt

Le fichier robots.txt doit être disponible à cette adresse :

https://www.exemple.com/robots.txt

Il doit répondre avec un code HTTP 200 et contenir des directives cohérentes.

Exemple minimal :

User-agent: *
Allow: /

Sitemap: https://www.exemple.com/sitemap.xml

Ce fichier indique que les robots respectueux du protocole peuvent explorer le site et précise l’adresse du sitemap.

Pour une boutique ou un CMS, il peut être nécessaire de bloquer certains espaces sans intérêt :

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /checkout/
Disallow: /compte/
Disallow: /recherche-interne/

Sitemap: https://www.exemple.com/sitemap.xml

Les règles ne doivent pas empêcher accidentellement les agents d’accéder aux feuilles de style, aux scripts nécessaires au rendu, aux images importantes ou aux pages que vous souhaitez rendre visibles.

Le fichier robots.txt n’est pas un mécanisme de sécurité. Il exprime des règles d’exploration dont le respect demeure volontaire. Cloudflare rappelle d’ailleurs que certains robots peuvent ignorer ces directives. (Cloudflare Docs)

Vérifier le sitemap XML

Le sitemap doit contenir les URL canoniques et indexables du site.

Testez manuellement les adresses suivantes :

https://www.exemple.com/sitemap.xml
https://www.exemple.com/sitemap_index.xml

Le fichier doit être accessible sans authentification, ne pas renvoyer d’erreur serveur et éviter d’inclure des pages en noindex, des redirections, des erreurs 404 ou des paramètres inutiles.

Pour un site important, utilisez plusieurs sitemaps spécialisés :

/sitemap-pages.xml
/sitemap-articles.xml
/sitemap-produits.xml
/sitemap-categories.xml

Cette organisation aide les moteurs et les agents à comprendre les différentes familles de contenus.

Ajouter des en-têtes Link lorsque cela est utile

Les en-têtes HTTP Link permettent d’indiquer certaines ressources avant même que l’agent analyse le code HTML.

Exemple :

HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"

Cloudflare explique que cette approche permet aux agents d’identifier des ressources importantes directement dans la réponse HTTP.

Cette optimisation est particulièrement pertinente pour les applications, les plateformes techniques et les sites disposant d’API publiques.

Deuxième contrôle : vérifier si les agents peuvent lire le contenu

Une page accessible ne garantit pas que son contenu soit correctement compris.

Les agents rencontrent souvent des difficultés sur les sites dont les informations principales sont injectées exclusivement avec JavaScript, présentées dans des éléments interactifs complexes ou noyées dans une grande quantité de code.

Tester le rendu sans JavaScript

Désactivez temporairement JavaScript dans votre navigateur ou utilisez une commande comme :

curl -L https://www.exemple.com/page/

Le résultat doit contenir le titre, les principaux paragraphes, les liens et les informations essentielles.

Lorsque la réponse initiale ne contient qu’un conteneur vide de ce type, la lecture peut devenir plus coûteuse :

<div id="app"></div>

Pour un site développé avec Next.js, Nuxt, Laravel, WordPress ou un autre framework moderne, privilégiez le rendu côté serveur, la génération statique ou une stratégie hybride pour les contenus publics.

Utiliser une structure HTML sémantique

Les agents comprennent mieux les documents clairement structurés.

Chaque page importante devrait contenir :

<main>
  <article>
    <header>
      <h1>Titre principal</h1>
    </header>

    <section>
      <h2>Première partie</h2>
      <p>Contenu...</p>
    </section>
  </article>
</main>

Les titres doivent suivre une hiérarchie logique. Une page ne doit pas utiliser des balises h2 ou h3 uniquement pour modifier la taille d’un texte.

Les tableaux doivent contenir de véritables balises <table>, <thead>, <tbody>, <th> et <td>. Les boutons doivent être identifiables comme des boutons et les liens comme des liens.

Vérifier les balises title et description

Les métadonnées doivent décrire précisément chaque page :

<title>Audit de compatibilité avec les agents IA</title>

<meta
  name="description"
  content="Analysez votre site et corrigez les obstacles qui empêchent les agents IA de lire et utiliser vos contenus."
>

Ces informations ne sont pas réservées à Google. Elles apportent également du contexte aux systèmes automatisés.

Markdown for Agents : rendre le contenu plus efficace pour l’IA

L’une des principales innovations mises en avant par Cloudflare est Markdown for Agents.

Lorsqu’un agent adresse une requête avec l’en-tête suivant :

Accept: text/markdown

un site compatible peut lui renvoyer une version Markdown de la page au lieu du document HTML complet.

Le Markdown est plus simple à analyser. Il supprime une grande partie du balisage, des menus, des scripts, des styles et des éléments décoratifs dont l’agent n’a pas besoin.

Selon Cloudflare, la négociation de contenu Markdown peut réduire la consommation de jetons jusqu’à 80 % dans certains cas. Cette réduction peut accélérer les réponses, diminuer les coûts et permettre à l’agent de lire une plus grande partie du contenu.

Comment tester manuellement Markdown for Agents ?

Exécutez cette commande :

curl -L https://www.exemple.com/page/ \
  -H "Accept: text/markdown" \
  -I

Recherchez notamment les en-têtes suivants :

content-type: text/markdown; charset=utf-8
vary: Accept
x-markdown-tokens: 725
x-original-tokens: 12345

Vous pouvez ensuite récupérer le contenu complet :

curl -L https://www.exemple.com/page/ \
  -H "Accept: text/markdown"

Lorsque la fonctionnalité est active, Cloudflare convertit le HTML à la volée et ajoute des informations permettant de comparer le nombre estimé de jetons du Markdown avec celui du HTML original. (Cloudflare Docs)

Comment activer Markdown for Agents dans Cloudflare ?

La documentation officielle de Markdown for Agents indique que la fonctionnalité peut être activée depuis le tableau de bord Cloudflare.

La procédure actuelle est la suivante :

1. connectez-vous au tableau de bord Cloudflare ;

2. sélectionnez votre compte et votre domaine ;

3. ouvrez la section AI Crawl Control ;

4. activez Markdown for Agents.

Selon la documentation actuelle, cette activation au niveau de la zone nécessite un forfait Cloudflare Pro ou Business. Cloudflare permet également de limiter la fonctionnalité à certains sous-domaines ou chemins grâce aux Configuration Rules. (Cloudflare Docs)

Vous pouvez, par exemple, activer le Markdown uniquement pour la documentation :

http.host eq "docs.exemple.com"

Ou uniquement pour le blog :

starts_with(http.request.uri.path, "/blog/")

Cette configuration ciblée est utile si certaines sections comprennent des interfaces dynamiques qui ne doivent pas être automatiquement converties.

Que contient la version Markdown générée ?

Cloudflare produit une structure composée de trois parties principales :

1. un frontmatter YAML créé à partir des métadonnées ;

2. le contenu principal converti en Markdown ;

3. les données JSON-LD conservées dans un bloc JSON.

Les menus, scripts, styles et éléments non éditoriaux sont retirés. Les données structurées JSON-LD restent disponibles pour aider l’agent à interpréter la nature de la page. (Cloudflare Docs)

Exemple :

---
title: Comment vérifier son site pour les agents IA ?
description: Méthode complète pour réaliser un audit agentique.
image: https://www.exemple.com/image.jpg
---

# Comment vérifier son site pour les agents IA ?

Contenu principal de la page...

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Comment vérifier son site pour les agents IA ?"
}

Cela montre que les métadonnées SEO et les données structurées restent importantes dans un environnement agentique.

## Faut-il ajouter un fichier llms.txt ?

Le fichier `llms.txt` est une proposition destinée à offrir aux modèles un index éditorial simplifié du site.

Il se place généralement à la racine :

```text
https://www.exemple.com/llms.txt

Exemple :

# Nom du site

> Description claire de l’entreprise et de ses activités.

## Services

- [Création de sites web](https://www.exemple.com/services/creation-site.md)
- [Référencement naturel](https://www.exemple.com/services/seo.md)

## Ressources

- [Guides](https://www.exemple.com/blog/)
- [Documentation](https://www.exemple.com/docs/)

## Contact

- [Demander un devis](https://www.exemple.com/contact/)

Le llms.txt ne doit pas être considéré comme un remplacement du sitemap XML, du maillage interne ou des données structurées. Il s’agit d’une couche de découverte supplémentaire.

Is It Agent Ready ne contrôle pas nécessairement ce fichier dans son audit standard. Cloudflare indique que l’analyse par défaut se concentre sur la négociation Markdown, mais qu’il est possible d’ajouter la vérification de llms.txt dans une analyse personnalisée. (The Cloudflare Blog)

Pour un site volumineux, évitez de placer des milliers de pages dans un fichier unique. Cloudflare a choisi de produire plusieurs fichiers llms.txt organisés par répertoire, puis de les relier depuis un index principal. Cette structure limite les documents trop volumineux et facilite l’accès au bon contexte.

Troisième contrôle : gérer l’accès des bots et agents IA

Rendre son site compatible avec les agents ne signifie pas autoriser tous les robots à tout faire.

Une bonne stratégie doit distinguer plusieurs usages :

• exploration pour la recherche ;

• utilisation comme source dans une réponse ;

• entraînement de modèles ;

• actions réalisées pour un utilisateur ;

• extraction commerciale massive ;

• robots malveillants ou non identifiés.

Cloudflare classe désormais les robots selon leur comportement plutôt qu’avec une simple étiquette générique. Un même service peut en effet explorer un site pour plusieurs finalités. (Cloudflare Docs)

Définir des règles spécifiques dans robots.txt

Vous pouvez autoriser certains robots et en bloquer d’autres :

User-agent: *
Allow: /

User-agent: ExampleTrainingBot
Disallow: /

User-agent: ExampleSearchBot
Allow: /

Sitemap: https://www.exemple.com/sitemap.xml

Avant d’ajouter un nom de robot, vérifiez sa documentation officielle et son user-agent exact. Une faute de nom rendrait la règle inefficace.

Utiliser les Content Signals

Les Content Signals permettent d’exprimer plus précisément les usages autorisés après l’accès au contenu.

Exemple présenté par Cloudflare :

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

Cette politique signifie :

Les Content Signals offrent donc davantage de nuances qu’un simple Allow ou Disallow.

Il faut néanmoins suivre l’évolution de cette initiative. Les signaux expriment une préférence, mais leur portée juridique et leur adoption peuvent varier selon les acteurs et les juridictions.

Attention à la politique par défaut de Markdown for Agents

La documentation de Cloudflare précise que si votre serveur d’origine fournit déjà un en-tête content-signal, sa valeur est conservée.

En revanche, si aucun en-tête n’est fourni par l’origine, Markdown for Agents ajoute actuellement cette valeur par défaut :

Content-Signal: ai-train=yes, search=yes, ai-input=yes

Les propriétaires de sites qui souhaitent interdire l’entraînement doivent donc définir explicitement leur propre politique au niveau du serveur d’origine ou de leur configuration Cloudflare. (Cloudflare Docs)

Il s’agit d’un point important à contrôler avant d’activer la conversion Markdown sur l’ensemble du domaine.

Utiliser AI Crawl Control de Cloudflare

Cloudflare propose AI Crawl Control pour observer les services d’IA qui visitent le site et appliquer des actions selon le robot concerné.

L’interface permet notamment de gérer les crawlers, de vérifier les directives du fichier robots.txt et d’activer différentes options comme Markdown for Agents.

Cloudflare propose aussi un fichier robots.txt géré automatiquement, mais sa configuration peut bloquer les robots d’IA connus. Cette option ne doit donc pas être activée sans vérifier qu’elle correspond à votre stratégie de visibilité. (Cloudflare Docs)

Une entreprise qui souhaite être citée dans les moteurs de réponses n’a pas nécessairement intérêt à bloquer tous les crawlers IA. À l’inverse, un éditeur proposant un contenu payant peut vouloir limiter fortement l’extraction.

Web Bot Auth : vérifier l’identité des agents

Les user-agents peuvent être falsifiés. Un robot malveillant peut se présenter sous le nom d’un service légitime afin de contourner les règles.

Web Bot Auth cherche à résoudre ce problème grâce à des signatures cryptographiques intégrées aux requêtes HTTP.

Le principe général est le suivant :

1. le bot signe sa requête ;

2. il publie ses clés publiques dans un répertoire connu ;

3. le site vérifie la signature ;

4. la requête peut être traitée selon l’identité vérifiée du bot.

Le point de terminaison utilisé pour publier les clés est notamment :

/.well-known/http-message-signatures-directory

Cloudflare vérifie la présence de ce mécanisme dans son audit, mais précise que tous les sites n’ont pas besoin de le mettre en œuvre. Il est surtout pertinent pour les services qui exploitent leurs propres agents ou qui doivent distinguer précisément les requêtes automatisées.

Quatrième contrôle : rendre les API et fonctionnalités découvrables

Un site de contenu peut obtenir un bon niveau de compatibilité sans API publique. Une application SaaS, une plateforme de réservation ou un outil professionnel doit aller plus loin.

L’objectif n’est plus simplement de rendre les pages lisibles. Il faut permettre aux agents de découvrir les actions disponibles et de les exécuter de façon contrôlée.

Publier un catalogue d’API

Le catalogue d’API repose sur un point de terminaison connu :

/.well-known/api-catalog

Il peut référencer les API, leurs spécifications OpenAPI, leur documentation et leurs points de terminaison d’état.

Exemple simplifié :

{
  "apis": [
    {
      "name": "API de réservation",
      "description": "Permet de rechercher et créer une réservation.",
      "documentation": "https://www.exemple.com/docs/api",
      "openapi": "https://www.exemple.com/openapi.json"
    }
  ]
}

Cette ressource évite qu’un agent doive parcourir manuellement toutes les pages de documentation pour comprendre les services disponibles.

Fournir une spécification OpenAPI correcte

Une API destinée aux agents doit disposer d’une spécification complète :

openapi: 3.1.0
info:
  title: API de réservation
  version: 1.0.0

paths:
  /reservations:
    post:
      summary: Créer une réservation
      requestBody:
        required: true
      responses:
        "201":
          description: Réservation créée

Les noms des opérations, descriptions, paramètres et réponses doivent être explicites. Un agent ne peut pas utiliser correctement une API dont les actions sont ambiguës ou insuffisamment documentées.

Configurer OAuth

Lorsqu’un agent doit agir au nom d’un utilisateur, il ne faut pas lui demander de récupérer directement les identifiants ou de détourner une session de navigateur.

OAuth permet à l’utilisateur d’accorder un accès limité et révocable.

Les agents doivent pouvoir découvrir le serveur d’autorisation et les ressources protégées grâce aux métadonnées prévues par les normes OAuth.

Cloudflare souligne qu’une procédure OAuth explicite est plus sûre que l’approche consistant à donner à l’agent l’accès complet à une session déjà connectée.

MCP : votre site a-t-il besoin d’un serveur Model Context Protocol ?

Le Model Context Protocol, ou MCP, est un protocole permettant à un agent de se connecter à des outils et à des sources de données.

Un serveur MCP peut, par exemple, exposer les outils suivants :

rechercher_des_produits
verifier_le_stock
creer_un_devis
consulter_une_commande
rechercher_dans_la_documentation

Is It Agent Ready vérifie notamment les mécanismes de découverte liés aux serveurs MCP.

Cloudflare utilise d’ailleurs son propre outil comme démonstration : Is It Agent Ready expose un serveur MCP permettant à un agent compatible d’analyser un site de manière programmatique, sans passer par l’interface web.

Qu’est-ce qu’une MCP Server Card ?

Une MCP Server Card est un document JSON placé dans un emplacement connu, par exemple :

/.well-known/mcp/server-card.json

Il décrit le serveur, son protocole, son point de terminaison, son mode d’authentification et ses outils.

Exemple simplifié :

{
  "version": "1.0",
  "serverInfo": {
    "name": "product-search",
    "title": "Recherche de produits",
    "version": "1.0.0"
  },
  "description": "Recherche des produits disponibles dans le catalogue.",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "authentication": {
    "required": true
  },
  "tools": [
    {
      "name": "search_products",
      "description": "Recherche des produits selon une requête.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        },
        "required": ["query"]
      }
    }
  ]
}

La MCP Server Card reste une proposition émergente. Elle est particulièrement intéressante pour les applications techniques, mais probablement excessive pour un simple site vitrine.

Agent Skills, A2A et WebMCP

Les Agent Skills décrivent des compétences ou procédures qu’un agent peut utiliser pour accomplir une tâche.

Un site peut publier un index à cette adresse :

/.well-known/agent-skills/index.json

Cet index indique quelles compétences sont disponibles et où trouver leurs instructions. Cloudflare utilise cette méthode sur Is It Agent Ready afin que les agents puissent comprendre les normes analysées et les correctifs associés.

Le protocole A2A, ou Agent-to-Agent, vise plutôt la communication entre agents. WebMCP cherche à exposer des fonctionnalités web sous une forme plus directement exploitable.

Ces normes sont encore en développement. Elles doivent être envisagées lorsque votre modèle économique nécessite de véritables interactions agentiques, et non pour améliorer artificiellement un score.

Cinquième contrôle : préparer une boutique au commerce agentique

Le commerce agentique désigne les situations dans lesquelles un agent recherche, sélectionne ou achète un produit pour le compte d’un utilisateur.

Un tunnel d’achat traditionnel est conçu pour un humain. Il repose souvent sur plusieurs écrans, des boutons graphiques, des formulaires dynamiques, des captchas et des validations visuelles.

Ce processus peut être difficile à utiliser pour un agent.

Is It Agent Ready recherche désormais plusieurs protocoles émergents :

Le protocole x402 réutilise notamment le code HTTP 402 Payment Required. Le serveur peut répondre avec des conditions de paiement structurées, l’agent réalise le paiement, puis recommence sa requête. (The Cloudflare Blog)

Ces technologies restent émergentes. Pour une boutique classique, les priorités immédiates restent un catalogue structuré, des pages produits accessibles, des données de prix cohérentes, une API sécurisée et un stock clairement identifiable.

Comment optimiser les pages produits pour les agents IA ?

Chaque page produit devrait présenter sans ambiguïté :

• le nom exact du produit ;

• la description ;

• le prix et la devise ;

• la disponibilité ;

• les variantes ;

• les délais de livraison ;

• la politique de retour ;

• l’identifiant du produit ;

• les avis ;

• les caractéristiques techniques.

Ces informations doivent apparaître dans le HTML rendu et dans les données structurées Product.

Exemple :

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Machine à bulles automatique",
  "sku": "MBA-001",
  "description": "Machine à bulles rechargeable avec lumières.",
  "offers": {
    "@type": "Offer",
    "price": "54.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://www.exemple.com/machine-bulles"
  }
}

La donnée structurée doit correspondre exactement au contenu visible. Un prix différent entre le JSON-LD et la page peut créer de la confusion pour les moteurs, les comparateurs et les agents.

Comment interpréter le score Is It Agent Ready ?

Le score doit servir de diagnostic, pas d’objectif absolu.

Un blog n’a pas besoin de déployer tous les protocoles commerciaux. Un site vitrine sans espace membre n’a pas besoin d’un système OAuth complexe. Une application SaaS peut, en revanche, avoir besoin d’un catalogue d’API, d’une authentification normalisée et d’un serveur MCP.

Vous pouvez utiliser cette grille :

Un bon audit doit répondre à cette question :

L’absence de cette norme empêche-t-elle un agent d’accomplir une tâche utile sur mon site ?

Lorsque la réponse est non, l’amélioration peut attendre.

Les erreurs les plus fréquentes qui bloquent les agents IA

Contenu exclusivement chargé côté client

La réponse HTML initiale ne contient presque aucune information. L’agent doit exécuter JavaScript, attendre les appels réseau et reconstruire la page.

Correction : utiliser le rendu serveur, la génération statique ou exposer une version accessible des données.

Pare-feu trop agressif

Un WAF ou une protection antibot peut envoyer un challenge JavaScript à tous les visiteurs automatisés.

Correction : distinguer les robots vérifiés, les agents autorisés et les comportements suspects.

Fichier robots.txt incohérent

Le site peut annoncer un sitemap inexistant, bloquer ses propres contenus ou utiliser une syntaxe invalide.

Correction : tester manuellement le fichier et vérifier les journaux d’exploration.

Informations essentielles cachées dans des images

Un prix, une procédure ou une caractéristique apparaît uniquement dans une bannière.

Correction : fournir également l’information sous forme textuelle et utiliser des textes alternatifs descriptifs.

Formulaires impossibles à interpréter

Les champs ne possèdent pas de labels et les messages d’erreur restent vagues.

Correction : utiliser des labels explicites, des attributs name cohérents et des réponses d’erreur structurées.

Données structurées absentes ou contradictoires

Le balisage indique une entreprise, un prix ou une date différente du contenu visible.

Correction : générer les données structurées à partir de la même source que l’interface.

Documentation trop fragmentée

Les informations sont dispersées sur des dizaines de pages sans index, résumé ni maillage cohérent.

Correction : ajouter une architecture documentaire claire, un llms.txt ciblé et des pages de référence complètes.

Cloudflare URL Scanner : une deuxième méthode d’audit

Cloudflare a également intégré les contrôles de préparation aux agents dans son URL Scanner.

Cet outil peut fournir des informations sur les en-têtes HTTP, le certificat TLS, le DNS, les technologies, les signaux de sécurité et la compatibilité agentique.

Dans le tableau de bord, le rapport dispose d’un onglet consacré à l’Agent Readiness. Cloudflare propose aussi une API permettant d’activer l’analyse avec l’option suivante :

{
  "options": {
    "agentReadiness": true
  }
}

Cette intégration permet d’automatiser les contrôles, par exemple après chaque déploiement ou dans une chaîne CI/CD. (The Cloudflare Blog)

Un audit régulier est préférable à une vérification unique. Une modification du CDN, du pare-feu, du framework ou du fichier robots.txt peut faire disparaître une fonctionnalité auparavant disponible.

Audit manuel complet en dix étapes

Voici une méthode fiable pour vérifier votre site sans dépendre uniquement d’un score automatique.

1. Contrôlez les codes HTTP

Les pages publiques doivent renvoyer un code 200. Vérifiez les redirections, les erreurs 404 et les erreurs serveur.

2. Inspectez robots.txt

Confirmez son accessibilité, la présence du sitemap et l’absence de blocage accidentel.

3. Analysez le sitemap

Supprimez les pages non canoniques, les redirections et les URL privées.

4. Testez le contenu sans JavaScript

Assurez-vous que les informations importantes sont présentes dans la réponse initiale.

5. Vérifiez le HTML sémantique

Contrôlez les titres, sections, tableaux, liens, boutons et formulaires.

6. Validez les métadonnées et données structurées

Testez les schémas Organization, Article, Product, Service, FAQPage ou SoftwareApplication selon le type de page.

7. Testez la négociation Markdown

Envoyez une requête avec Accept: text/markdown et comparez les contenus HTML et Markdown.

8. Définissez votre politique concernant les robots IA

Décidez clairement ce que vous autorisez pour la recherche, l’inférence et l’entraînement.

9. Analysez les fonctionnalités agentiques

Pour une application, vérifiez les API, OAuth, MCP, Agent Skills et fichiers .well-known.

10. Réalisez un test en situation réelle

Demandez à plusieurs assistants ou agents de trouver une information précise sur votre site. Vérifiez s’ils localisent la bonne page, comprennent correctement l’offre et citent la source appropriée.

Compatibilité avec les agents IA, SEO et GEO : quelles différences ?

Le SEO vise principalement la visibilité dans les moteurs de recherche.

Le GEO, ou Generative Engine Optimization, cherche à augmenter les chances qu’une marque ou un contenu soit utilisé dans les réponses générées par les systèmes d’IA.

L’Agent Readiness concerne la capacité technique d’un agent à découvrir, lire et utiliser le site.

Ces trois disciplines sont complémentaires.

Un excellent fichier MCP ne compensera pas un contenu pauvre ou une entreprise sans autorité. De même, une forte notoriété ne garantit pas qu’un agent puisse utiliser une interface mal structurée.

Pour compléter cet audit technique, consultez le guide expliquant comment mesurer sa visibilité dans les IA.

Vous pouvez également travailler votre présence dans les résultats génératifs grâce au guide consacré aux méthodes pour apparaître dans les AI Overviews de Google.

Enfin, la compatibilité technique doit s’accompagner d’une stratégie éditoriale et d’autorité. Le guide expliquant comment être cité par ChatGPT présente les optimisations complémentaires à mettre en œuvre.

FAQ : compatibilité des sites avec les agents IA