> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Gérer les utilisateurs, les groupes et les rôles avec SCIM

> Utilisez l’API SCIM pour gérer les utilisateurs, les groupes et les rôles personnalisés d’une organisation W&B grâce au provisionnement automatisé.

<Note>
  Regardez une [vidéo de démonstration de SCIM](https://www.youtube.com/watch?v=Nw3QBqV0I-o) (12 min)
</Note>

<h2 id="overview">
  Aperçu
</h2>

Cette page explique comment les administrateurs d’instance et les administrateurs de l’organisation utilisent l’API System for Cross-domain Identity Management (SCIM) pour automatiser la gestion des identités dans W\&B. L’API SCIM vous permet de provisionner et de déprovisionner des utilisateurs, de gérer l’appartenance aux équipes et de définir des rôles personnalisés par programmation, via un fournisseur d’identité ou un pipeline CI/CD, sans avoir à passer par l’interface de la W\&B App. Les groupes SCIM correspondent aux équipes W\&B.

L’API SCIM de W\&B est compatible avec des fournisseurs d’identité tels qu’Okta et Microsoft Entra. Pour configurer le SSO avec Okta, Microsoft Entra ou d’autres fournisseurs d’identité, consultez la [documentation SSO](/fr/products/wandb/platform/hosting/iam/sso).

Pour des exemples pratiques en Python illustrant l’utilisation de l’API SCIM, consultez le dépôt [`wandb-scim`](https://github.com/wandb/examples/tree/master/wandb-scim).

<h3 id="supported-features">
  Fonctionnalités prises en charge
</h3>

L’API SCIM prend en charge les fonctionnalités suivantes :

* **Filtrage** : l’API prend en charge le filtrage sur les points de terminaison `/Users` et `/Groups`.
* **Opérations PATCH** : prise en charge de `PATCH` pour la mise à jour partielle des ressources.
* **Prise en charge des ETags** : mises à jour conditionnelles basées sur les ETags pour détecter les conflits.
* **Authentification par compte de service** : les comptes de service de l’organisation peuvent accéder à l’API.
* **Cycle de vie des comptes de service** : provisionnez et déprovisionnez des [comptes de service à portée d'équipe ou limités à l’organisation](/fr/products/wandb/platform/hosting/iam/service-accounts). Pris en charge sur le **Cloud mutualisé**, ainsi que sur le **Cloud dédié** et les déploiements **autogérés** à partir de la version v0.81.0.

<Note>
  Si vous êtes administrateur de plusieurs organisations Enterprise en [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud), configurez l’organisation destinataire des requêtes API SCIM afin que les requêtes effectuées avec votre clé API s’appliquent à la bonne organisation. Cliquez sur votre image de profil, puis sur **Paramètres utilisateur**, et vérifiez le paramètre **Default API organization**.

  La valeur de l’espace réservé `[HOST-URL]` utilisé dans les exemples de cette page dépend de l’option d’hébergement choisie.

  Les exemples utilisent des ID d’utilisateur tels que `abc` et `def`. Dans les requêtes et réponses réelles, les ID d’utilisateur sont des valeurs hachées.
</Note>

<h2 id="authentication">
  Authentification
</h2>

Chaque requête SCIM doit être authentifiée par un principal administrateur. Les administrateurs de l’organisation peuvent s’authentifier à l’aide d’un **jeton Bearer** ou d’identifiants d’authentification **HTTP Basic**. Dans les deux cas, c’est la *même chaîne de clé API* qui est utilisée lorsqu’une clé est requise. Consultez les principales différences présentées dans la section suivante, puis choisissez une identité d’utilisateur ou un compte de service limité à l’organisation.

<h3 id="key-differences">
  Principales différences
</h3>

La liste suivante compare les identifiants d’authentification d’utilisateur et ceux de compte de service pour l’authentification SCIM :

* Cas d’usage : les utilisateurs sont plus adaptés aux actions d’administration interactives et ponctuelles. Les comptes de service sont plus adaptés à l’automatisation et aux intégrations (CI/CD, outils de provisionnement).
* Identifiants d’authentification : les utilisateurs envoient un nom d’utilisateur et une clé API pour l’authentification Basic. Les comptes de service envoient uniquement une clé API (sans nom d’utilisateur) pour l’authentification Basic. Pour l’authentification Bearer, envoyez uniquement la clé API dans l’en-tête (sans nom d’utilisateur).
* Bearer ou Basic : Bearer utilise `Authorization: Bearer [API-KEY]` avec la clé telle quelle. Basic utilise `Authorization: Basic <base64(...)>` (les utilisateurs encodent `username:API-KEY`, et les comptes de service encodent `:API-KEY`, précédé du caractère deux-points et avec un nom d’utilisateur vide).
* Portée et autorisations : utilisez la clé API d’un utilisateur administrateur de l’instance ou administrateur de l’organisation, ou celle d’un [compte de service limité à l’organisation](/fr/products/wandb/platform/hosting/iam/service-accounts#organization-scoped-service-accounts). Les clés des [comptes de service à portée d'équipe](/fr/products/wandb/platform/hosting/iam/service-accounts#team-scoped-service-accounts) ne permettent pas de s’authentifier auprès de l’API SCIM. Les comptes de service qui utilisent SCIM sont limités à l’organisation et fonctionnent sans interface, ce qui permet d’obtenir des pistes d’audit plus claires pour l’automatisation.
* Où obtenir les identifiants d’authentification : les utilisateurs copient leur clé API depuis les Paramètres utilisateur. Les clés des comptes de service limités à l’organisation se trouvent dans le tableau de bord de l’organisation, sous l’onglet **Service account**.
* Cloud mutualisé : si vous avez accès à plusieurs organisations Cloud mutualisé, vous devez définir l’organisation API par défaut afin que les appels d’API SCIM soient acheminés vers la bonne organisation.

<h3 id="bearer-token">
  Jeton Bearer
</h3>

Envoyez la clé API sous forme de jeton Bearer :

```bash theme={"system"}
Authorization: Bearer [API-KEY]
```

La valeur `[API-KEY]` correspond à la même chaîne que celle que vous utiliseriez comme mot de passe pour ce principal dans l'authentification HTTP Basic. N'encodez pas la clé en Base64 pour les requêtes Bearer.

<Note>
  L'authentification Bearer pour l'API SCIM est disponible dans le Cloud mutualisé W\&B, ainsi que dans le Cloud dédié et les déploiements autogérés à partir de la version v0.79.0.
</Note>

Les exemples suivants utilisent `[API-KEY]` comme espace réservé. Remplacez-le par une clé réelle appartenant à un utilisateur administrateur ou à un compte de service limité à l’organisation.

**Lister les utilisateurs**

```bash theme={"system"}
curl -s -S \
  -H "Authorization: Bearer [API-KEY]" \
  -H "Content-Type: application/scim+json" \
  "[HOST-URL]/scim/Users"
```

**Créer un utilisateur**

```bash theme={"system"}
curl -s -S -X POST \
  -H "Authorization: Bearer [API-KEY]" \
  -H "Content-Type: application/scim+json" \
  "[HOST-URL]/scim/Users" \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "dev-user2",
    "emails": [{"primary": true, "value": "dev-user2@example.com"}]
  }'
```

Pour plus d'informations, voir [Créer un utilisateur](#create-user).

<h3 id="users">
  Users
</h3>

Utilisez vos identifiants d’administration personnels pour effectuer des tâches d’administration interactives. Construisez l’en-tête HTTP `Authorization` sous la forme `Basic <base64(username:API-KEY)>`.

Par exemple, pour vous authentifier en tant que `demo:p@55w0rd` :

```bash theme={"system"}
Authorization: Basic ZGVtbzpwQDU1dzByZA==
```

<h3 id="service-accounts">
  Comptes de service
</h3>

Utilisez un compte de service limité à l’organisation pour les automatisations ou les intégrations. Construisez l’en-tête HTTP `Authorization` sous la forme `Basic <base64(:API-KEY)>` (notez le deux-points initial et le nom d’utilisateur vide). Vous trouverez les clés API des comptes de service dans le tableau de bord de l’organisation, sous l’onglet **Service account**. Reportez-vous à [Comptes de service limités à l’organisation](/fr/products/wandb/platform/hosting/iam/service-accounts#organization-scoped-service-accounts).

Par exemple, pour vous authentifier avec la clé API `sa-p@55w0rd` :

```bash theme={"system"}
Authorization: Basic OnNhLXBANTV3MHJk
```

<h2 id="microsoft-entra-id-configuration">
  Configuration de Microsoft Entra ID
</h2>

Utilisez cette section pour configurer le provisionnement automatique des utilisateurs et des groupes depuis Microsoft Entra ID vers W\&B via l’API SCIM.

Pour configurer le SSO avec Entra, voir [Configurer le SSO avec Entra](/fr/products/wandb/platform/hosting/iam/sso).

<h3 id="tenant-url">
  URL du locataire
</h3>

Dans les paramètres d'approvisionnement de votre application d'entreprise Entra, définissez **Tenant URL** sur votre URL de base SCIM W\&B, en y ajoutant le paramètre de requête `aadOptscim062020`, qui correspond à l'indicateur de fonctionnalité Entra :

```text theme={"system"}
[HOST-URL]/scim?aadOptscim062020
```

Par exemple, si votre instance se trouve à l’adresse `https://wandb.example.com`, définissez l’URL du locataire sur `https://wandb.example.com/scim?aadOptscim062020`.

Le paramètre `aadOptscim062020` active une gestion propre à Entra dans l’API SCIM de W\&B. Sans ce paramètre, Entra peut envoyer des requêtes de désactivation d’utilisateur contenant des valeurs booléennes sous forme de chaînes (`"False"` ou `"True"`) au lieu de booléens JSON (`false` ou `true`), ce qui peut faire échouer la désactivation.

Dans le champ **Secret Token**, saisissez la clé API d’un utilisateur administrateur de l’organisation ou d’un compte de service limité à l’organisation. Voir [Authentification](#authentication).

<Note>
  Lorsque vous ajoutez `aadOptscim062020` à l’URL du locataire, la désactivation d’utilisateurs depuis l’interface **Provision on demand** d’Entra, dans le centre d’administration Microsoft Entra, risque de ne pas fonctionner, car cette interface envoie toujours des valeurs booléennes sous forme de chaînes. Pour tester la désactivation manuellement, envoyez une requête SCIM `PATCH` au format `PatchOp` `Operations` qui remplace la valeur de `active` par `false` (voir [Désactiver un utilisateur](#deactivate-user)).
</Note>

<h3 id="team-names">
  Noms des équipes
</h3>

Nommez les groupes Entra associés aux équipes W\&B en utilisant des lettres minuscules et des traits d’union, par exemple `ml-platform` ou `data-science`. Évitez les espaces, les caractères de soulignement et tout autre caractère spécial dans les noms d’affichage des groupes que vous synchronisez avec W\&B.

<h3 id="user-attribute-mappings">
  Mappages d’attributs utilisateur
</h3>

Configurez les mappages d’attributs suivants dans Entra pour le provisionnement SCIM des utilisateurs :

| Attribut de l’application personnalisée W\&B | Attribut source (Entra) | Appliquer ce mappage | Faire correspondre les objets à l’aide de cet attribut |
| - | - | - | - |
| `emails[type eq "work"].value` | `mail` | Toujours | Oui |
| `active` | `Not([IsSoftDeleted])` | Toujours | |
| `displayName` | `displayName` | Toujours | |
| `userName` | `displayName` | Uniquement lors de la création de l’objet | |

<Note>
  Sur le **Cloud mutualisé**, le compte d’un utilisateur n’est pas géré par l’organisation. W\&B ne prend pas en charge la mise à jour de `displayName` via SCIM sur le Cloud mutualisé. Voir [Mettre à jour le nom d’affichage d’un utilisateur](#update-user-display-name).
</Note>

<h3 id="group-attribute-mappings">
  Mappages d’attributs de groupe
</h3>

Configurez les mappages d’attributs suivants dans Entra pour le provisionnement des groupes SCIM (équipes) :

| Attribut de l’application personnalisée W\&B | Attribut source (Entra) | Appliquer ce mappage | Faire correspondre les objets à l’aide de cet attribut |
| - | - | - | - |
| `displayName` | `displayName` | Uniquement lors de la création de l’objet | Oui |
| `members` | `members` | Toujours | |

<h2 id="user-management">
  Gestion des utilisateurs
</h2>

La ressource utilisateur SCIM correspond aux utilisateurs et aux comptes de service W\&B. Utilisez les points de terminaison de cette section pour provisionner, mettre à jour et supprimer des utilisateurs et des comptes de service dans votre organisation, par exemple lors de l’arrivée de nouveaux employés, pour faire pivoter les identifiants d’authentification des services ou pour révoquer l’accès des utilisateurs qui quittent l’organisation.

Pour en savoir plus sur les concepts relatifs aux comptes de service et les flux de travail dans l’interface utilisateur, consultez [Utiliser des comptes de service pour automatiser les flux de travail](/fr/products/wandb/platform/hosting/iam/service-accounts).

<Note>
  **Changement incompatible pour les intégrations qui analysent le JSON SCIM User**

  * Dans le Cloud dédié et les déploiements autogérés v0.80.1+, ainsi que dans les déploiements Cloud mutualisé après le 30 avril 2026, les réponses de `/scim/Users` (y compris les réponses `GET` d’un utilisateur, `GET` des utilisateurs et `PATCH` qui renvoient un User) sérialisent `emails` sous forme de tableau JSON d’objets dont les noms de champs sont en minuscules (`value`, `primary` et, de manière facultative, `type` ou `display`), conformément à SCIM 2.0.
  * Les déploiements sur des versions antérieures renvoient `emails` sous forme d’un objet JSON unique dont les clés sont en PascalCase (`Value`, `Primary`, etc.).

  Si votre code lit `emails` dans les *réponses* SCIM, traitez `emails` comme un tableau et lisez l’entrée principale (ou le premier élément).

  Les corps de requête de création ou de mise à jour d’utilisateurs utilisaient déjà la forme tableau et restent inchangés. Le filtre `list-users` `emails.value eq "..."` reste également inchangé.
</Note>

<h3 id="get-user">
  Obtenir un utilisateur
</h3>

Récupère les informations d’un utilisateur ou d’un compte de service spécifique de votre organisation à partir de son ID utilisateur, ou celles d’un utilisateur à partir de son adresse e-mail.

Les réponses concernant les comptes de service incluent `accountType` (`SERVICE` pour les comptes de service à portée d’équipe, `ORG_SERVICE` pour les comptes de service limités à l’organisation). Les comptes de service ne comportent pas de champ `emails`.

<h4 id="endpoint">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `GET`

<h4 id="parameters">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |

<h4 id="example">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête Get User">
    ```bash theme={"system"}
    GET /scim/Users/abc
    ```
  </Tab>

  <Tab title="Réponse Get User">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "daysActive": 42,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "lastActiveAt": "2023-10-15T14:32:10Z",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1"
    }
    ```

    La réponse fournit des informations sur l’activité de l’utilisateur au sein de l’organisation :

    * **`daysActive`** : nombre total de jours pendant lesquels l’utilisateur a été actif au sein de l’organisation.
    * **`lastActiveAt`** : horodatage ISO 8601 de la dernière activité de l’utilisateur. Renvoie `null` si l’utilisateur n’a jamais été actif.

    La définition d’« actif » varie selon le type de déploiement :

    * **Cloud dédié / autogéré** : un utilisateur est considéré comme actif s’il se connecte, ouvre une page quelconque de la W\&B App, journalise des runs, utilise le SDK ou interagit de quelque manière que ce soit avec le serveur W\&B.
    * **Cloud mutualisé** : un utilisateur est considéré comme actif s’il effectue, après le 8 mai 2025, une action auditable limitée à l’organisation. Pour la liste complète, voir [Actions de journalisation d’audit](/fr/products/wandb/platform/hosting/monitoring-usage/audit-logging#actions).
  </Tab>
</Tabs>

<h3 id="list-users">
  Lister les utilisateurs
</h3>

Récupère la liste de tous les utilisateurs et comptes de service de votre organisation. Chaque ressource comporte un champ `accountType` (`USER`, `SERVICE` ou `ORG_SERVICE`).

<h4 id="filter-users">
  Filtrer les utilisateurs
</h4>

Le point de terminaison `/Users` permet de filtrer les utilisateurs par nom d’utilisateur ou par adresse e-mail :

* `userName eq "value"` : filtrer par nom d’utilisateur.
* `emails.value eq "value"` : filtrer par adresse e-mail.

<h5 id="example-2">
  Exemple
</h5>

```bash theme={"system"}
GET /scim/Users?filter=userName eq "john.doe"
GET /scim/Users?filter=emails.value eq "john@example.com"
```

<h4 id="endpoint-2">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users`
* **Méthode** : `GET`

<h4 id="example-3">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de liste des utilisateurs">
    ```bash theme={"system"}
    GET /scim/Users
    ```
  </Tab>

  <Tab title="Réponse de liste des utilisateurs">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "Resources": [
            {
                "active": true,
                "daysActive": 42,
                "displayName": "Dev User 1",
                "emails": [
                    {
                        "primary": true,
                        "value": "dev-user1@example.com"
                    }
                ],
                "id": "abc",
                "lastActiveAt": "2023-10-15T14:32:10Z",
                "meta": {
                    "resourceType": "User",
                    "created": "2023-10-01T00:00:00Z",
                    "lastModified": "2023-10-01T00:00:00Z",
                    "location": "Users/abc"
                },
                "schemas": [
                    "urn:ietf:params:scim:schemas:core:2.0:User"
                ],
                "userName": "dev-user1"
            }
        ],
        "itemsPerPage": 9999,
        "schemas": [
            "urn:ietf:params:scim:api:messages:2.0:ListResponse"
        ],
        "startIndex": 1,
        "totalResults": 1
    }
    ```

    La réponse fournit des informations sur l’activité de chaque utilisateur au sein de l’organisation :

    * **`daysActive`** : nombre total de jours pendant lesquels l’utilisateur a été actif au sein de l’organisation.
    * **`lastActiveAt`** : horodatage ISO 8601 de la dernière activité de l’utilisateur. Renvoie `null` si l’utilisateur n’a jamais été actif.

    La définition d’« actif » varie selon le type de déploiement :

    * **Cloud dédié / autogéré** : un utilisateur est considéré comme actif s’il se connecte, ouvre une page de la W\&B App, journalise des runs, utilise le SDK ou interagit de quelque manière que ce soit avec le serveur W\&B.
    * **Cloud mutualisé** : un utilisateur est considéré comme actif s’il effectue, après le 8 mai 2025, une action auditable limitée à l’organisation. Consultez [Actions de journalisation d’audit](/fr/products/wandb/platform/hosting/monitoring-usage/audit-logging#actions) pour la liste complète.
  </Tab>
</Tabs>

<h3 id="create-user">
  Créer un utilisateur
</h3>

Crée un nouvel utilisateur dans votre organisation.

<h4 id="endpoint-3">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users`
* **Méthode** : `POST`

<h4 id="parameters-2">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `emails` | array | Oui | Tableau d’objets e-mail. Doit inclure une adresse e-mail principale |
| `userName` | string | Oui | Le nom d’utilisateur du nouvel utilisateur |
| `modelsSeat` | string | Non | Niveau de licence Models. Valeurs possibles : `full`, `viewer` ou `none`. Valeur par défaut : `full`. |
| `weaveRole` | string | Non | Niveau de rôle Weave. Valeurs possibles : `full`, `viewer` ou `none`. Valeur par défaut : `full`. |
| `registryAccess` | string | Non | Droit d’accès au registre. Valeurs possibles : `enabled` ou `none`. Si ce paramètre est omis, l’accès effectif est déduit de `modelsSeat` et `weaveRole` au moment de la lecture. Disponible dans le **Cloud mutualisé**, ainsi que dans le **Cloud dédié** et en déploiement **autogéré** à partir de la v0.83.0. |

<h4 id="example-4">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de création d’utilisateur (Cloud dédié/autogéré)">
    ```bash theme={"system"}
    POST /scim/Users
    ```

    ```json theme={"system"}
    {
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "emails": [
            {
                "primary": true,
                "value": "dev-user2@example.com"
            }
        ],
        "userName": "dev-user2",
        "modelsSeat": "full",
        "weaveRole": "full"
    }
    ```
  </Tab>

  <Tab title="Requête de création d’utilisateur (Cloud mutualisé)">
    ```bash theme={"system"}
    POST /scim/Users
    ```

    ```json theme={"system"}
    {
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User",
            "urn:ietf:params:scim:schemas:extension:teams:2.0:User"
        ],
        "emails": [
            {
                "primary": true,
                "value": "dev-user2@example.com"
            }
        ],
        "userName": "dev-user2",
        "modelsSeat": "full",
        "weaveRole": "full",
        "urn:ietf:params:scim:schemas:extension:teams:2.0:User": {
            "teams": ["my-team"]
        }
    }
    ```
  </Tab>
</Tabs>

<h4 id="response">
  Réponse
</h4>

<Tabs>
  <Tab title="Réponse de création d’utilisateur (Cloud dédié/autogéré)">
    ```text theme={"system"}
    (Status 201)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 2",
        "emails": [
            {
                "primary": true,
                "value": "dev-user2@example.com"
            }
        ],
        "id": "def",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "location": "Users/def"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "modelsSeat": "full",
        "weaveRole": "full",
        "userName": "dev-user2"
    }
    ```
  </Tab>

  <Tab title="Réponse de création d’utilisateur (Cloud mutualisé)">
    ```text theme={"system"}
    (Status 201)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 2",
        "emails": [
            {
                "primary": true,
                "value": "dev-user2@example.com"
            }
        ],
        "id": "def",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "location": "Users/def"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User",
            "urn:ietf:params:scim:schemas:extension:teams:2.0:User"
        ],
        "userName": "dev-user2",
        "organizationRole": "member",
        "modelsSeat": "full",
        "weaveRole": "full",
        "teamRoles": [
            {
                "teamName": "my-team",
                "roleName": "member"
            }
        ],
        "groups": [
            {
                "value": "my-team-id"
            }
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="provision-service-account">
  Provisionner un compte de service
</h3>

Crée un compte de service à portée d'équipe ou limité à l’organisation. Utilisez ce point de terminaison pour créer des identités sans interface destinées à l’automatisation, à la CI/CD ou aux intégrations qui ne doivent pas être liées à un utilisateur humain. Pour créer un utilisateur standard, omettez `accountType`. Voir [Créer un utilisateur](#create-user).

<Note>
  Disponible dans le **Cloud dédié** et en mode **autogéré** v0.81.0+, ainsi que dans le **Cloud mutualisé**.

  * Définissez `userName` sur le nom du compte de service. L’API utilise `userName` comme nom d’affichage du compte. Le champ `displayName` du corps de requête est ignoré.
  * Les `emails` ne sont pas requis pour les comptes de service.
  * `modelsSeat` et `weaveRole` ne sont pas pris en charge lors de la création et renvoient `400 Bad Request` s’ils sont présents.
  * Les comptes de service ne peuvent pas être mis à jour avec `PATCH` ou `PUT` ni être désactivés, et aucun rôle d’organisation, d’équipe ou de registre ne peut leur être attribué via SCIM. Après le provisionnement, créez des clés API dans la W\&B App.
</Note>

<h4 id="endpoint-4">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users`
* **Méthode** : `POST`

<h4 id="parameters-3">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `userName` | string | Oui | Nom unique du compte de service. |
| `accountType` | string | Oui | `SERVICE` pour un [compte de service à portée d’équipe](/fr/products/wandb/platform/hosting/iam/service-accounts#team-scoped-service-accounts), ou `ORG_SERVICE` pour un [compte de service limité à l’organisation](/fr/products/wandb/platform/hosting/iam/service-accounts#organization-scoped-service-accounts). |
| `urn:ietf:params:scim:schemas:extension:teams:2.0:User` | object | Oui | Objet d’extension Teams. |
| `defaultTeam` | string | Oui | Sous-champ de l’extension Teams. Nom d’une équipe W\&B existante. Le compte de service est créé en tant que membre de cette équipe. Pour les comptes de service à portée d’équipe, il s’agit de la seule équipe qu’ils rejoignent. Les comptes de service limités à l’organisation sont également ajoutés automatiquement aux équipes créées ultérieurement via SCIM. |
| `teams` | array | Non | **Cloud mutualisé uniquement.** Noms des équipes auxquelles ajouter le compte. Si vous utilisez ce champ, incluez-y également l’équipe indiquée dans `defaultTeam`. |

<h4 id="example-5">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de provisionnement d’un compte de service d’équipe">
    ```bash theme={"system"}
    POST /scim/Users
    ```

    ```json theme={"system"}
    {
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User",
            "urn:ietf:params:scim:schemas:extension:teams:2.0:User"
        ],
        "userName": "sa-deploy-bot",
        "accountType": "SERVICE",
        "urn:ietf:params:scim:schemas:extension:teams:2.0:User": {
            "defaultTeam": "ml-platform"
        }
    }
    ```
  </Tab>

  <Tab title="Requête de provisionnement d’un compte de service d’organisation">
    ```bash theme={"system"}
    POST /scim/Users
    ```

    ```json theme={"system"}
    {
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User",
            "urn:ietf:params:scim:schemas:extension:teams:2.0:User"
        ],
        "userName": "sa-ci-runner",
        "accountType": "ORG_SERVICE",
        "urn:ietf:params:scim:schemas:extension:teams:2.0:User": {
            "defaultTeam": "ml-platform"
        }
    }
    ```
  </Tab>
</Tabs>

<h4 id="response-2">
  Réponse
</h4>

<Tabs>
  <Tab title="Réponse du provisionnement d’un compte de service d’équipe">
    ```text theme={"system"}
    (Status 201)
    ```

    ```json theme={"system"}
    {
        "accountType": "SERVICE",
        "active": true,
        "displayName": "sa-deploy-bot",
        "id": "xyz",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "location": "Users/xyz"
        },
        "organizationRole": "member",
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User",
            "urn:ietf:params:scim:schemas:extension:wandb:2.0:User"
        ],
        "teamRoles": [
            {
                "teamName": "ml-platform",
                "roleName": "member"
            }
        ],
        "urn:ietf:params:scim:schemas:extension:wandb:2.0:User": {
            "organizationRole": "member"
        },
        "userName": "sa-deploy-bot"
    }
    ```
  </Tab>

  <Tab title="Réponse du provisionnement d’un compte de service d’organisation">
    ```text theme={"system"}
    (Status 201)
    ```

    ```json theme={"system"}
    {
        "accountType": "ORG_SERVICE",
        "active": true,
        "displayName": "sa-ci-runner",
        "id": "xyz",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "location": "Users/xyz"
        },
        "organizationRole": "member",
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User",
            "urn:ietf:params:scim:schemas:extension:wandb:2.0:User"
        ],
        "teamRoles": [
            {
                "teamName": "ml-platform",
                "roleName": "member"
            }
        ],
        "urn:ietf:params:scim:schemas:extension:wandb:2.0:User": {
            "organizationRole": "member"
        },
        "userName": "sa-ci-runner"
    }
    ```
  </Tab>
</Tabs>

Pour un compte de service limité à l’organisation, `accountType` vaut `ORG_SERVICE`.

Dans les déploiements **autogérés**, `organizationRole` vaut `service` ou `org_service` au lieu de `member`, selon le type de compte.

Si l’une des erreurs suivantes est renvoyée, vérifiez que la requête ne présente pas l’un de ces problèmes courants :

* `409 Conflict` : la requête contient des clés `userName` en double pour le même compte de service.
* `400 Bad Request` : la requête ne contient pas `defaultTeam` ou lui attribue une valeur non valide.

<h3 id="deprovision-service-account">
  Déprovisionner un compte de service
</h3>

Supprime définitivement un compte de service ainsi que son appartenance à l’organisation. Utilisez ce point de terminaison lorsqu’un compte de service n’est plus nécessaire (par exemple, après la mise hors service d’un pipeline d’automatisation). Cette suppression est définitive : le compte ne peut pas être réactivé via SCIM.

<Note>
  Disponible dans le **Cloud dédié** et en **autogéré** à partir de la v0.81.0, ainsi que dans le **Cloud mutualisé**. Utilisez l’`id` d’utilisateur SCIM du compte de service, obtenu dans la réponse de provisionnement ou via [Get user](#get-user). Le déprovisionnement ne supprime pas les clés API déjà émises. Si nécessaire, révoquez-les séparément dans la W\&B App.
</Note>

<h4 id="endpoint-5">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `DELETE`

<h4 id="parameters-4">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique du compte de service. |

<h4 id="example-6">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de déprovisionnement d’un compte de service">
    ```bash theme={"system"}
    DELETE /scim/Users/xyz
    ```
  </Tab>

  <Tab title="Réponse de déprovisionnement d’un compte de service">
    ```text theme={"system"}
    (Status 204)
    ```
  </Tab>
</Tabs>

<h3 id="delete-user">
  Supprimer un utilisateur
</h3>

<Warning>
  **Conserver l’accès administrateur**

  Veillez à ce qu’il existe toujours au moins un utilisateur administrateur dans votre instance ou votre organisation. Sinon, aucun utilisateur ne pourra configurer ni gérer le compte W\&B de votre organisation. Si une organisation utilise SCIM ou un autre processus automatisé pour déprovisionner des utilisateurs de W\&B, une opération de déprovisionnement risque de supprimer par inadvertance le dernier administrateur de l’instance ou de l’organisation.

  Pour obtenir de l’aide dans l’élaboration de procédures opérationnelles, ou pour restaurer l’accès administrateur, contactez l’[assistance](mailto:forge-support@coreweave.com).
</Warning>

Supprime complètement un utilisateur de votre organisation. Pour supprimer un compte de service, voir [Déprovisionner un compte de service](#deprovision-service-account).

<h4 id="endpoint-6">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `DELETE`

<h4 id="parameters-5">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur à supprimer |

<h4 id="example-7">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de suppression d’utilisateur">
    ```bash theme={"system"}
    DELETE /scim/Users/abc
    ```
  </Tab>

  <Tab title="Réponse de suppression d’utilisateur">
    ```text theme={"system"}
    (Status 204)
    ```
  </Tab>
</Tabs>

<Note>
  Pour désactiver temporairement l’utilisateur, reportez-vous à l’API [Désactiver un utilisateur](#deactivate-user), qui utilise le point de terminaison `PATCH`.
</Note>

<h3 id="update-user-email">
  Mettre à jour l’adresse e-mail d’un utilisateur
</h3>

Met à jour l’adresse e-mail principale d’un utilisateur.

**Non pris en charge dans le Cloud multilocataire**, où le compte de l’utilisateur n’est pas géré par l’organisation.

<h4 id="endpoint-7">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-6">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `emails` |
| `value` | array | Oui | Tableau contenant le nouvel objet e-mail |

<h4 id="example-8">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de mise à jour de l’adresse e-mail">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "emails",
                "value": [
                    {
                        "value": "newemail@example.com",
                        "primary": true
                    }
                ]
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de mise à jour de l’adresse e-mail">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "newemail@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1"
    }
    ```
  </Tab>
</Tabs>

<h3 id="update-user-display-name">
  Mettre à jour le nom d’affichage d’un utilisateur
</h3>

Met à jour le nom d’affichage d’un utilisateur.

**Non pris en charge dans le Cloud multilocataire**, où le compte des utilisateurs n’est pas géré par l’organisation.

<h4 id="endpoint-8">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-7">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `displayName` |
| `value` | string | Oui | Nouveau nom d’affichage |

<h4 id="example-9">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de mise à jour du nom d’affichage">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "displayName",
                "value": "John Doe"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse à la mise à jour du nom d’affichage">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "John Doe",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2025-7-01T00:00:00Z",
            "lastModified": "2025-7-01T00:00:00Z",
            "location": "users/dev-user1"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1"
    }
    ```
  </Tab>
</Tabs>

<h3 id="deactivate-user">
  Désactiver un utilisateur
</h3>

Désactive un utilisateur de votre organisation. Le résultat varie selon le type de déploiement :

* **Cloud dédié** / **Autogéré** : définit le champ `active` de l'utilisateur sur `false`. Pour rétablir l'accès d'un utilisateur désactivé à votre organisation, voir [Réactiver un utilisateur](#reactivate-user).
* **Cloud multilocataire** : retire l'utilisateur de l'organisation. Pour lui rendre l'accès, ajoutez-le de nouveau à votre organisation. Voir [Créer un utilisateur](#create-user-request-multi-tenant). Dans le Cloud multilocataire, le compte de l'utilisateur n'est pas géré par l'organisation.

<Note>Cette opération s'applique uniquement aux utilisateurs, et non aux comptes de service. La désactivation d'un compte de service n'est pas prise en charge. Gérez les comptes de service d'équipe dans les paramètres de l'équipe W\&B.</Note>

<h4 id="endpoint-9">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-8">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | ID unique de l’utilisateur à désactiver |
| `op` | string | Oui | `replace` |
| `value` | object | Oui | Objet contenant `{"active": false}` |

<h4 id="example-10">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête Deactivate User (Cloud dédié/autogéré)">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "value": {"active": false}
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Requête Deactivate User (Cloud multilocataire)">
    ```bash theme={"system"}
    PATCH /scim/Users
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "value": {"active": false}
            }
        ]
    }
    ```
  </Tab>
</Tabs>

<h4 id="response-3">
  Réponse
</h4>

<Tabs>
  <Tab title="Réponse de Deactivate User (Cloud dédié/autogéré)">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": false,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1"
    }
    ```
  </Tab>

  <Tab title="Réponse de Deactivate User (Cloud mutualisé)">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "value": {"active": true}
            }
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="reactivate-user">
  Réactiver un utilisateur
</h3>

Réactive un utilisateur précédemment désactivé dans votre organisation.

<Note>
  * La réactivation s’applique uniquement aux utilisateurs, et non aux comptes de service. Elle n’est pas prise en charge pour les comptes de service. Gérez les comptes de service dans les paramètres de l’équipe W\&B.

  * La réactivation des utilisateurs n’est pas prise en charge dans le [Cloud multilocataire](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud). Pour rétablir l’accès de l’utilisateur, ajoutez-le de nouveau à votre organisation. Voir [Créer un utilisateur](#create-user-request-multi-tenant). Dans le Cloud multilocataire, le compte d’un utilisateur n’est pas géré par l’organisation. Toute tentative de réactivation d’un utilisateur renvoie une erreur HTTP `400`. Le champ `detail` du corps de la réponse est renvoyé tel quel par l’API et peut encore employer l’ancienne dénomination du produit :
    ```json theme={"system"}
    {
        "schemas": [
            "urn:ietf:params:scim:api:messages:2.0:Error"
        ],
        "detail": "User reactivation operations are not supported in SaaS Cloud",
        "status": "400"
    }
    ```
</Note>

<h4 id="endpoint-10">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-9">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | ID unique de l’utilisateur à réactiver |
| `op` | string | Oui | `replace` |
| `value` | object | Oui | Objet contenant `{"active": true}` |

<h4 id="example-11">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de réactivation d'un utilisateur">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "value": {"active": true}
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de réactivation d'un utilisateur">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1"
    }
    ```
  </Tab>
</Tabs>

<h3 id="assign-organization-role">
  Attribuer un rôle d’organisation
</h3>

Attribue un rôle au niveau de l’organisation à un utilisateur.

<Note>Cette opération s’applique uniquement aux utilisateurs, et non aux comptes de service. Les rôles personnalisés ne sont pas pris en charge pour les comptes de service.</Note>

<h4 id="endpoint-11">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-10">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `organizationRole` |
| `value` | string | Oui | Nom du rôle (`admin` ou `member`) |

<Note>
  Le rôle `viewer` limité à l’organisation est obsolète et ne peut plus être attribué dans l’interface utilisateur. Si vous utilisez SCIM pour attribuer le rôle `viewer` à un utilisateur :

  * Il se voit attribuer le rôle `member` dans l’organisation.
  * Son `modelsSeat` est défini sur `viewer` au lieu de `full`, ce qui lui donne un accès en lecture seule à Models et un accès complet au registre. Si aucune licence Models n’est disponible, une erreur `Seat limit reached` est renvoyée. Ce paramètre peut être mis à jour ultérieurement lorsqu’une licence se libère.
  * Son `weaveRole` est défini sur `viewer` au lieu de `full`, ce qui lui donne un accès en lecture seule à Weave.
  * Tous ses rôles d’équipe et de projet existants sont définis sur `viewer`.
  * Il se voit attribuer le rôle registre `viewer` dans les registres visibles au niveau de l’organisation.

  L’attribution du rôle d’organisation `member` ou `admin` ne modifie ni le `modelsSeat` ni le `weaveRole` de l’utilisateur.
</Note>

<h4 id="example-12">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête d’attribution de rôle d’organisation">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "organizationRole",
                "value": "admin"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse d’attribution de rôle d’organisation">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "teamRoles": [
            {
                "teamName": "team1",
                "roleName": "admin"
            }
        ],
        "organizationRole": "admin"
    }
    ```
  </Tab>
</Tabs>

<h3 id="update-models-seat">
  Mettre à jour la licence Models
</h3>

Met à jour la licence Models d’un utilisateur.

<Note>
  Sur **Cloud multilocataire**, ainsi que sur **Cloud dédié** et en **autogéré** à partir de la v0.83.0, l’accès au registre est dissocié des licences Models. Définir `modelsSeat` sur `none` ne révoque plus l’accès au registre lorsque le `weaveRole` de l’utilisateur est différent de `none`. Pour révoquer l’accès au registre sur ces déploiements, utilisez [Mettre à jour l’accès au registre](#update-registry-access) et définissez `registryAccess` sur `none`.

  Sur **Cloud dédié** et en **autogéré** v0.82.0 et versions antérieures, l’accès au registre reste lié à `modelsSeat`. Sur ces versions, définissez `modelsSeat` sur `none` pour révoquer l’accès au registre.
</Note>

<h4 id="endpoint-12">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-11">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `modelsSeat` |
| `value` | string | Oui | Niveau de licence (`full`, `viewer` ou `none`) |

<h4 id="example-13">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de mise à jour de la licence Models">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "modelsSeat",
                "value": "full"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de mise à jour de la licence Models">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "organizationRole": "member",
        "modelsSeat": "full",
        "weaveRole": "full"
    }
    ```
  </Tab>
</Tabs>

<h3 id="update-weave-role">
  Mettre à jour le rôle Weave
</h3>

Met à jour le rôle Weave d’un utilisateur.

<h4 id="endpoint-13">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-12">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `weaveRole` |
| `value` | string | Oui | Niveau du rôle (`full`, `viewer` ou `none`) |

<h4 id="example-14">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de mise à jour du rôle Weave">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "weaveRole",
                "value": "full"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de mise à jour du rôle Weave">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "organizationRole": "member",
        "modelsSeat": "full",
        "weaveRole": "full"
    }
    ```
  </Tab>
</Tabs>

<h3 id="update-registry-access">
  Mettre à jour l’accès au registre
</h3>

Accorde ou révoque l’accès au registre au niveau de l’organisation pour un utilisateur. Ce droit est distinct des [rôles du registre](#add-to-registry) (`registryRoles`), qui contrôlent les autorisations propres à chaque registre une fois que l’utilisateur dispose de ce droit.

Sur **Cloud mutualisé**, ainsi que sur **Cloud dédié** et **autogéré** v0.83.0 ou version ultérieure, les utilisateurs dont la valeur de `modelsSeat` ou de `weaveRole` est différente de `none` ont accès au registre par défaut. Définissez `registryAccess` sur `none` pour révoquer l’accès au registre sans modifier leur licence Models ni leur rôle Weave.

Sur **Cloud dédié** et **autogéré** v0.82.0 ou version antérieure, utilisez [Mettre à jour la licence Models](#update-models-seat) et définissez `modelsSeat` sur `none` pour révoquer l’accès au registre. L’attribut `registryAccess` n’est pas disponible dans ces versions.

Si vous omettez `registryAccess` lors de la création, l’API déduit l’accès effectif à partir des valeurs `modelsSeat` et `weaveRole` de l’utilisateur lorsque vous lisez celui-ci. Une valeur `registryAccess` explicite prévaut sur cette déduction. Les utilisateurs disposant du rôle d’organisation limité à la facturation n’obtiennent pas d’accès au registre par cette déduction.

<h4 id="endpoint-14">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-13">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `registryAccess` |
| `value` | string | Oui | Droit d’accès au registre (`enabled` ou `none`) |

<h4 id="example-15">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de révocation de l’accès au registre">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "registryAccess",
                "value": "none"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de révocation de l’accès au registre">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "organizationRole": "member",
        "modelsSeat": "none",
        "weaveRole": "full",
        "registryAccess": "none"
    }
    ```
  </Tab>
</Tabs>

<h3 id="assign-team-role">
  Attribuer un rôle d’équipe
</h3>

Attribue un rôle d’équipe à un utilisateur.

<Note>Cette opération s’applique uniquement aux utilisateurs, et non aux comptes de service. Les rôles personnalisés ne sont pas pris en charge pour les comptes de service.</Note>

<h4 id="endpoint-15">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-14">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `replace` |
| `path` | string | Oui | `teamRoles` |
| `value` | array | Oui | Tableau d’objets contenant `teamName` et `roleName` |

<h4 id="example-16">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête d’attribution d’un rôle d’équipe">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "teamRoles",
                "value": [
                    {
                        "roleName": "admin",
                        "teamName": "team1"
                    }
                ]
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse à l’attribution d’un rôle d’équipe">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "teamRoles": [
            {
                "teamName": "team1",
                "roleName": "admin"
            }
        ],
        "organizationRole": "admin"
    }
    ```
  </Tab>
</Tabs>

<h3 id="add-to-registry">
  Ajouter au registre
</h3>

Ajoute un utilisateur à un registre en lui attribuant un rôle au niveau du registre.

<Note>Cette opération s’applique uniquement aux utilisateurs, et non aux comptes de service. Les rôles personnalisés ne sont pas pris en charge pour les comptes de service.</Note>

<h4 id="endpoint-16">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-15">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `add` |
| `path` | string | Oui | `registryRoles` |
| `value` | array | Oui | Tableau d’objets contenant `registryName` et `roleName` |

<h4 id="example-17">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête d’ajout au registre">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "registryRoles",
                "value": [
                    {
                        "roleName": "admin",
                        "registryName": "hello-registry"
                    }
                ]
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse d’ajout au registre">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "registryRoles": [
            {
                "registryName": "hello-registry",
                "roleName": "admin"
            }
        ],
        "organizationRole": "admin"
    }
    ```
  </Tab>
</Tabs>

<h3 id="remove-from-registry">
  Retirer d’un registre
</h3>

Retire un utilisateur d’un registre.

<Note>
  Cette opération retire un utilisateur d’un registre spécifique. Elle ne révoque pas l’accès au registre à l’échelle de l’organisation. Pour révoquer entièrement l’accès au registre, utilisez [Mettre à jour l’accès au registre](#update-registry-access).
</Note>

<Note>
  * Les opérations de retrait respectent les spécifications du protocole SCIM définies par la RFC 7644. Utilisez la syntaxe de filtre `"registryRoles[registryName eq \"{registry_name}\"]"` pour retirer un utilisateur d’un registre spécifique, ou `"registryRoles"` pour le retirer de tous les registres.
  * Cette opération ne s’applique qu’aux utilisateurs, pas aux comptes de service. Pour retirer des comptes de service d’un registre, passez par les paramètres de l’équipe W\&B.
</Note>

<h4 id="endpoint-17">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Users/{id}`
* **Méthode** : `PATCH`

<h4 id="parameters-16">
  Paramètres
</h4>

| Paramètre | Type | Requis | Description |
| - | - | - | - |
| `id` | string | Oui | L’ID unique de l’utilisateur |
| `op` | string | Oui | `remove` |
| `path` | string | Oui | `"registryRoles[registryName eq \"{registry_name}\"]"` ou `"registryRoles"` |

<h4 id="example-18">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête de retrait du registre">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "registryRoles[registryName eq \"goodbye-registry\"]"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de retrait du registre">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "registryRoles": [
            {
                "registryName": "hello-registry",
                "roleName": "admin"
            }
        ],
        "organizationRole": "admin"
    }
    ```
  </Tab>
</Tabs>

<Tabs>
  <Tab title="Requête de retrait de TOUS les registres">
    ```bash theme={"system"}
    PATCH /scim/Users/abc
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "replace",
                "path": "registryRoles"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse de retrait de TOUS les registres">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "active": true,
        "displayName": "Dev User 1",
        "emails": [
            {
                "primary": true,
                "value": "dev-user1@example.com"
            }
        ],
        "id": "abc",
        "meta": {
            "resourceType": "User",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Users/abc"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "userName": "dev-user1",
        "organizationRole": "admin"
    }
    ```
  </Tab>
</Tabs>

<h2 id="group-resource">
  Ressource Group
</h2>

La ressource de groupe SCIM correspond à une équipe W\&B. Les points de terminaison de cette section vous permettent de créer des équipes, de gérer leurs membres et, si vous le souhaitez, de configurer le stockage au niveau de l’équipe depuis votre fournisseur d’identité ou vos outils d’automatisation. Lorsque vous créez un groupe SCIM dans votre IAM, une équipe W\&B est créée et associée à ce groupe. Les autres opérations sur le groupe SCIM s’appliquent ensuite à cette équipe. Pour configurer un stockage personnalisé lors de la création de l’équipe, incluez `storageBucket` dans la requête.

<h3 id="service-accounts-2">
  Comptes de service
</h3>

Lorsque vous créez une équipe W\&B à l’aide de SCIM, tous les comptes de service au niveau de l’organisation sont automatiquement ajoutés à l’équipe, afin qu’ils conservent leur accès aux ressources de l’équipe.

<h3 id="filter-groups">
  Filtrer les groupes
</h3>

Le point de terminaison `/Groups` prend en charge le filtrage, ce qui permet de rechercher des équipes précises.

<h4 id="supported-filters">
  Filtres pris en charge
</h4>

Le point de terminaison `/Groups` prend en charge le filtre suivant :

* `displayName eq "value"` : filtre par nom d’affichage de l’équipe.

<h4 id="example-19">
  Exemple
</h4>

```bash theme={"system"}
GET /scim/Groups?filter=displayName eq "engineering-team"
```

<h3 id="get-team">
  Obtenir une équipe
</h3>

Récupérez les informations d’une équipe en fournissant son ID unique.

<h4 id="endpoint-18">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Groups/{id}`
* **Méthode** : `GET`

<h4 id="example-20">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    GET /scim/Groups/ghi
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "displayName": "acme-devs",
        "id": "ghi",
        "members": [
            {
                "Value": "abc",
                "Ref": "",
                "Type": "",
                "Display": "dev-user1"
            }
        ],
        "meta": {
            "resourceType": "Group",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Groups/ghi"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:Group"
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="list-teams">
  Lister les équipes
</h3>

Récupérer la liste des équipes.

<h4 id="endpoint-19">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Groups`
* **Méthode** : `GET`

<h4 id="example-21">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    GET /scim/Groups
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "Resources": [
            {
                "displayName": "acme-devs",
                "id": "ghi",
                "members": [
                    {
                        "Value": "abc",
                        "Ref": "",
                        "Type": "",
                        "Display": "dev-user1"
                    }
                ],
                "meta": {
                    "resourceType": "Group",
                    "created": "2023-10-01T00:00:00Z",
                    "lastModified": "2023-10-01T00:00:00Z",
                    "location": "Groups/ghi"
                },
                "schemas": [
                    "urn:ietf:params:scim:schemas:core:2.0:Group"
                ]
            }
        ],
        "itemsPerPage": 9999,
        "schemas": [
            "urn:ietf:params:scim:api:messages:2.0:ListResponse"
        ],
        "startIndex": 1,
        "totalResults": 1
    }
    ```
  </Tab>
</Tabs>

<h3 id="create-team">
  Créer une équipe
</h3>

Crée une nouvelle ressource d’équipe.

<h4 id="endpoint-20">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Groups`
* **Méthode** : `POST`

<h4 id="supported-fields">
  Champs pris en charge
</h4>

| Champ | Type | Requis |
| - | - | - |
| `displayName` | String | Oui |
| `members` | Multi-Valued Array | Oui (le sous-champ `value` est requis et correspond à un ID d’utilisateur) |
| `storageBucket` | Object | Non |

Vous pouvez configurer un [Bring your own bucket (BYOB)](/fr/products/wandb/platform/hosting/data-security/secure-storage-connector) au niveau de l’équipe lors de sa création en incluant un objet `storageBucket`. En l’absence de cet objet, l’équipe utilise le stockage par défaut ou celui de l’instance. Provisionnez le bucket (stratégie, CORS, identifiants d’authentification) et déterminez le format de l’adresse de stockage propre à chaque fournisseur à l’aide du guide BYOB. L’objet `storageBucket` comporte les sous-champs suivants :

* **Requis** : `name` (nom du bucket), `provider` (l’une des valeurs `COREWEAVE`, `AWS`, `AZURE`, `GCP` ou `MINIO`). La valeur est sensible à la casse : utilisez les majuscules comme indiqué.
* **Facultatif** : `path` (préfixe de chemin dans le bucket), `kmsKeyId` (clé KMS utilisée pour le chiffrement, par exemple sur AWS), `awsExternalId` (accès intercomptes AWS), `azureTenantId` (ID de locataire Azure), `azureClientId` (ID client de l’identité managée Azure).

Avant de créer l’équipe, W\&B vérifie que le bucket existe et qu’il est accessible. En cas d’échec de cette validation, la requête SCIM échoue et l’équipe n’est pas créée.

Une valeur `provider` non valide renvoie `400 Bad Request` avec une erreur SCIM qui indique les valeurs autorisées.

<h4 id="examples">
  Exemples
</h4>

Ces exemples montrent comment créer une équipe sans stockage personnalisé, puis avec un stockage BYOB chez un fournisseur donné. Sélectionnez l’onglet correspondant à la configuration de stockage souhaitée pour afficher un exemple de requête, puis sélectionnez l’onglet **Réponse** pour afficher un exemple de réponse.

<Tabs>
  <Tab title="Requête (sans BYOB)">
    ```bash theme={"system"}
    POST /scim/Groups
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
        "displayName": "wandb-support",
        "members": [
            {
                "value": "def"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="CoreWeave">
    ```bash theme={"system"}
    POST /scim/Groups
    Content-Type: application/scim+json
    ```

    ```json theme={"system"}
    {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
      "displayName": "ml-training-team",
      "members": [
        {
          "value": "user@example.com",
          "display": "user@example.com"
        }
      ],
      "storageBucket": {
        "name": "wandb-coreweave-bucket",
        "provider": "COREWEAVE",
        "path": "ml-training/experiments"
      }
    }
    ```
  </Tab>

  <Tab title="AWS S3">
    ```bash theme={"system"}
    POST /scim/Groups
    Content-Type: application/scim+json
    ```

    ```json theme={"system"}
    {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
      "displayName": "ml-team",
      "members": [
        {
          "value": "user@example.com",
          "display": "user@example.com"
        }
      ],
      "storageBucket": {
        "name": "my-company-wandb-data",
        "provider": "AWS",
        "path": "ml-team/experiments",
        "kmsKeyId": "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012",
        "awsExternalId": "wandb-external-id-abc123"
      }
    }
    ```
  </Tab>

  <Tab title="Azure">
    ```bash theme={"system"}
    POST /scim/Groups
    Content-Type: application/scim+json
    ```

    ```json theme={"system"}
    {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
      "displayName": "research-team",
      "members": [],
      "storageBucket": {
        "name": "wandbstorage",
        "provider": "AZURE",
        "path": "research/artifacts",
        "azureTenantId": "12345678-1234-1234-1234-123456789012",
        "azureClientId": "87654321-4321-4321-4321-210987654321"
      }
    }
    ```
  </Tab>

  <Tab title="GCP">
    ```bash theme={"system"}
    POST /scim/Groups
    Content-Type: application/scim+json
    ```

    ```json theme={"system"}
    {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
      "displayName": "data-science-team",
      "members": [
        {
          "value": "VXNlcjox",
          "display": "jane.doe@example.com"
        },
        {
          "value": "VXNlcjoy",
          "display": "john.smith@example.com"
        }
      ],
      "storageBucket": {
        "name": "my-gcs-bucket",
        "provider": "GCP",
        "path": "data-science/runs"
      }
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 201)
    ```

    ```json theme={"system"}
    {
        "displayName": "wandb-support",
        "id": "jkl",
        "members": [
            {
                "Value": "def",
                "Ref": "",
                "Type": "",
                "Display": "dev-user2"
            }
        ],
        "meta": {
            "resourceType": "Group",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:00:00Z",
            "location": "Groups/jkl"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:Group"
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="update-team">
  Mettre à jour une équipe
</h3>

Met à jour la liste des membres d’une équipe existante.

<h4 id="endpoint-21">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Groups/{id}`
* **Méthode** : `PATCH`
* **Opérations prises en charge** : `add` (ajout d’un membre), `remove` (suppression d’un membre), `replace` (remplacement des membres).

<Note>
  - Les opérations de suppression respectent les spécifications du protocole SCIM définies dans la RFC 7644. Utilisez la syntaxe de filtre `members[value eq "{user_id}"]` pour supprimer un utilisateur précis, ou `members` pour supprimer tous les utilisateurs de l’équipe.

    **Identification de l’utilisateur** : dans les opérations sur les membres, `{user_id}` peut correspondre à l’un des éléments suivants :

    * Un ID d’utilisateur W\&B.
    * Une adresse e-mail (par exemple, « [user@example.com](mailto:user@example.com) »).
  - Ces opérations s’appliquent uniquement aux utilisateurs, et non aux comptes de service. Pour modifier les comptes de service d’une équipe, accédez aux paramètres de l’équipe W\&B.
</Note>

<Info>
  Dans vos requêtes, remplacez `{team_id}` par l’ID réel de l’équipe et `{user_id}` par l’ID réel de l’utilisateur ou par son adresse e-mail.
</Info>

<h3 id="replace-team-members">
  Remplacer les membres de l’équipe
</h3>

Remplace tous les membres d’une équipe par une nouvelle liste.

<Note>Cette opération s’applique uniquement aux utilisateurs, pas aux comptes de service. Gérez les comptes de service dans les paramètres de l’équipe W\&B.</Note>

<h4 id="endpoint-22">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Groups/{id}`
* **Méthode** : `PUT`

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PUT /scim/Groups/{team_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
        "displayName": "acme-devs",
        "members": [
            {
                "value": "{user_id_1}"
            },
            {
                "value": "{user_id_2}"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "displayName": "acme-devs",
        "id": "ghi",
        "members": [
            {
                "Value": "user_id_1",
                "Ref": "",
                "Type": "",
                "Display": "user1"
            },
            {
                "Value": "user_id_2",
                "Ref": "",
                "Type": "",
                "Display": "user2"
            }
        ],
        "meta": {
            "resourceType": "Group",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:01:00Z",
            "location": "Groups/ghi"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:Group"
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="add-a-user-to-a-team">
  Ajouter un utilisateur à une équipe
</h3>

Ajoute `dev-user2` à `acme-devs` :

<Note>Cette opération ne fonctionne que pour les utilisateurs, pas pour les comptes de service. Gérez les comptes de service dans les paramètres de l’équipe W\&B.</Note>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PATCH /scim/Groups/{team_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "add",
                "path": "members",
                "value": [
                    {
                        "value": "{user_id}"
                    }
                ]
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "displayName": "acme-devs",
        "id": "ghi",
        "members": [
            {
                "Value": "abc",
                "Ref": "",
                "Type": "",
                "Display": "dev-user1"
            },
            {
                "Value": "def",
                "Ref": "",
                "Type": "",
                "Display": "dev-user2"
            }
        ],
        "meta": {
            "resourceType": "Group",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:01:00Z",
            "location": "Groups/ghi"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:Group"
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="remove-a-specific-user-from-a-team">
  Retirer un utilisateur spécifique d’une équipe
</h3>

Retire `dev-user2` de `acme-devs` :

<Note>Cette opération s’applique uniquement aux utilisateurs, et non aux comptes de service. Gérez les comptes de service dans les paramètres de l’équipe W\&B.</Note>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PATCH /scim/Groups/{team_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "remove",
                "path": "members[value eq \"{user_id}\"]"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Statut 200)
    ```

    ```json theme={"system"}
    {
        "displayName": "acme-devs",
        "id": "ghi",
        "members": [
            {
                "Value": "abc",
                "Display": "dev-user1"
            }
        ],
        "meta": {
            "resourceType": "Group",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:01:00Z",
            "location": "Groups/ghi"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:Group"
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="remove-all-users-from-a-team">
  Supprimer tous les utilisateurs d’une équipe
</h3>

Supprime tous les utilisateurs de `acme-devs` :

<Note>Cette opération s’applique uniquement aux utilisateurs, et non aux comptes de service. Gérez les comptes de service dans les paramètres de l’équipe W\&B.</Note>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PATCH /scim/Groups/{team_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "remove",
                "path": "members"
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "displayName": "acme-devs",
        "id": "ghi",
        "members": null,
        "meta": {
            "resourceType": "Group",
            "created": "2023-10-01T00:00:00Z",
            "lastModified": "2023-10-01T00:01:00Z",
            "location": "Groups/ghi"
        },
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:Group"
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="delete-team">
  Supprimer une équipe
</h3>

L’API SCIM ne permet pas de supprimer des équipes, car d’autres données leur sont liées. Supprimez les équipes depuis la W\&B App, ce qui vous permet de confirmer que vous souhaitez bien tout supprimer.

<h2 id="role-resource">
  Ressource Role
</h2>

La ressource Role de SCIM correspond aux rôles personnalisés de W\&B. Utilisez les points de terminaison de cette section pour créer et gérer les rôles personnalisés par programmation (par exemple, pour que les définitions de rôles restent synchronisées avec vos politiques d’accès). Les points de terminaison `/Roles` ne font pas partie du schéma SCIM officiel. W\&B les ajoute afin de permettre la gestion automatisée des rôles personnalisés dans les organisations W\&B.

<h3 id="get-custom-role">
  Obtenir un rôle personnalisé
</h3>

Récupérez les informations d’un rôle personnalisé à partir de son ID unique.

<h4 id="endpoint-23">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Roles/{id}`
* **Méthode** : `GET`

<h4 id="example-22">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    GET /scim/Roles/abc
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
        "description": "A sample custom role for example",
        "id": "Um9sZTo3",
        "inheritedFrom": "member", // indique le rôle prédéfini
        "meta": {
            "resourceType": "Role",
            "created": "2023-11-20T23:10:14Z",
            "lastModified": "2023-11-20T23:31:23Z",
            "location": "Roles/Um9sZTo3"
        },
        "name": "Sample custom role",
        "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
        "permissions": [
            {
                "name": "artifact:read",
                "isInherited": true // héritée du rôle prédéfini member
            },
            ...
            ...
            {
                "name": "project:update",
                "isInherited": false // autorisation personnalisée ajoutée par un administrateur
            }
        ],
        "schemas": [
            ""
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="list-custom-roles">
  Lister les rôles personnalisés
</h3>

Récupère les informations de tous les rôles personnalisés de l’organisation W\&B.

<h4 id="endpoint-24">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Roles`
* **Méthode** : `GET`

<h4 id="example-23">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    GET /scim/Roles
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    ```json theme={"system"}
    {
       "Resources": [
            {
                "description": "A sample custom role for example",
                "id": "Um9sZTo3",
                "inheritedFrom": "member", // indique le rôle prédéfini dont hérite le rôle personnalisé
                "meta": {
                    "resourceType": "Role",
                    "created": "2023-11-20T23:10:14Z",
                    "lastModified": "2023-11-20T23:31:23Z",
                    "location": "Roles/Um9sZTo3"
                },
                "name": "Sample custom role",
                "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
                "permissions": [
                    {
                        "name": "artifact:read",
                        "isInherited": true // héritée du rôle prédéfini member
                    },
                    ...
                    ...
                    {
                        "name": "project:update",
                        "isInherited": false // permission personnalisée ajoutée par l’administrateur
                    }
                ],
                "schemas": [
                    ""
                ]
            },
            {
                "description": "Another sample custom role for example",
                "id": "Um9sZToxMg==",
                "inheritedFrom": "viewer", // indique le rôle prédéfini dont hérite le rôle personnalisé
                "meta": {
                    "resourceType": "Role",
                    "created": "2023-11-21T01:07:50Z",
                    "location": "Roles/Um9sZToxMg=="
                },
                "name": "Sample custom role 2",
                "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
                "permissions": [
                    {
                        "name": "launchagent:read",
                        "isInherited": true // héritée du rôle prédéfini viewer
                    },
                    ...
                    ...
                    {
                        "name": "run:stop",
                        "isInherited": false // permission personnalisée ajoutée par l’administrateur
                    }
                ],
                "schemas": [
                    ""
                ]
            }
        ],
        "itemsPerPage": 9999,
        "schemas": [
            "urn:ietf:params:scim:api:messages:2.0:ListResponse"
        ],
        "startIndex": 1,
        "totalResults": 2
    }
    ```
  </Tab>
</Tabs>

<h3 id="create-custom-role">
  Créer un rôle personnalisé
</h3>

Crée un nouveau rôle personnalisé dans l’organisation W\&B.

<h4 id="endpoint-25">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Roles`
* **Méthode** : `POST`

<h4 id="supported-fields-2">
  Champs pris en charge
</h4>

| Champ | Type | Requis |
| - | - | - |
| `name` | String | Nom du rôle personnalisé |
| `description` | String | Description du rôle personnalisé |
| `permissions` | Tableau d’objets | Tableau d’objets d’autorisation, chacun comprenant un champ `name` de type string dont la valeur a la forme `w&bobject:operation`. Par exemple, un objet d’autorisation pour l’opération de suppression sur les runs W\&B aurait pour valeur de `name` `run:delete`. |
| `inheritedFrom` | String | Le rôle prédéfini dont hérite le rôle personnalisé. Il peut s’agir de `member` ou de `viewer`. |

<h4 id="example-24">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    POST /scim/Roles
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Role"],
        "name": "Sample custom role",
        "description": "A sample custom role for example",
        "permissions": [
            {
                "name": "project:update"
            }
        ],
        "inheritedFrom": "member"
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 201)
    ```

    ```json theme={"system"}
    {
        "description": "A sample custom role for example",
        "id": "Um9sZTo3",
        "inheritedFrom": "member", // indique le rôle prédéfini
        "meta": {
            "resourceType": "Role",
            "created": "2023-11-20T23:10:14Z",
            "lastModified": "2023-11-20T23:31:23Z",
            "location": "Roles/Um9sZTo3"
        },
        "name": "Sample custom role",
        "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
        "permissions": [
            {
                "name": "artifact:read",
                "isInherited": true // héritée du rôle prédéfini member
            },
            ...
            ...
            {
                "name": "project:update",
                "isInherited": false // permission personnalisée ajoutée par un administrateur
            }
        ],
        "schemas": [
            ""
        ]
    }
    ```
  </Tab>
</Tabs>

<h3 id="update-custom-role">
  Mettre à jour un rôle personnalisé
</h3>

Les sections suivantes expliquent comment ajouter des autorisations à un rôle personnalisé existant ou lui en retirer.

<h4 id="add-permissions-to-role">
  Ajouter des autorisations à un rôle
</h4>

Ajoute des autorisations à un rôle personnalisé existant.

<h5 id="endpoint-26">
  Point de terminaison
</h5>

* **URL** : `[HOST-URL]/scim/Roles/{id}`
* **Méthode** : `PATCH`

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PATCH /scim/Roles/{role_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "add",
                "path": "permissions",
                "value": [
                    {
                        "name": "project:delete"
                    },
                    {
                        "name": "run:stop"
                    }
                ]
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    Renvoie le rôle mis à jour, avec les nouvelles autorisations ajoutées.
  </Tab>
</Tabs>

<h4 id="remove-a-permission-from-a-role">
  Retirer une autorisation d’un rôle
</h4>

Retire des autorisations d’un rôle personnalisé existant.

<h5 id="endpoint-27">
  Point de terminaison
</h5>

* **URL** : `[HOST-URL]/scim/Roles/{id}`
* **Méthode** : `PATCH`

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PATCH /scim/Roles/{role_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations": [
            {
                "op": "remove",
                "path": "permissions",
                "value": [
                    {
                        "name": "project:update"
                    }
                ]
            }
        ]
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    Renvoie le rôle mis à jour, sans les autorisations spécifiées.
  </Tab>
</Tabs>

<h3 id="replace-custom-role">
  Remplacer un rôle personnalisé
</h3>

Remplace l’intégralité de la définition d’un rôle personnalisé.

<h4 id="endpoint-28">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Roles/{id}`
* **Méthode** : `PUT`

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    PUT /scim/Roles/{role_id}
    ```

    ```json theme={"system"}
    {
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Role"],
        "name": "Updated custom role",
        "description": "Updated description for the custom role",
        "permissions": [
            {
                "name": "project:read"
            },
            {
                "name": "run:read"
            },
            {
                "name": "artifact:read"
            }
        ],
        "inheritedFrom": "viewer"
    }
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 200)
    ```

    Renvoie la définition de rôle remplacée.
  </Tab>
</Tabs>

<h3 id="delete-custom-role">
  Supprimer un rôle personnalisé
</h3>

Supprimez un rôle personnalisé de l’organisation W\&B. **Utilisez cette opération avec prudence**. Le rôle prédéfini dont héritait le rôle personnalisé est réattribué à tous les utilisateurs qui disposaient de ce rôle personnalisé avant sa suppression.

<h4 id="endpoint-29">
  Point de terminaison
</h4>

* **URL** : `[HOST-URL]/scim/Roles/{id}`
* **Méthode** : `DELETE`

<h4 id="example-25">
  Exemple
</h4>

<Tabs>
  <Tab title="Requête">
    ```bash theme={"system"}
    DELETE /scim/Roles/abc
    ```
  </Tab>

  <Tab title="Réponse">
    ```text theme={"system"}
    (Status 204 No Content)
    ```
  </Tab>
</Tabs>

<h2 id="advanced-features">
  Fonctionnalités avancées
</h2>

Les sections suivantes décrivent des fonctionnalités facultatives (contrôle de concurrence basé sur les ETag et réponses d’erreur standard) qui permettent aux intégrations SCIM de fonctionner en toute sécurité en production.

<h3 id="etag-support">
  Prise en charge des ETags
</h3>

L’API SCIM prend en charge les ETags pour les mises à jour conditionnelles, afin d’éviter les conflits liés aux modifications simultanées. C’est essentiel lorsque plusieurs administrateurs ou systèmes automatisés modifient la même ressource, car cela garantit qu’une mise à jour n’en écrase pas silencieusement une autre. Les ETags sont renvoyés dans l’en-tête de réponse `ETag` et dans le champ `meta.version`.

<h4 id="etags">
  ETags
</h4>

Pour utiliser les ETags, suivez ces étapes :

1. **Obtenir l’ETag actuel** : lorsque vous effectuez une requête GET sur une ressource, relevez l’en-tête ETag dans la réponse.
2. **Mise à jour conditionnelle** : incluez l’ETag dans l’en-tête `If-Match` lorsque vous mettez à jour la ressource.

<h4 id="example-26">
  Exemple
</h4>

```text theme={"system"}
# Obtenir l’utilisateur et noter l’ETag
GET /scim/Users/abc
# La réponse contient : ETag: W/"xyz123"

# Mettre à jour avec l’ETag
PATCH /scim/Users/abc
If-Match: W/"xyz123"

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin"
        }
    ]
}
```

Une réponse d’erreur `412 Precondition Failed` indique que la ressource a été modifiée depuis que vous l’avez récupérée.

<h3 id="error-handling">
  Gestion des erreurs
</h3>

L’API SCIM renvoie des réponses d’erreur SCIM standard :

| Code de statut | Description |
| - | - |
| `200` | Succès |
| `201` | Créé |
| `204` | Aucun contenu (suppression réussie) |
| `400` | Requête incorrecte : paramètres ou corps de requête non valides |
| `401` | Non autorisé : échec de l’authentification |
| `403` | Interdit : autorisations insuffisantes |
| `404` | Introuvable : la ressource n’existe pas |
| `409` | Conflit : la ressource existe déjà |
| `412` | Échec de la condition préalable : l’ETag ne correspond pas |
| `500` | Erreur interne du serveur |

<h2 id="implementation-differences-per-deployment-type">
  Différences d’implémentation selon le type de déploiement
</h2>

W\&B maintient deux implémentations distinctes de l’API SCIM, dont les fonctionnalités diffèrent. Avant d’intégrer SCIM, consultez le tableau suivant pour vérifier que les opérations sur lesquelles vous vous appuyez sont disponibles pour votre type de déploiement.

| Fonctionnalité | Cloud mutualisé | Cloud dédié et autogéré |
| - | - | - |
| Mettre à jour l’adresse e-mail de l’utilisateur | - | ✓ |
| Mettre à jour le nom d’affichage de l’utilisateur | - | ✓ |
| Désactivation de l’utilisateur | ✓ | ✓ |
| Réactivation de l’utilisateur | - | ✓ |
| Plusieurs adresses e-mail par utilisateur | ✓ | - |
| Définir `modelsSeat` lors de la création ou de la mise à jour | ✓ | ✓ |
| Définir `weaveRole` lors de la création ou de la mise à jour | ✓ | ✓ |
| Définir `registryAccess` lors de la création ou de la mise à jour | ✓ | ✓ |
| Révoquer l’accès au registre avec `modelsSeat: none` | - | ✓ |
| Révoquer l’accès au registre avec `registryAccess: none` | ✓ | ✓ |

<h2 id="limitations">
  Limitations
</h2>

Tenez compte des contraintes suivantes lorsque vous concevez des intégrations SCIM :

* **Nombre maximum de résultats** : 9 999 éléments par requête.
* **Cloud dédié et autogéré** : une seule adresse e-mail par utilisateur est prise en charge.
* **Suppression d’équipe** : non prise en charge via SCIM (utilisez l’interface web de W\&B).
* **Réactivation d’utilisateur** : non prise en charge dans les environnements Cloud mutualisé.
* **Limites de licences** : les opérations peuvent échouer si l’organisation a atteint sa limite de licences.
