Découvrez notre score de préparation aux agents. Votre site est-il prêt à accueillir les agents ?

Internet a toujours dû s'adapter à de nouvelles normes. Il a appris à communiquer avec les navigateurs web, puis à dialoguer avec les moteurs de recherche. Il doit désormais apprendre à dialoguer avec les agents IA.

Nous sommes ravis de vous présenter aujourd'hui isitagentready.com : un nouvel outil conçu pour aider les propriétaires de sites à mieux comprendre comment optimiser leurs sites pour les agents, du guidage de ces derniers à travers le processus d'authentification au contrôle du contenu qu'ils peuvent voir, du format dans lequel ils le reçoivent et de la manière dont ils le rémunèrent. Nous lançons également un nouvel ensemble de données sur Cloudflare Radar, conçu pour suivre l'adoption de chaque norme relative aux agents sur Internet.

Nous souhaitons prêcher par l'exemple. C'est pourquoi nous vous informons également de notre récente réorganisation de la Developer Documentation Cloudflare (les documents destinés aux développeurs) dont le but consistait à rendre notre site de documentation le plus convivial possible pour les agents, mais aussi de permettre aux outils IA de répondre plus rapidement aux questions, pour un coût nettement inférieur.

En réalité… pas vraiment. Cette situation est attendue, mais révèle également à quel point les agents pourraient être plus efficaces qu'ils ne le sont aujourd'hui si des normes étaient adoptées.

Pour analyser cette dernière, Cloudflare Radar a sélectionné les 200 000 domaines les plus visités sur Internet, filtré les catégories pour lesquelles la préparation aux agents n'a aucune importance (comme les redirections, les serveurs publicitaires et les services de tunnellisation) afin de se concentrer sur les entreprises, les plateformes et les éditeurs avec lesquels les agents AI pourraient réellement avoir besoin d'interagir. Nous avons ensuite scanné les catégories restantes à l'aide de notre nouvel outil.

