Blog · Souveraineté & conformité IA · 11 juillet 2026

Modèles IA chinois en entreprise : le vrai coût, au-delà du prix au token

Qwen, DeepSeek, GLM et Kimi coûtent dix à vingt fois moins cher que les modèles fermés américains, pour une qualité annoncée comme comparable. Le cas Qwen à Bercy révèle un risque réel, mais propre à certains usages. Un second risque, plus large, touche n'importe quel modèle, quelle que soit sa nationalité.

Fin juin, la Direction générale du Trésor a débranché le modèle Qwen d'Alibaba de son outil interne HéphAIstos, testé par une centaine d'agents. Plusieurs hauts fonctionnaires avaient signalé des réponses orientées sur des sujets liés à la Chine. Parmi les exemples documentés : ce modèle qualifie Taïwan d'« élément inaliénable de la Chine » et refuse de commenter Tiananmen. Le lendemain de l'arrêt, Bercy est passé à un modèle Mistral (sources : Generation-NT, L'Usine Digitale).

L'épisode circule beaucoup, souvent lu comme une preuve qu'il faudrait s'interdire les modèles chinois par principe. Je ne partage pas cette lecture, pour deux raisons. La première : le biais politique illustré ici ne pèse que sur une partie des usages, ceux qui touchent à l'actualité internationale, à l'analyse géopolitique ou à des contenus de formation sur ces sujets. Pour la majorité des tâches d'entreprise, coder, résumer, extraire des données, répondre à un client, ce biais précis est sans effet, et l'écart de prix reste un avantage net. La seconde : il existe un risque plus large que celui-ci, qui touche tous les modèles sans exception, chinois ou américains, et dont on parle beaucoup moins.

Le prix imbattable, et pourquoi il progresse encore

Sur un scénario type de traitement de texte (1 million de tokens en entrée, 200 000 en sortie), l'écart est net :

Modèle	Coût du scénario
DeepSeek V4 Pro	0,61 $
Qwen3-Coder-480B	0,50 $
Mistral Large 3	0,80 $
Claude Opus 4.x	10,00 $
GPT-5.5	11,00 $

Mistral, l'alternative européenne la plus citée, se situe entre les deux : environ 30 % plus cher que DeepSeek V4 Pro sur ce scénario, mais dix fois moins cher que Claude Opus ou GPT-5.5. Ce surcoût modeste a un vrai argument pour qui préfère éviter tout le reste de cet article, biais, conformité, auto-hébergement, en choisissant directement un modèle européen.

Les fournisseurs chinois ajoutent un second levier : des rabais allant jusqu'à 99 % sur les tokens réutilisés (mémoire de conversation, documents consultés à plusieurs reprises), ce qui avantage structurellement les usages agentiques. La riposte américaine existe déjà : Anthropic a mis Claude Sonnet 5 à tarif promotionnel jusqu'au 31 août, un prix d'appel qui répond directement à cette pression.

Ce que Bercy a découvert avec Qwen

Le point technique le plus intéressant de l'incident n'est pas le biais lui-même, mais la façon dont Bercy en a parlé. L'administration a insisté sur l'étanchéité de l'outil, sans accès à internet ni porte dérobée. Cette précaution protège contre une fuite de données. Elle ne change rien à un biais installé dans les poids du modèle : un système parfaitement isolé du réseau peut très bien continuer à répondre selon un narratif d'État sur les sujets sensibles. Sécurité technique et neutralité du contenu sont deux problèmes distincts, et Bercy semble avoir traité le second comme s'il se réglait avec le premier.

Autre point factuel utile : aucune source ne mentionne de tentative de correction avant le retrait. Le modèle a été remplacé, pas audité ni corrigé. Des méthodes existent pourtant pour faire les deux, elles sont documentées plus bas.

Le risque de boîte noire touche tous les modèles

Aucun fournisseur, chinois ou américain, ne permet à ses clients d'inspecter complètement ce qui se passe à l'intérieur d'un modèle de langage. C'est un système entraîné sur des volumes de données que personne d'extérieur ne peut vérifier ligne par ligne, quelle que soit la nationalité de l'éditeur.

Le risque concret qui en découle porte un nom : le prompt injection, des instructions malveillantes ou cachées, glissées dans un document, une page web ou un email que le modèle va lire, qui détournent son comportement sans que l'utilisateur s'en rende compte. Ce risque est classé en tête du OWASP Top 10 for LLM Applications, la référence sur les risques de sécurité des applications qui utilisent des modèles de langage, et il concerne indifféremment un modèle fermé américain ou un modèle chinois ouvert.

Un paradoxe mérite d'être connu avant de trancher sur ce terrain : un modèle fermé, dont on ne consomme que l'accès via une API, est en réalité moins auditable de l'extérieur qu'un modèle publié en open weight, c'est à dire dont les paramètres (les poids) sont téléchargeables librement. Personne ne peut disséquer GPT ou Gemini pour vérifier ce qu'ils contiennent réellement. Le test d'Ellamind sur dix modèles, ou l'analyse technique indépendante qui a localisé, dans l'architecture de Qwen 3.5, les mécanismes précis qui déclenchent des refus sur certains sujets, n'ont été possibles que parce que ces modèles étaient ouverts. L'origine géographique d'un modèle ne dit rien à elle seule sur son niveau d'opacité réelle.

Pour un DSI, la bonne réponse à ce risque n'est pas de choisir le bon pays, elle est structurelle : ne jamais laisser un modèle exécuter une action conséquente à partir d'un contenu non vérifié (un document reçu, une page web), valider et filtrer ses sorties avant usage, et surveiller son comportement dans la durée plutôt que de le considérer validé une fois pour toutes. Un marché commence à se structurer autour de ce besoin : des plateformes comme Velatir ajoutent un point de validation humaine avant qu'un agent exécute une action sensible, d'autres comme Lakera, dont le filtrage des tentatives d'injection est une spécialité reconnue. Je pense que ce type de couche de supervision va devenir aussi indispensable que l'antivirus l'a été pour les postes de travail. Elle a aussi un bénéfice direct pour la conformité : les journaux d'approbation et de validation qu'elle génère sont exactement le type de preuve qu'un régulateur demande en cas de contrôle, quel que soit le modèle utilisé derrière.

Le biais n'est pas une fatalité chinoise

Un test mené par Ellamind sur dix modèles et 168 cas sensibles donne une image plus fine que « les modèles chinois sont biaisés ». Kimi K2.5 obtient 98,8 % de réponses factuelles, au niveau de Claude ou GPT. DeepSeek V3.2 tombe à 19 %, avec 81 % de réponses alignées sur le narratif officiel. Le même modèle, GLM 4.7 Flash, montre un écart de 15 points selon l'API qui le sert : la couche de service compte autant que les poids eux-mêmes.

Le NIST américain arrive à une conclusion cohérente sur DeepSeek en particulier : narratifs trompeurs quatre fois plus fréquents que les modèles de référence américains sur les sujets liés au Parti communiste chinois, et un taux de réponse aux tentatives de contournement bien plus élevé (94 % contre 8 % pour les modèles américains sur des requêtes ouvertement malveillantes). Mais ce constat vaut pour ce modèle précis, pas pour la catégorie entière. La bonne question n'est pas « chinois ou pas », elle est « ce modèle précis, sur mes usages précis ».

Détecter un biais avant qu'il vous coûte cher

Les méthodes existent et sont documentées :

Prompts sentinelles. Une liste standardisée de sujets sensibles (Taïwan, Tiananmen, Hong Kong, Xinjiang) testée systématiquement avant tout déploiement, exactement la méthode utilisée par Ellamind.

Analyse de sentiment ciblée. Soumettre des phrases identiques en ne changeant que le nom d'une personnalité politique, et comparer le ton attribué par le modèle.

Red teaming structuré. Tester volontairement le modèle avec des scénarios adverses pour révéler ses failles, selon une taxonomie de test plutôt qu'un essai informel (celle du NIST fait référence), avec une catégorie dédiée aux biais politiques.

Une analyse technique indépendante a récemment localisé, dans l'architecture de Qwen 3.5, les mécanismes précis qui déclenchent le refus systématique sur certains sujets (Tiananmen, Taïwan, Xinjiang, Tibet). Le résultat mérite d'être connu par tout DSI qui évalue ces modèles : le biais n'est pas diffus dans l'ensemble du modèle, il est localisable. Ce qui est localisable est corrigeable.

Corriger plutôt que bannir

Quand un biais est identifié sur un modèle qu'on veut garder pour son rapport prix/performance, plusieurs leviers existent, du plus léger au plus lourd :

1. Garde-fous dans le prompt système. Suffisant pour du comportement général, mais insuffisant pour les refus câblés dans l'architecture : l'analyse sur Qwen 3.5 montre qu'un simple prompt ne débloque pas la réponse sur Tiananmen.

2. RAG (retrieval-augmented generation) avec sources contrôlées. Forcer le modèle à s'appuyer sur une base documentaire choisie (textes officiels, rapports d'ONG) plutôt que sur sa mémoire d'entraînement, pour les sujets identifiés comme sensibles.

