Guide pratique de la souveraineté des données dans le partage de données avec des tiers : fournisseurs, sous-traitants et environnements multinationaux

La souveraineté des données reste maîtrisable tant que les données demeurent au sein d’une seule organisation et d’une même juridiction. Elle devient un enjeu de gouvernance dès que les données sont partagées — avec un fournisseur, un sous-traitant, une filiale régionale ou un partenaire soumis à un régime juridique différent.

La plupart des organisations gèrent correctement leur premier niveau de conformité, mais perdent la souveraineté en périphérie : dans la chaîne des fournisseurs, lors des transferts internes transfrontaliers dans les structures multinationales, ainsi que dans les canaux de messagerie et de partage de fichiers qui transportent la majorité du contenu sensible hors des cadres formels de contrôle de souveraineté.

Ce guide aborde les obligations réglementaires qui accompagnent les données dans les relations avec des tiers, les risques de souveraineté liés aux modèles de données centralisés à l’échelle multinationale, la surface de souveraineté méconnue des données non structurées en circulation, les clauses indispensables dans les contrats fournisseurs et celles qui ne peuvent pas se substituer à des mesures techniques, ainsi que l’architecture de chiffrement qui rend la souveraineté techniquement opposable aux tiers.

Résumé Exécutif

À retenir : Le responsable du traitement reste responsable de la gestion des données par les sous-traitants et leurs propres sous-traitants, quel que soit le nombre de niveaux contractuels. La plupart des échecs en matière de souveraineté ne surviennent pas chez le fournisseur cloud principal, mais dans la chaîne des fournisseurs, lors des transferts internes multinationaux et dans les canaux de données non structurées — messagerie électronique, partage de fichiers et MFT — qui transportent une part importante de contenu sensible hors des dispositifs formels de contrôle de souveraineté. La base technique repose sur la détention des clés de chiffrement par le client : lorsque le propriétaire des données détient les clés que le fournisseur ne possède jamais, ce dernier ne peut ni accéder au contenu lisible ni le divulguer, même sous contrainte légale — comblant ainsi la faille que les seuls contrats ne peuvent pas éliminer.

Pourquoi c’est important : L’article 28 du RGPD sur les obligations des sous-traitants, les exigences de gestion des risques liés aux tiers TIC de DORA (applicables dès janvier 2025) et le mandat de sécurité de la supply chain de NIS 2 créent des obligations de responsabilité qui se chevauchent, avec des sanctions pouvant atteindre 4 % du chiffre d’affaires mondial et une responsabilité personnelle des dirigeants. Ces obligations s’appliquent aussi bien aux données non structurées échangées par e-mail ou via le partage de fichiers qu’aux données structurées dans les bases de données — une distinction que la plupart des organisations n’ont pas encore intégrée dans leurs pratiques.

Résumé des points clés

1. Le responsable du traitement est responsable de toute la chaîne de traitement. L’article 28 du RGPD rend le responsable du traitement responsable de la conformité des sous-traitants et de leurs propres sous-traitants, quel que soit le nombre de niveaux contractuels. Une violation ou un manquement à la souveraineté par un sous-traitant de quatrième niveau expose le responsable du traitement à des risques réglementaires.
2. Les transferts internes au sein des multinationales sont considérés comme des transferts internationaux au sens du RGPD. Un stockage centralisé de données aux États-Unis, accessible par des filiales européennes, constitue un transfert vers un pays tiers soumis aux exigences du Chapitre V. Le fait d’appartenir au même groupe ne crée aucune exemption de juridiction.
3. La messagerie électronique et le partage de fichiers sont soumis aux mêmes obligations de souveraineté que les données structurées. Le RGPD, NIS 2 et DORA ne font aucune distinction selon le format des données. Le véritable écart d’application est organisationnel — la plupart des programmes de souveraineté se concentrent sur les bases de données et négligent les canaux par lesquels circulent réellement les données sensibles.
4. Les clés de chiffrement détenues par le client sont le contrôle technique qui rend la souveraineté opposable aux fournisseurs. Lorsque le propriétaire des données détient les clés que le fournisseur ne possède jamais, ce dernier ne peut ni accéder au contenu lisible ni le divulguer, même sous contrainte légale — il n’est donc plus nécessaire de faire confiance aux contrôles d’accès internes ou aux engagements de souveraineté du fournisseur.
5. Les dispositifs BYOK et les schémas de gestion de clés proposés par les grands fournisseurs cloud ne sont pas équivalents à la détention des clés par le client. Dans les dispositifs BYOK/BYOE, l’infrastructure du fournisseur gère les opérations de déchiffrement et conserve une capacité d’accès technique. Une assignation judiciaire permet d’obtenir des données lisibles. Avec des clés détenues par le client, le fournisseur ne possède jamais la capacité de déchiffrement : c’est la seule solution qui élimine réellement l’exposition au CLOUD Act et aux accès gouvernementaux.

