❌

Vue normale

Reçu aujourd’hui — 22 octobre 2026 ⏭ Next - Articles gratuits

OpenAI s’attaque à la migration des projets en COBOL

22 octobre 2026 à 09:53
Réécrivons tout en Rust
OpenAI s’attaque à la migration des projets en COBOL

OpenAI a de nouvelles envies de conquête, cette fois dans le champ de ce qu’elle nomme « les langages à faibles ressources ». L’entreprise vise explicitement cette fois les vieux, voire très vieux langages, au premier rang desquels le COBOL. La promesse est de faire exploser le nombre de projets de migration grâce à ses soins.

Selon OpenAI, les dernières avancées de ses modèles ont renforcé leurs capacités à créer et à migrer des logiciels dans des langages comme COBOL, Fortran et Visual Basic. Des langages dits « à faibles ressources », car ils ont moins de code et de documentation pour entrainer les modèles que d’autres bien plus courants comme Python et JavaScript.

« COBOL fait fonctionner⁠ plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte de crédit en personne et 95 % des transactions aux distributeurs automatiques », indique OpenAI, montrant l’ampleur du marché. Des chiffres familiers ? Nous avions les mêmes dans notre article de juillet 2025 consacré au COBOL et à sa présence toujours importante. Ils sont issus d’une enquête réalisée par Reuters en 2024. Dans notre article, nous montrions d’ailleurs que le langage restait vivant, mais qu’il y avait un déficit de développeurs formés à ce langage. Fortran, utilisé pour les prévisions météorologiques⁠ et l’analyse de sûreté des réacteurs nucléaires⁠, fait aussi partie des langages visés.

OpenAI dit avoir reçu de nombreux retours sur la difficulté à travailler avec l’IA sur ces langages. « La documentation peut être incomplète, les développeurs d’origine peuvent avoir quitté l’entreprise, et des règles métier importantes peuvent n’exister que dans le code », indique OpenAI. Autant de problématiques que nous avions abordées dans notre article.

OpenAI s’est fabriqué deux évaluations

L’entreprise souhaitait savoir si ses modèles avaient progressé. La question est presque rhétorique : le billet d’OpenAI est là pour montrer à quel point ses LLM ont justement progressé.

Pour les mesurer, OpenAI dit avoir créé deux évaluations. La première, MultiLang, vérifie si un modèle peut créer un moteur de base de données compatible avec SQLite dans 20 langages, en partant d’une page blanche. La seconde est une évaluation plus spécifique aux migrations COBOL pour vérifier si le modèle peut migrer des programmes existants en préservant leur comportement. En somme, l’une vérifie la création de nouveaux logiciels, tandis que l’autre s’assure que les migrations réussissent.

Sans surprise, OpenAI indique que les progrès de ses modèles sont « considérables ». Astra a ainsi atteint un score de 87,4 % sur le premier test en moyenne, contre 26,8 % pour GPT-5.6 Sol, avec des progrès sur l’ensemble des 20 langages. « GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40,3 % pour un coût estimé de l’API inférieur d’environ 78 % », ajoute OpenAI.

Les règles particulières du COBOL

L’évaluation spécifique au COBOL est plus intéressante, car le problème initial est plus complexe. OpenAI rappelle ainsi que la réussite d’une migration dépend d’une pleine compréhension de la logique métier et des comportements propres au langage. « Par exemple, l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s’exécuter sans erreur tout en produisant des résultats financiers différents », affirme l’entreprise.

La vérification se base sur des « tests cachés » qui exigent des sorties observables identiques, à l’octet près. La migration n’est considérée réussie que si tous les tests sont validés. Dans le cas présent, les projets en COBOL devaient être convertis en C++, Java, Kotlin, Python ou Rust.

Dans cette évaluation, GPT‑6.1 Sol a atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre à peine 5,4 % pour GPT‑5.6 Sol, le tout avec un coût inférieur de 39 %. OpenAI ajoute qu’avec un effort de raisonnement plus élevé (on ne connait pas l’effort de départ), le score grimpe à 97,9 %.

Le message est donc clair : on peut utiliser Astra et GPT-6.1 Sol pour migrer les projets ou en bâtir de nouveaux compatibles. Une conclusion qu’OpenAI met d’autant plus en avant que l’IA fait exploser depuis plusieurs mois les projets de réécriture, de nombreux développeurs (confirmés ou en herbe) se lançant notamment dans une course aux performances.

OpenAI ajoute toutefois que même si les résultats obtenus vont dans le bon sens, « leur application à des logiciels en production exige toujours une vérification par des experts et des tests tenant compte des règles métier et des dépendances du système ».

Des résultats à prendre avec des pincettes

Le principal problème de cette annonce est son opacité. C’est particulièrement vrai dans le cas de COBOL.

On ne sait pratiquement rien en effet de l’évaluation construite par OpenAI, alors que MultiLang a son dépôt GitHub. Rien sur le nombre de programmes, leur origine, leur taille ou même leur degré de ressemblance avec du COBOL réellement utilisé en production. L’évaluation étant opaque, elle ne peut pas être reproduite par des tiers indépendants et il faut donc croire OpenAI sur parole. Que les modèles progressent sur des langages comme COBOL ou Fortran ne fait pas de doute, mais il est difficile de se rendre compte de l’évolution concrète sur la seule base des affirmations d’OpenAI, les évaluations étant proposées par la même entreprise qui propose les modèles testés.

Notons également que les deux évaluations envisagent des tests très différents dans leur approche. SQLite est un projet présent depuis longtemps et aux nombreuses réimplémentations, des portages existant dans plusieurs des langages testés. Il n’est donc pas étonnant qu’un modèle récent s’en sorte bien, puisqu’il restitue en partie des connaissances présentes dans les données d’entraînement. À l’inverse, la situation est plus complexe pour COBOL, Fortran et d’autres anciens langages, les ressources étant nettement moins nombreuses.

❌