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

# Mettre en place votre écosystème de plugins

> Créez, hébergez et administrez un ensemble partagé de plugins Devin pour toute votre organisation ou entreprise

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

Ce guide vous explique comment mettre en place votre propre **écosystème de plugins** : un repo de plugins géré par votre organisation, distribué à chaque session Devin et à chaque utilisateur CLI via un manifeste géré, avec des plugins requis, facultatifs et interdits comme mécanismes de gouvernance.

Deux repos modèles accompagnent ce guide :

* [**plugin-template**](https://github.com/CognitionAI/plugin-template) — une base de départ pour créer un plugin unique (ou un ou deux).
* [**team-marketplace-template**](https://github.com/CognitionAI/team-marketplace-template) — le modèle complet d’écosystème : un monorepo de plugins, ainsi qu’un **méta-plugin** dont le manifeste définit votre configuration de base et votre politique.

<div id="1-author-your-plugins">
  ## 1. Créez vos plugins
</div>

Un plugin est un répertoire contenant un manifeste `.devin-plugin/plugin.json` ; tout le reste est facultatif :

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # sous-agents personnalisés (CLI/Desktop uniquement pour l'instant) ; agents/<name>/AGENT.md fonctionne aussi
├── hooks.json          # lifecycle hooks
├── mcp_config.json     # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>
```

Commencez par faire un fork de [plugin-template](https://github.com/CognitionAI/plugin-template), puis consultez la [référence des plugins CLI](/fr/cli/extensibility/plugins/overview) pour le format complet. Gardez `AGENTS.md` court — il consomme du contexte à chaque session pour tous les utilisateurs du plugin.

<div id="2-validate-and-test-locally">
  ## 2. Valider et tester en local
</div>

Les deux modèles sont fournis avec un validateur (`node scripts/validate-template.mjs`) et un workflow CI qui l’exécute à chaque PR. Pour un test en conditions réelles, installez-les depuis un dossier local avec le [Devin CLI](/fr/cli/index) :

```bash theme={null}
devin plugins install ./plugins/my-plugin   # lié : les modifications s'appliquent à la prochaine session
devin plugins list
```

<div id="3-host-them-in-one-repo">
  ## 3. Hébergez-les dans un seul repo
</div>

Placez tous les plugins de votre org dans un seul repo, dans des sous-dossiers (`plugins/<name>/`), chacun référencé avec sa propre source `git-subdir`. Le repo peut rester privé : les sessions cloud le récupèrent via votre intégration Git, et les utilisateurs du CLI le récupèrent avec leurs propres identifiants Git (ils doivent donc eux aussi avoir accès au repo).

Faites un fork de [team-marketplace-template](https://github.com/CognitionAI/team-marketplace-template) pour utiliser cette structure — puis mettez à jour les URL `git-subdir` de son méta-plugin pour qu'elles pointent vers votre fork. Dans le template, le méta-plugin se trouve à la **racine du repo** ; le repo lui-même est donc l’unité installable : déclarer `your-org/your-marketplace` installe toute la configuration de base.

<div id="4-define-your-baseline-with-a-meta-plugin">
  ## 4. Définissez votre configuration de base avec un méta-plugin
</div>

L’approche du **méta-plugin** transforme tout votre écosystème en une seule unité installable. Il s'agit d’un plugin avec peu, voire pas, de contenu propre — c’est son manifeste qui fait le travail. Placez-le à la racine du repo afin que le repo lui-même soit le méta-plugin :

```jsonc theme={null}
// .devin-plugin/plugin.json (racine du dépôt)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // installé automatiquement pour tous, de façon récursive
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    // approuvé, non installé automatiquement ; constitue également une exception aux interdictions de ce manifeste
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}
```

<div id="5-distribute-from-settings-marketplace">
  ## 5. Distribuer depuis Settings → Marketplace
</div>

Un administrateur ajoute une entrée au manifeste géré sur la [page Marketplace de Settings](https://app.devin.ai/settings/marketplace) — voir le [guide de la marketplace des plugins](/fr/product-guides/plugins):

```json theme={null}
{
  "requiredPlugins": ["acme/plugins"]
}
```

Rendre obligatoire le repo de la marketplace installe son méta-plugin racine, qui inclut récursivement toute la configuration de base.

Toutes les personnes dans le périmètre reçoivent désormais automatiquement la configuration de base. Choisissez le périmètre avec soin :

* Le manifeste **enterprise/account** s’applique aux sessions cloud **et** aux utilisateurs du CLI connectés au compte.
* Le manifeste **org** s’applique **uniquement aux sessions cloud** — le CLI n’a pas de contexte d’organisation.

<div id="6-govern">
  ## 6. Gouvernance
</div>

Les trois listes forment le langage de politique à chaque niveau (manifestes gérés, config du repo, manifestes du plugin). Le niveau d’autorité supérieur l’emporte — Enterprise/compte sur org, sur repo, sur utilisateur — et un niveau inférieur ne peut jamais réautoriser ce qu’un niveau supérieur interdit, ni interdire ce qu’il exige.

Pour verrouiller un compte afin de n’autoriser qu’un ensemble approuvé :

```json theme={null}
{
  "forbiddenPlugins": ["*"],
  "requiredPlugins": [
    "acme/plugins",
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ]
}
```

Les entrées required/optional du manifeste lui-même sont exemptées de leur propre interdiction `"*"` ; rien d’autre ne l’est, et aucun niveau inférieur ne peut élargir cette exception. L’exemption ne couvre que les entrées *directement listées* — les dépendances transitives d’un plugin requis ne sont pas exemptées — donc, en cas de verrouillage, listez explicitement tout ce que le méta-plugin embarque (ici `engineering-baseline` et `security-guardrails`). Consultez les [règles de gouvernance](/fr/product-guides/plugins#governance-rules) pour la sémantique complète.

<div id="7-evolve">
  ## 7. Faire évoluer
</div>

* La fusion dans la branche par défaut du repo de votre plugin **constitue** la publication : les nouvelles sessions la prennent en compte automatiquement — voir [comment les mises à jour sont déployées](/fr/product-guides/plugins#how-updates-roll-out).
* Teams ajoutent des plugins par PR au repo de la marketplace ; la CI du template valide la structure à chaque PR.
* Les plugins Claude existants s'installent tels quels (Devin utilise `.claude-plugin/plugin.json` à défaut), vous pouvez donc recommander des plugins de la communauté dans `optionalPlugins` sans les intégrer au dépôt.

<div id="current-limitations">
  ## Limitations actuelles
</div>

* Les plugins se chargent dans les sessions cloud, le [Devin CLI](/fr/cli/index) et Devin Desktop (lors de l’utilisation de Devin Local) ; ils ne s’appliquent pas à l’agent Cascade classique.
* Les **Subagents** (`agents/<name>.md` or `agents/<name>/AGENT.md`) se chargent uniquement dans les agents Devin locaux (CLI et Devin Desktop), et non dans les sessions cloud.
* **Hooks** : les sessions cloud exécutent les hooks `command` pour chaque [événement](/fr/cli/extensibility/hooks/lifecycle-hooks), à l’exception de `SessionStart` et `SessionEnd` ; les hooks de type `prompt` sont réservés au CLI et au local.
* Le **MCP fourni par un plugin** se charge dans la session, mais n’apparaît pas encore dans l’interface Settings du MCP.
* Les manifestes **au niveau de l’organisation** ne s’appliquent pas aux utilisateurs du CLI ; utilisez le manifeste Enterprise/de compte pour l’application dans le CLI.

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

* [Marketplace des plugins](/fr/product-guides/plugins) — côté application web : manifestes, périmètres, mises en ligne
* [Référence des plugins CLI](/fr/cli/extensibility/plugins/overview) — format de fichier, création, installations par utilisateur
* [Skills](/fr/product-guides/skills) — les procédures `SKILL.md` fournies avec les plugins