Description de l’image : un smartphone posé sur un bureau en bois affichant une interface de chat IA avec des écouteurs branchés — le marqueur visuel d’une conception de prompt IA adaptée aux lecteurs d’écran.

Temps de lecture : 9 minutes

Une nouvelle discipline de conception a cristallisé au sein de la communauté de l’accessibilité au cours des dix-huit derniers mois, et elle ne dispose pas encore d’un nom établi. Certaines équipes l’appellent « ingénierie de prompts adaptée aux technologies d’assistance » ; d’autres, « prompts système façonnés pour les lecteurs d’écran » ; les praticiens issus du design d’interface vocale tendent à l’appeler « la couche de sortie vocale d’un LLM ». Quelle que soit l’étiquette, le savoir-faire est identique : rédiger des prompts système et des règles de mise en forme des sorties qui rendent les assistants d’IA générative — ChatGPT, Claude, Gemini, Copilot, Be My AI — utiles aux environ 253 millions de personnes dans le monde qui accèdent à ces produits via un lecteur d’écran.

Le problème est concret et le mode d’échec est bruyant. Un LLM entraîné sur le web public produit, par défaut, une prose décorée de tirets cadratins, de listes markdown imbriquées, de blocs de code, de titres qui n’existent que parce que le modèle a jugé que la réponse était « structurée », et d’émojis décoratifs. Lu à haute voix par NVDA, JAWS, VoiceOver ou TalkBack, ce résultat devient un flux d’interjections « tiret tiret », d’énumérations « puce puce puce » sans aucun sens de la fin d’un élément, d’annonces « titre de niveau deux » qui interrompent une phrase, et de chaînes de noms d’émojis (« visage souriant avec lunettes de soleil ») entre chaque clause. L’information est bien là. L’utilisateur ne peut pas l’extraire sans revenir en arrière trois fois. Cet article est un premier repère sur ce que la discipline demande aux concepteurs de modèles, ce que les produits ont livré jusqu’à présent, et les problèmes UX ouverts que personne n’a encore résolus.

La nouvelle discipline — en quoi elle consiste réellement

La conception de prompts adaptée aux lecteurs d’écran n’est pas une règle unique. C’est un petit ensemble de contraintes qui, ensemble, produisent une sortie qu’un synthétiseur peut prononcer intelligiblement et qu’une touche de navigation de lecteur d’écran peut parcourir. Les contraintes se répartissent en quatre catégories.

Des réponses concises avec une structure sémantique. La sortie par défaut des LLM est trop longue pour une écoute — une réponse de 600 mots qui se lit bien dans le navigateur d’un utilisateur voyant devient un monologue de quatre minutes que l’utilisateur de lecteur d’écran n’a aucun moyen de parcourir en diagonale. La discipline demande des réponses plus courtes, mais surtout des réponses plus courtes et structurées : un résumé d’ouverture en une phrase à laquelle l’utilisateur peut s’arrêter, suivi d’une structure que le lecteur d’écran peut naviguer par titre ou par élément de liste.

Éviter les tirets cadratins et autres signes de ponctuation que les synthétiseurs misprononcent. Le tiret cadratin, le tiret semi-cadratin, la parenthèse, la barre oblique comme conjonction, le séparateur en ASCII — tous sont lus à haute voix soit comme silence, soit comme un « tiret » littéral, soit comme une pause confuse qui coupe une proposition en deux. La convention qui émerge dans les grands modèles est : préférer la virgule et le point ; utiliser le deux-points pour l’unique endroit où il mérite vraiment sa place ; ne jamais utiliser de tirets cadratins dans les réponses en contexte vocal ; ne jamais utiliser de règles ASCII pour séparer les sections.

Déclarer ce qui est une liste, ce qui est un titre, ce qui est du code. La parole synthétisée n’a pas de hiérarchie visuelle. Un titre doit être annoncé comme « titre », une liste doit être annoncée comme « liste avec N éléments, élément un », le code doit être annoncé comme « code », et le modèle doit soit produire des structures que le lecteur d’écran reconnaît (HTML, markdown correct que la surface de rendu convertit en ARIA), soit narrer verbalement la structure lui-même (« Voici trois options. Option un : … »).

Pas de soupe markdown. Le markdown convient lorsque la surface de rendu le convertit en HTML sémantique. Le markdown est hostile lorsque la surface affiche les astérisques et les traits de soulignement bruts, car le lecteur d’écran annonce alors « astérisque astérisque » avant chaque mot en gras. La discipline consiste à détecter le contexte de rendu — interface de chat avec rendu markdown versus terminal versus interface vocale pilotée par lecteur d’écran — et à façonner la sortie en conséquence. Le même modèle doit produire des représentations de surface différentes de la même réponse.