Pourquoi le partage de données avec des tiers est l’événement de souveraineté le plus risqué

Dès que les données quittent le contrôle direct de l’organisation, le risque de souveraineté s’accroît. Le responsable du traitement conserve l’entière responsabilité réglementaire au titre de l’article 28 du RGPD pour la façon dont les données sont traitées tout au long de la chaîne des fournisseurs — mais il ne contrôle plus l’infrastructure, les politiques d’accès ni la juridiction légale de l’entité qui les traite. C’est dans cet écart entre responsabilité et contrôle que surviennent la plupart des échecs de souveraineté.

Le problème du CLOUD Act est particulièrement aigu dans la chaîne des fournisseurs. Une organisation européenne ayant mis en place une infrastructure souveraine peut partager des données sensibles avec un fournisseur basé aux États-Unis dont l’infrastructure est entièrement soumise au CLOUD Act. L’architecture de souveraineté s’arrête à la frontière de l’organisation ; la structure juridique américaine du fournisseur crée une exposition à laquelle l’organisation européenne pensait avoir échappé. Une gestion efficace des risques tiers en matière de souveraineté exige soit des preuves techniques vérifiables de contrôles équivalents chez le fournisseur, soit une architecture dans laquelle le fournisseur ne détient jamais de données lisibles.

Le cadre réglementaire : des obligations qui suivent les données

L’article 28 du RGPD impose que le traitement par un sous-traitant soit encadré par un contrat contraignant imposant des obligations équivalentes à celles du RGPD, y compris pour les sous-traitants ultérieurs. Les responsables du traitement doivent autoriser le recours à des sous-traitants, faire circuler les obligations tout au long de la chaîne et demeurer pleinement responsables en cas de manquement des sous-traitants. Un fournisseur incapable de fournir des preuves d’audit de ses contrôles de souveraineté ne répond pas aux exigences de l’article 28, quelle que soit la teneur de son contrat.

L’article 30 de DORA impose aux entités financières de l’UE d’inclure dans leurs contrats TIC des clauses spécifiques sur la localisation des données, la résidence des données, la gestion des clés de chiffrement, l’accessibilité en cas d’incident et les stratégies de sortie. DORA exige explicitement d’évaluer si les fournisseurs TIC peuvent démontrer une protection contre les accès gouvernementaux de pays tiers — une référence directe à l’exposition au CLOUD Act. Les fournisseurs incapables de démontrer une gestion conforme des clés créent une non-conformité active à DORA pour l’entité financière.

L’article 21 de NIS 2 impose aux opérateurs de services essentiels de mettre en œuvre des mesures de sécurité de la supply chain prenant en compte la posture de souveraineté des fournisseurs et prestataires directs — et de documenter cette évaluation. L’obligation se propage dans la chaîne : un fournisseur dont le sous-traitant introduit un risque de souveraineté expose l’opérateur de services essentiels à un risque NIS 2 au sommet de la chaîne.

