> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/account/roles-and-page-access.md).
# Rôles et accès aux pages
Accès aux pages par fonctionnalité dans l’ABAC Kilo IoT — Édition, Consultation ou Aucun accès par surface, avec libellés Admin/Éditeur/Visiteur.
Kilo IoT Server utilise le contrôle d'accès basé sur les attributs (ABAC). L'accès est évalué selon trois attributs : l'organisation à laquelle vous appartenez, si vous êtes le propriétaire, et les autorisations par fonctionnalité dont vous disposez. Chaque fonctionnalité peut être définie indépendamment sur Modifier, Voir ou Aucun accès. Il n'y a pas de sélecteur de rôle — vous travaillez directement avec les autorisations par fonctionnalité.
## Le modèle par fonctionnalité
Lorsque vous invitez un utilisateur ou modifiez ses autorisations, la boîte de dialogue affiche une **Accès aux pages** liste. Chaque fonctionnalité comporte trois options à boutons radio :
* **Modifier** — l'utilisateur peut consulter et effectuer des modifications
* **Afficher** — l'utilisateur peut voir la fonctionnalité mais ne peut pas la modifier
* **Aucun accès** — la fonctionnalité est masquée pour l'utilisateur
## Surfaces configurables
Les fonctionnalités suivantes apparaissent dans l'invitation et la boîte de dialogue des autorisations. Vous pouvez définir chacune d'elles indépendamment.
| Fonctionnalité | Niveaux autorisés | Valeur par défaut pour les nouvelles invitations | Règles spéciales |
| ---------------------- | ----------------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Vue d’ensemble | Modifier / Voir / Aucun accès | Modifier | |
| Tableaux de bord | Modifier / Voir / Aucun accès | Modifier | |
| Dispositifs | Modifier / Voir / Aucun accès | Modifier | |
| Caméras | Modifier / Voir / Aucun accès | Modifier | |
| Cartes SIM | Modifier / Voir / Aucun accès | Modifier | |
| Notifications | Modifier / Voir / Aucun accès | Modifier | |
| Règles | Modifier / Voir / Aucun accès | Modifier | |
| Abonnement | Modifier / Voir / Aucun accès | Modifier | |
| Gérer les utilisateurs | Modifier / Voir / Aucun accès | Aucun accès | L'accès en lecture permet à l'utilisateur de consulter la liste des membres et les invitations en attente. L'accès en modification est requis pour inviter des utilisateurs, modifier les autorisations, révoquer des invitations et supprimer des membres. |
| Connecteurs | Modifier / Voir / Aucun accès | Modifier | |
| Journal d’audit | Voir / Aucun accès | Aucun accès | Aucune option Modifier n'existe. Le journal d'audit est en lecture seule pour tout le monde, y compris le propriétaire. Même si un accès en écriture est demandé par d'autres moyens, il est automatiquement ramené à la lecture à la création et à l'acceptation de l'invitation. |
| Clés API | Modifier / Aucun accès | Modifier | Aucune option Voir n'existe. La gestion des clés API est en libre-service — si un utilisateur y a accès, il peut créer et gérer ses propres clés. |
## Surfaces côté serveur
Le modèle d'autorisations sous-jacent comprend quatre fonctionnalités supplémentaires qui sont appliquées côté serveur mais n'apparaissent pas dans la boîte de dialogue : Passerelles, Journaux, Centre de notifications et Géorepérage. Celles-ci ne peuvent pas être configurées via l'interface Utilisateurs et ne sont pas pertinentes pour la gestion quotidienne des accès.
## Valeurs par défaut pour les nouvelles invitations
Lorsque vous ouvrez la boîte de dialogue d'invitation, les autorisations sont préremplies avec des valeurs par défaut codées en dur — et non à partir d'un modèle. Le point de départ de chaque nouvelle invitation est :
* **Modifier** sur toutes les surfaces sauf Gérer les utilisateurs et Journal d'audit
* **Aucun accès** sur Gérer les utilisateurs
* **Aucun accès** sur Journal d'audit
Vous pouvez ajuster chaque surface individuellement avant d'envoyer l'invitation. Ces valeurs par défaut sont conçues pour donner à un nouveau membre de l'équipe un large accès aux fonctionnalités opérationnelles, tout en limitant les capacités administratives et d'audit jusqu'à ce qu'elles soient explicitement accordées.
## Libellés d'affichage et correspondance
Le tableau des utilisateurs affiche **Accès en modification** et **Accès en lecture** colonnes. Celles-ci affichent des libellés calculés — et non des rôles stockés. La plateforme définit trois modèles d'autorisations nommés et compare les autorisations réelles de chaque utilisateur à ceux-ci :
| Modèle | Ce qu'il inclut | Ce qu'il exclut |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| **Admin** | Modification sur toutes les surfaces configurables. Journal d'audit = Lecture. Clés API = Modification. Inclut Abonnement et Gérer les utilisateurs. | Aucune exclusion |
| **Éditeur** | Modification sur la plupart des surfaces. Journal d'audit = Lecture. Clés API = Modification. | Aucun accès à Abonnement et Gérer les utilisateurs |
| **Lecteur** | Lecture sur la plupart des surfaces. Journal d'audit = Lecture. Clés API = Modification (exception de libre-service). | Aucun accès à Abonnement et Gérer les utilisateurs |
Une fois les autorisations enregistrées, la plateforme compare l'ensemble réel des autorisations de l'utilisateur à ces modèles :
* Si l'ensemble correspond au modèle Administrateur → la colonne affiche **Admin**
* Si elle correspond au modèle Éditeur → **Éditeur**
* Si elle correspond au modèle Lecteur → **Lecteur**
* Si l'ensemble ne correspond à aucun modèle → la colonne affiche à la place les noms des fonctionnalités individuelles
* Le propriétaire s'affiche toujours **Propriétaire**
Ces libellés vous aident à voir en un coup d'œil quel type d'accès chaque membre possède, mais le modèle sous-jacent est toujours par fonctionnalité. Les modèles ne sont pas attribués comme des rôles et ne préremplissent pas la boîte de dialogue — ils servent uniquement à calculer les libellés d'affichage dans le tableau des utilisateurs.
## Accès du propriétaire
Le propriétaire n'est pas un modèle d'autorisation. C'est une propriété de l'organisation elle-même — exactement un membre est le propriétaire, et ce statut est enregistré dans la fiche de l'organisation.
Le propriétaire bénéficie automatiquement d'un accès à toutes les fonctionnalités, à une exception près : le journal d'audit est toujours en lecture seule, même pour le propriétaire. Cela est appliqué à deux niveaux — les autorisations du propriétaire sont générées avec le journal d'audit défini sur lecture, et une couche d'application distincte refuse explicitement l'écriture dans le journal d'audit pour chaque utilisateur.
L'accès du propriétaire ne peut pas être modifié ni supprimé. Il ne change que lors du transfert de propriété dans [Paramètres de l’organisation](/kilo-docs-fr/kilo-iot-server/account/organization-settings.md).
## Lorsque vous n'avez pas accès
Lorsque vous n'avez pas d'accès en modification à une fonctionnalité, la plateforme désactive les contrôles concernés — les boutons et les champs apparaissent grisés. Le survol d'un contrôle désactivé affiche une infobulle expliquant pourquoi et qui contacter :
* Si aucun autre administrateur n'existe dans l'organisation : *"Vous n'avez pas les autorisations requises. Veuillez contacter le propriétaire de votre organisation."*
* Si des administrateurs existent : *"Contactez vos administrateurs : Maria Schmidt, ..."*
Les administrateurs listés dans l'infobulle sont automatiquement déduits du propriétaire de l'organisation et de tous les membres qui ont **Gérer les utilisateurs** défini sur Modifier. Ces contacts sont calculés automatiquement — et non configurés manuellement.
## Évaluation des accès
L'accès est vérifié par fonctionnalité : cet utilisateur dispose-t-il d'une autorisation de lecture ou d'écriture pour cette fonctionnalité dans cette organisation ? Si aucune autorisation correspondante n'existe, l'accès est refusé. Le propriétaire est la seule exception — il bénéficie automatiquement d'un accès à toutes les fonctionnalités, le journal d'audit étant limité à la lecture.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/account/roles-and-page-access.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
