Comment les agents conversationnels compagnons doivent-ils reconnaître le souhait d’un utilisateur d’arrêter ?

Partir des mots de l'utilisateur, et non d'une théorie sur son humeur

Des messages comme « stop », « j'ai fini », « ça suffit », « au revoir » ou « on s'arrête là » sont des preuves directes que l'utilisateur souhaite mettre fin à l'échange. Intégrez ces expressions, ainsi que leurs variantes naturelles, dans la gestion de l'arrêt du produit. Considérez-les comme des consignes de contrôle tout au long de la conversation, y compris lors d'une activité créative ou pendant que le système pose une question.

Cette démarche suit les directives établies en matière de design conversationnel. Google recommande de respecter les formulations telles que « j'ai terminé » et « laisse tomber », et préconise de ne pas remettre en question le choix d'une personne qui souhaite quitter une tâche inachevée lorsque peu de progrès risquent d'être perdus. Amazon Lex définit de manière similaire une intention d'arrêt (« stop intent ») pour les expressions indiquant que l'utilisateur souhaite clore une interaction. (Recommandations de Google sur la fin des conversations ; intention d'arrêt intégrée d'Amazon Lex)

La réponse du produit doit accuser réception de la consigne une seule fois, puis clore le tour de parole. Par exemple : « C'est noté. Nous pouvons nous arrêter là. » Ne faites pas suivre cet accusé de réception d'une autre question, d'une invitation à poursuivre ou d'une demande de justification. Une commande d'arrêt ne doit pas se transformer en une micro-négociation obligeant l'utilisateur à se répéter.

Considérer l'accomplissement d'une tâche comme une fin naturelle

Un utilisateur peut avoir terminé sans formuler explicitement « stop ». Il a pu demander une courte histoire et la recevoir, choisir une idée d'activité pour le week-end ou finaliser la révision d'un message. Dès lors que le résultat demandé a été fourni et qu'aucun point de la tâche n'est en suspens, le système peut conclure par une déclaration concise comme « Voici la version finale » ou « Cela vous fait un plan pour samedi ». Il n'est pas nécessaire d'ajouter systématiquement « Que souhaitez-vous faire d'autre ? ».

