GPT-Image-2.6 vs GPT-Image-2.5 : le remplacement tient à une chaîne, pas à la facture

Migrer de GPT-Image-2.5 à GPT-Image-2.6 est, au niveau de l’API, la mise à niveau la moins spectaculaire qu’OpenAI ait livrée de toute l’année. Mêmes deux points de terminaison, même grille tarifaire, même répartition Flare contre Sunburst. La chaîne du modèle change, et rien d’autre n’a besoin de changer. C’est aussi le piège. GPT-Image-2.6 ajoute un paramètre que GPT-Image-2.5 n’a jamais eu — un réglage de complexité — et le fait de l’omettre ne revient pas à le désactiver. Sa valeur par défaut est high. Un pipeline qui remplace la chaîne et met en production n’achète pas la même quantité de travail pour le même prix ; il achète plus de travail, ce qui explique pourquoi le premier rapport de coûts après une migration peut évoluer alors que les tarifs publiés, eux, n’ont pas bougé.

Les deux modèles sont passés en disponibilité générale selon les mêmes conditions commerciales, et c’est ce qui rend cette comparaison inhabituelle. Il n’y a pas de débat sur le prix. Le débat porte entièrement sur l’endroit où le nouveau travail est investi, et sur la question de savoir si votre trafic est façonné de manière à en bénéficier.

La surface de l’API est vraiment un remplacement direct — avec un trou dedans.

OpenAI a déployé GPT-Image-2.6 le 4 novembre 2026 sous la forme de deux modèles API plutôt que d’un seul, reprenant la structure établie avec la version 2.5. Le niveau orienté détail et cohérence est GPT-Image-2.6 Sunburst ; le niveau axé sur la vitesse est GPT-Image-2.6 Flare. Leurs prédécesseurs, GPT-Image-2.5 Sunburst et GPT-Image-2.5 Flare, conservent les mêmes noms et le même rapport entre eux.

• Chaînes de modèle — gpt-image-2.6-flare et gpt-image-2.6-sunburst remplacent gpt-image-2.5-flare et gpt-image-2.5-sunburst, même logique de nommage, une pour la latence et une pour le détail.

• Points de terminaison — /v1/images/generations et /v1/images/edits, inchangés. Aucun nouveau point de terminaison à intégrer.

• Tarifs — 5 $ par million de jetons d’entrée texte, 8 $ par million de jetons d’entrée image, 30 $ par million de jetons de sortie image, avec l’entrée mise en cache à 1,25 $ et 2,00 $. Identique octet pour octet à la version 2.5.

Niveaux de qualité — low, medium, high, xhigh, max et auto. Même échelle.

• Tailles recommandées — 1024×1024, 1536×1024 et 1024×1536 restent en tête de la documentation, les dimensions personnalisées étant acceptées en multiples de 16 et les ratios d’aspect de 1:3 à 3:1.

• La faille — 2.6 n'est pas disponible via l'API Batch. Si votre budget d'images repose sur une tâche nocturne à moitié prix, cette tâche ne bouge pas encore.

Cette dernière ligne est bien celle qui casse réellement quelque chose. Tout ce qui précède se résume à un remplacement de chaîne et à une exécution de régression. Le déficit en traitement par lots est un obstacle architectural précisément pour les charges de travail — catalogues en masse, rechargements historiques nocturnes, génération A/B à grande échelle — où une remise de 50 % est la raison d’être même de la charge de travail.

Le véritable atout, c’est le curseur de complexité, et sa valeur par défaut est la surprise.

La complexité est un nouvel axe qui se situe à côté de la qualité plutôt qu’en son sein, et cette distinction est plus importante qu’elle n’en a l’air. La qualité contrôle le rendu : combien de tokens de sortie sont consacrés à l’image. La complexité contrôle la planification : la quantité de raisonnement que le modèle effectue avant de commencer le rendu. Vous pouvez demander une image de basse qualité d’une scène complexe, ou une image de haute qualité d’une scène simple, et dans la 2.6, ce sont véritablement des demandes distinctes.

La documentation indique explicitement que l’omission du paramètre lui attribue par défaut la valeur high. Ainsi, un appelant qui migre une requête 2.5 en changeant uniquement le nom du modèle, sans rien modifier d’autre, opte donc silencieusement pour le budget de planification maximal à chaque appel. Ce n’est pas un bug — c’est la valeur par défaut judicieuse pour un modèle dont l’argument de vente est de réfléchir davantage — mais cela signifie que le premier mois de trafic 2.6 ne constitue pas une comparaison à l’identique avec le dernier mois de trafic 2.5.

