Où résident vos données : la souveraineté juridictionnelle dans le partage sécurisé de fichiers en entreprise

Pour les organisations réglementées dans l’UE, la question « Où résident les données ? » ne relève plus uniquement du service IT. Les juristes, les DPO et les équipes achats participent désormais systématiquement aux discussions — car la réponse a des implications directes pour la conformité RGPD, les obligations NIS 2, les exigences tierces de DORA et l’exposition à la portée extraterritoriale de juridictions hors UE.

Cet article explique ce que signifie réellement la souveraineté juridictionnelle pour le partage de fichiers en entreprise : où résident physiquement les données, qui détient l’autorité légale pour y accéder, que se passe-t-il lorsqu’un gouvernement en fait la demande, et comment sont encadrés les transferts transfrontaliers. Nous détaillons les questions que les organisations européennes doivent poser à chaque fournisseur — et analysons l’approche de Kiteworks sur chacun de ces points, en fonction de sa structure contractuelle et de sa posture de conformité documentée.

Résumé Exécutif

Idée principale : La souveraineté juridictionnelle dans le partage de fichiers en entreprise repose sur trois axes : l’emplacement physique des données, l’autorité légale pouvant exiger l’accès, et les mesures techniques et contractuelles empêchant toute divulgation non autorisée. Ces trois questions sont souvent traitées séparément lors des achats — mais elles sont interdépendantes, et une faille sur l’un de ces axes remet en cause l’ensemble.

Pourquoi c’est important : NIS 2 et DORA imposent aux organisations de prouver qu’elles comprennent et maîtrisent l’exposition juridictionnelle de leurs fournisseurs. Schrems II a fait des mécanismes de transfert transfrontalier un critère clé d’achat. Avec le CLOUD Act qui étend la portée du gouvernement américain aux données détenues par des sociétés mères américaines partout dans le monde, le choix du cocontractant — et du droit applicable — est devenu l’une des décisions les plus lourdes de conséquences dans la relation fournisseur.

5 Points Clés à Retenir

  1. Résidence et souveraineté des données ne sont pas synonymes. La résidence désigne l’emplacement physique des données. La souveraineté concerne l’autorité légale pouvant exiger ou obtenir l’accès. Un fournisseur peut stocker des données à Francfort tout en restant soumis à la législation américaine via sa structure d’entreprise. Il faut donc répondre séparément à ces deux questions.
  2. L’entité contractante compte autant que le produit. Le cocontractant détermine le droit applicable à la relation et les lois extraterritoriales auxquelles le fournisseur est soumis. Signer avec une entité américaine vous expose au CLOUD Act, même si les serveurs sont à Amsterdam.
  3. Le chiffrement HYOK (Hold Your Own Key) est une garantie de transfert, pas seulement une fonction de sécurité. L’architecture HYOK — clés détenues par le client, hors du contrôle du fournisseur — transforme la donnée d’un objet juridiquement saisissable en une donnée techniquement inaccessible. L’EDPB reconnaît le chiffrement HYOK comme mesure complémentaire valable pour les transferts transfrontaliers, sous réserve de conditions : algorithme robuste, clés hors du pays tiers, aucun accès de l’importateur aux clés même sous contrainte légale — selon le cadre Schrems II et l’actuel Data Privacy Framework UE–États-Unis, où des mesures complémentaires restent recommandées en raison d’un recours en cours (C-703/25 P).
  4. La transparence sur l’accès gouvernemental est une exigence d’achat, pas une faveur. NIS 2 et DORA imposent aux organisations de comprendre la réaction du fournisseur face à une demande d’accès gouvernementale. « Nous respectons la loi applicable » n’est pas une réponse. Demandez la procédure de contestation et la politique de notification client.
  5. La juridiction des sous-traitants est un risque caché dans la plupart des déploiements de partage de fichiers. Les engagements de protection des données de votre fournisseur ne valent que pour sa chaîne de sous-traitance. Un sous-traitant situé dans une juridiction à risque de surveillance élevé peut exposer des données que votre contrat principal protège en théorie.

Résidence des Données : Où Sont-elles Réellement Stockées ?

La réponse à « Où résident les données ? » dépend fondamentalement du modèle de déploiement — et la réponse diffère radicalement entre on-premises et SaaS. Bien répondre à cette question est crucial non seulement pour la conformité mais aussi pour la résilience opérationnelle. Si la résidence des données n’est pas verrouillée contractuellement, elle peut évoluer au gré des décisions d’infrastructure du fournisseur, sans votre consentement.

