GPT-6.1 Sol sur COBOL : 86,6 % contre 5,4 %, et un seul des deux tests peut être relancé

Le 19 octobre 2026, OpenAI a publié deux évaluations de code destinées aux langues peu dotées, et le chiffre phare est à mettre au crédit de GPT-6.1 Sol : 86,6 % des tâches de migration COBOL ont été réussies à faible effort de raisonnement, contre 5,4 % pour GPT-5.6 Sol au même réglage, pour atteindre 97,9 % lorsque l'effort augmente. La seconde évaluation, MultiLangBench, raconte une autre histoire, celle d'un autre modèle — GPT-6 Astra a obtenu une moyenne de 87,4 % sur vingt langues à effort maximal — mais c'est la moitié la plus utile de cette publication, car OpenAI a mis son harnais de test sur GitHub sous licence Apache-2.0 et vous pouvez l'exécuter vous-même cet après-midi. L'évaluation de migration COBOL, celle qui porte les 86,6 %, est une autre affaire : ses tests sont cachés, son critère de réussite est une parité de sortie octet pour octet avec des cas que personne en dehors d'OpenAI n'a vus, et aucun tiers ne l'a reproduite. Cette asymétrie résume tout, et il vaut la peine de le dire clairement avant que l'un ou l'autre de ces chiffres ne soit cité dans un dossier de justification de migration. Les défaillances documentées de l'IA et les incidents d'agents qui se cachent derrière des publications comme celle-ci sont recueillis dans l'archive des incidents d'IA d'OrcaRouter, où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.

Une date à retenir. GPT-6.1 Sol lui-même date du 29 septembre 2026 — il ne s'agit pas d'un lancement, et rien ici ne modifie les poids, le prix ou la grille tarifaire du modèle. Ce qui s'est passé le 19 octobre, c'est qu'O​penAI a publié des éléments de preuve sur ce que le modèle sait faire dans une catégorie qu'elle n'avait pas documentée auparavant, et a mis à disposition un benchmark que chacun peut réexécuter. C'est l'événement dont traite cet article.

Ce qui a été réellement publié, et à quoi sert chaque moitié

Les deux évaluations répondent à des questions différentes, et la formulation même d’OpenAI les distingue. MultiLangBench demande si un modèle peut construire quelque chose dans une langue sur laquelle personne ne s’entraîne : implémenter SQLite 3.40.1 de zéro dans l’un des vingt langages de programmation, puis passer une suite de tests de conformité de bases de données. L’évaluation de la migration COBOL demande si un modèle peut déplacer quelque chose : traduire des programmes COBOL en C++, Java, Kotlin, Python ou Rust tout en préservant exactement le comportement observable.

Le premier est un test de seuil minimal de capacité. Le second est celui qui intéresse réellement les entreprises, car le COBOL n’est pas une curiosité de benchmark — les estimations de longue date d’IBM placent le COBOL derrière plus de 40 % des systèmes bancaires en ligne et environ 95 % des transactions aux distributeurs automatiques, et le code est maintenu par une main-d’œuvre qui n’est pas remplacée.

• MultiLangBench, effort maximal — GPT-6 Astra 87,4 %, GPT-6 Luna 40,3 %, GPT-5.6 Sol 26,8 %. Astra a dépassé 83 % dans 19 langues sur 20 ; le COBOL était son point le plus faible à 72,1 %, contre 10,9 % pour GPT-5.6 Sol, ce qui montre que la langue la plus difficile de l'ensemble reste celle qui dispose des outils les plus anciens.

• Migration COBOL, effort réduit — GPT-6.1 Sol 86,6 %, GPT-5.6 Sol 5,4 %, à un coût d'API estimé à 61 % de celui du modèle plus ancien pour l'exécution de l'évaluation, soit 39 % de moins.

• Migration COBOL, effort plus élevé — GPT-6.1 Sol 97,9 %, qu’OpenAI décrit comme proche de la saturation.

