Les sites Web ont appris à communiquer avec les navigateurs, puis ont commencé à interagir avec les moteurs de recherche. Cloudflare pense maintenant que les sites Web doivent apprendre à communiquer avec les agences IA et propose un outil pour les aider. C'est une initiative ambitieuse, mais elle soulève plus de questions qu'elle ne fournit de réponses.

Points Forts :

  • Cloudflare a lancé un outil gratuit appelé isitagentready.com, qui évalue la conformité des sites Web avec les agences IA sur quatre dimensions : découvrabilité, contenu, contrôle d'accès et capacités.
  • Le Web n'est pas encore prêt : seulement 4 % des 200 000 sites Web analysés signalent leurs préférences pour l'utilisation de l'IA, et moins de 15 sites ont adopté les dernières normes telles que les Cartes de Serveur MCP ou les Catalogues API.
  • L'initiative repose sur un écosystème de normes en cours de construction, ce qui expose les premiers adoptants au risque de fragmentation ou d'obsolescence rapide.
  • Cloudflare se trouve dans une position où il détermine le score et propose des solutions pour l'améliorer, ce qui nécessite d'être interrogé.

Un Outil de Notation pour un Problème Réel

Le point de départ de Cloudflare est solide. Lorsqu'une agence IA souhaite accéder à un site Web, lire la documentation, acheter un produit ou interagir avec une API, elle se heurte à une infrastructure conçue pour les humains : HTML complexe, formulaires, sessions, captchas. En conséquence, des agences lentes, coûteuses en termes de jetons et souvent erronées émergent.

Cloudflare a mesuré l'ampleur du problème en parcourant les 200 000 noms de domaine les plus visités et en filtrant les redirections, les serveurs publicitaires et les services de tunnel, se concentrant sur les sites avec lesquels les agences pourraient raisonnablement interagir.

Le résultat est frappant : 78 % des sites ont un fichier robots.txt, mais presque tous sont écrits pour les navigateurs de moteurs de recherche traditionnels, pas pour les agences. Seulement 3,9 % fournissent du contenu en format Markdown sur demande. Et les nouvelles normes comme les Cartes de Serveur MCP ne sont disponibles que sur moins de 15 sites dans l'ensemble du jeu de données.

La solution proposée par Cloudflare via isitagentready.com offre un score structuré autour de quatre axes.

  • Découvrabilité, vérifie la présence et la qualité des fichiers robots.txt, sitemap.xml et des en-têtes de lien.
  • Contenu, évalue si le site propose une version propre en Markdown répondant à la demande d'une agence.
  • Contrôle d'accès, examine si le site exprime des préférences claires sur ce que les IA peuvent faire avec son contenu.
  • Enfin, capacités, teste la présence de normes plus avancées comme les Cartes de Serveur MCP, les Catalogues API ou la découverte OAuth pour permettre aux agences de s'authentifier correctement.

Normes Encore en Développement et Adoption Pratiquement Nulle

Ici, l'enthousiasme de Cloudflare doit être tempéré. Beaucoup des normes mises en avant à ce stade sont soit en phase de brouillon à l'IETF, soit des propositions informelles sans garantie d'acceptation générale. Le Catalogue API (RFC 9727), les Cartes de Serveur MCP ou l'authentification des bots Web sont de nouvelles normes qui n'ont pas encore atteint le statut RFC définitif à la date de publication.

Ce phénomène n'est pas propre à Cloudflare : c'est la réalité d'un Web en phase d'évolution. Cependant, cela nécessite une honnêteté que Cloudflare semble minimiser dans son article de blog. Si l'on considère qu'une norme adoptée aujourd'hui peut être révisée ou abandonnée dans les dix-huit mois, cela pourrait créer une charge de travail nécessitant une réintégration. Alors que les grands acteurs disposent des ressources pour suivre ces évolutions, ce n'est pas nécessairement le cas pour les petites équipes ou les développeurs indépendants.

L'exemple de llms.txt est frappant. Proposé en septembre 2024, ce fichier standardisé pour présenter un site à un LLM n'est pas inclus par défaut dans le score de Cloudflare, il est seulement facultatif. La raison ? La norme est encore en phase de discussion. C'est une décision prudente, mais cela montre également que Cloudflare ne sait pas encore quels risques il doit prendre.

Discussion sur le Contenu Markdown : Un Réel Gain Mesuré

Un des aspects les plus concrets de l'initiative, et probablement le plus urgent, est la capacité d'un serveur à répondre en format Markdown lorsqu'une agence envoie l'en-tête Accept: text/markdown. Cloudflare affirme avoir mesuré une réduction allant jusqu'à 80 % du nombre de jetons nécessaires pour lire une page.

Le contexte de ce chiffre est important. Le HTML d'une page de documentation technique est souvent très lourd : navigation, menus, scripts, balises imbriquées... tout cela crée du bruit pour un LLM. Un fichier Markdown bien structuré est l'essence du contenu sans emballage. Le résultat direct est une réduction des coûts des appels API pour les agences, une diminution des latences et une augmentation des chances d'obtenir le contexte complet sans interruption.

