Skip to main content
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 — une base de départ pour créer un plugin unique (ou un ou deux).
  • 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.

​
1. Créez vos plugins

Un plugin est un répertoire contenant un manifeste .devin-plugin/plugin.json ; tout le reste est facultatif :
Commencez par faire un fork de plugin-template, puis consultez la référence des plugins CLI pour le format complet. Gardez AGENTS.md court — il consomme du contexte à chaque session pour tous les utilisateurs du plugin.

​
2. Valider et tester en local

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 :
Vous pouvez également téléverser un dossier de plugin ou un .zip dans votre périmètre personnel depuis Customize → Plugins et le tester dans une session cloud.

​
3. Hébergez-les dans un seul repo

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

​
4. Définissez votre configuration de base avec un méta-plugin

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 :

​
5. Distribuer depuis Customize

Un admin installe le repo du marketplace depuis Customize → Plugins → Add plugin → From repository au périmètre organization ou enterprise — voir le guide Plugins. Cela ajoute une entrée au manifeste géré du périmètre :
Exiger le repo marketplace installe son méta-plugin root, qui récupère l’ensemble de la configuration de base de manière récursive. Customize indexe ensuite le périmètre et liste chaque plugin ainsi récupéré, avec ses skills, MCP, hooks et règles. Toutes les personnes du périmètre reçoivent désormais la configuration de base automatiquement — dans les cloud sessions, le Devin CLI et Devin Desktop. Choisissez le périmètre en connaissance de cause :
  • Le manifeste enterprise s’applique à toutes les organizations de l’enterprise.
  • Un manifeste organization s’applique aux cloud sessions de cette organization, ainsi qu’au CLI/Desktop des members dont c’est l’organization principale.
Si la configuration de base embarque des MCP servers nécessitant des credentials, terminez la configuration dans l’onglet MCPs après l’indexation. Pour les servers OAuth avec un accès Organization, connectez un service account que les members partageront ; avec un accès Personal, chaque member connecte son propre account. S’il manque du contenu de la configuration de base, suivez Résoudre les problèmes d’indexation.

​
6. Gouvernance

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é :
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 dépendances et gouvernance pour la sémantique complète.

​
7. Faire évoluer

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

​
Limitations actuelles

  • Les plugins se chargent dans les sessions cloud, le Devin CLI 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.
  • Les Hooks sont actuellement exécutés au mieux et échouent en mode ouvert — un hook qui ne parvient pas à se charger ou à s’exécuter n’arrête pas la session — ne vous y fiez donc pas encore pour des garde-fous essentiels. Consultez la référence des hooks du CLI pour la configuration locale.
  • La gouvernance échoue en mode ouvert : si un manifeste géré ne peut pas être récupéré au démarrage de la session, les plugins de ce niveau ne sont pas installés et ses interdictions ne sont pas appliquées pour cette session.
  • Le contenu de plugin provenant d’un repo privé n’apparaît dans Customize que pour les organisations dont l’intégration Git peut accéder au repo ; ailleurs, il reste masqué jusqu’à ce que le repo soit autorisé dans Settings → Repositories.

​
En savoir plus