Déploiement On-Premises : Le Client Maîtrise la Géographie

En déploiement on-premises, le client exploite l’appliance Kiteworks sur une infrastructure qu’il possède ou contrôle — dans le centre de données et la juridiction de son choix. Le fournisseur n’a aucun accès à cette infrastructure et ne décide pas de l’emplacement des données. Pour les organisations réglementées en Allemagne, France, Pays-Bas ou autres États membres exigeant le maintien des données dans certaines frontières, ce modèle apporte la réponse la plus claire : les données sont là où vous les placez, sous votre contrôle physique et opérationnel.

Le modèle d’appliance durcie de Kiteworks renforce cette garantie. L’appliance est autonome et fonctionne indépendamment de l’infrastructure cloud de Kiteworks. Aucune connexion obligatoire à des systèmes opérés par le fournisseur ne peut entraîner un transfert de données hors de la zone choisie par le client. Associé à l’architecture HYOK — où le client détient et gère les clés de chiffrement indépendamment de Kiteworks — le modèle on-premises offre à la fois le contrôle physique de la résidence et l’indépendance cryptographique.

Déploiement SaaS : Un Autre Enjeu

Le déploiement SaaS implique que les données résident sur une infrastructure opérée par le fournisseur. Pour les clients européens, cela signifie vérifier quelles régions sont disponibles, si les données restent dans ces régions en toutes circonstances, et s’il existe des mécanismes de repli pouvant entraîner un transfert hors UE. Kiteworks propose des options SaaS en région UE — les régions précises, leur statut de certification et les engagements contractuels sur la localisation des données sont des points à aborder lors de tout achat SaaS dans l’UE.

En toute transparence, le déploiement on-premises offre aux organisations européennes la réponse la plus solide sur la résidence des données. Le SaaS introduit des décisions géographiques côté fournisseur qui nécessitent un engagement contractuel explicite pour être maîtrisées.

L’Entité Contractante : Avec Qui Signez-vous Réellement ?

Cette question est plus importante qu’on ne le pense souvent lors des achats. L’entité juridique avec laquelle vous contractez détermine le droit applicable à la relation, la juridiction compétente en cas de litige, et — point crucial — les gouvernements pouvant contraindre le fournisseur à fournir ou à donner accès aux données. Deux aspects sont à distinguer : l’entité contractante principale, et la question de la société mère qui la contrôle.

Kiteworks Europe AG : L’Entité Contractante pour l’UE

Pour les clients EMEA, l’entité contractante est Kiteworks Europe AG, enregistrée à Bahnhofstrasse 29, Zoug, Suisse. C’est cette entité qui figure dans le contrat de licence EMEA, et cela compte pour deux raisons.

Premièrement, la Suisse n’est pas membre de l’UE, mais bénéficie d’une décision d’adéquation pour les transferts de données depuis l’UE, et son droit est reconnu comme offrant une forte protection des données. Deuxièmement, et de façon plus concrète, l’incorporation en Suisse apporte une réelle protection face au CLOUD Act américain. Le CLOUD Act impose aux entités américaines de fournir les données détenues partout dans le monde sur requête légale américaine. Une entité suisse n’est pas directement soumise à cette juridiction — elle relève du droit suisse, qui impose ses propres procédures et un cadre d’entraide judiciaire (MLAT) avant toute exécution d’une demande étrangère.

Cela ne signifie pas qu’une entité suisse est immunisée contre toute demande étrangère. Cela veut dire que la voie légale est plus encadrée, mieux définie, et plus susceptible de permettre la notification et la contestation par le client. C’est une position nettement plus favorable que de contracter directement avec une entité américaine, pour qui l’obligation de se conformer au CLOUD Act est domestique.

À vérifier : Assurez-vous que votre contrat de licence mentionne explicitement Kiteworks Europe AG comme entité contractante. Si votre contrat date de plusieurs années, vérifiez que le nom de l’entité est à jour — certains contrats anciens peuvent mentionner une entité précédente. Demandez à votre équipe Kiteworks de confirmer l’entité contractante en vigueur pour votre juridiction.

Kiteworks USA, la Holding Intermédiaire UK et la Question de la Société Mère

