TL ; DR : Les agents IA lisent votre site à travers trois prismes distincts (captures d’écran, DOM brut et arbre d’accessibilité) et, la plupart du temps, les sites leur sont involontairement hostiles sur ces trois plans. Les correctifs recoupent le travail d’accessibilité et de Core Web Vitals que vous devriez déjà mener. Voici l’ordre de priorité, l’audit de 5 minutes et la boucle de mesure que vous pouvez lancer dès aujourd’hui.
Je travaillais sur notre outil « agent-ready » il y a quelques semaines. L’idée était de soumettre de vrais sites clients à un agent basé sur Playwright et d’observer sa manière de les utiliser. Je l’ai donc envoyé sur notre propre page d’accueil, celle que j’avais mise en ligne mille fois, et je lui ai demandé de trouver la tarification.
Il a cliqué le mauvais CTA. Puis il a tenté de cliquer sur un bouton qui n’en était pas un (un <div> stylé que nous avions bricolé à la hâte). Finalement, il a abandonné et m’a demandé où se trouvait la page de prix.
Je savais pourtant que notre site affichait une navigation secondaire au survol. Un humain déplace son curseur, le menu apparaît, problème réglé. L’agent, lui, ne disposait que d’une capture d’écran de l’état « au repos ». Aucun curseur à déplacer. Pour lui, la nav uniquement au survol n’existait tout simplement pas.
C’est ce jour-là que j’ai cessé de voir les agents IA comme des crawlers plus malins et que j’ai commencé à les considérer comme un nouveau type de visiteur aux limites étranges. (Parenthèse : je pensais depuis des mois qu’ils fonctionnaient comme Googlebot avec quelques étapes en plus. Je me suis trompé pendant les six premiers mois de l’an dernier.) Ce qui suit est le fruit de mes découvertes depuis, essentiellement en cassant des choses et en observant les réactions des agents.
Un agent IA qui arrive sur votre page d’accueil ne crawle pas pour un index de recherche. Il essaie d’accomplir la tâche qu’un humain lui a confiée : réserver le vol, comparer les offres, ajouter l’article au panier. Il dispose de minutes, pas d’heures. Et chaque clic inutile coûte des jetons d’inférence à l’utilisateur.
Cela change la donne en matière de design. Un bot de recherche peut échouer silencieusement et vous ne le saurez jamais. Un agent échoue bruyamment, devant un utilisateur payant, et la fois suivante cet utilisateur lui demandera d’éviter votre site. Les moteurs de recherche dotés d’IA commencent à se comporter de la même façon. Si leur crawler ne peut extraire une réponse fiable de votre page, la réponse ira à celui qui est lisible. Les clics que vous receviez depuis les SERP sont remplacés par des citations dans un résumé IA, et les citations se gagnent par la lisibilité, pas par le budget pub.
Pour une analyse plus détaillée du volet « IA comme canal de découverte », le pilier silo « ask engine optimization » couvre directement l’aspect recherche. Cet article traite de l’autre moitié : ce qui se passe lorsqu’un agent essaie réellement d’utiliser votre site.
C’est la partie qu’aurais aimé qu’on m’explique il y a un an. Les agents ne voient pas les pages web d’une seule manière. Il en existe trois, et les grands fournisseurs les combinent différemment.
« Les agents peuvent consulter votre site de 3 façons principales : les captures d’écran, le HTML brut et l’arbre d’accessibilité. L’arbre d’accessibilité est une API native du navigateur qui distille le DOM en l’essentiel : rôles, noms et états des éléments interactifs. Pour un agent IA, c’est une carte haute fidélité qui ignore le “bruit” visuel du CSS pour se concentrer sur l’utilitaire pur. »
— Kasper Kulikowski & Omkar More, web.dev : Build agent-friendly websites
Voici, début 2026, la répartition par fournisseur. Le « computer-use » d’Anthropic fonctionne uniquement par captures d’écran. Claude voit une image 1024×768, raisonne sur les coordonnées pixels et demande au harnais de déplacer la souris. Aucun DOM côté Anthropic. L’Operator (CUA) d’OpenAI combine captures, DOM et arbre d’accessibilité, même si la communication d’OpenAI insiste sur la boucle screenshot et que la superposition DOM apparaît surtout dans le reverse-engineering tiers. Le Project Mariner de Google lit les pixels et le DOM sous-jacent. Les frameworks basés sur Playwright comme browser-use privilégient d’abord l’arbre d’accessibilité et ne repassent aux captures que si nécessaire.
L’économie compte davantage que l’architecture. Un instantané d’arbre d’accessibilité pèse 2 à 5 KB. La capture d’écran équivalente dépasse 100 KB. Soit un coût par étape 20 à 50 fois supérieur en jetons d’inférence. Les agents capables de lire l’arbre d’accessibilité ont tout intérêt à le faire. Les sites qui produisent un arbre propre sont utilisés. Les autres se retrouvent avec des captures coûteuses, plus d’échecs de clics et, à terme, sont zappés.
Vous pouvez voir l’arbre d’accessibilité de votre site dès maintenant. Ouvrez Chrome DevTools, onglet Accessibility, cochez « Enable full accessibility tree ». C’est à peu près ce qu’un agent comme browser-use récupérera. Chrome masque par défaut les nœuds ignorés et les nœuds génériques sans nom, ce qui est pratique : ce sont justement les éléments qui posent problème aux agents.
Les citations sont les nouveaux clics, du moins pour certaines requêtes. D’après la synthèse cross-plateforme de Profound, Wikipédia représente 47,9 % des sources top 10 de ChatGPT, Reddit 21 % des Google AI Overviews et 46,7 % de Perplexity. Les pourcentages bougent sans cesse (selon le tracking de Leapd, la part Reddit de ChatGPT est passée d’environ 60 % à 10 % en six semaines après un simple paramètre Google), mais la tendance se confirme : les moteurs IA privilégient le contenu qu’ils peuvent analyser avec confiance et écartent le reste.
« Certains LLM, comme ChatGPT et Claude, n’exécutent pas JavaScript (contrairement à Gemini), ce qui rend le Server-Side Rendering (SSR) crucial pour que le contenu important apparaisse dans leurs réponses. »
— Aleyda Solis, AI Search : Where Are We & What Can We Do About It?
Cette seule phrase est plus concrète que la plupart des conseils AI-SEO que j’ai lus. Si votre contenu clé est rendu côté client, ChatGPT et Claude ne le verront pas. Gemini, si. Quoi qu’on en pense, c’est une exigence technique vérifiable, pas une intuition. Notre article sur le playbook des crawlers IA détaille quels crawlers exécutent JavaScript et lesquels non.
Soyons honnêtes sur ce que nous ignorons. Aucune étude publique ne corrèle directement les scores d’accessibilité et les taux de citation IA. Le mécanisme est défendable (l’arbre d’accessibilité sert aussi aux lecteurs d’écran), mais le lien empirique n’est pas démontré. Le meilleur proxy est le résumé d’accessibility.works d’une étude sur 10 000 sites montrant que les sites conformes WCAG généraient 23 % de trafic organique en plus et se positionnaient sur 27 % de mots-clés supplémentaires. La méthodologie est peu documentée, donc je prends cela comme indicatif, pas décisif.
Vous verrez quantité de listes « 8 choses » dans ce domaine. La liste est utile pour s’organiser ; elle cesse de l’être si vous traitez les huit items comme également importants. Ils ne le sont pas. Voici la comparaison.
| Signal | Ce qu’un agent voit si c’est réussi | Ce qui casse si c’est raté | Effort |
|---|---|---|---|
| Éléments sémantiques natifs | <button>, <a>, <h1> apparaissent dans l’arbre a11y avec leurs rôles implicites |
Les <div> stylés en boutons disparaissent complètement de l’arbre a11y |
Faible |
| Noms accessibles sur les champs | « input, type=email, label=‘Adresse email’ » | « input, type=text » (un placeholder seul ne crée pas de nom) | Faible |
| Cibles interactives visibles | Boutons > ~8 px² (plancher empirique web.dev) et idéalement 24×24 px CSS (WCAG 2.5.8 AA) | Les modèles de vision filtrent les petites cibles ; les agents à coordonnées souris les ratent | Faible |
| Mise en page stable (CLS bas) | Les coordonnées de clic tombent sur le bon élément | Images lazy-load décalent la page ; l’agent clique le mauvais bouton | Moyen |
| Contenu rendu serveur | ChatGPT et Claude voient le HTML complet au premier fetch | Le contenu hydraté seulement client est invisible pour les crawlers sans JS | Moyen-élevé |
| Hiérarchie de titres | Un <h1>, puis <h2>/<h3> imbriqués |
Titres visuels en <p> = pas d’outline pour l’agent |
Faible |
| Pas de superpositions fantômes / pièges de focus | Les clics atteignent l’élément visible | Calques transparents interceptent les clics ; l’agent reste bloqué | Moyen |
| URLs et formulaires prévisibles | L’agent peut reprendre après une nav ; les champs s’auto-décrivent | Routes SPA qui mangent l’historique : les tâches multi-étapes déraillent | Moyen |
Deux signaux dominent. Les éléments sémantiques natifs et les noms accessibles sont la base. Si vous ratez ça, le reste est inutile. Sur les quelques centaines de sites passés par notre vérification agent-ready depuis le lancement, l’échec le plus courant est exactement celui-ci : un CTA construit en <div> stylé, donc invisible dans l’arbre d’accessibilité. Environ la moitié des homepages auditées en ont au moins un. Le plancher de 8 px² vient d’observations (web.dev), pas d’une limite architecturale : les encodeurs CLIP utilisent en réalité des patchs de 14×14 ou 16×16 px, donc voyez-y un minimum raisonnable, pas un chiffre magique.
C’est ce que je ne vois jamais dans les autres articles sur l’« agent-readiness ». La plupart vous livrent une check-list de 8 à 30 points et vous laissent vous débrouiller. Voici ce que je fais vraiment quand j’ai 5 minutes entre deux réunions.
Minute 1. Lancez notre agent-ready check gratuit. Il envoie votre homepage à un agent Playwright et vous remonte les problèmes : <div role="button"> sans tabindex, input caché qui piège le focus, CTA visible en capture mais absent de l’arbre d’accessibilité… C’est l’outil que Lida et moi avons publié après l’épisode « GPT ne voit pas nos hovers » (nous n’étions pas d’accord sur le timing ; elle voulait des données plus propres ; j’ai sorti la version brute). C’est gratuit, sans e-mail.
Minute 2. Ouvrez votre site dans Chrome, DevTools, volet Accessibility, arbre complet. Repérez les nœuds rôle « generic » sans nom. Chacun est un endroit où l’agent doit deviner.
Minute 3. Lancez le vibe-coded scanner sur la même URL. C’est un scan qualité code que nous avons créé pour piéger les patterns que Cursor, Copilot et Lovable génèrent par défaut : <div onClick> en guise de bouton, labels manquants, titres déguisés en paragraphes. (Je l’ai fait parce que la moitié des sites qu’on audite sont maintenant générés par IA, et les générateurs ne maîtrisent pas encore le HTML sémantique.)
Minute 4. Lancez un audit Lighthouse. Notez le score CLS : >0,1 = limite ; >0,25 = l’agent rate régulièrement ses clics. Notez aussi le score accessibilité, car le même audit détecte les labels manquants et les problèmes de contraste qui nuisent aux lecteurs d’écran et aux agents.
Minute 5. Choisissez le pire problème parmi ces quatre rapports et notez-le. Demain, corrigez juste celui-là. N’essayez pas de tout régler d’un coup.
Cinq minutes, c’est le vrai budget de la plupart des responsables marketing. Si vous en avez plus, tant mieux. Sinon, cette boucle suffit à révéler le plus gros problème, généralement tout ce qu’il vous faut savoir.
Trois patterns expliquent la majorité des échecs que je vois. Le premier : le <div> stylé en bouton. Il ressemble à un bouton, a un état hover, réagit au clic, mais n’est pas un bouton pour l’arbre d’accessibilité.
« N’utilisez pas un
<div>,<span>ou autre élément non interactif. Si vous ne pouvez pas y accéder au clavier via Tab, c’est probablement une très mauvaise idée. »— Adrian Roselli, Links, Buttons, Submits, and Divs, Oh Hell
Roselli écrivait cela en 2016, une décennie avant qu’on parle « d’agents IA ». L’heuristique Tab-clavier qu’il décrit colle aujourd’hui à la lisibilité agent : si le clavier ne peut y accéder, l’arbre d’accessibilité ne l’expose pas, et un agent Playwright ne le voit pas. L’addition d’une décennie de boutons en <div> arrive.
Le deuxième pattern : l’instabilité de layout. Nous l’avons vécu lors de la migration .io → .com. Des images héros lazy-load déplaçaient le bouton « Get started » de 40 px environ 800 ms après le rendu. Les humains ne voyaient presque rien. Les agents Playwright repéraient le bouton à la position initiale, attendaient, puis cliquaient l’espace vide. Ce n’est pas théorique : issue #6238 de Playwright documente ce problème, toujours ouvert. Le CLS Lighthouse est mon proxy : >0,1, méfiance.
Le troisième pattern : les overlays fantômes. Bannières cookies qui ne se ferment pas vraiment, popups RGPD laissant un backdrop transparent, widgets intercom en z-index 9999 au-dessus de votre CTA. Chacun intercepte les clics destinés à l’élément visible dessous. Web.dev les mentionne explicitement, et notre vibe-coded scanner les détecte.
« Ces dispositifs s’appuient sur l’Accessibility Tree — le mécanisme utilisé par les ordinateurs pour permettre aux technologies d’assistance de lire et d’interpréter l’interface — pour fonctionner. En reposant sur un balisage éprouvé et largement supporté, nous rendons notre travail polyvalent et robuste. »
— Eric Bailey, Truths about digital accessibility
Bailey écrivait cela en 2019, à propos des lecteurs d’écran. La phrase que je retiens est « le mécanisme qu’utilisent les ordinateurs ». Il définit l’arbre d’accessibilité comme une interface programmatique pour les machines, pas seulement pour les personnes handicapées. L’arrivée des agents IA fusionne trois métiers (accessibilité, crawlabilité SEO, lisibilité agent) en un : produire une description machine-lisible de votre interface.
Un traitement plus long du versant SEO figure dans notre pilier accessibilité-pour-le-SEO. En bref, les mêmes correctifs (HTML sémantique, noms accessibles, layout stable) déplacent trois aiguilles d’un coup.
Si vous ne faites rien d’autre de cet article, faites ceci dans cet ordre.
<div> et <span> boutons par des <button>. Effet maximal, coût minimal. Ce seul changement vous fait passer d’« invisible » à « visible » pour les agents a11y-tree first comme browser-use, Mariner et les crawlers Playwright.<label for> à chaque champ. Un placeholder n’est pas un nom accessible. Sans label, l’agent voit un input texte anonyme, point.<h1> par page, <h2> pour les sections. Ne stylisez pas un <p> en titre.
J’ai vu des équipes passer deux semaines sur un fichier llms.txt avant de corriger leur bouton checkout en <div>. L’ordre est inversé.
Vous avez expédié les correctifs. Et après ?
Pour la stabilité de layout, l’audit Lighthouse est la mesure fiable la moins chère. Testez la même URL avant/après, observez CLS, accessibilité et INP évoluer. (Quand nous avons remplacé nos <div> boutons sur les pages marketing, notre score a11y Lighthouse a bondi de 14 pts et le CLS est passé de 0,18 à 0,04. Ce n’est pas un essai contrôlé, mais c’est typiquement le genre d’impact réalisable en une après-midi.)
Pour la lisibilité agent, relancez l’agent-ready check. L’outil donne un score de parseabilité et la liste des CTAs atteignables ou non. La métrique que je surveille : « CTAs identifiés ». Si ce n’est pas 100 %, l’agent devine encore quelque part.
Pour les citations IA (le vrai KPI SEO), utilisez notre backlink checker pour suivre les mentions dans les résumés IA. Les citations de ChatGPT, Perplexity ou AI Overviews ressemblent à des backlinks, juste depuis de nouvelles sources. Si vos correctifs portent, vous verrez ces citations apparaître en semaines, pas en jours. Notre méthodologie d’audit de visibilité IA détaille cette boucle longue.
Je signale la stat de Wil Reynolds relayée par Orbit Media, « 0,8 % de trafic, 10 % de leads ». C’est réel, sourçable, utile. Mais c’est la donnée d’une entreprise sur une période donnée, et Reynolds précise que ce n’est pas universel. Je le prends comme preuve que le trafic IA convertit mieux que sa part, pas comme un multiplicateur garanti. Si votre trafic IA convertit 5× votre orga moyen, c’est significatif. Sinon, le multiplicateur ne s’applique pas.
WebMCP est la spéc à surveiller. Elle permet à un site d’enregistrer des outils JavaScript que les agents IA peuvent appeler directement, faisant de la page un serveur Model Context Protocol. Chrome 146 Canary a livré un aperçu sous flag. Edge 147 a suivi en mars 2026. Le brouillon W3C Community Group date du 23-04-2026.
Je suis fan, mais lucide sur le timing. La spéc précise : « Ce n’est pas un standard W3C ni sur la track ». Aucun grand vendeur LLM n’a documenté l’usage de WebMCP. Cloudflare a trouvé moins de 15 sites adoptant les MCP Server Cards. Horizon 2-5 ans minimum.
« Le navigateur web est conçu pour les humains et les développeurs, pas pour les systèmes IA agents. La plupart du contenu est structuré pour la consommation visuelle, pas programmatique, avec des éléments dynamiques, des mises en page complexes et des composants interactifs qui résistent au parsing simple. »
— Cobus Greyling, The Future of Web Browsing AI Agents
Pour Greyling, la check-list agent-friendly (cet article, en somme) est un contournement d’une incompatibilité plus profonde que des standards comme WebMCP veulent résoudre. Il a peut-être raison. Je ne sais pas si WebMCP gagnera, si llms.txt ou NLWeb le feront, ou si un futur standard absorbera tout. Ce que je sais, c’est que la pyramide de priorité est le travail à faire maintenant en attendant que la couche standards se stabilise. Notre vision : agentic SEO workflows.
Un site lisible et utilisable de façon fiable par des agents IA (Claude computer-use, OpenAI Operator, Project Mariner, crawlers Playwright) en plus des humains. L’essentiel : les éléments interactifs doivent se dévoiler clairement via l’arbre d’accessibilité du navigateur, la mise en page ne doit pas bouger pendant l’action de l’agent, et le contenu important doit être rendu serveur pour que les crawlers sans JavaScript le lisent.
Ils utilisent une ou plusieurs des trois entrées : captures d’écran, HTML brut ou arbre d’accessibilité. Les agents « screenshot only » (computer-use d’Anthropic) raisonnent en coordonnées pixels et ratent tout sous 8 px² empirique. Les agents DOM-aware (Project Mariner, Operator) y superposent les données élément. Les agents « accessibility-tree first » (browser-use, la plupart des crawlers Playwright) disposent d’une carte structurelle propre mais ratent ce qui n’est pas exposé sémantiquement.
Bing confirme que schema aide Copilot à comprendre. Google reconnaît que les données structurées donnent un avantage en résultats. Les preuves directes d’un impact sur la citation IA sont mixtes : une étude ne voit aucune corrélation, une autre trouve 61,7 % de citation pour les schemas riches en attributs. Considérez-le comme utile côté recherche IA, pas comme un multiplicateur garanti.
Un format proposé (similaire à robots.txt) qui indique aux crawlers IA où trouver votre contenu important sous forme propre. Plus de 844 000 sites l’avaient publié en octobre 2025. L’adoption est élevée, la consommation faible : John Mueller et Gary Illyes (Google) disent qu’aucun gros système IA ne l’utilise en signal opérationnel. À faire si vous avez 10 minutes ; pas prioritaire sur vos boutons en <div>.
Le plus rapide : audit de 5 minutes : lancez notre agent-ready check, ouvrez l’arbre Accessibility dans DevTools, un rapport Lighthouse et un scan vibe-coded. Ces quatre points font remonter le plus gros souci. Corrigez-le avant d’attaquer le suivant.
Les agents IA lisent votre site via captures, DOM et arbre d’accessibilité, selon des mixes propres à chaque fournisseur. La majorité des correctifs sont des ajustements d’accessibilité que vous devriez déjà faire : éléments sémantiques natifs, noms accessibles, layout stable, rendu serveur. La couche standards (WebMCP, llms.txt, NLWeb) évolue lentement ; les correctifs peu glamour sont urgents.
Lancez notre agent-readiness check gratuit pour mesurer la lisibilité de votre site pour ChatGPT, Claude et Perplexity. Il vous dira quels CTAs l’agent a manqués, quels boutons ont disparu de l’arbre d’accessibilité et quels décalages mangent les clics. C’est l’outil que j’aurais aimé avoir le jour où GPT n’a pas vu nos états au survol.
no credit card required
No related articles found.