• Détail par langage qu’O​penAI a bien publié — Fortran : 83,5 % pour Astra contre 21,4 % pour GPT-5.6 Sol ; Visual Basic : 89,4 % contre 27,5 % ; OCaml : 85,8 % contre 25,6 % ; GPT-6 Luna à 17,1 % sur COBOL, 31,4 % sur Fortran, 34,1 % sur OCaml et 41,6 % sur Visual Basic.

• Coût par échantillon sur MultiLangBench — environ 0,77 $ pour GPT-6 Luna contre 3,48 $ pour GPT-5.6 Sol, soit environ 78 % de moins, le chiffre qui fait du modèle le plus faible du tableau l'élément intéressant pour un pipeline de génération de builds.

L'évaluation que vous pouvez relancer : ce que MultiLangBench demande réellement

Le dépôt est github.com/openai/MultiLangBench, sous Apache-2.0, et lire le harnais de test est plus instructif que lire le classement. La tâche est suffisamment précise pour qu’un modèle ne puisse pas bluffer : produire un exécutable qui prend un chemin de base de données comme argument de ligne de commande, lit une requête SQL depuis stdin et se comporte comme SQLite 3.40.1. Les tests proviennent de la suite TCL de SQLite elle-même — environ 51 000 tests au total, dont environ 24 000 ont été convertis en triplets utilisés par le harnais : une base de données initiale, une requête utilisateur et une requête de validation. Les noms des tests sont des hachages SHA-256 de ces composants, de sorte que la suite n’est pas mémorisable par nom.

Les règles sont là où se niche la difficulté, et chacune ferme un raccourci :

• Pas d’Internet, et pas de SQLite nulle part dans l’environnement. Le harnais dit de supprimer d’abord toute trace de SQLite. Un modèle ne peut pas lancer le vrai moteur via le shell, et il ne peut pas récupérer une implémentation.

• La validation s'exécute sur le véritable SQLite 3.40.1. Votre implémentation modifie la base de données ; le harnais l'extrait et la vérifie avec le produit authentique. Un comportement approximatif échoue.

• Soixante secondes par test, et une réponse dans la mauvaise langue obtient zéro. Le mélange des langues échoue, et le banc d’essai précise qu’un autre modèle peut être utilisé pour vérifier dans quelle langue vous avez réellement écrit. Cette dernière règle existe parce que la triche évidente — l’écrire en Python et l’encapsuler — est la première chose qu’un modèle capable essaie.

• L'exécution rapide compte 272 tests, pas 24 000. Le README recommande de n'exécuter que les tests dont les noms commencent par 00, 01 ou 02 lorsque vous voulez un nombre comparable. C'est le détail à noter avant de comparer votre propre score à celui d'OpenAI : une exécution complète de la suite et une exécution rapide ne sont pas la même mesure, et le README le dit.

C'est un benchmark réel et vérifiable. Il vous apprend aussi quelque chose que la couverture médiatique n'a pas dit : le chiffre phare de 87,4 % a été mesuré sur une suite que vous pouvez faire tourner sur votre propre modèle, ce qui est suffisamment rare pour mériter le téléchargement.

L’évaluation que vous ne pouvez pas réexécuter, et pourquoi ce n’est pas automatiquement un scandale

L’évaluation de la migration COBOL est conçue, exécutée et notée par O​penAI, et ses cas de test ne sont pas publiés. Le seuil de réussite est énoncé avec précision — une migration n’est validée que si chaque test caché produit une sortie observable identique octet pour octet — et c’est précisément cette précision qui rend le résultat non vérifiable de l’extérieur : les 86,6 % sont la mesure d’O​penAI sur les propres cas cachés d’O​penAI. Une seule des deux évaluations de la publication peut être reproduite par un lecteur.

Ne pas publier les tests de migration n’est pas indéfendable. Le corpus est vraisemblablement tiré de véritables programmes hérités, et sa publication peut divulguer du code client ou fournir à de futurs modèles un jeu d’entraînement. La parité octet pour octet est aussi un critère véritablement conservateur, plus strict que la plupart des évaluations de fournisseurs : elle ne récompense pas une traduction qui n’est que proche.

