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

# Guide de mise en place du SSO

> Guide complet pour configurer le SSO, comprendre les points à prendre en compte concernant SCIM et configurer les groupes de l'IdP avec Devin Enterprise.

Ce guide accompagne les administrateurs d’entreprise tout au long du cycle de vie du SSO avec Devin — de la mise en place initiale à la configuration des groupes de l'IdP — et explique comment Devin gère le provisionnement des utilisateurs sans SCIM.

Pour les instructions de configuration propres à chaque fournisseur, consultez [Okta](/fr/enterprise/security-access/sso/okta), [Microsoft Entra ID](/fr/enterprise/security-access/sso/azure), [SAML](/fr/enterprise/security-access/sso/saml) ou [OIDC générique](/fr/enterprise/security-access/sso/oidc).

***

<div id="1-setting-up-sso">
  ## 1. Configurer le SSO (authentification unique)
</div>

<div id="creating-your-sso-application">
  ### Création de votre application SSO
</div>

Créez une application dans votre fournisseur d’identité (Okta, Microsoft Entra ID ou tout IdP compatible SAML/OIDC) et partagez les identifiants suivants avec votre équipe Cognition :

| Type de connexion      | Protocole                      | Éléments à fournir                                      |
| :--------------------- | :----------------------------- | :------------------------------------------------------ |
| **Okta**               | OIDC (Okta Workforce Identity) | Domaine Okta, ID client, secret client, périmètres      |
| **Microsoft Entra ID** | OIDC (Microsoft Entra ID)      | Domaine Microsoft Entra ID, ID client, secret client    |
| **SAML**               | SAML 2.0 (tout IdP)            | URL de connexion, certificat de signature X.509         |
| **OIDC générique**     | OIDC                           | URL de découverte, ID client, secret client, périmètres |

<Note>
  Vous devez également fournir votre ou vos domaines de messagerie vérifiés afin que Devin sache quelles adresses e-mail considérer comme fiables lorsqu’elles proviennent de votre IdP.
</Note>

<div id="what-happens-after-setup">
  ### Ce qui se passe après la configuration
</div>

Une fois que votre équipe Cognition a les identifiants, elle configure la connexion SSO. Une fois la configuration terminée :

1. La connexion SSO est associée à votre entreprise Devin
2. **Ajout automatique à l’entreprise lors de la connexion** est activé — tout utilisateur qui s’authentifie via le SSO est automatiquement ajouté à votre entreprise
3. Votre ou vos domaines de messagerie sont enregistrés comme domaines de confiance — seules les adresses e-mail provenant de ces domaines sont acceptées
4. **Attribution des rôles basée sur les groupes (RBAC)** est activée — les groupes IdP transmis lors de la connexion peuvent être associés à des rôles Devin
5. Les connexions sociales par défaut (Google, GitHub) sont désactivées — le SSO devient la méthode d’authentification obligatoire

<div id="the-user-login-experience">
  ### L’expérience de connexion utilisateur
</div>

1. L’utilisateur accède à votre URL Devin
2. Il est redirigé vers l’IdP configuré (Okta, Microsoft Entra ID, etc.)
3. L’utilisateur s’authentifie normalement
4. L’IdP renvoie à Devin les informations de l’utilisateur et ses appartenances à des groupes
5. Devin effectue automatiquement les actions suivantes :
   * Crée le compte de l’utilisateur s’il s’agit de sa première connexion (provisionnement juste-à-temps)
   * Lui attribue le rôle Enterprise Member par défaut
   * Synchronise ses appartenances aux groupes IdP — ajoute les nouveaux groupes et supprime les groupes obsolètes
   * Enregistre la connexion dans le journal d’audit de l’entreprise

***

<div id="self-service-administration">
  ## Administration en libre-service
</div>

Les éléments suivants sont accessibles directement aux administrateurs Enterprise dans l’application web Devin.

<div id="idp-group-management">
  ### Gestion des groupes du fournisseur d’identité
</div>

**Settings → Enterprise → Groupes du fournisseur d’identité**

* Voir tous les groupes synchronisés lors des connexions des utilisateurs
* Attribuer un groupe à un rôle au niveau de l’Enterprise (p. ex., « Tous les membres de `Engineering-Admins` obtiennent le rôle Enterprise Admin »)
* Attribuer un groupe à des orgs spécifiques avec des rôles spécifiques (p. ex., « `Team-Backend` obtient l’accès Member dans l’org Backend »)
* Ajouter ou supprimer en masse des groupes dans plusieurs orgs
* Voir à combien d’orgs chaque groupe est attribué