Kiteworks Europe AG s’inscrit dans une structure d’entreprise plus large, incluant une holding intermédiaire au Royaume-Uni, société mère directe de l’entité suisse. Cela introduit un second vecteur juridictionnel que les organisations européennes doivent cartographier : le UK Investigatory Powers Act 2016 (IPA) et l’accord d’accès aux données UK–US (2022).

Le UK IPA donne aux autorités britanniques le pouvoir d’émettre des avis de capacité technique, des mandats de collecte massive et des obligations de conservation de données à des fournisseurs connectés au Royaume-Uni. L’accord d’accès aux données UK–US (2022) — accord bilatéral dans le cadre du CLOUD Act — permet aux autorités britanniques et américaines de faire des demandes directes aux fournisseurs dans la juridiction de l’autre. Ainsi, la holding intermédiaire UK introduit une voie de contrainte distincte, parfois plus directe que la voie MLAT suisse évoquée plus haut.

En pratique : L’entité contractante suisse (Kiteworks Europe AG) réduit l’exposition directe au CLOUD Act pour les clients européens. La holding intermédiaire UK introduit l’exposition au UK IPA et à l’accord d’accès UK–US comme second vecteur. Comme pour le CLOUD Act, la réponse opérationnelle en matière de protection des données est que l’architecture HYOK transforme toute contrainte légale réussie en restitution de données chiffrées — la holding UK, comme la société mère américaine, ne peut fournir de données lisibles dont elle ne détient pas les clés. Les organisations dont l’analyse de risques exige la cartographie complète de la chaîne de contrôle doivent demander confirmation de la structure de détention à leur équipe Kiteworks.

Pour la majorité des organisations réglementées européennes, la structure suisse et les garanties techniques (HYOK, déploiement on-premises) suffisent à répondre aux exigences de souveraineté. Pour les exigences les plus strictes — nécessitant propriété et gouvernance européennes sur la technologie elle-même — la société mère américaine et la holding UK sont des limites à documenter.

Accès Gouvernemental : Que Se Passe-t-il en Cas de Demande d’un État ?

Schrems II a rendu cette question incontournable. La Cour de justice de l’UE a invalidé le Privacy Shield en 2020 précisément parce que la législation américaine sur la surveillance — CLOUD Act, FISA 702, Executive Order 12333 — permet aux autorités US d’accéder aux données personnelles sans recours effectif pour les personnes concernées dans l’UE.

Depuis juillet 2023, le Data Privacy Framework (DPF) UE–États-Unis a remplacé le Privacy Shield comme mécanisme d’adéquation pour les transferts vers les organisations américaines certifiées DPF. Le Tribunal de l’UE a confirmé l’adéquation du DPF en septembre 2025 (Latombe, T-553/23), mais un recours est en cours devant la CJUE (C-703/25 P). Le DPF constitue donc actuellement le mécanisme légal pour les transferts UE–US — mais sa validité future n’est pas garantie, et les organisations qui s’appuient sur le DPF comme principal mécanisme de transfert doivent maintenir des mesures complémentaires en cas d’invalidation.

Toute organisation ayant un fournisseur avec une société mère américaine doit répondre sérieusement à la question de la législation sur la surveillance, quel que soit le mécanisme de transfert utilisé. Deux éléments comptent : comprendre la cartographie de l’exposition, et disposer d’une garantie technique rendant la contrainte légale inopérante.

Cartographie de l’Exposition au CLOUD Act

Le CLOUD Act s’applique aux entités américaines et à leurs filiales. Pour les clients européens contractant avec Kiteworks Europe AG sous droit suisse, l’exposition directe au CLOUD Act est réduite — les autorités américaines devraient passer par une procédure MLAT suisse pour contraindre Kiteworks Europe AG, au lieu d’un mandat domestique. Cette procédure est plus lente, plus transparente et plus facilement contestable.

Cependant, il faut aussi prendre en compte la chaîne des sous-traitants. Si un sous-traitant Kiteworks manipulant des données européennes est une entité américaine, la portée du CLOUD Act peut s’étendre à travers ce sous-traitant, même si l’entité contractante principale est suisse. D’où l’importance de la juridiction des sous-traitants — c’est un point clé de l’évaluation d’impact sur les transferts exigée par Schrems II.

HYOK comme Garantie Technique selon Schrems II

