COBOL : OpenAI passe de 5,4 % à 86,6 % sur ses propres tests

Le 19 octobre 2026, OpenAI a publié « Advancing coding in low-resource programming languages ». Sur son évaluation de migration COBOL, GPT-6.1 Sol atteint 86,6 % de précision à faible effort de raisonnement, contre 5,4 % pour GPT-5.6 Sol. Le bond est spectaculaire, mais il vient d'évaluations conçues et publiées par OpenAI elle-même.

Le sujet est périphérique pour un blog SEO, et on le traite comme tel : pas de promesse sur le référencement, mais une lecture critique de ce que l'IA sait désormais faire sur du code ancien, et de la manière d'auditer un benchmark constructeur avant de le glisser dans un argumentaire client. Les implications pour le métier de consultant sont notre analyse, pas des faits tirés des sources.

01Ce qu'OpenAI a réellement publié

Le texte d'OpenAI affirme que les derniers modèles sont plus performants pour construire et migrer des logiciels dans des langages dits à faibles ressources, comme COBOL, Fortran et Visual Basic. Ces langages disposent de moins de code et de documentation que Python ou JavaScript, donc de moins de matière pour l'entraînement.

OpenAI met en avant leur poids réel : selon son article, COBOL supporte plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte en personne et 95 % des transactions aux distributeurs automatiques. Fortran sert à la prévision météo et à l'analyse de sûreté des réacteurs nucléaires. FourWeekMBA et KuCoin News rattachent ces pourcentages à des données IBM. Cette attribution n'a pas pu être confirmée sur la page d'OpenAI : à prendre avec prudence.

Deux évaluations, deux questions différentes

MultiLangBench demande à un modèle de construire, à partir de zéro, un moteur de base de données compatible SQLite dans 20 langages. L'évaluation de migration COBOL, elle, demande de migrer des programmes existants vers un autre langage en préservant leur comportement. L'une mesure la création, l'autre la traduction fidèle, et c'est cette seconde qui parle le plus aux équipes qui héritent de vieux systèmes.

02Les chiffres, modèle par modèle

Sur MultiLangBench, GPT-6 Astra atteint un taux moyen de réussite aux tests de 87,4 % sur 20 langages, contre 26,8 % pour GPT-5.6 Sol, avec une amélioration dans chaque langage testé. GPT-6 Luna atteint 40,3 %, donc plus que GPT-5.6 Sol, pour un coût d'API estimé inférieur d'environ 78 %. Pour situer ces modèles, notre guide d'OpenAI pour choisir entre Astra, Sol et Luna détaille leurs positionnements.

Sur la migration COBOL, GPT-6.1 Sol atteint 86,6 % à faible effort de raisonnement contre 5,4 % pour GPT-5.6 Sol, avec un coût inférieur de 39 %. À effort plus élevé, la précision monte à 97,9 %. OpenAI en tire que l'évaluation est presque saturée, ce qui est aussi un signal : un test saturé distingue mal les modèles entre eux. Le lancement de GPT-6.1 Sol est revenu dans notre récap du DevDay 2026.

Le détail par langage de GPT-6 Astra, rapporté par Interesting Engineering et Superpower Daily, montre un écart net sur COBOL. Les extraits consultés ne précisent pas le modèle de comparaison pour chaque ligne (seule la moyenne oppose explicitement Astra à GPT-5.6 Sol).

Superpower Daily ajoute qu'Astra dépasse 83 % dans chacun des 19 autres langages, dont 85,8 % en OCaml. COBOL, à 72,1 %, reste donc le point faible du lot.

03Ce que ces tests mesurent vraiment

Le piège de la migration de code, c'est qu'un programme réécrit peut tourner sans erreur tout en produisant des résultats faux. Interesting Engineering cite un exemple : COBOL peut supprimer les décimales excédentaires si le programme ne demande pas explicitement d'arrondi. Un langage cible qui arrondit par défaut donnera alors des chiffres différents, sans aucun message d'erreur.

C'est ce que l'évaluation cherche à capter : les programmes doivent être traduits vers C++, Java, Kotlin, Python ou Rust sans changer leur comportement. Mesurer la fidélité du comportement est plus exigeant que vérifier que le code compile, et c'est un point méthodologique sérieux en faveur du test.

Un score de benchmark dit ce qu'un modèle réussit sur un test, pas ce qu'il garantit sur votre système.

Côté MultiLangBench, OpenAI dit avoir adapté des tests de la suite existante de SQLite, et l'évaluation mesure la capacité à organiser des bases de code. C'est un cadre sérieux, mais un moteur de base de données écrit de zéro reste loin d'un système hérité de trente ans, avec ses dépendances, ses données sales et sa documentation absente.

04Ce qui reste à prouver

Première réserve : tous les scores viennent d'évaluations conçues et publiées par OpenAI. FourWeekMBA le rappelle en précisant qu'il s'agit des propres évaluations de l'éditeur, et nous n'avons constaté aucune réplication indépendante à ce jour. Les chiffres, eux, concordent entre toutes les sources que nous avons croisées : le risque n'est pas une erreur de recopie, c'est un biais de conception possible.

Deuxième réserve : la disponibilité du protocole. CellCog indique qu'OpenAI publie sur GitHub la configuration de l'évaluation, la suite de tests et les résultats par langage. Nous n'avons pas pu vérifier le dépôt, et cette affirmation n'est pas confirmée par les extraits de la source primaire que nous avons relus. Nous n'avons d'ailleurs pas relu l'intégralité de la page d'OpenAI. Si le dépôt existe, c'est la condition pour qu'un tiers rejoue les tests.

Troisième réserve, de lecture : les comparaisons ne portent pas toujours sur les mêmes modèles. MultiLangBench met en scène GPT-6 Astra et GPT-6 Luna, la migration COBOL GPT-6.1 Sol, tous face à GPT-5.6 Sol. Les 86,6 % et les 87,4 % ne sont donc pas des mesures d'un même modèle sur un même test.

05Ce que cela change pour un consultant SEO (notre analyse)

Ce qui suit est une analyse, pas un fait tiré des sources. Beaucoup de missions SEO butent sur du code ancien : anciens sites, scripts maison, back-ends peu documentés où personne ne sait plus pourquoi une redirection ou une balise est générée ainsi. Si l'IA devient fiable hors Python et JavaScript, la lecture, l'explication et la migration de ces bases devraient devenir plus accessibles. C'est une hypothèse de travail, que seuls des tests sur vos propres cas valideront.

Elle s'inscrit dans une tendance plus large d'agents de code utilisés en production, comme le montre notre article sur Amp, qui code avec GPT-6 Astra. Le garde-fou de l'exemple COBOL vaut aussi en SEO : une migration qui « fonctionne » peut altérer silencieusement des URL, des canoniques ou des en-têtes. Il faudra donc comparer le comportement avant et après (crawl, statuts HTTP, balisage), pas seulement vérifier l'absence d'erreur.

Auditer un benchmark constructeur avant de le citer

Avant de reprendre un chiffre dans un argumentaire client, quatre questions suffisent. Qui a conçu le test et qui l'a publié ? Les modèles comparés sont-ils les mêmes d'une ligne à l'autre ? Le protocole est-il rejouable par un tiers ? Le test se rapproche-t-il de votre cas réel ? Sur ce dossier, la réponse à la deuxième est « pas toujours », à la troisième « à confirmer », à la première « l'éditeur lui-même ». Cela n'invalide pas les résultats, cela fixe le niveau de prudence.