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

# Contrôles de Local Agent

> Configurez les paramètres de Devin Desktop et de Devin CLI dans votre Enterprise à l'aide d'une configuration de base au niveau racine et de dérogations par organisation.

Les administrateurs Enterprise configurent l'utilisation des Local Agents par les membres — [Devin Desktop](/fr/desktop/devin-local) et [Devin CLI](/fr/cli/enterprise/team-settings) — au moyen d'un système à deux niveaux :

* La **configuration au niveau racine** définit la configuration de base qui s'applique à toutes les organisations de votre Enterprise.
* Les **dérogations au niveau de l'organisation** vous permettent d'adapter certains contrôles pour une organisation spécifique sans affecter les autres.

Les deux niveaux proposent le même ensemble de contrôles (fonctionnalités, modèles, autorisations et sécurité, MCP/ACP, intelligence de la base de code, partage et conformité). Cette page explique comment ces deux niveaux interagissent.

<Note>
  Ces contrôles régissent les Local Agents qui s'exécutent sur les machines de vos membres. Ils prévalent sur toute configuration locale définie par un membre au niveau de l'utilisateur ou du projet : les règles imposées par l'Enterprise ont toujours priorité. Consultez les [paramètres d'équipe de la CLI](/fr/cli/enterprise/team-settings) pour connaître les différents paramètres et leur signification.
</Note>

<div id="root-level-configuration">
  ## Configuration au niveau racine
</div>

La configuration au niveau racine constitue votre référence à l’échelle de l’entreprise. Chaque organisation de l’entreprise hérite de ces valeurs, sauf si elle applique explicitement une dérogation à un contrôle spécifique.

Gérez la configuration au niveau racine depuis les paramètres de l’entreprise :

* **Settings → Enterprise → Devin Desktop**

Définissez d’abord ici vos valeurs par défaut à l’échelle de l’entreprise. Tout ce que vous configurez à ce niveau devient la valeur effective pour toutes les organisations qui n’ont pas appliqué de dérogation.

<div id="organization-level-overrides">
  ## Dérogations au niveau de l’organisation
</div>

<Warning>
  L’application de dérogations propres à une organisation nécessite d’attribuer la facturation des Local Agents à des sous-organisations spécifiques. **Contactez votre équipe de compte pour activer cette fonctionnalité** avant de vous appuyer sur des dérogations au niveau de l’organisation.
</Warning>

Dans chaque organisation, les admins peuvent ouvrir la même page de Settings et définir des dérogations pour certains contrôles uniquement au sein de cette organisation. Sur la page au niveau de l’organisation, chaque contrôle affiche la valeur actuellement héritée de la racine, grisée et non modifiable, ainsi qu’une action **Override**.

<Steps>
  <Step title="Ouvrir les Settings de l’organisation">
    Accédez à la page des Settings **Devin Desktop** de l’organisation. Les contrôles hérités de la racine sont affichés, mais ne sont pas modifiables.
  </Step>

  <Step title="Définir une dérogation pour un contrôle">
    Cliquez sur **Override** pour le contrôle que vous souhaitez modifier. Le contrôle devient modifiable et sa valeur est désormais définie au niveau de l’organisation.
  </Step>

  <Step title="Réinitialiser l’héritage">
    Cliquez sur **Réinitialiser** pour un contrôle faisant l’objet d’une dérogation afin de supprimer celle-ci. Le contrôle hérite alors de nouveau de la valeur actuelle au niveau racine.
  </Step>
</Steps>

<div id="overrides-are-a-pure-replacement-lists-are-not-merged">
  ### Les dérogations remplacent intégralement les valeurs : les listes ne sont pas fusionnées
</div>

Une dérogation au niveau de l’organisation **remplace entièrement** la valeur définie au niveau racine pour ce contrôle. Cela est particulièrement important pour les contrôles qui contiennent des listes, tels que :

* Modèles autorisés
* Serveurs MCP et serveurs MCP figurant dans la liste d’autorisation
* URL du registre MCP
* Règles d’autorisation (`allow` / `ask` / `deny`)
* Listes d’autorisation et de refus de Command
* Listes d’autorisation et de refus des domaines du sandbox