Les recommandations de l’EDPB sur les mesures complémentaires (Recommandations 01/2020) reconnaissent explicitement le chiffrement dont l’importateur ne détient pas les clés comme garantie technique valable pour les transferts de données. L’architecture HYOK de Kiteworks a été conçue pour ce cas précis.

Avec HYOK, le client détient les clés de chiffrement sur sa propre infrastructure. Kiteworks — et tout gouvernement contraignant Kiteworks — ne peut pas déchiffrer les données, car il ne possède pas les clés. Les données, stockées par Kiteworks ou ses sous-traitants, sont inaccessibles sans la participation du client. Cela transforme le risque de contrainte légale en impossibilité technique, ce qui constitue la mesure complémentaire la plus solide actuellement disponible sur le marché.

Kiteworks documente son exposition légale au CLOUD Act, à la FISA 702 et au cadre multi-juridictionnel pertinent pour ses activités. Ces mécanismes diffèrent sur la notification : une demande d’application du CLOUD Act peut permettre la notification du client et une contestation, alors que les directives FISA 702 imposent un secret légal interdisant d’informer le client concerné. Kiteworks prévoit une politique de notification et une procédure de contestation pour les cas où la loi l’autorise, dans sa documentation sur l’accès gouvernemental. L’association de l’architecture HYOK et d’un HSM opéré par le client sur site — avec chiffrement validé FIPS 140-3 — constitue la base technique pour empêcher l’accès extraterritorial, ce que les organisations réglementées doivent documenter dans leurs évaluations d’impact sur les transferts.

Contrôles à l’Export et Conformité Multi-juridictionnelle

Pour les organisations des secteurs défense, aérospatial ou technologies à double usage, la conformité aux contrôles à l’export ajoute une couche supplémentaire à la question juridictionnelle. Kiteworks détient la classification IRAP PROTECTED selon l’Australian Information Security Manual — un cadre pertinent pour les organisations du secteur défense dans les pays alliés de l’OTAN. La plateforme répond aussi aux exigences de conformité ITAR, pour les organisations manipulant des données techniques contrôlées.

Le portefeuille de certifications multi-juridictionnelles — BSI C5 Type 2, ISO 27001, Cyber Essentials Plus, IRAP PROTECTED, FedRAMP High In Process, SOC 2 Type II — apporte la preuve de conformité dont les équipes achats des secteurs réglementés ont besoin pour leurs évaluations de risques tierces.

Transferts Transfrontaliers : Maintenir la Conformité RGPD

Pour tout transfert de données personnelles depuis l’UE vers un pays tiers, le RGPD Chapitre V exige soit une décision d’adéquation pour le pays de destination, soit une garantie appropriée — le plus souvent les clauses contractuelles types. Depuis Schrems II, les SCC seules ne suffisent plus pour les transferts vers les États-Unis. Les organisations doivent réaliser une évaluation d’impact sur les transferts et, si le cadre légal du pays de destination n’offre pas une protection équivalente, mettre en place des mesures complémentaires.

Pour les transferts vers les États-Unis, le Data Privacy Framework (DPF) UE–États-Unis, en vigueur depuis juillet 2023 et confirmé par le Tribunal de l’UE en septembre 2025 (Latombe, T-553/23), constitue un mécanisme d’adéquation pour les organisations certifiées DPF. Cependant, un recours est en cours devant la CJUE (C-703/25 P), et les organisations qui s’appuient sur le DPF doivent maintenir des mesures complémentaires par précaution. Pour les transferts via l’entité suisse de Kiteworks, l’adéquation suisse — maintenue séparément selon le droit suisse — offre un mécanisme de transfert supplémentaire indépendant de la validité du DPF.

Clauses Contractuelles Types et DPA Kiteworks

Le Data Processing Agreement (DPA) de Kiteworks s’appuie sur le cadre SCC, couvrant la relation responsable–sous-traitant et les mécanismes de transfert pour toute donnée sortant de l’UE. Le DPA inclut les mécanismes de transfert exigés par l’article 46 du RGPD pour un traitement licite.

Pour les organisations réalisant une TIA — comme l’exige Schrems II — les facteurs à considérer sont le cadre légal du pays importateur, la nature des données transférées, et les mesures techniques et organisationnelles en place. La structure suisse est un facteur pertinent : décision d’adéquation suisse et exigences procédurales suisses pour les demandes d’accès étrangères créent un profil de risque différent d’un transfert direct vers une entité américaine.

