Le 19 octobre 2026, OpenAI a annoncé des progrès de ses modèles pour les langages de programmation dits « peu dotés en ressources », notamment COBOL, Fortran et Visual Basic. L’expression ne désigne pas ici une langue humaine peu représentée : elle décrit un langage informatique pour lequel les modèles trouvent moins de code, de documentation et d’exemples que pour Python ou JavaScript. L’amélioration est importante pour les organisations qui maintiennent des logiciels anciens ou spécialisés. Elle ne signifie toutefois pas qu’un assistant peut modifier seul un système critique. Pour un développeur, un étudiant ou une petite équipe, la bonne réponse consiste à construire un protocole de test reproductible avant d’adopter l’outil.

Ce qui change réellement

OpenAI explique que ses modèles récents sont devenus plus capables de comprendre, construire et migrer du code dans des langages moins présents dans les données d’entraînement. Le besoin est concret : certains de ces langages soutiennent encore des services essentiels, tandis que leur documentation, leurs bibliothèques et leurs communautés sont plus réduites que celles des écosystèmes dominants.

Le progrès porte donc sur un angle mort des assistants de programmation. Il peut faciliter l’explication d’un module ancien, la rédaction d’un test ou la préparation d’une migration. Mais une annonce globale ne mesure pas votre version du compilateur, vos conventions internes, vos dépendances ni vos contraintes réglementaires. La performance utile doit être vérifiée sur votre propre code.

Pourquoi le compilateur et les tests restent indispensables

Une étude publiée en février 2026 sur Idris illustre la différence entre une réponse plausible et un programme validé. Sans retour, GPT-5 ne résolvait que 22 exercices sur 56. Avec une boucle fondée sur les erreurs du compilateur et les tests locaux, il en résolvait 54. Le résultat ne prouve pas qu’un modèle devient fiable dans tous les langages ; il montre que le feedback exécutable peut transformer fortement sa performance.

Cette logique vaut pour tout projet : le modèle propose, l’environnement tranche. Un code qui semble correct peut échouer à la compilation, modifier un type, oublier un cas limite ou produire un résultat différent avec une ancienne bibliothèque. Plus le langage est rare ou le système ancien, moins il faut accepter une sortie sans preuve.

Construire un jeu de vingt tâches représentatives

Commencez par sélectionner vingt exemples anonymisés issus du travail réel. Répartissez-les en quatre groupes : expliquer du code existant, corriger un défaut connu, ajouter une petite fonctionnalité et écrire des tests. Incluez des cas simples, courants et difficiles. Pour chaque tâche, notez le résultat attendu, la commande de compilation, les tests à exécuter et les fichiers que l’outil n’a pas le droit de modifier.

Évitez de choisir uniquement des exercices scolaires. Un assistant peut réussir une fonction isolée et échouer sur un projet où les règles sont réparties entre plusieurs modules. Ajoutez donc des dépendances réelles, une convention interne et au moins un cas où la bonne réponse consiste à demander une information manquante.

Mesurer cinq critères au lieu d’une impression

Pour chaque essai, mesurez cinq éléments : compilation réussie, tests passés, absence de régression, respect du périmètre et temps de correction humaine. Conservez aussi le prompt, la version du modèle et les erreurs retournées. Une réponse plus élégante n’est pas meilleure si elle exige davantage de retouches ou modifie des fichiers non demandés.

Comparez ensuite l’outil à votre méthode actuelle. S’il réduit le temps sur l’explication mais augmente les erreurs lors des migrations, limitez son rôle. L’adoption n’a pas besoin d’être totale : une équipe peut autoriser l’assistant pour documenter et générer des tests, tout en gardant les modifications de production sous revue stricte.

Donner au modèle le bon contexte, sans lui donner tout le dépôt

Fournissez la version du langage, les commandes de compilation, les interfaces utiles et un exemple conforme aux conventions du projet. Le travail MultiPL-T sur les langages moins dotés montre aussi l’intérêt de générer des tests puis de valider les traductions plutôt que de conserver du code simplement parce qu’il ressemble à la cible.

Limitez cependant l’accès aux secrets, données personnelles et composants sans rapport avec la tâche. Un contexte plus large n’est pas toujours un meilleur contexte. Préférez un dossier de test, une copie contrôlée du module et des droits minimaux. Le résultat doit passer par une revue humaine avant toute intégration.

Une méthode accessible aux petites équipes et aux étudiants

Il n’est pas nécessaire de disposer d’une grande infrastructure. Un dépôt d’exercice, un compilateur local, vingt cas documentés et un tableau de résultats suffisent pour commencer. Un étudiant peut appliquer la même méthode à un langage enseigné dans son établissement. Une PME peut l’utiliser pour évaluer un ancien outil interne sans exposer immédiatement son système de production.

Transformez chaque erreur découverte en nouveau test permanent. Au fil des essais, vous construirez une base qui mesure les progrès des modèles sans dépendre de leurs promesses. Cette discipline est particulièrement utile quand la documentation est rare : elle remplace l’intuition par des preuves exécutables.

Conclusion : tester avant d’élargir

Les progrès annoncés le 19 octobre élargissent le champ des assistants de code, mais ils ne suppriment ni les compilateurs, ni les tests, ni la revue. La prochaine étape est simple : choisissez vingt tâches réelles, définissez les critères avant l’essai, exécutez chaque sortie dans un environnement isolé et mesurez le temps de correction. Adoptez l’outil là où il apporte une preuve de valeur, puis élargissez seulement lorsque les résultats restent stables.