Skip to main content

Que sont les plugins ?

Un plugin regroupe des skills — et éventuellement des règles, des hooks, des serveurs MCP et des subagents — afin de pouvoir être installé et réutilisé comme une seule unité. Consultez la référence des plugins pour connaître le format de fichier et ce qu’un plugin peut inclure. Les plugins constituent la couche de personnalisation partagée entre les sessions Devin dans le cloud, le Devin CLI et Devin Desktop : installez un plugin une seule fois et ses skills deviennent disponibles sous forme de commandes /<plugin>:<skill> partout où vous utilisez Devin. Les plugins peuvent être installés à trois niveaux : Cette page couvre le volet application web : la page Customize, l’installation à chaque périmètre, l’indexation, les MCP et les manifestes gérés qui sous-tendent le tout.

La page Customize

Les plugins se trouvent sur la page Customize, accessible depuis l’élément Customize de la sidebar (elle remplace les anciennes pages Settings → Plugins, Settings → Marketplace et Settings → Connections → MCP servers ; les anciens liens sont redirigés). Elle comporte cinq onglets :
  • Plugins — tout ce qui est installé, regroupé par périmètre, ainsi que Browse marketplace pour en installer d’autres.
  • Skills — les skills que Devin charge à la demande, depuis les plugins installés et vos dépôts.
  • MCPs — les MCP servers qui fournissent à Devin des tools au-delà de ceux intégrés. Voir MCPs ci-dessous.
  • Hooks — des commandes qui s’exécutent automatiquement à certains moments d’une session.
  • Rules — des règles permanentes que Devin suit dans chaque session.
Utilisez les onglets de périmètre pour choisir Personal, Organization ou Enterprise, selon vos accès. Chaque périmètre affiche son contenu effectif : ce qui s’applique réellement une fois la gouvernance appliquée. Pour modifier du contenu au niveau du dépôt (skills, règles et plugins déclarés dans le fichier .devin/config.json d’un repo), modifiez les fichiers du dépôt. Qui peut modifier quoi :
  • Personal — n’importe qui, pour son propre périmètre.
  • Organization — les members disposant d’un accès aux Organization Settings.
  • Enterprise — les members disposant d’un accès aux enterprise settings.
Cliquez sur un plugin pour ouvrir sa fiche de détails : ses skills, MCPs, hooks, règles et subagents ; la ref suivie ou le SHA pinné et le chemin ; les périmètres dans lesquels il est installé et ce qui le requiert ; ses autorisations ; et — si vous disposez des droits — les actions pour connecter ses MCPs, modifier ce qu’il requiert, le désinstaller ou (dans le cas d’un plugin uploadé) le supprimer.

Installer des plugins

Depuis le marketplace

Cliquez sur Browse marketplace dans l’onglet Plugins. Le marketplace se présente comme une liste unique combinant le marketplace officiel de Devin (CognitionAI/devin-marketplace, généralement un plugin par intégration comme Linear, Notion, Datadog ou Snowflake) et les plugins ajoutés par votre organisation ou votre entreprise. Chaque carte propose un menu d’installation listant tous les périmètres dans lesquels vous pouvez écrire, et indique où le plugin est déjà installé (« Installed for me », « Installed at organization », etc.). Avant la première installation d’un plugin, Devin affiche un avis de sécurité : l’installation autorise Devin à exécuter les règles, hooks et skills du plugin (et, pour un plugin doté de MCP servers, à accéder à des données externes par leur intermédiaire). Ne poursuivez donc que si vous faites confiance au plugin et que vous avez vérifié sa source. Les plugins du marketplace officiel sont signalés comme tels. Après l’installation, un toast confirme le périmètre et — si le plugin fournit un MCP server nécessitant des credentials ou une autorisation — propose Connect MCP pour terminer la configuration sans attendre. Les Enterprise admins peuvent masquer le marketplace officiel pour toutes les orgs (interrupteur Show official marketplace plugins) et définir quels MCP servers du marketplace sont visibles par les organisations sous Marketplace availability.

Depuis un dépôt, un .zip ou l’éditeur

