AWS et RGPD 2026 : checklist et 6 points de conformité

L’essentiel. AWS fournit l’un des cadres contractuels les plus complets du marché cloud : un DPA aligné sur l’article 28 du RGPD, des régions européennes, des certifications multiples et des outils de chiffrement et de journalisation. Mais la conformité de votre projet ne dépend pas d’AWS seul : le modèle de responsabilité partagée signifie qu’AWS sécurise « le cloud » et que vous sécurisez « ce qui est dans le cloud ». Un bucket S3 public ou un chiffrement absent vous placent en manquement, quelle que soit la qualité de l’infrastructure. Ce guide décompose les engagements documentés d’AWS et vous donne une checklist de configuration en 6 points.

Amazon Web Services (AWS) est le leader mondial du cloud computing et l’infrastructure de référence d’une majorité de start-up et d’un nombre croissant d’entreprises françaises. Choisir AWS, c’est confier à Amazon l’infrastructure sur laquelle tournent vos applications, vos bases de données et, par conséquent, les données personnelles de vos utilisateurs. La question de la conformité RGPD est donc structurante.

La réponse n’est ni un « oui » ni un « non ». Elle tient dans le partage des responsabilités : AWS documente un socle contractuel et technique solide, et votre configuration détermine le reste. Ce guide analyse ce socle sous l’angle juridique et opérationnel, puis vous donne les mesures concrètes à mettre en place.

Qualification juridique : le modèle de responsabilité partagée

AWS, sous-traitant au sens de l’article 28

Pour les services d’infrastructure (IaaS) et de plateforme (PaaS) — EC2, S3, RDS, Lambda — AWS agit en qualité de sous-traitant au sens de l’article 28 du RGPD. Vous êtes le responsable de traitement : vous décidez quelles données sont stockées, comment elles sont traitées et dans quelle finalité.

AWS ne détermine pas les finalités de vos traitements. AWS ne décide pas quelles données vous placez dans un bucket S3 ou une base RDS. AWS met à disposition une infrastructure que vous configurez et utilisez selon vos besoins : c’est la définition même de la sous-traitance RGPD.

Le partage des responsabilités

Le Shared Responsibility Model est le concept central pour comprendre la conformité sur AWS.

AWS est responsable de la sécurité DU cloud	Vous êtes responsable de la sécurité DANS le cloud
Sécurité physique des datacenters	Configuration des groupes de sécurité et ACL réseau
Sécurité de l’infrastructure et de l’hyperviseur	Chiffrement des données (au repos et en transit)
Maintenance des composants d’infrastructure	Gestion des identités et des accès (IAM)
Disponibilité et résilience de la plateforme	Mise à jour de vos OS et applications
—	Sauvegardes, journalisation, choix de la région

Ce partage a une conséquence juridique directe : en cas de violation causée par une mauvaise configuration de votre côté (bucket S3 public, par exemple), la responsabilité au titre de l’article 32 du RGPD vous incombe, et vous devrez le cas échéant procéder à la notification de la violation à la CNIL. L’inverse vaut si la faille provient de l’infrastructure AWS.

Quand AWS agit comme responsable de traitement

Pour certains traitements liés à la gestion de votre compte (facturation, support, communication commerciale), AWS agit comme responsable de traitement. De même, certains services managés peuvent impliquer des décisions d’AWS sur les finalités. Le DPA d’AWS couvre, selon sa documentation, ces différentes situations.

Le DPA d’AWS au crible de l’article 28

Le AWS Data Processing Addendum (DPA) est le contrat de sous-traitance. Il est intégré aux conditions d’utilisation (AWS Customer Agreement). Le tableau ci-dessous confronte les exigences de l’article 28(3) aux dispositions documentées par AWS. Analyse fondée sur la documentation AWS (DPA et pages de conformité) consultée en juillet 2026 ; il ne s’agit pas d’un audit ni d’un constat de conformité, mais d’une lecture des engagements contractuels publiés.

Exigence de l’art. 28(3)	Ce que prévoit le DPA AWS (documentation juillet 2026)
Instructions documentées (a)	Traitement des données conformément aux instructions du client définies au contrat et par la configuration des services
Confidentialité du personnel (b)	Engagement de confidentialité du personnel AWS
Mesures de sécurité ©	Programme de sécurité documenté, certifications multiples (ISO 27001, SOC 2, C5, HDS)
Sous-traitance ultérieure (d)	Liste des sous-traitants ultérieurs publiée, mécanisme de notification préalable
Assistance aux droits (e)	Outils techniques permettant au client de répondre aux demandes d’accès, de suppression, de portabilité
Assistance sécurité et AIPD (f)	Coopération pour les analyses d’impact et les notifications de violation
Suppression ou restitution (g)	Suppression des données par le client à tout moment ; suppression confirmée en fin de contrat
Audits et inspections (h)	Rapports mis à disposition via AWS Artifact (SOC 2, ISO 27001, PCI-DSS, C5…) ; programme d’audit sur site

