Analyse approfondie · Environ 4 min de lecture
OpenAI mesure des progrès dans les langages moins courants
Les évaluations portent sur SQLite et sur la migration de COBOL sans modification du comportement observable.
- Date de la source
- Publié ici
- Source vérifiée
OpenAI a publié le 19 octobre des évaluations de programmation visant des langages disposant de moins de données d’entraînement, notamment COBOL, Fortran et Visual Basic. Il s’agit de tâches d’ingénierie précises, pas d’une garantie de migration automatique des systèmes anciens.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- MultiLangBench demande de construire des moteurs compatibles SQLite dans 20 langages. OpenAI annonce 87,4 % de tests réussis en moyenne pour GPT-6 Astra avec un effort de raisonnement maximal, contre 26,8 % pour GPT-5.6 Sol.
- Une autre évaluation vérifie que les programmes COBOL réécrits conservent leur comportement observable. Tous les tests cachés doivent réussir pour valider une migration.
Ce que mesurent les deux évaluations
La publication du 19 octobre distingue deux problèmes souvent confondus dans les annonces de programmation par IA. MultiLangBench mesure la quantité de nouvelles fonctions de base de données qu’un modèle peut implémenter ; la tâche COBOL vérifie si une réécriture conserve le comportement existant. Selon notre lecture, cette distinction compte davantage qu’un pourcentage isolé. Un code plausible peut échouer aux deux tests. Une équipe de modernisation doit préciser la capacité recherchée et les preuves capables de révéler un échec avant la mise en production.
Comment le test SQLite vérifie les fonctions
Dans MultiLangBench, le candidat reçoit une base et une requête SQL, modifie la base, puis la véritable implémentation SQLite vérifie le résultat. Le README précise SQLite 3.40.1 et trois éléments : base initiale, requête du candidat et requête de validation de référence. Il indique environ 24 000 tests convertis parmi 51 000 tests TCL, avec un sous-ensemble par défaut de 272. L’utilisation de la suite complète doit être signalée. Notre interprétation : ce format compare des fonctions observables entre langages, sans démontrer une couverture de tous les tests SQLite originaux.
Lire les scores avec leurs paramètres
OpenAI annonce 87,4 % de tests réussis en moyenne pour GPT-6 Astra avec un raisonnement maximal, contre 26,8 % pour GPT-5.6 Sol. COBOL passe de 10,9 % à 72,1 %, restant plus difficile que les autres langages évalués. GPT-6 Luna atteint 40,3 %, pour un coût API estimé de 0,77 dollar par échantillon contre 3,48 dollars pour GPT-5.6 Sol. Ces compromis précision-coût diffèrent. Nous recommandons de comparer le coût par résultat accepté, échecs et revue inclus, plutôt que de confondre appel moins cher et migration moins coûteuse.
Pourquoi la réécriture doit garder le comportement
L’autre évaluation traduit COBOL vers C++, Java, Kotlin, Python ou Rust. Les sorties observables doivent être identiques octet par octet, et tous les tests cachés doivent réussir. L’annonce illustre un piège : l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires sauf demande explicite d’arrondi. Une réécriture qui arrondit peut fonctionner tout en changeant les résultats financiers. OpenAI rapporte 86,6 % pour GPT-6.1 Sol à faible effort, contre 5,4 % pour GPT-5.6 Sol au même réglage et un coût API réduit de 39 % ; un effort supérieur atteint 97,9 %.
Les conditions d’une reproduction utile
Le dépôt public demande de retirer les implémentations SQLite existantes de l’environnement et interdit internet. Une solution dans un autre langage ou mélangeant plusieurs langages échoue ; divergences, plantages et tests dépassant 60 secondes échouent aussi. Ces règles évitent de confondre construction et réutilisation d’un moteur installé. Nous avons consulté la documentation sans exécuter le benchmark. Toute reproduction devrait consigner modèle exact, effort, sous-ensemble, environnement et coût afin de ne pas présenter des conditions modifiées comme une expérience identique.
Passer du benchmark à un pilote maîtrisé
Nous suggérons un pilote limité à un module non critique, en enregistrant des entrées représentatives et les sorties attendues avant toute réécriture. Ajoutez arrondis, enregistrements absents et dépendances propres au module : ce sont nos conseils de validation, pas des résultats publiés. Faites examiner les différences par les responsables métier et gardez un retour arrière possible. L’annonce invite à essayer l’API, sans accorder un budget API supplémentaire aux abonnés ChatGPT. Le progrès justifie une étude, pas l’abandon des critères de production ou de la responsabilité experte.
Pourquoi cela compte
Les équipes peuvent examiner le protocole publié et tester leurs propres règles métier. Le choix du modèle doit intégrer la couverture des tests, les réglages de raisonnement et le coût réel de l’API.
Limites et disponibilité
Ces résultats proviennent du fournisseur et n’ont pas été reproduits par AISubHub. Un benchmark ne garantit pas la sûreté en production : revue experte et tests des dépendances restent nécessaires.
Sources et preuves
Date de la source: 19 oct. 2026 · Source vérifiée: 20 oct. 2026
Pour approfondir
Source vérifiée: 20 oct. 2026
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.