Guide de déploiement pour les administrateurs

Utilisez ce guide pour planifier le déploiement de ChatGPT Enterprise dans les périmètres d’administration suivants :

Accès à l’espace de travail.
Politique d’exécution locale pour les fonctionnalités concernées dans l’application de bureau ChatGPT, Codex CLI et l’extension IDE.
Codex cloud.
Accès à la Platform API.
Accès aux plugins et aux connecteurs.
Autorisations dans les systèmes connectés.

Pour un nouveau déploiement, effectuez les étapes dans l’ordre. Pour modifier un seul périmètre, consultez les pages indiquées par les liens.

Si vous gérez une passerelle de modèles pour des clients Codex locaux, consultez Déployer Codex via une passerelle pour la qualification de la passerelle, la distribution des identifiants d’authentification et la configuration à transmettre aux clients. Configurez séparément l’accès à l’espace de travail si votre déploiement utilise ses fonctionnalités.

Dans les paramètres de l’espace de travail, Codex and Work Local regroupe l’accès local à Codex et à Work sous Allow members to use Codex and Work Locally. Certains espaces de travail proposent à la place des sections Codex Local et Work Local indépendantes. Dans cette disposition, Allow members to use Codex locally contrôle Codex et Use Work locally contrôle Work. L’activation de l’une n’active pas l’autre. Ces libellés désignent des autorisations de l’espace de travail, et non des produits ou clients distincts. Les autorisations relatives aux jetons et les limites de durée de vie des identifiants apparaissent soit dans une section Access tokens, soit dans la section d’accès local, selon l’espace de travail. La configuration gérée constitue une couche de politiques distincte qui peut restreindre le comportement d’exécution pris en charge pour les fonctionnalités concernées dans ces clients. Ce guide nomme l’interface individuelle lorsque le comportement ou la disponibilité diffère.

Pour une présentation des contrôles d’accès, consultez Rôles et autorisations de l’espace de travail. Consultez les guides du centre d’aide pour les procédures actuelles des espaces de travail ChatGPT et la documentation développeur accessible via les liens pour le comportement des environnements d’exécution locaux et hébergés.

Pour en savoir plus sur la sécurité, la confidentialité et les protections de l’environnement d’exécution en entreprise, consultez Approbations et sécurité des agents et le livre blanc sur la sécurité de Codex.

Étape 1 : attribuer les responsabilités et choisir un mode de déploiement

Désignez un responsable pour chaque partie du déploiement :

Accès à l’espace de travail : membres, licences, rôles et fonctionnalités prises en charge dans l’espace de travail.
Politique d’exécution locale : approbations, profils d’autorisation, accès au système de fichiers et au réseau, et autres exigences pour les clients locaux pris en charge.
Codex cloud : environnements hébergés, connexions aux dépôts et politique d’exécution dans le cloud.
Systèmes connectés : installation des applications côté fournisseur, comptes et autorisations.
Rapports et conformité : accès aux analyses, exportations d’audit et traitement des données en aval.

Déterminez si chaque public a besoin des fonctionnalités locales concernées dans l’application de bureau ChatGPT, Codex CLI, l’extension IDE, Codex cloud, ou d’une combinaison de ces environnements. Lorsqu’un workflow utilise une authentification par API key, traitez l’accès à la Platform API comme un périmètre distinct au niveau de l’organisation et du projet.

Étape 2 : configurer l’accès à l’espace de travail et l’identité

Utilisez les membres, licences, groupes et autorisations RBAC prises en charge dans l’espace de travail ChatGPT pour accorder aux publics visés l’accès aux fonctionnalités appropriées. Vérifiez l’accès aux clients locaux et à Codex cloud à partir des instructions actuelles relatives à l’espace de travail, sans supposer qu’un même rôle contrôle tous les environnements. Réservez les rôles d’administration intégrés aux personnes qui administrent l’espace de travail.

Les contrôles et libellés de l’espace de travail évoluent au fil du temps. Consultez les sources suivantes pour connaître les procédures actuelles :

Testez la connexion et l’accès aux fonctionnalités avec un membre disposant des autorisations prévues. L’accès à l’espace de travail ne donne pas accès aux dépôts, aux fichiers ou aux actions d’un service connecté.

Configurer l’accès à l’ordinateur local avec Work Cloud

