Codex : abonnement vs API pour accès, facturation et automatisation

La connexion avec ChatGPT convient au travail humain interactif dans Codex CLI, IDE, desktop ou les surfaces cloud lorsque le quota, l’appartenance au workspace et les contrôles disponibles relèvent déjà du plan. Une clé API OpenAI propre convient lorsque le workload doit être facturé à une organisation ou un projet API, disposer d’une frontière de dépenses distincte ou fonctionner via un processus orienté machine. Cela ne garantit pas des modèles, fonctionnalités, limites ou contrôles de données identiques : consignez la surface, le compte, le workspace, la méthode d’authentification, le modèle et le responsable de facturation avant le test.

Ne choisissez pas l’API simplement parce que la tâche est technique et ne déplacez pas un login ChatGPT personnel vers la CI simplement parce que le plan est déjà payé. Séparez d’abord pairing local, tâche cloud déléguée, code review, automatisation planifiée et intégration programmatique propre. Pour chaque classe, définissez identité, permissions, budget, preuves et condition d’arrêt. Le parcours le plus simple qui passe de manière reproductible les gates de qualité, d’autorité et de coût l’emporte.

• Humain, session locale ou IDE et quota du plan → commencez par la connexion ChatGPT.
• Projet API, credential de service, metering propre ou intégration d’application → évaluez une clé API ou workload identity.
• Codex cloud ou review → vérifiez séparément connexion du repository, politique du workspace et reçu d’usage.
• Mode mixte → interdisez le fallback silencieux du payeur et documentez le routing.

OpenAI sépare explicitement la connexion avec ChatGPT de l’utilisation de votre propre clé API. Après un changement de méthode d’authentification, ne vous fiez ni à un ancien prompt de terminal ni au simple fait qu’un abonnement soit actif. Conservez un reçu sans secrets : client et version, méthode d’authentification, label masqué d’organisation ou de workspace, modèle actif, repository, profil sandbox, timestamp et page d’usage où la facturation est attendue. Dans la CLI, vérifiez l’état courant avant le premier run significatif.

Construisez un test négatif dans un projet jetable : laissez un credential de test inactif dans un profil shell contrôlé et vérifiez que l’opérateur détecte l’écart avant exécution. N’écrivez jamais de token dans un log, screenshot, issue ou preuve éditoriale. Pour l’automatisation, utilisez l’identité projet ou service la plus étroite disponible, avec rotation et test de révocation ; une session OAuth humaine ne doit pas devenir silencieusement une identité machine partagée.

Codex avec un compte ChatGPT utilise le quota et la facturation du plan concerné ; les crédits supplémentaires disponibles et le comportement de reset dépendent du plan et du workspace. Codex avec votre propre clé API utilise la tarification API et les limites du projet API. Même lorsque les deux parcours mesurent des tokens, rate card, usage inclus, cache, frais d’outils, budget owner et facture de référence peuvent différer. Ne confondez pas une estimation de dashboard avec la facture financière.

Comparez le coût par tâche acceptée avec le même commit, le même ensemble de tâches, les mêmes instructions, la même classe de modèle, politique de raisonnement, frontière réseau et grille du reviewer. Enregistrez input, input cache, output, activité des tools, retries, workers parallèles, minutes de review, résultat accepté et interruption. Ne publiez pas une moyenne fournisseur comme prévision pour votre équipe. Si la tâche change entre les parcours ou si un run bénéficie d’un cache chaud, marquez la comparaison invalide et recommencez.

• Reçu du plan → workspace, quota ou pool de crédits, état de reset et artefact accepté.
• Reçu API → organisation, projet, modèle, usage, état du budget et source de facture.
• Achèvement inconnu → vérifiez d’abord l’état git et les effets de bord, puis décidez du retry.
• Changement de prix ou de modèle → mettez à jour le manifeste daté plutôt qu’une ancienne table mémorisée.

Codex local interactif peut demander une approbation, montrer un diff et travailler dans une sandbox à côté d’une personne. Une tâche cloud déléguée dépend du repository connecté, de l’environnement et des contrôles du workspace. `codex exec` non interactif, GitHub Action ou Codex SDK ajoutent output lisible par machine, durée maximale, concurrence, retries et risques de complétion partielle. Le même login ne rend pas ces surfaces opérationnellement équivalentes.