<div id="member-management">
  ### Gestion des membres
</div>

**Settings → Enterprise → Membres**

* Afficher tous les membres Enterprise, y compris leurs appartenances aux groupes IdP
* Inviter de nouveaux membres par e-mail
* Mettre à jour les rôles des membres
* Supprimer des membres

<div id="custom-roles">
  ### Rôles personnalisés
</div>

**Settings → Enterprise → Rôles**

* Créez des rôles personnalisés avec des autorisations granulaires
* Attribuez des rôles personnalisés à des utilisateurs ou à des groupes IdP

Consultez [Rôles personnalisés et RBAC](/fr/enterprise/security-access/custom-roles) pour en savoir plus.

<div id="api-for-automation">
  ### API d’automatisation
</div>

Devin fournit une API v2 que vous pouvez utiliser pour automatiser la gestion des membres :

| Action                                         | endpoint API                                 |
| :--------------------------------------------- | :------------------------------------------- |
| Lister tous les membres                        | `GET /v2/enterprise/members`                 |
| Inviter des utilisateurs par e-mail (en masse) | `POST /v2/enterprise/members/invite`         |
| Supprimer un membre                            | `DELETE /v2/enterprise/members/{user_id}`    |
| Mettre à jour en masse les rôles des membres   | `PATCH /v2/enterprise/members/roles`         |
| Migrer des membres d’un rôle à un autre        | `PATCH /v2/enterprise/members/migrate-roles` |
| Lister tous les rôles                          | `GET /v2/enterprise/roles`                   |
| Lister tous les groupes IdP                    | `GET /v2/enterprise/groups`                  |
| Créer à l’avance des groupes IdP               | `PUT /v2/enterprise/groups`                  |
| Récupérer les affectations d’org d’un groupe   | `GET /v2/enterprise/groups/{group_name}`     |

***

<div id="2-understanding-devin-without-scim">
  ## 2. Comprendre Devin sans SCIM
</div>

À ce jour, Devin ne prend pas en charge le protocole SCIM. Toute la gestion des utilisateurs et des groupes s’effectue via les événements de connexion SSO et l’interface utilisateur/API de Devin. Voici ce que cela signifie concrètement.

<div id="user-provisioning-login-triggered-only">
  ### Provisionnement des utilisateurs : déclenché uniquement lors de la connexion
</div>

|                                         | Avec SCIM                                                                                             | Devin (sans SCIM)                                                                                                                            |
| :-------------------------------------- | :---------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- |
| **Comment les utilisateurs sont créés** | L'IdP crée immédiatement l'utilisateur dans l'application dès qu'il lui est attribué                  | L'utilisateur n'existe dans Devin qu'après sa première connexion SSO — ou après une invitation manuelle via l'interface utilisateur ou l'API |
| **Quand cela se produit**               | L'administrateur attribue l'application à l'utilisateur → l'utilisateur apparaît en quelques secondes | L'administrateur attribue l'application à l'utilisateur → rien ne se passe dans Devin tant qu'il ne se connecte pas                          |
| **Préprovisionnement**                  | Le compte utilisateur est prêt avant même que l'utilisateur n'accède à l'application                  | Aucun préprovisionnement, sauf si l'administrateur l'invite explicitement via l'interface utilisateur de Devin ou l'API                      |

Lors de l'arrivée de nouveaux employés, l'administrateur peut soit les inviter à l'avance (**Settings → Enterprise → Membres → Inviter**, ou via l'API), soit simplement les laisser être provisionnés automatiquement lors de leur première connexion.

<div id="user-deprovisioning-manual-only">
  ### Déprovisionnement des utilisateurs : manuel uniquement
</div>

|                                          | Avec SCIM                                                                                    | Devin (sans SCIM)                                                                                                       |
| :--------------------------------------- | :------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- |
| **Mode de suppression des utilisateurs** | L’IdP désactive/supprime l’utilisateur → l’application désactive immédiatement l’utilisateur | Désactiver/supprimer un utilisateur dans l’IdP n’a aucun effet dans Devin                                               |
| **Départ**                               | L’employé quittant l’entreprise perd l’accès en quelques minutes                             | L’employé quittant l’entreprise conserve l’accès jusqu’à sa suppression manuelle de Devin et l’expiration de sa session |
| **Conformité**                           | Conformité automatisée — aucun compte orphelin                                               | Risque de comptes orphelins, sauf si l’administrateur gère les deux systèmes                                            |

