Google Cloud et RGPD : guide de conformité 2026

Google Cloud Platform (GCP) est le troisième acteur mondial du cloud computing, derrière AWS et Microsoft Azure. En France, GCP est particulièrement présent dans les startups, les entreprises data-driven et les organisations qui utilisent déjà l’écosystème Google (Google Workspace, BigQuery, Vertex AI). Si votre infrastructure tourne sur GCP, les données personnelles de vos utilisateurs sont hébergées, traitées et stockées sur l’infrastructure de Google.

La première 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 où Google est responsable de traitement pour ses propres finalités. Google Cloud Platform fonctionne sous un contrat de sous-traitance (Data Processing Addendum) où Google agit en tant que sous-traitant pour le compte du client. Cette distinction est fondamentale pour l’analyse de conformité.

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

Qualification juridique : Google Cloud comme sous-traitant

Le modèle 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 qualité de sous-traitant au sens de l’article 28 du RGPD. Vous êtes le responsable de traitement : vous décidez quelles données stocker, comment les traiter, et dans quelle finalité. Google fournit l’infrastructure que vous configurez.

Cette qualification est identique à celle d’AWS : le cloud provider met à disposition une infrastructure, le client la configure et l’utilise pour ses propres finalités. Google ne détermine pas les finalités de traitement de vos données sur GCP.

Le modèle de responsabilité partagée

Comme AWS, Google Cloud applique un modèle de responsabilité partagée (Shared Fate Model, dans la terminologie de Google) :

Google est responsable de :

• Sécurité physique des datacenters
• Sécurité de l’infrastructure réseau et de l’hyperviseur
• Chiffrement par défaut des données au repos et en transit
• Maintenance et mise à jour des composants d’infrastructure
• Disponibilité et résilience de la plateforme

Vous êtes responsable de :

• Configuration des règles de pare-feu et des VPC
• Gestion des identités et des accès (IAM)
• Choix de la région de stockage et de traitement
• Configuration du chiffrement supplémentaire (CMEK, EKM)
• Paramétrage des journaux d’audit (Cloud Audit Logs)
• Gestion des durées de conservation des données
• Mise à jour de vos applications et conteneurs

La différence terminologique est notable : Google utilise “Shared Fate” plutôt que “Shared Responsibility”, pour souligner son engagement à aider activement les clients dans la sécurisation de leur environnement (via Security Command Center, recommandations de configuration, etc.). En pratique, la répartition des responsabilités est très similaire à celle d’AWS.

Cas particuliers

• BigQuery : service d’entrepôt de données entièrement géré. Google reste sous-traitant, mais la sensibilité est accrue car BigQuery centralise souvent des volumes importants de données personnelles (analytics, profils clients, données comportementales).
• Vertex AI : plateforme d’IA/ML. Si vous entraînez des modèles sur des données personnelles, Google reste sous-traitant pour l’infrastructure, mais vous devez documenter les finalités du traitement et la base légale. Vérifiez que les données d’entraînement ne sont pas utilisées par Google pour améliorer ses propres modèles (opt-out configurable).
• Google Workspace : c’est un produit distinct avec son propre DPA. Si vous utilisez à 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 intégré au Google Cloud Platform Terms of Service et automatiquement applicable à tous les clients GCP.

Exigence Art. 28	Couverture Google Cloud	Évaluation
Instructions documentées (28(3)(a))	Traitement conforme aux instructions du client définies par la configuration des services	Conforme
Confidentialité du personnel (28(3)(b))	Engagement de confidentialité pour tout le personnel Google	Conforme
Mesures de sécurité (28(3)©)	Annexe sécurité détaillée, certifications multiples	Conforme
Sous-traitants ultérieurs (28(3)(d))	Liste publiée, mécanisme de notification préalable et droit d’objection	Conforme
Assistance droits des personnes (28(3)(e))	Outils techniques (export, suppression) + engagement contractuel	Conforme
Assistance sécurité et AIPD (28(3)(f))	Coopération 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 ultérieurs : Google publie la liste de ses sous-traitants avec localisation et nature du service. Un mécanisme de notification préalable est prévu, avec un délai d’objection de 30 jours.
• Engagement de notification de violation : Google s’engage à notifier sans délai indu toute violation de données, ce qui facilite votre propre obligation de notification au titre de l’article 33.
• Compliance Reports Manager : portail en libre-service équivalent à AWS Artifact, permettant de télécharger 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 proposé en standard. Pour les organisations soumises à des exigences d’audit renforcées (secteur financier, santé), cette limitation doit être évaluée.

Transferts internationaux et evaluation d’impact du transfert

Régions européennes

GCP propose plusieurs régions 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 région europe-west9 (Paris) est la région de référence pour les clients français. Si vous sélectionnez cette région et ne configurez aucune réplication vers des régions hors EEE, vos données restent en France.

Quand y a-t-il transfert hors UE ?

Les transferts hors UE interviennent dans les scénarios suivants :

