12 novembre 2026 · Équipe VRAMfarm

Mes données sont-elles en sécurité sur un GPU loué ? Qui les voit, où, RGPD

Les autres clients ne peuvent pas voir vos données. L’hôte propriétaire de la machine le pourrait techniquement pendant que votre serveur tourne, comme sur n’importe quel cloud où quelqu’un d’autre détient le matériel. Après l’arrêt, le disque du serveur est effacé. Pour la plupart des travaux d’IA (modèles publics, vos propres images, entraînements, jeux de données de test), c’est un niveau de sécurité raisonnable. Pour des secrets, des données clients ou des données personnelles de tiers, il faut prendre les précautions décrites ici.

Qui gère la machine, et où elle se trouve

VRAMfarm ne possède pas de data centers. Le catalogue rassemble les machines d’hôtes sélectionnés, et c’est ce qui permet de garder des prix bas. Trois informations sur chaque machine sont visibles avant le lancement :

• Le pays. Il s’affiche sur chaque machine du catalogue et dans le sélecteur, où vous pouvez aussi filtrer par région. « Europe » y désigne la géographie, pas l’UE : la région peut inclure le Royaume-Uni, la Suisse ou la Norvège, donc vérifiez le code pays si la localisation dans l’UE compte pour vous. Quelques machines affichent « Pays non précisé » ; évitez-les si la localisation compte.
• Vérifiée ou non. Par défaut, le catalogue n’affiche que les machines vérifiées. Les autres n’apparaissent que si vous cochez « Afficher les machines non vérifiées ».
• La fiabilité, c’est-à-dire la part du temps pendant laquelle la machine a fonctionné sans panne, avec sa version de pilote et de CUDA.

C’est donc vous qui choisissez où votre tâche s’exécute. Un détail : si la machine choisie est louée par quelqu’un d’autre dans les secondes qui précèdent votre lancement, nous prenons une machine similaire du même type, qui peut se trouver dans un autre pays. La fiche du serveur dans Mes serveurs indique le pays où il tourne réellement : vérifiez-le avant d’envoyer quoi que ce soit de sensible.

Ce qui protège vos données par défaut

Votre propre conteneur. Chaque serveur tourne dans un conteneur distinct, avec son propre disque et les GPU que vous avez loués. Une grosse machine peut accueillir plusieurs clients à la fois, chacun dans son conteneur, et aucun ne peut voir les fichiers, les processus ou la mémoire GPU des autres.

Des clés, pas des mots de passe. SSH n’accepte que la clé publique enregistrée dans vos paramètres ; il n’y a pas de mot de passe à deviner. SSH et scp sont chiffrés de bout en bout, de votre ordinateur jusqu’au serveur. Le lien Jupyter de Mes serveurs contient un long token, qui fonctionne comme un mot de passe : ne publiez pas de captures d’écran où il apparaît. Vous vous connectez par notre adresse, avec un port distinct pour chaque serveur.

Le disque est effacé à l’arrêt. Quand vous arrêtez le serveur, le conteneur et son disque sont supprimés, et nous ne gardons aucune copie en dehors d’un dossier que vous avez choisi d’enregistrer. Le support ne peut pas non plus le restaurer : c’est le revers de la même médaille. Ce que nous ne pouvons pas vous fournir, c’est un certificat attestant que chaque bloc physique du disque de l’hôte a été réécrit. Si ce niveau de garantie compte, chiffrez les données, comme décrit plus bas.

Le dossier enregistré n’appartient qu’à vous. Si vous cliquez sur Enregistrer et arrêter, /workspace part vers un stockage qui n’est lié à aucun hôte. Le dossier de chaque client a sa propre clé d’accès, qui n’ouvre que ce dossier, et ces clés sont stockées chiffrées dans notre base de données. Le dossier est supprimé quand vous le supprimez dans le tableau de bord, quand vous supprimez votre compte, ou après 30 jours avec un solde à zéro, avec un avertissement préalable.

Ce qu’un hôte pourrait techniquement voir

Un conteneur sépare les clients entre eux. Il ne vous sépare pas du propriétaire de la machine. Une personne disposant d’un accès administrateur au serveur physique peut, en principe, regarder dans les conteneurs qui y tournent : leur disque, leur mémoire, la mémoire du GPU, le trafic réseau qui sort de la machine. C’est vrai sur tous les clouds où le matériel ne vous appartient pas. Sur les clouds de type place de marché, avec de nombreux hôtes indépendants, c’est simplement plus visible.

La sélection des hôtes, les machines vérifiées et les scores de fiabilité réduisent la probabilité que quelqu’un le fasse. Ils ne le rendent pas impossible, et nous ne prétendrons pas le contraire. Il existe du matériel qui cache une tâche en cours même au propriétaire de la machine (le confidential computing sur certains GPU de data center), mais nous ne le proposons pas. Si votre contrat exige cette garantie, il vous faut un fournisseur qui l’offre.

Ce que voit notre propre service : le nombre de connexions, la charge du GPU et le volume de trafic, utilisés pour la facturation et l’arrêt automatique en cas d’inactivité. Notre automatisation se connecte aussi à votre serveur pour installer une application prête à l’emploi, la redémarrer si elle plante et enregistrer votre dossier quand vous le demandez. Nous ne vendons pas de données, et les applications prêtes à l’emploi font tourner leurs modèles sur votre serveur : vos prompts ne sont donc pas transmis à un service d’IA externe.