Nous avons ainsi produit un nouveau graphique nommé « Adoption of AI agent standards » (Adoption des normes relatives aux agents IA) qui figure désormais sur la page Cloudflare Radar AI Insights (Statistiques concernant l'IA). Cette page nous permet ensuite de mesurer l'adoption de chaque norme dans différentes catégories de domaines.

Certains éléments ont retenu notre attention en ce qui concerne les mesures de contrôle individuelles :

• L'utilisation du fichier robots.txt est pratiquement universelle et 78 % des sites en possèdent un. La grande majorité d'entre eux sont toutefois rédigés à l'attention des robots d'indexation des moteurs de recherche traditionnels, pas pour les agents IA.

• Signaux de contenu : 4 % des sites ont déclaré leurs préférences en matière d'utilisation de l'IA dans leurs fichiers robots.txt. Cette nouvelle norme gagne manifestement en popularité.

• La négociation de contenu Markdown (diffusion de contenu text/markdown grâce à l'en-tête Accept: text/markdown) est présente sur 3,9 % des sites.

• De nouvelles normes émergent, comme les cartes de serveur MCP (MCP Server Cards) et les catalogues d'API (RFC 9727), mais elles n'apparaissent que pour moins de 15 sites sur l'ensemble du jeu de données. Nous en sommes encore à un stade précoce. Vous avez la possibilité de vous démarquer en faisant partie des premiers sites à adopter les nouvelles normes et à travailler efficacement avec les agents. 

Ce graphique sera actualisé chaque semaine et les données seront également accessibles par l'intermédiaire de l'outil Data Explorer ou de l'API Radar.

Vous pouvez obtenir un score évaluant l'état de votre préparation aux agents pour votre propre site web en vous rendant sur isitagentready.com et en saisissant l'URL de votre site.

Les scores et les audits qui proposent un retour d'information exploitable ont déjà contribué à l'adoption de nouvelles normes. L'outil Google Lighthouse, par exemple, évalue les sites web en fonction de leurs performances et de leur respect des bonnes pratiques en matière de sécurité. Il guide les propriétaires de sites dans l'adoption des dernières normes régissant les plateformes web. Nous pensons qu'un outil similaire devrait exister pour aider les propriétaires de sites à adopter les bonnes pratiques concernant les agents.

Lorsque vous saisissez l'URL de votre site, Cloudflare adresse des requêtes à ce dernier pour contrôler les normes qu'il prend en charge, avant de lui attribuer un score basé sur quatre axes :

• Référencement : robots.txt, sitemap.xml, en-têtes de lien (RFC 8288)

• Contenu : Markdown for Agents

• Contrôle des accès des bots : signaux de contenu, règles régissant les bots IA contenues dans le fichier robots.txt, Web Bot Auth

• Fonctionnalités : Agent Skills (compétences des agents), catalogue d'API (RFC 9727), identification des serveurs OAuth à l'aide des RFC 8414 et RFC 9728, MCP Server Card et WebMCP

^{Capture d'écran des résultats obtenus après exécution de la procédure de contrôle de l'état de préparation aux agents effectuée pour un site web donné.}

Nous vérifions également si le site prend en charge les normes de commerce agentique, notamment x402, Universal Commerce Protocol et Agentic Commerce Protocol, mais celles-ci ne sont pas encore prises en compte dans notre note.

Pour chaque contrôle en échec, nous vous communiquons une invite à transmettre à votre agent de codage afin qu'il l'implémente en votre nom.

Le site lui-même est prêt pour accueillir les agents et prêche donc par l'exemple. Il expose un serveur MCP sans état (https://isitagentready.com/.well-known/mcp.json) au moyen d'un outil scan_site exécuté en Streamable HTTP. N'importe quel agent compatible MCP peut donc analyser les sites web de manière programmatique, sans passer par l'interface web. Il publie également un index des Agent Skills (https://isitagentready.com/.well-known/agent-skills/index.json) comportant des documents de compétences pour chaque norme contrôlée. Les agents sauront non seulement ce qu'il faut corriger, mais aussi comment procéder.

Intéressons-nous maintenant de manière plus approfondie aux contrôles de chaque catégorie et à leur importance pour les agents.

Le fichier robots.txt existe depuis 1994 et la plupart des sites en possèdent un. Le fichier robots.txt sert deux objectifs pour les agents. Il définit les règles d'exploration (quels agents peuvent accéder à quelles ressources) et pointe vers les sitemaps de votre site. Un sitemap (plan de site) est un fichier XML qui répertorie chaque chemin d'accès à votre site. Il s'agit fondamentalement d'une carte que les agents peuvent suivre pour explorer l'ensemble de votre contenu sans avoir à suivre chaque lien. Le fichier robots.txt est la première étape des agents lorsqu'ils explorent un site.

Au-delà des sitemaps, les agents sont également capables d'identifier des ressources importantes directement à partir des en-têtes de réponse HTTP, et plus précisément de l'en-tête de réponse Link (RFC 8288). Contrairement aux liens incorporés au code HTML, l'en-tête Link fait partie intégrante de la réponse HTTP elle-même et permet donc à un agent d'identifier les liens vers les ressources sans avoir à analyser le moindre balisage :

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

Le déploiement d'un agent sur votre site est une chose. S'assurer qu'il peut réellement lire votre contenu en est une autre.

En septembre 2024 (soit ce qui semble remonter à une éternité compte tenu de la rapidité d'évolution de l'IA), le fichier llms.txt a été avancé comme moyen de proposer une représentation d'un site web conviviale pour les LLM et de s'intégrer à la fenêtre contextuelle du modèle. Placé à la racine de votre site, le fichier llms.txt fournit une liste de lecture structurée aux agents : la nature du site, son contenu et l'emplacement de ses informations importantes. Considérez-le comme un plan de site conçu pour être lu par un LLM plutôt qu'indexé par un robot d'exploration :

# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)

La négociation de contenu Markdown va encore plus loin. Lorsqu'un agent va chercher une page et lui adresse un en-tête Accept: text/markdown, le serveur répond en proposant une version propre de la page en Markdown plutôt qu'en HTML. La version Markdown nécessite beaucoup moins de jetons (d'après nos mesures, jusqu'à 80 % de moins dans certains cas). Les réponses sont donc plus rapides, moins coûteuses et plus susceptibles d'être consommées dans leur intégralité, compte tenu des limitations dont la plupart des outils d'agents disposent par défaut en ce qui concerne leurs fenêtres de contexte.

Par défaut, nous ne vérifions que si le site traite correctement la négociation de contenu Markdown et ne contrôlons pas la présence d'un fichier llms.txt. Vous pouvez personnaliser vous-même le processus d'analyse afin qu'il intègre le fichier llms.txt si vous le souhaitez.

Maintenant que les agents peuvent s'orienter sur votre site Internet et consommer votre contenu, la question suivante se pose : souhaitez-vous réellement permettre à n'importe quel bot de faire de même ?

Le fichier robots.txt peut servir à autre chose que d'indiquer simplement l'emplacement des sitemaps. C'est également à cet endroit que vous définissez vos règles d'accès. Vous pouvez déclarer explicitement quels bots d'exploration sont autorisés à entrer sur votre site et les ressources auxquelles ils peuvent accéder. Vous pouvez même stipuler des chemins d'accès spécifiques. Cette convention est bien établie et ce fichier demeure le premier élément que tous les bots bien élevés doivent consulter avant de commencer à explorer un site.

Les signaux de contenu vous permettent d'être encore plus spécifiques. Plutôt que de vous contenter d'autoriser un bot à accéder à votre site ou de l'empêcher d'entrer, vous pouvez déclarer exactement ce que l'IA peut faire avec votre contenu. La présence d'une directive Content-Signal au sein de votre fichier robots.txt, vous permet de contrôler trois aspects de manière indépendante : si votre contenu peut être utilisé à des fins d'entraînement de l'IA (« ai-train »), s'il peut être utilisé comme entrant IA à des fins d'inférence et d'ancrage (« ai-input »), et s'il doit figurer dans les résultats de recherche (« search ») :

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

Inversement, le projet de norme IETF Web Bot Auth (authentification des bots web) permet aux bots « amis » de s'authentifier et aux sites web qui reçoivent des requêtes de la part des bots de les identifier comme tels. Le bot signe ses requêtes HTTP et le site récepteur contrôle ces signatures à l'aide des clés publiques publiées par le bot.

Ces clés publiques résident sur un point de terminaison bien connu, /.well-known/http-message-signatures-directory, que nous contrôlons bien évidemment dans le cadre de l'analyse.

Tous les sites n'ont pas besoin de mettre cette mesure de contrôle en œuvre. L'opération n'est par exemple pas nécessaire si votre site se contente de diffuser du contenu et n'adresse pas de requêtes à d'autres sites. Nous nous attendons cependant à ce que cette technologie prenne de l'importance au fil du temps, suite à l'augmentation du nombre de sites Internet qui exécutent leurs propres agents et adressent des requêtes à d'autres sites.

Au-delà de la consommation passive de contenu, les agents peuvent également interagir directement avec votre site web en effectuant des appels d'API, en invoquant des outils et en achevant des tâches de manière autonome.

Si votre service comporte une ou plusieurs API publiques, le catalogue d'API (RFC 9727) s'impose comme un emplacement unique et connu où les agents peuvent identifier toutes vos API. Hébergé à l'adresse /.well-known/api-catalog, il dresse la liste de vos API et renvoie vers leurs spécifications, leur documentation et leurs points de terminaison d'état, en vous évitant ainsi de contraindre les agents à parcourir votre portail pour développeurs ou votre documentation.

Nous ne pouvons décemment pas parler des agents sans mentionner le MCP. Le protocole MCP (Model Context Protocol, protocole de contexte de modèle) est une norme ouverte qui permet aux modèles IA de se connecter à des sources de données et des outils externes. Plutôt que de développer une intégration personnalisée pour chaque outil IA, vous n'avez à bâtir qu'un serveur MCP unique, que tous les agents compatibles pourront utiliser.

Vous pouvez également publier une MCP Server Card pour aider les agents à trouver votre serveur MCP (cette proposition est en cours de rédaction). Cette Card se présente sous la forme d'un fichier JSON résidant à l'adresse /.well-known/mcp/server-card.json et permet de décrire votre serveur avant même qu'un agent ne s'y connecte : les outils qu'il expose, la manière d'y accéder et la procédure à suivre pour s'authentifier auprès de lui. Les agents consultent ce fichier et connaissent dès lors tout ce dont ils ont besoin pour commencer à utiliser votre serveur :

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
  "version": "1.0",
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "search-mcp-server",
    "title": "Search MCP Server",
    "version": "1.0.0"
  },
  "description": "Search across all documentation and knowledge base articles",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "authentication": {
    "required": false
  },
  "tools": [
    {
      "name": "search",
      "title": "Search",
      "description": "Search documentation by keyword or question",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string" }
        },
        "required": ["query"]
      }
    }
  ]
}

