OpenAI lance de nouveaux indicateurs pour la programmation IA dans les langues à faibles ressources

OpenAI lance deux nouvelles évaluations axées sur les « langages de programmation à faibles ressources » : MultiLangBench exige que les modèles implémentent à partir de zéro un moteur de base de données compatible SQLite en utilisant 20 langues différentes ; une autre évaluation demande aux modèles de migrer des programmes COBOL vers C++, Java, Kotlin, Python ou Rust, tout en conservant le comportement d'origine. Les résultats officiels montrent que GPT‑6 Astra atteint un taux moyen de réussite aux tests de 87,4 % sur MultiLangBench, tandis que GPT‑6.1 Sol atteint une précision de 97,9 % lors de la migration COBOL sous forte intensité de raisonnement. Cela indique que les capacités de programmation par IA s'étendent désormais des langages dominants comme Python et JavaScript vers les anciennes technologies encore utilisées par les banques, les gouvernements et les institutions scientifiques. Toutefois, ces résultats proviennent d'évaluations conçues et exécutées par OpenAI ; 87,4 % représente le pourcentage de cas de test réussis et ne signifie pas que le modèle a implémenté une version exploitable de SQLite, ni que 97,9 % permet de considérer que les banques peuvent migrer leurs systèmes critiques sans examen humain.

Auteur et source de l'article : OpenAI

Dans le domaine de la programmation par IA, les langages à faibles ressources désignent les langues pour lesquelles les codes, documents et contenus de questions-réponses publics disponibles pour l'apprentissage des modèles sont relativement limités, et non pas des langues dépourvues de valeur pratique.

Python et JavaScript possèdent un vaste écosystème open source, permettant aux modèles de voir une grande quantité de code, de rapports d'erreurs et de registres de corrections. En revanche, les matériaux publics pour COBOL, Fortran, Visual Basic et OCaml sont beaucoup moins nombreux, et une grande partie de leur code est encore enfermée dans des systèmes internes d'entreprises.

En parallèle, ces langages assument toujours des tâches essentielles. OpenAI cite des données d'IBM selon lesquelles COBOL soutient plus de 40 % des systèmes de banque en ligne, 80 % des transactions par carte de crédit hors ligne et 95 % des transactions aux guichets automatiques ; Fortran est toujours utilisé pour la prévision météorologique et l'analyse de sécurité des réacteurs nucléaires.

Le défi de maintenir ces systèmes ne réside pas seulement dans la vieillesse de la syntaxe. Les développeurs originaux ont peut-être quitté l'entreprise, la documentation est incomplète, et les véritables règles métier ne existent que dans le code. La raison pour laquelle un programme tronque les décimales ou traite les enregistrements de comptes inexistants peut ne jamais avoir été documentée, pourtant elle influence directement les résultats des calculs financiers.

Ainsi, ce que l'IA doit véritablement démontrer, ce n'est pas « si elle peut traduire COBOL en un Python qui semble plus moderne », mais si les règles métiers sont toujours exécutées de manière identique après la migration.

OpenAI a publié MultiLangBench. Il exige que le modèle construise, lors d'un processus de programmation prolongé, un moteur de base de données compatible SQLite en utilisant la langue spécifiée.

Le programme candidat reçoit un fichier de base de données initial et une requête SQL ; après exécution, il produit une base de données modifiée. Le système d'évaluation appelle ensuite l'implémentation officielle de SQLite pour vérifier si le contenu de la base de données correspond au résultat de référence. Grâce à ce fichier de base de données comme interface commune, les mêmes fonctionnalités peuvent être comparées entre langages.

Teste 20 langages, notamment C, C++, COBOL, Fortran, Java, JavaScript, Lean, OCaml, Python, Rust, Visual Basic et Zig, pour évaluer la capacité du modèle à organiser des bases de code, gérer l'état, traiter les erreurs, ajouter de nouvelles fonctionnalités et éviter de rompre les fonctionnalités existantes. Les cas de test sont adaptés de la suite de tests existante de SQLite.

Avec l'intensité d'inférence maximale, le taux de réussite moyen des tests de GPT-6 Astra est de 87,4 %, contre 26,8 % pour GPT-5.6 Sol. OpenAI affirme que Astra présente une amélioration dans les 20 langues :

COBOL passe de 10,9 % à 72,1 %, OCaml de 25,6 % à 85,8 %, Fortran de 21,4 % à 83,5 %, Visual Basic de 27,5 % à 89,4 %. Parmi les 20 langages, 19 dépassent 83 %, et COBOL reste le plus difficile.

