Cloudflare Agent Readiness Score : ce que le chiffre signifie vraiment

Cloudflare a lancé un outil qui attribue un score de "readiness" à n'importe quel domaine, mesurant sa capacité à interagir avec les AI agents. Beaucoup de responsables SEO ont découvert un score de 20/100 et paniqué. Avant de lancer un sprint correctif, il faut comprendre ce que ce score mesure réellement — et surtout ce qu'il ne mesure pas.

Ce que Cloudflare évalue (et la méthodologie derrière le score)

Le Agent Readiness Score de Cloudflare repose sur une série de vérifications automatisées qui inspectent la surface technique d'un site exposée aux AI agents. Contrairement à un audit Lighthouse qui évalue les performances front-end, ce score évalue la lisibilité machine structurée : est-ce qu'un agent autonome (pas un crawler classique, pas un humain) peut comprendre, négocier et interagir avec votre site de façon programmatique ?

Les checks se répartissent en plusieurs catégories :

Fichiers de déclaration d'intention

Cloudflare vérifie la présence de fichiers comme robots.txt, llms.txt, llms-full.txt, ai.txt, et /.well-known/agent.json. Chacun remplit un rôle distinct :

• robots.txt : standard historique, mais Cloudflare évalue aussi la granularité des directives pour les user-agents IA (GPTBot, ClaudeBot, Google-Extended, etc.)
• llms.txt : un format émergent proposé pour décrire le contenu d'un site à destination des LLMs (description du site, sitemap sémantique, liens vers les contenus principaux)
• /.well-known/agent.json : le fichier clé pour l'interopérabilité agent. Il déclare les capacités du site, les endpoints API, les protocoles supportés (MCP, A2A, etc.)

Google lui-même a publié des guidelines contradictoires selon ses produits sur la gestion de llms.txt, comme analysé dans cet article. Le fait que Cloudflare évalue ce fichier comme un critère binaire (présent/absent) sans pondérer la qualité de son contenu est une première limite méthodologique.

Données structurées et machine-readability

Le score pénalise l'absence de Schema.org, mais de façon assez grossière. Un site e-commerce sans Product schema perdra des points. Un blog sans Article schema aussi. Mais un SaaS B2B qui vend un service intangible n'a souvent aucun type de schéma pertinent à implémenter au-delà de Organization et WebSite.

Endpoints d'interaction

C'est la partie la plus avant-gardiste — et la moins applicable aujourd'hui. Cloudflare vérifie si votre site expose des endpoints compatibles avec des protocoles d'agents : est-ce qu'un agent peut réserver, acheter, interroger une base de connaissances via une API déclarée ? Pour 95% des sites, la réponse est non, et c'est normal.

Pourquoi votre score est probablement plus bas qu'il ne devrait l'être

Prenons un cas concret. Un média en ligne avec 8 000 articles, construit sur Next.js avec SSR, bonne implémentation Schema.org (NewsArticle, BreadcrumbList, Organization), robots.txt propre, sitemap XML à jour. Ce site obtient un Agent Readiness Score de 30/100.

Pourquoi ? Parce que le score intègre des vérifications qui ne s'appliquent pas à un média :

• Pas de /.well-known/agent.json : un média n'a pas d'API transactionnelle à exposer aux agents. Il n'y a rien à "réserver" ou "acheter" via un agent autonome. Pénalité injustifiée.
• Pas de llms-full.txt : ce fichier est censé fournir un dump exhaustif du contenu pour ingestion LLM. Pour un média qui publie 20 articles/jour, maintenir ce fichier est irréaliste et potentiellement contre-productif (vous donnez votre contenu gratuitement aux modèles sans contrepartie).
• Pas de protocole MCP/A2A détecté : ces protocoles sont conçus pour des interactions transactionnelles (réservation, e-commerce, services). Un site éditorial n'en a pas besoin.

Le score de 30/100 reflète donc une inadéquation entre la grille d'évaluation et le type de site, pas un problème technique réel.

