Gouverner les personnalisations

Il s'agit de la troisième des cinq décisions, la Gouvernance. Vous avez décidé de ce à quoi Claude peut accéder. Vous allez maintenant découvrir les personnalisations qui modifient le fonctionnement de Claude, et comment ces changements peuvent se propager dans toute votre organisation. Les Skills, les configurations partagées et les consignes permanentes que votre organisation donne à Claude se retrouvent tous ici, car ils répondent à une même question à différents niveaux : dans quelle mesure ce qu'un membre configure peut-il atteindre les autres ?

Personnalisations des membres et instructions d'organisation

Cette leçon porte sur trois types de personnalisations. Les sections ci-dessous détaillent chacune d'elles, puis abordent la posture (la règle de votre organisation déterminant qui peut créer, partager et faire évoluer ces personnalisations) qui régit leur portée de diffusion.

1. Skills et plugins

   Un skill est un dossier d'instructions, de scripts et de ressources que Claude charge lorsqu'une tâche l'exige. En pratique, il encapsule un flux de travail afin que Claude l'exécute de la même manière à chaque fois : un premier examen de contrat que votre équipe juridique effectue selon son propre guide de référence, un formateur de résumés qui rédige dans votre style, ou un post-mortem d'incident selon votre modèle. Avec un skill, Claude connaît déjà vos conventions, de sorte que personne n'a besoin de les réexpliquer à chaque conversation.

   Un plugin regroupe des skills avec d'autres composants (connecteurs, sous-agents) afin qu'une boîte à outils complète s'installe en une seule fois ; la même posture s'applique aux skills et aux plugins, c'est pourquoi le reste de cette leçon emploie le terme « personnalisations » pour désigner cette famille. Un plugin ne peut pas donner à un membre un connecteur ou une capacité que ses groupes n'incluent pas déjà ; il fonctionne avec ce qui est déjà en place.

2. Projets

   Un projet est un espace de travail doté de son propre contexte et de ses propres fichiers, qui persistent pour tous ceux qui y travaillent. Le partage des projets détermine si un projet créé par un membre peut être partagé avec d'autres personnes de votre organisation, et dans quelle mesure. Désactiver « Projets publics » rend privé tout projet public, de sorte que toute personne qui n'y avait pas été ajoutée perd l'accès. Personne ne peut rendre un nouveau projet public, bien que le partage avec des personnes ou des groupes nommés continue. Le partage d'un projet avec un groupe est en version bêta, de sorte que la granularité que vous observez peut différer de celle d'une autre organisation ; le paramètre lui-même constitue le choix de posture.

3. Instructions d'organisation

   Les instructions d'organisation sont un bloc de consignes inclus dans les conversations de vos membres avec Claude sur les surfaces qui le prennent en charge : le contexte permanent de votre organisation. Utilisez-les pour donner à Claude des faits et des consignes permanents : qui est votre organisation et comment elle est structurée, le ton à adopter pour les écrits destinés aux clients, ou une règle valable pour chaque session, comme citer le document source chaque fois que Claude cite du contenu interne. La version de Pluto apparaît plus loin dans cette leçon.

Pourquoi les personnalisations ont besoin d'une gouvernance

La possibilité de partager une personnalisation apporte une réelle valeur ajoutée à l'expérience des membres qui travaillent avec Claude. Un skill créé par un membre peut codifier un flux de travail qu'une équipe exécute déjà, de sorte qu'il se diffuse sous une forme plus uniforme, souvent plus rapide et de meilleure qualité. Les membres peuvent également créer des flux de travail qui n'existaient pas avant Claude et les déployer à l'échelle de votre organisation.

Le revers de la médaille, c'est la prolifération : sans gouvernance, votre organisation pourrait se retrouver avec des dizaines de skills quasi identiques, des flux de travail non testés se propageant à des équipes qui présument qu'ils ont été examinés, ou des données sensibles rendues accessibles en partageant un projet à l'échelle de l'organisation. La gouvernance est ce qui vous permet de maîtriser délibérément cette diffusion, et décider à qui vous autorisez la création et le déploiement de personnalisations en est le cœur.

La gouvernance se résume à trois questions :

1. Que sont autorisées à faire les personnalisations lorsqu'elles s'exécutent ?
2. Qui peut les créer, et qui peut les utiliser ?
3. Comment passent-elles du membre qui les a créées à tous les autres ?

Ce que les personnalisations peuvent faire lorsqu'elles s'exécutent

