> ## 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.

# Profils de sécurité

> Définissez des profils de sécurité Devin réutilisables qui restreignent les accès réseau, MCP, git et GitHub CLI, et associez-les aux organisations, automatisations et sessions.

Les profils de sécurité vous permettent de définir des ensembles réutilisables de restrictions de sécurité — accès réseau, accès MCP, accès git et identifiants GitHub CLI — et de les appliquer aux sessions Devin dans toute votre organisation. Au lieu de configurer ces restrictions session par session, les administrateurs créent des profils nommés une seule fois et les associent au niveau le plus pertinent : comme valeur par défaut à l’échelle de l’organisation, sur une automatisation spécifique ou sur une session individuelle. Les environnements Enterprise peuvent également partager des profils entre toutes les organisations et les imposer comme seuil minimal strict que personne à un niveau inférieur ne peut assouplir.

<div id="restrictions-in-a-profile">
  ## Restrictions d’un profil
</div>

Un profil est un ensemble nommé de restrictions. Chaque restriction est facultative — un profil n’impose de restrictions qu’aux paramètres qu’il configure.

<div id="network-policy">
  ### Politique réseau
</div>

Une politique réseau est une liste d’autorisation des destinations que la machine de la session est autorisée à joindre. Toutes les autres connexions sortantes sont bloquées. Les entrées de la liste d’autorisation peuvent être :

* **Noms d’hôte**, avec des caractères génériques `*` (par ex. `*.github.com`, `registry.npmjs.org`). Un `*` correspond à n’importe quelle suite de caractères, y compris les points.
* **Plages CIDR IPv4 / IPv6** (par ex. `10.0.0.0/8`).

