# Recueil de scénarios

> Suivez un scénario de hub public ou explorez des scénarios Thalovant nommés, avec décisions, étapes et vérifications de réussite.

Source: https://docs.thalovant.com/fr/examples/scenarios/

---
{/* Last Edit: Claude Opus 5.5 - 2026-09-28 - Motive: Canadian French translation of the English page. */}

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

  
    Une personne qui découvre Thalovant crée une connexion restreinte pour un hub de la liste publique.
  
  
    Un espace de travail crée un hub à lui, une connexion et des règles d'accès restreintes.
  
  
    Une personne chargée de la révision découpe un accès large en ensembles de règles d'accès lisibles.
  
  
    Un membre de l'équipe de soutien remonte la piste dans Dashboard, Clients, Access rules et Topology.
  
  
    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.
  
  
    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.

  
    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.
  
  
    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](/fr/workspace/billing-and-plans/). 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](/fr/account/api-tokens/).
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](/fr/developers/provisioning/) 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