Chat

Le déclencheur Chat transforme un workflow en un chat que vos visiteurs peuvent utiliser, sur une page hébergée par Scrydon ou à l'intérieur de votre propre site web. Chaque message envoyé par un visiteur exécute le workflow une fois. Un bloc Chat Reply renvoie la réponse.

Le construire

1. Ajoutez un déclencheur Chat. Un workflow doté d'un déclencheur Chat n'a aucun autre déclencheur.
2. Ajoutez les blocs qui élaborent la réponse, par exemple un bloc Knowledge et un bloc Agent. Utilisez <chat.message> pour le message du visiteur et <chat.history> pour les tours précédents (<chat.sessionId> est l'identifiant de session du visiteur). <chat.history> est une liste de tours {role, content}, du plus ancien au plus récent, que Scrydon charge depuis la conversation elle-même ; un visiteur ne peut pas l'envoyer. Pour qu'un Agent réponde en tenant compte de la conversation, référencez les deux dans son message, par exemple Conversation jusqu'ici : <chat.history> suivi de Question : <chat.message>.
3. Terminez par un bloc Chat Reply. Son message est ce que le visiteur voit. Le premier Chat Reply atteint par l'exécution répond ; l'exécution se poursuit ensuite.
4. Cliquez sur Deploy (le bouton affiche Versions une fois tout déployé), ouvrez Paramètres d'exécution, choisissez l'environnement puis un compte de service sous Exécuter en tant que. Chaque environnement a le sien. Une URL en production s'exécute toujours sous ce compte, jamais sous votre identité, et un workflow sans compte de service ne peut être ni déployé ni promu. L'URL de test s'exécute aussi sous ce compte ou, tant qu'aucun n'est choisi, sous votre identité. Le menu Exécuter en tant que à côté du bouton Run de la barre d'outils ne modifie qu'une seule exécution manuelle.

Les paramètres du déclencheur Chat sont Title, Welcome message, Suggested questions, Theme colour, Avatar (un ou deux caractères, ou un emoji), Fallback message (affiché lorsqu'une exécution se termine sans atteindre un Chat Reply) et History depth (nombre de messages précédents transmis à l'exécution : de 0 à 50, 10 par défaut). Sous ces paramètres, le panneau du déclencheur contient les réglages propres à l'interface : l'interrupteur Interface activée, Partager, Accès, Limites et Conversations.

L'URL

Le chat se trouve sous l'URL publique de l'application agentic : sa forme dépend donc du mode de routage de votre déploiement :

Le préfixe /agentic en mode sous-chemin fait partie de l'adresse. Copiez l'URL depuis la section Partager plutôt que de la construire à la main. L'identifier est une chaîne aléatoire générée par le serveur ; il ne peut pas être deviné, et pour un lien sans mot de passe, posséder l'URL suffit pour y accéder.

L'essayer avant de déployer

Une fois le workflow enregistré, le panneau du déclencheur affiche une URL de test sous Partager. Elle exécute votre brouillon actuel, sous le compte Run As (sous votre identité tant qu'aucun n'est choisi), avec les mêmes règles que celles d'un visiteur. Sous votre identité, les réponses d'un chat de test ne citent aucune source : les citations sont lues sous le compte de service. Seules les personnes connectées à Scrydon avec un accès en modification au workflow peuvent l'ouvrir. Ouvrir le chat de test l'ouvre dans un nouvel onglet. Les conversations de test sont signalées comme des tests dans Conversations.

Le panneau indique d'abord qu'il crée l'URL de test. Si cela dure plus d'environ une minute, il indique que l'URL de test n'a pas été créée et propose Réessayer ; rechargez l'éditeur si elle n'apparaît toujours pas. Un workflow qui n'appartient à aucun environnement (une automatisation d'espace de travail) n'obtient jamais d'interface, donc pas d'URL de test : construisez le chat dans un workflow qui appartient à un environnement.

Passer en production

Une URL en production appartient à un environnement. Promouvez le workflow vers l'environnement suivant et déployez-le : la copie de cet environnement obtient sa propre URL en production, épinglée à la version déployée, et son panneau l'affiche sous la forme URL en production, version N. Déployer le workflow modifiable ne publie rien. Promouvoir à nouveau conserve l'URL, donc les intégrations continuent de fonctionner. Une organisation qui n'a qu'un seul environnement a une URL de test et aucune URL en production. URL en production des autres environnements liste les copies des autres environnements ; modifiez le mot de passe, les origines et les limites d'une URL en production depuis la copie de cet environnement. Dans un environnement que vous ne pouvez pas modifier, comme la production, l'éditeur ne s'ouvre pas : l'onglet Partager de la page du workflow affiche l'URL en production, les extraits d'intégration et l'état de Interface activée, et Monitor affiche l'URL en production sur la ligne du déclencheur du workflow, avec un bouton de copie.

L'intégrer à votre site web

Les extraits Intégrer apparaissent sur une URL en production.

• Lien vers la page hébergée.
• Iframe : copiez l'extrait depuis le panneau.
• Bulle de chat : collez le script du lanceur pour obtenir un bouton de chat.
• Votre propre interface : utilisez le client d'interface.

