Ilustración editorial para GPT-6 Sol y Luna: qué anuncia OpenAI y qué falta comprobar
Imagen generada con gpt-image-2.5-sunburst para InferamaSource ↗
01

OpenAI élargit la famille GPT-6 avec Sol et Luna

OpenAI a présenté GPT-6 Sol et GPT-6 Luna comme de nouveaux modèles de son catalogue. L’entreprise les inscrit dans une stratégie qui cherche à concilier capacités et coût de service ; elle ne les décrit pas simplement comme deux noms désignant une seule et même option. Cette distinction compte pour les équipes qui choisissent un modèle en fonction de la tâche à accomplir. Toutefois, les informations fournies ne permettent ni d’attribuer à chacun une liste exhaustive de fonctionnalités, ni d’établir une comparaison indépendante de leurs capacités.

Dans sa communication officielle, OpenAI évoque des améliorations de l’infrastructure, de la mise en cache et de l’inférence pour expliquer la baisse des coûts. L’entreprise affirme également répercuter ces économies sur ses clients en réduisant ses prix. Il s’agit de l’explication d’OpenAI concernant sa propre offre, et non d’un audit externe de ses coûts d’exploitation ou d’une garantie que chaque application dépensera dans la même proportion.

Il convient donc de distinguer trois sujets : la place qu’OpenAI attribue à chaque modèle, les tarifs qu’elle publie pour l’utilisation de l’API et les résultats obtenus par un système donné en production. Les deux premiers peuvent être vérifiés dans la documentation de l’entreprise ; le troisième nécessite des essais portant sur les tâches, les consignes et les limites propres à l’équipe qui évalue les modèles.

02

La baisse annoncée et sa base de comparaison

OpenAI affirme que les prix de l’API pour Sol et Luna sont inférieurs de 50 % aux prix promotionnels de GPT-5.6. La référence mérite attention : cela ne signifie pas nécessairement que les deux modèles coûtent moitié moins cher que n’importe quel tarif antérieur de GPT-5.6. La comparaison formulée par l’entreprise porte sur un tarif promotionnel précis. Il ne faut pas la transformer en comparaison avec les tarifs standard, avec le coût total d’une application ou avec les modèles d’autres fournisseurs.

Les pages officielles consacrées aux tarifs et aux modèles sont les sources à consulter pour connaître les montants en vigueur, les unités facturées et les modalités de service. Les éléments fournis pour rédiger cet article ne comprennent pas les chiffres précis des tarifs d’entrée et de sortie de Sol et Luna ; il ne serait donc pas rigoureux de reprendre des montants. En outre, un tarif publié ne suffit pas à déterminer le coût réel d’une tâche : celui-ci dépend du volume de texte traité, des réponses générées, de l’utilisation de la mise en cache et de la configuration de chaque requête.

Pour établir un budget, une équipe devrait calculer les coûts à partir de son propre profil d’utilisation plutôt que d’appliquer mécaniquement le pourcentage annoncé. Une tâche peut nécessiter davantage de jetons, de nouvelles tentatives ou de vérifications humaines avec un modèle ; elle risque alors de coûter plus cher, même si son tarif unitaire est plus bas. À l’inverse, un tarif supérieur peut se justifier s’il réduit les étapes ultérieures, à condition que cet avantage soit mesuré lors d’un test représentatif.

Comment interpréter les comparaisons de coûts

Avant toute comparaison, définissez une unité et une charge de travail identiques. La baisse annoncée par OpenAI ne remplace pas ce calcul.

ComparaisonCe qu’elle permet de conclureCe qu’elle ne permet pas de conclure
Tarifs publiés pour l’entrée et la sortieLe montant facturé pour les usages couverts par ces tarifs, d’après la documentation en vigueur.Le coût total d’une tâche comprenant de nouvelles tentatives, des outils ou une supervision.
Baisse de 50 % annoncéeLa réduction qu’OpenAI déclare par rapport aux prix promotionnels de GPT-5.6.Que chaque facture ou application coûtera exactement moitié moins.
Coût d’une tâche donnéeLa dépense observée pour une charge de travail définie et une configuration précise.Que le résultat sera le même pour d’autres tâches, volumes ou configurations.
03

Performances et erreurs : des affirmations de l’entreprise, pas une vérification indépendante

OpenAI présente ces nouveaux modèles comme améliorant le rapport entre coût et capacités. L’article de Xataka rapporte des affirmations de l’entreprise concernant une diminution des erreurs factuelles et une progression de Sol par rapport à son prédécesseur dans FrontierCode, un test décrit comme évaluant si des modifications de code sont prêtes à être intégrées à un projet. Le même article précise qu’Astra reste, selon les informations publiées par OpenAI, le modèle le plus capable de la famille.

Ces affirmations ne doivent pas être considérées comme des résultats indépendamment vérifiés. Les sources fournies ne donnent ni le protocole complet, ni les scores, ni l’ensemble des tâches évaluées, ni les intervalles d’incertitude, et ne font état d’aucune reproduction externe des tests. Elles ne permettent pas non plus de conclure que la baisse des erreurs se retrouvera uniformément dans toutes les langues, tous les domaines et toutes les applications. Une évaluation de programmation ne suffit pas, par exemple, à démontrer une amélioration de l’analyse documentaire ou du service client.

