OpenAI ne présente plus son modèle le plus récent comme une seule référence assortie de plusieurs vitesses. La famille GPT‑5.6 se compose de Sol, Terra et Luna : trois niveaux de capacité, de latence et de prix, auxquels s'ajoutent différents efforts de raisonnement et des modes agentiques.

Ce découpage rend le catalogue plus flexible, mais déplace une partie de la complexité vers les équipes. Choisir systématiquement Sol maximise la facture sans garantir le meilleur produit. Choisir Luna partout peut rendre certains workflows fragiles. La bonne unité de décision n'est plus l'application entière : c'est la tâche, son niveau de risque et le coût d'un échec.

Les trois modèles en un tableau

ModèlePositionnementPrix API entrée / sortie par million de tokensUsage de départ
GPT‑5.6 Solmodèle phare, raisonnement et tâches longues5 $ / 30 $problèmes complexes, recherche, code difficile, synthèse finale
GPT‑5.6 Terracompromis capacité, vitesse et coût2,50 $ / 15 $production courante, agents contrôlés, extraction et transformation
GPT‑5.6 Lunamodèle le plus rapide et économique1 $ / 6 $classification, routage, reformulation, grands volumes simples

Ces tarifs ne suffisent pas à calculer le coût d'un workflow. Un modèle deux fois moins cher qui produit davantage de tokens, recommence une tâche ou appelle trop d'outils peut coûter davantage au résultat utile. À l'inverse, Sol peut devenir économique s'il termine en un passage un travail qui exige plusieurs tentatives ailleurs.

Sol n'est pas le nouveau mode par défaut de ChatGPT

Dans les conversations ChatGPT classiques, GPT‑5.5 Instant reste le choix rapide par défaut. GPT‑5.6 Sol alimente les niveaux de raisonnement Medium, High et Extra High selon le forfait. La variante Pro cible les travaux difficiles et longs.

Terra et Luna ne sont pas sélectionnables dans une conversation ChatGPT standard. OpenAI les propose dans d'autres surfaces, notamment Codex, ChatGPT Work et l'API, avec une disponibilité qui dépend du plan. Cette distinction évite une fausse attente fréquente : voir trois noms dans une annonce ne signifie pas que chaque utilisateur les trouvera dans le même sélecteur.

Le déploiement reste progressif. Un compte éligible peut ne pas afficher immédiatement Sol, et un administrateur Business ou Enterprise peut contrôler l'accès dans son espace de travail.

Choisir à partir du coût de l'erreur

Une tâche à faible risque et facilement vérifiable mérite d'abord Luna. Classer un ticket, détecter une langue, extraire cinq champs ou reformuler un titre dispose d'une réponse attendue et d'un contrôle simple. Le débit et le prix dominent.

Terra correspond aux workflows dont la difficulté varie : répondre à partir d'une base documentaire, préparer une modification de code limitée, analyser un contrat selon une grille ou orchestrer quelques outils. Il devient le candidat naturel d'un test de production, à condition de mesurer les échecs par catégorie.

Sol se justifie lorsque la tâche combine plusieurs sources, une planification longue, des outils, des ambiguïtés et un coût d'erreur élevé. Une migration complexe, une enquête technique, une analyse scientifique ou la synthèse finale d'un agent peuvent bénéficier de sa capacité supplémentaire.

La règle utile est simple : utiliser le modèle le moins cher qui atteint le niveau de qualité et de fiabilité requis, puis escalader lorsque les signaux montrent qu'il ne suffit pas.

Le routage vaut mieux qu'un choix unique

Une architecture efficace peut répartir le travail :

  1. Luna classe la demande, extrait les contraintes et rejette les cas incomplets ;
  2. Terra traite le flux normal avec des outils et un format de sortie validé ;
  3. Sol reprend les cas incertains, longs ou sensibles ;
  4. un contrôle déterministe ou humain valide le résultat avant une action irréversible.

Le routage ne doit pas reposer uniquement sur l'intuition du modèle. Utilisez des règles observables : longueur du contexte, nombre d'outils, catégorie de données, score d'incertitude, échec d'un validateur, nombre de tentatives ou valeur financière de l'action.

Cette approche protège aussi la capacité. Les requêtes ordinaires ne monopolisent pas le modèle le plus lent, tandis que les cas difficiles disposent d'une voie d'escalade explicite.

Les benchmarks sont un point de départ fournisseur

