Comment choisir son modèle : pour une même consigne, quel modèle devriez-vous lancer
📚 Navigation de la série : Le chapitre précédent 〔29 Intégrations Slack / Linear et SDK〕 traitait de l'utilisation avancée consistant à invoquer Codex ailleurs et à l'intégrer dans vos propres produits. Ce chapitre ramène l'attention sur une décision locale quotidienne : au moment où vous appuyez sur Entrée, quel modèle travaille pour vous en arrière-plan et avec quelle intensité. Le chapitre suivant 〔31 Techniques avancées et accélération〕 expliquera comment rendre l'ensemble du flux plus rapide et plus économique.
On dit souvent que « choisir le modèle le plus puissant est toujours la bonne solution », et j'y ai cru pendant longtemps.
Pendant un temps, j'ai verrouillé mon modèle par défaut sur gpt-5.5 et réglé l'intensité du raisonnement au maximum sur xhigh, pensant « régler le problème une fois pour toutes ». Jusqu'au jour où je lui ai demandé de renommer une variable de data en payload — une tâche manuelle de 30 secondes. Il lui a fallu près d'une minute de « réflexion approfondie » avant de s'exécuter. En observant l'animation de chargement du raisonnement, j'ai réalisé pour la première fois que le « plus puissant » pouvait être un peu ridicule.
En clair, le meilleur modèle n'est pas le plus puissant, c'est le plus adapté. Utiliser un modèle phare avec un raisonnement maximal pour corriger une simple faute de frappe, c'est comme utiliser une pelleteuse pour arracher un brin d'herbe : c'est lent, coûteux et cela montre que vous ne savez pas utiliser l'outil. Inversement, si vous devez restructurer tout un module et que vous choisissez un modèle léger pour aller vite, il risque de vous proposer une solution apparemment fonctionnelle mais contenant trois pièges cachés, et le temps nécessaire pour corriger les erreurs sera équivalent à temps perdu avec cinq exécutions avec un bon modèle.
Ce chapitre explique en détail comment choisir : les modèles actuellement disponibles dans Codex, un réglage plus immédiat que le changement de modèle (l'intensité du raisonnement), ainsi qu'un tableau de correspondance « cas d'usage → modèle + intensité » que j'utilise personnellement tous les jours. Après cela, vous ne serez plus perdu devant le panneau /model.
Ce que vous obtiendrez après avoir lu ce chapitre :
- Un cadre de décision sans avoir à mémoriser les paramètres : choisir un modèle revient à faire correspondre « la difficulté de la tâche » à « la puissance de calcul à investir ».
- Les rôles respectifs des modèles actuellement disponibles dans Codex, lequel est le modèle par défaut, et lesquels sont obsolètes.
- Un réglage souvent ignoré par les débutants, mais plus immédiat que le changement de modèle — l'intensité du raisonnement (reasoning effort).
- Un tableau de correspondance à copier-coller : « quel modèle pour quelle tâche + quelle intensité de raisonnement ».
- Quatre méthodes de basculement : modifier le modèle par défaut, démarrer avec un modèle spécifique, changer temporairement en cours de session, et configurer individuellement les sous-agents.
- Un guide pratique à suivre pour constater par vous-même la différence entre les différents niveaux pour une même consigne.
⚠️ Les noms des modèles et leur disponibilité peuvent varier selon les versions et les abonnements (par exemple, quel est le dernier modèle phare ou ceux accessibles avec votre compte). Ce chapitre enseigne la méthode pour évaluer et basculer. Les modèles spécifiques disponibles sont ceux listés dans votre panneau
/modellocal ; ne mémorisez pas les noms. Pour les commandes et les options de configuration, référez-vous à la documentation officielle de Codex.
01 Commençons par clarifier : choisir un modèle ne signifie pas « choisir le plus cher »
Pour faire simple : le choix d'un modèle consiste à faire correspondre « la complexité de la tâche » à « la puissance de calcul à allouer » — trop en faire est un gaspillage, pas assez mène à l'échec.
Beaucoup de gens (y compris moi-même à l'époque) supposent que « choisir le plus puissant est la meilleure option car ses capacités sont maximales ». L'erreur de ce raisonnement réside dans le fait qu'il ne prend en compte que la réussite de la tâche, en ignorant le temps d'attente et le coût. Pourtant, dans le développement réel, ces deux derniers facteurs se font sentir au quotidien :
- Vous effectuez des dizaines d'allers-retours avec Codex chaque jour ; si vous attendez 30 secondes de plus à chaque tour, cela représente près d'une demi-heure perdue à regarder un écran de chargement.
- Les abonnements ont des quotas et l'utilisation de clés API consomme directement de l'argent. Le coût par token des modèles phares est plusieurs fois supérieur à celui des modèles légers.
Par conséquent, avant de choisir un modèle, évaluez trois variables dans votre esprit :
Quelle est la complexité du travail ? Combien de temps puis-je attendre ? Le coût m'importe-t-il ? En équilibrant ces trois aspects, vous saurez rapidement quel modèle choisir.
| Votre situation | Orientation du choix |
|---|---|
| Travail difficile (architecture, refactorisation inter-modules, bugs complexes) | Utilisez le modèle phare, donnez-lui une intensité de raisonnement maximale, priorité à la précision |
| Travail simple (renommer, ajouter des commentaires, écrire une petite fonction) | Utilisez un modèle léger, intensité de raisonnement faible, priorité à la rapidité et à l'économie |
| Réponse instantanée requise (pair programming en temps réel, questions-réponses rapides) | Utilisez un modèle optimisé pour les réponses instantanées, pour éviter qu'il ne « réfléchisse trop longtemps » |
💡 Résumé en une phrase : Choisir un modèle ne consiste pas à prendre le plus fort, mais à adapter la puissance de calcul à la complexité de la tâche.
02 Quels sont les modèles actuellement disponibles dans Codex
En ouvrant le panneau /model, vous verrez une liste de noms qui peut sembler déroutante au premier abord. Pas d'inquiétude, mémorisez les rôles plutôt que les paramètres.
Analogie : Choisir un modèle, c'est comme attribuer une tâche à quelqu'un. Pour les tâches d'architecture difficiles, vous faites appel au développeur le plus expérimenté et le plus réfléchi (modèle phare) ; pour les petites modifications rapides, un stagiaire agile suffit (modèle léger) ; pour un pair programming interactif où chaque question appelle une réponse immédiate, vous choisissez le plus réactif (modèle instantané). Assigner la bonne personne rend le travail efficace ; se tromper conduit soit à gaspiller des ressources, soit à manquer de capacités.
Voici les rôles des différents modèles de Codex actuels :
| Modèle | Rôle | Idéal pour | Vitesse / Coût |
|---|---|---|---|
gpt-5.5 | Modèle phare, recommandé par défaut | Programmation complexe, actions système, travail de recherche, flux de recherche | Plus lent / Le plus cher |
gpt-5.4-mini | Léger, rapide et économique | Tâches de programmation légères, utilisation par les sous-agents | Rapide / Bon marché |
gpt-5.3-codex-spark | Instantané (aperçu de recherche) | Itérations de programmation à haute fréquence presque en temps réel (orienté texte brut, capacités plus limitées) | Très rapide / Bon marché |
Quelques points clés pour éviter les erreurs :
- Le modèle par défaut est utilisé si rien n'est spécifié. Si vous ne changez rien, Codex (application, CLI ou extension d'IDE) utilisera automatiquement le modèle phare recommandé, ce qui convient dans la plupart des cas.
gpt-5.3-codex-sparkest un aperçu de recherche (research preview), actuellement réservé aux abonnés ChatGPT Pro. Il est normal de ne pas le voir si vous n'avez pas cet abonnement, ce n'est pas un défaut d'installation.- Deux noms que vous avez pu voir dans d'anciens tutoriels sont désormais obsolètes :
gpt-5.2etgpt-5.3-codex. Ils ont été marqués comme obsolètes (deprecated) par l'authentification ChatGPT officielle. Si vos scripts, votre fichierconfig.tomlou vos commandescodex exec --modelles mentionnent encore, remplacez-les au plus vite. Certains modèles obsolètes peuvent rester accessibles via l'API avec une clé API, selon la page officielle des modèles de l'API.
Mon organisation personnelle la plus fréquente est : conserver le modèle phare pour la session principale, et déléguer les tâches répétitives simples à des sous-agents configurés avec gpt-5.4-mini. Le mois dernier, pour nettoyer les imports obsolètes dans plus de vingt fichiers d'un projet, j'ai demandé à l'agent principal de planifier le travail, et une dizaine de sous-agents ont modifié les fichiers en parallèle avec le modèle mini. Tout était terminé en quelques minutes. Pour ce genre de travail volumineux mais simple, la vitesse et le coût de mini font toute la différence, alors que le modèle phare aurait été un gaspillage de temps et d'argent.
💡 Résumé en une phrase : Mémorisez les rôles, pas les paramètres — le modèle phare pour le travail difficile, mini pour la rapidité et l'économie, spark pour l'instantané, et n'utilisez plus les deux noms obsolètes dans vos configurations.
En plaçant ces trois modèles sur un graphique « Complexité de la tâche × Vitesse et Coût », tout devient clair : plus on va vers le bas à droite, plus la tâche est complexe et plus le modèle est puissant mais lent et coûteux (modèle phare gpt-5.5) ; plus on va vers le haut à gauche, plus il est rapide et économique (mini, spark). Choisir un modèle revient à situer votre tâche sur ce graphique.
03 Un réglage plus immédiat que le changement de modèle : l'intensité du raisonnement
Les débutants se focalisent sur « quel modèle choisir », tandis que les utilisateurs expérimentés ajustent également un autre paramètre : l'intensité du raisonnement (reasoning effort). Beaucoup de gens l'ignorent, mais son impact sur l'expérience est souvent plus direct qu'un changement de modèle.
Analogie : L'intensité du raisonnement correspond au temps de réflexion accordé avant de répondre. Pour un même étudiant brillant (un même modèle), le laisser répondre en un coup d'œil produira un résultat très différent de celui obtenu en le laissant faire des brouillons et vérifier ses calculs — mais cette dernière méthode sera bien plus lente. L'intensité du raisonnement règle précisément ce temps de réflexion.
L'intensité du raisonnement dans Codex comporte cinq niveaux (uniquement pour les modèles compatibles et via l'API de réponses) :
| Niveau | Signification | Adapté à |
|---|---|---|
minimal | Presque aucune réflexion supplémentaire, réponse instantanée | Tâches ultra-simples, questions-réponses fréquentes |
low | Analyse rapide | Modifications simples, itérations rapides |
medium | Équilibre entre vitesse et profondeur (souvent le niveau par défaut) | Majorité des tâches de programmation quotidiennes |
high | Raisonnement approfondi | Refactorisations complexes, bugs tenaces |
xhigh | Raisonnement maximal (selon la compatibilité du modèle) | Architecture et débogage les plus complexes |
Notez deux points : medium est généralement le point de départ par défaut (la valeur par défaut dépend de votre version locale) ; xhigh n'est pas supporté par tous les modèles. Pour vérifier si vous pouvez l'utiliser, sélectionnez-le dans le panneau /model. S'il n'est pas supporté ou s'il provoque une erreur, le panneau l'indiquera, ou vous pouvez consulter la documentation officielle du modèle.
C'est ce qui explique le problème mentionné au début (« attendre une minute pour renommer une variable ») : le modèle n'était pas inefficace, c'est moi qui avais réglé le raisonnement sur xhigh, l'obligeant à réfléchir intensément pour une tâche qui ne le nécessitait pas. À l'inverse, un jour où je cherchais un bug de concurrence intermittent, le niveau standard tournait en rond sans trouver. J'ai augmenté l'intensité à high et relancé la tâche ; le modèle a alors pu analyser en profondeur la logique pour identifier précisément la situation de compétition (race condition).
Ainsi, si vous n'êtes pas satisfait du résultat, ne vous précipitez pas pour changer de modèle : souvent, augmenter l'intensité du raisonnement d'un niveau suffit. Si c'est trop lent, baissez-la d'un niveau. Ce réglage est plus léger et plus rapide à tester qu'un changement de modèle.
💡 Résumé en une phrase : Avant de changer de modèle, pensez à l'intensité du raisonnement — augmentez-la s'il manque de pertinence, baissez-la s'il est trop lent. C'est souvent la solution.
04 Tableau de correspondance pratique : quel modèle et quelle intensité pour quel travail
Les explications théoriques sont utiles, mais une recette concrète l'est encore plus. Voici le tableau de correspondance « cas d'usage → modèle + intensité de raisonnement » que j'utilise au quotidien. Vous pouvez le copier et l'adapter à vos habitudes :
| Cas d'usage | Modèle recommandé | Intensité du raisonnement |
|---|---|---|
| Conception d'architecture, choix technologiques | gpt-5.5 | high / xhigh |
| Refactorisation inter-modules, modifications complexes | gpt-5.5 | high |
| Débogage de bugs complexes ou intermittents | gpt-5.5 | high |
| Écriture de code et logique au quotidien | gpt-5.5 | medium |
| Correction de petits bugs, formatage, commentaires | gpt-5.4-mini | low |
| Traitement par lots de tâches simples par des sous-agents | gpt-5.4-mini | low / medium |
| Itérations rapides et interactives en temps réel | gpt-5.3-codex-spark | minimal |
Comment utiliser ce tableau ? Ne vous compliquez pas la vie au début : commencez avec la configuration quotidienne (modèle phare + medium), puis ajustez selon les besoins spécifiques :
- Si la solution proposée est trop superficielle et manque des cas limites → augmentez l'intensité à
high. - Si de nombreuses tâches simples et répétitives vous ralentissent → passez à
gpt-5.4-miniavec une intensité plus faible pour un traitement par lots. - Si vous souhaitez poser plusieurs petites questions rapidement sans attendre sa réflexion → utilisez le modèle instantané et le niveau
minimal.
Mon habitude consiste à conserver la configuration par défaut « modèle phare + medium », qui convient pour la grande majorité des tâches. Je ne change manuellement que pour les phases de « réflexion intense » ou de « traitement par lots ». Considérez ce réglage comme un outil spécifique dans votre boîte à outils : utilisez-le quand c'est nécessaire, sans vous poser de questions à chaque fois.
💡 Résumé en une phrase : Utilisez par défaut la combinaison « modèle phare + medium » et ne changez manuellement que pour les tâches complexes ou les gros volumes de tâches simples.
05 Quatre méthodes de basculement : par défaut, au démarrage, en cours de session, ou par sous-agent
Une fois le choix fait, il faut savoir comment l'appliquer. Codex propose quatre méthodes pour répondre à tous les cas de figure, du réglage permanent à l'usage unique.
① Définir le modèle par défaut (permanent). Ajoutez cette ligne dans votre fichier de configuration ~/.codex/config.toml pour que chaque démarrage l'utilise :
# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"② Spécifier temporairement au démarrage (pour la session en cours). Utilisez l'option -m ou --model :
# Démarrer une nouvelle session avec un modèle spécifique
codex -m gpt-5.5
# Fonctionne également en mode non interactif avec codex exec
codex exec -m gpt-5.4-mini "Nettoyer les imports obsolètes dans ce fichier"③ Changer en cours de session (changement à la volée). Tapez directement la commande slash suivante dans votre session Codex pour ouvrir le sélecteur et changer de modèle :
/modelLe nouveau panneau /model permet généralement de choisir à la fois le modèle et l'intensité du raisonnement. L'affichage exact dépend de votre version locale.
④ Configurer individuellement pour un sous-agent (délégation). L'agent principal utilise le modèle phare pour planifier et délègue les tâches simples à des sous-agents exécutant gpt-5.4-mini — c'est la stratégie la plus rentable. Voir les détails dans 〔21 Sous-agents (Subagents)〕.
Comparatif des quatre méthodes :
| Méthode | Action | Portée | Cas d'usage |
|---|---|---|---|
| Par défaut | Modifier model dans config.toml | Toutes les sessions futures | Définir votre modèle principal stable |
| Au démarrage | codex -m <modele> | Uniquement la session en cours | Lancer une tâche ponctuelle avec un autre modèle |
| En cours de session | /model | Après le changement | Changer de modèle à la volée en cours de route |
| Par sous-agent | Spécifier dans la configuration du sous-agent | Uniquement ce sous-agent | L'agent principal supervise et délègue les tâches simples |
⚠️ Exception : Les tâches Codex Cloud exécutées dans le cloud ne permettent pas de modifier le modèle par défaut actuellement, cette règle dépend des spécifications officielles.
💡 Résumé en une phrase : Modifiez le fichier config pour le long terme, utilisez
-mpour un démarrage temporaire, tapez/modelpour changer en cours de session, et attribuez le modèle mini aux sous-agents pour les tâches secondaires.
06 Deux options d'optimisation supplémentaires
Une fois le modèle et l'intensité configurés, deux options supplémentaires permettent d'affiner l'expérience. Elles sont utiles à connaître mais pas indispensables au début.
① Résumé du raisonnement (model_reasoning_summary) — contrôle l'affichage du cheminement de pensée. Les valeurs possibles sont auto / concise / detailed / none. Choisissez detailed pour voir toutes les étapes de réflexion, ou none pour masquer ce contenu et éviter d'encombrer l'écran :
# ~/.codex/config.toml
model_reasoning_summary = "concise"② Niveau de service (service_tier) — définit la priorité de vos requêtes. Les valeurs sont flex (flexible, optimisation du coût, peut être légèrement plus lent) et fast (vitesse prioritaire). Si vous êtes pressé et que le coût vous importe peu, vous pouvez essayer fast — notez que cela nécessite d'activer également une option expérimentale (feature flag) pour fonctionner :
# ~/.codex/config.toml
# Mode flexible (par défaut)
service_tier = "flex"
# Mode rapide : nécessite d'activer le feature flag correspondant pour être effectif
service_tier = "fast"
[features]
fast_mode = trueCes deux paramètres relèvent de l'optimisation pour les utilisateurs avancés. Les débutants peuvent conserver les valeurs par défaut sans problème.
💡 Résumé en une phrase : Le résumé du raisonnement gère l'affichage de la réflexion, le niveau de service gère la priorité de passage, laissez les valeurs par défaut au début.
07 Pratique : observez la différence entre les niveaux pour une même consigne
La théorie est une chose, mais manipuler les réglages vous permettra de mieux en appréhender l'impact. Ces trois étapes prennent moins de cinq minutes.
Étape 1 : Vérifiez les modèles disponibles sur votre compte.
Dans une session Codex, tapez :
/modelRésultat attendu : Un sélecteur s'affiche, listant les modèles disponibles pour votre compte / abonnement actuel (la liste varie d'un utilisateur à l'autre). Identifiez les modèles présents et celui actuellement actif.
Étape 2 : Définissez une configuration par défaut.
Ouvrez le fichier ~/.codex/config.toml (créez-le s'il n'existe pas) et écrivez :
model = "gpt-5.5"
model_reasoning_effort = "medium"Enregistrez et ouvrez une nouvelle session. Tapez /model pour vérifier que le modèle et l'intensité correspondent bien à vos nouveaux réglages par défaut.
Étape 3 : Lancez la même consigne avec deux intensités différentes pour comparer.
Choisissez une demande nécessitant un peu de réflexion, par exemple : « Aide-moi à refactoriser cette fonction pour la rendre plus facile à tester, et explique tes choix. »
- Exécutez-la d'abord avec le niveau
mediumpar défaut. Observez le temps d'attente et la pertinence de la solution. - Modifiez la configuration pour passer
model_reasoning_effortàhigh, ouvrez une nouvelle session et relancez exactement la même consigne.
Vous devriez constater que l'exécution avec high est nettement plus lente, mais que la solution proposée est souvent plus fouillée (prise en compte de cas limites supplémentaires, présentation d'alternatives ou explications détaillées). Vivre cette expérience de compromis entre rapidité et profondeur vous aidera à choisir le bon réglage intuitivement par la suite.
💡 Résumé en une phrase : Utilisez le sélecteur pour voir vos modèles, modifiez le fichier de configuration pour fixer les valeurs par défaut, puis comparez deux niveaux différents avec la même consigne pour vous faire la main.
Synthèse
Ce chapitre a décomposé le choix du traitement en deux réglages complémentaires et une méthode de travail :
- Le principe du choix : Adapter la puissance de calcul à la complexité de la tâche. Le meilleur modèle n'est pas le plus fort, c'est le plus adapté.
- Les modèles actuels :
gpt-5.5(phare) pour le travail complexe,gpt-5.4-minipour la rapidité et l'économie,gpt-5.3-codex-sparkpour le temps réel ; n'utilisez plus les versions obsolètesgpt-5.2etgpt-5.3-codex. - L'intensité du raisonnement est un atout clé : Augmentez-la si le modèle manque de discernement, baissez-la pour gagner du temps. C'est souvent plus efficace que de changer de modèle.
- Un tableau de correspondance et une règle simple : Utilisez par défaut la combinaison « modèle phare +
medium», et ne changez manuellement que pour les tâches complexes ou les gros volumes de tâches simples. - Quatre méthodes de basculement : Par configuration permanente, au démarrage, à la volée en cours de session, ou par configuration de sous-agent.
Vous êtes maintenant capable de : Ouvrir le panneau /model sans hésitation, évaluer en un coup d'œil le modèle et l'intensité nécessaires pour votre tâche, et effectuer le basculement selon la méthode la plus appropriée.
Le chapitre suivant 〔31 Techniques avancées et accélération〕 pousse la démarche plus loin : nous verrons comment optimiser l'ensemble du flux pour le rendre plus rapide, plus économique et limiter les corrections. D'ici là, une question : avez-vous remarqué que les ralentissements proviennent souvent d'un contexte désordonné qui égare le modèle, plutôt que d'un manque de puissance de ce dernier ? C'est précisément le sujet de notre prochain chapitre.