Can AI agents use your website?

Un nouveau genre de visiteur

Pendant trente ans, un site web a eu exactement un genre de visiteur qui comptait : une personne, dans un navigateur, regardant des pages rendues. Tout dans le web moderne — les paquets JavaScript, les bandeaux de cookies, les défis visuels anti-bots — a été construit pour ce visiteur. Les agents IA brisent l’hypothèse. Un agent qui travaille pour un utilisateur récupère en général du HTML brut sans exécuter de JavaScript, s’identifie honnêtement avec un agent utilisateur comme GPTBot ou ClaudeBot, lit les fichiers orientés machine qu’un site publie (robots.txt, sitemaps, llms.txt, spécifications OpenAPI), et décide en quelques requêtes si ce site peut seulement être compris et utilisé. Les sites qui ratent ce test ne sont pas punis bruyamment ; l’agent va simplement ailleurs, et la visite n’apparaît jamais dans aucun tableau de bord d’analytique que vous possédiez.

Cela compte maintenant, et non un jour, parce que les agents deviennent un vrai canal : des assistants qui recherchent des achats, des agents qui réservent et achètent, des agents de support qui lisent votre documentation pour répondre aux clients, des robots qui construisent les index depuis lesquels ces systèmes répondent. Chacun d’eux note votre site sur la lisibilité par machine, et la plupart des sites n’ont jamais été conçus pour être lus ainsi. L’écart est rarement de la malveillance ou de la négligence — c’est que la surface orientée machine (les règles d’exploration, le HTML brut, les descriptions d’API) a grandi par accident pendant que la surface orientée humain recevait toute l’attention de conception. La préparation aux agents est la discipline qui consiste à combler cet écart exprès.

Les quatre couches de la préparation aux agents

Le vérificateur note quatre couches, dans l’ordre où un agent les vit. La découverte (20 points), c’est si l’agent peut trouver la carte du site : un robots.txt analysable et ce qu’il dit aux principaux robots d’IA, un sitemap joignable, un fichier llms.txt, des données structurées, une URL canonique qui pointe sur elle-même. L’accès (30 points), c’est si l’agent peut entrer une fois arrivé : des pages qui répondent à un client HTTP simple, aucun refus des agents utilisateurs d’IA, aucun interstitiel de défi anti-bots, un contenu réel dans le HTML brut plutôt qu’une coquille vide attendant le JavaScript, une redirection propre vers HTTPS et des codes de statut honnêtes — un vrai 404 pour ce qui n’existe pas, parce qu’un agent qui ne peut pas distinguer une page absente d’une vraie ne peut faire confiance à rien d’autre de ce que le site dit.

L’utilisabilité (40 points) est la plus grande couche, parce qu’arriver n’est pas transiger. Elle demande si le site expose une machinerie par laquelle un agent peut agir : une spécification OpenAPI aux chemins que les agents cherchent, une documentation qu’une machine peut trouver, un point de terminaison MCP qui répond à une sonde de protocole, des métadonnées de découverte d’authentification quand il y a une API à laquelle se connecter, et les humbles formulaires web — inscription, contact, prospect — joignables sans défi et assez bien étiquetés pour être remplis correctement. Les paiements (10 points) demandent si un agent pourrait payer : un fichier de découverte pour l’un des protocoles émergents de commerce agentique (ACP, UCP, AP2, x402) et un paiement qui ne plante pas un défi au visage de l’agent. Les paiements ne sont notés que quand un site vend réellement quelque chose ; sur un site sans signaux de commerce, toute la couche n’est pas applicable et le score est remis à l’échelle sans elle.

Comment lire un score