Il existe au moins un point de données public qui va dans le même sens. Un test pratique sur trois images, publié le 4 novembre, a rapporté $0.1245 de sortie sur 2.6 contre $0.0446 pour les mêmes images fixes sur 2.5 — environ le triple, sur une grille tarifaire qui n’a pas changé. Trois images ne constituent pas un benchmark et ne devraient pas être citées comme tel ; l’échantillon est bien trop petit pour établir un multiplicateur. Ce que cela fait, en revanche, c’est démontrer le mécanisme, et le mécanisme est documenté : davantage de jetons de planification par requête, activés par défaut, facturés à $30 par million.

Si vous ne devez retenir qu’une seule étape opérationnelle de cet article, retenez celle-ci. Définissez explicitement la complexité — medium est une première estimation raisonnable pour correspondre au comportement de l’ère 2.5 — puis mesurez les jetons de sortie par requête avant et après. Ne mesurez pas les dollars par requête. Les dollars par requête vous diront que la grille tarifaire n’a pas changé, ce que vous saviez déjà. Les jetons par requête vous diront si le modèle fait plus de travail que ce que vous avez demandé.

Là où aboutit réellement l'accélération de 50 % annoncée

OpenAI décrit GPT-Image-2.6 comme environ 50 % plus rapide dans l’ensemble, mais les chiffres par palier sont bien plus intéressants que le chiffre phare, et il s’agit des chiffres du fournisseur lui-même, non mesurés indépendamment. Flare serait environ 2,6× plus rapide que son prédécesseur, les rendus de faible qualité s’achevant en seulement six secondes. Sunburst serait environ 1,15× plus rapide.

Ces deux chiffres décrivent deux améliorations complètement différentes. Si votre pipeline utilise Flare pour l’itération — exploration de vignettes, réglage des prompts, tout ce pour quoi un humain attend le résultat —, 2.6 représente un saut qualitatif, et la migration se rentabilise rien que par le gain d’attention. Si votre pipeline utilise Sunburst pour la qualité de sortie finale, une amélioration de 15 % de la latence se situe dans la plage de variabilité d’une exécution à l’autre sur la plupart des configurations d’hébergement, et la vitesse n’est pas du tout une raison de migrer.

Il faut le signaler honnêtement : le même petit test pratique qui avait rapporté l’inflation des tokens a aussi rapporté que 2.6 était plus lent que 2.5 sur ses trois images, ce qui contredit l’affirmation du fournisseur. Avec n=3, c’est du bruit, pas une réfutation. Mais cela rappelle que « 50 % plus rapide » est un agrégat de présentation de lancement tous niveaux de qualité confondus, et qu’un pipeline réel ne voit qu’un seul niveau à un seul réglage de qualité.

Personne n’a encore marqué 2,6, et 2,5 est toujours en tête

C’est l’aspect de la comparaison que la plupart des couvertures médiatiques passent sous silence. Artificial Analysis, qui exploite ses classements AA-Image-T2I v2.1 et d’édition, n’avait pas la moindre ligne pour GPT-Image-2.6 au moment de la consultation, le 5 novembre 2026. Pas un score faible — aucune ligne.

Ce que ces tableaux montrent bel et bien, c’est que le modèle remplacé continue de les remporter :

• Du texte à l'image — GPT-Image-2.5 Sunburst (max) 1 224 Elo sur 13 153 votes, première place. GPT-Image-2.5 Flare (max) 1 207 sur 12 498, deuxième place. GPT Image 2 (high) 1 188, troisième place.

• Édition d’images — GPT-Image-2.5 Sunburst (max) 1 200 sur 18 370 votes, premier. GPT-Image-2.5 Flare (max) 1 183 sur 19 259, troisième derrière MAI-Image-2.7-Preview à 1 197.