Les agents sont plus efficaces lorsqu'ils disposent de compétences d'agent (Agent Skills) qui les aident à accomplir des tâches spécifiques. Mais comment un agent peut-il identifier les compétences qu'un site lui propose ? Nous avons proposé que les sites puissent rendre ces informations disponibles à l'adresse .well-known/agent-skills/index.json, un point de terminaison qui indique à l'agent quelles compétences sont disponibles et à quel endroit. Vous remarquerez peut-être que la norme .well-known (RFC 8615) est utilisée par de nombreux autres normes ayant trait aux agents et à l'autorisation. Nous souhaitons à ce titre remercier Mark Nottingham de Cloudflare, qui est à l'origine de cette norme, ainsi que les autres contributeurs de l'IETF !

De nombreux sites exigent que vous vous connectiez en premier lieu avant d'accéder à leur contenu. C'est la raison pour laquelle les utilisateurs humains éprouvent des difficultés à accorder aux agents la capacité d'accéder à ces sites en leur nom et pourquoi certains ont adopté l'approche de contournement potentiellement dangereuse qui consiste à ce que l'utilisateur accorde aux agents l'accès à son navigateur web par l'intermédiaire de la session sur laquelle ils sont connectés.

Une meilleure solution existe et permet aux internautes d'accorder explicitement l'accès. En indiquant aux agents où trouver le serveur d'autorisation (RFC 9728), les sites qui prennent en charge OAuth permettent aux agents d'accompagner les utilisateurs humains au terme d'un processus OAuth, au sein duquel ils pourront choisir d'accorder officiellement l'accès à l'agent. Comme annoncé lors de l'Agents Week 2026, la solution Cloudflare Access prend désormais en charge l'intégralité de ce processus OAuth. Nous avons également montré de quelle manière des agents tels qu'OpenCode peuvent s'appuyer sur cette norme pour s'assurer que tout fonctionne correctement lorsque les utilisateurs communiquent des URL protégées aux agents :

