Le 19 octobre 2026, OpenAI a présenté de nouveaux résultats sur la programmation dans des langages peu représentés dans les données d'entraînement. Les travaux sur OpenAI et COBOL incluent la construction d'un moteur compatible SQLite et la migration de programmes existants. Les scores s'améliorent dans les tests internes de l'entreprise, mais le vrai enjeu pour les équipes qui maintiennent ces systèmes reste la conservation du comportement logiciel, y compris les règles qu'un code apparemment plus moderne pourrait altérer.
Que mesurent les deux évaluations?
OpenAI distingue deux capacités distinctes. MultiLangBench mesure la proportion de logiciels fonctionnels qu'un modèle parvient à construire dans vingt langages. La seconde évaluation porte sur la traduction de programmes COBOL en préservant leurs sorties. Ce sont des benchmarks publiés par l'éditeur, pas un bilan de migrations bancaires achevées. L'annonce met à jour le tableau du codage agentique d'OpenAI: elle rend observables des tâches et des critères de réussite spécifiques, sur lesquels vérifier les progrès annoncés.
Sur MultiLangBench, OpenAI rapporte un taux moyen de réussite aux tests de 87,4% pour GPT-6 Astra, contre 26,8% pour GPT-5.6 Sol, au niveau de raisonnement maximal. Dans la migration COBOL, GPT-6.1 Sol atteint 86,6% à faible raisonnement contre 5,4% pour son prédécesseur; avec un raisonnement plus élevé, il monte à 97,9%. Sur MultiLangBench, GPT-6 Luna obtient 40,3%. Ces évaluations ont des critères différents: ces pourcentages ne forment pas un classement unique.
Our latest model advances bring stronger capabilities for building and migrating software in low-resource programming languages such as COBOL, Fortran, and Visual Basic.
, OpenAI (@OpenAI) October 19, 2026
These languages power software that banks, governments, and businesses depend on. Progress here means… pic.twitter.com/Mulo5P3iCO
Pour ceux qui suivent l'adoption de l'intelligence artificielle en entreprise, la question centrale est de comprendre ce qu'on demande exactement au système. Écrire une nouvelle fonction et remplacer un programme qui opère depuis des années peuvent mobiliser des compétences communes, mais les risques sont différents. Dans le second cas, une simplification apparemment raisonnable peut modifier une règle que personne n'a documentée ailleurs. L'évaluation doit donc connaître également ce que le nouveau code doit conserver.
Comment contrôler un moteur SQLite reconstruit?
Le dépôt public MultiLangBench décrit le protocole en détail. Le modèle reçoit la documentation de SQLite 3.40.1 et doit produire un exécutable dans le langage demandé. Chaque cas part d'une base de données initiale, applique une requête au programme candidat et vérifie le résultat en utilisant l'implémentation de référence. Cela permet d'évaluer des implémentations écrites dans des langages différents via une interface commune, plutôt que de juger si le code paraît plausible à un lecteur humain.
Le README distingue aussi le matériel disponible du sous-ensemble suggéré. Environ 24 000 cas ont été convertis depuis la suite originale; pour des raisons de coût, le document indique un sous-ensemble de 272 tests, tout en permettant des évaluations plus étendues à condition qu'elles soient déclarées. Il serait inexact de confondre le nombre de cas présents dans le dépôt avec le nombre effectivement exécuté dans chaque évaluation. Le détail compte: un pourcentage devient comparable uniquement quand l'échantillon, l'environnement et les règles d'exécution sont explicites.
Les instructions imposent un environnement sans accès à Internet et la suppression des copies de SQLite que le modèle pourrait réutiliser. Ce sont des conditions conçues pour isoler la capacité observée. Dans les comparaisons entre benchmarks, le périmètre des outils disponibles fait partie du résultat. Ici, la question porte sur la capacité à construire une implémentation: pouvoir rappeler le programme original changerait la tâche et rendrait le score moins informatif.
Pourquoi conserver les sorties est plus difficile que réécrire?
Notre lecture est que le critère le plus intéressant concerne la continuité des règles métier. Un programme peut compiler, répondre rapidement et produire un fichier valide, tout en traitant différemment un cas limite. Prenons un exemple illustratif: une archive dans laquelle un champ vide signifie «à vérifier». Une réécriture qui le convertit systématiquement en zéro pourrait réussir de nombreux tests ordinaires et modifier le sens des seuls dossiers encore incomplets.
La comparaison avec la sortie précédente sert à identifier des différences de ce type; elle ne décide pas seule si l'ancienne règle était correcte. Notre lecture distingue deux travaux distincts: répliquer le comportement existant et choisir délibérément quels comportements modifier. Les mélanger rend difficile la distinction entre une erreur de migration et un changement voulu. Le contrôle humain reste nécessaire, surtout lorsque la décision dépend d'une règle métier et non de la grammaire du langage.
OpenAI décrit un cas concret: l'arithmétique en virgule fixe de COBOL tronque les chiffres décimaux excédentaires quand l'arrondi n'est pas explicitement demandé. Réécrire cette partie en arrondissant peut produire des nombres différents sans générer d'erreur d'exécution. C'est pourquoi le test de migration exige une correspondance octet par octet des sorties observables et ne considère une migration réussie que si elle passe tous les tests. La définition du «succès» est bien plus exigeante que la simple compilation.
Un benchmark remplace-t-il les tests de fiabilité?
La documentation officielle de SQLite montre l'ampleur du problème de robustesse d'une base de données. Elle décrit des tests sur l'épuisement de la mémoire, les erreurs de lecture et d'écriture, les crashs, les coupures d'alimentation, les fichiers malformés et les régressions. La compatibilité fonctionnelle observée sur un ensemble de requêtes est une dimension utile. La capacité à protéger données et état quand l'environnement se dégrade en est une autre, qui requiert des tests conçus pour ces conditions spécifiques.
Notre lecture est que le benchmark devient plus utile quand il aide à identifier les contrôles manquants. Dans une archive, compteraient par exemple la reprise après interruption et la compatibilité avec les applications qui l'interrogent. Ce sont des vérifications à concevoir, pas des résultats à attribuer aux modèles de recherche. La suite publiée mesure une partie de la fonctionnalité: la fiabilité d'un substitut exigerait aussi des tests construits sur les erreurs et les dépendances du système original.
Qu'est-ce qui rend la comparaison reproductible?
Le dépôt définit le résultat à travers deux éléments: le taux de réussite et le coût des appels à l'interface API. Une réplication devrait déclarer le modèle, l'échantillon, la configuration et les conditions d'exécution, ainsi que la dépense observée. Notre lecture est que conserver ces éléments permet de comprendre si une différence provient d'un modèle meilleur ou d'un budget plus élevé. N'enregistrer que le pourcentage final supprimerait les informations nécessaires pour répéter la comparaison.
Le niveau de raisonnement mérite aussi une attention particulière. Dans la migration COBOL, les 86,6% et les 5,4% se réfèrent tous deux au niveau bas; les 97,9% appartiennent à une configuration plus exigeante, non précisée par une étiquette exacte dans le texte. Les confondre effacerait une différence déclarée. Dans l'évaluation de l'intelligence artificielle appliquée au logiciel, le rapport entre précision et ressources mobilisées doit rester visible, surtout quand on décide quelle configuration tester sur son propre projet.
OpenAI et COBOL:
- Confirmé: publication des résultats le 19 octobre et dépôt MultiLangBench accessible.
- Non démontré: que les scores équivalent à la fiabilité d'une migration bancaire en production.
- À surveiller: les réplications externes, les échantillons déclarés et les vérifications sur les règles spécifiques des systèmes d'entreprise.
La lecture d'ensemble
Notre lecture est que le changement le plus intéressant réside dans la capacité à rendre observable une partie du travail sur les logiciels anciens. Un banc d'essai public permet de discuter des entrées, des contrôles et des erreurs concrètes. C'est pourquoi le sujet du contrôle indépendant des évaluations d'IA reste pertinent même quand le matériel provient d'un autre laboratoire: l'accès à la méthode et la confirmation indépendante sont deux étapes distinctes.
Les signaux à surveiller seront les implémentations reproductibles, les défauts documentés et la comparaison entre le temps gagné à l'écriture et celui requis par la vérification. Un résultat proche du maximum du benchmark peut indiquer un test à rendre plus difficile, pas un problème industriel définitivement résolu. Pour ceux qui maintiennent des systèmes essentiels, le progrès utile se mesure à la qualité des modifications qu'ils parviennent à accepter et à expliquer.