OpenAI annonce des gains sur le code, le travail intellectuel, la navigation, l'utilisation d'ordinateurs, la cybersécurité et les sciences. L'entreprise affirme notamment que Sol produit de meilleurs résultats avec moins de tokens dans plusieurs évaluations et présente Terra et Luna comme compétitifs à des coûts inférieurs.

Ces chiffres proviennent du fournisseur et mélangent benchmarks publics, évaluations internes et retours de partenaires. Ils ne permettent pas de prévoir directement le taux de réussite sur un dépôt, des documents ou des utilisateurs particuliers.

Un test local doit conserver les mêmes entrées, outils, limites, validateurs et critères pour chaque modèle. Mesurez au minimum :

  • réussite complète de la tâche ;
  • erreurs factuelles ou structurées ;
  • tokens d'entrée et de sortie ;
  • latence médiane et au 95e percentile ;
  • appels d'outils et boucles inutiles ;
  • interventions humaines ;
  • coût par résultat accepté, pas seulement par requête.

Une vingtaine de cas représentatifs donne un premier signal. Un lancement progressif sur du trafic réel permet ensuite d'observer les demandes que le jeu de test n'avait pas anticipées.

Le cache change la facture des longs contextes

GPT‑5.6 introduit des points d'arrêt explicites du cache et une durée minimale annoncée de trente minutes. Les lectures de cache bénéficient d'une remise de 90 % sur l'entrée, tandis que les écritures sont facturées 1,25 fois le tarif d'entrée non mis en cache.

Le cache devient intéressant lorsque de nombreuses requêtes partagent une longue base stable : instructions, schéma d'outils, documentation ou corpus de référence. Il l'est moins si le préfixe change à chaque appel ou si la donnée n'est jamais réutilisée pendant la fenêtre disponible.

Placez les éléments stables avant les éléments variables, suivez le taux de cache réellement obtenu et évitez de gonfler le contexte au prétexte qu'il sera moins cher. Un token lu reste un token à traiter, avec un effet possible sur la latence et l'attention du modèle.

Programmatic Tool Calling et multi-agent

Dans l'API Responses, OpenAI propose un appel programmatique d'outils : le modèle peut écrire et exécuter en mémoire un programme qui coordonne plusieurs outils et traite leurs résultats intermédiaires. L'objectif est de réduire les allers-retours où chaque petit résultat revient dans le contexte du modèle.

Le mode multi-agent, initialement en bêta, permet de lancer des sous-agents en parallèle puis de synthétiser leur travail. Cette parallélisation peut accélérer une recherche composée de branches indépendantes, mais elle multiplie aussi les appels, les permissions et les points de défaillance.

N'utilisez pas plusieurs agents pour une tâche séquentielle simple. Réservez-les aux travaux réellement décomposables, fixez un budget global, limitez les outils de chaque rôle et journalisez les décisions utilisées dans la synthèse.

Les capacités cyber exigent des garde-fous

OpenAI publie une fiche système et affirme que GPT‑5.6 améliore fortement la détection et la correction de vulnérabilités. L'entreprise indique aussi avoir renforcé les contrôles pour les demandes biologiques et cyber à haut risque.

Pour une équipe de développement, un modèle plus capable ne justifie pas de lui donner directement les secrets, la production ou un réseau interne. Les analyses doivent s'exécuter dans un environnement isolé, avec des dépôts filtrés, des identités temporaires, des commandes autorisées et une revue des correctifs.

Les refus et contrôles supplémentaires peuvent également affecter des travaux légitimes. Un banc d'essai de sécurité doit donc mesurer à la fois les réponses dangereuses et les blocages injustifiés, sans tenter de contourner les protections.

Une stratégie de migration pragmatique

Ne remplacez pas un nom de modèle dans toute l'application en une seule fois. Commencez par enregistrer, pour chaque workflow, le modèle, l'effort, le nombre de tokens, la latence, les outils et le résultat du validateur.

Testez ensuite Luna sur les tâches déterministes à gros volume, Terra sur le flux principal et Sol sur un échantillon de cas complexes. Comparez le coût par succès et définissez les règles d'escalade. Gardez une voie de retour tant que les distributions d'erreurs ne sont pas stables.

GPT‑5.6 apporte davantage de choix, pas une réponse universelle. L'équipe qui gagnera le plus ne sera pas celle qui sélectionne le modèle le plus puissant partout, mais celle qui sait associer chaque niveau de capacité à une tâche mesurée, une permission limitée et un budget visible.