Un LLM chinois (grand modèle de langage) à poids ouverts, c’est un fichier de plusieurs dizaines de gigaoctets que vous téléchargez, que personne ne signe, et dont vous ne verrez jamais les données d’entraînement. Vous le posez sur vos serveurs. À partir de là, la question de ce qu’il contient devient la vôtre.
Ces modèles ne sont plus une curiosité militante. En mai 2026, ils représentaient environ 61 % des tokens (les unités de texte facturées par les modèles) consommés sur OpenRouter, et 41 % des téléchargements de modèles sur Hugging Face sur douze mois. Pour une grande partie des équipes techniques, ils sont devenus l’option installée par défaut.
Reste une question que l’écosystème français pose peu, alors qu’elle décide de tout : qu’accepte-t-on exactement en installant ces poids au cœur de son infrastructure ?
Les laboratoires chinois ouvrent leurs poids pour imposer un standard
Ouvrir des poids relève de la stratégie de distribution, pas de la générosité. Quand l’accès aux accélérateurs les plus puissants est contraint, l’avantage se déplace de la puissance de calcul vers l’adoption. Un modèle que tout le monde télécharge devient un standard de fait, qui finit par dicter les formats, les outils et les habitudes de toute une filière.
La licence fait le reste du travail. Quand un modèle sort sous MIT, l’objection juridique classique en entreprise tombe : plus de clause d’usage restrictive à faire arbitrer par le service juridique, plus de plafond d’utilisateurs, plus de restriction commerciale. Ajoutez un coût au token très inférieur à celui des offres fermées, et l’arbitrage se fait presque tout seul. La comparaison avec Meta mesure l’écart : la licence communautaire de Llama autorise l’usage commercial, mais impose de demander une autorisation à Meta au-delà de 700 millions d’utilisateurs actifs mensuels, et elle n’a jamais été reconnue comme une licence open source.
Cette génération se renouvelle vite : Kimi, GLM, DeepSeek et Qwen ont tous publié une version majeure au cours des derniers mois. Le classement change chaque trimestre. Les critères pour juger ce qu’on installe, eux, ne bougent pas.
Poids ouverts ne veut pas dire open source
C’est la confusion la plus coûteuse du moment. Des poids ouverts, ce sont des paramètres téléchargeables assortis d’une licence d’usage. Un projet open source, au sens où on l’entend pour du logiciel, supposerait aussi les données d’entraînement, le code du pipeline et la recette de post-entraînement.
Rien de tout cela n’est publié, ni chez les laboratoires chinois, ni chez la plupart des occidentaux qui diffusent des poids. La conséquence est directe : vous pouvez exécuter le modèle, vous ne pouvez pas vérifier ce qu’il a appris.
- Ce que vous gagnez : exécution hors ligne, aucune donnée qui sort de chez vous, fine-tuning et quantification possibles, indépendance vis-à-vis de la disponibilité d’une API.
- Ce que vous n’obtenez pas : la provenance des données, la reproductibilité de l’entraînement, une preuve d’intégrité de l’artefact, et le moindre recours si le comportement dérive.
S’ajoute un risque que beaucoup d’équipes découvrent tard : le format des fichiers. Les artefacts sérialisés au format Pickle exécutent du code au moment du chargement, ce qui ouvre la porte à une exécution de code arbitraire sur la machine qui déploie. F5 Labs le rappelait fin juillet 2026, à propos précisément des modèles chinois à poids ouverts : la chaîne d’approvisionnement d’un modèle est un vecteur d’attaque à part entière, exactement comme une dépendance logicielle.
Les parades sont connues et peu coûteuses : privilégier le format safetensors, télécharger depuis le dépôt officiel de l’éditeur plutôt qu’un miroir, vérifier les empreintes, charger dans un environnement isolé la première fois. C’est l’hygiène qu’on applique déjà à n’importe quelle dépendance tierce, rien de plus.
En France, l’API chinoise et l’auto-hébergement n’ont pas le même statut juridique
On confond en permanence deux situations qui n’ont pas le même profil de risque.
Premier cas : vous appelez une API hébergée en Chine. Vos prompts quittent l’Union européenne et tombent sous le droit local, notamment la Cybersecurity Law et la Data Security Law de 2021, qui organisent l’accès des autorités aux données détenues sur le territoire. Côté RGPD, il n’existe pas de décision d’adéquation pour la Chine. Le transfert doit donc être encadré et documenté, et son analyse d’impact doit trancher une question inconfortable : des garanties contractuelles tiennent-elles face à un droit d’accès étatique ?
Second cas : vous téléchargez les poids et vous exécutez l’inférence sur votre propre infrastructure, en France ou ailleurs dans l’Union. Là, aucune donnée ne part. Le sujet juridique se déplace vers la responsabilité que vous prenez en exploitant le modèle : le règlement européen sur l’IA fait peser des obligations sur celui qui met un système sur le marché sous son propre nom ou modifie substantiellement un modèle. Dans ce scénario, c’est vous.
Autrement dit, l’auto-hébergement ne supprime pas le risque : il le transforme. Vous échangez une question de juridiction contre une charge de sécurisation et de conformité que personne ne portera à votre place.
Les biais et la censure se mesurent, ils ne se supposent pas
Un modèle porte l’alignement de ceux qui l’ont entraîné. Les modèles chinois refusent ou reformulent certains sujets politiques, c’est documenté et facile à reproduire chez soi. Mais pour une entreprise, ce n’est presque jamais le sujet qui coûte : personne n’interroge un modèle de production sur l’histoire politique.
Ce qui compte, c’est de savoir où le modèle dévie sur vos propres domaines. Un glissement de cadrage sur une question industrielle, un refus inattendu sur un dossier réglementaire, une reformulation orientée dans une synthèse de veille : ces écarts-là passent inaperçus, et c’est pour ça qu’ils coûtent cher.
La méthode tient en quelques étapes, et elle vaut pour n’importe quel modèle.
- Constituer un jeu d’évaluation maison de cent à trois cents prompts couvrant vos cas d’usage réels et les sujets sensibles de votre secteur.
- Exécuter à paramètres fixes (température, seed, version du modèle) pour que les écarts observés viennent du modèle et pas du hasard d’échantillonnage.
- Comparer systématiquement à un modèle de référence déjà en production : ce qui vous informe, c’est l’écart, pas la note absolue.
- Mesurer trois choses : taux de refus, exactitude factuelle vérifiable, orientation du cadrage sur les sujets clivants.
- Rejouer ce jeu à chaque montée de version, y compris pour une version dite mineure.
Un point mérite d’être posé franchement : un test ne prouve jamais une absence. On peut établir qu’un modèle se comporte correctement sur trois cents cas, on ne peut pas démontrer qu’aucun comportement conditionnel ne dort dans les poids. C’est pour cela que la provenance de l’artefact et le niveau d’exposition du système comptent autant que le score de benchmark.
Dernière nuance, souvent oubliée : la censure du modèle et le filtre du service sont deux mécanismes distincts. Les mêmes poids exécutés chez vous et interrogés via l’API officielle de l’éditeur ne donnent pas toujours la même réponse. Si vous auto-hébergez, testez les poids que vous déployez, pas la vitrine.
Quand un modèle occidental reste le choix raisonnable
Rien de ce qui précède ne condamne les modèles chinois, et le raisonnement inverse serait tout aussi paresseux : les modèles occidentaux fermés ne sont pas auditables non plus. Ils viennent simplement avec autre chose : un contrat, un tribunal compétent, un interlocuteur à qui opposer une responsabilité quand ça dérape.
Un modèle chinois auto-hébergé est un excellent choix quand les charges sont massives et internes, quand le coût au token décide, quand l’environnement est isolé et que les sorties sont relues ou consommées par une chaîne technique. Il l’est beaucoup moins dans trois cas de figure.
- Vous devez expliquer à un client ou à un régulateur d’où vient un comportement du système, et le prouver.
- Le modèle est exposé directement à des utilisateurs finaux, sans filtre ni relecture, sur un sujet sensible.
- Vous n’avez pas l’équipe pour tenir un déploiement dans la durée : correctifs, rotation des versions, surveillance des sorties.
Le bon réflexe n’est pas de trancher par pays, mais par exposition. Plus le système touche directement des personnes ou des décisions engageantes, plus le niveau de preuve exigé du composant doit monter. Cette échelle ne dépend d’aucun drapeau.
À l’arrivée, vous n’avez pas à instruire un procès en confiance contre les laboratoires chinois. Vous avez à fixer le niveau de preuve que vous exigez d’un composant impossible à auditer, et la part de risque que vous acceptez de porter quand il tourne sur vos machines.
Écrivez cette grille de décision une fois, noir sur blanc. Elle resservira au modèle suivant, celui qui prendra la tête du classement le trimestre prochain, quel que soit le pays qui l’aura entraîné.
Questions frequentes
Un modèle à poids ouverts est-il open source ?
Non. Les poids ouverts donnent accès aux paramètres du modèle et à une licence d’usage, mais pas aux données ni au code d’entraînement. Sans ces éléments, le modèle n’est ni reproductible ni auditable au sens de l’open source.
Mes données partent-elles en Chine si j’utilise un LLM chinois ?
Uniquement si vous passez par une API hébergée en Chine, auquel cas les prompts tombent sous le droit local. Si vous téléchargez les poids et exécutez l’inférence sur votre propre infrastructure en Europe, aucune donnée n’est transmise à l’éditeur.
Quel est le principal risque technique au moment du téléchargement ?
Le format de sérialisation. Un fichier au format Pickle exécute du code au chargement, ce qui permet une exécution de code arbitraire sur la machine hôte. La parade consiste à privilégier le format safetensors, à télécharger depuis le dépôt officiel de l’éditeur et à vérifier les empreintes.
Comment vérifier concrètement les biais ou la censure d’un modèle ?
En construisant un jeu d’évaluation maison de cent à trois cents prompts couvrant vos cas d’usage et vos sujets sensibles, exécuté à paramètres fixes et comparé à un modèle de référence. Ce jeu doit être rejoué à chaque changement de version, y compris mineure.
Une licence MIT suffit-elle à lever le risque juridique ?
Non. Une licence permissive règle la question du droit d’usage et de redistribution, pas celle de la provenance des données d’entraînement. Elle ne dispense pas non plus des obligations qui incombent à celui qui met un système sur le marché sous son propre nom.