Les agents peuvent également acheter des produits en votre nom, mais les procédures de paiement en ligne ont été conçues pour les humains : ajouter un article au panier, saisir le numéro de carte de paiement et cliquer sur « Payer ». Ce processus s'effondre totalement lorsque l'acheteur est un agent IA.

La norme x402 résout ce problème au niveau du protocole en rétablissant l'erreur HTTP 402 « Payment Required » (« paiement nécessaire »), un code d'état présent dans les spécifications depuis 1997, mais qui n'avait jamais connu une large utilisation. Le processus est simple : un agent demande une ressource, le serveur répond par un code 402 et un contenu lisible par machine qui décrit les conditions du paiement. L'agent procède au paiement et recommence. Cloudflare s'est associée à Coinbase pour lancer la x402 Foundation, un organisme dont la mission consiste à favoriser l'adoption du x402 en tant que norme ouverte pour les paiements sur Internet.

Nous contrôlons également la présence des protocoles Universal Commerce Protocol (protocole de commerce universel) et Agentic Commerce Protocol (protocole de commerce agentique), deux normes émergentes parmi les protocoles de commerce agentique conçues pour permettre aux agents d'identifier et d'acheter les produits que les humains achèteraient généralement par l'intermédiaire de boutiques d'e-commerce (et donc en suivant un processus de paiement).

