Recueil de scénarios

Utilisez ce recueil quand vous comprenez les mots de base et voulez des exemples réalistes. Chaque scénario nomme l’objectif, l’ordre à suivre sans risque et les vérifications qui prouvent que la configuration est en bon état.

Ces exemples ne sont pas des scripts à copier tels quels. Reprenez la structure et choisissez des noms qui conviennent à votre propre espace de travail.

Index des scénarios

Essayer un hub public

Une personne qui découvre Thalovant crée une connexion restreinte pour un hub de la liste publique.

Créer un hub de soutien privé

Un espace de travail crée un hub à lui, une connexion et des règles d’accès restreintes.

Revoir les accès de l'équipe

Une personne chargée de la révision découpe un accès large en ensembles de règles d’accès lisibles.

Réparer un client périmé

Un membre de l’équipe de soutien remonte la piste dans Dashboard, Clients, Access rules et Topology.

Changer le runtime d'un seul hub

Une personne qui bâtit le hub crée un ensemble de compétences distinct avant de toucher aux valeurs par défaut partagées.

Provisionner un hub par le code

Un développeur crée un groupe de runtime et un hub avec un jeton d’API plutôt que dans le tableau de bord.

Scénario 1 : essayer un hub public

Objectif : explorer un hub public sans créer de hub à vous.

Ce scénario de hub public est le chemin le plus court vers une première réponse, puisqu’aucun hub à vous n’entre en jeu.

1. Ouvrez Public hubs (hubs publics) et choisissez une fiche qui indique clairement à qui elle s’adresse.
2. Créez une seule connexion, nommée d’après l’application, l’appareil ou l’essai.
3. Utilisez des règles d’accès restreintes qui correspondent à la première tâche.
4. Utilisez le lien de configuration et gardez les éléments de configuration privés.
5. Vérifiez Dashboard (tableau de bord) pour le nombre de clients et tout élément qui demande votre attention.

Si tout va bien : un client existe pour un hub public, et le nom de la règle d’accès explique pourquoi cet accès existe.

Scénario 2 : créer un hub de soutien privé

Objectif : créer un hub qui appartient à l’espace de travail pour un comptoir de soutien.

Élément	Exemple de nom	Pourquoi ça aide
Hub	support-frontdesk	Nomme la destination et son rôle.
Client	frontdesk-client	Nomme ce qui se connecte.
Règles d’accès	frontdesk-questions-only	Montre que l’accès est restreint avant même qu’on ouvre la règle.
Choix du runtime	valeur par défaut de l’espace de travail	Garde la première configuration petite.

Vérifiez d’abord Billing (facturation) si le hub, la connexion, une entrée payante du Skill Store ou l’action d’adresse est verrouillé. Ensuite, créez le hub, créez la connexion, ajoutez les règles d’accès et vérifiez Dashboard.

Si tout va bien : Dashboard affiche le hub et le client attendus, et Topology montre le client quand l’état en direct est disponible.

Scénario 3 : revoir les accès de l’équipe

Objectif : rendre les accès lisibles avant d’ajouter d’autres connexions.

Commencez par repérer les ensembles de règles d’accès aux noms vagues comme default, full ou temporary. Puis séparez-les selon leur raison d’être.

Au lieu de	Créez
Un seul ensemble large par défaut	frontdesk-questions-only
Un seul ensemble de service partagé	skill-status-read
Un seul ensemble large temporaire	temporary-review-window, avec une date de fin dans les notes

Si tout va bien : chaque ensemble de règles d’accès peut être revu sans ouvrir de clients qui n’ont rien à voir.

Scénario 4 : réparer un client périmé

Objectif : comprendre pourquoi frontdesk-client apparaît comme stale (périmé) dans Topology.

Ordre de vérification

1. Ouvrez Dashboard et notez l’élément qui demande votre attention.
2. Ouvrez Clients et confirmez que le client est actif et rattaché à support-frontdesk.
3. Confirmez que le lien de configuration ou le fichier de connexion est toujours privé et placé avec l’application qui se connecte.
4. Ouvrez Access rules (règles d’accès) et confirmez que le client est lié au hub.
5. Ouvrez Topology et comparez les états stale, missing, warning et connected.

Cause probable

1. Absent de Clients : habituellement, le client n’a pas été créé ou il a été supprimé.
2. Présent mais hors ligne : habituellement, ce sont les éléments de configuration ou l’application en cours d’exécution qui demandent votre attention.
3. Présent mais bloqué : habituellement, il faut revoir Access rules.
4. Visible dans Dashboard mais stale dans Topology : habituellement, la dernière mise à jour en direct n’est pas encore arrivée.

Si tout va bien : le symptôme mène à une seule page responsable plutôt qu’à une supposition.

Scénario 5 : changer le runtime d’un seul hub

Objectif : changer la langue ou l’emplacement d’un seul hub sans changer tous les hubs qui utilisent les compétences par défaut.

1. Créez ou choisissez un ensemble de compétences distinct pour le hub concerné.
2. Attribuez seulement le hub visé à cet ensemble de compétences.
3. Ouvrez Runtime config pour cet ensemble de compétences.
4. Changez la langue, l’emplacement, la parole ou les compétences bloquées seulement là où c’est nécessaire.
5. Vérifiez Dashboard et Topology avant de déplacer d’autres hubs vers le même ensemble de compétences.

Si tout va bien : seul le hub visé utilise les valeurs par défaut du runtime modifiées.

Scénario 6 : expliquer un bouton verrouillé

Objectif : déterminer si une action verrouillée relève du forfait ou de la configuration.

Commencez par Facturation et forfaits. Lisez la carte du forfait, l’utilisation actuelle et le message à côté de l’action verrouillée. Les actions verrouillées les plus courantes sont la création d’un autre hub, l’ajout d’une autre connexion, une entrée payante du Skill Store, la définition de l’adresse d’un hub ou une option de soutien qui relève d’un autre forfait.

Si tout va bien : la personne sait s’il faut changer de forfait, réduire son utilisation ou retourner à la page d’origine pour poursuivre la configuration.

Scénario 7 : provisionner un hub par le code

Objectif : créer un groupe de runtime et un hub à partir d’un script plutôt que du tableau de bord.

1. Créez un jeton d’API avec la portée d’écriture des hubs sur la page Jetons d’API.
2. Parcourez d’abord le catalogue de compétences. La lecture du catalogue fonctionne avec tous les forfaits : vous pouvez donc décider ce que le hub fera tourner avant de passer à un forfait supérieur.
3. Créez le groupe de runtime, puis créez le hub qui y est rattaché.
4. Installez une compétence dans le groupe de runtime et publiez les deux sur un canal.
5. Vérifiez Dashboard pour voir le nouveau hub, puis connectez-y un client.

Si tout va bien : le hub apparaît dans le tableau de bord exactement comme un hub créé à la main. Et le script peut être relancé sans risque, puisque la création de hub accepte une clé d’idempotence.

Consultez Provisionner des hubs pour les appels, les règles de portée et de forfait, et le tableau des erreurs.

Créer votre propre scénario

Suivez ce modèle :

1. Nommez l’objectif. Gardez-le court et précis.
2. Nommez le hub. Le nom du hub doit expliquer la destination.
3. Nommez la connexion. Le nom de la connexion doit expliquer ce qui se connecte.
4. Nommez les règles d’accès selon leur raison d’être. Le nom doit accélérer la révision.
5. Choisissez la première vérification de santé. Dashboard d’abord, puis Topology quand l’état en direct compte.

Faire la première configuration