TL;DR : un lecteur d’écran et un moteur de réponse IA ont un point commun. Ni l’un ni l’autre ne « voit » votre page : ils lisent sa structure. Une hiérarchie de titres propre, des images décrites, des tableaux balisés et des liens qui disent où ils mènent rendent un contenu utilisable par une personne aveugle et exploitable par un assistant qui cherche quoi citer. L’accessibilité n’est pas un chantier à part du GEO : c’est souvent le même.
Un visiteur qui navigue avec NVDA ou VoiceOver ne parcourt pas une page comme vous. Il saute de titre en titre, se fait lire la liste des liens, interroge un tableau cellule par cellule. Tout ce que la mise en page exprime visuellement, un gros titre, une colonne mise en valeur, une photo explicite, doit donc exister dans le code pour lui parvenir.
Un moteur de réponse fonctionne dans une situation assez proche. Quand ChatGPT, Perplexity ou AI Mode vont chercher une page pour répondre à une question, ils en récupèrent le contenu, le découpent en passages et choisissent ceux qui répondent le mieux. Eux non plus ne profitent pas de votre charte graphique. Ce qu’ils exploitent, c’est du texte et de la structure.
Cette convergence a une conséquence pratique pour les marques : le travail d’accessibilité et le travail de visibilité dans l’IA se recoupent largement.
Deux lecteurs qui ne voient pas la page
Il serait exagéré de dire que les modèles ont été conçus pour lire le web comme une technologie d’assistance. Les mécanismes internes de sélection des sources ne sont pas publiés, et chaque moteur a sa propre recette. Mais les deux lecteurs partagent une contrainte : ils dépendent de ce que le HTML déclare explicitement.
Une page dont le titre principal est une image, dont les intertitres sont de simples paragraphes en gras et dont le tableau de prix est une capture d’écran pose le même problème aux deux. Le lecteur d’écran n’a rien à annoncer. Le moteur de réponse, lui, n’a pas de passage clair à extraire, ni d’étiquette pour savoir de quoi parle chaque bloc. Nous avions détaillé ce qui rend un passage reprenable dans notre article sur le contenu citable par l’IA : la lisibilité de la structure y revient constamment.
Les recoupements, élément par élément
Le tableau ci-dessous met en regard ce que chaque bonne pratique apporte aux deux publics.
| Élément | Pour un lecteur d’écran | Pour un moteur de réponse |
|---|---|---|
Titres h1 à h6 hiérarchisés | Navigation de section en section, plan de la page | Découpage en passages thématiques, repérage de la réponse |
| Texte alternatif des images | Restitution de l’information portée par l’image | Information disponible sous forme de texte, donc exploitable |
Tableaux avec th, scope, caption | Lecture cellule par cellule avec ses en-têtes | Données comparatives interprétables ligne par ligne |
| Intitulés de liens explicites | Liste des liens compréhensible hors contexte | Signal sur le sujet de la page liée |
Langue déclarée (lang) | Prononciation correcte par la synthèse vocale | Identification sans ambiguïté de la langue du contenu |
Listes balisées (ul, ol) | Annonce du nombre d’éléments | Étapes et critères isolables tels quels |
Rien de ce tableau n’est un « hack » destiné aux IA. Ce sont des exigences d’accessibilité anciennes, que l’on retrouve dans le RGAA, le référentiel français (version 4.1.2, 106 critères répartis en 13 thématiques). L’intérêt, pour une équipe marketing, est de constater qu’un même effort de production sert deux objectifs.
Là où le parallèle a ses limites
Il ne faut pas pousser l’analogie trop loin. Un moteur de réponse est capable de reconstituer du sens à partir d’un texte mal balisé ; un lecteur d’écran, beaucoup moins. À l’inverse, l’accessibilité couvre des sujets qui n’intéressent aucun robot : la navigation au clavier, la visibilité du focus, les contrastes de couleur, les sous-titres des vidéos, le comportement des fenêtres modales. Rendre un site accessible ne se résume donc pas à bien baliser ses articles.
De même, être accessible ne garantit pas d’être cité. Les moteurs pèsent aussi l’autorité de la source, la fraîcheur, la précision de la réponse apportée. La structure est une condition favorable, pas une assurance.
Pour une lecture plus détaillée des points de contact, avec l’angle du spécialiste de l’accessibilité, on peut se reporter à l’analyse d’audit-rgaa.eu sur l’accessibilité et les moteurs de réponse.
Un argument de plus depuis juin 2025
Le sujet a pris une dimension réglementaire. Depuis le 28 juin 2025, l’European Accessibility Act, transposé en droit français, étend les obligations d’accessibilité à de nombreux services grand public en ligne, dont le commerce électronique ; les micro-entreprises qui fournissent des services en sont exemptées. Les contrôles relèvent de l’ARCOM.
Pour un annonceur, cela change la façon de présenter le chantier en interne. La mise en conformité n’est plus seulement une contrainte : les mêmes corrections améliorent la façon dont les pages sont lues par les assistants que vos clients interrogent. C’est un rare cas où l’obligation et l’acquisition tirent dans le même sens.
Par où commencer sur un site existant
Sans lancer d’audit complet, quelques vérifications rapides donnent une idée de l’état des lieux :
- Afficher le plan des titres d’une page clé avec une extension de navigateur. S’il ne se lit pas comme un sommaire cohérent, ni un lecteur d’écran ni un moteur n’en tireront grand-chose.
- Relire les textes alternatifs des images porteuses d’information (schémas, graphiques, tableaux en image). Une image vide de description est une information perdue pour les deux lecteurs.
- Remplacer les tableaux en image par de vrais tableaux HTML avec en-têtes.
- Lister les liens « en savoir plus » et les réécrire avec un intitulé qui nomme la destination.
- Compléter la couche sémantique par des données structurées, qui précisent l’entité, l’auteur et le type de contenu.
Ces corrections ne demandent pas de refonte. Elles relèvent de l’hygiène éditoriale, et elles profitent à tous les lecteurs de la page, humains ou non.