Comment les clauses contractuelles types répondent-elles aux enjeux de souveraineté des données — et quelles sont leurs limites ?
Les clauses contractuelles types (CCT) constituent le mécanisme le plus utilisé pour transférer des données personnelles de l’UE vers des pays tiers. Depuis l’arrêt Schrems II, elles sont aussi largement mal comprises : on les considère à tort comme une solution de souveraineté, alors qu’elles n’en sont qu’un point de départ. Les CCT répondent à l’exigence documentaire du RGPD en matière de transfert. Elles ne peuvent pas — et légalement ne pourront jamais — prévaloir sur les lois de surveillance des pays de destination.
Comprendre précisément où les CCT fonctionnent et où elles échouent constitue la base de tout programme sérieux de souveraineté des données à l’international.
Résumé Exécutif
Idée principale : Les clauses contractuelles types instaurent des obligations contractuelles contraignantes entre exportateurs et importateurs de données pour les transferts transfrontaliers de données personnelles selon le chapitre V du RGPD. Depuis Schrems II, il faut compléter les CCT par des évaluations d’impact sur les transferts (TIA) qui déterminent si la législation du pays de destination compromet leur efficacité — et, en cas de risque avéré, par des mesures techniques complémentaires. Pour les transferts vers des infrastructures contrôlées par les États-Unis, l’EDPB recommande en priorité le chiffrement contrôlé par le client, avec des clés conservées hors de l’infrastructure du fournisseur. Sans cette architecture, les CCT ne sont qu’une documentation juridique sans réelle protection.
Pourquoi c’est important : Les autorités autrichienne, française et italienne de protection des données ont rendu des décisions de sanction contre certains fournisseurs cloud américains pour violation du RGPD — précisément parce que les CCT n’étaient pas complétées par des mesures techniques adéquates. Les amendes peuvent atteindre 4 % du chiffre d’affaires mondial. Un programme CCT non revu à l’aune des exigences post-Schrems II n’est pas une posture de conformité — c’est une exposition documentée.
Résumé des points clés
- Les CCT sont un instrument juridique, pas un contrôle technique. Elles lient les parties entre elles. Elles ne lient pas les gouvernements étrangers, ne suppriment pas les lois de surveillance, et n’empêchent pas la divulgation forcée. Elles protègent contre l’utilisation abusive volontaire par l’importateur — pas contre l’accès imposé par un gouvernement auquel l’importateur ne peut légalement s’opposer.
- Schrems II a fondamentalement changé les exigences liées aux CCT. L’arrêt de la CJUE en 2020 impose que les CCT pour les transferts vers les États-Unis soient complétées par des TIA et, en cas de risque avéré lié au CLOUD Act ou à la FISA 702, par des mesures techniques complémentaires. Les CCT seules ne suffisent plus pour les transferts vers des fournisseurs américains.
- L’EDPB impose le chiffrement contrôlé par le client comme mesure complémentaire requise. Les recommandations 01/2020 préconisent le chiffrement avec des clés détenues exclusivement hors du pays de destination — hors de l’infrastructure du fournisseur — comme mesure technique capable de contrer l’accès gouvernemental imposé. Les mesures contractuelles complémentaires (engagements de notification, procédures de contestation) sont explicitement insuffisantes.
- Les CCT ne couvrent pas les données non personnelles, les risques en transit, l’exposition à la supply chain ou les failles DLP. Leur champ d’application se limite aux données personnelles au sens du RGPD. La souveraineté des données à l’international exige un cadre de contrôle plus large, incluant les données non personnelles (EU Data Act), l’interception en transit et la chaîne des sous-traitants.
- Un programme CCT statique expose à des sanctions actives. Le principe de responsabilité du RGPD impose une revue continue. Les TIA réalisées avant Schrems II, avant les décisions des autorités autrichienne/française/italienne, ou avant les contestations juridiques du Data Privacy Framework UE-États-Unis, sont probablement insuffisantes selon les standards actuels.
Ce que font — et ne font pas — les CCT
Les clauses contractuelles types sont des modèles contractuels approuvés par la Commission européenne, servant de base légale pour transférer des données personnelles de l’UE hors EEE selon l’article 46 du RGPD. Elles imposent à l’importateur des obligations précises : traiter les données uniquement pour les finalités prévues, mettre en œuvre des mesures de sécurité appropriées, notifier l’exportateur en cas de demande d’accès gouvernemental lorsque c’est autorisé, et contester les demandes jugées illégales. Les CCT actuelles ont été mises à jour en 2021 pour tenir compte du contexte post-Schrems II.
Ce que les CCT ne font pas est tout aussi crucial. Elles ne modifient pas les obligations légales des entreprises américaines au titre du CLOUD Act ou de la section 702 de la FISA. Un fournisseur américain, même doté des meilleures CCT, doit toujours répondre à une demande valide fondée sur le CLOUD Act. Les CCT obligent le fournisseur à contester les demandes excessives ; elles ne peuvent pas l’obliger à refuser une injonction légale émanant de son propre gouvernement. Ce n’est pas un défaut de rédaction — c’est une limite structurelle des contrats en tant qu’outils de protection des données. Les contrats lient les parties entre elles, pas les gouvernements souverains. La CJUE l’a confirmé dans Schrems II : si la législation du pays de destination permet un accès gouvernemental incompatible avec les droits fondamentaux de l’UE, les seules CCT sont insuffisantes.
Liste de contrôle RGPD Conformité
Pour en savoir plus :
L’exigence Schrems II : les évaluations d’impact sur les transferts
Depuis Schrems II, les organisations qui s’appuient sur les CCT pour des transferts vers les États-Unis doivent réaliser des évaluations d’impact sur les transferts (TIA) — une analyse documentée visant à déterminer si la législation américaine compromet l’efficacité des CCT pour le transfert concerné. Une TIA n’est pas une formalité. Elle doit traiter honnêtement le CLOUD Act et la FISA 702 comme des bases légales actives permettant la divulgation de données sans contrôle judiciaire européen — et conclure sur l’adéquation des mesures techniques complémentaires face au risque identifié.
Une TIA qui reconnaît l’exposition au CLOUD Act mais conclut que les engagements de notification et les procédures de contestation suffisent ne répond pas aux exigences post-Schrems II. L’EDPB distingue les mesures contractuelles complémentaires — qui modifient les engagements du fournisseur — et les mesures techniques complémentaires — qui modifient ce que le fournisseur est techniquement capable de faire. Pour les transferts exposés au CLOUD Act, seules les mesures techniques sont adéquates. Un fournisseur qui peut être contraint de fournir des données en clair n’offre pas une protection suffisante, quels que soient ses engagements. C’est précisément ce sur quoi les décisions nationales d’application des autorités de protection des données se sont appuyées.
La mesure technique requise par l’EDPB : le chiffrement contrôlé par le client
Les recommandations 01/2020 de l’EDPB identifient une mesure technique complémentaire adaptée à l’exposition au CLOUD Act : le chiffrement dont le fournisseur américain n’a jamais accès aux clés. Les clés doivent être générées par le client européen, stockées dans une infrastructure hors du contrôle du fournisseur, et ne jamais lui être transmises. Dans cette architecture, une demande fondée sur le CLOUD Act ne permet d’obtenir que des données chiffrées — le fournisseur est techniquement incapable de fournir des données en clair, quelle que soit la contrainte légale. Cela permet de satisfaire à la fois à l’obligation de divulgation du CLOUD Act et à l’exigence de protection du RGPD.
Le chiffrement géré par le client (BYOK/BYOE), avec des clés stockées dans des modules matériels de sécurité sous le contrôle exclusif du client européen, constitue la mise en œuvre concrète. Les organisations incapables de présenter une architecture de gestion des clés démontrant que le fournisseur américain ne détient aucune capacité de déchiffrement ne respectent pas la norme Schrems II en matière de mesures techniques complémentaires — quelle que soit la complétude des CCT. La même logique s’applique aux contrôles de localisation des données : les engagements contractuels de localisation doivent être appuyés par un géorepérage au niveau de l’infrastructure — une mesure technique complémentaire — et non par de simples déclarations contractuelles qui pourraient être contournées administrativement.
Les limites des CCT
Même un programme CCT pleinement conforme ne couvre qu’une partie des enjeux de souveraineté des données à l’international. Trois limites subsistent, quelle que soit la complétude des CCT.
Données non personnelles. Les CCT couvrent uniquement les données personnelles au sens du RGPD. Les données non personnelles relèvent du chapitre VII de l’EU Data Act, qui impose aux fournisseurs cloud de mettre en place des mesures techniques empêchant l’accès illégal de gouvernements non européens. Un programme CCT conforme au RGPD laisse totalement de côté la question des données non personnelles du point de vue de la souveraineté.
Exposition à la supply chain. Les CCT régissent la relation directe exportateur-importateur. Si un fournisseur américain recourt à des sous-traitants dans d’autres juridictions, chacun crée un vecteur d’accès gouvernemental distinct. Une gestion efficace des risques liés aux tiers impose de cartographier et d’évaluer l’ensemble de la chaîne des sous-traitants de façon indépendante.
Obligations sectorielles. Les exigences DORA en matière de risques liés aux tiers TIC et le mandat de sécurité de la supply chain de la directive NIS 2 imposent des obligations de souveraineté allant au-delà de la conformité RGPD sur les transferts. Les CCT couvrent la dimension RGPD ; elles ne couvrent pas les exigences sectorielles.
Comment Kiteworks contribue à la conformité CCT — et va plus loin
Kiteworks fournit les contrôles d’architecture qui rendent les programmes CCT réellement protecteurs, et pas seulement conformes sur le papier. Le Réseau de données privé Kiteworks met en œuvre un chiffrement géré par le client (BYOK/BYOE) avec chiffrement validé FIPS 140-3 niveau 1 et AES-256 au repos — les clés étant détenues exclusivement par le client européen, sans aucun accès pour Kiteworks.
Une demande fondée sur le CLOUD Act adressée à Kiteworks ne permet d’obtenir que des données chiffrées. La conclusion de la TIA devient défendable non pas grâce aux engagements de Kiteworks, mais parce que Kiteworks est techniquement incapable d’agir autrement. Le déploiement à locataire unique dans le lieu européen choisi par le client garantit la résidence des données au niveau de l’infrastructure, et non du contrat.
Des contrôles de sécurité Zero trust régissent tous les accès, chaque événement étant enregistré dans des journaux d’audit immuables via le tableau de bord RSSI. Un reporting préconfiguré pour le RGPD, NIS 2, DORA et ISO 27001 maintient la documentation des transferts à jour pour tous les cadres applicables. Messagerie électronique, partage de fichiers, MFT, formulaires web et API sont gérés sur une seule plateforme avec des contrôles homogènes — ce qui élimine les failles de fragmentation propres aux environnements multi-plateformes.
Pour découvrir comment Kiteworks contribue à la conformité de votre programme CCT et comble les lacunes architecturales auxquelles il ne peut répondre seul, réservez votre démo sans attendre !
Foire aux questions
Les clauses contractuelles types sont des modèles contractuels approuvés par la Commission européenne, servant de base légale pour transférer des données personnelles de l’UE vers des pays tiers selon l’article 46 du RGPD. Elles lient les importateurs à des obligations portant sur la limitation des finalités, les mesures de sécurité, la coopération sur les droits des personnes concernées, la notification d’accès gouvernemental et les procédures de contestation des demandes illicites. Les CCT actuelles, mises à jour en 2021, intègrent l’exigence post-Schrems II de mesures complémentaires. Depuis Schrems II, les CCT pour les transferts vers les États-Unis doivent être accompagnées d’évaluations d’impact sur les transferts et — en cas de risque lié au CLOUD Act ou à la FISA 702 — de mesures techniques complémentaires.
L’arrêt Schrems II de la CJUE (juillet 2020) a établi que les CCT ne peuvent être utilisées que si la législation du pays de destination ne compromet pas leur efficacité pour le transfert concerné. Pour les transferts vers les États-Unis, les organisations doivent réaliser des TIA traitant honnêtement le CLOUD Act et la FISA 702 comme des risques réels de divulgation — et mettre en œuvre des mesures techniques complémentaires le cas échéant. Les recommandations 01/2020 de l’EDPB précisent que les mesures contractuelles complémentaires sont insuffisantes lorsque la loi américaine impose au fournisseur de se conformer, quels que soient les termes du contrat. Les programmes CCT antérieurs à Schrems II et non revus exposent à des sanctions actives.
Une mesure complémentaire contractuelle modifie ce que l’importateur de données s’engage à faire — par exemple, s’engager à contester les demandes d’accès gouvernemental ou à notifier l’exportateur en cas de demande. Une mesure complémentaire technique modifie ce que l’importateur est techniquement capable de faire. Le chiffrement contrôlé par le client, avec des clés hors de l’infrastructure du fournisseur, est une mesure technique complémentaire : le fournisseur ne peut fournir de données en clair, quelle que soit la demande légale reçue, car il ne possède jamais les clés de déchiffrement. L’EDPB exige des mesures techniques complémentaires pour les transferts exposés au CLOUD Act, car les mesures contractuelles ne peuvent pas prévaloir sur une contrainte légale américaine — ce que le fournisseur promet de ne pas faire ne change pas ce que la loi américaine lui impose de faire.
Non. Les clauses contractuelles types (CCT) sont un instrument du RGPD couvrant les données personnelles. Les données non personnelles transférées à l’international relèvent d’autres cadres : le chapitre VII de l’EU Data Act impose aux fournisseurs cloud de mettre en place des mesures techniques empêchant l’accès illégal de gouvernements non européens aux données non personnelles stockées dans l’UE ; des réglementations sectorielles ajoutent des exigences pour les données financières, de santé ou gouvernementales. Un programme CCT conforme au RGPD pour les transferts de données personnelles peut laisser les données non personnelles d’une organisation totalement sans protection du point de vue de la souveraineté — d’où la nécessité d’aller au-delà de la conformité RGPD pour une souveraineté internationale complète.
Une revue de conformité Schrems II doit porter sur quatre éléments : les TIA existantes traitent-elles honnêtement le CLOUD Act et la FISA 702 comme des risques réels (et non de simples préoccupations théoriques) ; ces TIA documentent-elles des mesures techniques complémentaires adéquates (chiffrement contrôlé par le client avec une architecture de gestion des clés documentée, et non de simples engagements contractuels) ; les contrôles de résidence des données sont-ils techniquement appliqués plutôt que contractuellement déclarés (géorepérage au niveau de l’infrastructure, et non engagements de politique) ; et les journaux d’audit immuables assurent-ils la documentation continue exigée par le principe de responsabilité du RGPD. Les organisations utilisant Kiteworks peuvent générer des packages de documentation de conformité préétablis — preuves d’architecture, registres de gestion des clés et exports de journaux d’audit — pour chaque élément de cette revue, couvrant le RGPD, NIS 2, DORA et les exigences nationales des autorités de protection des données.
Ressources complémentaires
- Article de blog
Souveraineté des données : bonne pratique ou exigence 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 de souveraineté des données - Article de blog
Souveraineté des données et RGPD [Comprendre la sécurité des données]