DeepSeek : plus d’un million de journaux, conversations et clés API exposés

Une conversation avec un assistant d’intelligence artificielle peut contenir bien davantage qu’une simple question technique : extraits de documents professionnels, idées de produits, informations personnelles, morceaux de code ou identifiants. C’est pourquoi la découverte, fin janvier 2025, d’une base de données DeepSeek accessible depuis Internet sans authentification est particulièrement préoccupante. Selon les chercheurs de Wiz, l’instance exposée contenait plus d’un million de journaux non chiffrés, parmi lesquels figuraient des historiques de conversations et des clés API.

DeepSeek, entreprise chinoise d’IA connue pour ses modèles conversationnels, a rapidement gagné en visibilité auprès du grand public et des développeurs. Mais cet épisode rappelle une réalité parfois oubliée : un modèle performant ne protège pas, à lui seul, les données qui transitent par les services qui l’entourent. La sécurité dépend aussi des bases de données, des interfaces de programmation, des réglages cloud et des procédures de contrôle.

Ce que les chercheurs de Wiz ont découvert

La société de cybersécurité Wiz a identifié une base de données interne de DeepSeek qui pouvait être consultée publiquement, sans mot de passe ni autre mécanisme d’authentification. Les chercheurs ont alors alerté DeepSeek. D’après leur compte rendu, l’entreprise a retiré l’accès public à la base peu après ce signalement.

L’exposition concernait une instance de ClickHouse, un système de gestion de base de données fréquemment utilisé pour analyser rapidement de grands volumes de données. L’outil n’est pas, en lui-même, un problème de sécurité. Le risque apparaît lorsqu’une instance est reliée à Internet sans contrôle d’accès adapté, ou lorsque ses interfaces d’administration et de requête restent ouvertes par erreur.

Les journaux de discussion consultés par les chercheurs étaient principalement rédigés en chinois. Cette barrière linguistique n’aurait toutefois qu’une portée limitée : les outils de traduction permettent aujourd’hui de comprendre rapidement une grande partie d’un échange dans une autre langue. Le caractère potentiellement sensible d’un historique ne dépend donc pas de la langue employée.

Quelles données étaient accessibles ?

Le volume annoncé, plus d’un million de journaux, ne signifie pas nécessairement un million d’utilisateurs ni un million de conversations distinctes. Un journal informatique est un enregistrement technique : il peut correspondre à un message, une requête, une opération système, un appel à une API ou une étape de traitement. Son intérêt pour un attaquant dépend donc autant de son contenu que de son nombre.

Dans cette affaire, trois catégories d’informations concentrent les principales inquiétudes.

Une clé API fonctionne comme un badge numérique. Elle permet à une application de prouver son identité auprès d’un service afin d’envoyer des requêtes ou d’accéder à certaines fonctions. Lorsqu’elle est exposée, la bonne pratique consiste généralement à la révoquer puis à en créer une nouvelle. Sa seule présence dans une base ouverte ne permet pas de savoir immédiatement quels droits elle donne, mais elle ne doit jamais être considérée comme une information anodine.

Les historiques de conversations posent une question différente. Les assistants IA sont utilisés aussi bien pour reformuler un courrier que pour résumer une réunion, déboguer du code ou préparer un document. L’utilisateur peut parfois y coller un contenu qu’il ne publierait jamais volontairement. Cela rend la protection des traces de conversation particulièrement importante, y compris lorsqu’elles sont conservées à des fins techniques ou d’amélioration du service.

Une exposition ne prouve pas une extraction de données

Le terme de « fuite » est couramment employé dès lors que des données deviennent visibles depuis Internet. Il faut néanmoins distinguer plusieurs niveaux de certitude. Dans le cas rapporté par Wiz, l’accès public à la base est établi. En revanche, rien dans les éléments disponibles au 30 janvier 2025 ne permet d’affirmer qu’un tiers malveillant a effectivement téléchargé ou exploité les données avant que l’accès soit fermé.

Cette nuance est essentielle. Une porte laissée ouverte ne prouve pas qu’une personne est entrée, mais elle crée un risque réel et justifie une enquête. Pour évaluer l’ampleur d’un incident, une entreprise doit notamment pouvoir déterminer depuis quand l’accès était ouvert, examiner les journaux de connexion et identifier d’éventuels téléchargements inhabituels. Or la durée exacte de l’exposition de la base DeepSeek n’était pas connue au moment de la publication.

L’incertitude ne réduit pas la gravité potentielle du problème. Des conversations ou des clés API accessibles sans protection peuvent suffire à provoquer des dommages, même si l’exposition est brève. Dans le secteur de l’IA, où la confiance repose sur la capacité des plateformes à traiter des requêtes parfois sensibles, la transparence sur le périmètre d’un incident compte autant que sa correction technique.

Pourquoi une erreur de configuration peut suffire

