Opérateurs
Administration de locataire pour les opérateurs
Pilotez la surface d'Accès de l'opérateur : choisissez la frontière du compte, puis gérez les membres, les permissions, les cibles d'espaces de travail, la politique de facturation, le SSO et les preuves d'intégration depuis un seul bureau géré par Console.
Dernière mise à jour
À quoi sert la surface d’Accès
La surface de l’opérateur sur /tenants s’intitule Opérations d’accès dans Console, et la zone de travail qu’elle contient est le Bureau des opérations client. C’est une seule route gérée par Console où les équipes de plateforme choisissent une frontière de compte une fois, puis exécutent toute la boucle de livraison : portée d’accès et d’identité, membres et permissions, routage des cibles d’espaces de travail, préparation de la facturation, environnements persistants, preuves Shared Drive et restitution d’usage (showback).
La même route présente une vue en libre-service aux administrateurs client afin qu’ils puissent confirmer leur accès, soumettre les détails SSO, traiter la liste de contrôle d’intégration et inviter leur équipe. Les libellés et les actions disponibles changent selon votre rôle : les opérateurs et administrateurs de plateforme voient le support inter-clients et le travail de configuration approuvé, tandis que les administrateurs client ne voient que leur propre compte.
Utilisez-la comme contrôle de lancement. Approuvez la frontière du compte, la porte de facturation, l’accès du locataire, le routage des cibles et le transfert d’usage avant qu’un client ne commence à créer des espaces de travail.
Choisissez d’abord la portée
Confirmez toujours le client facturable, le locataire et la portée des membres avant de changer quoi que ce soit. La plupart des actions sont à portée client et appliquent le client sélectionné lorsqu’un est présent. Sur un nouveau cluster, exécutez d’abord le démarrage (bootstrap) et la vérification de portée — il répond à qui vous êtes connecté, quel compte client vous gérez, où les espaces de travail s’exécuteront et si l’usage peut être attribué à ce client — avant de tester les flux ultérieurs d’espace de travail ou de facturation.
Si les libellés d’accès SSO sont vides, les pages ultérieures telles qu’Analytics peuvent ne pas savoir quelle portée client utiliser. Reconnectez-vous via SSO avant de tester la création d’espaces de travail.
Sous-onglets à travers le bureau
Le Bureau des opérations client regroupe son travail en sous-onglets le long du haut de la surface. Parcourez-les à peu près dans cet ordre lors d’un lancement.
| Sous-onglet | Ce que vous y faites |
|---|---|
| Overview | Confirmez la frontière active du client ou du locataire et accédez aux surfaces qui gèrent le support, la revue, les environnements, le stockage, la facturation et l’audit. |
| Customers | Enregistrements clients, politique de facturation, intégration et transfert d’API. |
| Members | La liste des membres du client et du locataire. |
| Permissions | Politique de fonctionnalités et de méta-permissions par adhésion. |
| Targets | Routage des espaces de travail et alias de modèles. |
| Onboarding | Liste de contrôle, configuration SSO, cycle de vie et historique des notifications. |
Les couloirs de l’Overview reflètent la boucle d’exploitation : accès client, changement revu, preuve QA, environnement candidat, promotion et revue de facturation. Les actions rapides de l’Overview ouvrent Customers, Members, CI & Review, Environments, Shared Drive, politique de facturation, Analytics et historique d’audit.
Disponibilité des actions (la carte CRUD)
Le badge carte CRUD indique quels chemins de création, de mise à jour et de suppression sont accessibles dans la session en cours, et pourquoi les autres ne le sont pas. Lisez-le quand une action semble manquer. Par exemple, il explique que les comptes client n’ont pas encore de route de suppression — déplacez plutôt le cycle de vie vers suspendu, désengagement (offboarding) ou clôturé — et que certaines actions sont réservées aux opérateurs car elles pilotent la facturation, l’attribution ou la frontière du compte.
Quelques entrées à connaître :
- Compte client — réservé aux opérateurs, car l’enregistrement du compte pilote la facturation, le cycle de vie et l’attribution. Les administrateurs client peuvent soumettre des données d’intégration mais ne peuvent pas modifier l’enregistrement facturable.
- Members — créer, mettre à jour et supprimer nécessitent des droits d’administrateur de locataire ; les routes à portée client appliquent le client sélectionné.
- Clés d’API Archibot — disponibles à l’étape de transfert au client. Les secrets bruts ne sont affichés qu’une seule fois.
- Notifications — les administrateurs client peuvent lire leur historique de notifications ; l’envoi reste réservé aux opérateurs.
Aide intégrée à l’application
Chaque panneau comporte un contrôle d’aide contextuelle. L’action Expliquer les opérations d’accès ouvre une boîte de dialogue qui reformule les quatre questions de configuration et un glossaire en langage clair : un compte client est l’entreprise facturable, un locataire est la part d’accès à Console pour cette entreprise, une cible d’espace de travail est le cluster d’exécution où s’exécutent les espaces de travail, et une clé d’API est la manière dont Archibot ou l’automatisation appelle l’API à portée client. La boîte de dialogue est un contexte en lecture seule ; sa fermeture vous ramène à la même portée. Utilisez-la quand vous n’êtes pas sûr qu’un libellé manquant ou une portée vide bloque un test ultérieur.
Onglets Customers et intégration
Ouvrez le sous-onglet Customers pour traiter un seul compte. Chaque enregistrement client comporte sa propre bande d’onglets :
- Profile — identité du compte.
- Plan — cycle de vie, valeurs par défaut et niveau de service.
- Onboarding — liste de contrôle et historique du cycle de vie.
- Billing — revue de facturation et politique tarifaire.
- API — accès à l’API à portée client.
L’onglet Onboarding ouvre ses propres sous-onglets : Details (contexte du compte et contacts), SSO setup (partager ou revoir les métadonnées de l’IdP), Checklist (l’enregistrement de lancement partagé), Lifecycle (historique des états) et Notifications (historique durable des notifications). Le statut et les notes de la liste de contrôle deviennent l’enregistrement de lancement partagé au lieu d’e-mails ou de chats par canaux parallèles.
Membres et permissions
Sur le sous-onglet Members, les opérateurs peuvent inviter, créer, mettre à jour, transférer, désactiver et supprimer des membres au sein du locataire sélectionné. (Les administrateurs client peuvent inviter, créer, mettre à jour, désactiver et supprimer, mais pas transférer.) Utilisez l’administrateur de locataire avec parcimonie — la plupart des utilisateurs devraient être des membres du locataire à moins qu’ils ne gèrent les invitations ou les preuves d’intégration.
Le sous-onglet Permissions ouvre l’éditeur de Politiques de permissions, qui définit l’accès dérivé du rôle, les permissions de fonctionnalités personnalisées et les méta-permissions pour chaque adhésion dans la portée sélectionnée.