Stockage centralisé multinational : le problème caché de souveraineté

Les groupes multinationaux centralisent souvent le stockage des données — entrepôt de données unique, CRM unifié, plateforme RH centralisée — accessible par les filiales de plusieurs pays. Chaque accès à des données personnelles de l’UE depuis un stockage centralisé hors UE constitue un transfert international soumis au Chapitre V du RGPD. L’appartenance au même groupe ne crée aucune exemption : lorsqu’une filiale européenne accède à des données stockées dans la plateforme centralisée de la maison mère américaine, il s’agit d’un transfert nécessitant une décision d’adéquation, des clauses contractuelles types avec analyses d’impact, ou un autre mécanisme valide. L’exposition au CLOUD Act s’applique au fournisseur américain du stockage centralisé, quel que soit le pays d’origine des données.

Les modèles centralisés concentrent également les risques : une seule demande liée au CLOUD Act ou une action réglementaire peut toucher simultanément les données de toutes les filiales. Pour les groupes soumis à NIS 2 ou DORA dans plusieurs États membres, une seule défaillance de souveraineté centralisée déclenche une exposition réglementaire dans plusieurs juridictions à la fois. La solution conforme à la souveraineté n’est pas forcément d’abandonner la centralisation — il s’agit d’appliquer un chiffrement détenu par le client au niveau des données, afin que le stockage centralisé ne contienne que des données chiffrées, tandis que les clés de déchiffrement restent entre les mains des entités propriétaires dans leurs juridictions respectives.

Messagerie et partage de fichiers : la surface de souveraineté négligée

Les programmes de souveraineté des données se concentrent massivement sur les bases de données et les données structurées — en négligeant les canaux par lesquels transitent la majorité des données sensibles : pièces jointes aux e-mails, plateformes de partage de fichiers et workflows MFT. Un contrat envoyé par e-mail à un fournisseur, un rapport financier partagé via une plateforme collaborative, un dossier de due diligence transféré à l’étranger — chacun constitue un transfert de données transfrontalier soumis aux mêmes obligations RGPD, NIS 2 et DORA qu’une réplication de base de données.

Le RGPD s’applique à tout traitement de données personnelles, quel que soit le format — y compris la transmission par e-mail. L’écart d’application est organisationnel : appliquer des contrôles de souveraineté aux bases de données, mais pas aux canaux de messagerie et de partage de fichiers qui les relient à l’extérieur, laisse d’importantes failles à la périphérie. Les exigences pratiques de souveraineté pour les données non structurées en circulation sont identiques à celles des données structurées : chiffrement en transit et au repos, contrôle des accès lors des transmissions transfrontalières, traçabilité de chaque événement de transfert, et application de règles empêchant la transmission vers des destinations non conformes — le tout au niveau de la plateforme, car les données quittent complètement l’infrastructure de l’organisation lorsqu’elles sont partagées avec un tiers.

Ce que doivent contenir les contrats fournisseurs — et ce qu’ils ne peuvent pas remplacer

Les contrats fournisseurs portant sur des données sensibles en matière de souveraineté doivent inclure : la limitation des finalités et instructions de traitement ; les standards de chiffrement et l’architecture de gestion des clés (en précisant si le fournisseur conserve la capacité de déchiffrement) ; l’autorisation des sous-traitants et la transmission des obligations ; les délais de notification en cas de violation ; les droits d’audit avec un périmètre précis ; la restitution ou la suppression des données à la fin du contrat ; et — pour les entités soumises à DORA — la localisation des données, la gestion des clés et les clauses de sortie conformément à l’article 30.

