Marketplace des plugins

Les plugins sont en bêta fermée. Pour demander l’accès, contactez support@cognition.ai. Leur fonctionnement et leur configuration peuvent évoluer dans les prochaines versions.

Que sont les plugins ?

Un plugin est un ensemble de 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 connectés au compte (la configuration au niveau de l’Enterprise / compte s’applique aussi au CLI — voir sessions cloud vs. 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.

Où les configurer

Accédez à 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 — 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é.

Le manifeste

Le manifeste est un document JSON unique comportant trois listes :

{
  "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.

Règles de gouvernance

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.

Ajouter vos propres plugins

Un plugin est simplement un répertoire qui contient un manifeste .devin-plugin/plugin.json et un dossier skills/ contenant des 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.
Hooks — un fichier hooks.json à la racine du plugin enregistre des hooks de cycle de vie 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 ("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 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 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é 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.

Importer un bundle de plugin

Dans l’onglet 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.

Utiliser un repo privé de skills

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

Déploiement des mises à jour

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.

Compatibilité

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.

Périmètre et héritage

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 :

Manifeste Enterprise / compte (cette page)
Manifeste Org (cette page)
Configuration de plugin au niveau du repo (le .devin/config.json d’un repo)
Plugins au niveau utilisateur — les installations CLI 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).

Sessions cloud vs. CLI

Les sessions cloud Devin comme le Devin CLI 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.

En savoir plus

Skills — les procédures SKILL.md intégrées aux plugins
Référence des plugins CLI — format des fichiers de plugin, création et installation par utilisateur
Playbooks — modèles de prompt réutilisables associés aux sessions

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Marketplace des plugins

Que sont les plugins ?

Où les configurer

Le manifeste

Règles de gouvernance

Ajouter vos propres plugins

Importer un bundle de plugin

Utiliser un repo privé de skills

Déploiement des mises à jour

Compatibilité

Périmètre et héritage

Sessions cloud vs. CLI

En savoir plus

​Que sont les plugins ?

​Où les configurer

​Le manifeste

​Règles de gouvernance

​Ajouter vos propres plugins

​Importer un bundle de plugin

​Utiliser un repo privé de skills

​Déploiement des mises à jour

​Compatibilité

​Périmètre et héritage

​Sessions cloud vs. CLI

​En savoir plus

Que sont les plugins ?

Où les configurer

Le manifeste

Règles de gouvernance

Ajouter vos propres plugins

Importer un bundle de plugin

Utiliser un repo privé de skills

Déploiement des mises à jour

Compatibilité

Périmètre et héritage

Sessions cloud vs. CLI

En savoir plus