Le GLM-5.2 à poids ouverts de Z.ai se rapproche des performances des principaux modèles de pointe en cybersécurité et en capacités biologiques, selon une nouvelle évaluation de SaferAI, une organisation à but non lucratif spécialisée dans la sécurité de l’IA. Le rapport souligne aussi une faiblesse nette : le modèle a montré peu des comportements de refus et des garde-fous de mise à disposition qui limitent l’usage des modèles fermés.

Les résultats de SaferAI précisent un débat qui dépasse désormais la question de savoir si les systèmes à poids ouverts peuvent rivaliser avec les modèles d’OpenAI et d’Anthropic. La question plus difficile est de savoir si les développeurs, les régulateurs et les acheteurs d’entreprise peuvent gérer les risques de modèles très capables une fois que leurs poids sont disponibles au téléchargement, à la modification et à l’exécution en dehors de l’infrastructure d’un fournisseur.

GLM-5.2 réduit l’écart de capacité

SaferAI a indiqué que GLM-5.2 n’était qu’à quelques mois de GPT-5.5 d’OpenAI et de Claude Opus 4.7 d’Anthropic sur les tâches de cyber et de biologie incluses dans son évaluation. C’est un résultat significatif pour un modèle à poids ouverts provenant d’un développeur chinois, même si les éléments de preuve viennent de l’évaluation d’une seule organisation à but non lucratif et non d’un vaste programme de benchmarks répliqué de manière indépendante.

L’organisation à but non lucratif a mené ses tests via l’API publique de Z.ai. Ce détail compte, car un modèle accessible par API peut ne pas se comporter exactement comme des poids téléchargeables déployés sur le matériel propre d’un client. Cela signifie aussi que l’évaluation ne permet pas, à elle seule, d’établir comment le modèle se comporterait après un fine-tuning, des changements de prompts système ou la suppression des contrôles côté fournisseur.

Malgré tout, les résultats soutiennent une tendance plus large du marché : les systèmes à poids ouverts deviennent des alternatives crédibles pour les équipes qui ont besoin de personnalisation, de déploiement local ou d’un meilleur contrôle des données et de l’infrastructure. L’écart de capacité entre les modèles disponibles publiquement et les offres de pointe devient moins निर्णant pour certaines charges de travail techniques.

L’écart de sécurité est plus important que le score

SaferAI a indiqué que GLM-5.2 n’a refusé aucune des demandes offensives de cybersécurité ou de biologie à double usage reçues pendant les tests. À l’inverse, l’organisation a indiqué que Claude Opus 4.7 refusait de manière si constante qu’elle n’a pas pu terminer le benchmark de cybersécurité CyberGym sur ce modèle.

Ces résultats doivent être lus comme une comparaison des comportements observés dans les conditions de test, et non comme un classement complet de sécurité. Les taux de refus peuvent varier selon les prompts, les versions de modèle, les instructions système et la conception de l’évaluation. Ils illustrent néanmoins la distinction centrale de cette histoire : capacité et réduction du risque sont deux dimensions distinctes.

Henry Papadatos, directeur exécutif de SaferAI, a déclaré à TechCrunch que le système le plus capable n’est pas automatiquement le plus risqué ni le plus sûr ; les mesures d’atténuation autour de lui doivent aussi être prises en compte. Pour un modèle fermé, les fournisseurs peuvent déployer des classificateurs, un entraînement au refus, de la surveillance et des restrictions d’API. Ces contrôles sont imparfaits, mais ils donnent au fournisseur une certaine capacité continue à modifier la manière dont le système répond.

Ce levier disparaît en grande partie lorsque les poids sont publiés. Les utilisateurs peuvent exécuter un modèle à poids ouverts sans l’API du fournisseur d’origine, modifier son prompt système, le fine-tuner pour un objectif plus étroit ou supprimer entièrement les garde-fous. Il en résulte un problème de gouvernance qui ne peut pas être traité uniquement par des conditions d’utilisation ou une modération après la publication.

Ce que SaferAI dit manquer

SaferAI a indiqué que Z.ai n’avait pas publié de cadre de sécurité, d’engagements de tests avant déploiement ni d’évaluation des risques pour GLM-5.2. TechCrunch a indiqué avoir demandé à Z.ai si l’entreprise avait effectué des évaluations internes ou par des tiers de la sécurité de pointe avant la sortie, sans avoir reçu de réponse.

L’absence de documentation publique ne prouve pas qu’aucun test interne n’a eu lieu. Elle rend toutefois plus difficile pour les clients, les chercheurs et les décideurs publics de comprendre quels risques ont été évalués, quelles mesures d’atténuation ont été envisagées et quels seuils de mise à disposition l’entreprise a utilisés.

