Qu'est-ce que GLM 5.2 ? Le codage à poids ouverts à 1/6 du prix

La version en une phrase

GLM 5.2 est le modèle de langage phare à poids ouverts de Z.ai, lancé le 13 juin 2026 et conçu spécifiquement pour le codage, le raisonnement et le travail « agentique » piloté par des outils — c'est-à-dire les tâches en plusieurs étapes où un modèle planifie, appelle des outils, lit les résultats et révise son travail au cours d'une longue session.

Z.ai est la marque internationale de Zhipu AI, une entreprise de recherche pékinoise issue du Knowledge Engineering Group de l'université Tsinghua en 2019. « À poids ouverts » est l'expression essentielle : les paramètres réels du modèle sont publiés sur Hugging Face (sous zai-org/GLM-5.2), ainsi que sur ModelScope et Ollama, sous licence MIT et sans restriction régionale. Vous pouvez l'héberger vous-même, l'affiner et l'intégrer à un produit commercial sans demander d'autorisation.

Pourquoi un modèle de codage à poids ouverts est plus important que les benchmarks

Avant le mécanisme, parlons de la motivation. Si cette sortie a attiré l'attention, ce n'est pas parce qu'il s'agit du modèle le plus intelligent au monde — ce n'est pas le cas. C'est parce qu'il a comblé l'essentiel de l'écart avec les modèles de pointe fermés tout en étant gratuit à télécharger et peu coûteux à appeler. Pour un développeur, cela change le calcul de deux décisions autrefois déjà tranchées.

La première concerne la dépendance à un fournisseur. Si votre agent de codage fonctionne via une API fermée, vous ne pouvez pas l'exécuter hors ligne, vous ne pouvez pas l'inspecter et votre tarif dépend de ce que le fournisseur décidera au prochain trimestre. Les poids ouverts suppriment ces trois contraintes d'un coup. La seconde concerne le coût. Le prix API indiqué pour GLM 5.2 est de 1,40 $ par million de tokens d'entrée et 4,40 $ par million de tokens de sortie, ce que Z.ai présente comme environ un sixième du coût de modèles de pointe comparables. Pour une charge de travail qui consomme beaucoup de tokens — et le codage agentique en consomme énormément — ce ratio résume tout.

Le piège, car il y en a toujours un : les poids ouverts peuvent être hébergés en toute sécurité par vos soins, mais faire transiter vos données par l'API cloud de Z.ai signifie qu'elles passent par une infrastructure soumise à la loi chinoise sur le renseignement national. Le département de la Sécurité intérieure des États-Unis a averti que ce cadre pourrait contraindre les entreprises chinoises à transmettre des données concernant des personnes américaines. Ces deux faits coexistent : des poids gratuits et inspectables que vous pouvez exécuter n'importe où, et une API hébergée qui soulève une véritable question de juridiction des données. La réponse dépend entièrement de votre choix : hébergement autonome ou appel au cloud. J'y reviendrai.

Comment ça fonctionne, sans simplifications abusives

GLM 5.2 est un modèle Mixture-of-Experts (MoE). Sa taille annoncée est d'environ 744 à 753 milliards de paramètres au total — les sources divergent légèrement, ce qui montre aussi que le chiffre précis n'est pas encore stabilisé — dont environ 40 milliards seulement sont actifs pour chaque token donné.

Cette répartition est l'astuce centrale, et mérite une analogie. Un modèle dense ressemble à un généraliste unique qui doit réfléchir à tout pour chaque question. Un modèle MoE ressemble davantage à une grande entreprise : il contient les connaissances d'une très vaste organisation, mais pour une tâche donnée, il ne réveille que les quelques spécialistes concernés. Vous obtenez la capacité d'un modèle de 744 milliards de paramètres pour un coût de service proche de celui d'un modèle de 40 milliards. Par rapport à son prédécesseur GLM 4.5 — 355B au total, 32B actifs — GLM 5 a agrandi l'entreprise (à 744B / 40B) et l'a entraînée sur davantage de données (28,5 billions de tokens, contre 23 billions auparavant).

Trois autres éléments comptent, chacun étant destiné à résoudre un problème précis plutôt qu'à étoffer artificiellement une liste de fonctionnalités.