La comparaison entre modèles dépend également des conditions d’exécution du test : consignes, outils activés, configuration, limite de réponse et budget d’exécution. Si ces conditions varient, un score isolé peut confondre les capacités du modèle et les avantages liés à sa configuration. Les éléments disponibles ne permettent pas de confirmer que tous les chiffres de performance comparent les modèles dans des conditions équivalentes.

La conclusion prudente reste donc limitée : OpenAI annonce des améliorations et une baisse de prix, et certains médias reprennent ces déclarations. Les sources fournies ne justifient pas d’en faire une garantie générale de précision, de qualité en programmation ou d’économies.

Tester les modèles en interne avant de choisir

Cette démarche ne présuppose pas qu’un modèle soit supérieur à l’autre : elle vise à mesurer son adéquation à une tâche donnée.

  1. 01Définissez un échantillon de requêtes réelles, sans inclure de données que l’équipe n’est pas autorisée à partager.
  2. 02Appliquez les mêmes consignes, outils, limites et critères d’évaluation à Sol et Luna.
  3. 03Mesurez séparément la qualité, les erreurs importantes, la latence, le coût total et le besoin de vérification humaine.
  4. 04Répétez le test avec des cas difficiles et un volume représentatif ; consignez les changements entre les exécutions.
  5. 05Prenez votre décision en fonction du coût et de la qualité acceptables pour cette tâche, tout en prévoyant une possibilité de retour à la situation précédente.
04

Disponibilité et vérifications à effectuer avant une migration

OpenAI publie une documentation sur les modèles, les tarifs et les recommandations d’utilisation de son API. Les sources journalistiques fournies couvrent également l’annonce et les canaux de disponibilité. Toutefois, les informations disponibles pour cet article ne précisent pas suffisamment les fonctionnalités, les limites ou les conditions propres à chaque modèle et à chaque canal. Elles ne permettent pas non plus d’affirmer que l’accès est identique pour tous les comptes, toutes les régions ou tous les produits. Il faut vérifier ces détails dans la documentation en vigueur avant de préparer une migration.

Le guide officiel des modèles sert notamment à comparer les usages recommandés et les différences fonctionnelles. Pour une équipe, l’identifiant exact du modèle compte autant que son nom commercial : il faut vérifier l’identifiant accepté par l’API, les capacités activées et les limites appliquées au compte qui sera réellement utilisé. La mention d’une fonctionnalité dans une annonce ne suffit pas à supposer qu’elle est disponible dans tous les environnements.

Il est également utile de vérifier si l’application dépend de formats de réponse, d’outils ou de comportements particuliers. Un changement de modèle peut imposer des ajustements à la validation, à la gestion des erreurs et à la supervision. Si la migration concerne un processus critique, le test devrait être effectué en parallèle ou dans un environnement contrôlé avant de remplacer le modèle utilisé. La comparaison doit prendre en compte non seulement le prix nominal, mais aussi les nouvelles tentatives, la latence, les résultats rejetés et le travail de vérification.

05

Ce que la nouvelle offre peut apporter et ce qu’il reste à vérifier

Sol et Luna peuvent intéresser les organisations qui souhaitent comparer différents profils de coût et de capacité au sein du catalogue d’OpenAI. Le choix ne découle ni du nom du modèle ni du pourcentage annoncé : il dépend de l’adéquation du modèle aux exigences d’une tâche et de l’acceptabilité du coût mesuré, y compris celui des opérations en aval. Si l’application exige une fonctionnalité ou une limite précise, il faut commencer par vérifier ce point dans la documentation et dans le compte où le modèle sera déployé.

Les informations fournies permettent d’attribuer à OpenAI l’annonce d’une baisse de 50 % par rapport aux prix promotionnels de GPT-5.6, ainsi que les améliorations revendiquées à partir de ses évaluations. En revanche, elles ne donnent pas les tarifs unitaires nécessaires pour établir un budget précis, ni assez de détails méthodologiques pour vérifier indépendamment les performances. Elles ne précisent pas non plus toutes les différences de disponibilité entre l’API et les produits.

Dans la pratique, une équipe devrait consulter les tarifs en vigueur, confirmer l’identifiant du modèle et les fonctionnalités disponibles, puis tester ses propres cas et comparer le coût total à la qualité obtenue. Tant que ces données ne sont pas réunies, la baisse annoncée constitue une raison d’évaluer cette option, et non une garantie d’économies pour tous les usages.

Questions ouvertes

  • Les tarifs précis d’entrée et de sortie de GPT-6 Sol et Luna, ainsi que l’ensemble des anciens tarifs nécessaires à une comparaison indépendante, ne sont pas fournis.
  • Les sources fournies ne détaillent pas entièrement les limites, les fonctionnalités ou les conditions d’accès applicables à chaque modèle dans l’API et les produits.
  • Les protocoles et les résultats complets des évaluations portant sur les erreurs factuelles et la programmation ne sont pas disponibles ; leur comparabilité ne peut donc pas être confirmée et leurs résultats ne peuvent être généralisés à d’autres tâches.
  • Il est impossible d’estimer les économies réelles d’une organisation sans connaître son volume, son profil d’utilisation, ses nouvelles tentatives et ses coûts de vérification.
06

Poursuivre l’exploration

06

Sources consultées

03

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.

Proposer une correction