Travaillez l’éditeur en trois mouvements :
- Utilisez Contrôles de politique et Filtres et recherche pour restreindre la liste, puis choisissez un membre. Les tuiles de métriques (Modèles de rôle, Politiques personnalisées, Octrois meta, Administrateurs) montrent comment la portée est répartie.
- Dans l’Éditeur de politique de membre, choisissez le Mode de politique. Modèle de rôle calcule les permissions effectives à partir du rôle et du statut sélectionnés ; Octrois personnalisés enregistre directement les tableaux de fonctionnalités et de méta-permissions sur l’adhésion.
- Appliquez un Octroi prédéfini comme paquet de départ, ajustez les octrois individuels dans la matrice de fonctionnalités, puis choisissez Enregistrer la politique. Utilisez Effacer la sélection pour revenir en arrière sans enregistrer.
Les octrois prédéfinis fournissent un paquet connu que vous pouvez ajuster :
- Administrateur de locataire — administration complète du locataire et du client avec délégation contrôlée.
- Responsable d’espace de travail — cycle de vie des espaces de travail, écriture sur Shared Drive et gestion de la revue CI.
- Gestionnaire de facturation — Analytics, factures, plafonds de dépenses et tarification des ressources sans contrôle des espaces de travail.
- Auditeur — visibilité en lecture seule sur l’ensemble des opérations plus l’autorité d’export d’audit.
Les méta-permissions contrôlent qui peut déléguer des rôles, accorder ou révoquer des permissions, approuver des exceptions, gérer des modèles de politique, approuver l’accès au support, exporter des preuves d’audit ou approuver une élévation d’urgence (break-glass). N’accordez-les qu’aux adhésions qui administrent la politique d’accès. Chaque octroi de fonctionnalité est enregistré par ID de permission stable afin que l’application future du backend consomme la même politique.
Cibles d’espaces de travail et valeurs par défaut
Create Workspace ne peut router les espaces de travail pour un compte qu’une fois qu’une cible d’espace de travail est attachée, donc attachez une cible avant la création d’espaces de travail par le client. Sur le sous-onglet Targets, vous confirmez l’URL d’exécution de l’espace de travail, le mode d’authentification de la cible, les alias de modèles et les fournisseurs Git pris en charge. Les alias de modèles maintiennent stables les noms visibles par le client ; les champs de jeton de service sur les cibles restent réservés aux opérateurs.
Utilisez Valeurs par défaut de l’espace de travail pour définir les valeurs au niveau de l’organisation avec lesquelles Create Workspace devrait démarrer pour ce client.
Facturation et tarification des ressources
L’onglet Billing couvre la préparation de la facturation, le transfert vers Stripe et la politique tarifaire des ressources. L’état de facturation est la porte de création d’espace de travail : enregistrez le rail de paiement et marquez le compte comme essai approuvé ou vérifié avant la création d’espaces de travail par le client.