Ce dont les lecteurs d’écran ont réellement besoin de l’IA

Pour rendre les contraintes ci-dessus concrètes, il est utile d’examiner le comportement réel des quatre combinaisons lecteur d’écran / système d’exploitation qui dominent le domaine : JAWS sur Windows, NVDA sur Windows, VoiceOver sur macOS et iOS, et TalkBack sur Android. Ils ne sont pas interchangeables, et un prompt qui produit une excellente sortie pour l’un peut être illisible sur un autre.

Navigation par titre. Les quatre lecteurs exposent une touche de navigation par titre (H dans JAWS et NVDA, Rotor dans VoiceOver, la bascule de contrôle de lecture dans TalkBack). Pour qu’une longue réponse IA soit navigable, le modèle doit émettre de vrais titres sémantiques — soit via un pipeline de rendu markdown qui convertit en <h2>/<h3> avec une hiérarchie de niveaux correcte, soit via l’API de réponse structurée de la surface de chat. Un modèle qui « structure » sa réponse en mettant en gras les trois premiers mots de chaque paragraphe a produit quelque chose qui semble structuré visuellement et est complètement plat pour un lecteur d’écran.

Navigation par liste. Les listes sont utiles dans la sortie vocale précisément parce que le lecteur d’écran annonce le décompte (« liste avec sept éléments ») et permet à l’utilisateur de parcourir les éléments avec la touche de navigation par élément de liste (I dans NVDA, L dans JAWS). Mais cela ne fonctionne que si la liste est un vrai <ul> ou <ol>. Une « liste » produite en émettant des caractères de puce au début de chaque ligne, sans conteneur de liste, est lue comme de la prose ordinaire avec une interjection inexpliquée « cercle noir » ou « puce » sur chaque ligne.

Saut par section. Les réponses IA longues — explications, comparaisons, code avec commentaires, instructions en plusieurs étapes — nécessitent un moyen pour l’utilisateur de lecteur d’écran de sauter à la section qui l’intéresse sans écouter le préambule. C’est la partie la plus difficile à bien concevoir, car le modèle doit produire une structure navigable et la surface de chat doit la rendre d’une manière que le système d’exploitation expose à la technologie d’assistance, et le lecteur d’écran doit être configuré pour utiliser la touche de navigation par titre dans cette surface. Les trois échouent dans la pratique ; c’est généralement le deuxième point qui pose problème.

Indices de prononciation. Les voix synthétiques trébuchent sur les termes techniques, les acronymes avec des lettres mixtes, les URL, les identifiants de code, la notation mathématique et les noms non anglophones. Un modèle bien conçu, pour les réponses en contexte lecteur d’écran, épellera les acronymes à la première utilisation (« WCAG, les Règles pour l’accessibilité des contenus web »), développera les sigles que le synthétiseur ne peut pas prononcer, et évitera d’incorporer des URL brutes dans une prose courante où le synthétiseur lira les barres obliques à haute voix. En 2026, aucun des grands produits ne fait cela de façon cohérente.

Comment les produits gèrent la question

À mi-2026, les grands produits d’IA générative ont pris des positions visiblement différentes sur la sortie adaptée aux lecteurs d’écran. Aucun n’a encore réussi. La progression est plus rapide qu’il y a douze mois, mais l’écart entre le meilleur et le moins bon reste important.

ChatGPT (OpenAI). Le client web est maintenant livré avec un bouton de mode « concis » qui raccourcit les réponses par défaut et réduit la décoration markdown. Le mode vocal introduit en 2024 — et substantiellement amélioré en 2025 — est ce que n’importe quel grand produit a fait de plus proche d’une interface native pour lecteur d’écran, car il contourne entièrement le chat visuel et délivre une réponse vocale avec un geste d’arrêt, de relecture et « répétez ». Le champ d’instructions personnalisées permet aux utilisateurs de lecteur d’écran de déclarer leurs préférences une fois et de les appliquer à toutes les sessions, ce qui est le contournement piloté par l’utilisateur sur lequel la communauté s’est établie. Les lacunes restantes : les modèles GPT adoptent toujours par défaut une prose riche en tirets cadratins sauf instruction contraire, et le niveau de titre émis en markdown ne correspond pas toujours proprement à l’ARIA dans la surface de chat.

Claude (Anthropic). La discipline des prompts système de Claude s’est le plus rapprochée des conventions décrites ci-dessus. Le modèle est notoirement moins enclin aux tirets cadratins que la gamme GPT en 2026, adopte par défaut des réponses plus courtes, et répond bien aux instructions de prompt système comme « vous vous adressez à un utilisateur de lecteur d’écran ; n’utilisez pas de tirets cadratins, préférez des paragraphes courts, et utilisez de vrais titres ou des listes numérotées lorsqu’une structure est nécessaire ». La surface de chat Claude.ai rend le markdown en HTML sémantique avec des niveaux de titre corrects, ce qui fait fonctionner la touche de navigation par titre. La sortie vocale via des intégrations tierces existe mais est moins développée que le mode vocal first-party de ChatGPT.

