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

# Autorisations

> Contrôlez ce que l’agent peut faire grâce à des règles d’autorisation détaillées

Le système d’autorisation détermine quelles actions l’agent peut effectuer sans vous demander votre approbation. Vous pouvez préapprouver les actions sûres, bloquer les actions dangereuses et toujours demander une confirmation pour les opérations sensibles.

***

<div id="default-permission-behavior">
  ## Comportement par défaut des autorisations
</div>

Devin CLI utilise un système d’autorisations à plusieurs niveaux pour concilier puissance et sécurité. Le comportement par défaut dépend du [mode](/fr/cli/essential-commands#modes) actuel :

Chaque cellule indique si cet outil s’exécute automatiquement (**Auto**, sans confirmation) ou attend votre approbation (**Prompt**) dans ce mode :

| Type d’outil                                 | Exemple                         | Normal | Accept Edits             | Bypass | Autonomous (sandbox) |
| -------------------------------------------- | ------------------------------- | ------ | ------------------------ | ------ | -------------------- |
| Lecture seule                                | Lecture de fichiers, grep, glob | Auto   | Auto                     | Auto   | Auto                 |
| Fetch                                        | Requêtes HTTP                   | Prompt | Prompt                   | Auto   | Auto                 |
| Commandes Bash                               | Exécution de commandes shell    | Prompt | Prompt                   | Auto   | Auto                 |
| Modifications de fichiers via `edit`/`write` | Modifier/écrire des fichiers    | Prompt | Auto (dans le workspace) | Auto   | Prompt               |

En **mode Normal** (par défaut), les opérations en lecture seule sont approuvées automatiquement, tandis que les écritures et les commandes shell nécessitent votre approbation explicite. Chaque fois que vous approuvez une action, vous pouvez choisir de l’autoriser une seule fois, pour la session ou de façon permanente pour le projet.

En **mode Accept Edits**, les modifications de fichiers dans le workspace sont approuvées automatiquement, mais les commandes shell et les écritures en dehors du workspace nécessitent toujours une confirmation.

En **mode Bypass**, tous les appels aux outils sont approuvés automatiquement, sans confirmation.

En **mode Autonomous**, les commandes shell et les requêtes réseau sont approuvées automatiquement, car le sandbox au niveau du système d’exploitation limite ce à quoi elles peuvent accéder. Les modifications directes de fichiers via les outils `edit`/`write` nécessitent toujours une confirmation, car ces outils fonctionnent en dehors du sandbox. Autonomous n’est disponible que lorsque le [sandbox au niveau du système d’exploitation](#autonomous-mode) est actif.

<Warning>
  Les modes Bypass et Autonomous ne remplacent **pas** les autorisations à l’échelle de l’organisation. Les règles de refus et de demande imposées par les admins, configurées via [Team Settings](/fr/cli/enterprise/team-settings), restent actives quel que soit le mode d’autorisation de l’utilisateur. Consultez [Precedence](#precedence) pour plus de détails.
</Warning>

<div id="autonomous-mode">
  ### Mode Autonomous
</div>

Autonomous est le mode d’autorisation associé à l’option `--sandbox`. En pratique, il correspond approximativement à « Accept Edits in the current workspace », avec en plus la possibilité d’exécuter n’importe quelle commande shell, les deux étant confinés par le sandbox au niveau du système d’exploitation. Lorsque le sandbox est actif :

* **C’est le seul mode d’autorisation disponible.** Les modes Normal, Accept Edits et Bypass sont masqués dans les sessions sandbox. Le mode Plan reste disponible.
* **Les commandes shell et les opérations de récupération sont automatiquement approuvées** au lieu d’afficher une demande de confirmation, car le sandbox contrôle ce qu’elles peuvent lire, écrire et atteindre sur le réseau.
* **Les modifications directes de fichiers via les outils `edit` et `write` continuent de demander une confirmation.** Ces outils s’exécutent dans le processus CLI plutôt qu’à l’intérieur du sandbox, et ne peuvent donc pas être confinés par celui-ci. Accorder un périmètre `Write(...)` dans le prompt étend dynamiquement le sandbox afin que les commandes shell suivantes puissent y écrire.
* **Les périmètres accordés en cours de session étendent dynamiquement le sandbox** pour les commandes suivantes.

```bash theme={null}
devin --sandbox --permission-mode autonomous
```

Utilisez Bypass lorsque vous voulez une exécution sans restriction, sans isolation au niveau du système d’exploitation ; utilisez `--sandbox` (qui sélectionne Autonomous) lorsque vous voulez une exécution non supervisée avec des restrictions imposées par le système d’exploitation sur l’accès au système de fichiers et au réseau. Consultez la [référence de configuration du sandbox](/fr/cli/reference/configuration/config-file#sandbox) pour en savoir plus sur les racines accessibles en lecture/écriture et le filtrage des domaines, ainsi que [Team Settings → Sandbox Enforcement](/fr/cli/enterprise/team-settings#sandbox-enforcement) pour les contrôles au niveau Enterprise.

***

<div id="how-permissions-work">
  ## Fonctionnement des autorisations
</div>

Lorsque l’agent appelle un outil, le système d’autorisations évalue vos règles par ordre de priorité :

1. **Règles de refus** — Vérifiées en premier. En cas de correspondance, l’action est bloquée immédiatement.
2. **Règles de demande** — Vérifiées en deuxième. En cas de correspondance, une confirmation vous est toujours demandée (cela prévaut sur toute règle d’autorisation).
3. **Règles d’autorisation** — Vérifiées en dernier. En cas de correspondance, l’action s’exécute sans demander de confirmation.
4. **Par défaut** — Si aucune règle ne correspond, une approbation vous est demandée.

<Note>
  Comme les refus sont vérifiés avant les demandes, et les demandes avant les autorisations, une règle de refus l’emporte toujours. Si le même périmètre correspond à la fois à une règle de refus et à une règle de demande, c’est la règle de refus qui s’applique.
</Note>

***

<div id="configuration">
  ## Configuration
</div>

Ajoutez des autorisations dans la section `permissions` de votre fichier de configuration :

<Note>
  Sous Windows, le chemin du fichier de configuration utilisateur est `%APPDATA%\devin\config.json` (généralement `C:\Users\<you>\AppData\Roaming\devin\config.json`) et non `~/.config/devin/config.json`. Consultez [Fichier de configuration](/fr/cli/reference/configuration/config-file#file-locations) pour plus de détails.
</Note>

<Tabs>
  <Tab title="Configuration du projet">
    ```json theme={null}
    // .devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(src/**)",
          "Exec(npm run)"
        ],
        "deny": [
          "Exec(rm)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Configuration utilisateur">
    ```json theme={null}
    // ~/.config/devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(**)",
          "Exec(git)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Dérogation locale">
    ```json theme={null}
    // .devin/config.local.json
    {
      "permissions": {
        "allow": [
          "Exec(docker compose)"
        ]
      }
    }
    ```
  </Tab>
</Tabs>

***

<div id="permission-syntax">
  ## Syntaxe des autorisations
</div>

Il existe deux types de critères de correspondance pour les autorisations : **basés sur le périmètre** (qui contrôlent les chemins/commandes/URL accessibles) et **basés sur les outils** (qui contrôlent les outils pouvant être utilisés).

<div id="scope-based-permissions">
  ### Autorisations basées sur le périmètre
</div>

<AccordionGroup>
  <Accordion title="Read(glob)" icon="eye" defaultOpen>
    Contrôle l'accès en lecture aux fichiers. Le motif glob correspond aux chemins de fichiers.

    ```json theme={null}
    "allow": [
      "Read(src/**)",           // Tous les fichiers dans src/
      "Read(~/.config/**)",     // Fichiers de configuration du répertoire personnel
      "Read(/tmp/**)"           // Répertoire temporaire
    ]
    ```

    Les chemins de répertoire correspondent automatiquement à tous les fichiers qu'ils contiennent.
  </Accordion>

  <Accordion title="Write(glob)" icon="pen">
    Contrôle l'accès en écriture et en modification des fichiers.

    ```json theme={null}
    "allow": [
      "Write(src/**)",          // Peut écrire n'importe où dans src/
      "Write(tests/**)"         // Peut écrire dans les fichiers de test
    ],
    "deny": [
      "Write(*.lock)",          // Ne peut pas modifier les fichiers .lock
      "Write(.env*)"            // Ne peut pas modifier les fichiers .env
    ]
    ```
  </Accordion>

  <Accordion title="Exec(prefix)" icon="terminal">
    Contrôle l'exécution des commandes shell. S'applique aux commandes qui commencent par le préfixe donné.

    ```json theme={null}
    "allow": [
      "Exec(git)",              // git, git status, git commit...
      "Exec(npm run)",          // npm run test, npm run build...
      "Exec(python)"            // python, python script.py...
    ],
    "deny": [
      "Exec(rm)",               // Bloque rm, rm -rf, etc.
      "Exec(sudo)"              // Bloque les commandes sudo
    ]
    ```

    <Note>
      `Exec(git)` correspond à "git", "git status", "git commit -m 'msg'" mais PAS à "gitk" ni à "github-cli". Le préfixe doit correspondre à un mot complet.
    </Note>
  </Accordion>

  <Accordion title="Fetch(pattern)" icon="globe">
    Contrôle l'accès aux requêtes HTTP fetch à l'aide de motifs d'URL.

    ```json theme={null}
    "allow": [
      "Fetch(https://api.github.com/*)",    // API GitHub
      "Fetch(https://*.example.com/*)",     // Tous les sous-domaines de example.com
      "Fetch(domain:npmjs.org)"             // N'importe quelle URL sur npmjs.org
    ]
    ```

    Les motifs d'URL suivent la norme [WHATWG URL Pattern](https://urlpattern.spec.whatwg.org/). Le raccourci `domain:` correspond à n'importe quel chemin sur le domaine exact.
  </Accordion>
</AccordionGroup>

<div id="tool-based-permissions">
  ### Autorisations par outil
</div>

Faites correspondre le nom de l’outil pour contrôler des outils entiers :

```json theme={null}
{
  "permissions": {
    "deny": [
      "edit",       // Bloquer toutes les modifications de fichiers
      "exec"        // Bloquer toute exécution de commandes
    ],
    "allow": [
      "read",       // Autoriser toutes les lectures de fichiers
      "grep",       // Autoriser toutes les recherches
      "glob"        // Autoriser toutes les recherches de fichiers
    ]
  }
}
```

**Noms des outils disponibles :** `read`, `edit`, `grep`, `glob`, `exec`

<div id="mcp-tool-permissions">
  ### Autorisations des outils du serveur MCP
</div>

Contrôlez l'accès aux outils du serveur MCP :

```json theme={null}
{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // Outil spécifique sur un serveur spécifique
      "mcp__github__*",               // Tous les outils sur le serveur github
      "mcp__*"                        // Tous les outils MCP
    ],
    "deny": [
      "mcp__github__delete_repo"      // Bloquer un outil dangereux spécifique
    ]
  }
}
```

| Motif               | Correspond à                 |
| ------------------- | ---------------------------- |
| `mcp__server__tool` | Un outil spécifique          |
| `mcp__server__*`    | Tous les outils d’un serveur |
| `mcp__*`            | Tous les outils MCP          |

***

<div id="path-patterns">
  ## Motifs de chemin
</div>

Les motifs glob dans `Read()` et `Write()` prennent en charge :

| Motif | Signification                                                          |
| ----- | ---------------------------------------------------------------------- |
| `*`   | N’importe quels caractères dans un seul segment de chemin              |
| `**`  | N’importe quels caractères sur plusieurs segments de chemin (récursif) |
| `~`   | Expansion du répertoire personnel                                      |

**Exemples :**

```json theme={null}
"allow": [
  "Read(**)",                    // Tous les fichiers partout
  "Read(src/**/*.ts)",           // Tous les fichiers TypeScript dans src/
  "Write(~/projects/myapp/**)"   // Écriture dans un projet spécifique
]
```

<Note>
  Utilisez un préfixe de chemin absolu (par ex., `Read(/**)`) lorsque vous souhaitez inclure tous les fichiers du système. Un simple `Read(**)` sans `/` au début est interprété par rapport à votre répertoire de travail actuel ; il ne correspond donc qu’aux fichiers situés dans ce répertoire — et non à ceux auxquels on accède ailleurs via des chemins absolus.
</Note>

***

<div id="persistence-options">
  ## Options de persistance
</div>

Lorsque l'agent demande une autorisation pendant une session, vous pouvez choisir comment enregistrer votre décision :

| Option                           | Emplacement d’enregistrement                                               | Partagé avec la Team ? |
| -------------------------------- | -------------------------------------------------------------------------- | ---------------------- |
| Autoriser une fois               | Non enregistré                                                             | Non                    |
| Autoriser pour la session        | En mémoire uniquement                                                      | Non                    |
| Autoriser pour le projet         | `.devin/config.json`                                                       | Oui                    |
| Autoriser pour le projet (local) | `.devin/config.local.json`                                                 | Non                    |
| Autoriser globalement            | `~/.config/devin/config.json` (`%APPDATA%\devin\config.json` sous Windows) | Non                    |

<div id="mcp-server-level-grants">
  ### Autorisations au niveau du serveur MCP
</div>

Lorsqu'une demande d'autorisation s'affiche pour un outil MCP spécifique (p. ex., `list_issues` sur le serveur Figma), l'invite d'autorisation propose également des options plus larges à l'échelle du serveur :

| Option                                                   | Effet                                                                 |
| -------------------------------------------------------- | --------------------------------------------------------------------- |
| Autoriser cet outil (cette session)                      | Accorde l'accès à l'outil spécifique pour la session en cours         |
| Toujours autoriser cet outil                             | Enregistre l'autorisation pour cet outil dans la configuration        |
| Autoriser tous les outils sur ce serveur (cette session) | Accorde l'accès à tous les outils du serveur pour la session          |
| Toujours autoriser les outils sur ce serveur             | Enregistre l'accès à tous les outils du serveur dans la configuration |

Cela vous permet d'accorder rapidement un accès général à un serveur MCP de confiance sans devoir approuver chaque outil individuellement.

***

<div id="precedence">
  ## Ordre de priorité
</div>

Lorsque plusieurs sources d'autorisation définissent des règles, elles sont fusionnées selon l'ordre de priorité suivant (de la plus élevée à la plus faible) :

1. Settings de l'organisation/de la Team (si Enterprise)
2. Autorisations au niveau de la session (approbations interactives)
3. Configuration locale du projet (`.devin/config.local.json`)
4. Configuration du projet (`.devin/config.json`)
5. Configuration utilisateur (`~/.config/devin/config.json` ; `%APPDATA%\devin\config.json` sous Windows)

<Warning>
  Les refus définis au niveau de l'organisation ne peuvent pas être remplacés par la configuration du projet ou de l'utilisateur. Cela garantit l'application des politiques Enterprise.
</Warning>

***

<div id="examples">
  ## Exemples
</div>

<div id="minimal-development-setup">
  ### Configuration de développement minimale
</div>

Autorisez les opérations courantes en lecture seule et demandez une confirmation pour tout le reste :

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}
```

<div id="full-trust-for-a-project">
  ### Confiance totale pour un projet
</div>

Approuvez automatiquement la plupart des opérations dans le projet :

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}
```

<div id="locked-down-enterprise">
  ### Enterprise verrouillée
</div>

Limiter aux seules opérations sûres spécifiques, et toujours demander une confirmation avant toute écriture :

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}
```

<Tip>
  Dans cet exemple, les écritures dans `.env*` sont purement et simplement refusées, toutes les autres écritures demandent systématiquement confirmation à l'utilisateur, et seules quelques commandes en lecture seule sont approuvées automatiquement. Comme `deny` est vérifié avant `ask`, le refus de `.env*` prévaut sur la règle `Write(**)` `ask`.
</Tip>