D4 · Team Adoption and Governance

Ce domaine vaut 20 % de l’examen blanc — soit environ 10 items sur 50. Il passe du workflow d’un ingénieur à celui d’une organisation : comment un admin déploie Codex, l’authentifie, gouverne qui peut faire quoi, le maintient configuré de façon cohérente, l’audite et sécurise le code qu’il produit. L’examen récompense le défaut gouverné — moindre privilège, configuration managée, pistes d’audit et analyse de sécurité — plutôt que le chemin le plus rapide vers « tout le monde a Codex ».

Ce que vous devez savoir

Les admins déploient Codex via un guide de déploiement et une configuration managée pour que les réglages soient cohérents, non laissés à chaque ingénieur. L’authentification a plusieurs options — workload identity, personal access tokens (PAT) et comptes de service — choisies selon qu’un humain ou un système agit. L’accès est gouverné par les groupes et le provisioning, les rôles et permissions d’espace de travail, et des contrôles sur les plugins, connectors et skills. La supervision provient des workspace analytics, de l’Analytics API et de l’API de compliance et des audit events ; les charges réglementées utilisent la configuration HIPAA. Enfin, Codex Security (plugin, CLI, cloud) analyse le code et s’intègre à la CI et à GitLab CI.

Objectifs d’apprentissage

À l’issue de cette page, vous devriez être capable de :

1. Planifier un déploiement admin en utilisant la configuration managée pour la cohérence à l’échelle.
2. Choisir une option d’authentification — workload identity, PAT ou compte de service — pour un acteur donné.
3. Gouverner l’accès avec les groupes, le provisioning, les rôles et permissions d’espace de travail.
4. Contrôler les extensions — plugins, connectors et skills — au niveau de l’espace de travail.
5. Auditer et mesurer Codex avec les workspace analytics, l’Analytics API et l’API de compliance / les audit events.
6. Configurer les charges réglementées et sécurisées, y compris la configuration HIPAA et Codex Security avec l’analyse en CI.

4.1 Déploiement admin et configuration managée

Un déploiement qui laisse la configuration à chaque ingénieur produit de la dérive et du risque. La configuration managée permet aux admins de définir et d’imposer des réglages de façon centralisée.

UNGOVERNED ROLLOUT              GOVERNED ROLLOUT
each engineer configures        admin sets managed configuration
their own model, perms,   ──►   → consistent model availability,
extensions → drift, risk        permissions, allowed extensions

4.2 Options d’authentification

Choisissez le mécanisme d’auth selon qui ou quoi agit.

Who is acting?
│
├─ A cloud workload / CI ─────► workload identity federation (no long-lived secret)
├─ An org-owned automation ───► service account
└─ An individual scripting ───► personal access token (PAT)

4.3 Groupes, provisioning, rôles et permissions

Gouverner l’accès à l’échelle signifie gérer les identités et ce que chacune peut faire.

Le principe est le moindre privilège : les admins sont peu nombreux, la plupart des ingénieurs sont membres, le provisioning est automatisé pour que les partants perdent l’accès promptement, et les permissions correspondent à la responsabilité.

4.4 Analytics et mesure de l’adoption

On ne peut pas gouverner ce qu’on ne voit pas. Codex expose à la fois un dashboard et une surface programmatique.

L’adoption se mesure, ne se présume pas : qui utilise Codex, dans quelle mesure, et — combinée à des signaux de qualité (D5) — si l’usage produit de bons résultats.

4.5 Compliance, audit et charges réglementées

La gouvernance exige une piste d’audit et, pour certains secteurs, une configuration spécifique.

Pour une charge réglementée, la réponse conforme à l’examen combine la bonne configuration (p. ex. HIPAA) avec une piste d’audit (API de compliance et audit events) — pas l’une sans l’autre.

4.6 Codex Security et analyse en CI

Codex Security analyse le code que Codex (et votre équipe) produit, à travers le plugin, le CLI et le cloud.

CODE (human or Codex) ─► SCAN / DEEP SCAN ─► WORKBENCH TRIAGE ─► FIX / HARDEN
                                │                                    │
                          CI / GitLab CI                      vulnerability
                          gate the pipeline                   report