La Politique tarifaire des ressources superpose les valeurs par défaut du déploiement pour la comptabilité Analytics et des dépassements d’un seul client. Le panneau indique la source de la politique, combien de clés sont explicitement définies pour le client et les clés par défaut de base issues de la configuration de déploiement. Ne remplacez les conditions du client ici que lorsqu’un devis, un plan de service ou un accord d’entreprise utilise des allocations ou des tarifs différents, puis choisissez Enregistrer la politique.
Les préréglages tarifaires estimés fournissent des points de départ de lancement que vous pouvez ajuster avant de chiffrer :
- Pilote — allocation initiale pour une équipe d’implémentation validant CI, revue, QA et un petit Shared Drive.
- Équipe — allocation de travail pour une équipe client active avec des cycles répétés de revue/QA et un usage modéré de Shared Drive.
- Entreprise — allocation plus importante pour la planification d’un déploiement multi-équipes, un QA intensif et un stockage d’environnement persistant plus important.
Utilisez Partir des valeurs par défaut du déploiement pour réinitialiser l’éditeur. Enregistrez le libellé de version du modèle tarifaire pour le devis ou la révision de politique. Stripe reste la source de référence pour les factures, les paiements et les enregistrements de revenus — les entrées tarifaires de Console sont des conditions d’opérateur ou de client, pas des charges utiles de fournisseur, et les événements de facture Stripe mettent à jour l’historique des paiements automatiquement.
Configuration SSO
Les administrateurs client soumettent le type d’IdP, les domaines, les claims, les groupes, les URL de callback et les utilisateurs de test sur l’onglet SSO setup afin qu’ISM puisse mapper l’accès en toute sécurité. Pour OIDC, collectez les URL de discovery ; pour SAML, collectez les URL de métadonnées et les détails de validation de callback. Les opérateurs revoient les métadonnées soumises sur le même onglet. Les libellés d’accès SSO proviennent du fournisseur d’identité et déterminent quel aperçu, quelles actions de configuration et quelle portée client Console expose.
Gardez les deux paquets de notes séparés
- Détails soumis par le client et Contexte de lancement ISM sont visibles par le client. Utilisez-les pour le contexte que le client peut revoir avec ISM.
- Notes internes de l’opérateur sont réservées à ISM et ne devraient pas apparaître dans les réponses d’intégration à portée client.
Dans chaque champ — visible par le client ou interne — gardez à l’écart les identifiants, les détails de paiement, les clés privées et les liens d’invitation. Le cycle de vie d’intégration et l’historique des notifications sont des enregistrements durables ; l’envoi d’e-mails reste verrouillé derrière l’expéditeur de notifications.
Guides connexes
- Rôles d’accès pour les frontières de rôle que cette surface applique.
- Configuration de l’administrateur client pour le parcours en libre-service côté client.
- Centre d’opérations pour les signaux en direct de CI, QA, bots et capacité.
- Environnements persistants et CI Review pour les couloirs de la revue à la promotion.
- Usage et facturation pour la façon dont la restitution et les enregistrements Stripe rejoignent la politique tarifaire que vous définissez ici.
Terminé quand
- La portée client et locataire sélectionnée est correcte avant tout changement.
- Le contexte visible par le client et les notes internes de l'opérateur sont conservés dans leurs propres paquets.
- Une cible d'espace de travail est attachée avant qu'un client ne crée des espaces de travail.
- Les identifiants, les détails de paiement, les clés privées et les liens d'invitation restent en dehors de chaque champ.