Créez un execution manifest pour chaque mode : source commit, chemins inscriptibles, politique réseau, source des secrets, commandes autorisées, politique d’approbation, schéma de sortie, timeout, clé d’idempotence, commandes de validation et autorité de merge. La facturation API facilite le metering projet mais ne limite pas automatiquement l’autorité shell. Une politique de workspace ChatGPT peut fournir des contrôles admin utiles, sans remplacer branch protection ni un gate de déploiement indépendant.

Pour Business, Enterprise ou Edu, vérifiez appartenance, rôle, disponibilité des modèles, configuration gérée, contrôles de données, connecteur repository et surface d’audit comme des entitlements distincts. Pour l’API, vérifiez rôles d’organisation et de projet, comptes de service, limites de dépense, permissions de modèle et cycle de vie des clés. Supprimer un seat ne prouve pas la révocation d’un credential API ; supprimer une clé API ne déconnecte pas un repository GitHub de Codex cloud.

Exécutez un test joiner-mover-leaver avec un utilisateur synthétique. Le joiner reçoit uniquement le repository et le mode nécessaires ; le mover perd l’ancien projet et l’ancienne politique ; le leaver perd le workspace ChatGPT, le projet API, la connexion repository, les credentials en cache et le schedule d’automatisation. Security conserve des reçus horodatés, pas des secrets. Tout chemin résiduel vers une écriture ou un run facturable bloque le rollout.

Choisissez 12 à 20 tâches représentatives : explication de repository, correction de bug, refactor multi-fichiers, réparation de tests, investigation de dépendances, review et refus correct faute de preuves suffisantes. La première semaine, exécutez-les via le parcours ChatGPT approuvé ; la seconde, via un projet API restreint. Figez commit, version client, classe de modèle, configuration, ordre des tâches et grille d’acceptation. Avant chaque run, capturez le reçu d’authentification ; après, le diff, les checks, l’état de complétion et la source de facturation.

Ajoutez des failure fixtures : quota épuisé, plafond budgétaire API, utilisateur révoqué, clé révoquée, refus réseau, refus d’approbation, timeout après modification possible et output machine corrompu. Le pilote passe lorsque l’attribution du payeur est reproductible, que les tâches critiques se terminent ou échouent en mode fermé, que finance peut réconcilier l’usage et que le reviewer ne constate pas de dégradation d’acceptation. Le résultat choisit un modèle opérationnel ; il ne prouve pas une supériorité universelle du produit.

• Freeze → commit, ensemble de tâches, classe de modèle, politique et critères d’acceptation.
• Observe → authentification, payeur, tokens ou quota, tools et état de complétion.
• Review → correction, régressions, temps de correction et qualité des preuves.
• Reconcile → reçu client contre dashboard de référence du plan ou de l’API.
• Decide → parcours le moins complexe qui passe les gates critiques.

Avant la migration, inventoriez configuration Codex, AGENTS.md, skills, serveurs MCP, variables d’environnement, connexions repository, environnements cloud, schedules d’automatisation, réglages de modèles et sources de policy. Ne copiez pas un credential entre parcours : réémettez-le depuis l’owner cible avec le scope minimal. Après le cutover, exécutez un canary read-only, vérifiez reçu d’authentification, sandbox, réseau et destination de facturation, puis seulement autorisez une tâche de patch.

Dans un modèle mixte, le routing doit être déterministe : par exemple pairing humain local via workspace sign-in, proposition CI via projet API et merge uniquement via branch protection. Interdisez le fallback vers une clé ou un compte personnel. Le rollback restaure le chemin d’authentification approuvé précédent, désactive les nouveaux schedules, révoque le nouveau credential et réconcilie usage en attente et effets de bord.

Consignez decision owner, classes de workload, surfaces requises, source d’identité, frontière de données, éligibilité des modèles, quota ou budget API, concurrence, besoins d’audit, politique d’approbation, scope repository, exit owner et date de review. Référencez la documentation officielle actuelle plutôt que de copier limites et prix modifiables. Marquez `unknown` toute valeur absente de votre compte ou contrat.

Choisissez le parcours ChatGPT s’il couvre les surfaces Codex interactives ou gouvernées requises avec un quota clair et un cycle de vie workspace. Choisissez le parcours API pour une frontière séparée de facturation programmatique et d’identité lorsque workload et conditions le permettent. Un parcours mixte n’est acceptable qu’avec routing explicite, budgets indépendants, isolation des credentials et révocation testée. Réévaluez après tout changement de plan, pricing, rate card, modèle, client, policy ou surface d’automatisation.