HYOK comme Réponse Schrems II

Pour les organisations recherchant la position la plus solide sur la légalité des transferts transfrontaliers, HYOK est la mesure complémentaire la plus défendable. Si les données sont chiffrées avec des clés détenues par le client et inaccessibles à Kiteworks, même en cas de transfert de données chiffrées, il n’y a pas d’exposition significative — le destinataire ne peut pas les lire.

Ce n’est pas une astuce. C’est précisément l’architecture envisagée par l’EDPB dans ses recommandations sur les mesures complémentaires. Les organisations utilisant Kiteworks avec HYOK et un déploiement on-premises disposent d’une position solide pour leurs évaluations d’impact sur les transferts.

Sous-traitants : Le Risque Juridictionnel Souvent Oublié

Les engagements de protection des données d’un fournisseur ne valent que pour sa chaîne de sous-traitance. Chaque sous-traitant susceptible de manipuler ou d’accéder à des données européennes introduit sa propre exposition — sa juridiction d’incorporation, ses obligations légales locales, et le risque d’accès gouvernemental qui en découle.

Le DPA de Kiteworks inclut une liste de sous-traitants (Annexe 1) couvrant les entités traitant des données européennes. C’est la base d’un cadre conforme à l’article 28 du RGPD — un fournisseur incapable de nommer ses sous-traitants ne peut pas garantir sérieusement la conformité.

État actuel de la transparence sur les sous-traitants : La liste de l’Annexe 1 du DPA documente les sous-traitants actuels, mais un registre client en temps réel avec notification automatique des changements n’est pas encore publié. C’est un point reconnu. Pour les organisations ayant besoin d’une visibilité continue sur les changements de sous-traitants — comme le prévoit l’article 28 du RGPD via le droit d’opposition — il faut aborder ce sujet directement avec Kiteworks et prévoir une notification contractuelle.

Pour les équipes achats, la question à poser n’est pas seulement « Qui sont vos sous-traitants aujourd’hui ? » mais « Comment serez-vous notifiés en cas de changement, et quel délai avant l’activation d’un nouveau sous-traitant ? » L’article 28(2) du RGPD donne le droit de s’opposer, mais seulement si la notification arrive à temps pour l’exercer.

Souveraineté Juridictionnelle : Les Questions à Poser à Votre Fournisseur

Utilisez ce tableau lors des discussions achats, négociations DPA et évaluations de risques tierces. Les questions sont structurées pour faire émerger les distinctions importantes pour la conformité réglementaire dans l’UE.

Sujet Question à poser Réponse solide Réponse faible
Entité contractante Quelle entité juridique est la partie contractante pour les clients européens, et sous quel droit ? Entité UE ou pays adéquat (ex. entité suisse sous droit suisse) ; pas d’entité américaine Société mère américaine ; droit applicable : droit d’un État US
Résidence des données Pouvez-vous vous engager contractuellement à ce que les données européennes ne quittent jamais l’UE, quelles que soient les circonstances ? On-premises : contrôle client ; SaaS : engagement contractuel explicite sur les régions UE sans repli hors UE « Les données sont stockées dans l’UE » sans engagement contractuel ; régions de repli non divulguées
Exposition au CLOUD Act Une entité de votre groupe est-elle soumise au CLOUD Act américain, et quelles conséquences pour les données européennes ? Cartographie honnête de l’exposition ; structure suisse/UE limite la portée directe ; HYOK rend les données techniquement inaccessibles « Nous respectons la loi applicable » sans détail ; aucune reconnaissance de l’exposition
Accès gouvernemental Quelle est votre politique en cas d’injonction gouvernementale d’accès aux données ou de coupure de service ? Procédure de contestation documentée ; notification client si légalement permis ; HYOK : accès forcé ne donne que des données chiffrées Aucune politique publiée ; « nous respectons les décisions de justice » ; pas de HYOK ou équivalent
Transferts transfrontaliers Quel mécanisme encadre tout transfert de données européennes hors EEE, et quelles mesures complémentaires s’appliquent ? Cadre SCC dans le DPA ; TIA documentée ; HYOK reconnu par l’EDPB comme mesure complémentaire SCC sans TIA ; aucune mesure complémentaire ; périmètre de transfert non divulgué
Sous-traitants Pouvez-vous fournir une liste à jour des sous-traitants, leurs juridictions et un mécanisme de notification des changements ? Liste nominative ; juridiction divulguée ; notification préalable avec délai d’opposition Référence générique à des « prestataires tiers » ; pas de divulgation de juridiction ; pas de notification des changements