Mais le critère est aussi là où commencent les difficultés pratiques, et les propres mises en garde d’OpenAI le soulignent. Le résultat d’une migration nécessite encore une revue par des experts et des tests par rapport aux règles métier et aux dépendances système avant la mise en production. Et la parité octet pour octet est difficile exactement là où COBOL est difficile : le langage tronque et arrondit l’arithmétique en virgule fixe d’une manière que la plupart des langages cibles ne font pas, si bien qu’une traduction peut sembler correcte, réussir une suite de tests qui vérifie « à peu près », et malgré tout décaler un solde d’un centime. Une suite cachée qui exige une égalité exacte gère cela ; votre propre processus de revue doit aussi le gérer, car le score du modèle n’est pas une affirmation sur vos programmes.

Le chiffre des coûts demande la même prudence. Les 39 % d’économies constituent une estimation pour l’exécution de l’évaluation — les jetons entrants et sortants du benchmark — et non le coût du remplacement d’un système de production, qui est dominé par la découverte, la revue par des experts, les tests d’intégration et les années de comportement non documenté qu’aucune évaluation n’échantillonne.

Ce que 86,6 % et 97,9 % devraient changer dans une décision

La lecture honnête est plus étroite que les gros titres, et plus utile qu’eux. Un niveau de référence de 5,4 % n’est pas un modèle qui fonctionne à moitié ; c’est un modèle qui ne produit presque jamais de traduction préservant le comportement, si bien que l’ancienne génération n’a jamais été candidate pour ce travail. GPT-6.1 Sol à 86,6 % se situe dans la fourchette où l’économie s’inverse : un outil qui ébauche l’essentiel d’une traduction et laisse un relecteur la vérifier est un produit différent d’un outil qui ne produit rien d’utilisable.

Le 97,9 % à effort élevé est le chiffre dont il faut se méfier, non pas parce qu’il est faux, mais parce qu’il est saturé. Une fois qu’un benchmark approche de son plafond, il cesse de distinguer les modèles et commence à mesurer la suite, et O​penAI le dit elle-même. Pour la planification, considérez 86,6 % à faible effort comme le point de fonctionnement économique et 97,9 % comme le plafond de ce que l’évaluation peut vous montrer — pas comme une promesse de précision pour votre base de code.

Il y a aussi une vérification croisée qui vaut la peine d’être faite, et elle va à l’encontre de l’engouement. Dans le test de build, le COBOL est resté la langue la plus faible de GPT-6 Astra à 72,1 %, même si Astra est le modèle globalement le plus performant, avec une moyenne de 87,4 %. La langue est difficile dans les deux sens. Un modèle qui migre bien le COBOL lors d’une évaluation cachée n’est pas pour autant bon en COBOL ; il est bon sur le schéma que l’évaluation échantillonne.

L'autre chose qui s'est produite cette semaine : l'affirmation concernant la trace de raisonnement

Un post largement partagé le 21 octobre affirmait que les traces de raisonnement de GPT-6.1 Sol sont « totalement lisibles, rien à craindre ». Rien dans la publication d'OpenAI du 19 octobre, ni sur la page de documentation du modèle lui-même, ne permet d'affirmer qu'il s'agit d'un changement dans ce que renvoie l'API. Le guide de raisonnement d'OpenAI précise explicitement que les tokens de raisonnement bruts ne sont pas exposés — les éléments de raisonnement restent opaques — et que ce que vous pouvez demander est un résumé du raisonnement via le paramètre summary, avec le contenu de raisonnement chiffré rejoué d'un tour à l'autre. GPT-6.1 Sol prend en charge la forme all_turns de ce rejeu. Un canal de résumé n'est pas une trace lisible, et confondre les deux, c'est ainsi qu'une affirmation de sécurité finit par être faite à partir d'une capture d'écran.

