# Règles d'accès

> Comprendre comment les règles d'accès relient les clients aux hubs et gardent l'accès clair.

Source: https://docs.thalovant.com/fr/concepts/access-rules/

---
{/* Last Edit: Claude Opus 5.5 - 2026-09-28 - Motive: Canadian French translation of concepts/access-rules.mdx. */}

Les **règles d'accès** décident de ce qu'un client peut faire ou non sur un hub.

Le hub répond à la question **où le client se connecte-t-il?** Le client répond à **qu'est-ce qui se connecte?** Les règles d'accès répondent à **qu'est-ce qui est permis?**

Créez les règles d'accès une fois que le [client](/fr/concepts/clients/) existe et que le [hub](/fr/concepts/hubs/) est bien défini. Utilisez ensuite [Topology](/fr/concepts/topology/) pour confirmer que le client connecté se comporte comme prévu.

  La barre latérale appelle cette page **Access rules**. L'URL et l'API disent encore `acl`,
  et les deux désignent la même chose.

## Ce qu'est une règle

Une règle d'accès, c'est ce qu'un client a le droit de faire sur un hub, mis par écrit. Vous la créez une fois le client en place, parce que la règle nomme le client. Elle contient le hub, les clients qu'elle couvre, ce qui est permis, ce qui est bloqué et une note qui explique pourquoi. Commencez étroit, un seul objectif par règle, et traitez « tout » comme l'exception qu'il faut justifier.

## Ce que contient une règle d'accès

L'éditeur vous donne deux listes et un peu de contexte :

- le **hub** auquel elle s'applique;
- les **clients liés** qui la reçoivent;
- les **règles d'autorisation** (Allow rules) : ce que le client peut faire;
- les **règles de refus** (Deny rules) : ce qu'il ne peut pas faire, peu importe ce que dit la liste d'autorisation;
- un **nom** et une **description**, pour qu'un collègue puisse comprendre plus tard pourquoi elle existe.

## Trois formes qui reviennent souvent

Ce sont des habitudes, pas des boutons. L'éditeur est le même dans chaque cas; ce
qui change, c'est ce que vous mettez dans la liste d'autorisation.

  
  
  

**Actions nommées** n'autorise que ce que vous énumérez. C'est le bon choix par défaut, et
c'est ce que la plupart des clients devraient avoir.

**Actions nommées, plus refus** ajoute une liste de refus par-dessus. Un refus l'emporte toujours; c'est donc
ainsi que vous gardez une capacité hors de portée d'un client qui a par ailleurs
besoin d'une autorisation large. Cette forme convient à tout ce qui est exposé au public.

**Grand ouvert** autorise tout. Ne l'utilisez que si vous faites confiance à l'objectif du client
et que vous avez jugé le risque acceptable. Consignez alors cette décision dans la
description, parce que la prochaine personne qui la lira va poser la question.

## Comment lire une règle d'accès

Lisez les règles d'accès de haut en bas :

1. **Hub :** l'endroit où ces règles d'accès s'appliquent.
2. **Clients liés :** les clients qui reçoivent ces règles d'accès.
3. **Actions permises :** ce que ces clients peuvent faire.
4. **Actions bloquées :** ce qui reste bloqué.
5. **Notes :** pourquoi ces règles d'accès existent.

Si le nom du client et celui des règles d'accès n'expliquent pas clairement leur lien, renommez-les ou décrivez-les avant d'ajouter d'autres règles.

## Créer des règles d'accès

Créez les règles d'accès une fois le client en place. Le lien entre les deux sera alors plus facile à lire.

1. **Ouvrez Access rules.** Sélectionnez Create.
2. **Choisissez un hub.** Les règles d'accès s'appliquent toujours à un seul hub.
3. **Nommez les règles d'accès.** Utilisez un nom fondé sur l'objectif, comme `frontdesk-questions-only`.
4. **Liez des clients.** Sélectionnez les clients qui doivent recevoir cet accès.
5. **Choisissez la forme.** Utilisez un accès étroit pour la plupart des clients.
6. **Révisez les actions permises et bloquées.** Autorisez seulement ce qui est nécessaire et bloquez les actions risquées.

Avant d'enregistrer, formulez les règles d'accès en une phrase simple :

> Ces clients peuvent faire ces actions sur ce hub, et ces actions-là restent bloquées.

Si cette phrase est difficile à dire, divisez les règles d'accès ou renommez-les avant d'ajouter d'autres connexions.

## Protections par défaut des hubs publics

Pour l'accès à un hub public, Thalovant privilégie des valeurs par défaut étroites :

- aucun envoi de messages à plus grande portée;
- aucune escalade, c'est-à-dire aucune demande de plus haut niveau;
- aucune propagation, c'est-à-dire aucun transfert de travail;
- aucun accès à contrôle complet;
- un accès aux questions normales seulement.

Les clients publics restent ainsi utiles, tout en limitant les prises de contrôle larges par accident.

## Quand quelque chose est refusé

**Permission denied** et **access blocked** veulent dire la même chose : ce
client a demandé quelque chose que sa règle d'accès ne permet pas. Lisez d'abord la liste de refus
(un refus l'emporte sur une autorisation), puis la liste d'autorisation, puis vérifiez que vous regardez
bien la règle à laquelle le client est réellement lié.

Élargir la règle est la dernière étape, pas la première. Si quelqu'un dit qu'un client a
**trop d'accès**, la solution consiste habituellement à la diviser en deux règles plus étroites
plutôt qu'à ajouter un autre refus.

## Quatre modèles à reprendre

Avant d'élargir une règle d'accès parce que quelque chose a été refusé, vérifiez si l'un
de ces modèles décrit déjà le rôle du client. La plupart des clients correspondent à l'un d'eux.

| Modèle | À utiliser quand | Ce qu'il autorise |
| --- | --- | --- |
| Questions seulement | Un client destiné aux utilisateurs doit poser des questions normales. | Les questions et l'état, avec les contrôles plus larges bloqués. |
| Observateur | Un client n'a besoin que de la santé ou de l'état. | Un accès en lecture seule. |
| Assistant de compétences | Un client aide Thalovant à voir les compétences disponibles. | Le partage de compétences, plus seulement les petites lectures dont il a besoin. |
| Tâche temporaire | Un client de confiance accomplit une seule tâche précise. | Des actions précises, avec une description claire. |

## Suggestions de compétences en direct

Quand un client partage de l'information en direct sur les compétences d'un hub, le générateur de règles d'accès peut afficher les compétences disponibles. Vous pouvez ainsi bloquer des éléments exacts sans deviner leurs noms.

Si les suggestions en direct ne sont pas encore offertes, les règles d'accès fonctionnent quand même. Commencez par quelque chose de simple, puis revenez plus tard quand les suggestions apparaîtront.

:::tip
Créez les règles d'accès une fois le client en place. Le générateur peut alors afficher les vrais choix de clients pour le hub sélectionné.
:::

## Une règle d'accès est prête quand

Une règle d'accès est prête quand :

- son nom explique son objectif;
- les clients liés ont tous besoin du même genre d'accès;
- les actions permises sont précises;
- les contrôles plus larges sont bloqués, sauf s'il existe une raison écrite;
- les notes expliquent pourquoi l'accès existe;
- un collègue pourrait lire la phrase qui résume les règles d'accès sans avoir à deviner.