Codex · Chapitre 5
Intégrer des modèles tiers comme DeepSeek
3 minutes de lecture
📚 Navigation de la série : Le chapitre précédent 〔04 Abonnements et facturation〕 détaillait la rentabilité des différents abonnements et modes de facturation sous Codex. Ce chapitre poursuit dans la thématique de l'optimisation des coûts en abordant une alternative avancée : remplacer le modèle de traitement de Codex par des modèles tiers comme DeepSeek. ⚠️ Précision importante (fonctionnalité expérimentale sujette à modification, à valider en pratique) : Codex est un produit développé par OpenAI, et la documentation officielle ne documente pas l'intégration de modèles comme DeepSeek. L'accès à des modèles tiers est une méthode communautaire s'appuyant sur l'option officielle de personnalisation des fournisseurs (
model_providers). Le succès et la stabilité de cette intégration dépendent de la compatibilité des protocoles d'API du fournisseur tiers, ce qui constitue la principale source d'erreur (détaillée au paragraphe 03). Les options de configuration et comportements par défaut décrits s'appuient sur la documentation officielle ; la section concernant DeepSeek repose sur les solutions communautaires validées en pratique. Les adresses d'API, noms de modèles et compatibilités de protocoles peuvent évoluer selon les spécifications de DeepSeek et de Codex.
Commençons par une discussion réelle que j'ai eue récemment :
Un collègue : « Tu as connecté DeepSeek à Claude Code pour économiser, pourquoi ne pas faire pareil avec Codex ? » Moi : « Je pensais que c'était aussi simple... mais après deux heures de configuration et des paramètres corrects, chaque requête renvoie une erreur 400. » Un collègue : « Ah bon ? Ce n'est pas juste une question de modifier l'URL
base_url? » Moi : « Codex et Claude Code ne fonctionnent pas de la même manière. Bien qu'ils se ressemblent, leur architecture sous-jacente est différente. »
En vérité, ce chapitre est l'une des alertes les plus importantes de cette série. De nombreux guides expliquent comment connecter Codex à DeepSeek, mais la majorité omet un aspect technique crucial : l'intégration de tiers dans Codex repose sur une logique de protocole totalement différente de celle de Claude Code. Calquer votre expérience de Claude Code se soldera par des erreurs de protocole. Ce chapitre détaille ce point de blocage.
Ce que vous obtiendrez après avoir lu ce chapitre :
- La distinction fondamentale entre l'intégration de tiers sous Codex et sous Claude Code (pour vous éviter des heures de recherche).
- Un comparatif d'aide à la décision pour évaluer l'intérêt de connecter des modèles tiers à Codex.
- Les avantages et inconvénients des deux méthodes d'intégration (modification manuelle du fichier
config.tomlou passage par un proxy tiers). - Un modèle de configuration complet
model_providers, la procédure de validation associée et le diagnostic des erreurs courantes.
01 La différence de gestion des modèles entre Codex et Claude Code
Retenez ce principe clé : sous Claude Code, le changement de modèle s'effectue via des variables d'environnement, tandis que sous Codex, il requiert la déclaration d'un fournisseur dans le fichier de configuration. De plus, Codex impose des contraintes strictes sur les protocoles d'API compatibles.
Détaillons le fonctionnement : Codex s'exécute localement dans votre terminal comme un client de développement. Il gère la lecture du code, l'appel des outils et le contexte, mais ne traite pas la réflexion de manière autonome. Pour chaque étape, il transmet une requête à un modèle de traitement (le modèle par défaut étant le modèle phare gpt-5.5 d'OpenAI, conformément à la documentation officielle).
Utiliser un modèle tiers consiste à modifier l'adresse de destination des requêtes de Codex pour l'orienter vers une autre API. Codex propose cette option de personnalisation :
Vous pouvez également orienter Codex vers tout fournisseur ou modèle compatible avec les protocoles Chat Completions ou Responses API pour répondre à vos besoins spécifiques. (Source : documentation officielle de Codex)
Analogie : Le format des prises électriques. Claude Code fonctionne comme un adaptateur universel : il suffit que l'API tierce présente une compatibilité avec le protocole Anthropic pour que la connexion s'établisse. Codex est plus restrictif sur le type de prise : il requiert uniquement les protocoles d'OpenAI (Chat Completions ou Responses API). Les modèles comme DeepSeek proposent des API compatibles OpenAI (Chat Completions), ce qui permet théoriquement d'établir la connexion. Cependant, un piège subsiste :
La documentation officielle de Codex stipule que le support de Chat Completions API est obsolète et sera retiré dans les prochaines versions. Codex oriente son architecture vers le protocole Responses API. Ce dernier étant un protocole récent propre à OpenAI, la majorité des plateformes tierces ne l'implémentent pas de manière complète.
C'est la raison du blocage mentionné en introduction : la compatibilité OpenAI annoncée par DeepSeek concerne le protocole Chat Completions classique et non le nouveau protocole Responses API requis par Codex.
💡 Résumé en une phrase : Claude Code utilise le protocole Anthropic via des variables d'environnement ; Codex utilise le protocole OpenAI (en privilégiant Responses API) via le fichier
config.toml. Évitez de calquer la configuration de Claude Code sur Codex.
02 Faut-il connecter des modèles tiers à Codex ?
Voici l'analyse des avantages et inconvénients pour vous guider :
Connecter des modèles tiers à Codex présente un intérêt limité par rapport à Claude Code. Cette conclusion s'appuie sur trois facteurs :
- La compatibilité de protocole est plus incertaine sous Codex (comme détaillé au paragraphe 01), ce qui peut bloquer l'intégration.
- Les performances de code du modèle phare GPT-5.5 de Codex sur les tâches complexes et les refactorisations importantes restent supérieures à celles des modèles alternatifs tiers.
- La formule d'abonnement OpenAI (Plus ou Pro) inclut déjà le quota d'accès à Codex (voir chapitre 04). Connecter une API tierce facturée à l'usage représente donc un surcoût inutile si vous disposez déjà de cet abonnement.
Tableau comparatif des solutions :
| Critère | Modèles GPT officiels (par défaut) | Modèles tiers / alternatifs (ex. : DeepSeek) |
|---|---|---|
| Tarification | Inclus dans l'abonnement ou facturation à l'usage | Économique sur les volumes de requêtes standard |
| Accès réseau | Requiert une connexion internet ouverte | Direct, sans contraintes géographiques pour les modèles locaux |
| Installation | Opérationnelle dès la connexion du compte | ⚠️ Risques d'incompatibilité de protocole d'API |
| Qualité de code | Performances optimales (GPT-5.5) | Adapté au code de routine, limites sur l'architecture complexe |
| Support technique | Support officiel complet | Expérimental, sans garantie de support |
| Pérennité | Garantie par les mises à jour de l'outil | Liée aux évolutions des protocoles et noms de modèles tiers |
Contrairement aux conclusions sur Claude Code où l'usage de modèles tiers permet de réaliser des économies importantes, l'intégration sous Codex comporte des contraintes de protocole qui limitent la viabilité de cette solution.
Profils d'utilisateurs concernés :
- Cas d'usage potentiel : développeurs réalisant de gros volumes de modifications simples de routine (code de base) souhaitant limiter les coûts de facturation de l'API, ou utilisateurs contraints par des limites d'accès géographique aux API officielles.
- Profils non recommandés : utilisateurs disposant déjà d'un abonnement OpenAI (double facturation), développeurs traitant des tâches complexes d'architecture de code, ou personnes recherchant une configuration simple et stable.
Personnellement, j'utilise fréquemment DeepSeek avec Claude Code pour les tâches courantes, mais je conserve les modèles officiels sous Codex. L'instabilité des protocoles de connexion de Codex rend l'optimisation des coûts peu intéressante face au temps passé en maintenance de configuration.
💡 Résumé en une phrase : La connexion de modèles tiers à Codex comporte des risques d'incompatibilité de protocole. Sauf besoin spécifique d'accès local ou de gros volumes de code simple, privilégiez l'utilisation des modèles officiels d'OpenAI.
03 Deux approches d'intégration : configuration manuelle vs proxy de traduction
Si vous décidez d'intégrer un modèle tiers, vous devez choisir votre méthode d'accès.
Le schéma ci-dessus résume les choix : les deux méthodes mènent au même résultat, mais la gestion de la compatibilité des protocoles reste l'étape clé de l'intégration.
Approche 1 : Modification du fichier config.toml (méthode officielle)
Codex centralise ses paramètres dans le fichier utilisateur ~/.codex/config.toml (voir documentation officielle). Vous pouvez y déclarer vos propres fournisseurs de modèles.
Analogie : Enregistrer un nouveau contact dans votre répertoire. Par défaut, Codex communique uniquement avec OpenAI. Pour interroger DeepSeek, vous devez renseigner sa fiche de contact dans le fichier de configuration : son nom, l'URL de son API (base_url) et la variable d'environnement contenant sa clé d'accès (API Key). Vous indiquez ensuite à Codex d'utiliser ce nouveau contact par défaut.
Voici les clés de configuration de la section model_providers (voir documentation officielle) :
| Option | Rôle |
|---|---|
model_providers.<id>.name | Nom d'affichage du fournisseur personnalisé |
model_providers.<id>.base_url | URL de l'API du fournisseur |
model_providers.<id>.env_key | Variable d'environnement contenant la clé API |
model_providers.<id>.wire_api | Protocole utilisé, seul le mode responses est supporté et configuré par défaut |
model_provider (parent) | Fournisseur actif sélectionné (par défaut openai) |
model (parent) | Modèle de traitement actif |
Notez la valeur de l'option wire_api : la documentation officielle stipule que le protocole responses est le seul supporté. C'est la limite de cette approche : si l'API tierce ne gère que les requêtes Chat Completions classiques sans supporter le format Responses API d'OpenAI, cette méthode officielle échouera.
⚠️ DeepSeek propose une API compatible avec la structure d'OpenAI, mais celle-ci cible principalement le protocole Chat Completions standard. La compatibilité avec le protocole
responsesde Codex dépend des versions des API actives et doit être validée par vos soins.
Approche 2 : Utilisation d'un proxy tiers de traduction de protocole (communautaire)
Pour lever les blocages de compatibilité de protocole, la communauté utilise un proxy local agissant comme traducteur de requêtes. Codex envoie ses requêtes au format standard d'OpenAI au proxy local, qui les convertit au format accepté par DeepSeek, puis effectue la conversion inverse pour la réponse.
L'outil open source et multiplateforme CC Switch (disponible sur GitHub github.com/farion1231/cc-switch) applique cette méthode : il configure un proxy local sur votre machine qui redirige les appels de Codex vers le fournisseur tiers de votre choix en gérant la conversion de protocole de manière transparente.
Après l'installation de CC Switch, accédez à la console et cliquez sur l'option de configuration des fournisseurs (« Add Provider »).
Sélectionnez Codex dans la liste des outils pris en charge sur la gauche pour afficher les paramètres associés sur la droite. Renseignez la clé API et sélectionnez le fournisseur tiers de destination (ex. : DeepSeek). CC Switch gère alors la traduction des flux réseau.
CC Switch intègre des configurations pré-paramétrées pour les principaux fournisseurs tiers (DeepSeek, OpenRouter, etc.), vous évitant de renseigner manuellement les URL d'API.
Analogie : L'utilisation d'un interprète. Codex s'exprime en anglais (protocole OpenAI) et DeepSeek en français. L'approche 1 suppose que DeepSeek comprenne directement l'anglais (support de Responses API). L'approche 2 place un interprète (le proxy local) entre les deux pour traduire les échanges en temps réel.
Comparatif des deux approches :
| Caractéristique | Approche 1 : Configuration manuelle | Approche 2 : Proxy local (ex. : CC Switch) |
|---|---|---|
| Support | Méthode officielle documentée | Solution communautaire tierce |
| Compatibilité | Liée au support du protocole responses par l'API | Traduction transparente des requêtes par le proxy |
| Complexité | Modification manuelle du fichier TOML | Interface graphique simplifiée |
| Diagnostic | Paramètres visibles et modifiables directement | Couche intermédiaire supplémentaire (boîte noire) |
| Souplesse | Configuration fixe par fichier | Changement rapide de fournisseur via l'interface |
| Profil cible | Utilisateurs souhaitant comprendre le fonctionnement | Utilisateurs recherchant une solution rapide à configurer |
Choisissez l'approche 1 pour appréhender la configuration des flux de Codex, et privilégiez l'approche 2 (proxy) pour obtenir un résultat fonctionnel rapidement sans gestion des protocoles d'API.
💡 Résumé en une phrase : La configuration manuelle (approche 1) est transparente mais soumise aux contraintes de protocole de l'API. Le proxy local (approche 2) simplifie la connexion en traduisant les requêtes en arrière-plan.
04 Pratique : configuration manuelle du fichier config.toml
Voici la structure de configuration à appliquer dans le fichier utilisateur pour l'approche 1. La compatibilité de la réponse dépend de l'API du fournisseur tiers utilisé.
Le chemin d'accès au fichier est ~/.codex/config.toml sous macOS/Linux, et C:\Users\NomUtilisateur\.codex\config.toml sous Windows. Créez le dossier et le fichier s'ils n'existent pas.
Étape 1 : Obtenir une clé API DeepSeek
- Accédez à la console d'administration DeepSeek Platform et connectez-vous.
- Créez une nouvelle clé API et enregistrez-la dans un espace sécurisé (clé au format
sk-xxxxxxxx).
🔑 Protégez votre clé API. Ne l'inscrivez pas en clair dans vos fichiers de configuration et ne la commitez pas sur Git. Nous allons l'appeler via une variable d'environnement.
Étape 2 : Déclarer la variable d'environnement
Associez votre clé à une variable d'environnement (ex. : DEEPSEEK_API_KEY) pour qu'elle soit lue par Codex sans apparaître en clair dans le fichier de configuration.
Sous macOS / Linux :
export DEEPSEEK_API_KEY=<votre_cle_api_deepseek>Sous Windows (PowerShell) :
$env:DEEPSEEK_API_KEY="<votre_cle_api_deepseek>"Cette déclaration temporaire est active uniquement dans le terminal courant. Pour la rendre permanente, ajoutez la commande dans votre fichier d'initialisation de shell (~/.zshrc sous macOS, ~/.bashrc sous Linux) ou dans les propriétés système des variables d'environnement sous Windows.
Étape 3 : Configurer le fournisseur dans le fichier config.toml
Éditez le fichier ~/.codex/config.toml et ajoutez les lignes suivantes :
# Configuration principale : associer le fournisseur et le modèle de traitement
model_provider = "deepseek"
model = "<nom_du_modele_de_deepseek>"
# Déclaration du fournisseur d'API personnalisé
[model_providers.deepseek]
name = "DeepSeek"
base_url = "<url_de_l_api_de_deepseek>"
env_key = "DEEPSEEK_API_KEY" # Nom de la variable d'environnement configurée à l'étape 2
# L'option wire_api prend par défaut la valeur "responses" si non renseignéeDescription des options :
model_provider = "deepseek": indique à Codex d'utiliser le fournisseur personnalisé déclaré ci-dessous à la place d'OpenAI.model: le nom du modèle de traitement à interroger (référez-vous à la documentation officielle de DeepSeek, les dénominations évoluant selon les versions).[model_providers.deepseek]: la section de configuration du fournisseur associé à l'identifiantdeepseek.base_url: l'URL d'API de destination fournie par DeepSeek.env_key: la clé de la variable d'environnement lue par Codex pour l'authentification.
Les identifiants internes openai, ollama et lmstudio étant réservés par le système, utilisez une dénomination personnalisée pour déclarer votre fournisseur.
💡 Résumé en une phrase : La configuration manuelle associe une variable d'environnement contenant la clé API à une section de fournisseur personnalisée déclarée dans
config.toml.
05 Procédure de validation de la connexion
Une fois la configuration appliquée, validez le bon fonctionnement de la liaison avant de commencer le développement.
1. Vérification du modèle actif
Lancez Codex et utilisez la commande slash /permissions ou /model (voir chapitre 30) pour confirmer que le modèle personnalisé est détecté par l'interface.
codexSaisissez la commande suivante dans la console interactive :
/modelVous pouvez également forcer le modèle au démarrage en utilisant l'option -m (ex. : codex -m <nom_modele>).
2. Validation de la réponse
Envoyez une requête simple de test dans la console interactive pour confirmer la réception de la réponse :
Bonjour, confirme en une phrase que tu fonctionnes correctement.Interprétation des retours :
| Statut de retour | Cause probable | Action corrective |
|---|---|---|
| Réponse correcte affichée | Connexion opérationnelle | Aucune, l'intégration est fonctionnelle |
| Code d'erreur 401 | Clé API invalide ou variable d'environnement non détectée | Vérifier le nom de la variable env_key et la validité de la clé API |
| Code d'erreur 400 | Incompatibilité de protocole d'API | Le fournisseur n'implémente pas Responses API. Passer à l'approche 2 (proxy) |
| Modèle non trouvé | Dénomination de modèle erronée | Vérifier la clé model dans la documentation du fournisseur |
Si une erreur 400 s'affiche, cela confirme l'incompatibilité de l'API du fournisseur avec le protocole Responses API de Codex. Inutile d'ajuster les paramètres de configuration : utilisez le proxy CC Switch (approche 2) pour contourner la restriction de protocole.
💡 Résumé en une phrase : Validez l'intégration avec la commande slash
/modelpuis lancez une requête de test simple. Une erreur 401 indique un défaut de clé API, une erreur 400 signale une incompatibilité de protocole.
06 Optimisation de l'intensité du raisonnement pour les modèles tiers
Si la connexion est établie, vous pouvez ajuster l'intensité du raisonnement de votre modèle personnalisé pour maîtriser la consommation de vos jetons.
Configurez l'option model_reasoning_effort (valeurs compatibles : minimal, low, medium, high, xhigh) dans le fichier config.toml :
model_reasoning_effort = "medium"Analogie : Adapter le temps de réflexion. Configurer une intensité faible (low) convient aux modifications simples de routine (rapides et économiques). Réservez l'intensité élevée (high) aux développements complexes pour éviter de consommer inutilement des ressources de calcul sur des tâches simples.
Notez que certaines fonctionnalités natives de Codex (comme la recherche réseau basée sur les index d'OpenAI) peuvent présenter des comportements altérés ou indisponibles lors de l'utilisation de modèles tiers. Conservez ces limites à l'esprit lors du développement.
💡 Résumé en une phrase : Configurez l'option
model_reasoning_effortsurmediumpar défaut pour optimiser vos coûts de traitement avec le modèle tiers.
Synthèse
Ce chapitre a présenté la méthodologie pour intégrer des modèles tiers dans Codex :
- Le fonctionnement technique : Codex requiert la compatibilité avec les protocoles d'OpenAI (en privilégiant Responses API) et diffère de la gestion de Claude Code.
- La prise de décision : connectez un modèle tiers si vous réalisez de gros volumes de code simple, et conservez les modèles officiels pour les tâches complexes.
- Le choix de la méthode : la modification de
config.toml(approche 1) est transparente mais sensible aux protocoles ; le proxy local (approche 2) simplifie la conversion des requêtes. - La configuration TOML : déclaration de la section
model_providersassociée aux variables d'environnement. - Le diagnostic de connexion : validation via la commande slash
/modelet interprétation des codes d'erreurs (401 pour la clé, 400 pour le protocole).
Vous êtes en mesure de : Évaluer l'opportunité d'intégrer un modèle tiers, choisir entre la configuration directe ou l'usage d'un proxy local, et structurer les paramètres de connexion associés.
Le chapitre suivant 〔06 Exécuter une première tâche〕 marque le début de la section pratique de ce guide : nous confierons une tâche de modification de code réelle à Codex pour analyser son comportement de développement.