Nouveau Trouve le job que tu mérites sur Les Joies du Code

Thème d'affichage

OpenAI affirme que GPT⁠-⁠6.1 Sol migre du COBOL vers Java ou Rust avec 98 % de réussite

Nicolas Lecointre ·
OpenAI affirme que GPT⁠-⁠6.1 Sol migre du COBOL vers Java ou Rust avec 98 % de réussite

Alerte au COBOL — Selon un billet de blog publié en début de semaine par OpenAI, GPT-6.1 Sol, le modèle de milieu de gamme de l'entreprise, sait migrer des programmes COBOL vers Java, Rust ou Python sans en changer le comportement dans 97,9 % des cas.

Même avec un temps de réflexion réduit, il réussit encore 86,6 % des migrations, là où la génération précédente plafonnait à 5,4 % dans les mêmes conditions.

Le mythe du développeur COBOL irremplaçable, qu'on tire de sa retraite à prix d'or dès que le mainframe de la banque tousse, en prend un coup.

Homme chauve qui essuie ses fausses larmes avec une liasse de billets

Les langages qui tiennent la caisse

Le COBOL, le Fortran et Visual Basic font partie de ce qu'OpenAI appelle les langages "à faibles ressources" : les modèles disposent de beaucoup moins de code et de documentation pour les apprendre qu'en Python ou en JavaScript.

Et pourtant, je ne vous apprends rien : ces langages font tourner des services essentiels.

Citant IBM, OpenAI rappelle que le COBOL est derrière plus de 40 % des systèmes de banque en ligne, 80 % des paiements par carte de crédit en magasin et 95 % des transactions aux distributeurs automatiques.

Quant au Fortran, il sert toujours à des tâches aussi critiques que les prévisions météo ou les analyses de sûreté des réacteurs nucléaires.

Visual Basic, lui, reste bien ancré dans les entreprises, des applications métier legacy en VB6 aux macros VBA, sa déclinaison intégrée à Excel, Word ou Access.

Et Microsoft sait qu'il ne peut pas y toucher sans casser quelque chose : il livre toujours le moteur d'exécution de VB6 avec Windows 11 et le prend en charge sur Windows Server 2025, alors que l'environnement de développement de VB6 n'est plus supporté depuis... 2008.

Meme GTA V : Franklin tient Chop en laisse, légendés COBOL, Fortran et Visual Basic, et le chien L'économie mondiale

Les développeurs COBOL, eux, se font rares. Au début de la pandémie de Covid-19 aux États-Unis, le New Jersey en manquait tellement que son gouverneur avait lancé un appel aux bénévoles pour remettre d'aplomb son système d'allocations chômage.

Et le sujet est d'ailleurs assez sensible pour faire frissonner la bourse : en février, IBM, le roi historique du mainframe, a vu son action perdre 13 % en une séance après un billet d'Anthropic affirmant que Claude Code pouvait automatiser l'exploration et l'analyse d'un code COBOL avant sa migration.

Recoder SQLite en COBOL (et dans 19 autres langages)

Pour mesurer les progrès de ses modèles, OpenAI a créé MultiLangBench. Ce benchmark leur demande de recoder de zéro un moteur de base de données compatible SQLite, dans 20 langages différents.

Le modèle n'a droit qu'à la documentation de SQLite, sans accès à Internet et sans la moindre trace du code original dans son environnement (histoire de couper court au copier-coller).

Chaque test fournit au programme une base de données et une requête SQL, puis c'est le vrai SQLite qui inspecte la base modifiée. La même batterie de tests, adaptée de celle de SQLite, sert ainsi pour les 20 langages.

À ce petit jeu, GPT-6 Astra, le modèle haut de gamme d'OpenAI, passe en moyenne 87,4 % des tests, contre 26,8 % pour GPT-5.6 Sol.

Astra dépasse les 83 % dans 19 langages sur 20. Seul le COBOL (évidemment) reste en dessous, à 72,1 %, contre 10,9 % pour GPT-5.6 Sol.

Le Fortran passe de 21,4 % à 83,5 %, et Visual Basic de 27,5 % à 89,4 %.

Graphique en barres du taux de réussite aux tests SQLite par langage, GPT-6 Astra autour de 90 % contre 20 à 35 % pour GPT-5.6 Sol

Au centime près