Les fuites de données ne résultent pas toutes d’un piratage sophistiqué. Une mauvaise configuration peut suffire : un service de base de données laissé ouvert sur Internet, une règle réseau trop permissive, un compte administrateur mal protégé ou une interface de gestion rendue accessible par inadvertance. Ces erreurs peuvent intervenir lors d’un déploiement rapide, d’un test, d’une migration vers le cloud ou d’une modification de l’infrastructure.

Dans un environnement correctement protégé, une base contenant des données sensibles devrait cumuler plusieurs barrières : authentification forte, accès réseau limité aux seuls systèmes nécessaires, gestion rigoureuse des droits, chiffrement, surveillance des connexions et vérifications régulières de la configuration. Il ne s’agit pas d’une mesure unique, mais d’une défense en profondeur.

Pour une entreprise d’IA, l’enjeu est accru par le nombre de composants concernés. Un service conversationnel combine généralement une interface web ou mobile, des serveurs d’API, des systèmes de stockage, des outils de suivi des performances et parfois des prestataires cloud. Chacun de ces maillons peut générer des journaux. Or les logs sont indispensables pour diagnostiquer une panne ou mesurer l’usage, mais ils peuvent aussi conserver des données auxquelles ils ne devraient pas donner accès.

L’affaire DeepSeek met donc en lumière une responsabilité plus large que celle d’un seul réglage technique. Les entreprises doivent savoir quelles données elles collectent, limiter leur conservation lorsque c’est possible et vérifier que les systèmes qui les hébergent ne sont pas exposés par erreur.

Ce que peuvent faire les utilisateurs et les entreprises

À la date du 30 janvier 2025, les informations disponibles ne permettent pas de dire avec précision quels comptes ou quelles conversations auraient pu être concernés. Les utilisateurs de DeepSeek n’ont donc pas à conclure automatiquement que leurs données ont été récupérées par un tiers. Ils peuvent toutefois adopter des pratiques utiles pour ce service comme pour tout autre assistant IA.

• Ne saisissez pas dans une conversation des mots de passe, numéros de carte bancaire, documents d’identité, clés d’accès ou secrets industriels.
• Si une clé API, un jeton d’accès ou un mot de passe a été copié dans un échange, révoquez-le et remplacez-le sans attendre une confirmation d’incident.
• Préférez des extraits anonymisés lorsque vous demandez une aide sur un document de travail, un contrat, du code ou des données clients.
• Vérifiez les paramètres de confidentialité et les règles de conservation des données avant d’utiliser un outil d’IA dans un cadre professionnel.

Changer le mot de passe d’un compte peut être pertinent en cas de doute, mais cela ne protège pas rétroactivement le contenu d’un échange déjà envoyé. Le réflexe le plus important consiste à ne pas traiter une fenêtre de discussion comme un coffre-fort. Même lorsqu’un service paraît pratique et familier, la prudence doit rester la règle pour les informations sensibles.

Les organisations ont, de leur côté, intérêt à définir les usages autorisés. Une politique interne claire peut préciser quelles données ne doivent jamais être envoyées à un assistant externe, quels services sont validés par les équipes informatiques et comment gérer les identifiants techniques. Pour les développeurs, les clés API doivent être stockées dans des outils dédiés, et non dans le code source, un fichier partagé ou une conversation.

Ce qu’il faut surveiller après l’exposition

Pour DeepSeek, cet incident intervient au moment où la visibilité de ses outils et de ses modèles augmente fortement. Dans un marché où les utilisateurs comparent les capacités des assistants, la fiabilité de l’infrastructure devient aussi un critère de choix. Une entreprise peut proposer un modèle très performant, mais perdre la confiance de ses clients si elle ne démontre pas qu’elle protège correctement leurs échanges et leurs accès techniques.

Plusieurs questions devront recevoir des réponses précises. DeepSeek pourra notamment clarifier la durée d’exposition de la base, la nature exacte des journaux concernés, les éventuels accès constatés avant la fermeture et les mesures prises pour éviter qu’un service similaire soit ouvert à l’avenir. Un retour d’expérience technique détaillé permettrait aussi aux utilisateurs et aux partenaires d’évaluer les garanties apportées.

L’épisode pourrait également attirer l’attention des autorités chargées de la protection des données. Toute évaluation réglementaire dépendrait de plusieurs éléments, dont la nature des informations concernées, les personnes touchées, les territoires où le service est proposé et les obligations applicables. À ce stade, l’essentiel est de ne pas transformer une exposition avérée en scénario non démontré, tout en prenant au sérieux le risque créé.

La leçon dépasse finalement DeepSeek. À mesure que les assistants IA s’installent dans les usages quotidiens, ils deviennent des réceptacles de données personnelles et professionnelles. Les entreprises qui les conçoivent doivent considérer la sécurité des conversations, des journaux et des clés d’accès comme une fonction centrale du produit, pas comme une contrainte ajoutée après son lancement.