Si votre déploiement inclut l’accès à l’ordinateur local pour Work ou dots, examinez les politiques dans Agent Security avant le déploiement. La migration des politiques et l’accès aux fonctionnalités sont des modifications distinctes ; le processus de confirmation n’exige pas la création d’une politique pour activer l’accès. La politique Global prise en charge régit l’orchestration dans le cloud lorsqu’une politique gérée est activée. Les exigences d’exécution locale et les contrôles des appareils régissent l’ordinateur connecté. Les conteneurs cloud de Work et les ordinateurs cloud de dots utilisent leurs propres configurations et exigences d’exécution. Suivez le guide Accès à l’ordinateur local pour Work Cloud et dots pour connaître les exigences de configuration et les critères d’éligibilité propres à chacun.

Utilisez l’API de gestion des politiques pour gérer les paramètres Global. Pour gérer les paramètres Local ou Codex Cloud, utilisez l’interface Agent Security. Les workflows existants utilisant l’API Global restent disponibles après la migration. Testez vos scripts et vos intégrations Terraform, et vérifiez que les affectations et l’ordre des politiques restent inchangés.

Vérifiez la compatibilité avant d’activer la synchronisation :

Politique réseau. Lorsque des dérogations propres à l’environnement sont disponibles, testez les exceptions experimental_network décrites dans Configuration gérée. Une restriction globale peut rester en vigueur malgré une autorisation au niveau de l’environnement.

Hooks d’entreprise. Lorsque cette fonctionnalité est activée pour votre espace de travail, l’accès à l’ordinateur local avec Work Cloud prend en charge les hooks MCP définis par les administrateurs, qui s’exécutent sur le coordinateur cloud (orchestrateur) pour les événements de cycle de vie et d’outils pris en charge. Les hooks de commande et ceux provenant de la configuration locale ou de plugins ne sont pas pris en charge avec l’orchestration cloud, même lorsque les outils s’exécutent localement.
Hooks non pris en charge. Les hooks de commande et ceux provenant de la configuration locale ou de plugins ne sont pas pris en charge avec l’orchestration cloud, même lorsque les outils s’exécutent localement. Lorsque l’orchestration et l’exécution sont toutes deux locales, les hooks existants pris en charge continuent de fonctionner dans les fils de discussion Work et Codex exclusivement locaux. Les administrateurs peuvent toujours configurer les hooks gérés pris en charge dans Agent Security pour ces workflows.
Audit. Avant de vous appuyer sur ces hooks, testez la connexion de rappel, vérifiez les événements qu’elle reçoit et examinez l’incidence des échecs sur la tâche. Les hooks MCP ne fournissent pas de piste d’audit complète via la Compliance API.
Exigences relatives aux données. L’accès à l’ordinateur local avec Work Cloud ne garantit pas une absence stricte de conservation des données. La résidence des données et la résidence de l’inférence couvrent uniquement les contenus éligibles ainsi que les charges de travail, régions et configurations prises en charge. Enterprise Key Management (EKM) couvre les contenus stockés pris en charge dans les espaces de travail éligibles. Work n’est pas pris en charge avec la résidence de l’inférence aux Émirats arabes unis. Si enforce_residency est activé dans une politique cloud, Autoriser l’accès à l’ordinateur local est désactivé pour Work comme pour dots. Cette protection ne configure pas la résidence de l’espace de travail et ne désactive pas, à elle seule, Work Cloud ou dots. Si votre organisation exige la ZDR, n’activez pas cette fonctionnalité.

En tant que propriétaire de l’espace de travail, examinez les autorisations Work des utilisateurs ou groupes concernés. Activez Work Cloud, puis Autoriser l’accès à l’ordinateur local. Utilisez les affectations de rôles prises en charge pour accorder l’accès. Consultez Rôles et autorisations de l’espace de travail.

Étape 3 : configurer les exigences d’exécution locale

Les exigences locales limitent le comportement d’exécution lorsqu’un utilisateur lance une exécution locale prise en charge dans l’application de bureau ChatGPT, Codex CLI ou l’extension IDE. Distribuez requirements.toml par l’intermédiaire d’un canal cloud, appareil ou système pris en charge. Maintenez cette politique séparée des rôles et groupes de l’espace de travail ChatGPT.

Utilisez les profils d’autorisation pour les clients locaux pris en charge au lieu de baser de nouveaux déploiements sur les anciennes restrictions du mode sandbox. Par exemple :

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Pour désactiver Computer Use dans l’ensemble des fonctionnalités prises en charge du navigateur et du bureau, restreignez chaque clé de fonctionnalité publique intervenant dans l’expérience :

