Introduction : enjeux opérationnels
Déployer un avatar IA sur une borne ou un écran en lieu public exige d'assurer l'accès pour les personnes présentant des déficiences visuelles, auditives, motrices ou cognitives, sans perdre la qualité multilingue ni la disponibilité 24/7. Ce guide vise à transformer des principes généraux en éléments concrets à intégrer au cahier des charges, au pilote et au runbook d'exploitation.
Les responsables de projet, DSI et équipes accessibilité trouveront ici : le cadre réglementaire utile, les critères techniques à vérifier, des recommandations UX pour la conversation et l'interface, un protocole de tests utilisateurs handicapés et une checklist d'audit prête à l'emploi.
Cadre réglementaire et application des WCAG
Les référentiels d'accessibilité web tels que WCAG offrent un cadre technique pertinent pour les interfaces des bornes interactives. En pratique, il s'agit d'appliquer les principes d'alternative aux médias, d'opérabilité clavier, de lisibilité visuelle et de robustesse.
Avant le déploiement, vérifiez quelles obligations s'appliquent localement à votre projet (réglementation nationale, marchés publics, politiques internes). Les exigences concrètes peuvent varier selon le type de lieu et le statut de l'organisme. Considérez WCAG comme un guide technique que votre interface devra traduire en règles de conception et en critères d'acceptation.
Critères techniques essentiels pour l'interface borne
La compatibilité avec les aides techniques dépend autant du logiciel d'interface que du matériel et de l'intégration. Pour garantir l'interopérabilité avec les lecteurs d'écran et les technologies d'assistance, exigez que l'interface respecte des principes concrets : structure sémantique claire, libellés accessibles, ordre de tabulation logique et indication visible du focus.
Autres points techniques à inclure dans le cahier des charges : prise en charge de la navigation clavier complète, textes dimensionnables sans perte de fonctionnalité, contrastes visibles, alternatives textuelles pour les éléments non textuels et modes d'entrée multiples (tactile, voix, saisie au clavier).
Compatibilité lecteurs d'écran et structure des réponses
Pour qu'un lecteur d'écran annonce correctement les contenus produits par l'avatar, la couche d'interface doit exposer des éléments textuels et des attributs ARIA pertinents. Prévoir des sorties textuelles équivalentes aux messages vocaux afin qu'un utilisateur aveugle ou malvoyant accède aux mêmes informations.
Lors de l'intégration, testez la lisibilité des réponses courtes et la clarté des libellés. Évitez les présentations uniquement iconographiques ou animées sans alternative textuelle. L'architecture de l'écran doit permettre au visiteur d'identifier rapidement l'état de la session (attente, en cours, résultat).
Interaction vocale, malentendants et alternatives visuelles
L'interaction vocale est essentielle pour beaucoup d'usages, mais elle doit être toujours accompagnée d'une alternative visuelle. Prévoir un champ de saisie textuelle visible, un clavier virtuel tactile et des boutons de commandes claires pour lancer, arrêter ou répéter une interaction.
Le sous-titrage et la transcription temps réel améliorent l'accessibilité pour les personnes malentendantes. Ces fonctions nécessitent généralement une intégration spécifique avec un service de STT/transcription et un composant d'affichage des sous-titres. Il est donc utile d'anticiper ces besoins dans le cahier des charges et de prévoir les APIs ou webhooks nécessaires.
Ergonomie physique et implantation de la borne
L'accessibilité physique dépend du choix d'emplacement et de l'ergonomie matérielle : positionnement permettant l'accès en fauteuil, surface d'appui suffisante, inclinaison de l'écran, lisibilité sous différents angles et protection contre l'éblouissement. Ces aspects sont dépendants du matériel choisi et des contraintes du site.
Pensez également aux situations d'usage assis vs debout, à la présence d'un repose-bras ou d'un plan d'appui pour la saisie, et à une signalétique claire pour orienter les usagers vers la borne. La qualité du microphone et du haut-parleur impacte la fluidité de l'interaction vocale et doit être prise en compte dans les tests en condition réelle.
Accessibilité cognitive et conception de la conversation
Adapter la conception conversationnelle aux personnes présentant des troubles cognitifs passe par une écriture claire, des phrases courtes, des choix limités et une aide pas à pas. Prévoyez des confirmations simples et des options de reprise facile lorsque l'avatar n'a pas compris.
La persona de l'avatar doit rester prévisible et cohérente. SANIA peut être personnalisée selon l'activité et les besoins du client, ce qui permet d'ajuster le ton, la vitesse de parole et la complexité du vocabulaire selon le public visé.
Protocole de tests utilisateurs handicapés pour un pilote opérationnel
Un pilote accessible intègre des tests utilisateurs avec des personnes présentant des déficiences visuelles, auditives, motrices et cognitives. Définissez des objectifs de test précis : validation de la navigation clavier, compréhension des réponses vocales et textuelles, usage en condition de bruit réel et évaluation de la signalétique physique.
Organisez des scénarios représentatifs (exemples : trouver une information simple, demander une orientation, changer la langue). Durant chaque session, collectez des observations qualitatives, notez les points d'interruption et demandez un retour sur la facilité d'usage et la compréhension. Prévoyez des tests en plusieurs langues si le site reçoit un public multilingue.
Checklist d'audit opérationnelle prête à l'emploi
Cette liste peut être intégrée au cahier des charges et utilisée pendant le pilote et l'exploitation. Elle couvre l'interface, la voix, le matériel et les tests.
Présence d'un mode texte accessible équivalent à chaque message vocal.
Navigation clavier complète et ordre de tabulation logique sur l'interface.
Étiquetage clair des contrôles avec attributs accessibles (ARIA) et libellés visibles.
Indication visuelle du focus et retours d'état explicites (lecture en cours, attente).
Tailles de cibles tactiles suffisantes et zones de saisie faciles d'accès.
Contraste des couleurs conforme aux recommandations WCAG pour le texte principal et les éléments interactifs ou, à défaut, mise en évidence des alternatives visuelles (icônes accompagnées de texte). Notez que les ratios précis sont définis par WCAG et doivent être consultés selon l'objectif de conformité choisi par l'organisation. Voici un point opérationnel : testez l'interface en conditions de luminosité variables pour valider la lisibilité réelle..
Exemples de configurations SANIA et points à préciser dans le cahier des charges
Voici trois configurations illustratives et les éléments à spécifier dans le cahier des charges. Attention : certaines fonctions nécessitent une intégration spécifique et ne sont pas automatiquement fournies sans développement.
Configuration 1 - interface tactile et texte accessible : SANIA est déployée sur un écran/borne interactive avec interface tactile et sorties textuelles complètes. Caractéristiques à définir : navigation clavier, libellés ARIA, gestion du focus, tailles de police adaptables. Remarques sur SANIA : l'avatar peut être utilisé avec une interface tactile et textuelle et exploite une base de connaissances propre à l'organisation.
Configuration 2 - ajout de l'interaction vocale : SANIA fournit l'interface vocale et la synthèse vocale. Préciser dans le cahier des charges la gestion des interruptions vocales, la commutation de langue en session et la qualité requise pour les microphones et haut-parleurs. Remarques sur SANIA : SANIA peut communiquer dans plus de 100 langues, peut fonctionner 24 heures sur 24 et peut gérer l'interruption d'une réponse vocale lorsque l'utilisateur reprend la parole.
Configuration 3 - accessibilité augmentée (sous-titrage et transcription) : pour proposer des sous-titres ou une transcription temps réel, prévoyez une intégration spécifique avec un service de STT et un composant d'affichage des sous-titres. Précisez les APIs, latence acceptable et modes de basculement si le service de transcription est indisponible. Cette couche est une intégration et requiert de définir les responsabilités entre les parties prenantes.
Points de vigilance et erreurs fréquentes
Ne pas limiter l'accessibilité à la seule interaction vocale : une borne doit toujours proposer des alternatives textuelles et tactiles. Evitez de considérer la reconnaissance vocale comme une solution universelle sans prévoir des scénarios de secours.
Ne confondez pas accessibilité logicielle et accessibilité matérielle. Des choix matériels inadéquats (écran non lisible en plein soleil, microphone mal positionné) peuvent rendre inutile une interface logicielle bien conçue.
Enfin, ne présumez pas de la conformité : incluez les personnes concernées dans le pilote et documentez les choix faits pour pouvoir les justifier en cas d'audit.
En pratique : préparer le pilote et le runbook d'exploitation
Intégrez les critères d'accessibilité dès la rédaction du cahier des charges et prévoyez des tests en conditions réelles avant la généralisation. Définissez des points de revue opérationnels pour vérifier la disponibilité des services vocaux et de transcription lorsque ceux-ci sont intégrés.
Documentez les procédures de maintenance matérielle et logicielle, les contacts pour les services tiers (par ex. fournisseur STT), et les scénarios de dégradé (mode texte uniquement si la fonction vocale est indisponible). Prévoyez enfin une consigne claire pour orienter les visiteurs vers une aide humaine lorsque l'avatar ne peut pas répondre.