À l'inverse, un site e-commerce de 15 000 SKUs qui n'implémente aucune de ces couches a un vrai problème stratégique. Les AI agents shopping (Google Shopping avec Gemini, Amazon Rufus, etc.) vont privilégier les catalogues qu'ils peuvent parser programmatiquement. Pour ce type de site, chaque point du score correspond à un delta de visibilité futur mesurable.

Les checks qui comptent réellement, par type de site

Site e-commerce (5 000 à 50 000 produits)

Voici les éléments qui ont un impact réel sur la capacité des agents à interagir avec votre catalogue :

1. Schema Product avec toutes les propriétés transactionnelles

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Câble USB-C Thunderbolt 4 — 2m",
  "sku": "TB4-USBC-2M",
  "gtin13": "5901234123457",
  "brand": {
    "@type": "Brand",
    "name": "CablePro"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://cablestore.fr/produits/tb4-usbc-2m",
    "priceCurrency": "EUR",
    "price": "34.99",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "4.90",
        "currency": "EUR"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 1,
          "maxValue": 3,
          "unitCode": "DAY"
        }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail"
    }
  }
}
</script>

Les propriétés shippingDetails et hasMerchantReturnPolicy sont celles que la plupart des sites oublient. Ce sont précisément celles qu'un agent shopping va interroger pour comparer des offres et prendre une décision d'achat au nom de l'utilisateur.

2. Le fichier /.well-known/agent.json

Pour un e-commerce, ce fichier a un sens. Il déclare les capacités transactionnelles du site :

{
  "schema_version": "1.0",
  "name": "CableStore",
  "description": "Vente de câbles et accessoires informatiques professionnels",
  "url": "https://cablestore.fr",
  "capabilities": {
    "product_search": {
      "endpoint": "https://cablestore.fr/api/v1/products/search",
      "method": "GET",
      "parameters": {
        "q": "string — search query",
        "category": "string — product category slug",
        "min_price": "number",
        "max_price": "number",
        "in_stock": "boolean"
      }
    },
    "product_detail": {
      "endpoint": "https://cablestore.fr/api/v1/products/{sku}",
      "method": "GET"
    }
  },
  "authentication": {
    "type": "api_key",
    "header": "X-Agent-Key"
  },
  "rate_limits": {
    "requests_per_minute": 60
  },
  "contact": "[email protected]"
}

Ce fichier n'a pas encore de spécification standardisée définitive. Cloudflare pousse sa propre structure. Google travaille sur le User-Chosen Products (UCP) framework qui couvre un périmètre similaire mais avec des conventions différentes. L'important est d'avoir quelque chose de structuré plutôt que rien.

Site éditorial / média

Pour un média, les checks réellement pertinents sont :

• robots.txt avec directives granulaires pour les bots IA (vous décidez ce que les LLMs peuvent ou ne peuvent pas ingérer)
• Schema NewsArticle / Article complet avec datePublished, dateModified, author typé en Person avec sameAs
• llms.txt basique (optionnel, et à gérer avec discernement)

Le fichier agent.json avec des endpoints transactionnels ? Inutile. Le score de Cloudflare vous pénalise pour ça, mais c'est du bruit.

SaaS B2B

Pour un SaaS, la situation est intermédiaire. Un agent pourrait vouloir :

• Interroger votre documentation technique (un llms.txt pointant vers votre doc API a du sens)
• Vérifier vos plans tarifaires (schema SoftwareApplication avec offers)
• Initier un trial via API

Mais si votre modèle commercial repose sur un processus de vente avec démo et qualification, exposer un endpoint de signup aux agents n'est pas forcément souhaitable.

Comment auditer votre score et prioriser les actions

Étape 1 : récupérer le détail du score

Cloudflare expose le score sur son dashboard pour les domaines qu'il proxifie. Pour les autres, l'outil public donne un score global. Mais le score global est insuffisant — vous avez besoin du détail par catégorie de check.

