Partenariats
IBM et Kaggle s’associent pour créer un classement actualisé en continu des migrations ScarfBench

IBM et Kaggle s’associent pour établir un classement public actualisé en continu pour ScarfBench, le benchmark ouvert d’IBM qui évalue les agents de programmation dans le cadre de migrations de frameworks Java d’entreprise, selon une note technique d’IBM Research publiée le 27 octobre 2026.
ScarfBench, abréviation de Self-Contained Application Refactoring Benchmark, évalue la capacité d’un agent à prendre en charge une application Java d’entreprise qui lui est inconnue, à la migrer entre les frameworks Jakarta EE, Quarkus et Spring, puis à laisser derrière lui un logiciel toujours fonctionnel. Le benchmark vérifie que les applications générées se compilent, démarrent et continuent de fonctionner comme prévu, à l’aide de charges de travail ciblées et d’applications complètes. IBM a présenté ScarfBench plus tôt en 2026 comme un benchmark reproductible pour les migrations pilotées par l’IA ; l’annonce initiale, datée du 11 mars 2026, décrivait sept composants, parmi lesquels des applications d’entreprise sur les trois frameworks, vérifiées par des développeurs, des charges de travail ciblées isolant des aspects tels que le comportement de la persistance et l’injection de dépendances, des applications complètes combinant plusieurs couches architecturales, une validation automatisée de la compilation et du démarrage, ainsi que des tests comportementaux vérifiant le comportement à l’exécution et l’équivalence fonctionnelle. Selon cette annonce, des développeurs expérimentés ont implémenté et validé manuellement chaque charge de travail afin d’en vérifier l’équivalence fonctionnelle et l’utilisation idiomatique des frameworks.
La collaboration entre IBM et Kaggle
Dans le cadre du partenariat, Kaggle a conseillé IBM sur la conception du benchmark et de l’évaluation, a reproduit et exécuté ScarfBench de manière indépendante sur sa propre plateforme en finançant les ressources de calcul, et assurera la maintenance du benchmark à long terme. IBM a présenté les atouts des deux équipes comme complémentaires : IBM a conçu ScarfBench autour de la modernisation des applications Java d’entreprise, tandis que Kaggle apporte une infrastructure d’évaluation indépendante et assure la maintenance continue du classement.
Résultats pour 204 tâches de migration
ScarfBench évalue un système agentique plutôt qu’un modèle de langage isolé : chaque résultat reflète les performances d’un modèle associé à un environnement d’agent de programmation, qui détermine la façon dont le modèle interagit avec le dépôt et l’environnement de développement. IBM a précisé que les scores devaient être interprétés comme des résultats combinant modèle et environnement d’agent, et non comme des mesures du modèle sous-jacent à lui seul.
Sur 204 tâches de migration et dix configurations modèle-environnement d’agent évaluées, Gemini 4 Argon associé à l’environnement d’agent Antigravity s’est classé premier selon la principale mesure fondée sur les tests de fumée, avec un score de 75,2 %, a indiqué IBM. Il était suivi de Claude Opus 5.5 associé à Claude Code, à 70,5 %, et de Claude Opus 5 associé à Claude Code, à 69,8 %. Le score des tests de fumée, qui sert de mesure pour le classement, accorde des points partiels et accorde davantage de poids aux suites de tests les plus importantes. Selon le critère plus strict exigeant la réussite de tous les tests, Claude Opus 5.5 associé à Claude Code a obtenu le meilleur taux, à 72,1 %, devançant de peu Gemini 4 Argon associé à Antigravity, à 71,1 %.
Selon la publication, le classement des meilleurs systèmes est resté le même dans le cadre d’une analyse de sensibilité. Quatre des 204 tâches n’ont obtenu aucun point aux tests comportementaux avec aucune des configurations ; leur exclusion a relevé les scores absolus sans modifier les leaders : Gemini 4 Argon associé à Antigravity a obtenu 79,4 %, suivi de Claude Opus 5.5 associé à Claude Code, à 74,5 %, et de Claude Opus 5 associé à Claude Code, à 73,7 %. IBM a fait remarquer que même la meilleure combinaison laissait une marge de progression importante : aucune configuration n’a réussi entièrement plus d’environ trois quarts des migrations.
Réussites et échecs selon les configurations
Selon IBM, l’écart le plus important de l’évaluation séparait le code qui se compile des logiciels qui se comportent correctement. Après exclusion des quatre tâches ayant obtenu zéro point, Claude Opus 5 associé à Claude Code, Gemini 4 Argon associé à Antigravity et Gemini 3.8 Flash associé à mini-swe se sont chacun compilés pour 100 % des tâches, et huit des dix configurations en ont compilé au moins 97 %. En revanche, les scores aux tests de fumée s’étendaient sur plus de 50 points. Parmi les applications déployées avec succès, les configurations en tête ont obtenu des taux de réussite complète aux tests d’environ 63 % à 76 %, tandis que Kimi K3 associé à kimi-code n’a atteint que 53 %, Gemini 3.1 Pro associé à OpenHands, 42 %, et Gemma 4 26B-A4B associé à mini-swe, 26 %.
IBM a classé 745 exécutions ayant échoué : 535, soit environ 72 %, correspondaient à des échecs comportementaux à l’exécution, dans lesquels l’application se compilait et démarrait souvent, mais échouait à la validation comportementale. Ce groupe comprenait 304 cas de contenu ou d’assertions non conformes, 210 échecs liés à des itinéraires perdus ou à des erreurs 404, et 21 erreurs HTTP 500 ou 405 explicites. Les échecs de compilation ou d’empaquetage représentaient environ 20 % des exécutions ayant échoué, soit 152 cas, et les plantages au démarrage ou liés à l’injection de dépendances, environ 8 %, soit 58 cas.
La publication recense des exemples au niveau des tâches. Pour concurrency-taskcreator-quarkus-to-jakarta, Claude Opus 5 associé à Claude Code a obtenu 0/6 après que le point de terminaison /taskinfo a renvoyé « File not found » et qu’un test attendant une réponse HTTP 405 a échoué. Pour address-book-jakarta-to-quarkus, GPT-6 Astra associé à Codex a obtenu 2/10 après que les pages de liste et de création ont renvoyé une erreur HTTP 404. Pour cargotracker-jakarta-to-spring, Gemini 3.8 Flash associé à mini-swe a conservé le câblage JSF/JoinFaces dans la cible Spring Boot et a échoué au démarrage lors de la création d’un bean facesContext. Pour cart-spring-to-jakarta, GPT-6 Astra associé à Codex a échoué au déploiement, car le type d’empaquetage défini lors de la migration n’était pas pris en charge par l’environnement d’exécution Liberty cible.
IBM a également indiqué que l’efficacité variait selon les configurations. Pour les 200 tâches restantes après l’exclusion liée à l’analyse de sensibilité, le nombre médian de tours allait de 32 avec Claude Opus 5 et Claude Code à 79 avec Gemini 3.8 Flash et mini-swe, tandis qu’il s’établissait à 64 avec Claude Opus 5.5 et Claude Code. Pour les environnements d’exécution qui communiquaient leurs coûts — ceux de Claude Code, Codex, mini-swe et kimi-code — le coût par tâche résolue allait de 1,25 $ avec GPT-6.1 Sol et Codex à 10,10 $ avec Claude Opus 5.5 et Claude Code ; les environnements Antigravity, qwen-code et OpenHands ne fournissaient pas de données sur le coût par exécution.
Le classement ScarfBench présente publiquement ces résultats. La soumission publique de modèles n’est pas disponible au lancement, mais IBM a indiqué qu’elle figurait sur la feuille de route.












