Adopter Codex en équipe : guide pratique des permissions, des conventions et du chemin Bedrock

Quand une équipe commence à utiliser Codex ensemble, la première question de la sécurité et des opérations n’est généralement pas « quel plan acheter ? ». C’est plutôt « qui a le full access, que peut lire .env, et où voit-on l’usage et les logs d’audit ? ». Ces questions déterminent la première étape de l’adoption en équipe. La bonne réponse n’est pas de choisir d’abord une API key. C’est de définir d’abord la frontière de permission. Cet article propose un cadre de décision pour l’adoption en entreprise : configurez requirements.toml et les permission profiles pour contraindre les permissions des membres, standardisez les règles AGENTS.md partagées, choisissez ensuite un chemin de déploiement comme ChatGPT Workspace, API Key ou Amazon Bedrock, puis reliez analytics et compliance. Un fait doit être clair dès le départ : AWS a annoncé le 2026-06-03 la disponibilité de GPT-5.4 dans GovCloud, mais le provider Bedrock de Codex ne prend actuellement pas en charge les endpoints GovCloud. Ce sont deux faits différents.

1. Cadre de permissions en entreprise : ne laissez pas le full access vivre sur chaque machine locale

Lorsqu’une entreprise veut standardiser Codex, elle peut utiliser des cloud-managed requirements pour contraindre le comportement local. requirements.toml est le fichier de politique de Codex. Les administrateurs peuvent attribuer différentes politiques par groupe d’utilisateurs au lieu de laisser chaque membre configurer son environnement.

1.1 Champs clés de requirements.toml

Voici les champs les plus utilisés :

Champ	Rôle	Valeur recommandée
approval_policy	Contrôle si une validation humaine est requise	"suggest" ou "auto-edit" ; ne pas utiliser "never" par défaut
approvals_reviewer	Désigne la personne qui valide	Owner d’équipe ou owner sécurité
automatic_review_policy	Règles de review automatique	Définir selon le niveau de risque du projet
permission profiles	Modèle de permission plus récent (0.138.0+)	Recommandé pour les nouveaux déploiements
sandbox_mode	Ancien modèle de permission	Réservé aux migrations legacy
web_search_mode	Autorise ou non la recherche web	Optionnel, mais à limiter pour les projets sensibles
managed_hooks	Configuration unifiée des hooks	lint-check, test-runner, et similaires
MCP servers allowlist	Serveurs MCP autorisés	Seulement les serveurs approuvés comme filesystem et github

Codex 0.138.0 et plus recommande les permission profiles avec allowed_permission_profiles et default_permissions. Les déploiements plus anciens doivent encore utiliser allowed_sandbox_modes.

1.2 Combinaisons interdites

La combinaison suivante ne doit pas être utilisée comme standard d’équipe :

danger-full-access + approval_policy = "never"

C’est la combinaison au privilège maximal sans validation. Elle doit être bloquée dans les cloud-managed requirements pour ne pas apparaître dans les configurations locales individuelles.

1.3 Exemple de configuration

# requirements.toml
[managed]
approval_policy = "suggest"
allowed_permission_profiles = ["suggest", "auto-edit"]
default_permissions = "suggest"

[mcp]
allowed_servers = ["filesystem", "github"]

[hooks]
managed_hooks = ["lint-check", "test-runner"]

Cet exemple limite les membres à "suggest" ou "auto-edit", met "suggest" par défaut, n’autorise pour MCP que filesystem et github, et garde le même ensemble de hooks. Si vous voulez donner "auto-edit" à un noyau de développement et laisser les stagiaires sur "suggest", c’est le bon endroit.

2. Moindre privilège et sandbox design : règles concrètes, deny glob et protection des fichiers sensibles

Les responsables sécurité n’ont pas besoin d’un slogan sur le moindre privilège. Ils ont besoin de règles concrètes : quels fichiers peuvent être lus, lesquels peuvent être modifiés, et lesquels sont totalement interdits ?

2.1 Trois valeurs pour filesystem

Les permissions filesystem de Codex prennent trois valeurs :

• read: lecture seule, aucune modification
• write: lecture/écriture, modifications autorisées
• deny: accès totalement bloqué