Le premier est une conception à attention creuse que Z.ai appelle IndexShare. Le problème résolu est le suivant : le coût de l'attention augmente douloureusement lorsque la fenêtre de contexte s'allonge, et celle de GLM 5.2 est très longue (nous y reviendrons). Normalement, un modèle recalcule à chaque couche les tokens antérieurs auxquels il doit prêter attention. IndexShare calcule cet index une seule fois lors de la première de chaque groupe de quatre couches d'attention, puis le réutilise pour les trois suivantes. Z.ai indique que cela réduit de 75 % le coût d'indexation des produits scalaires dans ces couches réutilisées, et d'environ 2,9 fois le calcul par token à la longueur de contexte maximale d'un million de tokens. En termes simples : c'est ce qui rend abordable l'exécution réelle d'un contexte d'un million de tokens.

Le deuxième élément est les modes de raisonnement doubles — deux réglages sélectionnables de l'effort de réflexion appelés High et Max. Max est destiné au codage complexe en plusieurs étapes, lorsque le modèle a besoin d'espace pour planifier et réviser son travail ; il peut consommer près de 85 000 tokens de sortie pour une seule tâche. High ne perd que quelques points de performance tout en réduisant environ de moitié cette sortie de tokens : c'est le réglage à choisir lorsque la latence et le coût comptent davantage que le dernier point de pourcentage. À retenir en une phrase : Max lorsque la justesse est primordiale, High pour le travail quotidien.

Le troisième est la prédiction de plusieurs tokens, qui permet au modèle de prédire plusieurs tokens lors d'un seul passage avant, au lieu de les prédire un par un — ce qui accélère l'inférence et améliore accessoirement la cohérence à longue portée.