L’analyse de sécurité a sa place dans le pipeline (CI / GitLab CI), pas comme une étape manuelle dont quelqu’un se souvient, pour que le code produit par Codex soit analysé avant d’être mergé.

Cadre de décision

Utilisez ROLL OUT SAFELY (ROSA) : Rollout config, Ownership (auth), Scope (rôles), Audit.

Erreurs courantes

Défi de mise en situation

Scénario. Une entreprise de logiciels de santé déploie Codex auprès de 120 ingénieurs répartis en six équipes. Aujourd’hui, un groupe pilote a chacun installé le CLI, s’est connecté personnellement, a épinglé des modèles différents, et un ingénieur a câblé un job cloud nocturne avec son propre personal access token. Certains dépôts touchent des informations de santé protégées. La direction veut des chiffres d’adoption pour une mise à jour du conseil d’administration et un enregistrement auditable pour son équipe compliance. Un ingénieur propose : « laissons chacun s’auto-configurer comme le pilote, gardons le token personnel pour le job nocturne, et récupérons les chiffres d’adoption manuellement chaque mois ».

Trace de raisonnement d’expert.

1. L’auto-configuration ne passe pas à l’échelle et ne gouverne pas. 120 ingénieurs épinglant chacun des modèles et des permissions, c’est de la dérive et du risque. Le déploiement a besoin d’une configuration managée définissant de façon centralisée la disponibilité des modèles, les permissions et les extensions autorisées.
2. L’auth du job nocturne est fausse. Un personal access token lie une automatisation d’org à une personne — elle casse quand la personne part et n’est pas une identité d’org. Une charge cloud/CI devrait utiliser la workload identity federation ; une automatisation d’org partagée pourrait utiliser un compte de service. L’un ou l’autre est correct plutôt qu’un PAT ici.
3. Les PHI imposent une configuration réglementée. Les dépôts touchant des informations de santé protégées exigent la configuration HIPAA ; l’« usage interne » ne les en exempte pas.
4. La compliance a besoin d’une piste d’audit. L’enregistrement auditable de l’équipe compliance, c’est l’API de compliance et les audit events, activés dans le cadre du déploiement — pas reconstruits plus tard.
5. Les chiffres d’adoption devraient être programmatiques. Les récupérations manuelles mensuelles sont sujettes à l’erreur ; les workspace analytics plus l’Analytics API fournissent la mise à jour du conseil de façon reproductible.
6. Sécuriser le chemin du code. Le code produit par Codex dans un produit de santé devrait être analysé en CI via Codex Security avant merge, pas manuellement.

Décision conforme à l’examen : déployer avec la configuration managée ; authentifier le job nocturne avec la workload identity federation (ou un compte de service), pas un token personnel ; appliquer la configuration HIPAA aux dépôts touchant des PHI ; activer l’API de compliance et les audit events ; reporter l’adoption via les workspace analytics et l’Analytics API ; et exécuter Codex Security en CI. Pas d’auto-configuration à l’échelle, pas de PAT personnel pour une automatisation d’org, pas de récupérations d’adoption manuelles, pas d’omission de la config HIPAA parce qu’elle « paraît interne ».

Pièges d’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

Points clés à retenir

• Déployez avec la configuration managée pour que la disponibilité des modèles, les permissions et les extensions autorisées soient cohérentes, non par ingénieur.
• Choisissez l’auth selon l’acteur : workload identity federation pour les charges CI/cloud, comptes de service pour les automatisations d’org, PAT pour les individus.
• Gouvernez l’accès avec les groupes, le provisioning et des rôles et permissions au moindre privilège ; automatisez le cycle de vie de l’utilisateur.
• Mesurez l’adoption avec les workspace analytics et l’Analytics API — des chiffres, pas des anecdotes.
• Gardez une piste d’audit avec l’API de compliance et les audit events ; appliquez la configuration HIPAA aux charges PHI.
• Analysez le code produit par Codex avec Codex Security (plugin, CLI, cloud) intégré à la CI / GitLab CI, avant merge.
• Le défaut gouverné — moindre privilège, config centrale, audit, sécurité dans le pipeline — l’emporte sur le chemin le plus rapide vers « tout le monde a Codex ».