La règle de priorité est simple : les règles plus spécifiques gagnent, et deny a la priorité la plus haute. Par exemple, si vous configurez à la fois "**/*.env" = "deny" et ":workspace_roots" = "write", les fichiers .env restent bloqués même si le workspace root est inscriptible.

2.2 Limiter le périmètre du workspace

Utilisez :workspace_roots pour limiter la zone de travail :

[permissions.filesystem]
":workspace_roots" = "write"

Ainsi, Codex ne peut travailler qu’à l’intérieur du workspace root courant et de ses sous-dossiers. Les fichiers hors de ce périmètre ne sont pas accessibles.

2.3 Protéger les fichiers sensibles

Les deny globs permettent de garder les fichiers d’environnement et les répertoires secrets hors de portée :

[permissions.filesystem]
":workspace_roots" = "write"
"**/*.env" = "deny"
"**/secrets/**" = "deny"
"**/*.log" = "read"

Cela signifie :

• le workspace root et ses sous-dossiers sont inscriptibles
• tous les fichiers .env sont bloqués partout
• secrets/ et ses sous-dossiers sont bloqués
• les fichiers .log sont en lecture seule

2.4 Permission réseau

La permission réseau peut être contrôlée par des listes allow/deny de domaines :

[permissions.network]
enabled = true
allow = ["github.com", "api.openai.com"]
deny = ["localhost", "127.0.0.1"]

Codex peut ainsi atteindre github.com et api.openai.com, tout en bloquant localhost et loopback. Il existe une protection supplémentaire pour les réseaux locaux/privés, donc les équipes peuvent aussi définir leurs propres listes de domaines.

2.5 permission profiles versus sandbox mode

Comparaison	Permission profiles	Sandbox mode
Stade	Modèle plus récent	Modèle plus ancien
Granularité	Plus fine	Plus grossière
Champs de config	allowed_permission_profiles + default_permissions	allowed_sandbox_modes
Recommandation	À privilégier pour les nouveaux déploiements	Principalement pour les migrations legacy

Les nouveaux déploiements devraient préférer les permission profiles. Le sandbox mode peut être progressivement abandonné.

3. Conventions d’équipe partagées : un seul AGENTS.md, pas un fichier custom par personne

Les équipes ont besoin d’un prompt commun, de règles de contexte partagées et d’instructions de review partagées. Elles n’ont pas besoin que chacun maintienne sa propre version et disperse la maintenance dans une dizaine de fichiers. AGENTS.md est le fichier d’instructions de Codex. Il supporte des règles en couches et des priorités.

3.1 Ordre de la chaîne d’instructions

Au démarrage, Codex construit la chaîne suivante :

règles globales (~/.config/codex/AGENTS.md)
  -> règles projet (project AGENTS.md)
  -> règles du répertoire le plus proche

Le fichier le plus proche gagne en cas de chevauchement.

3.2 Architecture en couches

Ne mettez pas toutes les règles dans un seul énorme fichier. Travaillez en couches :

• ~/.config/codex/AGENTS.md : règles globales, style, attentes de test, interdictions générales
• AGENTS.md projet : architecture, dépendances, style de déploiement
• AGENTS.md module : besoins spécifiques au module

Chaque couche devrait rester autour de 10-15 KiB pour rester maintenable et éviter les troncatures.

3.3 Gérer la limite de 32 KiB

Codex met project_doc_max_bytes à 32 KiB par défaut. Si AGENTS.md devient trop gros, il peut être tronqué.

Deux solutions existent :

1. augmenter project_doc_max_bytes
2. diviser le document en répertoires imbriqués

Le découpage est souvent préférable, car il rend la propriété et la maintenance plus claires.

3.4 À quoi sert AGENTS.override.md

AGENTS.override.md sert à surcharger le AGENTS.md supérieur et possède la plus haute priorité. Utilisez-le quand :

• un sous-répertoire précis a besoin d’un override temporaire
• un module expérimental a besoin de limites plus souples
• un module diffère de la politique du projet

Notez la raison de l’override pour éviter la confusion dans l’équipe.

3.5 Conseil de maintenance

Lors de la maintenance d’AGENTS.md, soyez explicites sur :

• Ownership : qui possède quelle couche ?
• Maintenance budget : combien de temps de review chaque sprint ?
• Review cycle : à quelle fréquence revoir les règles globales et projet ?

AGENTS.md devient alors une référence vivante partagée, au lieu d’un fichier privé que chacun réécrit.

