Gérer Codex dans une organisation

Leçon réécrite le 3 novembre 2026 d’après l’Admin rollout guide, la page Pricing et ChatGPT usage limits and spend controls de la documentation de Codex. L’ancienne version décrivait une console d’administration sur codex.openai.com, des rôles « Admin, Developer, Viewer » et des quotas en nombre de tâches par jour qui ne correspondent pas au produit ; l’administration passe par l’espace de travail ChatGPT. Les libellés de l’interface évoluent : le Help Center d’OpenAI fait foi pour les procédures. Sources : Admin rollout guide · Pricing · Usage limits.

Déployer Codex pour une équipe de développement

Passer de l’usage individuel de Codex à un déploiement pour toute une organisation demande de la planification. Ce qui tenait debout pour un développeur curieux devient ingérable à trente personnes dès lors que personne n’a défini qui accède à quoi, ni qui paie. Le guide de déploiement d’OpenAI découpe le sujet en frontières d’administration distinctes : l’accès à l’espace de travail, la politique d’exécution locale, Codex Cloud, l’accès à l’API, les plugins et connecteurs, et les permissions dans les systèmes connectés.

Choisir l’offre

Le choix ne se réduit pas à l’effectif : ce sont surtout les obligations d’authentification centralisée et de traçabilité qui font basculer vers Enterprise.

Vérifiez les tarifs et le contenu des offres sur la page de tarification de Codex au moment de décider : ils évoluent.

Nommer des responsables

Avant de toucher aux réglages, désignez un responsable pour chaque frontière : l’accès à l’espace de travail (membres, sièges, rôles), la politique d’exécution locale (approbations, profils de permissions, accès aux fichiers et au réseau), Codex Cloud (environnements, connexions aux dépôts), les systèmes connectés (installation des applications côté GitHub, comptes, permissions) et le reporting (analyses, exports d’audit). Décidez ensuite, public par public, s’il a besoin de Codex en local, dans le cloud, ou des deux ; l’accès par clé d’API relève d’une frontière à part, celle de l’organisation et des projets de la plateforme API.

Ouvrir les accès sans les ouvrir trop grand

L’accès se règle dans l’espace de travail ChatGPT : appartenance, sièges, groupes et permissions RBAC quand l’offre les propose. Ne supposez pas qu’un même rôle contrôle toutes les surfaces : vérifiez séparément l’accès local et l’accès cloud, avec un membre de test qui a exactement les permissions prévues. Gardez les rôles d’administration intégrés pour les seules personnes qui administrent l’espace.

Deux réglages méritent une attention particulière. L’usage local se contrôle par une permission dédiée — selon la présentation de votre espace, Allow members to use Codex and Work Locally, ou des sections séparées Codex Local et Work Local. Et Codex Cloud est désactivé par défaut dans les espaces Enterprise : un administrateur accorde Use Codex in the cloud au public visé et, séparément, Manage workspace environments aux personnes qui créent et modifient les environnements partagés.

Le contrôle le plus structurant reste celui des dépôts. Codex Cloud respecte les permissions et les protections du système source : limitez donc, côté GitHub, l’accès de l’intégration aux seuls dépôts dont chaque public a besoin. L’accès à l’espace de travail ne contourne pas ces contrôles. Un dépôt de secrets ne doit jamais être connecté, quelle que soit la commodité ponctuelle que cela représenterait un jour de rush.

Encadrer l’exécution locale

Pour l’application de bureau, le CLI et l’extension, la politique locale se distribue par un fichier requirements.toml, déployé par un canal géré (cloud, gestion des appareils ou système). Il impose des contraintes que l’utilisateur ne peut pas lever, par exemple les profils de permissions autorisés :

default_permissions = ":workspace"

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

Les environnements cloud n’héritent pas de cette politique locale, ni des réglages de gestion des appareils : leurs exigences se configurent à part.

Maîtriser la consommation

Les limites d’usage et les contrôles de dépense de l’espace de travail s’appliquent à l’activité éligible de votre offre, dont une partie de l’activité Codex quand votre contrat utilise des crédits ChatGPT partagés ou achetés : garde-fous par utilisateur, plafonds au niveau de l’espace, notifications. Ils ne couvrent ni tout l’usage de Codex, ni la facturation de la plateforme API, qui se pilote de son côté. Le mode Ultrafast de GPT-6 Astra, désactivé par défaut dans les espaces Enterprise éligibles, consomme plus vite : revoyez les plafonds par utilisateur avant de l’ouvrir.

Pour savoir où part la consommation, servez-vous des analyses de l’espace de travail et de l’Analytics API, pas de la Compliance API, réservée aux usages d’audit et d’enquête (leçon 17).

Diffuser les standards par un modèle de dépôt

Rien ne garantit qu’un nouveau projet démarre avec une configuration correcte, sauf si vous la placez dans le point de départ. La configuration propre à un dépôt — réglages par défaut, règles de commandes, skills — se versionne dans .codex ou .agents, selon l’emplacement documenté de chaque fonction ; elle fournit des valeurs par défaut et des workflows réutilisables, mais ne peut accorder aucun accès.

# Dépôt modèle de votre organisation
my-org/project-template/
  AGENTS.md           → Standards de l'organisation, dont ## Code Review Rules
  .codex/             → Configuration et règles partagées
  .github/
    workflows/
      codex-review.yml → Revue automatisée (leçon 14)

Chaque projet créé depuis ce modèle hérite des standards sans réunion de lancement ni rappel à l’ordre trois mois plus tard.

Accueillir un nouveau développeur

1. Ajoutez-le à l’espace de travail ChatGPT, dans le groupe qui porte les bonnes permissions.
2. Vérifiez son accès local et, si votre public en a besoin, son accès à Codex Cloud et aux environnements.
3. Vérifiez côté GitHub qu’il voit les dépôts prévus, et eux seuls.
4. Partagez le guide d’utilisation interne et le dépôt modèle.
5. Faites-lui explorer le projet avec Codex : « Explique l’architecture de ce dépôt et les commandes utiles », depuis la racine, pour qu’il lise aussi l’AGENTS.md.

Cette dernière étape produit une découverte du projet taillée sur mesure, que le nouvel arrivant lit avant de solliciter ses collègues.

Points clés à retenir

• L’administration de Codex passe par l’espace de travail ChatGPT, découpée en frontières : accès, exécution locale, cloud, API, plugins, systèmes connectés
• Business apporte SSO SAML et MFA ; Enterprise et Edu, SCIM, RBAC, Compliance API et contrôles de données
• Codex Cloud est désactivé par défaut en Enterprise ; l’accès aux dépôts se limite côté GitHub
• requirements.toml impose la politique locale ; la configuration de dépôt ne fait que proposer des valeurs par défaut
• Les contrôles de dépense de l’espace ne couvrent ni tout Codex ni la facturation de l’API