<Warning>
  Il s’agit de la principale lacune opérationnelle. Lors du départ d’un employé, l’administrateur doit également le supprimer de Devin (**Settings → Enterprise → Members → Remove**, ou via l’API). Les sessions actives continuent de fonctionner jusqu’à leur expiration naturelle — aucune révocation instantanée de session n’est déclenchée par l’IdP.
</Warning>

<div id="group-sync-login-time-only-not-real-time">
  ### Synchronisation des groupes : à la connexion uniquement, pas en temps réel
</div>

|                                  | Avec SCIM (Group Push)                                                                   | Devin (sans SCIM)                                                                                                                  |
| :------------------------------- | :--------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- |
| **Moment de la synchronisation** | L'IdP répercute en temps réel les modifications d'appartenance aux groupes               | Les groupes se synchronisent uniquement lorsque l'utilisateur se connecte                                                          |
| **Ajout à un groupe**            | L'administrateur ajoute l'utilisateur au groupe → l'application le reflète immédiatement | L'administrateur ajoute l'utilisateur au groupe → Devin ne le prend en compte qu'à la prochaine connexion de l'utilisateur         |
| **Retrait d'un groupe**          | L'administrateur retire l'utilisateur du groupe → l'application le reflète immédiatement | L'administrateur retire l'utilisateur du groupe → Devin continue d'afficher l'ancienne appartenance jusqu'à la prochaine connexion |
| **Source de référence**          | L'IdP est toujours la source de référence                                                | L'IdP n'est la source de référence qu'au moment de la connexion — des écarts peuvent apparaître entre deux connexions              |

Si un administrateur modifie le groupe IdP d'une personne (p. ex. en la faisant passer d'Engineering à Sales), Devin ne reflétera pas ce changement tant que l'utilisateur ne se sera pas reconnecté. En attendant, l'utilisateur conserve ses anciens rôles basés sur les groupes ainsi que son accès à l'organisation.

<div id="built-in-alternatives-to-scim">
  ### Alternatives natives à SCIM
</div>

Devin inclut plusieurs fonctionnalités qui couvrent les cas d’usage SCIM courants :

1. **Provisionnement juste-à-temps** — les utilisateurs sont créés automatiquement lors de leur première connexion SSO avec le rôle d’entreprise par défaut
2. **Synchronisation complète des groupes à chaque connexion** — chaque fois qu’un utilisateur se connecte, Devin effectue un diff complet de ses groupes IdP : il ajoute les nouveaux et supprime les anciens
3. **RBAC basé sur les groupes** — vous pouvez associer des groupes IdP à des rôles d’entreprise et à l’accès aux organisations dans les Settings de Devin, avec prise d’effet lors de la prochaine connexion
4. **API V2 pour l’automatisation** — les invitations, suppressions et modifications de rôle en masse peuvent être scriptées pour combler les lacunes de provisionnement et de déprovisionnement
5. **Journaux d’audit** — chaque connexion est enregistrée, ce qui permet de savoir qui a accédé à Devin

***

<div id="3-configuring-idp-managed-groups">
  ## 3. Configuration des groupes gérés par l’IdP
</div>

Si vous utilisez SCIM avec d’autres applications (p. ex., Slack, Box), cette section explique le fonctionnement du modèle de groupes de Devin et comment configurer correctement votre IdP.

<div id="context-scim-groups-vs-idp-groups">
  ### Contexte : groupes SCIM vs groupes IdP
</div>

* **Groupes SCIM :** L’application cible indique à l’IdP quels groupes existent (l’IdP les « importe »). L’application est la source de référence pour la structure des groupes. L’IdP synchronise les utilisateurs dans ces groupes définis par l’application.
* **Groupes IdP (ce qu’utilise Devin) :** L’IdP est la source de référence. Les groupes sont définis dans l’annuaire de l’IdP, et les appartenances aux groupes sont transmises à Devin via des assertions SAML/OIDC au moment de la connexion.

Comme Devin n’utilise pas SCIM, vous fonctionnez déjà en mode « groupes IdP ». L’essentiel est de s’assurer que les bons groupes sont envoyés par votre IdP et correctement mappés dans Devin.

<div id="step-1-define-groups-in-the-idp">
  ### Étape 1 : Définir les groupes dans l’IdP