Le DPA d’AWS figure parmi les plus détaillés du marché cloud. AWS Artifact permet de télécharger en libre-service les rapports d’audit et de certification, ce qui facilite l’alimentation de votre propre documentation de conformité — un atout par rapport aux fournisseurs qui exigent une demande formelle pour chaque rapport. Reste que la signature et la bonne compréhension du DPA relèvent de votre responsabilité : un DPA parfait mal articulé avec votre registre des traitements ne vous protège pas.

Transferts internationaux et CLOUD Act

Le choix de la région : votre principal levier

Avec AWS, la localisation des données est sous votre contrôle. AWS propose plusieurs régions dans l’Espace économique européen (EEE) :

• eu-west-3 (Paris) — la région de référence pour les clients français
• eu-central-1 (Francfort), eu-west-1 (Irlande), eu-south-1 (Milan), eu-north-1 (Stockholm), eu-south-2 (Espagne)

Si vous sélectionnez la région Paris et ne configurez aucune réplication vers une région hors EEE, vos données restent en France pour le stockage et le traitement. C’est la configuration la plus simple du point de vue du régime des transferts hors UE.

Quand y a-t-il transfert hors UE ?

• Choix d’une région hors EEE (us-east-1, ap-northeast-1…) pour le stockage ou le traitement ;
• Réplication inter-régions vers une région hors EEE (S3 Cross-Region Replication pour la reprise après sinistre) ;
• Services edge : CloudFront (CDN) distribue le contenu sur des points de présence dans le monde entier ; Lambda@Edge exécute du code sur ces mêmes emplacements ;
• Support technique : les ingénieurs AWS peuvent accéder à vos ressources depuis des localisations hors EEE, sauf activation de l’option de support limité à l’UE.

Les mécanismes de transfert et l’affaire Latombe

Pour les transferts vers les États-Unis, AWS s’appuie, selon sa documentation consultée en juillet 2026, sur :

1. L’EU-US Data Privacy Framework (DPF) : les entités Amazon concernées figurent sur la liste des organisations certifiées DPF. Point d’actualité important : le DPF a été contesté devant le juge européen (recours Latombe). Le Tribunal de l’Union européenne a rejeté ce recours le 3 septembre 2025 et confirmé la décision d’adéquation. Un pourvoi est pendant devant la Cour de justice de l’Union européenne en 2026. Le DPF reste donc en vigueur en juillet 2026, mais son avenir n’est pas définitivement sécurisé — d’où l’intérêt de ne pas fonder votre conformité sur ce seul mécanisme.
2. Les clauses contractuelles types (CCT) de la Commission (décision d’exécution 2021/914) : intégrées au DPA comme mécanisme subsidiaire, elles continuent de s’appliquer si l’adéquation venait à être remise en cause.
3. Les mesures supplémentaires : chiffrement (AWS KMS, CloudHSM), contrôle granulaire des accès (IAM), journalisation exhaustive (CloudTrail).

Le CLOUD Act : le point de tension

AWS est une filiale d’Amazon, entreprise américaine soumise au CLOUD Act. Cette loi permet aux autorités américaines de demander l’accès à des données détenues par des entreprises américaines, y compris stockées hors des États-Unis — y compris, donc, sur la région Paris.

• Risque théorique : le CLOUD Act confère un pouvoir d’accès extraterritorial. Ce risque existe même avec des données stockées en France.
• Position d’AWS : selon ses rapports de transparence, AWS conteste les demandes qu’elle considère comme excessives ou en conflit avec le droit européen.
• Mesure la plus efficace : le chiffrement côté client (client-side encryption) avec des clés que vous gérez seul (via CloudHSM ou un HSM externe) rend les données illisibles pour AWS, donc pour toute autorité qui y accéderait via AWS.
• Position des autorités européennes : la CNIL et le Comité européen de la protection des données n’ont pas interdit AWS ; ils recommandent des mesures supplémentaires (chiffrement, pseudonymisation) pour les traitements sensibles.

Pour des données sensibles au sens de l’article 9 ou à haut risque, le chiffrement côté client avec gestion externe des clés est la mesure de référence pour neutraliser le risque CLOUD Act.

Sécurité et certifications : l’angle de l’article 32

L’article 32 du RGPD impose des mesures de sécurité adaptées au risque. Selon la documentation AWS consultée en juillet 2026, AWS détient notamment :