Le second test d'OpenAI demande aux modèles de migrer des programmes COBOL existants vers C++, Java, Kotlin, Python ou Rust, sans en changer le comportement.

Des tests, que le modèle ne voit pas pendant la migration, vérifient ensuite que le programme migré produit exactement les mêmes sorties que l'original, à l'octet près. Une migration n'est validée que si elle les passe tous.

OpenAI donne l'exemple d'un piège : en COBOL, les calculs en virgule fixe tronquent les décimales en trop, sauf si le code demande explicitement un arrondi.

Prenons une TVA à 5,5 % sur un article à 19,99 euros. Le calcul exact donne 1,09945 euro, à ranger dans un champ à deux décimales :

       01 PRIX-HT    PIC 9(3)V99 VALUE 19.99.
       01 TVA        PIC 9(3)V99.
       01 TVA-ARR    PIC 9(3)V99.
       01 AFFICHAGE  PIC 9.99.

           COMPUTE TVA = PRIX-HT * 0.055
           COMPUTE TVA-ARR ROUNDED = PRIX-HT * 0.055
           MOVE TVA TO AFFICHAGE
           DISPLAY "TVA tronquée : " AFFICHAGE
           MOVE TVA-ARR TO AFFICHAGE
           DISPLAY "TVA arrondie : " AFFICHAGE

Sans le mot-clé ROUNDED, COBOL coupe tout ce qui dépasse la deuxième décimale au lieu d'arrondir :

TVA tronquée : 1.09
TVA arrondie : 1.10

Une réécriture qui arrondit ces valeurs au lieu de les tronquer peut alors tourner sans la moindre erreur tout en sortant des résultats financiers différents.

C'est exactement ce risque que pointaient les spécialistes quand le DOGE, le département de l'efficacité gouvernementale d'Elon Musk, voulait réécrire en quelques mois le COBOL de la sécurité sociale américaine : un simple écart d'arrondi pouvait fausser des paiements à grande échelle.

Un an et demi plus tard, le chantier express promis n'a toujours pas abouti. Mais au moins, on a maintenant la voiture volante.

Sur le test de migration, avec un temps de réflexion réduit, GPT-6.1 Sol réussit 86,6 % des migrations, contre 5,4 % pour GPT-5.6 Sol, qui coûtait pourtant plus cher.

Avec plus de temps de réflexion, il atteint même 97,9 %.

Graphique d'OpenAI : GPT-6.1 Sol approche 98 % d'exactitude en migration COBOL pour moins de 1 dollar par essai, devant GPT-6, GPT-5.6 et Astra

À ce niveau, le test n'a presque plus de marge : pour savoir si le prochain modèle fait mieux, il faudra corser l'exercice.

OpenAI, juge et partie

Avant de renvoyer les devs COBOL à la retraite pour de bon, mieux vaut garder en tête que tous ces chiffres viennent d'OpenAI : l'entreprise a conçu les tests, fait passer l'examen à ses propres modèles et corrigé elle-même les copies.

Si MultiLangBench est publié en open source, les tests de migration COBOL dont parle la firme de Sam Altman ne sont quant à eux pas publics.

OpenAI ne précise pas non plus combien de programmes les modèles devaient migrer dans le cadre de cet exercice, ni leur taille.

Difficile, dans ces conditions, de savoir par exemple si ces programmes ressemblent de près ou de loin aux dizaines de millions de lignes de COBOL de la sécurité sociale américaine.

L'entreprise prévient d'ailleurs elle-même qu'un passage en prod demande toujours une relecture par des experts et des tests qui confrontent le code aux règles métier et aux dépendances de l'existant, d'autant qu'il est très souvent question de systèmes critiques.

Pour son évaluation, OpenAI avait déjà sous la main les tests qui comparent chaque programme migré à l'original. Dans une vraie migration, il faudra d'abord les écrire, et donc savoir exactement ce que le système doit produire dans chaque cas.

Et ce savoir-là ne peut pas être scrapé sur GitHub : il est dans la tête des devs COBOL qui maintiennent ces systèmes depuis des décennies.

À propos de l'auteur

Nicolas Lecointre

Nicolas Lecointre

Fondateur des Joies du Code, je suis l'actualité et la culture des développeurs depuis 2012. Ancien développeur, je me consacre aujourd'hui entièrement au média.

Voir sa page auteur

Offres d'emploi

Voir toutes les offres

À lire également

Articles similaires