</div>

Dans la console d’administration de votre IdP (les exemples ci-dessous utilisent Okta) :

1. Accédez à **Directory → Groups**
2. Créez des groupes correspondant aux niveaux d’accès à Devin (p. ex., `Devin-Engineering`, `Devin-Admins`, `Devin-DataScience`)
3. Assignez les utilisateurs à ces groupes

Il s’agit de groupes natifs de l’IdP : votre IdP est la source de référence quant à l’appartenance de chacun.

<div id="step-2-configure-group-claims-in-the-idp-app">
  ### Étape 2 : Configurer les attributs de groupe dans l’application IdP
</div>

Les groupes doivent être inclus dans la réponse d’authentification afin que Devin puisse les lire.

<div id="for-saml-connections">
  #### Pour les connexions SAML
</div>

1. Accédez à **Applications → \[application Devin] → SAML Settings → Modifier**
2. Sous **Déclarations d’attribut de groupe**, ajoutez :
   * **Nom :** `groups`
   * **Filtre :** « Commence par » → `Devin-` (ou utilisez « Correspond à l’expression régulière » pour des motifs plus complexes)
3. Cela indique à l’IdP d’inclure les noms des groupes correspondants dans l’assertion SAML

<div id="for-oidc-connections">
  #### Pour les connexions OIDC
</div>

1. Accédez à **Applications → \[application Devin] → Connexion → Modifier**
2. Sous **OpenID Connect ID Token → Type de revendication de groupes**, sélectionnez "Filtre"
3. Réglez le filtre pour qu'il corresponde aux groupes Devin (p. ex., "Commence par" → `Devin-`)

<Tip>
  Utilisez un préfixe de filtre comme `Devin-` afin que seuls les groupes pertinents soient envoyés. Il n'est pas nécessaire d'envoyer tous les groupes de l'IdP de l'organisation.
</Tip>

<div id="step-3-map-groups-to-roles-and-orgs-in-devin">
  ### Étape 3 : Associer les groupes aux rôles et aux organisations dans Devin
</div>

Une fois les groupes transmis lors de la connexion, associez-les dans Devin.

<div id="in-the-devin-ui">
  #### Dans l’interface Devin
</div>

1. **Settings → Enterprise → Groupes du fournisseur d’identité**
2. Les groupes apparaissent automatiquement dès qu’un membre du groupe se connecte
3. Cliquez sur un groupe → attribuez-lui un rôle à l’échelle de l’entreprise (p. ex. Enterprise Admin ou un rôle personnalisé)
4. Cliquez sur un groupe → affectez-le à des orgs spécifiques avec des rôles spécifiques au niveau de l’org

<div id="via-the-api-for-pre-setup-or-automation">
  #### Par l’API (pour la pré-configuration ou l’automatisation)
</div>

* Créez les groupes à l’avance avant toute connexion : `PUT /v2/enterprise/groups`
* Listez les groupes et les organisations auxquelles ils sont attribués : `GET /v2/enterprise/groups`

<div id="step-4-if-migrating-from-scim-groups-in-other-apps">
  ### Étape 4 : si vous migrez depuis des groupes SCIM dans d'autres applications
</div>

Si vous faites évoluer votre stratégie IdP globale en passant de groupes gérés par SCIM à des groupes gérés par l'IdP dans l'ensemble de vos outils (pas seulement Devin) :

1. **Arrêtez l'importation des groupes SCIM** dans les autres applications :
   * Dans l'IdP : accédez à l'onglet **Provisioning → Integration** → décochez "Import Groups"
   * Cela empêche l'application cible d'être la source de référence pour les groupes
2. **Créez des groupes correspondants** dans l'annuaire de l'IdP :
   * Accédez à **Directory → Groups** et créez des groupes qui correspondent à ceux qui existaient dans l'application cible
   * Attribuez les utilisateurs à ces groupes natifs de l'IdP
3. **Configurez Group Push** (pour les applications qui le prennent en charge) :
   * Dans la configuration IdP de l'application : onglet **Push Groups** → recherchez les groupes par nom → liez-les aux groupes cibles existants
   * Cela amène l'IdP à remplacer l'appartenance interne de l'application — l'IdP devient l'unique source de référence
   * Devin n'a pas besoin de Group Push, car il lit directement les groupes à partir de l'assertion d'authentification
4. **Désactivez la synchronisation des groupes SCIM** dans les autres applications :
   * Assurez-vous que "Import Groups" reste désactivé pour empêcher l'application cible de redevenir la source de référence

