Google Cloud et RGPD : guide de conformite 2026

Google Cloud Platform (GCP) est le troisieme acteur mondial du cloud computing, derriere AWS et Microsoft Azure. En France, GCP est particulierement present dans les startups, les entreprises data-driven et les organisations qui utilisent deja l’ecosysteme Google (Google Workspace, BigQuery, Vertex AI). Si votre infrastructure tourne sur GCP, les donnees personnelles de vos utilisateurs sont hebergees, traitees et stockees sur l’infrastructure de Google.

La premiere clarification essentielle : Google Cloud est juridiquement distinct des services grand public de Google. Gmail, Google Search, YouTube et Google Ads fonctionnent sous des conditions de service ou Google est responsable de traitement pour ses propres finalites. Google Cloud Platform fonctionne sous un contrat de sous-traitance (Data Processing Addendum) ou Google agit en tant que sous-traitant pour le compte du client. Cette distinction est fondamentale pour l’analyse de conformite.

Ce guide analyse la conformite RGPD de GCP sous l’angle juridique et operationnel, en comparaison avec AWS et le RGPD qui partage un modele similaire. Pour une vue d’ensemble de la conformite des outils SaaS, consultez notre guide RGPD par outil.

Qualification juridique : Google Cloud comme sous-traitant

Le modele de sous-traitance

Pour les services d’infrastructure (Compute Engine, Cloud Storage, Cloud SQL) et de plateforme (App Engine, Cloud Functions, Cloud Run), Google Cloud agit en qualite de sous-traitant au sens de l’article 28 du RGPD. Vous etes le responsable de traitement : vous decidez quelles donnees stocker, comment les traiter, et dans quelle finalite. Google fournit l’infrastructure que vous configurez.

Cette qualification est identique a celle d’AWS : le cloud provider met a disposition une infrastructure, le client la configure et l’utilise pour ses propres finalites. Google ne determine pas les finalites de traitement de vos donnees sur GCP.

Le modele de responsabilite partagee

Comme AWS, Google Cloud applique un modele de responsabilite partagee (Shared Fate Model, dans la terminologie de Google) :

Google est responsable de :

• Securite physique des datacenters
• Securite de l’infrastructure reseau et de l’hyperviseur
• Chiffrement par defaut des donnees au repos et en transit
• Maintenance et mise a jour des composants d’infrastructure
• Disponibilite et resilience de la plateforme

Vous etes responsable de :

• Configuration des regles de pare-feu et des VPC
• Gestion des identites et des acces (IAM)
• Choix de la region de stockage et de traitement
• Configuration du chiffrement supplementaire (CMEK, EKM)
• Parametrage des journaux d’audit (Cloud Audit Logs)
• Gestion des durees de conservation des donnees
• Mise a jour de vos applications et conteneurs

La difference terminologique est notable : Google utilise “Shared Fate” plutot que “Shared Responsibility”, pour souligner son engagement a aider activement les clients dans la securisation de leur environnement (via Security Command Center, recommandations de configuration, etc.). En pratique, la repartition des responsabilites est tres similaire a celle d’AWS.

Cas particuliers

• BigQuery : service d’entrepot de donnees entierement gere. Google reste sous-traitant, mais la sensibilite est accrue car BigQuery centralise souvent des volumes importants de donnees personnelles (analytics, profils clients, donnees comportementales).
• Vertex AI : plateforme d’IA/ML. Si vous entrainez des modeles sur des donnees personnelles, Google reste sous-traitant pour l’infrastructure, mais vous devez documenter les finalites du traitement et la base legale. Verifiez que les donnees d’entrainement ne sont pas utilisees par Google pour ameliorer ses propres modeles (opt-out configurable).
• Google Workspace : c’est un produit distinct avec son propre DPA. Si vous utilisez a la fois GCP et Google Workspace, deux DPA distincts s’appliquent.

Analyse du DPA Google Cloud

Le Google Cloud Data Processing Addendum est le contrat de sous-traitance au sens de l’article 28. Il est integre au Google Cloud Platform Terms of Service et automatiquement applicable a tous les clients GCP.

