# Comptes et accès

Un compte regroupe vos projets, vos coéquipiers et un modèle d’accès.

Canonical page: https://beeuni.ai/docs/fr/accounts

Un compte regroupe vos [projets](/docs/fr/project) et les personnes qui y travaillent. Lorsque vous vous inscrivez, Beeuni crée un compte personnel pour vous. Invitez un coéquipier et il devient un compte d’équipe. Les comptes personnels et d’équipe utilisent les mêmes rôles, la même facturation et les mêmes limites.

<a id="one-access-model"></a>

## Un modèle d’accès unique

Beeuni utilise un seul type d’octroi : une **affectation**. Chaque affectation associe un principal à un rôle, à une portée donnée.

| Terme | Signification |
|---|---|
| **Principal** | La personne ou l’entité qui détient l’accès : un `user`, un `group`, un `service_account` (l’identité d’un agent) ou l’adresse e-mail d’un invité `pending`. |
| **Rôle** | Un ensemble nommé d’autorisations. Beeuni fournit les rôles intégrés ci-dessous. Un compte peut ajouter des rôles personnalisés. |
| **Autorisation** | Une action, par exemple `project.secret.read` ou `member.update`. |
| **Portée** | L’endroit où le rôle s’applique : l’ensemble du `account` ou un seul `project`. |
| **Objet** | Facultatif. Limite l’affectation à un seul `agent`, `skill`, `secret`, `app` ou `trigger` dans la portée. |
| **Expiration** | Facultative. L’affectation cesse d’accorder l’accès à `expires_at`. |

Il n’existe pas de deuxième registre d’octrois. L’accès d’un groupe, une autorisation par ressource et une association à un rôle personnalisé sont tous des affectations. Seuls le principal, l’objet et le rôle diffèrent.

<a id="account-roles"></a>

## Rôles de compte

Chaque personne d’un compte détient un rôle de compte :

- **Propriétaire** — contrôle total, y compris sur les membres et la facturation.
- **Admin** — gère les projets, les membres, les groupes, les rôles et les jetons.
- **Membre** — travaille uniquement dans les projets auxquels il détient une affectation de projet.

Le propriétaire et l’admin disposent d’un accès équivalent à celui d’un gestionnaire sur tous les projets du compte. Une affectation de projet ne peut pas réduire cet accès. Pour limiter l’accès d’un propriétaire ou d’un admin à un projet, vous devez d’abord remplacer son rôle de compte par celui de membre.