Gemini (Google). L’intégration étroite avec TalkBack sur Android est l’avantage structurel de Gemini ; le modèle peut passer la main au lecteur d’écran au niveau du système d’exploitation via les services d’accessibilité d’Android d’une manière que les concurrents iOS et web ne peuvent pas. Le flux « Hey Google, demande à Gemini… » sur les appareils Android accessibles est, pour certains utilisateurs, l’expérience IA plus lecteur d’écran la plus naturelle disponible. Les lacunes restantes : l’interface web sur-décore encore les réponses, la hiérarchie des titres dans les réponses web de Gemini est incohérente, et le modèle est plus enclin à produire des émojis décoratifs que ses concurrents.

Be My AI (Be My Eyes + OpenAI). C’est le plus étroitement ciblé des quatre — un assistant de description visuelle qui utilise des modèles de vision de classe GPT-4 pour décrire des images et des environnements aux utilisateurs aveugles et malvoyants. C’est aussi le seul produit de cette liste conçu dès le départ avec un utilisateur de lecteur d’écran comme audience principale. La conception des prompts de Be My AI est la démonstration la plus claire du domaine de ce à quoi ressemble une sortie adaptée aux technologies d’assistance en pratique : les descriptions s’ouvrent avec un résumé d’une phrase à laquelle l’utilisateur peut s’arrêter, suivent avec un détail structuré seulement si demandé, et évitent le langage spatial (« à gauche », « au-dessus ») qui nécessite un contexte de vision pour être interprété. En 2026, ce produit reste ce que le domaine a de plus proche d’une implémentation de référence.

L’observation transversale est que les quatre produits ont progressé sur les parties faciles — réponses plus courtes, moins de tirets cadratins, un champ d’instructions personnalisées — et ont à peine commencé sur les parties difficiles. Les parties difficiles sont exposées ci-dessous.

Problèmes UX ouverts que personne n’a résolus

La littérature sur la conception de prompts adaptée aux lecteurs d’écran converge sur quatre problèmes UX ouverts pour lesquels la bonne réponse n’est pas encore connue. Aucun d’eux n’est un problème de capacité du modèle ; tous sont des problèmes de conception d’interaction qui se situent entre le LLM, la surface de chat, le système d’exploitation et le lecteur d’écran.

L’interruptibilité. Un utilisateur voyant peut scanner une réponse LLM en environ deux secondes et décider s’il doit la lire. Un utilisateur de lecteur d’écran ne peut pas. Si la réponse est fausse ou hors sujet, l’utilisateur doit écouter suffisamment pour s’en rendre compte, puis interrompre. Les modes vocaux ont un bouton d’arrêt. Les modes texte généralement non — la réponse arrive en streaming et le lecteur d’écran l’annonce comme nouveau contenu à mesure qu’elle arrive, et l’utilisateur n’a pas de moyen propre de dire « arrête de générer, ce n’est pas ce que j’ai demandé ». L’application Be My AI gère cela le mieux ; les clients web de chat le gèrent le moins bien.

La répétition de la dernière réponse avec une granularité sélectionnable. Demander à un lecteur d’écran de relire la dernière réponse est facile si la réponse est courte. C’est inutilisable si la réponse fait six paragraphes et que l’utilisateur ne veut entendre que le troisième paragraphe à nouveau. L’interaction que la communauté demande est « répète le dernier élément de liste », « répète la dernière section de titre », « répète le dernier bloc de code ». Cela exige que la surface de chat expose la structure au lecteur d’écran d’une manière que les propres commandes de relecture du lecteur d’écran peuvent adresser. En 2026, aucun des grands produits ne fait cela ; l’utilisateur doit utiliser la navigation ligne par ligne du lecteur d’écran, ce qui est laborieux.

La navigation par section dans la sortie vocale. Les modes vocaux n’ont pas de touche de navigation par titre. L’utilisateur écoute une réponse de quatre minutes de façon linéaire, sans possibilité de sauter de la section « aperçu » à la section « détails » sans rembobiner dans le temps. Les conceptions d’interaction en cours de prototypage — une « liste de sections » vocale que l’utilisateur peut naviguer avec les touches fléchées, une commande vocale « aller à la section trois », un mode « donne-moi les titres uniquement » — sont précoces. Le suivi « plus de détails sur les couleurs » de l’application Be My AI est la version fonctionnelle la plus proche de cela dans un produit en production.