Le menu Add plugin de l’onglet Plugins prend en charge trois autres sources, toutes installables sur n’importe quel périmètre pour lequel vous disposez de droits d’écriture : Les plugins téléversés ou créés peuvent être modifiés par la suite depuis leur fiche de détails. En supprimer un efface définitivement ses fichiers : il n’en existe aucune autre copie. Ne placez pas de secrets dans les fichiers de plugin ; utilisez plutôt des références de secrets.

Depuis la CLI

devin plugins install <source> ajoute par défaut le plugin à votre périmètre personnel, afin qu’il vous suive dans vos cloud sessions et sur vos autres appareils. Utilisez --local pour l’installer uniquement sur la machine actuelle. Consultez les commandes CLI.

Laisser Devin s’en charger

Dans une cloud session, vous pouvez demander à Devin d’enregistrer un élément en tant que skill, rule, hook ou MCP server personnel, ou encore d’installer un plugin à votre place. Devin propose alors la modification sous forme de carte que vous approuvez ou refusez ; les modifications approuvées sont ajoutées à votre périmètre personnel et s’appliquent aux sessions ultérieures.

Comment les plugins parviennent aux sessions (synchronisation cloud ↔ local)

Chaque périmètre repose sur un managed manifeste stocké dans Devin Cloud (voir Le manifeste). Une installation, où qu’elle soit effectuée, écrit dans ce manifeste, et chaque interface le lit :
  • Les cloud sessions récupèrent les manifestes enterprise, organization et personnel au démarrage, puis installent les plugins correspondants sur la machine de la session, en plus des plugins déclarés par les dépôts qu’elles clonent.
  • Le Devin CLI et Devin Desktop récupèrent les mêmes manifestes lorsque vous êtes connecté : un plugin installé depuis le web apparaît donc sur votre laptop, et un devin plugins install lancé sur votre laptop se retrouve dans votre prochaine cloud session. Les plugins provenant de repos privés sont récupérés avec vos credentials git locaux : vous devez donc avoir vous-même accès au repo. Une enterprise peut désactiver complètement les plugins CLI (Devin CLI plugins dans les enterprise settings).
  • Les utilisateurs solo (sans organization) ne disposent que d’un périmètre personnel.
Les sessions en cours conservent ce qu’elles ont chargé au démarrage ; les modifications ne s’appliquent qu’à la prochaine session. L’installation d’un plugin et l’authentification MCP sont deux étapes distinctes. Connectez les MCP cloud depuis Customize → MCPs ; pour le serveur OAuth d’un plugin exécuté dans le CLI, utilisez devin mcp login. Synchroniser un plugin ne signifie pas que tous les appareils partagent les mêmes credentials.

Indexation

Devin conserve un index des plugins de chaque périmètre : il clone chaque source de plugin, lit son manifeste et son contenu, résout les dépendances et applique la gouvernance. La page Customize affiche le résultat de l’indexation — les plugins, leurs skills, MCP, hooks et règles, ainsi que tout élément bloqué par une politique — et la ligne de statut indique quand chaque périmètre a été indexé pour la dernière fois.
  • Ce qui la déclenche — installer, supprimer ou modifier un plugin met automatiquement une réindexation en file d’attente. Utilisez Plugin settings → Reindex plugins pour actualiser l’index après avoir poussé des modifications vers le dépôt source d’un plugin.
  • Pendant l’exécution — une exécution peut être planifiée, en file d’attente, en cours de démarrage ou en cours d’indexation. Les réindexations fréquentes sont espacées, et l’enregistrement des bundles importés peut mettre un court instant à être mis en file d’attente. Les MCP de plugins peuvent être connectés dès que leur configuration a été indexée.
  • Résultats — ouvrez Plugin settings (le menu en forme d’engrenage) pour consulter la date de dernière indexation et les éventuels problèmes. Une actualisation en échec peut laisser visible le dernier résultat réussi : la présence d’un plugin dans la liste ne prouve pas que la dernière actualisation a réussi.
  • Accès au dépôt — le contenu de plugin indexé depuis un dépôt n’est affiché que dans une organisation ayant accès à ce dépôt via son intégration Git. À défaut, le contenu du périmètre est retenu et accompagné de la mention Plugin repos unauthorized ; accordez l’accès au dépôt dans Settings → Repositories. La gouvernance issue d’un périmètre retenu (ses interdictions) continue de s’appliquer.
  • Politique réseau — l’indexation s’exécute sur une machine qui hérite de la politique réseau de session de votre organisation ; les sources de plugins doivent donc y être accessibles.