L’accès équivalent à celui d’un gestionnaire ne comprend pas les sessions privées des membres. Un propriétaire de compte peut autoriser les propriétaires et les admins à y accéder en activant **Admins can open every session** sous **Settings → Security**. Seul un propriétaire peut modifier ce paramètre, et chaque utilisation est consignée dans le journal d’audit. Consultez [Accès aux sessions](/docs/fr/work/sessions#admins-can-open-every-session).

Pour inviter un coéquipier, saisissez son adresse e-mail dans la page des membres du compte. L’invitation est une affectation sur un principal `pending`. Elle devient une affectation `user` dès que la personne l’accepte.

<a id="project-roles"></a>

## Rôles de projet

Dans un projet, un principal détient l’un des deux rôles suivants :

- **Membre** — consulte le projet, démarre et arrête ses sessions, déclenche ses automatisations. Aucune modification ni configuration.
- **Gestionnaire** — détient toutes les autorisations du projet : modifie le projet, gère les automatisations, les connecteurs, les compétences, les secrets et les accès, détient les clés de la passerelle et supprime le projet.

Il n’existe pas de troisième rôle de projet.

Le rôle de gestionnaire comprend l’ensemble des autorisations du projet. Un rôle personnalisé ne fait qu’ajouter des autorisations : aucun rôle ne peut en retirer une à un gestionnaire. Les [affectations d’objet](#object-assignments) sont le mécanisme distinct qui limite *les objets* auxquels une autorisation s’applique.

Définissez l’accès au projet dans ses paramètres d’accès ou avec `beeuni access` — consultez [CLI](/docs/fr/cli#access).

<a id="groups"></a>

## Groupes

Un groupe est un principal, exactement comme une personne. Attribuez un rôle à un groupe dans une portée donnée et tous ses membres le détiennent. Un groupe ajoute des accès. Il ne retire jamais les accès qu’une personne détient déjà. Un groupe provisionné par SCIM est du même type de principal qu’un groupe créé manuellement.

<a id="object-assignments"></a>

## Affectations d’objet

Une affectation peut désigner un objet unique dans un projet : un `agent`, un `skill`, un `secret`, un `app` ou un `trigger`. Aujourd’hui, Beeuni applique les affectations d’objet aux agents et aux compétences.

- **Par défaut, l’accès aux agents est fermé.** Un membre n’accède à un agent que si une affectation le désigne, désigne l’un de ses groupes ou désigne tout le projet.
- **Par défaut, tous les autres types d’objet sont ouverts.** Sans affectation sur l’objet, un membre y accède. Un compte de connecteur partagé associé à une affectation ne peut être utilisé que par les personnes qu’elle désigne — consultez [Choisir qui peut utiliser un compte partagé](/docs/fr/connect/connectors#choose-who-can-use-a-shared-account).
- **Tout le projet est également un principal.** Dans la boîte de dialogue **Grant access**, sélectionnez **Everyone in**, puis le nom du projet, pour donner accès à un agent à tous les membres en une seule fois (`principal_type: "project"`, `principal_id` = l’identifiant du projet). Cette option ne prend en charge que les affectations d’objet — jamais les rôles — afin que chaque personne conserve son propre rôle de projet.
- **Une affectation d’objet restreint également un gestionnaire de projet.** C’est ce qui donne un sens à « limiter cet agent au groupe finance ». Le rôle de gestionnaire donne accès par défaut hors portée, il ne constitue pas une dérogation.
- **Les propriétaires et les admins de compte ne sont jamais limités par une affectation d’objet**, pas plus qu’un compte de service agissant sur ses propres affectations.

Une affectation d’objet n’accorde aucune autorisation par elle-même. Elle répond à la question « quels objets ? », et non « quelles actions ? ».

<a id="expiry"></a>

## Expiration

Ajoutez une `expires_at` à une affectation pour qu’elle cesse d’accorder l’accès à cet instant précis. Le moteur ignore toute affectation expirée. La ligne est conservée dans la piste d’audit.

<a id="one-vocabulary-two-bindings"></a>

## Un vocabulaire, deux associations

Une personne, un groupe ou un agent obtient des accès dans Beeuni sous forme de **rôles** — les affectations décrites ci-dessus. Un agent comporte une **deuxième association distincte** : les autorisations Beeuni déclarées dans son manifeste, sous `beeuni.yaml`, dans `agents.<name>.beeuni_permissions`. Une session ne peut effectuer que les actions autorisées par les deux. Elles ne peuvent jamais élargir les accès l’une de l’autre. Même si le manifeste d’un agent contient `project.secret.read`, il ne peut rien lire si la décision liée au rôle le lui refuse. De même, un agent lancé par un propriétaire ne peut rien lire si son manifeste ne répertorie pas l’action. Les rôles relèvent de l’état du compte ; les autorisations Beeuni relèvent de l’état du dépôt dans le manifeste. Consultez la [Référence du manifeste](/docs/fr/project/manifest#agents).

Pour une session d’agent, le rôle pris en compte est celui associé au compte de service de l’agent — son **plafond** — ou le plafond d’agent par défaut si aucun rôle n’est associé. Le rôle de la personne qui a démarré la session ne s’applique pas. Une autorisation, `project.credentials.issue`, est réservée aux humains et ne s’applique jamais à un agent. Un agent n’accorde que les accès qu’il détient lui-même. Dans le centre d’accès, sous **Agents**, les admins sélectionnent un agent comme principal d’un rôle de projet. Consultez [Autorisations des agents](/docs/fr/project/permissions).

<a id="custom-roles"></a>

## Rôles personnalisés

Un rôle personnalisé est un rôle appartenant au compte, avec les autorisations de votre choix. Son attribution crée une seule affectation : aucune affectation de base intégrée ne s’y superpose. Un rôle personnalisé peut accorder l’accès à un projet sans aucun rôle de projet intégré ; c’est ainsi que fonctionne un rôle de type département.

Un rôle personnalisé ne fait qu’ajouter des autorisations. Beeuni ne comporte aucune règle de refus.

Les rôles personnalisés nécessitent l’option `rbac` pour les entreprises. Sans celle-ci, toute tentative d’attribution renvoie `402` avec `code: "entitlement_required"`.

## Super-admin

Le super-admin n’est pas un rôle, mais un indicateur appliqué à une appartenance à un compte. Il contourne toutes les vérifications d’autorisation, et chaque contournement est consigné dans le journal d’audit. Les rôles régissent les accès ordinaires ; le super-admin est la porte de sortie, avec audit.

La personne qui crée le compte devient propriétaire et super-admin. Lorsqu’un propriétaire est rétrogradé, le rôle de propriétaire et l’indicateur de super-admin changent ensemble : la modification efface l’indicateur et consigne `iam.member.super_admin.revoke`. Si l’indicateur de super-admin est accordé à une personne qui n’est pas propriétaire, il reste actif jusqu’à ce qu’un propriétaire le révoque.

<a id="single-sign-on-domain"></a>

## Domaine de l’authentification unique

Un fournisseur d’identité SAML affirme l’adresse e-mail de chaque personne. Beeuni ne fait confiance à cette adresse en dehors de votre compte que pour un domaine que celui-ci a vérifié. En attendant :

- une personne connectée par votre fournisseur d’identité rejoint quand même votre compte et obtient ses groupes ;
- son identité SSO ne correspond à aucune invitation provenant d’un autre compte, et la fonction « ajouter un membre par e-mail » d’un autre compte ne la trouve pas ;
- une connexion SSO ne fusionne jamais une identité existante avec l’identité SSO ;
- **Enforce SSO** n’a aucun effet et la connexion par mot de passe reste disponible pour le domaine.

Pour vérifier le domaine, ouvrez **Identity** dans les paramètres du compte. La carte SSO affiche un enregistrement TXT DNS : nom `_beeuni-verification.<your-domain>`, valeur `beeuni-verification=<token>`. Publiez-le auprès de votre fournisseur DNS, puis sélectionnez **Verify domain** (`POST /v1/accounts/:accountId/iam/sso/provider/verify-domain`). Un domaine ne peut appartenir qu’à un seul compte : un domaine déjà vérifié par un autre compte ne peut pas être vérifié une seconde fois. La modification du domaine principal lance une nouvelle revendication, non vérifiée.

Une fois le domaine vérifié et **Enforce SSO** activé, le formulaire de connexion Web, `/v1/access/check-email` ainsi que les routes sans interface `/v1/auth/sign-in/password`, `/v1/auth/sign-in/magic-link` et `/v1/auth/verify-otp` refusent toutes les connexions par mot de passe et code envoyé par e-mail pour ce domaine (`403 sso_required`).

Une connexion SSO ne fusionne jamais un propriétaire ou un super-admin avec une identité SSO, même sur un domaine vérifié. Ils conservent leur identité existante et l’identité SSO rejoint le compte en tant que membre distinct.

<a id="per-feature-access-settings"></a>

## Paramètres d’accès propres à chaque fonctionnalité

Certaines fonctionnalités possèdent leur propre paramètre de visibilité, en plus du modèle de rôles :

| Paramètre | Détermine |
|---|---|
| [Mode d’accès à l’application](/docs/fr/feature-flags/apps#access-modes) | Qui peut ouvrir une application déployée |
| [Accès aux sessions des automatisations](/docs/fr/connect/triggers#session-access) | Qui peut ouvrir les sessions créées par une automatisation |
| [Règle de canal Slack](/docs/fr/connect/slack) | Qui peut démarrer une session depuis un canal |
| [Fonctionnalités de l’ordinateur](/docs/fr/connect/computers#what-the-computer-allows) | Quels appels au système de fichiers, au shell et au bureau un ordinateur connecté accepte |

Chaque paramètre restreint l’accès à une seule ressource. Aucun n’accorde une autorisation refusée par la décision liée au rôle.

<a id="the-access-api"></a>

## API d’accès

| Méthode + chemin | Fonction |
|---|---|
| `GET /v1/accounts/{accountId}/iam/assignments` | Répertorie les affectations. Filtre par principal, portée, objet ou rôle. |
| `POST /v1/accounts/{accountId}/iam/assignments` | Crée une affectation. |
| `DELETE /v1/accounts/{accountId}/iam/assignments/{assignmentId}` | Révoque une affectation. |
| `GET /v1/accounts/{accountId}/iam/permissions` | Fournit le catalogue des autorisations sous forme de données. |
| `GET /v1/accounts/{accountId}/iam/roles` | Répertorie les rôles intégrés et personnalisés. |
| `GET /v1/accounts/{accountId}/iam/roles/{roleId}/permissions` | Fournit les autorisations d’un rôle. |

Le catalogue est constitué de données, et non d’une liste codée en dur. Chaque autorisation comporte ses indicateurs `action`, `scope_type`, `resource_type`, `delegable`, `description`, `area`, `level` et `implies`. Consultez-le au lieu de coder en dur les chaînes d’action.

Les routes de modification déterminent l’autorisation requise en fonction de ce que vous attribuez : `project.members.manage` pour un rôle de projet ou une affectation d’objet, `project.connector.connections.manage` pour une affectation `connection`, `member.update` pour un rôle de compte et `policy.create` pour un rôle personnalisé. Vous ne pouvez pas contourner un plafond en choisissant une autre route.

<a id="branding"></a>

## Personnalisation de l’image de marque

Un compte Enterprise peut appliquer sa propre image de marque à l’application pour tous ses membres : un logo au format paysage, une icône carrée et une favicon, chacune avec une variante facultative pour le mode sombre, ainsi qu’un nom de produit qui remplace « Beeuni » dans le titre de l’onglet du navigateur. Ouvrez **Account → Branding** (`/accounts/{accountId}?tab=branding`). Les images importées doivent être au format PNG, JPEG, WebP, SVG ou ICO et peser au maximum 1 Mo. L’icône remplace un logo manquant, la favicon utilise l’icône par défaut et une variante sombre manquante utilise l’image claire. Les logos dans l’application suivent le thème de l’application ; la favicon suit le jeu de couleurs du système d’exploitation.

L’image de marque est liée au compte, pas au navigateur : dans un projet, les membres voient l’image de marque du compte auquel appartient le projet. Les pages de connexion, les e-mails et les pages de partage public conservent l’image de marque Beeuni, car aucun compte ne peut être associé à une marque tant que la personne n’est pas connectée. À l’expiration de l’option Enterprise, les membres voient de nouveau Beeuni. Rien n’est supprimé, et le compte peut retirer à tout moment les éléments importés.

| Méthode + chemin | Fonction |
|---|---|
| `GET /v1/accounts/{accountId}/branding` | Fournit l’enregistrement stocké et indique si le forfait l’autorise. |
| `PUT /v1/accounts/{accountId}/branding` | Définit ou efface `app_name`. Nécessite `account.write` et l’option `branding` (sinon, `402 entitlement_required`). |
| `POST /v1/accounts/{accountId}/branding/assets/{kind}` | Importe une image au format multipart `file`. `kind` correspond à `logo`, `icon`, `favicon` ou à leurs variantes `_dark`. Même condition que pour `PUT`. |
| `DELETE /v1/accounts/{accountId}/branding/assets/{kind}` | Supprime une image. `account.write` uniquement. |
| `DELETE /v1/accounts/{accountId}/branding` | Rétablit tous les éléments Beeuni. `account.write` uniquement. |

`GET /v1/accounts` fournit l’`branding` effectif de chaque compte : l’enregistrement si l’option est active, `null` sinon. Ainsi, le client effectue le rendu à partir d’une seule requête qu’il envoie déjà. Dans le SDK : `beeuni.accounts.branding.{get, update, uploadAsset, removeAsset, reset}`.

<a id="switching-accounts"></a>

## Changer de compte

Si vous appartenez à plusieurs comptes, passez de l’un à l’autre à l’aide du sélecteur de compte. Chaque compte conserve ses propres projets, membres et paramètres.

<a id="signed-in-devices"></a>

## Appareils connectés

**Settings → Security → Devices** répertorie tous les endroits où vous êtes connecté : navigateurs, application de bureau et application mobile.

- Le bouton **Sign out** d’un appareil met fin à cette connexion immédiatement. Elle ne peut pas être renouvelée, son jeton cesse de fonctionner sur les routes du compte et le téléphone ne reçoit plus de notifications push.
- L’option **Sign out other devices** met fin à toutes les autres connexions. Elles ne peuvent pas être renouvelées et leurs téléphones cessent immédiatement de recevoir des notifications push.

Un téléphone reconnecté reçoit de nouveau les notifications push.

<a id="tokens"></a>

## Jetons

Beeuni vous connecte à l’aide d’un jeton d’accès personnel (`beeuni_pat_...`). Il agit en tant que personne qui l’a créé et détient exactement les mêmes affectations que cette personne. Un compte de service (`beeuni_sa_...`) est un principal distinct, et non l’identifiant d’une personne ; il n’a accès à aucun projet tant qu’une affectation ne lui en accorde pas.

Ces deux types de jetons se trouvent à des endroits différents, car ils appartiennent à des propriétaires différents. Vos propres clés API se trouvent dans vos paramètres, sous **Settings → API keys** (`/settings/tokens`) : vous seul pouvez les voir, et elles cessent de fonctionner lorsque votre appartenance prend fin. Les jetons des comptes de service sont une configuration du compte, sous **Account → Tokens**, à côté des règles de clé qui régissent leur expiration.

Consultez la documentation sur l’authentification du SDK pour en savoir plus sur les jetons.

<a id="audit-log"></a>

## Journal d’audit

Le journal d’audit consigne chaque requête qui atteint l’API, que la requête ait ou non identifié son appelant. Le serveur écrit une ligne pour chaque requête HTTP, mise à niveau WebSocket, requête d’aperçu, transfert Git et appel SCIM. La couverture ne dépend pas de la route.

Chaque ligne indique l’appelant que la requête a permis d’identifier :

| `actor_type` | Appelant |
| --- | --- |
| `human` | Une personne connectée ou son jeton (`source: api_key`). |
| `agent` | L’identifiant d’agent d’une session. La ligne indique également la personne au nom de laquelle l’agent agit. |
| `service_account` | Un jeton de compte de service. |
| `system` | Une clé API de compte, un jeton d’annuaire SCIM, un webhook d’intégration accompagné d’une signature vérifiée ou une tâche d’arrière-plan Beeuni (`source: worker`). |
| `anonymous` | Une requête sans identifiant, ou avec un identifiant invalide ou falsifié. |

Chaque ligne consigne également l’identifiant authentifié par l’API dans `credential_kind` et `credential_id`. L’identifiant désigne l’identifiant, jamais le secret. L’application Web l’affiche sous **Via**, avec le nom du jeton ou de l’application, le cas échéant.

| `credential_kind` | Identifiant d’authentification | `credential_id` |
| --- | --- | --- |
| `browser_session` | Une session de connexion Beeuni (l’application web ou un client disposant d’un JWT de connexion). | L’identifiant de session de connexion. |
| `personal_access_token` | Un jeton d’accès personnel, comme celui de la CLI. | L’identifiant du jeton. |
| `oauth_app` | Le jeton `beeuni_oat_` d’une application connectée, comme un client MCP. | L’identifiant du client OAuth. |
| `session_token` | Le propre jeton d’une session d’agent. | L’identifiant de la session. |
| `api_key` | Une clé API de compte. | L’identifiant de la clé. |
| `service_account` | Un jeton de compte de service. | L’identifiant du compte de service. |
| `scim_token` | Un jeton d’annuaire SCIM. | L’identifiant du jeton. |

L’API ne lit jamais `X-Beeuni-Client`. La CLI, le serveur MCP et l’application web appellent tous la même API, et n’importe quel client peut envoyer n’importe quelle valeur d’en-tête. Le journal consigne donc ce que l’API peut vérifier. Les lignes écrites avant le 2026-09-30 peuvent contenir un `client_reported_source` déclaré par le client. Les nouvelles lignes laissent ce champ vide. Filtrez par identifiant d’authentification avec `?credential_kind=oauth_app` sur `GET /v1/accounts/:accountId/audit`, ou `beeuni audit ls --credential-kind oauth_app`.

Les lignes écrites avant 2026-10 contiennent `session_sequence`, `integrity_previous_hash` et `integrity_hash` : un compteur par session et une chaîne de hachage. Les nouvelles lignes laissent ces trois champs vides, qui sont obsolètes. La chaîne n’était jamais vérifiée, et sa maintenance sérialisait toutes les écritures d’une session. Le journal d’une session est trié par date de création : les lignes ayant un `session_sequence` apparaissent d’abord, dans cet ordre, puis les lignes plus récentes, dans l’ordre de création par l’API.

Une requête refusée correspond à une ligne avec `outcome: denied`. `metadata.auth` indique le mode d’authentification de l’appelant : l’identifiant du jeton, jamais le secret. Un clonage Git est l’action `git.clone`. Un push est `git.push`, et `metadata.refs` répertorie chaque référence créée, mise à jour ou supprimée.

<a id="retention"></a>

### Conservation

| Ancienneté de l’événement | Emplacement | Mode de consultation |
| --- | --- | --- |
| De 0 à 90 jours | PostgreSQL, une partition par semaine | Le journal d’audit dans l’application web, `GET /v1/accounts/:accountId/audit`, `beeuni audit ls`, les webhooks d’audit et l’exportation |
| De 90 à 365 jours | Une archive S3 avec Object Lock (mode conformité) | Exportation uniquement : `GET /v1/accounts/:accountId/audit/export` ou `beeuni audit export` |
| Plus de 365 jours | Supprimé | Indisponible |

Les semaines vont du lundi à 00:00 UTC au lundi suivant à 00:00 UTC. Une semaine est transférée dans l’archive dès que son dernier instant remonte à 90 jours. Un événement devient donc consultable uniquement par exportation entre 90 et 97 jours après sa survenue. L’archive conserve un événement jusqu’à 365 jours après la fin de sa semaine. Il est donc conservé de 365 à 372 jours au total, et le verrou de conservation empêche quiconque, y compris le personnel de Beeuni, de raccourcir cette durée ou de le supprimer avant. La politique de confidentialité indique la même limite : les journaux de l’application sont conservés jusqu’à 365 jours.

L’exportation renvoie l’archive et PostgreSQL sous forme d’une seule liste, de la plus ancienne à la plus récente, avec les mêmes filtres, les mêmes champs et la même pagination `X-Audit-Next-Cursor`. Les deux modes de consultation nécessitent l’autorisation `auditAccess`. Les événements archivés contiennent les mêmes champs que les événements actifs ; `session_sequence` et les hachages d’intégrité sont vides pour les événements écrits depuis 2026-10 (voir ci-dessus).

### Actions

Chaque ligne comporte un `action` nommé `domain.resource.verb` et un titre affiché par l’application web et `beeuni audit ls` :

| Action | Titre | Émise par |
| --- | --- | --- |
| `gateway.key.revoke` | Clé de passerelle LLM révoquée | Une requête à `DELETE /v1/projects/:projectId/gateway/keys/:keyId`. |
| `iam.group.create` | Groupe créé | La requête qui a créé le groupe. La ligne contient le nouveau groupe dans `after`. |
| `secret.consumer.used` | Secret utilisé | Un bac à sable qui a lu un secret. |
| `api.rate_limit.exceeded` | Limite de débit de l’API atteinte | Un limiteur qui a refusé une requête. `metadata.limiter` en indique le nom. |

Chaque route d’API correspond à une seule action. La ligne d’une requête conserve le modèle de route dans `metadata.http`, jamais le chemin brut, qui peut contenir un jeton. Lorsqu’un gestionnaire enregistre son propre événement pour la requête, avec l’état avant et après, cet événement constitue l’unique ligne de la requête. Une requête qui ne correspond à aucune route est `api.route.unmatched`.

Filtrez par préfixe d’action : `?action=iam.` sur `GET /v1/accounts/:accountId/audit`, `beeuni audit ls --action iam.` ou `--action-prefix` d’un webhook d’audit. [Actions du journal d’audit](/docs/fr/audit-actions) répertorie toutes les actions et leurs titres. Les lignes écrites avant le 2026-09-24 utilisent `METHOD /template` comme action et affichent les mêmes titres.

Les tâches d’arrière-plan de Beeuni agissent sans requête : elles expirent les autorisations et les permissions de tunnel, suppriment les branches de session expirées, activent les déploiements d’App et déplacent les projets entre fournisseurs de bac à sable. Leurs lignes contiennent `source: worker`, et `metadata.auth.worker` indique le nom de la tâche, par exemple `tunnel-cleanup` ou `app-deployments`. La ligne d’un déploiement d’App indique aussi comme initiateur le membre qui l’a lancé.

Une requête anonyme qui désigne l’un de vos projets est inscrite dans votre journal. Sélectionnez ces lignes avec `actor_type=anonymous`. Les lignes anonymes sont soumises à une limitation de débit sur chaque processus d’API, afin qu’un flot de telles requêtes ne puisse pas évincer les lignes attribuées. Les sondes d’état, les requêtes préliminaires CORS et le trafic anonyme vers une App déployée ne sont pas enregistrés.

<a id="billing"></a>

## Facturation

Free comprend un projet et 20 $ de crédits de bienvenue, valables 30 jours après réception. Dès la période suivante, vous recevez 2 $ par mois, sans report. Les crédits couvrent le fonctionnement de l’ordinateur et les modèles officiels.

L’offre de bienvenue est accordée une seule fois par compte personnel. Les bénéficiaires de l’ancienne offre de 2 $ reçoivent la différence de 18 $ ; les comptes qui ne l’ont jamais reçue obtiennent 20 $. Créer une autre équipe ou un autre projet ne la déclenche pas à nouveau. Les crédits achetés sont conservés séparément et ne sont pas supprimés à l’expiration ou au renouvellement mensuel des crédits gratuits.

La facturation s’applique au niveau du compte et couvre tous les projets de celui-ci. Beeuni propose une offre gratuite, une offre Pro et une offre Équipe facturée par siège, chacune avec son propre accès aux modèles et ses propres crédits. Utiliser votre propre clé de modèle ne rend pas l’utilisation gratuite : Beeuni facture tout de même des frais de plateforme en plus, sauf avec l’offre gratuite.

> **Entreprise**
>
> L’authentification unique (`sso`), le provisionnement SCIM (`scim`), les rôles personnalisés (`rbac`) et l’accès à l’audit (`auditAccess`) sont des droits inclus dans l’offre Entreprise. Un droit est indépendant d’un rôle : il détermine si la fonctionnalité est disponible pour le compte, tandis que le rôle détermine toujours qui peut l’utiliser. Contactez l’équipe commerciale pour les activer.