Imaginez un collaborateur. Il délègue à son assistant IA une tâche simple. Il doit comparer trois offres d’assurance professionnelle. Puis il pré-remplit le formulaire de contact du prestataire le mieux noté. L’agent se met en route. Il visite les sites, interroge les pages, tente d’interagir. Sur certains, il avance sans friction. Sur d’autres, il s’arrête net, sans message d’erreur, sans explication, sans traces.
Que s’est-il passé ? La réponse tient en une question que peu d’équipes IT posent encore. Votre site est-il lisible par un agent IA ?
Un agent IA ne « voit » pas, il lit
Contrairement à un utilisateur humain qui perçoit une page dans sa globalité, ses couleurs, sa mise en page, ses animations, un agent IA ne rend pas la page visuellement. Il interroge sa structure.
Pour cela, il s’appuie sur ce qu’on appelle l’arbre d’accessibilité (accessibility tree) : une représentation hiérarchique et sémantique de la page, construite automatiquement par le navigateur à partir du HTML. Cet arbre liste les éléments interactifs, leurs rôles, leurs libellés, leurs relations. C’est sur cette surface, et non sur l’apparence visuelle, que l’agent s’appuie pour comprendre ce qu’il peut faire sur une page.
En pratique, un agent cherche des réponses à des questions simples : quel est cet élément ? À quoi sert-il ? Comment m’en saisir ? Si l’arbre d’accessibilité lui fournit ces réponses clairement, il avance. Sinon, il s’arrête.
Ce que l’agent ignore, en revanche : le CSS et les transitions visuelles. Dans la plupart des cas, il ignore aussi le JavaScript exécuté côté client après le chargement de la page. Pour lui, ce qui n’est pas dans le HTML structuré n’existe tout simplement pas.
Quels sont les éléments qui bloquent un agent IA ?
Plusieurs configurations techniques courantes rendent une page opaque pour un agent IA.
Un élément cliquable sans rôle explicite. Quand un bouton est implémenté comme un <div> ou un <span> stylisé sans attribut de rôle (role="button"), l’agent ne peut pas identifier qu’il s’agit d’un élément interactif. Il voit un bloc de texte, pas une action possible.
Un contenu chargé uniquement en JavaScript. Les variantes produit, les prix dynamiques, les disponibilités en temps réel : si ces informations sont injectées dans le DOM après le rendu initial via JavaScript, elles sont invisibles dans l’arbre d’accessibilité que l’agent consulte. La page lui apparaît incomplète.
Une image sans texte alternatif. Pour un agent qui ne perçoit pas les visuels, une image sans attribut alt descriptif est une boîte noire. Si cette image est porteuse d’une information clé, un tarif, un label, une offre, l’agent ne peut pas en tenir compte dans son raisonnement.
Un formulaire sans libellés associés. Un champ de saisie sans <label> lié est techniquement présent dans l’arbre, mais sans identité. L’agent ne sait pas ce qu’on lui demande d’y saisir. Remplir un formulaire de contact ou de souscription devient alors une opération hasardeuse, voire impossible.
Ces quatre cas ne sont pas des situations marginales. Ils correspondent à des pratiques de développement très répandues, notamment dans les interfaces construites avec des frameworks JavaScript modernes qui privilégient la souplesse visuelle sur la structuration sémantique.
Qu’est-ce que ça change pour les équipes web et IT ?
Pendant longtemps, l’accessibilité numérique a été perçue comme un sujet de conformité réglementaire : une obligation à remplir pour respecter le RGAA ou les normes WCAG, avec un périmètre d’impact limité à une fraction des utilisateurs.
Ce périmètre vient de s’élargir.
Atlas (OpenAI), Comet (Perplexity), Auto Browse (Google Chrome) : ces agents navigateurs autonomes sont déployés depuis la fin 2025. Ils ne sont pas une tendance à horizon lointain. Ils sont déjà utilisés par des collaborateurs, des acheteurs, des décideurs qui leur délèguent des tâches de recherche, de comparaison et d’interaction sur le web. Et ils lisent vos sites exactement comme un lecteur d’écran le ferait.
Ce glissement a une conséquence directe pour les équipes IT et digitales : les investissements réalisés pour améliorer l’accessibilité, structuration HTML sémantique, libellés explicites, gestion du contenu dynamique, produisent désormais un effet secondaire immédiat. Ils améliorent la lisibilité du site pour ces nouveaux utilisateurs non humains.
Ce n’est pas un chantier supplémentaire. C’est un chantier existant qui rapporte deux fois : une fois pour la conformité réglementaire et l’inclusion des utilisateurs humains, une fois pour la compatibilité avec les agents IA qui agissent à leur place.
Les équipes qui ont déjà engagé ce travail ont pris une longueur d’avance qu’elles ne mesurent pas encore tout à fait. Celles qui ne l’ont pas fait accumulent une dette technique dont les effets seront difficiles à tracer dans les dashboards, mais bien réels dans les résultats.
Une opportunité de réconciliation
L’accessibilité numérique a longtemps souffert d’un déficit de légitimité business. Perçue comme un poste de coût réglementaire plutôt que comme un investissement, elle a été repoussée, minimisée, traitée en dernier recours.
L’émergence d’agents IA autonomes change la donne.Elle ne crée pas un nouveau problème.Elle révèle plutôt la valeur de ce qui avait été négligé. Un site bien structuré sémantiquement n’est pas seulement plus inclusif pour les utilisateurs humains : il est aussi plus opérable pour les agents qui agissent à leur place.
C’est peut-être la meilleure nouvelle pour les équipes qui portent ce sujet depuis des années : les arguments ont changé de camp. L’accessibilité n’est plus seulement une question d’éthique ou de conformité. Elle est devenue une condition pour être visible sur le web de demain. Une part croissante des échanges sera lancée par des machines.