archi bot Documentation produit

Cette traduction est générée automatiquement (bêta). Le guide en anglais fait foi.

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.

Opérateurs de plateformeAdministrateurs de plateformeAdministrateurs client

Dernière mise à jour

Surface d'Accès de l'opérateur rendue par Console sur des données sûres, affichant le bureau des opérations client sans aucun jeton de service ni secret exposé.
Exemple rendu par Console avec des données sûres : les opérateurs pilotent le bureau des opérations client depuis une seule route. Les jetons de service et les identifiants ne sont jamais affichés ici.

À 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-ongletCe que vous y faites
OverviewConfirmez 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.
CustomersEnregistrements clients, politique de facturation, intégration et transfert d’API.
MembersLa liste des membres du client et du locataire.
PermissionsPolitique de fonctionnalités et de méta-permissions par adhésion.
TargetsRoutage des espaces de travail et alias de modèles.
OnboardingListe 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.

Éditeur de Politiques de permissions de Console avec les métriques de Contrôles de politique à gauche et l'Éditeur de politique de membre à droite.

Travaillez l’éditeur en trois mouvements :

  1. 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.
  2. 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.
  3. 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.

Panneau de Politique tarifaire des ressources de Console avec la source de la politique, les remplacements client, les clés par défaut et les préréglages d'estimation Pilote, Équipe et Entreprise.

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

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.