AI Agent Readiness Checker
La préparation aux agents IA, c’est le degré d’utilisabilité d’un site web pour un agent IA : un logiciel qui arrive sans navigateur, lit le HTML brut et les fichiers lisibles par machine, et tente d’accomplir une tâche au nom d’un visiteur. Ce vérificateur aborde un domaine comme le ferait un agent — requêtes HTTP simples, agents utilisateurs d’agents, les chemins bien connus que les agents essaient d’abord — et note ce qu’il trouve de 0 à 100 sur quatre couches : découverte, accès, utilisabilité et paiements.
Vous voulez savoir dès que votre site casse pour les agents — ou pour tout le monde ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Ce que fait l’analyse, couche par couche
La visite d’un agent ne ressemble en rien à celle d’une personne. Pas de clics, pas de défilement et en général pas de JavaScript : l’agent récupère directement les fichiers et les pages, décide d’après ce qui revient si le site peut être compris et utilisé, et abandonne vite quand ce n’est pas le cas. Cette analyse rejoue cette visite en quatre couches. La découverte demande si l’agent peut seulement trouver la carte du site — un robots.txt analysable et la façon dont il traite les principaux robots d’IA, un sitemap XML joignable, un fichier llms.txt, des données structurées sur la page d’accueil, une URL canonique correcte. L’accès demande si l’agent peut vraiment entrer : la page d’accueil doit répondre à un client HTTP simple, ne doit pas refuser les agents utilisateurs d’IA connus ni leur lancer un interstitiel de défi anti-bots, doit servir un contenu réel dans son HTML brut plutôt qu’une coquille d’application vide, rediriger proprement vers HTTPS et renvoyer des codes de statut honnêtes, y compris un vrai 404 pour les pages qui n’existent pas.
Les deux couches les plus lourdes regardent au-delà de la porte d’entrée. L’utilisabilité — la plus grande couche, qui vaut 40 des 100 points — demande si l’agent peut faire quelque chose une fois dedans : y a-t-il une spécification OpenAPI aux chemins que les agents essaient, s’analyse-t-elle et décrit-elle de vraies opérations, la documentation de l’API est-elle découvrable, un point de terminaison MCP répond-il à une sonde initialize, y a-t-il des métadonnées de découverte d’authentification quand le site a une API, les formulaires d’inscription et de contact sont-ils joignables sans défi et assez bien étiquetés pour être remplis ? Les paiements demandent si un agent pourrait terminer un achat : un fichier de découverte de paiement agentique pour l’un des protocoles émergents (ACP, UCP, AP2 ou x402) et une page de paiement qu’un agent peut atteindre. Les paiements sont délibérément conditionnels — ils ne sont notés que lorsque le site montre des signaux de commerce, comme des liens de panier ou de paiement, parce qu’un blog ou un site de documentation ne devrait pas perdre de points pour un paiement dont il n’a jamais eu besoin.
Comment fonctionne le score
Chaque couche porte une part fixe des 100 points — découverte 20, accès 30, utilisabilité 40, paiements 10 — et chaque vérification dans une couche réussit, avertit, échoue ou n’est pas applicable. Un score de 70 ou plus gagne l’étiquette « prêt pour les agents » ; les notes en lettres sont A à partir de 85, B à 70, C à 55, D à 40 et F en dessous. Quand toutes les vérifications d’une couche ne sont pas applicables — les paiements sur un site sans signaux de commerce sont le cas courant — la couche disparaît entièrement et les couches restantes sont remises à l’échelle de 100, de sorte que le score compare toujours des choses comparables. Chaque constat nomme les points qu’il coûte : la liste « corriger d’abord » trie simplement les échecs et les avertissements selon les points que vous récupéreriez, donc l’ordre de la page est l’ordre dans lequel il vaut la peine de travailler. Et chaque constat est montré en entier — la preuve recueillie, ce qu’il signifie et la correction — gratuitement, sans sections verrouillées.
Vérifications liées : le bilan de santé de site web pour le tableau classique disponibilité, certificat et DNS du même domaine, le noteur SSL quand le problème de l’agent s’avère être la configuration TLS, et le ping global quand la joignabilité diffère selon la région. Le guide compagnon, les agents IA peuvent-ils utiliser votre site web ?, parcourt les couches, explique comment lire un score et ce qu’une analyse réelle de ce site a trouvé.
Des limites honnêtes, dites comme les résultats le méritent. L’analyse s’exécute depuis notre serveur dans une région Azure des États-Unis et fait au plus environ 45 requêtes, donc elle voit le site depuis un réseau, sur un continent, comme le verrait un agent hébergé là-bas. Un verdict « introuvable » signifie toujours « introuvable aux chemins qu’un agent essaierait, d’ici, à cet instant » — jamais l’affirmation qu’un fichier n’existe nulle part. Un site qui se comporte différemment selon la géographie, ou qui limite le débit des clients inconnus, peut obtenir un autre score depuis un autre point de vue ; revérifiez après les changements au lieu de traiter une analyse comme un verdict éternel. Rien de tout cela n’est une raison de cacher les constats : les services qui vendent des audits de préparation aux agents montrent habituellement le score gratuitement et facturent les corrections par domaine. Ici, les corrections sont l’essentiel, donc les corrections sont gratuites.
Les quatre couches et ce que chacune demande
| Découverte — 20 points | Un agent peut-il trouver le site et sa carte ? Un robots.txt analysable et son traitement des robots d’IA, un sitemap XML joignable, llms.txt, des données structurées et une URL canonique autoréférente. |
| Accès — 30 points | Un agent peut-il entrer ? La page d’accueil répond à un client HTTP simple et aux agents utilisateurs d’IA sans défi anti-bots, sert un contenu réel en HTML brut, redirige proprement vers HTTPS et renvoie un vrai 404 pour les pages manquantes. |
| Utilisabilité — 40 points | Un agent peut-il agir ? Une spécification OpenAPI découvrable et analysable, une documentation d’API, un point de terminaison MCP qui répond à une sonde, une découverte d’authentification là où une API existe, et des formulaires qu’un agent peut trouver, lire et soumettre. |
| Paiements — 10 points | Un agent peut-il payer ? Un fichier de découverte de paiement agentique (ACP, UCP, AP2 ou x402) et un paiement joignable sans défi — noté uniquement quand le site montre des signaux de commerce, sinon non applicable. |
Questions fréquentes
Qu’est-ce qu’un agent IA, en ce sens ?
Un logiciel qui visite un site web au nom de quelqu’un et tente d’accomplir une tâche — rechercher, réserver, acheter, remplir un formulaire — sans qu’une personne pilote un navigateur. Les agents récupèrent en général du HTML brut et des fichiers lisibles par machine (robots.txt, sitemaps, llms.txt, spécifications OpenAPI), peuvent s’identifier avec des agents utilisateurs comme GPTBot ou ClaudeBot, et ne peuvent pas résoudre de défis visuels ni exécuter de JavaScript lourd comme le fait un navigateur. Un site peut être excellent pour les personnes et presque inutilisable pour les agents ; ce vérificateur mesure la seconde propriété.
Quel score compte comme prêt pour les agents ?
70 sur 100 ou plus, ce qui est aussi une note B ou mieux (le A commence à 85, le C à 55, le D à 40). Le seuil est une convention de la catégorie de préparation aux agents plutôt qu’une loi de la nature : à 70, un site est normalement découvrable, joignable sans défis, et expose assez de structure lisible par machine pour qu’un agent travaille avec. Lisez les constats, pas seulement le nombre — deux sites à 70 peuvent manquer de choses entièrement différentes.
La couche paiements dit « non applicable ». Est-ce grave ?
Non. Les paiements ne s’appliquent qu’aux sites qui montrent des signaux de commerce — des liens de panier ou de paiement, ou une plateforme de boutique connue. Quand elle ne s’applique pas, la couche est retirée du calcul et les trois autres couches sont remises à l’échelle de 100, donc un blog, un site de documentation ou un portfolio n’est jamais puni pour l’absence d’un paiement. Il en va de même pour les vérifications individuelles dans d’autres couches : la vérification de la page de tarifs n’est pas applicable quand aucune page de tarifs n’est liée, et celle du formulaire d’inscription quand il n’y a pas de lien d’inscription.
Pourquoi l’analyse voit-elle autre chose que mon navigateur ?
Parce que la visite d’un agent est différente. L’analyse utilise des requêtes HTTP simples, aucune exécution de JavaScript, et dans plusieurs vérifications l’agent utilisateur d’un robot d’IA, le tout depuis notre serveur dans une région Azure des États-Unis. Si votre site sert une coquille vide qui ne se remplit qu’après l’exécution de JavaScript, ou montre un défi anti-bots aux agents utilisateurs inconnus, ou se comporte différemment en dehors de votre pays, l’analyse rapporte cette vue aux yeux d’agent — qui est exactement la vue qui décide si les agents peuvent utiliser le site.
Tous les constats et corrections sont-ils vraiment gratuits ?
Oui. Chaque constat que ce vérificateur produit — la preuve, ce qu’il signifie, la correction et les points qu’il vaut — est montré en entier sur cette page, et le lien du rapport peut être partagé avec n’importe qui. Certains services de préparation aux agents montrent un score gratuit et facturent la liste des corrections par domaine ; nous pensons que les corrections sont la partie utile, donc il n’y a pas de mur payant ici. L’analyse est limitée en débit parce que chacune coûte jusqu’à environ 45 requêtes, mais une analyse terminée est à vous.