Lorsque vous appliquez une dérogation à l’un de ces contrôles de liste, la liste de l’organisation est utilisée **telle quelle** : elle n’est *ni* mise en union, ni complétée, ni autrement combinée avec la liste au niveau racine. La valeur définie au niveau de l’organisation constitue l’intégralité de la liste effective.

<Warning>
  Les listes étant remplacées plutôt que fusionnées, une dérogation au niveau de l’organisation n’hérite **d’aucune** entrée de la liste racine. Si vous souhaitez que les entrées de la liste racine restent en vigueur pour cette organisation, incluez-les explicitement dans la dérogation.
</Warning>

Par exemple, si la racine autorise les serveurs MCP `A` et `B` et qu’une organisation remplace la liste des serveurs MCP autorisés par `C` uniquement, les membres de cette organisation ne peuvent utiliser que `C` : ni `A` ni `B`.

<div id="each-control-is-independent">
  ### Chaque contrôle est indépendant
</div>

Les dérogations s’appliquent contrôle par contrôle. La dérogation appliquée à un contrôle n’a aucun effet sur les autres contrôles :

* Les contrôles faisant l’objet d’une dérogation prennent leur valeur au niveau de l’organisation.
* Tous les autres contrôles continuent d’hériter de la configuration au niveau racine.

Vous pouvez ainsi vous écarter de la référence Enterprise uniquement pour les contrôles dont une organisation a besoin, tandis que tous les autres restent synchronisés avec la racine. Si vous modifiez ultérieurement une valeur au niveau racine, cette modification s’applique à toutes les organisations n’ayant pas dérogé à ce contrôle particulier.

<div id="reset-to-inherit">
  ### Réinitialiser pour hériter
</div>

Vous pouvez supprimer toute dérogation avec **Réinitialiser**. La réinitialisation d’un contrôle supprime la valeur définie au niveau de l’organisation et permet à ce contrôle d’hériter à nouveau de la valeur racine, comme s’il n’avait jamais fait l’objet d’une dérogation. Elle ne s’applique qu’au contrôle réinitialisé ; les autres dérogations de la même organisation ne sont pas affectées.

<div id="which-organizations-controls-apply-to-a-user">
  ## Quels contrôles d'organisation s'appliquent à un utilisateur
</div>

Les contrôles d'organisation d'un utilisateur Enterprise sont configurés en fonction de son **organisation de facturation principale**.

L'organisation de facturation principale est l'organisation à laquelle est facturée l'utilisation du Local Agent par l'utilisateur. Elle est déterminée dans l'ordre suivant :

1. **Attribution explicite** — un administrateur attribue une organisation de facturation à l'utilisateur.
2. **Détermination automatique** — sinon, la première organisation à laquelle l'utilisateur a accès (par adhésion directe ou via un groupe du fournisseur d'identité) est utilisée.

En pratique, un utilisateur bénéficie de la configuration au niveau racine, ainsi que des éventuelles dérogations définies pour son organisation de facturation principale. Deux utilisateurs d'une même Enterprise peuvent donc disposer de contrôles effectifs différents si leurs organisations de facturation principales diffèrent ou si elles appliquent des dérogations à des paramètres différents.

<Tip>
  Si vous vous appuyez sur des contrôles propres à une organisation, nous vous recommandons d'**attribuer explicitement une organisation de facturation principale à chaque utilisateur** plutôt que de vous fier à la détermination automatique. L'attribution explicite permet de savoir avec certitude quelles dérogations d'organisation s'appliquent à chaque utilisateur.
</Tip>

<div id="further-reading">
  ## Pour aller plus loin
</div>

* [Paramètres d’équipe de Devin CLI](/fr/cli/enterprise/team-settings) — les différents contrôles et leur rôle
* [Local Agent de Devin](/fr/desktop/devin-local) — le Local Agent dans Devin Desktop
* [Autorisations](/fr/cli/reference/permissions) — la syntaxe des règles d’autorisation utilisée par les contrôles d’autorisation
* [Configuration](/fr/cli/reference/configuration/config-file) — le lien entre la configuration locale (utilisateur/projet) et les paramètres imposés
