Dev
OpenAI apprend à ses modèles à bien parler COBOL, Fortran et Visual Basic…
Par Laurent Delattre, publié le 21 octobre 2026
Avec deux évaluations inédites consacrées aux langages « à faibles ressources », OpenAI revendique un bond spectaculaire : ses modèles GPT-6 écrivent désormais du COBOL ou du Fortran et migrent des programmes COBOL vers Java ou Rust sans en altérer le comportement. De quoi relancer une course à la modernisation où AWS, IBM, Google, Microsoft et Anthropic se bousculent déjà.
En informatique, les langues mortes ont la vie dure. Selon IBM, COBOL fait encore tourner plus de 40 % des systèmes bancaires en ligne, 80 % des paiements par carte en magasin et 95 % des retraits aux distributeurs ! Fortran sert toujours aux prévisions météorologiques et aux analyses de sûreté nucléaire. Et ne parlons pas de VB (Visual Basic) qui a laissé une empreinte indélébile dans bien des développements d’apps métiers et dans les macros attachées aux documents Office.
Pourtant, ces langages sont souvent considérés comme délaissés par les IA génératives, faute d’un corpus de code et de documentation comparable à celui du C++, de Python ou de JavaScript. C’est pourquoi les assistants de programmation se sont jusqu’ici souvent montrés à la peine sur un terrain où les équipes en auraient pourtant le plus besoin. Les DSI le savent, les applications écrites dans ces anciens langages riment trop souvent avec des documentations lacunaires, des codes peu commentés, des développeurs d’origine partis depuis longtemps, des règles métier qui ne survivent plus que dans le code.
Reconstruire SQLite dans vingt langages
Pour évaluer les progrès de ses modèles dans la compréhension et la génération de ces langages anciens, OpenAI a créé MultiLangBench.
Si le principe est simple, l’exercice n’en demeure pas moins redoutable : sans accès à Internet et guidé uniquement par la documentation de SQLite 3.40.1, le modèle IA doit dans un premier temps recréer de toutes pièces un moteur de base de données compatible dans l’un des vingt langages retenus. Il doit ensuite réussir une batterie de tests tirés de la suite officielle du projet.
Et à en croire les résultats publiés, GPT-6 Astra marque une réelle avancée en la matière sur les générations précédentes. Il réussit en moyenne 87,4 % des tests, contre 26,8 % pour GPT-5.6 Sol. Plus économique, le modèle GPT-6 Luna plafonne à 40,3 % mais pour 0,77 dollar seulement par échantillon contre 3,48 dollars pour GPT-5.6 Sol qui ne réussit que 26,8 % des tests. On notera qu’OpenAI prend bien soin de ne pas préciser le coût moyen des tests sur son très onéreux GPT-6 Astra.
Migrer du vieux code sans le trahir
La seconde évaluation répond sans doute davantage aux préoccupations des DSI. Elle consiste à convertir des programmes COBOL en C++, Java, Kotlin, Python ou Rust, tout en conservant exactement les mêmes résultats lors de tests cachés. Le moindre écart suffit à faire échouer la migration. Or, les pièges sont nombreux. En COBOL, les décimales en trop sont par exemple tronquées, sauf si un arrondi est demandé. Un programme réécrit qui arrondit à la place peut donc fonctionner sans erreur, mais produire des résultats financiers inexacts.
Dans ce test, GPT-6.1 Sol réussit 86,6 % des migrations avec un réglage de raisonnement limité, contre seulement 5,4 % pour GPT-5.6 Sol. Il coûte aussi 39 % moins cher. Avec un réglage plus poussé, son taux de réussite grimpe à 97,9 %, soit presque un sans-faute.
En clair, les modèles savent désormais analyser assez finement un programme ancien pour le documenter ou le traduire. Et forcément, cela change un peu la donne pour tous les DSI confrontés à une dette technique ancestrale.
Bonne nouvelle néanmoins pour les équipes de développement actuelles, l’IA n’en est pas encore au stade où tout ce travail de modernisation se fait en aveugle. OpenAI recommande avant toute mise en production que des experts vérifient le code et mènent des tests adaptés aux règles métier et aux dépendances du système.
Une bataille d’outillage déjà engagée
Les grands acteurs n’ont pas attendu ces chiffres pour dégainer leurs outils. AWS Transform for mainframe, qui a absorbé Blu Age, analyse les programmes COBOL et les JCL, documente les règles métier puis convertit le code en Java.
IBM a fait évoluer watsonx Code Assistant for Z vers son très populaire assistant agentique Bob, enrichi cet été de processus dédiés au COBOL et au PL/I d’IBM Z.
Google Cloud pousse son Mainframe Assessment Tool, qui extrait les règles métier avec Gemini.
Microsoft propose dans GitHub Copilot des agents (encore en preview) qui convertissent du code mainframe vers Java.
Et, pour l’anecdote, rappelons qu’en février dernier, Anthropic, avec un simple billet consacré à Claude Code et au COBOL, avait fait plonger l’action IBM de 13 % en une séance.
Les investisseurs IBM y voyaient la mort du mainframe, qui se porte pourtant à merveille. Contrairement aux DSI, ils ignoraient que moderniser un tel existant ne se résume pas à une simple traduction du code. Ordonnancement des traitements batch, migration des données, adhérences à CICS, IMS ou DB2… les embûches se logent bien au-delà du code COBOL.
IBM tient d’ailleurs exactement le même langage en affirmant que le principal défi vient davantage de la plateforme que du langage, un argument qui, il est vrai, sert aussi ses propres intérêts, l’avenir des IBM Z et son discours autour de Bob.
Les nouveaux tests publiés par OpenAI confirment ainsi que le modèle est de moins en moins le maillon faible de toute modernisation et que c’est la validation qui doit désormais concentrer toute l’attention des équipes de développement.
En somme, les langues mortes du SI ont trouvé leurs traducteurs, mais leurs copies devront encore être soigneusement relues.
À LIRE AUSSI :
À LIRE AUSSI :