Le score va de 0 à 100, avec des notes en lettres A à partir de 85, B à 70, C à 55, D à 40 et F en dessous — et 70, le seuil du B, est l’endroit où la convention de la catégorie place la ligne « prêt pour les agents ». Traitez le nombre comme un résumé, pas comme le produit. Le produit est la liste des constats : chaque vérification qui a échoué ou averti, la preuve recueillie pour elle, ce qu’elle signifie, la correction et les points que la correction récupère. L’ordre « corriger d’abord » est simplement cette liste triée par points récupérables, ce qui n’est presque jamais l’ordre que donnerait une liste générique — un llms.txt manquant peut valoir plus que trois avertissements cosmétiques réunis, et le tri est ce qui vous le dit.

Deux habitudes de lecture gardent le nombre honnête. D’abord, respectez le mécanisme de non applicable : les vérifications et les couches entières sortent quand leur condition préalable est absente, et le score se renormalise, donc un site de documentation n’est pas noté sur son paiement. Un score n’a de sens que face aux couches qui s’appliquaient. Ensuite, rappelez-vous ce que signifie un verdict : « introuvable » est toujours « introuvable aux chemins qu’un agent essaierait, depuis le réseau du scanner, au moment de l’analyse ». Les agents essaient les chemins conventionnels — c’est le sens de l’exercice —, mais une analyse est un échantillon de la surface orientée machine, pas un audit de tout ce qu’un agent déterminé pourrait finir par découvrir avec un humain pour le guider.

Les échecs qui coûtent le plus, et leurs corrections

La même poignée d’échecs explique la plupart des points perdus sur les sites réels. Robots d’IA bloqués par défaut : un robots.txt copié d’un modèle, ou un préréglage de sécurité d’un CDN, refuse sèchement GPTBot, ClaudeBot et compagnie — parfois le contraire de ce que le propriétaire veut, puisque les mêmes robots nourrissent les moteurs de réponses où le propriétaire veut apparaître. La correction est une politique robots délibérée : décidez par robot, écrivez-la, gardez le sitemap autorisé. La coquille vide : la page d’accueil renvoie un paquet JavaScript et une roue qui tourne, le contenu réel n’étant rendu que côté client ; les humains ne le remarquent jamais, les agents voient une page vide. Rendez côté serveur, ou pré-rendez, le contenu qui compte. Pas de carte pour machines : pas de sitemap, pas de llms.txt, pas de données structurées — chacun bon marché à ajouter, chacun un constat séparé jusqu’à ce que vous le fassiez.

La seconde poignée concerne l’action plutôt que la lecture. Sécurité défi d’abord : un mur anti-bots qui défie chaque client inconnu défie aussi chaque agent ; la correction est de défier sur le comportement et les signaux de risque plutôt que sur la seule étrangeté, et de garder joignable la surface publique en lecture seule. APIs non documentées ou introuvables : l’API existe, mais il n’y a pas de spécification OpenAPI à un chemin trouvable, donc chaque intégration d’agent devient un jeu de devinettes sur mesure ; publier la spécification est un export unique dans la plupart des cadres. Formulaires qu’un agent ne peut pas remplir : champs sans étiquettes, indications seulement dans le texte de substitution, et flux d’envoi qui exigent de résoudre un casse-tête visuel pour un formulaire de contact routinier. Aucune de ces corrections n’exige de reconcevoir le site humain — la couche orientée machine est presque entièrement additive, et c’est pourquoi les points sont là à prendre.

Étude de cas : ce site, analysé

Une révélation avant le nombre. sysosx.com lui-même ne peut pas être analysé avec le vérificateur public ci-dessus : comme chaque vérification de sysosx, le point de terminaison refuse sysosx.com comme cible bloquée, par conception, pour que l’outil ne puisse pas pointer sur sa propre infrastructure. L’étude de cas ci-dessous a donc été produite autrement — le même moteur d’analyse, avec les mêmes vérifications et la même notation, exécuté localement contre le site sysosx.com en direct. Le score est une sortie réelle du moteur, pas une estimation ; seul le point de vue diffère.

Où sont partis les points : les principaux constats

Questions fréquentes