L'outil URL Scanner proposé par Cloudflare vous permet de nous adresser une URL de votre choix et d'obtenir un rapport détaillé à son sujet : en-têtes HTTP, certificats TLS, enregistrements DNS, technologies utilisées, données relatives aux performances et signaux de sécurité. Il s'agit d'un outil fondamental pour les chercheurs en sécurité et les développeurs qui souhaitent comprendre le fonctionnement exact d'une URL en coulisses.

Nous avons repris les mêmes mesures de contrôle que celles utilisées sur la page isitagentready.com et les avons ajoutées à l'URL Scanner sous un nouvel onglet nommé Préparation aux agents. Ainsi, lorsque vous scannerez une URL donnée, vous pourrez désormais consulter le rapport complet sur l'état de préparation aux agents du site, en plus de son analyse habituelle : les contrôles réussis, le degré actuel du site et les recommandations pour améliorer le score du site.

Cette intégration est également disponible de manière programmatique par l'intermédiaire de l'API URL Scanner. Transmettez l'option « agentReadiness » dans votre requête d'analyse afin d'y inclure les résultats indiquant le niveau de préparation aux agents :

curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    -d '{
          "url": "https://www.example.com",
          "options": {"agentReadiness": true}
        }'

Lorsque nous étions en train de développer les outils qui nous permettraient de mesurer le degré de préparation d'Internet, nous savions que nous devions nous assurer que nos propres affaires étaient en ordre. Nos documents doivent être facilement compréhensibles pour les agents que nos clients utilisent.

Nous avons naturellement adopté les normes pertinentes relatives aux sites et au contenu mentionnées ci-dessus. N'hésitez d'ailleurs pas à consulter notre score en la matière ici. Nous ne nous sommes toutefois pas arrêtés en si bon chemin. Découvrez comment nous avons amélioré les Developer Docs de Cloudflare afin d'en faire l'une des ressources les plus conviviales pour les agents sur Internet.

Malheureusement, sur les 7 agents testés en février 2026, seuls Claude Code, OpenCode et Cursor demandent du contenu avec l'en-tête Accept: text/markdown par défaut. Pour les autres, nous avions besoin d'une connexion de secours fluide basée sur URL.

