Connexion à des modèles tiers comme DeepSeek

📚 Navigation de la série : Le chapitre précédent 04 · Tarification et facturation a explicité la structure de coûts de Codex (abonnement vs facturation à l'usage). Ce chapitre aborde une alternative d'optimisation : substituer le modèle par défaut de Codex par un modèle tiers comme DeepSeek.

⚠️ Note préalable sur les limites de compatibilité : Codex étant un produit propriétaire d'OpenAI, sa documentation officielle n'encadre pas l'usage de modèles alternatifs comme DeepSeek. L'intégration de tiers est un cas d'usage communautaire s'appuyant sur la clé de configuration model_providers. La réussite de cette intégration dépend du protocole réseau exposé par le fournisseur tiers, ce qui constitue l'obstacle principal (détaillé à la section 03). Les paramètres officiels documentés sont signalés dans ce texte, les éléments spécifiques à DeepSeek reposant sur les tests de la communauté et étant sujets à évolution.

Voici un retour d'expérience pour situer les enjeux.

Un confrère : « Puisque tu as connecté DeepSeek sur Claude Code pour réduire les coûts, fais de même avec Codex. » Moi : « C'est ce que j'ai tenté d'abord... mais j'ai fait face à des erreurs 400 persistantes malgré une configuration correcte. » Le confrère : « Vraiment ? Il ne suffit pas de modifier le paramètre base_url ? » Moi : « Le fonctionnement de Codex diffère de celui de Claude Code. Leurs structures logiques sont distinctes. »

Ce point est crucial. Les guides en ligne décrivant le couplage de Codex et DeepSeek omettent fréquemment un élément technique indispensable : l'intégration de tiers dans Codex repose sur une logique différente de celle de Claude Code. Appliquer les méthodes de Claude Code à Codex conduit à des erreurs de protocoles. Ce chapitre détaille ces mécanismes.

À la fin de ce chapitre, vous obtiendrez :

• La distinction fondamentale entre l'intégration de tiers dans Codex et dans Claude Code
• Un tableau comparatif pour évaluer la pertinence de cette configuration
• Le comparatif des deux méthodes d'intégration (modification manuelle de config.toml vs proxy local)
• Un gabarit de configuration de model_providers, la validation d'accès et la résolution des pannes

---

01 La différence d'intégration entre Codex et Claude Code

Règle clé : Claude Code sélectionne ses modèles via des variables d'environnement, tandis que Codex s'appuie sur la section « fournisseurs de modèles » (model providers) de son fichier de configuration. De plus, Codex exige la conformité à un protocole réseau spécifique, invalidant de fait les API compatibles partielles.

Détails techniques :

L'utilitaire Codex est un client local — il interagit avec les fichiers et exécute les commandes, mais délègue l'analyse à un modèle distant. Par défaut, il s'adresse à la famille GPT d'OpenAI (la version recommandée étant gpt-5.5 ; source : documentation officielle Models).

Le couplage avec un tiers consiste à modifier cette cible de requête. La documentation officielle de Codex encadre cette possibilité :

« Vous pouvez également orienter Codex vers n'importe quel fournisseur ou modèle supportant les API Chat Completions ou Responses pour vos cas d'usage spécifiques. » (Traduit de la documentation officielle Models).

Analogie : Les formats de prises électriques. Claude Code fonctionne comme un adaptateur universel ; dès lors qu'un modèle tiers propose une API compatible avec la syntaxe d'Anthropic, la connexion s'établit. Codex s'apparente à un appareil exigeant un format de prise fixe — il ne gère que les protocoles Chat Completions et Responses d'OpenAI. De nombreux modèles alternatifs comme DeepSeek proposent des API compatibles avec la syntaxe d'OpenAI, ce qui permet théoriquement d'établir la connexion. Il existe cependant une contrainte technique :

La documentation officielle de Codex indique que le support de l'API Chat Completions est obsolète et sera retiré dans les versions futures (source : document Models). Codex bascule ainsi exclusivement vers l'API Responses. Cette spécification récente d'OpenAI n'est pas encore implémentée par la majorité des fournisseurs tiers.

C'est l'origine des blocages décrits en introduction : la compatibilité OpenAI annoncée par DeepSeek ne couvre pas nécessairement l'API Responses exigée par Codex.

💡 En résumé : Claude Code gère les modèles via variables d'environnement et protocole Anthropic ; Codex utilise le fichier config.toml et exige le protocole OpenAI (notamment l'API Responses) — évitez de transposer les méthodes d'intégration de l'un sur l'autre.

---

02 Évaluer l'opportunité de l'intégration d'un tiers

