Pourquoi cet audit existe
Un site moderne n’est plus seulement visité par des humains et parcouru par des moteurs. Il est aussi interprété par des agents IA qui peuvent analyser une page, choisir une action, cliquer, remplir un formulaire, comparer des options ou préparer une recommandation.
Cette couche change le problème. Un site peut être bien référencé, visuellement correct et pourtant fragile pour un agent. Le bouton principal peut être rendu comme un faux élément interactif. Un formulaire peut être visible, mais mal exposé dans l’arbre d’accessibilité. Un composant peut bouger après hydratation. Une action peut être claire pour un humain, mais ambiguë dans le DOM.
L’audit de navigabilité agentique mesure précisément cet écart : ce que l’interface semble permettre, ce que le HTML expose réellement, ce que l’arbre d’accessibilité rend compréhensible, et ce qu’un agent peut exécuter avec fiabilité.
Ce chantier s’appuie sur une évolution publique du Web. Google décrit désormais les agents comme un nouveau type de visiteur capable d’interpréter, de planifier et d’exécuter des actions. Sa documentation recommande des sites sémantiques, accessibles, stables et cohérents entre rendu visuel, DOM et accessibility tree : Build agent-friendly websites.
Le score de préparation agentique
Pour les organisations qui veulent une première lecture avant mandat, Pagup expose aussi un score de préparation agentique. Il ne remplace pas l’audit, mais il rend le référentiel public : stabilité DOM, cohérence visuel / accessibilité, sémantique actionable, risque d’hydratation et déterminisme des parcours.
Ce que Lighthouse mesure, ce que l’audit Pagup ajoute
L’arrivée d’Agentic Browsing dans Lighthouse change le vocabulaire du marché. Elle donne aux équipes un premier ensemble de signaux observables : accessibilité, stabilité, noms programmatiques, llms.txt, WebMCP et qualité de certains éléments interactifs.
Mais Lighthouse ne remplace pas l’audit Pagup. Il vérifie des signaux ponctuels. L’audit de navigabilité agentique vérifie des parcours complets : comprendre l’offre, suivre le bon chemin, choisir un CTA, remplir un formulaire, interpréter une confirmation et revenir au bon contexte.
C’est pourquoi l’audit distingue trois niveaux :
- signal technique : ce que Lighthouse ou un outil similaire peut détecter ;
- risque de parcours : ce qui peut empêcher un agent d’accomplir une tâche réelle ;
- risque de représentation : ce qui peut pousser un agent à mal qualifier l’organisation, son offre ou ses preuves.
À lire en complément : Audit Lighthouse Agentic Browsing : ce que votre site réussit, manque ou ne mesure pas et Matrice Lighthouse Agentic Browsing vs score Pagup.
Ce que l’audit mesure
L’audit ne cherche pas à deviner si un site « plaira » à une IA. Il vérifie des propriétés techniques observables.
1. Stabilité DOM et stabilité visuelle
Nous comparons l’état initial de la page, son état après hydratation et son état après interaction. L’objectif est de repérer les changements qui peuvent déplacer, masquer ou redéfinir une action critique.
Un bouton qui change de position entre l’identification et le clic n’est pas seulement un problème UX. C’est un risque d’exécution. Chrome documente d’ailleurs la stabilité visuelle comme une condition importante pour les agents qui s’appuient sur des captures ou des interactions coordonnées : Layout stability.
2. Cohérence entre screenshot, DOM et arbre d’accessibilité
Un agent moderne ne lit pas seulement le texte. Il croise plusieurs signaux : rendu visuel, structure HTML, DOM, noms accessibles, rôles, états et relations.
L’audit vérifie donc si ces canaux racontent la même chose. Un élément qui ressemble à un bouton doit être un bouton. Un champ visible doit avoir un nom accessible. Un CTA placé dans une carte produit doit être relié sans ambiguïté au bon produit.
3. Sémantique actionable
Nous vérifions la qualité des éléments d’action : <button> pour les actions, <a> pour les navigations, <label> lié aux champs, attributs name, textes de CTA explicites, états aria-expanded ou aria-current quand ils sont nécessaires.
L’objectif est simple : un agent doit comprendre non seulement qu’un élément peut être activé, mais aussi ce que cette activation déclenche.
4. Risque d’hydratation
Les interfaces sur-hydratées peuvent créer une divergence entre ce que le serveur livre, ce que le navigateur rend et ce que JavaScript transforme ensuite. L’audit repère les contenus critiques injectés tardivement, les actions absentes du HTML initial, les menus instables, les formulaires dépendants d’un état client fragile et les erreurs qui réduisent la prévisibilité de l’interface.
Cette dimension est particulièrement importante dans une architecture web machine-first, où le contenu et les actions critiques doivent être disponibles avant les enrichissements JavaScript.
5. Qualité de la carte d’accessibilité
L’accessibilité ne sert pas seulement les humains qui utilisent des technologies d’assistance. Elle force aussi l’interface à être nommée, structurée et intentionnelle.
Nous auditons les boutons sans nom, les champs sans label, les modales mal reliées, les erreurs de formulaire non associées, les menus ambigus et les éléments interactifs cachés de l’arbre d’accessibilité.
6. Déterminisme interactionnel
Un agent doit pouvoir exécuter une tâche sans perdre son contexte. L’audit examine donc la clarté des étapes, les confirmations, les erreurs, les redirections, les états désactivés, les actions irréversibles et la relation entre objectif, interface et résultat.
Un bon parcours agentique n’est pas seulement cliquable. Il est prévisible.
7. Hiérarchie visuelle et affordances
La taille, la proximité, le contraste, l’ordre visuel et la cohérence des boutons orientent le comportement d’un agent. Nous vérifions si les actions principales, secondaires et dangereuses sont suffisamment distinguées, et si les éléments cliquables ressemblent réellement à des éléments cliquables.
8. Découvrabilité machine et préparation WebMCP
L’audit vérifie aussi les points d’entrée machine : sitemap, robots, données structurées, surfaces llms.txt, maillage interne, hiérarchie des ressources et préparation éventuelle à WebMCP.
WebMCP reste expérimental, mais Chrome le présente comme une manière d’exposer des outils structurés aux agents pour qu’ils puissent agir avec plus de vitesse, de fiabilité et de précision : WebMCP early preview.
Livrables typiques
Selon le périmètre, l’audit peut inclure :
- une cartographie des parcours agentiques critiques ;
- une comparaison entre HTML initial, DOM hydraté, rendu visuel et arbre d’accessibilité ;
- une matrice de risques par gabarit ;
- une liste priorisée des éléments non actionnables ou ambigus ;
- des recommandations HTML, ARIA, CSS et front-end ;
- une évaluation du risque d’hydratation ;
- un plan de correction par priorité ;
- des pistes de tests automatisés pour éviter les régressions.
Quand cet audit devient prioritaire
Cet audit devient pertinent quand :
- votre site possède des formulaires, tunnels, filtres, réservations, paniers, configurateurs ou interfaces complexes ;
- vous préparez une refonte et voulez éviter de reconstruire une interface fragile pour les agents ;
- votre site dépend fortement de JavaScript côté client ;
- vos parcours critiques changent selon le chargement, la taille d’écran ou l’état utilisateur ;
- vous voulez savoir si votre site est réellement prêt pour le Web agentique, au-delà d’un simple fichier
llms.txt.
Ce que ce service n’est pas
Ce service n’est pas une promesse de classement SEO. Il ne prétend pas prédire comment chaque agent du marché se comportera.
Il ne remplace pas non plus un diagnostic complet de lisibilité numérique. Il traite une couche précise : la capacité opérationnelle du site à être compris, parcouru et manipulé par des agents.
Prochaine étape
Si le problème semble large, le bon point d’entrée reste le diagnostic stratégique de lisibilité numérique. Si le risque est déjà localisé dans l’interface, les formulaires, les composants ou l’architecture front-end, vous pouvez ouvrir un brief orienté navigabilité agentique.