À cet effet, nous mettons chaque page à disposition séparément par l'intermédiaire d'un fichier Markdown (relative à l'URL de la page) à l'adresse /index.md. Cette tâche est réalisée de manière dynamique en combinant deux règles Cloudflare, sans dupliquer les fichiers statiques : 

• Une règle de réécriture d'URL fait correspondre les requêtes se terminant par /index.md et les réécrit de manière dynamique vers le chemin de base à l'aide de l'expression regex_replace (en supprimant /index.md). 

• Une règle de transformation d'en-tête de la requête correspond au chemin de la requête initiale avant sa réécriture (raw.http.request.uri.path) et définit automatiquement l'en-tête Accept: text/markdown. 

Grâce à ces deux règles, nous pouvons récupérer n'importe quelle page au format Markdown en ajoutant l'adresse /index.md à l'URL :

• https://developers.cloudflare.com/r2/get-started/index.md

Nous pointons vers ces URL /index.md dans nos fichiers llms.txt. Autrement dit, pour ces chemins /index.md, nous renverrons toujours du texte Markdown, quels que soient les en-têtes définis par le client. Nous parvenons à mener à bien cette opération sans étape de développement supplémentaire ni duplication de contenu.

Le fichier llms.txt sert de « base principale » aux agents, en leur offrant un répertoire de pages conçu pour aider les LLM à trouver le contenu. Un document unique de plus de 5 000 pages de documentation dépasse toutefois la taille des fenêtres contextuelles des modèles.

Plutôt qu'un fichier massif, nous générons un fichier llms.txt distinct pour chaque répertoire de premier niveau dans nos documents. Le fichier llms.txt à la racine pointe simplement vers ces sous-répertoires.

• https://developers.cloudflare.com/llms.txt

• https://developers.cloudflare.com/r2/llms.txt

• https://developers.cloudflare.com/workers/llms.txt

Nous supprimons également des centaines de pages d'annuaires qui n'apportent que peu de valeur sémantique à un LLM afin de nous assurer que chaque page propose un contexte descriptif riche (titres, noms sémantiques et descriptions).

Nous omettons, par exemple, près de 450 pages qui ne servent qu'à dresser une liste des répertoires localisés, comme : https://developers.cloudflare.com/workers/databases/.

Ces pages apparaissent dans notre sitemap, mais ne contiennent que très peu d'informations pour un LLM. Comme toutes les pages filles sont déjà liées individuellement au sein du fichier llms.txt, la récupération d'une page de répertoire ne propose qu'une liste redondante de liens et contraint l'agent à émettre une autre requête pour trouver le contenu réel.

Chaque entrée du fichier llms.txt doit être riche en contexte, mais légère en jetons, pour aider les agents à s'orienter de manière efficace. Les utilisateurs humains peuvent ignorer l'en-tête frontmatter et les étiquettes de filtrage, mais ces métadonnées constituent la roue directrice pour un agent IA. C'est la raison pour laquelle notre équipe Product Content Experience (PCX) a affiné nos titres de page, nos descriptions et nos structures d'URL afin que les agents sachent toujours exactement quelles pages récupérer.

Examinons une section de notre fichier racine llms.txt.

Chaque lien comporte un nom sémantique, une URL correspondante et une description de haute valeur. Aucun travail supplémentaire n'a été nécessaire pour générer le fichier llms.txt. Toutes les informations étaient déjà disponibles dans l'en-tête frontmatter des documents. Il en va de même pour les pages mentionnées dans les répertoires de premier niveau des fichiers llms.txt. L'ensemble de ce contexte confère aux agents tous les outils nécessaires pour trouver plus efficacement les informations pertinentes.

Nous testons également nos documents par rapport aux afdocs. Cette spécification de documentation émergente et adaptée aux les agents, qui se double d'un projet open source, permet aux équipes de tester divers aspects des sites de documentation, comme l'identification du contenu et la navigation. Cette spécification nous a permis de développer nos propres outils d'audit personnalisés. En ajoutant quelques mesures correctives ciblées et spécifiques à notre scénario d'utilisation, nous avons produit un tableau de bord conçu pour faciliter l'évaluation.

Nous avons pointé un agent (Kimi-k2.5 via OpenCode) vers les fichiers llms.txt d'autres grands sites de documentation technique et demandé à cet agent de répondre à des questions techniques très spécifiques.

En moyenne, l'agent pointé vers la documentation de Cloudflare a consommé 31 % de jetons en moins et est arrivé à la bonne réponse 66 % plus rapidement que le site moyen non optimisé pour les agents. L'intégration de nos répertoires de produits au sein d'une fenêtre contextuelle unique permet aux agents d'identifier la page exacte dont ils ont besoin et de la récupérer en suivant un chemin linéaire unique.

La précision des réponses des LLM constitue bien souvent une conséquence de l'efficacité de la fenêtre contextuelle. Nous avons observé une tendance récurrente avec d'autres ensembles de documentation pendant les tests.

1. La boucle grep : de nombreux sites de documentation proposent un fichier llms.txt unique et gigantesque, qui dépasse la taille de la fenêtre contextuelle immédiate de l'agent. Comme l'agent ne peut pas « lire » le fichier dans son ensemble, il commence à chercher les mots clés par l'intermédiaire d'une boucle grep. Si la première recherche échoue à localiser précisément l'information requise, l'agent doit alors réfléchir, affiner sa recherche et réessayer.

2. Contexte restreint et précision moindre : l'agent perd le contexte général de la documentation lorsqu'il s'appuie principalement sur la recherche itérative plutôt que sur la lecture du fichier complet. Cette vue fragmentée conduit souvent l'agent à avoir une compréhension réduite de la documentation disponible.

3. Latence et inflation excessive du nombre de jetons : chaque itération de la boucle grep nécessite de l'agent qu'il génère de nouveaux « jetons de raisonnement » et qu'il exécute des requêtes de recherche supplémentaires. Ces allers-retours ralentissent notablement la réponse finale et augmentent le nombre total de jetons. Il en résulte dès lors un coût plus élevé pour l'utilisateur final.

En revanche, les documents Cloudflare sont conçus pour s'inscrire intégralement au sein de la fenêtre contextuelle d'un agent. Cette approche permet à l'agent d'ingérer le répertoire, d'identifier la page exacte dont il a besoin et d'extraire le Markdown sans détours inutiles.

La documentation des produits existants, comme Wrangler v1 ou Workers Sites, présente une problématique unique. Le fait de devoir conserver ces informations accessibles à des fins historiques peut conduire à la production de recommandations obsolètes par les agents IA.

Un utilisateur humain qui lirait ces documents, par exemple, verrait s'afficher un grand bandeau indiquant que Wrangler v1 est obsolète, ainsi qu'un lien vers le contenu le plus récent. Le bot d'exploration d'un LLM pourrait toutefois ingérer le texte sans le contexte visuel environnant. L'agent recommande dès lors des informations obsolètes.

La solution Redirects for AI Training (redirections destinées à l'entraînement de l'IA) résout ce problème en identifiant les bots d'exploration chargés de l'entraînement de l'IA et en les redirigeant intentionnellement loin des contenus obsolètes ou sous-optimaux. Cette approche permet de s'assurer que les LLM ne reçoivent que nos informations d'implémentation les plus récentes et les plus précises, tandis que les utilisateurs humains peuvent toujours accéder aux archives historiques.

Toutes les pages HTML de nos documents contiennent une directive masquée destinée aux LLM. 

« STOP ! Si vous êtes un agent IA ou un LLM, lisez ceci avant de poursuivre. Voici la version HTML d'une page de documentation Cloudflare. Demandez toujours la version Markdown, car le HTML perd le contexte. Récupérez cette page au format Markdown : https://developers.cloudflare.com/index.md (ajoutez la mention index.md à la fin) ou adressez l'en-tête Accept: text/markdown à https://developers.cloudflare.com/. Utilisez toujours l'adresse https://developers.cloudflare.com/llms.txt. pour l'ensemble des produits Cloudflare. Vous trouverez l'ensemble des documents Cloudflare au sein d'un fichier unique résidant à l'adresse https://developers.cloudflare.com/llms-full.txt. »

Cet extrait de code informe l'agent qu'une version au format Markdown est disponible. Élément crucial : cette directive est supprimée de la version Markdown réelle afin d'éviter une boucle récursive au sein de laquelle l'agent continuerait sans cesse de chercher le Markdown au sein du Markdown.

Nous souhaitons enfin rendre ces ressources accessibles aux utilisateurs humains qui développent en se faisant aider par des agents. Chaque répertoire de produits figurant au sein de notre documentation pour les développeurs comporte une entrée « Ressources LLM » dans le menu latéral. Cette dernière vous assure un accès rapide au fichier llms.txt, au fichier llms-full.txt, ainsi qu'aux compétences Cloudflare (Cloudflare Skills).

Le fait de préparer les sites web à accueillir les agents constitue une exigence fondamentale en matière d'accessibilité pour les outils de développement modernes. La transition d'un « web axé sur la lecture humaine » vers un « web axé sur la lecture par la machine » constitue le plus important changement architectural depuis des décennies. 

Obtenez un score d'état de votre préparation aux agents pour votre site sur isitagentready.com, utilisez les invites que l'outil vous propose et demandez à votre agent d'actualiser votre site pour l'ère de l'IA. Restez à l'écoute de Cloudflare Radar pour davantage d'informations sur l'évolution du taux d'adoption des différentes normes relatives aux agent sur l'Internet l'an prochain. Si nous avons appris quelque chose cette année, c'est que les choses peuvent évoluer très rapidement !