3. Classifieurs de sortie. Un filtre en aval qui détecte une réponse alignée sur un narratif d'État et la fait regénérer.

4. Fine-tuning ciblé (DPO, direct preference optimization, ou LoRA, low-rank adaptation). La méthode la plus robuste : ajouter une couche légère sur les poids existants pour corriger un comportement précis, sans réentraîner tout le modèle. C'est l'option la plus praticable pour une entreprise qui veut garder le modèle plutôt que le jeter.

À ma connaissance, aucune entreprise française n'a encore documenté publiquement ce pipeline complet en production sur un modèle chinois. Les cas disponibles sont des audits, pas des corrections déployées. À garder en tête avant de présenter cette voie comme déjà balisée.

S'approprier le modèle plutôt que dépendre de l'API

Utiliser un modèle open weight chinois ne signifie pas dépendre de l'API du fournisseur chinois. Les poids sont publics, et plusieurs clouds européens les hébergent déjà sur leur propre infrastructure. Scaleway propose Qwen3.6-35B et Qwen3-Coder-30B dans son catalogue, hébergés à Paris, en se positionnant explicitement comme fournisseur souverain. Outscale, filiale de Dassault Systèmes, mise sur la même logique de souveraineté mais avec un modèle occidental (Mistral) plutôt qu'un modèle chinois. Le tarif d'un déploiement dédié, public sur leur page tarifs, dépend du GPU choisi et du volume d'usage, à comparer au coût variable d'une API facturée au token.