Les sessions, elles, n’attendent pas l’index : elles récupèrent et installent les plugins directement au démarrage.

Résoudre les problèmes d’indexation

  1. Ouvrez Customize → Plugins dans l’organization où vous avez besoin du plugin. Sélectionnez son périmètre Personal, Organization ou Enterprise, puis ouvrez Plugin settings pour lire le problème ainsi que le plugin ou le périmètre qu’il désigne.
  2. Si une exécution est planifiée, en file d’attente, en cours de démarrage ou en cours d’indexation, laissez-la se terminer. Si le plugin n’a jamais été indexé, ou si sa source a changé depuis le dernier index, choisissez Reindex plugins.
  3. Pour une exécution en échec ou un contenu manquant, appliquez le correctif correspondant ci-dessous. Enregistrez ou committez la correction, puis choisissez Reindex plugins et vérifiez de nouveau le résultat. Les modifications d’un manifeste partagé ou des autorisations de dépôt peuvent nécessiter l’intervention d’un admin.
Une fois l’indexation réussie, ouvrez les détails du plugin et vérifiez que les skills, règles, hooks ou MCP attendus apparaissent bien. Si un MCP nécessite encore une autorisation, terminez sa connexion. Pour utiliser un contenu de plugin modifié, démarrez une nouvelle session. Pour une installation CLI obsolète, utilisez devin plugins update ; une réindexation dans Customize actualise la liste web. Une installation réalisée avec --local reste sur cet appareil. Si l’indexation échoue de manière répétée, ou si une exécution reste en file d’attente ou en cours d’indexation sans progresser, contactez le support. Indiquez l’organization et le périmètre, la source et la ref du plugin, la date du dernier indexation, l’erreur exacte et une capture d’écran du problème.

MCPs

Les MCP servers se gèrent depuis l’onglet MCPs de Customize, pour ces trois mêmes périmètres. Cet onglet comporte deux types d’entrées :
  • From plugins — les MCP servers déclarés par un plugin installé. Le plugin détient les paramètres de connexion (URL, transport, credentials requis), affichés en lecture seule ; vous pouvez néanmoins l’activer, le désactiver, le connecter ou le désinstaller. La plupart des plugins officiels du marketplace se résument à un seul MCP server, accompagné éventuellement de skills.
  • Standalone — les MCP servers installés indépendamment : serveurs personnalisés (Add custom MCP) et serveurs installés depuis l’ancien MCP marketplace, toujours accessible depuis l’onglet.
Connexion. Un MCP de plugin qui nécessite une API key ouvre une fiche Connect avec ses secrets prêts à renseigner ; s’il utilise OAuth, il ouvre le flux d’autorisation du provider ; s’il ne requiert ni l’un ni l’autre, il est prêt dès l’installation du plugin. Connectez-le depuis le toast d’installation, depuis la fiche de détails du plugin ou depuis la ligne du MCP. Connexions partagées ou par member. Pour un MCP OAuth installé au périmètre organization ou enterprise, le paramètre Access du serveur détermine le mode de partage de la connexion : l’accès Organization correspond à une connexion unique partagée par tous les utilisateurs du périmètre — utilisez un service account, et non un compte personnel — tandis que l’accès Personal amène chaque member à autoriser son propre compte. Pour les serveurs dépourvus d’accès par member, installez le plugin (ou le MCP) au périmètre personnel lorsque chaque member a besoin de ses propres credentials. Si les members connectent le même MCP du marketplace un par un, un admin peut l’installer une seule fois pour l’organization : les plugins qui le déclarent utiliseront cette connexion. MCPs enterprise. Les enterprise admins configurent un serveur une seule fois — y compris un bundle de certificats d’autorité de certification privée pour le trafic MCP routé via le réseau du client — et choisissent quelles organizations en bénéficient. L’installation du même serveur par une organization prévaut sur celle de l’enterprise. Pour les types de transport, les champs des serveurs personnalisés et les notes de configuration propres à chaque serveur, consultez MCP servers.

