Méthodologie de notation

Ce que nous mesurons

Une question : à quel point est-il facile pour un utilisateur derrière un agent IA de trouver un produit sur ce site et de le placer dans un panier ?

Le scénario : un acheteur demande à Claude, ChatGPT ou Operator d'acheter quelque chose sur votre site. L'agent lance son navigateur (via un serveur Model Context Protocol, un outil computer-use intégré ou une couche d'automatisation headless), navigue vers votre site, essaie de trouver le bon produit, essaie de l'ajouter au panier, et soit réussit soit abandonne. S'il abandonne, l'utilisateur va chez un concurrent — et vous ne voyez jamais la vente perdue dans GA4.

Serge mesure, de manière déterministe et sans exécuter d'agent en direct au moment du scan, si les conditions structurelles pour que ce parcours réussisse sont en place. Nous regardons les choses dont un agent aurait besoin : données produit lisibles par machine, DOM navigable, éléments interactifs accessibles, accès crawler non bloqué, structure d'URL cohérente, signaux clairs d'inventaire et de prix, et une poignée d'autres signaux qui corrèlent avec le succès de la traversée par l'agent.

Comment nous mesurons

Déterministe. Le scanner public n'appelle pas de LLM au moment du scan. Exécuter un agent réel contre chaque domaine qui atteint le site rendrait le scanner inabordable et lent. Au lieu de cela, Serge crawle un échantillon représentatif du site et inspecte les propriétés structurelles qui prédisent si un agent serait capable de compléter la tâche.

Les exécutions d'agents en direct ont lieu dans le produit payant. Investigate Mode (notre livrable entreprise) exécute un véritable agent IA — Claude Desktop via MCP, et plus tard Operator et GPT Agent — contre une URL spécifique pour capturer la session réelle, le raisonnement, les interactions DOM et les points de défaillance. C'est une surface séparée, derrière le tier payant. Le scanner public est le cousin déterministe qui vous donne une réponse rapide, peu coûteuse et partageable à la même question.

Les vérifications spécifiques et les pondérations continuent d'évoluer. La direction de recherche actuelle inclut :

• L'agent peut-il atteindre le site du tout ? Posture de protection bot, robots.txt, comportement WAF.
• L'agent peut-il trouver des produits ? Sitemap, sémantique de navigation, trouvabilité des URL produit, structure de liens internes.
• L'agent peut-il parser les données produit ? Schema.org Product / Offer / Availability, prix structurés, métadonnées de variantes.
• L'agent peut-il interagir avec la page ? Vrais boutons vs <div onClick>, noms accessibles, rôles ARIA, sémantique clavier.
• L'agent peut-il ajouter au panier ? Exposition de l'état du panier, mécanique de sélection de variantes, visibilité de l'inventaire.

Nous continuerons à publier des révisions ici à mesure que la liste de vérifications, les pondérations et la calibration de benchmark se resserrent.

Comment le score est calculé

États de vérification

Chaque vérification individuelle renvoie l'un de quatre états :

Courbe de calibration

Les scores bruts de vérification sont passés à travers une courbe de calibration par morceaux qui mappe la plage théorique 0–100 sur une distribution pratique. La courbe est calibrée contre les données de benchmark des domaines scannés et est conçue pour que :

• Les victoires précoces sont récompensantes. Corriger un seul problème bloquant sur un site notant 20 produit une augmentation de score visible — pour que les premiers adoptants voient le progrès rapidement.
• La plage médiane a une séparation claire. Un score de 50 est significativement différent d'un score de 65.
• Le sommet est difficile à atteindre. Passer de 90 à 95 nécessite substantiellement plus d'investissement d'ingénierie que de passer de 40 à 55.

Cela suit le même principe utilisé par Google Lighthouse, qui calibre les scores contre les distributions du monde réel pour qu'ils reflètent des benchmarks pratiques plutôt que des maxima théoriques.

Bandes de score

Les labels et significations des bandes sont mis à jour dans le cadre de la refonte de la méthodologie pour décrire les résultats en termes de trouvabilité produit (par ex. « les agents peuvent trouver la plupart des produits mais peuvent échouer à la sélection de variante ») plutôt qu'en termes génériques de readiness antérieurs.

Comment nous gérons les cas limites

Protection bot et fallback navigateur

Si le crawler Serge est bloqué par un WAF ou une page de challenge, nous marquons les vérifications affectées comme « blocked » plutôt que « fail ». Les vérifications bloquées sont exclues du dénominateur du score — nous notons uniquement ce que nous pouvons réellement voir.

Lorsque le user-agent par défaut de SergeBot est silencieusement bloqué, nous récupérons les ressources clés en utilisant un user-agent navigateur standard. Cela nous permet de livrer de vrais résultats pour les sites derrière une protection bot CDN agressive. Le rapport de scan indique quand ce fallback a été utilisé.

Le blocage par protection bot est lui-même un constat. Si notre crawler déterministe ne peut pas atteindre votre site, les vrais agents IA utilisant des navigateurs headless peuvent faire face à des restrictions similaires. Cela est rapporté comme un constat avec des recommandations spécifiques pour permettre l'accès aux agents légitimes sans ouvrir la porte aux scrapers abusifs.

Sites sans e-commerce

La notation Serge est conçue pour les sites e-commerce — les sites qui existent pour permettre à un client de trouver un produit et de l'acheter. Si le scanner ne trouve pas de pages produit, pas de mécanique de panier et pas de prix, le score devient un cas dégénéré et nous le disons explicitement plutôt que d'inventer un nombre dénué de sens. Les sites non commerce ne sont pas notre ICP cible dans la cohorte actuelle.

Stabilité du score pendant la refonte

Comme la méthodologie est activement en cours de refonte, les scores générés pendant la période de transition peuvent évoluer à mesure que des vérifications sont ajoutées, supprimées ou repondérées. Une fois que la nouvelle méthodologie sera verrouillée, nous nous engageons à la garder stable pour qu'un score de 65 mesuré au mois A signifie la même chose qu'un score de 65 mesuré au mois B. Le progrès doit être mesuré contre une règle stable.

Travaux antérieurs et influences

La méthodologie de notation Serge s'inspire de pratiques établies dans plusieurs domaines :

Conception de la courbe de notation

• Google Lighthouse — Utilise des courbes log-normales calibrées contre les données de performance web du monde réel (HTTP Archive). Serge suit le même principe : les scores sont calibrés contre la distribution réelle des domaines scannés, pas contre des maxima théoriques.
• SSL Labs — Est passé de scores numériques 0–100 à des notes alphabétiques A–F pour la clarté de communication. A également été pionnier des plafonds durs : une seule défaillance critique remplace le score total.
• SecurityScorecard — Échelle logarithmique démontrant que le scanning externe et non intrusif peut produire des scores qui corrèlent avec les résultats du monde réel.

Protocoles et standards d'agents

Lorsque pertinent, la notation référence des standards et protocoles émergents qui aident les agents à interagir avec les plateformes web. Ce sont des signaux d'entrée pour la notation, pas des frameworks que nous avons inventés :

• WCAG 2.2 — Standards d'accessibilité pour les technologies d'assistance. Forte superposition avec ce dont les agents ont besoin pour interagir avec une page.
• Schema.org Product — Données produit structurées que les agents parsent pour comprendre l'inventaire, le prix, la disponibilité et les variantes.
• Robots Exclusion Protocol (RFC 9309) — Comment les sites déclarent les permissions de crawler.
• Model Context Protocol — Le standard ouvert d'Anthropic pour l'intégration agent-à-outil. Les vrais agents IA utilisent aujourd'hui des serveurs MCP de navigateur (Playwright MCP, Browser MCP, PageBolt) pour piloter des navigateurs.

Pourquoi le scanner est gratuit

Le scanner Serge suit un modèle prouvé par :

• HubSpot Website Grader (2007) — Outil gratuit de notation de site web qui a noté 4 millions de sites et est devenu le mécanisme principal de génération de leads de HubSpot, générant 40 000+ backlinks organiques.
• SecurityScorecard (2014) — Widget gratuit de score de sécurité utilisé par 880 000+ entreprises et qui a évolué vers $140M ARR en tant que générateur de leads définissant la catégorie.

Tous deux ont démontré qu'un outil de notation gratuit et partageable peut définir une catégorie et construire l'autorité par la transparence et la cohérence.

Limites

Nous croyons en la transparence sur ce que le score peut et ne peut pas vous dire.

Ce que le score mesure : Si les conditions structurelles pour qu'un agent IA trouve un produit et l'ajoute à un panier sont en place sur votre site, basé sur des signaux observables de l'extérieur.

Le score n'est pas une garantie. Un score élevé signifie que les conditions structurelles pour le succès de l'agent sont en place. Cela ne garantit pas que chaque agent sur chaque tâche réussira. Pour des données spécifiques et observables d'achèvement de tâche, utilisez Investigate Mode (exécuter de vrais agents contre votre site) ou le snippet de tracking passif (capturer les vraies sessions d'agents au moment où elles se produisent).

Le score est une mesure ponctuelle dans le temps. L'écosystème des agents évolue rapidement. Nous nous engageons à maintenir le framework à jour et, une fois la refonte terminée, à maintenir la stabilité du score pour que le progrès puisse être mesuré contre une règle stable.

Retours

Nous accueillons les retours sur la méthodologie. Si vous croyez qu'une vérification produit des résultats inexacts, s'il nous manque un signal important, ou si vous avez des recherches qui devraient informer le framework, contactez-nous.

L'objectif est d'avoir cela bien — pour les équipes e-commerce notées et pour les agents qui essaient de faire des achats sur leurs sites.