Un chatbot utile doit savoir orienter vers une personne lorsque la réponse manque, qu’une décision est nécessaire ou que l’utilisateur le demande. Concevez ce passage avec le reste du parcours : canal disponible, informations transmises et confirmation de prise en compte.
Délimiter ce que le chatbot peut traiter
Séparez information générale, consultation d’un dossier et action métier. Un assistant documentaire peut expliquer une procédure sans être habilité à modifier une commande. Indiquez ses limites dans un langage compréhensible. La présence d’une interface de chat ne doit pas faire disparaître les moyens de contact habituels. Sur mobile, vérifiez qu’elle ne masque pas la navigation ou les informations essentielles.
Définir les déclencheurs du relais
Prévoyez au minimum la demande explicite de l’utilisateur, l’absence de source suffisante et les situations hors périmètre. Évitez les boucles où le modèle reformule indéfiniment la même réponse. Les déclencheurs doivent pouvoir être testés avec des exemples. Pour une question sensible, la fluidité d’une réponse ne prouve pas qu’elle constitue une décision autorisée.
Décrire le relais comme un parcours complet
Un bouton de contact ne suffit pas si personne ne sait ce qu’il transmet ou qui traitera la demande. Décrivez l’état initial, l’action de l’utilisateur, les informations proposées et la confirmation attendue. Le parcours peut rester simple : un résumé à relire, un formulaire et un canal de réception vérifié. L’important est de ne pas laisser croire que la demande a été prise en compte avant que l’application le confirme réellement.
| Situation | Réponse de l’interface | Vérification en recette |
|---|---|---|
| L’utilisateur demande une personne | Un moyen de contact accessible est proposé | Pas de boucle imposant de nouvelles reformulations |
| La documentation ne répond pas | La limite est annoncée et une suite utile est proposée | Aucune condition ou valeur inventée |
| Le service est fermé | La disponibilité réelle est expliquée | Aucun délai automatique non validé |
| Le canal échoue | Un message d’échec et une alternative sont disponibles | Aucune fausse confirmation d’envoi |
| Une décision métier est nécessaire | La demande est orientée vers le rôle compétent | Le modèle ne présente pas une modification comme réalisée |
Cette grille est une proposition de conception. Les permissions restent déterminantes : un assistant informatif ne doit pas pouvoir modifier un contrat ou un accès simplement parce que sa réponse le suggère. Les recommandations de l’OWASP pour les applications LLM aident à distinguer le texte produit des actions réellement autorisées.
Transmettre seulement ce qui aide
Le relais peut proposer un résumé que la personne relit avant envoi. Identifiez les informations nécessaires, le destinataire et le canal approuvé. Ne recopiez pas automatiquement toute la conversation si elle contient des données inutiles. Si le service est fermé, annoncez le moyen de laisser une demande et ce qui se passera ensuite, sans promettre un délai qui n’a pas été validé par l’équipe.
Exemple fictif : une demande de modification
Un visiteur veut changer une prestation déjà commandée. Le chatbot peut expliquer où trouver les informations utiles et proposer un contact, mais il ne confirme pas la modification. L’utilisateur vérifie un résumé de sa demande avant transmission. La page affiche une confirmation réelle de réception ou un message d’échec permettant de réessayer ; une formule générée ne remplace pas cette vérification.
Concevoir un résumé que la personne peut contrôler
- Limitez le résumé à la question, au contexte utile et aux éléments que l’utilisateur accepte de transmettre. Montrez-le avant l’envoi lorsque le parcours le permet.
- Indiquez le canal et le destinataire fonctionnel de la demande. Une formule vague comme « nous allons nous en occuper » ne décrit pas une réception vérifiable.
- Permettez de corriger le résumé. Une mauvaise reformulation par le modèle ne doit pas devenir la seule version de la demande conservée par l’équipe.
- Testez la réception avec des données de démonstration, puis le scénario d’échec. Vérifiez le parcours au clavier et sur un écran étroit, y compris lorsque la fenêtre de chat est ouverte.
Dans une simulation fictive, une personne souhaite faire évoluer une prestation déjà commandée. Le chatbot peut expliquer quelles informations préparer et proposer un résumé. Il ne confirme pas une acceptation ni une modification du dossier. L’équipe reçoit une demande exploitable et reste responsable de la décision. Cette séparation permet d’aider rapidement sans fabriquer un engagement commercial.
Pour un site d’agence, le relais peut orienter vers un échange de cadrage plutôt que chercher à résoudre immédiatement chaque situation. Prévoyez la revue des questions restées sans réponse pour améliorer la documentation. La préparation d’une base de connaissances et les tests de qualité du RAG deviennent alors complémentaires du travail sur le formulaire et sur la réception réelle des messages.
Tester la fin du parcours
Simulez une réponse introuvable, une demande humaine immédiate et une panne du canal de contact. Contrôlez clavier, lecture mobile et messages de confirmation. L’OWASP recense les risques liés aux sorties et aux accès des applications LLM : limitez donc les pouvoirs du chatbot à ce qui est nécessaire. Reliez ce travail à l’amélioration du formulaire de contact pour conserver une issue fiable.