Commencez par vérifier manuellement les fichiers attendus :

# Vérifier la présence des fichiers de déclaration
for file in robots.txt llms.txt llms-full.txt .well-known/agent.json ai.txt; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://cablestore.fr/$file")
  echo "$file: HTTP $status"
done

# Résultat attendu :
# robots.txt: HTTP 200
# llms.txt: HTTP 404
# llms-full.txt: HTTP 404
# .well-known/agent.json: HTTP 404
# ai.txt: HTTP 404

Ce script trivial vous donne en 5 secondes la carte de ce qui manque. Ensuite, classez chaque fichier manquant en trois catégories : pertinent pour votre type de site, optionnel mais utile, non applicable.

Étape 2 : auditer les données structurées avec Screaming Frog

Lancez un crawl Screaming Frog en activant l'extraction de structured data (Configuration > Spider > Extraction > JSON-LD). Exportez vers un CSV et vérifiez la couverture :

• Quel pourcentage de vos pages produit ont un schema Product ?
• Combien incluent offers, availability, shippingDetails ?
• Vos pages auteur ont-elles un schema Person avec sameAs pointant vers des profils vérifiables ?

Sur un e-commerce de 15 000 pages produit, vous découvrirez typiquement que 60-70% des pages ont un schema Product basique (nom, prix, disponibilité) mais que moins de 15% incluent shippingDetails et hasMerchantReturnPolicy. Ce delta de 85% représente votre surface d'amélioration la plus impactante.

Étape 3 : prioriser par impact business, pas par score Cloudflare

Le score Cloudflare pondère tous les checks de façon relativement égale. Votre priorisation doit être différente :

Check	E-commerce	Média	SaaS B2B
robots.txt granulaire (user-agents IA)	Haute	Haute	Moyenne
Schema complet avec propriétés transactionnelles	Critique	N/A	Moyenne
llms.txt	Moyenne	Basse*	Haute
/.well-known/agent.json	Haute	Basse	Moyenne
Protocole MCP/A2A	Basse (sauf marketplace)	N/A	Basse

*Basse pour un média car fournir un llms.txt exhaustif revient à offrir votre contenu aux modèles gratuitement. C'est une décision business, pas technique.

Implémenter llms.txt sans offrir votre contenu gratuitement

Le fichier llms.txt est un standard proposé (pas encore formalisé en RFC). Sa structure est simple : un fichier texte à la racine du site qui décrit le contenu et pointe vers les ressources clés.

Le piège : beaucoup d'implémentations suggèrent d'y lister toutes vos URLs avec des descriptions complètes. Pour un média ou un site dont la valeur réside dans le contenu lui-même, c'est un cadeau empoisonné. Vous facilitez l'ingestion par les LLMs sans aucune garantie de citation ou de trafic retour.

L'approche pragmatique :

# cablestore.fr

> CableStore est le spécialiste français des câbles et connectique professionnelle. 
> Catalogue de 15 000 références avec specs techniques détaillées.