Due Diligence Juridictionnelle : Liste de Contrôle pour la Mise en Œuvre

Savoir à quoi ressemblent les bonnes réponses est une chose. Les vérifier systématiquement lors de l’achat — et maintenir cette vérification tout au long du contrat — en est une autre. La due diligence juridictionnelle comporte deux phases : le travail avant signature, puis le suivi continu. Les deux sont nécessaires ; la plupart des organisations excellent dans la première, moins dans la seconde.

Au Moment du Contrat

  • Vérifiez explicitement l’entité contractante. Ne présumez rien. Contrôlez le bloc de signature et la définition de « Kiteworks » dans votre contrat. Confirmez qu’il s’agit de l’entité UE ou suisse, pas d’une société mère américaine. Si votre contrat est antérieur à une restructuration, demandez une confirmation écrite de l’entité contractante actuelle.
  • Exigez une annexe ou une déclaration d’évaluation d’impact sur les transferts. Demandez au fournisseur son TIA standard, ou qu’il atteste dans le DPA qu’une TIA a été réalisée et que des mesures complémentaires sont en place. « Nous avons des SCC » ne suffit pas sans TIA pour les flux concernés.
  • Négociez la notification préalable des changements de sous-traitants. L’article 28 du RGPD vous donne le droit de vous opposer à de nouveaux sous-traitants. Ce droit n’est effectif que si vous êtes notifié à l’avance. Précisez le délai de notification dans le DPA — 30 jours est un bon point de départ.
  • Documentez l’architecture HYOK dans votre registre de risques. Si vous déployez HYOK, mentionnez-le explicitement dans votre TIA et votre DPIA comme mesure complémentaire reconnue par l’EDPB. Cela crée une traçabilité auditable du traitement du risque.

Suivi Continu

  • Examinez la liste des sous-traitants au moins une fois par an. Tout changement modifie votre profil de risque. Programmez un rappel calendaire aligné sur la fréquence de notification du fournisseur, et attribuez la revue à une personne de votre service juridique ou conformité.
  • Surveillez l’évolution du droit dans les juridictions du fournisseur. Le droit suisse et européen évolue. Les décisions d’adéquation peuvent être remises en cause (Schrems II en est l’exemple). Suivez les évolutions majeures dans les juridictions de vos fournisseurs.
  • Refaites une TIA en cas de changement de structure du fournisseur. Acquisition, fusion ou changement de société mère peuvent modifier l’exposition juridictionnelle. Prévoyez une clause contractuelle imposant la notification de tout changement de structure affectant l’entité contractante.

Coût Business, Financier et de Réputation d’une Erreur sur la Juridiction

Les échecs de souveraineté juridictionnelle diffèrent des incidents de sécurité classiques. Ils ne sont que rarement révélés par un incident — ils émergent lors d’un audit, d’une enquête réglementaire ou d’une procédure judiciaire, alors que la faille existe depuis longtemps. Les conséquences touchent la réglementation, l’opérationnel et la réputation, et elles s’additionnent.

Risque Réglementaire et Juridique

La conformité à l’article 46 du RGPD pour les transferts transfrontaliers est une obligation légale stricte, pas une simple bonne pratique. Transférer des données vers un pays tiers sans garantie adéquate — ou avec des SCC non appuyées par une TIA et des mesures complémentaires — expose directement à des sanctions réglementaires. Les autorités ont déjà infligé des amendes substantielles pour des mécanismes de transfert insuffisants, et la pression s’est accrue depuis Schrems II.

L’article 21 de NIS 2 impose des mesures de sécurité supply chain appropriées. Une relation fournisseur dont l’exposition juridictionnelle de la chaîne des sous-traitants n’est pas cartographiée constitue une faille supply chain — qu’une autorité de contrôle peut légitimement interroger lors d’un audit NIS 2. DORA impose des exigences similaires aux entités financières, avec des obligations de surveillance des tiers TIC incluant la compréhension du domicile juridique des opérations du fournisseur.