• Choix d’une région hors EEE pour le stockage ou le traitement
• Réplication multi-régions incluant des régions hors EEE
• Support technique Google : les ingénieurs support peuvent accéder aux données depuis des localisations hors UE. Google propose Access Transparency (journalisation des accès par le personnel Google) et Access Approval (approbation préalable par le client) pour les plans Premium
• Services globaux : certains services (Cloud CDN, Cloud Armor) distribuent du contenu sur des points de présence mondiaux

Mécanismes de transfert

1. EU-US Data Privacy Framework : Google LLC est certifié DPF.
2. Clauses contractuelles types (CCT) : intégrées au DPA comme mécanisme subsidiaire.
3. Mesures supplémentaires : chiffrement systématique, contrôle de localisation, journalisation des accès.

Le CLOUD Act : même problématique qu’AWS

Google est une entreprise américaine soumise au CLOUD Act, avec les mêmes implications que pour AWS. Le risque d’accès extraterritorial par les autorités américaines existe, même pour des données stockées en France.

La réponse de Google Cloud : Google publie un rapport de transparence annuel et s’engage à contester les demandes excessives ou en conflit avec le droit européen. Google propose en outre des mesures supplémentaires spécifiques :

• Customer-Managed Encryption Keys (CMEK) : vous gérez vos propres clés de chiffrement via Cloud KMS.
• External Key Manager (EKM) : la mesure la plus forte. Les clés de chiffrement sont hébergées en dehors de l’infrastructure Google, chez un fournisseur tiers (Thales, Fortanix, etc.). Google ne peut pas déchiffrer vos données sans votre clé externe. C’est l’équivalent de l’approche client-side encryption d’AWS, mais intégrée nativement dans l’architecture GCP.
• Assured Workloads : environnement restreint garantissant que le traitement reste dans des régions spécifiques, avec des contrôles d’accès renforcés.

Pour les données sensibles, la combinaison région Paris + EKM + Assured Workloads constitue la configuration la plus protectrice contre le risque CLOUD Act.

Securite informatique

Certifications

Google Cloud détient un portefeuille de certifications comparable à celui d’AWS :

• ISO 27001 : système de management de la sécurité de l’information
• ISO 27017 : sécurité cloud
• ISO 27018 : protection des données personnelles dans le cloud
• ISO 27701 : système de management de la vie privée (certification spécifique à la protection des données, rare dans le secteur)
• SOC 2 Type II : contrôles de sécurité, disponibilité, confidentialité
• SOC 3 : rapport public
• CSA STAR : Cloud Security Alliance
• C5 : catalogue de conformité cloud du BSI allemand
• FedRAMP : autorisation du gouvernement fédéral américain

Point distinctif : la certification ISO 27701 est une certification spécifique au management de la vie privée, que Google Cloud a obtenue et qu’AWS ne met pas en avant de la même manière. C’est un élément de différenciation dans une évaluation comparative.

Sécurité par défaut

Google Cloud se distingue par un chiffrement par défaut de toutes les données, au repos et en transit, sans action requise du client. C’est une différence avec AWS où le chiffrement au repos doit être activé pour certains services. Toutes les données stockées sur GCP sont chiffrées en AES-256 au repos, et tout le trafic interne au réseau Google est chiffré.

Infrastructure de sécurité

• BeyondCorp : modèle de sécurité zero-trust pour l’accès aux ressources
• Security Command Center : plateforme centralisée de gestion des vulnérabilités et de la posture de sécurité
• Chronicle : SIEM (Security Information and Event Management) intégré
• Titan Security Keys : clés de sécurité matérielles pour l’authentification
• Shielded VMs : machines virtuelles avec intégrité vérifiée au démarrage

Configuration recommandée pour la conformité RGPD

1. Sélectionner la région Paris (europe-west9)

Choisissez europe-west9 comme région par défaut pour tous vos services GCP. Configurez des Organization Policies pour restreindre la création de ressources aux régions européennes uniquement (constraint gcp.resourceLocations). C’est l’équivalent des Service Control Policies d’AWS.

2. Configurer le chiffrement

• Par défaut : le chiffrement Google-managed est actif automatiquement. C’est suffisant pour les traitements courants.
• CMEK : pour un contrôle accru, gérez vos propres clés via Cloud KMS. Vous pouvez révoquer l’accès à vos données en désactivant la clé.
• EKM : pour les données 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 privilège via les rôles prédéfinies et les rôles personnalisées.
• Activez la vérification en deux étapes 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 défaut) et les Data Access Logs (à activer manuellement pour les services contenant des données personnelles).
• Access Transparency : activez la journalisation des accès par le personnel Google à vos données (plans Premium/Enterprise).
• Access Approval : configurez l’approbation préalable pour tout accès par le personnel Google (plans Premium/Enterprise).

5. Gérer la conservation des données

• Configurez des politiques de rétention pour Cloud Storage (Object Lifecycle Management).
• Définissez des politiques de rétention pour BigQuery (durée de vie des tables, suppression automatique).
• Documentez les durées de conservation dans votre registre des traitements.

6. Activer Assured Workloads (si nécessaire)

Pour les traitements soumis à des exigences régulatoires strictes, Assured Workloads crée un environnement restreint avec des garanties de localisation, des contrôles d’accès renforcés, et une restriction du personnel Google qui peut accéder aux données. C’est l’équivalent d’un environnement dédié, sans le coût d’une infrastructure privée.

