# Autorisations et héritage
GitBook dispose d’un modèle de permissions flexible qui vous permet d’avoir autant, ou aussi peu, de contrôle sur les permissions que vous le souhaitez. Le modèle de permissions dans GitBook est un [**fondé sur les rôles**](/docs/documentation/fr/collaboration/member-management/roles.md#roles-in-gitbook)**, en cascade** modèle. Cela signifie que vous définissez des valeurs par défaut puis, à n’importe quel niveau du contenu, décidez si vous souhaitez hériter de ces valeurs par défaut ou non.
Vous pouvez définir les permissions à quatre niveaux : **organisation**, **site**, **collection**, et **espace**.
### Rôles par défaut de l'organisation
Lorsque vous ajoutez un membre à votre organisation, vous définissez [son rôle par défaut](/docs/documentation/fr/collaboration/member-management/roles.md). Ce rôle s’applique à tout contenu qui hérite de ses permissions depuis les valeurs par défaut de l’organisation.
### Comment les permissions se propagent
Dans GitBook, les permissions sont résolues par **priorité**et non par le rôle le plus élevé à travers chaque niveau.
Pour les espaces en mode hérité, GitBook résout l’accès dans cet ordre :
* **Espace** — remplacements directs des membres et des équipes sur l’espace
* **Site** — permissions du site parent
* **Collection** — permissions de la collection parente, s’il y en a une
* **Organisation** — le rôle par défaut défini pour chaque membre
Cela signifie que les permissions du site remplacent les valeurs par défaut de l’organisation et de la collection parente pour les espaces liés en mode hérité. Les remplacements directs au niveau de l’espace restent prioritaires sur tout le reste.
Voici deux exemples de la façon dont cela fonctionne en pratique :
Exemple 1
Un membre a le rôle de Créateur au niveau de l’organisation. Un espace lié est en mode hérité, et le site parent définit ce membre comme Commentateur. Le membre obtient l’accès Commentateur dans cet espace, car le site a priorité sur la valeur par défaut de l’organisation.
Exemple 2
Une collection définit un espace comme Lecteur, et le site parent le définit comme Commentateur. L’espace utilise Commentateur, car les permissions du site ont priorité sur la collection parente en mode hérité. Si vous donnez ensuite à un membre un accès direct de Créateur sur l’espace, ce remplacement direct l’emporte pour ce membre.
{% hint style="info" %}
**Remarque :** Les permissions du site s’appliquent uniquement aux espaces en mode hérité. Si un espace dispose de ses propres permissions configurées — c’est-à-dire qu’il n’est pas en mode hérité — celles-ci ont priorité et les permissions au niveau du site ne l’affecteront pas.
{% endhint %}
### Gestion de l’héritage
À chaque fois que vous créez une collection ou un espace, vous pouvez définir le type d’héritage souhaité. Vous avez trois grandes options lorsque vous définissez l’héritage d’un contenu :
### Hériter
Définir l’héritage sur **hériter** fera en sorte que l’espace ou la collection hérite des rôles attribués dans le **contenu du niveau parent**. Pour les espaces ou collections de niveau supérieur, ce parent est l’organisation, ils hériteraient donc des rôles par défaut de l’organisation. Pour les espaces ou sous-collections à l’intérieur d’une collection, le parent sera la collection dans laquelle se trouve le contenu.
Lorsqu’un espace est lié à un site et reste en mode hérité, GitBook résout l’accès dans cet ordre : remplacements directs de l’espace, puis le site parent, puis la collection parente, et enfin l’organisation. Les permissions du site ont priorité sur les valeurs par défaut de l’organisation et de la collection pour les espaces liés en mode hérité, mais elles ne modifient pas les remplacements directs au niveau de l’espace.
### Accès par rôle spécifique
Sélectionner un rôle spécifique lors de la définition de l’héritage des permissions d’une collection ou d’un espace va **réinitialiser** les rôles par défaut de l’organisation et attribuer à chaque **non-administrateur** ce rôle au sein de la collection ou de l’espace. Par exemple, si vous définissez l’héritage sur **lecteur**, tout le monde dans l’organisation aurait un accès en lecture seule à l’espace ou à la collection, quel que soit son rôle par défaut.
L’accès direct d’un membre ou d’une équipe à cette collection ou cet espace peut toujours remplacer ce paramètre hérité. Si vous définissez un rôle spécifique sur l’espace lui-même, l’espace n’utilise plus le mode hérité, donc les permissions au niveau du site ne l’affectent pas.
### Aucun accès
Vous pouvez également révoquer complètement l’accès de tous les membres non administrateurs de l’organisation au niveau d’un espace ou d’une collection. Cela masquera le contenu pour tout le monde, sauf pour les administrateurs et la personne qui a créé l’espace ou la collection.
{% hint style="info" %}
L’option d’héritage par défaut pour tout nouvel espace ou toute nouvelle collection est **hériter**. Cela signifie que chaque fois qu’un contenu est créé, il héritera par défaut des permissions de son parent.
{% endhint %}
### Définition des permissions spécifiques au contenu
Une fois que vous avez décidé de l’héritage des permissions pour votre espace ou votre collection, vous pouvez personnaliser davantage l’accès en donnant aux équipes ou aux membres un **accès direct**.
### Donner un accès direct à une équipe
Vous pouvez ajouter une équipe directement à une collection ou à un espace avec un rôle spécifique. Cela donnera à toute personne de cette équipe l’accès spécifié au contenu.
{% hint style="info" %}
L’accès par équipe est un excellent moyen de s’assurer que les bonnes personnes ont accès au bon contenu ; chaque fois qu’une personne est ajoutée à une équipe ou en est retirée, elle gagnera ou perdra, respectivement, les permissions définies sur le contenu.
{% endhint %}
### Donner un accès direct à un membre
De la même manière que pour les équipes, vous pouvez également donner un accès direct aux membres. C’est la façon la plus granulaire de gérer les permissions. Lorsque vous donnez à des membres individuels un accès direct à une collection ou à un espace, vous remplacez toutes les permissions héritées qu’ils pourraient avoir. L’accès direct d’un membre est idéal si vous avez besoin d’un contrôle très précis sur les collaborateurs.
Les membres disposant d’un accès direct au niveau de l’espace sont entièrement retirés du mécanisme d’héritage. Leur rôle est défini explicitement et n’est pas प्रभावित par les permissions au niveau de l’organisation, du site ou de la collection.
### Garder le contrôle des permissions
Même si cela peut sembler assez complexe au départ, le modèle de permissions de GitBook vous donne le contrôle si vous en avez besoin, et disparaît du chemin si ce n’est pas le cas. Pour de nombreuses équipes, une **solution à configurer une fois et à oublier** en matière de gestion des permissions suffit. Pour d’autres équipes, en particulier les grandes organisations, ce niveau de contrôle sur l’accès et le flux de travail est essentiel.
#### Configurer une fois et oublier
Si vous voulez simplement intégrer vos coéquipiers et commencer à éditer du contenu avec eux, vous n’aurez peut-être même jamais besoin de consulter les permissions. Invitez les personnes, définissez leur rôle par défaut, et tout contenu que vous créerez héritera par défaut de ces rôles. Pas besoin d’entrer dans les détails !
#### Contrôle de l’accès et du flux de travail
Pour les grandes organisations, les équipes qui divisent leur organisation en collections distinctes, ou les équipes qui ont besoin d’un contrôle très granulaire du flux de travail ; alors entrer dans les détails est exactement ce qu’il faut. En utilisant une combinaison d’héritage, de remplacement, d’accès direct aux équipes et d’accès direct aux utilisateurs, vous pouvez créer des flux de travail et des modèles d’accès qui vous permettent de garder le contrôle.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://gitbook.com/docs/documentation/fr/collaboration/member-management/permissions-and-inheritance.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.