# D4 · Team Adoption and Governance Déploiement par l’admin, options d’authentification, groupes et provisioning, rôles et permissions d’espace de travail, configuration managée, API d’analytics et de compliance, configuration HIPAA et Codex Security. import { Accordions, AccordionItem } from '@prosefly/astro-components'; 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. | Élément de déploiement | Objectif | | --- | --- | | Guide de déploiement admin | La séquence : mise en place de l’espace de travail, auth, groupes, rôles, config, monitoring | | Configuration managée | Définir et imposer des réglages de façon centralisée (disponibilité des modèles, permissions, extensions) | | Disponibilité des modèles d’espace de travail | Contrôler quels modèles l’espace de travail peut utiliser | | Contrôles plugin / connector / skill | Décider quelles extensions sont autorisées | ```text UNGOVERNED ROLLOUT GOVERNED ROLLOUT each engineer configures admin sets managed configuration their own model, perms, ──► → consistent model availability, extensions → drift, risk permissions, allowed extensions ``` :::tip[Signal d’évaluation] `Consistent settings across the team`, `stop engineers each configuring their own` → **configuration managée**. `Which models can the workspace use` → **disponibilité des modèles d’espace de travail**. `Which plugins/skills are allowed` → contrôles plugin/connector/skill. ::: ## 4.2 Options d’authentification Choisissez le mécanisme d’auth selon *qui ou quoi agit*. | Option | Pour qui | À choisir quand | | --- | --- | --- | | **Workload identity federation** | Systèmes / CI s’exécutant dans un cloud (K8s, AWS, Azure, GCP, OCI, GitHub Actions, SPIFFE, X.509) | Une charge automatisée doit s’authentifier sans secret à longue durée de vie | | **Comptes de service** | Identités non humaines, détenues par l’org | Une automatisation ou un bot partagé agit pour le compte de l’org, pas d’une personne | | **Personal access tokens (PAT)** | Un usage individuel et scriptable | Une personne a besoin d’un token pour son propre accès scripté | ```text 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) ``` :::tip[Signal d’évaluation] `CI / Kubernetes / GitHub Actions authenticating without a stored secret` → **workload identity federation**. `Shared bot / org automation` → **compte de service**. `A person's own script` → **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. | Contrôle | Ce qu’il gouverne | | --- | --- | | **Groupes & provisioning** | Qui est dans l’espace de travail et comment on l’ajoute/le retire (cycle de vie de l’utilisateur) | | **Rôles & permissions d’espace de travail** | Ce que chaque membre peut faire — admin vs membre vs restreint | | **GPTs & partage** | Ce qui peut être créé et partagé, et avec qui | 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. | Surface | À utiliser pour | | --- | --- | | **Workspace analytics** | Une vue dashboard de l’adoption et de l’usage | | **Analytics API** | Accès programmatique aux données d’usage/d’adoption pour votre propre reporting | 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. | Surface | Ce qu’elle fournit | | --- | --- | | **API de compliance & audit events** | Un enregistrement des actions pour la compliance et l’investigation | | **Configuration HIPAA** | Configuration pour les charges traitant des informations de santé protégées | 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. :::tip[Signal d’évaluation] `Prove who did what, investigate an incident` → **API de compliance / audit events**. `Protected health information` → **configuration HIPAA**. `Report adoption programmatically` → **Analytics API**. ::: ## 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. | Capacité | Ce qu’elle fait | | --- | --- | | Scans / deep scans | Trouver des vulnérabilités dans le code | | Security workbench | Trier les résultats | | Triage, correctifs, durcissement | Passer de résultat → correctif → code durci | | Rapports de vulnérabilité | Communiquer le risque | | Intégration CI / GitLab CI | Exécuter l’analyse dans le pipeline | | Modèles de cyber-safety & accès de confiance | Travail de sécurité gouverné et attentif à la sûreté | ```text 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)** : **R**ollout config, **O**wnership (auth), **S**cope (rôles), **A**udit. | Étape | Question | Le mouvement | | --- | --- | --- | | **Rollout config** | Les réglages sont-ils cohérents dans l’équipe ? | Configuration managée : disponibilité des modèles, permissions, extensions autorisées | | **Ownership (auth)** | Qui ou quoi s’authentifie ? | Workload identity pour les charges CI/cloud ; comptes de service pour les automatisations d’org ; PAT pour les individus | | **Scope (rôles)** | Qui peut faire quoi ? | Groupes + provisioning + rôles et permissions au moindre privilège | | **Audit** | Peut-on le prouver et le mesurer ? | API de compliance / audit events ; workspace analytics + Analytics API ; Codex Security en CI ; config HIPAA où requis | ## Erreurs courantes | Erreur | Pourquoi elle survient | À faire à la place | | --- | --- | --- | | Laisser chaque ingénieur configurer son propre Codex | Le plus rapide vers « tout le monde l’a » | Utiliser la configuration managée pour des réglages cohérents | | Utiliser un PAT pour un pipeline CI | C’est le token que vous connaissez | Les charges CI/cloud utilisent la workload identity federation (pas de secret à longue durée de vie) | | Utiliser un compte personnel pour un bot partagé | Il est déjà en place | Utiliser un compte de service pour l’automatisation détenue par l’org | | Donner l’admin à tout le monde | Moins d’erreurs de permission | Moindre privilège : peu d’admins, la plupart membres, permissions selon la responsabilité | | Aucune piste d’audit | Elle n’a pas été mise en place | Activer l’API de compliance et les audit events dès le premier jour | | Analyses de sécurité manuelles et occasionnelles | Quelqu’un s’en souviendra | Intégrer Codex Security dans la CI / GitLab CI pour que le code soit analysé avant merge | | Supposer que l’« usage interne » ne nécessite pas de config HIPAA | La donnée paraît confinée | Les PHI exigent la configuration HIPAA indépendamment du cadrage interne | | Mesurer l’adoption par anecdote | Les dashboards paraissent optionnels | Utiliser les workspace analytics et l’Analytics API pour de vrais chiffres | | Laisser le provisioning manuel | Petite équipe aujourd’hui | Automatiser le provisioning pour que les partants perdent l’accès promptement | ## 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 | Piège | Pourquoi il est tentant | Le discriminant | | --- | --- | --- | | « Laissons les ingénieurs s’auto-configurer ; c’est plus rapide » | Ça supprime le travail admin | À l’échelle, ça cause de la dérive ; la configuration managée impose la cohérence | | « Utiliser un PAT pour le job CI » | C’est le token sous la main | Les charges CI/cloud utilisent la workload identity federation | | « Un compte personnel convient pour le bot partagé » | Déjà en place | L’automatisation d’org utilise un compte de service, pas une personne | | « Les PHI internes ne nécessitent pas de config HIPAA » | La donnée paraît confinée | Les PHI exigent la configuration HIPAA indépendamment du cadrage | | « On récupérera les données d’audit si on en a un jour besoin » | Effort de mise en place maintenant | Les audit events doivent être activés en amont pour avoir un enregistrement | | « Des chiffres d’adoption mensuels manuels conviennent » | Les dashboards paraissent optionnels | Utiliser les workspace analytics et l’Analytics API | | « Les analyses de sécurité peuvent être une étape manuelle » | Les gens s’en souviendront | Mettre Codex Security en CI / GitLab CI pour qu’il s’exécute avant merge | | « Donner l’admin à tout le monde pour éviter les erreurs de permission » | Moins de tickets de support | Moindre privilège ; les permissions selon la responsabilité | ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Essayez avant de révéler. A. Demander à chaque ingénieur de configurer son propre Codex de la même façon B. Une configuration managée définie de façon centralisée par l’admin C. Un document partagé décrivant les réglages D. Rien ; les valeurs par défaut conviennent **Réponse : B.** La configuration managée permet à un admin de définir et d’imposer des réglages de façon centralisée, évitant la dérive. L’auto-configuration (A) et un document (C) comptent sur des individus reproduisant les réglages à la main, et les valeurs par défaut (D) n’imposent pas la politique choisie par l’équipe. A. Un personal access token commité dans le dépôt B. La workload identity federation C. Un mot de passe admin partagé D. Un mot de passe de compte de service dans un fichier env **Réponse : B.** La workload identity federation permet aux charges cloud/CI de s’authentifier sans secret stocké à longue durée de vie. Un PAT commité (A) et un mot de passe dans un fichier env (D) sont des secrets stockés, et un mot de passe admin partagé (C) est à la fois un secret et un échec de gouvernance. A. Le compte personnel d’un ingénieur B. Un compte de service C. Une boîte mail de groupe D. Le PAT de l’admin **Réponse : B.** Un compte de service est une identité non humaine détenue par l’org, ce qu’une automatisation partagée devrait précisément utiliser. Un compte personnel (A) ou le PAT de l’admin (D) lie l’automatisation à un individu, et une boîte mail de groupe (C) n’est pas une identité d’auth. A. Aucune ; c’est interne B. La configuration HIPAA C. Seulement un modèle plus strict D. Désactiver Codex entièrement **Réponse : B.** Les charges traitant des informations de santé protégées exigent la configuration HIPAA. « Interne » (A) n’exempte pas les PHI, un modèle plus strict (C) n’est pas le contrôle de compliance, et désactiver Codex (D) est inutile quand la configuration HIPAA existe. A. Le dashboard des workspace analytics uniquement B. L’API de compliance et les audit events C. L’Analytics API D. `AGENTS.md` **Réponse : B.** L’API de compliance et les audit events fournissent l’enregistrement des actions utilisé pour la compliance et l’investigation. Le dashboard d’analytics (A) et l’Analytics API (C) servent à l’adoption/l’usage, et `AGENTS.md` (D) est une directive de dépôt. A. Le dashboard des workspace analytics B. Des anecdotes de quelques ingénieurs C. L’Analytics API pour du reporting programmatique D. Lire l’historique de shell de chaque ingénieur E. Deviner à partir du nombre de licences **Réponse : A et C.** Les workspace analytics (dashboard) et l’Analytics API (programmatique) sont les vraies surfaces de mesure. Les anecdotes (B), l’historique de shell (D) et les estimations par nombre de licences (E) ne sont pas des mesures d’adoption fiables. A. Comme une étape manuelle dont quelqu’un se souvient de l’exécuter B. En CI / GitLab CI via Codex Security C. Seulement après un incident D. Jamais ; le modèle est de confiance **Réponse : B.** Intégrer Codex Security dans la CI / GitLab CI garantit que le code est analysé avant merge automatiquement. Une étape manuelle (A) se saute, l’analyse post-incident (C) est trop tardive, et faire confiance au modèle sans analyse (D) est le risque à éviter. A. Aucun ; c’est efficace B. Cela viole le moindre privilège ; les permissions devraient correspondre à la responsabilité, avec peu d’admins et la plupart des ingénieurs comme membres C. Les admins ne peuvent pas coder D. Cela désactive les analytics **Réponse : B.** Accorder l’admin universel casse le moindre privilège et élargit le rayon d’impact des erreurs et compromissions. Ce n’est pas simplement efficace (A), les admins peuvent bien sûr coder (C), et cela ne désactive pas les analytics (D). A. Aucun problème ; les PAT sont pour l’automatisation B. Un PAT lie une automatisation d’org à une personne et casse quand elle part ; utiliser la workload identity federation ou un compte de service à la place C. Les PAT sont plus lents ; changer de modèle D. Utiliser le PAT de l’admin à la place **Réponse : B.** Un token personnel lie une automatisation d’org à un individu, créant une fragilité et un vide de gouvernance ; la workload identity ou un compte de service est l’identité correcte au niveau org. Les PAT sont pour les individus, pas l’automatisation d’org (A) ; le correctif n’est pas un changement de modèle (C) ; et utiliser le PAT de l’admin (D) a le même problème de compte personnel. A. `AGENTS.md` dans chaque dépôt B. Les contrôles managés plugin / connector / skill au niveau de l’espace de travail C. Les réglages locaux de chaque ingénieur D. Le sélecteur de modèle **Réponse : B.** Les contrôles plugin/connector/skill au niveau de l’espace de travail décident quelles extensions sont autorisées. `AGENTS.md` (A) est une directive par dépôt, les réglages locaux (C) sont par ingénieur et non gouvernés, et le sélecteur de modèle (D) sélectionne des modèles, pas des extensions. A. Choisir le modèle automatiquement B. Gérer qui est dans l’espace de travail et garantir que les partants perdent l’accès promptement (cycle de vie de l’utilisateur) C. Analyser le code D. Générer des rapports d’adoption **Réponse : B.** Les groupes et le provisioning gèrent l’appartenance et le cycle de vie de l’utilisateur pour que l’accès soit accordé et révoqué correctement. Ils ne sélectionnent pas les modèles (A), n’analysent pas le code (C, c’est Codex Security), et ne génèrent pas de rapports (D, ce sont les analytics). A. La configuration HIPAA pour les dépôts traitant des PHI B. Un large auto-approve pour accélérer les choses C. L’API de compliance et les audit events pour l’enregistrement des actions D. Désactiver les analytics pour la confidentialité E. Un unique compte admin partagé pour tout le monde **Réponse : A et C.** Une charge réglementée a besoin de la bonne configuration (HIPAA pour les PHI) et d’une piste d’audit (API de compliance et audit events). Un large auto-approve (B) augmente le risque, désactiver les analytics (D) supprime une supervision utile, et un compte admin partagé (E) détruit la responsabilité. A. Le CLI uniquement B. Le plugin, le CLI et le cloud C. Seulement après l’achat d’un produit séparé D. Uniquement dans l’extension IDE **Réponse : B.** Codex Security couvre le plugin, le CLI et le cloud, avec des scans, un triage en workbench, des correctifs et une intégration CI. Il n’est pas réservé au CLI (A) ni à l’IDE (D), et il fait partie de la surface de sécurité Codex plutôt que d’un achat entièrement séparé (C). A. La disponibilité des modèles d’espace de travail B. `codex exec` C. L’échelle de raisonnement D. Record & replay **Réponse : A.** La disponibilité des modèles d’espace de travail contrôle quels modèles l’espace de travail peut utiliser. `codex exec` (B) est un mode d’exécution, l’échelle de raisonnement (C) règle l’effort, et record & replay (D) capture des sessions — aucun ne restreint la disponibilité des modèles. ## 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 ».