Le manifeste

Derrière chaque périmètre se trouve un managed manifest — un document JSON comportant trois listes. L’interface Customize le modifie pour vous ; Plugin settings (roue dentée) → Edit manifest, dans l’onglet Plugins, y donne accès directement :
  • requiredPlugins — installés pour tous les utilisateurs du périmètre (récursivement, y compris tous les plugins dont ils dépendent). L’installation depuis l’UI ajoute une entrée ici.
  • 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.
Le manifeste est stocké tel quel ; l’agent valide la source complète au moment de l’installation. Consultez la référence des plugins pour connaître les formes de source que peut prendre chaque entrée et la sémantique complète des dépendances et de la gouvernance.

Gouvernance

Les trois listes constituent le langage de politique à chaque niveau — entreprise, organisation, dépôt (.devin/config.json) et personnel — et l’autorité la plus élevée l’emporte : une entreprise peut imposer un plugin qu’aucune organisation, aucun repo ni aucun utilisateur ne peut retirer, et en interdire un qu’aucun niveau inférieur ne peut réintroduire. Un plugin bloqué par une politique apparaît sous Installed but blocked dans l’onglet Plugins, et ses skills sont ignorés au démarrage de la session, accompagnés d’un avertissement indiquant le niveau à l’origine de l’interdiction. Pour restreindre une entreprise à un ensemble approuvé, interdisez "*" et listez les plugins approuvés (ainsi que leurs dependencies) dans requiredPlugins/optionalPlugins ; voir Set up your plugin ecosystem pour un exemple concret et inheritance and levels pour l’ensemble des règles.

Périmètre et héritage

  • Les comptes autonomes disposent d’un manifeste de compte (intitulé Organization dans Customize), auquel s’ajoute le manifeste personnel de chaque membre.
  • Les entreprises disposent d’un manifeste d’entreprise hérité par chaque organisation enfant, puis d’un manifeste par organisation au niveau inférieur, et enfin des manifestes personnels.

Déploiement des mises à jour

  • Les modifications du manifeste (installations, suppressions, modifications du manifeste) s’appliquent à la session suivante, sur toutes les interfaces.
  • Les modifications du contenu d’un plugin — les fusions dans la branche suivie par un plugin sont répercutées automatiquement sur les nouvelles sessions (les cloud sessions les récupèrent au démarrage ; en CLI, la mise à jour se fait avec devin plugins update). Customize affiche le nouveau contenu après la prochaine exécution d’indexation — cliquez sur Reindex plugins pour le récupérer 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.

Épingler un plugin

Un plugin déclaré sous la forme "owner/repo" (ou avec un ref) suit une branche ou un tag : un même manifeste peut donc pointer vers des contenus différents au fil du temps. Customize signale ces entrées comme Plugin source not pinned. Pour figer un plugin sur un contenu précis, utilisez la forme objet avec un sha :
Un plugin épinglé ne change jamais tant que vous ne modifiez pas le SHA. ref (une branche ou un tag) et sha s’excluent mutuellement : une entrée ne peut pas définir les deux. Les mêmes champs fonctionnent avec les formes de source url et git-subdir. Les plugins téléversés sont toujours épinglés au contenu que vous avez téléversé. Si deux périmètres épinglent le même plugin sur des SHA différents, l’index signale un conflit d’épinglage.

Variables d’environnement des plugins

Ajoutez env à une entrée requiredPlugins ou optionalPlugins pour configurer des hooks de commande dans les sessions cloud. Utilisez Devin Secrets pour les identifiants ; les autres valeurs peuvent être des chaînes littérales.
Démarrez une nouvelle session cloud pour appliquer les modifications. Les dépendances nécessitent leur propre entrée dans le manifeste et env.

Références prises en charge

Le secret doit être accessible depuis la session. Pour un secret clé-valeur existant, ajoutez /ENTRY, par exemple secret:org:AWS_CREDS/ACCESS_KEY_ID. Les configurations MCP des plugins référencent les secrets sous la forme ${NAME} ; les members fournissent les valeurs depuis la fiche de détails du server, et toute valeur littérale inscrite dans la configuration est supprimée.

En savoir plus