Contrastant avec les récents classements qui le plaçaient en tête de plusieurs benchmarks, le modèle GLM-5.2 de Z.ai obtient des résultats décevants dans un test indépendant mené sur des correctifs logiciels issus de deux dépôts open source réels. L'évaluation, réalisée avec l'outil Stet, a mesuré la capacité du modèle à reproduire cinquante demandes de fusion (pull requests) déjà intégrées dans les projets graphql-tools (Go) et sqlparser-rs (Rust), en comparant la qualité du code produit et la fidélité au comportement attendu.

Méthodologie et résultats

Chaque pull request a été rejouée sur un instantané figé du dépôt, avec une seule tentative par tâche, sans fuite d'information. Un juge aveugle basé sur GPT-5.4 a attribué deux scores : un indice de qualité artisanale (craft, de 0 à 4) et un indice d'équivalence (equivalence, de 0 à 1) mesurant la proximité avec le correctif humain original. GLM-5.2 a été exécuté en mode de raisonnement moyen (medium reasoning).

Sur les deux dépôts, le modèle se classe dernier parmi les cinq modèles testés sur les deux indicateurs. Pour graphql-tools (25 tâches), GLM-5.2 obtient un craft moyen de 2,38 et une équivalence de 0,47, contre respectivement 2,90 et 0,73 pour le meilleur modèle (Opus 4.8 en mode haut). Sur sqlparser-rs (25 tâches), le craft atteint 2,69 et l'équivalence 0,78, toujours en queue de peloton. Le modèle Composer 2.5, pourtant positionné sur un segment économique, obtient des notes systématiquement supérieures en équivalence sur les deux dépôts (0,60 sur Go, 0,95 sur Rust) malgré un craft très proche.

Coût et temps d'exécution

L'évaluation révèle également un désavantage économique. Le coût par tâche de GLM-5.2 s'élève à 1,40 dollar sur le dépôt Go et 1,04 dollar sur le dépôt Rust. Composer 2.5 est nettement moins cher (0,71 et 0,53 dollar respectivement), tandis que les modèles premium comme Opus 4.8 (3,98 et 3,02 dollars) ou GPT-5.5 (4,69 et 3,41 dollars) coûtent plus cher mais offrent une qualité bien supérieure.

Le temps d'exécution médian est également le plus long : environ 16 minutes par tâche pour GLM-5.2, soit le plus lent de l'échantillon. La tâche la plus coûteuse sur Go a consommé 14,1 millions de tokens et 4,07 dollars en une boucle de 326 tours, presque entièrement consacrée à la relecture des mêmes fichiers.

Comportement et taille des correctifs

La taille médiane des correctifs générés par GLM-5.2 se situe dans la moyenne du panel : il ajoute autant de lignes que les autres modèles, voire plus sur Rust (+284 lignes ajoutées, contre +175 pour Opus 4.8), et supprime peu de code, à l'instar des modèles Opus. L'étude conclut que ce n'est pas la taille du patch qui explique le déficit de qualité, mais bien le contenu lui-même, jugé moins fidèle au comportement du correctif humain.

Limites et recommandations

Les auteurs de l'évaluation, qui travaillent sur l'outil Stet, reconnaissent la marge d'erreur statistique liée à l'échantillon de cinquante tâches, mais estiment que l'écart est suffisamment marqué pour être significatif. Ils recommandent de réserver GLM-5.2 à un travail de première ébauche supervisé par un modèle plus intelligent, et déconseillent de l'utiliser sans surveillance sur des bases de code en production.

Ce nouveau test indépendant nuance fortement les performances affichées par GLM-5.2 dans d'autres classements récents où il figurait en tête, notamment dans des benchmarks de codage et d'agents. La différence pourrait provenir de la nature des tâches évaluées (correctifs réels vs. problèmes isolés) ou des réglages de raisonnement utilisés selon les tests.