L'intérêt principal n'est pas seulement financier : les requêtes ne transitent plus par une infrastructure chinoise, les données restent en Europe, et l'entreprise garde la main sur le modèle plutôt que sur un accès révocable à une API.

L'auto-hébergement ne vous met pas en conformité avec l'AI Act

C'est le point que la plupart des articles sur le sujet oublient de préciser, alors qu'il change directement ce qu'un DSI peut promettre à sa direction juridique. Le règlement européen sur l'IA distingue deux rôles : le fournisseur, qui développe le modèle et le met sur le marché, et le déployeur, qui se contente de l'utiliser, y compris en l'hébergeant lui-même. Les obligations de transparence pèsent sur le premier, pas sur le second, un peu comme un constructeur automobile doit publier les résultats de crash-test de son véhicule, pas le garage qui l'entretient ni l'automobiliste qui le conduit.

L'Article 53 de l'AI Act impose au fournisseur de publier un résumé des données d'entraînement de son modèle. Télécharger et héberger soi-même les poids d'un modèle chinois ne fait pas de l'entreprise le fournisseur au sens du règlement, elle reste déployeur. Et depuis le 1er juin 2026, un fournisseur chinois dispose d'une raison juridique supplémentaire de ne pas publier cette documentation : la Chine a réformé son droit du secret des affaires pour reconnaître explicitement les données d'entraînement et les algorithmes comme des actifs protégeables, ce qui renforce sa capacité à refuser de les divulguer si elles répondent aux critères de confidentialité et de valeur commerciale. Rien n'oblige ce fournisseur à publier le résumé attendu par l'Article 53, et s'il choisit de ne pas le faire, ce résumé n'existe simplement pas, où que le modèle tourne ensuite.