Ensemble, le point pratique essentiel est la fenêtre de contexte : jusqu'à 1 000 000 de tokens d'entrée (via l'identifiant glm-5.2[1m]), avec jusqu'à 131 072 tokens de sortie. C'est environ cinq fois la limite d'environ 200 000 tokens de GLM 5.1. Un million de tokens suffit pour conserver simultanément dans le contexte une base de code de taille moyenne — exactement le cas d'utilisation visé par toute cette conception.

Est-il vraiment performant ?

C'est ici que la hiérarchisation de la confiance est importante ; je vais donc distinguer clairement les faits des chiffres rapportés.

Le fait : Z.ai a lancé GLM 5.2 avec aucune suite de benchmarks officielle. Chaque chiffre qui circule provient soit du fournisseur, après coup, soit d'évaluations indépendantes initiales, dont aucune n'a encore été largement reproduite. Considérez les décimales précises comme des indications, pas comme une vérité absolue.

Avec cette réserve, les chiffres rapportés sont cohérents entre les sources et vont dans la même direction. Sur Terminal-Bench 2.1 (codage autonome depuis un terminal), GLM 5.2 obtiendrait 81,0 — une forte progression par rapport aux 62,0 de GLM 5.1, et à environ quatre points des 85,0 de Claude Opus 4.8. Sur SWE-bench Pro (résolution de problèmes réels de génie logiciel), il obtiendrait 62,1, devant GPT-5.5 à 58,6 et son propre prédécesseur à 58,4, mais derrière Claude Opus 4.8 à 69,2. Sur l'Intelligence Index d'Artificial Analysis, il aurait obtenu 51 — le score le plus élevé de tous les modèles à poids ouverts.

Ce qui donne davantage de poids à ces chiffres que le tableau habituel d'un fournisseur, c'est la confirmation indépendante, plus difficile à manipuler. Sur le Arena.ai's Code Arena — un classement Elo fondé sur des votes humains en duel à l'aveugle — GLM 5.2 serait arrivé deuxième au classement général. Et sur le Design Arena participatif, il aurait pris la première place avec un Elo de 1360, devant même Claude Fable 5. Les votes de préférence de personnes qui ignorent le modèle sont bien plus difficiles à manipuler qu'un taux de réussite autodéclaré ; ce sont donc ces deux résultats auxquels je ferais le plus confiance.

Mon analyse, formulée comme un jugement et non comme un fait : GLM 5.2 est actuellement le modèle de codage à poids ouverts le plus performant, il dépasse GPT-5.5 sur plusieurs tâches de codage et reste derrière Claude Opus 4.8 sur les tâches les plus difficiles et à long horizon, de un à environ treize points selon la tâche. Il est proche, mais pas devant — pour une fraction du prix.

GLM 5.2 contre Claude Opus 4.8 et GPT-5.5

Pour choisir entre les trois, les compromis sont assez clairs. Le tableau rassemble les scores rapportés des benchmarks de codage ainsi que les faits immuables (prix, contexte, licence) :

En résumé, honnêtement : Claude Opus 4.8 reste le plus performant des trois pour le codage agentique le plus difficile, et constitue le choix par défaut le plus sûr lorsque vous payez pour garantir la justesse lors de longues exécutions autonomes. GPT-5.5 se situe entre les deux sur ces benchmarks de codage précis. L'argument en faveur de GLM 5.2 n'est pas « c'est le meilleur », mais « il n'est qu'à quelques points du meilleur, il est ouvert et coûte une fraction du prix ». Si votre budget est limité, que vous voulez l'héberger vous-même ou l'affiner, l'argument est solide. Si vous exécutez des agents critiques à long horizon, pour lesquels quelques points de fiabilité supplémentaires justifient leur coût, Claude Opus 4.8 est le choix le plus prudent. Les tarifs de Claude sont publiés par Anthropic ; les chiffres de GLM correspondent aux tarifs rapportés par Z.ai's.

Si vous souhaitez tester les deux concurrents fermés avec vos propres prompts, vous pouvez tous deux les appeler via une seule API sur GPT Proto — Claude Opus 4.8 (thinking) et GPT-5.5 — au tarif fixe de 4 $ par million de tokens chacun. (Ce tarif fixe est celui de GPT Proto ; le partage entrée puis sortie de 5,00 $ / 25,00 $ indiqué dans le tableau correspond au prix catalogue d'Anthropic pour Opus 4.8 — le même modèle, deux structures tarifaires différentes.) Regrouper les trois familles derrière une seule clé est le moyen le moins cher d'effectuer vous-même la comparaison.

GLM 5.2 face aux modèles GLM utilisables aujourd'hui

GLM 5.2 est lui-même distribué avec des poids ouverts que vous téléchargez et hébergez — l'API hébergée de Z.ai est le seul moyen officiel de l'appeler, et, comme indiqué plus haut, cela soulève une question de juridiction des données. Mais la gamme GLM n'a pas commencé avec 5.2, et le passage des versions précédentes est le moyen le plus clair de voir ce qui a réellement changé.

La comparaison la plus utile est celle avec GLM 5.1, son prédécesseur direct. Deux différences ressortent. La fenêtre de contexte est passée d'environ 200 000 tokens à 1 000 000 — une multiplication par cinq qui constitue la principale amélioration. Et, en matière de codage, les progrès annoncés sont importants : Terminal-Bench 2.1 est passé de 62,0 à 81,0, et SWE-bench Pro de 58,4 à 62,1. Autrement dit, l'essentiel de la position de GLM 5.2 dans les classements provient de l'amélioration par rapport à sa propre version précédente, et non d'un simple ajustement.

Si vous préférez appeler aujourd'hui un GLM hébergé via une API compatible OpenAI unique plutôt que de déployer les poids ouverts, les modèles GLM actuellement proposés par GPT Proto sont ceux qui précèdent immédiatement 5.2 dans la lignée :

GLM-5.1 est ce qui se rapproche le plus de 5.2 parmi les modèles que vous pouvez appeler ici — même famille, une génération précédente, avec un contexte d'environ 200K plutôt que 1M. Pour beaucoup de tâches de codage, vous ne remarquerez pas la différence ; pour les tâches à l'échelle d'un dépôt qui nécessitent de garder toute la base de code dans le contexte, c'est précisément l'écart que 5.2 comble. Les tarifs complets par token de chaque modèle sont disponibles sur la page des modèles.

Utiliser GLM 5.2 dans Claude Code, avec un exemple exécutable

Un détail rend la gamme GLM particulièrement facile à intégrer aux workflows existants : GLM 5.2 expose un point de terminaison compatible avec Anthropic. Les outils conçus pour communiquer avec Claude — Claude Code, Cline, OpenCode — peuvent s'y connecter directement, en remplaçant le modèle situé derrière un agent de codage sans réécrire l'intégration. C'est pourquoi « GLM 5.2 dans le codage avec Claude » est un véritable cas d'usage et pas seulement une expression de recherche : le harnais de l'agent reste identique, seul le modèle sous-jacent change. (Pour 5.2 spécifiquement, cela signifie utiliser le point de terminaison de Z.ai ou un déploiement autonome, puisque les poids ouverts constituent la voie officielle.)

Si vous préférez ne pas gérer un déploiement, la solution pratique aujourd'hui consiste à appeler un GLM hébergé via l'API compatible OpenAI de GPT Proto. Voici un exemple avec GLM 5.1 — le modèle disponible le plus proche — qui constitue une bonne base avant de décider si le contexte supplémentaire de 5.2 justifie un hébergement autonome :

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_GPTPROTO_API_KEY",
    base_url="https://api.gptproto.com/v1",
)

resp = client.chat.completions.create(
    model="glm-5.1",
    messages=[
        {
            "role": "user",
            "content": (
                "Refactor this function for readability and explain the change:\n\n"
                "def f(x):\n"
                "    return [i for i in x if i % 2 == 0]"
            ),
        }
    ],
)

print(resp.choices[0].message.content)

La même requête avec cURL :

curl https://api.gptproto.com/v1/chat/completions \
  -H "Authorization: Bearer $GPTPROTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.1",
    "messages": [
      {"role": "user", "content": "Write a Python function that returns the nth Fibonacci number, iteratively."}
    ]
  }'