D'une manière générale, connecter un modèle tiers à Codex s'avère moins pertinent que dans le cas de Claude Code.

Les limites de la démarche tiennent à trois aspects :

1. Le taux de réussite est plus faible en raison des contraintes d'API (Responses API).
2. Les performances du modèle de base GPT-5.5 sont optimales pour les tâches d'agent de Codex (refactorisation, modifications globales), un modèle tiers pouvant présenter des comportements dégradés.
3. L'usage de Codex étant inclus dans l'abonnement ChatGPT Plus/Pro (voir chapitre 04), l'appel à une API trier ce facturée à la consommation génère un surcoût injustifié.

Voici le comparatif entre le modèle par défaut et les solutions tierces :

Critère	GPT Officiel (Par défaut)	Modèles tiers (ex. DeepSeek)
Coût	Élevé en facturation à l'usage	✅ Économique (tarif nettement inférieur)
Réseau	Exige un accès réseau stable aux serveurs OpenAI	✅ Accès direct selon la localisation du fournisseur
Intégration	Immédiate après connexion	⚠️ Risques d'incompatibilité de protocoles
Capacités d'agent	✅ GPT-5.5 optimal sur les tâches complexes	Adapté aux tâches courantes, limites sur l'analyse globale
Support	✅ Natif et documenté	❌ Expérimental
Stabilité	Stable au fil des mises à jour	⚠️ Soumis aux modifications d'API du tiers

La démarche présente donc des incertitudes techniques absentes de l'intégration sur Claude Code, limitant la pertinence de l'économie financière réalisée.

Cas d'usage justifiant l'intégration :

• ✅ Recommandé : Utilisateurs intensifs sans abonnement ChatGPT cherchant à optimiser leurs factures API, contraintes d'accès réseau aux serveurs d'OpenAI, ou démarche de test technique.
• ❌ À éviter : Abonnés ChatGPT (surcoût inutile), développeurs intervenant sur des architectures logicielles complexes (nécessitant les capacités de GPT-5.5), ou profils recherchant une configuration simple.

En conclusion, si déléguer les tâches courantes à DeepSeek est pertinent sur Claude Code, l'intégration reste peu recommandée sur Codex en raison de l'instabilité de la configuration.

💡 En résumé : L'intégration de tiers sur Codex présente un risque d'incompatibilité réseau absent de Claude Code. Les abonnés ChatGPT et les développeurs recherchant des solutions stables doivent privilégier le modèle par défaut.

---

03 Deux méthodes d'intégration : configuration manuelle ou proxy local

Deux démarches d'intégration sont envisageables :

Le schéma résume les options : l'accès direct par configuration exige la compatibilité du serveur distant, l'usage d'un proxy déportant la traduction de protocoles en local.

Méthode 1 : Modification de config.toml (Intégration native)

Les paramètres de Codex sont centralisés dans le fichier ~/.codex/config.toml (source : document de référence Configuration). Vous pouvez y déclarer un fournisseur de modèles personnalisé.

Analogie : Enregistrer un contact dans son répertoire. Par défaut, seul OpenAI figure dans votre liste de contacts. Pour joindre un tiers comme DeepSeek, vous devez renseigner sa fiche : nom, URL d'accès (base_url) et variable d'environnement contenant la clé d'authentification. Vous pouvez ensuite demander à Codex d'appeler ce nouveau contact.

Les paramètres clés à renseigner dans le fichier sont les suivants (source : document de référence Configuration) :

Paramètre	Description
model_providers.<id>.name	Nom d'affichage du fournisseur de modèles
model_providers.<id>.base_url	URL d'accès de l'API
model_providers.<id>.env_key	Nom de la variable d'environnement contenant la clé d'API
model_providers.<id>.wire_api	Protocole utilisé, seul responses étant supporté nativement
model_provider (Racine)	Identifiant du fournisseur actif (par défaut openai)
model (Racine)	Nom du modèle sélectionné

Note : Le paramètre wire_api exige la valeur responses. Si le fournisseur ciblé ne supporte pas l'API Responses d'OpenAI, cette intégration directe échouera.

⚠️ L'API de DeepSeek est compatible avec la syntaxe Chat Completions d'OpenAI. Sa compatibilité avec le protocole responses exigé par Codex dépend des implémentations respectives et doit être validée par vos propres tests. 配置语法是对的，但「对方接不接」不是这份配置能保证的。

Méthode 2 : Proxy local (Solution communautaire)

Pour contourner les incompatibilités de protocoles, la communauté utilise des serveurs intermédiaires : un processus local intercepte les requêtes Responses API de Codex, les convertit au format Chat Completions supporté par DeepSeek, et gère la conversion inverse pour la réponse. Pour Codex, l'échange s'effectue de manière transparente.

