En bref
Quand vous confiez des données personnelles à un prestataire, vous restez responsable du traitement au sens du RGPD.
Les fuites viennent rarement de la malveillance : copies de test, accès trop larges, serveurs mal configurés.
Anonymiser avant de transmettre limite ce qui peut fuir, sans empêcher le prestataire de travailler.
Développement, migration, support, analyse de données, projet d’IA : les entreprises confient chaque jour des données à des ESN, des sous-traitants, des freelances ou des cabinets.
Ces données contiennent souvent des personnes : clients, patients, salariés, candidats.
Le contrat rassure, mais ce sont les copies qui fuient.
Prestataire et RGPD : qui est responsable ?
Le RGPD distingue deux rôles.
- Le responsable du traitement.
C’est l’entreprise qui décide pourquoi et comment les données sont traitées : c’est vous. - Le sous-traitant.
C’est le prestataire qui traite les données pour votre compte, sur vos instructions.
Externaliser ne transfère donc pas la responsabilité.
En cas d’incident chez le prestataire, c’est vers vous que se tournent la CNIL, vos clients et la presse.
L’article 28 du RGPD impose un contrat avec chaque sous-traitant.
La CNIL précise qu’il doit fixer notamment l’objet, la durée, la finalité du traitement et les obligations de sécurité des parties.
Ce contrat est indispensable.
Il ne suffit pas pour autant : juridiquement encadré ne veut pas dire techniquement maîtrisé.
Pourquoi les données fuient chez les prestataires
Le problème est rarement la malveillance.
Il est presque toujours organisationnel.
- Une base de production transmise en entier.
Pour tester une fonctionnalité, le prestataire reçoit toutes les données clients réelles. - Des copies qui se multiplient.
Un environnement de staging, une copie locale pour le debug, une sauvegarde temporaire, un export pour reproduire une erreur. - Des environnements secondaires moins protégés.
Les bases de test et les serveurs de recette sont souvent moins surveillés que la production. - Des accès trop larges et trop longs.
Les droits ouverts pour un projet restent actifs bien après sa fin. - Des copies conservées au-delà du besoin.
Sauvegardes techniques et fichiers « temporaires » survivent à la mission.
En quelques étapes, une seule base devient plusieurs copies, chez plusieurs personnes.
Voir aussi les environnements de test, angle mort du RGPD.
5 exemples réels de fuites évitables
Ces incidents publics montrent le même schéma : un prestataire, un accès ou une configuration mal maîtrisés, et des données en clair.
-
Change Healthcare (2024).
Ce prestataire du secteur de la santé américain a été attaqué via un accès trop large et sans authentification à plusieurs facteurs.Résultat : une fuite massive de données de santé et le blocage de son système de facturation.
-
Dell (2024).
Les noms et adresses d’environ 49 millions de clients ont été exposés, faute d’un accès suffisamment restreint aux données clients.Ces données nourrissent ensuite le phishing ciblé.
-
American Express (2024).
Des données de cartes ont été exposées via un prestataire de traitement des paiements qui les stockait en clair.Conséquence : un remplacement massif de cartes.
-
Pegasus Airlines.
6,5 To de données, dont des données personnelles, se trouvaient sur un serveur cloud accessible publiquement.Une simple erreur de configuration a suffi.
-
Perceptics et la CBP (2019).
Un sous-traitant de l’agence américaine des douanes et de la protection des frontières (CBP) a été attaqué : des données biométriques de voyageurs ont fuité.
Dans chaque cas, des données réelles et identifiantes ont été exposées par un accès, une configuration ou un prestataire mal maîtrisés.
Comment protéger les données confiées à un prestataire
- Définir le besoin réel.
Un développeur a besoin de la structure et du volume, pas des vrais noms ; un data scientist a besoin des montants et des dates, pas des adresses. - Détecter les données personnelles.
Pas seulement les colonnes « nom » ou « email » : aussi les champs libres, les commentaires, les signatures et les combinaisons qui désignent une personne. - Anonymiser avant le transfert.
Le prestataire reçoit une copie utilisable, sans identités ; c’est l’application directe du principe de minimisation. - Garder l’original en interne.
La base ou le dossier source ne sort jamais. - Limiter et tracer les accès.
Des droits restreints, pour une durée définie, et une trace de ce qui a été transmis.
Le choix de la méthode dépend de l’usage : voir le guide des méthodes d’anonymisation.
Les cas qui reviennent le plus souvent
- Un prestataire IA.
Il doit entraîner un modèle sur des années d’historique : rapports, fiches, échanges. Voir anonymiser les données industrielles avant de les confier à un prestataire IA. - Un cabinet ou un expert.
Un avocat, un expert-comptable ou un expert judiciaire reçoit des contrats, des pièces et des correspondances. Voir l’anonymisation des documents juridiques. - Une ESN ou un freelance en développement.
Il travaille sur une copie de base pour tester, migrer ou corriger un bug. - Un partenaire commercial.
Il reçoit un contrat, une proposition commerciale ou un tableau de clients.
Dans tous ces cas, le prestataire a besoin du contenu, pas de l’identité des personnes.
Confiance et prévention vont ensemble
Anonymiser avant de transmettre n’est pas un signe de méfiance envers le prestataire.
C’est une protection pour les deux parties.
Le prestataire manipule moins de données sensibles, donc porte moins de risque.
Vous gardez la maîtrise de ce qui circule.
Avec NymData
NymData détecte et anonymise les données personnelles de vos fichiers (PDF, Word, Excel, PowerPoint, CSV, texte) et de vos bases PostgreSQL et MySQL, sur vos serveurs, avant tout envoi à un prestataire :
- Une cartographie d’abord.
Analysez un dossier ou une base sans rien modifier, et consultez le rapport des données trouvées avant d’agir. - Une copie anonymisée, l’original intact.
Les fichiers traités sont écrits dans un dossier séparé ; pour une base, les données anonymisées sont insérées dans une base cible. - Un identifiant constant.
Dans vos fichiers Word, Excel, CSV et vos bases, Jean Dupont devient PERSON_7b94f21c dans tout le projet, ce qui garde les jointures et les tests cohérents. - Un rapport d’audit pour chaque traitement.
Vous savez ce qui a été détecté et traité avant de transmettre.
Questions fréquentes
Comment protéger les données personnelles confiées à un prestataire externe ?
En ne lui transmettant que ce dont il a besoin pour sa mission (principe de minimisation).
En anonymisant les identités avant l'envoi, et en gardant l'original en interne.
En encadrant la relation par un contrat de sous-traitance et des accès limités dans le temps.
RGPD et externalisation : quelles sont les obligations de l'entreprise ?
L'entreprise reste responsable du traitement, même quand le prestataire traite les données.
Elle doit choisir un sous-traitant qui présente des garanties suffisantes et signer avec lui un contrat conforme à l'article 28 du RGPD.
En cas de violation de données, c'est à elle de la gérer et, le cas échéant, de la notifier à la CNIL.
Comment sécuriser les contrats et propositions commerciales contre les fuites d'information ?
Ces documents contiennent souvent des données personnelles : noms des signataires, coordonnées, parfois des informations sur des salariés ou des clients.
Avant de les transmettre à un prestataire ou à un cabinet, anonymisez les données personnelles dans une copie et gardez l'original en interne.
Pensez aussi aux métadonnées : l'auteur d'un fichier Word ou PowerPoint voyage avec lui.
Un prestataire certifié suffit-il à éliminer le risque ?
Non.
Une certification est un bon signal, mais elle n'empêche pas une erreur de configuration, une copie de debug oubliée ou une sauvegarde gardée trop longtemps.
Anonymiser complique-t-il le travail du prestataire ?
Non, si c'est bien préparé.
La structure des fichiers et des bases est conservée ; seules les identités sont anonymisées.
Avec un identifiant constant, une même personne garde le même code dans toutes les tables, ce qui préserve les jointures et les tests.