Six façons de réduire le risque

1. N’envoyez pas de secrets. Pas de clés d’API de production, d’identifiants d’administration cloud, de fichiers .env de systèmes en production ni de clés SSH privées. Si une tâche a besoin d’un token, créez-en un rien que pour elle : un token Hugging Face en lecture seule, une clé S3 limitée à un seul bucket, un token d’API VRAMfarm distinct. Révoquez-le une fois la tâche terminée. La colonne Dernière utilisation dans Paramètres → Tokens API montre si un token est utilisé.

2. Chiffrez les jeux de données pour le stockage et le transfert. Gardez les données sensibles chiffrées chez vous et dans votre bucket, et ne les déchiffrez que sur le serveur, idéalement dans un dossier que vous n’enregistrerez pas. Avec age :

# sur votre ordinateur
tar czf - dataset | age -p > dataset.tgz.age

# sur le serveur (apt-get install -y age)
age -d dataset.tgz.age | tar xzf - -C /root

Sous Windows, une archive 7-Zip en AES-256 avec noms de fichiers chiffrés (7z a -p -mhe=on data.7z dataset) fait le même travail. Soyez au clair sur ce que cela vous apporte : les données sont protégées dans votre bucket, pendant le transfert et dans les restes après l’arrêt. Pendant que la tâche tourne, les fichiers déchiffrés existent sur le serveur : le chiffrement ne protège donc pas contre un hôte qui inspecte une machine en marche.

3. Gardez les conversations et les prompts sur votre propre serveur. Pour des documents confidentiels, un chat privé avec Qwen3 ou une autre application prête à l’emploi fait tourner le modèle sur le GPU que vous louez. Rien ne part vers une API d’IA externe, et la conversation est supprimée à l’arrêt, sauf si vous enregistrez le dossier.

4. Choisissez le pays. Si vos données doivent rester dans l’UE, choisissez une machine dans un pays de l’UE, et vérifiez la fiche du serveur après le lancement pour confirmer où il a atterri.

5. Récupérez les résultats, puis arrêtez sans enregistrer. Pour un projet sensible, téléchargez ce dont vous avez besoin avec scp ou rclone et cliquez sur Arrêter, pas sur Enregistrer et arrêter. Si vous avez enregistré un dossier auparavant, supprimez-le dans le tableau de bord à la fin du projet. La différence entre les deux boutons est expliquée dans ce que deviennent vos fichiers quand vous arrêtez un GPU.

6. Envoyez moins de données réelles. Déboguez sur des échantillons synthétiques ou anonymisés, retirez les noms et les identifiants des enregistrements, recadrez les visages dont la tâche n’a pas besoin. Des données qui ne sont pas sur le serveur ne peuvent pas en fuiter.

Pour les photos personnelles destinées à l’entraînement d’un LoRA, une inquiétude fréquente : entraîner un modèle sur votre propre visage pendant un après-midi sur une machine vérifiée représente un faible risque pour la plupart des gens. Si une fuite des photos vous contrarierait, utilisez le plus petit jeu qui fonctionne (15 à 25 images en général), choisissez le pays et arrêtez sans enregistrer. Les photos d’autres personnes demandent leur autorisation, ce qui relève aussi du RGPD.

Le RGPD en clair

Quand vous envoyez des données personnelles de tiers (clients, patients, salariés, utilisateurs de votre application), vous êtes le responsable du traitement et c’est vous qui décidez de sa finalité. Celui qui les traite pour vous est un sous-traitant, et le RGPD exige un contrat écrit avec lui, l’accord de traitement des données (DPA) de l’article 28. Nous ne pouvons pas encore en proposer : notre société est encore en cours de création, et il n’y a pas de DPA à télécharger. D’ici là, ne traitez pas de données personnelles de tiers sur ces serveurs, sauf si votre propre conseiller en protection des données estime que c’est acceptable dans votre cas. Les données anonymisées et synthétiques ne sont pas des données personnelles et ne posent pas ce problème.

La localisation. Les machines peuvent se trouver hors de l’UE, et nous ne promettons pas un traitement uniquement dans l’UE. Vous voyez le pays avant le lancement et pouvez rester dans l’UE en choisissant des machines situées dans l’UE. Les questions juridiques, comme celle de savoir quelles lois étrangères peuvent s’appliquer à un hôte donné, dépendent de qui gère la machine et où. Nous y répondrons sérieusement quand le DPA existera, pas dans un article de blog.

Les certifications. Si votre contrat exige des data centers certifiés ISO 27001 ou équivalent pour chaque machine, un catalogue de nombreux hôtes n’est pas l’outil adapté à ce projet aujourd’hui.

Les données de votre compte (e-mail, historique des paiements, clé SSH, chat du support) relèvent de notre politique de confidentialité. Vous pouvez demander à les consulter, à les corriger ou à les supprimer. La suppression de votre compte efface votre e-mail, votre nom, votre clé SSH et votre dossier enregistré.

Pour la plupart des travaux que l’on fait sur des GPU loués (générer des images, entraîner sur ses propres données, tester des modèles ouverts), les protections par défaut plus les mesures 1, 4 et 5 suffisent. Pour des données clients, décidez avant d’envoyer quoi que ce soit, pas après, et en cas de doute, demandez-nous ce qui s’applique à votre cas.