Maya Bennett
IBM Research a présenté ScarfBench, un benchmark ouvert conçu pour évaluer la capacité des agents IA à gérer la migration de frameworks Java d'entreprise. Le benchmark révèle que la configuration et les dépendances d'exécution sont les principaux obstacles, et non la traduction de code.
Les récentes avancées dans les agents de codage ont suscité un engouement autour de la modernisation assistée par IA. Mais une question importante demeure : les agents IA peuvent-ils moderniser de manière fiable des applications d'entreprise réelles ?
Les benchmarks existants en génie logiciel ont montré des progrès impressionnants dans la correction de bugs et la génération de code, mais la migration de framework présente un défi fondamentalement différent. Le succès nécessite non seulement de traduire le code, mais aussi de préserver le comportement, d'adapter les systèmes de build et de naviguer dans les dépendances d'exécution.
Pour combler cette lacune, IBM Research a créé ScarfBench (Self-Contained Application Refactoring Benchmark), un benchmark ouvert pour évaluer les agents IA sur des tâches de migration entre frameworks en Java d'entreprise. ScarfBench se concentre sur les migrations entre trois écosystèmes Java majeurs : Spring, Jakarta EE et Quarkus.
Contrairement aux benchmarks traditionnels qui comparent le code généré à des implémentations de référence, ScarfBench évalue si les applications migrées se construisent, se déploient et préservent effectivement le comportement.
Pourquoi la migration est difficile
La migration de framework va bien au-delà du remplacement d'annotations. Une simple migration de dépôt peut nécessiter des modifications dans l'injection de dépendances, la configuration de persistance, les requêtes et les descripteurs de framework. De petites erreurs dans l'un de ces éléments peuvent empêcher un déploiement réussi.
Figure : Exemple de migration Spring → Jakarta
La migration de framework nécessite de traduire la sémantique du framework, pas seulement le code source.
Présentation de ScarfBench
ScarfBench offre un moyen systématique d'évaluer les agents IA sur des tâches de migration de frameworks Java d'entreprise. Les applications doivent se construire avec succès, se déployer correctement et passer la validation comportementale. Cela fournit une mesure beaucoup plus réaliste de la qualité de la modernisation.
Le benchmark inclut à la fois des tâches de migration ciblées et des migrations d'applications entières.
Figure : Pipeline de construction de ScarfBench
À partir d'une taxonomie Java d'entreprise basée sur JSR, des migrations expertes créent des implémentations vérifiées sur Spring, Jakarta EE et Quarkus.
Comment les agents de pointe se comportent-ils ?
IBM Research a évalué plusieurs agents de codage de pointe sur ScarfBench. Malgré de bonnes performances sur les benchmarks traditionnels de génie logiciel, la migration de framework reste difficile. Les taux de succès varient considérablement selon les paires de frameworks, et les migrations d'applications entières restent particulièrement difficiles.
Figure : Classement actuel
Figure : Progression Compilation → Déploiement → Test
Le succès de compilation dépasse systématiquement celui du déploiement, qui lui-même dépasse le succès comportemental. Le seul succès de construction surestime considérablement la qualité de la migration.
Figure : Résultats de migration par framework cible
La difficulté de migration dépend fortement du framework cible, Jakarta EE s'avérant particulièrement difficile.
Ce que nous avons appris sur les agents IA pour la modernisation Java
Au-delà de la mesure des taux de succès, ScarfBench aide à comprendre comment les agents se comportent pendant la modernisation.
Les agents peuvent-ils dire de manière fiable quand une migration est terminée ?
Une application migrée n'est utile que si elle se construit et s'exécute réellement. IBM Research a comparé les résultats rapportés par les agents à une vérification indépendante de la construction.
« Claude Code a signalé des constructions réussies pour 29 applications sur 30. Seules 22 de ces applications se sont réellement construites avec succès. Pendant ce temps, l'unique application classée comme échouée par l'agent s'est finalement construite correctement. »
— IBM Research
Cela suggère que l'auto-évaluation des agents ne doit pas être considérée comme un signal fiable de l'achèvement de la migration. Une validation indépendante par construction et test reste essentielle.
Comment les agents naviguent-ils dans les dépendances des applications ?
Les migrations de framework affectent rarement un seul fichier ou une seule couche. Les modifications dans la configuration, les services, les bases de données et les composants web se répercutent souvent sur l'ensemble de l'application.
Les couches les plus fréquemment visitées étaient la configuration, le web, la base de données et les services. Les transitions courantes incluaient configuration ↔ web et service ↔ base de données. Cela suggère que la migration est un processus itératif de résolution de dépendances plutôt qu'une simple transformation source-à-source.
Où les agents dépensent-ils le plus d'efforts ?
En utilisant la fréquence de revisite des couches comme indicateur de l'effort de migration, les chercheurs ont constaté que la configuration domine l'effort de migration. Plutôt que de procéder linéairement, les agents revenaient à plusieurs reprises sur les artefacts liés à la configuration tout en résolvant les différences de framework et les problèmes de dépendances.
Quels défis ne concernent pas la transformation de code ?
Tous les problèmes de migration ne proviennent pas du code source. Les agents ont souvent rencontré des difficultés avec des problèmes environnementaux, notamment des incohérences de cache Docker, des problèmes de connectivité de port, et des problèmes de wrapper Maven et d'outils de build. Ces problèmes opérationnels retardaient souvent la validation même lorsque la migration du code source était en grande partie terminée.
Figure : Répartition des modes d'échec
Les échecs de modernisation couvrent les systèmes de build, les environnements de déploiement, l'injection de dépendances, les bases de données, les points de terminaison, les assertions et l'infrastructure.
Point clé à retenir
Le plus grand défi dans la modernisation de framework n'est pas la traduction du code Java. C'est la gestion du réseau de dépendances à travers la configuration, l'infrastructure et les environnements d'exécution. Bien que les agents de pointe puissent automatiser des parties substantielles du processus de migration, la validation fiable et le raisonnement architectural restent essentiels pour obtenir des résultats réussis.
ScarfBench aide à exposer ces défis et fournit un moyen standardisé de mesurer les progrès vers une modernisation d'applications véritablement autonome.
Explorez ScarfBench
ScarfBench est conçu comme une ressource ouverte pour les chercheurs et les praticiens. Les ressources incluent un ensemble de données de benchmark, une infrastructure d'évaluation, un classement public, de la documentation et du code open source. Les chercheurs peuvent comparer les architectures et techniques des agents. Les praticiens peuvent utiliser ScarfBench pour évaluer les solutions de modernisation avant de les déployer dans des environnements de production.
- Site web : https://scarfbench.info
- Ensemble de données : https://huggingface.co/datasets/ibm-research/ScarfBench
- Espace : https://huggingface.co/spaces/ibm-research/ScarfBench
- Dépôt GitHub : https://github.com/scarfbench/scarfbench
- Classement : https://scarfbench.info/leaderboard
- Article : https://arxiv.org/abs/2605.06754
La migration de framework reste l'un des plus grands problèmes non résolus dans le génie logiciel assisté par IA. IBM Research espère que ScarfBench aidera la communauté à mesurer les progrès et à accélérer la prochaine génération de modernisation d'applications assistée par IA. L'équipe invite les chercheurs, les praticiens et les auteurs de frameworks à contribuer et à repousser les limites de ce que les agents IA peuvent accomplir dans la modernisation des logiciels d'entreprise.
