L’essentiel
- OpenAI a annoncé le 27 septembre avoir corrigé un bug qui dégradait la compréhension des images par GPT-6 Sol et GPT-6 Luna.
- Le correctif concerne l’API et Codex, y compris l’usage de l’ordinateur (computer use), selon le compte officiel OpenAI Developers.
- OpenAI recommande de relancer les évaluations et de retester les flux qui reposent sur des entrées d’images.
- L’annonce ne donne ni la date d’apparition du bug, ni la part des requêtes touchées, ni de mesure avant et après.
Dimanche soir, le compte OpenAI Developers a publié deux messages sur X. Le premier annonce que GPT-6 Sol et Luna voient de nouveau correctement les images. Le second demande aux clients de relancer leurs évaluations et de « redonner une chance » aux flux de travail qui utilisent des images.
Ce second message reconnaît, sans le formuler, que des décisions ont été prises sur un modèle défectueux. Aux équipes, désormais, de retrouver lesquelles.
Une panne qui ne lève aucune alerte
Un modèle de vision dégradé ne plante pas. Il ne renvoie pas d’erreur 500, ne dépasse pas ses délais, ne coûte pas plus cher. Il répond, avec l’aplomb habituel, en lisant un peu moins bien le tableau, la facture ou la capture d’écran qu’on lui soumet.
Pour une équipe qui teste, la différence est invisible à l’œil nu. Une extraction de champs qui rate une ligne sur dix ressemble à la limite normale d’un modèle compact, pas à un bug. On ajuste le prompt, on ajoute une consigne, on conclut que Luna n’est pas fait pour ce document-là.
Or OpenAI présente justement Luna comme le modèle des tâches administratives à fort volume : synthèse de documents, extraction d’informations. Les documents scannés et les PDF en image forment une bonne partie de ce volume. La régression frappait donc l’usage même que l’éditeur met en avant.
Une semaine de comparaisons faussées face à Opus 5.5
Le calendrier aggrave le problème. La série 6 de Sol et Luna est arrivée le 22 septembre, à moitié prix par rapport à la série 5.6, quatre-vingt-dix minutes après la sortie d’Opus 5.5 chez Anthropic. Beaucoup d’équipes ont passé les jours suivants à mettre les deux offres côte à côte pour décider où basculer leurs charges.
Le correctif n’apparaît dans le changelog de l’API que le 25 septembre. Si le bug était présent dès le lancement, et OpenAI ne dit pas le contraire, une partie de ces bancs d’essai a mesuré autre chose que le modèle réel. Un pipeline de lecture de reçus jugé trop imprécis, un agent de test d’interface abandonné parce qu’il se trompait de bouton : ces verdicts reposent peut-être sur un défaut corrigé depuis.
Personne ne pourra en faire le compte. OpenAI ne publie ni la date de début, ni l’ampleur de la dégradation, ni les scores de vision avant et après le correctif. Le client, lui, n’a généralement pas conservé assez de traces pour trancher après coup. Une évaluation menée une seule fois, au moment du choix, ne dit rien de ce que le modèle est devenu le lendemain.
Avec le computer use, voir mal devient agir mal
Le message d’OpenAI cite explicitement l’usage de l’ordinateur dans Codex. Ce mode repose entièrement sur la lecture d’écran : l’agent regarde une capture, repère un champ ou un bouton, puis clique. Une vision dégradée ne produit plus seulement une réponse fausse, elle produit une action fausse.
Un clic sur la mauvaise ligne d’un back-office, une case cochée par erreur, un formulaire rempli dans le mauvais champ : dans un flux agentique, l’erreur de perception se propage aux étapes suivantes. Les équipes qui ont trouvé Codex hésitant sur des interfaces pendant cette période ont peut-être mis en cause leur propre configuration, ou la maturité du computer use en général.
Avant de citer en réunion un retour d’expérience négatif sur l’agent de Codex recueilli ces derniers jours, mieux vaut rejouer le scénario.
Même nom de modèle, comportement différent
L’épisode rappelle une propriété dérangeante des modèles servis par API (interface de programmation) : le nom reste le même quand le comportement change. Entre le mardi 22 et le vendredi 25, « GPT-6 Sol » a pu désigner deux systèmes qui ne lisaient pas les images de la même façon. Rien, côté client, ne signalait la différence.
Le fournisseur surveille ses modèles, évidemment. Mais il les surveille avec ses propres jeux de tests, qui ne ressemblent pas à vos factures, à vos plans techniques ou à l’interface de votre ERP (progiciel de gestion intégré). La seule sonde qui mesure ce qui compte pour vous, c’est vous qui la construisez. Quelques gestes suffisent :
- garder un jeu d’évaluation figé, avec de vraies images issues de votre production et les réponses attendues ;
- le relancer à intervalle régulier, pas seulement au moment de choisir un modèle ;
- journaliser les scores dans le temps pour repérer une rupture, plutôt qu’un chiffre isolé ;
- relancer ce jeu dès qu’un éditeur publie une entrée de changelog qui touche votre usage.
Les équipes qui gèrent une base de données ou un service tiers critique pratiquent ce suivi depuis longtemps. Pour les modèles, la discipline reste rare, parce qu’on continue de traiter un modèle comme un produit fini qu’on choisit une fois.
Un changelog en guise de post-mortem
OpenAI a au moins reconnu le problème publiquement et donné une consigne claire. Beaucoup de régressions silencieuses ne sont jamais annoncées du tout.
Deux messages et une ligne de changelog ne suffisent pourtant pas à reconstituer ce qui s’est passé. Sans période d’exposition datée, les équipes ne savent pas quelles évaluations invalider. Sans ordre de grandeur, elles ne savent pas si l’écart valait quelques points ou changeait le classement face aux modèles concurrents. Anthropic avait placé la barre plus haut en avril : son post-mortem sur la baisse de qualité de Claude Code datait chacun des trois changements en cause, de leur mise en ligne à leur correction.
La série 6 était vendue sur sa fiabilité, avec un taux d’erreur divisé par deux selon les évaluations internes d’OpenAI. Une régression de vision non datée écorne cet argument, et la prochaine comparaison publique entre Sol, Luna et leurs rivaux devra préciser de quel côté du correctif elle a été faite.
Mon avis
Deux messages sur X, sans date de début ni mesure d’impact, suffisent à montrer qui porte le risque d’un modèle multimodal : le client, pas l’éditeur. Je considère désormais qu’un jeu d’évaluation maison relancé chaque semaine sur les mêmes images fait partie du coût d’intégration, au même titre que la facture de tokens. Les équipes qui l’avaient ont vu la courbe plonger puis remonter ; les autres découvrent aujourd’hui qu’elles ont peut-être jugé un modèle sur sa panne.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