Ce qu'un skill est autorisé à faire lorsqu'il s'exécute dépend des capacités : certains skills exécutent du code, d'autres effectuent des recherches sur le web, d'autres encore lisent des fichiers. Un skill ne s'exécute que lorsque la capacité dont il a besoin est activée ; ainsi, lorsque vous activez une capacité, vérifiez les deux commutateurs ensemble : la capacité et les skills de vos équipes qui en dépendent. Les skills nécessitent l'exécution de code : dans les paramètres de l'organisation, vous devez activer le paramètre Exécution de code et création de fichiers dans le cloud (certaines consoles l'affichent encore sous le nom Exécution de code et création de fichiers), ainsi que Skills, avant que les membres puissent utiliser un skill. Si vous laissez désactivée, à l'échelle de l'organisation, une capacité dont dépend un skill, le skill que votre équipe financière souhaite (par exemple, un synthétiseur de recherches) ne sera pas du tout disponible.

Qui peut les créer et les utiliser

La possibilité pour les membres de créer et d'utiliser des skills est un paramètre à l'échelle de l'organisation. C'est l'un des rares paramètres qui se situent au-dessus de vos groupes plutôt que d'être rattachés à l'un d'eux, bien que la capacité Créer des skills d'un rôle personnalisé détermine qui peut créer, et ses capacités de partage déterminent qui peut partager. La distribution peut toutefois être rattachée à un groupe : un skill intégré dans un plugin peut être attribué à un groupe spécifique, de sorte que seul ce groupe le voit.

Comment elles se diffusent à tous les autres

La manière dont un skill se diffuse est régie par quatre contrôles de distribution distincts, qui constituent votre posture :

1. Provisionnement par le propriétaire : un propriétaire télécharge un skill et celui-ci apparaît dans la liste de skills de chaque membre, activé par défaut (les membres peuvent le désactiver pour eux-mêmes). Seuls les propriétaires, ainsi que toute personne dont le rôle a le paramètre Bibliothèques défini sur « Peut gérer », peuvent ajouter ou supprimer ces skills.
2. Partage de skills (activé par défaut, sauf si votre organisation a défini une préférence pour les skills) : les membres partagent un skill, ou un plugin qu'ils ont créé, directement avec des collègues spécifiques, qui peuvent l'utiliser mais pas le modifier.
3. Partage avec des groupes (désactivé par défaut) : les membres partagent un skill ou un plugin avec un groupe entier pour lequel « Partager des ressources avec ce groupe » est activé.
4. Publication (« Désactivée », « Nécessite une validation » ou « Ouverte ») : les membres soumettent un skill ou un plugin à la bibliothèque de l'organisation, où il peut atteindre l'ensemble de l'organisation (lors de la validation, le validateur choisit si tout le monde ou des groupes spécifiques y ont accès). Avec « Désactivée », les membres ne peuvent pas soumettre, bien que les propriétaires puissent toujours ajouter directement des skills pour l'ensemble de l'organisation. Avec « Nécessite une validation », chaque soumission et chaque version ultérieure attend qu'un propriétaire, ou toute personne dont le rôle a le paramètre Bibliothèques défini sur « Peut gérer », l'approuve ; personne ne peut approuver sa propre soumission. Avec « Ouverte », les soumissions peuvent être publiées sans validation. Si personne dans votre organisation n'a choisi de valeur pour la Publication, une valeur par défaut s'applique, et elle n'est pas la même pour toutes les organisations, vérifiez donc laquelle s'applique à vous.

La gouvernance de Pluto

Pluto applique une posture mixte : les membres de la plupart des groupes créent librement et partagent au sein de leur groupe, et tout ce qui est destiné à aller au-delà du groupe passe par un validateur désigné dans ce groupe ; Payments & Trust applique une posture plus stricte, de sorte que rien de ce qui y est créé n'est partagé tant que ce n'est pas approuvé (validation préalable), une règle que Pluto fait respecter via son validateur et sa politique ; un rôle personnalisé peut également désactiver le partage de skills et le partage de projets pour les membres d'un groupe, si vous souhaitez que le produit porte une partie d'une règle de ce type. Les instructions d'organisation de Pluto nomment Pluto, ses cinq unités commerciales et son style maison pour les écrits destinés aux clients. Elles se lisent ainsi : « Vous assistez Pluto, une fintech comptant cinq unités commerciales : Retail, B2B, Payments & Trust, Platform et Ops. Les écrits destinés aux clients sont simples et courts, dans le style maison de Pluto. »

Le widget interactif ci-dessous suit un skill tout au long du cycle création-validation-publication : basculez entre les postures — la création ouverte avec diffusion validée de Pluto pour la plupart des groupes, la validation préalable pour Payments & Trust — et observez où se situe le point de contrôle.

1 · Votre décision

Votre posture de personnalisation : avec quelle liberté les membres créent-ils et partagent-ils des skills, des plugins et des projets, et une seule posture couvre-t-elle l'ensemble de l'organisation ?

2 · Les choix qui s'offrent à vous

Il n'existe pas de posture unique partagée par la plupart des entreprises ici ; la posture reflète la manière dont votre entreprise gère déjà les outils que ses propres collaborateurs créent. Trois postures couvrent la plupart des cas :

3 · Si vous modifiez cela plus tard

La plupart des paramètres de posture sont librement réversibles : modifiez-en un et il s'applique à partir de ce moment, sans travail d'annulation. Les deux directions ne sont toutefois pas équivalentes. Assouplir est sans conséquence — autorisez davantage de création et de partage, et les membres gagnent en marge de manœuvre. Resserrer est la direction à aborder avec prudence, et deux paramètres se comportent de manière opposée. Désactiver « Projets publics » affecte ce qui existe déjà : les projets publics deviennent privés, et ils restent privés si vous réactivez le paramètre. Un paramètre de Publication plus strict ne supprime rien de ce qui est déjà publié, qui reste dans la bibliothèque de l'organisation jusqu'à ce qu'un propriétaire le supprime ; examinez donc les skills fortement utilisés au regard de la nouvelle règle et supprimez ceux qui ne la respectent pas.

Ressources de mise en œuvre

Une fois votre décision prise, les paramètres de création et de partage, l'exécution de code, le partage de projets et les instructions d'organisation se trouvent dans les paramètres de l'organisation.

• Que sont les skills ? : ce qu'est un skill et ce qu'il fait du point de vue du membre, avant de définir la posture qui le régit.
• Provisionner et gérer les skills pour votre organisation : création, activation et gouvernance des skills, y compris les paramètres de partage à l'échelle de l'organisation et de Publication que vous définissez ici.
• Que sont les projets ? : ce qu'est un projet et ce qu'il contient, afin que vous puissiez décider de l'étendue de son partage.
• Gérer la visibilité et le partage des projets : les paramètres de partage des projets qui se trouvent dans les paramètres de l'organisation.
• Contrôler le partage des projets pour votre organisation : ce que fait la désactivation de « Partager les projets » ou « Projets publics », et comment définir le partage des projets par rôle.
• Définir les instructions d'organisation : où se trouvent les instructions, qui peut les définir, et la limite de caractères.
• Guide de consommation Claude Enterprise : la section sur les instructions d'organisation : les consignes permanentes que porte chaque conversation.
• Déployer des flux de travail à grande échelle avec Claude Cowork dans votre organisation : à quoi ressemble le partage à grande échelle dans la pratique, tiré de la bibliothèque de tutoriels Claude.

Activité de la leçon

Ce qu'il faut apporter à votre responsable de la gouvernance et à votre responsable de la sécurité : la posture que vous avez choisie, le validateur des personnalisations avant leur diffusion à l'échelle de l'organisation et pour quels groupes, et si l'exécution de code reste activée et pour qui. Si la posture n'est pas la vôtre seule à définir, voici le dossier à leur transmettre.

Avant d'enregistrer une posture, vérifiez-la à l'aune de trois questions auxquelles vous pouvez déjà répondre :

1. Laquelle des trois postures correspond à la manière dont votre entreprise gère aujourd'hui les outils que ses propres collaborateurs créent, et un groupe réglementé a-t-il besoin d'une posture plus stricte que les autres ?
2. Si votre posture comporte un point de contrôle de validation, qui est le validateur, et pour quels groupes ?
3. Que devraient dire vos instructions d'organisation : les deux ou trois lignes que chaque conversation devrait porter sur qui vous êtes et les normes que Claude devrait suivre ?

→ Consignez cela dans le compagnon de travail, section Leçon 8.

Et ensuite ?

Les membres peuvent désormais créer et partager dans les limites que vous avez définies. Le module suivant, Dépenses, aborde le coût de cette activité : où se situent les plafonds de dépenses dans votre organisation, et qui en est responsable lorsqu'un membre les atteint.