ClovisLLM - GLM 5.2
ClovisLLM évoluera vers GLM 5.2, la nouvelle génération du modèle GLM le 30 juillet.
Cette version ne se contente pas d’améliorer légèrement les résultats sur des questions isolées. Elle cible un problème plus difficile : permettre à un modèle de rester efficace pendant une tâche longue, comportant de nombreuses étapes, plusieurs fichiers et des appels d’outils répétés.
Aucune modification des endpoints ou des formats de réponse de l’API Clovis n’est nécessaire.
Les chiffres à retenir
Les scores suivants comparent GLM 5.2 à GLM 5.1 dans les conditions publiées par Z.ai.
GLM 5.1
GLM 5.2
Terminal-Bench 2.1 — Exécution de tâches réelles dans un terminal
+17,5 pts
SWE-bench Pro — Résolution de problèmes dans de vrais dépôts logiciels
+3,7 pts
NL2Repo — Génération d’un dépôt à partir d’instructions
+6,2 pts
DeepSWE — Problèmes complexes de génie logiciel
+28,2 pts
ProgramBench — Développement et raisonnement sur du code
+12,8 pts
FrontierSWE — Tâches d’ingénierie longues et difficiles
+43,9 pts
PostTrainBench — Modification et entraînement de modèles
+14,2 pts
SWE-Marathon — Projets logiciels exécutés sur une longue durée
score ×13
MCP-Atlas — Utilisation d’outils et de serveurs MCP
+5 pts
Tool-Decathlon — Appels et orchestration d’outils
+7,5 pts
Ces résultats sont issus des évaluations publiées par l’éditeur du modèle. Ils doivent donc être considérés comme des indicateurs techniques, et non comme une garantie de résultat identique pour tous les cas d’usage.
Pourquoi certains gains sont beaucoup plus importants que d’autres
Sur SWE-bench Pro (Résolution de problèmes dans de vrais dépôts logiciels), le score passe de 58,4 à 62,1. Le gain est réel, mais relativement limité : +3,7 points.
La différence est beaucoup plus forte sur les benchmarks qui demandent au modèle de travailler longtemps :
- FrontierSWE : 30,5 → 74,4
- DeepSWE : 18.5 → 46,6
- SWE-Marathon : 1 → 13
- Terminal-Bench 2.1 : 63,5 → 81,0
Ce contraste est important. Il indique que GLM 5.2 n’est pas seulement meilleur pour produire une fonction ou corriger une erreur ponctuelle. Il progresse surtout lorsqu’il faut :
analyser un environnement existant
élaborer un plan
modifier plusieurs éléments
lancer des commandes ou des tests
lire les résultats
identifier ce qui ne fonctionne pas
modifier sa stratégie
poursuivre jusqu’à obtenir un résultat exploitable
C’est précisément le fonctionnement attendu d’un agent de développement ou d’un agent métier connecté à plusieurs outils.
Comparaison avec les autres modèles
Pour mettre ces résultats en perspective, le graphique ci-dessous compare GLM 5.2 à plusieurs modèles de référence sur des tâches de développement logiciel, d’utilisation d’outils et de raisonnement. Certains modèles propriétaires haut de gamme, comme Claude Opus, conservent une avance sur plusieurs benchmarks. GLM 5.2 se positionne néanmoins parmi leurs concurrents les plus sérieux et obtient des performances compétitives sur une grande diversité de tâches.
Cette comparaison montre surtout que GLM 5.2 n’est plus seulement une alternative intéressante parmi les modèles à poids ouverts : il est capable de rivaliser avec certains des meilleurs modèles propriétaires actuellement disponibles.
Son niveau de performance, son coût d’utilisation nettement plus faible, ainsi que son déploiement dans un environnement souverain français 🇫🇷 comme Clovis, en font une solution particulièrement compétitive pour les organisations recherchant à la fois puissance, maîtrise des données et indépendance technologique.
Une amélioration concrète du développement logiciel
Les progrès ne sont pas uniformes selon la nature de la tâche.
Sur SWE-bench Pro, le gain est de 3,7 points. Ce benchmark mesure la capacité à résoudre des tickets dans des dépôts logiciels réels. GLM 5.2 atteint 62,1, contre 58,4 pour GLM 5.1.
Sur NL2Repo, qui demande de produire un dépôt complet à partir d’une description, le modèle passe de 42,7 à 48,9.
Sur ProgramBench, il passe de 50,9 à 63,7.
Enfin, sur DeepSWE, le score progresse de 18 à 46,2. Cette hausse de 28,2 points suggère une nette amélioration sur les problèmes qui nécessitent davantage qu’une correction locale et imposent un raisonnement à l’échelle d’un système logiciel.
Pour un utilisateur, cela peut se traduire par une meilleure capacité à :
comprendre l’organisation d’un projet existant
appliquer une évolution sur plusieurs fichiers
respecter des contraintes d’architecture
vérifier son travail par des tests
corriger une première implémentation insuffisante
maintenir son objectif après de nombreux appels d’outils
Un résultat indépendant intéressant en cybersécurité
Les benchmarks publiés par l’éditeur ne constituent pas une validation indépendante. Un test mené par l’équipe de sécurité de Semgrep apporte toutefois un point de comparaison extérieur.
Sur une tâche de détection de vulnérabilités de type IDOR, GLM 5.2 a obtenu un score F1 de 39 % avec un harness minimaliste basé sur Pydantic AI.
Dans ce même test :
- Claude Code obtenait entre 28 % et 37 % selon la version utilisée ;
- MiniMax M3 obtenait 23 % ;
- Kimi K2.7 Code obtenait 22 % ;
- GPT-5.5 utilisé avec Codex obtenait 20 % ;
- la solution spécialisée de Semgrep atteignait entre 53 % et 61 %.
GLM 5.2 n’a donc pas dépassé le système spécialisé de Semgrep, mais il a obtenu le meilleur résultat parmi les modèles testés avec une orchestration légère.
Il s’agit néanmoins d’un seul benchmark, sur un type précis de vulnérabilité et avec un nombre limité d’exécutions. Ce résultat ne permet pas de conclure que GLM 5.2 est systématiquement meilleur que les autres modèles en cybersécurité.
Ce que GLM 5.2 ne résout pas
Le modèle reste susceptible de produire des informations incorrectes, d’appeler un mauvais outil ou de persévérer dans une stratégie inefficace.
GLM 5.2 doit donc toujours être utilisé avec :
- des permissions limitées ;
- une validation des commandes sensibles ;
- une journalisation des appels d’outils ;
- des limites de durée et de consommation ;
- une vérification humaine pour les opérations critiques.