Skip to main content
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 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 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 les plugins dans l’application web : manifestes gérés, périmètres et importations.

​
Où les configurer

Accédez à Settings → Resources → Plugins. 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 — 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.
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.

​
Ajouter vos propres plugins

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

​
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 → Resources → Plugins) 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.

​
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 la configuration de plugin au niveau du repo et de l’utilisateur. Consultez les niveaux et l’héritage pour les autres niveaux et les règles d’autorité.

​
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