Exigence Art. 28	Couverture Google Cloud	Evaluation
Instructions documentees (28(3)(a))	Traitement conforme aux instructions du client definies par la configuration des services	Conforme
Confidentialite du personnel (28(3)(b))	Engagement de confidentialite pour tout le personnel Google	Conforme
Mesures de securite (28(3)©)	Annexe securite detaillee, certifications multiples	Conforme
Sous-traitants ulterieurs (28(3)(d))	Liste publiee, mecanisme de notification prealable et droit d’objection	Conforme
Assistance droits des personnes (28(3)(e))	Outils techniques (export, suppression) + engagement contractuel	Conforme
Assistance securite et AIPD (28(3)(f))	Cooperation pour les analyses d’impact et les notifications de violation	Conforme
Suppression ou restitution (28(3)(g))	Suppression sur instruction du client via les outils GCP + suppression en fin de contrat	Conforme
Audits et inspections (28(3)(h))	Rapports SOC 2, ISO 27001 via Compliance Reports Manager + engagement d’audit	Conforme

Points forts du DPA Google Cloud :

• Transparence sur les sous-traitants ulterieurs : Google publie la liste de ses sous-traitants avec localisation et nature du service. Un mecanisme de notification prealable est prevu, avec un delai d’objection de 30 jours.
• Engagement de notification de violation : Google s’engage a notifier sans delai indu toute violation de donnees, ce qui facilite votre propre obligation de notification au titre de l’article 33.
• Compliance Reports Manager : portail en libre-service equivalent a AWS Artifact, permettant de telecharger les rapports de certification.

Point d’attention : comme pour AWS, le droit d’audit s’exerce principalement via les rapports de certification (SOC 2, ISO 27001). Un audit physique sur site n’est pas propose en standard. Pour les organisations soumises a des exigences d’audit renforcees (secteur financier, sante), cette limitation doit etre evaluee.

Transferts internationaux et evaluation d’impact du transfert

Regions europeennes

GCP propose plusieurs regions dans l’EEE :

• europe-west1 (Belgique) – la region historique de Google Cloud en Europe
• europe-west3 (Francfort, Allemagne)
• europe-west4 (Pays-Bas)
• europe-north1 (Finlande)
• europe-west6 (Zurich, Suisse)
• europe-west8 (Milan, Italie)
• europe-west9 (Paris, France)
• europe-southwest1 (Madrid, Espagne)
• europe-central2 (Varsovie, Pologne)

La region europe-west9 (Paris) est la region de reference pour les clients francais. Si vous selectionnez cette region et ne configurez aucune replication vers des regions hors EEE, vos donnees restent en France.

Quand y a-t-il transfert hors UE ?

Les transferts hors UE interviennent dans les scenarios suivants :

• Choix d’une region hors EEE pour le stockage ou le traitement
• Replication multi-regions incluant des regions hors EEE
• Support technique Google : les ingenieurs support peuvent acceder aux donnees depuis des localisations hors UE. Google propose Access Transparency (journalisation des acces par le personnel Google) et Access Approval (approbation prealable par le client) pour les plans Premium
• Services globaux : certains services (Cloud CDN, Cloud Armor) distribuent du contenu sur des points de presence mondiaux

Mecanismes de transfert

1. EU-US Data Privacy Framework : Google LLC est certifie DPF.
2. Clauses contractuelles types (CCT) : integrees au DPA comme mecanisme subsidiaire.
3. Mesures supplementaires : chiffrement systematique, controle de localisation, journalisation des acces.

Le CLOUD Act : meme problematique qu’AWS

Google est une entreprise americaine soumise au CLOUD Act, avec les memes implications que pour AWS. Le risque d’acces extraterritorial par les autorites americaines existe, meme pour des donnees stockees en France.

La reponse de Google Cloud : Google publie un rapport de transparence annuel et s’engage a contester les demandes excessives ou en conflit avec le droit europeen. Google propose en outre des mesures supplementaires specifiques :

• Customer-Managed Encryption Keys (CMEK) : vous gerez vos propres cles de chiffrement via Cloud KMS.
• External Key Manager (EKM) : la mesure la plus forte. Les cles de chiffrement sont hebergees en dehors de l’infrastructure Google, chez un fournisseur tiers (Thales, Fortanix, etc.). Google ne peut pas dechiffrer vos donnees sans votre cle externe. C’est l’equivalent de l’approche client-side encryption d’AWS, mais integree nativement dans l’architecture GCP.
• Assured Workloads : environnement restreint garantissant que le traitement reste dans des regions specifiques, avec des controles d’acces renforces.

Pour les donnees sensibles, la combinaison region Paris + EKM + Assured Workloads constitue la configuration la plus protectrice contre le risque CLOUD Act.

