Accessibilité et visibilité dans les IA
Un moteur de réponse ne classe pas des pages : il en extrait des morceaux pour composer une réponse, et cite ses sources. Cette mécanique change la nature de l'exigence. Il ne s'agit plus seulement d'être trouvé — il faut être découpable, c'est-à-dire contenir des unités de sens qui tiennent debout seules.
Or c'est exactement ce que le RGAA impose, pour une raison qui n'a rien à voir avec les moteurs : un lecteur d'écran, lui aussi, consomme la page par fragments.
Ce que fait un moteur de réponse
- Il récupère la page et en extrait le texte.
- Il la découpe en segments autonomes.
- Il retient les segments pertinents pour la question posée.
- Il compose une réponse et attribue une source.
L'étape décisive est la deuxième. Un contenu dont les segments ne tiennent pas seuls — parce que le sens dépend d'un titre mal placé, d'une mise en forme visuelle ou d'une image non décrite — se découpe mal, et se retrouve mal cité, voire pas cité du tout.
Le parallèle avec le lecteur d'écran
Une personne au lecteur d'écran ne lit pas une page de bout en bout : elle saute de titre en titre, entre dans une section, lit un paragraphe. Elle consomme la page par unités autonomes.
Un moteur de réponse fait la même chose. Ce qui rend une page utilisable pour la première la rend exploitable pour le second — et ce n'est pas une analogie commode, c'est la même contrainte technique.
Ce qui se recoupe, concrètement
| Exigence RGAA | Effet sur la citation |
|---|---|
| Titres annonçant réellement leur section | Le découpage suit le sens du document plutôt qu'un seuil de caractères |
| Paragraphes qui se tiennent seuls | Un segment extrait reste compréhensible hors de son contexte |
| Tableaux avec en-têtes déclarés | Les valeurs restent associées à leur signification une fois extraites |
| Alternatives textuelles renseignées | L'information portée par un visuel entre dans le texte exploitable |
| Contenu lisible sans JavaScript | Le contenu existe pour un collecteur qui n'exécute pas les scripts |
| Langue déclarée | Le traitement linguistique s'applique correctement |
| Régions déclarées | Le contenu se distingue des éléments répétés de gabarit |
| Listes réellement balisées | Une énumération reste une énumération après extraction |
Le point le plus déterminant
De tous les critères, celui dont l'effet est le plus direct est le rendu sans JavaScript. Un contenu qui n'existe qu'après exécution des scripts dépend entièrement de la capacité — et de la volonté — du collecteur à rendre la page. Selon les moteurs et les collecteurs, cette capacité varie.
Côté RGAA, c'est une exigence de robustesse. Côté visibilité, c'est une assurance. Voir l'accessibilité des applications monopages.
Ce que nous ne savons pas
Aucun éditeur de moteur de réponse n'a déclaré utiliser des signaux d'accessibilité dans ses critères de sélection, et nous n'avons pas de données propres permettant d'affirmer qu'un site accessible est davantage cité.
Ce que nous affirmons est plus étroit et vérifiable : les propriétés structurelles qu'exige le RGAA sont celles qui rendent un contenu extractible. C'est un lien de cause à effet technique, pas une corrélation mesurée. Toute page qui promet mieux sans données invente.
Ce qu'on en fait
- Écrire des titres qui annoncent plutôt que des titres qui intriguent. « Le calcul du taux de conformité » se cite ; « Et maintenant ? » ne se cite pas.
- Faire tenir chaque paragraphe seul. Éviter les « comme vu plus haut » et les pronoms dont l'antécédent est à deux sections de distance.
- Mettre les données en tableau plutôt qu'en image, avec leurs en-têtes déclarés.
- Garantir le contenu dans le document, sans dépendre d'un rendu différé.
Ces quatre pratiques sont exactement celles que nous appliquons sur ce site — et elles servent d'abord les lecteurs.
Seconde valve du cocon : cette page est autorisée à lier vers les silos GEO et référencement IA existants. Liens à poser lors de l'intégration.
Poursuivre
Le même raisonnement appliqué aux moteurs de recherche classiques : accessibilité et SEO.