Le problème ne se limite pas aux développeurs chinois. Les fournisseurs de pointe font eux aussi face à des jailbreaks récurrents et à d’autres défaillances de leurs défenses. Far.ai a signalé des techniques de jailbreak réutilisables contre des modèles comme Grok 4.5 de xAI et Gemini 3.1 Pro de Google DeepMind. Les fournisseurs fermés peuvent corriger ces faiblesses de manière centralisée ; les distributeurs de poids ouverts ne peuvent généralement pas empêcher les utilisateurs en aval de les restaurer ou de les amplifier.

Papadatos, de SaferAI, a cité le filtrage des données de préentraînement comme une mesure possible. Supprimer des données offensives de cybersécurité ou biologiques des données d’entraînement peut réduire certaines connaissances dangereuses, et les recherches citées par le rapport suggèrent que les risques biologiques peuvent parfois être réduits sans perte majeure de performance générale. La cybersécurité est plus difficile, car les compétences de codage qui rendent les modèles utiles aux développeurs se recoupent aussi avec des compétences utiles pour trouver et exploiter des vulnérabilités.

Implications pour les créateurs et les acheteurs d’entreprise

Pour les créateurs d’IA, GLM-5.2 crée un compromis pratique plutôt qu’une simple victoire dans le choix d’un modèle. Des poids locaux peuvent soutenir un déploiement privé, réduire la dépendance à une API externe et permettre une personnalisation pour le travail de sécurité défensive. Mais les équipes qui déploient le modèle hériteraient de la responsabilité des contrôles d’accès, de la journalisation, de la surveillance, des tests d’abus et de la réponse aux incidents.

Les entreprises devraient donc évaluer les modèles à poids ouverts selon deux axes séparés. Le premier est la performance sur la tâche : qualité de code, analyse de vulnérabilités, aide à la recherche biologique, latence et exigences d’infrastructure. Le second est la sécurité opérationnelle : le modèle refuse-t-il les requêtes dangereuses, à quel point ces refus peuvent-ils être contournés, et l’organisation peut-elle détecter les abus après le déploiement ?

Cette distinction est particulièrement importante pour les équipes de cybersécurité. Un modèle qui aide à identifier des faiblesses dans des systèmes internes peut aussi être capable de générer des conseils offensifs. Les organisations qui envisagent GLM-5.2 ou des systèmes comparables devront mettre en place des autorisations limitées, une exécution en sandbox, une revue humaine et des frontières claires entre l’analyse défensive et les actions contre des systèmes de tiers.

La sortie intensifie aussi la concurrence entre les stratégies à poids ouverts et les stratégies à modèle fermé. Les partisans des poids ouverts, dont Clem Delangue, PDG de Hugging Face, soutiennent que l’accès à des modèles capables peut aider les défenseurs à se préparer aux attaques et à identifier les vulnérabilités avant que les criminels ne les exploitent. Papadatos rétorque que la valeur défensive ne justifie pas automatiquement la mise à disposition de capacités dangereuses sans garde-fous plus solides.

Ce qu’il faut surveiller ensuite

Le premier signal sera de savoir si Z.ai publie un cadre de sécurité, une évaluation des risques ou des détails sur les tests préalables à la sortie pour GLM-5.2. Une reproduction indépendante des résultats cyber et bio de SaferAI sera également importante, en particulier des évaluations comparant le comportement de l’API hébergée avec le modèle téléchargeable.

Les chercheurs et les acheteurs devraient surveiller la facilité avec laquelle les garde-fous de GLM-5.2 peuvent être modifiés ou supprimés, ses performances après fine-tuning, et la possibilité que de nouvelles méthodes de mise à disposition préservent des capacités utiles de codage et de recherche tout en limitant l’assistance offensive.

Les régulateurs seront eux aussi confrontés à une question de politique publique concrète : les obligations doivent-elles s’appliquer aux fournisseurs de modèles au moment de la mise à disposition, aux entreprises qui distribuent les poids, ou aux organisations qui les déploient dans des flux de travail à haut risque ? Les règles existantes, centrées sur la modération des contenus, peuvent ne pas répondre aux risques créés par une exécution locale sans restriction.

Perspective Creati.ai

L’importance de GLM-5.2 ne tient pas seulement au fait qu’un modèle à poids ouverts se rapproche davantage des systèmes de pointe. Elle tient au fait que les progrès en capacité font de l’architecture de sécurité un sujet central de produit et d’achat. La position d’un modèle dans les benchmarks indique aux créateurs ce qu’il peut faire ; ses contrôles de mise à disposition déterminent le niveau de confiance qu’ils peuvent accorder à son déploiement.

La meilleure prochaine étape n’est pas de considérer les poids ouverts comme intrinsèquement dangereux ou les API fermées comme intrinsèquement sûres. C’est d’exiger des preuves comparables pour les deux : évaluations transparentes, mesures d’atténuation documentées, tests d’abus réalistes et responsabilité claire après le déploiement. Tant que ces preuves ne deviendront pas routinières, la course aux capacités continuera d’avancer plus vite que l’argument de sécurité censé la soutenir.