<script src="https://app.example.com/agentic/embed/chat.js" data-interface="<identifier>" async></script>

Le script ajoute un bouton de chat. Pour une page qui n'est pas en anglais, définissez data-label-open (le nom accessible du bouton, « Open chat » par défaut) et data-title (le titre du cadre de chat, « Chat » par défaut). Échap ferme le chat et rend le focus au bouton, que le focus soit sur votre page ou dans le chat. La page du chat demande la fermeture au lanceur par un message sans donnée, et le lanceur ne l'accepte que de son propre cadre de chat.

<iframe src="https://app.example.com/agentic/chat/<identifier>?embed=1" title="Chat"
  width="400" height="600" style="border:0"
  sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-popups-to-escape-sandbox" referrerpolicy="strict-origin-when-cross-origin"></iframe>

Ajoutez l'origine de votre site (par exemple https://www.example.com) aux Origines autorisées de l'interface. Les autres sites ne peuvent ni intégrer le chat dans une iframe ni appeler son API. Règles :

• Les origines commencent par https:// ; seule l'origine nue compte, donc un chemin ou une requête est ignoré.
• Les caractères génériques (*), y compris https://*.example.com, ne sont jamais acceptés. Listez chaque origine.
• L'hôte doit être un nom d'hôte public ordinaire : les adresses privées, de bouclage et de métadonnées cloud sont rejetées, de même que les ports bloqués par le validateur d'URL.
• Au plus 50 origines, de 512 caractères chacune.
• Une liste vide signifie que seul Scrydon lui-même peut intégrer la page dans une iframe.

Une URL de test ne peut pas être intégrée à un autre site.

Ce que les visiteurs peuvent lire et écrire

L'exécution d'un visiteur ne lit que les documents explicitement étiquetés avec l'étiquette la plus basse de votre schéma de classification (par exemple PUBLIC). Un document sans étiquette n'est jamais utilisé, quelle que soit l'étiquette par défaut de la base de connaissances. La section Partager nomme cette étiquette et vous avertit lorsqu'un bloc Knowledge du workflow n'a aucun document qu'un visiteur peut lire.

L'exécution d'un visiteur ne peut écrire ni dans une base de connaissances, ni dans Memex, ni dans le stockage : rien de ce qu'envoie un visiteur n'est enregistré dans les connaissances ou les fichiers de votre organisation.

• Un bloc Knowledge réglé sur Add Data, ou un bloc Storage réglé sur Write File ou Delete File, empêche de déployer ou de promouvoir le workflow avec un déclencheur Chat ou Form. Réglez plutôt le bloc sur une lecture.
• Dans l'exécution d'un visiteur, un bloc Agent ne se voit pas proposer les outils qui écrivent dans une base de connaissances ou dans le stockage. Si vous en avez sélectionné un vous-même, l'Agent s'arrête en indiquant la raison.
• L'outil Workflow Executor n'est pas disponible dans l'exécution d'un visiteur, car le workflow qu'il lance ne suivrait pas ces règles. Utilisez un bloc Workflow pour appeler un autre workflow : il s'exécute sous les mêmes règles.

Accès et limites

• Mot de passe : facultatif, défini sous Accès (de 8 à 256 caractères). Le modifier ou le supprimer déconnecte tous les visiteurs. Une interface protégée par mot de passe exige https à la fois sur la page qui l'intègre et sur l'hôte Scrydon : le cookie de connexion est SameSite=None; Partitioned, que les navigateurs rejettent en http simple.
• Limites (valeurs par défaut, modifiables sous Limites) : Message le plus long (caractères) 2 000 (de 1 à 20 000), Messages par conversation 50 (de 1 à 1 000), Messages par jour, tous visiteurs confondus 1 000 (de 1 à 1 000 000 ; le quota se renouvelle toutes les 24 heures), Conserver les conversations pendant (jours) 30 (de 1 à 365).
• Conversations : Ouvrir les conversations les liste de la plus récente à la plus ancienne. Affichez les visiteurs, les tests ou tout, lisez une transcription, et utilisez Effacer la conversation lorsqu'un visiteur le demande. L'effacement supprime les messages et retire le texte du visiteur des exécutions qui y ont répondu. Une conversation dont l'exécution est en cours ne peut pas être effacée avant la fin de cette exécution. Un visiteur dont la conversation a été effacée, ou a expiré, en démarre une nouvelle avec son message suivant.
• Rétention : une conversation est effacée au bout du nombre de jours défini après son dernier message. Les conversations expirées sont purgées toutes les heures, donc l'une d'elles peut survivre à son expiration jusqu'à une heure. Une conversation dont l'exécution est en cours est conservée jusqu'à la fin de cette exécution : c'est-à-dire en cours d'exécution, ou en attente d'une approbation à laquelle personne n'a répondu.

Lorsqu'un visiteur est refusé

Un visiteur dont le navigateur bloque les cookies tiers peut tout de même discuter dans votre site ; chaque message démarre alors une nouvelle conversation.

Dépannage