## Documentation
- [Guide de compatibilité USB-C](https://cablestore.fr/guides/compatibilite-usb-c): Matrice complète de compatibilité USB-C par protocole (USB 2.0 à USB4, Thunderbolt 3/4/5)
- [API Catalogue](https://cablestore.fr/developers/api): Documentation de l'API REST pour intégrations partenaires

## Catégories principales  
- [Câbles USB-C](https://cablestore.fr/cables-usb-c): Câbles USB-C certifiés, triés par protocole et longueur
- [Câbles HDMI](https://cablestore.fr/cables-hdmi): Câbles HDMI 2.0 et 2.1, certifiés Ultra High Speed
- [Adaptateurs](https://cablestore.fr/adaptateurs): Adaptateurs et hubs multiport

## Politique
Pour toute utilisation commerciale de nos données produit, contactez [email protected]

Remarquez ce qui n'y figure pas : les fiches produit individuelles, les prix, les avis clients. Vous exposez la structure et les contenus éducatifs (qui servent votre autorité), pas les données transactionnelles (qui servent votre CA).

Ce positionnement est cohérent avec l'approche de Google sur la visibilité des marques dans les résultats IA : les agents doivent comprendre qui vous êtes et ce que vous proposez, pas nécessairement accéder à chaque donnée produit sans passer par votre site.

Gérer les user-agents IA dans robots.txt : au-delà du binaire

La plupart des implémentations robots.txt traitent les bots IA en bloc : tout autoriser ou tout bloquer. L'approche fine consiste à segmenter par intention :

# robots.txt — CableStore
# Crawlers de recherche classiques
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

# Agents IA pour l'indexation de contenu (training data)
# Bloquer — notre contenu n'est pas gratuit pour le training
User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

# Agents IA pour le shopping / comparaison (trafic transactionnel)
# Autoriser — ces agents génèrent des conversions
User-agent: Google-Shopping
Allow: /produits/
Allow: /api/v1/products/
Disallow: /compte/
Disallow: /panier/

# Agent Google généraliste (Gemini dans Search)
User-agent: Google-InternalBot
Allow: /produits/
Allow: /guides/
Disallow: /compte/

# Fallback
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /compte/
Disallow: /panier/

Sitemap: https://cablestore.fr/sitemap-index.xml

Un point critique : à ce jour, Google-Shopping n'est pas un user-agent officiel. Google utilise Googlebot pour l'essentiel de ses crawls, y compris Shopping. La segmentation granulaire par user-agent IA est donc encore aspirationnelle pour certains agents. Mais GPTBot, ClaudeBot, CCBot et Google-Extended sont documentés et respectés par leurs opérateurs respectifs.

Vérifiez régulièrement dans vos logs serveur quels user-agents IA crawlent effectivement votre site. Un outil comme GoAccess ou une analyse directe des access logs vous donnera la réalité terrain :

# Identifier les bots IA dans vos access logs Nginx
grep -iE "(GPTBot|ClaudeBot|CCBot|Google-Extended|anthropic|Bytespider|PetalBot)" \
  /var/log/nginx/access.log | \
  awk '{print $14}' | sort | uniq -c | sort -rn | head -20

Si GPTBot crawle 50 000 URLs/jour sur votre site média et que vous ne le bloquez pas, vous offrez votre production éditoriale à OpenAI sans contrepartie. Le score Cloudflare vous dira que c'est "bien" parce que vous êtes "ouvert" aux agents. Votre directeur éditorial aura un avis différent.

Le vrai enjeu derrière le score : la course au protocole

Le Agent Readiness Score de Cloudflare n'est pas un outil neutre d'évaluation technique. C'est un levier stratégique pour Cloudflare, qui développe activement son propre écosystème d'AI agents (Cloudflare Workers AI, AI Gateway, etc.). En promouvant une grille d'évaluation qui valorise les formats et protocoles qu'ils supportent, Cloudflare se positionne comme l'infrastructure de référence pour l'ère des agents.

Ce n'est pas une critique — c'est un constat. Google fait exactement la même chose avec ses recommandations sur les données structurées et le protocole UCP. Anthropic pousse MCP (Model Context Protocol). Google répond avec A2A (Agent-to-Agent).

Pour un responsable technique, le risque est d'investir massivement dans un protocole qui ne deviendra pas le standard. L'approche défensive : implémenter les couches de base qui seront utiles quel que soit le protocole gagnant.

Ces couches de base sont :

1. Des données structurées Schema.org complètes (le plus petit dénominateur commun)
2. Un robots.txt avec des directives granulaires par user-agent
3. Un llms.txt minimal décrivant la structure du site
4. Des APIs REST documentées si votre site a une dimension transactionnelle

Les protocoles MCP et A2A sont encore trop immatures pour justifier un investissement d'implémentation sur un site de production, sauf si vous êtes une marketplace ou une plateforme de réservation où l'interaction agent est déjà une réalité (pensez à Booking.com, pas à votre blog corporate).

Monitoring continu : ne pas traiter le score comme un snapshot

Le score Cloudflare est une photo à un instant T. Mais les fichiers de configuration évoluent, les déploiements cassent des choses, et les équipes de développement ne pensent pas toujours au llms.txt quand elles reconfigurent le serveur.

Un scénario classique : votre équipe DevOps migre vers une nouvelle infrastructure. Le reverse proxy est reconfiguré. Le /.well-known/agent.json retourne un 404 parce que personne n'a pensé à ajouter la route dans la nouvelle config Nginx. Pendant 6 semaines, les agents qui tentent de découvrir vos capabilities transactionnelles repartent bredouilles.

Ce type de régression silencieuse est exactement ce qu'un outil de monitoring comme Seogard détecte automatiquement. Comme pour les metas qui disparaissent lors d'une migration de framework, les fichiers d'interopérabilité agent sont des cibles de régression que personne ne surveille manuellement.

Intégrez la vérification de ces fichiers dans vos checks de déploiement :

# Extrait d'un pipeline CI/CD — vérification post-deploy
agent-readiness-check:
  stage: post-deploy
  script:
    - |
      DOMAIN="https://cablestore.fr"
      ERRORS=0
      
      for path in "/robots.txt" "/llms.txt" "/.well-known/agent.json" "/sitemap-index.xml"; do
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" "${DOMAIN}${path}")
        if [ "$STATUS" != "200" ]; then
          echo "❌ ${path} returned HTTP ${STATUS}"
          ERRORS=$((ERRORS + 1))
        else
          echo "✅ ${path} OK"
        fi
      done
      
      # Vérifier que le schema JSON-LD est présent sur la homepage
      SCHEMA_COUNT=$(curl -s "${DOMAIN}" | grep -c "application/ld+json")
      if [ "$SCHEMA_COUNT" -eq 0 ]; then
        echo "❌ No JSON-LD schema found on homepage"
        ERRORS=$((ERRORS + 1))
      else
        echo "✅ JSON-LD schema found (${SCHEMA_COUNT} blocks)"
      fi
      
      if [ "$ERRORS" -gt 0 ]; then
        echo "⚠️ ${ERRORS} agent readiness check(s) failed"
        exit 1
      fi
  only:
    - main

Ce check de 30 lignes dans votre pipeline CI/CD évite des semaines de régression non détectée. C'est le strict minimum.

Ce que le score ne dit pas (et qui importe plus)

Le Agent Readiness Score ne mesure pas :

• La qualité de vos données structurées : il vérifie la présence, pas la validité. Un schema Product avec des offers vides passera le check mais sera inutile pour un agent.
• La performance de vos endpoints : déclarer une API dans agent.json ne sert à rien si elle répond en 8 secondes ou retourne des erreurs 30% du temps.
• La fraîcheur de vos données : un llms.txt qui pointe vers des URLs 404 est pire que pas de llms.txt du tout.
• L'alignement avec votre stratégie business : ouvrir tous vos contenus aux agents de training est "agent-ready" selon le score, mais potentiellement destructeur de valeur.

Ces dimensions qualitatives sont invisibles dans un score automatisé. Elles nécessitent un jugement humain informé par une compréhension du modèle business du site.

Le score est un point de départ utile pour identifier les lacunes évidentes — pas une feuille de route d'implémentation. Filtrez chaque recommandation à travers cette question : est-ce qu'un agent AI interagissant avec cette fonctionnalité génère de la valeur pour mon business ? Si la réponse est non, le check échoué est du bruit, pas un signal.

Le Cloudflare Agent Readiness Score va probablement évoluer rapidement à mesure que les protocoles se stabilisent. Les actions qui survivront à toutes les itérations sont les fondamentaux : des données structurées complètes, un robots.txt réfléchi, et un monitoring continu pour détecter les régressions dès qu'elles surviennent — ce qui est précisément le type de surveillance automatique que Seogard surveille en permanence sur votre périmètre technique.