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

# Plugins

> Installez et partagez des ensembles de skills à partir d’un dépôt, d’une URL git ou d’un dossier local.

<Note>
  Les plugins sont en **bêta**. Leur comportement et leur configuration peuvent changer dans de futures versions.
</Note>

Un **plugin** est un ensemble de [skills](/fr/cli/extensibility/skills/overview) que vous pouvez
installer depuis un dépôt GitHub, une URL git ou un dossier local, puis réutiliser d’un
projet à l’autre. L’installation d’un plugin rend ses skills disponibles sous forme de
commandes slash `/<plugin>:<skill>`, et il peut importer automatiquement d’autres plugins dont il dépend.

Un plugin est simplement une source qui contient :

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # Le manifeste du plugin
└── skills/
    └── review/
        └── SKILL.md    # Un skill ordinaire
```

Le répertoire `skills/` contient des skills ordinaires — les plugins n’introduisent aucun nouveau
format de skill. Voir [Créer des skills](/fr/cli/extensibility/skills/creating-skills) pour le format
`SKILL.md`.

***

<div id="installing-a-plugin">
  ## Installation d’un plugin
</div>

La source d’un plugin peut être un `owner/repo` GitHub, une URL git ou un chemin local :

```bash theme={null}
# Depuis GitHub
devin plugins install acme/review-tools

# Depuis n'importe quel hôte git
devin plugins install https://gitlab.com/acme/review-tools.git

# Depuis un dossier local (idéal pour la création)
devin plugins install ./my-plugin
```

Avant l’installation, Devin affiche ce que le plugin ajoute — les skills qu’il fournit,
les plugins requis qui seront installés automatiquement, ainsi que toute politique qu’il introduit
(par exemple, s’il interdit d’autres plugins). Passez `-y` / `--yes` pour ignorer le
prompt.

Les plugins sont installés au niveau de l’**utilisateur** et sont disponibles dans tous vos
projets.

***

<div id="managing-plugins">
  ## Gérer les plugins
</div>

```bash theme={null}
# Lister les plugins installés, leurs versions, et indiquer si certains sont bloqués par une politique
devin plugins list

# Afficher les skills d'un plugin et ses listes required/optional/forbidden
devin plugins info review-tools

# Récupérer à nouveau un plugin (ou tous les plugins) à la dernière version
devin plugins update review-tools
devin plugins update

# Supprimer un plugin (les plugins required installés automatiquement sont conservés)
devin plugins remove review-tools
```

Les plugins locaux sont liés directement à leur dossier source, donc les modifications sont prises en compte immédiatement :
`devin plugins install ./my-plugin` → modifiez `skills/<name>/SKILL.md` → les modifications
s’appliquent dès la session suivante, sans `update`.

***

<div id="the-manifest">
  ## Le manifeste
</div>

`.devin-plugin/plugin.json` décrit le plugin. Seul `name` est obligatoire, et
il doit être unique parmi les plugins installés (il s’agit de l’espace de noms `/<name>:…`).

```jsonc theme={null}
{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}
```

Champs de métadonnées pris en charge : `name`, `version`, `description`, `author`
(`{ name, email }`), `homepage`, `repository`, `license` et `keywords`.

Une entrée de dépendance est une **source** — soit une forme abrégée sous forme de chaîne, soit un objet :

* `"owner/repo"` → GitHub
* `"https://…"`, `"git@…"`, `"ssh://…"` → URL git
* `{ "source": "github", "repo": "owner/repo" }`
* `{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }`

Toutes les formes GitHub pour le même dépôt (`owner/repo`, l’URL HTTPS, l’URL `.git`,
la forme SSH) désignent le même plugin.

***

<div id="dependencies-and-governance">
  ## Dépendances et gouvernance
</div>

Un plugin peut déclarer trois listes, ce qui permet à un seul plugin de servir de collection organisée et encadrée d'autres plugins.

<div id="requiredplugins">
  ### `requiredPlugins`
</div>

Installés automatiquement (de façon récursive) lors de l’installation du plugin. Si un plugin requis
est bloqué par une politique, l’installation échoue dans son ensemble — il n’existe pas d’installation partielle.

<div id="optionalplugins">
  ### `optionalPlugins`
</div>

Une **liste des plugins autorisés** par ce plugin. Ils ne sont **pas**
installés automatiquement ; cette liste ne sert qu’à définir une exception pour une entrée interdite
(voir ci-dessous).

<div id="forbiddenplugins">
  ### `forbiddenPlugins`
</div>

Une **liste d’interdiction**. Chaque entrée est l’un des éléments suivants :

* Une identité de plugin exacte, écrite sous la forme `owner/repo`, d’une URL git ou d’un chemin local.
* Un **motif glob** — toute entrée contenant `*`. Le `*` correspond à n’importe quelle séquence de
  caractères, y compris `/`. Les motifs sont d’abord normalisés dans l’espace
  d’identité canonique : `acme/*` devient donc `https://github.com/acme/*` (tous les
  repos GitHub de `acme`), `*/secrets` correspond à un repo nommé `secrets` sous
  n’importe quel propriétaire, et `https://gitlab.com/acme/*` correspond à
  n’importe quel repo sous ce chemin.
* Le seul `"*"`, qui correspond à tous les autres plugins (un verrouillage impossible à contourner).

Les règles de la politique sont :

* **L’interdiction l’emporte.** Un plugin est bloqué si un plugin installé
  l’interdit (via son identité exacte, un glob correspondant ou `"*"`).
* **Auto-dérogation.** Les `requiredPlugins`, `optionalPlugins` d’un plugin, ainsi que le plugin
  lui-même, sont exemptés de sa **propre** liste d’interdiction. Ainsi,
  `forbiddenPlugins: ["*"]` avec `optionalPlugins: [B, C]` signifie « m’autoriser,
  moi-même, B et C ; interdire tout le reste. »
* **Aucune réautorisation inter-plugin.** Les listes d’autorisation d’un plugin ne peuvent pas réautoriser
  ce qu’**un autre** plugin interdit. Un plugin installé avec
  `forbiddenPlugins: ["*"]` constitue un verrouillage impossible à contourner.
* **Ouvert par défaut.** Si aucun plugin installé n’interdit quoi que ce soit, rien n’est bloqué.

La politique est appliquée à deux moments :

* **Au moment de l’installation** — l’installation d’un plugin bloqué (ou d’un plugin dont les plugins requis
  ne peuvent pas être satisfaits, ou dont le nom entre en conflit avec un plugin installé) est
  refusée.
* **Au moment du chargement** — si un plugin devient bloqué après l’installation (par exemple, si un plugin
  qui l’interdit est installé plus tard), il reste sur disque mais ses skills sont
  ignorées au démarrage de la session, avec un avertissement indiquant le nom du plugin qui l’interdit.