Points d’attention spécifiques

BigQuery et la centralisation des données

BigQuery est le service d’entrepôt de données analytique de GCP, et c’est souvent là où se concentrent les volumes les plus importants de données personnelles. Les tables BigQuery peuvent contenir des profils clients, des historiques de navigation, des données transactionnelles, des logs applicatifs. Trois points de vigilance :

• Localisation : vérifiez que vos datasets BigQuery sont créés dans une région européenne (EU multi-region ou région spécifique comme europe-west9).
• Rétention : configurez la durée de vie des tables et des partitions pour respecter la durée de conservation.
• Accès : restreignez l’accès aux datasets contenant des données personnelles via IAM et les contrôles de colonne/ligne de BigQuery.

Vertex AI et l’entraînement de modèles

Si vous entraînez des modèles de machine learning sur des données personnelles via Vertex AI, documentez ce traitement dans votre registre avec une base légale spécifique. Vérifiez que Google ne réutilise pas vos données d’entraînement pour améliorer ses propres modèles : le DPA de Google Cloud prévoit que les données client ne sont pas utilisées pour les services de Google, mais vérifiez les conditions spécifiques au service Vertex AI. Pour les modèles GenAI (Gemini via Vertex AI), les mêmes précautions s’appliquent.

Comparaison avec AWS

GCP et AWS présentent un niveau de conformité RGPD comparable. Les différences notables :

• Chiffrement par défaut : GCP chiffre tout par défaut, AWS requiert une activation pour certains services.
• External Key Manager : GCP propose une solution EKM nativement intégrée. AWS offre CloudHSM, qui est plus complexe à déployer.
• Certifications : GCP a ISO 27701 (vie privée) ; AWS a HDS (santé, spécifique au marché français).
• Régions françaises : les deux proposent une région Paris.
• Marché français : AWS a une présence plus ancienne et plus large en France, avec une certification HDS que GCP n’a pas à ce jour.

Pour une analyse détaillée d’AWS, consultez notre guide AWS et RGPD.

Les applications déployées sur GCP intègrent souvent des services tiers comme Stripe pour le paiement, chacun nécessitant sa propre évaluation RGPD.

Pour l’utilisation d’outils d’IA générative en entreprise, consultez notre analyse de Claude et RGPD.

Google Cloud héberge de nombreux outils SaaS dont la conformité RGPD doit être évaluée individuellement, comme Slack ou Notion.

Support technique et accès aux données

Les ingénieurs de support Google peuvent accéder à vos ressources pour résoudre un incident. Activez Access Transparency pour journaliser ces accès et Access Approval pour les approuver préalablement. Pour les données sensibles, l’EKM garantit que le personnel Google ne peut pas lire vos données même en cas d’accès à l’infrastructure.

FAQ

Google Cloud est-il conforme au RGPD ?

Google Cloud fournit un cadre de conformité parmi les plus complets du marché : DPA conforme à l’article 28, certifications étendues (ISO 27001, ISO 27701, SOC 2, C5), régions européennes avec contrôle de localisation, chiffrement par défaut, et outils avancés (EKM, Assured Workloads, Access Approval). La conformité effective dépend de votre configuration : choix de la région, paramétrage d’IAM, politique de conservation, activation du chiffrement supplémentaire. Google sécurise l’infrastructure ; vous sécurisez ce qui tourne dessus. C’est ce type d’évaluation 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 réponse la plus efficace est l’External Key Manager (EKM) : vos données sont chiffrées avec une clé que vous gérez en dehors de l’infrastructure Google. Même si les autorités américaines obtiennent un mandat CLOUD Act, les données sont illisibles sans votre clé externe. Combinez l’EKM avec la région Paris, Access Approval, et Assured Workloads pour le niveau de protection maximal. Les autorités européennes n’ont pas interdit l’utilisation de Google Cloud et recommandent la mise en oeuvre de mesures supplémentaires pour les traitements sensibles.

Quelle différence entre Google Cloud et Google Workspace pour le RGPD ?

Ce sont deux produits distincts avec des conditions contractuelles et des DPA différents. Google Cloud Platform (GCP) est un service d’infrastructure où Google est sous-traitant : vous contrôlez intégralement ce que vous stockez et traitez. Google Workspace est un service de productivité où Google traite vos données dans un cadre plus structuré (Gmail, Drive, Meet), avec des conditions de service spécifiques. Si vous utilisez les deux, assurez-vous que les deux DPA sont en place et documentez les traitements séparément dans votre registre.

Comment choisir entre AWS et Google Cloud pour la conformité RGPD ?

Les deux plateformes offrent un niveau de conformité comparable. Les critères de choix RGPD sont marginaux : GCP a un avantage sur le chiffrement par défaut et l’EKM ; AWS a un avantage sur la certification HDS pour les données de santé en France. Le choix se fait généralement sur des critères techniques et business. Quelle que soit la plateforme, appliquez la même checklist : région européenne, chiffrement renforcé, IAM rigoureux, journalisation, conservation documentée. Consultez notre guide AWS et RGPD pour une analyse détaillée.