La restriction s’applique à tous les accès réseau depuis la session — commandes shell, navigation, installations de packages et scripts. Devin détecte lorsqu’il s’exécute sous une politique réseau restrictive : il peut voir la liste d’autorisation actuelle et, lorsqu’il est bloqué parce qu’une destination manque, il demandera l’accès. L’approbation de la demande ajoute la destination pour cette session (sous réserve de toute application obligatoire — voir [application](#mandatory-vs-recommended-enforcement)).

Les destinations nécessaires au fonctionnement de Devin (comme le proxy git utilisé pour accéder à vos dépôts connectés) sont autorisées automatiquement.

<div id="mcp-access">
  ### Accès MCP
</div>

Par défaut, les sessions peuvent utiliser n’importe quel [serveur MCP](/fr/work-with-devin/mcp) installé dans votre organisation. Un profil peut restreindre cela avec **une liste d’autorisation de serveurs MCP** — les sessions soumises au profil ne peuvent utiliser que les serveurs listés.

<Note>
  L’accès MCP est géré indépendamment de la politique réseau : vous **n’avez pas** besoin d’ajouter l’adresse d’un serveur MCP à la liste d’autorisation réseau. Les serveurs autorisés par le profil sont automatiquement accessibles, et les serveurs exclus par le profil restent inutilisables quelle que soit la politique réseau.
</Note>

<div id="devin-mcp-access">
  ### Accès à Devin MCP
</div>

Les sessions ont également accès aux propres outils de gestion de Devin via le Devin MCP intégré — création de sessions enfants et envoi de messages, modification de Knowledge et des playbooks, gestion des planifications, etc. Un profil peut restreindre ce périmètre avec **Devin MCP en lecture seule** : les sessions régies par ce profil peuvent toujours consulter les ressources de Devin (lister les sessions, consulter Knowledge, examiner les playbooks), mais ne peuvent pas effectuer d’opérations d’écriture comme créer des sessions ou modifier Knowledge.

<div id="git-access-level">
  ### Niveau d’accès Git
</div>

Définit ce que la session peut faire avec vos dépôts connectés :

| Niveau            | Ce que Devin peut faire                                                      |
| ----------------- | ---------------------------------------------------------------------------- |
| **Lecture seule** | Cloner et récupérer des dépôts, mais pas envoyer de branches ni ouvrir de PR |
| **Complet**       | Cloner, récupérer, envoyer et ouvrir des PR normalement                      |

<div id="github-cli-token">
  ### Jeton GitHub CLI
</div>

Au-delà des opérations git de base autorisées par le niveau d’accès git, la machine de Devin peut disposer d’un jeton GitHub CLI (`gh`) qui permet à Devin d’utiliser directement les fonctionnalités de GitHub via l’API GitHub. Un profil peut **supprimer le jeton GitHub CLI** de la machine : les sessions régies par ce profil continuent d’utiliser vos dépôts via l’intégration git de Devin, mais ne peuvent pas effectuer d’appels directs à l’API GitHub.

Un profil ne peut conserver le jeton que s’il accorde également un accès git **complet** et, s’il définit une politique réseau, autorise `api.github.com`. Ces deux conditions sont vérifiées lors de l’enregistrement du profil.

<div id="where-profiles-live">
  ## Où se trouvent les profils
</div>

Les profils existent à deux périmètres :

* Les **profils d’organisation** sont créés dans **Settings → Customization → profils de sécurité** et ne peuvent être utilisés qu’au sein de cette organisation.
* Les **profils Enterprise** (comptes Enterprise uniquement) sont créés dans **Enterprise settings → Devin → profils de sécurité** et peuvent être utilisés par toutes les organisations de l’Enterprise. Les organisations peuvent sélectionner un profil Enterprise pour leurs sessions, leurs automatisations ou leur configuration par défaut d’organisation, mais seuls les administrateurs Enterprise peuvent modifier le profil lui-même.

Les noms de profil doivent être uniques dans leur périmètre. Chaque profil comporte également un [niveau d’application](#mandatory-vs-recommended-enforcement) qui détermine si les niveaux inférieurs peuvent y déroger.

<div id="what-you-can-bind-a-profile-to">
  ## Ce à quoi vous pouvez associer un profil
</div>

Un profil prend effet lorsqu’il est *associé* à une ressource. Les associations forment une hiérarchie, du niveau le plus large au plus spécifique :

1. **Par défaut pour l’Enterprise** — s’applique aux nouvelles sessions dans chaque organisation de l’Enterprise.
2. **Par défaut pour l’organisation** — s’applique aux nouvelles sessions de cette organisation.
3. **Par défaut pour les automatisations** — s’applique aux sessions démarrées par les [automatisations](/fr/product-guides/automations) de cette organisation, en remplaçant la valeur par défaut de l’organisation pour ces sessions. Défini depuis la même page des Settings des profils de sécurité.
4. **Automatisation** — s’applique aux sessions démarrées par cette automatisation spécifique, en remplaçant la valeur par défaut des automatisations. Défini depuis l’Editor de l’automatisation.
5. **Session** — choisi pour une session individuelle lors de sa création (via le menu d’options dans le panneau de démarrage de session), ou modifié plus tard dans les Settings de la session.

À chaque niveau, vous pouvez faire l’un des trois choix suivants :

* **Hériter** (par défaut) — aucun choix explicite ; le niveau supérieur décide.
* **Épingler un profil** — les sessions à ce niveau utilisent le profil sélectionné.
* **Aucun profil** — retrait explicite, afin que les sessions à ce niveau s’exécutent sans restriction même si un niveau supérieur définit une valeur par défaut recommandée.

Lorsqu’une session démarre, Devin parcourt la hiérarchie de haut en bas : l’association la plus spécifique l’emporte, sauf si un profil obligatoire défini plus haut impose des restrictions (voir ci-dessous). Les sessions lancées par d’autres sessions (sessions enfants) sont régies par la même chaîne que leur parent ; il n’est donc pas possible de contourner les restrictions en déléguant le travail.

<div id="when-changes-take-effect">
  ### Quand les modifications prennent effet
</div>

Une session détermine le profil qui la régit au moment où elle démarre : lors de sa création initiale, puis chaque fois qu’elle sort de veille ou redémarre. Les modifications apportées au contenu d’un profil ou à une association quelconque (une valeur par défaut, une automatisation épinglée ou une sélection de session) ne se propagent **pas** automatiquement aux sessions déjà en cours d’exécution — une session en cours conserve les restrictions déterminées lors de sa dernière sortie de veille. Les modifications prennent effet immédiatement pour les nouvelles sessions, et pour les sessions existantes, la prochaine fois qu’elles reprennent.

<div id="mandatory-vs-recommended-enforcement">
  ## Application obligatoire ou recommandée
</div>

Chaque profil possède un niveau d’application :

<div id="recommended">
  ### Recommandé
</div>

Un profil recommandé est un profil par défaut, pas une obligation. Toute personne (disposant de l’autorisation appropriée) à un niveau inférieur peut épingler un profil différent ou s’en retirer complètement. Utilisez les profils recommandés pour offrir aux Teams une configuration initiale pertinente tout en conservant la flexibilité.

<div id="mandatory">
  ### Obligatoire
</div>

Un profil obligatoire constitue un seuil minimal auquel les niveaux inférieurs ne peuvent pas déroger :

* **Le refus n’a aucun effet.** Une sélection « aucun profil » sous un profil obligatoire est ignorée.
* **Les sélections des niveaux inférieurs peuvent uniquement renforcer les restrictions, jamais les assouplir.** Si un niveau inférieur épingle un autre profil, les deux sont *croisés* :
  * Les listes d’autorisation réseau sont restreintes aux destinations autorisées par **les deux** profils.
  * Les listes d’autorisation MCP sont restreintes aux serveurs autorisés par les deux.
  * L’accès Git prend le **minimum** (la lecture seule l’emporte sur l’accès complet).
  * L’accès Devin MCP est en lecture seule si **l’un ou l’autre** des profils définit la lecture seule.
  * Le jeton GitHub CLI est supprimé si **l’un ou l’autre** des profils le supprime.
* **Les modifications en cours de session restent contraintes.** L’accès réseau accordé pendant une session (p. ex. en approuvant la demande de Devin pour un nouveau domaine) est croisé avec la politique du profil obligatoire ; une session ne peut donc jamais obtenir un accès dépassant ce qu’autorise le profil obligatoire.

Par exemple, une entreprise peut associer un profil obligatoire à une politique réseau autorisant `*.internal.example.com` comme valeur par défaut à l’échelle de l’entreprise. Les organisations peuvent ensuite superposer leurs propres profils pour restreindre davantage des Teams ou des workflows spécifiques, mais aucune organisation, aucune automatisation ni aucune session ne peut élargir l’accès au-delà de la politique de l’entreprise.

<div id="permissions-and-governance">
  ## Autorisations et gouvernance
</div>

La gestion des profils est régie par une autorisation dédiée, **Gérer les profils de sécurité**, distincte de la gestion générale des paramètres. Elle existe à deux niveaux, chacun étant accordé indépendamment :

| Niveau d’autorisation | Ce qu’elle permet                                                                                                                                                                                   | Accordée par défaut à          |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| Organisation          | Créer, modifier et supprimer des profils d’organisation ; définir les configurations par défaut de l’organisation et des automatisations ; épingler des profils aux automatisations et aux sessions | Administrateurs d’organisation |
| Enterprise            | Créer, modifier et supprimer des profils Enterprise ; définir la configuration Enterprise par défaut                                                                                                | Administrateurs Enterprise     |

Les deux niveaux de cette autorisation peuvent être attribués à des [rôles personnalisés](/fr/enterprise/security-access/custom-roles), ce qui vous permet de déléguer la gestion des politiques de sécurité (par exemple à une équipe de sécurité) sans accorder tous les droits d’administration.

Les membres qui ne disposent pas de cette autorisation ne peuvent ni lister, ni sélectionner, ni modifier les profils — leurs sessions appliquent simplement la configuration par défaut résolue — mais chacun peut voir si sa session est régie par un profil et de quel accès réseau elle dispose.

<div id="setting-up-security-profiles">
  ## Configuration des profils de sécurité
</div>

1. **Créez un profil.** Accédez à **Settings → Customization → Profils de sécurité** (ou **Enterprise settings → Devin → Profils de sécurité** pour un profil à l’échelle de l’entreprise), créez un profil et configurez ses paramètres de sécurité et son niveau d’application.
2. **Définissez une valeur par défaut.** Définissez ce profil comme profil par défaut de votre organisation (ou profil par défaut de l’entreprise) afin que les nouvelles sessions l’utilisent automatiquement.
3. **Épinglez-le là où c’est nécessaire.** Appliquez une dérogation à la valeur par défaut sur des automatisations spécifiques — par exemple, un profil plus strict pour une automatisation qui touche des systèmes sensibles — ou sur des sessions individuelles au moment de leur création.
4. **Renforcez progressivement.** Commencez par un profil recommandé pour observer l’impact, puis rendez-le obligatoire une fois que vos listes d’autorisation couvrent les besoins légitimes de vos équipes.

<div id="automations-and-profiles">
  ## Automatisations et profils
</div>

Les automatisations peuvent avoir leur propre politique réseau et leur propre sélection de serveurs MCP. Il s’agit de **couches uniquement restrictives** qui s’ajoutent au profil applicable : les sessions démarrées par l’automatisation n’ont accès qu’aux destinations réseau et aux serveurs MCP autorisés par **l’automatisation et le profil**. Une automatisation ne peut donc jamais étendre l’accès du profil.

La couche d’automatisation est déterminée dynamiquement à chaque démarrage ou sortie de veille de session. La modification de la politique réseau d’une automatisation prend donc effet sans qu’il soit nécessaire de recréer ses sessions.

<div id="outposts-and-profiles">
  ## Outposts et profils
</div>

Les sessions exécutées sur les [Devin Outposts](/fr/cloud/outposts/overview) déterminent leur profil applicable via la même chaîne d’association que les sessions cloud, et les restrictions appliquées par Devin depuis son cloud — la liste d’autorisation MCP, le mode lecture seule de Devin MCP, le niveau d’accès Git et la suppression du jeton de la GitHub CLI — s’appliquent aux sessions Outpost exactement comme aux sessions cloud.

La **politique réseau** est différente. Devin applique la liste d’autorisation réseau d’une session au niveau de la machine sur les VM gérées par Devin, mais un worker Outpost s’exécute sur l’infrastructure que vous exploitez. Devin n’installe donc pas de règles de pare-feu sur vos machines. À la place, la politique réseau effective de chaque session en file d’attente est transmise à votre orchestrateur via l’[API Outposts](/fr/cloud/outposts/reference) sous la forme de `spec.network_policy` (l’activation de la politique, ainsi que les noms d’hôte et CIDR autorisés). Son application — par exemple à l’aide d’un proxy de sortie par session, d’une `NetworkPolicy` Kubernetes ou de règles de pare-feu de VM — relève de la responsabilité de l’opérateur Outpost. Devin voit toujours la liste d’autorisation et demande l’accès aux destinations manquantes comme d’habitude, mais l’approbation d’une demande met uniquement à jour la politique de la session dans Devin ; elle ne modifie pas votre réseau à elle seule. `spec.network_policy` est capturée lorsque la session est mise en file d’attente pour un Outpost et actualisée lorsqu’elle y est remise en file d’attente (par exemple après que la session entre en veille et en sort). Relisez-la donc via l’API plutôt que de supposer qu’elle est statique.

<Warning>
  Si vous vous appuyez sur la politique réseau d’un profil obligatoire comme frontière stricte, assurez-vous que votre infrastructure Outpost applique `spec.network_policy` à chaque session qu’elle exécute. Sans cela, les sessions sur les Outposts disposent du même accès réseau que vos machines.
</Warning>