Une requête envoyée à une IA peut contenir bien plus qu’une simple question : code source, identifiants, contrats, données de surveillance ou informations liées à un programme stratégique. En septembre 2026, la Chine a ouvert une enquête visant DeepSeek et Moonshot AI après des accusations de transfert de données utilisateur vers les modèles Claude d’Anthropic. Les autorités cherchent notamment à déterminer si des informations sensibles ont quitté les systèmes concernés.
Cette affaire rappelle une règle simple : une IA ne doit jamais devenir un canal de sortie incontrôlé pour les données de l’entreprise. Ce guide présente les risques concrets, les contrôles à mettre en place et une méthode opérationnelle pour utiliser les assistants génératifs sans exposer les informations les plus sensibles.
L’enquête chinoise vise un transfert potentiel de données vers Claude
L’enquête concerne DeepSeek et Moonshot AI, l’entreprise qui développe la famille de modèles Kimi. Selon plusieurs rapports publiés les 22 et 23 septembre 2026, l’autorité chinoise du cyberespace examine des accusations selon lesquelles des requêtes utilisateur auraient été acheminées vers les modèles Claude d’Anthropic sans information claire des clients.
Anthropic affirme avoir observé des opérations d’illicit distillation, une technique qui consiste à interroger un modèle concurrent puis à exploiter ses réponses pour améliorer un autre modèle. L’entreprise a déclaré que DeepSeek aurait généré plus de 12 millions d’échanges avec Claude sur une période de 14 jours en juillet 2026. Moonshot aurait, de son côté, fait parvenir près de 300 000 requêtes à Claude sur dix jours à l’aide de 5 380 comptes considérés comme frauduleux.
Ces chiffres correspondent aux accusations d’Anthropic. Ils ne constituent pas une décision établissant une violation. L’enquête chinoise porte précisément sur les circonstances du routage, la nature des informations transmises et l’éventuelle violation des règles chinoises sur la sécurité des données et les transferts transfrontaliers.
À retenir : une enquête sur un fournisseur d’IA ne prouve pas que chaque utilisateur a été exposé. Elle montre toutefois qu’un acheminement indirect vers un autre modèle peut devenir difficile à détecter sans journaux, restrictions réseau et politique claire de traitement des données.
Les rapports mentionnent des requêtes susceptibles d’avoir contenu des informations liées à une entreprise technologique chinoise, à un programme d’IA, à un système de police municipal ou à une agence gouvernementale russe. D’autres comptes rendus évoquent des données de surveillance, des systèmes internes et des identifiants.
Pour une entreprise, le risque ne dépend donc pas seulement du nom affiché dans l’interface. Un service présenté comme un assistant unique peut appeler une API tierce, utiliser plusieurs modèles ou transmettre une requête à un sous-traitant. La protection doit couvrir toute la chaîne technique.
Une requête d’IA peut divulguer quatre catégories de données
Le premier risque concerne les secrets d’affaires, c’est-à-dire les informations dont la divulgation peut donner un avantage à un concurrent. Il peut s’agir d’une feuille de route produit, d’un prix négocié, d’un algorithme, d’une stratégie commerciale ou d’un projet d’acquisition.
La deuxième catégorie regroupe les données personnelles. Un texte collé dans un assistant peut contenir un nom, une adresse électronique, un numéro de téléphone, un dossier médical, une conversation client ou un identifiant indirect. La pseudonymisation réduit le risque, mais elle ne le supprime pas si plusieurs éléments permettent de réidentifier une personne.
La troisième catégorie est technique : code source, clés API, journaux applicatifs, configurations cloud, certificats, adresses internes et messages d’erreur. Les assistants sont particulièrement pratiques pour corriger du code, mais un extrait apparemment court peut révéler l’architecture d’un système ou un secret réutilisé ailleurs.
La quatrième catégorie concerne les informations réglementées ou stratégiques. Elle inclut les données bancaires, les dossiers de santé, les informations classifiées, les données liées à la défense et les documents soumis à une obligation contractuelle de confidentialité.
Une règle de tri simple consiste à se poser trois questions avant chaque envoi :
- Le texte contient-il un identifiant, un secret ou une information permettant de reconnaître une personne ou une organisation ?
- Sa publication sur un serveur extérieur créerait-elle un problème juridique, commercial ou de sécurité ?
- Le même objectif peut-il être atteint avec un exemple fictif, des données synthétiques ou un extrait anonymisé ?
Si la réponse à l’une des deux premières questions est positive, la requête doit être bloquée ou transformée avant son envoi.
Les contrôles indispensables avant de déployer un assistant
La première mesure consiste à établir une classification des données, soit un classement qui associe chaque information à un niveau de sensibilité et à des règles de traitement. Une grille à quatre niveaux suffit souvent : public, interne, confidentiel et critique.
| Niveau | Exemples | Règle d’usage avec une IA externe |
|---|---|---|
| Public | Documentation publiée, communiqué, page web | Utilisation possible après validation du service |
| Interne | Procédure non publiée, compte rendu d’équipe | Utilisation limitée à un espace professionnel contrôlé |
| Confidentiel | Contrat, données client, code propriétaire | Anonymisation et validation préalable |
| Critique | Clé secrète, données de santé, information classifiée | Interdiction d’envoi à un service externe |
Cette classification doit être intégrée aux outils de travail, et pas seulement conservée dans un document de conformité. Un système de DLP, ou prévention contre la perte de données, peut repérer des adresses électroniques, des numéros de carte, des clés ou des motifs de secrets avant qu’une requête ne quitte le réseau.
Le deuxième contrôle porte sur les comptes. Les collaborateurs ne devraient pas utiliser une adresse personnelle pour transmettre des informations professionnelles à un assistant public. Les comptes d’entreprise permettent de centraliser l’authentification, de désactiver un accès lors du départ d’un salarié et d’appliquer des règles communes.
Le troisième contrôle concerne les droits. Un utilisateur qui peut interroger un modèle ne doit pas automatiquement pouvoir lui transmettre toutes les données accessibles depuis son poste. Le principe du moindre privilège limite chaque compte aux ressources nécessaires à sa mission.
Le quatrième contrôle porte sur les journaux. Il faut conserver les événements utiles : utilisateur, application, date, volume, destination, modèle appelé et résultat de la règle de filtrage. Le contenu intégral des requêtes ne doit pas être conservé sans justification, car les journaux peuvent eux-mêmes devenir une source de fuite.
La confidentialité d’un assistant ne se déduit pas de son interface
Une interface professionnelle peut donner une impression de sécurité sans fournir toutes les garanties nécessaires. L’organisation doit vérifier les conditions contractuelles du service, le traitement des requêtes, les sous-traitants, les régions d’hébergement, les délais de conservation et les mécanismes de suppression.
La question centrale est celle de la réutilisation des données. Certains services distinguent les espaces grand public, les offres professionnelles et les API. Ces environnements peuvent appliquer des règles différentes concernant l’entraînement des modèles, la conservation des journaux ou l’accès des équipes du fournisseur.
Un audit fournisseur doit examiner au minimum :
- Le service utilise-t-il les requêtes pour entraîner ou améliorer un modèle ?
- Les données sont-elles chiffrées pendant le transport et au repos ?
- Qui peut accéder aux requêtes et dans quelles circonstances ?
- Quels sous-traitants traitent les données ?
- Dans quels pays les données peuvent-elles être stockées ou traitées ?
- Quelle procédure permet d’effacer un compte, une conversation ou un fichier ?
- Le fournisseur publie-t-il des rapports d’incident et des informations de disponibilité ?
Le chiffrement protège les données contre certains accès non autorisés, mais il ne rend pas une requête invisible au fournisseur qui doit la traiter. Pour les informations les plus sensibles, l’option la plus sûre consiste à utiliser un modèle déployé dans un environnement contrôlé, avec des règles d’accès et une conservation maîtrisée.
Le déploiement interne ne supprime pas tous les risques. Le modèle, les dépendances, les serveurs, les journaux et les comptes d’administration doivent être maintenus. Une solution locale mal configurée peut être plus vulnérable qu’un service externe correctement administré.
Le cas du code impose des garde-fous spécifiques
Le code source ne doit pas être traité comme un simple texte. Il peut contenir des secrets, des noms d’hôtes, des chemins internes, des dépendances vulnérables et des hypothèses de sécurité invisibles dans une courte fonction.
Avant d’utiliser une IA pour corriger ou expliquer du code, il faut supprimer les clés, jetons, certificats et variables d’environnement. Les noms de domaines internes, les identifiants de clients et les noms de projets doivent être remplacés par des valeurs fictives. Le fragment transmis doit être réduit à la partie nécessaire pour reproduire le problème.
Une procédure sûre peut suivre ce schéma :
- Copier le code dans un environnement de travail séparé.
- Exécuter un détecteur de secrets avant tout envoi.
- Remplacer les valeurs réelles par des données synthétiques.
- Retirer les commentaires révélant l’architecture ou la logique métier.
- Envoyer le plus petit extrait permettant de comprendre le défaut.
- Vérifier la réponse dans un environnement de test avant toute mise en production.
- Contrôler les dépendances et les commandes proposées par le modèle.
Les suggestions générées par une IA doivent être considérées comme du code non vérifié. Elles peuvent introduire une dépendance malveillante, désactiver une vérification, exposer une erreur détaillée ou appliquer une configuration trop permissive.
L’équipe doit également interdire l’envoi direct de journaux de production. Même après suppression des noms, un journal peut révéler des identifiants persistants, des adresses IP, des paramètres de requête ou des fragments de données personnelles.
Les équipes doivent surveiller les flux, pas seulement les réponses
La surveillance ne doit pas se limiter au texte affiché dans l’application. Le point critique est le flux entre l’utilisateur, l’application d’IA, les connecteurs et les modèles appelés en arrière-plan.
Une architecture contrôlée sépare les fonctions : authentification, filtrage, routage, appel du modèle, stockage temporaire et journalisation. Chaque étape doit avoir une politique propre. Un connecteur qui permet à une IA de consulter une base documentaire doit, par exemple, appliquer les mêmes permissions que l’utilisateur humain.
Les contrôles réseau peuvent bloquer les destinations inconnues, limiter les appels aux domaines approuvés et empêcher l’utilisation d’API personnelles depuis les postes professionnels. Cette approche réduit le risque de contournement, notamment lorsque les salariés utilisent plusieurs assistants en parallèle.
Les alertes doivent viser des comportements mesurables :
- Hausse soudaine du volume de requêtes envoyées à un modèle externe.
- Transmission répétée de fichiers volumineux.
- Recherche de mots associés aux secrets, aux contrats ou aux données réglementées.
- Création de comptes multiples pour contourner une limite.
- Appels vers une destination non approuvée.
- Utilisation d’un assistant depuis un poste ou une localisation inhabituelle.
La détection doit rester proportionnée. Lire le contenu de toutes les conversations peut créer un nouveau problème de confidentialité. Une stratégie plus équilibrée combine analyse automatique des motifs sensibles, accès restreint aux alertes et conservation limitée des données nécessaires à l’enquête.
En cas d’incident, l’organisation doit pouvoir répondre à cinq questions : quelles données ont été envoyées, par qui, quand, vers quel service, et pendant combien de temps ? Sans ces éléments, l’évaluation de l’impact devient beaucoup plus incertaine.
Un plan de sécurisation en 30 jours
Une démarche progressive permet d’obtenir rapidement un niveau de contrôle acceptable sans attendre le déploiement d’une architecture complète.
Jours 1 à 7 : cartographier les usages
L’entreprise doit recenser les assistants utilisés, les extensions installées, les API appelées et les flux documentaires connectés. Cette étape inclut les outils officiellement approuvés et les usages non déclarés découverts dans les journaux réseau ou les postes de travail.
Le recensement doit identifier les données traitées, les équipes concernées, les modèles appelés et les pays susceptibles de recevoir les informations. Il faut ensuite classer les usages selon le risque, plutôt que de se concentrer uniquement sur la popularité d’un produit.
Jours 8 à 15 : bloquer les fuites évidentes
Les accès personnels doivent être séparés des usages professionnels. Les clés et mots de passe doivent être recherchés dans les dépôts de code et révoqués lorsqu’ils ont été transmis à un service externe. Les règles réseau peuvent limiter les destinations et les extensions non approuvées.
Une consigne courte doit être communiquée à toutes les équipes : aucune clé, donnée client, contrat confidentiel, dossier de santé ou information stratégique ne doit être copié dans un assistant externe.
Jours 16 à 23 : déployer les contrôles
L’organisation peut mettre en place une passerelle d’accès, une authentification centralisée, un filtrage DLP et une journalisation minimale. Les équipes techniques doivent tester les règles avec des données synthétiques afin d’éviter de provoquer une fuite pendant la phase de validation.
Les fournisseurs doivent être réévalués avec une grille commune. Un service dont les pratiques de conservation, les sous-traitants ou les flux transfrontaliers ne sont pas compatibles avec les exigences de l’entreprise doit être limité aux données publiques ou remplacé.
Jours 24 à 30 : tester la réponse
Un exercice interne doit simuler l’envoi accidentel d’un document confidentiel. L’objectif est de mesurer le temps nécessaire pour identifier la requête, bloquer le compte, révoquer les secrets, contacter le fournisseur et évaluer les obligations de notification.
Les résultats doivent déboucher sur des actions concrètes : correction d’une règle, réduction d’un droit, modification d’une procédure ou formation ciblée. Une politique qui n’est jamais testée risque de rester théorique.
Notre avis : interdiction ciblée, contrôle permanent
L’affaire DeepSeek et Moonshot ne justifie pas une interdiction indistincte de tous les assistants d’IA. Elle montre plutôt la nécessité de contrôler les destinations, les modèles appelés et les données transmises, y compris lorsque le routage est indirect.
Les informations critiques doivent rester hors des services externes tant que l’organisation ne maîtrise pas leur traitement. Pour les données internes et confidentielles, l’accès doit passer par un espace professionnel authentifié, filtré et journalisé. Les usages publics peuvent rester ouverts lorsqu’ils portent sur des informations déjà publiées ou des données synthétiques.
Dans les six prochains mois, les entreprises les mieux préparées seront celles qui sauront répondre précisément à une question simple : où va chaque requête après son envoi ? La réponse devra inclure le fournisseur initial, les éventuels sous-traitants, le modèle réellement appelé et la durée de conservation. À mesure que les modèles se multiplieront, la sécurité dépendra moins du nom affiché dans l’interface que de la visibilité sur toute la chaîne de traitement.