DeepSeek en local résout-il le problème des données en Chine ? 2026

DeepSeek existe comme deux choses séparables : un service hébergé (application, web, API) exploité depuis la Chine, et un ensemble de modèles à poids ouverts que vous pouvez télécharger et exécuter partout. Presque tout débat sur « la confidentialité de DeepSeek » confond ces deux choses, d'où des réponses brouillées. Gardez-les distinctes et l'image devient claire.

C'est dans le service hébergé que réside la préoccupation. Lorsque vous saisissez du texte dans l'application DeepSeek ou appelez son API, votre saisie voyage jusqu'aux serveurs de DeepSeek, et la politique de confidentialité de l'entreprise indique que les données sont stockées en République populaire de Chine. C'est un flux de données transfrontalier aux conséquences réglementaires réelles dans l'UE.

Les poids ouverts sont un objet entièrement différent. Les distillations DeepSeek-R1 sont des fichiers que vous téléchargez depuis un registre de modèles et exécutez avec Ollama ou LM Studio sur votre propre matériel. Ils ne contiennent aucun code réseau ni télémétrie — les exécuter n'envoie rien à DeepSeek. La question de confidentialité pour les poids n'est pas « où vont mes données » (nulle part) mais une question distincte sur le comportement du modèle, traitée plus bas.

Le service DeepSeek hébergé stocke les données des utilisateurs en Chine et les collecte directement, ce que les régulateurs européens ont traité comme une grave préoccupation transfrontalière de protection des données. C'est documenté dans la propre politique de confidentialité de DeepSeek et reflété par une action réglementaire concrète — ce n'est pas de la spéculation.

Les faits, énoncés de façon neutre :

Lorsque vous auto-hébergez un modèle DeepSeek à poids ouverts, aucun serveur DeepSeek n'intervient, donc il n'y a aucun flux de données transfrontalier vers la Chine — vos invites et vos sorties ne quittent jamais votre machine. C'est le seul changement qui résout le problème de protection des données : vous avez supprimé le service qui stockait les données à l'étranger.

Vous n'avez pas à le croire sur parole. Comme les modèles ne contiennent aucune télémétrie, vous pouvez vérifier directement l'absence de sortie : exécutez le modèle avec votre réseau surveillé et confirmez qu'il n'y a aucune connexion sortante pendant l'inférence. Une simple règle de pare-feu ou une capture de paquets pendant une session suffit à le démontrer.

Pour la configuration pratique, entièrement hors ligne — y compris comment vérifier le « vraiment hors ligne » par surveillance du trafic — voir Exécuter DeepSeek hors ligne 2026 : configuration auto-hébergée. Pour choisir la distillation à exécuter, voir Meilleur modèle de raisonnement local 2026.

L'auto-hébergement résout le problème de flux de données mais pas toutes les préoccupations : certains chercheurs en sécurité signalent des problèmes au niveau des poids du modèle — vulnérabilité aux jailbreaks et alignement narratif des sorties — qui existent quel que soit l'endroit où le modèle s'exécute. Il importe de le dire clairement et de présenter les deux côtés plutôt que de laisser entendre que local équivaut à sans risque.

La préoccupation, énoncée équitablement : des chercheurs ont rapporté que les modèles DeepSeek peuvent être relativement vulnérables aux jailbreaks, et que sur certains sujets politiquement sensibles les sorties reflètent un alignement narratif particulier. Ce sont des propriétés des poids eux-mêmes, donc l'exécution locale ne les change pas.

Le contre-argument, énoncé tout aussi équitablement : tout modèle ouvert comporte une certaine surface de jailbreak, et l'alignement narratif existe dans les modèles de tout pays d'origine, façonné par les données d'entraînement et les choix de réglage. Pour les mathématiques, la logique, le codage et la plupart des raisonnements métier — les tâches pour lesquelles les gens auto-hébergent réellement les distillations R1 — ces préoccupations sont largement orthogonales au travail.

L'enseignement pratique est de séparer les deux questions. « Mes données fuient-elles ? » est tranchée (non, en auto-hébergement vérifié). « Est-ce que je fais confiance aux sorties de ce modèle sur les sujets sensibles ? » est une question de choix de modèle à trancher au mérite, comme pour tout modèle. Pour un regard ciblé sur la question de conformité, voir DeepSeek est-il conforme au RGPD ?.

Au titre du RGPD, le service DeepSeek hébergé soulève un problème de transfert transfrontalier ; un déploiement auto-hébergé sur une infrastructure de l'UE le contourne largement car aucune donnée personnelle n'est transférée hors de votre contrôle. La loi chinoise sur la sécurité des données (DSL) et la loi sur la protection des informations personnelles (PIPL) régissent le côté du service hébergé ; le RGPD régit le vôtre.

Le mécanisme compte. Le RGPD restreint les transferts de données personnelles de l'UE vers des pays tiers sans garanties adéquates. Envoyer des invites à une API hébergée en Chine est un tel transfert ; exécuter les poids ouverts sur un serveur que vous contrôlez dans l'UE n'est pas un transfert du tout — les données ne quittent jamais votre environnement de traitement.

C'est pourquoi « utiliser les poids ouverts, pas l'API hébergée » est la réponse standard d'ingénierie de la confidentialité pour les équipes de l'UE. Elle convertit une difficile question de conformité au transfert transfrontalier en une question ordinaire de traitement de données sur site que vous savez déjà satisfaire.

Un déploiement DeepSeek propre du point de vue de la confidentialité tient en trois décisions : choisir une distillation à poids ouverts, l'exécuter sur du matériel que vous contrôlez et vérifier l'absence de sortie. Rien de tout cela ne touche au service hébergé.

Auto-hébergez lorsque vous voulez le raisonnement de DeepSeek sans le chemin de données du service hébergé ; n'évitez entièrement DeepSeek que si les préoccupations sur les poids du modèle l'emportent sur ses forces pour votre travail spécifique.