Remplacez glm-5.1 par glm-5 ou glm-5-turbo pour échanger de la qualité contre une réduction des coûts, ou par claude-opus-4-8-thinking / gpt-5.5 pour effectuer la comparaison exacte du tableau ci-dessus — le tout avec la même clé.

Vous aurez d'abord besoin de cette clé : créez-en une depuis le tableau de bord GPT Proto, insérez-la dans YOUR_GPTPROTO_API_KEY et l'appel ci-dessus fonctionnera tel quel. Les tarifs par token de chaque modèle se trouvent sur la page des modèles si vous souhaitez calculer le coût avant de vous engager.

Ses points forts et ses limites

Ses points forts sont concrets : c'est le meilleur modèle de codage à poids ouverts dans les classements existants, il est distribué sous une licence MIT véritablement permissive, son contexte d'un million de tokens est bien réel et abordable à exécuter grâce à IndexShare, et son rapport coût-performances est le meilleur de sa catégorie.

Ses faiblesses sont tout aussi concrètes et méritent d'être énoncées clairement plutôt que dissimulées. Il reste derrière Claude Opus 4.8 pour le codage le plus difficile à long horizon — l'écart est faible, mais constant. Z.ai n'a publié aucun benchmark officiel ; les chiffres doivent donc être pris avec une réserve jusqu'à leur reproduction par davantage de laboratoires indépendants. Enfin, la question de la juridiction des données de l'API cloud est bien réelle : si vos données ne peuvent légalement ou contractuellement franchir une frontière donnée, l'API hébergée de Z.ai est la mauvaise solution — hébergez plutôt vous-même les poids ouverts, ce qui constitue précisément l'intérêt de leur ouverture.

À qui s'adresse-t-il, et à qui ne s'adresse-t-il pas ?

Utilisez GLM 5.2 si vous êtes un développeur qui veut des capacités de codage proches des modèles de pointe sans leur tarif, si vous devez l'héberger ou l'affiner vous-même, ou si vous développez un produit agentique sensible aux coûts, où la consommation de tokens domine. Il convient particulièrement bien à ceux qui disposent déjà d'un harnais d'agent compatible avec Claude et souhaitent lui associer un moteur moins cher.

Choisissez plutôt Claude Opus 4.8 si vous exécutez des agents autonomes critiques à long horizon, pour lesquels les derniers points de fiabilité justifient le surcoût, ou si votre travail est soumis à des règles de résidence des données que l'API GLM hébergée ne peut pas respecter et que vous ne pouvez pas héberger vous-même.