4. Choix du chemin de déploiement : ChatGPT Workspace, API Key ou Bedrock ?

Les organisations doivent choisir quel chemin de facturation, de conformité et de contrôle adopter. Les trois options ont des avantages, des limites et des usages différents.

4.1 Tableau comparatif

Dimension	ChatGPT Business/Enterprise	API Key	Amazon Bedrock
Authentification	Connexion ChatGPT	OPENAI_API_KEY	Bedrock API key ou AWS IAM
Facturation	OpenAI Workspace	Compte API OpenAI	Compte AWS
Gouvernance d’équipe	Analytics Dashboard, managed requirements	Aucune gouvernance d’équipe native	AWS IAM et CloudTrail
Complétude des fonctions	La plus complète	La plus flexible	Ensemble partiel (voir 4.2)
Conformité / région	Régions OpenAI	Régions OpenAI	Régions AWS et data residency
Support GovCloud	Non	Non	Le modèle peut être disponible, mais le support du provider est distinct (voir 4.3)
Meilleur cas d’usage	Équipes petites/moyennes avec gestion de workspace	Développeurs qui veulent une intégration flexible	Équipes centrées AWS avec facturation, IAM et conformité

4.2 Capacités manquantes sur Bedrock

Au 2026-06-08, les capacités suivantes ne sont pas disponibles sur ce chemin :

• Fast Mode
• recherche web/fichier hébergée
• computer use
• shell tool
• génération d’images
• serveurs MCP distants
• on-demand inference only n’est pas supporté ; utilisez Provisioned Throughput

Ces capacités dépendent de services cloud hébergés par OpenAI, d’outils hébergés ou de découverte cloud-managed, donc elles sont hors de ce chemin. Si votre équipe en dépend, utilisez plutôt ChatGPT Workspace ou API Key.

4.3 Clarification GovCloud

Il faut distinguer deux faits :

1. GPT-5.4 sur AWS GovCloud (US-West) est disponible

   • le modèle lui-même est disponible dans GovCloud
   • GPT-5.4 peut être appelé via l’API Bedrock

2. Le provider Codex Bedrock ne prend pas en charge les endpoints GovCloud

   • le provider amazon-bedrock de Codex ne supporte actuellement pas les endpoints Bedrock Mantle dans les régions AWS GovCloud
   • vous ne pouvez pas configurer Codex vers Bedrock dans GovCloud aujourd’hui

N’écrivez donc pas « Codex sur Bedrock supporte GovCloud » comme si ces deux faits étaient identiques.

4.4 Scénarios adaptés

Choisissez le chemin selon les besoins de l’organisation :

ChatGPT Business/Enterprise

• petites et moyennes équipes
• besoin d’une gestion de workspace
• besoin de la couverture fonctionnelle la plus complète
• pas besoin de facturation AWS ni d’IAM

API Key

• développeurs qui veulent une intégration souple
• pas besoin de gouvernance d’équipe
• facturation directe sur un compte API OpenAI
• pas besoin d’administration de conformité

Amazon Bedrock

• équipes centrées AWS avec comptes AWS, IAM et billing existants
• veulent regrouper les coûts sous des engagements AWS
• ont besoin de data residency ou de régions AWS spécifiques
• acceptent un ensemble de fonctions partiel (voir 4.2)

5. Configuration et limites de Bedrock : auth AWS-native, fonctions manquantes et risque GovCloud

Les équipes qui choisissent Bedrock doivent comprendre précisément le setup, l’authentification, les capacités manquantes et la frontière GovCloud.

5.1 Configurer le provider amazon-bedrock

Définissez le provider dans le fichier de config Codex :

{
  "provider": "amazon-bedrock",
  "aws_region": "us-east-1",
  "model_id": "openai.gpt-5.5"
}

L’ID du modèle et la région doivent suivre les documents officiels.

5.2 Auth AWS-native

Le chemin Bedrock utilise l’authentification AWS-native, pas OPENAI_API_KEY :

• Bedrock API key : clé courte, 12 heures max ou durée de session, héritant des permissions IAM principal
• AWS IAM credentials : configurées via un rôle IAM ou un utilisateur IAM

En production, il est recommandé d’utiliser des clés courtes ou des rôles IAM. Les clés longues ne servent qu’à l’exploration.

