Faire progresser la programmation dans les langages à faibles ressources
Les dernières avancées de nos modèles renforcent leurs capacités à créer et à migrer des logiciels dans des langages de programmation à faibles ressources, tels que COBOL, Fortran et Visual Basic. Ces langages disposent de moins de code et de documentation pour l’apprentissage des modèles que des langages comme Python et JavaScript. Ils font pourtant fonctionner des infrastructures critiques et des services essentiels dans le monde entier. COBOL fait fonctionner(ouverture dans une nouvelle fenêtre) 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, tandis que Fortran est utilisé pour les prévisions météorologiques(ouverture dans une nouvelle fenêtre) et l’analyse de sûreté des réacteurs nucléaires(ouverture dans une nouvelle fenêtre). Améliorer la capacité de l’IA à travailler dans ces langages pourrait aider les équipes à maintenir et à moderniser les logiciels dont dépendent les services essentiels.
Ces travaux sont guidés par les retours de développeurs et d’entreprises clientes, qui nous ont signalé les difficultés fréquentes des modèles de programmation avec ces langages. Maintenir et moderniser ces logiciels peut être difficile : 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. Qu’elles corrigent des bugs ou migrent vers un autre langage, les équipes doivent préserver le comportement dont dépendent leurs systèmes.
Pour mesurer les progrès, nous avons développé deux évaluations. MultiLangBench vérifie si un modèle peut créer de toutes pièces un moteur de base de données compatible avec SQLite dans 20 langages de programmation différents. Notre évaluation de migration COBOL vérifie si un modèle peut migrer des programmes existants vers un autre langage tout en préservant leur comportement. Ensemble, elles testent deux compétences complémentaires : créer de nouveaux logiciels et préserver le fonctionnement des logiciels existants.
Nos derniers modèles affichent des progrès considérables dans les deux évaluations, avec une exactitude bien supérieure à moindre coût.
Sur MultiLangBench, GPT‑6 Astra atteint un taux moyen de réussite aux tests de 87,4 % sur 20 langages de programmation, contre 26,8 % pour GPT‑5.6 Sol, avec des progrès dans chaque langage testé. 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 %.
Dans notre évaluation de migration COBOL, GPT‑6.1 Sol atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre seulement 5,4 % pour GPT‑5.6 Sol, pour un coût inférieur de 39 %. Avec un effort de raisonnement plus élevé, l’exactitude atteint 97,9 %, soit un résultat proche du plafond de l’évaluation.
Dans l’ensemble, ces résultats montrent que nos modèles deviennent nettement plus performants sur un large éventail de langages de programmation, tout en offrant un meilleur rapport coût-efficacité.
MultiLangBench demande à un modèle de créer un moteur de base de données compatible avec SQLite dans un langage de programmation donné. Le modèle doit organiser une base de code, gérer l’état et les erreurs, et ajouter de nouvelles fonctionnalités tout en préservant celles qui existent déjà.
Pour comparer les implémentations entre les langages, nous utilisons des fichiers de base de données comme interface commune. Le programme évalué reçoit une base de données initiale et une requête SQL, puis produit une base de données modifiée. Nous utilisons l’implémentation de référence de SQLite pour vérifier si la base de données obtenue contient les données attendues. Cela nous permet d’appliquer les mêmes tests, quel que soit le langage utilisé pour créer le moteur.
Nous avons adapté à ce format des tests issus de la suite de tests existante de SQLite. L’évaluation mesure la quantité de fonctionnalités opérationnelles qu’un modèle peut créer lors d’une session de programmation prolongée, en indiquant le taux de réussite aux tests et le coût de l’API.
Avec un effort de raisonnement maximal, GPT‑6 Astra atteint un taux moyen de réussite aux tests de 87,4 % sur les 20 langages, contre 26,8 % pour GPT‑5.6 Sol. Les progrès concernent chaque langage testé, notamment COBOL (de 10,9 % à 72,1 %), OCaml (de 25,6 % à 85,8 %), Fortran (de 21,4 % à 83,5 %) et Visual Basic (de 27,5 % à 89,4 %). Astra obtient un score supérieur à 83 % dans 19 des 20 langages, COBOL restant le plus difficile avec 72 %.
GPT‑6 Luna offre une option moins coûteuse qui surpasse également GPT‑5.6 Sol dans chaque langage testé. Avec un effort de raisonnement maximal, il atteint un taux moyen de réussite aux tests de 40,3 %. Les gains concernent notamment COBOL (de 10,9 % à 17,1 %), OCaml (de 25,6 % à 34,1 %), Fortran (de 21,4 % à 31,4 %) et Visual Basic (de 27,5 % à 41,6 %). Ces progrès s’accompagnent d’un coût moyen estimé de l’API de 0,77 $ par échantillon, contre 3,48 $ pour GPT‑5.6 Sol, soit une baisse d’environ 78 %.
Nous publions le dispositif d’évaluation et la suite de tests de MultiLangBench sur GitHub(ouverture dans une nouvelle fenêtre), ainsi que les résultats pour chaque langage. Les développeurs peuvent examiner ce que teste l’évaluation, consulter les performances dans les langages qu’ils utilisent et identifier les lacunes pertinentes pour leur travail.
Notre seconde évaluation demande aux modèles de migrer des programmes COBOL vers C++, Java, Kotlin, Python ou Rust tout en préservant le fonctionnement de chaque programme.
Pour réussir une migration, il faut comprendre à la fois la logique métier du programme et les comportements propres au langage COBOL. Les programmes COBOL traitent souvent des transactions financières et des enregistrements métier, où des détails comme les règles d’arrondi et la gestion des enregistrements manquants reflètent les exigences métier. 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.
Pour vérifier que ces comportements sont préservés, nous évaluons nos modèles sur des tests cachés qui exigent des sorties observables identiques, octet par octet. Une migration n’est considérée comme réussie que si tous les tests sont validés. Ces capacités de préservation du comportement sont utiles aux équipes qui maintiennent et modernisent des systèmes anciens. Toutefois, 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.
Dans cette évaluation, GPT‑6.1 Sol atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre 5,4 % pour GPT‑5.6 Sol avec le même réglage, pour seulement 61 % du coût de l’API. Avec un effort de raisonnement plus élevé, l’exactitude atteint 97,9 %, approchant ainsi le plafond de l’évaluation. Ces résultats d’évaluation témoignent des progrès vers une migration de code plus exacte et plus abordable pour les équipes qui modernisent les logiciels dont dépendent leurs entreprises.
Ces évaluations, ainsi que les retours directs des développeurs et des entreprises clientes, nous aident à comprendre où nos modèles progressent et où ils présentent encore des lacunes.
Notre objectif est d’aider les modèles à appliquer leurs compétences en génie logiciel à davantage de langages : comprendre des dépôts inconnus, planifier des modifications, utiliser des outils de compilation, exécuter des tests et corriger les erreurs.
Vous pouvez essayer nos derniers modèles via l’API sur des tâches de programmation dans les langages utilisés par votre équipe. Vos retours sur ce qui fonctionne, les difficultés des modèles et les langages ou processus à privilégier ensuite orientent la façon dont nous entraînons et évaluons les modèles pour mieux prendre en charge les logiciels dont vous dépendez.