La question de la passation AT — quand l’IA parle-t-elle par rapport à lire du contenu à haute voix ? C’est la question de conception la plus profonde. Si un utilisateur de lecteur d’écran ouvre un assistant IA sur une page web, qui parle — la propre voix de l’IA (couche TTS), ou le lecteur d’écran installé de l’utilisateur lisant la sortie texte de l’IA ? Les deux voix ont des réglages différents, des débits différents, des indices de prononciation différents, des gestes d’arrêt et de relecture différents. Deux systèmes essayant de parler du même contenu en même temps ne produit rien d’utilisable. La convention qui émerge est : les interactions en mode vocal utilisent le TTS propre de l’IA et suppriment explicitement le lecteur d’écran ; les interactions en mode texte émettent du HTML sémantique et laissent le lecteur d’écran parler. Mais la frontière entre les deux modes n’est pas toujours nette — la description d’images, la génération de code, la notation mathématique et les réponses multimodales se situent toutes de façon inconfortable entre voix et texte — et c’est à cette frontière que vivent la plupart des problèmes UX actifs.

La suite

La discipline en est grossièrement au stade où se trouvait l’accessibilité web vers 2002 — passé la phase « est-ce un vrai problème ? », passé la phase « qui est responsable ? », dans la phase « quelles sont les règles réelles ? ». Trois choses sont susceptibles de se produire au cours de 2026 et 2027.

Premièrement, les concepteurs de modèles vont codifier leurs prompts internes pour lecteurs d’écran et les publier, de la même façon qu’Anthropic publie les prompts système de Claude dans des déclarations d’accessibilité de style VPAT et qu’OpenAI a commencé à documenter les comportements par défaut de GPT. La communauté demande l’équivalent d’une fiche modèle — une « fiche de sortie lecteur d’écran » — qui nomme les conventions qu’un modèle donné a été entraîné ou incité par prompt système à suivre.

Deuxièmement, les surfaces de chat — clients web, applications mobiles, intégrations IDE — vont acquérir des pipelines de rendu HTML sémantique correctement configurés et une exposition ARIA correcte pour l’historique de chat, avec les touches de navigation mappées au lecteur d’écran du système d’exploitation. C’est un travail peu glamour, et c’est le travail qui fera le plus bouger les choses pour les utilisateurs quotidiens.

Troisièmement, les fournisseurs de lecteurs d’écran eux-mêmes — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — vont commencer à livrer des fonctionnalités adaptées à l’IA : navigation native par titre dans les surfaces de chat IA, un geste standardisé « arrêter la génération », des commandes de relecture plus intelligentes qui connaissent la structure de réponse des LLM. L’écosystème d’extensions open source de NVDA produit déjà des premières versions de celles-ci. Les lecteurs propriétaires sont plus lents mais la direction est la même.

L’observation plus profonde est que la conception de prompts adaptée aux lecteurs d’écran a cessé d’être une préoccupation de niche d’une poignée de développeurs aveugles et est devenue une attente de base de chaque équipe produit IA qui souhaite livrer sur des marchés réglementés. L’Acte européen sur l’accessibilité (EAA) s’applique aux « terminaux en libre-service interactifs » et aux « équipements terminaux grand public à capacité informatique interactive » — une catégorie qui capture presque certainement un grand assistant IA sur téléphone. La couche de sortie adaptée aux technologies d’assistance n’est plus une fonctionnalité ; elle est contraignante pour les marchés publics. Les équipes qui établissent les règles maintenant livreront les produits qui survivront au 28 juin 2025 et au-delà. Les équipes qui la traitent comme une réflexion après coup seront le prochain cycle de cas d’application de l’EAA.

Réflexions finales

Le savoir-faire est modeste, les enjeux sont importants, et les règles sont encore en cours d’élaboration. Si vous construisez avec des LLMs et que vous n’avez pas encore eu une conversation avec un utilisateur de lecteur d’écran sur ce à quoi ressemble réellement votre produit quand il l’utilise, c’est la prochaine chose sur la liste. La plupart de ce qui ne va pas avec l’IA pour les utilisateurs de lecteurs d’écran en 2026 n’est pas un problème de capacité du modèle ; c’est un problème de conception de prompts et de surface que n’importe quelle équipe produit peut corriger en un sprint, si elle décide de le faire.

La communauté a été généreuse de son temps, de ses tests et de sa patience. Elle perd aussi patience plus vite qu’avant, parce que les produits sont désormais grand public et que l’excuse « on cherche encore » a expiré. La discipline est là. Les conventions convergent. Les dix-huit prochains mois sépareront les équipes qui ont écouté de celles qui ne l’ont pas fait.