[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false

Pour obtenir la liste de référence des clés, le comportement de distribution, l’ordre de priorité et d’autres exemples, consultez Configuration gérée et la référence de requirements.toml.

Étape 4 : standardiser la configuration du dépôt

Utilisez une configuration limitée au dépôt pour partager les valeurs par défaut, les règles et les skills du projet sans dupliquer la configuration pour chaque utilisateur. Enregistrez la configuration dans .codex ou .agents selon l’emplacement documenté de la fonctionnalité :

Type	Source	Utilisation
Configuration	Principes de base de la configuration	Définir les valeurs par défaut du dépôt pour les clients locaux pris en charge
Règles	Règles	Contrôler les commandes qui nécessitent une approbation hors du sandbox
Skills	Créer des skills	Mettre les workflows du dépôt à la disposition des clients pris en charge

La configuration du dépôt peut fournir des valeurs par défaut et des workflows réutilisables. Elle ne peut pas accorder l’accès à l’espace de travail, aux modèles, à la Platform API ou aux systèmes connectés.

Étape 5 : configurer Codex cloud

Codex cloud utilise des environnements hébergés et des dépôts de code source connectés.

Codex Cloud est désactivé par défaut pour les espaces de travail Enterprise. Les paramètres existants Utiliser Codex dans le cloud sont conservés depuis Codex Cloud (Legacy) : les espaces de travail qui avaient déjà activé Cloud conservent leur accès, et ceux où Cloud était désactivé le restent jusqu’à ce qu’un administrateur l’active. L’accès reste soumis au déploiement et aux restrictions de l’espace de travail.

Planifiez chaque périmètre de contrôle :

Accordez l’autorisation Utiliser Codex dans le cloud aux utilisateurs concernés. Accordez séparément Gérer les environnements de l’espace de travail aux personnes qui créent et modifient les environnements partagés de l’espace de travail. Consultez les recommandations sur les rôles de l’espace de travail.
Installez et configurez l’intégration prise en charge avec le système de gestion du code source.
Dans le système de gestion du code source, limitez l’accès aux dépôts dont chaque groupe d’utilisateurs a besoin.
Configurez les environnements cloud, les secrets, l’accès à Internet et les exigences prises en charge gérées dans le cloud pour ces dépôts.
Configurez les workflows hébergés facultatifs, comme la revue de code.
Testez l’accès aux tâches avec un membre représentatif et la gestion des environnements avec l’administrateur désigné. Vérifiez les autorisations de chaque personne sur l’espace de travail, les environnements et les dépôts.

Les environnements cloud n’héritent pas de la politique locale de l’appareil, des paramètres MDM ni de l’accès au réseau local. Examinez les exigences prises en charge gérées dans le cloud séparément des exigences installées sur l’ordinateur d’un utilisateur. Consultez Se connecter à des services pour l’accès aux destinations et Agent Security pour comprendre comment les exigences de l’espace de travail encadrent les environnements cloud.

Codex cloud respecte les autorisations et les protections des dépôts exposées par le système de gestion du code source connecté. L’accès à l’espace de travail ne contourne pas ces contrôles. Consultez Environnements cloud pour les recommandations de configuration et d’exécution.

Étape 6 : configurer les plugins et les fonctionnalités connectées

Évaluez séparément l’installation des plugins, les skills inclus, les fonctionnalités reposant sur des connecteurs, les actions des connecteurs et les autorisations du système source. La désactivation d’une fonctionnalité reposant sur un connecteur ne désinstalle pas nécessairement le plugin ni les skills qu’il inclut.

Avant d’inclure un plugin ou un skill dans le déploiement :

Confirmez sa source, son responsable, le public visé et la date de révision.
Examinez les skills inclus, les connecteurs, les MCP servers, les hooks, ainsi que les données et actions requises par chaque fonctionnalité.
Testez-le avec des données non sensibles et les droits d’accès minimaux dont il a besoin.
Consignez la personne responsable de sa réévaluation et de son retrait.

Les plugins fonctionnent dans Chat et Work sur ChatGPT pour le Web, l’application de bureau et les appareils mobiles, dans Codex au sein de l’application de bureau ChatGPT, ainsi que dans le navigateur de plugins de Codex CLI. Ils ne sont pas disponibles dans l’extension IDE. ChatGPT et Codex partagent un même répertoire public universel de plugins ; les contrôles de l’espace de travail déterminent les plugins auxquels les membres peuvent accéder.

Consultez Contrôles des plugins et Contrôles des skills pour découvrir le modèle complet.

Étape 7 : mettre en place la gouvernance et l’observabilité

Choisissez l’interface de rapports correspondant à votre besoin :

Utilisez Analyses de l’espace de travail pour consulter les analyses interactives de l’espace de travail ChatGPT et les analyses Codex.
Utilisez l’Analytics API pour produire des rapports agrégés par programmation avec la Codex Analytics API.
Utilisez la Compliance API pour obtenir des enregistrements d’audit et d’investigation.
Utilisez Limites d’utilisation et contrôles des dépenses de ChatGPT lorsque l’activité Codex dépendant de l’offre consomme des crédits admissibles de l’espace de travail ChatGPT.

Lors de la création d’une intégration, consultez les références de l’API accessibles après authentification pour connaître les exigences d’accès, les schémas, les champs, les règles de conservation et le comportement des requêtes en vigueur.

Protégez le périmètre de l’intégration :

Stockez les API keys et autres identifiants d’intégration dans le système de gestion des secrets de l’organisation.
Limitez l’accès aux systèmes en aval et aux données conservées au public autorisé.
Protégez les enregistrements exportés de la Compliance API en fonction de leur sensibilité et de la politique de conservation de l’organisation, puis testez les workflows de collecte et de suppression par rapport au contrat actuel.

Étape 8 : vérifier et maintenir le déploiement

Après avoir activé l’accès à l’ordinateur local avec Work Cloud, créez une tâche et poursuivez la conversation depuis un autre appareil pris en charge. Les tâches existantes ne sont pas migrées et conservent leur fonctionnement initial, exclusivement local ou exclusivement cloud. Gardez l’ordinateur en ligne pour les étapes qui nécessitent ses fichiers ou ses outils. Testez une action que la politique doit autoriser et une action qu’elle doit bloquer, en vérifiant séparément, pour l’exécution locale et l’exécution cloud, les approbations applicables et les restrictions relatives au système de fichiers et au réseau. Testez également le démarrage d’un nouveau tour lorsque l’ordinateur local est indisponible. Une tâche éligible peut se poursuivre dans un conteneur cloud sans accès aux fichiers ni aux outils locaux de cet ordinateur. Une tâche ne peut pas passer de l’exécution locale au cloud au cours d’un tour.

Consignez les paramètres effectifs et le résultat de chaque test. Si une restriction ne fonctionne pas comme prévu, résolvez le problème avant que les utilisateurs ne s’y fient. Suivez le comportement documenté pour la désactivation de la synchronisation. Traitez la suppression de l’accès, l’interruption des tâches et la conservation des données comme des actions distinctes.

Vérifiez chaque périmètre applicable avec des identités représentatives :

Membres, licences et autorisations de rôle prises en charge dans l’espace de travail ChatGPT.
Fonctionnalités locales concernées dans l’application de bureau ChatGPT, Codex CLI et l’extension IDE, notamment la connexion et les exigences d’exécution réellement appliquées.
Accès à Codex cloud, configuration des environnements et autorisations des dépôts.
Accès aux organisations et projets de la Platform API pour les workflows utilisant une API key.
Installation des plugins, skills inclus, accès aux connecteurs et actions prises en charge.
Autorisations et accès aux données dans les systèmes connectés.
Accès aux analyses et aux données de conformité pour les administrateurs responsables.

Consignez le responsable et la source procédurale actuelle de chaque contrôle. Cette consignation permet aux administrateurs de mettre à jour les procédures lorsque l’interface utilisateur ou les politiques évoluent, sans modifier le modèle d’administration.

Après le déploiement initial, examinez les accès, les fonctionnalités connectées, l’utilisation des crédits, les retours adressés au support et les workflows réellement utilisés par les équipes. Adaptez la portée du déploiement et les instructions destinées aux administrateurs lorsque ces indicateurs évoluent.

Si vous devez désactiver l’accès à l’ordinateur local avec Work Cloud

La désactivation de l’accès à l’ordinateur local avec Work Cloud interrompt les tours en cours. Les utilisateurs peuvent démarrer un nouveau tour dans une conversation cloud existante. Ce tour utilise automatiquement Work Cloud sans accès aux fichiers locaux. Demandez aux utilisateurs de démarrer un nouveau tour après l’interruption et expliquez que les fichiers locaux ne seront plus accessibles au fil de discussion cloud.

Recherches récentes

Recherches suggérées

Navigation de la documentation