Securite informatique

Certifications

Google Cloud detient un portefeuille de certifications comparable a celui d’AWS :

• ISO 27001 : systeme de management de la securite de l’information
• ISO 27017 : securite cloud
• ISO 27018 : protection des donnees personnelles dans le cloud
• ISO 27701 : systeme de management de la vie privee (certification specifique a la protection des donnees, rare dans le secteur)
• SOC 2 Type II : controles de securite, disponibilite, confidentialite
• SOC 3 : rapport public
• CSA STAR : Cloud Security Alliance
• C5 : catalogue de conformite cloud du BSI allemand
• FedRAMP : autorisation du gouvernement federal americain

Point distinctif : la certification ISO 27701 est une certification specifique au management de la vie privee, que Google Cloud a obtenue et qu’AWS ne met pas en avant de la meme maniere. C’est un element de differenciation dans une evaluation comparative.

Securite par defaut

Google Cloud se distingue par un chiffrement par defaut de toutes les donnees, au repos et en transit, sans action requise du client. C’est une difference avec AWS ou le chiffrement au repos doit etre active pour certains services. Toutes les donnees stockees sur GCP sont chifrees en AES-256 au repos, et tout le trafic interne au reseau Google est chiffre.

Infrastructure de securite

• BeyondCorp : modele de securite zero-trust pour l’acces aux ressources
• Security Command Center : plateforme centralisee de gestion des vulnerabilites et de la posture de securite
• Chronicle : SIEM (Security Information and Event Management) integre
• Titan Security Keys : cles de securite materielles pour l’authentification
• Shielded VMs : machines virtuelles avec integrite verifiee au demarrage

Configuration recommandee pour la conformite RGPD

1. Selectionner la region Paris (europe-west9)

Choisissez europe-west9 comme region par defaut pour tous vos services GCP. Configurez des Organization Policies pour restreindre la creation de ressources aux regions europeennes uniquement (constraint gcp.resourceLocations). C’est l’equivalent des Service Control Policies d’AWS.

2. Configurer le chiffrement

• Par defaut : le chiffrement Google-managed est actif automatiquement. C’est suffisant pour les traitements courants.
• CMEK : pour un controle accru, gerez vos propres cles via Cloud KMS. Vous pouvez revoquer l’acces a vos donnees en desactivant la cle.
• EKM : pour les donnees sensibles, utilisez l’External Key Manager avec un fournisseur externe (Thales CipherTrust, Fortanix, Equinix SmartKey). C’est la protection maximale contre le CLOUD Act.

3. Configurer IAM avec rigueur

• Appliquez le principe du moindre privilege via les roles predefinies et les roles personnalises.
• Activez la verification en deux etapes pour tous les comptes.
• Utilisez des comptes de service avec des permissions minimales.
• Auditez les permissions avec IAM Recommender et Policy Analyzer.

4. Activer la journalisation

• Cloud Audit Logs : activez les Admin Activity Logs (actifs par defaut) et les Data Access Logs (a activer manuellement pour les services contenant des donnees personnelles).
• Access Transparency : activez la journalisation des acces par le personnel Google a vos donnees (plans Premium/Enterprise).
• Access Approval : configurez l’approbation prealable pour tout acces par le personnel Google (plans Premium/Enterprise).

5. Gerer la conservation des donnees

• Configurez des politiques de retention pour Cloud Storage (Object Lifecycle Management).
• Definissez des politiques de retention pour BigQuery (duree de vie des tables, suppression automatique).
• Documentez les durees de conservation dans votre registre des traitements.

6. Activer Assured Workloads (si necessaire)

Pour les traitements soumis a des exigences regulatoires strictes, Assured Workloads cree un environnement restreint avec des garanties de localisation, des controles d’acces renforces, et une restriction du personnel Google qui peut acceder aux donnees. C’est l’equivalent d’un environnement dedie, sans le cout d’une infrastructure privee.

Points d’attention specifiques

BigQuery et la centralisation des donnees

BigQuery est le service d’entrepot de donnees analytique de GCP, et c’est souvent la ou se concentrent les volumes les plus importants de donnees personnelles. Les tables BigQuery peuvent contenir des profils clients, des historiques de navigation, des donnees transactionnelles, des logs applicatifs. Trois points de vigilance :

