Lambert : interdire les poids ouverts reviendrait à interdire aussi les API des modèles de pointe

Nathan Lambert, auteur de la newsletter Interconnects, affirme que la discussion sur l'interdiction des modèles à poids ouverts repose sur une prémisse erronée. D'après son évaluation, la majorité des attaques documentées impliquant l'IA est, pour l'instant, passée par des modèles fermés. Son analyse part d'un rapport d'Anthropic consacré au modèle chinois GLM-5.3. Lambert juge que ce rapport contourne la question principale. Sa conclusion est tranchée : quiconque veut interdire les poids ouverts au nom de la sécurité doit être prêt à interdire aussi les API publiques des modèles de pointe.

Où l'argument en faveur de l'interdiction se brise

La logique habituelle des partisans des restrictions est simple. Les poids ouverts ne peuvent pas être rappelés, on peut les affiner et les débarrasser de leurs garde-fous, ils sont donc plus dangereux. Lambert objecte que le tableau empirique est différent : les incidents réels qu'il a été possible de documenter concernent plus souvent des systèmes fermés.

La raison, selon toute vraisemblance, est prosaïque. Un attaquant n'a pas besoin de son propre cluster si un modèle puissant se vend par API. L'accès fermé est moins cher, plus rapide et ne demande aucune compétence en ingénierie. Les filtres du fournisseur peuvent être contournés en ajustant les requêtes ou avec des comptes volés, et cela se produit déjà.

De là découle la symétrie sur laquelle repose toute la position de l'auteur. Si le critère d'interdiction est « le modèle peut aider à mener une attaque », il frappe aussi bien les poids que les API. Interdire l'un et laisser l'autre, c'est défendre non pas la sécurité, mais un modèle économique précis.

Ce qui cloche dans le rapport sur GLM-5.3

D'après la description de Lambert, le rapport d'Anthropic documente les capacités du modèle chinois, mais ne répond pas à la question clé : combien de risque ajoutent précisément les poids ouverts par rapport à ce que l'attaquant obtient de toute façon via les API fermées ? Sans cette base de référence, aucun chiffre sur des capacités « dangereuses » ne dit quoi que ce soit de l'utilité d'une interdiction. Un modèle peut écrire des exploits avec assurance, mais si les systèmes de pointe payants font la même chose, interdire les poids ne change rien.

Il y a aussi une question d'intérêts. Anthropic publie des modèles fermés, et l'argument contre les poids ouverts coïncide avec sa position commerciale. Cela ne signifie pas que les conclusions sont fausses. Mais c'est précisément pour cela que la méthodologie doit être transparente et la comparaison avec les équivalents fermés obligatoire.

Le facteur chinois

Le troisième volet de l'argument concerne les laboratoires chinois. Ils évaluent les risques à leur manière et décident de publier ou non leurs poids selon leur propre grille. Une interdiction aux États-Unis ou dans l'UE n'annulera pas les publications hors de ces juridictions. Des poids mis en ligne restent accessibles à tous, y compris à ceux que l'interdiction devait arrêter.

Les principaux points de l'analyse :

• la majorité des attaques documentées avec l'IA est pour l'instant passée par des modèles fermés ;
• le rapport d'Anthropic sur GLM-5.3 ne compare pas le risque des poids ouverts à celui des API fermées ;
• les laboratoires chinois appliquent leur propre grille d'évaluation des menaces ;
• une interdiction cohérente des poids ouverts devrait aussi s'étendre aux API publiques des modèles de pointe.

Ce que les équipes et les régulateurs doivent vérifier

Pour les régulateurs, la conclusion est pratique : tout rapport sur les cyberrisques d'un modèle gagne à être lu avec une question en tête, celle de la base de référence. Que pouvait faire l'attaquant sans ce modèle, et que fait-il avec ? Sans réponse, les conclusions ne peuvent pas servir de fondement à une loi.

Les entreprises qui construisent des produits sur des poids ouverts ont intérêt à prévoir une solution de repli. Le risque de restrictions existe, et la dépendance à un seul modèle, surtout d'origine chinoise, peut devenir un problème de conformité. Conserver des copies des poids et tester un remplaçant à l'avance coûte moins cher qu'une migration en urgence.

Les équipes de sécurité en tirent une leçon plus importante : il faut aussi surveiller les API fermées. Si les attaques réelles passent par elles, le contrôle des abus, la vérification des clients et l'analyse des requêtes anormales apportent davantage que la querelle sur les licences.