Certification	Portée
ISO 27001	Management de la sécurité de l’information
ISO 27017 / 27018	Sécurité cloud / protection des données dans le cloud
SOC 2 Type II	Contrôles de sécurité, disponibilité, confidentialité
PCI-DSS Level 1	Services de paiement
C5	Catalogue de conformité cloud du BSI allemand
HDS	Hébergeur de Données de Santé (région Paris)
SecNumCloud	Qualification ANSSI — périmètre limité, à vérifier service par service

Ces certifications attestent d’un niveau de sécurité élevé de l’infrastructure. Elles ne préjugent pas de votre configuration : côté client, le chiffrement, la gestion IAM, la configuration réseau et la journalisation relèvent de votre responsabilité et doivent figurer dans l’analyse d’impact (AIPD) de vos traitements. AWS Artifact vous fournit les attestations à joindre à votre documentation, mais c’est à vous de démontrer que vous les avez exploitées.

Checklist de configuration RGPD en 6 points

Voici la configuration de référence. Checklist indicative fournie à titre documentaire — ne constitue pas un conseil juridique ni un audit. À adapter à votre architecture avant usage. Version de juillet 2026.

1. Verrouiller la région

Sélectionnez la région Paris (eu-west-3) comme région par défaut. Configurez des Service Control Policies (SCP) au niveau d’AWS Organizations pour interdire le lancement de ressources hors EEE. Cela élimine le risque de transfert hors UE par erreur de configuration.

2. Chiffrer systématiquement

• Au repos : chiffrement par défaut pour S3, EBS, RDS, DynamoDB, via AWS KMS.
• En transit : TLS imposé ; politiques de bucket rejetant les requêtes non chiffrées.
• Données sensibles : chiffrement côté client avec clés gérées via CloudHSM ou HSM externe (protection contre le risque CLOUD Act).

3. Configurer IAM avec rigueur

Principe du moindre privilège, MFA sur tous les comptes (surtout le compte root), rôles IAM plutôt que clés d’accès à long terme, audit régulier via IAM Access Analyzer.

4. Activer la journalisation

CloudTrail sur toutes les régions, journaux stockés dans un bucket dédié et chiffré ; alarmes CloudWatch sur les événements de sécurité ; VPC Flow Logs pour les réseaux contenant des données personnelles.

5. Piloter la conservation

Implémentez des politiques de cycle de vie S3 pour supprimer automatiquement les données à l’échéance définie dans votre registre, et alignez les rétentions RDS/EBS sur vos durées de conservation documentées.

6. Restreindre les services edge et le support

Limitez CloudFront aux emplacements européens ; appliquez la même restriction à Lambda@Edge s’il traite des données personnelles ; activez l’option de support limité aux équipes de l’EEE si votre plan le permet.

Points d’attention par service

S3 : la première source de fuites

Les buckets S3 mal configurés sont la cause n° 1 des fuites sur AWS. Le blocage de l’accès public (Block Public Access) est activé par défaut, mais vérifiez qu’il l’est au niveau du compte et de chaque bucket, et utilisez AWS Config pour détecter automatiquement les buckets non conformes.

RDS et bases de données

Activez le chiffrement au repos (à la création, non modifiable ensuite), restreignez l’accès réseau via les groupes de sécurité, activez les journaux d’audit et configurez des sauvegardes automatiques cohérentes avec vos obligations.

Services managés d’IA : le nouvel enjeu 2026

Certains services managés (Amazon Rekognition, Comprehend, Transcribe, ou les services de generative AI type Bedrock) traitent activement vos données. Trois vérifications s’imposent : où les données sont-elles traitées (tous les services ne sont pas disponibles dans toutes les régions) ; AWS utilise-t-il vos données pour améliorer ses modèles (une option de retrait existe généralement) ; et le service relève-t-il de l’AI Act. Un traitement de reconnaissance faciale ou biométrique via un service cloud peut relever d’une catégorie à haut risque et croiser des obligations RGPD et IA — voir notre analyse de la classification des risques IA et l’actualité IA 2026. Documentez chaque service managé comme un traitement distinct dans votre registre.

Sous-traitants ultérieurs et vos propres SaaS

Vérifiez la liste des sous-traitants ultérieurs d’AWS et intégrez-la à votre cartographie. Pensez aussi que vos propres outils (Sendy via Amazon SES, Stripe, Slack, Notion) sont eux-mêmes des sous-traitants à évaluer : un questionnaire d’évaluation des sous-traitants systématise cette revue.

Données de santé et HDS

Pour héberger des données de santé, la certification HDS est obligatoire en droit français (article L1111-8 du Code de la santé publique). AWS est certifié HDS pour la région Paris ; utilisez exclusivement cette région et les services couverts. Voir aussi nos obligations spécifiques au cabinet médical.

AWS, GCP, Azure : la même logique