5.3 Régions commerciales AWS prises en charge

Les documents officiels prennent actuellement en charge ces régions commerciales AWS :

• us-east-1
• us-west-2
• eu-west-1
• ap-northeast-1

Pour la liste à jour, consultez la documentation AWS Bedrock OpenAI models.

5.4 Gouvernance des Bedrock API keys

Règles importantes pour les API keys Bedrock :

• Short-term key : jusqu’à 12 heures ou la durée de session, hérite des permissions IAM principal, recommandé pour la production
• Long-term key : réservé à l’exploration, non recommandé en production
• CloudTrail logging : les appels API sont enregistrés dans AWS CloudTrail ; la clé elle-même n’est pas loggée en clair
• IAM actions control : les actions IAM peuvent déterminer qui peut créer et utiliser des API keys

5.5 Fonctions manquantes à nouveau

Au 2026-06-08, Bedrock n’offre pas :

• Fast Mode
• recherche web/fichier hébergée
• computer use
• shell tool
• génération d’images
• serveurs MCP distants
• on-demand inference only n’est pas supporté ; utilisez Provisioned Throughput

Si votre équipe a besoin de ces fonctions, basculez vers ChatGPT Workspace ou API Key.

5.6 Risque GovCloud à nouveau

Encore une fois, il faut séparer :

• GPT-5.4 AWS est disponible dans GovCloud (US-West) : le modèle est disponible dans GovCloud
• Le provider Codex Bedrock ne prend pas en charge les endpoints GovCloud : vous ne pouvez pas configurer Codex vers Bedrock dans les régions AWS GovCloud aujourd’hui

Si votre équipe a besoin de GovCloud, ne partez pas du principe que Codex peut déjà y pointer Bedrock.

6. Gouvernance et audit : où voir l’usage et les logs de conformité ?

Les managers doivent suivre l’adoption, l’usage et l’impact des code reviews, et ils ont besoin pour cela de sorties analytics et audit.

6.1 Comparaison des trois chemins de gouvernance

Chemin	Fonction	Délai	Idéal pour
Analytics Dashboard	adoption, usage, feedback de code review	Les données d’usage peuvent avoir jusqu’à 12 heures de retard	Suivi du rollout
Analytics API	buckets quotidiens/hebdomadaires, usage workspace/par utilisateur, découpage par client, métriques de code review	De quasi temps réel à quelques heures	Gouvernance des coûts et analyses approfondies
Compliance API	export des activités Codex et des métadonnées d’audit	Dépend de l’intégration SIEM/eDiscovery	Audit conformité

6.2 Scénarios d’usage

6.2.1 Suivi du rollout

Utilisez Analytics Dashboard pour voir l’adoption et l’usage de l’équipe :

• taux d’activation des membres
• qualité du feedback de code review
• distribution de l’usage par client

Les données du dashboard peuvent avoir jusqu’à 12 heures de retard, donc elles conviennent mieux aux rapports hebdo ou mensuels qu’au monitoring temps réel.

6.2.2 Gouvernance des coûts

Utilisez l’Analytics API pour une analyse plus poussée :

• découper l’usage par workspace/user/model
• comparer les buckets quotidiens et hebdomadaires
• répartir l’usage par client (Codex App/CLI/IDE/Cloud)
• synthétiser les métriques de code review

C’est le bon chemin pour la gouvernance des coûts et l’optimisation interne.

6.2.3 Audit conformité

Utilisez la Compliance API pour exporter les logs d’audit :

• enregistrements d’activité Codex
• métadonnées d’audit
• intégration SIEM/eDiscovery
• support des revues de conformité

Ce chemin convient aux organisations réglementées comme la finance, l’administration et la santé.

6.3 Recommandation de chemin de gouvernance

• Analytics Dashboard : pour les responsables techniques et chefs de projet qui suivent le rollout
• Analytics API : pour les platform engineers qui font de la gouvernance des coûts et des analyses approfondies
• Compliance API : pour les équipes sécurité et conformité qui connectent SIEM et eDiscovery

Les trois chemins peuvent être combinés selon les besoins de l’organisation.

7. Chemin de déploiement d’équipe : du test individuel à la gouvernance d’organisation

Les équipes ne savent souvent pas par où commencer, comment découper l’adoption par étapes, ni comment choisir les premières tâches pilotes.