Risque Business et Opérationnel

Un ordre d’accès gouvernemental entraînant la divulgation de données client — ou une injonction de coupure de service mettant une plateforme hors ligne — peut avoir des conséquences opérationnelles catastrophiques pour les organisations dépendantes du partage de fichiers dans leurs processus réglementés. Contrats, données d’essais cliniques, documents de défense, dossiers financiers : ce sont précisément ces données qui intéressent les gouvernements disposant de larges pouvoirs de surveillance. Comprendre et maîtriser ce risque n’est pas une case à cocher pour la conformité — c’est un enjeu de continuité opérationnelle.

Risque de Réputation

Pour les organisations qui s’engagent sur la souveraineté auprès de leurs propres clients — banques garantissant que les données ne quittent pas l’UE, établissements de santé promettant la résidence des données patients, prestataires publics revendiquant la conformité à des référentiels de sécurité — une faille juridictionnelle dans la chaîne fournisseur peut rendre ces engagements caducs. Les dommages réputationnels d’un « nous ignorions que notre fournisseur de partage de fichiers avait une société mère américaine » ne se réparent pas par un communiqué de presse.

Pourquoi Choisir Kiteworks pour la Souveraineté Juridictionnelle

La position de Kiteworks sur la souveraineté juridictionnelle se distingue de la plupart des éditeurs américains par la combinaison de son entité contractante suisse, de son architecture HYOK et de la diversité de ses certifications indépendantes.

La structure suisse (Kiteworks Europe AG, Bahnhofstrasse 29, Zoug, Suisse) constitue une barrière contractuelle réelle contre la portée directe du CLOUD Act pour les clients européens — pas un bouclier absolu, mais une position nettement plus défendable que de contracter avec une entité américaine. HYOK transforme cette protection juridique en garantie technique : même en cas d’accès légal, les données restent inaccessibles sans la participation du client. Cette combinaison — entité suisse, HYOK et déploiement on-premises — représente aujourd’hui la posture de souveraineté juridictionnelle la plus solide sur le marché du partage de fichiers en entreprise.

Le portefeuille de conformité couvre plusieurs juridictions : BSI C5 Type 2 et ISO 27001 pour l’évaluation indépendante en Europe, Cyber Essentials Plus pour le marché UK, IRAP PROTECTED pour l’Australie, FedRAMP High In Process pour le marché fédéral US, et SOC 2 Type II comme attestation de référence. Pour les équipes achats menant des évaluations de risques tierces selon NIS 2 ou DORA, cette diversité d’attestations indépendantes allège la charge de preuve par rapport aux fournisseurs imposant des questionnaires de sécurité sans certification.

Les limites à connaître : la société mère est américaine ; le registre des sous-traitants est actuellement une annexe du DPA, pas un registre public en temps réel. Ce sont des sujets à aborder avec les équipes juridiques et contractuelles de Kiteworks avant signature.

Conclusion

Pour les organisations réglementées européennes, la souveraineté juridictionnelle dans le partage de fichiers n’est plus une affaire juridique à régler une fois lors de l’achat initial. C’est une discipline opérationnelle et de conformité continue — couvrant l’entité contractante, la résidence des données, l’exposition à l’accès gouvernemental, les mécanismes de transfert et la chaîne des sous-traitants — qui exige une gestion active tout au long de la relation fournisseur.

Kiteworks propose une base documentée et validée indépendamment pour cette discipline : entité contractante suisse, architecture HYOK reconnue comme mesure complémentaire Schrems II, DPA appuyé sur les SCC, et portefeuille de certifications multi-juridictionnelles couvrant les référentiels auxquels sont soumises les organisations réglementées EMEA.


Foire Aux Questions

1. En tant qu’institution financière européenne soumise à DORA, quelles informations juridictionnelles dois-je obtenir d’un fournisseur de partage de fichiers avant signature ?

DORA impose une évaluation des risques tiers TIC couvrant le domicile légal, la localisation des données et l’exposition à l’accès gouvernemental. Avant de signer, obtenez : le nom de l’entité contractante et sa juridiction d’incorporation ; une liste à jour des sous-traitants avec leurs juridictions ; le mécanisme de transfert transfrontalier (SCC ou décision d’adéquation) ; une TIA ou une attestation du fournisseur qu’elle existe ; et la procédure documentée de contestation d’accès gouvernemental et la politique de notification client du fournisseur.