Le raisonnement vaut pour tous les grands hyperscalers américains : le régime de sous-traitance de l’article 28, le partage des responsabilités, le risque CLOUD Act et l’importance du chiffrement côté client sont identiques. Ce qui diffère : les régions disponibles, les certifications, la granularité des outils et le détail du DPA. Pour une analyse comparable, consultez notre guide Google Cloud et RGPD. Dans tous les cas, l’enjeu n’est pas de choisir un fournisseur « conforme », mais de configurer et documenter votre usage pour l’être vous-même — ce qu’un audit régulier permet de vérifier (méthode d’audit RGPD).

FAQ

AWS peut-il être utilisé en conformité avec le RGPD ?

Oui, AWS peut être utilisé dans le cadre d’un traitement conforme, à condition que vous fassiez votre part. AWS documente un DPA aligné sur l’article 28, des régions européennes, des certifications de sécurité et des outils de chiffrement et de journalisation. Mais la conformité effective dépend de votre configuration : un bucket S3 public, un IAM permissif ou une absence de chiffrement constituent des manquements, quelle que soit la qualité de l’infrastructure. La formule à retenir : AWS sécurise le cloud, vous sécurisez ce que vous mettez dans le cloud. Un audit de votre configuration permet d’objectiver cette part de responsabilité.

Le CLOUD Act rend-il l’usage d’AWS impossible sous le RGPD ?

Non. Le CLOUD Act est un facteur de risque, pas une interdiction. Les autorités européennes n’ont pas prohibé AWS ; elles recommandent des mesures supplémentaires. La plus efficace est le chiffrement côté client avec gestion externe des clés, qui rend les données illisibles pour AWS et pour toute autorité y accédant via AWS. Complétez par le choix d’une région européenne, la limitation des accès du support aux équipes de l’EEE et la documentation de votre analyse de risque. Pour des données à sensibilité élevée (santé, données judiciaires), le chiffrement côté client est indispensable.

Le Data Privacy Framework suffit-il pour héberger sur AWS ?

Le DPF est en vigueur en juillet 2026 et couvre les transferts vers les entités américaines certifiées. Mais il a été contesté : le Tribunal de l’UE a rejeté le recours Latombe le 3 septembre 2025, et un pourvoi est pendant devant la CJUE. Compte tenu de l’histoire des cadres précédents (annulés par la CJUE), il est prudent de ne pas fonder votre conformité sur le seul DPF. Privilégiez une région européenne (pas de transfert), et conservez les CCT et les mesures supplémentaires du DPA comme filet de sécurité si l’adéquation venait à être remise en cause.

Comment éviter tout transfert hors UE sur AWS ?

Trois mesures : sélectionnez la région Paris (ou une autre région EEE) par défaut et interdisez les autres via des Service Control Policies ; limitez CloudFront et Lambda@Edge aux emplacements européens ; activez le support limité à l’EEE. Avec cette configuration, vos données de stockage et de traitement ne quittent pas l’Union. Documentez ce choix et la configuration correspondante — c’est cette documentation qui vous protégera en cas de contrôle. Attention aux réplications inter-régions et aux services managés non disponibles en Europe.

Quelles certifications AWS sont pertinentes pour le marché français ?

Les plus pertinentes sont HDS (obligatoire pour les données de santé), ISO 27001 (référence internationale), C5 (catalogue du BSI allemand reconnu en Europe), SOC 2 Type II (contrôles de sécurité et disponibilité) et, pour un périmètre limité de services, la qualification SecNumCloud de l’ANSSI. Ces attestations sont téléchargeables via AWS Artifact et doivent figurer dans votre documentation comme mesures de sécurité au titre de l’article 32. Elles concernent l’infrastructure ; elles ne dispensent pas de sécuriser votre propre couche applicative.

Une violation de données sur AWS : qui notifie la CNIL ?

Cela dépend de l’origine de la violation. Si elle résulte de votre configuration (bucket public, IAM trop permissif), vous êtes responsable de traitement et c’est à vous de procéder, le cas échéant, à la notification à la CNIL dans les 72 heures. Si elle provient de l’infrastructure AWS, AWS doit vous en informer en tant que sous-traitant, et il vous appartient alors d’apprécier l’obligation de notification. Dans tous les cas, la décision de notifier et l’information des personnes concernées relèvent du responsable de traitement, pas du sous-traitant.

Un logiciel peut-il aider à auditer sa configuration AWS au regard du RGPD ?

Oui. Au-delà des outils natifs (AWS Config, IAM Access Analyzer, Security Hub) qui contrôlent la couche technique, un logiciel RGPD permet d’industrialiser le volet juridique : cartographier les traitements hébergés sur AWS, documenter les sous-traitants et les transferts, tenir le registre et suivre les mesures de sécurité de l’article 32. La combinaison des deux — contrôle technique côté AWS, documentation de conformité côté RGPD — est ce qui vous permet de démontrer votre conformité en cas de contrôle.