Migrer depuis GPT-5.3, GPT-5.4 et la série o

Dernière leçon de ce cours, et la plus opérationnelle : que faire de vos usages et de votre code construits sur la génération précédente ? La réponse tient en deux mouvements. D’abord comprendre la logique de correspondance entre l’ancienne famille et la nouvelle — elle est plus simple qu’il n’y paraît. Ensuite dérouler une migration méthodique, parce que c’est précisément sur les migrations « évidentes » qu’on casse la production.

La logique de correspondance

Le changement conceptuel central, vous le connaissez depuis la leçon sur les niveaux de raisonnement : ce qui était un choix de modèle est devenu un réglage. L’ancienne génération vous faisait arbitrer entre des modèles généralistes (GPT-5.3, GPT-5.4) et des modèles de raisonnement (o3, o3-pro, o4-mini) ; la famille GPT-5.6 remplace cet arbitrage par un choix de gamme — Sol, Terra ou Luna — combiné à un niveau de raisonnement. La table suivante traduit cette logique cas par cas.

Prenez cette table pour ce qu’elle est : un point de départ, pas une loi. Elle reflète les positionnements annoncés des modèles, pas le comportement de vos prompts sur vos données. La seule correspondance fiable est celle que vos évaluations confirment — nous y revenons plus bas, parce que c’est le cœur de la méthode.

Dans ChatGPT (interface)

Si votre usage passe par l’interface, la migration est déjà faite pour vous : le sélecteur de modèles reflète la nouvelle famille. Les réflexes enseignés dans nos cours de prise en main restent entièrement valables — formuler clairement, donner du contexte, itérer. Ce qui a vieilli, ce sont les descriptions de modèles que ces cours mentionnent : « GPT-5.3 pour le quotidien, o3 pour le raisonnement » correspond à l’ancienne génération. Le choix se fait désormais entre membres de la famille GPT-5.6, et le raisonnement se dose au lieu de se choisir par modèle. Si vous formez des équipes, c’est le point à mettre à jour dans vos supports en priorité.

Dans votre code : la méthode en cinq étapes

Pour une base de code, la migration se déroule dans un ordre précis, et cet ordre n’est pas décoratif.

Commencez par inventorier les identifiants : cherchez gpt-5.3, gpt-5.4, o3 et o4-mini dans le code, mais aussi dans les fichiers de configuration et les variables d’environnement — c’est là que se cachent les identifiants qu’un simple grep du code source ne trouve pas. Tant que l’inventaire n’est pas complet, tout le reste est prématuré.

Vient ensuite le vrai travail de refonte : traduire « quel modèle » en « quel niveau de raisonnement ». Partout où votre code contenait une logique de routage — « si la tâche est complexe, appeler le modèle de raisonnement, sinon le modèle rapide » — remplacez le couple de modèles par un seul modèle et un paramètre reasoning variable. C’est une simplification bienvenue de votre architecture, mais elle demande de relire chaque point de routage, pas de faire un rechercher-remplacer.

Troisième étape, la plus souvent sautée et la plus coûteuse à sauter : rejouez vos évaluations. Les correspondances de la table ci-dessus sont des hypothèses. Mesurez la qualité, la latence et le coût sur vos cas réels avant de basculer quoi que ce soit en production. Une équipe qui migre sur la foi de la table et découvre en production qu’un flux critique répond différemment n’a pas gagné de temps — elle en a perdu, plus la confiance de ses utilisateurs.

Quatrième étape : recalculez le budget. Les prix ont changé — Sol à 5/30, Terra à 2/12, Luna à 0,20/1,20 — et, combinés aux niveaux de raisonnement, ils redéfinissent l’arbitrage coût/qualité de chaque flux. Un flux qui tournait sur o4-mini peut coûter moins cher sur Terra en raisonnement medium, ou plus cher : seul le calcul sur vos volumes réels le dira.

Enfin, évaluez le Programmatic Tool Calling — la leçon précédente lui est consacrée. Si vos agents enchaînent les appels d’outils, ce mécanisme peut réduire tokens et latence de façon substantielle, mais c’est un chantier d’architecture séparé de la simple bascule d’identifiants. Ne le mélangez pas avec la migration de base : faites d’abord fonctionner l’équivalence, puis optimisez.

Points clés à retenir

• Remplacez le couple « modèle rapide / modèle de raisonnement » par un modèle + un réglage
• Sol, Terra ou Luna : le choix se fait au rapport qualité/coût, pas à la fonctionnalité
• Aucune bascule de production sans rejouer vos évaluations
• Les prix et les niveaux de raisonnement redéfinissent le budget de chaque flux

Testez vos connaissances

Validez votre lecture des nouveautés OpenAI de l’été 2026.

La migration est le passage obligé — la leçon ci-dessus vous donne l’ordre des opérations, modèle par modèle.