Intelligence Artificielle
Pour la semaine du 30 mai au 5 juin 2026, Cloudflare Radar a mesuré que 57,2 % des requêtes HTTP vers du contenu HTML provenaient de bots automatisés, contre 42,8 % d’humains. Le PDG de Cloudflare, Matthew Prince, prévoyait ce basculement pour 2027 : il est arrivé avec plus d’un an d’avance (Source : Cloudflare Radar, via Search Engine Journal, juin 2026). Une part croissante de ce trafic automatisé, ce sont des agents IA (ChatGPT Atlas, Copilot, Gemini, Claude, etc.) qui naviguent pour le compte de vrais utilisateurs, et ces agents ne lisent pas votre page comme un humain : ils lisent en priorité l’arbre d’accessibilité, la même structure qui sert les lecteurs d’écran depuis vingt ans.
L’arbre d’accessibilité est la version simplifiée du DOM que le navigateur expose aux technologies d’assistance et, désormais, aux agents IA : elle indique le rôle, le nom et l’état de chaque élément interactif d’une page.
Au Québec, 21 % des personnes de 15 ans et plus vivent avec une incapacité, soit environ 1,4 million de personnes (1 422 020 précisément) (Source : Office des personnes handicapées du Québec, d’après l’Enquête canadienne sur l’incapacité 2022 de Statistique Canada). L’arbre d’accessibilité sert donc désormais deux publics à la fois : les personnes qui utilisent une technologie d’assistance, et une majorité grandissante de trafic automatisé qui décide, à partir de cette même structure, si votre site peut être compris, cité ou utilisé.
L’essentiel à retenir
- L’arbre d’accessibilité est la structure que le navigateur génère à partir du DOM ; les agents IA s’en servent pour comprendre et agir sur une page, exactement comme les lecteurs d’écran.
- Google a lancé en juin 2026 un audit Lighthouse dédié, Agentic Browsing, avec un test qui vérifie littéralement si votre arbre d’accessibilité est bien formé.
- Un <div> cliquable sans href ni rôle bloque à la fois Googlebot et les agents IA de la même manière.
- Le web devient globalement plus difficile à lire pour les machines : le rapport WebAIM Million 2026 signale la première régression en six ans.
Sommaire
Qu'est-ce que l'arbre d'accessibilité ?
L'arbre d'accessibilité est une version simplifiée et filtrée du DOM (Document Object Model) : la représentation interne que le navigateur construit à partir de votre code HTML lorsqu'il charge une page) .
Le navigateur convertit d'abord votre balisage HTML en arbre DOM, puis en dérive un second arbre, plus restreint, exposé via l'API d'accessibilité du système d'exploitation. C'est cet arbre que consultent aussi bien un lecteur d'écran comme NVDA ou VoiceOver qu'un agent IA piloté par un modèle de langage.
Les 4 propriétés d'un nœud (nom, description, rôle, état)
L'arbre d'accessibilité est composé de nœuds, chacun représentant un élément de la page qui a un sens pour un lecteur d'écran ou un agent IA (un titre, un lien, un bouton, un champ de formulaire, une région de navigation).
Chaque nœud porte les quatre propriétés suivantes :
- le nom (comment désigner l'élément),
- la description (un complément facultatif),
- le rôle (bouton, champ, liste)
- l'état (coché, déplié).
L'arbre d’accessibilité indique aussi ce qui peut être fait avec un nœud : un lien peut être suivi, un champ peut recevoir du texte. C'est exactement l'information dont un agent a besoin pour agir, pas seulement pour lire.
L'arbre exclut aussi tout ce qui n'a pas d'utilité fonctionnelle : les <div> purement décoratifs, les éléments masqués via aria-hidden ou display:none, les images sans texte alternatif qui n'apportent rien au sens du contenu. C'est cette exclusion qui fait la différence avec le DOM complet : là où le DOM contient tout, l'arbre d'accessibilité ne garde que ce qui est réellement utile pour comprendre et agir sur la page.
Arbre d'accessibilité vs arborescence de site : ne pas confondre
Il existe une confusion fréquente : l'arbre d'accessibilité n'est pas l'arborescence de navigation d'un site web. L'arborescence de site désigne l'organisation hiérarchique de vos pages, un concept d'architecture de l'information et de SEO. L'arbre d'accessibilité décrit la structure sémantique d'une seule page, à l'usage des technologies d'assistance et, désormais, des agents.
Pourquoi les agents IA lisent l'arbre d'accessibilité plutôt que votre page ?
Un agent qui pilote un navigateur peut comprendre une page de trois façons :
Un agent IA peut lire le HTML brut
Un agent qui doit résumer un article de blog statique peut se contenter de récupérer le code source HTML et d'en extraire le texte, sans avoir besoin d'interagir avec la page. C'est rapide et peu coûteux, mais ça tombe vite à plat sur un site fortement JavaScript : sur une page produit qui charge son contenu dynamiquement (comme beaucoup de fiches e-commerce en React), le HTML brut récupéré au premier chargement peut être quasiment vide, avant même que le prix ou la description n'apparaissent.
Un agent IA peut analyser une capture d'écran avec un modèle de vision,
Le Computer-Using Agent d'OpenAI, qui alimente Operator, illustre cette approche vision-first. Pour réserver une table dans un restaurant en ligne, l'agent prend une capture d'écran de la page. Il repère visuellement le bouton « Réserver », clique aux coordonnées correspondantes, puis reprend une capture pour valider le résultat. La méthode fonctionne même sur un site mal codé, mais elle reste lente et peut se tromper si deux boutons se ressemblent visuellement, un problème que l'arbre d'accessibilité résout par nature grâce à ses rôles et noms explicites.
Ou alors un agent IA peut lire l'arbre d'accessibilité.
Le choix n'est pas neutre.
Playwright MCP (Microsoft), un outil utilisé pour laisser un modèle piloter un navigateur, fonctionne exclusivement à partir de l'arbre d'accessibilité, sans modèle de vision, l'outil indiquant lui-même qu'un instantané d'accessibilité est préférable à une capture d'écran.
Certains agents combinent les deux approches.
Fait révélateur : même OpenAI, malgré son approche vision-first, indique dans sa documentation développeurs que ChatGPT Atlas utilise les balises ARIA, les mêmes rôles et labels qui servent les lecteurs d'écran, pour interpréter la structure d'une page, et recommande d'améliorer l'accessibilité d'un site pour que l'agent le comprenne mieux (Source : OpenAI, Publishers and Developers FAQ, via Search Engine Journal).
Deux raisons expliquent ce choix : le coût (une capture d'écran consomme un grand nombre de jetons pour être interprétée) et la fiabilité (un modèle de vision doit deviner quels pixels forment un bouton cliquable, alors que l'arbre l'indique explicitement, avec un rôle et un nom).
Un consultant SEO a publié en juin 2026 un banc d'essai personnel comparant ces méthodes sur ses propres pages (méthodologie déclarée, à considérer comme indicatif plutôt que comme norme universelle) :
| Méthode | Coût approximatif | Fiabilité observée |
| Capture d'écran (vision) | ~50 000 jetons/page | ~40 %, limitée au contenu visible sans défilement |
| HTML brut (DOM) | ~8 000 jetons/page | Élevée sur pages statiques, faible sur pages fortement JavaScript |
| Arbre d'accessibilité filtré | ~15 000 jetons/page | ~90 %, structuré et adapté à la fenêtre de contexte |
| Markdown | ~5 800 jetons/page | Élevée pour le contenu texte, mais aveugle aux éléments interactifs |
(Source : banc d'essai John McAlpin, juin 2026, sur Claude Sonnet 4)
Cette dernière ligne est importante : un export markdown propre, comme ceux que certains fournisseurs génèrent désormais en périphérie de réseau, reste une bonne façon de faire lire du contenu à un agent, mais il ne peut pas lui dire qu'un contrôle est un bouton, s'il est désactivé, ou lui donner quelque chose à cliquer.
Il permet à l'agent de lire la page, pas de l'utiliser. Et contrairement à l'arbre d'accessibilité, une copie markdown est un document séparé de la page réelle, qui peut diverger de ce que voient les humains, volontairement ou par dérive au fil du temps.
Pourquoi intégrer l'arbre d'accessibilité à votre stratégie SEO
Trois raisons concrètes justifient d'en faire un chantier prioritaire, pas seulement une bonne pratique de conformité. En effet, cet élément est a prendre en considération dans tous vos prochains audit GEO.
Google en a fait un signal explicite de visibilité pour la recherche agentique.
En juin 2026, Chrome for Developers a lancé une nouvelle catégorie d'audits Lighthouse, « Agentic Browsing », qui évalue si un site est compatible avec les agents IA.
Un des tests vérifie littéralement si l'arbre d'accessibilité est bien formé, et si chaque élément interactif possède un nom programmatique
(Source : Chrome for Developers, « Un kit d'outils pour rendre votre site Web compatible avec les agents », juin 2026).
Ce n'est plus un simple critère de conformité : c'est un audit technique nommé, avec un pass/fail précis.
Un axe de différenciation pour l'instant peu disputé.
Le rapport WebAIM Million 2026, qui analyse un million de pages d'accueil, montre que 95,9 % d'entre elles comportent au moins une non-conformité WCAG 2 détectable, avec une moyenne de 56,1 erreurs par page, en hausse pour la première fois en six ans (Source : WebAIM, « The WebAIM Million 2026 », webaim.org/projects/million/).
Avec 95,9 % des pages d'accueil non conformes, la probabilité que vos concurrents directs n'aient pas encore corrigé leur arbre d'accessibilité est statistiquement écrasante : c'est un chantier que la grande majorité du marché n'a pas encore entamé.
Un même défaut de code bloque à la fois le SEO classique et le SEO agentique.
Un lien codé en <div onclick=""> plutôt qu'en <a href=""> n'apparaît dans l'arbre d'accessibilité qu'avec un rôle générique, sans chemin de navigation exploitable.
Or Googlebot et les agents IA parcourent tous deux le web principalement via des chemins href explicites : ce défaut arrête les deux publics de la même façon (Source : John McAlpin, « Why SEOs Should Care About the Accessibility Tree for the Agentic Future », juin 2026).
C'est un des rares correctifs techniques qui profite simultanément à l'indexation classique SEO et à la lisibilité pour les agents, sans arbitrage à faire entre les deux.
Qu’évalue exactement l'audit "Agentic Browsing" de Lighthouse
Agentic Browsing de Page Speed Insight évalue trois domaines :
- Accessibilité : les agents s'appuient sur l'arbre d'accessibilité comme modèle de données principal. Un des tests vérifie que chaque élément interactif possède un nom programmatique.
- Stabilité : mesurée via le Cumulative Layout Shift (CLS, un critère incontournable des web performances), pour éviter qu'un élément ne se déplace au moment où un agent tente de cliquer dessus.
- Intégration WebMCP : WebMCP est une norme proposée qui permet à un site d'exposer directement des actions structurées aux agents IA, plutôt que de les laisser deviner comment interagir avec l'interface visuelle
Vous l’avez compris, ce score est pour l'instant informatif plutôt que comparatif : il donne des signaux de réussite, d'échec et d'avertissement plutôt qu'un classement.
Si ce test échoue sur vos pages, Google indique explicitement que les agents IA auront du mal à les utiliser. Ce n'est plus seulement une bonne pratique de conformité : c'est un signal de visibilité pour la recherche agentique.
Comment inspecter l'arbre d'accessibilité de votre site
Avec Chrome DevTools
Ouvrez l'inspecteur, sélectionnez un élément dans l'arbre DOM, puis cliquez sur l'onglet Accessibility. Activez la bascule « Show accessibility tree » pour remplacer la vue DOM par l'arbre d'accessibilité complet de la page.
Avec Firefox DevTools
Depuis Firefox, l'inspecteur d'accessibilité s'active automatiquement dès qu'on sélectionne l'onglet Accessibility dans les outils de développement, sans réglage préalable.
Avec un audit Lighthouse Agentic Browsing
Depuis Chrome, un audit Lighthouse dédié (accessible aussi via PageSpeed Insights) signale directement si votre arbre d'accessibilité est bien formé, avec le libellé d'erreur exact à corriger.
Comprendre un nœud « ignoré »
Un nœud marqué comme « ignoré » n'apparaît pas dans l'arbre d'accessibilité final : le navigateur l'exclut parce qu'il le juge purement décoratif ou qu'il est masqué intentionnellement. Deux techniques produisent ce résultat : un style CSS display:none, souvent combiné à visibility:hidden, ou un attribut aria-hidden="true". Dans les deux cas, le contenu devient invisible autant pour un agent IA que pour un lecteur d'écran comme NVDA ou VoiceOver.
<!-- Inaccessible : aucun rôle, aucune interactivité clavier -->
<div class="btn-style">Envoyer</div>
<!-- Accessible : rôle, nom et état gérés automatiquement -->
<button type="submit">Envoyer</button>
Le paradoxe ARIA : plus d'attributs, parfois plus d'erreurs
Un résultat contre-intuitif du rapport WebAIM Million 2026 : les pages d'accueil qui utilisent des attributs ARIA comptent en moyenne 59,1 erreurs, contre 42 pour les pages qui n'en utilisent pas.
La raison est simple : un attribut ARIA vide ou incorrect ne laisse pas l'arbre d'accessibilité vide, il le remplit d'une information fausse mais présentée avec assurance, ce qui est pire pour un agent qu'un vide honnête, puisque l'agent n'a aucun moyen de savoir qu'il est induit en erreur.
C'est là que les recommandations divergent. Certains fournisseurs d'IA conseillent simplement d'ajouter des rôles et des labels ARIA pour aider leurs agents à comprendre une page.
Le W3C, dans sa première règle du ARIA, recommande l'inverse : utiliser un élément HTML natif porteur du bon sens et du bon comportement plutôt que de rajouter un rôle ARIA sur un élément détourné de son usage, chaque fois que c'est possible.
La bonne approche n'est pas d'empiler des étiquettes, c'est de corriger la structure du site à la base, pour qu'elle dise la vérité sur ce qu'elle est. C'est plus exigeant à faire correctement, mais c'est aussi la seule méthode qui fonctionne vraiment, autant pour les visiteurs qui utilisent des technologies d'assistance que pour les IA qui naviguent de plus en plus sur le web.
SGQRI 008 3.0 et Loi canadienne sur l'accessibilité (Québec et Canada)
Un arbre d'accessibilité mal structuré reste aussi un problème de conformité au Québec et au Canada.
Au Québec, les sites web des organismes publics doivent respecter le Standard sur l'accessibilité des sites Web (SGQRI 008 3.0), entré en vigueur le 29 avril 2024 et publié par le ministère de la Cybersécurité et du Numérique, basé sur les WCAG 2.1 et certains critères de la version 2.2 (Source : Gouvernement du Québec, 2026).
À l'échelle fédérale, la Loi canadienne sur l'accessibilité, sanctionnée le 21 juin 2019 et entrée en vigueur le 11 juillet 2019, vise un Canada sans obstacle d'ici 2040. Elle renvoie, pour les technologies de l'information, à la norme CAN/ASC-EN 301 549:2024, qui reprend les WCAG 2.1 niveaux A et AA (Source : Normes d'accessibilité Canada).
Conclusion
L'arbre d'accessibilité n'est plus un sujet de niche réservé aux audits de conformité. C'est la structure que Google formalise officiellement via Lighthouse, celle que Playwright MCP et ChatGPT Atlas consultent pour agir sur un site, et celle que le rapport WebAIM Million 2026 montre en train de se dégrader au moment précis où elle compte le plus.
Un balisage sémantique propre, des liens qui sont de vrais liens, des boutons qui sont de vrais boutons : ce sont les mêmes correctifs qui servent une personne utilisant un lecteur d'écran, un robot d'indexation, et un agent IA qui tente de remplir un formulaire à la place d'un client.
FAQ sur l'arbre d'accessibilité
L'arbre d'accessibilité améliore-t-il le référencement SEO?
Pas directement de façon confirmée. Il n’est pas un facteur de classement officiellement reconnu par Google, mais une bonne sémantique HTML profite à la fois à l’accessibilité et à la lisibilité du contenu par les moteurs de recherche.
Quelle est la différence entre l'arbre DOM et l'arbre d'accessibilité?
Le DOM contient tous les éléments, attributs et nœuds de texte d’une page. L’arbre d’accessibilité en est une version filtrée, ne conservant que les informations utiles aux technologies d’assistance.
Pourquoi un agent IA comme ChatGPT Atlas lit-il l'arbre d'accessibilité plutôt que de s'appuyer sur des captures d'écran?
Parce que c’est moins coûteux en jetons à traiter et plus fiable : l’arbre indique explicitement le rôle et le nom de chaque élément, alors qu’un modèle de vision doit deviner quels pixels forment un bouton cliquable. C’est confirmé pour Atlas par la documentation développeurs d’OpenAI elle-même, qui précise qu’il s’appuie sur les mêmes rôles et labels ARIA que les lecteurs d’écran (Sources : OpenAI Publishers and Developers FAQ, via Search Engine Journal et No Hacks, 2026).
Qu'est-ce que l'audit "Agentic Browsing" de Lighthouse?
Une nouvelle catégorie d’audits Google, lancée en juin 2026, qui évalue si un site est compatible avec les agents IA sur trois plans : l’accessibilité (arbre bien formé), la stabilité visuelle (CLS) et l’intégration WebMCP.
Un export markdown de mon site suffit-il à le rendre lisible par une IA?
Il permet à un agent de lire et citer votre contenu, mais pas d’agir dessus : un fichier markdown ne peut pas indiquer qu’un élément est un bouton cliquable ou un champ de formulaire, contrairement à l’arbre d’accessibilité.
Ajouter des balises ARIA améliore-t-il toujours l'arbre d'accessibilité?
Non. Le rapport WebAIM Million 2026 montre que les pages utilisant l’ARIA comptent en moyenne plus d’erreurs que celles qui n’en utilisent pas, généralement parce que l’ARIA est mal appliquée. Le HTML natif reste la première option recommandée par le W3C.
Un lien qui n'est pas en attribut href a-t-il un impact sur le SEO ?
Sans attribut href, ce lien n’apparaît dans l’arbre d’accessibilité qu’avec un rôle générique, sans chemin de navigation, ce qui bloque à la fois les robots d’indexation classiques et les agents IA.
Mon site est-il conforme aux normes d'accessibilité au Québec?
Les organismes publics québécois doivent respecter le SGQRI 008 3.0, en vigueur depuis avril 2024. Un audit de l’arbre d’accessibilité de vos pages est une étape clé pour vérifier cette conformité.
Quel est le lien entre l'arbre d'accessibilité et le RGAA / WCAG / ARIA?
Les WCAG fixent les critères internationaux d’accessibilité. Le RGAA (France), le SGQRI 008 3.0 (Québec) et la norme CAN/ASC-EN 301 549 (Canada) sont des déclinaisons locales et vérifiables de ces critères. ARIA est l’outil technique qui permet d’atteindre ces critères quand le HTML natif ne suffit pas. Dans les trois cas, c’est l’arbre d’accessibilité qu’on inspecte pour vérifier la conformité.
Sources
MDN Web Docs, « Arbre d'accessibilité »
Gouvernement du Québec, « Standard sur l'accessibilité des sites Web (SGQRI 008 3.0) »
Gouvernement du Québec / OPHQ, « Statistiques sur les personnes handicapées »
Gouvernement du Canada, « Résumé de la Loi canadienne sur l'accessibilité »
Normes d'accessibilité Canada, « CAN/ASC-EN 301 549:2024 »
Gouvernement français, RGAA, Glossaire
Chrome for Developers, « Accessibility features reference »
Mozilla, « Accessibility Inspector »
web.dev (Google), « Arborescence d'accessibilité »
WebAIM, « The WebAIM Million 2026 »
Search Engine Journal, « The Accessibility Tree Is How AI Agents Read Your Site & It's Breaking », Slobodan Manic, juin 2026
Chrome for Developers (blog), « Un kit d'outils pour rendre votre site Web compatible avec les agents », juin 2026
John McAlpin, « Why SEOs Should Care About the Accessibility Tree for the Agentic Future », juin 2026
Elevage Digital, « Fix Accessibility Tree Not Well Formed Errors », Renee Dunn, CPWA, juillet 2026
Cloudflare Radar, données trafic bots vs humains, juin 2026
Envoyer un message
Plus de lecture
Intelligence Artificielle 
Comment l’intelligence artificielle (IA) révolutionne l’analyse de données?
Intelligence Artificielle 
