OpenAI corrige un bug d’encodage d’images sur GPT-6 Sol et GPT-6 Luna

EElias

Alors, OpenAI a corrigé un défaut d’encodage des images qui dégradait la compréhension visuelle de GPT-6 Sol et GPT-6 Luna, d’après AlphaSignal. Le correctif est actif sur les modèles existants, dans l’API et dans Codex, sans changement de code ni migration de version. L’encodage, c’est l’étape qui prépare l’image pour que le modèle puisse ensuite en traiter le contenu ; un défaut à cette étape peut donc affecter ce que le système comprend avant même qu’il formule une réponse. Il faut toutefois rester précis : OpenAI n’a pas publié le détail de la cause technique, ni indiqué pendant combien de temps le problème a affecté les modèles. L’entreprise n’a pas non plus chiffré l’amélioration obtenue après la correction. On sait donc qu’un défaut a été corrigé et que le correctif est déployé, mais on ne peut pas encore mesurer publiquement l’ampleur de ses effets.

EElias

Une image n’est pas interprétée comme une simple photographie que le modèle regarderait directement ; elle est d’abord convertie en une représentation que le système peut traiter. On peut comparer cette étape à la préparation d’un document avant sa lecture : si des détails sont perdus ou déformés à ce moment-là, l’analyse qui suit part d’une base moins fidèle. Les informations disponibles identifient bien l’encodage des images comme la couche concernée, mais elles ne décrivent pas précisément le mécanisme du défaut. Il serait donc hasardeux d’affirmer qu’un élément particulier, comme les petits caractères ou la position d’un objet, a été systématiquement touché. Ce qu’on peut dire, c’est que la qualité de compréhension visuelle de ces 2 modèles était dégradée par le problème, tandis qu’aucune mesure chiffrée de cette dégradation n’a été publiée. La correction porte sur le traitement des images ; elle ne permet pas, à elle seule, de conclure que chaque réponse incorrecte venait de ce défaut ou que toutes les tâches visuelles se comportaient de la même façon.

EElias

Le correctif s’applique aux usages de GPT-6 Sol et GPT-6 Luna par l’API et Codex, notamment aux tâches de vision par ordinateur et aux agents qui analysent des captures d’écran. Cela peut inclure, par exemple, un système chargé d’examiner une image ou une interface, mais il faut distinguer ces exemples des cas effectivement mesurés par OpenAI : aucune liste exhaustive d’applications touchées n’a été publiée. Pour un agent de contrôle informatique, une capture d’écran peut servir à comprendre l’état d’une page avant d’agir ; une meilleure lecture de l’image peut donc compter pour la suite du workflow. Mais nous ne savons pas si un type précis d’agent a été plus touché qu’un autre, ni si toutes les requêtes contenant des images étaient concernées. Le correctif couvre aussi les usages dans Codex, ainsi que les tâches de vision prises en charge par l’API. Autrement dit, il ne s’agit pas d’une nouvelle version à installer dans chaque projet : les identifiants existants restent en place et la correction s’applique automatiquement aux usages concernés. Les équipes doivent néanmoins vérifier leurs propres tâches au lieu de supposer qu’elles ont toutes connu le même effet.

EElias

OpenAI recommande de relancer les évaluations visuelles et de réessayer les workflows d’images qui ont pu être affectés. C’est une façon de vérifier les performances sur ses propres tâches, plutôt que de déduire un gain général à partir de la seule annonce du correctif. Une équipe peut reprendre ses tests habituels avec les mêmes images et les mêmes consignes, puis comparer les résultats obtenus ; cette comparaison fournit une indication sur son cas d’usage, pas une mesure universelle pour tous les utilisateurs. Il faut aussi distinguer les nouvelles requêtes des sorties déjà produites : les réponses générées avant le correctif ne sont pas modifiées rétroactivement. Si une application s’appuie sur d’anciens résultats, ceux-ci restent donc tels qu’ils ont été enregistrés, et les équipes peuvent décider de revoir les évaluations ou les étapes de travail concernées. Aucun changement de code ni migration de modèle n’est nécessaire pour bénéficier du déploiement. La recommandation de relancer des tests reste néanmoins importante, précisément parce qu’OpenAI n’a publié ni résultats comparatifs ni mesure chiffrée de l’amélioration.

EElias

Les endpoints et les tarifs des 2 modèles restent inchangés. GPT-6 Sol est facturé 2 dollars par million de jetons en entrée et 10 dollars par million en sortie ; pour GPT-6 Luna, les tarifs sont de 0,10 dollar en entrée et 0,50 dollar en sortie par million de jetons. Ces montants décrivent le prix des modèles, pas le coût d’un workflow complet, qui dépend aussi de la manière dont une équipe les utilise. Le point pratique, c’est que les intégrations existantes conservent leurs identifiants et leurs endpoints, sans migration imposée par cette correction. Le correctif est côté service et s’applique aux usages concernés, mais OpenAI n’a pas détaillé la cause technique exacte ni la période d’exposition au problème. L’absence de ces précisions empêche de déterminer combien de requêtes ou d’équipes ont pu être concernées. Elle ne remet pas en cause le fait confirmé que la correction est active et que les tarifs annoncés ne changent pas ; elle limite plutôt ce qu’on peut déduire sur l’ampleur passée du défaut et sur le bénéfice obtenu par chaque utilisateur.

EElias

La limite principale, c’est le manque de données publiques pour mesurer l’incident : OpenAI n’a précisé ni sa cause technique exacte, ni sa durée, ni l’ampleur de la baisse de qualité. Aucun résultat comparatif chiffré n’a été publié après le correctif. Il est donc impossible d’affirmer que l’amélioration est identique pour tous les usages, ou même de quantifier un gain moyen à partir des informations disponibles. Ce qui est établi, en revanche, c’est qu’un défaut d’encodage affectait la compréhension visuelle de GPT-6 Sol et GPT-6 Luna, et qu’OpenAI a déployé une correction sur les usages concernés. Les équipes n’ont pas à modifier leur code pour la recevoir, mais elles peuvent relancer leurs évaluations visuelles et retester les workflows qui comptent pour elles. Cette vérification leur permet de constater ce qui change sur leurs propres exemples, sans confondre un résultat local avec une garantie générale. Enfin, les réponses produites avant le correctif restent inchangées : la correction améliore le traitement des nouvelles requêtes concernées, elle ne réécrit pas l’historique.