RGPD et cloud : obligations AWS, Azure, GCP

Migrer vers le cloud ne fait pas disparaître vos obligations RGPD — cela les redistribue. Quand votre entreprise confie ses données personnelles à AWS, Azure ou Google Cloud, elle reste responsable de traitement au sens de l’Art. 4(7) du RGPD. Le fournisseur cloud, lui, agit comme sous-traitant. Cette répartition a des conséquences juridiques très concrètes que beaucoup de DSI et DPO sous-estiment.

Le modèle de responsabilité partagée : ce que dit le RGPD

Les trois hyperscalers (AWS, Azure, GCP) reposent sur un modèle dit de « responsabilité partagée » (shared responsibility model). Le fournisseur sécurise l’infrastructure physique, le réseau et la couche de virtualisation. Le client, lui, reste responsable de la configuration, du chiffrement, de la gestion des accès et — surtout — de la conformité juridique des traitements.

En droit, cette répartition correspond précisément à la relation responsable de traitement / sous-traitant définie par le RGPD. L’Art. 24 impose au responsable de traitement de mettre en œuvre des mesures techniques et organisationnelles appropriées « compte tenu de la nature, de la portée, du contexte et des finalités du traitement ». Utiliser un cloud public ne vous exonère d’aucune de ces obligations.

La CNIL l’a rappelé dans ses recommandations sur le cloud computing : « le recours à des prestations de cloud computing peut engendrer des risques pour la protection des données personnelles » et le responsable de traitement doit « procéder à une analyse de risques » avant toute migration.

Ce que cela signifie en pratique

Concrètement, quand vous hébergez des données personnelles sur AWS, Azure ou GCP, vous devez :

• Qualifier juridiquement chaque service cloud utilisé (IaaS, PaaS, SaaS) et identifier les traitements de données personnelles associés
• Vérifier le contrat sous-traitant (Data Processing Agreement) proposé par le fournisseur
• Évaluer les transferts de données vers des pays tiers
• Configurer la sécurité conformément à l’Art. 32 du RGPD
• Documenter ces choix dans votre registre des traitements

Le contrat sous-traitant (DPA) : Art. 28 en pratique

L’Art. 28 du RGPD impose un contrat écrit entre le responsable de traitement et son sous-traitant. Les trois hyperscalers proposent chacun un Data Processing Addendum (DPA) qui couvre les exigences de l’article 28 :

• AWS : le « AWS GDPR Data Processing Addendum » est intégré aux AWS Service Terms depuis 2018. Il inclut les clauses contractuelles types (CCT) de la Commission européenne pour les transferts hors UE.
• Azure / Microsoft : le « Microsoft Products and Services Data Protection Addendum » (DPA) couvre l’ensemble des services Microsoft 365 et Azure, avec les CCT et des engagements de transparence.
• GCP / Google : le « Cloud Data Processing Addendum » (CDPA) s’applique automatiquement aux services Google Cloud Platform et inclut les CCT.

Les points de vigilance

Ayant conseillé des entreprises de toutes tailles sur ces sujets depuis plus de 15 ans, je constate que les DPA des hyperscalers couvrent le minimum légal, mais laissent plusieurs zones grises :

Sous-traitants ultérieurs. L’Art. 28(2) exige une autorisation préalable pour tout sous-traitant ultérieur. Les trois fournisseurs utilisent un mécanisme d’autorisation générale avec notification des changements. Vérifiez que vous avez bien activé les notifications et documentez votre processus d’opposition.

Accès aux données par le fournisseur. Les DPA prévoient un accès limité du personnel du fournisseur aux données client, mais les conditions exactes varient. Lisez attentivement les sections « Access to Customer Data » ou « Personnel Data Protection ».

Audit. L’Art. 28(3)(h) vous donne un droit d’audit. En pratique, aucun hyperscaler ne vous laissera auditer ses datacenters physiquement. Ils proposent à la place des certifications (ISO 27001, SOC 2, C5) et des rapports d’audit tiers. C’est une pratique acceptée par l’EDPB, à condition que vous documentiez votre évaluation de ces rapports.

Transferts de données hors UE : le point critique

C’est le sujet le plus sensible juridiquement. AWS, Azure et GCP sont des entreprises américaines. Même si vous choisissez une région européenne (eu-west-1, France Central, europe-west1), certains traitements annexes (support technique, maintenance, détection de menaces) peuvent impliquer un accès depuis les États-Unis.

Depuis l’invalidation du Privacy Shield par l’arrêt Schrems II (CJUE, 16 juillet 2020), les transferts de données hors UE reposent principalement sur :