(Le module d'interactions en 20 langues basculables permet de consulter les performances et les coûts de chaque modèle pour chaque langue.)

Ces chiffres doivent être correctement interprétés. Les 87,4 % représentent le pourcentage moyen de cas de test réussis et ne signifient pas que le modèle a une probabilité de 87,4 % de générer une base de données complète, stable et entièrement conforme à toutes les spécifications SQLite. Les environ 12,6 % d'échecs restants peuvent encore correspondre à des problèmes tels que les transactions, la gestion des erreurs ou la cohérence des données, suffisants pour empêcher un déploiement en production.

Cela démontre que le modèle peut continuer à construire des logiciels relativement complexes dans une langue inconnue, et non pas que SQLite peut déjà être réécrit en une seule fois par une IA.

OpenAI a également testé GPT-6 Luna, une version moins coûteuse. Il a obtenu un taux de réussite moyen de 40,3 % sur 20 langues, contre 26,8 % pour GPT-5.6 Sol.

Le coût moyen de l'API de Luna est d'environ 0,77 $ par échantillon, contre environ 3,48 $ pour GPT‑5.6 Sol, soit une réduction d'environ 78 %. Toutefois, ses performances n'atteignent pas le niveau d'Astra : Luna obtient 17,1 % sur COBOL, 31,4 % sur Fortran et 41,6 % sur Visual Basic.

Ces résultats présentent deux approches différentes : Astra utilise davantage de ressources d'inférence pour maximiser la réussite des tâches complexes, tandis que Luna traite un plus grand nombre d'échantillons à moindre coût, ce qui la rend idéale pour les essais en masse, les analyses préliminaires et les tâches d'assistance à faible risque.

Le coût mentionné ne représente que l'estimation des frais d'API dans le cadre de l'évaluation et n'inclut pas les ressources humaines nécessaires pour la revue technique, l'environnement de test, la validation métier et la correction des erreurs. Pour les systèmes hérités, les frais d'appel au modèle ne constituent souvent pas le coût le plus élevé dans le cadre du projet de migration.

Le deuxième critère d'évaluation exige que le modèle migre un programme COBOL vers C++, Java, Kotlin, Python ou Rust.

L'accent n'est pas mis sur la propreté du code de traduction, mais sur la cohérence byte à byte des sorties observables entre l'ancien et le nouveau programme. Chaque résultat de migration doit passer tous les tests masqués pour être considéré comme réussi.

OpenAI a cité en exemple les nombres à virgule fixe : COBOL peut par défaut simplement tronquer les chiffres décimaux supplémentaires, à moins que le programme n'exige explicitement un arrondi. Si le modèle modifie arbitrairement en arrondissant selon les habitudes de programmation modernes, le programme fonctionnera normalement, mais les résultats financiers seront modifiés.

Avec une faible intensité d'inférence, l'exactitude de transfert de GPT‑6.1 Sol atteint 86,6 %, contre seulement 5,4 % pour GPT‑5.6 Sol ; le coût estimé de l'API est également inférieur de 39 % pour le premier. En augmentant l'intensité d'inférence, GPT‑6.1 Sol atteint 97,9 %, rendant ce jeu d'évaluations presque saturé.

Les 97,9 % ici représentent « la proportion de programmes ayant réussi intégralement les cas cachés dans le test d'OpenAI », et non « tout système COBOL peut migrer automatiquement et en toute sécurité 97,9 % de son code ».

Les systèmes bancaires réels peuvent être connectés à des mainframes, des bases de données propriétaires, des planificateurs de traitement par lots et des protocoles de communication internes, et présentent des flux d'exception non couverts par les cas de test. OpenAI a également clairement indiqué que le déploiement en production nécessite une revue par des experts et une revalidation en fonction des règles métier réelles et des dépendances.

OpenAI a téléchargé sur GitHub l'environnement d'évaluation, le jeu de tests et les résultats par langue de MultiLangBench ; les développeurs peuvent consulter le contenu des tests et les réexécuter avec d'autres modèles ou frameworks d'agents.

Cela présente plus de valeur qu'une simple affichage d'un tableau de résultats : les observateurs externes peuvent analyser précisément sur quelles fonctionnalités SQL le modèle échoue, ainsi que comparer si les résultats sont influencés par les invites, les permissions des outils, le budget d'inférence et la durée d'exécution.

Cependant, l'article officiel n'a annoncé que la mise à disposition de MultiLangBench, sans mentionner que les échantillons complets du programme d'évaluation de la migration COBOL ainsi que les tests masqués sont désormais accessibles. Le score de 97,9 % de ces derniers ne peut pas être vérifié ni reproduit entièrement par des tiers, contrairement à MultiLangBench.

Les deux évaluations ont également été conçues par OpenAI et sont principalement utilisées pour comparer ses propres modèles. Elles ne couvrent pas encore un grand nombre de bases de code d'entreprises réelles, les coûts de maintenance à long terme, les vulnérabilités de sécurité, la dégradation des performances, ni le temps nécessaire à une révision humaine. Par conséquent, les résultats démontrent d'abord les progrès des modèles sur des tâches contrôlées, et non une validation finale de la résolution du problème de modernisation des logiciels d'entreprise.

Au cours des deux dernières années, les démonstrations de produits d'IA pour la programmation se sont principalement concentrées sur la création de sites web, d'applications mobiles et d'outils Python. Ces scénarios sont intuitifs, mais ne constituent pas les problèmes logiciels les plus coûteux pour les grandes entreprises.

Les banques, les assurances, les gouvernements et les institutions de recherche rencontrent réellement des difficultés avec des codes qui fonctionnent depuis des décennies et que personne n'ose modifier facilement. Ils peuvent ne pas être à la mode, mais contiennent les règles sur lesquelles reposent le traitement des comptes, le calcul des impôts, la chaîne d'approvisionnement et le fonctionnement des infrastructures.

L'importance de MultiLangBench réside précisément dans cela : la capacité du modèle à se détacher de la langue d'entraînement la plus courante et à transférer les méthodes d'ingénierie logicielle vers des piles technologiques où les données sont rares, les outils obsolètes et les erreurs plus coûteuses.

Si cette capacité continue de s'améliorer, le premier changement apporté par l'IA ne sera probablement pas « supprimer en un clic tout le COBOL », mais plutôt aider les ingénieurs à lire du code inconnu, compléter les tests, restaurer la documentation manquante et localiser les règles métier, avant d'effectuer la migration par modules validés. Les experts humains resteront responsables de décider quelles fonctionnalités doivent être conservées et quand il est réellement possible de remplacer les systèmes anciens.