Ce que les contrats ne peuvent pas faire est tout aussi important. Un contrat imposant à un fournisseur américain de protéger les données européennes contre l’accès gouvernemental ne modifie pas son obligation légale de répondre à une demande valide au titre du CLOUD Act. Une clause de résidence des données crée une responsabilité en cas de violation — elle n’empêche pas techniquement les données de quitter une juridiction. Les contrats documentent les obligations ; ils ne constituent pas des contrôles techniques. La question centrale n’est donc pas de savoir si le contrat est complet, mais si le fournisseur peut démontrer, par l’architecture technique, que les données européennes sont protégées contre toute divulgation forcée, quelle que soit la demande légale.

Clés de chiffrement détenues par le client : la base technique

Les clés de chiffrement détenues par le client éliminent le risque de souveraineté dans la chaîne des fournisseurs à la source. Le propriétaire des données détient les clés que le fournisseur ne possède jamais — rendant ce dernier techniquement incapable d’accéder au contenu lisible ou de le divulguer, même sous contrainte légale. Cela diffère fondamentalement des dispositifs BYOK ou de gestion de clés par le client, où l’infrastructure du fournisseur gère les opérations de déchiffrement et conserve une capacité d’accès. Dans un schéma BYOK, une assignation judiciaire permet d’obtenir des données lisibles. Avec des clés détenues par le client, le fournisseur ne détient que des données chiffrées qu’il ne peut pas déchiffrer.

Appliqué au partage de données avec des fournisseurs, cela signifie que les données sensibles arrivent déjà chiffrées chez le fournisseur, avec des clés qu’il ne possède jamais. Le fournisseur peut les stocker, les transmettre et les traiter — mais il ne peut ni les lire, ni les divulguer, ni répondre à une demande gouvernementale sur leur contenu lisible. La souveraineté est maintenue non parce que le fournisseur a pris des engagements, mais parce qu’il n’a aucune capacité technique de les violer. Cela simplifie également l’évaluation de la souveraineté chez les fournisseurs : au lieu d’auditer les contrôles d’accès, la juridiction et la chaîne des sous-traitants de chaque fournisseur, le propriétaire des données maintient la souveraineté grâce à un contrôle architectural unique appliqué avant que les données ne quittent sa propre infrastructure.

Comment Kiteworks comble la faille de souveraineté avec les tiers

Le Réseau de données privé Kiteworks garantit la souveraineté des données avec les tiers sur tous les canaux utilisés par les données sensibles pour quitter une organisation — messagerie électronique, partage de fichiers, MFT, formulaires web et API — sous un cadre de règles unifié. Les clés de chiffrement contrôlées par le client, détenues exclusivement par le propriétaire des données et jamais accessibles à Kiteworks, garantissent que Kiteworks ne peut pas accéder aux données des clients, ni répondre à une assignation avec du contenu lisible, ni être contraint par un gouvernement de fournir des données déchiffrées.

La garantie de souveraineté est architecturale : elle s’applique quelle que soit la demande légale adressée à Kiteworks ou au fournisseur destinataire. Un déploiement à locataire unique dans l’emplacement choisi par le client place les données sous la juridiction et le contrôle de l’infrastructure du propriétaire. L’architecture de sécurité Zéro trust régit tous les accès fournisseurs et sous-traitants, chaque événement étant tracé dans des journaux d’audit immuables via le tableau de bord RSSI — fournissant la coopération d’audit de l’article 28, la documentation opérationnelle DORA et les preuves de la supply chain exigées par NIS 2. Le reporting conformité préconfiguré pour le RGPD, NIS 2, DORA et ISO 27001 fournit la documentation de responsabilité qu’aucun contrat fournisseur ne peut générer seul.

Pour découvrir comment Kiteworks sécurise le partage de données avec des tiers sur tous les canaux et dans toutes les juridictions, réservez une démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Souveraineté des données : bonne pratique ou obligation réglementaire ?
• eBook
  Souveraineté des données et RGPD
• Article de blog
  Évitez ces pièges de la souveraineté des données
• Article de blog
  Bonnes pratiques en matière de souveraineté des données
• Article de blog
  Souveraineté des données et RGPD [Comprendre la sécurité des données]