Un utilisateur clique sur Envoyer après que l’assistant a annoncé « Envoyer la facture à Alice », car l’interface donne l’impression que c’est bien cette action qui va être effectuée.
L’interface exécute alors une requête dont le véritable destinataire est bob@vendor.com, et l’utilisateur ne s’en aperçoit qu’une fois la facture arrivée dans la mauvaise boîte de réception.
Cette défaillance ne nécessite en rien que le modèle « pirate » le produit.
L’erreur survient à la frontière de l’interface, là où le texte généré est validé par un humain et où l’interface laisse la description fluide de l’assistant se substituer aux paramètres qui seront réellement exécutés.
L’exemple suivant présente une interface d’assistant minimaliste qui met en évidence ce décalage dès que l’on clique sur le bouton.
Ce code rend le problème concret en dissociant ce qu’affiche l’interface de ce que l’action transmettrait réellement ; un simple clic permet de visualiser la charge utile effective que le produit enverrait.
Le décalage que nous venons d’observer s’explique par le fait qu’un flux d’assistant côté client comporte plusieurs étapes distinctes, chacune pouvant engendrer un type différent de croyance erronée ou dangereuse.
Nous pouvons identifier quatre étapes gérées par le frontend et les associer toutes au même scénario d’« envoi de facture », afin que les correctifs ultérieurs soient appliqués au point adéquat du flux.
L’intérêt de distinguer ces étapes réside dans le fait que chacune nécessite un mécanisme de contrôle spécifique ; ainsi, l’affichage d’une bannière d’avertissement à une étape inadaptée ne permet pas d’éviter le problème.
Le schéma suivant met en évidence les deux frontières cruciales dans le cadre de ce cours : celle où le texte devient du DOM et celle où la validation se transforme en requête.