7.1 Cadre de déploiement en trois étapes

Étape 1 : contrôle individuel (définir la frontière de permission)

Objectif : s’assurer que la frontière de permission de chaque membre reste contrôlable afin que les fichiers sensibles ne se dispersent pas sur les machines locales.

Actions clés :

• interdire danger-full-access + approval_policy = "never" comme défaut d’équipe
• protéger .env et secrets/ avec des deny globs
• définir :workspace_roots pour limiter la zone de travail

Critère de succès : aucun membre ne peut accéder à des fichiers sensibles sans approbation.

Étape 2 : pilote petite équipe (conventions partagées + tâches à faible risque)

Objectif : unifier AGENTS.md et les skills dans une petite équipe, puis commencer par des tâches à faible risque pour vérifier que le flux fonctionne.

Actions clés :

• écrire un AGENTS.md global (attentes de style et de test)
• écrire un AGENTS.md projet (architecture, dépendances, déploiement)
• choisir des tâches à faible risque : génération de docs, corrections de lint, ajouts de tests
• éviter l’automatisation directe du déploiement en production ou de la logique de paiement

Critère de succès : la majorité des membres utilisent le AGENTS.md partagé et aucun incident majeur de sécurité n’apparaît.

Étape 3 : gouvernance organisationnelle (managed requirements + Analytics/Compliance API)

Objectif : élever permissions et conventions au niveau de l’organisation et relier observabilité et audit.

Actions clés :

• configurer les cloud-managed requirements par groupe utilisateur
• connecter Analytics Dashboard/API pour suivre adoption et usage
• connecter Compliance API au SIEM
• revoir régulièrement permission profiles et MCP allowlists

Critère de succès : le tableau de gouvernance est en ligne et les logs d’audit sont traçables.

7.2 Tâches pilotes recommandées

Privilégier d’abord les tâches à faible risque

Bonnes tâches pour le premier lot pilote :

• génération de documentation : README, docs API, nettoyage de notes
• corrections de lint : eslint, prettier, automatisation du formatage
• ajouts de tests : unit tests et squelettes de tests d’intégration
• suggestions de refactoring : idées d’amélioration de structure avec review humaine

Éviter l’automatisation directe

Mauvaises tâches pour le premier lot pilote :

• déploiement en production
• logique de paiement
• changements de permissions
• suppression de données

Ces tâches sont à haut risque et doivent attendre que la gouvernance et l’audit soient mûrs.

7.3 Relation avec le reste de la série

Cet article est la page de décision pour l’adoption en équipe ; les articles suivants pourront aller plus loin :

• style d’écriture AGENTS.md : règles par couches, éviter la troncature, maintenance
• blocages personnels et sandboxes : problèmes de permission, setup sandbox, erreurs fréquentes
• intégration Cloud/GitHub : développement distant, review GitHub, Cloud tasks
• optimisation coûts et quota : techniques de réduction de tokens et contrôle budgétaire
• automatisation et tâches longues : triggers planifiés, heartbeats et jobs multi-jours

Résumé et prochaines étapes

Si vous êtes responsable technique et que vous déployez Codex dans une équipe, l’ordre devrait être :

1. Lire d’abord la configuration de permission (sections 1 et 2) pour bloquer les combinaisons dangereuses
2. Standardiser ensuite les conventions (section 3) pour que AGENTS.md ait une forme commune
3. Choisir le chemin de déploiement après cela (sections 4 et 5) pour décider entre Workspace, API Key et Bedrock
4. Connecter la gouvernance en dernier (section 6) via Analytics et Compliance APIs

Ensuite, vous pouvez aller plus loin sur des modules plus spécifiques :

• style d’écriture AGENTS.md : règles par couches, éviter la troncature, maintenance
• blocages personnels et sandboxes : problèmes de permission, setup sandbox, erreurs fréquentes
• intégration Cloud/GitHub : développement distant, review GitHub, Cloud tasks
• optimisation coûts et quota : techniques de réduction de tokens et contrôle budgétaire
• automatisation et tâches longues : triggers planifiés, heartbeats et jobs multi-jours

Bases connexes :

• bases de la collaboration Git en équipe : Git flow, stratégie de branches et workflow de code review
• secrets CI et sécurité des permissions : secrets GitHub Actions, frontières de permission et pratiques de sécurité