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

# Marketplace des plugins

> Installez et rendez obligatoires des bundles de skills pour tous les membres de votre org ou de votre entreprise depuis l’application web Devin

<Note>
  Les plugins sont en **bêta fermée**. Pour demander l’accès, contactez [support@cognition.ai](mailto:support@cognition.ai). Leur fonctionnement et leur configuration peuvent évoluer dans les prochaines versions.
</Note>

<div id="what-are-plugins">
  ## Que sont les plugins ?
</div>

Un **plugin** est un ensemble de [skills](/fr/product-guides/skills) — et éventuellement de règles, de hooks et de serveurs MCP — regroupées pour pouvoir être installé et réutilisé comme une seule unité. Alors qu’une skill se trouve dans un seul repo, un plugin est une source portable (un repo GitHub, une URL git, un sous-dossier de repo ou un fichier `.zip` importé) que vous pouvez rendre obligatoire dans l’ensemble de votre org ou de votre entreprise.

Les **plugins gérés** permettent à un administrateur d’installer des plugins de façon centralisée depuis l’application web Devin, afin qu’ils s’appliquent à **toutes les personnes de l’org ou de l’entreprise** — sans configuration par utilisateur. Cela couvre les sessions Devin dans le cloud **ainsi que** les utilisateurs de [Devin CLI](/fr/cli/index) connectés au compte (la configuration au niveau de l’Enterprise / compte s’applique aussi au CLI — voir [sessions cloud vs. CLI](#cloud-sessions-vs-the-cli)). Lorsqu’un plugin est installé, ses skills deviennent automatiquement disponibles pour Devin sous forme de commandes `/<plugin>:<skill>`.

Cette page couvre la partie cloud (application web) des plugins. Pour le format de fichier des plugins et le processus d’installation par utilisateur du CLI, consultez la [référence des plugins CLI](/fr/cli/extensibility/plugins/overview).

<div id="where-to-configure-them">
  ## Où les configurer
</div>

Accédez à [**Settings → Marketplace**](https://app.devin.ai/settings/marketplace). La page comporte deux onglets :

* **Marketplace** — parcourez les plugins (le catalogue officiel de Devin, ainsi que ceux ajoutés par votre org ou votre instance Enterprise) et installez-les. L’installation d’un plugin **l’ajoute au manifeste du périmètre choisi comme plugin requis**, ce qui l’installe pour tous les utilisateurs de ce périmètre.
* [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) — modifiez le **manifeste** brut du plugin au format JSON, et téléversez votre propre plugin sous forme de dossier ou de fichier `.zip` (ou créez-en un dans l’Editor).

L’accès est soumis aux autorisations :

* Les **Org admins** (accès aux paramètres de l’organisation) gèrent le manifeste de l’**org**.
* Les **Enterprise admins** (accès aux paramètres Enterprise) gèrent également le manifeste **Enterprise** partagé.

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

Le manifeste est un document JSON unique comportant trois listes :

```jsonc theme={null}
{
  "requiredPlugins": [
    // Propriétaire/dépôt GitHub
    "acme/review-tools",

    // toute URL git
    "https://gitlab.com/acme/secure-base.git",

    // forme objet
    { "source": "github", "repo": "acme/audit-logging" },

    // un plugin situé dans un sous-dossier
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "optionalPlugins": [],

  "forbiddenPlugins": [
    "sketchy-org/bad-plugin",
    "acme/*"
  ]
}
```

* **`requiredPlugins`** — installés pour tous les utilisateurs du périmètre (récursivement, y compris tous les plugins dont ils dépendent).
* **`optionalPlugins`** — une liste d’autorisation qui autorise des plugins sans les installer automatiquement ; elle sert à définir des exceptions à une entrée interdite.
* **`forbiddenPlugins`** — une liste d’interdiction d’identités de plugin ou de motifs glob (p. ex. `acme/*`, ou `"*"` pour un blocage total).

Chaque entrée de `requiredPlugins` / `optionalPlugins` est une **source** — soit une chaîne en forme abrégée, soit un objet :

| Forme                                                              | Signification                                          |
| ------------------------------------------------------------------ | ------------------------------------------------------ |
| `"owner/repo"`                                                     | dépôt GitHub                                           |
| `"https://…"`, `"git@…"`, `"ssh://…"`                              | n’importe quelle URL git                               |
| `{ "source": "github", "repo": "owner/repo" }`                     | GitHub, format objet                                   |
| `{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }` | URL git, format objet                                  |
| `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`        | un plugin situé dans un sous-dossier d’un repo partagé |

Toutes les formes GitHub pour un même repo (`owner/repo`, l’URL HTTPS, l’URL `.git`, la forme SSH) correspondent à la même identité de plugin.

Le manifest est stocké tel quel ; l’agent valide la source complète au moment de l’installation.

<div id="governance-rules">
  ### Règles de gouvernance
</div>

Les entrées `forbiddenPlugins` sont mises en correspondance avec les identités de plugin :

* Une **identité exacte**, écrite sous la forme `owner/repo` ou d’une URL Git. Toutes les formes GitHub d’un même repo (`owner/repo`, l’URL HTTPS, l’URL `.git`, la forme SSH) renvoient à la même identité.
* Un **motif glob** — toute entrée contenant `*`. Le `*` correspond à n’importe quelle séquence de caractères, y compris `/` : `acme/*` correspond à tous les repos GitHub de `acme`, `*/secrets` correspond à un repo nommé `secrets` chez n’importe quel propriétaire, et `https://gitlab.com/acme/*` correspond à n’importe quel repo sous ce chemin.
* Le simple `"*"`, qui correspond à tout le reste (verrouillage complet).

Les listes se combinent selon une logique où l’interdiction l’emporte :

* **L’interdiction l’emporte.** Un plugin est bloqué si un manifest actif ou un plugin installé l’interdit. Si rien n’interdit quoi que ce soit, rien n’est bloqué.
* **Dérogation pour soi-même.** Les `requiredPlugins` et `optionalPlugins` d’un manifest (ou d’un plugin) — et, pour un plugin, le plugin lui-même — sont exemptés de leur **propre** liste d’interdictions. Ainsi, `"forbiddenPlugins": ["*"]` plus `"optionalPlugins": ["acme/approved"]` signifie « n’autoriser que ce que ce manifest liste ; interdire tout le reste. » Cette exception ne couvre que ces entrées directes, pas les dépendances transitives d’un plugin requis — listez-les explicitement dans le cadre d’un verrouillage.
* **Aucune réautorisation inter-périmètres.** La liste des autorisations d’un manifest ou d’un plugin ne peut pas réautoriser ce qu’**un autre** interdit. Un verrouillage `"forbiddenPlugins": ["*"]` ne peut pas être contourné depuis un périmètre inférieur.

L’application des règles se fait à deux moments :

* **À 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 chargement** — un plugin bloqué après avoir déjà été installé reste sur le disque, mais ses skills sont ignorées au démarrage de la session, avec un avertissement indiquant l’élément qui l’interdit.

En plus de ces règles, les manifestes gérés sont **hiérarchisés** — **entreprise/compte** au-dessus de **l’organisation**, elle-même au-dessus de la configuration des plugins au niveau du dépôt et de l’utilisateur. Le niveau d’autorité supérieur prévaut : un niveau inférieur ne peut jamais interdire un plugin qu’un niveau supérieur exige, ni réautoriser un plugin qu’un niveau supérieur interdit. Ainsi, une interdiction au niveau de l’organisation ne peut pas bloquer un plugin exigé au niveau de l’entreprise, mais une interdiction au niveau de l’entreprise prévaut sur une exigence au niveau de l’organisation.

<div id="adding-your-own-plugins">
  ## Ajouter vos propres plugins
</div>

Un plugin est simplement un répertoire qui contient un manifeste `.devin-plugin/plugin.json` et un dossier `skills/` contenant des [skills](/fr/product-guides/skills) ordinaires :

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # nom, version et listes de dépendances optionnelles
├── AGENTS.md           # règle toujours active optionnelle
├── rules/              # règles déclenchées optionnelles
├── hooks.json          # lifecycle hooks optionnels
├── mcp_config.json     # serveurs MCP optionnels
└── skills/
    └── review/
        └── SKILL.md    # une skill ordinaire
```

Au-delà des skills, un plugin peut inclure :

* **Règles** — un fichier `AGENTS.md` à la racine du plugin est injecté comme règle toujours active dans chaque session — dans les sessions cloud comme dans le CLI. Les fichiers Markdown d’un dossier `rules/` sont également chargés, en respectant leur frontmatter `trigger` — consultez la [référence des plugins CLI](/fr/cli/extensibility/plugins/overview).
* **Hooks** — un fichier `hooks.json` à la racine du plugin enregistre des [hooks de cycle de vie](/fr/cli/extensibility/hooks/lifecycle-hooks) qui s’exécutent dans la session. Les sessions cloud exécutent les hooks `command` pour tous les événements sauf `SessionStart` et `SessionEnd` — ainsi, `PreToolUse`, `PostToolUse`, `PermissionRequest`, `UserPromptSubmit`, `Stop` et `PostCompaction` fonctionnent tous ; les hooks de type `prompt` sont réservés au CLI et au local.
* **Serveurs MCP** — un fichier `mcp_config.json` à la racine du plugin déclare des serveurs [MCP](/fr/work-with-devin/mcp) (`"mcpServers": { "<name>": { … } }`) qui se chargent dans chaque session où le plugin est installé. Ils n’apparaissent pas encore dans l’interface Settings des MCP, mais leurs outils sont disponibles pour Devin. La configuration MCP d’un plugin peut définir un Client ID OAuth et des scopes, mais jamais de client secret OAuth — une configuration de serveur qui en contient un est rejetée lors de l’activation.
* **Sous-agent personnalisé** — profils `agents/<name>.md` (ou `agents/<name>/AGENT.md`). Ils ne se chargent actuellement que dans les agents Devin locaux — le [Devin CLI](/fr/cli/extensibility/plugins/overview) et Devin Desktop — pas dans les sessions cloud.

Le **plugin est l'unité d'installation** : l'installer installe tous ses skills (ainsi que tout ce qui figure dans ses `requiredPlugins`) — vous ne pouvez pas installer des skills individuellement depuis un plugin. Pour proposer des skills séparément, répartissez-les dans des plugins distincts. Consultez la [référence des plugins CLI](/fr/cli/extensibility/plugins/overview) pour le format complet de `plugin.json` et la procédure de création en local.

Selon l'emplacement du plugin, ajoutez-le de l'une des façons suivantes :

| Où il se trouve                                            | Comment l'ajouter                                                                                                                                      |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Repo git public**                                        | Ajoutez `"owner/repo"` (ou l'URL git) au manifeste, ou installez-le depuis l'onglet Marketplace s'il figure dans le catalogue                          |
| **Repo git privé**                                         | Même entrée de manifeste — voir [utiliser un repo de skills privé](#using-a-private-skills-repo) pour comprendre comment l'authentification fonctionne |
| **Sous-dossier d'un repo** (p. ex. un monorepo de plugins) | `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }` — chaque sous-dossier constitue son propre plugin                                          |
| **Pas du tout dans un repo**                               | Téléversez-le sous forme de bundle (ci-dessous)                                                                                                        |

Un repo (ou un sous-dossier `git-subdir`) correspond à un plugin. Un même repo peut héberger plusieurs plugins dans des sous-dossiers, chacun référencé par sa propre entrée `git-subdir`.

<div id="uploading-a-plugin-bundle">
  ### Importer un bundle de plugin
</div>

Dans l’onglet [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration), la section **Plugin importé** vous permet d’importer un plugin sous la forme d’un dossier ou d’un fichier `.zip`, ou d’en créer un directement dans l’éditeur. L’enregistrer l’ajoute au manifeste comme plugin requis (ce qui l’installe pour tous les utilisateurs du périmètre) ; le supprimer retire la référence. C’est une bonne option pour un plugin que vous ne souhaitez pas (ou ne pouvez pas) héberger dans un dépôt git.

<div id="using-a-private-skills-repo">
  ### Utiliser un repo privé de skills
</div>

Faites pointer le manifeste directement vers le repo privé — en général, vous n'avez pas besoin de l'inclure dans votre [snapshot d'environnement](/fr/onboard-devin/environment/blueprints). Tout repo privé auquel Devin peut déjà accéder via votre intégration Git s'installe automatiquement. Utilisez le format d'URL git, ou `git-subdir` pour installer un plugin à partir d'un sous-dossier d'un repo partagé. (Les utilisateurs de la CLI couverts par le même manifeste récupèrent le contenu avec leurs propres identifiants git locaux ; ils doivent donc eux aussi avoir accès au repo.)

Si le repo n'est pas accessible via votre intégration Git, soit **téléversez-le sous forme de bundle** (ci-dessus), soit clonez-le pendant la configuration de l'environnement et référencez-le via un chemin local.

<div id="how-updates-roll-out">
  ## Déploiement des mises à jour
</div>

* Les **modifications du manifeste** (Settings → Marketplace) s’appliquent à la **session suivante**.
* Les **modifications du plugin** — les fusions dans la branche suivie par un plugin sont répercutées automatiquement sur les nouvelles sessions, en quelques heures. Verrouillez le plugin sur un SHA de commit pour garder le contrôle des mises à jour ; en CLI, `devin plugins update` met à jour immédiatement.
* Les sessions en cours conservent ce qu’elles ont chargé au démarrage — les mises à jour ne modifient jamais une session en cours d’exécution.

<div id="compatibility">
  ## Compatibilité
</div>

Les plugins Claude fonctionnent aussi : s'il n'y a pas de `.devin-plugin/plugin.json`, Devin utilise à la place un `.claude-plugin/plugin.json`. Lorsque les deux manifestes sont présents, celui de Devin prévaut.

<div id="scope-and-inheritance">
  ## Périmètre et héritage
</div>

Les manifestes gérés existent sur deux niveaux au maximum :

* Les **comptes autonomes** disposent d’un seul manifeste de **compte** qui s’applique à tout le monde.
* Les **entreprises** disposent d’un manifeste **enterprise** partagé, **hérité par chaque org enfant**, ainsi que d’un manifeste par **org** qui s’y ajoute en dessous. La vue Marketplace affiche les deux, et les administrateurs Enterprise peuvent choisir d’installer un plugin au périmètre enterprise (il s’applique partout), ou un administrateur d’org peut l’installer uniquement pour son org.

Ils se situent en haut de la hiérarchie globale des plugins, au-dessus de toute configuration de plugin par repo ou par utilisateur :

1. Manifeste **Enterprise / compte** (cette page)
2. Manifeste **Org** (cette page)
3. Configuration de plugin au niveau du **repo** (le `.devin/config.json` d’un repo)
4. Plugins au niveau **utilisateur** — les installations [CLI](/fr/cli/extensibility/plugins/overview) propres à une personne, qui s’appliquent uniquement à son agent Devin local et ne sont jamais chargées dans les sessions cloud

Le niveau supérieur prévaut : un niveau inférieur ne peut jamais autoriser un plugin qu’un niveau supérieur interdit, ni interdire un plugin qu’un niveau supérieur exige (voir les [règles de gouvernance](#governance-rules)).

<div id="cloud-sessions-vs-the-cli">
  ### Sessions cloud vs. CLI
</div>

Les sessions cloud Devin comme le [Devin CLI](/fr/cli/index) appliquent toutes deux le manifeste **enterprise/account** : les plugins requis sont installés et les interdictions sont également appliquées aux utilisateurs du CLI connectés au compte.

Le manifeste **org** s'applique uniquement aux **sessions cloud**. Le CLI s'authentifie au niveau du compte et n'a pas de contexte d'org ; les exigences et interdictions au niveau de l'org ne s'appliquent donc pas aux utilisateurs du CLI. Placez dans le manifeste **enterprise/account** tout ce qui doit être appliqué dans le CLI (ou à l’échelle du compte), et utilisez le manifeste d'org pour les ajouts spécifiques à l'org dans les sessions cloud.

<div id="learn-more">
  ## En savoir plus
</div>

* [Skills](/fr/product-guides/skills) — les procédures `SKILL.md` intégrées aux plugins
* [Référence des plugins CLI](/fr/cli/extensibility/plugins/overview) — format des fichiers de plugin, création et installation par utilisateur
* [Playbooks](/fr/product-guides/creating-playbooks) — modèles de prompt réutilisables associés aux sessions