Le 19 octobre (heure locale), OpenAI a annoncé que les capacités de développement et de migration de ses derniers modèles avaient fortement progressé pour les langages de programmation sur lesquels l’IA dispose de peu de code ou de documentation pour s’entraîner, comme COBOL, Fortran ou Visual Basic. Pour mesurer ces progrès, l’entreprise a conçu deux évaluations internes. Lors de celle portant sur la migration de programmes COBOL vers un autre langage, le taux de réussite a atteint 97,9 % avec un niveau de raisonnement plus élevé.
Avant les chiffres, il faut comprendre la place qu’occupent encore les vieux langages
COBOL est un langage créé en 1959. Certains seront peut-être surpris qu’un langage aussi ancien soit encore utilisé, mais il reste très présent dans les systèmes des institutions financières et des administrations. Selon OpenAI, COBOL est à la base de plus de 40 % des systèmes de banque en ligne, de 80 % des transactions par carte de crédit en face à face et de 95 % des opérations aux distributeurs automatiques.
Fortran, également évalué cette fois-ci, est utilisé pour les prévisions météorologiques et les analyses de sûreté des réacteurs nucléaires. Comparé à Python ou JavaScript, le volume de code et de documentation dont l’IA peut tirer des enseignements est limité. Le paradoxe, c’est que ces langages continuent pourtant de soutenir les fondations de la société.
Cette initiative aurait été lancée après que des développeurs et des entreprises clientes eurent signalé que les modèles de programmation peinaient avec ces langages. Il faut retenir que le projet part de difficultés concrètes rencontrées sur le terrain.
Une évaluation de migration où « ça fonctionne » ne suffit pas
La rigueur de la deuxième évaluation mérite l’attention. Elle consiste à migrer un programme COBOL vers le C++, Java, Kotlin, Python ou Rust, puis à vérifier qu’il conserve le même comportement que le programme d’origine. Pour réussir, les sorties doivent correspondre parfaitement, octet par octet. De plus, les tests utilisés ne sont pas publics, et seul un programme qui les réussit tous est considéré comme une réussite.
Un exemple permet de bien comprendre. En arithmétique à virgule fixe avec COBOL, les décimales supplémentaires sont tronquées, sauf si l’on précise explicitement qu’il faut arrondir. Que se passerait-il si, après la migration, le programme se mettait à arrondir par habitude ? Aucune erreur ne serait signalée, mais le résultat du calcul d’un montant pourrait être différent.
Il suffit d’imaginer des écarts d’un yen qui s’accumulent sur des millions d’opérations bancaires ou d’assurance pour saisir l’importance de cette évaluation. Il serait sans doute plus juste de parler non pas d’un simple remplacement de langage, mais du transfert vers un autre langage du « comportement » d’un code où des règles métier, parfois implicites, se sont inscrites au fil des années.
Comment interpréter le chiffre de 97,9 % ?
Récapitulons les résultats. Lors de l’évaluation de migration, le taux de réussite de « GPT-6.1 Sol » était de 86,6 % avec un niveau de raisonnement bas. Dans les mêmes conditions, celui de GPT-5.6 Sol était de 5,4 %, soit un écart considérable. Le coût de l’API serait limité à 61 % de celui de GPT-5.6 Sol. En augmentant le niveau de raisonnement, le taux de réussite a atteint 97,9 %.
L’autre évaluation, « MultiLangBench », est d’une nature différente. Elle consiste à demander de créer de zéro un moteur de base de données compatible avec SQLite dans chacun de 20 langages de programmation. Avec un niveau de raisonnement maximal, « GPT-6 Astra » a obtenu un taux moyen de réussite aux tests de 87,4 % sur les 20 langages, contre 26,8 % pour GPT-5.6 Sol.
Pour éviter toute confusion, voici un tableau comparant les deux évaluations.
【Comparaison des évaluations】
・Évaluation de migration : migration de COBOL vers l’un de 5 langages, avec vérification de l’identité des sorties octet par octet. GPT-6.1 Sol obtient 86,6 % avec un faible niveau de raisonnement, et 97,9 % lorsque celui-ci est augmenté.
・MultiLangBench : création d’un moteur de base de données compatible avec SQLite dans 20 langages. GPT-6 Astra affiche un taux moyen de réussite de 87,4 %.
COBOL reste le plus difficile
Dans MultiLangBench, 19 des 20 langages ont dépassé les 83 %. COBOL a obtenu 72,1 % : un net progrès par rapport aux 10,9 % de GPT-5.6 Sol, mais il demeure le langage le plus difficile.
Le modèle à bas coût « GPT-6 Luna » a lui aussi dépassé GPT-5.6 Sol, avec une moyenne de 40,3 %. Le coût estimé de l’API par échantillon est de 0,77 dollar, soit environ 78 % de moins que les 3,48 dollars de GPT-5.6 Sol. L’environnement d’évaluation et la suite de tests devraient être publiés sur GitHub.
Les progrès de l’IA et l’état actuel de la modernisation des systèmes existants
Ce n’est pas la première fois que l’IA est utilisée pour migrer du COBOL. En 2023, IBM a annoncé « watsonx Code Assistant for Z », un outil qui convertit du COBOL en Java grâce à l’IA générative. En février dernier, la société américaine Anthropic a expliqué dans un billet de blog comment Claude Code pouvait contribuer à la modernisation de COBOL. Cette annonce a pesé sur le cours d’IBM, qui a enregistré sa plus forte baisse en une journée depuis environ 25 ans. Le marché suit donc ce secteur de près : un seul billet de blog suffit à faire vaciller le cours de l’action.
Le contexte social compte également. En 2020, pendant la pandémie de COVID-19, les demandes ont afflué vers les systèmes d’assurance chômage des États américains, conçus en COBOL. Certains se souviennent peut-être que le manque de spécialistes capables d’intervenir était devenu un problème. La question de savoir si l’IA peut s’attaquer aux domaines où la main-d’œuvre manque ne relève pas seulement de la technologie : elle touche à la pérennité des administrations et de la finance.
À utiliser sans lui confier entièrement la tâche
Malgré ces chiffres élevés, OpenAI souligne qu’une revue par des spécialistes et des tests au regard des règles métier et des dépendances du système restent indispensables avant toute mise en production. Même si les tests vérifiant une correspondance octet par octet sont réussis, les systèmes en place comportent encore des traitements d’exception et des connexions avec d’autres systèmes que les tests d’évaluation n’anticipent pas.
Je pense qu’il est plus réaliste de voir l’IA non comme une « formule magique pour tout remplacer d’un coup », mais comme un « sous-traitant qui fait avancer la migration de manière à en faciliter la vérification ». Lorsque la documentation des spécifications du système d’origine a disparu, la capacité à concevoir des méthodes permettant de vérifier que son comportement initial est bien reproduit aura sans doute plus de valeur que la rapidité de conversion. Le chiffre de 97,9 % montre que, à condition que les humains prennent en charge les vérifications, le champ des migrations possibles s’est considérablement élargi.
コメント