• Le Data Privacy Framework (DPF) UE-États-Unis, adopté par la Commission européenne le 10 juillet 2023 (décision d’adéquation). AWS, Microsoft et Google sont tous certifiés DPF.
• Les clauses contractuelles types (CCT) de la Commission européenne (décision 2021/914), intégrées dans les DPA des trois fournisseurs comme mécanisme subsidiaire.
• Des mesures supplémentaires (chiffrement côté client, pseudonymisation) recommandées par l’EDPB dans ses Recommandations 01/2020.

Évaluation du risque de transfert (TIA)

Même avec le DPF en place, il est recommandé de documenter une Transfer Impact Assessment (TIA) pour chaque service cloud utilisé. Cette analyse doit évaluer :

• La législation du pays de destination en matière de surveillance (section 702 du FISA, Executive Order 12333 pour les États-Unis)
• Les garanties apportées par le DPF (mécanisme de recours devant la Data Protection Review Court)
• Les mesures techniques supplémentaires mises en œuvre (chiffrement, clés gérées par le client)

La CNIL n’a pas encore invalidé le DPF, mais la Cour de justice de l’UE pourrait être saisie à nouveau. Documentez vos choix pour pouvoir réagir rapidement en cas de nouvelle invalidation.

Sécurité des données : configurer le cloud conformément à l’Art. 32

L’Art. 32 du RGPD exige des mesures de sécurité « appropriées » au risque. En environnement cloud, cela passe par des choix de configuration que le fournisseur met à disposition mais que vous devez activer.

Chiffrement

Les trois hyperscalers proposent du chiffrement au repos et en transit par défaut. Mais le chiffrement par défaut utilise des clés gérées par le fournisseur. Pour les données sensibles ou à risque élevé, privilégiez :

• Customer Managed Keys (CMK) : vous contrôlez la clé de chiffrement via AWS KMS, Azure Key Vault ou Google Cloud KMS
• Client-Side Encryption : les données sont chiffrées avant d’atteindre le cloud, ce qui constitue une mesure supplémentaire au sens des recommandations EDPB

Gestion des accès

Appliquez le principe du moindre privilège (Art. 25, privacy by design) :

• Activez l’authentification multifacteur (MFA) sur tous les comptes d’administration
• Utilisez les rôles IAM avec des permissions granulaires
• Mettez en place une journalisation des accès (CloudTrail, Azure Monitor, Cloud Audit Logs)
• Révisez les permissions trimestriellement

Localisation des données

Choisir une région européenne est un premier réflexe, mais ne suffit pas. Vérifiez que :

• Les sauvegardes restent dans la même région ou dans une autre région UE
• Les services managés (IA, analytics, CDN) ne répliquent pas les données hors UE
• Les logs de diagnostic ne sont pas centralisés dans un datacenter américain

La CNIL recommande de configurer les data residency controls disponibles chez chaque fournisseur : AWS Organizations SCP, Azure Policy, GCP Organization Policy Constraints.

Analyse d’impact (AIPD) : quand est-elle nécessaire ?

L’Art. 35 du RGPD impose une analyse d’impact lorsqu’un traitement est « susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques ». La CNIL a publié une liste de traitements pour lesquels l’AIPD est obligatoire (délibération n° 2018-327 du 11 octobre 2018).

En matière de cloud, une AIPD est recommandée quand :

• Vous migrez vers le cloud des données de santé, des données sensibles au sens de l’Art. 9, ou des données à grande échelle
• Vous utilisez des services d’intelligence artificielle cloud (reconnaissance faciale, scoring, profilage)
• Le traitement combine plusieurs sources de données personnelles dans le cloud
• Les données sont transférées vers un pays tiers sans décision d’adéquation

L’AIPD doit évaluer spécifiquement les risques liés au cloud : perte de contrôle sur les données, risque d’accès non autorisé par le fournisseur ou des autorités étrangères, et risque de verrouillage technique (vendor lock-in).

Registre des traitements : documenter vos services cloud

Chaque service cloud impliquant des données personnelles doit figurer dans votre registre des traitements au titre de l’Art. 30. Pour chaque entrée, documentez :

• Le service cloud utilisé (nom exact, région, type IaaS/PaaS/SaaS)
• Les catégories de données personnelles hébergées
• Les finalités du traitement
• Le fondement juridique (base légale)
• La référence au DPA du fournisseur
• Les mesures de sécurité configurées
• Le mécanisme de transfert hors UE applicable

C’est le type de documentation que des outils comme Legiscope permettent d’automatiser — la cartographie des sous-traitants cloud et la génération des fiches de traitement associées représentent un travail considérable quand on le fait manuellement.

