AWS, Azure, Google Cloud : vérifier le dossier RGPD
Comparez AWS, Azure et Google Cloud sur les contrats, flux, accès, preuves de sécurité et sortie du service, sans verdict global trompeur.
Pour choisir entre AWS, Azure et Google Cloud, la bonne question est : ce service précis, avec cette configuration et ces données, offre-t-il les garanties nécessaires ? Une comparaison des seules marques laisse de côté les régions, les fonctions activées, les prestataires et les accès de support.
Le dossier présenté ici sert à préparer une décision entre DPO, DSI et responsable métier. Il ne classe pas tous les services d’un fournisseur sous un verdict unique.
Ce qu’il faut retenir
- Le partage des tâches de sécurité ne détermine pas, à lui seul, les rôles juridiques.
- Un DPA doit être rapproché de votre contrat, des services couverts et de votre architecture.
- Stockage européen, transferts, accès et maîtrise des clés nécessitent des vérifications distinctes.
- Une décision exploitable indique les preuves reçues, les réglages imposés et les points restant à résoudre.
1. Comparer des projets équivalents
Décrivez d’abord l’application et ses contraintes : données, personnes concernées, finalités, disponibilité nécessaire et équipe chargée de l’exploitation. Comparez ensuite des architectures équivalentes. Une machine virtuelle administrée par vos équipes et une application entièrement managée ne transfèrent pas les mêmes tâches techniques au fournisseur.
Préparez un tableau commun aux trois offres :
| Rubrique | Question à documenter |
|---|---|
| Périmètre | Quels services, options et fonctions expérimentales sont activés ? |
| Contrat | Quelle entité signe, quels documents et quelles versions s’appliquent ? |
| Flux | Où sont stockées, copiées, consultées et exportées les données ? |
| Administration | Qui corrige, autorise les accès, surveille et restaure ? |
| Preuves | Quels rapports couvrent réellement les services retenus ? |
| Sortie | Que peut-on récupérer, dans quel format et avant quelle échéance ? |
Ajoutez une colonne « inconnu » : elle évite de transformer une absence de réponse en garantie présumée. Pour obtenir les pièces prioritaires, utilisez notre démarche d’audit prestataire avec preuves manquantes.
2. Qualifier les rôles par opération
La CNIL distingue la fourniture du service, son amélioration et les traitements de sécurité. Un fournisseur agit généralement comme sous-traitant pour les opérations effectuées sur instruction ; il peut déterminer seul certaines finalités propres, notamment de sécurité globale, ou participer à des décisions communes. La qualification dépend des faits. Voir son analyse du cloud du 28 mai 2026.
Votre entreprise peut elle-même être sous-traitante lorsqu’elle exploite une application pour ses clients. Il faut alors vérifier l’autorisation de recourir au fournisseur et organiser la remontée des incidents et des informations utiles.
Le schéma technique de responsabilité partagée reste utile pour attribuer les tâches. Microsoft précise expressément que sa documentation sur la responsabilité partagée fournit un cadre de gouvernance et ne remplace pas les conclusions juridiques ou les stipulations contractuelles. Ne confondez donc pas « gère le système d’exploitation » et « responsable de traitement ».
3. Rassembler les documents propres à chaque fournisseur
Les points d’entrée officiels facilitent la collecte, sans dispenser de lire les documents applicables à votre commande :
| Fournisseur | Point de départ | Vérification à mener |
|---|---|---|
| AWS | Centre RGPD officiel | DPA, conditions des services et informations sur les flux des fonctions utilisées |
| Microsoft Azure | Portail des DPA Microsoft | Version applicable, Product Terms et engagements propres aux produits |
| Google Cloud | Cloud Data Processing Addendum | Services couverts, annexes et conditions spécifiques de l’offre |
Le portail Microsoft présente une édition de mai2026 lors de cette revue. Conservez la version effectivement applicable à votre contrat, plutôt que d’associer automatiquement la dernière version publique à toute commande antérieure.
À titre d’exemple concret, le CDPA Google distingue le rôle du client responsable ou sous-traitant (§4.1), les instructions (§5.2) et les étapes d’effacement (§6). Il prévoit des délais et situations particulières, dont la récupération après fin du contrat et certaines données couvertes par un contrat continu. La fermeture visible d’un environnement ne prouve donc pas une disparition immédiate de chaque copie. Ces clauses ne doivent pas être transposées aux deux autres fournisseurs.
L’Art. 28(3) du RGPD impose un contenu contractuel précis. Vérifiez l’assistance, les sous-traitants ultérieurs, la sortie et l’audit. Les rapports de certification constituent des éléments de preuve ; les modalités d’audit doivent être examinées, sans affirmer que tous les fournisseurs interdisent systématiquement toute inspection.
4. Examiner les transferts sans automatisme
Une région européenne ne couvre pas nécessairement tous les journaux, services globaux, accès d’assistance ou outils ajoutés à l’application. Notre guide sur l’hébergement européen et la télémétrie aide à séparer ces flux.
Pour chaque transfert identifié, relevez le destinataire et le mécanisme applicable. Une décision d’adéquation couvrant réellement le transfert relève de l’Art.45. Des clauses contractuelles types ou d’autres garanties de l’Art.46 appellent l’examen correspondant, notamment de leur efficacité dans le contexte du transfert. Il ne faut pas présenter adéquation, clauses et analyse d’impact comme trois formalités toujours cumulatives. Consultez les outils de la CNIL sur les transferts.
Si un mécanisme repose sur une certification de l’entité destinataire, vérifiez son statut et son périmètre à la date de votre décision. Le nom commercial d’un groupe ne démontre pas à lui seul que chaque entité et chaque donnée sont couverts. Pour un flux fondé sur des garanties appropriées, notre modèle d’analyse d’impact du transfert structure les questions restantes.
5. Vérifier la sécurité en situation réelle
Attribuez les tâches de configuration et d’exploitation : identités, droits, interfaces exposées, secrets, chiffrement, surveillance, sauvegardes et restauration. Les besoins découlent des risques, conformément à l’Art.32(1), et des particularités de l’application.
Exemple hypothétique : une base chiffrée au repos reste accessible à un compte de service disposant de droits excessifs. La présence du chiffrement ne corrige pas cette habilitation. De même, une option de clé gérée par le client ne prouve pas, à elle seule, que personne chez le fournisseur ne peut accéder aux données en clair pendant leur traitement. Faites préciser le modèle technique et les accès possibles.
L’AIPD n’est pas automatiquement requise parce que le fournisseur est américain ou qu’une donnée sensible est présente. Examinez les critères de risque élevé et les listes applicables ; la méthode AIPD permet de documenter la décision.
Prévoyez enfin un canal d’alerte surveillé. L’Art.33(2) demande au sous-traitant d’informer le responsable sans retard injustifié. Le délai de72heures prévu à l’Art.33(1) concerne la notification du responsable à l’autorité, dans les conditions de cet article : ce n’est pas un délai général accordé à tout prestataire.
6. Formaliser l’autorisation de mise en production
La décision peut rester courte : architecture approuvée, données admises, services exclus, réglages obligatoires, tests de restauration réalisés, mécanismes de transfert et réserves. Chaque réserve doit avoir un responsable et une échéance. Une incertitude déterminante sur un accès ou une garantie doit être résolue avant d’autoriser le flux concerné.
Déclenchez une nouvelle vérification lors d’un changement de région, d’une fonction d’IA, d’un nouveau destinataire ou d’un usage différent des données. Le registre décrit les activités de traitement ; il n’exige pas automatiquement une fiche distincte pour chaque service technique du catalogue.
FAQ
Peut-on utiliser ces clouds pour des données personnelles ?
Le RGPD n’établit pas d’interdiction générale par marque. Il faut démontrer que le traitement concret respecte ses exigences et, le cas échéant, celles propres au secteur ou à l’organisme.
Une offre certifiée suffit-elle pour les données de santé ?
Vérifiez d’abord le régime applicable à l’hébergement, puis le certificat, les activités et les services couverts. Une certification globale du fournisseur ne remplace pas cette correspondance.
Faut-il recommencer l’audit à chaque nouvelle fonction ?
Évaluez le changement. Une option qui ajoute un destinataire, une réutilisation ou un lieu de traitement peut nécessiter une nouvelle analyse ; une correction sans incidence sur ces éléments n’appelle pas nécessairement une revue complète.
Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.