L'utilitaire open source CC Switch (disponible sur github.com/farion1231/cc-switch) implémente ce mécanisme : il exécute un proxy local et intègre des profils de configuration pour DeepSeek ou d'autres services tiers.

Après installation de CC Switch, accédez à la configuration via le bouton Add Provider :

Sélectionnez l'application cible (ici Codex), choisissez le fournisseur distant (ex. DeepSeek), renseignez votre clé d'API et sauvegardez. Le proxy CC Switch gérera la conversion de requêtes.

L'application propose des profils préconfigurés pour DeepSeek ou OpenRouter pour éviter la saisie manuelle des adresses d'API.

Analogie : Faire appel à un interprète. Codex s'exprime en anglais (protocole Responses), DeepSeek ne comprend que le français (Chat Completions). L'option 1 consiste à exiger du récepteur qu'il comprenne l'anglais. L'option 2 déploie un interprète (le proxy) entre les deux pour traduire les messages dans les deux sens.

Comparatif des deux approches :

Critère	Méthode 1 : config.toml	Méthode 2 : Proxy local
Officiel	✅ S'appuie sur les paramètres natifs	❌ Utilitaire communautaire
Compatibilité d'API	⚠️ Dépend du support de l'API Responses par le tiers	✅ Conversion transparente par le proxy (meilleur taux de réussite)
Difficulté	Saisie manuelle TOML sujette aux erreurs	Interface graphique simple
Transparence	Paramètres explicites	Ajoute un intermédiaire invisible en cas d'erreur
Flexibilité	Édition manuelle à chaque changement	Bascule de profil en un clic
Public cible	Développeurs souhaitant comprendre le flux	Profils recherchant une configuration rapide

Recommandation : privilégiez la méthode 1 pour comprendre les mécanismes sous-jacents, et optez pour la méthode 2 (proxy) pour un déploiement fonctionnel immédiat.

💡 En résumé : La configuration native (Méthode 1) est transparente mais soumise au support du protocole Responses ; l'usage d'un proxy (Méthode 2) offre une meilleure compatibilité mais ajoute une dépendance locale.

---

04 Pratique : gabarit de configuration de config.toml

Voici la structure de configuration de base pour l'intégration native. Notez que la compatibilité effective dépend du fournisseur d'API configuré.

Emplacement du fichier : ~/.codex/config.toml sous macOS/Linux, et C:\Users\NomUtilisateur\.codex\config.toml sous Windows. Créez le fichier s'il n'existe pas.

Étape 1 : Obtenir une clé d'API DeepSeek

1. Connectez-vous sur la Console DeepSeek.
2. Créez et copiez une clé d'API (au format sk-xxxxxxxx).

🔑 Sécurisez cette clé. Ne l'inscrivez pas en clair dans vos fichiers de configuration. Nous allons l'exporter dans une variable d'environnement.

Étape 2 : Exporter la clé dans l'environnement

Déclarez la clé dans une variable nommée DEEPSEEK_API_KEY :

macOS / Linux :

export DEEPSEEK_API_KEY=<你的 DeepSeek API Key>

Windows (PowerShell) :

$env:DEEPSEEK_API_KEY="<你的 DeepSeek API Key>"

Pour pérenniser cette variable, ajoutez la déclaration dans votre fichier .zshrc (Zsh) ou .bashrc (Bash) puis exécutez source, ou configurez-la dans les variables d'environnement de Windows.

Étape 3 : Déclarer le fournisseur dans config.toml

Éditez le fichier ~/.codex/config.toml :

# 顶层：告诉 Codex 这次用我们自定义的提供商和模型
model_provider = "deepseek"
model = "<DeepSeek 的模型名，以官方文档为准>"

# 自定义一个名为 deepseek 的模型提供商
[model_providers.deepseek]
name = "DeepSeek"
base_url = "<DeepSeek 的 API base_url，以官方文档为准>"
env_key = "DEEPSEEK_API_KEY"   # 引用上一步的环境变量名
# wire_api 不写则默认为 responses（官方唯一支持的值）

Explication des paramètres :

• model_provider = "deepseek" : Indique à Codex d'utiliser le profil deepseek déclaré ci-dessous au lieu d'OpenAI.
• model = "..." : Désigne le modèle cible. Consultez la documentation officielle de DeepSeek pour connaître l'identifiant actif.
• [model_providers.deepseek] : Section déclarant le nouveau profil d'accès.
• base_url : Point d'accès de l'API (consultez les documentations de DeepSeek).
• env_key = "DEEPSEEK_API_KEY" : Référence la variable d'environnement configurée à l'étape 2.