Les documents de lancement d’OpenAI citent Design Arena pour une première place de 2.6 Sunburst. C’est une affirmation réelle sur un classement réel, mais il s’agit d’un panel de votants différent sur une échelle différente, et le fait qu’un fournisseur choisisse le classement qui flatte sa sortie ne constitue pas une preuve exploitable par un acheteur. Le score comparable, provenant d’un tiers et issu d’un vote, pour 2.6 n’existe pas encore. D’ici là, la position défendable est que 2.5 est le modèle d’image le mieux noté de manière indépendante sur les deux principaux classements et que 2.6 n’a pas fait ses preuves — meilleur dans les aspects précis où OpenAI affirme qu’il l’est, et non mesuré partout ailleurs.

Une migration qui tient en un après-midi

Le remplacement coûte assez peu pour que l'approche raisonnable ne consiste pas en une migration big-bang, mais en une migration mesurée, menée sur vos propres prompts plutôt que sur le jeu de prompts de référence de qui que ce soit.

Commencez par fixer la complexité à une valeur que vous avez choisie, afin que le changement soit celui que vous avez opéré et non celui qui s’est imposé par défaut. Ensuite, relancez quelques centaines de prompts réels issus de vos journaux de production — pas les prompts propres de vos fixtures de test, mais les désordonnés, avec des fautes de frappe et des ratios d’image malcommodes. Comparez deux chiffres : les tokens de sortie par image acceptée, et les images acceptées pour cent tentatives. Le second est celui où une amélioration de la cohérence se manifesterait, et c’est le chiffre qui détermine réellement si la mise à niveau permet d’économiser de l’argent, car une image que vous jetez coûte le budget de tokens complet et ne rapporte rien.

Conservez un chemin de repli vers la 2.5 pour le travail par lots, car la 2.6 ne peut pas encore le prendre en charge. Et traitez tout trafic Sunburst comme une question de qualité plutôt que de vitesse — si le taux d'acceptation ne bouge pas, vous avez acheté une amélioration de latence de 15 % et une facture de planification plus élevée.

Quand rester sur 2.5 est la bonne réponse

Trois cas sont suffisamment clairs pour être nommés. Les charges de travail par lots doivent rester, car 2.6 n’est pas sur l’API Batch et 2.5 l’est. Les pipelines de qualité Sunburst doivent rester, sauf si le test du taux d’acceptation indique le contraire, car une accélération de 1,15× ne compense pas un changement de modèle de coûts. Et toute personne dont le taux d’acceptation actuel est déjà acceptable doit rester, car les nouvelles capacités — export SVG, GIF animé, édition guidée par balisage — sont des fonctionnalités additives, et non des améliorations de qualité, et vous n’en avez besoin que si vous avez un livrable qui les exige.

La mise à niveau est bien réelle. Elle se concentre simplement sur la latence de Flare et sur de nouveaux formats de sortie, et ces éléments sont plus restrictifs que ne le suggère « un nouveau modèle ».

La disponibilité, et la forme délicate d'une migration scindée

OrcaRouter propose GPT-Image-2.5 Flare et GPT-Image-2.5 Sunburst aujourd'hui au prix catalogue avec 0 % de marge, donc le tarif du fournisseur est celui que vous payez, sans marge ajoutée. GPT-Image-2.6 ne figure pas au catalogue au 5 novembre 2026 — un jour après son lancement — ce qui fait du problème pratique immédiat une question de routage plutôt que de modélisation : pendant le banc d'essai, le trafic 2.5 passe par une clé avec bascule automatique, tandis que le trafic 2.6 va directement à OpenAI dans le cadre d'un second contrat et d'une seconde facture.

Cette distinction mérite d’être anticipée plutôt que découverte. Vérifiez le catalogue avant d’engager un chemin de production sur 2.6, car aucun routeur ne peut promettre une parité dès le jour du lancement sur un modèle vieux de vingt-quatre heures. Lorsqu’il sera disponible, la règle de répercussion signifie que le tarif du fournisseur est ce que vous payez le jour même — un changement de prix côté OpenAI arriverait sans renégociation de notre côté — mais d’ici là, la lecture honnête de la situation est que 2.5 est routable et 2.6 ne l’est pas.

C'est un autre argument en faveur d'une migration de la taille d'un après-midi plutôt que d'une migration de la taille d'un week-end. Faites passer 2.5 par le routeur, maintenez votre référence de coûts stable, et ajoutez 2.6 derrière un feature flag une fois que vous avez mesuré ce que la valeur par défaut de complexité fait à vos nombres de tokens. Le modèle n'est pas près de disparaître, et le point de terminaison batch arrivera avant votre prochain cycle de planification trimestriel.