Ressources · 42
Assistant conversationnel accessible : multimodalité, erreurs et relais humain
Concevoir un assistant de service que chacun peut utiliser, comprendre et quitter pour obtenir une aide humaine sans recommencer sa demande.
· 18 min
Ce que ce guide permet
- Rendre entrée et sortie utilisables par plusieurs modes
- Permettre de comprendre et corriger une réponse
- Définir quand et comment joindre une personne
- Vérifier le parcours avec des utilisateurs et des cas difficiles
Contrôle express
- Le service fonctionne-t-il au clavier et avec une technologie d’assistance pertinente ?
- Un utilisateur peut-il lire une réponse sans dépendre de la voix ou d’un effet visuel ?
- Les messages d’erreur expliquent-ils comment reprendre ?
- La réponse distingue-t-elle un fait vérifié d’une hypothèse ?
- Le relais humain est-il trouvable avant et après un échec ?
- La personne de support reçoit-elle seulement le contexte nécessaire, avec le choix de l’utilisateur ?
Méthode pas à pas
- 01
Définir des tâches et des limites explicites
Choisissez des demandes réelles : trouver une information, corriger un compte, comprendre un tarif et demander une aide humaine. Indiquez ce que l’assistant peut expliquer, proposer ou transmettre, et ce qu’il ne doit jamais décider seul.
Livrable : carte des tâches, des données nécessaires et des seuils de relais.
- 02
Offrir plusieurs façons d’interagir
Vérifiez texte, clavier, focus, ordre de lecture, contraste, zoom et annonces de nouveaux messages. Si la voix est proposée, gardez une voie textuelle complète et des contrôles pour ralentir, relire ou interrompre.
Livrable : parcours testés sur appareils et modes d’entrée représentatifs.
- 03
Rendre réponse et erreur réparables
Une réponse doit permettre de voir d’où vient l’information lorsque la décision l’exige. Évitez les formulations qui affirment une certitude absente. En cas d’ambiguïté, reformulez le besoin, gardez la saisie utile et proposez une action suivante claire.
Livrable : scénarios de réponse correcte, incertaine, erronée et sans réponse.
- 04
Concevoir le passage à une personne
Définissez les motifs de relais : demande explicite, répétition d’échecs, situation sensible, désaccord ou action hors périmètre. Présentez le canal, sa disponibilité et les informations qui seront transmises ; laissez l’utilisateur corriger ou retirer ce contexte.
Livrable : protocole de relais, résumé contrôlable et responsable de réception.
- 05
Tester la continuité de bout en bout
Rejouez chaque tâche avec des profils, capacités et environnements variés, puis suivez ce qui se passe après le transfert. Mesurez la résolution et les abandons, examinez les erreurs graves et revoyez le service après un changement de modèle ou de contenu.
Livrable : jeu de tests daté, constats priorisés et décision de publication.
Exemple d’application
Situation illustrative
Une cliente souhaite comprendre pourquoi un remboursement annoncé n’apparaît pas. L’assistant lui propose d’abord une réponse générale, puis reconnaît qu’il ne peut pas vérifier l’état de son dossier. Au clavier et avec un lecteur d’écran, elle accède au même bouton de relais.
Décision et preuve attendue
Avant transfert, elle voit et corrige un résumé sans données bancaires. L’agente humaine reçoit le motif, les étapes déjà essayées et la question non résolue ; la cliente n’a pas à répéter le parcours. Le test note le temps de reprise et la résolution, pas seulement le nombre de conversations automatisées.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Tâche accomplie | Part des scénarios résolus sans information trompeuse, par mode d’accès | Corriger le parcours ou réduire le périmètre |
| Relais effectif | Demandes de relais arrivées à une personne avec contexte utile | Réparer disponibilité, résumé ou routage |
| Erreur récupérable | Échecs où l’utilisateur peut corriger et poursuivre sans tout ressaisir | Réviser messages et conservation de l’état |
| Qualité de réponse | Réponses vérifiées sur un jeu de cas daté, y compris les cas sans réponse | Actualiser sources et seuils de refus |
Erreurs fréquentes
- Présenter la voix comme seule voie accessible
- Déplacer le focus à chaque message sans contrôle
- Donner une réponse assurée lorsque la source manque
- Cacher le contact humain derrière plusieurs refus
- Transmettre toute la conversation sans nécessité ni choix
- Mesurer seulement la réduction des demandes au support
Questions fréquentes
Un chatbot accessible suffit-il à rendre le service accessible ?
Non. Les pages, formulaires, canaux de transfert et réponses reçues après le relais font partie de la même tâche.
Le relais doit-il attendre plusieurs échecs ?
Non. Une personne doit pouvoir le demander directement ; un échec répété ou une situation sensible peuvent aussi le déclencher.
La note du W3C sur les interfaces naturelles est-elle une norme de conformité ?
Non. Elle décrit des besoins utilisateurs et reste un document de travail. Les critères WCAG applicables au service web se vérifient séparément.
Faut-il conserver toute la conversation pour aider l’agent ?
Transmettez seulement le contexte nécessaire à la demande, indiquez-le à l’utilisateur et prévoyez correction ou retrait avant transfert.
Références officielles
Pour aller plus loin
Analyses associées