Notification de violation : qui fait quoi ?

En cas de violation de données impliquant un service cloud, l’Art. 33 impose une notification à la CNIL dans les 72 heures. Mais la détection de l’incident peut dépendre du fournisseur cloud.

Les DPA des trois hyperscalers prévoient une obligation de notification « dans les meilleurs délais » (without undue delay) :

• AWS : notification dans les 72 heures suivant la découverte
• Azure : notification dans les 72 heures
• GCP : notification « promptement et sans retard injustifié »

Le point critique est que le délai de 72 heures pour notifier la CNIL court à partir du moment où vous (le responsable de traitement) prenez connaissance de la violation — pas à partir de la notification du fournisseur. Il est donc essentiel de :

• Configurer les alertes de sécurité du fournisseur cloud
• Définir un processus interne de réponse aux incidents
• Tester ce processus régulièrement (au moins une fois par an)

Comparaison : AWS, Azure et GCP face au RGPD

Critère	AWS	Azure	GCP
DPA disponible	Oui (Service Terms)	Oui (DPA Microsoft)	Oui (CDPA)
Certifié DPF	Oui	Oui	Oui
CCT intégrées	Oui (2021/914)	Oui (2021/914)	Oui (2021/914)
Régions UE (France)	eu-west-3 (Paris)	France Central (Paris)	europe-west9 (Paris)
Chiffrement CMK	AWS KMS	Azure Key Vault	Cloud KMS
ISO 27001	Oui	Oui	Oui
SOC 2 Type II	Oui	Oui	Oui
SecNumCloud	Non (en cours via partenaires)	Non (via Bleu avec Orange/Capgemini)	Non (via S3NS avec Thales)
Résidence données UE	Configurable	Configurable (EU Data Boundary)	Configurable (Assured Workloads)
Code de conduite CISPE	Oui	Non	Non

Les trois fournisseurs offrent un niveau de conformité comparable pour les obligations RGPD de base. Les différences se jouent sur les certifications souveraines (SecNumCloud) et les outils de gouvernance des données.

Ce qu’il faut retenir

• Le cloud ne transfère pas vos obligations RGPD : vous restez responsable de traitement, le fournisseur est sous-traitant au sens de l’Art. 28.
• Vérifiez et documentez le DPA de chaque fournisseur cloud, en portant une attention particulière aux sous-traitants ultérieurs et aux droits d’audit.
• Les transferts vers les États-Unis sont couverts par le Data Privacy Framework, mais documentez une TIA et préparez un plan B en cas d’invalidation.
• La sécurité est votre responsabilité : activez le chiffrement CMK, le MFA, la journalisation et les contrôles de résidence des données.
• Documentez tout dans votre registre des traitements : services utilisés, régions, DPA, mesures de sécurité, mécanismes de transfert.

FAQ

Peut-on utiliser AWS, Azure ou GCP en conformité avec le RGPD ?

Oui, les trois hyperscalers proposent des Data Processing Agreements conformes à l’Art. 28, sont certifiés sous le Data Privacy Framework pour les transferts UE-US, et intègrent les clauses contractuelles types. La conformité dépend surtout de votre configuration : choix de la région, chiffrement, gestion des accès et documentation.

Le Data Privacy Framework suffit-il pour les transferts vers les États-Unis ?

Le DPF constitue actuellement une base légale valide pour les transferts vers les entreprises américaines certifiées (AWS, Microsoft, Google le sont). Cependant, sa pérennité n’est pas garantie (comme l’ont montré les invalidations du Safe Harbor et du Privacy Shield). Il est recommandé de documenter une Transfer Impact Assessment et de prévoir des mesures supplémentaires comme le chiffrement côté client.

Faut-il réaliser une AIPD avant de migrer vers le cloud ?

Une AIPD est obligatoire si la migration concerne des données sensibles (Art. 9), des traitements à grande échelle, ou des transferts vers un pays tiers sans décision d’adéquation. Même hors de ces cas, la CNIL recommande de réaliser une analyse de risques documentée avant toute migration vers le cloud.

Quelle différence entre chiffrement par défaut et chiffrement CMK ?

Le chiffrement par défaut protège vos données au repos avec des clés gérées par le fournisseur cloud — le fournisseur peut techniquement accéder aux données. Avec le chiffrement CMK (Customer Managed Keys), vous contrôlez les clés via AWS KMS, Azure Key Vault ou Cloud KMS, ce qui empêche le fournisseur d’accéder aux données en clair. Pour les données sensibles, le chiffrement CMK est la mesure technique recommandée par l’EDPB.