• Localisation : verifiez que vos datasets BigQuery sont crees dans une region europeenne (EU multi-region ou region specifique comme europe-west9).
• Retention : configurez la duree de vie des tables et des partitions pour respecter la duree de conservation.
• Acces : restreignez l’acces aux datasets contenant des donnees personnelles via IAM et les controles de colonne/ligne de BigQuery.

Vertex AI et l’entrainement de modeles

Si vous entrainez des modeles de machine learning sur des donnees personnelles via Vertex AI, documentez ce traitement dans votre registre avec une base legale specifique. Verifiez que Google ne reutilise pas vos donnees d’entrainement pour ameliorer ses propres modeles : le DPA de Google Cloud prevoit que les donnees client ne sont pas utilisees pour les services de Google, mais verifiez les conditions specifiques au service Vertex AI. Pour les modeles GenAI (Gemini via Vertex AI), les memes precautions s’appliquent.

Comparaison avec AWS

GCP et AWS presentent un niveau de conformite RGPD comparable. Les differences notables :

• Chiffrement par defaut : GCP chiffre tout par defaut, AWS requiert une activation pour certains services.
• External Key Manager : GCP propose une solution EKM nativement integree. AWS offre CloudHSM, qui est plus complexe a deployer.
• Certifications : GCP a ISO 27701 (vie privee) ; AWS a HDS (sante, specifique au marche francais).
• Regions francaises : les deux proposent une region Paris.
• Marche francais : AWS a une presence plus ancienne et plus large en France, avec une certification HDS que GCP n’a pas a ce jour.

Pour une analyse detaillee d’AWS, consultez notre guide AWS et RGPD.

Support technique et acces aux donnees

Les ingenieurs de support Google peuvent acceder a vos ressources pour resoudre un incident. Activez Access Transparency pour journaliser ces acces et Access Approval pour les approuver prealablement. Pour les donnees sensibles, l’EKM garantit que le personnel Google ne peut pas lire vos donnees meme en cas d’acces a l’infrastructure.

FAQ

Google Cloud est-il conforme au RGPD ?

Google Cloud fournit un cadre de conformite parmi les plus complets du marche : DPA conforme a l’article 28, certifications etendues (ISO 27001, ISO 27701, SOC 2, C5), regions europeennes avec controle de localisation, chiffrement par defaut, et outils avances (EKM, Assured Workloads, Access Approval). La conformite effective depend de votre configuration : choix de la region, parametrage d’IAM, politique de conservation, activation du chiffrement supplementaire. Google securise l’infrastructure ; vous securisez ce qui tourne dessus. C’est ce type d’evaluation que Legiscope permet d’automatiser.

Le CLOUD Act rend-il Google Cloud non conforme au RGPD ?

Le CLOUD Act est un facteur de risque, pas un facteur d’interdiction. La reponse la plus efficace est l’External Key Manager (EKM) : vos donnees sont chiffrees avec une cle que vous gerez en dehors de l’infrastructure Google. Meme si les autorites americaines obtiennent un mandat CLOUD Act, les donnees sont illisibles sans votre cle externe. Combinez l’EKM avec la region Paris, Access Approval, et Assured Workloads pour le niveau de protection maximal. Les autorites europeennes n’ont pas interdit l’utilisation de Google Cloud et recommandent la mise en oeuvre de mesures supplementaires pour les traitements sensibles.

Quelle difference entre Google Cloud et Google Workspace pour le RGPD ?

Ce sont deux produits distincts avec des conditions contractuelles et des DPA differents. Google Cloud Platform (GCP) est un service d’infrastructure ou Google est sous-traitant : vous controlez integralement ce que vous stockez et traitez. Google Workspace est un service de productivite ou Google traite vos donnees dans un cadre plus structure (Gmail, Drive, Meet), avec des conditions de service specifiques. Si vous utilisez les deux, assurez-vous que les deux DPA sont en place et documentez les traitements separement dans votre registre.

Comment choisir entre AWS et Google Cloud pour la conformite RGPD ?

Les deux plateformes offrent un niveau de conformite comparable. Les criteres de choix RGPD sont marginaux : GCP a un avantage sur le chiffrement par defaut et l’EKM ; AWS a un avantage sur la certification HDS pour les donnees de sante en France. Le choix se fait generalement sur des criteres techniques et business. Quelle que soit la plateforme, appliquez la meme checklist : region europeenne, chiffrement renforce, IAM rigoureux, journalisation, conservation documentee. Consultez notre guide AWS et RGPD pour une analyse detaillee.