Il s'agit d'une déduction de conception issue du principe voulant que les réponses conversationnelles restent brèves, pertinentes et concentrées sur la tâche. La checklist de design conversationnel d'Amazon préconise un nombre minimal d'étapes ainsi que des messages ciblés, et déconseille d'interrompre une expérience par une suggestion sans rapport. Appliqué aux agents conversationnels compagnons, cela revient à conditionner les questions de relance à l'existence d'une réelle étape suivante, plutôt que d'en greffer une à chaque réponse terminée. (Principes de design conversationnel d'Amazon Alexa)

Il existe des exceptions. Si la demande comporte plusieurs volets, le système doit mener à terme les éléments convenus ou préciser clairement ce qui reste à faire. Si un utilisateur demande un brouillon puis une révision, lui renvoyer uniquement le brouillon ne constitue pas une tâche accomplie. En revanche, une fois le cadre convenu respecté, une relance ouverte risque de donner l'impression qu'une interaction terminée est toujours en cours. Une conclusion concise évite que le système n'étende insidieusement la tâche de l'utilisateur.

Rendre la pause facile à formuler et simple à reprendre

Mettre en pause est différent de mettre fin. « Faisons une pause », « je reviendrai là-dessus », « un instant » ou « garde ça pour plus tard » peuvent signaler le besoin d'un temps d'arrêt tout en conservant le travail. Lorsque le produit prend en charge l'historique des conversations ou la sauvegarde de brouillons, il peut confirmer en langage clair ce qui restera accessible. S'il n'est pas en mesure de conserver l'état actuel, il doit l'indiquer avant le départ de l'utilisateur lorsque cette contrainte importe.

Laissez la pause sous le contrôle de l'utilisateur. N'exigez aucune explication et ne présumez d'aucun motif pour cette interruption. Si le produit dispose d'une commande visible de pause ou de fermeture, nommez-la clairement et attribuez-lui un comportement prévisible. Les recommandations du W3C sur le contrôle par l'utilisateur indiquent que les changements de contexte doivent être initiés par l'utilisateur ou pouvoir être désactivés ; ce principe justifie des commandes limpides et des comportements prévisibles lors des transitions. (Directives du W3C sur le Changement à la demande)

Le produit doit également distinguer une pause d'un arrêt explicite à partir des mots et des actions proposés par l'interface. Une pause peut conserver un brouillon ou l'avancement d'une tâche si la fonctionnalité est prise en charge. Un arrêt doit mettre un terme à l'interaction en cours. N'affirmez pas qu'une conversation est enregistrée si ce n'est pas réellement le cas, et n'interprétez pas la sortie de l'application ou le silence comme une demande d'envoi de messages supplémentaires.

Suivre un ordre clair pour les signaux ambigus et explicites

Une hiérarchie utile des signaux pour l'implémentation est la suivante :

Arrêt explicite ou au revoir : clore l'échange immédiatement.

Demande explicite de pause ou de sauvegarde : suspendre ou sauvegarder si cette option est prise en charge, puis confirmer brièvement le résultat.

Demande accomplie : fournir le résultat attendu et conclure sans exiger de nouveau tour de parole.

Message ambigu : poser une seule courte question de clarification uniquement lorsque l'ambiguïté bloque la poursuite de la tâche.

Silence : patienter ou fermer la session active selon le fonctionnement habituel du produit ; ne pas en déduire un état émotionnel.

Cet ordonnancement est une proposition pratique de conception, non une mesure standardisée ou un classificateur universel. Son objectif est d'éviter que des instructions directes soient supplantées par des hypothèses incertaines. Par exemple, « Ça suffit » doit l'emporter sur la prédiction du système supposant qu'une suggestion connexe serait bienvenue. Une question telle que « Souhaitez-vous vous arrêter là ou enregistrer pour plus tard ? » n'est pertinente que si la formulation de l'utilisateur laisse réellement planer un doute sur ces issues.

Si un produit exécute une action lourde de conséquences ou risque d'entraîner la perte d'un travail significatif, une confirmation peut être appropriée pour protéger ce travail. Veillez à ce que cette confirmation soit précise et facile à traiter : « Voulez-vous quitter maintenant et abandonner ce brouillon ? ». Dans le cas d'une conversation ordinaire où peu d'avancées sont en jeu, des confirmations répétées créent des frictions superflues. Les recommandations de Google formulent la même distinction : ne demandez pas de confirmation de sortie à moins qu'une perte notable d'avancement ne soit en jeu. (Recommandations de Google sur la fin des conversations)

Formuler une réponse de clôture brève et complète

Un message de fin ne doit avoir qu'une seule fonction : signifier clairement que le système a compris l'utilisateur et que l'interaction est close ou suspendue. Voici des exemples adaptés :

Arrêt : « Entendu. Nous nous arrêtons là. »

Tâche créative terminée : « Voici le poème révisé. »

Pause avec sauvegarde : « En pause. Votre brouillon est conservé dans cette discussion. »

Pause sans option de sauvegarde : « D'accord. Vous pourrez revenir à cette conversation plus tard, mais je ne peux pas enregistrer de brouillon distinct. »

N'utilisez que des formulations fidèles aux capacités réelles du produit. Évitez tout appel à l'émotion, toute remarque culpabilisante ou toute relance sous forme de question. Une conclusion peut rester bienveillante sans demander à l'utilisateur de rassurer le système ni de prolonger l'échange. L'objectif de conception est d'offrir une fin limpide et digne de confiance.

Tester les cas limites, pas seulement les commandes évidentes

Passez en revue des exemples courts d'interactions courantes : un arrêt direct au cours d'un récit, « ça suffit » après une recommandation, une tâche d'écriture achevée, une demande de pause en cours de route et un « peut-être plus tard » ambigu. Vérifiez que chaque situation entraîne le comportement prévu et qu'aucune relance n'apparaît après un arrêt clair ou une tâche terminée.

Surveillez également les faux positifs. La phrase « Arrête d'employer cette expression et essaie-en une autre » comporte le mot « arrête », mais il s'agit d'une consigne liée à la tâche et non nécessairement d'un souhait de clore la discussion. Interprétez les termes en contexte, tout en maintenant une commande d'arrêt dédiée accessible en cas de mauvaise interprétation du système. La documentation d'Amazon décrit une intention d'arrêt intégrée pour les expressions d'arrêt habituelles ; un agent conversationnel compagnon peut s'appuyer sur cette même logique de base tout en adaptant la détection à son interface textuelle ou vocale. (Intention d'arrêt intégrée d'Amazon Lex)

Consignez les défaillances concrètes, telles qu'une demande d'arrêt suivie d'une autre question, une tâche finie déclenchant une suggestion non sollicitée, ou une pause entraînant la perte du travail après avoir laissé entendre qu'il était enregistré. Il s'agit de vérifications comportementales observables, non de suppositions sur les ressentis de l'utilisateur. Elles permettent aux équipes de perfectionner l'interaction sans chercher à analyser l'état d'esprit des personnes à partir de leurs mots.

Une règle simple pour une conclusion respectueuse

Lorsque l'utilisateur met clairement fin à l'échange, arrêtez-vous. Lorsque la tâche convenue est finie, concluez brièvement. Lorsque l'utilisateur demande une pause, préservez son autonomie et précisez les modalités de sauvegarde effectives. Ne posez de relance que si elle est indispensable pour achever la demande ou lever une véritable ambiguïté. Cela procure aux agents conversationnels compagnons une méthode concrète pour identifier les conclusions d'échange, tout en laissant à l'utilisateur le plein contrôle de ses choix, de son rythme et de la suite à donner.

Continuer sur ce thème