Pour Devin en particulier, aucune migration n'est nécessaire. Assurez-vous simplement que les étapes 1 à 3 ci-dessus sont effectuées (groupes définis dans votre IdP, claims configurés, mappages définis dans Devin).

***

<div id="key-considerations">
  ## Points clés à retenir
</div>

<AccordionGroup>
  <Accordion title="Renommage des groupes dans l'IdP">
    Si un groupe est renommé, Devin le considère comme un nouveau groupe. Les mappages de rôles de l'ancien groupe ne sont pas transférés automatiquement — vous devrez reconfigurer le nouveau nom de groupe dans les Settings de Devin.
  </Accordion>

  <Accordion title="L'ajout à un groupe ne donne pas un accès immédiat à Devin">
    Un utilisateur ajouté à un groupe IdP mappé à Devin n'obtiendra cet accès qu'après s'être connecté.
  </Accordion>

  <Accordion title="Le retrait d'un groupe n'entraîne pas la suppression immédiate de l'accès à Devin">
    Retirer un utilisateur d'un groupe IdP ne révoque pas immédiatement son accès à Devin. Lors de sa prochaine connexion, Devin synchronise et supprime l'appartenance à l'ancien groupe devenue obsolète. Toute appartenance directe (attribuée en dehors des groupes) n'est pas affectée.
  </Accordion>

  <Accordion title="Les noms de groupes doivent correspondre exactement">
    Le nom du groupe dans l'IdP doit correspondre exactement à ce que Devin voit. La casse est prise en compte.
  </Accordion>

  <Accordion title="Pas de groupes imbriqués">
    Devin ne prend pas en charge les groupes imbriqués/hiérarchiques. Si l'IdP envoie un groupe parent, les membres des groupes enfants ne sont pas inclus automatiquement. Chaque groupe doit être attribué explicitement.
  </Accordion>
</AccordionGroup>

***

<div id="recommended-setup-for-scim-like-behavior">
  ## Configuration recommandée pour un comportement « de type SCIM »
</div>

Pour un contrôle aussi strict que possible sans SCIM, suivez cette approche :

<Steps>
  <Step title="Configurez votre fournisseur d'identité (source de référence)">
    1. Définissez des groupes : `Devin-Admins`, `Devin-Backend`, `Devin-Frontend`, etc.
    2. Assignez les utilisateurs à des groupes
    3. Configurez les attributs de groupe SAML/OIDC avec un filtre « Commence par : `Devin-` »
  </Step>

  <Step title="Devin se synchronise à chaque connexion">
    Lorsqu'un utilisateur se connecte via SSO, Devin :

    * Crée automatiquement l'utilisateur s'il est nouveau
    * Effectue une synchronisation complète des groupes (ajoute les nouveaux groupes et supprime les groupes obsolètes)
    * Applique immédiatement les correspondances groupe-rôle et groupe-org
  </Step>

  <Step title="Facultatif : automatisez avec l'API V2">
    Configurez une tâche planifiée pour combler les lacunes de SCIM :

    1. Récupérez les utilisateurs actifs depuis l'API de votre IdP
    2. Récupérez les membres de Devin via `GET /v2/enterprise/members`
    3. Invitez les nouveaux employés via `POST /v2/enterprise/members/invite`
    4. Supprimez les employés ayant quitté l'entreprise via `DELETE /v2/enterprise/members/{user_id}`

    Vous obtenez ainsi un provisionnement et un déprovisionnement de type push sans SCIM.
  </Step>
</Steps>

<div id="what-this-gives-you">
  ### Ce que cela vous apporte
</div>

* Votre IdP comme source unique de référence pour la structure des groupes et l’appartenance
* Accès automatique basé sur les groupes à chaque connexion
* Provisionnement/déprovisionnement via API pour couvrir ce que SCIM prend normalement en charge
* Journal d’audit complet pour toutes les connexions et les changements d’appartenance

<div id="current-limitations">
  ### Limites actuelles
</div>

* **Synchronisation des groupes en temps réel d’une connexion à l’autre** — les groupes ne sont mis à jour que lorsque les utilisateurs se connectent
* **Révocation instantanée des sessions en cas de déprovisionnement** — les sessions restent actives jusqu’à expiration
* Les **événements de cycle de vie déclenchés par l’IdP**, comme la suspension ou la réactivation, ne sont pas pris en charge