⚠️ Les paramètres de modèles et d'URL sont volontairement indiqués sous forme de gabarits car ils dépendent des caractéristiques techniques actives du fournisseur d'API.

Note : Les identifiants openai, ollama et lmstudio étant réservés par le système, évitez de les surcharger (source : document de référence Configuration).

💡 En résumé : L'intégration native exige d'exporter la clé d'API, de déclarer le profil sous model_providers dans config.toml et de l'activer à la racine du fichier. Le succès final dépend de la compatibilité des protocoles.

---

05 Valider le fonctionnement

Lancez ces contrôles avant de démarrer vos développements.

Vérification en deux étapes :

1. Contrôle visuel du modèle actif

Démarrez Codex et lancez la commande /model (source : document Models). Vérifiez que le modèle personnalisé est disponible dans les choix proposés.

codex

Saisissez :

/model

Note : Vous pouvez forcer le modèle au lancement avec l'option -m (ex. codex -m nom-du-modele, source : document Models).

2. Validation de requête

Formulez un prompt de test simple :

你好，用一句话回复确认你能正常工作。

Analyse du retour de la console :

Comportement	Cause probable	Résolution
Réponse cohérente affichée	✅ Connexion réussie	Configuration fonctionnelle
Erreur 401 / Échec d'authentification	Clé d'API incorrecte ou variable d'environnement non lue	Vérifier env_key et la déclaration de la variable dans le terminal
Erreur 400 / Incompatibilité de protocole	Incompatibilité avec l'API Responses	L'accès natif est impossible. Opter pour le proxy local (Méthode 2)
Message indiquant un modèle introuvable	Identifiant de modèle erroné	Consulter les documentations du fournisseur d'API

L'erreur 400 valide l'incompatibilité avec l'API Responses exigée par Codex. Si ce cas se présente, basculez vers la méthode du proxy local.

💡 En résumé : Valisez le profil avec /model puis lancez un prompt de test ; l'erreur 401 signale un problème de clé, l'erreur 400 une incompatibilité de protocole.

---

06 Configuration du niveau d'effort après connexion

Si la connexion est établie, vous pouvez configurer le niveau de raisonnement du modèle pour optimiser la consommation de tokens.

Le paramètre model_reasoning_effort accepte les valeurs minimal / low / medium / high / xhigh (selon la compatibilité du modèle distant ; source : document de référence Configuration) :

model_reasoning_effort = "medium"

Analogie : Le choix d'allocation de temps d'examen. Le mode low correspond à des réponses rapides et concises pour les questions courantes. Les modes high ou xhigh permettent au modèle de structurer son raisonnement sur des problèmes de fond. Limiter le niveau d'effort évite de consommer inutilement des tokens.

Recommandation : conservez le niveau medium par défaut pour préserver vos limites, et n'élevez le paramètre à high que pour les restructurations de code complexes.

Note : Le recours à un modèle tiers désactive certaines fonctionnalités dépendantes de l'infrastructure d'OpenAI (comme la recherche web indexée, source : document de référence Configuration).

💡 En résumé : Configurez le niveau d'effort via model_reasoning_effort — medium pour l'usage courant, high pour les tâches complexes ; certaines fonctions liées à l'infrastructure d'OpenAI seront inactives.

---

07 Résumé

L'intégration de modèles tiers comme DeepSeek sur Codex constitue une option d'optimisation financière intéressante mais expérimentale et plus complexe que sous Claude Code.

Étape	Rôle / Action clé
Différence logique	Codex s'appuie sur le protocole OpenAI (API Responses) et non sur la syntaxe Anthropic
Opportunité	Peu pertinent pour les abonnés ChatGPT ou en présence de développements complexes
Méthodes	Fichier config.toml (native) ou proxy local (CC Switch)
Configuration	Déclarer les variables sous model_providers dans config.toml
Validation	Contrôle visuel avec /model et prompt de test (les erreurs 400 signalant un conflit d'API)
Optimisation	Ajuster l'effort de raisonnement avec model_reasoning_effort

Vous disposez des bases pour configurer et valider l'accès à un modèle tiers, tout en sachant diagnostiquer les éventuelles incompatibilités de protocoles.

La réussite de la connexion dépend principalement de la compatibilité du protocole réseau exposé par le fournisseur tiers.

---

Le chapitre suivant 06 · Exécuter une première tâche débute la mise en pratique de l'agent. Vous y apprendrez à déléguer des modifications de code complexes à Codex sur votre machine.

Lectures recommandées

• Windows : environnement natif vs WSL
• Rédaction de prompts : formuler ses besoins pour Codex
• Sécurité et limites des droits d'écriture