# Groupes

Les **groupes** complètent les [rôles](/fr/docs/auth-roles-rbac) en ajoutant une couche plusieurs-à-plusieurs : un utilisateur possède exactement un rôle, mais peut appartenir à **n'importe quel nombre de groupes**. Les permissions peuvent référencer les groupes avec le préfixe `group:`, ce qui les rend idéaux pour l'accès à l'échelle d'une équipe et au niveau du champ.

```yaml
auth:
  strategies:
    - type: emailAndPassword
  groups:
    - name: marketing
    - name: finance
      description: Finance team with access to financial data
    - name: project-alpha
      description: Cross-functional team
      maxMembers: 50
```

Les équipes sont configurées via les groupes — définissez un groupe par équipe (ingénierie, marketing, …) et référencez-le dans les permissions.

## Définir des groupes

`auth.groups` est un tableau de définitions de groupes.

| Propriété     | Description                                                                                                                                                                                  |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name`        | **Obligatoire.** Identifiant du groupe. Minuscules, alphanumérique, traits d'union ; doit commencer par une lettre. Doit être unique et ne doit pas entrer en conflit avec le nom d'un rôle. |
| `description` | Description lisible de la finalité du groupe.                                                                                                                                                |
| `maxMembers`  | Nombre maximal de membres (entier ≥ 1). Illimité lorsqu'il est omis.                                                                                                                         |

**Règles de nommage** — les noms de groupe correspondent à `^[a-z][a-z0-9-]*$` (la même convention que les noms de rôle) :

| Nom             | Valide ? | Raison                        |
| --------------- | -------- | ----------------------------- |
| `marketing`     | ✅       | lettres minuscules            |
| `dev-team`      | ✅       | trait d'union autorisé        |
| `project-alpha` | ✅       | trait d'union autorisé        |
| `Marketing`     | ❌       | majuscule non autorisée       |
| `123team`       | ❌       | doit commencer par une lettre |

:::callout
**Les rôles et les groupes partagent un seul espace de noms.** Un groupe nommé `admin` est rejeté car il entre en conflit avec le rôle intégré. Gardez les noms de groupe distincts de tous les noms de rôle intégrés et personnalisés. La validation rejette aussi les noms de groupe en double.
:::

## Appartenance

Un utilisateur peut être membre de plusieurs groupes simultanément. L'appartenance est gérée à l'exécution (attribuée par les administrateurs ou par les [automatisations](/fr/docs/automations-overview)) — le schéma déclare quels groupes _existent_, pas qui en fait partie. Lorsque `maxMembers` est défini, les tentatives d'ajout d'un membre au-delà du plafond sont rejetées.

## Permissions basées sur les groupes

Référencez un groupe dans le bloc `permissions` d'une table en préfixant son nom par `group:`. Les entrées de groupe se placent aux côtés des noms de rôle dans les mêmes tableaux de permissions :

```yaml
tables:
  - id: 1
    name: Campaigns
    fields:
      - { id: 1, name: title, type: single-line-text, required: true }
      - { id: 2, name: budget, type: number }
    permissions:
      read: [member, 'group:marketing']
      update: ['group:marketing']
      # field-level: only finance can read the budget column
      fields:
        budget:
          read: ['group:finance']
```

| Forme d'entrée    | Signification                                     |
| ----------------- | ------------------------------------------------- |
| `member`          | Accorder à toute personne ayant le rôle `member`. |
| `group:marketing` | Accorder à chaque membre du groupe `marketing`.   |
| `admin`           | Accorder au rôle `admin`.                         |

La résolution des permissions suit le principe **le plus permissif l'emporte** : les permissions effectives d'un utilisateur sont l'union de celles accordées par son rôle et par chaque groupe auquel il appartient. Si le rôle d'un utilisateur accorde `read` et que son groupe `marketing` accorde `update`, il obtient les deux.

:::callout
Les groupes brillent pour les **permissions au niveau du champ** — par ex. exposer une colonne `salary` ou `budget` uniquement à un `group:finance` tandis que le reste de la table est largement lisible. Voir [Permissions de table](/fr/docs/table-permissions) pour le modèle complet au niveau du champ.
:::

## Pages associées

- [Rôles & RBAC](/fr/docs/auth-roles-rbac) — la couche à rôle unique sur laquelle s'appuient les groupes.
- [Permissions de table](/fr/docs/table-permissions) — modèle complet de permission `group:` et au niveau du champ.
- [Automatisations](/fr/docs/automations-overview) — attribuer des utilisateurs à des groupes en réponse à des événements.