Concrètement, ça ne rend pas l'usage du modèle illégal en Europe. Le manquement expose surtout le fournisseur : l'AI Office, l'organe européen chargé de faire respecter ces règles pour les modèles GPAI, peut lui infliger une amende allant jusqu'à 3 % de son chiffre d'affaires mondial ou 15 millions d'euros, et exiger une mise en conformité. Tant qu'aucune décision de retrait n'est prononcée contre le modèle lui-même, une entreprise qui l'utilise en interne, sans le redistribuer ni construire de système à haut risque dessus, reste dans son bon droit. Le risque pour vous se loge ailleurs, dans le temps : si vous construisez quelque chose de plus ambitieux sur ce modèle plus tard, vous hériterez du même trou documentaire, sans personne à qui le reprocher.

Une exemption existe pour les modèles publiés en licence libre, mais elle ne couvre pas les modèles à risque systémique, et selon plusieurs analyses juridiques, elle ne dispense pas de l'obligation de résumé des données d'entraînement. Autre point de vigilance pour un DSI : rester simple utilisateur interne du modèle préserve le statut de déployeur. Redistribuer ce modèle dans un produit soulève un risque différent de celui qu'on imagine souvent : l'entreprise ne devient pas fournisseur du modèle chinois lui-même, elle devient fournisseur du système qu'elle construit autour, et seulement si ce système est classé à haut risque par le règlement. Dans ce cas, elle doit obtenir par contrat les informations nécessaires auprès du fabricant du modèle. Si celui-ci ne coopère pas, la mise sur le marché européen du produit peut se retrouver bloquée.

Souveraineté d'infrastructure et conformité documentaire sont deux sujets distincts. L'auto-hébergement règle le premier. Il laisse le second entier.

Ce qu'il faut retenir

Le prix des modèles chinois est un avantage compétitif réel, pas un piège à éviter par principe. La méthode que je recommande tient en quatre points : auditer le modèle précis sur les sujets sensibles propres à votre activité, plutôt que la catégorie entière. Traiter le risque de boîte noire, prompt injection compris, comme universel, quel que soit le fournisseur choisi. Corriger ce qui peut l'être par RAG, filtrage ou fine-tuning ciblé plutôt que jeter un modèle qui fonctionne bien sur le reste, et envisager l'auto-hébergement souverain si la localisation des flux de données compte pour vous. Et tenir ce choix de modèle comme un dossier vivant, pas une décision figée, dans le même esprit que la littérature IA continue exigée par l'Article 4 de l'AI Act : un modèle qui passait un audit hier n'est pas dispensé du suivant.

Sources : mistral.ai (tarifs Mistral Large 3), Generation-NT et L'Usine Digitale (incident HéphAIstos/Qwen à la Direction générale du Trésor), Ellamind (test de censure sur dix modèles), NIST/CAISI (évaluation des modèles DeepSeek), une analyse technique indépendante sur le routage interne de Qwen, Scaleway (offre de cloud souverain), artificialintelligenceact.eu (Article 53 du règlement européen sur l'IA), China IP Law Update (réforme du secret des affaires en Chine, entrée en vigueur le 1er juin 2026), OWASP Top 10 for LLM Applications (risque de prompt injection). Article rédigé le 11 juillet 2026, les informations citées sont celles connues à cette date.

Cet article présente une analyse à partir de sources publiques, à titre d'information générale. Il ne constitue pas un conseil juridique et n'engage pas la responsabilité de son autrice sur les décisions prises à partir de sa lecture. Toute question de conformité propre à votre organisation doit être validée avec vos propres conseils juridiques.