Cloudflare explique avoir testé son propre site de documentation (developers.cloudflare.com) et avoir redirigé une agence (via Kimi-k2.5 OpenCode) vers plusieurs sites techniques. Résultat : 31 % de consommation de jetons en moins et des réponses correctes 66 % plus rapides par rapport à d'autres sites non optimisés. Ces chiffres doivent être pris avec précaution, car ils proviennent de conditions de test internes non auditées. Cependant, l'ordre de grandeur est cohérent avec ce qui est connu sur l'excès structurel du HTML.

Application Technique dans Cloudflare Docs : Pratique et Répétable

La partie la plus instructive de l'article est la manière dont Cloudflare a restructuré sa propre documentation. L'approche est intéressante car elle surmonte un problème réel : parmi les sept outils testés en février 2026, seuls trois (Claude Code, OpenCode et Cursor) envoient automatiquement l'en-tête Accept: text/markdown. Une alternative est donc nécessaire pour les autres.

La solution choisie combine deux règles de Cloudflare :

  • Une réécriture d'URL transforme la requête /r2/get-started/index.md en /r2/get-started/,
  • Et ajoute automatiquement l'en-tête Accept: text/markdown à ces requêtes réécrites.

Résultat : Toute agence peut accéder à la version Markdown de n'importe quelle page en ajoutant /index.md à l'URL, sans avoir besoin de gérer un en-tête spécial.

Une autre décision notable : au lieu d'un seul fichier géant llms.txt (la documentation de Cloudflare contient plus de 5 000 pages), chaque répertoire de premier niveau a son propre fichier, et le fichier racine pointe vers ces sous-répertoires. Cela évite la boucle grep décrite dans l'article : une agence confrontée à un fichier trop long commence à perdre le fil, à rechercher des mots-clés, à augmenter les appels et à diminuer la qualité des réponses.

La granularité a également été soigneusement considérée : Environ 450 pages contenant uniquement des listes de liens (pages de répertoire) ont été exclues de llms.txt, car elles n'ajoutent aucune valeur sémantique pour un LLM pour les sous-pages déjà listées individuellement.

Un Acteur Notant et Vendant la Préparation au Score

La position de Cloudflare nécessite un examen attentif. L'entreprise publie un score de référence pour la préparation des agences, l'intègre dans le Navigateur URL, propose des modèles prêts à corriger chaque point de défaillance... et vend des produits (Workers, Rules, Access) pour appliquer ces corrections. isitagentready.com est également proposé par Cloudflare et héberge un serveur MCP.

Cela n'est pas nécessairement problématique : Google a fait la même chose avec Lighthouse et Core Web Vitals, devenant un fournisseur qui juge et fournit des outils pour améliorer la performance (via Google Cloud, Firebase, etc.). Cependant, cela signifie que les critères du score peuvent évoluer en fonction des intérêts commerciaux de l'entreprise autant que des besoins réels des agences. Une norme soutenue par une seule entreprise, même de bonne foi, peut influencer les directives.

De plus, il est remarquable que Cloudflare promeuve activement des normes concernant les paiements aux agences (x402, Protocole de Commerce Universel) ; certaines de ces normes incluent des partenaires directs comme Coinbase. Ces normes ne sont pas encore incluses dans le score, mais leur présence dans l'outil indique déjà un aspect.

Ce que les Développeurs Peuvent Réellement Faire Aujourd'hui

Malgré ces réserves, de nombreuses actions offrent un retour clair et immédiat, indépendamment de l'évolution des normes :

  • Offrir du Markdown sur demande est techniquement simple, réduit les coûts pour les consommateurs d'API et améliore la qualité des réponses pour les agences. C'est une priorité.
  • Modifier le robots.txt pour les agences IA (par exemple, en ajoutant des directives pour des navigateurs comme GPTBot, ClaudeBot, CCBot) est une bonne hygiène et sans coût, clarifiant les droits d'accès.
  • Pour les sites avec beaucoup de contenu, structurer le llms.txt par section est une bonne pratique de documentation pour les agences et pour ceux qui souhaitent rapidement comprendre l'architecture d'un site.

D'un autre côté, appliquer les Cartes de Serveur MCP ou les Catalogues API pour un site qui n'a pas encore d'API publique ou de cas d'utilisation clair pour les agences équivaut à construire une salle d'attente sans visiteurs.

Adoption Comme Indicateur de Marché, Pas Comme Obligation

La véritable valeur de l'initiative de Cloudflare réside peut-être dans le jeu de données Radar : un ensemble de données qui suit chaque adoption de norme parmi les 200 000 sites les plus visités sur une base hebdomadaire, segmenté par catégories de noms de domaine. Ces données permettront de mesurer si les normes apportent réellement des bénéfices ou si la plupart des sites restent passifs, s'attendant à ce que les agences s'adaptent à eux, comme ils l'ont fait avec HTML depuis déjà trente ans.

La réponse à cette question en dira long sur la dynamique de pouvoir entre les éditeurs de sites et les développeurs d'agences. Les agences les plus populaires, lorsqu'elles auront acquis des capacités de parsing HTML suffisamment robustes, exerceront moins de pression sur les sites pour qu'ils s'adaptent. En revanche, si les coûts et les délais de consommation de HTML non optimisé deviennent un avantage concurrentiel mesurable pour les sites conformes, l'adoption augmentera naturellement.