Ce qui est mesurable est adjacent et plus intéressant pour quiconque audite un agent. L’évaluation de GPT-6.1 Sol par Sonar, le 9 octobre, menée face à GPT-6 Sol avec un effort moyen sur 4 444 tâches Java, a constaté que les tokens de raisonnement avaient chuté de 51,4 % — de 2,64 M à 1,28 M — tandis que la part du raisonnement dans la sortie passait de 41,8 % à 19,5 %, que la sortie augmentait et que le taux de réussite fonctionnel s’améliorait de 83,09 % à 85,29 %. La même exécution a constaté une baisse de 32,4 % de la densité de vulnérabilités, mais une hausse des constats de fiabilité de gravité critique, de 21 à 46, les bogues de concurrence constituant la catégorie la plus importante avec 196 constats. C’est là un arbitrage sur lequel un relecteur peut agir. « Les traces sont lisibles » ne l’est pas, car les traces ne sont pas ce qui est renvoyé.

Pour un projet de migration, cela compte d’une manière concrète : votre piste d’audit est le diff et la sortie des tests, pas la narration du modèle. Prévoyez en conséquence la capacité de revue — le constat de Sonar selon lequel 39,4 % de code généré en plus a produit 12 982 constats au total, contre 9 859, donne la forme du coût qui se cache derrière un score de benchmark.

Gérer vous-même les deux bras

Le problème pratique d’une comparaison comme celle-ci, c’est que le bras de référence et le nouveau bras correspondent généralement à deux contrats, deux clés et deux relations de facturation, ce qui crée suffisamment de friction pour que personne n’exécute la référence. Les deux modèles figurent dans notre catalogue derrière une seule clé : openai/gpt-6.1-sol et openai/gpt-5.6-sol, aux tarifs catalogue d’O​penAI avec 0 % de marge, soit les mêmes 2,00 $ en entrée et 10,00 $ en sortie par million de tokens que vous paieriez au fournisseur, avec l’entrée mise en cache à 0,10 $ et les écritures de cache à 2,50 $, et le palier au-dessus de 272K répercuté à 4,00 $, 0,20 $, 5,00 $ et 15,00 $. Une modification tarifaire d’un fournisseur prend effet ici le jour de sa publication, et non à la prochaine revue de contrat.

Ce pass-through est ce qui rend peu coûteux l’exécution d’un benchmark le jour même : pointez la suite rapide MultiLangBench sur les deux modèles, payez le tarif catalogue pour chacun, et vous obtenez un chiffre concernant votre propre chaîne d’outils plutôt que celle d’OpenAI. Le basculement automatique est l’autre moitié de l’argument — si le modèle plus récent se dégrade en cours d’exécution ou si une route est limitée en débit, la requête n’échoue pas avec lui, ce qui vous permet de placer un modèle non éprouvé devant un pipeline de migration avant d’avoir vos propres preuves.

Le banc d'essai MultiLangBench est public et les cas de migration COBOL ne le sont pas, donc le seul test honnête des 86,6 % est celui que vous construisez : échantillonnez quelques centaines de vos propres programmes COBOL, traduisez-les et comparez la sortie octet par octet au comportement d'origine. Cela représente une semaine de travail et vaut plus que le tableau du fournisseur.

Que regarder ensuite

Trois éléments changeraient ce tableau, et aucun ne s'est encore produit. La publication par O​penAI des cas de migration COBOL, ou leur réexécution par un laboratoire indépendant, transformerait un chiffre de fournisseur en mesure. La reproduction par un tiers du tableau par langage de MultiLangBench nous dirait si le 72,1 % de COBOL est une propriété du langage ou de la suite. Et le relevé de benchmark indépendant du modèle — Artificial Analysis place actuellement GPT-6.1 Sol à un Intelligence Index de 52, douzième sur 214 modèles, à 55,2 tokens de sortie par seconde et 0,72 $ par tâche d'indice — est la vérification qui ne dépend pas du tout des évaluations propres à O​penAI.

D’ici là, le résumé utile est court. GPT-6.1 Sol est un modèle du 29 septembre dont la capacité sur le code hérité a été documentée le 19 octobre, dans une évaluation que vous pouvez exécuter et une que vous ne pouvez pas. Celle qui est exécutable indique que la nouvelle génération est d’une autre classe sur les langues à faibles ressources. Celle qui ne l’est pas indique que la migration COBOL mérite désormais un pilote. Seule votre propre base de code peut transformer l’une ou l’autre en décision.