Les responsables et les demandes

Un déploiement sans responsable clair dérive vite : les demandes d’accès s’accumulent, les plafonds ne sont jamais revus, personne ne sait qui a activé tel connecteur. Avant de toucher à un réglage, désignez qui décide quoi, et organisez la façon dont les demandes arrivent.

Les rôles intégrés

Claude Enterprise propose des rôles avec des droits différents :

• Primary Owner : un seul par organisation. Il occupe une licence, peut être un compte de service non rattaché à une personne, et détient certains droits exclusifs, comme activer l’API de conformité ou créer une clé d’API d’analytique.
• Owner : gère l’organisation, y compris la facturation et les réglages de sécurité.
• Admin : administre au quotidien ; sur Enterprise, un Admin voit toutes les analyses sauf la dépense.
• User : utilise Claude, sans droits d’administration.
• Custom : un membre dont le rôle est réglé sur « Custom » n’a aucune permission par défaut ; tout ce qu’il peut faire vient des rôles personnalisés attribués à ses groupes (leçon 5).

Des droits d’administration sans faire de tout le monde un Owner

Les rôles personnalisés peuvent accorder des permissions d’administration ciblées — facturation, identité et accès, analytique, bibliothèques de skills et de plugins… — sans donner les pleins pouvoirs d’un Owner. C’est la bonne façon de répartir le travail :

• un responsable facturation avec la permission Billing (« Can manage ») pour les achats de crédits et les plafonds ;
• un responsable identité avec Identity & Access pour les groupes et les rôles ;
• dans chaque service, un référent qui suit la consommation de son équipe. Le guide de consommation d’Anthropic recommande précisément de nommer un « propriétaire de groupe » par département, avec un rôle qui donne Analytics (« Can view ») et éventuellement Billing (« Can view »), sans le rendre Owner ni Admin.

Organiser les demandes

Une fois Claude ouvert, les demandes arrivent : un nouveau connecteur, une skill à diffuser, un plafond à relever, l’accès à Claude Code pour une personne hors de l’équipe technique. Prévoyez dès le départ :

• un point d’entrée unique (un formulaire, un canal, une file de tickets) plutôt que des messages privés à l’administrateur ;
• un responsable par type de demande, aligné sur les décisions du carnet : accès, gouvernance, dépenses ;
• un critère de décision écrit : par exemple, un relèvement de plafond s’accorde après avoir regardé ce que produit la dépense du groupe (leçon 12), pas automatiquement ;
• une revue périodique : le guide de consommation conseille de revoir la consommation des groupes chaque semaine pendant le lancement, puis chaque mois.

Le cas d’Atelier Nova

Inès garde le rôle de Primary Owner sur un compte de service partagé avec la DSI, pour ne pas dépendre d’une personne. Elle nomme deux Owners (elle-même et le DSI), crée un rôle « Facturation » pour le contrôle de gestion, et un rôle « Référent » (Analytics en lecture) pour un référent par service : produit, ventes, support, fonctions support. Les demandes passent par un formulaire unique dans l’outil de tickets interne.

À reporter dans votre carnet : le nom du Primary Owner, la liste des Owners, les rôles d’administration ciblés et leurs titulaires, le point d’entrée des demandes.

À vous de jouer

Les responsables. Dans votre carnet, ajoutez une ligne par type de demande attendue (accès, connecteur, plafond, skill ou plugin) avec son responsable. Puis listez les personnes qui recevront des droits d’administration, et vérifiez pour chacune qu’un rôle personnalisé suffit, sans en faire un Owner.

Sources officielles : Owners and intake (Claude Academy) · Roles and permissions · Manage custom roles on Enterprise plans · Claude Enterprise consumption guide

Points clés à retenir

• Un seul Primary Owner, qui peut être un compte de service ; des Owners en nombre limité
• Les rôles personnalisés donnent des droits d’administration ciblés sans faire d’Owners
• Un référent par service, avec l’analytique en lecture, rapproche les décisions du terrain
• Un point d’entrée unique et un critère écrit pour chaque type de demande