2. Qu’est-ce que le chiffrement HYOK et comment répond-il aux exigences de mesure complémentaire Schrems II pour les transferts de données UE ?

HYOK (Hold Your Own Key) signifie que le client détient et gère les clés de chiffrement indépendamment du fournisseur. Les recommandations 01/2020 de l’EDPB sur les mesures complémentaires (Annexe 2, Cas d’usage 3) reconnaissent explicitement le chiffrement avec des clés inaccessibles à l’importateur comme garantie technique valable : si l’importateur ne peut pas déchiffrer les données, toute contrainte légale ne donne que des données chiffrées. Pour les organisations européennes utilisant Kiteworks avec HYOK, les données sont inaccessibles à Kiteworks et à toute autorité qui le contraindrait.

3. Même sans lien avec les États-Unis, serions-nous soumis au CLOUD Act si nous utilisons Kiteworks ? Comment l’architecture de chiffrement et de contrôle des données de Kiteworks répond-elle à cette problématique ?

Le CLOUD Act concerne toute entité américaine — mais pour les clients européens de Kiteworks, la question se pose à deux niveaux.

Premier niveau : l’entité contractante. Les clients européens contractent avec Kiteworks Europe AG (entité suisse), pas avec la société mère américaine. L’entité suisse n’est pas soumise à l’autorité d’un mandat américain. Les autorités US devraient passer par une procédure MLAT suisse, plus lente, plus transparente et plus contestable qu’un ordre CLOUD Act adressé à une entité US.

Second niveau — et le plus important pour la souveraineté : le CLOUD Act devient inopérant si le fournisseur ne peut pas fournir de données lisibles. Avec l’architecture HYOK de Kiteworks, le client détient et gère les clés de chiffrement sur sa propre infrastructure. Kiteworks ne possède pas ces clés. Même si un ordre CLOUD Act était exécuté et que Kiteworks s’y conformait, seules des données chiffrées seraient transmises — illisibles sans les clés du client, dont il garde la maîtrise. Cette séparation entre la détention des données et celle des clés fonde la souveraineté : la contrainte légale sur le fournisseur ne donne rien d’exploitable. L’EDPB reconnaît cette architecture comme mesure complémentaire valable dans Schrems II précisément pour cette raison.

Pour les déploiements on-premises avec HSM opéré par le client (SafeNet Luna de Thales, validé FIPS 140-3), la clé ne quitte jamais le matériel contrôlé par le client. Même une saisie physique de l’infrastructure Kiteworks ne donnerait que des données chiffrées.

4. Quelles informations Kiteworks doit-il fournir pour notre évaluation d’impact RGPD couvrant sa plateforme ?

Pour une TIA sur Kiteworks, demandez : la juridiction d’incorporation de Kiteworks Europe AG ; la liste des sous-traitants avec leur juridiction ; le DPA avec annexes SCC ; la documentation de HYOK comme mesure complémentaire reconnue par l’EDPB ; et la politique d’accès gouvernemental couvrant la procédure de contestation et la notification client. La structure suisse, le cadre SCC et l’architecture HYOK constituent ensemble la base de l’évaluation.

5. Comment le déploiement on-premises de Kiteworks se compare-t-il au SaaS pour la résidence des données et la souveraineté juridictionnelle ?

Le déploiement on-premises donne aux organisations européennes un contrôle total sur la résidence — l’appliance fonctionne sur une infrastructure contrôlée par le client, dans la juridiction de son choix, sans mouvement de données vers des systèmes opérés par le fournisseur. Le SaaS implique une infrastructure opérée par le fournisseur, nécessitant un engagement contractuel explicite sur les régions UE et la surveillance de la géographie des sous-traitants. Pour des exigences strictes de résidence ou de souveraineté, on-premises avec HYOK est la posture la plus solide. Le SaaS convient si les engagements contractuels sont explicites et régulièrement vérifiés.

Lancez-vous.

Il est facile de commencer à garantir la conformité réglementaire et à gérer efficacement les risques avec Kiteworks. Rejoignez les milliers d’organisations qui ont confiance dans la manière dont elles échangent des données privées entre personnes, machines et systèmes. Commencez dès aujourd’hui.

Table of Content
Partagez
Tweetez
Partagez
Explore Kiteworks